Use Case Diagrams

Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage

complexity Reduce time-to-market for business

problem solutions Decrease development costs Manage the risk of mistakes

*Why do we use model?

The UML is a graphical language for specifying visualizing constructing documenting

the artifacts of software systems Added to the list of OMG adopted

technologies in November 1997 as UML 1.1 Most recent minor revision is UML 1.3,

adopted in November 1999 Next minor revision will be UML 1.4,

planned to be adopted in Q2 2001 Next major revision will be UML 2.0,

planned to be completed in 2002

*Quick Tour

UML NotationUML notation is useful for graphically depicting object oriented analysis and design models.

Models system requirements Facilitates design decisions Promotes communications among key players involved in the development effort Integrates system views in a complete and consistent fashion Employs a simple notation set

UML Diagrams 12 basic diagrams divided into 3 categories Structural Diagrams

Class Diagram, Object Diagram, Component Diagram, and Deployment Diagram. 

Behavior Diagrams Use Case Diagram, Sequence Diagram, Activity

Diagram, Collaboration Diagram, and Statechart Diagram. 

Model Management Diagrams Packages, Subsystems, and Models

UML and OOAD The techniques drawn from the UML model for OOAD include:

Use cases - represent the functional requirements of the system.

Object diagrams- graphical depiction of the objects associated with the system.

Class diagrams - show the static structure of data and operations and their relationships in a logical view of the system.

Behavior diagrams or activity diagrams - model the behavior of the system.

State diagrams - represent how objects change their states in response to events.

Sequence diagrams - show interactions between objects. Implementation diagrams including component diagrams and

deployment diagrams. Interaction or collaboration diagrams - Present an alternate or

complement to the sequence diagram that models interactions between objects in the system.

OOAD and the SDLC The object oriented development life cycle

builds on the foundation of the SDLC. But OOAD is iterative in design focusing

on the evolution of the system throughout the system development process.

For instance models built in the analysis phase are reused and refined during the design phase.

What is use case modeling? use case model: a view of a

system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).

answers WHAT is the system to do

System Requirements and Use Cases

Use case diagrams are the primary focus of the requirements determination phase of analysis

Use cases describe system behavior from an external viewpoint and establish system boundaries

http://www.zoo.co.uk/~z0001039/PracGuides/pg_use_cases.htm

System Requirements and Use Cases An important aspect of use cases is that they

describe the system from the perspective of external users.

The process was designed to be inherently iterative so that developers wold involve users in discussions throughout the model development process.

This process also facilitates and enables the discovery of not yet identified system requirements.

Use cases analysis takes the place of the functional requirements stage used in SDLC.

Iterative Nature of Use Cases

Use cases control the formation of all other models used in the development process.

If user requirements change during the development process, the changes are first made in the use case model.

Changes to the use case dictate what changes need to be made in the other models.

Use Case Modeling Jacobson (and others, 1992) pioneered the application of

use case modeling for analyzing the functional requirements of a system.

Use case modeling depicts what the system is to do. It is the process of identifying and modeling business

events, who initiated them and how the system responds to them.

Use case modeling works to provide a solution to a problem by breaking down the entire scope of system functionality into many smaller views of system functionality. These smaller views of the system are often referred to as Packages. Within each package, the system is further broken down into task level functionality called 'Use Cases'

Complete Use Case modeling includes visualization (diagrams) and corresponding step-by-step documented descriptions of each identified use case.

Benefits of Use Cases Use cases are used during the entire system

development process. During analysis the use cases are used to

model functionality of the proposed system and are the starting point for identifying objects.

Use cases contain an enormous amount of system functionality detail. So they are a constant resource for validation and testing.

Use case is an invaluable vehicle for communication between developers and end users.

Definition of a Use Case A Use Case is a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task.

Use Case Modeling A use case model is the visualization

of a use case. A use case model has two

components: actors and use cases. Actors initiate system activity - a use

case - to complete some business task.

Note the simplicity of the model. The initial model itself it not detailed.

Fig. 3-53, UML Notation Guide

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

F ill orde rsShipping Clerk

status

order

Use Case Diagram

Characteristics of Actors

Actors represent anything that needs to interacts with the system to exchange information

An actor is a user or role that that is usually external to the system

An actor can be people as well as another system, hardware device, etc.

An actor does not represent a single individual An actor always initiates a use case. Actors are represented as stick people and Actors are given names. Because actors are outside the system, they do not need to be described in detail. Actor

Actors vs Users

Actors are different from users. A user is anyone who uses the system. An actor is a role a user plays. An actor is a type or class of users - user is a specific instance of an actor

(If the same user plays two roles, he would be represented as an instance in each class of actor, i.e. John Patton is both an instructor and advisor. He would be represented as an instance in both the actor called Instructor and the actor called Advisor.)

Characteristics of use cases

A use case is the function being described. A use case always represents complete

functionality not individual actions. A use case is a complete sequence of related

actions representing a specific way of using the system.

Use cases represent the behavior of the system in response to stimuli from an actor.

Use cases are represented as ellipses (oval).

Use Case

Actors and Temporal Events Events triggered by time are called temporal events.

Who is the actor in a temporal event?

The actor is the system itself.

Temporal Event ExampleThe backup of system data is automatically initiated to occur every night at 2:30 am. No one has to request the backup. It is a temporal event. The actor for this temporal event is the system itself.

nightly backup

system

Identifying Actors and Use Cases

One place to start is to look at context model diagrams of the system. To identify use cases, Jacobson recommends asking:

What are the main tasks performed by each actor?

Will the actor read or update any information in the system?

Will the actor have to inform the system about changes outside the system?

Does the actor have to be informed about unexpected changes?

Constructing the Use Case Model The goal is to build a use case diagram for each

significantly different kind of scenario in the system. Each scenario shows a different sequence of

interactions between actors and the system with no or conditions.

Use cases are constructed after the actors and use cases have been identified.

Use cases are often grouped in to subsystems representing logical functional areas of the system. This partitioning aids in understanding the system architecture and is key to defining your development strategy - which use cases will be developed first and by whom.

Use Case Example

<<extends>>

Owner Customer

Job/EstimateProcess

Job/Invoice Process

Late Job/Invoices

Track Customer

Customer Contact

<<extends>>

<<extends>>Office Worker

Track Job/Estimate

Old Job/Estimate

Documenting the Use Case

Each use case is documented using a step-by-step description starting with the actor initiating the use case and ending with the business event.

The description includes objective of the use case, the actor that initiates the use case and the exchange of information between the actors and the use case.

Normal Course of Events First

The normal course of events is usually documented first.

Normal course of events includes major steps that happen the majority of the time

This allows you to concentrate on the system concept without getting bogged down in too many details.

Contents of a Use Case Document (normal course of events)

• The name of the actor who initiated the case.• A high level description of the use case

• A normal event course describing the use case's major steps from beginning to end of this interaction with the actor

• Pre-condition describing the state the system is in before the use case is executed

• Post-condition describing the state the system is in after the use case is executed

• An assumptions section, which includes, any non-behavioral issues, such as performance or security, that are associated with the use case but are difficult to model within the use case's course of events.

Alternate Course of ActionA use case may also have alternate courses of actions

These alternates are deviations or branches from the normal course of events.

Alternates are documented in a separate use case.

Contents of a Use Case Document (alternate course of action)

The name of the actor who initiated the case A high level description of the use case A normal event course describing the use case's major steps

from beginning to end of this interaction with the actor Alternate course of action describing the major steps of

deviation from the normal course of action Pre-condition describing the state the system is in before the

use case is executed Post-condition describing the state the system is in after the

use case is executed An assumptions section, which includes, any non-behavioral

issues, such as performance or security, that are associated with the use case but are difficult to model within the use case's course of events.

More on developing Use Cases A use case may participate in relationships with other use cases.

There are two primary types of relationships - includes and extends.

There use to exist a relationship called ‘uses’ but it has gone away.

Fig. 3-54, UML Notation Guide

*Use Case Relationships

additional requests :

OrderProduct

Supply Arrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog

Extends An extends relationship, extends a use case by adding new behavior or actions.

The extends symbol is <<extends>>

When to use <<extends>> Model alternate sequences through

<<extends>> relationships Remember a use case is usually modeled

first using a normal course of actions. Then "what if" conditions are considered

and alternate courses of action are modeled in separate use cases.

These alternate use cases are related to the original use case by an "extends" relationship.

Extends

Includes The includes relationship is used to

prevent repetition of the steps required to other use cases

Includes - specifies that the base use case needs an additional use case in order to fully describe its processes.

It is mainly used to show common functionality that is shared by several use cases

Includes

When to use <<extends>> or <<includes>> Use <<extends>>

Intent is to model an extension or variation of a complete use case

Use <<includes>> The base use case must use

another use case in order to complete its process

Diagram from Popkin Software: http://www.popkin.com/images/usecase.gif

Example of Use Case Diagram for a Course Registration System

Discover ActorsActors are examined to determine their needs:

RegistrarProfessorStudent Billing System

Remember that use cases are within the system, actors are outside.

Registrar Professor Student Billing System

A use case is a pattern of behavior the system exhibits

Use cases identified: Maintain Registrar Request Course Roster Maintain Schedule Register for courses

Discover Use Cases

Maintain Curriculum

Request Course Roster

Maintain Schedule

Register for Course

Put Use Cases with ActorsEach use case is a sequence of related transactions performed by an actor and a system in a dialogue.

Actors are examined to determine their needs: Registrar - maintains curriculum Professor - requests rosters Student – registers for courses Billing System - receives information related to billing from registration

Remember that use cases are within the system, actors are outside.

BillingSystem

Student Professor

RegistrarMaintain Curriculum

Request Course Roster

Maintain Schedule

Register for Course

Relationships between use cases• A use case may participate in

relationships with other use cases. • Two common relationships are uses and

extends.

• Includes arise when one use case needs another use case.

Look for Includes

LogonValidation

Register for Course

Maintain Curriculum

Extend extends a use case by adding new behavior or actions. An extends relationship shows optional behavior. The use case that is extended must make sense without the extension.

Discover Extends

Register for CourseRequest help

Request helpRegister for Course

Use cases in opposite order – Notice the direction of the arrow

The Complete Use Case

BillingSystem

Maintain Schedule

Register for Course

Student

Professor

Request Course Roster

Registrar

Request Help

LogonValidation

<<extends>>

<<includes>>

Maintain Curriculum

<<includes>>

What’s This?

Pitfalls of Use Case Modeling The system boundary is undefined or

inconstant. The use case is written from the

system's (not the actors') point of view.

The actor names are inconsistent. There are too many use cases. The actor-to-use case relationships

resemble a spider's web.

Pitfalls continued The use-case specifications are too long. The use-case specifications are confusing. The use case doesn't correctly describe

functional entitlement. The customer doesn't understand the use

cases. The use cases are never finished. Lilly, S. Use Case Pitfalls: Top 10 Problems from Real

Projects Using Use Cases. Proceedings of TOOLS, USA 99, IEEE, 1999.

More information on the area of Use Case and Use Case Modeling

Information on Use Cases - great resource for templates, etc.: www.usecases.org

General Resources on Use Case: http://www.pols.co.uk/usecasezone/use-case-

papers.htm

Quote of the WeekThe roots of OO can be found in basic human thinking:

"In apprehending the real world, [people] constantly employ three methods of organization, which pervade all of their thinking: 1. the differentiation of experience into particular objects

and their attributes - eg. When they distinguish between a tree and its size or spatial relations to other objects.

2. the distinction between whole objects and their counterparts - eg. when they contrast a tree with its component branches, and

3. the formation of and the distinction between different classes of objects -eg. when they form the class of all trees and the class of all stones and distinguish between them."

Encyclopedia Britannica - Classification Theory