Re: (FC-Devel) core design + project steps

["Dr. Thomas Fricke" <Thomas.Fricke@oen.siemens.de>]

Hi all,

just in time to save a rainy weekend the mail from Chen Ofek 
arrived :-)

> I also introduced a global Concept Map (it is an STL map that you can
> find a pointer to concept given its name).
> The idea is that if a concept is used in two different diagrams it
> refers to the same concept and the code for the concept will have to
> consider both (or more) diagrams.

Good idea, this is a common source of problems in our tool (STP from
aeonix)

> But now I have a problem of all concepts have the same scope, so I need
> something like name space. which is not implemented.

To be solved later...

> I saw in the mailing list archives some discussion about argo/UML and it
> looks like you have decided to use it as the first step.

More or less, there has not been a final discussion. 

> I have run argo and it looks very nice as a beginning, although it takes
> a lot of memory and CPU, I assume because java is an interpreter.

I think, the swing lib is the problem. I have run into memory swapping
on a 64 MB Linux...

> But the question is what is the add-on of this project. If we want to do
> UML tool I think that a better way would be to join the argo project and
> not to split forces.

I agree.

> I think that as a seperate project we can work on the idea of generating
> code with Conceptual Graphs and try to write such clever algorithms as
> were discussed earlier (transformation from Domain to Domain,
> Generalization and Specifying algorithms).
> btw: in that case I think we should change our project's name to "COD -
> concept oriented design"
> 

As tried to explain earlier, we can glue together several project.
The result will be a rather fat application, this is not optimal,
I can live with a hybrid solution.
 
> The most urgent tasks I think are :
> - agree about the general design (interface to the Conceptual graphs and
> the question of global concept map)

I agree.

> - use GEF (the graph editor framework from uci) to implement conceptual
> graphs.

For practical reasons.

> - implement code generation (either in argo/UML or directly from
> Conceptual Graphs) so that we can bootstrap our project (as I suggested
> earlier)
>

I see argo/UML more as a viewer, but I need a closer look. The code
should
be generated in the CG part.
 
> Tell me what do you think (I hope I was clear about all my points).

I think most of your comments are clear. The negative consequences of
gluing together argo and some C++ CG part is the necessity of some corba
stuff ( or something with similar functionality) 

Then we have involved 

C++:
	CG
	DataBase (or files, for the beginning)
	Code Generator
	C++ Corba
-------- interface ------------
Java:
	Java Corba
	Swing
	Argo
	JVM

This is a rather fat application from the system design point of view. 

I will have to buy some more memory for my Linux system... I is not a 
principal, only a practical problem... If we could decide to use pure
Java, we can save all above the JVM. If we decide to use C++, we need
some
viewing code.

What do the others think about the problem?

Have a nice weekend,

	Thomas

-- 
Thomas Fricke
SIEMENS AG, OEN TR SW PT    
Fon: +49/30 386-36 344, Fax: -21928
Siemensdamm 62, D 13629 Berlin