04 UseCaseTutorial1

UML
Use Case Modeling
Minder Chen, 1994-2004
Use Case - 1
Objectives
Identify actors from a problem statement. Identify use cases from a problem statement. Learn how to create a use-case diagram that accurately models the system. Learn how to write use-case specification, glossary, and supplementary specification document.
Use Case - 2
The Purpose of the Requirements Discipline

The Requirements discipline intends to:
Find agreement on what the system should do. Provide a better understanding of the system requirements. Define the boundaries of the system. Provide a basis for planning the technical contents of iterations. Provide a basis for estimating cost. Define a user-interface for the system.
Use Case - 3
Requirements in the Context of SDLC or RUP
Use Case - 4
Relevant Requirements Deliverables or Artifacts

Use-Case Model
Glossary Actors
Use Cases
...
Supplementary Specification Use-Case Specifications
Use Case - 5
What Is a Use-Case Model?

A model that describes a systems functional requirements in terms of use cases. A model of the systems intended functionality (use cases) and its environment (actors).
Student
View Report Card
Register for Courses
Login
Minder Chen, 1994-2004 Use Case - 6
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.
Usages of a Use Case Model
Use Case - 8
The software development life cycle
Use Case - 9
Use Case Granularity
Source: http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/jul02/TopTenWaysJul02.pdf
Use Case - 10
Major Concepts in Use-Case Modeling

An actor represents anything that interacts with the system. A use case defines a set of usecase instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.
Actor
Use Case
Use Case - 11
What Are the Benefits of Use-Case Models?

Used to communicate with the end users and domain experts
Provides buy-in at an early stage of system development Insures a mutual understanding of the requirements Who interacts with the system and what the system should do The interfaces the system should have All requirements have been captured The development team understands the requirements
Used to identify
Used to verify
Use Case - 12
System Surroundings and Actors

Users who execute the systems
Main functions Secondary functions, such as system administration
External hardware that the system uses Other systems interacting with the system
Use Case - 13
Useful Questions in Finding Actors

Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system used? Who will support and maintain the system? What are the systems external resources? What other systems will need to interact with this one?
Actor
Use Case - 14
Actors and Roles

An actor represents a role that a human, hardware device, or another system can play. The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Actor names should clearly denote the actors role Actor description:
Area of responsibility Dependency of the actor on the system
Minder as Professor
Professor
A User May Have Different Roles

Minder as Student
Student
Use Case - 15
Use Case Modeling: Core Elements
Construct Description
use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A coherent set of roles that users of use cases play when interacting with these use cases. Represents the boundary between the physical system and the actors who interact with the physical system.
Syntax
UseCaseName
actor
ActorName
system boundary
Use Case - 16
Use Case Modeling: Core Relationships
Construct
association
Description
Syntax
The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other. A relationship from an extension use extend case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case. generalization A taxonomic relationship between a more general use case and a more specific use case.
<<extend>>
Use Case - 17
Use Case Modeling: Core Relationships (contd)
Construct
include Or use
Description
An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.
Syntax
<<include>>
Use Case - 18
Example: Online HR System

Online HR System
Locate Employees
Update Employee Profile
Manager
{if currentMonth = Oct.} Update Benefits
Employee
Healthcare Plan System
{readOnly}
Access Travel System
Access Pay Records
Insurance Plan System
Use Case - 19
Case Study: Course Registration Problem Statement

Course Registration Problem Statement
(From Visual Modelling with Rational Rose and UML, Terry Quatrani 1998)
The university will require a new Course Registration system. At the beginning of each semester, professors at the university will register the courses that they are going to teach with the system. The system then will allow students to request a course catalogue containing a list of course offerings for the coming semester. Information about each course such as professor, department and prerequisites are included. The student then can select four-course offering. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. For each semester, there is a period of time that students can change their schedule through adding or dropping courses. Professors must be able to access the system to indicate which courses they will be teaching and to see which students signed up for their course offerings.
Use Case - 20
Practice: Find the Actors

In the Course Registration System Requirements document, read the Problem Statement for the Course Registration case study. As a group, identify the following:
Actors Description of the actor
Use Case - 21
Finding Use Cases: Focus on the Actor

The system exists only for its users Use cases should be based on the users needs
Answer the following questions to find use cases.

For each actor you have identified, what are the tasks the system would be involved in? Does the actor need to be informed about certain occurrences in the system? Will the actor need to inform the system about sudden, external changes? What information must be modified or created in the system?
Use Case - 22
MOT Analysis Example: Credit Card

Pri to MOT
Recognition Information gathering Comparison Applying for Credit Card Receiving Credit Card Using Credit Card Providing Information Changing and Upgrading Gifts giving Emergency Assisting No usage follow-up Stop membership follow-up
MOT: Moment of Truth
MOT
After MOT
Use Case - 23
Practice: Solution
The external system responsible for student billing
Billing System
Student A person who is teaching classes at the University
A person who is registered to take courses at the University The unabridged catalog of all courses offered by the University
Professor
Course Catalog
The person who is responsible for the maintenance of the course registration system
Registrar
Use Case - 24
Name Use Cases

The name indicates what is achieved by its interactions with the actor(s). The name may be several words in length. No two use cases should have the same name.
Login Maintain Student Information

Practice: Finding Use Cases

In the Course Registration System Requirements document, read the Problem Statement for the Course Registrations case study. As a group, using the actors identified in the earlier practice session, identify the following:
Use Cases Use-Case names
Use Case - 26
Practice: Solution
View Report Card
Login
Select Courses To Teach
Submit Grades
Maintain Professor Information
Maintain Student Information
Close Registration
Use Case - 27
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.
a use case: . . .describes a sequence of actions, performed by a system, that yields a result of value to the user.
Use Case - 28
Concept: Communicate-Association
Use cases and actors interact by sending signals to one another. To indicate such interactions, use a communicate-association.
Actor
Communicate-Association
Use Case
Use Case - 29
Practice: Use Case and Actor Communication In the Course Registrations System Requirements document, read the Problem Statement for the Course Registration case study. As a group, using the actors and use cases identified in the earlier practice session, identify:
Communicate-associations between the actors and the use cases.
Use Case - 30
Use Case and Actor Communication

View Report Card
Student
Course Catalog
Maintain Professor Information
Login
Maintain Student Information Select Courses to Teach Registrar Professor
Submit Grades
Close Registration
Billing System
Use Case - 31
Develop a Library System Use Cases Exercise Identify actors Determine major use major use cases Draw a use case diagram
The library system is designed for a local public library.
Use Case - 32
Use-Case Specifications
Name Brief description Flows of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams
Use-Case Model
Actors Use Cases
...
Use-Case Specifications
Use Case - 33
Use Case Description: Change Flight Actors: traveler, client account db, airline reservation system Preconditions:
Traveler has logged on to the system and selected change flight itinerary option System retrieves travelers account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then System displays transaction summary. If no flights are available then
Basic course

Alternative courses
Use Case - 34
Use Case Flow of Events

Has one normal, basic flow Happy Case Several alternative flows Regular variants of the basic flow Odd cases Exceptional flows handling error situations
Use Case - 35
What Are Scenarios?

A scenario is an instance of a use case
Use Case - 36
Glossary
Course Registration System Glossary 1. Introduction
This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.
2. Definitions
Glossary
The glossary contains the working definitions for the key concepts in the Course Registration System. 2.1 Course: A class offered by the university.
2.2 Course Offering: A specific delivery of the course for a specific semester you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered. 2.3 Course Catalog: The unabridged catalog of all courses offered by the university.
Use Case - 37
Supplementary Specification
Functionality Usability Reliability Performance Supportability Design constraints
Supplementary Specification
Online Resource: http://www-106.ibm.com/developerworks/rational/library/3975.html#N10071
Use Case - 38
Verify a Use Case Model

Is the use-case model understandable? By studying the use-case model, can you form a clear idea of the system's functions and how they are related? Have all functional requirements been met? Does the use-case model contain any superfluous behavior? Is the division of the model into use-case packages appropriate?
Use Case - 39
Verify Actors
Have all the actors been identified? Is each actor involved with at least one use case? Is each actor really a role? Should any be merged or split? Do two actors play the same role in relation to a use case? Do the actors have intuitive and descriptive names? Can both users and customers understand the names?
Use Case - 40
Verify Use Cases

Is each use case involved with at least one actor? Is each use case independent of the others? Do any use cases have very similar behaviors or flows of events? Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? Do customers and users understand the names and descriptions of the use cases?
Use Case - 41
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? Are any use cases overly complex?
Use Case - 42
Verify Glossary
Does each term have a clear and concise definition? Is each glossary term included somewhere in the usecase descriptions? Are terms used consistently in the brief descriptions of actors and use cases?
Use Case - 43
Library System Use Case

A library contains books and journals. The task is to develop a computer system for borrowing books. In order to borrow a book the borrower must be a member of the library. There is a limit on the number of books that can be borrowed by each member of the library. 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. Users can extend the loans. 1. Draw a use case diagram for a library system. 2. Give a use case description for two use cases: Borrow a copy of a book Extend the loan of a book http://www.cs.nott.ac.uk/~sxp/OOMethods/Exer1.pdf
Use Case - 44
Step Wise Refinement of Use Case Model

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 is one and only one basic flow.
Step Wise Refinement of Use Case Model

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? 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?
Reminders
Write something readable.
Casual, readable use cases are still useful whereas unreadable use cases wont get read. 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 Show a goal succeeding.
Work breadth-first, from lower precision to higher precision.
For each step:
Capture the actors 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). Ask why to find a next-higher level goal
For data descriptions (only put Precision Level 1 into the use case text):
Precision Level 1: Data nickname Precision Level 2: Data fields associated with the nickname Precision Level 3: Field types, lengths, and validations
Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley

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
Continued
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.
Use Case - 49
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?
Use Case - 50
Exercise
Create a payroll system for restaurants and hotels. Make certain that the usual deductions are taken into consideration. The payroll must accommodate both salaried and hourly employees. The waiters are salaried employees, but the busboys are hourly employees. The payroll system must print checks weekly. The system will produce a payroll register which will be turned over to auditors monthly. Income and tax reports (such as W-2s* in the U.S.) must be prepared according to legal requirements. Reports concerning voluntary deductions will be prepared for various agencies on a quarterly basis. ? The payroll must treat part-time employees as hourly employees. Full-time employees and salaried employees may take advantage of the various company benefits, part-time employees may not. Restaurant employees will be able to eat meals at their restaurant but will have the cost of the meals deducted from their paycheck. Hotel employees will have room costs deducted if they live in the hotel. There are voluntary deductions and mandatory government deductions that must be taken into account. *W-2 = U.S. annual income statement
Exercise
Identify for the Payroll System
Actors Use cases
Name the use cases Produce the use-case model for the Payroll System. Provide:
Actor descriptions Brief use-case descriptions
Compare your results to other groups.

Are there differences? Why? How would you resolve these differences?
Use Case Diagram
Telephone Catalog
Check status
Place order
Salesperson
Fill orders Customer Establish credit Shipping Clerk
Supervisor
UML Notation Guide

Use Case Relationships

<<includes>> and <<extends>>
Supply Customer Data Order Product
Arrange Payment
include
include
include
Place Order
1 * Extension points additional requests :
after creation of the order
extend
the salesperson asks for the catalog
Request Catalog
Use Case - 54
Actor Relationships
Place Order
Salesperson
Establish Credit
Supervisor
Use Case - 55
Online HR System: Use Case Relationships
Update Medical Plan
Update Dental Plan
Update Insurance Plan
<<include>>
<<include>>
<<include>>
Update Benefits
______________ Extension points benefit options: after required enrollments <<extend>> employee requests reimbursement option Elect Reimbursement for Healthcare extension point name and location <<extend>> employee requests stock purchase option Elect Stock Purchase
Employee
extension condition
Use Case - 56
Online HR System: Update Benefits Use Case
Actors: employee, employee account db, healthcare plan system, insurance plan system Preconditions: Employee has logged on to the system and selected "update benefits" option Basic course System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. Alternative courses If health plan is not available in the employees area the employee is informed and asked to select another plan... Use Case - 57 Minder Chen, 1994-2004
When to model use cases Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven method
start with use cases and derive your structural and behavioral models from it.
If you are not using a use-case driven method

make sure that your use cases are consistent with your structural and behavioral models.
Use Case - 58
Use Case Modeling Tips

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 to help derive objects and messages for interaction diagrams 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

Use Case - 60
Use Case - 61
Set Display Options
Use Case - 62
A Use Case Diagram Created in Visio
OPS
Place order ___________ Handle Rush Order extends uses Handle Rush Order Manage inventory
Log in uses Administration Login Track shipment Customer Manage Shipment Order Operation Clerk
Use Case - 63
Display Options for Communications
Use Case - 64
Model Explorer
Linking an Linking a model element to another diagram
Use Case - 65
Exercise: Automated Teller Machine (ATM)

Brief Statement of Purpose: An ATM is an electronic device designed for automated dispensing of money. A user can withdraw money quickly and easily after authorization. The user interacts with the system through a card reader and a numerical keypad. A small display screen allows messages and information to be displayed to the user. Bank members can access special functions such as ordering a statement Additional Notes: Users shall be able to access the ATM by punching in their account number and PIN. Once the system has verified that the account is active and the PIN matches with the account number, the system offers the users four choices. Users can withdraw money, deposit money, check balance or quit the session. The user must have a minimum of $100 in his / her account. At the end of any transaction a printed copy of the transaction is provided to the user. A transaction could be - withdraw money, deposit money or check balance. Once the user has completed a transaction, the system offers the user the same four choices, until the user decides to quit.
Requirements
Brief Summary of Requirements: The ATM is required: 1. To allow authorized card holders to make transactions
1. Card holders shall view and/or print account balances 2. Card holder shall make cash withdrawals 3. Card holder shall make cash or check deposits 4. Card holder shall quit session
2. To allow bank members to access additional, special services

1. A bank member shall be able to order a statement 2. A bank member shall be able to change security details (e.g. PIN number)
3. To allow access to authorized bank staff

1. Authorized staff can gain access to re-stock the machine 2. Authorized staff are able to carry out routine servicing and maintenance
4. To keep track of how much money it contains and alert bank staff when stocks are getting low.
Use Case - 67
Exercise Requirements
Identify the actors Identify the uses cases Draw the top level Use-Case diagram Develop a detailed Use-Case analysis for a use case. Your analysis should contain a brief description of the use case, the basic and alternative flows, pre and post conditions.
Use Case - 68
The authoring life cycle of Use Cases
Use Case - 69
Context of a System
The whole is more than the sum of the parts The whole determines the sum of the parts The parts cannot be understood if considered in isolation from the whole The parts are dynamically interrelated and interdependent
-- Fredrick Hagel (1770-1831)
Use Case - 70

04 UseCaseTutorial1

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

04 UseCaseTutorial1

Transféré par

Droits d'auteur :

Formats disponibles

UML

Use Case Modeling

Minder Chen, 1994-2004

Minder Chen, 1994-2004

The Purpose of the Requirements Discipline

Minder Chen, 1994-2004

Requirements in the Context of SDLC or RUP

Minder Chen, 1994-2004

Relevant Requirements Deliverables or Artifacts

Minder Chen, 1994-2004

What Is a Use-Case Model?

View Report Card

Register for Courses

What is Use Case Modeling?

System behavior is captured in use cases.

Usages of a Use Case Model

Minder Chen, 1994-2004

The software development life cycle

Minder Chen, 1994-2004

Use Case Granularity

Minder Chen, 1994-2004

Major Concepts in Use-Case Modeling

Minder Chen, 1994-2004

What Are the Benefits of Use-Case Models?

Minder Chen, 1994-2004

System Surroundings and Actors

Minder Chen, 1994-2004

Useful Questions in Finding Actors

Minder Chen, 1994-2004

Actors and Roles

A User May Have Different Roles

Use Case Modeling: Core Elements

Minder Chen, 1994-2004

Use Case Modeling: Core Relationships

Minder Chen, 1994-2004

Use Case Modeling: Core Relationships (contd)

Minder Chen, 1994-2004

Example: Online HR System

Update Employee Profile

{if currentMonth = Oct.} Update Benefits

Healthcare Plan System

Access Travel System

Access Pay Records

Insurance Plan System

Minder Chen, 1994-2004

Case Study: Course Registration Problem Statement

Minder Chen, 1994-2004

Practice: Find the Actors

Minder Chen, 1994-2004

Finding Use Cases: Focus on the Actor

Answer the following questions to find use cases.

Minder Chen, 1994-2004

MOT Analysis Example: Credit Card

MOT: Moment of Truth

Minder Chen, 1994-2004

Student A person who is teaching classes at the University

Minder Chen, 1994-2004

Name Use Cases

Register for Courses

Login Maintain Student Information

Practice: Finding Use Cases

Minder Chen, 1994-2004