Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

In our last Episode, The UML Guy met Deadline, a project manager with a Grim problem. Today, another member of The Team wanders into the Lounge. (Click the pictures for larger images.)

Episode 21a

Episode 21b 

This one is for @arphahat (who shaved his beard a long time ago). Now can I have my freakin' cookie dough?

And yes, I already referenced this film in Episode 18. It's one of my favorites. Deal with it.

Back in Episode 10, I introduced Sequence Diagrams because I needed to demonstrate them for Ann Arbor Day of .NET. In Episode 16, I contrasted them with Activity Diagrams with Swimlanes and showed some similarities and some differences.

But spurred on by a suggestion from @arphahat (if there's a joke you find funny in this strip, there's a good chance it's his -- I wrote all the unfunny jokes), I decided it was time to show why I think Sequence Diagrams are the UML diagrams that speak most clearly to programmers.

At the end of the day, many programmers just care about code. They love solving problems and using code to do it. And a lot of things that go into a complete development process -- talking to customers, researching rules and regulations, documenting business rules, end user docs -- just don't interest them. And most of the UML I've shown so far has been about those things. Those other things that aren't code. Bo-ring...

But Sequence Diagrams are different. Yes, in some way, they're like the dreaded flow charts that Apathetic Coders hate more than anything; but they're also about Objects and Methods and Classes. In other words, they're about what we have to write in the code! In a way, they're Object-Oriented Flow Charts.

And as I demonstrated a little in this Episode, Sequence Diagrams actually let us think through the code we have to write. We put down an Object, and give it a Class. We ask what it's supposed to do, and we add that to the Class. Then we ask "What does it need to do that work?" Oh, that's another Object, another Class, another Method. Repeat, repeat, repeat. And when we're done, we've defined a bunch of Classes, and defined (or at least implied) a bunch of relations between them. So creating a Class Diagram is practically trivial.

So now all we have to do is wait for the 23rd century and tools that will convert those directly to code.


Wait a minute! What are we waiting for? Those tools exist today! In fact, they've been around since the dawn of UML, and are getting better and more powerful every year! In fact, let me demonstrate with Enterprise Architect. I started by converting the Sequence Diagram to this somewhat more elaborate Class Diagram. (I couldn't help myself, really! My geek-ness knows no bounds...)

Weapons Systems

Then I right-clicked on the Package in the model and selected Generate Source Code:

Generate Code

The Generate Package Source Code window opened, and I selected what I wanted to generate and where I wanted it generated:

Generate Package Source Code

I clicked Generate, and the following C# code just beamed in from nowhere (and I apologize to Editor Bill and any other non-coders reading, but I want the Apathetic Coders to see what they're getting at the push of a button):

//  Photon Torpedo System.cs
//  Implementation of the Class Photon Torpedo System
//  Generated by Enterprise Architect
//  Created on:      07-Nov-2008 10:29:12 AM
//  Original author: Martin L. Shoemaker

public class PhotonTorpedoSystem : IWeapons {

    public PhotonTorpedoSystem(){




    public virtual void Dispose(){


    /// <param name="lock"></param>
    public void Aim(SensorLock _lock){


    public void Fire(){


}//end Photon Torpedo System

OK, OK, I won't hurt Editor Bill's brain any further. The remaining files can be found here.

Now this is only one way these files might work. Enterprise Architect has a lot of options for controlling code generation: languages to use, idioms to apply, locations to store files, and more. And other tools can produce code that looks even more different. You have to learn what to expect from your chosen tool.

Many UML tools will also reverse engineer Classes and Class Diagrams from code. The results are usually ugly, because the diagrams are laid out by a machine. Machines have no sense of esthetics. But the elements are there, and you can rearrange them into a more legible diagram.

And some tools can go far further. For example, Visual Studio Team System's next version, code-named Rosario, can do more than generate code or generate Class Diagrams: it can actually reverse engineer Sequence Diagrams from code! I recorded a demo of this using the April Community Tech Preview, and you can find that video here. This is a phenomenally powerful tool for learning and diagnosing legacy code. What Rosario does in an hour, I used to do on new projects in weeks. Once upon a time, there were reasons to doubt the power of good UML tools. Today, I find the better tools to do what I need without any doubt. And tomorrow's tools? Well, you don't have to wait until the 23rd century. Rosario will probably arrive late 2009 or early 2010. I can't wait! And thanks to CTPs, I don't have to! Look for future videos that further explore the power of UML in Rosario (now referred to as Visual Studio Team System 2010).

Now I have some miscellaneous notes on today's Episode...

I'm not gonna explain all the Star Trek jokes in this Episode. Either you get 'em, or you don't. There are just too many to explain.

Back in Episode 16, @dfavre paid me a cryptic comment by responding "Whoa!" I didn't get it, so he explained it was a Bill & Ted "Whoa!" Well, I'm sorry to say that I've never seen Editor Bill's favorite film, so I still didn't get it. So Editor Bill explained: "Bill and Ted 'Whoa!' is good; Joey Lawrence 'Whoa!' is bad." I loved that line, so I stole it.

The hair on the Admiral is a toupee. If you can't tell, blame the artist, not the hair dresser.

Despite the hair jokes and the cadence jokes, William Shatner is one of my heroes. The way he has ups and downs in his career but keeps coming back is inspiring; but then on this album, he reveals a number of real insecurities that show his coming back and coming back is a struggle against the voice in his head that says, "You're not good enough. You never were. You're just a fluke. A has been." Well, a couple of Emmys give him something to say back to those voices. Go ahead and make fun of him, laugh at him. He'll laugh with you, because making fun of him keeps him public. And as Jason Alexander once observed, nobody can do a better Shatner parody than Shatner.

I'm almost the first to coin the term "technobabulator". finds no hints on it. Google finds two uses on two SF boards. So it's not mine, but it's very likely that you heard it here first.

Speaking of technobabble: I'm not sure that Starfleet ships have to open a pinhole in the shields in order to fire out. I probably got that from Niven and Pournelle. But it makes sense, and it made for a more interesting example.

Editor Bill commented that there seemed to be a flaw here: we jumped straight into Sequence Diagrams and Class Diagrams and code without any Use Cases! First, let me say how proud that makes me. Editor Bill is a good friend who's not a developer; but I keep telling him that he speaks Developer and End User like few people I know can do. If I had a budget, I would put him in charge of a project post-haste, and make him responsible for representing the end user's view to the developers. To have him now speaking UML and thinking how to apply UML makes me feel like: I win!

But he also already had my answer: UML isn't a process, it's a language. You can use it in the context of any conversation about the system, at any stage of a process, no matter what the process is or even if you have no process but code like mad! This Episode isn't an example of a healthy development process; but sadly, it is an example of situations some developer ends up in every single day.

I've told this story before, in a lot of forms and a lot of venues. Since this is a comic strip (sorta), I'll keep it brief and stick to the high points. Early in my UML career, when I didn't even really grasp the scope and potential of UML, I inherited a legacy product, a mountain of bugs, and an anxious manager. They needed bugs fixed, and they needed them now. I was the only one left in the company who knew this technology, so it was me or nobody. Now they knew intellectually that nobody was going to step in and fix bugs in 8 years of legacy code overnight; but even though I promised nothing, they still hoped that I had some miracle in my back pocket.

I did have a miracle in my back pocket. I just didn't know it yet. I had UML.

I agreed to try for a miracle, if they would agree to let me try something radical. At the time, we were experimenting with UML and Rational ROSE, one of the earliest and most powerful of all UML power tools (and still a fine UML tool). I was spearheading that effort at the company. I wasn't 100% sure why I was so interested in UML (though I have recently come up with an answer); but I was interested at the same time the managers were, so they let me learn on the projects. (Thank you, Phil and Steve!) I said I could try taking ROSE home and reverse engineering a "map" of the code. From that, I would try to learn and understand where the new bugs were. But they had to give me time to learn before I could fix.

And so they agreed; and so I did. I started by reverse engineering the Classes and Class Diagrams. With the tools of the time, that took me days. Then, though I didn't know the code, I knew the technology. I could find user input points. Comparing those to screen shots and the help docs, I derived Use Cases and Use Case Diagrams. Working at my best possible speed at the time, that took me days more.

I wish today I could remember why I did what I did next. If someone suggested it, I want to thank him, because it was right. I took those Use Cases, and I took the code, and I manually reverse engineered Sequence Diagrams to describe what happened when the user pushed a particular button. That took me days and days and days; but when I was done, I had learned what that code did in ways I couldn't have known without making something from the information.

And when they asked, "How long will it take to add this data to this report?" I was able to ask, "Where does that information come from? OK, that's this signal. That causes this Use Case, which is detailed in this Sequence Diagram. OK, where does it come in? There? OK, so I can add it to this object, and this call, and this database table." And then I asked, "When does this report happen? OK, when they push this button on this screen, I see it. And that runs through this controller, and pulls this data... There, there's where I need to read the new column. Then I can pass that in with this call, and this one, and... OK, here's the report Class. I need to add one column here, and put this field into there. OK, I can do this in about two weeks, because I don't do SQL. If you can lend me a DB guy, we should have it in under one."

Think about it. This code was 4,000 source files that had been under development for eight years, all written by one developer. And that one developer wasn't me! Yet in under 30 days, I was able to understand, explain, maintain, and extend the code. All because UML helped me to converse: first with the code, then with myself, then with the managers, then with the DB guy. I was by no means an expert on that code yet; but I was familiar, and comfortable, and confident, and competent. I didn't truly appreciate it at that time, but that was my miracle.

And today, with a decade's improvement in tools, and a decade's improvement in my skills, that would be hours instead of days. With upcoming tools like Rosario, some of that will be minutes instead of hours. The future's so bright, I gotta wear shades.

And finally, an unexpected conclusion...

I learned something in drawing today's Episode. Well, I may have known all along, somewhere in the back of my head; but when I drew this Episode, it all came together with a click! Although @arphahat inspired today's episode and served (pre-shaving) as the model for Apathetic Coder, the truth is that thanks to the vagaries of Spacetime distortions (where's @coreyhaines when you need him?), Apathetic Coder is The UML Guy, just a younger version. When this film was in the theaters, I just couldn't see the point to any sort of design drawing (we called it flowcharting back then). I was busy. I had code to write. All this picture-drawing was getting in my way. I would never have admitted it, but I was Apathetic Coder (without the beard).

So although I have a policy never to explicitly state my ulterior motive in drawing the Lounge, I can say this much: when I'm talking to you in this strip, I'm talking to Me. I'm talking to the Me who worked long hours and days and weeks and months on poorly defined projects that didn't have to be that way. I'm talking to the Me who loved writing code but hated failing and hated whatever seemed to make failures more common than successes. I'm talking to the Me who didn't listen to friends who were struggling with some of the same ideas but a little ahead of me in seeing the potential. I'm talking to the Me who thought it was all about code, and didn't see that it's all about communication. I'm talking to all the Mes stuck in warehouses and offices and who knows where at 3 a.m. with an 8 a.m. deadline, trying to understand how they got there. And I'm talking to all the Me's out there who might be smarter and quicker than I was, if only somebody can show them a reason to pay attention.

It was a long, strange trip indeed from Apathetic Coder to The UML Guy. Come, walk with me. I want to show you a shortcut.

Posted on Saturday, November 15, 2008 5:09 PM Ulterior Motive Lounge | Back to top

Comments on this post: Ulterior Motive Lounge Episode 21: The Wrath of Code

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: