The pros and cons of use case diagrams

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?

• Actors: An actor represents a role external to a system that uses or is used by a system. Actors can be shown as boxes marked with an «actor» stereotype or a stick figure. From a stylistic point of view, stick figures are best reserved for human roles. (In spite of technological advances and Hollywood, it looks a little strange to see devices or software systems presented in human form. As an aside, the term actor is somewhat misleading, as we normally think of an actor as someone who plays a role, not as the role itself. To sidestep such confusion an increasing number of practitioners favor the term user role.
• System boundary: A boundary that separates actors -- which are external to the software system -- from use cases -- which represent goals fulfilled by the system -- makes clear the separation between the software system of interest and the world around the system. It also acts as a reminder that the behavior of the use cases in question is system behavior and not the broader and sometimes less-deterministic and less-biddable behavior of the world around the system that might lead to or be inspired by the use cases. The system box is sometimes treated as an optional presentation feature. Omission makes sense if use cases are used to model a business rather than a software system, but otherwise absence does not make the chart grow sounder.

It is common to find use case diagrams with extra ad hoc ornamentation. Although well meant, such extras are invariably confusing rather than helpful. ,

• Use cases: Use cases, shown as named ellipses, live within the system. Use cases represent the functional behavior of the system in terms of goals that can be fulfilled by the system. Use case diagrams do not define the content of their use cases; they simply show their names and relationships. For defining use cases, practitioners are advised to turn to concise and focused textual descriptions.
• Associations between use cases and actors: Actors do not simply sit around resting, and a system's use cases are not orphaned islands of functionality. Associations connect primary actors with the use cases that represent the goals they can have against a system, and they connect secondary actors with the use cases that use them to fulfill goals.
• Relationships between use cases: It is possible for use cases to include, extend or generalize other use cases. In theory the idea that use cases can interrelate, much as classes on a class diagram do, makes sense. The problem is that in practice this aspect of use case diagrams is not only less than useful, it is typically harmful.
  
  Not only do use case relationships obscure a diagram, disenfranchising all but the UML geeks, but they tend to distract practitioners from the objective of identifying and understanding the system's behavior. Use case diagrams that make use of such relationships often end up degenerating into an ineffective top–down programming model of the system. They are rarely backed up by clear use case descriptions.

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