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

[Danny Werner <danny@vrijdag.xs4all.nl>]

Hi all, hi Duane & Jason,

Please consider _not_ responding to this message as it is. 
There are many important topics here. I'll cut it into 10 pieces 
and send them to the list. Wait for the pieces (AFL 1..10) to
respond.
I'll try cutting in a way that won't hurt the original author's
points, but if I will just shoot me, don't flame.  

Jason wrote:
 
> 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.

In my view this comes close to an optimal form of what 
we have right now, under the assumption that everybody
on the team has it's own set of collaborating tools and
toolettes, in a very suboptimal way. We are not yet able
to cooperate as a team because of the zillions
of differences in mind-sets and in the formats. 
So if we just stick together and to the goal, we grow our 
own FreeCASE, working out the interfaces as we are improving
in getting along. The UML gives coordination on the mind-set,
now let's crunch those formats.

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

Please expand on that, Jason. This is where the problems are
that we have to tackle anyway.
 
> 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.  

They did. It is called 'the Internet'. 
Should I include the word in the glossary?
I hesitated putting in CORBA ;-)

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

Should we? I don't think so. Not getting the interfaces right at
the first go gives some nasty jobs later on, but that is - I think -
what we agreed to give our best shot at when we joined the team.

> Even if we do it as well as current CASE
> tools, we might limit ourselves to the 
> feature-set of current tools.

Even less. Keep it very very simple, as simple as possible 
for the first go. As soon as we can jointly model and build a 
distributedly running trivial "hello world!"-ish application
with FreeCASE, I'll be drinking champagne with Pierre Jarillon. 
(Sorry, US is to far) 

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

Succesful integration of (not to big) models into one is 
only possible after very intensive communication amongst
people having deep knowledge of the individual models themselves.
Nobody has the complete model in his or her mind when working
on a part. Why should we expect a computer system (one central
leading repository) to be capable of that complexity. 
Why should anyone think that people are able to design
such a system. The power of the internet stems from not
having the need of much -if any, by now- permanent central
authority.

> We would be relying on t standards
> such as OMG's MOF to determine what the interface to the repository

I did not study the MOF yet. I will. Jason's suggestions are very
good until now, so I'll trust him on this one.

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

Yep, let's not make another Island. Let's make bridges. 
 
> 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?
 
(Duane):
> >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?

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

Well? Is it dissectable?
(I did not get it running yet because of some stupidities
here, but I was very impressed by the tour and by the GEF-demo's)
BTW, So that's were we start, Jeff?
 
> Hoever Argo is no "thin client" by any means.  Argo will probably
> always be a memory and CPU hog.  

Maybe we could relax on that requirement and not demand
thin-client ability for every task. Model/code (any supported 
language, not just java) browsing for instance should not
need such a 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

I've read Jason's (e.a.) paper "Software Architecture Critics in
Argo".
I can't wait to try.

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

That's why we will have to be able to communicate 
workable parts between stations. 
It is also a reason to isolate the 
'model'/'language feature' mapping.
 
> 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.
 
(Duane)
> >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!

Perl. If there are Python adepts here, oh well, 
but I won't learn Tcl! (nor VBA, read on)
 
(Jason):
> 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.
 
(Duane):
> >* 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.

Here, here! Applause. Or whatever. Serious, let's agree on that.
It's in Jeff's list but it doesn't hurt to emphasize it as a
core requirement.

> 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?
 
-------
Please don't make emails this long ever again, especially when
the contents is so damn interesting. It does'nt comply with 
the idea of small components and cooperation on parts someone
is good at. Please comment on my partitioning.

			Danny
====
Voltaire: "One only values dreams that came to fruition."