> I looked at the dMOF information at your web site but it is not entirely
> clear to me
> what "programming against the MOF repository IDL" really means when all I
> really care
> is to navigate through the XMI model and extract the information I need
> according to a
> UML profile that we are defining as a set of stereotypes, constraints and
> tagged value pairs.
I assume that by XMI, you really mean XMI for UML 1.3 (or some other version).
What you do is take the UML meta-model and feed it into the dMOF meta-model
repository. Then use the dMOF tools to generate the IDL and Java code for
a MOF / UML repository and the corresponding XMI 'consumer' and 'producer'
applications. [The IDL should be similar to the IDL in the UML 1.3 spec.]
At runtime, you'd first import a set of UML diagrams into the repository
from an XMI/UML document. Your client would use the Java (or C++ or C
or Ada or Fortran or ...) APIs generated by your favourite IDL compiler
to navigate over the web of CORBA objects that represent your UML model.
So for example, given a Class in your hand you might write the following
to print the names of all of the Attributes declared by the Class:
import Foundation.Core.*;
...
Class c = ...
ModelElement[] contents = c.owned_element();
for (int i = 0; i < contents.length; i++) {
UmlAttribute attr = UmlAttributeHelper.narrow(contents[i]);
if (attr != null) {
System.out.println("The attributes name is " + attr.name());
}
}
I'm sure that you will agree that code like the above is easier to
read than equivalent code to navigate a DOM object graph. The contrast
is even greater when your application follows 'links' in the model; e.g.
to find the type of a UmlAttribute.
Another couple of advantages are:
* Your application doesn't need to pull the entire UML model into
memory. In fact, it may be able to work entirely against the
copy of the model in the repository.
* Since you are coding against higher level generated APIs, the
Java (or C++, or ...) compiler will stop you compiling programs
that look for attributes that don't exist. For example, you
won't be able to compile a program that tries to find the contents
of a UmlAttribute ... because a UmlAttribute won't have an
'owned_element()' operation.
> Maybe I missed something; could you point me to an example of dMOF
> that illustrates this kind of behavior?
There's a very simple example in the dMOF 1.0 release if you care to
download it.
I've got a number of other applications that work this way ... but
they are part of the dMOF code base and I can't show them to you.
There are at least three other DSTC research projects using dMOF. One of
the projects involves a dMOF generated repository for an extended UML.
-- Steve
