The Rational Unified Process: An Introduction (3rd Edition)

DEFINITIONS

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 the solution to that problem. 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 may 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 under-standable 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]

^[1] Use cases were introduced by Ivar Jacobson in Object-Oriented Software Engineering: A Use-Case-Driven Approach. Reading, MA: Addison-Wesley, 1992. See also the more recent book: Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process . Reading, MA: Addison Wesley Longman, 1999.

Use Case and Actor

To build a use-case model, you must understand two key concepts: use case and actor. The Rational Unified Process defines these terms as follows :

• A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.

• An actor is someone or something outside the system that interacts with the system.

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:

• Actions

  An action is a computational or algorithmic procedure that is invoked when the actor provides a signal to the system or when the system gets a time event. An action may imply signal transmissions to either the invoking actor or other actors. An action is atomic, which means it is performed either in its entirety or not at all.

• A sequence of actions

  The sequence of actions referred to in the definition is a specific flow of events through the system. Many different flows of events are possible, and many of them may be very similar. To make a use-case model understandable, we group similar flows of events into a single use case.

• The system performs

  Again, note that we are concerned with what the system does in order to perform the sequence of actions. The use case helps us to define a firm boundary around the system; what is done by the system is described clearly, separate and distinct from the actions in the outside world. In this way, a use case helps us bound the scope of the system.

• An observable result of value

  The sequence of actions must yield something that has value to an actor of the system. An actor should not have to perform several use cases in order to achieve something useful. Focusing on useful value provided to an actor ensures that the use case has relevance and is at a level of granularity that the user can understand.

• A particular actor

  Focusing on a particular actor forces us to isolate the value provided to specific groups (roles) of users of the system, ensuring that the system does what they need it to do. It helps us avoid building use cases that are too large. It also prevents us from losing focus and building systems that try to satisfy the needs of everyone but in the end satisfy no one.

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 Actors

A 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.

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 of using the system. The name of a use case usually conveys the value provided to the actor.

Flow of Events

The most important part of the use case in the requirements workflow 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 Events

Let's look at an example of a flow of events for one of the use cases described above. An initial outline of the flow of events of the use case Withdraw Money could be written as follows:

1. The use case begins when the Client inserts a card into the ATM. The system reads and validates information on the card.

2. The system prompts for a personal identification number (PIN). Client enters the PIN. The system validates the PIN.

3. The system asks which operation the client wishes to perform. Client selects "Withdraw Money."

4. The system requests the amount of withdrawal. Client enters amount.

5. The system requests the account type. Client selects the account type (checking, savings, credit).

6. The system communicates with the ATM network to validate the account ID, PIN, and availability of the amount requested .

7. The system asks the Client whether a receipt is desired. This step is performed only if there is paper available to print the receipt.

8. The system asks the Client to remove the card. Client removes the card. (The request is a security measure to ensure that Clients do not leave their cards in the machine.)

9. The system dispenses the requested amount of cash.

10. The system prints a receipt, if requested, which ends the use case.

When you try to describe what the system performs by giving complete sequences of actions, you rapidly realize that there are many courses of action ”various 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:

• Input from an actor

  The actor can choose, from several options, what to do next . For example, the bank's Clients may cancel the transaction at any time, or they may decide they do not need a receipt.

• The internal state of the system

  For example, the ATM may be out of cash or have no paper for receipts, or the cash dispenser or printer may jam.

• Time-outs and errors

  For example, if the ATM user does not respond within a specified time interval, the system might automatically cancel the transaction. If the user enters the wrong PIN several times, the transaction might be canceled and the card confiscated.

Scenarios

We 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 "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 Model

The 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 Model

The 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 those 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).