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

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

Hi, Duane! 

>>>>> "DG" == Duane Griffin writes:

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

 DG> I think that the architecture that Jeff proposed does not need to be a
 DG> far away target. I don't think that that architecture imposes much
 DG> additional complexity, and if I thought it did I wouldn't be happy
 DG> with us using it at all. We do need to think about the repository
 DG> first though, and I think that is a point that we all agree on, yes?

 DG> CVS: I think the suggestion is that CVS be a part of how we implement
 DG> the repository (in fact the main part).

Agreed.  Should repository code be independed from actual repository
backend such as CVS?  I guess yes..

 DG> CORBA: I don't think it is decided that we are going to use CORBA
 DG> internally, by any means. In Jeff's architecture there are secondary
 DG> servers - one of these would be a CORBA interface to the system. Also
 DG> if we have a good modular interface to the components of the tool
 DG> CORBA should be able to be integrated later with a minimum of trouble.

Agreed.

 DG> Network: IMHO this should be fairly fundamental. One of my biggest
 DG> problems with ARGO is that it is a single monolithic program (albeit
 DG> an excellent one, Jason :). Personally I would like to slice and dice
 DG> the system as finely as is realistic, given performance requirements
 DG> and the operating environment.

If you wish to distribute FreeCASE at Repository Server interface I see no
problem.  Just implement yet another Secondary Interface Server and voila'
But distributing repository is difficult and, if we're goind to use CVS as
the basis, is very difficult.

My suggestions: 
 - repository is to be located on single node, 
 - network access to be done through Secondary Interface Servers, 
 - if necessary, repository may be replicated as usual CVS repository
   (that's have separate problems and I don't wish to bang my head against
    them now)

 DG>  IDE: I am a bit unsure as to what the IDE would be in that
 DG> diagram. Can Jeff or someone else explain in more detail what that or
 DG> the command line would consist of?

Umm... Don't know.  It is disconnected from the rest of diagram.  May be
Jeff just sketched ICVS<-IDE packages initially and then expanded it into
the rest of diagram?

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

 DG> I dunno, it sounds pretty good to me! I really can't see how any
 DG> decent CASE tool could not provide the features above, in one way or
 DG> another. We do need to discuss which to implement now and which to
 DG> defer though.

Well, I'm just describing a solution to the problem, not the features we
have to implement in first cycle :)  I'd better transform this to the
requirements specification and then, only at use-case level, would
prioritize them.

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

 DG> I agree. It should not need to be limited to UML, and indeed it may be
 DG> (should be? ) possible to use the UML meta-model quite nicely to define
 DG> models/languages that are entirely different from UML (CGs for
 DG> instance).

Uhum...  So actual repository code should be rather independed from the
metamodel.  Are UML Core Components flexible enough to become the
interface, which repository code should depend on?  E.g. are they flexible
enought to represent Concept Graphs?  I think so, but YMMV and I'm
interested in 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.

 DG> Firstly, I am assuming that by 'do better' you mean we should find and
 DG> use a better methodology, not that we should develop one ourselves...
 DG> IMHO we should keep in mind that UML is familiar to a lot of people,
 DG> and is becoming a de-facto (and indeed de-jure) standard. For a
 DG> production system (as opposed to a research system), this is perhaps
 DG> more important than technical merits, if the difference is not too
 DG> great. Also it should be noted that this project was advertised as
 DG> being a project to create a UML CASE tool, with other methodologies to
 DG> be support at some time in the future (i.e. probably after v1.0) To
 DG> change this would be fairly fundamental, and may alienate some of the
 DG> project's support base (which doesn't look too good as it is).

Thanks for supporting my point.

[...]

 DG> BTW, isn't it an absolute nightmare trying to discuss the design of
 DG> models, and the tools which work on them, using the language of the
 DG> models themselves?  I swear my brain has started leaking from my ears
 DG> during meta-CASE tool design brainstorming sessions. Writing the
 DG> paragraph above just brought all those memories rushing back :)

Yes, it is.  I remember when reading the UML 1.0 specification I had
constantly to decipher what 'the type Type' and 'the Attribute, associated
with the type Class' should mean :)   Yet, I don't know anything better :(

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

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