In our last Episode, Linguist Coder and Prototype Analyst kidnapped The UML Guy and demanded he explain arrows in UML. After a rescue by the police, The UML Guy returns to the Lounge. (Click the picture for a larger image.)

This one is for Jennifer Marsman, who is quite possibly the second-most-fanatical UML geek that I know. She's also the creator of Featured Women in Technology, an ongoing series of profiles on women who shine in technology fields. Jennifer does her part to show young women that technology isn't an all-men's club. And boy, is she right! Besides her profiles of Dianne Marsh, Katy Kneale, Janet Galore, Carey Payette, Amity Binkert, and Lidiane Souza, I would add (off the top of my head) Lynne Molenkamp, Dana Coffey, Michelle Leroux Bustamante, Mary Poppendieck, Julie Lerman, Betsy Weber, Sarah Dutkiewicz, Anne Gogh, Gina Loveless, Grace Hopper, Rachel Appel, Janine Moore, Maggie Longshore, Elizabeth Naramore, Lynn Langit, Jennifer Davis, and Kirstin Juhl. Plus many more whom I forget at the moment, but whom I respect as colleagues, and to whom I offer my sincere apologies for my feeble memory. And lest we forget, Jennifer Marsman.

The Lounge is a bit testosterone heavy so far. Partly due to the characters I used as inspirations, partly no doubt from my own experience, the Lounge cast so far has run about 7 males per female. I decided that was out of balance (although honestly, it's a better ratio than most places I've worked); so it was time to add Geek Girl to the cast. Think of her as a spokesperson for all the engineers and designers and evangelists and authors and speakers in the list above. With Crystal Bernard's accent, because Wings happened to be on while I was drawing this Episode. (It's amazing the tricks the mind plays. I could "hear" Geek Girl in my head, clear as a bell, and couldn't place the voice, even as the same voice was speaking in the background.)

Modeling user interfaces in UML is a common problem; and State Diagrams are easily the best answer I've found. They're a great way to show flow that's based on user decisions, not on some algorithm. With Events and Actions, they're a great way to show control events and how your system responds to them within a given form.

And perhaps most important, they're a great way to handle The Cancel Problem. In a modern GUI, it's often the case that a user can cancel at almost any point. Even worse: if you're building a Web app, they can always just close the browser, or even disconnect from the Web. That's not an immediate cancel; but it will be a cancel when the Web session times out. If there's some work that has to be done to clean up when the user cancels, trying to draw control flow with Activity Diagrams, or even with State Diagrams, becomes a nightmare as you try to draw arrows from every possible cancel point to the clean up work. But with a Superstate that contains all of the cancelable Substates, you can easily show that all of these Substates handle cancel in the same way: by performing this clean up work. In today's Episode, for example, no matter where you are in the Booking process when you cancel, you have to go to Releasing, or the suspect will get lost in the system.

User interfaces aren't the only things you can model with State Diagrams, of course. They're a powerful tool for modeling certain kinds of business processes. In particular, if you have a document-centric process, where some document (such as an Order for goods) passes to different departments as different people act on it and different events occur, then you can easily automate that process as a document object that passes through different States in response to some Events, and which does work within a State in response to other Events. This can be a convenient way to model processes built within a Service Oriented Architecture.

Another value of State Diagrams is that a number of tools will turn these directly into executable code. In particular, Windows Workflow Foundation is a powerful tool that lets you graphically design both Sequential Workflows (similar to Activity Diagrams) and State Workflows, and then execute them directly. There's some work involved in hooking them into a user interface, but there's amazing flexibility and power in being able to depict and edit a flow graphically and then change your mind without having to change a lot of code.

In our last Episode, Apathetic Coder and The UML Guy derived code from Sequence Diagrams. Today, the Lounge has a pair of unexpected visitors. (Click picture for a larger image. UPDATE: The larger image is broken somehow. I probably can fix that later tonight.)

This Episode is a hodgepodge of obscure references:

• Star Trek.
• Zatanna the Magician.
• The Ransom of Red Chief.
• Benjamin Franklin.
• Entity Relationship Diagrams (ERDs).
• Data Flow Diagrams (DFDs).
• Episode 8.
• Night Court.
• Columbo.
• Who Framed Roger Rabbit?
• Plus a couple of coworkers with unusual interests: Scott Morris, who specializes in assembling rapid prototypes of systems; and Harry Gilbert, linguist and programmer and musician (among other talents).

If you don't know all of these references, this Episode can be completely baffling.

Kinda like the arrows can be in UML, until you get used to them.

To me, the UML arrows are natural. They're "right". They're what I learned, and they make sense.

But to people skilled in ERDs and DFDs, the arrows are precisely backwards. In those notations, arrows indicate the direction that data moves: in other words, from provider to client. UML's arrows run from client to provider.

For that difference, I can only apologize. The notation is what it is. It took me two years of teaching UML before some student had the guts to raise a hand and ask "Why are the arrows backwards?" Now at least I'm aware of the issue, and (usually) remember to bring it up early so that you can grapple with it.

At the same time, what's the client and what's the provider isn't necessarily cut and dried. In fact, it can be an arbitrary implementation decision. Does a book refer to its chapters, or does a chapter refer to its book? Or both? And if the answer is both, is that one association, or two? In code, it almost has to be two; and in UML, we would model that as two arrows. But if it's a single association, we model that as just a line, not an arrow. That's also a common way to model the association when we haven't yet decided what's the client and what's the provider.

So if the arrows are confusing, I apologize. I'll do my best to make really clear examples.

This Episode is for Harry and Scott, who demanded it. Now, they didn't hold me at gunpoint, but they got really close...

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.)

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.

Tick-tick-tick-tick-tick-tick-tick-tick-tick...

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...)

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

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

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(){

    }

    ~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". Live.com 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.

In our last Episode, Evil Tester used his newly gained UML skills plus his testing expertise to generate mountains of good news for The Reader. The Lounge is attracting attention from unexpected quarters, including today's new cast member... (Click the pictures for larger images.)

Why yes, I am reading Steve McConnell's Software Estimation right now. You should be, too. While he has earlier argued that requirements errors are the most common factor in project failures, here he shows that systemic underestimation is also a pretty significant factor (complicated, of course, by requirements problems). He shows you techniques that can improve your estimates to a 25% error range (with practice); but he also discusses what an estimate means, what it doesn't mean, how to revise it, and how to effectively communicate estimates and attendant risks to stakeholders.

And one of the fundamental techniques he describes is refining the problem down to a large number of smaller elements. Those smaller elements can then be counted or calculated or judged to produce a number of small estimates. And a fundamental truth of estimating is that many smaller estimates have less error than a few large estimates do.

And where can you find the smaller elements to estimate? Well, if you don't know my answer, you need to reread today's Episode... Long before I ever read McConnell's book, my estimating practice was good for about a 30% to 40% error range (when I followed it rigorously -- not following it is always a risk). And that practice is simple: don't estimate until I have at least a rich Use-Case-level model, and preferably a detailed Swimlane-level model; then build the estimate from the models I have.

Now when I do that, the estimate that results is usually one the customers don't like. They have a Target, and they want the Target to be the Estimate. But that's a contributing factor to the systemic problem that McConnell describes:

The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger.

Yeah, bigger estimates... That's gonna make stakeholders happy! Not! But they're already unhappy with inaccurate estimates. Much of McConnell's book is about better estimating techniques, but it's also about educating stakeholders on the use and value of accurate estimates. It also discusses ways to present and justify your estimates, and to use them as a basis for negotiating a feature set and a schedule that satisfies your target. By no means do I want to imply that this is easy; but I find that with a good model, I can lay out a case: "These are the things I'll have to build. This is how long I expect each one to take. And this is what those add up to. Is there any reason to believe that we can do any of these faster? Can we do any of these in a simpler, faster fashion? Are there any of these that you don't need for this release?"

And no, that conversation won't be pleasant; but it's necessary. Unpleasant up front is better than unpleasant in the end. Committing to do the impossible damages everyone: the team, the company, the customer, everyone. The customer will plan other parts of the business around a schedule that's never gonna happen. That ties up resources and funds and people that might be better used elsewhere.

Is there a risk in that conversation? Maybe; but if there is, you need to find a new job. If reality is taboo at your company, it's not a question of if you're going to fail, it's only a question of when. But before you abandon ship, try McConnell's suggestions. It may be very possible to work out a win, if you approach the discussion carefully.

OK, now that I'm done shilling for McConnell... (Not really. It's not shilling, it's enthusiasm.) Let's discuss some details of this Episode.

This Episode is loosely inspired by this film, but owes much more to this book. The Hitchhiker's Guide joke was irresistible.

I loved the idea that even Grim is afraid of the consequences of a HIPPA violation! If you're in health care software and you're not afraid of HIPPA, you're either very brave, or very foolish. They take privacy violations seriously, so your software had better do the same.

The Use Case Diagram in panel 6 introduces some new notation; or at least, new for what we've seen of Use Cases:

• The triangle-headed generalization between Use Cases. You may recall from Episode 7 that the generalization arrow runs from the specific to the general. In Classes, the specific Class (a.k.a. the Child Class or the Subclass) added information or new behavior to the general Class (a.k.a. the Base Class or the Superclass). With Use Cases, a base Use Case defines a set of common rules and scenarios, and then a specific Use Case adds details or more scenarios. In this example, Reschedule is probably faster and easier than Schedule, since much of the information is already gathered. Maybe we can skip all the gathering steps and go straight to forecasting. On the other hand, Redo Missed is probably more complex, because we have to determine and set up an appropriate punishment.
• The dependence (i.e., dashed arrow) from Visit Appt. to Redo Missed, tagged with the <<call>> stereotype. This indicates that somewhere during the course of Visit Appt., we may have to also perform Redo Missed. Let me emphasize that again: may. A given Use Case can contain multiple scenarios, and the included Use Case may be part of one scenario or all. The only way to be more specific is to drill in to the Activity Diagram inside the Use Case.

It's easy to go overboard with Use Case generalization and included Use Cases. Resist that urge! That can overcomplicate your Use Case Diagrams to the point where no one can read them and they lose their value. In particular, if your Use Case Diagram starts to look like a flowchart, you should be drawing an Activity Diagram. Use generalization and includes when they clarify and answer questions, not just because you can.

Model-View-Controller and data access layers are just a start to good architectural patterns. The Gang of Four and Martin Fowler have a lot more to say on this subject.

Please don't take the estimates in this Episode too literally. I did my best to make them plausible; but real estimates deserve more thought than I put into these. They're not a project plan; they're just a demonstration of the principle that:

Early estimates tend to expand with detail.

And yet they don’t expand indefinitely! It’s the early estimates that are most sensitive to detail. Notice how from panel to panel 9, we jumped from 5-13 weeks up to 15-31 weeks, or around a factor of 2.5-3. Yet from panel 9 to panel 11, we jumped only to 14-36 weeks. That’s a factor of around 1.2, or maybe even a decrease. This reflects the Cone of Uncertainty described by McConnell. As the development cycle proceeds through phases of maturity, the uncertainty goes down, and the estimates go down with it. I usually find that waiting beyond Swimlanes to do my estimates doesn’t add much accuracy, especially considering that it takes a lot longer. McConnell argues that the optimum time to make a “Commitment” estimate is after the user interface is sketched out and approved. He’s probably right, because the UI is the most tangible information the customer can see to provide feedback. But that takes a lot more time, and customers are impatient. I can take requirements all the way from idea to Swimlanes in relatively short order, so that’s where I prefer to estimate.

Note also that the summing technique I used here (sum the lows for the total low, sum the highs for the total high) is naive. I kept things simple to stay within the bounds of a comic strip. McConnell has much more sophisticated techniques to suggest, yet techniques that aren't that much harder to apply.

Oh, and did I mention that you should read Steve McConnell's Software Estimation? You should!

In response to Episode 16, Mitch asked yet another thought-provoking set of questions:

Another reason for swim lanes: I've seen them before. It was very enlightening to see the similarity between the new concept of Sequence Diagrams with a familiar friend.

Here is a nagging concern: whether you approach your model from the top-down or the bottom-up, if your premises are flawed, how will you know that your nice neat diagrams have errors? It's one thing to note omissions, like the outstanding payables. It's quite another to detect "hangs" (A depends on B depends on A) and illogical constructs, like mistakenly switching the swim lanes for the analyst and the saboteur :).

Is there a "middle out" approach to UML? I recently read a thought-provoking article about how to write technical manuals. The author explained a middle-out approach that works - for manuals.

Cheers,

Mitch

Belatedly, I'd like to respond. To address the first question first, this is the benefit of working with a team. Trust your team members to see what you miss, and they’ll trust you to do the same. I used to espouse a fundamental dilemma of design:

Good design comes from individuals; sound design comes from committees.

And then, building on this dilemma, I advocated for a “most likely” path to successful design: design in isolation, because that’s the best way to get a single, unified vision with great clarity; and then review with a committee to have them point out oversights and places where you thought the design communicated, but it really didn’t.

Boy, was I an officious prig! More and more as I work with clients and teams, I’ve reached this conclusion:

Good design comes from good teams; sound design comes from good teams.

I still see benefit from the “design alone, approve together” approach. You really do benefit from people with different blind spots pointing out your blind spots.

But I see more benefit when a good team can create the design together. Note the difference here between “committee” and “team”. Heinlein said, “A committee is a life form with six or more legs and no brain.” Well, a team has the brains of every team member, actively involved or else not showing up. Jim McCarthy describes the essence of team-ness and team building in two books. He describes a lot of techniques, while by no means promising that team-building will be easy; but two of the fundamental techniques he describes are easy: Check In and Check Out. His point is that if you’re not honestly, actively participating in the current team activity, then your responsibility to the team and to yourself is to Check Out of that activity, and Check In when you can commit to it again. Someone who’s in a design meeting solely because the boss said to be there won’t contribute to the design, and will inevitably add a sense of lethargy to the discussion. Someone who’s there because he or she is curious and interested and actively participating will lead to a better design.

I’m sure I’m making team-oriented design sound too easy. I can only say that in my recent experience, it can be easy. The more I trust the team – including the customers – to communicate their ideas and sanity-check mine, the more I find that trust justified and reciprocated. It didn’t start easy. Like many of us, I had an instinctive distrust of committee efforts. Heck, “design by committee” is a cliché for “poorly and overly designed”. And I still experience that in some design “teams” that are really design committees. But I find that extending trust and giving a committee a chance to be a team pays off more often than the cynics expect.

There are three techniques that I find make a big difference in the effectiveness of my team design efforts:

1. Trust. As above, and as DeMarco notes: the surest way to be trusted is to trust. It seems to be something in human nature.
2. Listen. Really listen, especially to any customers in the discussion. Hear before you speak. When I work with a new customer, I routinely spend the first hour of our time together just listening. I might take notes, but probably not: I want them to know they have my full attention. And then, after I’ve heard their concerns, I start drawing diagrams of what they said, or finding existing diagrams that reflect their concerns and updating those based on their new information.
3. Be their UML tool. This is easy for me to say, hard for you to do until you yourself master a good tool; but I find it’s incredibly effective. Almost anyone on the team can read the diagrams and suggest changes; but if they have to struggle with a tool to put their ideas out there, they get frustrated and stop communicating. I want nothing in the way of that communication. This is a really good argument for team design sessions to use a whiteboard as their design tool: everyone knows how to use a whiteboard! But I find I can get almost the same ease of use plus all the benefits of a good tool-built design if I let them talk while I draw with my diagrams on a screen where they can comment. Soon they’re telling me what I’ve drawn wrong, without me having to teach them UML. Sometimes they’ll ask me notation questions, and I’ll answer to make sure they’re not confused; but I consciously “tone down” the notation, avoiding the obscure and the complex for the simple and the comprehensible.

Of course, none of this helps if you’re a lone developer. In that case, I can only recommend the Beatles Strategy: get by with a little help from your friends. Find fellow developers who are similarly in need of design feedback, and take turns reviewing each others’ work. Of course, there can be confidentiality issues here (no plan is perfect!), but “buddy reviews” can be a great way to find and patch design holes.

As for the question, “Is there a ‘middle out’ approach to UML?”: Nineteenth century German Field Marshall Helmuth Graf von Moltke told us: “No battle plan ever survives contact with the enemy.” Top-down, bottom-up, even middle-out: these are all battle plans for how we think we’re going to attack the analysis and design problem. And as von Moltke taught, blindly following your plan after it’s proven wrong is a plan for defeat. In the case of designing, especially when designing with customers, saying “We can’t discuss that now, that’s not on our plan” is akin to saying “That’s not important”; and they may even hear “You’re not important.”

So my real plan, regardless of top-down or bottom-up, is “If they say it, I draw it, and then I clean it up after we break.” I want to respect all the knowledge they share as they share it. One advantage of a good UML tool is it’s really easy to find a place or at least a parking place for any information you discover, whenever you discover it. I go in with a roughly top-down plan; but I adapt the plan to the people, not the people to the plan.

Thanks as always for great questions, Mitch!

In our last episode, The UML Guy showed Evil Tester how he could use UML to define new test cases with ease. Now The UML Guy wonders what sort of monster he created... (Click picture for a larger image.)

When you're a kid, and somebody famous shares your name, it opens your eyes to possibility. It gives you a sense that Hey! That could be me!

You Johns had Wayne (the ultimate tough guy) and Cash (the incredible musician). You Jims had Stewart and Cagney and Garner. You Robs had Redford.

We had Feldman. Is it any wonder we have a twisted way of viewing the world?

(And yes, I still love that fireplace! Some day I'm going to do an entire Episode consisting of nothing but shots of the fireplace. Well, maybe not...)

If there's a team I feel most underutilizes UML, it's the testers. If the analysts and the architects and the designers actually draw the diagrams (hey, I'm doing my best to convince them, but ya gotta give me more time!), it's like they're giving you a map of what's in their heads. Long before they get to code that you can test, you can start planning your tests. How will you test the different scenarios? What range of test data will you need for each scenario? Will you need tools or special setups for a given test?

And you can also play an early and active role in the requirements analysis. If you can't test it, neither can the user, so how will the user know when it's time to sign the check?

Some tests clearly can't be automated. If you're building, say, motorcycle diagnostic tools, sooner or later you have to hook up to a real motorcycle. And darn it, those things just don't like to be automated!

But we can automate a lot more tests than we sometimes expect. There are some great testing tools out there. Commercial products from companies like Microsoft and IBM and Compuware and HP (among others) will do a lot to automate your tests. They cost a lot, but they save a lot more.

And when I recommend Enterprise Architect (which I do often), one of the features I cite is their test management tools. These don't automate testing, but they automate test tracking.

And then there are free tools like JUnit and  NUnit. These automated unit testing tools will help Testing Coder (or is it Coding Tester?) to build tests of individual units of the code.

Of course, it would be even better if the programmers used good unit testing tools before the code reached the Evil Tester. That would wipe that smug look off his face! Heck, they could plan their unit tests before they even wrote the code! Why, they could even define their functional requirements in the form of tests they must pass in order to function correctly!

Nah, that's too radical. Nobody would ever do that...

No, this Episode has nothing to do with this film. But that was a good feint, huh?

And I want to point out again that mine was not the first Evil Tester comic!

UPDATE: Alan Richardson beat me to the Evil Tester joke, including his own Evil Tester comics. He also left a great comment below, and he has a lot more to say on testing.

In our last Episode, Process Cop explained the Process Menagerie, and The UML Guy lectured you on its importance. Today, a new cast member appears... (Click the picture for a larger image.)

First, let me say it's merely a happy coincidence that Evil Tester debuted in the Lounge on Halloween. I needed him for another project, and I was between films, so it just seemed like time to introduce him. But when I realized what day he would appear, I said, "Aha! This is great! They'll all think I planned it this way! They'll think I'm brilliant!"

[Oops! Did I say that out loud?] Ummm... Forget that whole last paragraph. Really, I've been planning the timing of this strip since before Episode 1. Really!

[OK, now I need a new introduction. Hmmm... Oh, I know!] First, I'm insufferably pleased with that fireplace, especially in panel 4, with Evil Tester standing in front of it. Probably none of you will know this, but that's exactly the fireplace from a restaurant we used to frequent in the 80s after a movie. I still remember sitting there with Sandy and a friend one evening after watching Wrath of Khan (again). (For those who're wondering, that counts as today's movie tie-in.)

And second, I want to make one thing extremely clear: Evil Tester is my best friend! He's every programmer's best friend. Every bug he finds at 3 PM is a bug the customers don't call me about at 3 AM! (Actually, I'm a night owl coder by nature. Calling me at 3 AM is probably the way to get my best work. But you get my point.)

And I want him to take fiendish delight in finding my bugs! I want a friendly rivalry (not a hostile competition!) between him and me. I want him to dig and probe and ferret out bugs so he can laugh at me about them. That will motivate me to do whatever it takes to be sure there are no bugs for him to find! And it's the best thing for the customer. A good Evil Tester is my last defense against myself!

And that means I want Evil Tester to learn UML. I want him to read our models as a tool to verify what we're supposed to build. (To repeat myself from the Episode: Just because they model something doesn't mean they'll build it!) I want him to look at the models and think of likely weak points to attack. I want him even to use UML to model his own tests -- really devious, complex tests, too complex for a simple verbal description.

And I want him to get even more out of UML; but that must wait for the next Episode.

So really, to all the great testers out there, especially Ernie Out in the Barn: when I call you Evil Tester, I mean it with all possible love and respect. And the horns and the pitchfork are just a joke I couldn't resist. Especially not on Halloween!

In our last Episode, we wrapped up Activity Diagrams (for now) by showing how Swimlanes let us specifiy who or what is responsible for each Activity or Branch. After the Lounge has dried out, we get some process instruction from Process Cop. (Click the picture for a larger image.)

Too often, I find that teams embark on "process improvement initiatives" without first understanding what their process currently is. This is like asking an architect to redesign your house without him ever seeing your house. The most he can do is design a whole new house. That will be way outside your budget, it won't fit your property, and it won't succeed!

Yet that's almost exactly how "process improvement" is implemented most of the time: "Here's the right process, so start following it. No, we don't know what process you were following, but this is better. This is right."

Bull. The right process varies by the team, by the project, by the schedule, and by the budget. Oh, you can have a meta-process that helps you define processes; or you can have a process family, and choose the best family member for a given project; but there is no one right process. And finding the best process starts with assessing your current process.

Some teams like the idea of Agile processes because more Orchestrated processes are getting in their way; but some teams like the idea of Agile processes because they really don't want a process at all, and Agile processes seem easy to subvert. If you have a team of Gnats arguing "We have to be more Agile," you may really have a team of anti-Process zealots. Their arguments for Agile are a sham. On the other hand, if you really want to improve your processes, Agile may be as far as you can move them. Gnats may become Cattle, but they can't become Circus Horses overnight. Look for more Orchestration only if you really need it.

On the other hand, if you have a team of Lemmings and you're trying to improve your processes to cut down on failures, yet more Orchestration will probably make matters worse. Lemming processes are the problem, not the solution.

And if you are embarking on a process improvement initiative, the first improvement I recommend is wider adoption and use of UML for communications throughout the process. I hope I've given you a few ideas here.

The fundamental goal of Process Cop is to ensure that process, team, tools, and requirements are all compatible. This is complicated, because team is “whoever we could hire”, tools are “whatever we’ve bought or built or downloaded”, and requirements are “whatever customers ask for”. The idea that a single process designed in isolation from these can be the missing link that somehow binds them all together is naïve, and will cause The Team to lose respect for Process Cop. Team, tools, requirements, and process all have to adjust in different ways if there’s to be any hope of success.

Now UML can help Process Cop to guide these adjustments. Remember: UML is about modeling systems, not just software, where:

System = Structure + Behavior + Goals

By this definition, a team and a development project make up a System; and indeed, UML can be used very successfully to define and revise the processes for that system. Maybe later, Process Cop will show you some examples.

For the record: lemmings don't actually march off cliffs in mass suicides. But it's such a powerful metaphor, it will never die.

P.S. Actually, I’ve never really liked this film series much. But it seemed like a good film reference for this Episode, since the subject is a little bit academic.

In our last Episode, we saw how Forks and Joins let us model parallel behavior within Activity Diagrams. But we're not quite done with Activity Diagrams. (Click pictures for larger images.)

No, the dolphins in panel 3 aren't my work. Anyone who thinks I can draw that well hasn't been paying attention. They were drawn by my lovely wife Sandy for our wedding invitation. I merely traced them. (The scuba gear and the singing crab... Now those you can blame on me.)

To discuss Swimlanes, I needed water; and this was the best water-themed film I could think of; plus it's a film I really enjoy. Still, after the title of this Episode, I'm going to have a much harder time objecting to Editor Bill's puns. (In my defense: in Michigan, we always have a Wet October...)

I stretched standard Activity Diagram notation just a little in this diagram: when an Activity was the responsibility of two entities, I drew it straddling the boundary between their Swimlanes. That's a common stretch, but don't overuse it. A good rule of thumb is that each Activity or Branch should be assigned to one Swimlane.

And no, I have no idea how The UML Guy and The Reader talk with scuba mouthpieces in. It's a comic strip. These things happen.

Swimlanes give us a powerful tool to discuss who or what is responsible for each Activity. They're also the point where we stand on the requirements analysis shore and dip a toe -- just a toe -- into system architecture. We can start with an Activity Diagram that accurately describes the customer's business process; and then as we add Swimlanes and assign responsibilities to them, we slowly start to identify pieces of the system that we'll have to build. I start with business rules that make sense to the customer, and iteratively revise them into a hint of an architecture.

@curtisgray is going to kick me for this; but to demonstrate how we can move from requirements to architecture via Swimlanes, we need to abandon the funny for a moment and look at a more serious business system. We'll build on the example from panel 5. And to make it more legible (and easier for me to draw), I'm going to draw it with Enterprise Architect from Sparx Systems, a powerful UML tool at a great price.

We start with a simple description of business rules:

Figure 1: Payment Processing (Business Rules Version)

The Supervisor logs in, if authorized, and issues zero or more payments for outstanding payables. When the Supervisor is done, the system shows a summary of payments issued. We use an Object with Data Flow Dependences to represent the summary information as it's generated.

Now our requirements say that this is supposed to be a Web-based system. (You didn't read that memo? I know I sent it to you. Must be lost in the system. What was your email address again?) So let's add Swimlanes for the Supervisor and the Web pages:

Figure 2: Payment Processing (Initial Architectural Assignments)

In case it's not obvious, the Payment Page is a page that shows Supervisor the payment for final approval before payment. I could complicate the diagram by showing how Supervisor can approve or cancel the payment. But that way, madness lies! Trust me, Cancel is a hard problem to model, and to code correctly! At some later date, maybe we'll look at The Cancel Problem. For now, let's pretend Supervisor always approves selected payments.

Sometimes people ask me why I include Swimlanes for users. This diagram gives a pretty good answer to that question. The Branch in Figure 1 (Done or Process Another Payment) made sense in the context of the business rules: Process payments until we're done. But when we start thinking about architectural assignments, we have to ask for each Branch: What decides this? And what's the code for this decision? Well, in this case, only Supervisor can decide, and there's no code. Some Branches can be decided by program logic; but when a Branch can only be decided by user input, then I like to put that Branch in the user's Swimlane.

Note that Summary Results is in the Payment Summary Page Swimlane. That's really only for convenient layout right now. As we elaborate the assignments further, there may be a more proper place for it; but sometimes, there's just no convenient place to put an Object. In cases like that, I put the Object wherever it "fits" graphically, but as close as I can get to where it's used. Good layout isn't subject to hard and fast rules; it's a matter of esthetics, and there's no foolproof esthetics algorithm. (I also usually put Final States -- i.e., the "targets" that mark end points of the diagram -- wherever they happen to fit.)

I left some parts of the diagram outside of Swimlanes: two Activities (Authorize Log In and Make Electronic Payment) and one Branch (Authorized or Not Authorized). That's because my first pass was simply to identify user interface Swimlanes; and we all know that business rules and data access shouldn't be in the user interface, right? (Right? Right? Please tell me we all know that by now...) So let's add Swimlanes for the business processing:

Figure 3: Payment Processing (Architectural Assignments, Revision 1)

OK, all you who doubted me when I said I'd find the right place for Summary Results, raise your hand. Let's see... 1, 2, 3... For the record, I'm typing one-handed right now, because my hand is raised. I hoped I would find a place, but I wasn't sure. Now that I've thought about it, though, it makes sense that the Payment System should allow a log of the latest payments.

If The Reader isn't asleep by this point, he may have noticed that I slipped an extra Activity into this diagram, one that was never discussed in the original business rules version: Confirm Payment. As we discussed the implementation, I realized this was an implicit rule in Figure 1: Issue Payment implies Confirm Payment; but Issue Payment belongs in Payment System, while Confirm Payment is part of the UI. Those needed to be separated.

And in fact, this is a common occurrence as you turn business rules into an architectural plan: you discover implicit rules, and also missing rules. For instance, in order to List Payables, it's necessary to find the outstanding payables. Nobody mentioned that in the business rules, because it was so obvious, everyone assumed it. Yet a literal reading of Figure 3 says that the UI just magically "knows" what to list.

Another problem with Figure 3 is that Electronic Payment System -- which is a third-party service (what, you didn't get that memo, either?) -- appears directly in our evolving program logic. For that matter, why do Payment System and Security System appear in the direct path of the diagram? Shouldn't these just be services that our main program just calls?

If you can't tell, my answer's "Yes"; but this will require more radical restructuring of the diagram:

Figure 4: Payment Processing (Architectural Assignments, Revision 2)

Yes, I changed my mind: for layout reasons, I decided it was cleaner to move the Branch out of the Supervisor Swimlane and into the Payables List Page Swimlane. I just have to trust that no one expects the code to decide when we're done. (If there really were some confusion, I could add a note to the diagram.)

And suddenly, all of the "flow" logic is in the user interface elements, and all of the "do" logic is in the components and systems behind the UI. In fact, the four UI Swimlanes reflect the original business logic almost exactly. This is common as you evolve toward an architecture: you find that the UI elements -- the only elements the user can see, and the elements that they understand -- embody the business flow. (If you prefer a more UI-independent architecture, such as Model-View-Controller, you still find most of the business flow residing in one area: the Swimlanes that represent the Controller. But that's too complex for today's example.)

Note that the Transitions from the UI to the business Swimlanes are marked <<call>>. This is a UML stereotype. Stereotypes are too large of a topic for this Episode. For now, think of <<call>> as a tag that says, "Go ahead and follow this path; but when you're done, come back here and move on." Rather than create a whole new kind of arrow and have to remember what yet another arrow means, we put the <<call>> tag on the standard Transition arrow. Every programmer knows what a call is, after all, and we're moving into the Land of the Programmers.

Readers who know UML Sequence Diagrams -- or even just those who've read Episode 10 -- may be asking, "Isn't an Activity Diagram with Swimlanes a lot like a Sequence Diagram?" And my only answer is "Yes." In fact, it's easy to envision how we might turn The Hunt for Wet October into a Sequence Diagram, simply by drawing on top of the diagram we already have:

Now it would take more than that to make a good Sequence Diagram; but you can see the possibility, I hope.

So if the diagrams can show the same information, at least in theory, why should we pick Activity Diagrams with Swimlanes over Sequence Diagrams? Or vice versa?

There's no absolute answer. In fact, some UML practitioners dislike Swimlanes for exactly this reason: "We already have a notation for that. Two notations only confuse The Reader." And I'm sympathetic to that view. But I see some reasons for preferring Activity Diagrams with Swimlanes:

• Because these diagrams are essentially just flowcharts, most customers can read them without explanation. (On the other hand, I find business people learn to read Sequence Diagrams without too much effort.)
• Because an Activity Diagram with Swimlanes can be created from the original business rules diagram (as I demonstrated above), users may more easily understand how the one led to the other. (On the other hand, you can certainly draw exactly the same thing with a Sequence Diagram. It just won't be so visually obvious.)
• With a good UML tool, it's really easy to copy an Activity Diagram to the clipboard, paste it into another diagram, and start adding Swimlanes and rearranging. I have yet to find a UML tool that lets me go from an Activity Diagram to a Sequence Diagram so easily.
• It's easier to show conditional logic and looping in an Activity Diagram than in a Sequence Diagram. (UML 2.0 improves Sequence Diagrams in this regard significantly; but it's still easier with Activity Diagrams.)

And I see some reasons for preferring Sequence Diagrams:

• For simple cases, the Sequence Diagram notation is cleaner. This is just my esthetic judgement, of course, but I just find them more readable.
• A lot of developers are already comfortable with Sequence Diagrams, and less so with Swimlanes.
• Some good UML tools will let you create new Classes and methods of those Classes directly in the Sequence Diagram. I have yet to find a UML tool that supports Class definition in Activity Diagrams nearly as cleanly.
• Sequence Diagrams were the first UML diagram where I got the point: "So these things call these other things to do this work. Got it." Yes, this is a very personal reason to prefer them; but I find a lot of developers have the same reaction: Sequence Diagrams just make sense to them.

Which should you choose? That's up to you. My job is to show you techniques, not to tell you what techniques you "must" use. I lean heavily toward Swimlanes these days, but still decide on a case-by-case basis.

In our last Episode, The UML Guy showed how to organize Activities into larger Activities. Meanwhile, Old Guy absconded with The Reader's UML book and the time-traveling Gremlin...

(Click pictures for larger images.)

And following up on Mitch's suggestion, here's a joke-free version of that diagram:

And so we see the second film, or at least the finale of it. This was a great opportunity to show parallel behavior with Forks and Joins, illustrating three different timelines. (Actually, experts say there were eight, yes, eight separate timelines in the series. Scary obsessions some people have [says the guy who draws comic strips about software modeling].)

Editor Bill asked, "Question: Is there a notation to denote time/synchronization between events on parallel paths?" That was a truly profound question for someone who's not a programmer, because it's exactly the hard problem programmers face in parallel/multi-threaded programming. Parallel apps screw up or crash when one Thread changes data while another is using it. Parallel apps hang when Thread A waits for Thread B to do work, and Thread B can't do its work without action from Thread A. These are classic, well-studied problems in programming. We know the techniques for avoiding them. (I hope we know!) But the trick is in knowing when and where to apply them. When you're deep in the code, you can easily forget that you need them; but out here at the modeling level, we can more easily see where they're needed.

Many of these techniques involve putting synchronization and locking mechanisms into the system. It's naive (but common) to put synchs and locks in the code wherever you need the data. It's naive, because it's easy to forget, and also because you then have to change the synchs and locks in many places if your rules change. It's much smarter to put the synchs and locks in the data Objects themselves. That way, when any Thread asks for the data or changes the data, the Object enforces the rules uniformly.

And so this is one common use for data Objects in Activity Diagrams: to indicate synchronized data that's shared among Threads. I'm very impressed with Editor Bill for catching this. I was going to explain this in panel 7; but that would've been a full-page panel, and wouldn't have been very funny.

These diagrams also indicate a subtle new bit of notation. Notice how when Traveler appears, he's labeled "I : Traveler" and "II : Traveler". In the Episodes so far, I've simplified things by blurring the line between Class and Object. A Class is a category of things, and an Object is one thing from a category. As long as there's only one Object of a given Class in the discussion, that distinction isn't very important (for analysis, and often for design -- at code time, the distinction is so large that you can't possibly confuse them).

But in this diagram, there are two Travelers: I from Back... to the 80s!, and II from Back... to the 80s! Part II. So I needed to distinguish between two different Objects. (To anticipate upcoming questions: an Actor is really just a form of a Class. As we discussed in Episode 3, an Actor is a role someone or something can fill. So an Object [sometimes called an "Instance"] of an Actor is someone or something filling that role. In this case, we have two Instances of Traveler. (All you folks who want to argue that it's the same person in both cases, go argue with the multiverse/parallel timeline folks in the corner. We're talking UML here, not philosophy of time travel.) We need to distinguish between the two Instances. In UML, we can give both a name and a Class to an Object. We indicate that with the name and the class, separated by a colon. For brevity, I've called these instances I and II. So the full identities are I : Traveler and II : Traveler.

So once again, the Spacetime Continuum is saved! Hooray! But next, I'm afraid we have to get responsible. Ugh!