Transcript Document

Object Oriented
Software Development
2009-2010
Use Case Modelling
OOSAD Booklet Chapter 5
Lecture: Week 5
Brian Farrimond
Session Aims



Understand the purpose of Use Case
diagrams and when they are used.
Differentiate between scenarios and UseCase diagrams
Draw Use Case Diagrams and document
them
2
Use Case Model


Shows the Tasks in a system
Shows the Actors in a system


initiators of a task and those who benefit
from the task
Shows the system boundary
3
Example Use Case Model
Watch
ReadTime
WatchUser
SetTime
ChangeBattery
WatchRepairPerson
4
Use Case components

Actors
WatchUser

Use Cases

Supporting Description
ReadTime
blah blah blah blah blah blah blah blah blah
5
Exercise 5.1 page 74

What are the tasks (functions) of an ATM
(Cash dispenser machine)?






Show balance
Dispense cash
Print mini-statement
Print receipt
Read card details
imperatives
Who might be the Actors?
6
Example Use Case Model
ATM
Display balance
Customer
Dispense Cash
Load Money
Bank Employee
7
Exercise 5.2 page 75

Which of the following are valid use case names:





??
Insert a new item
Re-order level
Increase the temperature
Increased temperature
Buy now
Page up
8
Identifying Use Cases
1. Identify Actors
2. Identify Scenarios
3. Identify Use Cases
4. Identify relationships among
Use Cases
9
Actors




Actors represent external entities that interact
with the system.
Actors may be human or an external system
(but still shown as a stick person).
A human actor is represented by a role (eg
customer)
A use case (task) is always initiated by an Actor
10
Exercise – Identify Actors
Chris has an ancient Nokia 3310 mobile phone, on
which he can make phone calls, store numbers, send
and receive sms text messages.
(it doesn’t have a camera, or colour, or WAP capabilities, but he is
still happy with it since he comes from Yorkshire and it is CHEAP
to run)
Possible Actors are:
1. PhoneUser (NOT Chris, who is an instance of
phoneUser)
2. PhoneNetwork (the phone talks to the phone
network)
11
Identifying Scenarios

A Scenario is a concrete, focussed
informal description of a single feature of
a system from the viewpoint of a
single actor.
Example: Some scenarios for borrowing a
book from a Library
12
Mark tries to borrow the library’s 1st copy
of “The Jelly-baby diet” but
is refused because he has
exceeded his book allowance
Sandra borrows the library's 3rd copy
of “Jerboa’s make good pets”,
when she has no other book out on loan.
The system is updated accordingly
Invent another scenario for this
use case
13
Use Cases
“A Task-Coherent unit of functionality”



A scenario is an instance of a Use Case
A use case is initiated by an Actor
A use case refers to a particular task (e.g.
Borrow book, Admit patient)
14
Exercise 5.4 page 81
15
Exercise 5.5 Which Use Cases are
these scenarios of?
1.
2.
3.
4.
James tries to enrol on the BA course but
his A-level grade in English is too low so
he is rejected
Register
on course
Asif has had enough of Computer
Networks and so transfers successfully
into Software Engineering instead.
Eileen has passed the first year and so
can progress into the second year so she
registers for the OO Software
Development module.
Janet tries to leave the Homer module to
take the Aristotle module but is too late.
Register
on module
Student
Swap
modules
16
Documenting a Use-Case
Use Case Name
Participating Actors
Entry condition
Flow of Events
Borrow Book
BookBorrower
Librarian
The BookBorrower presents a book and Library
Card to the Librarian at the issue desk.
1. The Librarian uses a bar-code reader to enter
the BookBorrower details from the Library card.
2. The system displays the Bookborrower status (fines
due, books on loan, borrowing limit)
3. If the Bookborrower has not exceeded their limit the
Librarian scans the book and the system
records the loan…
17
Documenting a Use-Case
Flow of Events
Exit condition
Must be true on exit
Special requirements
…..…continued
(The system records the loan AND the
BookBorrower leaves with the book )
OR (the bookborrower leaves without the
book and no loan is recorded).
The Bookborrower must be a student or staff
member of the University
See example on page 85 – Exercise 5.6
18
Exercise 5.6 (see p 85)
Which of these scenarios are handled correctly by the
description on page 85?
i.
The account clerk prints the bill for John Reeves with ID
number 1236540. Mr Reeves is a basic customer.
ii. The account clerk needs to print the bill for Joseph
Johnston but does not know his account number.
Error on page 86: “use cases” should be replaced
by “scenarios”
19
Exercise 5.6 (see p 85)
Which of these scenarios are handled correctly by the
description on page 85?
iii. The account clerk prints the bill for Jim Longstreet who is
a bonus customer whose first 100 units are at the special
bonus price.
iv. The account clerk doesn't print the bill for Amelie Harris
when he sees that there is no charge since she has not
used any units. He prints an advisory note instead.
20
System
boundary


Note that use
cases are
inside the
system and
actors outside
it
Could regard
use cases as
“buttons” on a
GUI
Draw this in
StarUML
21
Multiple systems

We can show more than one system on a use
case diagram if it helps to understand the
connection between them.
22
When should actors be
represented as classes?


Actors are outside the system – as the use case
diagrams show
But we make classes for them if:


we need to record information about them e.g. how
many books an actor has borrowed
the actor represents an external system. The actor
models the interface with the external system. The
corresponding class will have methods our system
can use to interact with it. E.g. client- server system
23
Connections with Classes

How do Use cases link with Class
Diagrams?


They show a complementary view of the
system
The system may record data about Actors,
which become Classes
Not all Actors become Classes!!
24
Extensions to use case symbols




Academics cannot leave things alone
They make a reputation / justify their existence
by tinkering with what already works
We shall look at two extensions to use case
symbology which may/may not be useful
The prime practical aim should be to ensure
the diagrams make sense to the non-technical
clients
25
Use cases as reusable
components: <<include>>

Shows that logging in is an activity that both
paying bills and checking balance require
26
Use cases as reusable
components: <<include>>


May confuse the client if used from the beginning
May be useful if added at detailed design stage
27
Identifying variations in a use
case: <<extend>>


To be used when a use case covers quite different
scenarios
Argued that may be clearer to show these
alternatives as subsidiaries of a main use case
28
Identifying variations in a use
case: <<extend>>

It could be argued that <<extend>> not needed
since the use case description can cover the
various scenarios
29
When use Use Cases?

Requirements analysis 

Planning


Helps in estimating effort / prioritisation
Design


Finding Actors, & functionality
Refining Class Diagram – “which objects
need to collaborate to implement a Usecase”
Verification

Verify system performs as required.
30
Possible Problems

Focus on Functions rather than objects


May not be Object Oriented solution!
Possibility of missing requirements.

Not all requirements can be obtained this
way.
Oh No!
31
Summary





Technique for finding functionality /
Actors (Beneficiaries)
Model of functionality
Covers all scenarios for a task
Useful throughout development
Documentation
32
Exercises

Exercise 5.7 page 91
Exercise 5.8 page 94

Read CW 2 specification

33