Sept 200592.3913 Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation...

Sept 2005 92.3913 Ron McFadyen 1

Use Cases

Introduced by Ivar Jacobson in 1986

•literal translation from Swedish ”usage case”

Used to capture and describe the functionality encompassed in some system or subsystem – a tool for analysis

A use case will illustrate one or more scenarios – one typical path and many alternative scenarios

A use case captures a goal of using the system

Use cases can be used to guide development of testing plans


Use Cases

Illustrated with diagrams and/or a behaviour specification (written in text form)

A project may begin with the definition of many “brief” or “casual” use case definitions – a few sentences each.

Later on, these can be become very formal or “fully dressed”

(for example see alistair.cockburn.us/usecases/uctempla.htm)

The UML defines the nature of the diagrams, but not the behaviour specifications – companies standardize their own approaches


Use Cases in the UML

•Functionality under consideration is represented by use cases (named ellipses)

•Actors are connected to use cases they use through associations

Use Cases


• Actor (typically a stick person)

• Use Case (a named ellipse)

• Associations (lines)

– Between Actors and Use Cases

– Between Use Cases

– Between Actors

Use Cases


Actors

• Actors represent the people or other systems that interact with the system.

• Each actor is drawn as a stick person with the name written underneath

• An actor represents a set of roles that users of a system may assume

• In a university registration system, we might have:

Student Registration Manager

Registration Advisor

Chair


Use Case Behaviour

• A use case is drawn as an ellipse, with its name within or below the ellipse

• A use case should be written as a behaviour specification separately from the diagram (the written use case)

• other UML diagrams (statechart, sequence, activity) can be used to illustrate behavioural information in a use case

• A use case will be implemented as a computer program and the actors initiate execution (or instantiation) of a use case

• A use case describe what a system does, not how it does it – a design activity is to determine how a use case is carried out.


Use Case Example

• We might begin describing a registration system as:

Register

Manage coursesStudent

Department Chair

Generate report

Registration Clerk

Registration

Between actors and use cases we draw associations (the lines) to indicate the use cases each actor can instantiate


Example: Processing a Sale at a Cash Register

• Use Case UC1: Process Sale• Primary Actor: Cashier• …• Preconditions: Cashier is identified and authenticated• Postconditions: Sale is saved…Commissions recorded…Payment

authorization approvals recorded• Main Success Scenario:1. Customer arrives at POS checkout with goods and/or services to

purchase2. Cashier starts a new sale3. Cashier enters item identifier4. System records sale line item and presents item description, price, and

running total. Price calculated from a set of price rules.Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated…


Process Sale Use Case

Cashier repeats steps 3-4 until indicates done.

5. System presents total with taxes calculated

6. Cashier tells customer the total, and asks for payment.

7. Customer pays and System handles payment

8. System logs completed sale and sends sale and payment information to the external Accounting System and Inventory System.

9. System presents receipt

10. Customer leaves with receipt and goods



• Extensions or Alternate Flows*a. At any time, the System fails:

1. Cashier restarts System, logs in, and requests recovery of prior sale2. System reconstructs prior state. …

3a. Invalid identifier:1. System signals error and rejects entry

3b. There are multiple of same item category and tracking unique item identity is not important (e.g. 5 packages of veggie burgers)1. Cashier can enter item category identifier and the quantity

…4a. The system generated item price is not wanted …

1. Cashier enters override price.2. System presents new price.

… Identifies the step where this condition may arise.

“*” means any step; “4” means at step 4; a letter following identifies a different exception


Use Case Associations

• Between use case and actor

– uses

• Between use cases

– include

– extend

– generalization

• Between actors

– generalization


Relating Use Cases

• Include relationship

• If one use case is designed to utilize the functionality of another use case there is an “include” dependency

• Consider that a base use case is executing. When it reaches the inclusion point, the included use case is instantiated and executed, and when it finishes the base use case continues.

• “Include” is a way to factor commonality out of use cases to make the design more modular

• Suppose the Process Sale use case is designed to use the functionality of Handle Credit Payment and the Handle Check Payment use cases.



• Extensions or Alternate Flows

……

7a. Customer pays with a credit card: include HandleCreditPayment

7b. Customer pays by cheque: include HandleChequePayment

7a and 7b show alternative ways for step 7 to complete

The Process Sale use case has explicit statements referring to other use cases ….. These are include dependencies …. Like calling a function or subroutine

Instead of the word include, we could use something else such as execute


Include Relationship

• In the UML diagram

Process Sale

Handle Cheque Payment

Handle Credit Payment

<<include>>

<<include>>

Process Sale has a dependency on Handle Check Payment, and another dependency on Handle Credit Payment

The dashed lines and the stick arrowhead are the correct way to depict these dependencies


Include Relationship

• Suppose a Purchase order system has two use cases Place Order and Track Order and both contain customer validation.

• Customer validation could be factored out, resulting in:

Validate Customer

<<include>>

<<include>>

Track Order

Place Order

Customer


Generalization/Specialization Relationship

• Suppose there is more than one version of a use case, and that the different versions have some things in common and other things that differentiate them

• The general notation is

Specialized use case name

Generalized use case name


Generalization/Specialization Relationship

• Example. Figure 3.14: specializations of RegisterCarSharer

Manually add car sharer

Register car sharer

Transfer car sharer from web-server

Car match administrator

Add car sharer web service

Third party


Generalization/Specialization of Actors

• Generalization can be applied to Actors.

• Example. Suppose for the department chair, who is a member of the faculty, there are some special duties

Faculty

Chair

Assign Grades

Manage Sections

Note that the Chair can do everything a faculty member can do, but also the Chair manages the sections of courses the department offers.


Generalization/Specialization of Actors

• What use cases can a Faculty execute?

• What use cases can a Chair execute?

Faculty

Chair

Assign Grades

Manage Sections


Extend Relationship

• The extend relationship is typically used for optional behaviour

• Extend is used to separate optional from mandatory behaviour

• Under a specified condition the base use case is extended with the behaviour specified in the extending use case.

• We say the extending use case is dependent on the base use case (note the directed line in the drawing)


Extend Relationship

• Process Sale collects the payment from the customer. Suppose payment via a gift certificate is considered an exceptional case, or for some reason we don’t want to alter the Process Sale use case

<<extend>>

Handle Gift Certificate Payment

Cashier Payment, if the Customer presents a gift certificate

Process SaleExtension Points:

Payment


Extend Relationship

• Process Sale declares/states “Payment” is an extension point, but Process Sale does not know anything more about this - the condition, the name of the other use case, …

<<extend>>

Handle Gift Certificate Payment

Cashier Payment, if the Customer presents a gift certificate

Process SaleExtension Points:

Payment


Example: Handle Gift Certificate Use Case

• Use Case UC7: Handle Gift Certificate

• Trigger: customer intends to pay with a gift certificate

• Extension Points: Payment in Process Sale

• Level: subfunction

• Main Success Scenario:

1. Customer gives gift certificate to cashier

2. Cashier enters id for gift certificate

3. System verifies certificate


Example: Processing a Sale at a Cash Register

• Use Case UC1: Process Sale• Primary Actor: Cashier• …• Preconditions: Cashier is identified and authenticated• Postconditions: Sale is saved…Commissions recorded…Payment

authorization approvals recorded• Extension Points: Payment, step 7.• Main Success Scenario:1. Customer arrives at POS checkout with goods and/or services to purchase2. Cashier starts a new sale3. Cashier enters item identifier4. System records sale line item and presents item description, price, and

running total. Price calculated from a set of price rules.Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated…

There are no substantive changes to the Process Sale use case

Why would we use extend instead of include?

Sept 200592.3913 Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation...

Documents

Transcript of Sept 200592.3913 Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation...