A large part of the Rational Unified Process focuses on modeling. As we explained in Chapter 5, models help us to understand and shape both the problem we are trying to solve as well as its solution. The choice of models and the choice of techniques used to express them have a significant impact on the way we think about the problem and try to shape the solution. Many approaches can be taken to model the problem and to express the requirements and constraints on the system to be developed. But keep in mind that once this model is developed, we will then need to formulate a model of the solution. If the model of the problem is too far removed from the model of the solution, a great deal of effort may be expended in attempting to translate the expression of the problem from a form understandable by end users into a form understandable by designers and builders. This presents many opportunities for misinterpretation and often makes it difficult to validate the solution with respect to the stated problem. Moreover, we will be working with several models in our process that must be kept consistent. In this chapter we focus primarily on one method of understanding and modeling the problem. An effective method, and one recommended by the Rational Unified Process, is the technique of use-case modeling. Use cases provide a means of expressing the problem in a way that is understandable to a wide range of stakeholders: users, developers, and customers. [1]
Use Case and ActorTo build a use-case model, you must understand two key concepts: use case and actor. The Rational Unified Process defines these terms as follows :
Note that the system is the thing under consideration; actors (roles that people or other systems might assume) are things that interact with it, and use cases define these interactions. In reviewing these definitions, let us consider several key terms and phrases that are used:
The description of a use case defines what the system does when the use case is performed. A system's functionality is defined by a set of use cases, each of which represents a specific flow of events. The use-case flow of events expresses the behavior of the system in a "gray box view" of the system, whereas a use-case realization , which is used later in design, is the "white box view"; it shows how the use case is actually performed in terms of interacting objects and classes. Example of Use Cases and ActorsA bank client, for example, can use an automated teller machine (ATM) to withdraw money, transfer money, or check the balance of an account. These capabilities can be represented by a set of use cases, as shown in Figure 6-1. Figure 6-1. A use-case diagram for an ATM
Each use case represents something that the system does that provides value to the bank's customer, the Client (actor). The collected use cases constitute all the possible ways to use the system. The name of a use case usually conveys the value provided to the actor. Flow of EventsThe most important part of the use case in the requirements discipline is its flow of events. The flow of events describes the sequence of actions between the actor and the system. It is written in natural language, in a simple, consistent prose , with a precise use of terms that draws on a common glossary of the problem domain. Example of a Flow of EventsLet's look at an example of a flow of events for one of the use cases just described. An initial outline of the flow of events of the use case Withdraw Money could be written as follows:
When you try to describe what the system performs by giving complete sequences of actions, you rapidly realize that there are many courses of actionvarious paths through the use-case flow of events. There are alternative branches and different cases (scenarios) to consider, and different values or effects are produced. Collectively, the use-case flow of events eventually describes all these possible courses. The path chosen depends on several things such as the following:
ScenariosWe do not want to have to express each possible alternate flow in a separate use case; rather, we will group them with other related use-case flows of events. Such a grouping defines a use-case class . An instance of a use-case class is one specific flow of events, or a specific path, through the use case. An instance of a use-case class is also called a scenario . It is usually sufficient and less cumbersome to refer to a use-case class as merely a use case, and a use-case instance as a scenario . Scenarios are used in the process to extract and emphasize a unique sequence of actions or a "thread" through a use case. This is especially useful when defining test cases. Also, when you're trying to find use cases during the early stages of a project, it is easier to start from a specific scenario and then expand it to more flows of events, finally generalizing it to a full-blown use case. Use-Case ModelThe use-case model, then, consists of the set of all use cases for the system, or a portion of the system, together with the set of all actors that interact with these use cases, thus describing the complete functionality of the system. It provides a model of the system's intended functions and its environment, and can serve as a contract between the customer and the developers. Use cases and actors are defined in the Unified Modeling Language (UML), and the Rational Unified Process uses use-case diagrams and activity diagrams to visualize the use-case model, including possible relationships among use cases. What about Concurrency?Sometimes you may be concerned about interactions among use cases at runtime, such as several use cases using the same resources and thereby creating an opportunity for conflict. The purpose of the use-case model is to make sure that all functional requirements are handled by the system. To remain focused on this, we ignore (for the moment) nonfunctional requirements, including concurrency. You should assume at this stage that all scenarios (use-case instances) can run concurrently without any problem. When the system is designed, you should then ensure that all nonfunctional requirements are handled correctly, including ensuring that concurrency requirements are dealt with properly. Example of a Use-Case ModelThe use-case model for the ATM example discussed earlier could be completed with use cases for the bank staff and use cases for the installation personnel. The use-case model is complemented by nonfunctional specifications that cover the aspects of the system that cannot be described easily in a use case or that apply to many or all use cases. Examples of these are design constraints, performance, reliability, and safety and security requirements (see Chapter 9). As the defined system grows, it is useful to make sure that certain terms are used consistently throughout all use cases. To address this need, we create as a companion document a project glossary or, even better, a simple object model of the domain called a domain model (see Chapter 8). |