OK, its quite likely that, over the coming months, I will devote considerable attention to complaining about the state of UML 2 on this blog. Now, let it be clear, I am a MOF guy, since it was invented, and lived for many years without having to worry overly about the mess that was UML 1.x. When people mentioned it, I could just say, "Well, its not a problem in MOF", and be done with it. (Note: This was despite a great lack of understanding about MOF, and subsequent misunderstanding about its role).
This all changed with UML2 / MOF2. Notionally, the move involved redefining MOF as a subset of UML. Fair enough, I guess, although I can't really see why its thatt important. Except for, UML has no concept of extents or reflection. OK, we'll add that in - its still nearly a subset.
Then, somewhere, someone (and my prejudices tell me it was a UML person) invented this heinous thing called a <<combine>> (also "define"-style package merge). This is the most evil thing I've ever seen in a MOF. Unlike everything else in MOF, its not a structural relationship. Its an instruction, a copy basically (with some bells and whistles about merging features), that "throws away" the relationship after "applying it". CMOF uses it, as does EMOF (for definition), and it just doesn't hang together when you look at it closely. More problematic is that it introduces time into the MOF/UML definition story. Time has no place in a meta-meta-model.
Of course, all this aside, its still a dog's breakfast. EMOF is in its concepts a really nice little language (see EMF for an implementation, largely free of the problems discussed in this post). However, its formal definition in the specification is expressed as a CMOF metamodel, not as an EMOF metamodel, which totally defeats the purpose of a MOF! A MOF is a metametamodel that must be, must be, self-defining! EMOF could be, easily, but isn't specified as such, which is just evil.
As for the documents themselves, I pity any UML tool vendor who takes it upon themselves to implement UML 2. I have read more coherent binaries than the UML 2 specification, which seems to have been inspired by the "Choose Your Own Adventure" books that I read as a child, but 10 times as long, and split across multiple books. It was cool when I was 7, but now its just a bloody nuisance.
Tuesday, May 18, 2004
UML2 gripes
Subscribe to:
Post Comments (Atom)
3 comments:
"I pity any UML tool vendor who takes it upon themselves to implement UML 2."
I think the key to building a useful tool is 'embrace and constrain'.
Tools designed to support the whole UML give you enough rope to hang yourself - I've seen the bodies!
Useful tools should support a method, rendered as a subset of the UML notation, not the notation itself.
Like UML1.x, the best thing you can do with UML2.x is ignore most of it. The best bit of any version of UML has always been the class model, which I think is largely derived from OMT.
However, back to UML 2.x (or to be specific, the class model) ...
What is good about UML 2.x is that associations can be abstract and they can be inherited. This really allows much neater expression of models as you can express an abstract association between abstract superclasses and then concretise it between only certain specific pairs of subtypes. So if abstract classes X and Y are associated by abstract association A, then concrete subclass X1 can have a concrete association A1 with Y1, and X2 with Y2 via A2 and so on. In UML1.x, you had the problem that X1 would be associated with both Y1 and Y2, and you had to add constraints to prevent it.
Indeed, abstact/inheritable associations are a vital piece in doing patterns in UML. What was needed (and didn't happen, unless I missed something!) is a means to specify a package as being a pattern template with certain names parameterised and then use that to "stamp out" other packages with the parameter names appropriately substituted. Close but no cigar.
Still there is always UML3 to look forward to!
The stamping-out approach had a lot of momentum early on from the PUML guys, but withered in the political heat. There are a couple of package relationships, in particular <<combine>>, that seem to strive towards it, although in my opinion they don't do much of a job. There are open FTF issues to better define it.
Post a Comment