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

List:       kde-kuml-devel
Subject:    Fwd: Re: nsuml library for C++, KUML
From:       Darius Stachow <shiva () dialup ! nacamar ! de>
Date:       2000-02-15 16:11:45
[Download RAW message or body]

Hi,

I've asked Toby to send the people of novosoft a mail and to ask if they can
assist us if we all agree to the design change.

I forward you their reply.

----------  Forwarded Message  ----------
Subject: Re: nsuml library for C++, KUML
Date: Tue, 15 Feb 2000 21:29:00 +0600
From: Constantine Plotnikov <cap@mail.novosoft.ru>


Hi!

Toby Baier wrote:
> We (say, Marko and me) just found out that some developers for KUML, a
> KDE UML-tool, live right here in Hamburg. I guess you know about the
> importance of KDE (if not, visit http://www.kde.org), which is next to gnome
> the most used desktop environment for Linux. KUML will be a tool neatly
> integrated to KDevelop, the standard IDE for KDE developers. At the moment
> KUML is still alpha, but they have many very eager developers, and they are
> getting forward rapidly. At the moment KUML can draw class diagrams and use
> case diagrams, load and save projects (only via serialization, not XMI), and
> the RE works quite well (KUML culd reverse engineer the nsuml "gen" directory
> in about a minute! The generated diagrams were a little crowded, though).
> 
> We have met Darius and Michel, two of the developers (Darius is lead
> developer for KUML), and told them about nsuml and how we use it in Argo.
> They were very impressed and consider to use something like it for KUML as
> well. At the moment they are discussing a MM exchange on their mailing list:
> http://lists.kde.org/?l=kde-kuml-devel&r=1&w=2&b=200002
> 
> What do you think, would it be interesting for Novosoft to have a C++ version
> of nsuml? The generator can remain Java of course, it only has to generate
> C++ code. More work will be the MFactory and MElementEvent stuff, which is
> hand coded. Do you have C++ skills at Novosoft? The KUML people would be very
> happy if they would get any support from you. We (Marko and me) will support
> them as good as we can, but unfortunetaly both of us can't write C++ code.
> 
> I guess it will raise Novosofts reputation a lot if nsuml is used in KUML!
> Please think about it.
> 
We are interested in it. We have expeirence in C++ but it is more 
limited with respect of generation of code then out Java expeirence.
Our C++ generators were for situations were there was a natural memory
management patterns. Java has a garbage collector and much of current 
nsuml code exploit the fact so c++ implementation will differ.

I also have zero knowledge about Qt componenet model, so events
and undo/redo part may differ much.

I have not noticed the integration with some scripting language
for writing plug-ins. If you plan to do it, the question will be
whether mm should be oriented on scripting langauage or on c++ code.
I would suggest the scripting language because it usually provide
useful utilites like garbage collection. It is often possible to 
compile from scripting langusge to c/c++ to get extra performance.
You may look at python as candidate scripting language.

I do not feel ready right now to provide good patterns for c++
generation of mm and I think that it should be your work as you 
already have expeirence with it.

We can consult you on mm ideas and how they can be mapped to c++
and how to extend generator to generate code for c++. But some 
tricks will not work as they are in c++ (for example memory 
management roles is one of big places to think).

Constantine
-------------------------------------------------------

-- 
Open your mind ...
Darius Stachow

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