Re: (FC-Devel) Re: Argo (+architecure +feature list)

[Jason Elliot Robbins <jrobbins@cadet.ics.uci.edu>]

Hi Duane,

>In terms of architecture, my personal preference would be a system of small
>inter-operating components (OK, I'll succumb to temptation and use a
>buzz-word, "Software Agents"), rather than a single application. This will
>give us a great deal of flexibility and scope for integration with existing
>and future tools, add-ons and environments. It would also allow us the freedom
>to develop different components in different languages, and provide other
>benefits in terms of ease of development.

By "components" I assume you mean pieces of code running in different
processes.  I am totally in favor of good modularization, but having a
lot of processes gets really sticky.

There are a number of trade-offs here.  Component-based systems are
much easier to develop if you have a good, stable architecture and
interface specs.  Devloping such an architecture is best done by
people who have substancial experience with similar systems.  It seems
that the FreeCASE team has a lot of experience in a lot of things, but
I think this would be the first component based CASE tool for all of
us (including me), and it is unlikely that we would get interfaces
right on the first few trys.  Even if we do it as well as current CASE
tools, we might limit ourselves to the feature-set of current tools.

One really helpful thing is the UML standard.  If we can agree on a
common data repository and data representation then we could prbably
be able to do a star-topology system where everything goes through the
repository.  If you look at the history of CASE standards, most of
them rely on shared repositories.  We would be relying on t standards
such as OMG's MOF to determine what the interface to the repository
should be.  An alternative would be to rely on a standard streaming
format, like XMI or UXF and a common representation of a UML document
in memory.  File based integrations are not so flashy, but they work,
they are easier to test, and it would make it easier to integrate with
existing development utilities, e.g., CVS.

As far as I know, no one has implemented a truely distributed CASE
tool, other than simply placing a repository on a different host.
Some tools, like (older versions of?) Software Through Pictures and
Cyanne's ObjectTeam seem to have a shell application and separate
applications for diagram editing, code generation, reporting, and
(limited) model analysis.  However, I think all of these components
execute on the user's desktop.  Maybe someone in the project knows
more about these tools?  

>How easily do you think the existing
>Argo system would fit into that or a similar model? If it doesn't fit well,
>how easily could it (or rather it's component pieces) be adapted to such a
>model?

Argo/UML does not have any persistence mechanism right now, so it
doesn't matter if it was file based or a UML repository server.  In
terms of Jeff's architecture diagram, Argo would be a Java GUI model
builder.

Hoever Argo is no "thin client" by any means.  Argo will probably
always be a memory and CPU hog.  Luckily memory and CPU time are cheap
and plentiful.  Some of the best features of Argo come from its
relatively tight integration of model with analysis, model with code
generation, and model with reverse engineering.  Design critics are
active all the time and constantly interacting with the model and user
interface.  Code generation is (intended to be) done in a very
incremental and interactive way so that the user can see how each
model change affects the code immediately.  Likewise, reverse
engineering (little more than parsing) should be integrated tightly
enough that users can modify the code fragments shown in the "Source"
tab and see the affects in the diagram or property tab immediately.
Relying on IPC or launching external programs for analysis and code
generation would almost certainly make Argo's current features too
slow.

You can tell which current CASE tools do things all in one process or
in different processes just by looking at their features.  Tools that
provide code views have CG & RE in the same process and focus on one
language, e.g., StructureBuilder or TogetherJ (I think).  Tools that
do not provide views of code and instead have batch commands for CG &
RE in multiple languages use different processes, e.g., Rational Rose.

http://www.tendril.com
http://www.togetherj.com
http://www.rational.com

The implementation might be changed a little to break things apart,
but not too much because the main features all need direct and
immediate access to the UML model and the user interface.  For
example, critics and code generation need to be running on the user's
desktop to give good interactive response times.  I have just added a
module dependency diagram to the web site.



>Some other feature/wish list items:
>* Extensibility and flexibility, this is a real lack in current CASE tools,
>from my limited experience. Especially if you arn't prepared to pay the owners
>to write the custom extensions for you!

Rose has a VBA-like scripting language, some others scripting
langauges too.  One advantage of an open-source tool would be that
people can hack code to do deep customizations.

>* Support for arbitrary methodologies and diagrams (including a minimally
>lossy transform between them) If I remember correctly, we may even be able to
>do this just using UML, doesn't it sort of become almost arbitrarily
>extensible through the use of stereotypes and supplementary features?

You can customize UML to add meaning to the diagrams.  In fact, I
published a conference paper on one way to do that.  See my home page
for the paper "Integrating Architecture Description Languages with a
Standard Design Method".  Different graphical diagrams is a related
issue.  I would rather see us focus on UML than try to spread
ourselves too thin on UML, OMT, Booch, Fusion, etc.

http://www.ics.uci.edu/~jrobbins

>* Integration with e-mail to provide facilities like periodic automatically
>generated progress reports, notifications of changes to specific areas of
>interest, links between messages/threads and documents (code, diagrams, etc)
>in revision control, etc.

Interesting idea.  The only current way that Argo uses email is to
send feedback to the authors of criticisms.  That way if you import a
class for playing sounds into your model and you specify that you
intend the app you are working on to run on PCs, UNIX, and Macs, you
might see a message from the author saying that this particular
reusable class does not work relably on the Mac.  You could then send
email to the person who authored that criticism of that reusable class
and ask them more about it.  This is currently stubbed out, I should
finish it by integrating with the JavaMail library.


>Yep, it certainly looks a good starting point, both in terms of the concepts
>and the code. I especially like the critics, one of the people I was working
>with on another CASE tool project had a very similar idea, but we never even
>got close to getting it off the ground. It sounds like you have some really
>interesting and innovative ideas that could go a long way towards providing
>the added value that FreeCASE could offer, as you mentioned above.

Thanks.  I like the critics and I am glad that other people like the
idea.  One thing that I would love to see happen is for people other
than me to start writing critics.  The framework is there and it is
pretty simple, but can people codify their ideas about good design in
a way that helps others?

jason!