Fun with UML


I found a nice article in the IEEE Computer magazine which is called “Transforming Software Development: An MDA Road Map” . The article is written in favour of MDA and therefore UML plays an important role.
Last week I have been at the net.object days in Erfurt. It was interesting to see that even in the MDA world the adjective “domain-specific” plays a certain role now ;-). None the less I still do not believe in UML. Let me explain why.

In the article somewhere in the middle one can read:
However, experts such as Steve Cook
further argue that MDA “does not translate
very directly into the technologies that we
use. For example, a UML class cannot be
used directly to depict a C# class because a
UML class does not support the notion of
properties while a C# class does.”

OK, thank you so far. So we have to accept that UML is not capable of modelling something like a .net class diagram. For the author this is no problem – he explains why later on. For me it really is. Today I was at a really large corporation with a room full of Java developer and I asked them “are you using UML”? Yes, sure they do. So I asked them to tell me why the diagram of the VSTS class designer certainly is no UML diagram. Silence. I said, hey, look here it supports Methods, Properties, … any idea. Silence.
So I said UML would not support Properties. You all said you are using UML but I would say you are doing it just the same way I did in the past. I just used parts of it and - to be honest – I never was happy with it. So having a tool which is not able to model a .net class (or C++ or Cobol or you name it) is of no use for me. But wait…
However, this is not a significant problem
in the MDA world, as transformations can
easily adapt to specific platforms through the
PIM-to-PSM conversion. More importantly,
objections that UML is hard to turn into code miss
the greater value of MDA—namely, its focus on

Oh, ok. So forget about those models, simply use different ones. But wait its getting better…
Rather than ask, How can I translate this lowlevel
representation into an even lower-level representation?
software developers should ask, How
can I verify that my understanding of the problem
matches my customer’s understanding? And how
can I easily translate that shared understanding into
a working system?

Yes, yes… thank you. So I would say, one should use UML whenever your customer is used to UML. In all other cases where your customer uses different modelling languages it would certainly be beneficial to use more customer centric modelling techniques. Or get your customer trained to UML or simply get another customer because the current one is not worth the effort...

 Yes, this really matches to my experiences. And if we would be able to use the customer’s models as a starting point to develop more specific models or even code… a dream comes true.
Sorry, but for me MDA and UML is still not open enough to be as helpful as it is praised to be.