Using Use Case Diagrams

Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis. rovide a !ay for developers, domain e"perts and end#users to Communicate. $erve as basis for testing. Use case diagrams contain use cases, actors, and their relationships.
1

Use Case

name

Use cases specify desired behavior. & use case is a description of a set of

sequences of actions, including variants, a system performs to yield an observable result of value to an actor. 'ach sequence represent an interaction of actors !ith the system.
%

$pecifying the )ehavior of a Use Case

Describing the flo! of events !ithin the use case. Can be done in natural language, formal language or pseudo#code. *ncludes+ ho! and !hen the use case starts and ends, !hen the use case interacts !ith actors and !hat ob-ects are e"changed, the basic flo! and alternative flo!s of the behavior.

&ctors

name

&n actor represents a set of roles that users

of use case play !hen interacting !ith these use cases. &ctors can be human or automated systems. &ctors are entities !hich require help from the system to perform their tas/ or are needed to e"ecute the system0s functions. &ctors are not part of the system.
.

Use Cases and &ctors

2rom the perspective of a given actor, a use

case does something that is of value to the actor, such as calculate a result or change the state of an ob-ect. 3he &ctors define the environments in !hich the system lives

'"ample of Use Case Diagram

registration

student

updating grades

faculty

output generating

6elationships bet!een Use Cases

1. 7eneralization # use cases that are specialized versions of other use cases. %. *nclude # use cases that are included as parts of other use cases. 'nable to factor common behavior. (. '"tend # use cases that e"tend the behavior of other core use cases. 'nable to factor variants.
5

1. 7eneralization
3he child use case inherits the
parent

behavior and meaning of the parent use case. 3he child may add to or override the behavior of its parent.

child

:ore about 7eneralization

registration

non#graduate registration

graduate registration

%. *nclude
base
<<include==

included

3he base use case e"plicitly incorporates

the behavior of another use case at a location specified in the base. 3he included use case never stands alone. *t only occurs as a part of some larger base that includes it.
1;

:ore about *nclude

'nables to avoid describing the same flo!

of events several times by putting the common behavior in a use case of its o!n.
updating grades

<<include== verifying student id

output generating

<<include==

11

(. '"tend
base
<<e"tend==

e"tending

3he base use case implicitly incorporates

the behavior of another use case at certain points called e"tension points. 3he base use case may stand alone, but under certain conditions its behavior may be e"tended by the behavior of another use case.
1%

:ore about '"tend

'nables to model optional behavior or

branching under conditions.

'"am copy request

<<e"tend==

'"am#grade appeal

1(

6elationships bet!een &ctors

7eneralization.
student

graduate student

non#graduate student

1.

6elationships bet!een Use Cases and &ctors

&ctors may be connected to use cases by

associations, indicating that the actor and the use case communicate !ith one another using messages.

updating grades faculty

11

'"ample
place phone call cellular net!or/
<<e"tend==

place conference call receive additional call

receive phone call

<<e"tend==

user

use scheduler
Cellular 3elephone
14

& :ore Complicate '"ample

Update Items Bookshop Worker Ship Order

Update Sta!! "etai#s %&stomer ' Bookshop Mana er $e ister "etai#s ,,in-#&de.. ,,e/tend.. +and#e Order ,,in-#&de.. ,,in-#&de.. Update %&stomer "etai#s S(stem )o in

15
Make Order *dd Items to Shoppin %art

Use Case Description

:'ach use case may include all or part of the follo!ing

3itle or 6eference >ame &uthor?Date :odification?Date urpose @vervie! Cross 6eferences &ctors re Conditions ost Conditions >ormal flo! of events &lternative flo! of events '"ceptional flo! of events *mplementation issues # meaningful name of the UC # the author and creation date # last modification and its date # specifies the goal to be achieved # short description of the processes # requirements references # agents participating # must be true to allo! e"ecution # !ill be set !hen completes normally # regular flo! of activities # other flo! of activities # unusual situations # foreseen implementation problems

18

'"ample# :oney Aithdra!

Use Case+ Aithdra! :oney &uthor+ B) Date+ 1#@C3#%;;. urpose+ 3o !ithdra! some cash from user0s ban/ account @vervie!+ 3he use case starts !hen the customer inserts his credit card into the system. 3he system requests the user *>. 3he system validates the *>. *f the validation succeeded, the customer can choose the !ithdra! operation else alternative 1 C validation failure is e"ecuted. 3he customer enters the amount of cash to !ithdra!. 3he system chec/s the amount of cash in the user account, its credit limit. *f the !ithdra! amount in the range bet!een the current amount D credit limit the system dispense the cash and prints a !ithdra! receipt, else alternative % C amount e"ceeded is e"ecuted. Cross 6eferences+ 61.1, 61.%, 65
19

'"ample# :oney Aithdra! (cont.)

&ctors+ Customer re Condition+

C 3he &3: must be in a state ready to accept transactions C 3he &3: must have at least some cash on hand that it can dispense C 3he &3: must have enough paper to print a receipt for at least one transaction

ost Condition+
C 3he current amount of cash in the user account is the amount before the !ithdra! minus the !ithdra! amount C & receipt !as printed on the !ithdra! amount C 3he !ithdra! transaction !as audit in the $ystem log file
%;

'"ample# :oney Aithdra! (cont.)

Typical Course of events:

&ctor &ctions
1. )egins !hen a Customer arrives at &3: %. Customer inserts a Credit card into &3: 1. Customer chooses EAithdra!F operation 5. Customer enters the cash amount

$ystem &ctions
(. $ystem verifies the customer *D and status .. $ystem as/s for an operation type 4. $ystem as/s for the !ithdra! amount 8. $ystem chec/s if !ithdra! amount is legal

9. $ystem dispenses the cash 1;. $ystem deduces the !ithdra! amount from account 11. $ystem prints a receipt 1(. Customer ta/es the cash and the receipt 1%. $ystem e-ects the cash card
%1

'"ample# :oney Aithdra! (cont.)

&lternative flo! of events+

C $tep (+ Customer authorization failed. Display an error message, cancel the transaction and e-ect the card. C $tep 8+ Customer has insufficient funds in its account. Display an error message, and go to step 4. C $tep 8+ Customer e"ceeds its legal amount. Display an error message, and go to step 4.

'"ceptional flo! of events+

C o!er failure in the process of the transaction before step 9, cancel the transaction and e-ect the card
%%

'"ample# :oney Aithdra! (cont.)

@ne method to identify use cases is actor#based+

# *dentify the actors related to a system or organization.
# 2or each actor, identify the processes they initiate or participate in.

& second method to identify use cases is event#based+

# *dentify the e"ternal events that a system must respond to. # 6elate the events to actors and use cases.

3he follo!ing questions may be used to help identify the use cases for a system+
# # # # # # Ahat are tas/s of each actor G Aill any actor create, store, change, remove, or read information in the system G Ahat use cases !ill create, store, change, remove, or read this information G Aill any actor need to inform the system about sudden, e"ternal changes G Does any actor need to be informed about certain occurrences in the system G Can all functional requirements be performed by the use cases G

%(

:oving on
3he EthingsF that EliveF inside the system

are responsible for carrying out the behavior the actors on the outside e"pect the system to provide. 3o implement a use case, !e create a society of classes that !or/ together to carry out the behavior of the use case.
%.