[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

I have regarded last month discussion more as brain storming before we sit and do an ordered definitions and design.
We didn't yet decided what problem we're going to solve.  We have no
requirements document.  We have no use cases.
I 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.
I prefer the interative project development style over the linear one (i.e. requirements -> design -> implementation)
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.
I don't see how a free project can die when the discussion is interesting :)
>>>>> "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)

I think you are being too linear.
>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.

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

Again, you are being too linear.
  - allow some integration with third-party tools like project management
    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.
I 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.
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.
You are probably confused by my vocabulary. When I say Conceptual Graph I don't mean graphical user interface.
The word graph here is used in the mathematical sense (a connected, directed graph).
So, what Thomas and I are discussing is a specific type of diagram that can be used as our repository interface because it is so general.
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 the
first design goal defined will be the interface to repository.
I think that we have discussed mainly the repository questions :)
I will write a seperate article to explain my view about the repository.

chen