Software Quality.com

The pros and cons of use case diagrams

By Kevlin Henney

Kevlin Henney, consultant, software architecture, development process
Kevlin Henney

In the Unified Modeling Language (UML), use cases are visually represented as ellipses. However, in spite of its popularity and size, UML has little of practical use to offer modelers beyond this simple iconic representation. Trying to capture and present requirements using just use case diagrams can often render the otherwise useful technique of use cases almost useless.

Practitioners are often drawn to expressing their intent by overworking the limited use case diagram notation, losing readers in a myriad of bubbles muddled together with obscure relationships and microscopic text. This article takes a step back to examine the pitfalls and recommend a more balanced and restrained approach.

What use cases diagrams show
What makes up a UML use case diagram?

There are a couple of other elements that sometimes find their way onto use case diagrams, such as packages, but the ones just listed are the core ingredients that, depending on use, can clarify or obscure the message of a diagram.

The notion that a diagram has a message is perhaps the question we should be asking. Having answered what a use case diagram can show from a technical point of view, we really need to ask what we want or need it to show from an intentional point of view. Unless we have a clear purpose for a diagram, the diagram is likely to end up a confused and aimless exhibition of notation.

What use case diagrams do not show
Use case diagrams do not present architectural models, user-interface models or workflow models. However, this does not appear to stop them from being press-ganged into these roles. It is common to find use case diagrams with extra ad hoc ornamentation. Although well meant, such extras are invariably confusing rather than helpful.

There are better approaches suited to each of these tasks. For architectural models, there are many ways to present and describe architecture, and many viewpoints from which to do so. For user-interface models, UI design is a discipline and activity that is not well addressed by UML, and even less so by use case diagrams. For workflow models, activity diagrams offer a clearer way of organizing flow by considering use cases as activities.

What a use case diagram is good at showing is the system context and a summary of the functional goals fulfilled by the system. In other words, use case diagrams offer a rich "table of contents" but are not themselves the content. They do not illustrate the structure of the software or its required behavior, which is why they are an iconic rather than a schematic concept.

More information on use cases
Patterns for Effective Use Cases -- Chapter 1, What Is a Quality Use Case?

How to document use cases

Use cases, scenarios and user goals

By contrast, a class diagram can illustrate a system's information model or some aspect of design, a textual use case description describes a slice of system behavior, and a state-machine diagram can illustrate an object's lifecycle. All of those are schematic in the sense that something can be built from them and they offer concrete and testable assertions about a system, either from an external or an internal point of view.

The notion that a use case diagram acts like a table of contents, a summary, is one that suggests that use case diagrams are not the only way to present an overview of actors and their goals. A tabular presentation can be just as effective, with actors in one column and their corresponding goals (i.e. use cases) in an adjacent column. Use case diagrams offer a more visual presentation for sketching on whiteboards, but sometimes a tabular presentation is easier to both read and write in word-processed documents and on Wiki pages.

Overwhelmed by use cases
In addition to subtle or obfuscating use of use case relationships, distraction from actually focusing on the use cases, and ad hoc extension of use case diagrams to fulfill more than their simple remit, the main failure mode of use case diagrams is sheer information overload.

How many use cases does a system have? And how many can you reasonably show on a use case diagram? Many of the examples in books and on training courses do not reflect the situation encountered on realistic projects. A handful of use cases -- five, 10, or even 15 -- will fit easily onto a single page, but shoehorning tens or even hundreds of use cases onto a single page is at best a pyrrhic victory. As a demographic group, those involved with software development already form a large market for sight correction. Small print scattered across a sea of lines and bubbles does nothing to improve the situation. These kinds of diagrams are better left undrawn, with the time better used in adding value to the software under development.

However, it is not the books and courses that are at fault, just the method of scaling. You have to look at the problem slightly differently: The challenge is not how to fit many use cases onto a single diagram, but how to ensure that a single diagram contains only a few use cases.

One approach is to focus on abstract or high-level use cases. In the sense that their descriptions tend to be sketchy and do not boil down to testable propositions, these are not really the same kind of use cases as the ones we focused on in the previous article. Such abstract use cases normally allude to more concrete use cases. For example, Manage Accounts might contain the more specific use cases Open Account, Close Account, Suspend Account, and Modify Account, which each share a theme but have quantifiably distinct goals and outcomes.

Another approach takes the idea of themes and containment in a different direction. There is no rule that says that a system should have only a single use case diagram, just an expectation. (The use of the singular use case rather than the plural use cases helps to feed this expectation.) Instead of a single use case diagram packed with unreadable detail, break out multiple use case diagrams, each at a manageable level of detail. Each diagram is based either on the principal actor for a set of use cases or on a common category that a set of use cases fit into, such as Account Management. Some practitioners use packages to show this kind of organization, but this is not strictly necessary and makes the use of notation more technical necessary.

In all this it is important to remember that the principal value of use cases lies in their individual descriptions. Use case diagrams, tables and any other technique employed to provide a big-picture overview can complement this detail, but they are not a substitute for it.

-----------------------------------------
About the author: Kevlin Henney is an independent consultant and trainer based in the UK. His work focuses on software architecture, patterns, development process and programming languages. He is a coauthor of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two recent volumes in the Pattern-Oriented Software Architecture series. You may contact him at [email protected].

24 Sep 2007

All Rights Reserved, Copyright 2006 - 2024, TechTarget | Read our Privacy Statement