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

[Andrey V Khavryutchenko <akhavr@compchem.kiev.ua>]

Hi, Thomas! 

>>>>> "TF" == Thomas Fricke writes:

TF> Andrey V Khavryutchenko wrote:

>> >> We didn't yet decided what problem we're going to solve.  We >>have
>> no requirements document.  We have no use cases.

TF> I tried to start with a very simple use case: derive complex numbers
TF> from real numbers. This case is an example everybody knows, and it is
TF> so simple, that it is hard to simplify it further.

Ouch.  I think we understand different things under the `use-case'.

I use `use case' in Jacobson sence: the atomic, valuable operation to an
external user of the system (an actor).  (For more info see the respective
chapter on cetus-links
http://www.cetus-links.org:80/oo_ooa_ood_methods.html ) 

I don't understand how your example fits this definition.

>> Helping programmers is an enormous problem.  And CASE tool won't do help
>> much (at least in commercial area) because major problems are related to
>> the project management (see Software CMM from SEI).

TF> Case tools are real big problem in any project I know.

Well, that's not my experience, but I don't want to discuss that now, since 
it does not belong to that project.

[...]

>> Too easy, unfortunately :( If you talk too long and do too little, very
>> few will follow.  Remember what was the boost of activity at Jun, when
>> Jeff anounced the project?  And where is it now?

TF> The decision to buy a certain casetool lasts usually more than 3
TF> months, the decision for the basic architecture (if we all have another
TF> job to do) we needed is not too much.

I don't see how that applies to our case.

CO> We need a Concept repository.  A Concept is basically defined by
TF> its
CO> connections.  Every Concept has an ID and a list of Ports.
>>

TF> I agree with concepts =~ patterns and port =~ roles?

Let's first do something with basic design elements, defined in UML and
then proceed to patterns.

[...]

>> > CO> The basic interface to the Diagram repository is
TF> connect(Concept c1,
CO> Concept c2, Concept port) : connect Concept c1 to Concept c2
>> through
CO> port port.  On this basis we can define any diagram we want.  Every
CO> Diagram as a whole is also definning a Concept.  For example: in out
CO> tool we should have the Concept of CodeGenerationComponent,we obviously
CO> need a Diagram to state what is the inner structure of this Concept,
CO> but if we define it as Concept we can use it as a node in another
CO> Diagram and we also can check (with argo's critics) if the Ports of the
CO> Concept are consistent with its inner structure.
>>

TF> I agree. This way we can derive more complex diagrams from the simpler
TF> ones.

Sorry, lost completely.  Can you describe your idea with more details?

>> ...  > CO> Now we can comlicate things and go to do detailed design
TF> with our > CO> Diagrams. lets say that Association is a general term
TF> for using a
CO> specific interface. (lets say calling the method doIt() ) So we
>> will
CO> define the CallingMethodDoIt Concept as : CallingMethodDoIt -->
CO> concept1 (again use definePort) define also : CallingMethodDoIt -->
CO> (via port subClass) Inheritance (via port superClass) <-- Association

>>  This is not the inheritance.  This is the instantiation of the
>> association.

TF> I cannot follow this detail.

The difference between a CallingMethod and CallingMethodDoIt is the same as 
between the class and the instance of that class.

[...]

TF> 1. Then we should focus on a general code generator, the repository and
TF> documentation. (perhaps SGML, perhaps cvs)

Well, I'm suggesting to use SGML as data format, not just as a format for
generated documentation.

TF> 2. Lateron we can decide to distribute the application, perhaps using
TF> Corba.

I think system should be distributed only at the secondary interface server 
level.

TF> The Conceptual Graphs and UML seem to be a good common starting
TF> point...  If we have simple example writing code onto the filesystem,
TF> we can connect it to a better repository.

This _could_ be done.  I _can_ do that. But first, I have to know, what
functionality that code should provide.  Therefore I've proposed the
problem statement and by the end of the week want to come out with
specifications for first iteration.

-- 
SY, Andrey V Khavryutchenko	http://www.kbi.kiev.ua/~akhavr

Shick's Law:
	There is no problem a good miracle can't solve.