Express the temporal order between a collection of use cases that must be invoked only in a specific order, even though the use cases are functionally unrelated to each other.
Characteristics: Very common. Basic solution.
Keywords: Dependency between use cases, invocation order, order between use cases, precondition, temporal order between use cases.
The Use-Case Sequence pattern affects the descriptions of use cases without any relationships between them, although they should be performed in a certain order. (Of course, some of the use cases might have relationships between them, but such relationships will not be defined because of the temporal order between the use cases.)
This pattern is used when there is a temporal order between the use cases but no information retrieved by an instance of one use case is to be included in an instance of another.
In many systems, the user must perform some kind of initiation procedure (for example, log in) before a collection of more or less independent services become available. After using some of these services, the user must execute some finalization procedure (for example, log out). However, although most of these services are unrelated to each other, most likely all of them will not be available at the same time. The user will have to navigate through a menu hierarchy or graph of Web pages to find the desired services and be able to initiate the corresponding use cases (see Figure 26.1).
In an Internet bank, the customer starts at a Web page requesting the customer's ID number and password key. After these have been entered, the system checks to see that the entered information is correct and then presents a welcome page with the latest news from the bank and similar information. On this page, the customer can choose between groups of services, such as managing the customer's account, stock portfolio, loans, and so forth. When the customer selects one of these groups, a new Web page will be presented that lists more detailed information, such as the customer's account numbers and the current balance of each account. If the customer requests even more details, the customer will be asked to select one of the accounts and another Web page will be presented with the transactions of the past two months.
Figure 26.1. The use cases in an Internet bank have no relationships between them, but there is a (partial) order in which they can be performed.
In principle, nothing prevents the user from utilizing a particular use case whenever he or she wants to do so, because all the use cases are functionally unrelated. In the preceding example, the Present Account Transactions use case, which retrieves and presents the details about the past two months' transactions of an account, takes an account number as the input, retrieves the information about the transactions, and presents it to the user. Therefore, from a functional point of view, this use case can be performed at any time, as long as the user provides the account number. It is the user interface that restricts what services can be selected. In this particular example, the user has no possibility to initiate the Present Account Transactions use case and cannot provide the account number as an input, except through specific Web pages.
How do we express that the use cases can be invoked only in a specific order? In principle, there are two ways: by means of preconditions and state machines. A precondition of a use case is used for stating which state the system is to be in when the use case is initiated. For example, the precondition of the Present Account Transactions use case includes, at least, the following:
In this way, the reader of the description of the use case will understand what must have taken place just before this use case is to be executed. Then, GUI specifiers and implementers, among others, will use the precondition as an input to their work, so that the GUI and the system will be specified and implemented accordingly.
A state machine can be used to specify what different states the user interface can be in and what transitions can be made between these states. Any use case that can be performed in a certain state is specified on a transition leaving that state and entering the state that the interface will be in after the use case has been performed (see Figure 26.2). Usually, the state machine describes the boundary class implementing the interface toward the user. However, the state machine can be generalized to apply to the whole system.
Figure 26.2. A state-machine diagram describing in which order some of the use cases of an Internet bank system can be invoked. The labels on the transitions correspond to the names of the use cases.
As a complement to preconditions and state machines, a flow chart or activity diagram may be drawn to show the order in which the use cases are to be invoked.
Although the use cases can be used only in a certain temporal order, they should not have include or extend relationships to each other to express the order in which they can be invoked. Such relationships are used for describing the addition of actions into another use case's sequence of actions—that is, expanding a use-case instance—and not for expressing temporal order between different use-case instances. If the use cases are complete in themselves, there will be no such additions. The only situations where include and extend relationships are to be used are when a use case initiates the sequence of actions of another use case, and when a use case makes use of a value calculated by another use case. Of course, this defines a temporal order between the actions described in different use cases, but these use cases are not independent of each order; they jointly model a complete usage of the system.
To sum up
We use preconditions or state machines to specify the order in which use cases can be performed.
We use include and extend relationships to specify that a use case initiates, or makes use of a value produced by, the actions described by another use case.
Smorgasbord
Another name of this pattern could have been Smorgasbord. At a (Swedish) smorgasbord, all dishes are present at once, so they are all available all the time to the eater who can choose from any dish that he or she likes. However, the tradition says that one should start with the herring. The next round is a selection of the different kinds of salmon and other cold dishes. Next follows the hot dishes, such as spare ribs, roast beef, and meatballs. Finally, the desserts are chosen. (Here some argue that one should have the cheeses before the sweets, whereas others have it the other way around.) So there is an order between the dishes, even though they are all present all the time.
This section provides an example of the application of the Use-Case Sequence pattern and uses preconditions to state the order of the use cases. We provide four use-case descriptions from an Internet bank: Present Navigation Page, Present Accounts, Pay Bills, and Present Account Transactions (see Figure 26.3). The first use case is used for navigating between the different services of the bank, which are presented by different Web pages. The Present Accounts use case can only be performed when the Web page of a service offering to display the accounts is shown. The same procedure is employed in the Pay Bills use case. The last use case presents the transactions that have been performed on an account over the past two months. This use case can be performed only on an account that is presented in the current Web page.
This example could also benefit from one of the CRUD patterns, as well as a Future Task blueprint.
There is no analysis model for this chapter because the temporal order between the use cases does not affect the structure of the analysis model. However, the preconditions of the use cases and the state machines are used as inputs when specifying the contents of the classes of the analysis model. Usually, the boundary class associated with the actor to which the use cases should appear in a specific order is to have a state machine allowing different types of input from the actor in different states. As an object of the boundary class changes its state, it offers a different menu alternative or presents another Web page to the user playing the role of an actor.