[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(FC-Devel) Core features...

Hello all,

in my opinion Chen Ofek and me are very close together, 
even if we seem to have different names for the same thing.
So I cited Chen Ofek's opinion with some of my additional 

> As I mentioned in my previous mail and in my discussion with Thomas
> Fricke
> (which seems to agree with me) I think
Thats right.
> that the main structure should be something like Conceptual Graphs.
> So, we should call our methodology "Concept Oriented Design".
> With Conceptual Graphs as our main structure I think that we should use
> as many
> diagram types as we can (e.g. State Machine diagrams, Use Case diagrams,
> Activity
> diagrams etc.)
> I think that we have to support three main domains with our diagrams:
> 1. Problem Domain

Is this the collection of use cases?

> 2. Solution Domain

Is this the place where the UML (or pattern parts) are living? 

> 3. Implementation Domain
> (our tool should support an unlimited number of Domains)

... and finally, is this the code generating and reengineering
domain? I am not sure, if this translations are the intended 

> I think that the most important feature will be to generate a set of
> diagrams for the Implementation Domain when given a set of Diagrams for
> the Solution Domain.

I have vague ideas about this part...

> If we can come up with an algorithm to transform between Problem Domain
> and Solution Domain it will be great.
> Also, we should have :
>     Generalizing Algorithm - will be used to move from Detailed Level to
> Top Level.
>     Specifying Algorithm - will be used to move from Top Level to
> Detailed Level.

This would be really exciting.

> The features of integrated Network,Corba and CVS are obvious important
> features but are not necessary for the
> first proto-type.

I agree, that they are not so important for the 0.99 versions. I think,
these problems could be solved later without changing the whole model.
For some of the problems I really have seen some solutions working.
The main ideas can be collected and be brought together.

> A note about development process: I think that we should generate a
> first proto-type which can do Conceptual Graphs,
> model our proto-type with that tool and continue our development with
> our tool.

This could be the point, were we really can start working together. I do
even need the graphic stuff at the beginning and would even be happy
with some text descriptions. We can start designing the viewing layer to
the diagrams as pictures with the tool inside. 

> In that way we can bootstrap our development and also use and check our
> tool as we develop it.

I think, this will speed up the development dramatically. So, we should 
start the first diagrams to design the first common patterns. I do not
if we should start immediately. However, there has been a discussion
days ago. What do you think about the inheritance modeled by Chen? 

> > In my humble opinion conceptual graphs should be talking about concepts. so
> > "class1","class2","role1","role2" are actuallyconcepts.
> > I would prefer something like:
> > CG {
> >     addConceptualConnection(Concept c1,Concept c2,Concept role1,Concept
> > role2)
> > }
> >
> You are right. The abused the class term. A class is an instance of
> several
> roles (subclass, superclass) in the inheritance concept.
> > This gives the possibility to use role1 as a concept in another connection
> > and creating complex design patterns.
> > For example:
> >
> >    cg.addConceptualConnection(myModel,myView,Model,View)
> >    cg.addConceptualConnection(Model,usageCount,subClass,superClass)

I have proposed an inheritance pattern, which have not looked general
However, trying to read the answer in details, I see, that I have not
the answer... Hmmm, anyone can help me? 

I think, we should start with an example (why not inheritance?) to see
the concept at

Bye everybody

Thomas Fricke
Fon: +49/30 386-36 344, Fax: -21928
Siemensdamm 62, D 13629 Berlin