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

[Andrew Sutton]

> I like your suggestions, and I also think this would be the way to to
> things if we really want to do it "the right way"
> The problem is that Iam not sure we can go this way... I mean, altough I
> see this as the correct approach, I also see the risk of being *too*
> academic and then not being able to get something that really works in real
> life.

thank you :) to address this concern, i think it might be worthwhile to go 
through these problems to get something that works *better* in real life. 
besides, if we show that we don't understand UML, than users are going to see 
that and move to something else.

> I am only learning UML now, and to be honest, the whole MOF-thing seems
> really interesting to me, but also a bit too abstract... and somehow i have
> the feeling that but for you and maybe other one or two guys in the group,
> the other developers are not MOF and XMI experts either =((

MOF is abstract. its actually really, really hard to wrap your head around. 
lets see if i can explain it... we know that an instance of C++ class is an 
object, right? (yes) well, in UML, when we create classes, what are we 
creating instances of? UML classes. a class in a diagram is an instance of a 
UML::Class. okay... what is a UML::Class an instance of? it's an instance of 
a Meta Object Facility Class (MOF::Class). just keep thinking about instances 
and classes.

anyways, it seems like the entire thing could really stop at the UML::Class 
doesn't it? theoretically it could. until you start thinking about other 
models. for example, the OMG's Common Warehousing Model is another metamodel 
defined using the MOF. it's used to model storage solutions (whereas UML 
models software solutions). The MOF is used to classify (define classes for) 
the information in each metamodel.

> I understand you propse to create a component (library) which:
> 1) reads XMI files
> 2) creates a model out of this files (not a DOM tree, but really a modell,
> containging a "Modell" object, which in turn contains "Class" and
> "Association" objects, etc. This objects have methods "setAttribute(xyz)"
> and so on
> 3) this component can then generate programming source code for the objects
> in its modell

yes until we get to 3. the code generation should be completely separate from 
the XMI implementation. remember, XMI has nothing to do with codegen. 
*separation of concerns*. the codegen stuff is a separate library. an 
application (probably cmd line) links the two together to read a file and 
generate the code - like a regular unix cmd line tool.

> Using this library, you suggest to feed it the XMI file of UML itself, have
> it generate the classes skeleton for us, and then we use this code for.....
> for what??

yes. the code generated from the XMI file of UML (hopefully) replaces 
UMLObject and friends in Umbrello's current configuration.

> -> if libXMI alread gives us a Modell, then we already have what we need,
> dont we? I am getting a bit confused now. why do we need another UML modell
> on top of the modell itslef?

XMI doesn't give us a model. XMI is just a model interchange format that 
doesn't have anything to do with UML - or MOF, really. it's the MOF bootstrap 
library that really drives the whole thing. it should be capable of 
generating code to implement metamodels. think of it like this.

codegen_1(MOF.xmi) == MOF metametamodel implementation
codegen_1(UML.xmi) == UML metamodel implementation
codegen_2(MyProject.xmi) == MyProject implementation

where codegen_1 is a code generation library that deals with MOF elements and 
codegen_2 is a code generation library that deals with UML elements 
(remembering that UML instantiates MOF classes and MyProject instantiates UML 
classes).

so... libXMI gives us generic parsing capabilities (to start with). libMOF 
allows us to parse metamodels. libUML allows us to parse UML models. 
different codegen libraries allow us to generate code specific to elements 
contained in the XMI document. e.g. codegen_1 (from above) targets MOF::* 
classes and codegen_2 targets UML::* classes.

> Another thing is: the code generator will probably only write the skeleton
> for the classes (class and method declarations) and we would still need to
> implement the methods manually.. right?  (ok, ok.. so for what I've seen
> most of them are just get/setter)

they're all get/set. there are constraints, but we'll deal with those later.

> ->How would we integrate this into "the application" ?  (just link it in
> and use it as a "normal" library?)

yes. Each major element (like UML::Class) would probably be wrapped by some 
QWidget object and have some property dialog.

> ->If libXMI is to be able to write code... how are we going to handle
> various languages?
> a)- should the library use come "code generation" libraries which get the
> modell and write the code (approach similar to current implementation) or
> b)- should it read the XMI file and generate code from there?

each code generator is its own library and understands how to write its own 
code. we can simplify the process by providing a pattern for code generators 
to follow.

i think that the code generator is run over top of the model elements, not the 
XML in the XMI file. this gives us better control over the code generators.

> If we want to just generate the UML implementation classes ( class Class,
> class Attribute, etc) then I think the better way would be to find out how
> XSLT work and then write one of those things to generate C++ code from the
> UML-XMI specification... but this of course would not give us a real
> Modell, just the classes to make the modell with.

i already thought about that - because i've been using XSLT extensively lately 
:) code generation requires alot of control over context and semantics. if we 
*really* wanted to use XSLT, i think we'd be in for a world of hurt.

> the other approach would be to get something intermediate between what we
> currently have, and the "real thing" ... that means, implement the UML
> classes where we feel it really makes sense, and simplify things when/if we
> feel some parts of the UML specification are
> too-detailed/abstract/academic.

the trick is to make the abstract/academic as painless as possible. libXMI is 
fairly concrete. think of libMOF and libMOF_bootstrap as concrete too. it 
helps if you don't think about UML at this point. we'll get there :)

> We could *probably* reach 100% UML conformity to the extern world, but not
> being UML conformat from inside *could* mean there will be things which are
> too difficult to implement (and we would have the same problem we have
> today) So, it would mean a big risk of having to redo everything again, but
> it would have the advantage that since it is more "concrete" it would be
> easier to understand and implement even without knowing every detail of the
> MOF or UML.

we could be 100% compliant on the inside (its not that difficult to implement) 
and slowly achieve compliance on the outside through iterative and better 
interface design. however, achieving compliance from a substandard internal 
implementation might requires two changes: external and internal - more work!

one more to answer.

andy