Refactor the Use Case Model
After each use case is fleshed out, the requirements gatherers must revisit and often revise the use case model as a whole. Using the guidelines for isolation and focus, use cases may need to be split up, merged, or clarified. Excessively complex use cases must be identified and fixed.
In some cases, a use case may seem well focused and isolated, but still be too complex. This is often found in use cases that consist of complex workflows. The system may not provide any value unless the entire workflow is completed; yet it may be difficult to comprehend the entire process at once. For example, consider the process of ordering a book online. The use case that provides the value is Purchase Book. That does not, however, specify the steps involved: The customer must find a book, consider any reviews, enter his or her payment information and shipping information, and, finally, purchase the book. No mere mortal could understand the activity diagram for this monolithic use case. Few organizations own a sufficiently large plotter to print it. Writing or even reading this huge flow of events from the beginning to the end would be exhausting. Finding a specific issue in a flow of events would be difficult. Despite the theoretical correctness of the use case, it fails the ultimate test; it is not useful to the stakeholders.
There are several mechanisms that manage this sort of complexity. The first splits up the use case and uses preconditions to describe the workflow. Another mechanism uses the include and extend relationships as specified by the UML. Also, variability can be expressed by actor and use case generalization. Let's consider these mechanisms as applied to a simple book-ordering example.
Split Up the Use Case
First, an unwieldy use case may be deleted and its functionality split into several use cases. These use cases are connected by preconditions and postconditions. Preconditions include any use cases that must be completed before the actor may start the use case. Postconditions include any changes to the system that must be accomplished during the use case. Figure 2.3 shows the Purchase Book use case split into many use cases. Find a Book allows the customer to search for a book by different criteria; it has no preconditions. View Reviews displays the reviews for a selected book; it has suc- cessful completion of Find a Book as a precondition. Since each customer must enter payment information at least once and each customer may buy many books, the Enter Payment Information use case is an optional part of the workflow. The same is true of Enter Shipping Information. The Complete Purchase use case has completion of the Enter Payment Information use case and the Enter Shipping Information use case as preconditions. All preconditions for a use case are described in the description of that use case.
This approach has several advantages. First and foremost, it breaks the use case model into manageable pieces. Each new use case has significantly smaller flows of events. The activity diagrams for the use cases no longer require an expensive plotter and a magnifying glass. The overall use case model is far easier to navigate and to understand.
Unfortunately, some information is hidden in this process. A reviewer must check the preconditions to determine the order and dependencies of the use cases in the workflow. There is no way to determine which use cases are optional and which use cases are essential to the workflow. While the layout of the diagram provides some visual clues, it is not a precise or clear description.
Use of Include and Extend Relationships
The UML provides two powerful and, at times, confusing relationships between use cases. The extend relationship allows a use case to be included as an option in another, or base, use case. The other relationship, include, allows a use case to always include another base use case.
Include
In an include relationship, the base use case depends on the included use case because it absorbs its behavior. An include relationship is represented by a dashed arrow pointing from the base use case to the included use case. The relationship is stereotyped by enclosing the word "include" within double angle brackets. The flow of events proceeds along in the base use case until the inclusion point is reached. At this point, the flow of events for the included use case is followed until it completes. After completion of the included use case, the rest of the base flow of events is followed to completion. The inclusion is not optional; when the base use case reaches the inclusion point, the included use case takes over the flow. Also, the included use case may be abstract, such that different forms of the use case can be included without changing the base use case.
Include has two major advantages. First, the base use case is simplified, since the included use case is pulled out. Second, a use case may be included in more than one base use case, so that common flows can be abstracted out. However, in order to qualify, the included use case must fit the definition of a use case. Specifically, it must pro- vide some isolated value to the actor.
Extend
In an extend relationship, the base use case does not include the subordinate use case. Instead, the extension use case depends on the base use case and optionally adds its flow of events to the base use case's flow of events. An extend relationship is represented by a dashed arrow pointing from the extension case to the base use case. The relationship is stereotyped by enclosing the word "extend” within double angle brackets. The base use case defines one or more extension points in its flow of events. Each extension use case specifies the extension point at which it may be inserted, along with the conditions that must hold for the insertion to take place. As the base use case's flow of events progresses to an insertion point, the conditions are checked for the extension use case. If the conditions are met, the extension use case's flow of events is followed to completion. Next, the base use case's flow of events picks up just after the extension point.
In an extend relationship, the dependency is from the extension use case to the base use case, as opposed to an include relationship, in which the dependency is from the base use case to the included use case. Extend use cases are optional, while included use cases must take over the flow if the base use case reaches the inclusion point.
Example
Let's take a look at an example. Figure 2.4 shows the Customer actor initiating the purchase Book use case. The include relationship between the Purchase Book use case and the Find a Book use case indicates that the flow of events for the Purchase Book use case always includes the flow of the Find a Book use case. Similarly, the include relationship between the Purchase Book use case and the Complete Purchase use case indicates that the flow of events for the Complete Purchase use case is always followed, if the flow of events for the Purchase Book use case reaches the inclusion point.
The extend relationships between the Purchase Book use case and the remaining use cases indicate that they are optional. For instance, the customer may have already entered shipping and payment information and be quite content with it.
There are advantages to using the include and extend relationships. The original use case is simplified because the flows of events in the base use case implement the included or extended use cases. Also, the relationships between the original use case and the subordinate use cases are far more precise and visually apparent than is the case for independent use cases and preconditions.
However, the precision of include and extend comes with a price. It is not always easy to explain the concepts; and, as noted earlier, a use case must be written for a wide audience. Imagine a requirements review with 30 people in attendance. Now picture trying to explain the include and extend relationships on the spot. If your use case model benefits from this more advanced notation, then it may be necessary to educate the stakeholders in small groups. Alternatively, it may be possible to show a simplified use case model that omits the inclusion and extension use cases to the wide audience, and reserve the more complex model for carefully targeted groups.
Use Case Generalization
In some situations, a use case may have several distinct paths. For example, there may be two ways in which to find a book. Customers who have a clear idea of their needs can search by title, subject, or even ISBN. Otherwise, customers browse in broad categories, such as mystery novels or home and garden. They may jump from book to book, by following links to similar books.
This combination of searching and browsing in one use case makes the Find a Book use case very difficult to develop and to understand. Fortunately, UML provides a mechanism for exactly this situation. The Find a Book use case is converted into an abstract use case, which means that it defines the value that is obtained by the actor, but does not specify the interactions that are used to reach the goal. Next, multiple concrete use cases are written, with each one specifying a set of interactions that reach the goal defined by the abstract use case. For the Find a Book use case, one concrete use case might be Search for a Book and the other might be Browse for a Book. Figure 2.5 shows the abstract Find a Book use case as a generalization of the two concrete use cases.
Use case generalization can help divide a complex use case into more manageable pieces. In many cases, just the act of creating the activity diagram identifies good candidates for use case generalization. Look for parallel paths that have the same basic purpose.
WARNING -Do not implement use case generalization based on use case size and complexity alone.
It is often tempting to split up a use case as the activity diagram and flow of events becomes unwieldy. Discipline and an understanding of the different mechanisms must temper this natural instinct. Arbitrary use of sophisticated mechanisms leads to confusion and eliminates many of the benefits of use cases.
When appropriate, use case generalization makes a use case model more precise without making it much more complex. It is an excellent mechanism when there are high-level alternatives in a use case, but both alternatives serve the same basic purpose.
That said, as with include and extend, use case generalization requires more sophistication from the consumers of the use case model. In my experience, the concept is significantly easier to explain than include and extend. Also, it is very easy to produce a high-level use case model that simply excludes the concrete use cases.
Actor Generalization
In many use case models, one actor is very similar to another actor, yet still has additional obligations or responsibilities. In the UML, an actor is shown as a special type of another actor by drawing a generalization arrow to the more general actor.
The generalization relationship is intended to document real-world differences and similarities between user groups. The more specific actor must initiate all of the use cases that the more generic actor initiates; thus the more specific actor is actually a type of the generalized actor.
Consider a simple hiring process, in which managers and employees both participate in the interview and selection processes, but in which only the manager discusses salary and makes the final hiring decision. Both perform the Interview Candidate and Evaluate Candidate use case, but only the manager performs the Tender Offer and Reject Candidate use cases. Figure 2.6 shows the first two use cases initiated by the Employee actor and the second two use cases initiated by the Manager actor. But note, since the Employee actor is a generalization of the Manager actor, the Manager actor also initiates the Interview Candidate and Evaluate Candidate use cases.
Actor generalization is appropriate only if the actor uses all of the use cases that the generalized actor uses, thus really is a special type of the generalized actor. Consider an example with technical experts and managers. In most companies, there is no generalization relationship between the actors. Not all managers are technical experts and not all technical experts are managers. There is no reason to force this into a generalization relationship. Instead, simply show the actors separately, as in Figure 2.7.
WARNING - Actor generalization can become needlessly complex. Don't impose a relationship where none exists. Remember, you can always eliminate the actor generalization and simply show the relationships between each actor and use case.
Actor generalization can simplify a use case model, especially if a new version of an actor adds a few use cases while initiating many existing use cases. However, actor generalization does add complexity and demand some incremental sophistication from the consumers of the use case model. Ifthe actors' names are well chosen, and the relationships are not excessively complex, most stakeholders find the underlying idea quite reasonable. After all, the relationships between actors reflect and highlight real- world differences and similarities between user communities.