AISD2013

Introduction to UML

Outline
Introduction Use Case Diagrams Writing Use Cases

Where are we?

Phase
Initiation Requirements

Actions
Raising a business need Interviewing stakeholders, exploring the system environment

Outcome
Business documents Organized documentation

Specification
Design

Analyze the engineering aspect of the system, building system concepts

Define architecture, components, data types, algorithms Program, build, unit-testing, integrate, Integrate all components, verification, validation, installation, guidance Bug fixes, modifications, adaptation

Formal specification
Formal Specification Testable system Testing results, Working sys System versions

Implementation documentation Testing & Integration Maintenance

Introduction | Diagrams | Writing | Guidelines

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 | Guidelines

Requirements vs. Design

Requirements:
What the system should do More abstract

Design:
How the system should do it More detailed
Introduction | Diagrams | Writing | Guidelines

 Visible Functional Requirements

Types of Requirements
Functional Visible Requirements
Hidden 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

Qualitative Requirements

Hidden Requirements
Database maintenance processes will occur every night
Introduction | Diagrams | Writing | Guidelines

Use Cases
Register User
admin Use case in diagram Use Case in script
Illustration

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

Use Case Diagram Objective

1. Create a semi-formal model of the functional requirements 2. Analyze and define:
Scope External interfaces Scenarios and reactions

Introduction | Diagrams | Writing | Guidelines

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 | Guidelines

Use Cases as Means of Communication

Customers

Designers

Users

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

Introduction | Diagrams | Writing | Guidelines

A Simple Example
Handle Message

Cellular Phone

Handle Call

External Phone Company

Bill Management Customer

System boundary

Association

Use Case

Actors
Example

Introduction | Diagrams | Writing | Guidelines

 External objects that produce/consume data:

Must serve as sources and destinations for data Must be external to the system

Finding Actors

Humans

Machines External systems Sensors

Organizational Units
Introduction | Diagrams | Writing | Guidelines

Database

Printer

The child actor inherits all usecases associations

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

Actors can be generalized

Perform Sale

Register Client Sales Person

Perform Business Sale

Institutional Sales Person

Cancel Sale

Sales Manager

Example

Introduction | Diagrams | Writing | Guidelines

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 Introduction | Diagrams | Writing | Guidelines Inheritance

Use-Case Levels
Base Use Case: Used directly by the user
Perform Sale

User goals Sub-functionality

Choose Products Fill-in billing info

Alistair Cockburn Writing Effective Use Cases

Introduction | Diagrams | Writing | Guidelines

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 <<include>> Fill-in billing info
Example

Introduction | Diagrams | Writing | Guidelines

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 usecase extends it <<extend>>
Perform Sale After checkout Product is a gift Gift wrap Products
Example

Introduction | Diagrams | Writing | Guidelines

Example: Amazon

Shopping Cart
Product Page

Review Writing
Introduction | Diagrams | Writing | Guidelines

Example contd
extend

Search Product

include

Rank Supplier

View Product Details

extend

Navigate Deals

include

Write Review

extend

Add to cart

Customer
include

Checkout

extend user is not a member

Login
Handle Order Status

Register

include

Introduction | Diagrams | Writing | Guidelines

 The child use case inherits the behavior parent use case:
The interaction (described in the textual description) Use case links (associations, include, extend, generalization)

Generalization between Use-Cases

Child use-case can substitute parent Use case Overriding occurs through the textual description
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

Handle Call

Handle Sale Call Customer Representative

Handle Technical Assistance Call Tech Assistant Representative

Example

Introduction | Diagrams | Writing | Guidelines

 Combining generalizations of actors and usecases can be dangerous

Submit and Get Grade Submit Exam Undergrad Student Submit Exam

Generalization Hazards

Undergrad Student

Submit Thesis

Submit Thesis

Graduate Student

Graduate Student

Bad: Undergrad can submit

thesis

Good: Only graduate student

can submit thesis

Introduction | Diagrams | Writing | Guidelines

Example: Phone Company Operational System

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.

Who are the actors?

The Cellular Phone

External Phone companies

Introduction | Diagrams | Writing | Guidelines

Example: Cell Company System

External Phone Company

Handle Cell Migration <<include>> Handle SMS Message <<include>> Handle Call while talking <<extend>> <<extend>> {phone initiate call} {incoming call} Handle Conference Call

Cellular Phone

Handle Voice Call

Handle Video Call

Handle Multiple Calls

3G Phone

Introduction | Diagrams | Writing | Guidelines

Name Actors Trigger Preconditions

Structure of a Use Case Specification

Post conditions

Success Scenario
Alistair Cockburn Writing Effective Use Cases

Alternatives flows

Introduction | Diagrams | Writing | Guidelines

Triggers
What starts the use-case? Examples:
Customer reports a claim Customer inserts card System clock is 10:00

Introduction | Diagrams | Writing | Guidelines

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 | Guidelines

Post-Conditions
A post-condition is the outcome of the usecase. 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 Introduction | Diagrams | Writing | Guidelines

 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 Interaction step It is composed of a sequence of action steps Administrator enters course name, code and description 1. Example: Validation
2. 3. System validates course code Step System adds the course to the db and shows a confirmation message

Success Scenario

Internal Change Step

Introduction | Diagrams | Writing | Guidelines

(plus) Interaction Step