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

[Duane Griffin <duane.griffin@paradigm.co.nz>]

Hi Chen, Andrey, all,

Chen Ofek wrote:
> 
> I prefer the interative project development style over the linear one (i.e.
> requirements -> design -> implementation)

I agree completely Chen, but, as I am sure you know, within each iteration you
need a linear process. Before you can design you have to have some
requirements, before you can implement you have to have some design. Do some
analysis, do some design, do some implementation, then do it all again :)

> Andrey V Khavryutchenko wrote:
> >
> > 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)

This sounds like an excellent plan. As for the linear/iterative thing - we
should keep in mind that this is only the first iteration, the very beginning.
Obviously before we can do anything we need to have some idea of what we are
going to do. Brainstorming and throwing ideas around is a very important part
of the process of deciding what to do, but IMHO the goal of all that is to
produce some requirements that will enable us to start the design. It must be
kept in mind that this is not a research project*, it is a project to create a
free, working, usable CASE tool which will make the process of creating
software artifacts easier for developers.

* Not that I am saying new and innovative ideas shouldn't be used, or the
envelope pushed; just that if we produce some fantastic new ideas, but no
working (or usable) system we will have *failed*.

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

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

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

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

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

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

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

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

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

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

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

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

Well, I think that code generation is more a luxury myself. If the design is
good writing the code from it is easy (although most code generators I have
seen still manage to totally stuff it up :( Assuming that we have a reasonable
set of requirements getting the design right is the key thing, and so if we
are going to bootstrap anything it should be that.

Would it be reasonable to consider using stereotypes on the closest equivalent
UML constructs to implement a conceptual graph? I must admit that I have not
investigated Conceptual Graphs deeply, but from what I have seen and read I
don't see them as being incompatible with standard OO models. Could you, for
example, implement one by using a class diagram with one stereotyped class
representing concepts and another representing relationships? You could impose
a constraint on classes of type 'concept' that they can only be connected to
classes of type 'relationship', and a constraint on classes of type
'relationship' that they can only be connected to classes of type 'concept',
and that they must have 0, 2 or more connections. You could also stereotype a
relationship, and constrain the classes to only use that relationship, etc.

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

Cheers,
Duane.

-- 
Duane Griffin
Paradigm Technology Ltd
Phone +64 4 4951000