Use case series: UML 2.0 use case diagrams

The UML way to organize and manage use cases.

Pros

• Provides a high level view of the use cases in a system, solution, or application.
• Clearly shows which actors perform which use cases, and how use cases combine to form business processes

Cons

• Presents an “inside-out” view of the sytem. This description reflects “what it is” not “why it is” – and it is easy to lose sight of why a particular use case is important.
• Poor communication tool when speaking to users and stakeholders about why and when the system will do what it will do.
• Time consuming to create and maintain

Instead of duplicating the explanation and summary work already done by Chris at grillcheese.blogspot.com, I’ll point you to his post, Introduction to UML-2 use case diagrams. Agile modeling has a detailed post on UML-2 use case diagrams.
There are ultimately four pieces of information you want to know about use cases. UML diagrams will show you two of them.

1. Which actors perform a particular use case? UML diagrams show this.
2. Which use cases are combined to create a business process? UML diagrams show this.
3. When is a use case scheduled for availability? UML diagrams do not show this.
4. Why are we doing a particular use case? UML diagrams do not show this.

Knowing that we can’t answer all 4 questions with a single communication tool, here’s what we should do:
(1&3) Create a matrix view of use cases versus actors to show which actors perform each use case, and when they will be available.

(2) Create a UML 2.0 use case diagram if you find that the benefits for your communication outweigh the costs of maintaining the diagrams. In projects I’ve worked on in the past, a simple flow chart with use case names have been used. These simple charts can be made in a fraction of the time, are more easily scannable, and present information more densely. If you are managing requirements with a tool that automatically generates the diagrams, then do it – but don’t spend a lot of time on them. A flowchart takes almost no time to draw, and communicates the information just as effectively (and more succinctly). Suggestion – use the flow chart.
(4) Ultimately, UML diagrams (often referred to as “use case cartoons”) focus your attention on what you are building, at the expense of losing focus on why you are building it. Create a mapping or maintain links (traceability) from use cases to goals.

The why of the use case is the most important information. Don’t let use case cartoons distract you from it.

Poll: Which use case format do you use?

If you answered ‘Other’ please comment and let us know what you use!
Quick links to posts in this series

• Use case series: Introduction
• Use case series: Formal use case
• Use case series: Informal use case
• Use case series: UML 2.0 use case diagrams