Ivan Marsic • Rutgers
University 62
engineers, and project managers. We will be mainly concerned with the actors that interact directly with the SuD, but any of the stakeholders has certain goals for the SuD and occasionally
it may be appropriate to list those goals.
Table 2-1 implies that a software system is developed with a purposeresponsibility—this purpose is helping its users actors to achieve their goals. Use cases are usage scenarios and therefore
there must be an actor intentionally using this system. The issue of developer’s intentions vs. possible usage scenarios is an important one and can be tricky to resolve. There is a tacit but
important assumption made by individual developers and large organizations alike, and that is that they are able to control the types of applications in which their products will ultimately be
used. Even a very focused tool is designed not without potential to do other things—a clever user may come up with unintended uses, whether serendipitously or intentionally.
Use Cases
A
use case
is a usage scenario of the system—a sequence of interactions between an external entity, known as
actor
, and the SuD. A use case represents an activity that an actor can perform on the system and what the system does in response. It describes what happens when an actor
disturbs our system from its “stationary state” as the system goes through its motions until it reaches a new stationary state. It is important to keep in mind that the system is reactive, not
proactive; that is, if left undisturbed, the system would remain forever in the equilibrium state. An actor can be a person or another system which interacts with our SuD.
There are two main categories of actors, defined relative to a particular use case: 1.
Initiating actor also called primary actor: initiates the use case to realize a goal, which depends on the actor’s responsibilities and the current context also called primary actor
2. Participating actor also called secondary actor: participates in the use case but does not
initiate it; two subcategories: a
Supporting actor: helps the SuD to complete the use case—in other words, our SuD acts as a initiating actor of the supporting actor
b Offstage actor: passively participates in the use case, i.e., neither initiates nor
helps complete the use case, but may be notified about some aspect of it Table 2-1 names the preliminary use cases for our case-study example. Use cases are usually
written as usage scenarios or scripts, listing a specific sequence of actions and interactions between the actors and the system. For use case scenarios, we will use a stepwise, “recipe-like”
description. A scenario is also called a use case instance, in the sense that it represents only one of several possible courses of action for a given use case. The use cases specify what information
must pass the boundary of the system in the course of interaction.
Chapter 2 • Object-Oriented Software Engineering
63
We usually first elaborate the “normal” scenario, also called main success scenario, which assumes that everything goes perfect. Since everything flows straightforward, this scenario
usually does not include any conditions or branching—it flows linearly. It is just a causal sequence of actionreaction or stimulusresponse pairs. Figure 2-1 shows the use case schema.
9
Alternate scenarios or extensions in a use case can result from: •
Inappropriate data entry, such as the actor making a wrong menu-item choice other than the one heshe originally intended, or the actor supplies an invalid identification.
• System’s inability to respond as desired, which can be a temporary condition or the
information necessary to formulate the response may never become available. For each of these cases we must create an alternate scenario that describes what exactly happens
in such a case and lists the participating actors. Although we do not know what new uses the user will invent for the system, purposeful
development is what governs the system design. For example, attempt to burglarize a home may
9
The UML standard does not specify the use case schema, so the format for use cases varies across different textbooks. Even a single author may use additional fields to show other important information,
such as non-functional requirements associated with the use case.
Use Case UC-: Name Identifier
[verb phrase]
Related Require’ts:
List of the requirements that are addressed by this use case
Initiating Actor:
Actor who initiates interaction with the system to accomplish a goal
Actor’s Goal:
Informal description of the initiating actor’s goal
Participating Actors:
Actors that will help achieve the goal or need to know about the outcome
Preconditions:
What is assumed about the state of the system before the interaction starts
Postconditions:
What are the results after the goal is achieved or abandoned; i.e., what must be true about the system at the time the execution of this use case is
completed
Flow of Events for Main Success Scenario:
→ 1. The
initiating actor
delivers an action or stimulus to the system the arrow indicates the direction of interaction, to- or from the system
← 2. The
system
’s reaction or response to the stimulus; the system can also send a message to a participating actor, if any
→ 3. …
Flow of Events for Extensions Alternate Scenarios:
What could go wrong? List the exceptions to the routine and describe how they are handled → 1a. For example, actor enters invalid data
← 2a. For example, power outage, network failure, or requested data unavailable …
The arrows on the left indicate the direction of interaction: → Actor’s action; ← System’s reaction
Figure 2-1: A general schema for UML use cases.
Ivan Marsic • Rutgers
University 64
be a self-contained and meaningful goal for certain types of system users, but this is not what we are designing the system for—this is not a legal use case; rather, this must be anticipated and
treated as an exception to a legal use case.
A note in passing, the reader should observe that use cases are not specific to the object-oriented approach to SE. In fact, they are decidedly process-oriented rather than object-oriented, for they
focus on the description of activities. As illustrated in Figure 1-3a, at this stage we are not seeing any objects; we see the system as a “black box” and focus on the interaction protocol
between the actors and the black box. Only at the stage of building the domain model we encounter objects, which populate the black box.
Actor Generalization
Actors may be defined in generalization hierarchies, in which an abstract actor description is shared and augmented by one or more specific actor descriptions.
2.2.3 Requirements Elicitation through Use Cases
For example, for the use case Unlock, the main success scenario in an abbreviated form may look something like this:
Use Case UC-1: Unlock
Related Requirem’ts:
REQ1, REQ2, REQ3 in Section 1.3.1 above
Initiating Actor:
Any of: Tenant, Landlord
Actor’s Goal:
To open the door’s lock and enter get space lighted up automatically.
Participating Actors:
LockDevice, LightSwitch, Timer
Preconditions:
• The set of valid keys stored in the system database is non-empty. • The system always displays the menu of available functions; at the
door keypad the menu choices are “Lock” and “Unlock.”
Postconditions:
The auto-lock timer has started countdown.
Flow of Events for Main Success Scenario:
→ 1.
Tenant Landlord
arrives at the door and selects the menu item “Unlock” 2.
include::AuthenticateUser UC-5 ← 3.
System
a signals to the
Tenant Landlord
the lock status, e.g., “open,” b signals to
LockDevice
to open the lock, and c signals to
LightSwitch
to turn the light on ← 4.
System
signals to the
Timer
to start the auto-lock timer countdown → 5.
Tenant Landlord
opens the door, enters the home [and shuts the door and locks] In step 5 above, the activity of locking the door is in brackets, since this is covered under the use
case Lock, and is not of concern in this use case. Of course, we want to ensure that this indeed happens, which is the role of the auto-lock timer, as explained below. In addition, we may want to
indicate how is the SuD affected should the door be unlocked manually, using a physical key.
Although I do not list the extensions or alternate scenarios in the above, normally for each of the steps in the main success scenario, we must consider what could go wrong. For example,
• In Step 1, the actor may make a wrong menu selection
Chapter 2 • Object-Oriented Software Engineering
65
• Exceptions during the actor authentication are considered below
• In Step 5, the actor may be held outside for a while, e.g., greeting a neighbor
For instance, to address the exceptions in Step 5, we may consider installing an infrared beam in the doorway that detects when the person crosses it. Example alternate scenarios are given for the
AuthenticateUser and Lock use cases below.
In step 2, I reuse a “subroutine” use case, AuthenticateUser, which I anticipate will occur in other use cases, as well. Here I include the main scenario for AuthenticateUser as well as the
exceptions, in case something goes wrong:
Use Case UC-5: AuthenticateUser sub-use case
Related Requirements:
REQ2, REQ3 in Section 1.3.1 above
Initiating Actor:
Any of: Tenant, Landlord
Actor’s Goal:
To be positively identified by the system at the door interface.
Participating Actors:
AlarmBell, Police
Preconditions:
• The set of valid keys stored in the system database is non-empty. • The counter of opening attempts equals zero.
Postconditions:
None worth mentioning.
Flow of Events for Main Success Scenario:
← 1.
System
prompts the actor for identification, e.g., alphanumeric key →
2.
Tenant Landlord
supplies a valid identification key ←
3.
System
a verifies that the key is valid, and b signals to the actor the key validity
Flow of Events for Extensions Alternate Scenarios:
2a.
Tenant Landlord
enters an invalid identification key ←
1.
System
a detects error, b marks a failed attempt, and c signals to the actor ← 1a.
System
a detects that the count of failed attempts exceeds the maximum allowed number, b signals to sound
AlarmBell
, and c notifies the
Police
actor of a possible break-in
→ 2.
Tenant Landlord
supplies a valid identification key 3. Same as in Step 3 above
When writing a usage scenario, you should focus on what is essential to achieve the initiating actor’s goal and avoid the details of how this actually happens. Focus on the “what” and leave out
the “how” for the subsequent stages of the development lifecycle. For example, in Step 2 of AuthenticateUser above, I just state that the user should provide identification; I do not detail
whether this is done by typing on a keypad, by scanning an RFID tag, or by some biometric technology.
Here is the main success scenario for the Lock use case:
Use Case UC-2: Lock
Related Requirements:
REQ1 in Section 1.3.1 above
Initiating Actor:
Any of: Tenant, Landlord, or Timer
Actor’s Goal:
To lock the door get the lights shut automatically ?
Participating Actors:
LockDevice, LightSwitch, Timer
Ivan Marsic • Rutgers
University 66
Resident
Tenant Landlord
Actor generalization. Preconditions:
The system always displays the menu of available functions.
Postconditions:
The door is closed and lock armed the auto-lock timer is reset.
Flow of Events for Main Success Scenario:
→ 1.
Tenant Landlord
selects the menu item “Lock” ← 2.
System
a signals affirmation, e.g., “lock closed,” b signals to
LockDevice
to arm the lock if not already armed, c signal to
Timer
to reset the auto-lock counter, and d signals to
LightSwitch
to turn the light off ?
Flow of Events for Extensions Alternate Scenarios:
2a. System senses that the door is not closed, so the lock cannot be armed ← 1.
System
a signals a warning that the door is open, and b signal to
Timer
to start the alarm counter
→ 2.
Tenant Landlord
closes the door ← 3.
System
a senses the closure, b signals affirmation to the
Tenant Landlord
, c signals to
LockDevice
to arm the lock, d signal to
Timer
to reset the auto-lock counter, and e signal to
Timer
to reset the alarm counter Notice that in this case, the auto-lock timer appears as both the initiating and participating actor
for this use case. This is also indicated in the use case diagram in Figure 2-2. This is because if the timeout time expires before the timer is reset, Timer automatically initiates the Lock use case,
so it is a initiating actor. Alternatively, if the user locks the door before the timeout expires, the timer will be reset, so it is an offstage actor, as well.
I also assume that a single Timer system can handle multiple concurrent requests. In the Lock use case, the timer may be counting down the time
since the lock has been open. At the same time, the system may sense that the door is not closed, so it may start the alarm timer. If the door is not shut
within a given interval, the system activates the AlarmBell actor and may notify the Police actor.
You may wonder why not just say that the system will somehow handle the auto-lock functionality rather than going into the details of how it works.
Technically, the timer is part of the planned SuD, so why should it be declared an external actor? Recall that the SuD is always passive—it reacts to an external
stimulus but does nothing on its own initiative. Thus, to get the system perform auto-lock, somebody or something must trigger it to do so. This is the responsibility of Timer. Timer is an
external stimulus source relative to the software under development, although it will be part of the end hardware-plus-software system.
Next follows the description of the ManageUsers use case:
Use Case UC-3: ManageUsers
Related Requirements:
REQ4 in Section 1.3.1 above
Initiating Actor:
Landlord
Actor’s Goal:
To register new residents andor remove the departed ones.
Participating Actors:
Tenant
Preconditions:
None worth mentioning. But note that this use case is only available
