[Uml-devel] Review / Redesign of Umbrello

Andrew Sutton ansutton at kent.edu
Wed Oct 23 22:19:01 UTC 2002


> > The UML metamodel is already there in the standard so of course we should
> > build a new domain model based on this (as they've already made most of
> > the work by defining the metamodel!). And since Umbrello is a KDE program
> > I think it should be a Qt implementation, where everything in the model
> > is dynamically available from a single "UMLModel *" through the Qt
> > metaobject system. It's completely doable.
>
> Can you explain what you mean by `domain model' (also Qt metaobject
> system)?

"domain model" is one of those fun catch phrases :) actually the uml standard 
provides the domain model - its a model of elements in some area of interest. 
here, we're interested in UML so the domain model consists of elements 
comprising the unified modeling language.

the Qt metaobject system is, in part, a reflective component to the Qt 
library. consider it "classes that describe classes". every Q_OBJECT you 
create has a method "metaObject" that returns a QMetaObject pointer - each 
QObject derived class definition instantiates a QMetaObject class (created 
behind the scenes by the meta object compiler (moc)) which is returned by 
that method. The QMetaObject instace provides interfaces that allow a 
programmer to access runtime type information about the class such as what 
properties it supports (Q_PROPERTY), any signals, slots, stuff like that. 

this is commonly referred to as reflection. consider Java. there's a whole 
Java package devoted to collection. you can access everything about a class 
at runtime (methods, parameters, attributes, implemented interfaces, etc).

it turns out that Qt's reflective capabilities are fairly week. - which is 
unfortunate because it would be *oh so* nice to have a good reflective 
toolkit sometimes. on the other hand, it might be interesting to hack their 
metaobject protocol to provide significantly more functionality - list 
methods, signals, slots, etc, but also support higher levels of features.

now... here's the only way this would ever be useful for this project. we'd 
need the capability to create a catalog of "higher level" attributes and 
relationships that reflect the information we find in the MOF and UML 
standards (they use the same model elements). this means we'd need attributes 
(and therefore interfaces) that reflected the multiplicity and and ordering 
for each attribute and relationship.

see, its a lot of work :)





More information about the umbrello-devel mailing list