8/15/2019 OOSE_Week 4- Use Case Diagrams
1/43
Modeling Concepts,Modeling Diagram
Designing with Use Cases
8/15/2019 OOSE_Week 4- Use Case Diagrams
2/43
Modeling
Models are abstractions that expose the essentials ofa complex problem or structure by ltering outnonessential details.
Describing a system at a high level of abstraction
A model of the system
Used for requirements and specications
Models help us organize, visualize, understand, andcreate complex things.
s it necessary to model soft!are systems"
8/15/2019 OOSE_Week 4- Use Case Diagrams
3/43
What is Visual Modeling?
Visual modeling is a !ay of thin#ing aboutproblems using models organized around real$!orld ideas.
Models are useful for Understanding problems
%ommunicating !ith everyone involved !iththe pro&ect 'customer, domain expert, analyst,
designers, etc.( Modeling enterprises
)reparing documentation
Designing programs and databases
8/15/2019 OOSE_Week 4- Use Case Diagrams
4/43
What is UML?
Unied Modeling *anguage +M -tandard, +b&ect Management roup ased on !or# from ooch, /umbaugh, 0acobson
UM* is a modeling language to express and designdocuments, soft!are )articularly useful for ++ design 1ot a process, but some have been proposed using UM* ndependent of implementation language
8/15/2019 OOSE_Week 4- Use Case Diagrams
5/43
Components of UML
2he UM* consists of a number of graphicalelements that combine to form diagrams.
UM* is a language3 it has rules forcombining these elements.
2he purpose of the diagrams is topresent multiple vie!s of a system3 this
set of multiple vie!s is called a model.
A UM* model tells !hat a system issupposed to do.
8/15/2019 OOSE_Week 4- Use Case Diagrams
6/43
Introduction
A very po!erful approach to resolvingfunctional requirements is to focus on ho! the product under development
!ill interact !ith users.
4
8/15/2019 OOSE_Week 4- Use Case Diagrams
7/43
What is a use case?
• A requirements analysis concept• A case of a use of the system5product• Describes the system6s actions from a
the point of vie! of a user• Tells a story • A sequence of events involving• nteractions of a user !ith the system
• s oriented to!ard satisfying a user6sgoal
http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_case
8/15/2019 OOSE_Week 4- Use Case Diagrams
8/43
How do we describe usecases?
• 2extual or tabulardescriptions
• User stories• Diagrams
8/15/2019 OOSE_Week 4- Use Case Diagrams
9/43
Use Case Descriptions
• actors $ something !ith a behavior orrole, e.g., aperson, another system, organization.
• scenario $ a specic sequence of actionsand interactions bet!een actors and thesystem, a.#.a. a use case instance
• use case $ a collection of related successand failure scenarios, describing actorsusing the system to support a goal.
8/15/2019 OOSE_Week 4- Use Case Diagrams
10/43
8/15/2019 OOSE_Week 4- Use Case Diagrams
11/43
8/15/2019 OOSE_Week 4- Use Case Diagrams
12/43
!inding ctors "*$
s+ the following uestions)
• 9ho are the system:s primary users"• 9ho requires system support for daily tas#s"
• 9ho are the system:s secondary users"• 9hat hard!are does the system handle"• 9hich other 'if any( systems interact !ith the
system in
question"• Do any entities interacting !ith thesystem perform multiple roles as actors"
• 9hich other entities 'human or other!ise(might have an interest in the system6soutput"
8/15/2019 OOSE_Week 4- Use Case Diagrams
13/43
What is a user story?
;.9ho"
8/15/2019 OOSE_Week 4- Use Case Diagrams
14/43
Use Case -cenario
>ere is a scenario for a medicalclinic.
A patient calls the clinic to make anappointment for a yearly checkup.he receptionist !nds the nearest
empty time slot in the appointmentbook and schedules the appointmentfor that time slot. "
8/15/2019 OOSE_Week 4- Use Case Diagrams
15/43
Use Case Diagrams
• A picture• describes ho! actors relate to use
cases
• and use cases relate to one another• Diagrams are not essential• 2hey are helpful in giving an overvie!,
but only secondary in importance to the
textual description• 2hey do not capture the full information
of theactual use cases
• n contrast, text is essential
8/15/2019 OOSE_Week 4- Use Case Diagrams
16/43
Use Case Diagram.b'ecti/e
• uilt in early stages ofdevelopment
• )urpose• -pecify the context of a system• %apture the requirements of a
system
• @alidate a systems architecture• Drive implementation and
generate test
cases
8/15/2019 OOSE_Week 4- Use Case Diagrams
17/43
%&le Use0CaseDiagram
A standard form of use case diagram is dened in the UniedModeling *anguage.
8/15/2019 OOSE_Week 4- Use Case Diagrams
18/43
;=
%lements of use casediagram) ctor
• Actor is someone interacting with use case(system function). Named by noun.
• Similar to the concept of user, but
a user can play dierent roles3
(example: a prof. can be instructor andresearcher – plays roles with two systems).
•!ctor triggers use case.
•!ctor has responsibility toward the system (inputs),and !ctor ha"e expectations from the system
(outputs).
1ame
8/15/2019 OOSE_Week 4- Use Case Diagrams
19/43
;B
%lements of use casediagram) Use Case
Do something
• -ystem function 'process C automated ormanual(.
• 1amed by verb.• ach Actor must be lin#ed to a use case, !hile some
use cases may not be lin#ed to actors.
1 Use Case
8/15/2019 OOSE_Week 4- Use Case Diagrams
20/43
%lements of use case diagram).ther details
%onnection bet!een Actor and Use %ase
#oundary of system
Include relationship between $se %ases (one $% must
call another& e.g., 'ogin $% includes $ser !uthentication $%)
Extend relationship between $se %ases (one $% calls
!nother under certain condition& thin of ifthen decision points)
;E
8/15/2019 OOSE_Week 4- Use Case Diagrams
21/43
Lin+ing Use Cases
• Association relationships• #enerali$ation relationships
• +ne element 'child( Fis based onFanother element 'parent(
• Include relationships• +ne use case 'base( includes the
functionality of another 'inclusioncase(
• -upports re$use of functionality• %&tend relationships
• +ne use case 'extension( extends thebehavior of another 'base(
8/15/2019 OOSE_Week 4- Use Case Diagrams
22/43
18
• 2he child use case
inherits the behavior
and meaning of the
parent use case.
• 2he child may add to or
override the behavior ofits parent.
parent
child
#2 3enerali4ation
8/15/2019 OOSE_Week 4- Use Case Diagrams
23/43
1
registration
graduate
registration
non-graduate
registration
More about3enerali4ation
8/15/2019 OOSE_Week 4- Use Case Diagrams
24/43
3enerali4ation%&le
2he actor +rder/egistry %ler# caninstantiate the
general use case)lace +rder.
)lace +rder canalso be
specialized by theuse cases )hone+rder or nternet+rder.
8/15/2019 OOSE_Week 4- Use Case Diagrams
25/43
3enerali4ation %&le5as+ #
stablish eneralize /elationship
An order management system acceptsordering of product by phone or
internet. 9rite the generalization forthis, !here that base use case !ill be
used by the order registry cler#
8/15/2019 OOSE_Week 4- Use Case Diagrams
26/43
5as+ # -olution
8/15/2019 OOSE_Week 4- Use Case Diagrams
27/43
!!
• 2he base use case explicitlyincorporates the behavior ofanother use case at a locationspecied in the base.
• 2he included use case never standsalone. t only occurs as a part ofsome larger base that includes it.
base included
*2 Include
8/15/2019 OOSE_Week 4- Use Case Diagrams
28/43
"#$%&' "()#*('&+ !3
More about Include
nables us to avoid describing thesame Go! of events several times byputting the common behavior in a usecase of its o!n.updating
grades
output
generating
verifying
student
id
8/15/2019 OOSE_Week 4- Use Case Diagrams
29/43
<
Include relationship
• *nclude relationship – a standard case lined to amandatory use case.
• xample8 to Authori$e 'ar (oan 'standard use case(,
a cler# must run 'heck 'lient)s 'redit *istory 'includeuse case(.
• 2he standard U% includes the mandatory U%
•Standard use case can N+ execute without the include
case tight coupling .
8/15/2019 OOSE_Week 4- Use Case Diagrams
30/43
!,
• 2he base use case implicitlyincorporates the behavior ofanother use case at certain pointscalled extension points.
• 2he base use case may stand alone,but under certain conditions itsbehavior may be extended by the
behavior of another use case.
base extending
62 %&tend
8/15/2019 OOSE_Week 4- Use Case Diagrams
31/43
!8
More about %&tend
• nables to model optionalbehavior orbranching under conditions.
Exam copy
request
Exam-grade
appeal
8/15/2019 OOSE_Week 4- Use Case Diagrams
32/43
<H
%&tend relationship
• Extend relationship – lining an optional usecase to a standard use case.
•xample8 +egister 'ourse 'standard use case(
may have +egister for pecial 'lass 'extend use
case( C class for non$standard students, in
unusual time, !ith special topics, requiring extra
feesI(.
• 2he optional U% extends the standard U%
• -tandard use case can execute !ithout theextend case
loose coupling.
8/15/2019 OOSE_Week 4- Use Case Diagrams
33/43
5as+ *
stablish JJncludeKK and JJxtendKK/elationships
%onsider an online Gight boo#ing system. A user !illsearch for an available Gight time and boo# the Gight ifdesired. 2he user !ill be able to chec# if there is any seatavailable, either !hen searching or boo#ing a Gight.
As part of an online Gight boo#ing system, the customermay have the option to upgrade their seat 'e.g economyto business class( !hen ma#ing Gight boo#ing.
8/15/2019 OOSE_Week 4- Use Case Diagrams
34/43
5as+ * -olution
8/15/2019 OOSE_Week 4- Use Case Diagrams
35/43
%&tend %&le
8/15/2019 OOSE_Week 4- Use Case Diagrams
36/43
3
place
phone call
cellular network
user
receive
phone call
place
conference
call
receive
additional
call
usescheduler
Cellular Telephone
%&le
8/15/2019 OOSE_Week 4- Use Case Diagrams
37/43
How to create use case diagram
*2 Draw o/als around the function labelso
Dra! system boundaryo Dra! actors and connect them !ith use cases 'if more intuitive,
this can be done as step
8/15/2019 OOSE_Week 4- Use Case Diagrams
38/43
Use0Case Diagram Case-tud7 "#$
Vending Machine
After client intervie! the follo!ing systemscenarios !ere identied8
. A customer buys a product . 2he supplier restoc#s the machine . 2he supplier collects money from the machine
+n the basis of these scenarios, the follo!ing
three actors can be identied8
%ustomer3 -upplier3 %ollector 'in this case%ollectorL-upplier(
U C Di C
8/15/2019 OOSE_Week 4- Use Case Diagrams
39/43
Use0Case Diagram Case-tud7 "6$
Introducing annotations 8notes9and constraints2
8/15/2019 OOSE_Week 4- Use Case Diagrams
40/43
%&le
Dra! a use case diagram for a tic#et distributorfor a train system. 2he system includes t!oactors8 a traveler, !ho purchases dierent typesof tic#ets, and a central computer system, !hich
maintains a reference database for the tari. Usecases should include8 uy+ne9ay2ic#et,uy9ee#ly%ard, uyMonthly%ard, Update2ari.Also include the follo!ing exceptional cases8
2ime$+ut 'i.e., traveler too# too long to insertthe right amount(, 2ransactionAborted 'i.e.,traveler selected the cancel button !ithoutcompleting the transaction(,Distributor+ut+f%hange, and
Distributor+ut+f)aper.
Wh t I U C
8/15/2019 OOSE_Week 4- Use Case Diagrams
41/43
What Is a Use CaseDescription?
A use case description is a specication ofthe interaction bet!een a product and the
actors in a use case.%reating use case descriptions is a form of
technical !riting, and good use casedescriptions should have the virtues of
good technical !riting8 2hey should be clear, easy to read, complete,
and unambiguous
B;
U C D i ti
8/15/2019 OOSE_Week 4- Use Case Diagrams
42/43
Use Case DescriptionContents
B<
8/15/2019 OOSE_Week 4- Use Case Diagrams
43/43
Use Case 5emplate