Uml Use-case Lecture

8/9/2019 Uml Use-case Lecture

1/47

1Spring 2005Specification and Analysis of Information Systems

Eran Toch

http://www.technion.ac.il/~erant

Session 3: Specifying Requirementswith Use Case Diagrams

Spring 2007


2/47

2

Outline

Introduction

Use Case Diagrams

Writing Use Cases

Guidelines for Effective Use Cases


3/47

3

Where are we?

Phase Actions Outcome

Initiation Raising a business needBusinessdocuments

RequirementsInterviewing stakeholders, exploring

the system environment

Organized

documentation

Specification Analyze the engineering aspect of thesystem, building system concepts Formalspecification

DesignDefine architecture, components, datatypes, algorithms

FormalSpecification

ImplementationProgram, build, unit-testing, integrate,documentation

Testable system

Testing &Integration

Integrate all components, verification,validation, installation, guidance

Testing results,Working sys

Maintenance Bug fixes, modifications, adaptationSystemversions

Introduction | Diagrams | Writing | Guidelines


4/47

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 iterativeprocess.



5/47

5

Requirements vs. Design

Requirements: What the system

should do

More abstract

Design:

How the systemshould do it

More detailed



6/47

6

Types of Requirements

Visible Functional Requirements The system will deliver cash to thecustomer

Cash will be delivered after cardwas taken out

Qualitative Requirements The authorization process will take

no more than 1 sec

The user interface will be easy touse

Hidden Requirements Database maintenance processes

will occur every night

QualitativeRequirements

HiddenFunctional

Requirements

Functional

Visible

Requirements



7/47


8/47

8

Use Case Diagram Objective

1. Create a semi-formal model of the functionalrequirements

2. Analyze and define: Scope

External interfaces Scenarios and reactions



9/47

9

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?)



10/47

10

Use Cases as Means of Communication

The use case should stimulate a discussion aboutwhat the system should do, mainly with peoplewho are outside of the development team.


Customers DesignersUsers


11/47

11

Outline

Introduction

Use Case Diagrams

Writing Use Cases



12/47

12

Example

A Simple Example

ActorsUse CaseSystem

boundary


Association


13/47

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



14/47

14

Example

Actors can be generalized

The child actorinherits all use-casesassociations


Should be used if (and onlyif), the specific actor hasmore responsibility than thegeneralized one (i.e.,associated with more use-cases)


15/47

15

Linking Use-Cases

Linking enables flexibility in requirementsspecification Isolating functionality

Enabling functionality sharing

Breaking functionality into manageable chunks

Three mechanism are used: Include

Extend

Inheritance



16/47

16

Use-Case Levels

User goals

Perform

Sale

Choose

Products

Fill-in

billing info

Sub-functionality


Base Use Case:Used directly bythe user

Alistair Cockburn Writing Effective Use Cases


17/47

17

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 specifiedin the base.


PerformSale Fill-in billinginfo

Example


18/47

18

Extend Graphical Representation

The base use case can incorporate another usecase 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 Sale

After checkout

Gift wrap

Products

Product is a gift

Example


19/47

19

Example: Amazon

Product Page

Review Writing

Shopping Cart



20/47

20

Example contd


SearchProduct

Navigate

Deals

Checkout

Handle OrderStatus

Login Register

ViewProductDetails Write

Review

RankSupplierinclude

include

include

include

extenduser is nota member

extend

extend

After pagegeneration

Add tocart

extend


21/47

21

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


22/47

22

Generalization Hazards

Combining generalizations of actors and use-cases can be dangerous

Bad: Undergrad can submitthesis

Good: Only graduatestudent can submit thesis



23/47

23

Example: Phone Company Operational System

The Cellular Phone

Who are the actors?

External Phone companies

Oranges objective: Build a system that handles SMSmessages, handles calls (for 2 and 3 generationphones), including conference calls and multiple callsfrom a single phone. The system must support users onthe move.



24/47

24

Example: Cell Company System



25/47

25

Outline

Introduction Use Case Diagrams

Writing Use Cases



26/47

26

Structure of a Use Case Specification

NameActors

Preconditions

Post conditions

Success Scenario

Alternatives flows


Alistair CockburnWriting EffectiveUse Cases

Trigger


27/47

27

Triggers

What starts the use-case? Examples: Customer reports a claim

Customer inserts card

System clock is 10:00



28/47

28

Preconditions

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

Examples User account exists

User has enough money in her account

There is enough disk space



29/47

29

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 isgranted by the user

Success guarantee What happens after a successful conclusion of the use-case.

Examples: The file is saved; Money is transferred



30/47

30

Success Scenario

The success scenario is the main story-line of theuse-case

It is written under the assumption that everything isokay, no errors or problems occur, and it leadsdirectly to the desired outcome of the use-case

It is composed of a sequence of action steps Example:

1. Administrator enters course name, code and description

2. System validates course code

3. System adds the course to the db and shows a confirmation message

Interactionstep

ValidationStep

Internal ChangeStep

(plus) InteractionStep



31/47

31

Guidelines for Effective Writing

Use simple grammar Only one side (system or actor)is doing something in a singlestep

Write from an objective pointof view Bad: Get the amount form the user

and give him the money

Any step should lead to someprogress Bad: User click the enter key

System Actor

Actor asks for money

System asks for amount

Actor gives the amount

System produce the money



32/47

32

Steps contd

Branches: Ifthe user has more than 10000$ in her account, the systempresents a list of commercials

Otherwise

Repeats:1. User enters the name of the item he wishes to buy

2. System presents the items

3. User selects items to buy

4. Systems adds the item to the shopping cart

5. User repeats steps 1-4 until indicating he is done



33/47

33

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



34/47

34

Alternative Flows

Success

Scenario

Shortcuts

Exceptions

Endpoints

Used to describeexceptionalfunctionality

Examples: Errors

Unusual or rarecases

Failures

Starting points

Endpoints Shortcuts

Starting points



35/47

35

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



36/47

36

Writing Include

If a base use-case include another use-case, wewill add a reference as a step:1. System presents homepage

2. User performs login to the system

OR



37/47

37

Writing Extend

Scenarios do not include direct references

Instead, they include extension points, such as:User enters search string

System presents search results

Extension point: results presentations

OR

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



38/47

38

Outline

Introduction

Use Case Diagrams

Writing Use Cases



39/47

39

How to Model?

print

saveBullets

format

loadSave

as

preview

File

action

s

Formattin

g actions

Viewing

Actions

Font

forma

t

Paragraph

format

Bottom-up ProcessTop-down Process

Starting with throwing allscenarios on the page, andthen combining them:

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


40/47

40

How to Model contd

Most of the analysis process are actually

Combined


41/47

41

Combining Processes

NumberLimit: 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



42/47

42

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



43/47

43

More Guidelines

Factor out common usages that are required bymultiple use cases If the usage is required use

If the base use case is complete and the usage may beoptional, consider use

A use case diagram should: contain only use cases at the same level of abstraction

include only actors who are required



44/47

44

Scope

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

Alistair Cockburn Writing Effective Use Cases

Topic In Out

Any non-software parts of the system

Statistical analysis of logs

Interfacing with credit card systems

Database cleaning processes

Backup of logs



45/47

45

When Are we Done?

When every actor is specified.

When every functional requirement has a use-casewhich satisfies it.

A tractability matrix can help us determine it:

Use Cases

Requirements



46/47

46

Moving on

Data entering and exiting the system is representedby data entities in structural diagrams.

Behavior induced by use cases can be captured inbehavioral diagrams.

Class AClass C

Class B

Class D

Use Case 1

Use Case 2Use Case 3



47/47

47

Summary

Introductionto the Unified Modeling Language (UML)

To Use Case Diagram

Use Case DiagramsDual presentation of use-cases

Include, Extend, Inheritance

Writing Use CasesPreconditions & Post-conditions

Main scenario vs. Alternative Flow


Uml Use-case Lecture

Documents

Transcript of Uml Use-case Lecture