3. use cases

Object-Oriented Software Systems Engineering – Chapter 3

Use Cases

Chapter 3


Objectives

In this chapter we will: Describe use case modelling Introduce use cases and actors Discuss relationships between use cases Introduce use case descriptions


Use Case Modelling

The purpose of use case modellingto decide and describe the functional

requirements of the systemto give clear and consistent description of what

the system should doto provide a basis for performing tests that

verify the systemto provide the ability to trace functional

requirements into classes and operations

Use case model represents use-case view is described by a use-case diagram


Use Case Modelling

Use Cases are described using both text documents and diagrams

Use-case modelling is primarily an act

of writing text NOT just drawing diagrams


Use Case Modelling

Definition of use caserepresents a complete functionality as perceived by an actora set of sequences of actions a system performs that yield

an observable result of value to a particular actor

Characteristicsis always initiated by an actorprovides tangible value to an actor (observable not

necessary salient)is complete - use case is not complete until an end value is

produced even if several communications occur along the way

Scenario’s are instances of use-casesA specific sequence of actions that illustrate behaviourYou’ll find primary scenarios and secondary scenarios


Use Case Modelling – terms & concepts

Name of System

A Use CaseAn Actor



The system boundary defines responsibilityblack box that provides use-caseswithin the system boundary

what the system does but not how the system does Use-cases

a description of a set of sequence of actions, including variants that the system performs to yield an observable value to an actor

a set of scenarios



Actorrepresenting a role that someone might play, rather than

a particular individualexternal entity that has interest in interacting with the

system

Interactiona communication relation between an actor and a use

case


Identifying Use Cases and Actors

What functions does the actor require from the system?

Does the actor need to read, create, destroy, modify or store some kind of data in the system?

Does the actor have to be notified about events in the system, or does the actor need to confirm with the system for something?

Could the actor’s daily work be simplified or made more efficient via new functions in the system?

What input/output does the system need? Can these requirements be handled by one actor

or someone else as well?


Use Case Modelling – organising use cases

UML use-case diagram

Communication associations:connect actors to use cases

Manager

UseCase 1

User 2UseCase 3

User 1

UseCase 2

An Actor A Use Case

Communication Association


Use Case Modelling – types of relationships

Relationships between actors

generalization - specialization

Library User

Student Lecturer


Use Case Modelling – types of relationships

Two stereotypes of dependency relationship in use cases

<<include>>

BA

Include specifies that the source use case

(A) explicitly incorporates the behaviour of the target (B)

A includes the behaviour of B

Extends specifies that the target use case

(B) extends the behaviour of the source (A)

A is extended from B by adding

some actions

<<extends>>

BA

Extension points


Use Case Relationships

Extend and Uses relationship - different forms of re-use Extend relationship - accounts for optional behaviour Include relationship -uses or include relationship

one use case uses another use case (reuse by composition)

Place orderExtension pointsset priority Vaildate user

Place rushorder

<<extends>>(set priority)

<<uses>>Check password

Retinal scan


A Simple Use Case Diagram of Librarypart 1

Library Member

Search for book

Borrow a copy of book LibrarianRefuse

loan

Member of Staff

Return a copy of book

Reserve a book

Library System

<<extend>> over limit

Update catalog

Extend loan

<<include>>

<<include>>


Use Case Diagram - order processing

Return product

Update product quantities

Place order extension points

set discount

<<extend>>

Give product information

Update account

Customer discount

<<include>><<include>>Cancel order

Get status on order

Run sales report

Customer

Sales Rep

Inventory system

Accounting system

<<include>>

<<include>>

<<include>>

<<include>>


Use Case Diagram - course management

Student

Register for courses

Billing system Create course

catalogue

Lecturer

Select courses to

teach

Registrar

Request course roster

Maintain information

Maintain course’s infor.

Maintain lecturer’s infor.

Maintain student’s infor

Course Management System


Manager

UseCase 1

Actor 2 UseCase 3

Actor 1

UseCase 2

Use Case diagram

Class 1Class 2

Class 3 Class 4

c3: objectc2: object <<Actor>>

User

0: event

1: operation 2: operation

Class diagram

Sequence diagram state 2

state 1

State diagram


Manager

UseCase 1

Actor 2 UseCase 3

Actor 1

UseCase 2Use Case diagram

Class 1Class 2

Class 3 Class 4

c3: objectc2: object <<Actor>>

User

0: event

1: operation 2: operation

Class diagram

Sequence diagram state 2

state 1

State diagram

state 2

state 1

State diagram


Use Case

A use case is a starting point You may not know very much about a subject,

write down what you do know Then you need to find out the detail that you do

not know but that you need to know in order to solve the problem

When we have as much detail as we need, we can produce Use Case Descriptions


Use Case Descriptions

A use case description: The text to describe a particular use case

interaction - in the form of a 2-way dialogue between the actor and the system

Provides the supporting detail for the use case diagram - not to be started until the diagram is complete/nearly complete

Also known as Use Case Scripts or Use Case Scenarios (beware - the latter has another meaning)


What to describe

Describe the most common/normal form of interaction first - the basic course

Describe possible variations separately - the alternative courses

The script should be in a conversational style:actor requests….System responds by….Actor does…..And so on..


Example of a Use Case Description

In the video rental shop, the interaction between Counter Assistant and Rent Video use case may be:

Actor Actions System Response1. Customer tenders video(s) to be

rented and membership card

2. Counter assistant enters member 3. System provides member details and

no.into system status of loans and fines

4. Assistant enters identification of each

video to be rented 5. System accepts ids and gives fee payable

6. Assistant requests payment, takes

money and enters payment made 7. System logs payment details


Guidelines

Include a series of numbered sections or steps which describe noteworthy events and possibly related context, constraints and business rules

Steps may alternate between actor and system, or may be a series of consecutive steps taken by either of them

Written from the user’s point of view Written in the vocabulary of the user


Conversational Style

This conversational style script (as if for a theatre play) is a good compromise between the advantages and disadvantages of other methods:

It is quick and easy to write (important for capturing early, outline information)

It is quick and easy to read and to understand It encourages concise-ness It identifies the required sequence of actions It highlights causes and effects


Essential Use Cases

These are used during the feasibility and analysis stages of the project

The aim is to be free of implementation detail to show the essence of the business requirements (the conceptual model)

Enables analysts, developers, users and clients to understand the scope of the problem and the processes required


Real Use Cases

Now the Essential Use Cases will be used as the basis for lateral, creative thinking with the opportunity for new ideas on how to create the system

Real Use Cases are used to document the design of the project

how it will work in reality

For a user interface it may include prototype screen shots, print layouts, form layouts, menus

For a system interface it may include file layouts


Template Sections

The following sections are normally included:

Use Case - its identifier/name Actors - list of actors involved. Show which one

initiates the use case Overview - short outline description summarising

the use case Type - category of the use case Cross References - use case relationships

(covered later)


Categories of Use Cases

1. Primary - major common process For example: Rent Video

2. Secondary - minor or rare processes For example: Request to supply unstocked New Video

3. Optional - processes that may or may not be used


Alternative Courses

Alternative courses can describe alternative events to the typical story

These are the less common, the exceptional or error cases

Place all the alternatives after all the typical course of events

For example:7. Customer pays clerk by cash or credit

Alternative Courses

7. Customer has unpaid late charges and will not pay them. Collect payment or cancel rental transaction


Use Case Descriptions

Review of use case descriptions:

Use Case descriptions supply the detail of system requirements

Conversational scripts are used to describe the interactions between actors and use cases

The basic course may be followed by 1 or more alternative courses

Essential Use Cases are used during Analysis, Real Use Cases are used during Design


Summary

In this chapter we have: Described use case modelling Introduced use cases and actors Discussed relationships between use cases Introduced use case descriptions

3. use cases

Documents