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

[Andrew Sutton]

On Thursday 07 November 2002 12:58 am, P. Fleury wrote:
> Andrew Sutton wrote:
> in otherwords, extract the semantics of the save/load stuff from the UML::*
> classes and shift to it a tree walking algorithm. the only problem i'd see
> is dynamically handling semantics. the way i was thinking, libXMI would
> dlopen() a metamodel library when it found the <XMI.metamodel> tag. it
> would have loaded libUML or libMOF because i was planning to implement
> save/load semantics in the elements themselves.

wow. that is absolutely identical to what i was thinking before the talk about 
decoupling.

think about it another way... low coupling is good, high cohesion is good. by 
separating the save/load capabilities into separate modules (while libXMI 
provides a save/load framework and libMOF/UML provides data modeling), we 
achieve both of those: low coupling and high cohesion. cohesion being the 
property that a module focuses on a relatively small set of functionality 
(e.g. a method that does only one thing has the highest cohesion).

> if we decouple save/load from modeling, the semantics have to go somewhere,
> and i'd still like them to be dynamic. being dynamic should allow us to
> handle extensions and other metamodels quite nicely.

intermediary's. actually the save feature is identical to code generation - at 
least how it traverses the containment hierarchy.

> The reason for having the "walker" is for modularity. The libXMI may be
> a stub, reading the XMI file up to the XMI.metamodel point, then loading
> the libUML and libUMLXMI, or in the MOF case, libMOF and libMOFXMI. The
> second lib is always responsible for read/write operations from/to a XMI
> file.
>
> Ok, now that I think about this a little bit more, it would be so that
> if we consider aspect oriented programming, we would have all the
> methods in the classes (scattered there) and have a set of clean
> interfaces (abstract base classes in C++) which represent the aspect of
> UML modeling, UMLXMI read/write, etc.

well put! the save/load features are crosscutting concerns to the prescribed 
data model of the MOF and UML standard.

> If I make these comments about modularity, it is because I think that
> code generation for the model only is easier than if we need to make the
> read/write ops at the same time, it makes maintenance easier because the
> code is logically grouped, and we have been bitten already once with
> backwards-compatilibity of UMl files.

i don't know. the more i think about it, the easier it seems to just build 
simple static functions mapped to namespace and tag to implement loading (at 
the very least). we could wrap them into a plugin class and make the dlopen 
part very OO.

> Now, I am no God, so maybe there are things I just did not see, that are
> fairly obvious to you. I would hate to be the captain of an ship liek
> Titanic...

have no fear. we're all on that voyage together :)

> This problem will recurr when we try to produce other code from UML
> models. That means, we need extra information to produce the code, which
> cannot be stored in the XMI. Therefore, we need this in some other
> "location" (maybe a section of XML in the XMI for vendor extensions,
> another file in the same tar file, or simply another file). I would see
> that once you have a model in UML, you can go about producing code, in
> which stage you can add these little pieces of info and let the thing
> produce code for you. That would enable setting inline flags for
> methods, setting the language in which you want a particular object to
> be produced, some other constraints like you can use Qt, KDE, gnome
> libs, etc. This could also later on become a sort of "code production
> tool" as the logical next step to the "modeling tool" which we are
> talking about. That's what I tried to explain a while ago with the
> inline methods, but I am poor at explaining, my co-workers and my family
> remind me that fact almost daily... (now the mailing lists too :-)

actually, i don't think we have anything to worry about. we can define 
extensions to UML without changing the metamodel. adding new stereotypes, for 
example (like <<qobject>>) is an extension. we should be able to do that 
without writing code. for example, {inline} might be a tagged value applied 
to UML classes for a C++ profile. i'm not *really* sure how this works yet, 
but i think it can be done.

i do like the idea of the code production tool. when we sit down to start 
designing the code generator stuff, we'll really want to think pretty hard 
about this. lets get the data model right first.

> >>right. as i mentioned before, it should all be contained in a package -
> >> not a model.
> >
> >no, I insist in having a model which can contain packages and other
> > elements. I think that not all elements must be contained in a package...
> > what about elements in the "global scope"? these should go directly under
> > the Model.
>
> Make it a "global package" :-) It exists in almost any programming
> language, which to me means there is a reason for it to exist, even if
> OO books tell you to avoid it like a highly dangerous desease.

there should always be a root container. if we use "Top" or "Logical View" or 
"Foo", there should always be a root container. and apparently, it must be 
some type of Ref::RefPackage.

hmm... point of confusion. if you can instantiate a UML::Package, it will 
derive from Ref::RefPackage. apparently, you can also instantiate a 
UML::Model which would also derive from Ref::RefPackage. ah shit... multiple 
inclusion of bases. i hate that. its just as bad as the circle of death.

> Well, maybe the split between walker and libXMI is there for nothing.
> But having the UML model knowing nothing about how you can save it make
> it cleaner. The libXMI "knows" about the UML model, knows how to walk
> it, and knows how to produce an XMI file. To some extend, you could
> think that writing an XMI file is just a special kind of codegen, which
> needs no additional information of its code generation (as opposed to
> thew QObject/inline etc. info for others)

yes! writing the XMI is a codegen. but you're kind of moving in a weird 
direction. there really isn't a "walk" protocol for saving. each codegen 
(including saving) is going to have to understand how to navigate the 
elements in the root and nested packages.

now... for saving... there is one possible difference. because of the 
reflective interfaces, it may... MAY be possible to write a very generic save 
routine that only uses the reflective interfaces. in otherwords, the save 
protocol is embedded completely within libXMI.

if we're really clever, we might even be able to do the same for the load 
protocol (dom tree walking). this might take some thought, but i really think 
it can be done. maybe :)

andy