In this chapter
Use case diagrams are one of the diagrams in the UML for modeling the dynamic aspects of systems. (Activity diagrams, state diagrams, sequence diagrams, and communication diagrams are four other kinds of diagrams in the UML for modeling the dynamic aspects of systems.) Use case diagrams are central to modeling the behavior of a system, a subsystem, or a class. Each one shows a set of use cases and actors and their relationships.
You apply use case diagrams to model the use case view of a system. For the most part, this involves modeling the context of a system, subsystem, or class, or modeling the requirements of the behavior of these elements.
Use case diagrams are important for visualizing, specifying, and documenting the behavior of an element. They make systems, subsystems, and classes approachable and understandable by presenting an outside view of how those elements may be used in context. Use case diagrams are also important for testing executable systems through forward engineering and for comprehending executable systems through reverse engineering.
Suppose someone hands you a box. On one side of that box, there are some buttons and a small LCD panel. Other than that, the box is nondescript; you aren't even given a hint about how to use it. You could randomly punch buttons and see what happens, but you'd be hard pressed to figure out what that box does or how to use it properly unless you spent a lot of trial-and-error time.
Software-intensive systems can be like that. If you are a user, you might be handed an application and told to use it. If the application follows normal conventions of the operating system you are used to, you might be able to get it to do something useful after a fashion, but you'd never come to understand its more complex and subtle behavior that way. Similarly, if you are a developer, you might be handed a legacy application or a set of components and told to use them. You'd be hard pressed to know how to use the elements until you formed a conceptual model for their use.
With the UML, you apply use case diagrams to visualize the behavior of a system, subsystem, or class so that users can comprehend how to use that element, and so that developers can implement that element. As Figure 18-1 shows, you can provide a use case diagram to model the behavior of that box—which most people would call a cellular phone.
A use case diagram is a diagram that shows a set of use cases and actors and their relationships.
A use case diagram is just a special kind of diagram and shares the same common properties as do all other diagrams—a name and graphical contents that are a projection into a model. What distinguishes a use case diagram from all other kinds of diagrams is its particular content.
Use case diagrams commonly contain
Like all other diagrams, use case diagrams may contain notes and constraints.
Use case diagrams may also contain packages, which are used to group elements of your model into larger chunks. Occasionally, you'll want to place instances of use cases in your diagrams as well, especially when you want to visualize a specific executing system.
The subject is shown as a rectangle containing a set of use case ellipses. The name of the subject is placed within the rectangle. The actors are shown as stick figures placed outside the rectangle; their names are placed under them. Lines connect actor icons to the use case ellipses with which they communicate. Relationships among use cases (such as extend and include) are drawn inside the rectangle.
You apply use case diagrams to model the use case view of a subject, such as a system. This view primarily models the external behavior of a subject—the outwardly visible services that the subject provides in the context of its environment.
When you model the use case view of a subject, you'll typically apply use case diagrams in one of two ways.
Modeling the context of a subject involves drawing a line around the whole system and asserting which actors lie outside the subject and interact with it. Here, you'll apply use case diagrams to specify the actors and the meaning of their roles.
Modeling the requirements of a subject involves specifying what that subject should do (from a point of view of outside the subject) independent of how that subject should do it. Here, you'll apply use case diagrams to specify the desired behavior of the subject. In this manner, a use case diagram lets you view the whole subject as a black box; you can see what's outside the subject and you can see how that subject reacts to the things outside, but you can't see how that subject works on the inside.
Given a system-any system-some things will live inside the system, some things will live outside it. For example, in a credit card validation system, you'll find such things as accounts, transactions, and fraud detection agents inside the system. Similarly, you'll find such things as credit card customers and retail institutions outside the system. The things that live inside the system are responsible for carrying out the behavior that those on the outside expect the system to provide. All those things on the outside that interact with the system constitute the system's context. This context defines the environment in which that system lives.
In the UML, you can model the context of a system with a use case diagram, emphasizing the actors that surround the system. Deciding what to include as an actor is important because in doing so you specify a class of things that interact with the system. Deciding what not to include as an actor is equally, if not more, important because that constrains the system's environment to include only those actors that are necessary in the life of the system.
To model the context of a system,
Identify the boundaries of the system by deciding which behaviors are part of it and which are performed by external entities. This defines the subject.
Identify the actors that surround the system by considering which groups require help from the system to perform their tasks, which groups are needed to execute the system's functions, which groups interact with external hardware or other software systems, and which groups perform secondary functions for administration and maintenance.
Organize actors that are similar to one another in a generalization-specialization hierarchy.
Where it aids understandability, provide a stereotype for each such actor.
Populate a use case diagram with these actors and specify the paths of communication from each actor to the system's use cases.
For example, Figure 18-2 shows the context of a credit card validation system, with an emphasis on the actors that surround the system. You'll find Customers, of which there are two kinds (Individual customer and Corporate customer). These actors are the roles that humans play when interacting with the system. In this context, there are also actors that represent other institutions, such as Retail institution (with which a Customer performs a card transaction to buy an item or a service) and Sponsoring financial institution (which serves as the clearinghouse for the credit card account). In the real world, these latter two actors are likely software-intensive systems themselves.
This same technique applies to modeling the context of a subsystem. A system at one level of abstraction is often a subsystem of a larger system at a higher level of abstraction. Modeling the context of a subsystem is therefore useful when you are building systems of interconnected systems.
A requirement is a design feature, property, or behavior of a system. When you state a system's requirements, you are asserting a contract, established between those things that lie outside the system and the system itself, which declares what you expect that system to do. For the most part, you don't care how the system does it, you just care that it does it. A well-behaved system will carry out all its requirements faithfully, predictably, and reliably. When you build a system, it's important to start with agreement about what that system should do, although you will certainly evolve your understanding of those requirements as you iteratively and incrementally implement the system. Similarly, when you are handed a system to use, knowing how it behaves is essential to using it properly.
Requirements can be expressed in various forms, from unstructured text to expressions in a formal language, and everything in between. Most, if not all, of a system's functional requirements can be expressed as use cases, and the UML's use case diagrams are essential for managing these requirements.
To model the requirements of a system,
Establish the context of the system by identifying the actors that surround it.
For each actor, consider the behavior that each expects or requires the system to provide.
Name these common behaviors as use cases.
Factor common behavior into new use cases that are used by others; factor variant behavior into new use cases that extend more main line flows.
Model these use cases, actors, and their relationships in a use case diagram.
Adorn these use cases with notes or constraints that assert nonfunctional requirements; you may have to attach some of these to the whole system.
Figure 18-3 expands on the previous use case diagram. Although it elides the relationships among the actors and the use cases, it adds additional use cases that are somewhat invisible to the average customer yet are essential behaviors of the system. This diagram is valuable because it offers a common starting place for end users, domain experts, and developers to visualize, specify, construct, and document their decisions about the functional requirements of this system. For example, Detect card fraud is a behavior important to both the Retail institution and the Sponsoring financial institution. Similarly, Report on account status is another behavior required of the system by the various institutions in its context.
The requirement modeled by the use case Manage network outage is a bit different from all the others because it represents a secondary behavior of the system necessary for its reliable and continuous operation.
Once the structure of the use case is determined, you must describe the behavior of each use case. Usually you should write one or more sequence diagrams for each mainline case. Then you should write sequence diagrams for variant cases. Finally, you should write at least one sequence diagram to illustrate each kind of error or exception condition; error handling is part of the use case and should be planned along with the normal behavior.
This same technique applies to modeling the requirements of a subsystem.
Most of the UML's other diagrams, including class, component, and state diagrams, are clear candidates for forward and reverse engineering because each has an analog in the executable system. Use case diagrams are a bit different in that they reflect rather than specify the implementation of a system, subsystem, or class. Use cases describe how an element behaves, not how that behavior is implemented, so it cannot be directly forward or reverse engineered.
Forward engineering is the process of transforming a model into code through a mapping to an implementation language. A use case diagram can be forward engineered to form tests for the element to which it applies. Each use case in a use case diagram specifies a flow of events (and variants of those flows), and these flows specify how the element is expected to behave-that's something worthy of testing. A well-structured use case will even specify pre- and postconditions that can be used to define a test's initial state and its success criteria. For each use case in a use case diagram, you can create a test case that you can run every time you release a new version of that element, thereby confirming that it works as required before other elements rely on it.
To forward engineer a use case diagram,
Identify the objects that interact with the system. Try to identify the various roles that each external object may play.
Make up an actor to represent each distinct interaction role.
For each use case in the diagram, identify its flow of events and its exceptional flow of events.
Depending on how deeply you choose to test, generate a test script for each flow, using the flow's preconditions as the test's initial state and its postconditions as its success criteria.
As necessary, generate test scaffolding to represent each actor that interacts with the use case. Actors that push information to the element or are acted on by the element may either be simulated or substituted by its real-world equivalent.
Use tools to run these tests each time you release the element to which the use case diagram applies.
Reverse engineering is the process of transforming code into a model through a mapping from a specific implementation language. To automatically reverse engineer a use case diagram is currently beyond the state of the art, simply because there is a loss of information when moving from a specification of how an element behaves to how it is implemented. However, you can study an existing system and discern its intended behavior by hand, which you can then put in the form of a use case diagram. Indeed, this is pretty much what you have to do anytime you are handed an undocumented body of software. The UML's use case diagrams simply give you a standard and expressive language in which to state what you discover.
To reverse engineer a use case diagram,
Identify each actor that interacts with the system.
For each actor, consider the manner in which that actor interacts with the system, changes the state of the system or its environment, or responds to some event.
Trace the flow of events in the executable system relative to each actor. Start with primary flows and only later consider alternative paths.
Cluster related flows by declaring a corresponding use case. Consider modeling variants using extend relationships, and consider modeling common flows by applying include relationships.
Render these actors and use cases in a use case diagram, and establish their relationships.
When you create use case diagrams in the UML, remember that every use case diagram is just a graphical presentation of the static use case view of a system. This means that no single use case diagram need capture everything about a system's use case view. Collectively, all the use case diagrams of a system represent the system's complete static use case view; individually, each represents just one aspect.
A well-structured use case diagram
Is focused on communicating one aspect of a system's static use case view.
Contains only those use cases and actors that are essential to understanding that aspect.
Provides detail consistent with its level of abstraction; you should expose only those adornments (such as extension points) that are essential to understanding.
Is not so minimalist as to misinform the reader about semantics that are important.
When you draw a use case diagram,
Give it a name that communicates its purpose.
Lay out its elements to minimize lines that cross.
Organize its elements spatially so that behaviors and roles that are semantically close are laid out physically close.
Use notes and color as visual cues to draw attention to important features of your diagram.
Try not to show too many kinds of relationships. In general, if you have complicated include and extend relationships, take these elements to another diagram.