OOSE_Week 4- Use Case Diagrams

8/15/2019 OOSE_Week 4- Use Case Diagrams

1/43

Modeling Concepts,Modeling Diagram

Designing with Use Cases


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"


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


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


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.


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


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/43

How do we describe usecases?

• 2extual or tabulardescriptions

• User stories• 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.


10/43


11/43


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"


13/43

What is a user story?

;.9ho"


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. "


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


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


17/43

%&ample Use0CaseDiagram

A standard form of use case diagram is dened in the UniedModeling *anguage.


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


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


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


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(


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


23/43

1

registration

graduate

registration

non-graduate

registration

More about3enerali4ation


24/43

3enerali4ation%&ample

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.


25/43

3enerali4ation %&ample5as+ #

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#


26/43

5as+ # -olution


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


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


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 .


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


31/43

!8

More about %&tend

• nables to model optionalbehavior orbranching under conditions.

Exam copy

request

Exam-grade

appeal


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.


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.


34/43

5as+ * -olution


35/43

%&tend %&ample


36/43

3

place

phone call

cellular network

user

receive

phone call

place

conference

call

receive

additional

call

usescheduler

Cellular Telephone

%&ample


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


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


39/43

Use0Case Diagram Case-tud7 "6$

Introducing annotations 8notes9and constraints2


40/43

%&ample

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


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


42/43

Use Case DescriptionContents

B<


43/43

Use Case 5emplate

OOSE_Week 4- Use Case Diagrams

Documents

Transcript of OOSE_Week 4- Use Case Diagrams