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

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

Hi,

Sorry for my late mail!
I still have less time at the moment and I don't think that this we change soon
:-(

On Sam, 19 Feb 2000, you wrote:
>Jake Fear wrote:
> 
>> Pascal, Maybe I am a pessimist, but I think automating the translation
>> from Java to C++ is a whole (and very difficult) project in itself.
>
>I just tried to find some tools to do this, because if we were to follow
>novosoft development, it would be highly useful. Sadly, such a tool
>seems out of reach for now.
>
>> Java is easy to read, I suggest we reuse the logic by using the Java
>> code as a "template", but performing the conversion more or less
>> manually.
I am sorry but I still I haven't enough time to check the nsuml sources and so
my ideas are just results of brainstorming.

I think extending the nsuml generator in order to make it able to generate the
c++ sources will be very hard. Maybe it's easier not to extend the
code generator but to port the _generated_ java sourcecode to c++.
But I don't have experience with tools that do a java->c++ translation so I
don't know a good method to get the c++ equivalent of the nsuml sources.

Getting the c++ sources will be harder and more time intensive as I've thought
:-(
Before we make a decision we all should imagine in what we engage!

On the other side I see the big advantages will could get if we do
it. 
One think would be XMI. I think XMI support is real importent if kuml
should be entitled to a commercial grade application. The possibiliy to
exchange models with other oo/uml tools would be very nice.

As my time is limited now (and other reasons) I can't become a leader role in
this task but it would be very nice if we could realize the switch.
Are there any volunteers for the leadership of this 'project' ?

Is it possible to realize XMI (not just XML with a selfmade DTD that isn't
compatible to the standard UML DTD!) with the current used metamodel?  Or is a
metamodel presumed like in ArgoUML that reflects the UML specifiction?
If so we would have to renounce to XMI and use a proprietary file format :-(

Let us see what we already have in kuml/data. There are metamodels for classes,
operations, attributes, use cases, packages and less others. The relationships
like generalization and association are partially written but not used or
tested at the moment.
There is a lot to do to make it complete and to support more diagram types. The
novosoft metamodel is complete, just the views have to be written.

>> Is there a final word on what to do with KUML's kuml/data
>> section?  I know it will need significant amounts of additional work, if
>> not a complete rewrite to address some of the suggestions that have
>> passed over the list.  I will have some time to hack on it soon, but I
>> don't know if I should do that yet.

>I have no good plan for how we should do this. But, what I know is that
>we have a well defined target and model : what ArgoUML does right now,
>which makes them far ahead from us. We have all the needed information
>(and certainly support) to succeed in this task. It will certainly ends
>up with a rewrite of some of our code, but, of course, it's really worth
>the pain.
I fully agree !

I think the harder part is to get the c++ equivalent of nsuml/gen/ru/novosoft/*

I will continue checking the generated nsuml sources at the weekend to get
more ideas ... 
Every idea on how to get the c++ equivalent is very appreciated!

-- 
Open your mind ...
Darius Stachow

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