[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Fwd: Re: [argo-dev] Re: p_george: KUML and Argo
From:       Darius Stachow <shiva () dialup ! nacamar ! de>
Date:       2000-02-17 17:25:31
[Download RAW message or body]



----------  Forwarded Message  ----------
Subject: Re: [argo-dev] Re: p_george: KUML and Argo
Date: Thu, 17 Feb 2000 11:32:56 +0100
From: Marko Boger <boger@informatik.uni-hamburg.de>


Hi everyone,

I am very pleased that Argo and KUML have found each other and are getting in
touch. Both project share a similar goal and are similarly ambitious. Both are
alive and making advances.

Both are open source and are part of open source communities. The difference is
that these communities are different. KUML is designed and developed for KDE
and Kdevelop. Argo is written in Java and part of the Java opensource community.

KDE and Java are two different platforms with different advantages and
disadvantages. 
KDE is especially designed for Linux, fast, and tightly integrated with a
large set of tools for this environment. 
Java is platform independent and much nicer as a language, but not as fast or
powerful as C++.

Jason and p-george have raised the issue of joining into one Projekt. Although
this might have the adantage of joining forces, I strongly believe that we
would be giving up the avantages of the platform we would lieve behind.
Clearly we should cooperate, but we should not join. 

I believe that  the most important issue for cooperation is the same file
format. This would allow us to exchange models, use each others tools etc. The
declared standard for doing this is XMI. In Argo this standard has already been
proven very usefull. For (some) other tools export to XMI is available. 
But XMI only stores the semantic information of a model. It does not store the
graghical information, like layout. This should be stored in a different file
for a clean separation. In Argo we use PGML and it also has proven to be
usefull. 

The second most important issue for cooperation is the meta model. The meta
model is used to store the model information at runtime. A structure
for such a meta model is nicely described by the OMG in the UML
standards. In Argo we now use a meta model that is directly generated
from this standardised model (a rational rose mdl-file). Toby and I have met
with Dariusz and Michel. We have shown them the meta model API and how it is
generated. It should not be too difficult to change the generator to  produce
C++ code. Novosoft also has expressed interest to support this. 

Then the two tools would be equivalent on the underlying model layer; XMI
import and export would come allong with that for free (it is also generated).

Then after that each of the two groups can choose what to adapt  from the
others, or whether we want to try out different things. On the view layer, I
think it would even be good to go some different ways, only that way new things
like rapid buttons, brooms tools or table views are developed. 

Ciao, Marko


On Thu, 17 Feb 2000, you wrote:
> Hi Everyone,
> 
>   This is a message from one of the core developers on the KUML
> project.  He raises several questions that we should answer.  
> 
> Thanks,
> jason!
> 
> ------- Forwarded Message
> 
> Date: Wed, 16 Feb 2000 21:48:46 +0100
> From: p_george <p_george@club-internet.fr>
> To: kuml-devel@barney.cs.uni-potsdam.de
> Subject: Re: KUML and Argo
> 
> Jason Elliot Robbins wrote:
> 
> > As for speed, Java is slower than C++, but that does not matter as
> > much as it once did.  Computers and JVMs are getting faster.  Also,
> > Java's multithreading ability make it easier to maintain interactive
> > performance (redraws per second) even if there is some application
> > processing going on at the same time.  It is true that ArgoUML has
> > some performance problems, but then again, I have never tried to
> > optimize it very much yet.
> 
> Some time ago, Corel gave up their office suite written in Java, because
> of performance. I really prefer programming in Java, but it has, and
> will always have, this important problem.
> For example, using kuml (with a less than optimized code), the import of
> nsuml source files takes more than 7 minutes on my outdated PC (Pentium
> 133 with 64 Mb RAM). With Java, it would mean more than one hour ! Even
> with a high end PC, it will remain too long. And nsuml is only a medium
> sized project (118.000 lines of code, 270 classes).
>  
> > If you want to switch to Java, I think there a million things we
> > should share.
> 
> If we were to switch to Java, then we'd better give up kuml and join
> ArgoUML.
> There is no point in continuing 2 different open source projects with
> exactly the same goals.
> 
> > Both projects could really benefit.  And "consumers"
> > would still have a choice among the differences.
> 
> Differences will be less and less visible as time goes : I think we'll
> take the nicest features of both kuml and ArgoUML. For example, we will
> certainly take the rules from ArgoUML that show advices to the user
> (like 'you forgot the attributes', 'you should use a singleton', etc.).
> I also like the table view showing the different classes. The UI
> interface of ArgoUML is far more advanced than ours (because of bells
> and whistles that are really missing in kuml for the moment).
>  
> > Here are some suggestions as to how we might work together even if the
> > KUML team decides to stick to C++ (these are just rough ideas):
> > 
> > Command line utilities to do merging of models, reverse engineering
> > into XMI, code generation from XMI.
> 
> Unfortunately, I don't know XMI at all (but it seems so important, that
> I'll have to learn it).
> 
> What I propose is to use common parsing and code generating processes.
> But there arises the problem of performance : I integrated 2 parsers in
> kuml, a Java one from ANTLR (www.antlr.org), and a C++ one from kdevelop
> (some improvements are under work, and will be committed in time). We
> may agree on an API that will allow the generation of XMI data from
> source files. I can make the parsers available as standalone dynamic
> libraries and you may use JNI to access them, if you agree in the use of
> native code.
> 
> For the problem of synchronization and coherence between a data
> repository (XMI ?) and source files, I started to think about it, and we
> may take great advantage by cooperating, as this is what will make *Uml
> (* = K | Argo) really useful for programers. 
> 
> There comes the real question underlying all this : WHY have TWO
> projects ? If all our work could be focused on a single project ...
> I know it is difficult to give up a project for another one, after
> having done a lot of work, but this should be considered.
> 
> I have to confess that if there was not the performance problem (that
> will never disappear), I would have joined ArgoUML.
>  
> > Command line tools for design analysis or metrics (input in XMI
> > format).
> 
> Design analysis like the Cable tools do is out of our scope, because too
> ambitious, I think.
>  
> > Shared file formats and similar user interface features.  This might
> > allow us to share some developer and/or user documentation.
> 
> This is very much like having a single project.
> 
> > Shared end-user documentation for UML.   I have noticed a real
> > shortage of UML tutorial information that is freely avaiable.
> 
> Yes, we (and especially I) need good documentation : we may dispatch the
> work for this.
>  
> > Shared scripting interface: e.g., we might both implement embedded
> > python shells that allow some functionality to be scripted and run on
> > either tool.
> 
> Maybe later, in release 5.0 ?
>  
> > I am sure there are many other ways we could work together for our
> > mutual advantage.
> 
> I personally volunteer to look at the process :
> 
> Source files --- Parser ---> repository (XMI ?) --- code gen. --->
> source files
> 
> What I need is to know more about XMI (what it does and doesn't), in
> order to make an idea whether it is feasible to use it as a repository
> (data that will ensure the coherence of the user's project).
> 
> Is there any contact in the ArgoUml team that may work with me on this ?
> 
> 
> 
> ------- End of Forwarded Message
> 
> 
> ------------------------------------------------------------------------
> Registering a domain name is quick and easy.
> http://click.egroups.com/1/1611/0/_/8551/_/950750153/
> 
> -- Talk to your group with your own voice!
> -- http://www.egroups.com/VoiceChatPage?listName=argo-dev&m=1
--
Marko Boger - Distributed Systems - Hamburg University
http://vsys-www.informatik.uni-hamburg.de
-------------------------------------------------------

-- 
Open your mind ...
Darius Stachow

[prev in list] [next in list] [prev in thread] [next in thread]