introduction to use cade diagram modelling

7/27/2019 Introduction to Use Cade Diagram Modelling

1/28

AISD2013

Introduction to UML


2/28

Outline

Introduction

Use Case Diagrams

Writing Use Cases


3/28

Where are we?Phase Actions Outcome

Initiation Raising a business need Businessdocuments

RequirementsInterviewing stakeholders, exploring

the system environment

Organized

documentation

Specification

Analyze the engineering aspect of the

system, building system concepts

Formal

specification

DesignDefine architecture, components, data

types, algorithms

Formal

Specification

ImplementationProgram, build, unit-testing, integrate,

documentationTestable system

Testing &

IntegrationIntegrate all components, verification,

validation, installation, guidance

Testing results,

Working sys

Maintenance Bug fixes, modifications, adaptationSystem

versions

Introduction | Diagrams | Writing | Guidelines


4/28

Source of Requirements

Initial requirements come from the customer, by: Documents, such as RFI/RFP

Meetings, reports

Advanced requirements come from the analysts, afterstudying: Scope and price

Feasibility (technological, organizational etc)

Prototypes

Final requirements are stabilized in an iterativeprocess.



5/28

Requirements vs. Design

Requirements: What the system

should do

More abstract

Design:

How the systemshould do it

More detailed



6/28

Types of Requirements Visible Functional Requirements

The system will deliver cash tothe customer

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 processeswill occur every night

QualitativeRequirements

HiddenFunctional

Requirements

Functional

Visible

Requirements



7/28

Illustration

Use Cases

A use case is a contract of an interactionbetween 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

Register User

Use case in diagram Use Case in script

admin



8/28

Use Case Diagram Objective

1. Create a semi-formal model of the functional

requirements

2. Analyze and define:

Scope

External interfaces

Scenarios and reactions



9/28

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 thereare, tradeoffs must be detected and discussed.

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



10/28

Use Cases as Means of Communication

The use case should stimulate a discussion about

what the system should do, mainly with people whoare outside of the development team.


Customers DesignersUsers


11/28

Example

A Simple Example

Handle Message

Cellular Phone

Customer

Bill Management

Handle Call External PhoneCompany

Actors

Use CaseSystem

boundary


Association


12/28

Finding Actors External objects that produce/consume data:

Must serve as sources and destinations for data

Must be external to the system

Humans Machines External systems Sensors

Database PrinterOrganizational Units



13/28

Example

Actors can be generalizedThe 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 Client

Sales Person

Institutional

Sales Person

Perform Sale

Perform

Business Sale

Sales Manager

Cancel Sale


14/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

InheritanceIntroduction | Diagrams | Writing | Guidelines


15/28

Use-Case Levels

User goals

Perform

Sale

Choose

Products

Fill-in billing

info

Sub-functionality


Base Use Case:

Used directly by the

user

Alistair Cockburn Writing Effective Use Cases


16/28

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

Example


17/28

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 Sale

After checkoutGift wrap

Products

Product is a gift

Example


18/28

Example: Amazon

Product Page

Review Writing

Shopping Cart



19/28

Examplecontd


SearchProduct

Navigate

Deals

Checkout

Handle Order

Status

Login Register

View Product

Details

Write

Review

Rank

Supplierinclude

include

include

include

extend

user is not

a member

extend

extend

Add to

cart

extend

Customer


20/28

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

representative

2. Mark representative as busy

3. Start record call

4. Stop record call

5. Log call details

6. Mark representative as free


21/28

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 submitthesis

Good: Only graduate studentcan submit thesis



22/28

Example: Phone Company Operational System

The Cellular Phone

Who are the actors?

External Phone companies

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



23/28

Example: Cell Company System


3G Phone

Handle SMS

Message

Cellular Phone

while talking

Handle Call

External Phone

Company

Handle Video

Call

Handle Cell

Migration

Handle Multiple

Calls

Handle

Conference Call

{incoming call}

{phone initiate call}

Handle Voice

Call


24/28

Structure of a Use Case

SpecificationNameActors

Preconditions

Post conditions

Success Scenario

Alternatives flows


Alistair Cockburn

Writing Effective

Use Cases

Trigger


25/28

Triggers

What starts the use-case?

Examples:

Customer reports a claim

Customer inserts card

System clock is 10:00



26/28

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



27/28

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 userIntroduction | Diagrams | Writing | Guidelines


28/28

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 desiredoutcome of the use-case

It is composed of a sequence of action steps

Example:1. Administrator enters course name, code and description2. System validates course code

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

Interaction

step

ValidationStep

Internal Change

Step(plus) Interaction

Step
