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

[Andrew Sutton]

On Tuesday 05 November 2002 3:45 pm, Luis De la Parra Blum wrote:
> 1)
> it seems everything is clear in the code generation stuff... 

basically, yes.

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

right. although, for UML, we have this concept of a "UML::Geometry" datatype. 
that sounds like it might be useful for associating raw dataelements (UML::*) 
to UI elements (QWidget or SVG something or other).

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

since umbrello is a UML modeling tool, the domain model for UML (as described 
by the standard) will be at the heart of all UML modeling.

BUT! because we agree that implementing MOF, Umbrello can be much more than 
just a UML modeling tool. it can be a generic modeling tool that 
"understands" how to deal with all types of models and extensions to models. 
good examples would be CWM (common warehousing model - also by OMG), 
aspect-oriented modeling extensions to UML and concern modeling (forthcoming 
from the IBM Hper/J team). actually, the last two are projects that i am or 
might be working with.

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

no. libUML implements classes and relationships of the UML domain model. 
ideally, it has nothing to do with reading XMI files. of course, this is (in 
my thinking) almost impossible - or at least very ugly to separate. just 
think of libUML as providing access to a very complicated data model for some 
application.

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

unfortunately, UML doesn't have a model element. it just has packages. the UML 
XMI file should contain a single package. in fact, if you read the JMI (Java 
Metedata Interface) specifications - which describe an MOF to Java mapping - 
their XMIReader class returns a package to the caller - not a model.

otherwise, right.

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

yes, but the same idea as above. think of libMOF as providing data access to 
an application. it really has nothing to do with reading or writing.

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

right. UML is defined in MOF. MOF is used to define modeling languages.

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

exactly. unfortunately, the code generator we write for MOF will be very 
specific to our design - that means we have to write MOF_bootstrap from 
scratch. unfortunately... its kinda big (30 classes?). but... we don't have 
to do any of the complicated work for MOF_bootstrap. MOF actually defines 
methods for its classes that should probably be implemented at some point. 
bootstrap doesn't need to do that.

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

not really. in fact, we should be able to use the bootstrap implementation to 
generate libUML directly. the only reason we'd recreate libMOF is to make its 
implementation follow the patterns prescribed by our metamodel code 
generator.

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

man... i've thought so much about this, and i'm just starting to figure it 
out. deriving from QObject would be a *huge* bonus for libMOF, libUML, libCWM 
or whatever.

anyway, i think we can do that. remember, we control what code is generated. 
its not wrong (or noncompliant) to *add* to the implementation. however, this 
is kind of tricky. we can only derive from QObject in classes that are leaf 
nodes of the inheritance tree. in fact, we can only derive from 
Ref::RefObject (or some other reflective interface) in leaf nodes of the 
inheritance tree). so, if the metamodel codegenerator runs into a leaf node 
class, we know to insert a QObject (probably something more specific) parent 
into its inheritance list. we can also modify the way the get, set, add, 
remove, or other methods are implemented to emit signals on well-known 
events.

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

no. the metamodel code generator must do this for us. remember, this code 
generator is going to generate code specifically for umbrello's design.

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

right. as i mentioned before, it should all be contained in a package - not a 
model.

every model element in uml has 0..* presentation elements. i believe that a 
presentation element is probably some kind of view (i.e. diagram). if we 
subclass our diagrams from UML::PresentationElement then that capability is 
built in for us. of course, if we do that, we can save diagrams directly into 
the XMI file (as, say, SVG) without sacrificing compliance).

> ohh.. I forgot to ask..
> where does libXMI fit into this design??
> so now I know XMI is a standard for model interchange, it is not specific
> to UML or MOF, right?
> so what exactly should be the role of libXMI ? what we need is to parse the
> file and get a DOM of it... that can be done with QDOM, Xerces, libXML(?)
> ... so what is the extra functionality of libXMI?

as mentioned, neither libUML nor libMOF is responsible for saving or loading 
documents. libXMI is primarily responsible for that capability.

actually, to be specific, the capability to load and save into an XMI document 
is a crosscutting concern of both libMOF and libUML.

on a side note, if we have fully compliant MOF and UML implementations 
(including the reflective interfaces), we should be able to completely remove 
any save load capabilities from both libMOF and libUML. honestly, that would 
be a pristine implementation because it completely decouples data modeling 
with serialization (save/load). i don't know if that's something we want to 
aim for right now.

andy