UML Is Chinese To Me

0 comments suggest edit

Chinese Character for
Money Jeff has a great post in which he compares UML to circuit diagrams and then asks, why doesn’t UML enjoy the same currency for software development?

In the comments Scott Hanselman makes a great point…

It’s because, IMHO, UML isn’t freaking obvious. It’s obtuse. What’s the open arrow, open circle mean again?

I think he is spot on. But you could also say that about any programming language, right? What is that colon between the two words mean?

public class Something : IObscurity<-- What the heck is that?
{
}

If you are a VB programmer, it might be unfamiliar. But if you are a C# programmer my question is like asking what is that funny curly line and dot at the end of this sentence? Oh that’s an interface implementation silly. Of course!

Don’t get me started on C++ with its double colon craziness and its @variable and variable* which leave the befuddled developer asking what exactly do they mean?

Isn’t UML a Decent Abstraction Layer?

The evolution of software has been a steady stream towards higher level abstractions. We no longer punch holes in cards to represent computer calculations in binary (at least I hope not). As a managed code developer, I don’t even have to worry about allocating memory (malloc anybody?) before I use code…Glory be! So doesn’t it seem natural that UML would be the next evolutionary step in that chain?

Umm…Well no.

The most successful widespread abstractions are those that abstract the underlying computing architecture, which itself is abstract. Memory, for example, is pretty the same thing to everybody, no matter what kind of software you are working on. If the machine can handle allocating and deallocating it for you so you don’t have to think about it all the time, then all the better for everybody.

But that same principle doesn’t work as well when we start raising the abstraction level to cover our real world concepts. The next obvious level of abstraction are domain classes. How many times have you written an Order class? I’ve written one. Great! Since I did the work, I can simply post that baby on SourceForge and save the rest of you suckers a bunch of time. Now anybody can simply just drag the UML representation into their UML diagrams and bam!, their Web 2.0 revolutionary microformatted shopping cart application is complete. Sit back and watch the flood of money flow in.

If only it were that easy.

Make a Wish

Evil Genie It would be nice to be able to work with such high level abstractions and wire them up. Oh, here, I’ll just draw a line from this order to the shopping cart and boom! when the user clicks this button, the item goes into the cart. But what about the various business rules triggered around adding this order to the cart? What about the fact that the cart lives in another process on a separate server and the order needs to serialized? What about the persistence mechanism? How do you express that in UML?

You can’t. Writing code is like asking an evil genie for a wish. No matter how carefully you craft the wish, there is always some pernicious detail left out just waiting to jab you in the eye. I wish I were rich and now I am some poor slob named Rich living in abject poverty. There are just too many moving parts and pitfalls in a piece of software to deal with and worry about.

UML has a bit of trouble capturing the semantics of code. Like snowflakes, no two Order classes are alike. Every client has their peculiar and idiosyncratic ideas on what an order is and how it should work in their environment. So what do we do? We start encumbering UML with all sorts of new symbols and glyphs so that we can work toward a semantically expressive UML (executable UML anyone?)

But this just turns UML into another programming language. The fact that it is in a diagram form doesn’t make it any more expressive than code. In a way, adopting UML is like changing from English to Chinese. Sure a single Chinese character can represent a whole word or even multiple words, but that doesn’t make it any easier to grasp. Now, you have to learn thousands of characters.

Not to mention the fact that you are writing the same code twice. Once by dragging a bunch of diagrams around with a mouse (how slow is that?) and again by writing out the actual compilable code. Granted, that particular issue my be solved by executable UML in which the model is the code. But that suffers from its own range of problems, not the least of which is the huge number of symbols required to make it work.

What is UML Good For?

Now to be fair, my criticism is about formal UML and UML modelling tools such as Rational Rose. If you are prepared to run wild and loose with your UML, it can be useful at a very high level as a planning tool. I sometimes sketch out interaction diagrams to help me think through the interactions of my class objects. That is useful. But I rarely keep these diagrams around because hell will freeze over before I waste a bunch of my time trying to keep all of them up to date with the actual code. The code really is the design. The only diagram potentially worth keeping around is the very high level system architecture diagram outlining the various subsystems.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

8 responses

  1. Avatar for Keyvan Nayyeri
    Keyvan Nayyeri April 14th, 2006

    I think that one of the reasons that leads to this difference is the distance between the details of implementaion in a circuit and a software.
    If you draw UML diagrams just paid time and have strucutre but this is aproximately nothing because you should code this and most of work is this.
    But in a circuit when you draw the diagram don't need to work hard to implement details. Just you should do it and it doesn't seem to be complicated.
    So at the end for a software after drawing your diagrams, you have nothing except a schema but for circuits you did at least half of work!
    On the other hand the process of drawing UML diagrams is harder than circuit diagrams, I think.
    And I'm agree that UML is not obvious and you can't teach it easily.

  2. Avatar for Eric
    Eric April 14th, 2006

    There's a really good discussion of why UML never caught on -- and is in fact useless for the things it ought to be most useful for -- in the book Software Factories.
    In short, it's incomplete or ambiguous in some vital areas, it's too general and thus doesn't map at all well to any existing language (making automated generation to/from code effectively impossible), etc.
    To be really useful, a modeling language has to have direct analogues in the language it's being implemented in, so that code generation tools can go to work. You largely can't do that with UML.

  3. Avatar for Haacked
    Haacked April 15th, 2006

    Right. UML seems divided into two paths. Either it is useful for high level architecture sketches in which case it needs to shed alot of weight.
    Or it will become a language in and of itself (albeit a symbol based rather than text based), in which case it will grow immensely and become just another executable programming language.
    This would solve the round tripping problem, but introduce brand new issues.

  4. Avatar for Eric
    Eric April 15th, 2006

    I should also add--C# is a modeling language for IL. IL is a modeling language for machine code. In both cases the mapping is relatively direct--certainly much more direct than the mapping from UML to C#.
    The problem is not that UML is a modeling language, but that it's too general a modeling language; the distance from abstraction to concretization is too far. A less general modeling language (such as the kinds of DSLs Microsoft has been pushing) is much more likely to be truly useful and thus successful.

  5. Avatar for Chuck
    Chuck April 17th, 2006

    Hmmm...
    I tend to view UML in the same light as design patterns.
    Developers implement the standard GoF or PoEAA design patterns every day. But most developers don't know that they've implemented the patterns. Similarly, developers and designers probably use a crude form of UML every day (whiteboard sessions) but probably don't know that they're speaking (crudely) the language of UML.
    This causes a problem only in communication of what has been designed/implemented. It's much easier to communicate ideas with a simple, standard set of abstractions ("I implemented Table Data Gateway for persisting Orders" or "I'm using a Memento to maintain state for the Cart") than to try explain exactly what you implemented with all of the gory details.
    Similarly, it's easier to make good use of UML as a standard modelling language. To you and your team, a squiggly line might mean inheritance; to the new contractor on your team, the squiggly line means "WTH?" :D
    As with design patterns, I feel that you can only derive value from UML if you learn the "language". I simply think that no one wants to learn UML. More importantly, *everyone* on your team has to learn UML for it to make any impact, which can also be said of design patterns.
    As for why people don't want to learn UML? That, I have a harder time answering :D
    ** By the way, the live comment preview feature is nice, but terribly slow in FireFox. Perhaps you should only render a buffered delta using the position of the cursor as a sync point?

  6. Avatar for YP
    YP April 17th, 2006

    This is a 禄(lu) characters?

  7. Avatar for Zahid Ayar
    Zahid Ayar June 9th, 2006

    check out Nelements Programming Language...that aims to make the lives of software developers much easier and software development more efficient!
    It is a visual programming language being developed in the language of thought (or what is close to it) that includes details that are missing in UML. Its basically designed to capture your thoughts in a format close to your language of thought and make it executable and programmatically manipulatable as well...Enjoy using it in the future!

  8. Avatar for John
    John August 1st, 2006

    yes, This is should say "lu". I am CHinese :)