Upload
vuthuan
View
220
Download
4
Embed Size (px)
Citation preview
USE CASES
Ch 6 in Textbook(Applying UML & Patterns)(Applying UML & Patterns)
Chapter objectives
Describe the meaning of Use caseIllustrate Use Case diagram, and the relationship types inside use case
2
relationship types inside use case diagram.Present different methods to write use case descriptions such as high level format and Expanded format
It describes the main system functions from the standpoint of an external observer
Used during requirements elicitation to represent external behavior
It emphasize on what the system does rather than how it
Capturing functional requirements with use case diagram
3
It emphasize on what the system does rather than how it does it
It is created during the early stages of a project - during the analysis phase rather than during the design ph ase
It provides a high-level view of what the system do es and who uses it
It provides the basis for determining the user inte rfaces (UIs) to the system
ATM
Example – ATM banking systemUse case Diagram
4
Use case diagramUse cases are drawn as ellipses with the name of the use case written inside the ellipseUse case name typically consists of an active verb and one or more nouns that concisely describe the system function modelled
5
System name
Actor 1
Use case 2
Use case 1
Actor 3
Actor 2
Use case diagramActors are drawn as stick persons with the role of the
actor written below
Actor names typically represent the role that an ac tor plays with respect to the system
6
ATM system example: all people interacting
with the ATM system’s user interface are
represented by a single actor, with the role
name ‘customer’, even if each person has
a different real name, a different job,…
use case diagram
Use case diagrams contain:– Actors – Use cases– Associations/ relationships among actors and use c ases
1- An actor:Is someone (e.g. human beings) or something (e.g.
7
Is someone (e.g. human beings) or something (e.g. other objects or systems) that interact with the system. An actor has a unique name.
Is entity external to the system who participates i n the story of the use case (receive or input), such as a person, computer system, or organization.
�e.g. a library clerk, cashier, customer, Passenger, GPS satellite, bank, customer department.
2- Use cases : a collection of related scenarios that describe actors using a system to support a goal.
One use case:Is a summary of scenarios.A scenario is a possible example of what happens
use case
8
A scenario is a possible example of what happens when an actor interacts with the systemRepresents a unit of functionality that the system providesScenario : contains a specific sequence of actions and interactions between actors and the system under discussion.� e.g. the scenario of entering book information into the
catalog, or buying items at a store, or using an AT M.
Use case diagramActors are connected to the use case/s with which they
interact by a line , which represents the relationshipbetween the actor(s) and the use case(s)
One actor may be associated with one or more use ca ses
One use case may be associated with one or more act ors
9
One use case may be associated with one or more act ors
Customer
Bank System
10
Use Case Diagrams ExampleLibrary Information System
Borrow
Resources
11
Librarian Patron
Return
Resources
Add
Resources
Class Exercise
Ask students to draw the Use Case diagram of a system (e.g. Airline reservation system)
12
Use case behaviour description
Each use case in a use case diagram can have an associated behavior specification
A behavior specification describes the sequence of actions making up a use case scenario
13
Types of use case behaviour description format
High level
use case
Expanded
use case
14
use case use case
HL use case describes a process very briefly, usually in 2 or 3 sentences.
Expanded use case describes a process in details. It has an additional section not present in HL, Typical course of events
High level use case format
It has the following format:Use Case: Use case nameActors: List of actors (external agents),
15
Actors: List of actors (external agents), indicating who initiates the use caseDescription (Success scenario): Narrative description of the process
Example: High Level Use case Buy Items
Use Case: Buy ItemsActor: Customer(initiator) , CashierDescription (Success scenario):
16
Description (Success scenario):� A customer arrives at a checkout with
items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items
Sample High-Level Primary Use Cases
Name: Add Resources.Actors: Librarian.Description: The use case begins when the Librarian receives new resources (books and
17
Librarian receives new resources (books and videos) to add to the catalog. The title, call number, and other information are recorded. Then the resources are placed on a shelf organized by resource type and call numbers.
Sample High-Level Primary Use CasesOther possible use cases.
Return a Resource.
Delete a Resource.
18
Notify Overdue Patrons.
Collect Fines.
Expanded use case format
Use Case: Name of use caseActors: List of actors (external agents), indicating who initiates the use casePurpose: Intention of the use caseOverview (Success scenario):
19
Overview (Success scenario):� Repetition of HL use case, or some similar summary
Type: 1-primary, secondary or optional2- essential or real
Cross References: Related use cases and system functions.Typical course of actions: describes in detail the conservation of interaction between the actors and the system.
Importance Levels of Use Cases
PRIMARY SECONDARY
Describes a major, common Describes a rare, unusual, or
20
Describes a major, commonprocess.
Describes a rare, unusual, or exceptional process.
Primary, Secondary and Optional Use cases
Type of Use case can be one of the following:1- Primary: represents major common
processes, such as Buy Items2- Secondary: represents minor or rare
21
2- Secondary: represents minor or rare processes, such as Request for Stocking New Product.
3- Optional: represents processes that may not be tackled.
Abstraction Levels of Use Cases
ESSENTIAL REAL
The essence of the process.Analysis-oriented.
Concrete, design-oriented.
Expresses process Expressed in terms of the
22
Expresses process(relatively) independent ofa hardware/software solution.
Expressed in terms of the solution—screen shots of windows, entry into input fields, and so forth.
Essential versus Real Use Cases
Essential Real
The Librarian records the callnumber.
The Librarian uses the laserwand to scan the bar code forthe call number, which istransmitted to the computer.
23
The AccountHolder identifieshimself to the ATM.
The AccountHolder insertsthe card into the ATM cardreader. He is prompted toenter his PIN (see screenshot 4), which he inputs with anumeric keypad.
Essential vs. Real Use Cases
EssentialVery abstract
RealVery concrete
Use Case Degree of Design Commitment
24
Essential use cases are expanded use cases that are expressed in an ideal form free of technology and implementation details. HL are always essential
Real use cases concretely describes the process in terms of its real current design, committed to specific input and output technology
Example 1: Essential vs. Real Use CasesATM withdraw cash
Actor Action1. This Customer identifies
themselves
System Response2. Presents options
Essential Use Case
25
Actor Action1. This Customer inserts his
card3. Enter PIN on keypad
System Response2. Prompts for PIN
4. Display options menu
Essential Use Case
Real Use Case
Example 2: Essential vs. Real Use CasesBuy Items
Actor Action1. This Cashier records the
identifier for each item
System Response2. Determines the item price &
adds the item information to the running sales transaction
The description & price of the Essential Use Case
26
Actor Action1. For each item, the Cashier
types in the UPC in the UPC field of Window1. They then press “Enter Item” button with the mouse or Enter key
The description & price of the item are presented
System Response2. Display the item price &
adds the item information to the running sales transaction
The description & price of the current item are displayed in Textbox 2 of Window 1
Essential Use Case
Real Use Case
Example: Expanded Use case Buy Items with Cash
Use Case: Buy Items with CashActor: Customer (initiator), cashierPurpose: Capture a sale & its cash paymentOverview (Success scenario):
27
Overview (Success scenario):� A customer arrives at a checkout with items to
purchase. The Cashier records the purchase items and collects a cash payment. On completion, the Customer leaves with the items
Type: primaryCross References: Functions R1.2,…
Typical Course of EventsActor Action
1. This use case begins when a Customer arrives at the POST checkout with items to purchase
2. The Cashier records the identifier from each item
System Response
3. Determines the item price and adds the item information to
28
identifier from each item
If there is more than one of the same item, the Cashier can enter the quantity as well
4. On completion of item entry, the Cashier indicates to the POST that item entry is complete
6. The Cashier tells the Customer the total
adds the item information to the running sales transaction
The description and price of the current item are presented
5. Calculate and presents the sale total
Typical Course of Events
Actor Action7. The Customer gives a cash
payment possibly greater than the sale total
8. The Cashier records the cash received amount
System Response
9. Shows the balance due back to the Customer & generate a receipt.
29
10. The Cashier deposits the cash received & extracts the balance owingThe Cashier gives the balance owing, & the printed receipt to the Customer
12. The Customer leaves with the items purchased
11. Logs the completed sale
Alternatives:Line 2. Invalid identifier entered. Indicate errorsLine 7. Customer didn’t have enough cash. Cancel sales tran saction
Identifying Use Cases
Type 1: Actor-based1. Identify the actors related to an organization2. For each actor, identify the processes they
initiate or participate in
30
initiate or participate in
Type 2: Event-based1. Identify the external events that a system must
respond to2. Relate the events to actors and use cases
Example: POST
Cashier Log inCash out
31
Customer Buy ItemsRefund Items
Examples of processes
A use case describes a process, such as business process.A process describes, from start to finish, a sequence of events, actions and transactions required to produce or complete something of
32
required to produce or complete something of value.
Examples of processes:Withdraw cash from an ATMOrder a productRegister for courses at a schoolCheck the spellingHandle a call
Decision Point & BranchingBuy Items
A Use case may contain decision points such as in Buy Items , the customer may choose to pay via cash, credit or check .If one of them is the typical case (usual), then the typical case is the one written in Typical course of events, and the other alternatives should be written in
33
events, and the other alternatives should be written in the Alternatives section.If all the alternatives are equal in their likelihood, (like the payment types), write in the main section of Typical course of events a branch event , that indicates that the possible branches are written in subsections.Then write a subsection for each branch, again
using Typical course of eventsIf subsections have alternatives, write them in an Alternatives section.
Example: Decision Point & BranchingBuy Items
Actor Action1. This use case begins when a
Customer arrives at POST checkout with items to purchase
2. ..3. Customer chooses payment type:
a. If cash payment, see section
System Response
Section: Main
34
a. If cash payment, see section pay by Cash
b. If credit payment, see section pay by Credit
d. If check payment, see section pay by Check
6. The cashier gives the receipt to the customer
7. The customer leaves with the items
4. Logs the completed sale5. Prints a receipt
Section: Pay by Cash
Actor Action1. The customer gives a
cash payment- possible greater than the sale total
2. The Cashier records the cash tendered
System Response
3. Shows the balance due back to the Customer
35
4. The Cashier deposits the cash received and extracts the balance owingThe Cashier gives the balance owing to the Customer
to the Customer
Alternative Courses:Line 4: Insufficient cash in drawer to pay balance. Ask for cash from supervisor, or ask Customer for a payment clos er to sale total
Plan & Elaborate Phase Steps
Define system functionDefine system boundary, actors & use casesHL use cases
36
Draw use case diagramExpand critical use cases (essential / Analysis)Real use case (Design)Rank use case (not discussed)
Cashier Log inCash out
Customer Buy ItemsRefund Items
Manager Start UpShut Down
System Administrator
Add New Users
Use cases in high level formatUse Case: Buy Items
37
Use Case: Buy ItemsActors: Customer (initiator), CashierType: PrimaryDescription: A Customer arrives at a checkout with items to purc hase. The Cashier records the purchase items and collects a payment. On completion, the Customer leaves the store with the items.
Use Case: Start UpActors: ManagerType: PrimaryDescription: A Manager powers on a POST in order to prepare it f or use by Cashiers. The Manager makes sure the date an d time are correct, after which the system is ready for Cashie rs’ use.
POST
Refund Purchased Items
Log In
Buy Items
Customer
Cashier
<<actor>>
CAS
38
Start Up
Items
System administrator
Manage Users
Etc.
Manager
Cashier
39
40
41
Alternatives?
Example Use case: Make Book Entry
Use Case: UC1 - Make Book EntryActor: Library clerkSuccess scenario:
42
� A library clerk accesses a terminal in order to enter one or possibly many book entries in a database. At the end of every entry, the system displays a confirmation message. At the end of the session the system would display an informative message.
UML use case diagramLibrary Information System
Library clerk
Make Book Entry
43
Library clerk
Browse Catalog
Handle Returns
Make Booking
Library member
The <<extends>> Relationship
<<extends>> relationships represent exceptional or seldom invoked cases.A reusable use case (component) that conditionally interrupts (is invoked optionally -- like a menu selection in an application) the execution of another use case to augment its functionality.
� The functionality in the original problem statement needs to be extended.
44
extended.The exceptional event flows are factored out of the main event flow for clarity.The base use case can be executed without the use case extension in extend associations. The responsibility for deciding when the extending use case should be used lies with the extending use case. Arrow points to use case being extended.
Extendeduse case
Extendinguse case
The <<extends>> Relationship
Use cases representing exceptional flows can extend more than one use case.The direction of an <<extends>> relationship is to the extended use caseFor example: the use case “ReportEmergency” is complete by itself , but can be extended by the use case “Help” for a specific scenario in which the user requires help
45
by itself , but can be extended by the use case “Help” for a specific scenario in which the user requires help
ReportEmergency
FieldOfficerfHelp
<<extend>>
When to Use <<extends>> Relationship
Major variation: If you have a major alternative path in the use case, and it’s complex enough to have its own alternative paths, then placing it on your diagram will honestly expose the complexity—which is helpful in costing, assignment, and scheduling.Optional subgoal: If you have parts of the use case that would be optional to implement (or even optional to execute) to meet the actor’s goals, put those parts into their own use case. Doing so clarifies the relationships between actors and their goals. It also emphasizes that you may deliver these optional goals in later releases.
46http://dotnet.org.za/hannes/archive/2006/01/31/use-cases-when-to-use-includes-generalization-and-extending.aspx
Passenger
PurchaseTicket
47
TimeOut
<<extends>>
NoChange
<<extends>>OutOfOrder
<<extends>>
Cancel
<<extends>>
The <<extends>> Relationship
ManageIncident
48
CreateIncidentHandleIncident CloseIncident
<<Extend>>
<<Extend>>
<<Extend>>
The <<extends>> Relationship
49
The <<extends>> Relationship
50
Bank System
51
52
The <<includes>> Relationship
<<includes>> relationship represents behavior that is factored out of the use case. A use case uses anoth er use case (“functional decomposition”) Used to indicate that one use case includes the functionality of another use case .A function in the original problem statement is too complex to be solvable immediately
53
complex to be solvable immediately� Describe the function as the aggregation of a set of
simpler functions. The associated use case is decomposed into smaller use cases
� A reusable use case (component) that is uncondition ally called into the execution of another use case (alwa ys included in the process – like running BIOS in a sys tem boot).
Included use case
Including use case
Passenger
�Responsibility for the decision about when to use i t lies with the calling use case. � Arrow points to the included use case. The direction of a <<includes>> relationship is to the using use case (unlike <<extends>> relationships).
54
PurchaseSingleTicket
PurchaseMultiTicket
NoChange
<<extends>>
Cancel
<<extends>>
<<includes>>
CollectMoney
<<includes>>
The <<includes>> Relationship
55
56
57
58
Actor Generalization
59
University Registration System
60