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

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

Hi, Chen! 

>>>>> "CO" == Chen Ofek writes:

 CO> Andrey V Khavryutchenko wrote:

 >> Hi, Chen!  Hi, everybody!
 >> 
 >> I've read the last month discussion on the list and have to say, that
 >> we're going into premature design :( Why I think so?

 CO> I have regarded last month discussion more as brain storming before we
 CO> sit and do an ordered definitions and design.

Well, it migh be viewed that way too.  Perhaps my perception is due reading
the month worth discussion within few hours.

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

 CO> I thought the problem is : helping programmers in their job.This is a
 CO> very big problem, which probably don't have an ultimate
 CO> solution. that's why I think we should play with our ideas (both in
 CO> discussion and in a working proto-type) and see what come out.  I
 CO> prefer the interative project development style over the linear one
 CO> (i.e.  requirements -> design -> implementation)

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).

Besides, will we produce something, if we even didn't agreed on what we're
going to do?

 >> Sorry, Chen.  I very appreciate your ideas, but I've seen lots of
 >> projects died from too deep diving into details just from the start.

 CO> I don't see how a free project can die when the discussion is
 CO> interesting :)

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?

 >> >>>>> "CO" == Chen Ofek writes:
 >> 
 CO> The most urgent tasks I think are : - agree about the general design
 CO> (interface to the Conceptual graphs and the question of global concept
 CO> map) - use GEF (the graph editor framework from uci) to implement
 CO> conceptual graphs.  - implement code generation (either in argo/UML or
 CO> directly from Conceptual Graphs) so that we can bootstrap our project
 CO> (as I suggested earlier)
 >>  I suggest the alternative steps.
 >> 
 >> 1. Define the problem (limit the scope).  I'll try to do that later in
 >> the mail.
 >> 
 >> 2. Define the requirements (functional, non-functional, domain terms)
 >> 
 >> 3. Write down use cases (just names for the start)

 CO> I think you are being too linear.

This is just a first iteration.

 >> >From that point we'll know what we're goind to build to solve the
 >> problem.  Then we can discuss what way we'll implement these
 >> requirements and discuss possible techniques, including your ideas,
 >> Chen.
 >> 
 >> As the preliminary architecture I suggest adopting what Jeff Wolfe did
 >> propose.  The diagram is at
 >> http://felgroup.creol.ucf.edu/FreeCASE/design/system_architecture.gif.

 CO> I agree to that architecture as a far away target. As I stated in
 CO> another article I think that the CVS, Corba, network and IDE are not
 CO> important to the first release.What Thomas and I are trying to think
 CO> about is the repository and we started talking about code generation.

And what's important?  I don't view code generation as a first priority
task.  The cornerstone is the repository, and versioning should be deep in
its nature.

 >> So, here goes the problem, as I view it.
 >> 
 >> One of the major problems in software development is the documenting,
 >> storage, versioning, retrieving and communicating the analytical and
 >> design documents.  The successful solution to this problem should allow
 >> its user to:
 CO>>   - manipulate (create, read, update, delete -- CRUD) create a
 CO>>     structured document
 CO>>   - manipulate (CRUD) any of its items
 CO>>   - create a dependendency link to any part of its item or item of
 CO>>     other document (may be subject to the interface, exposed by
 CO>>     document [module])
 CO>>   - store document(s) in a versioning system with full support of
 CO>>     diff'ing, tagging, branching
 CO>>   - comunicate it to a developer in both native and semi-standart
 CO>>     formats like gif, structured text or something else
 CO>>   - produce reports
 CO>>   - manipulate (CRUD) reverse dependencies to code (the code depends
 CO>>     on design, not otherwise)
 CO>
 CO>Again, you are being too linear.

Where particulary?

 CO>>   - allow some integration with third-party tools like project
 CO>>     management and bug tracking programs, perhaps trough versioning
 CO>>     system 
 CO>>   - allow custom scripting with high-level language like tcl
 CO>>     (http://www.scriptics.com) or python (http://www.python.org).
 CO>> Since the UML becomes the standart language for describing software
 CO>> models, the solution should be based on (but, perhaps? not limited
 CO>> to) it. 

 CO> I think that your requirements document should be titled TODO
 CO> document. we should add to it all those good ideas we want to see in
 CO> our tool. there is such a list on the FreeCASE home page in the page :
 CO> detailsAll your requierments sounds good, but again it is a broad
 CO> target. If you are satisfied with UML then work on argo/UML.I think
 CO> that we can do better then UML, and provide a transformation from
 CO> Conceptual Graphs to UML Domain.

Don't you think that we will redo the work done by UML guys?  As far as I
understand, you're suggesting to create our own metamodel.  I feel UML is
just as powerfull as it has to be and just as flexible as it should be.

 >> As you can see, graphical diagram editing tool is not specifically
 >> highlighted.  It should be just one of many ways to interact with the
 >> underlying model, but, likely, the most widely used.  Such editor(s)
 >> would be implemented as tools, operating on documents, extracted from
 >> repository.

 CO> You are probably confused by my vocabulary. When I say Conceptual
 CO> Graph I don't mean graphical user interface.  The word graph here is
Um.  Perhaps.  Sorry.
 CO> used in the mathematical sense (a connected, directed graph).  So,
 CO> what Thomas and I are discussing is a specific type of diagram that
 CO> can be used as our repository interface because it is so general.

Yes, I see.  But why should we redo what already have been done?  Why just
not take UML metamodel as the start, it's classes as our domain classes and 
one of SGML/XML formats as the storage?  I guess we'd receive a major push
by reusing those bits.

 >> To bootstrap the project we need the repository and diagram tool ready.

 CO> This will boostrap our design but we need also code generation
 CO> component to help us write the code.

Why code generation?  I don't think it's very usefull (at least I haven't
seen a usefull code generator).  Besides, what language it will target?
C++?  Java?  And what about high level scripting languages like python?  Or 
lower level like C?  Just this morning I had to review few files from INN
(the popular free internet netnews server).  It's written in very strong OO 
style and I'd like to be able to use FreeCASE to work with it too.

 >> Since previous discussions seem target mainly editor issues, let's the
 >> first design goal defined will be the interface to repository.

 CO> I think that we have discussed mainly the repository questions :) I
 CO> will write a seperate article to explain my view about the repository.

Ok.  But I have the question: what is missed or should be dropped from my
problem statement?  If we'll agree on it, I will proceed with the
requirements specification.

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

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