Uml Total Failure

UML is incapable of describing many C++ standard concepts. For example, in UML you have no way to represent

an exception
a template function
a function object
an iterator
a scoped typedef

These things are fundamental to C++, and there's no substantial C++ program that isn't littered with them, but they just don't appear in the graphic notation at all. I wonder if this is true for other OO languages too? Is there any language actually in use for which UML is an adequate representation?

-- PeterMerel

UML is an extensible graphical language. You are complaining not about UML, but about your CASE tool.

I've taken my comment (and those of the anon poster) out because what JohnDaniels says below is pretty much what I was getting at, though better worded. Anon, if you want the text back I took a copy. -- KeithBraithwaite

I think UML is a model of whatever we want to implement. The model says WHAT be have to do, not HOW to do it. A good UML model could be implemented using any OO or not OO language. It is a mistake to go straigth from the problem domain to the implementation. At DMR we have a method called Macroscope that makes heavy use of the User Level point of view, before you go into technical details such as what language to use.

I agree that models of the world and models of software are different, but we need notation for both. And it would be nice if the notations were the same or very similar. What's more, it's necessary to be able to model software abstractly, which is mostly what UML tries to do, I think. Unfortunately it was, from the start, polluted by the desire to do "C++ in pictures".

On the other hand, it is sometimes also necessary to capture the details of the interface of a class/component, so that you can reason about whether it will fit with some other class/component. That's the level at which it becomes important to have some way of representing exceptions, for example. Even so, it would be better to have some language-independent way of representing them, or at least some abstraction of the mechanism, otherwise you might as well reason about the code directly.

We're stuck with UML, but let's not panic. We need to find ways of making it work for us, and we need to convince the UmlCaseVultures that the devil is in the detail of interpretation and - especially - in proper SeparationOfConcerns. -- JohnDaniels

You can represent exceptions in UML. When I text search the notation and semantics documents for UML 1.1 I get many hits on exception. It is in the metamodel and its stereotype usage is described in notation.

You're supposed to represent them as signals on collaboration diagrams. But that makes them look like function calls and doesn't represent the effects of stack unwinding - which is the whole point of exceptions, imho.

Iterators either use templates or don't, but they are classes nonetheless, and representable.

I think the closest you get is representing them as a reference type - they're generalizations of pointers after all. But this doesn't represent the main use of them as ranges in algorithms.

Function objects, if you are referring to Cope's idiom, can be represented as classes also (or a stereotyped Type).

I mean Cope's functors all right, and specifically with their common STL meaning - as templated references to functions. You may have a point about doing these via stereotypes - do you push the semantics of the functor into the stereotype? What about when you're using them as references to template functions?

Scoped typedefs and member templates.. you have a point, but I don't see why you can't make a stereotype. Personally, I wouldn't want to. If the use of a modeling language is only correct when it has all the details of an implementation, then there is massive redundancy and an air of unreality hanging about.

If I were still dealing with ARM C++ I wouldn't have a problem, but there seems to be a kind of cognitive dissonance between the UML concepts and the STL ones. I find even the most detailed UML class diagrams gloss over the STLish semantics, some of which are very germane to a design. I don't mind this when the diagrams are only used for reporting to management, but when management buys the ReverseEngineering bit the UmlCaseVultures sell then life becomes quite difficult.

I'm actually kind of curious about what an economical graphic representation of the STLish bits would look like. Do the FunctionalProgramming folk have one?

I use UML as a snapshot of shared understanding.. either on a whiteboard or in a document. I suspect that Java and Smalltalk class/object structures, given the languages have less baggage, are completely representable in UML, but I am not sure.

-- MichaelFeathers

I suspect you're mostly right about UML being good for java and smalltalk; I'm happiest these days in C++ and Perl. It's not worth even trying to make a UML diagram of most Perl code - turn back, you're going the wrong way. --PeterMerel

Java is a better fit with UML than C++, but they are far from isomorphic. Multiple inheritance of implementation can't be expressed in Java. Anonymous inner classes can be hard to show on UML sequence diagrams. I wrote the Java RoundTripEngineering component for a commercial UML modeling tool. Despite repeated exhortations to "EatOurOwnDogFood?" we almost never used UML there. Our favorite meta-model was a box labeled "thing" with a line looping back to itself. -- EricHodges

This is a similar complaint -- how come there's no easy way to represent a Smalltalk Dictionary or a Java Hashtable in UML? I can do it for a Smalltalk design if I represent the Association class, but I really don't want to do that. I just want to say "this relationship links these three classes together with a key/value relationship". -- KyleBrown

Hmmm, I do this all the time. I show the Hashtable as a class with associations to the key and value classes, labeled as "/key" and "/value" - The "/" indicates a derived association. It means that the association is not written in the code as documented, but effectively exists as described. -- RussellGold

For Dictionaries or Hashtables you use a Qualified Association (see UmlDistilled page 91) -- MartinFowler

Ahhh... Now I've gone back and reread the bit on Qualified Associations, I see that this would work. However, it still doesn't give me a good feeling. The fact that it doesn't connect the class for Product, but seems to duplicate the information in another place doesn't give me a warm fuzzy. Also, how would you represent it in cases where the key is a String whose name is the important part (like customerID) instead of just the class name String? -- KyleBrown

That last part's actually easy: the key can be written as "customerID : String" rather than just String. -- RussellGold

Consider that, other than perhaps the iterator, none of the five things mentioned as being unrepresentable in UML are actually Object Oriented concepts. Sure, the may appear all over C++, but that doesn't mean that because they are missing from UML that there's a problem with UML, just that there's an unstated assumption that everything in C++ is Object Oriented. There's no way to represent operator overloading in UML either, but that's OK but that's no an Object Oriented concept.

You could just as easily as the question the other way: why does C++ have all these things that aren't in UML? Or are there things in UML that are missing from C++?

Finally, UML isn't just class diagrams. There are seven different types of diagrams in UML, but often class diagrams are the only thing we think of. Personally, I've found that doing Sequence Diagrams can help me tremendously more.

-- StevenNewton

The whole point of UML is not to model languages. It is to model problems. If you are looking at it the other way around, you don't know what it is.

That said, it is not the silver bullet it is sometimes represented as. It is, however, a useful tool with which to work on problem modelling and problem solving (two aspects of the same thing) before writing code. That doesn't mean that the whole application has to be notated in UML before we start coding, or whatever. It's a thinking tool. Nothing more.

-- danmcb