Many different groups of people need to understand the functionality of a system. First, obviously, are the owners of the system. They need to understand the functionality of the system under development, to make sure that the developed system will be the system they want and need. Just as important are the developers of the system, who need to know what system they are to produce. Another important group is the testers, who must verify that what the system offers is in accordance with what was originally agreed on. Other groups that must understand the system include the managers in the organization where the system is to be used, the technical writers who produce user manuals, the service personnel who install and maintain the system, and last, but not least, the users. This list, by no means exhaustive, might be considerably longer depending on the system in question.
What is important is to ensure that all the stakeholders of the system get a common description of the system functionality, one that they all understand and that is detailed enough to make an agreement meaningful and unambiguous. This has made it imperative to find a powerful, well-thought-out and at the same time simple technique to describe the system's functionality. Here the use-case concept has played a major role. This chapter introduces the most important constructs used in use-case modeling. The subsequent chapters provide a more thorough description of the constructs.
A use case defines one way of using the system being modeled. All behavior within the system—that is, all the ways the system can be used—is captured by the use cases. The users of the services (persons, machines, and other systems interacting with the system at hand) are modeled as actors. Together the use cases and the actors form a use-case model of the system. This model describes all the ways the system can be used by its environment—what services the system offers.
For example, in a use-case model of an ATM system (see Figure 3.1), one use case would typically be Withdraw Money, defining what the ATM does when a customer withdraws some money from an account. Another use case would be Transfer Money, which describes the actions of the ATM when money is withdrawn from one account and deposited in another account. The ATM offers both services to its users, here represented by the actor ATM Customer.
Figure 3.1. A use-case diagram presenting part of a use-case model of an ATM system. The diagram shows an actor associated with two use cases.
To look at another system that we have all experienced as users, we can use the model of a telephone exchange system (see Figure 3.2), where we will find use cases such as Local Call, Long-Distance Call, and Order Wake-Up Call. In some of these use cases, more than one actor is involved, because it takes two to make most telephone calls meaningful.
Figure 3.2. A use-case diagram showing some actors and use cases in a model of a telephone exchange.
As we have seen, a use case may involve one or more actors, each capturing a distinct role in relation to the use case. Each role modeled by an actor is played by entities in the system's surroundings, such as human beings, machines, and other software systems. Obviously, the same individual may play different roles, usually at different moments in time. For example, one subscriber may initiate calls as well as answer them (see Figure 3.3).
Figure 3.3. The users of a system play the roles defined by the actors. The figure shows instances—that is, actual occurrences of actors and use cases.
Use cases have proved to be easy to understand by different stakeholders of a system. Not only technical people appreciate the concept, but also managers and ordinary software users understand it easily. Use-case modeling has therefore rapidly become one of the more popular ways to capture the functionality of a system. (Unfortunately, this does not mean that everyone produces good use-case models and use-case descriptions!)
By defining the services offered by a system in terms of use cases, we get a comprehensive picture of the functionality of the system. The use cases can be mapped onto the classes in an object-oriented model of the system, showing what objects take part in the performance of each use case, and how these objects interact in doing so. This fills the gap between the user-oriented, outside view of the system functionality and the more technical object-oriented view of the system's interior. (Other implementation techniques, such as procedure/data-oriented implementations, are also possible.)
Use cases are suitable not only for capturing a system's functionality, they are also very useful for defining the boundaries of the system; that is, to express what is inside the system and what is outside. A use case models one way of using the system—that is, it captures everything that happens inside the system—from system boundary to system boundary. The external entities are captured by the actors. This implies that after the use cases and the actors have been identified, the system boundary has also been defined.
Moreover, use cases also prove useful as a basis for a number of other actions related to system development, such as identifying test cases, describing services that can be demanded when buying or configuring a system, planning and estimating the size and cost of a project developing a system, producing a user manual, and describing how different parts of the system interact.