UML Use Case Diagrams

1Spring 2005Specification and Analysis of Information Systems

Session 4:

Specifying Requirementswith Use Case Diagrams

Winter 2008

Analysis and Specification of Information Systems

Eran Tochhttp://www.technion.ac.il/~erant

2

Outline

• Introduction • Use Case Diagrams• Writing Use Cases• Linking Use Cases• Guidelines for Effective Use Cases

Introduction | Diagrams | Writing | Linking | Guidelines

3

Where are we?

Introduction | Diagrams | Writing | Linking | Guidelines

PhaseActionsOutcome

InitiationRaising a business needBusiness documents

AnalysisInterviewing stakeholders, exploring the system environment

Organized documentation

SpecificationAnalyze the engineering aspect of the system, building system concepts

Logical System Model

ImplementationProgram, build, unit-testing, integrate, documentation

Testable system

Testing & Integration

Integrate all components, verification, validation, installation, guidance

Testing results, Working sys

MaintenanceBug fixes, modifications, adaptationSystem versions

4

Source of Requirements

• Initial requirements come from the customer, by:– Documents, such as RFI/RFP– Meetings, reports

• Advanced requirements come from the analysts, after studying:– Scope and price– Feasibility (technological, organizational etc)– Prototypes

• Final requirements are stabilized in an iterative process.

Introduction | Diagrams | Writing | Linking | Guidelines

5

Requirements vs. Design

• Requirements:– What the system

should do– More abstract

• Design:– How the system

should do it– More detailed

Introduction | Diagrams | Writing | Linking | Guidelines

6

Types of Requirements

• Visible Functional Requirements– “The system will deliver cash to the

customer”– “Cash will be delivered after card

was taken out”

• Qualitative Requirements– “The authorization process will take

no more than 1 sec”– “The user interface will be easy to

use”

• Hidden Requirements– “Database maintenance processes

will occur every night”

QualitativeRequirements

HiddenFunctional

Requirements

Functional Visible

Requirements

Introduction | Diagrams | Writing | Linking | Guidelines

7

Outline

• Introduction • Use Case Diagrams• Writing Use Cases• Linking Use Cases• Guidelines for Effective Use Cases

Introduction | Diagrams | Writing | Linking | Guidelines

8

Illustration

Use Cases

• A use case is a contract of an interaction between the system and an actor.

• A full use-case model comprise of:– A diagram, describing relations between use-cases and

actors.– A document describing the use case in details

Use Case

Use case in diagram Use Case in scriptActor

Introduction | Diagrams | Writing | Linking | Guidelines

9

Objective

1. Create a semi-formal model of the functional requirements

2. Analyze and define:– Scope– External interfaces– Scenarios and reactions

Introduction | Diagrams | Writing | Linking | Guidelines

10

What Makes Good Use-Case Specification?

• Lack of ambiguity– Each requirement must be interpreted in a single manner.

• Completeness– They should cater for all current demands of the system.

• Consistency– Requirements should not conflict with each other. If there

are, tradeoffs must be detected and discussed.

• Avoid design– Requirements should raise a need, not answer it. (Why?)

Introduction | Diagrams | Writing | Linking | Guidelines

11

Use Cases as Means of Communication

The use case should stimulate a discussion about what the system should do, mainly with people who are outside of the development team.

Customers Designers Users

Introduction | Diagrams | Writing | Linking | Guidelines

12

Example

A Simple Example

Handle Message

Cellular Phone

Customer

Bill Management

Handle CallExternal Phone

Company

ActorsUse CaseSystem

boundaryAssociation

Introduction | Diagrams | Writing | Linking | Guidelines

13

Finding Actors

• External objects that produce/consume data:– Must serve as sources and destinations for data– Must be external to the system

Humans MachinesExternal systems Sensors

Database PrinterOrganizational Units

Introduction | Diagrams | Writing | Linking | Guidelines

14

Example

Actors can be generalized

The child actor inherits all use-cases associations

Should be used if (and only if), the specific actor has more responsibility than the generalized one (i.e., associated with more use-cases)

Register ClientSales Person

Institutional Sales Person

Perform Sale

Perform Business Sale

Sales Manager

Cancel Sale

Introduction | Diagrams | Writing | Linking | Guidelines

15

Outline

• Introduction • Use Case Diagrams• Writing Use Cases• Linking Use Cases• Guidelines for Effective Use Cases

Introduction | Diagrams | Writing | Linking | Guidelines

16

Structure of a Use Case Specification

Name

Actors

Preconditions

Post conditions

Success Scenario

Alternatives flows

Alistair Cockburn “Writing Effective Use Cases”

Trigger

Introduction | Diagrams | Writing | Linking | Guidelines

17

Triggers

• What starts the use-case?• Examples:

– Customer reports a claim– Customer inserts card– System clock is 10:00

Introduction | Diagrams | Writing | Linking | Guidelines

18

Preconditions

• What the system needs to be true before running the use-case.

• Examples– User account exists– User has enough money in her account– There is enough disk space

Introduction | Diagrams | Writing | Linking | Guidelines

19

Post-Conditions• A post-condition is the outcome of the use-case.• Examples

– Money was transferred to the user account– User is logged in– The file is saved to the hard-disk

• Minimal guarantee– The minimal things a system can promise, holding even when

the use case execution ended in failure– Examples: Money is not transferred unless

authorization is granted by the user• Success guarantee

– What happens after a successful conclusion of the use-case.– Examples: The file is saved; Money is transferred

Introduction | Diagrams | Writing | Linking | Guidelines

20

Success Scenario• The success scenario is the main story-line of the

use-case• It is written under the assumption that everything is

okay, no errors or problems occur, and it leads directly to the desired outcome of the use-case

• It is composed of a sequence of action steps • Example:

1. User enters product name, SKU and description2. System validates product SKU3. System adds the product to the DB and shows a confirmation message

Interaction step

Validation Step

Internal Change Step

(plus) Interaction Step

Introduction | Diagrams | Writing | Linking | Guidelines

21

Success Scenario Example

1. User enters a keyword2. System presents a set of search results, and

sponsored products, all of which include name, short description and price

3. User selects a product4. System displays a product page, including product

information, reviews and related products 5. User adds the product to the shopping cart

Introduction | Diagrams | Writing | Linking | Guidelines

22

Guidelines for Effective Writing

• Use simple grammar• Only one side (system or actor)

is doing something in a single step

• Write from an “objective” point of view– Bad: “Get the amount form the

user and give him the money”

• Any step should lead to some progress– Bad: “User click the enter key”

System ActorActor asks for money

System asks for amount

Actor gives the amount

System produce the money

Introduction | Diagrams | Writing | Linking | Guidelines

23

Steps – cont’d

• Branches:– If the user has more than 10000$ in her account, the

system presents a list of commercials– Otherwise…

• Repeats:1. User enters the name of the item he wishes to buy2. System presents the items3. User selects items to buy4. Systems adds the item to the shopping cart5. User repeats steps 1-4 until indicating he is done

Introduction | Diagrams | Writing | Linking | Guidelines

24

Use-Cases – Common Mistakes

• Complex diagram• No system• No actor• Too many user interface details

– “User types ID and password, clicks OK or hits Enter”

• Very low goal details– User provides name– User provides address– User provides telephone number– …

Introduction | Diagrams | Writing | Linking | Guidelines

25

Alternative Flows

Success Scenario

ShortcutsExceptions

Endpoints

• Used to describe exceptional functionality

• Examples:– Errors– Unusual or rare

cases– Failures– Starting points– Endpoints– Shortcuts

Starting points

Introduction | Diagrams | Writing | Linking | Guidelines

26

Alternative Flows - Example

• Errors:– “Case did not eject properly”– “Any network error occurred during steps 4-7”– “Any type of error occurred”

• Unusual or rare cases– “Credit card is defined as stolen”– “User selects to add a new word to the dictionary”

• Endpoints– “The system detects no more open issues”

• Shortcuts:– “The user can leave the use-case by clicking on the

“esc” key

Introduction | Diagrams | Writing | Linking | Guidelines

27

Outline

• Introduction • Use Case Diagrams• Writing Use Cases• Linking Use Cases• Guidelines for Effective Use Cases

Introduction | Diagrams | Writing | Linking | Guidelines

28

Linking Use-Cases

• Linking enables flexibility in requirements specification– Isolating functionality– Enabling functionality sharing – Breaking functionality into manageable chunks

• Three mechanism are used:– Include– Extend– Inheritance

Introduction | Diagrams | Writing | Linking | Guidelines

29

The “Include” Construct

• Include is used when:– Decomposing complicated behavior– Centralizing common behavior

• The base use case explicitly incorporates the behavior of another use case at a location specified in the base.

Perform Sale

Fill-in billing info

<<include>>

Example

Introduction | Diagrams | Writing | Linking | Guidelines

30

Writing Include

• If a base use-case include another use-case, we will add a reference as a step:1. System presents homepage2. User performs login to the system

OR<include: login to the system>

Introduction | Diagrams | Writing | Linking | Guidelines

31

Extend – Graphical Representation

• The base use case can incorporate another use case at certain points, called extension points.

• Note the direction of the arrow– The base use-case does not know which use-case

extends it

Perform SaleAfter checkout

Gift wrap Products

<<extend>>Product is a gift

Example

Introduction | Diagrams | Writing | Linking | Guidelines

32

Writing Extend

• Scenarios do not include direct references• Instead, they include extension points, such as:

User enters search stringSystem presents search resultsExtension point: results presentations

OR<extension point: results presentations>

• The extension use-case includes conditions in which the extension is being committed– Example: if the user belongs to the “rich clients” group– If more than two commercials were found

Introduction | Diagrams | Writing | Linking | Guidelines

33

Example: Amazon

Product Page

Review Writing Page

Shopping Cart

Introduction | Diagrams | Writing | Linking | Guidelines

34

Example – cont’d

Search Product

Navigate Deals

Checkout

Handle Order Status

Login Register

View Product Details Write

Review

Rank Supplier«include»

«include»

«include»

«include»

«extend»user is not a member

«extend»

«extend»

After page generation

Add to cart

«extend»

Customer

Introduction | Diagrams | Writing | Linking | Guidelines

35

Generalization between Use-Cases• The child use case inherits the behavior parent use case:

– The interaction (described in the textual description)– Use case links (associations, include, extend, generalization)

• Child use-case can substitute parent Use case• Overriding occurs through the textual description

Example

Handle Sale Call

Customer Representative

Tech Assistant Representative

Handle Call

Handle Technical Assistance Call

1. Transfer call to available representative2. Mark representative as busy3. Start record call4. Stop record call 5. Log call details6. Mark representative as free

Introduction | Diagrams | Writing | Linking | Guidelines

36

Generalization Hazards

• Combining generalizations of actors and use-cases can be dangerous

Undergrad Student

Graduate Student

Submit Exam

Submit Thesis

Undergrad Student

Graduate Student

Submit and Get Grade

Submit Thesis

Submit Exam

Bad: Undergrad can submit thesis

Good: Only graduate student can submit thesis

Introduction | Diagrams | Writing | Linking | Guidelines

37

Example: Phone Company Operational System

The Cellular Phone

Who are the actors?

External Phone companies

Orange’s objective: Build a system that handles SMS messages, handles calls (for 2 and 3 generation phones), including conference calls and multiple calls from a single phone. The system must support users on the move.

Introduction | Diagrams | Writing | Linking | Guidelines

38

Example: Cell Company System

3G Phone

Handle SMS Message

Cellular Phone

while talking

Handle Call

External PhoneCompany

Handle Video Call

Handle Cell Migration

<<include>> <<include>>

Handle Multiple Calls

Handle Conference Call

<<extend>>{incoming call}

<<extend>>{phone initiate call}

Handle Voice Call

Introduction | Diagrams | Writing | Linking | Guidelines

39

Outline

• Introduction • Use Case Diagrams• Writing Use Cases• Linking Use Cases• Guidelines for Effective Use Cases

Introduction | Diagrams | Writing | Linking | Guidelines

40

How to Model?

print

saveBullets format

loadSave

as

preview

File action

s

Formatting actions

Viewing Actions

Font forma

t

Paragraph format

Bottom-up Process Top-down Process

Starting with throwing all scenarios on the page, and then combining them:

Starting with an overview ofthe system, and then splittingUse-cases

Introduction | Diagrams | Writing | Linking | Guidelines

41

How to Model – cont’d

• Most of the analysis process are actually

Combined

Introduction | Diagrams | Writing | Linking | Guidelines

42

Combining Processes

• Number Limit:– The diagram should have between 3 to 10 base use-case. No

more than 15 use cases (base + included + extending).

• Abstraction:– All use-cases should be in similar abstraction levels.

• Size:– Use cases should be described in half a page or more.

• Interaction: – Use-cases which are carried out as part of the same interaction.

UCUC UC

Introduction | Diagrams | Writing | Linking | Guidelines

43

Dividing Processes

• Size:– If a use-cases takes more than a page, consider

include/extend

• Weak dependency:– If the dependency between two parts of a use-case is weak,

they should be divided.

UC

Introduction | Diagrams | Writing | Linking | Guidelines

44

More Guidelines

• Factor out common usages that are required by multiple use cases– If the usage is required use <<include>>– If the base use case is complete and the usage may be

optional, consider use <<extend>>

• A use case diagram should:– contain only use cases at the same level of abstraction– include only actors who are required

Introduction | Diagrams | Writing | Linking | Guidelines

45

Scope

• A good way to decide on the scope is by in/out lists:

Alistair Cockburn “Writing Effective Use Cases”

TopicInOut

Any non-software parts of the systemStatistical analysis of logsInterfacing with credit card systemsDatabase cleaning processesBackup of logs…

Introduction | Diagrams | Writing | Linking | Guidelines

46

When Are we Done?

• When every actor is specified.• When every functional requirement has a use-case

which satisfies it.• A tractability matrix can help us determine it:

Use Cases

Requirements

Introduction | Diagrams | Writing | Linking | Guidelines

47

Moving on

• Data entering and exiting the system is represented by data entities in structural diagrams.

• Behavior induced by use cases can be captured in behavioral diagrams.

Class AClass C

Class BClass D

Use Case 1

Use Case 2Use Case 3

Introduction | Diagrams | Writing | Linking | Guidelines

48

Summary Introduction

to the Unified Modeling Language (UML)To Use Case Diagram

Use Case DiagramsDual presentation of use-casesInclude, Extend, Inheritance

Writing Use CasesPreconditions & Post-conditionsMain scenario vs. Alternative Flow

Guidelines for Effective Use Cases

Introduction | Diagrams | Writing | Linking | Guidelines