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

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

Hi, Chen!  Hi, everybody!

I've finally finished my project, so I can now spend time on what I like to 
do, not what I have to.

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 no
requirements document.  We have no use cases.

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" == 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)

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

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
  - manipulate (create, read, update, delete -- CRUD) create a structured
  - 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
  - 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 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.

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.

To bootstrap the project we need the repository and diagram tool ready.
Since previous discussions seem target mainly editor issues, let's the
first design goal defined will be the interface to repository.

I'm going to install Argo/UML next week and play with it.

Ok, mail is already long enough, so I shut up.

Feel free to throw your favourite piece of cake on that.

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

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