How does XMI and MOF and UML all fit together?

June 11th, 2014

So, I’m trying to figure out the relationship between XMI and MOF and UML, and of the OMG N+2-fold path to enlightenment.  I think I have an example which makes sense to me, but perhaps it’s wrong nonetheless.  Here is my explanation, right or wrong.

I should say, first, that my goal is to do reverse engineering of C++ code.  I have a big C++ program which I need to understand, and I want to extract the data structure definitions, and display them in some modelling regime from which I can then extract diagrams.  The easiest modelling regime is UML, so that’s what I’m choosing.  I don’t know any real alternatives, given that I only have code and not intent.  If I had intent, and I had such things as invariants or preconditions, I could use Z-notation or Larch or ADT or something like that.  Perhaps there is no modern version of those, and perhaps those have not proven to be useful in the modern world.  In any case, this is my ultimate problem.

The mechanism I want to use to do this extraction is to use the Clang C++ language toolkit to extract the program structure.  Clang understands C++ pretty well.  It is the standard, native compiler for XCode on the MAC, and who doubts the infallibility of the Apple Computer Corporation.  It also has much industrial support.  I have made some prototype Clang tools before, so I know that the entire structure is available in really great detail.  I’m pretty confident that Clang can give me the C++ understanding I want.  The only unsolved problem I have now is creating the model in a convenient form.  The real requirement is that I must create the model in a form that can be imported into tools.  The two tools I care about are Magic Draw and Modelio.  The former is important because I have many colleagues who know and like Magic Draw, though they generally are not interested in reverse engineering.  Modelio is important because I think it’s important to be at least nominally tool neutral, and because I like it.  Supporting two tools is more than twice as good as supporting only one, at least as far as tool neutrality is concerned.  Modelio makes much less ugly diagrams than Magic Draw, which on Linux is dreadful.  Magic Draw is a much more complete tool than Modelio underneath the GUI, but it’s astonishingly ugly.

So, here’s my example.  Imagine that you want to represent a kitchen.  A kitchen has various parts, such as an oven, a range, a sink, a set of cabinets, perhaps a microwave oven, perhaps some lights and so forth.  Since I’m working with C++ code and a C++ compiler, it makes a certain amount of sense to represent this kitchen as a C++ object.  Since C++ is strongly types, the kitchen-representing-object has some set of classes, the most derived of which is something like Kitchen.  So, I have some kind of class definition, which looks something like this:

class Kitchen : public Room, public PublicArea ... {
  Sink *sink;
  Stove *stove;
     ...
public:
  void addSink(Sink *_sink);
  void addStove(Stove *_stove);
     ...
  void serialize(ObjectSink *sink);
};

The base classes Room, PublicArea and so forth, are kinds of rooms (or areas) that a Kitchen must be.  We can then just create a Kitchen object, add the parts and Bob’s your uncle.  I can serialize the Kitchen object with the serialize method.   Note that the ObjectSink parameter to serialize is not a Kitchen Sink.  It is some place to which the program can write serializable data.

So far this is so good.  But note that I have gone from instance to class silently.  An object has a class or three, and we know that because - what the heck, it’s C++.  Everything has a class, and it’s bound into the definition of the language.  Sapir and Whorf forbid our knowing objects without classes.  But in Lisp there are objects which don’t have classes, and in JavaScript (ECMA5 even) there are objects which have the same class, but which are pairwise behaviourally distinct.  This seems weird to me, but it’s very natural to my Web programming friends.   So, who am I to cry weird.  In my example I decided I needed a class, and I’m sticking to it.  I know it’s not really necessary.

So, I have a C++ class definition, and I have an object whose class is the given C++ class. I’m interested in modeling, and in a certain sense, the class definition is a model of the objects.  The class definition tells me how I can create a new object, and what I can do with the object once I have created it.  This completely constrains the set of objects I can create, unless I fire up a debugger and conjure up a miracle.  (The debugger can do anything.  The debugger is god.  I used to work on the Totalview debugger, and I’m very proud of what a Debugger can do, thank you very much.)  But a C++ class definition is a lousy model.  Imagine reading the C++ class definition or declaration and trying to display it in diagrammatic form, or to try to visualize a mansion, which has three kitchens and many other complicated rooms.  It’s daunting.  So, it would be better to have another representation of the class which was useful for all these other uses and also the C++ class definition.  Call this other representation UML, and realize or imagine that we don’t know what UML is.  We have two representations of the class Kitchen.  This is not really a good thing.  If we want to change them, which do we change?  Or, if we want to change them, do we need to change both, and how to we maintain consistency.  So, think further.  If we had a representation of the class Kitchen, and we could reliably generate the C++ class definition from the UML representation, we would have only one representation, the C++ class definition would be a reliable reflection of the UML representation, whatever that is, and all would be right with us.

We choose to express the UML representation in XML.  This is not logically necessary, but it makes a certain amount of creepy sense.

  1. The OMG (Object Management Group, not what my teen-aged sons think) represents UML in XML.
  2. XML is a reasonable, if verbose, way of specifying structured data, and the UML definition of the class Kitchen is structured.
  3. There are many XML standards.  Standards are good things, even if they are incomprehensible or ungrammatical.

So, a kitchen might be represented as:

<gri:Kitchen name="GriggsResearchInstituteTestKitchen">
  <gri:Ovens>
    <gri:Oven name="MainOven">...</gri:Oven>
  </gri:Ovens>
  <gri:Sinks>
    <gri:Sink name="DishwashingSink">...</gri:Sink>
    <gri:Sink name="HandWashingSink">...</gri:Sink>
   </gri:Sinks>
   ...
<gri:Kitchen>

More to come as I think about it.

June 11th, 2014

“Act without doing;
work without effort.
Think of the small as large
and the few as many.
Confront the difficult
[where] it is…easy;
accomplish the great task
by a series of small acts.”

Interesa bildo.

November 6th, 2008

Jen interesa bildo pri elektoj en usono.  Ŝajnas al mi ke la demokratistoj pli boniĝos dum la venontaj jaroj, sed eble me eraras.

Poplara voĉdona konto.

Poplara voĉdona konto.

Nur unu tago.

November 3rd, 2008

Mi ne estas avida Obama-o fervulo, sed tiu sprimas la sentojn de miaj amikoj kaj familio.

Les Misbarack

Mia Nova Retejo.

October 27th, 2008

Mi ĉanĝis mian retejon.  Mi aĉetis servon el la tre bona servo hostgator.com.

Mia malnova retejo estis plena je ne tre gravaj aferoj.  Mi esperas verki nur esperante ĉi tie.