1. Object-Oriented Analysis - Instructor Notes
Use Case Tutorial
Module 2 – Modeling System Behavior with Use Cases

2. Object-Oriented Analysis - Instructor Notes
What is Use Case Modeling?
A a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (i.e., use cases) that are meaningful to users (i.e., actors).
System behavior is how a system acts and reacts.
It is an outwardly visible and testable activity of a system.
System behavior is captured in use cases.
Use cases describe the system, its environment, and the relationship between the system and its environment.
No system exists in isolation. Every system interacts with people or automated systems for some purpose. These interactions result in some sort of predictable result. This predictable result is system behavior.
Use cases are the mechanism for capturing the desired behavior for the system that is under development, but they do not specify how the behavior is to be implemented.
The UML specifies a model for communicating system behavior, the use-case model.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

3. Object-Oriented Analysis - Instructor Notes
Usages of a Use Case Model
Object-Oriented Analysis - Instructor Notes
Module 2 – Modeling System Behavior with Use Cases

4. Object-Oriented Analysis - Instructor Notes
What Are the Benefits of Use-Case Models?
Used to communicate with the end users and domain experts
Provides buy-in at early stages of development
Insures a mutual understanding of the requirements
Used to identify
Who interacts with the system and what the system should do
The interfaces the system should have
Used to verify
All requirements have been captured
The development team understands the requirements
This slide is part of the “Fundamentals of Visual Modeling with UML” course.
Yes, you are selling the concept of a use-case model here. Many of your students may not immediately recognize the need for the use-case model because it is so simple. This slide is intended to bring out some of the problems that this model resolves. Feel free to add your own experiences here.
There are many ways to model a system, each of which may serve a different purpose. However, the most important role of a use-case model is to communicate the system's behavior to the customer or end user. Consequently, the model must be easy to understand.
The Use-Case model is also used to identify the actors that interact with the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs, ensuring that the system turns out to be what the users expected.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

5. Object-Oriented Analysis - Instructor Notes
System Surroundings and Actors
Object-Oriented Analysis - Instructor Notes
Users who execute the system’s
Main functions
Secondary functions, such as system administration
External hardware that the system uses
Other systems interacting with the system
This slide outlines some actors that the requirements team can overlook. It is very important that all the actors for a system are identified up front since use cases are identified based on the system’s actors.
For a Depot-Handling System, which supports the work in a depot, there are several categories of users: Depot Staff, Order Registry Clerk, Depot Manager. All these categories have specific roles in the system and you should therefore represent each one by a separate actor.
In a recycling machine used for recycling cans, bottles, and crates, Customer is the main actor, the one for whom the system is primarily built. Someone has to manage the machine, however. This role is represented by the actor, Operator.
A ventilation system that controls the temperature in a building continuously gets metered data from sensors in the building. Sensor is therefore an actor.
An automated teller machine must communicate with the central system that holds the bank accounts. The central system is probably an external one, and should therefore be an actor.
If you are building a Internet-based application, your primary actors are anonymous. You don't really know who they are, and you cannot make any assumptions about their skills and background. But you can still describe the role you expect them to play towards your system.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

6. Object-Oriented Analysis - Instructor Notes
Use Cases and Actors
A use case models a dialog between actors and the system.
A use case is initiated by an actor to invoke a certain functionality in the system.
The communicate- association can also be drawn in the other direction.
A use case can initiate communication with an actor. Usually, this occurs with a nonhuman actor.
a use case:
. . .describes a sequence of actions, performed by a system, that yields a result of value to the user.
It is important to show how actors relate to the use case. Therefore, on finding a use case, establish the actors that interact with it. To do this, you must define a communicate-association that is navigable in the same direction as the transmission between the actor and the use case.
Actors may be connected to use cases only by an association. An association between an actor and a use case indicates that the actor and the use case communicate with one another, each one able to send and receive messages.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

7. Object-Oriented Analysis - Instructor Notes
Develop a Library System Use Cases Exercise
Identify actors
Determine major use cases
Draw a use case diagram
The library system is designed for a local public library.
Module 2 – Modeling System Behavior with Use Cases

8. Object-Oriented Analysis - Instructor Notes
Verify Use-Case Specifications
Is it clear who wishes to perform a use case? Is the purpose of the use case also clear?
Does the brief description give a true picture of the use case?
Is it clear how and when the use-case's flow of events starts and ends?
Does the communication sequence between actor and use case conform to the user's expectations?
Are the actor interactions and exchanged information clear? Does the use-case contain any superfluous behavior?
Are any use cases overly complex?
Is the use-case unambiguous?
Include any (nonfunctional) requirements to be handled in the object models in the use-case Special Requirements.
Behavior might exist that is activated only when a certain condition is not met. There should be a description of what happens in such a case.
If you want your use-case model to be easy to understand, you might have to split up complex use cases. A use case that contains disparate flows of events is very difficult to understand and to maintain. It is best to divide such use cases into two or more separate use cases.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

9. Object-Oriented Analysis - Instructor Notes
Create and Verify a Glossary
Does each term have a clear and concise definition?
Is each glossary term included somewhere in the use-case descriptions?
Are terms used consistently in the brief descriptions of actors and use cases?
If each glossary term is not included somewhere in the use-case descriptions, that may imply that a use case is missing or that the existing use cases are not complete. It is more likely, though, that the term is not included because it is not needed, and it should be removed from the glossary.
A term should represent the same thing in all use-case descriptions.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

10. Object-Oriented Analysis - Instructor Notes
Library System Use Case Exercise
Object-Oriented Analysis - Instructor Notes
A library contains books and journals. The task is to develop a computer system for borrowing books. To borrow a book the borrower must hold a valid library card, have no books overdue by more than one week, and have no outstanding fines. There is a limit of 6 books that can be borrowed by a student and 12 books by a staff member.
The library may have several copies of a given book.
It is possible to reserve a book.
Some books are for short term loans only. Other books may be borrowed for 3 weeks. Borrowers can extend the loans.
Give a use case description for the following use case:
• Borrow a copy of a book
Solution:
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

11. Object-Oriented Analysis - Instructor Notes
Step Wise Refinement of Use Case Model
Object-Oriented Analysis - Instructor Notes
The eight basic steps to generate use cases model for each business process area:
Step 1: Confirm actors and goals. Have all actors and their goals been identified? Which actors can be generalized (combined)? Which goals are potential use cases?
Step 2: Develop an outline of the use case(s). For the goals identified as potential use cases, what are the key pieces? For each outline level, what are key data? Outline all use cases. Prioritize the use-case flows. Decide on a final use-case list (for initial pass).
Step 3: Write a brief description of the use case(s). What two or three sentences describe all actors and the basic flow? Generate content first, and worry about wordsmithing it later.
Step 4: Detail the basic flow. What event starts the use case? How does the use case end? How does the use case repeat some behavior? What is the "happy" (best case) path? There can only be one!
Module 2 – Modeling System Behavior with Use Cases

12. Object-Oriented Analysis - Instructor Notes
Step Wise Refinement of Use Case Model
Object-Oriented Analysis - Instructor Notes
Step 5: Detail the alternate flows. Are there optional situations for the use case? What might go wrong? What might not happen? Which resources might be blocked, limited, unavailable? Which alternate flows are special — perhaps nonfunctional — requirements (i.e., they apply to this use case only)?
Step 6: Review the use case(s). Are there more use cases? Should some use cases be redefined? Which ones can be combined?
Step 7: Record pre- and post-conditions. What was the previous state before this use case comes into play? What happens once the use case is complete?
Step 8: Develop generalizations for all use cases. Determine shared content and process for the use cases. What items have been noted for the glossary or as global business rules? Who has the most recent and accurate source document? Where is it located?
Module 2 – Modeling System Behavior with Use Cases

13. Object-Oriented Analysis - Instructor Notes
Reminders
Write something readable.
Casual, readable use cases are still useful whereas unreadable use cases won’t get read.
Work breadth-first, from lower precision to higher precision.
Precision Level 1: Primary actors name and goal
Precision Level 2: The use case brief; or the main success scenario
Precision Level 3: The extension conditions
Precision Level 4: The extension handling steps
For each step:
Show a goal succeeding.
Capture the actor’s intention, not the user interface details.
Have an actor pass information, validate a condition, or update state.
Write between-step commentary to indicate step sequencing (or lack of).
Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley
Module 2 – Modeling System Behavior with Use Cases

14. Object-Oriented Analysis - Instructor Notes
The Writing Process
1. Name the system scope and boundaries.
Track changes to this initial context diagram with the in/out list.
2. Brainstorm and list the primary actors.
Find every human and non-human primary actor, over the life of the system.
3. Brainstorm and exhaustively list user goals for the system.
The initial Actor-Goal List is now available.
4. Capture the outermost summary use cases to see who really cares.
Check for an outermost use case for each primary actor.
5. Reconsider and revise the summary use cases. Add, subtract, or merge goals.
Double-check for time-based triggers and other events at the system boundary.
6. Select one use case to expand.
Consider writing a narrative to learn the material.
Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley
Module 2 – Modeling System Behavior with Use Cases

15. Object-Oriented Analysis - Instructor Notes
Continued…
Object-Oriented Analysis - Instructor Notes
7. Capture stakeholders and interests, preconditions and guarantees.
The system will ensure the preconditions and guarantee the interests.
8. Write the main success scenario (MSS).
Use 3 to 9 steps to meet all interests and guarantees.
9. Brainstorm and exhaustively list the extension conditions.
Include all that the system can detect and must handle.
10. Write the extension-handling steps.
Each will end back in the MSS, at a separate success exit, or in failure.
11. Extract complex flows to sub use cases; merge trivial sub use cases.
Extracting a sub use case is easy, but it adds cost to the project.
12. Readjust the set: add, subtract, merge, as needed.
Check for readability, completeness, and meeting stakeholders’ interests.
Module 2 – Modeling System Behavior with Use Cases

16. Object-Oriented Analysis - Instructor Notes
Review Questions
What are the main artifacts of requirements?
What are the requirements artifacts used for?
What is a use-case model?
What is an actor?
What is a use case?
What is the difference between a scenario and a use case?
Question 1: The use-case model, supplementary specifications and the glossary are the main artifacts of Requirements.
Question 2: The Use-Case Model describes what the system does. The Supplementary Specification contains those requirements that don’t map to a specific use case. The Glossary defines a common terminology for all models.
Question 3: It is a model of the system's intended functionality and its environment. The use-case model serves as a contract between the customer and the developers.
Question 4: An actor represents a coherent set of roles that users of the system play when interacting with these use cases.
Question 5: A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. The use case properties may be documented in use-case specifications, which may include: brief description, flow of events, relationships, activity diagrams, use-case diagrams, etc.
Question 6: A scenario is an instance of a use case. It is one flow through a use case.
Module 2 – Modeling System Behavior with Use Cases
Module 2 – Modeling System Behavior with Use Cases

17. Object-Oriented Analysis - Instructor Notes
Use Case Modeling Tips
Object-Oriented Analysis - Instructor Notes
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately and consistently
Factor out common usages that are required by multiple use cases
If the usage is required use <<includes>> or <<uses>>
If the base use case is complete and the usage may be optional, consider use <<extends>>
A use case diagram should
contain only use cases at the same level of abstraction
include only actors who are required
Large numbers of use cases should be organized into packages
Module 2 – Modeling System Behavior with Use Cases

18. Object-Oriented Analysis - Instructor Notes
Use Case Exercise
Object-Oriented Analysis - Instructor Notes
Describe a Use Case for a user who has just chosen a book at BN.com and wants to check out.
This use case should end when the user has successfully paid for the book.
Module 2 – Modeling System Behavior with Use Cases