Use case diagrams capture a broad view of the primary functionality of the system in a manner easily grasped by nontechnical users. The use case diagrams can become a centralized roadmap of the system usage scenarios for people specifying the requirements of the system. Uses cases themselves can be decomposed into other uses cases and ultimately into scenarios that show detailed sequences of object interaction. Because they are at a high conceptual level and use the problem domain vocabulary, many people find the use case diagram the single most important tool for communicating with the users. The use case diagram can feed into a more rigorous textual specification and assist the process of requirements definition. The use case diagram allows this to occur in a collaborative fashion since all participants can understand the notation and semantics.
Scenarios are instances of a use case, just as objects are instances of classes. In this way, use case diagrams are like class diagrams -- they show the logical static structure of scenarios. Scenarios may define elaborate protocols consisting of many messages sent in particular sequences. Scenarios are more elaborate than single messages and rely on many external object interactions to achieve the required system function points. Scenarios are a powerful means for communicating detailed requirements because implementation and computer science concerns are effectively abstracted away. The scenarios can be directly associated with a number of detailed requirements so that their characteristics and implications are clear.
The relationship between use case and protocols is shown in Figure 8 below. The use case uses the protocols (and its contained event and data flows) to fulfill the system responsibilities. The event and data flows must be sufficiently rich to support the required uses of the system.
The top-level use case diagram is another view of the system context. It provides an overview of the system, not of classes and objects, but of function points. A function point is a broad scope area of functionality of the system and is isomorphic to a use case. Note that external objects may participate in some use cases but not others.
Figure 8 shows the system boundary as a rectangle with the external objects outside the system. These external objects connect to use cases within the system via protocols. Additionally, some use cases depend on others -- this is shown with a dashed arrowed line connecting the use cases.
Use cases are generic transactions typically involving potentially many external objects and many messages. Use cases are important because they provide a valuable tool for capturing system requirements. Figure 9, below, shows the context diagram for an ECG monitor. For simplicity, many normal functions of an ECG monitor have been omitted, such as monitoring blood oxygen saturation (SpO2) and invasive and non-invasive blood pressure. Five external objects are identified. The most important of these are clearly the patient (the primary data source) and the physician (the primary recipient of processed data and events). The other external objects of interest in this example are a remote display for the surgeon, a chart recorder for producing hardcopy recordings of waveforms, and the service representative who maintains the equipment. Message stereotypes are shown using both standard stereotype and iconic notations.
What are some ECG monitor use cases? Some candidates are:
Figure 10: ECG Monitor Use Case Diagram
A little thought shows that these use cases are not merely simple data flows. Consider "Display waveforms" use case. This involves the physician
Updating the software is another example. Many scenarios are possible:
There are a couple of relationships defined within the UML among use cases. The first is the «extends» relationship, which is a stereotyped generalization in which both the parent and the child must be use cases. The second is the «uses» relationship, a stereotyped form of dependency in which one use case depends on the functionality provided by another. The "Autoconfigure" use case is an example of the former in which the child use case is specialized from the "Configure Remote Display". The dependency that the "Capture Waveforms" use case has on the "Display Waveforms" use case is an example of the latter.
Acme elevator has a number of easily identifiable use cases, as shown in the next figure.
Figure 11: Elevator Use Case Diagram
An elevator is a fairly simple device, but even a use case as simple as "Take a ride" can produce many scenarios:
How does the analyst extract typical and nontypical uses of the system? Although some domain experts may think in abstract terms, the vast majority will be more comfortable identifying specific scenarios rather than use cases. The analyst must identify the dozens (or hundreds) of scenarios that map the important system aspects and from these deduce the use cases from these. A number of approaches to identifying the scenarios are possible.
The analyst can sit with the customer and ask probing questions, such as:
Another approach works well with a small team. Each object in the context diagram is written on a 3x5 card, including the System as one of the objects. Each team member takes a card and assumes the identity of the object. The team members "role play" the scenario by passing written messages to each other. As each team member receives a message, the member must identify different responses that he or she can reasonably make at this point. Each unique thread of responses is a scenario. The possible paths of these branch points define a decision tree. From this tree, a list of separate scenarios can be deduced.
A simple example is shown below. The last three columns are the objects being simulated by the team members during the role playing exercise.
Table 3: Role Playing Scenario
|
|
|
|
|||
|
|
|
|
|
|
|
| [Elevator idle at ground floor] | |||||
| 1 | Req. elevator @ floor 6 going up | Elevator starts going to floor 6 | Source | Target | |
| 2 | [Elevator passes floor 2] | ||||
| 3 | Req. elevator @ floor 2 going down | Elevator pends req. | Source | Target | |
| 4 | Elevator arrives at floor 6 | Target | Source | ||
| 5 | Passenger 1 gets in
and selects floor 8 |
Elevator closes door and begins going to 8 | |||
| 6 | Elevator arrives at floor 8 and opens door | Target | Source | ||
| 7 | Passenger 1 disembarks | ||||
| 8 | Door closure timer times out | Elevator closes door and begins going to floor 2 | |||
| 9 | Elevator arrives at floor 2 and opens door | Target | Source | ||
| 10 | Req. floor 1 | Elevator closes door and begins going to floor 1 | Source | Target | |
| 11 | Elevator arrives at floor 1 and opens door | Passenger 2 disembarks | Target | Source | |
| 12 | Elevator closes door and goes idle |
What are some branch points? Passenger 2 could have requested the elevator when it was actually passing the third floor. Would that be a different scenario? Clearly not because the thread of the scenario would be the same -- the elevator would continue on up to pick up passenger 1 and all subsequent actions would be the same. However, what if Passenger 2 requested an elevator going up before the elevator was even at floor 2? In this case, a different scenario would have resulted: the elevator would have stopped and picked up passenger 2 since a) it could, and b) the request was in the same direction as the elevator’s current direction. This latter alternative does present a scenario branch point.
The number of scenarios can quickly grow very large, and will require pruning. All scenarios that invoke identical system responses at each opportunity constitute a single scenario. Primary scenarios elaborate the major ways the use case is realized in practice. Secondary scenarios are relatively minor variants of the primary scenarios to explore exception handling, safety issues, and other important (but at this stage, peripheral) issues. Booch suggests that a moderate project will have a few dozen use cases, an order of magnitude more primary scenarios, and an order magnitude more secondary scenarios[6].
2.3.2 Using Use Cases
Use cases can provide a unifying strategy for the entire project development.
They are an embodiment of what the customer wants and expects to see when
the dust settles and the product ships. Use cases group together functionally
related scenarios and provide valuable information into all phases:
| Phase | Application of Use Cases |
| Analysis |
|
| Design |
|
| Coding |
|
| Testing |
|
| Deployment |
|