[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (FC-Devel) core design + project steps
>>>>> "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,
>> As the preliminary architecture I suggest adopting what Jeff Wolfe did
>> propose. The diagram is at
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
>> 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>Again, you are being too linear.
CO>> - allow some integration with third-party tools like project
CO>> management and bug tracking programs, perhaps trough versioning
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
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
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
There is no problem a good miracle can't solve.