Use cases are used for defining how the modeled system is to be used by its surroundings. A use case models one usage of the system; that is, it describes what sequences of actions will be performed by the system as a response to events occurring outside the system caused by the users. However, it does not capture actions outside the system; a use case exists only inside the system. A use case constitutes the complete usage of the system in the sense that it starts when someone outside the system initiates it, and it ends when, based on the initial input, no other input is expected and no more internal actions are to be performed.
In the ATM example, the
Withdraw Moneyuse case starts when the customer inserts the card into the card reader of the ATM. The use case reads the card information and asks the customer for the PIN code. After the PIN code has been entered, the use case validates it, and then asks what amount is to be withdrawn. When the amount has been entered, the use case verifies whether the amount may be withdrawn from the account; if so, it ejects the card, dispenses the cash, and prints a receipt. This is when the use case ends. All these actions must be performed when money is withdrawn. Inserting the card and entering the PIN code is not a complete usage of the ATM, nor is only printing a receipt or dispensing cash. These are just fragments of behavior that the ATM can perform, but they do not constitute complete usages of the ATM. Hence, they are not use cases—they are fragments of use cases.
Every use case has a purpose and provides a value for at least one of the stakeholders of the system. Often the beneficiary is one of the users involved in the use case, but other stakeholders are also possible. If no such stakeholder can be identified, the use case is most likely superfluous and should be removed, because nobody is interested in it.
In a surveillance system monitoring the traffic, there are a number of surveillance points in the streets registering passing vehicles. Surveillance personnel can request the gathered statistics to do various kinds of calculations. The use-case model of the system includes one use case registering vehicles passing the surveillance point and another use case presenting the statistics. In the registration use case, there is only one actor (the vehicle).
This actor can hardly be said to take an interest in the use case. (If the collecting of traffic statistics leads to an improved traffic environment in the future, this is good for the driver of the vehicle; to claim that the vehicle benefits from the registration use case is a bit far-fetched, however, to say the very least!) The surveillance personnel and the traffic planners, on the other hand, see the business value of that use case.
Likewise, the use case presenting the statistics has only one actor (the surveillance personnel). Because they need the use case to be able to perform their work, this use case provides a value to its actor.
A use-case name summarizes the usage of the system it models. The name is a verb phrase given in an active present tense form from the system's point of view, and it usually contains several words. For example, Generate Report, Withdraw Money, and Create Order are adequate names of use cases, whereas the following are examples of inadequate, potentially misleading use-case names: Receive Notification (the wrong point of view—should be Send Notification because this is what the system does), Bank Account (not a utilization—should be Handle Bank Account), and Withdrawal of Money (not active—should be Withdraw Money). However, in some cases a usage already has a well-established name, Login and Local Call, for instance. Obviously, these are appropriate use-case names.
Sometimes it is fruitful to classify the use cases in accordance with their importance to the system. This classification can be used, for example, when determining what impact a use case has on the system's architecture. Some of the use cases model the main and important usages of the system. If these use cases were to be excluded from the system, the system would not be meaningful. We call these use cases primary use cases. Secondary use cases support the performance of the primary use cases. Typically, the latter use cases add and remove such information to and from the system that is needed when the primary use cases are performed. Clearly, the primary use cases are more important than the secondary in the design of the system.
For example, Withdraw Money and Transfer Money are primary use cases of an ATM, whereas Read Transaction Log and Register ATM at Bank are secondary use cases. The latter two use cases are not the primary reason for building an ATM system. Another example is a ticketing system at an airline company, where Order Ticket is a primary use case, and Register Customer is a secondary use case. The reason for developing a ticketing system clearly is not to register customers; it is to handle ordered tickets.
There are also optional use cases that model utilizations of the system that might be included in one installation of the system, while excluded in another installation. Obviously, this group of use cases should have less impact on the system design than the other two groups.
The use cases include the actions performed inside the system as well as descriptions of the external events caused by the actors to initiate the performance of these actions, but they do not include actions performed outside the system. The actions included in the use cases can be of many different kinds, such as storing and retrieving information inside the system, performing calculations, as well as sending information, notifications, and requests to actors. However, a use case is independent of the internal structure of the system—the system can be more or less reorganized internally without affecting the use cases, as long as the use of the system remains the same. (Note that the realization of a use case is very much dependent on the internals of the system, but that is a separate issue. The use case itself is not. See Chapter 15, “Mapping Use Cases onto Classes.”)
This means that a use case's sequences of actions include actions that can be perceived from the outside of the system, but not actions that are dependent on the internal structure of the system—for example, how certain information is represented in the system, what communication takes place between elements inside the system, or which part of the system performs a specific piece of behavior.
Take the use case Withdraw Money in the ATM example and its basic flow, which is described in Figure 4.1. As you can see, the use case includes more actions than just a black-box view, that is, more than just input and output actions. For example, after a user enters the PIN code, the system clearly verifies internally whether the code is correct. Moreover, it is shown that a lot of events are logged, and that different kinds of checks are performed. Even though these are system internal events, they are crucial to the understanding of what takes place in the use case. Therefore, they are of interest to readers of use-case descriptions. However, no parts included reveal how the ATM is structured internally; that is, it is not a white-box description that includes internal communication and shows which part of the ATM does what.
Figure 4.1. A use-case is a gray-box description of the system. It describes what happens inside the system without revealing the internal structure of the system.
A use-case model gives a “gray-box view” of the system (see Figure 4.1). With such a description, the readers of a use-case model, especially three of the major stakeholders, the users, the customers, and the designers, can understand what the system is to do. They are not only interested in the communication between the actors and the system, but also in what happens inside the system. The former two are seldom interested in the internal structure of the system (or they may lack the competence to understand it), whereas the latter will use the use-case model to produce the internal structure of the system. A fourth stakeholder with interest in the use-case model is the test designer, who, among other things, should design tests independent of the internals of the system.
As previously mentioned, a use case describes a complete usage offered by the system, including descriptions of external events caused by input from the users and the system's responses to these inputs, possibly also including internal calculations as well as some output to the users. An instance of a use case (see Figure 4.2) models the performance of one particular usage described by the use case, carrying out one path through all the sequences of actions described in the use case, triggered by a user playing the role of the initiating actor. The use-case instance takes actual values as input from and output to the environment, it performs actions that cause changes to the system's internal state, and it makes actual decisions during the execution of the actions. The description of such an instance of a use case is by many called a scenario, for instance, in UML. For example, one scenario based on the use case Withdraw Money is a description of Hanna withdrawing $60 from her savings account at an ATM on November 20.
Figure 4.2. In UML, an instance is denoted in the same way as its classifier, although the name is underlined and preceded by an optional instance name followed by a mandatory colon. The name of a use-case instance is usually omitted.
The advantage of the use-case instance concept is that it makes it possible to discuss different ways to use one use case, for a use case can behave differently depending on the state of the system as well as on the input provided by the actors. Furthermore, the concept can be used to show what happens when different use cases make use of the same information in the system. For example, when modeling a warehouse system, it is important to resolve what is to happen when an order is to be executed and the order is modified at the same time. Use-case instances make it possible to discuss the situation.
Here it is relevant to point out an aspect of use cases that some find it difficult to grasp when they start working with use cases. As stated previously, use cases describe, among other things, the interactions between the system and its surroundings. However, instances of use cases do not send messages to each other (see Figure 4.3). What would it mean for a performance of a complete usage of a system to communicate with another complete usage of the same system, because they are both said to be complete? Still, assumed interaction is one of the most common misunderstandings regarding use cases. People are sometimes heard to mention situations when “this use case calls the other one,” which is impossible. Instead, if we want to describe that one use case is somehow interleaved with another one, in other words that the sequences of actions of one use case are combined with the sequences of another use case, we are actually describing a third use case. Parts of the sequence of the new use case happen to be described previously in other use cases. Chapter 7, “Include: Reusing Existing Use Cases,” and Chapter 8, “Extend: Expanding Existing Use Cases,” describe how use cases can be related to each other and how in that way we will reuse descriptions of already existing use cases.
However, use cases can affect each other indirectly by using the same pieces of information in the system. For example, both Withdraw Money and Deposit Money will modify the balance of an account, but that does not cause them to communicate with each other by somehow sending messages to each other. Each of them is a complete usage of the ATM, performed independently of whether the other is performed (concurrently) or not.
A use-case model contains all the use cases needed to make up a complete description of the functionality of a system. Because every way to use a system is modeled as a use case, all the behavior of the system will appear in the use-case model (except behavior performed due to the internal structure of the system, such as communication between different parts of the system, or creation and deletion of objects). If not, the system would contain behavior that does not participate in an offered usage, which, of course, would not make sense. Why would behavior not offered by the system to its users be included in the system?
Therefore, if the functionality of a system is to be described completely, the use-case model must capture every sequence that might occur when the system is used. This includes all kinds of flows, also exceptional cases and error cases. In the ATM system, for example, such flows are performed when the PIN code is not correct or the balance of the account does not cover the requested withdrawal. In the telephone exchange example, there would be an exceptional flow describing the case where no lines are available to connect the call.
Other flows that must also be captured include all normal variations of the basic flows. For example, the ATM Customer may or may not want a receipt documenting the withdrawal, or the Callee of the local call may not respond, so the call is not answered. Note, however, that the classification of the flows as basic, alternative, exceptional, and so on has no impact on the system itself. All flows must be identified and described, no matter what they are called. The classification of the flows is just a way for the reader as well as the producer of the model to organize the descriptions of the use cases.
If each such variant were defined by a separate use case, the result would be a very large set of use cases for a single system, so large in fact that the model would be completely incomprehensible. Furthermore, the description of most use cases would be very small because their actual flows would be described in just a few lines. Such a situation would not be manageable in practice, because there would be a lot of overhead handling all the documents for all the use cases, even if each document were to contain very little information.
The solution to this dilemma is to bundle together into one unit a set of sequences that are variations on the same theme—that is, variations, exceptions, and error variants of the same basic sequence of actions. The result is one use case, and this use case includes all the variants of the basic flow. The advantages are numerous. In this way, the total number of use cases for one system is reduced to a fraction of the total number of possible sequences, making the model comprehensible. Furthermore, we treat the basic flow, the alternative flows, and error flows as one conceptual unit; that is, they are to be handled together. By including the use case in the model, we make sure that all its variants are included as well, and by removing it, all the variants are excluded. Moreover, all the variants of one flow are described in one document, although possibly in different sections, which makes the document handling much more viable.
In many cases, it is quite obvious that two sequences should appear in the same use case (see Figure 4.4). For example, if the basic sequence includes a check that should result in true, the complement (a check resulting in false) should also be included in the same use case as a variant of the first sequence. Other cases are not so obvious. Here, the test is whether the two sequences both contribute to producing the value to the stakeholders. In the ATM example, for instance, the sequence withdrawing money and printing a receipt and the sequence withdrawing money without printing a receipt both contribute to helping the customer withdraw some money. However, what about the sequence denial due to too small balance? Does this sequence also contribute to that value? The answer is probably no, because it is most likely not the customer who wants to prevent the withdrawal in this case; it is the bank. So, do not only look at the actors of the system when verifying the values of the use case; one should also include the other stakeholders of the system.
Figure 4.4. There are multiple paths through a use case. An instance of the use case will perform one of these paths.
Of course, if you find a variant flow important enough to promote it to a use case of its own, do so! Just be aware that the size of the model will be increased. However, whether a sequence is to be captured as a separate use case or whether it is to be included in another use case is not the most important question when you create your model. The question is obviously relevant, but whichever you decide, somewhere in your model you will have to model and describe every sequence that is to be performed in the system. Moreover, no matter where you have it in your use-case model, the sequence will be realized in your analysis and design models, and eventually it will be implemented and tested.
This leads us to another common misunderstanding. Some insist that it is not possible to describe all the use cases of a system, because any system will contain an extremely large, if not infinite, number of use cases. This is wrong. A normal medium-sized system usually encompasses around 20 to 50 use cases, and to describe them is not a job for Sisyphus—at least not if it is clear what the system is to do; if not, that is what is problematic! Of course, the number of use cases increases with the size of the system, but not exponentially. One may think that a very large system would require many more use cases, but in fact, the number is still fairly limited. Remember that a use case includes all the variations of its basic flow, which reduces the number of use cases. The use of include and extend relationships in the model may also reduce the combinatory explosion of the size of a model.
Another reason for the limited size of most use-case models is that when a system is very large or complex, it is not possible to have just one description or specification of the system given at the same level of detail as that of a simpler or smaller system. Instead, the complexity is handled by decomposing the system into subsystems, where the scope is limited to a smaller part of the system and where the functionality can be further elaborated for each subsystem (see Chapter 18, “Component Hierarchy”).
As a comparison, just think of all the test cases that are specified for a system. All of them can and must be described; otherwise, it would not be possible to test the system in an organized way. This is also true of the user manual, which describes how the system is to be used. At least the test cases are given at a more fine-grained level than are the use cases, but even if the user manual is not described at that level of detail, it clearly describes all the different ways to use the system. Therefore, we can conclude that it is possible to describe all the functionality of a system with a use-case model.
The next chapter discusses how to model the context of the use cases, focusing on the users of the system. How commonalities, optionality, and the like are to be modeled is described in Chapter 6, “Structuring a Use-Case Model,” and the following chapters. How to prepare a detailed description of a use case is discussed in Chapter 13, “Describing Use Cases.”