Practical UML, Part II – Sequence Diagrams

April 11, 2012 1 comment

This article is one of a series of posts on learning UML. To start from the beginning, see this introduction.

Okay, I have a confession to make. This post isn’t entirely about sequence diagrams. What we’re actually going to talk about in this post is interaction diagrams. A sequence diagram is one of a category of diagrams, and I’m going to show you two types in that category. I’ll tell you about the sequence diagram, which is the often the best choice to meet the need because it is intuitive. But I’ll also show you an alternative you might choose to use instead when standing at a whiteboard.

The Basics

In an interaction diagram, we’re trying to show how objects behave across time. Often, an interaction diagram shows how a use case is fulfilled by the system. The diagram shows which objects have control and how data flows from one to the other. The first time I saw a sequence diagram, I loved it. I didn’t need an explanation of what was happening, I just got it intuitively. That’s the mark of a good presentation technique, I think, that it requires very little explanation. As it happens, that’s also going to make this post very easy. Here’s an example of a sequence diagram:


Time runs from top to bottom. Objects are laid out from left to right, and each one has a swim lane. The bottom of the call stack is on the left. The arrows show the messages (i.e. method calls) on various objects. There is some more detailed notation you can use if you want to be strict, but usually, you don’t have to worry about it too much if you’re just trying to get your point across. Some things to note:

  • The bar in an object’s swim lane shows the duration of the method, the dotted line is the object’s lifetime. In the example above, some unnamed method in FloorPanel is blocked for the duration of the handling of the request. This indicates that the method call is synchronous. (Asynchronous calls are described below).
  • When an object is created, the object box is dropped down to that point to show that it didn’t exist prior. Also, the arrow goes directly into the box.
  • Arrows can go in either direction.
  • When calling a method on the same object, stack them and use a self-referencing arrow (see the Elevator.EnqueueRequest method).

Slightly advanced features

It won’t take long working with sequence diagrams before you run into some situations where you want to show something a little more complicated. Perhaps you want to show a sequence within the sequence that is conditional, or is a loop. No problem. Here is a sequence diagram that has both an asynchronous call and a callback, as well as conditional logic:


This should be fairly self-explanatory, but to be clear:

  • You can see from the short method duration block that FileWatcher.WatchPath returns immediately. This indicates an asynchronous message. Sometimes, the shape of the arrow is also an indication. The tool I’ve used here uses a stick arrowhead instead of a block. Whatever.
  • The WaitPath method finishes execution prior to the callback, as indicated by the end of the block. That’s as we would expect in the case where we are monitoring events.
  • The conditional sequence is indicated by the box with a description of the conditions under which the sequence occurs. Use a similar notation for loops, except you should use "loop" instead of "opt" in the box label.

Alternative – Communication diagram.

It shouldn’t take you long to get comfortable with sequence diagrams, and once you do, you’re going to notice a problem when sketching them on a whiteboard: they take up a lot of space (just look at all the whitespace in the swim lanes). Sometimes, this just isn’t practical, such as when you have a lot of objects in play. There’s another kind of diagram called the communication diagram that meets the same purpose. It’s not quite as intuitive, but it does convey the same information. Here’s the original Elevator scenario presented as a communication diagram instead of a sequence diagram:


Not as intuitive, but it does get the job done. Same methods, same classes, same parameters. Much of the notation is shared, but we don’t have the nice y-axis to show time. Instead, we use numbers to order the method calls. Each level of the stack keeps its caller’s number prefix, and sub-calls increment sub-parts. The sequence is indicated by the rank. So based on the diagram, here is the sequence of calls:

1. FloorPanel.unknownmethod -> CallRequest.Create
2. FloorPanel.unknownmethod -> ElevatorBank.HandleRequest
2.1 ElevatorBank.HandleRequest -> ElevatorBank.LocateBestElevator
2.1.1 ElevatorBank.LocateBestElevator -> CallRequest.GetDirection
2.1.2 ElevatorBank.LocateBestElevator -> CallRequest.GetFloor
2.2 ElevatorBank.HandleRequest -> Elevator.Dispatch
2.2.1 Elevator.Dispatch -> Elevator.EnqueueRequest

I hope you’ll find these diagrams useful. As always, please ask questions in the comments of this post so that I can answer for everyone’s benefit.

What’s Next

In my next post, I’ll be showing state diagrams. Once you get the hang of them, they are easy to use and useful when you want to think about and discuss how the states of objects change over time.

Categories: UML

Get Your Read On

March 27, 2012 Leave a comment

I love to read books. (My wonderful wife likes to tease me, calling them my “nerd books” which I consider a badge of honor). My passion for reading kicked into high gear about ten years ago when I decided I needed to school myself on .NET. I was feeling a little out of the loop, had a lot of time to spend on the train (I was commuting into Boston at the time) so I decided to get the MCSD certification for .NET. There was a series of (very thick) books that prepped you for the exams. They covered ASP.NET, general C# programming, security, framework internals and the like. I probably learned way more than I needed to for the exams but had a great time doing it. I looked forward to my daily study times at the beginning and end of every work day.

When the exams were behind me, I thought, “now what?” A colleague introduced me to Martin Fowler’s Patterns of Enterprise Architecture. That naturally lead to his Refactoring book, as well as the rest of his work. Somewhere during that time, I realized that I could use books that I liked to direct me to other interesting and useful books. The bibliography is a wonderful thing.

Since that time, I’ve read many books. I’ve discovered that I much prefer book learning to classroom or conference because I can move at my own pace (often faster, but not always). In this post, I’d like to share some of the more notable books I’ve read as part of my own professional development program. In each of these, I’ve found something useful to apply to my professional life. Some have been transformative, others only interesting with a few nuggets of usefulness. Perhaps they will be useful for you.


  • The Principles of Product Development Flow – This is a fascinating theoretical book that applies economic models to understand how to manage software delivery to maximize value. These are the same principles behind lean manufacturing, whose concepts are being applied by many to software delivery. Lean manufacturing and agile are cut from the same cloth, and derive from very similar philosophies.
  • Continuous Delivery – This book teaches concepts and practices for improving the reliability and throughput time of software delivery. Think of it as continuous integration concepts carried through the entire process of software delivery, concluding at deployment to the production environment. It is the winner of the 2011 Jolt Excellence Award, which recognizes the top software development book of the year. I’ve read it twice so far. This is an important book.
  • Refactoring: Improving the Design of Existing Code – I hate to pick favorites because there are so many good books on this list, but Refactoring is probably the most important book on programming I’ve read. Code issues are presented (“code smells”) along with practical recipes for resolving those issues. Furthermore, its principles can be extrapolated and applied in so many circumstances that it naturally leads to the concepts found in many other books.
  • Working Effectively With Legacy Code – The author presents this book as a continuation of Fowler’s Refactoring.It provides a lot of practical advice on how to work in code with very thorny problems (monster methods, copy and paste code, code that’s hard to test, etc.).
  • The Art of Unit Testing – This is the book to read to understand and learn unit testing. Highly recommended, and very practical. It didn’t teach me much about unit testing that I didn’t already know, but it was incredibly useful in understanding how to explain the principles to others. Of course, if you’re new to unit testing, it’s great!
  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) – Don’t be put off by the name, this book is more about learning the art of OOD. UML is used as an approach to sketching designs. Fowler describes this as the “best introduction to object-oriented design.”
  • Domain-Driven Design – Helps you design better by getting you to focus on the nature of the business first (the domain), then build outward from there as needed to integrate with technology.
  • Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture – excellent set of patterns for object oriented systems.
  • UML Distilled – brief book on using UML for sketching designs. It’s brief and to the point.
  • Design Patterns (Gang of Four) – many people have read this, for better or worse. If you’re a programmer, you need to read it just to understand the what the heck your colleagues are talking about when they throw these names around. But I agree with much of Yegge’s criticisms.
  • Core J2EE Patterns – It’s a Java book, but most of this book is applicable to .NET. There are some really useful patterns here, which are helpful just in surfacing the complexities of common problems.
  • Pragmatic Programmer – This is one of those books that had some useful nuggets but didn’t blow my doors off. This probably has more to do with my stage in my career rather than the quality of the book. It’s really intended more for people closer to the beginning of their programming career. One of the useful nuggets I took from this, however, is the importance of scripting skills for programmers. Since I’m currently in the .NET/Windows world, this lead naturally to…
  • Windows PowerShell in Action – If you’re going to get proficient in PowerShell (and if you’re a .NET programmer you ought to), this is the one to get. It’s written by Bruce Payette, a co-designer of the language. It works both reading front-to-back, as well as a reference manual.


  • The Toyota Way – Toyota pioneered lean manufacturing, and this is the book that explains how they do it. Even if you aren’t working closely with manufacturing concerns, it’s a very interesting approach to optimizing work which you may find useful in software development.
  • The Toyota Way Fieldbook – This book is a companion to The Toyota Way. It contains some of the same material, but presents it in a way that is more practical.

General Interest Books

  • Pragmatic Thinking & Learning – thought-provoking book on how people learn and master subjects, and techniques for innovation by allowing for non-directed thinking.
  • Here Comes Everybody – This book is a good diversion from technology subjects. It’s an easy read that talks about how recent technology impacts our world. It didn’t blow me away, but it’s entertaining.
  • Getting Things Done – If you care about work management and your personal efficiency, this is a really useful book. The author presents a system for managing your work and restoring sanity to your daily life. I practice these techniques and have found them incredibly useful.

Did I miss any? What books have you found interesting or useful?

Categories: Books

Practical UML, Part III –State Diagrams

March 20, 2012 Leave a comment

This article is one of a series of posts on learning UML. To start from the beginning, see this introduction.

State diagrams are useful when you want to model (or think about or express) how the state of something changes based on events. Usually, you would use them to model the state of a single object. However, even if your design doesn’t have a single object managing a state (to be clear, it should), you can still use this technique. (Of course, after doing so, you’ll probably feel that some object should be responsible for managing it in order to ensure only valid transitions are allowed.)

Let’s have a look at an example, which models the state of a telephone:


The notation is pretty straightforward:

  • Each box is a state
  • The edges (or lines) are transitions from one state to another. Each is labeled with the event that causes the transition in the direction of the arrow.
  • Optionally, the event can have a condition (called guards) in brackets. This means that the transition occurs only if the event occurs and the condition is true. In this way, you can have the same event represented multiple times, such as the digit event on the Dialing state.
  • The large bounding box is called a superstate and is used to represent hierarchies of states.
  • The closed circle represents the starting point.
  • The circle with a dot inside represents termination.

The next time you’re struggling with understanding how a state changes over time (which can be a particular challenge when no single object has the responsibility), consider using a state diagram to provide clarity to the problem.

This is my last post on UML for a while. Hopefully, this has been useful and shown you some ways you can better communicate about system behavior and design. There are other diagrams that are useful (activity diagrams for modeling processes, deployment diagrams for modeling components deployed to systems), but I’ll leave those for you to discover on your own. I’ve mentioned it in prior posts, but if you’re interested in a short reference guide to these diagrams, I highly recommend UML Distilled. It’s 170 pages of UML goodness.

Categories: UML Tags:

Practical UML, Part I – Class Diagrams

March 4, 2012 1 comment

This article is one of a series of posts on learning UML. To start from the beginning, see this introduction.

UML includes specifications for multiple diagram types. These diagram types suit all kinds of needs. In this post, I’m going to be talking about the one that people are the most familiar with, the class diagram. A class diagram is a static diagram, meaning that there is no element of time or changing state. It shows classes — well, all types really — what they’re comprised of, and how they relate to each other. It’s important to note that UML diagrams are technology-agnostic. Although you may be able to pick up hints that the creator was thinking in one language or another, based on how things are named, generally a design can be implemented in any object-oriented language


In a class diagram, every type (class, interface, enum, struct) is represented as a box. The name goes at the top (or center if that’s all that’s in the box). So, if you wanted to represent this class in a class diagram:

public class Foo { }

It would look like this:

Are you still with me? Not too complicated, right? It seems trivial, but sometimes you’re only interested in showing classes and their relationships. And that’s fine. Other times, you want to show what the members of a class are, so extending our example:

public class Foo
	public int Id { get; set; }
	public string ToString() { //code here }
	public int Bar(string baz) { // code here }

In UML, classes have attributes and methods. In the region below the class name come the attributes (fields or properties for C-sharpies). In the bottom region come the methods. In both cases, the name of the member comes first, then a colon, then the type. In the case of a method, the trailing type is the method’s return type.

Sometimes, when it suits our purposes, we omit one or the other. For example, the name of the parameter to the Bar method is not particularly interesting, so you might do this:


Interfaces look exactly like classes, except they have what’s called a stereotype above the name. A stereotype is a category of types. If we had an interface iFoo:

public interface IFoo
	int Id { get; set; }
	string ToString();
	int Bar (string baz);

Here’s how we’d show that in UML:

This is exactly the same as a class, the only difference is the interface stereotype at the top.

Class-Level Relationships


The most common relationship — the one every OO programmer wants to show right off the bat, usually — is inheritance. Let’s get that one out of the way. Inheritance is shown as a solid line between two types. At the base class end is a block arrow. For example:

public class Fruit { }
public class Apple : Fruit {}

Would be shown as:

Note that the arrow is a block arrow. This is important. If you use a normal stick arrow, it just means dependency (see below), which is less specific than inheritance.

Interface Implementation

When implementing an interface, we show that a little bit differently than inheritance. If we have:

public interface IFruit { }

public class Fruit : IFruit { }

We show that relationship still with the block arrow, but with a dashed line:

I have to admit, this one is probably not a big deal. It’s really just a reminder that you’re not inheriting any implementation, which is already implied by the stereotype. But if you see it, that’s what it means.

Instance-Level Relationships

It is often useful to show relationships between instances of different types.


The association notation is very loose, and indicates objects of one type referencing objects of another type. The notation is so loose that it’s not clear which type references which. For this reason, I don’t use it, but you may find an application for it:


Aggregation is one way of showing that one class has (“has-a”) one or more objects of another type. Essentially, it shows a reference from one class to another. If we have a class Car with a collection of Wheel objects, we would show it this way:

The end with the diamond has the reference to the other.

Note: This notation is no more or less valid than showing the reference in the Car class attributes section. They convey the same idea:


In the example above, the fact that the diamond is closed means the Car instance “owns” the Wheel instances. They are not shared with other objects. This is a strong kind of aggregation called composition. A looser kind of aggregation would show an open diamond, which means there is a reference to the other class, but ownership is not indicated. For example:

A Course has Student objects, but other Course instances may share references to the same Student objects.


Cardinality is a fancy word that just means how many of each type at each end? Each end of an association can have a number or a range next to it to indicate how many of each object we expect. Here are some examples:

  • 0..1 : zero or one instances
  • 1 : one, and only one
  • 0..*: zero, or many (no limit)
  • *: many (no limit)
  • 1..4: at least one, but no more than four

You can put cardinality on either end, both, or neither. Here it is in action:

Because Car is composed of Wheel instances, there is only one Car instance in the relationship. We could put a one at the other end, but it would be superfluous.

Named Relationships

If you want, you can put a label on the relationship, which indicates the member of the referencing class that is the reference to objects of another class.

General Relationships


The final type of relationship I’m going to discuss is dependency, and it’s one of the most important ones. The dependency relationship is an ambiguous one. It doesn’t really explain what the nature of the relationship is, just that one type depends on another. From a design standpoint, it means that changes to the target class can impact the referring class because it has awareness of it. Dependencies can result for a variety of reasons, including inheritance, aggregation, composition, having parameters of the type, or even using an instance in one of its methods. Basically, if a type refers to the target type in any way, a dependency is created. Dependency notation is not limited to classes. It can be used to describe relationships between classes, interfaces, packages (assemblies), or anything else.

TIP: Understanding dependencies of your system is crucial to good design. Loose coupling, that holy grail of design, is defined by having as few dependencies between classes as possible.

A dependency is indicated in UML through a simple arrow from one type to another, the line can be solid or dashed, it doesn’t really matter:

This tells us that ApplePeeler uses the Apple class in some way. It has a dependency on Apple (although we are left to guess as to what the nature of the dependency is, since the ApplePeeler as shown in the diagram doesn’t specify its members).

For more discussion of class diagrams, there is a fairly good Wikipedia article on the subject.

What’s Next

In my next article, we’ll leave the static world of class diagrams to examine sequence diagrams, which allow us to describe how objects interact with each other through time. Stay tuned!

Categories: UML Tags:

Practical UML – Introduction

February 28, 2012 4 comments

UML – as many of us probably know – stands for Unified Modeling Language. UML is a notation used to describe object oriented systems (although it may also be used in other ways). It’s one of those things that started out as a good idea, but got taken to a logical extreme, at which point it became absurd. Most people who are not very familiar with UML (or worse, learned it in school) think it’s pretty pointless. And at the extreme, it absolutely is. But taken back at its original idea, it’s a really handy notation for sharing ideas.

What Went Wrong

I will rule the tri-state area!You can read the entire history of UML if you like, but let me put it in a nutshell: it’s a notation used to describe object-oriented systems. That’s the initial good idea. The proponents of UML loved it so much that they felt if they were able to develop the “language” enough, they could describe any system desired, and that UML would take the place of writing code. The promise was that you could create models that were so detailed that they could be used to generate code. Tools were written to generate code from UML (and vice versa). This really was seen as a kind of silver bullet to programming. The language became hopelessly complex, and frankly, silly. No one could remember all the notation, and many people felt (rightfully, in my opinion) that the programming language was a better way to specify such things.

Stepping Back

Oh, there you are, Perry.I’m a big believer in UML: not as a programming language, but as a way of sharing ideas. The point is to use the features of UML that are useful in conveying ideas and conducting design sessions. In fact, there is a fantastic book that teaches object-oriented programming called Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. This is one of the best books out there for learning OOD, but the author also makes great use of the practice of using UML. He says there are three ways to use UML:

  • UML as programming language
  • UML as documentation
  • UML as sketch

It is this third way that he advocates, and which I argue you will find useful.

UML As Sketch

When using the UML as sketch approach, pretty much anything goes. Diagrams are not meant to be interpreted as complete, but rather to convey an idea. This means — to me, anyway — that you can include or not include any UML feature you want. But if you want people to understand the information you’re presenting, it’s probably a good idea not to include a visual element incorrectly. For example, you can have boxes with lines between them. Things like cardinality (numbers at one end or the other), arrows, or diamonds are optional. Do what is useful to you in the message you’re trying to convey. But if you put an arrow on a line, use the right one. Don’t use a block arrow (used to indicate inheritance, class B inherits from class A) when you want to indicate dependency (class B knows about/uses class A).

What’s Next

Hopefully, some readers remain at this point, and I’ve convinced you that UML is worth spending a few minutes to learn. In upcoming posts, I will present aspects of UML you will find useful in your sketches. The intent is not to provide exhaustive explanation, but rather to show the general idea of various aspects. Fore a more complete reference, there is a very short book on the subject that should answer all your questions. My personal copy is located in the FD Software Engineering library in Lexington.

Stay tuned for your crash course in UML! First up are class diagrams.

Categories: UML Tags:

Tech Blog Discovery

October 1, 2010 Leave a comment

Today, I stumbled upon Fabulous Adventures in Coding, an excellent technical blog written by Microsoft technologist Eric Lippert. (Although considering the bizarre behavior of the blogs at MSDN, its not all that surprising. Access a blog one way and they require you to create and account? Wha?)

Many of his posts are related to the internals of .NET, and several caught my eye. I haven’t had a chance to read them yet, but they’re going on my “to do” list:

Of course, if I’d been paying closer attention to Jeff Atwood, I would already know about Eric Lippert.

Categories: Uncategorized

A Non-Techie Windows User Talks Microsoft Tablet, Testifies on the iPad Experience

September 15, 2010 Leave a comment
Microsoft PDC 2008 @ LA Convention Center, LA



Prolific blogger Mary Jo Foley, who writes the essential “All About Microsoft” blog, reports on the potential future of Microsoft Surface, the multi-touch display technology Microsoft introduced several years ago. Specifically, she discusses how it might be adapted to a tablet device:


Microsoft user interface researcher Bill Buxton told the Globe and Mail that he expects Microsoft to be offering three years from now a tablet device that will be like a slimmed-down mini Surface.

That sounds all well and good… except for the three years part.

Har har. She then goes on to describe her own (favorable) experience with the iPad.

I’ve used and continue to use my 16 GB iPad with 3G and wifi a lot. (In spite of AT&T’s overly pricey 3G data plans, I’m glad I got one with both, as wifi hotspots are still few and far between in many places.)I toss it into my purse when I am going out for a few hours and don’t want to pack up my laptop and lug it with me. I use it to surf the Web, check my mail, read books using the Kindle app, keep up with Twitter (via the Osfoora Twitter client, which I still like a lot more than Twitter’s own iPad client or other alternatives).

Not exactly a money quote, but read the whole thing if you’re considering taking the iPad plunge and want the Windows perspective.

Categories: Uncategorized

Get every new post delivered to your Inbox.