What is wrong with UML Design Tools (part 2)

A good tool should save you work.  That is you should get more out of it than you put in.  The idea behind most UML design tools is that you put in work up front creating a design model, and then create diagrams that show multiple views or perspectives on the target system.  The tool then keeps these views in sync with changes to the model.  The models are either constructed by graphically editing diagrams, or are extracted from source code in a process called reverse engineering.

Before we start spewing out lots of diagrams, we should try to determine what their purpose is to be.  Are we primarily making diagrams to fulfill some contractual requirement?  Is the purpose to get critical feedback from other designers to improve the design?  Are the diagrams used to help developers understand the design and guide their work?  Or are they detailed specifications that fully describe the software?  Of course you might say that you want to use your UML diagrams for all of these, but I’d argue that these uses drive different kinds of diagrams and different features in a design tool.

Let’s start with reverse engineering tools.  This begs the question, if we’ve got code, what do we need the design diagram for?  Or put another way, what does the diagram do for us that the code doesn’t?  The truth is code can be hard to read.  Key functionality can be spread over many pages within a compilation unit, or over several units.  Source code is where developers live.  It’s a pretty dense encoding of information.  If a diagram attempts to capture all the detail of the code, it will be even less readable than the code it represents.  If you’ve used reverse engineering tools you know what I mean, and the ones I’ve used only attempt to capture structural relationships in a single view.

I look for design diagrams to provide 2 things, clarity and emphasis.  Diagrams can often convey larger patterns that are hard to see just by looking at code.  Most interesting patterns involve collaborations between multiple interfaces and/or classes.  These exist in code but are less obvious and easy to miss.  In large, complex programs, there is a lot of code that is fairly straightforward with fairly obvious function and intent.  Understanding the design requires understanding the bits of code that are not so obvious.  These represent key design features that follow from design trades.  Unfortunately they don’t jump up and announce themselves.  A good diagram is an opportunity to emphasize essential elements or features in the design and deemphasize or abstract details that are less interesting.

Now what is a trivial detail and what is an essential design feature depends on context.  If you are the designer of a utility library then most or all of the details of a String class may be of interest in your design diagrams.  If you are designing business object that use strings, then simply identifying an attribute as a string is probably all you need to see.  It’s not uncommon to see classes with over 30 operations.  If you show all of these on a UML class diagram, you can’t even fit the box on a single page; this doesn’t really result in a useful diagram.

One of my big pet peeves is that UML tools want you to commit to an implementation language even in the analysis phase.  For instance, when I’m defining attributes I’m expected to select types from primitives and classes from the target language.  OOA methodology says I should probably be using a text description for attributes at this point, but many tools don’t support that.  When I want to specify a type, things like number, string or date are usually sufficient.  An analysis model doesn’t usually need to be concerned with things like numeric precision.  I recently wanted to specify that an attribute was a URL, but had to reference a Java class to do it.  I might or might not use a class that supports URL syntax, but the intent to store a URL is pretty clear either way.

Constructing effective diagrams takes time and careful thought.  Believe me, I’ve seen many ineffective diagrams.  The more clutter you can remove, the easier it is to focus attention on important design elements.  So the last thing you need from your design tool is added clutter.  Accepted OOD practice is to make member variables private and provide get and set operations to provide public access.   In many tools this will end up as 1 attribute and 2 operations on your class diagram.  This might be accurate, but it’s not interesting and tends to clutter up the diagram.  A good tool should have an option to suppress getters and setters.  Another redundant item in class diagrams are attributes that implement associations.   We all know that there must be some structure that actually holds the association, but this is not what an “attribute” is supposed to be.  If there’s an association on the diagram, the intent is captured, showing the variable that implements it as an attribute is redundant and confusing.

Well that’s enough for this rant.  I think there’ll be more coming.  Also stay tuned for an article about what makes and effective design diagram.

6 Responses to “What is wrong with UML Design Tools (part 2)”

  1. Yanic Says:

    Again, hear hear!

    The point of “clarity and emphasis” is one I (desperately) try to instill upon my students.

    The intent of its creator is what makes a diagram valuable, each diagram has a purpose for which it was created and it should only contain the elements relevant to that purpose. That is why automatically generated diagrams by ‘modern’ (*cough*) case tools are so useless, they have very little support for filtering (which would add intelligence to the view).

    It always reminds me of one of Einstein’s quotes, about making something as simple as possible but not any simpler : the diagram is ready when nothing else can be left out :o)

    Incidentally, I’m working on something that lets you generate sequence diagrams from running code but with programmable filtering (see my comment to part 1 in this series).

    You observation about attributes+methods+associations is spot on. The way I explain it to my students is that for a design diagram, (private) attributes are not relevant since we are only interested in the ‘outside’ of objects (what services they can render to the rest of the system).

    So a design class diagram should in principle only contain methods, but we use attributes and associations as a shorter notation so we don’t have to show so many methods (e.g. instead of methods addStudent, removeStudent, getStudents, … we simply show an attribute ‘students [0..*] : Student’ or an association to the Student class). As a result, we should have some kind of mapping for what attributes/associations mean on a design class diagram, i.e. what methods they represent.

    Malcolm, we think very alike about these things. Hopefully you’ll take me up on my offer (see comment on part 1 in this series). There’s lots of neat stuff I put into my tool that I want you to try out ;o)

    • malcolm83 Says:

      I will check it out. I’m glad there’s someone out there who thinks alike. I’ve been thinking for a while how much sense it would make to turn a stack trace into a sequence diagram. After all, they’re really just a snapshot of one (or more) possible flows of control. I’m not a fan of trying to show lots of branches and loops.

      Have you ever read anything by Desmond D’Souza? He’s got an interesting take on why you need to use state to describe the semantics of interfaces (though that’s just logical state).

      I like your idea about simplifing diagrams. I’ve got a couple of books by Edward Tufte who applies that logic to all kinds of graphics. You sound like you might be a fan.

      How’d you come across my blog?

  2. Yanic Says:

    Indeed, sequence diagrams are at their best when they only show a single scenario.

    If you’re into java, I’ve created a companion tool that allows you to trace the execution of a piece of code and apply some advanced filtering/processing to it (all using simple java code). The idea is that the filtering code captures the ‘human factor’ (i.e. the viewpoint that makes a diagram valuable) so it can be reused when the diagram needs to be re-generated because of code changes.

    I hadn’t heard of D’Souza, but I’m very much into design by contract to capture (parts of) the semantics.

    I’ve come across Tufte once or twice whilst surfing the web (that and the obligatory London underground diagram :o).

    Your blog came up because of the reference to UML tools, I’ve got a couple of google alerts set up for that subject matter.

    Anyway, let me know if you want a complimentary license for Trace Modeler – plus a link to the latest version that has a lot of new features (not yet released).

    (btw, it might be an idea to post my comments as well, it looks a bit weird when you’re talking to yourself on your blog ;o)

  3. Joe Hoff Says:

    Well, I’m late to the party.

    I really like what you wrote here. I’ve felt much the same way about existing OO tools.

    One trick I learned with things to avoid the imposed precision of classes the tools try to force you to: Just use ‘//’ to designate a pseudo-type — in your example, URL. The prefix did a couple of things: prevented the tool from generating nonsense. Provided a visual indicator to the reader that precision wasn’t precise. At some point (after discussing alternatives but prior to final review) all those ‘//’s would have to be replaced to be considered complete. Gotten myself into trouble by allowing the team to press forward with abstractions just to find that the ‘//’ type/data they were waving their hands at didn’t really exist anywhere in the system.

    Been a long time, Malcom. Hope all is going well with you.

    • malcolm83 Says:

      Better late than never. I was starting to think I was out here all by myself. I didn’t see the notice on your comment, I haven’t checked that e-mail account in a while. Still slogging in the video game world? Let me know when you’re ready for the fast-paced world of government contracting ;)

  4. Kiezer Says:

    Lost health care love-warrior spirit?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 124 other followers

%d bloggers like this: