07-UseCaseDiagrams

Analyse et Méthodologie Informatiques

Roel WuytsULB

2005/2006

http://decomp.ulb.ac.be/education/ami0506/

Use Case Diagrams

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 2

UML Use Cases

Can be used to discover requirements

✦ and write them down

Central to UML

✦ Link users and system builders

Tend to be better to find out functional user requirements (focus on interaction)

✦ not well suited to find out about constraints, high-level business and non-functional requirements, or domain requirements


Parts of a Use Case Diagram...

Actors

Use cases

Systems

System

Name_Of_System



The system

✦ Could be any system, not just SW systems.

✦ Define clear and precise boundaries:

‣ Don’t be too ambitious - think small !

‣ Identify basic functionality and concentrate on defining a stable and well-defined architecture.

‣ More functionality can always be added later!

✦ Compile a catalog of central concepts or entities



The actors

✦ Who or what uses the system

‣ Represents a role, not an individual user!

✦ Communicates with the system by sending and receiving messages

✦ Actors are in control and initiate actions

✦ Actors can be ranked :

‣ Primary and secondary actors


Parts of a Use Case Diagram.

Use cases

✦ A set of sequences of actions a system performs

‣ A textual description !

✦ Always initiated by an actor

✦ Delivers an observable result of value to an actor

✦ Is connected to an actor through associations

‣ Normally bidirected one-to-one relations


Use case

Specify desired behaviour

✦ not how it is carried out (implemented)

✦ Therefore it is useful for communication between users and developers

carries out some tangible amount fo work

✦ not too big, nor too small

✦ does something that’s of value to an actor


Use case diagram Example

Process loan

LoanOfficer

actor association use case

Insurances

system


Describing the use case

Flows of events specify the behaviour of a use case

✦ clearly enough for an outsider to understand it

✦ what a system does, not how!

Several ways

✦ structured text (without/with pre-post conditions)

✦ pseudo-code

✦ sequence diagrams

✦ state diagrams


Use case descriptions

A description should include:

✦ how and when the use case starts and ends

✦ when it interacts with actors and what objects are exchanged

✦ the basic flow and alternative flows of the behaviour

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006

Use Case Specification Structure Example

Actors

Pre-conditions

Post-conditions

Basic Flow

Alternative Flows

Special Requirements

Use case relationships

✦ (for complex systems)

11


Description Example

Main flow of events: The use case starts when the system prompts the Customer for a PIN Number. The Customer can now enter a PIN number via the keypad. The Customer commits the entry by pressing the Enter button. The system then checks this PIN number to see if it is valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use case.

Exceptional flow of events: The Customer can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the Customer’s account.

Exceptional flow of events: The Customer can clear a PIN number anytime before committing it and reenter a new PIN number.

Exceptional flow of events: If the Customer enters an invalid PIN number, the use case restarts. If this happens three times in a row, the system cancels the entire transaction, preventing the Customer from interacting with the ATM for 60 seconds.


Describing a Use Case…

Use cases are goal oriented !

✦ What is it trying to achieve

✦ Which functions does the actor require, what does he/she need to do?

✦ Which actor initiates the use case and in which situations?

✦ Which messages or events are necessary


Describing a Use Case.

What is the flow of messages between actors and the use case?

✦ Depends on conditions and exceptions

‣ Be cautious : don’t be too detailed

‣ Specific exceptions can be clarified by scenarios

Which entities are modified and/or used?

When is the use case considered to be finished and what kind of value is delivered to the actor?


Relationships

Between actors

✦ generalization

Between use cases

✦ generalization

✦ inclusion

✦ extension


Actor generalization

Can have general kinds of actors, and specialize them with the generalization relationship

Commercial

Customer

Customer


Use case generalization

child use case inherits behaviour and meaning from the parent use case

✦ and can override

child use case can be used wherever the parent use case is used


Use case generalization example

Validate User

Check password

Retinal Scan


Includes relationship

A base use case including a supplier use case means that the base use case explicitly incorporates the supplier use case at a certain location

✦ the included use case never exists alone

✦ think of include as: the base case pulling behavior from the supplier case

Used to model common behaviour in one place, and afterwards use it in several other places


Includes relationship example

<include>

Signing Insurance

Policy

Signing Car Insurance

Signing Life Insurance

<include>


Includes relation description

Description of Track Order use case:

Main flow of events: Obtain and verify the order number. include (Validate User). For each part in the order, query its status, then report back to the user.

Validate UserTrack Order

<include>


Extends relationship

“A base use case extends an extension use case” means that the base use case implicitly incorporates the behaviour of the extension use case at a location specified by the extension use case

✦ the location is called the extension point

Used to model optional system behaviour

✦ So mandatory behaviour can be modeled separately from optional behaviour


<extends>(set priority)

Place order

Extension pointsset priority

Place rush order

Validate User

<include>

Extends relationship

extension point

extend relationship


Extends relationship description

Description of Place Order use case:

Main flow of events: include (Validate user). Collect the user’s order items. (set priority). Submit the order for processing.


Example

Cellular Telephone

Cellular Network

<extend>

Receive phone callReceive

additional call

User

<extend>

Place phone callPlace

conference call

Use scheduler


What to model with use cases?

Behavior of an element

✦ what a element does

Context of a system

✦ interaction of outside actors with the system

Requirements of a system

✦ make contract between outside and system


Modeling element behaviour

Advantages

✦ let domain experts specify outward view (what) so that developers can construct inside view (how)

✦ let developers approach an element and understand it

✦ basis for testing


Modeling element behaviour

Identify the actors that interact with the element

Organize actors by identifying general and more specialized roles

For each actor, consider the primary ways it interacts with the element

Consider exceptional ways of interaction

Organize these behaviours as use cases

✦ Every behaviour -> one use case


Example

Ship partial order

Place order

Validate customer

Bill customer

Track order

Ship order

Extension pointsmaterials ready

<include>

<include>

<include>

<extend>


Modeling the System Context

Systems have an inside and an outside

✦ Those inside carry out behaviour that those on the outside expect

Can be modeled explicitly with use cases

✦ Focus lies on actors surrounding the system

✦ What to include as an actor

‣ and what not



Identify the actors that surround the system

✦ which groups require help from the system

✦ which groups are needed to execute the system

✦ which groups interact with external hardware

✦ which groups perform secondary functions for administration and maintenance

Organize the actors (generalization relationships)

When needed, stereotype actors

Put them in a use case and connect to use cases



Credit Card Verification System

Customer

Process customer bill

Perform card transaction

Reconcile transactions

Manage customer account

IndividualCustomer

CorporateCustomer

Retail institution

Sponsoring financial

institution


Modeling System Requirements

Establish outside actors

For each actor, model expected or required behaviour

name these common behaviour with use cases

model relations between actors and use cases

Adorn the use cases with notes that assert nonfunctional requirements of the system


Modeling System Requirements

Credit Card Verification System

Customer

Process customer bill

Perform card transaction

Reconcile transactions

Manage customer account

Retail institution

Sponsoring financial

institution

Report on account status

Detect card fraud

Manage network outage


Notes and Tips

A well-structured use case:

✦ names a single identifiable behaviour of the system

✦ factors common behaviour by using inclusion

✦ factors variants by using extension

✦ describes the flow of events clearly enough for an outsider to easily understand it

✦ uses a minimal set of descriptions that specify the normal and variant semantics of the use case


Notes and tips: drawing

When drawing a use case:

✦ show only those use case that are important to understand the behaviour

✦ show only the actors relating to these use cases

When drawing a use case diagram:

✦ give it a name communicating its purpose

✦ minimize lines that cross

✦ semantically close elements should be physically close

✦ Use different diagrams when needed


Examples

University

Camera

37


Example 1 : University

38


Example 2 : University

39


Example 3 : Camera

40

Camera

Open Shutter

Close Shutter

Flash

Photographer


Example 4 : Camera

41

Camera

Take Picture

Change FilmPhotographer


Conclusion

Use “Use Case Diagrams” to capture user requirements

✦ Note that there is the diagram and the descriptions

Can have relations between use cases: generalization, inclusion and extension

42

07-UseCaseDiagrams

Documents

Transcript of 07-UseCaseDiagrams