Hi, Chen! Hi, everybody!I have regarded last month discussion more as brain storming before we sit and do an ordered definitions and design.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?
We didn't yet decided what problem we're going to solve. We have noI thought the problem is : helping programmers in their job.This is a very big problem, which probably don't have an ultimate solution. that's why I think we should play with our ideas (both in discussion and in a working proto-type) and see what come out.
requirements document. We have no use cases.
Sorry, Chen. I very appreciate your ideas, but I've seen lots of projectsI don't see how a free project can die when the discussion is interesting :)
died from too deep diving into details just from the start.
>>>>> "CO" == Chen Ofek writes:I think you are being too linear.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)
>From that point we'll know what we're goind to build to solve the problem.I agree to that architecture as a far away target. As I stated in another article I think that the CVS, Corba, network and IDE are not important to the first release.What Thomas and I are trying to think about is the repository and we started talking about code generation.
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.
So, here goes the problem, as I view it.Again, you are being too linear.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:
- manipulate (create, read, update, delete -- CRUD) create a structured
document
- manipulate (CRUD) any of its items
- create a dependendency link to any part of its item or item of other
document (may be subject to the interface, exposed by document
[module])
- store document(s) in a versioning system with full support of diff'ing,
tagging, branching
- comunicate it to a developer in both native and semi-standart formats
like gif, structured text or something else
- produce reports
- manipulate (CRUD) reverse dependencies to code (the code depends on
design, not otherwise)
- allow some integration with third-party tools like project managementI think that your requirements document should be titled TODO document. we should add to it all those good ideas we want to see in our tool. there is such a list on the FreeCASE home page in the page : detailsAll your requierments sounds good, but again it is a broad target. If you are satisfied with UML then work on argo/UML.I think that we can do better then UML, and provide a transformation from Conceptual Graphs to UML Domain.
and bug tracking programs, perhaps trough versioning system
- allow custom scripting with high-level language like tcl
(http://www.scriptics.com) or python (http://www.python.org).
Since the UML becomes the standart language for describing software models,
the solution should be based on (but, perhaps? not limited to) it.
As you can see, graphical diagram editing tool is not specificallyYou are probably confused by my vocabulary. When I say Conceptual Graph I don't mean graphical user interface.
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.
To bootstrap the project we need the repository and diagram tool ready.This will boostrap our design but we need also code generation component to help us write the code.
Since previous discussions seem target mainly editor issues, let's theI think that we have discussed mainly the repository questions :)
first design goal defined will be the interface to repository.
chen
