Professional Documents
Culture Documents
COM 6030 Software Analysis and Design: - Use Cases and Activity Diagrams
COM 6030 Software Analysis and Design: - Use Cases and Activity Diagrams
COM6030 Systems
University of Sheffield
Outline
University of Sheffield
FirstUse
part
of the
course
case
model
A user-oriented approach on systems analysis.
Identify the users of the system and the tasks they
must undertake.
UML uses technical terms actors and use cases.
Actor = a user of the system in a particular role (an
actor might be an external system as well); a
customer in the ATM system is an actor.
Use case = is a task which an actor needs to
perform with the help of the system; withdraw cash
from ATM is a use case; use case may describe a
simple or a fairly complex behaviour.
COM6030 Systems
University of Sheffield
Use cases
Use cases were first proposed by Jacobson (1992) for capturing
requirements:
identify single user interactions with a system;
identify stakeholder interactions with a business;
not a good formalism for expressing control logic.
Idea is to elicit required system functionality. No prior knowledge of
system assumed:
interview the client, taking notes;
collect use cases (i.e. scenarios, examples of usage);
concentrate initially on normal flow of events;
later, look for alternative or exceptional flows;
structure the model afterwards.
COM6030 Systems
University of Sheffield
Use cases
A use case is: "a single complete interaction of a user with a
system that delivers a result of observable value"
i.e. the smallest-level business task that has meaning and
delivers something of value for the user.
Limits:
single complete interaction - accomplishes a single objective, not
multiple (upper bound);
result of observable value - accomplishes a business function,
not a code instruction (lower bound).
Positive examples:
Deliver goods, Pay Invoice, Process order.
Negative examples:
Enter password, Increase productivity, Quit menu.
COM6030 Systems
University of Sheffield
Natural language
representations
There is deliberately no specified format. Natural
language representations can be:
informally structured descriptions
pseudocode with pre, post-conditions
COM6030 Systems
University of Sheffield
Inputs:
PIN, bank system record.
Outputs:
PIN correct, PIN incorrect.
Criticality:
Validation of PIN is a key component of ATM function.
Risk:
Very high.
Dependencies: User input, communication with bank system.
COM6030 Systems
University of Sheffield
University of Sheffield
Communication association.
Generalisation relationship.
Dependency relationship.
<<extend>
>
COM6030 Systems
University of Sheffield
Actors
Actors are a fundamental component of Use Case diagrams
An actor interacts with a system to produce an observable result.
Actors are often users of a system.
Names correspond to role of actor in use case.
Actors may not necessarily be human.
A generalisation relationship may exist between actors. X is a
generalisation of Y if Y-is-a-X.
University
employee
Actor
Buyer Seller
Broker
Three actors in an
estate agency
COM6030 Systems
University employee is a
generalisation of
academics. All
academics are university
employees, but not all
university employees are
academics.
Academic
10
University of Sheffield
Use cases
System
ATM system
Actor - human
Actor
another
system
Manage
PIN
Customer
Use case
COM6030 Systems
Get
balance
Withdraw
cash
11
Bank
One can
distinguish a
Card Manager
actor
University of Sheffield
Transaction
Manage
PIN
Customer
Bank
Get
balance
Withdraw
cash
COM6030 Systems
12
University of Sheffield
Generalisations
A generalisation relationship may exist between use cases as
well as actors.
X is a generalisation of Y if Y-is-a-X.
Direction of generalisation is from specific to general.
For ATM system
Transaction
Bank
Get
balance
COM6030 Systems
Card manager
13
University of Sheffield
Requirements review
The system is specified as a set
of subsystems (only one for
ATM system).
Each subsystem consists of
a list of actors and their roles;
a list of use case descriptions;
associated use case diagrams;
activity diagrams (next slides)
optional.
Actor descriptions
Customer
Bank
Card
Manager
Inserts card; validates the PIN entered by the user against the central
record held on the bank system. Returns an output indicating that the PIN
is either correct or incorrect. If the PIN is correct then the session can
continue. If the PIN is not correct then the session will terminate, and the
card should be returned to the user.
Manage PIN
..
Get balance
Withdraw cash
COM6030 Systems
14
University of Sheffield
what they need from the system their associated use cases;
other interactions which use cases they might take part in for
someone elses benefit.
COM6030 Systems
15
University of Sheffield
Activity diagrams
Activity diagrams are useful to
describe an overall workflow of an area of the customers activities;
specify how individual use cases unfold and may depend on other
use cases (all transactions of an ATM follow PIN validation);
represent how an operation (see object specifications) could be
implemented.
The fundamental block is an activity; a transition out of an activity
normally means that the activity has been completed.
Insert card
COM6030 Systems
Validate
PIN
16
University of Sheffield
Elements of activity
diagrams
Validate PIN
COM6030 Systems
17
University of Sheffield
Insert card
Validate PIN
[incorrect PIN]
[correct PIN]
Receive card
Transaction
COM6030 Systems
18
University of Sheffield
ATM system
Insert card
Validate PIN
[incorrect PIN]
[correct PIN]
Receive card
COM6030 Systems
Transaction
19
University of Sheffield
Summary
Two key UML diagrams for requirements
analysis: use cases and activity diagrams.
Requirements specification using use case
diagrams and natural language description.
Activity diagrams to specify formally a use
case description and to show
interdependences among use cases.
COM6030 Systems
20
University of Sheffield