IBM
Contents Index Previous Next



Use Cases


The most important problem to tackle when designing a new system is not to verify the correctness of the system or to get an optimized implementation. None of this matters if the system does not solve the right problem. User-centered requirements analysis using use cases is an approach to capture requirements from the user's point of view. The intention is of course that the users will be able to understand and validate the use cases, and thus confirm that they indeed define the right system to be built.

Consider a system that controls the access to a building, allowing users to enter the building through doors that can be opened by entering a card and a code into a card reader. Some typical use cases for this system may be:

An important term when discussing use cases is the notion of an "actor". An actor is an outside entity that interacts with the system. An actor can be a human being, a hardware unit, a computer program or anything else that can communicate with the system. Usually there is also made a distinction between the individual users of a system and the actors. An actor is not supposed to be an individual user, but rather represents one of the different "roles" individual users can play when interacting with the system.

Each use case describes essentially the possible sequences of events that take place when one or more actors interact with the system in order to fulfill the purpose of the use case. Note that the use case does not define one specific sequence of events, but rather a set of possible sequences.

A use case is thus simply a description, in one format or another, of a certain way to use the system. It has been found to be a very efficient way to capture a user's view of the system and the concept of use cases is now used in a number of object-oriented methods. The version used in SOMT is mainly a combination of the original use cases as described in [19] and the OMT version [20]. A difference is that, as will be seen below, SOMT puts some more effort in the formalization of the use cases to be able to use them for verification purposes during the object design.

In SOMT the use case model is in practise composed of three parts:

The list of actors should describe all actors that have been identified, why they use the system (or which service they provide to the system) and what their responsibilities are.

The list of use cases just gives a one-sentence description of each use case.

The lists of actors and use cases can either be separate documents or be a part of the data dictionary. The lists are particularly useful in the beginning of the requirements analysis when trying to identify the most important use cases and actors.

Two different formats are used to describe use cases in SOMT. One purely textual format and one format that uses MSC diagrams to define the use cases. Depending on the application (and the users) one or both of the notations can be used in a specific project. If the chosen approach is to describe the use cases by means of MSCs and they turn out to be very complex, it is possible to use a combination of plain MSCs and HMSCs to describe them. Most of the things that can be expressed with HMSCs can also be expressed by plain MSCs, so it is a matter of taste if you want to use HMSCs or not. HMSCs have certain advantages, especially if the system is complex:

The choice of notation for use cases is a matter of personal taste and the application at hand. There are four different possibilities:

Textual Use Cases

The textual format consists essentially of natural language text structured into a number of fields and is easiest introduced with an example. Consider the Enter building use case for the access control system that controls the doors of a building. This use case is depicted in Example 647.

Example 647 : Textual description of the Enter building use case

Use case name: Enter building
Actors: Regular user, Door
Preconditions: `Enter card' is displayed and doors 
are closed and locked
Postconditions: Same as preconditions
Description: A user enters a card into the   
cardreader. `Enter code' is displayed on the 
display. The user enters his code (4 digits) using 
the keyboard. The door is unlocked and `Door 
unlocked. Please enter.' is displayed. The user 
opens the door, enters the building and closes the 
door again. the door is locked again and `enter 
card' is displayed.
Exceptions: - If the user enters the wrong code then 
`Wrong code' is flashed for 3 seconds and then 
`enter card' is displayed.
- If the user does not open the door after it has 
been unlocked, then the door is locked again after 
30 seconds and `Enter card' is displayed

As can be seen in the example, a use case has the following fields:

As with the textual requirements, it is important to analyze the textual use cases and clearly mark all important concepts in order to be able to use them when identifying classes and when performing consistency checks between the different models.

Message Sequence Charts

The second notation for use cases used in SOMT is Message Sequence Charts (MSCs). An MSC is a diagram that shows a number of communicating entities (called instances) and the messages that they exchange. Two MSCs that correspond to the "Enter building" use case are shown in Figure 637 and Figure 638. Figure 637 describes the normal case and Figure 638 describes one of the exceptions.

A comment to this use case: There is always a choice of how much to show in a use case. In this particular example there is of course a choice whether to show the interaction between the User and the Door that does not involve the system. There is of course such an interaction where the user opens and closes the door. What to do depends on the purpose of the use case. Is the purpose mainly to describe and understand the problem domain or is the purpose to define the precise requirements on the system? In this use case we have assumed that the purpose is to define the requirements so the interaction that does not directly involve the system is left out of the MSC.

Figure 637 : The "Enter_building" use case

Figure 638 : The exception "WrongCode" for the "Enter_building" use case

Identifying Use Cases

Often some use cases are found very easily from the purpose of the system, but in some cases it is more difficult. One strategy that works well, both as a means to find use cases and as a means to check that all important use cases have been found, is:

  1. Identify the actors.
  2. Identify the use cases needed by each actor.

These two tasks are discussed in the following sections.

Finding Actors

By reading the textual requirements model or discussing with customers, candidates for actors can be found through the answers to the following questions:

Now, we have a set of possible actors. From this, we have to decide if these candidates really are actors or if they are parts of the (software) system. By doing this, we identify the boundaries of the system. This step does not provide any final solutions and decisions taken here might be modified later.

If the actor represents a user, perhaps one, single user, try to keep the level of abstraction that comes with the actor concept. It might be the case that this specific user can perform some tasks that can be performed by other users and some unique tasks. Therefore, try to distinguish between the roles that the users can play, i.e. the actors, and the users themselves. See Figure 639.

Figure 639 : Example of difference between users and actors

Document all actors in a list, describe each actor by a name and describe briefly its role when interacting with the system. The description should contain the actors' responsibilities and the way the actor uses the system. During the process of identifying the actors these descriptions are most conveniently kept in the textual document that lists all actors. This can either be a separate document or a part of the data dictionary.

The set of actors may be due to changes after having started to describe the use cases. Especially the MSC diagrams are useful to pinpoint the problem of determining the actors. In practice this means that the activity of identifying use cases by defining actors and use cases should be performed iteratively.

Finding Use Cases

When you have defined a set of actors, it is time to describe the way they interact with the system.

Steps:

  1. For each actor, find the tasks and functions that he should be able to perform or tasks which the system needs the actor to perform. Search the textual requirements for verb phrases, these are possible candidates for use cases.
    • If possible, make the use cases as complete as possible, i.e. make one use case of a complex function rather than splitting it up into several use cases for each sub-function.
    • To begin with, concentrate on the normal cases. Leave the exceptional cases until a later stage.
  2. Name the use cases and enter them in a textual list of use cases.
    • The names should be informative and be accompanied with general descriptions of the use case functionality.
    • The naming should be done with care, the description of the use case should be descriptive and consistent. Example: the use case that describes when a person leaves deposit items to a recycling machine could either be named Receive deposit items or Returning deposit items, but the latter is preferable since it is usually better to give names that reflect the users point of view rather than the systems.
    • From the list of use cases, try to discard unnecessary use cases. A use case should represent a set of events that leads to a clear goal (or in some cases several distinct goals that could be alternative) for the actor or for the system.
  3. Describe the use cases using the textual use case format and/or give a formal description of the use cases using MSCs (combined with HMSCs if necessary). Use the terms in the requirements object model and data dictionary as much as possible. Focus to begin with on the normal cases.
  4. Refine the use cases by examining the exceptional cases that are possible for each use case.

Now, we have got a view of possible candidates for use cases. It is not sure that all of these need to be described in separate use cases; some of them may be modeled as exceptions to other use cases. Consider what the actor wants to do!

While finding (or specifying) the use cases, it might be the case that you have to make changes to your set of actors. All actor changes should be updated in the textual list of actors and use cases. The changes should be carried out with care, since changes to the set of actors affect the use cases as well.


http://www.ibm.com/rational
Contents Index Previous Next