[Uml-devel] Re: Umbrello design (was UML XML tree viewer)

Luis De la Parra Blum lparrab at gmx.net
Tue Nov 5 12:46:08 UTC 2002


ok, trying to sumarize things...

1)
it seems everything is clear in the code generation stuff... it should be a 
library which gets a pointer to a Model (or to individual objects) and it 
writes the code for it. We can load the libraries at run time directly from 
umbrello (the way its done now) or if someone wants to use the code 
generation facility without starting umbrello, can create a small program 
that links to libUML (to parse the file and get a model) and to the codgen 
library to output the code.. I would prefer to load the libraries at run time 
from umbrello itself, but if someone wants to create a command line program 
it would be a matter of 10 lines of code (libUML->parse(); 
libCodeGen->write() )

2)
the design of the user interface and other things will have to be discussed 
later

3)
we focus now on designing the basis.
As I understand things, the heart of the whole thing will be "libUML" (or 
whatever its called)
libUML is a piece of code (most likely a library) that reads UML models stored 
in XML / XMI and generates a model out of it. This model consits of a "Model" 
object which contains a bunch of "UML::Class", "UML::UseCase", 
"UML::Association" etc. this set of objects are the equivalent (will replace) 
the UMLObject, UMLClass etc. in the current implementation of Umbrello and 
will be 100% UML-compilant.

so far, ok.
now, we dont want to code a "Class", "Association", etc. from scratch, so we 
need "something" that generates the skeleton for this classes from us.
This thing will read the UML-specification and generate the appropiate classes 
(the UML Implementation)
As I understand it, this "thing" is a "libMOF" and a "MOFCodeGenerator".
libMOF reads MOF models (ok, metamodels) and generates the metamodel ... this 
is how we are going to generate a model for UML, right?

I tought UML was specified in UML itself, but it seems that is specified in 
MOF. ok.
I think I understand this as well...

here are where things get complicated...
I assume you (Andrew) dont want to write libMOF from scratch either, so you 
are suggesting having yet another program generate libMOF for us, this "other 
program" would be what you call libMOF_bootstrap (and its corresponding code 
generator)... am I write with this??
but we will have to write libMOF_bootstrap by hand, right??  (unless of course 
we find a program somewhere in the net that can read MOF models and generate 
the model / code.

question: is there much difference in implementing libMOF_bootstrap to 
implementing libMOF directly?  (ie, cant we skip this extra step?)

Another point I'm just thinking about, is that we cannot have an UML 
Implementation that is "only" the UML Model... I mean, I dont want our 
"UML::Class" to be "just" a thing with a name, and some booleans (isActive, 
etc) but has to have some other functionality that is not described by UML...
for example, our UML::Class should be a QObject so that we can use signals and 
slots  ( I want to emit a signal when a new attribute gets added to the class 
so that the diagram can update itself, for example)
our UML::Class should also have a method "writeXMI" or something like that to 
store the model back to disk ( libUML would read the file and create the 
objects, but we need to save them back)

so what are we going to do about this? do you want to have libMOF do its 
thing, and then modify the output of libMOF to add this functionality?

Something else... I had another (quick) look at the UML specification... I am 
beginning to understand more of it. Something that got my attention is that I 
didnt find a "UML::Model" anywhere... there are classes, namespaces, 
associations and actors, but they all live in a Model, which is not defined 
anywhere (or I didnt see it)
this "Model" is our "Document", which should have methods like "allElements()" 
which returns a list of ModelElements and "diagram("Activity","myDiagram") 
which would return the corresponding diagram.

ok. time to go now.
more comments later.

luis




More information about the umbrello-devel mailing list