Scenarios and Use Cases

Dr Kristin Stock

Outline

1. Object Oriented Systems Analysis, Modelling

and Design
2. UML
3. Use Case Diagrams
4. Advanced Use Case Diagram Features
5. Describing Use Cases
6. Additional Tools
7. Case study: COMPASS scenarios and use cases

1. Object Oriented Analysis,

Modelling and Design

SDLC: Methodologies
Methodology: a formalized approach to
implementing the SDLC
Categories
By area of focus
Process oriented
Data centered
Object-oriented

By sequencing and emphasis of phases:

Structured
Rapid action development
Agile development

Object-Oriented
Systems Analysis & Design
Modular we use modules known as objects
that encapsulate both data and process
We decompose problems into objects that
combine both

OOAD is Use-case Driven

Use-cases are the core of the methodology
How the user interacts with the system
to perform some activity.
Inherently simple because only one process
at a time.

OOAD uses 3 Views

Functional how the system
behaves from the perspective of
the user
Road

Structural - the objects the system

uses
Road

Behavioural How the objects

Railway

Footpath

OOAD is Iterative and

Incremental
Functional

Behavioural

Gradual refinement of models

from all three views

Structural

Important Concepts in
OOAD

Classes
Objects
Methods
Messages
Encapsulation
Inheritance
Polymorphism

Classes and Objects

Object (instance):
instantiation of a class
Representation of a real
world object
Attributes: information that
describes the class
Behaviours: things the
object does
State: values at a point in
time

Road
name
speed limit
width
surface
widen
change surface
change speed limit
open
close

Methods & Messages

Methods: implement the
behaviour of a class
Messages: information
sent to an object to trigger
a method (procedure call)

Road
name
speed limit
width
surface
widen
change surface
change speed limit
open
close

Encapsulation & information

hiding
Encapsulation: combination
of process & data
Information hiding:
functionality is hidden

Road
name
speed limit
width
surface
widen
change surface
change speed limit
open
close

Inheritance
Inheritance
General classes are created
(superclasses)
Subclasses can inherit data
and methods from a
superclass
Abstract classes are not
instantiated.

Road
name
speed limit
width
surface
widen
change surface
change speed limit
open
close

Polymorphism & dynamic binding

Polymorphism: the same
message can have different
meanings
Dynamic binding: type of
object is not determined
until run-time
Contrast with static
binding: type of object
determined at compile time

2. Unified Modelling Language

UML

The Unified Process

A specific SDLC methodology.
A two-dimensional process consisting of phases
and workflows
Phases are time periods in development
Workflows are the tasks that occur in each phase
Activities in both phases & workflows will overlap

The Unified Process

Unified Process Phases

Inception (similar to Planning Phase)
Feasibility analyses performed
Workflows vary but focus is on business modeling &
requirements gathering

Elaboration
Heavy focus on analysis & design developing models
Other workflows may be included

Construction: Focus on programming

(implementation)
Transition--Focus on testing & deployment

Unified Modeling Language

Provides a common vocabulary of objectoriented terms and diagramming techniques
UML is not the only modelling
language/notation (flow diagrams, data flow
diagrams, ER diagrams, etc), but is now the
most popular.
Models are logical; i.e., independent of how
they are implemented (manual or
computerized).

OOAD Views
Functional
How the
objects
interact

How the
system
behaves from
the
perspective
of the user

Behavioural

Gradual refinement of models

from all three views

The
objects
the
Structural system
uses

UML Diagrams
Represent the
data and static
relationships in
an information
system

Depict the
dynamic
relationships
among the
instances or
objects that
represent the
business
information
system

3. Use Case Diagrams

What are Use Case Diagrams?

The first step in turning the requirements into
functional models.
Model how a user interacts with a system to
perform an activity.
Very high level no details on process, structure,
etc.

Example Use-Case

Library Book Collection

Management System
Use Case Diagram

Elements of Use-Case Diagrams

Actors: users
or other interacting systems
Associations: lines to connect actors and usecases
Interactions, inclusions, extensions or
generalizations

Use-case:
a major process in the system
that gives a benefit to the users
Subject boundary: a named box that depicts the
scope of the system
An association relationship: links an actor with the

Identifying Major Use-Cases

Review the requirements definition
Identify the subjects boundaries
Identify the primary actors and their goals
Identify the business processes and major usecases
Carefully review the current set of use-cases
Split or combine some to create the right size
Identify additional use-cases

Scenarios
A story about an example user and use of the
system.
Very useful for helping you think about use
cases.
Mrs Smith likes to have her car serviced once a year or
every 10,000 kms, whichever is sooner, and is very
concerned that she not leave it too long. She would
like to be reminded of the need for the service, but
does not use any technology other than a basic mobile
phone..

Bridge the gap between requirements and use

cases.

Actors
Roles that interact with the IT system
Including external systems
Those who only receive from the system are
also actors

Time can also be an actor

Triggering timed processes

The role using the system is the actor

e.g. If a customer service rep (CSR) acts on
behalf of the customer then CSR is the actor,
not Customer

Role Maps and Generalizations

A role map is a use case diagram that shows only

actors
Central diagram to depict users across the whole model

Can use generalization to show overlapping roles

May partially overlap

One role may completely encompass another
Partial overlaps can be expressed using abstractions
Can simplify use case diagrams by reducing the
number of associations

158.225 Systems Analysis and Design 2014

30

Actor Generalization
Overlapping role
(abstraction)
Accounting
Staff

Accountant
Bookkeeper
Specialized roles

concrete role
Customer
Service Rep

Customer
Service
Manager

encompasses the
role above

Use Case Packages

Collections of use cases and the diagrams that
describe them
Group related use cases into a folder
Could group by main actor
Or group by business use case
Or group using another approach

Name a package with a noun phrase related to

its use case contents

Use Case Diagram with Packages

Card Applications
Customer
Service Rep

Actor
VERIFY

Credit Updates
CSR
Manager

How Many Use Cases in a

Project?
No rules
Jacobsen recommends about 20 for a 10 person-year
project
Fowler reports about 100 for a similar sized project

Relate use cases to release plan

Roll out at least one use case (or use case
scenario) in each release
Release frequency may impact on use case size
and number

Key Business Classes

Concepts from the use cases become classes in the
structural model
Peace
Committee

handles

Case

generates

resolved through
Peace Committee
Member

Peace
Gathering

Payment

4. Advanced Use Case

Diagram Features

Advanced Use Case

Features
Increase reuse in the use case model
Certain identical steps may appear in more than
one case
Extract into an include use case

A use case may enhance one that already exists

Add an extend use case

Several use cases are variations on a theme

Put general rules in a generalized use case

Stereotypes and Actors

A stereotype is an extension of a UML
feature
You can add your own

A stereotype name appears in guillemets

These are guillemets

One context in which we might use this is to

define an actor that is not shown as a stick
figure
Actor

Can be used to differentiate system

actorsSystem
Messaging
from human actors

Relations in Use Case Diagrams

An include relationship: Represents the
inclusion of the functionality of one use case
within another
An extend relationship: Represents the
extension of the use case to include optional
behavior.
A generalization relationship: Represents a
specialized use case to a more generalized one.

include Use Cases

Check
Available
Seats

include

Included / inclusion use case

include

Change
Reservation

Make
Reservatio
n

base use case

Agent

extend Use Cases

Where we add requirements to an existing use case without
changing the original use case
Original use case is stand-alone
Extending/extension use case is not

Good for:
Seldom-used options
Customizing generic products
Breaking out alternate flows

Need to define
The point where the base use case is extended
The condition for doing so

extend Use Case Diagram

Make
Reservation
extension points
Set seat class
Agent

Condition: {passenger requested 1st class}

Extension point: Set seat class

extend

Make 1st class

reservation

Generalized Use cases

Can be abstract or concrete
An actor could use a concrete generalized use case

Pool common features from concrete specialized

use cases
e.g. business process such as credit card validation

Override or extend aspects of the use case

Different cards may require different handling but
the process is much the same

Generalized Use Case

Example
Deposit
Check

Deposit
Check Via
Teller

contains
generic
steps

Teller

contain overriding
or additional steps
Deposit Check
via ATM
Bank
Customer

http://q.xorro.com/pndk

5. Describing Use Cases

Describing System Use Cases

System use cases are typically described

with text
They may also optionally be described using

Activity diagrams
Decision tables
Decision trees
Other artifacts

Use Case Description Templates

Incorporate best practice

Institutionalize practice within an organization
Can be customized to work within a given organization
Simple narrative to capture workflows

Basic flow
+
Alternative success flows
+
Exceptional (error) flows

Example Template (main)

Name, Perspective, Type

Brief description (one paragraph)
Rules of precedence (triggers, pre-conditions)
Post conditions
Extension points
Priority
Status
Dates (expected, actual)
Context diagram
Flow of events
Basic flow
Alternate flows
Exception flows

Example Template
(supporting)
Special requirements (non-functional / constraints)
Related materials (links)

Activity diagram
User interface
Class diagram
Assumptions
Information items
Prompts and messages
Business rules
External interfaces
Related artifacts

Documenting Basic Flow

The ideal application of the use case

Tell a story users narrative of interaction
Simple subject-verb-object sentences
Consistent tense (present or future)
Each step is testable and traceable
Maximum 9 25 steps
Include reference to validation
Refer to merged fields (e.g. whole customer
record, not each line)

Basic Flow Example

Review Case Report (partial)
The System displays a list of resolved cases that have not
been reviewed
The user selects a case
The system validates that a case is payable
The system determines the payment amount
The system marks the case as payable
The system records the payment amount
The system checks the Cash fund records to ensure that
adequate funds exist
The system records the fact that the case has been reviewed

Documenting Alternate Flows

Scenarios not covered in the basic flow that still

realize a user goal
Recoverable errors / optional or alternative
activities

Options (e.g. same day delivery)

Tools (e.g. spell check)
System state (e.g. item out of stock)
Data entry errors / revisions (e.g. funds too low for
that withdrawal amount)

Alternate Flow Issues

For each alternate flow, you need to identify:
Trigger
What event or decision causes the alternate flow

Divergence point
Where it occurs in the basic flow

Convergence point
Where it returns to the basic flow

Documenting Exception
Flows
Error conditions that lead to the user abandoning
their goal
User cancels transaction
System errors force transaction cancellation

Usually no convergence point

use case ends in failure

6. Additional Tools

Decision Tables
Describe the system responses to a number
of interrelated factors
Not needed if factors can be evaluated
separately
Table lists all possible situations and how the
system treats them
Accounts for all possible combinations of
factors
Can be used to create test cases

Decision Table Example

Life insurance factors

Decision Trees
Alternative to a decision table
Using a tree diagram rather than a table

Condition/Response Table
If conditions can be evaluated one by one
rather than in combination, use a
condition/response table
Condition

Response

Under minimum

No tax payable

Minimum - $18,000

Tax bracket A

$18,000.01 - $60,000

Tax bracket B

$60,000.01 - $500,000

Tax bracket C

Over $500,000

Tax bracket D

7. CoMPASS Case Study

System Goals
Specifically a system for advanced search and
discovery of scientific resources:
journal papers
data sets
web services that implement scientific models.

A knowledge infrastructure.
The creation of an ontology was central.
Ontology = structure for describing knowledge
using a formal (logical) notation that allows
reasoning.

Scenario 1

1.1 Knowledge Discovery Scenario

Jane is a marine scientist and wants to buy equipment to

study a particular phenomenon, about which she has little
knowledge. She wants to find ALL the instruments that are
capable of studying that phenomenon and knowledge about
how to use those instruments and of how that phenomenon
has been studied in the past. She is also interested in
gathering journal articles and spatial datasets of past research
on this phenomenon within her specific study area.

Scenario 2

1.2 Knowledge Use Scenario

Jane has discovered that there has been a lot of research on

this phenomenon in the past, but that a new measurement
instrument has been developed that measures this
phenomenon to a much greater accuracy and which has not
been used in her study area before. She wants to compare
research she will undertake with this new instrument to all
the earlier research undertaken by various research groups.
She needs to collect the data of this past research, and in
some cases reformat the data, and do some statistical
analysis that compares the past results with her data.

Concept Map

Workshop Competency
Questions
For a specific instrument one wants to know:
What does it measure?
What is the accuracy or precision?
What environmental parameters are required for successful operation? (e.g. in
ocean water salinity can be measured with conductivity, but in brackish water a
chemical measure might be more sensible.)
Who supplies the instrument?
Who has used the instrument?
What do I get for free?

For a specific survey one wants to know:

What instruments do I have to use?

Which resolution do I need?
What are the advantages and disadvantages of available/used instruments?
What measurements have been made (in the past)?
Which instruments were used?

Summary
UML is a modelling notation that enables OOAD.
A collection of different types of diagrams that
are used together.
Use case diagrams give a high level functional
view of the system requirements.
Use scenarios to connect functional requirements
to use cases.