object oriented sad-2 part i

7/23/2019 Object Oriented SAD-2 Part I

1/80

Object-Oriented System Analysis And

Design

Chapter II- Modeling usingUML

Understanding modeling toolsin system/software

development


2/80

Chapter ObjectiveChapter Objective

o be familiar with UML diagramso appreciate di!erent aspects

modeling process in system

development

12/06/15 2


3/80

Chapter II- opicsChapter II- opics

Overview- he UML"unctional Model

Use Case #iagram $essential and system%

&tructural Model Class/object' Component and

#eployment #iagram

(ehavioral Models )ctivity' &tate chart' se*uence

/collaboration

3


4/80

Overview- he UMLOverview- he UML

12/06/15 4


5/80

OO M+,O#OLOI+&OO M+,O#OLOI+&

#uring the early .s' there were around 0 O-Omethodologies among them1

Rumbaughs Object Modeling Technique (OMT):Class and )ssociations

Shlaer-Mellor (Object-Oriented Analysis!esign

(OOA!)"

#ooch Method : Categories and &ubsystems

$ir%s-#roc& (Res'onsibility-!rien

!esignlassRes'onsibilityollaboration)

R!!R" oad*ourdon Methodology : Class' Object' Class-2-

Object

+acobson Object-Oriented So%t,are ngineering

(OOS)Use case driven


6/80

34O(L+M&34O(L+M&

he e5istence of di!erent OOmethodologies resulted in thefollowing problems1

4esulted in multitudeinterpretation of same concepts

+ncouraged confusion

Limited the progress of methodsMethods in6uenced one another


7/80

,+ 7++# "O4 &)7#)4#I8)IO7,+ 7++# "O4 &)7#)4#I8)IO7

here are many methods and notationscompeting with each other that users are

distracted by the decisions they need to ma9e:

+5isting methods are already converging since

these methods pic9 up ideas from othersources:

) single' common language is desirable

because it can be used for all development

methods' used throughout the project lifecycle'and used for di!erent application technologies:


8/80

,+ U7I"IC)IO7,+ U7I"IC)IO7

(ased on the fact that di!erences betweenthe various methods were becomingsmaller:

he method wars did not move OO any

longer:;im 4umbaugh and rady (ooch decided at

the end of nition of a universal language for O-Omodeling

Uni>ed Method :? Oct:


9/80

,+ U7I"IC)IO7@,+ U7I"IC)IO7@

) year later they were joined byIvar ;acobson

Objective1 &tandardiAation of the

o-o development process he Uni>ed Method was

transformed into .M1- the.ni/ed Modeling 1anguage

B/.B UML :. ./.B UML :.nes structural and

behaioral things and

diagrams: UML is the language of

blueprints for software:


12/80

UML@UML@

It is a graphical language for isualiAing

&pecifying D building models that are

precise' unambiguous' and complete Constructing D possible to map from

a model in the UML to aprogramming language

#ocumentingIntended for software-intensive

systems


13/80

E,) UML I& 7OE,) UML I& 7O

UML is not a method ormethodology $Method F 7otation$e:g:'UML% G 3rocess%

UML does not dictate a particular

processUML can be used to record the

resulting domain and designmodels' independent of the process

Choose an appropriate process for aparticular project' independent ofthe modeling language


14/80

E,H U&+ UMLE,H U&+ UML

&tandardiAed notation without sacri>cingspecialiAed model data

Common language that can be used fromproduct conception to delivery' fromsystem to detailed design levels

4educed learning curve across projectsIncreased domain and design model

reuseIncreased customer involvement

/understanding of problem translation toproduct solution


15/80

UML &4UCU4+UML &4UCU4+

#uilding bloc&s things

relationships

#iagrams

ommon mechanisms speci>cations

)dornments/ dicoration

common divisions

e5tensibility mechanisms

ArchitectureArchitecture use-case viewuse-case view

logical viewlogical view

process viewprocess view implementation viewimplementation view

deployment viewdeployment view

UML

Commonmechanisms

ArchitectureBuildingblocks


16/80

he Uni>ed Modelinghe Uni>ed ModelingLanguage $UML%Language $UML% UML has three building bloc9s1

hings' the objects:

4elationships' the glue that holds

things together: #iagrams' categoriAed as either

structure or behavioral:


17/80

U7#+4&)7#I7 UMLU7#+4&)7#I7 UML

#.21!234 #1O5S O6 .M1


18/80

(UIL#I7 (LOCK& O"(UIL#I7 (LOCK& O"

UML@UML@: 4elationships D tie things together

): #ependency $uses% D a semanticrelationship between two things in whicha change to one thing $the independent

thing% may a!ect the semantics of theother thing $the dependent thing%) car uses a fuel

(: )ssociation D a structural relationship that

describes a set of lin9s' a lin9 being aconnection among objects:

employee

::nitionIdentify use cases

Identify relationshipsUse symbols for representing use

cases and actors with in a

boundary#e>ne use case description

12/06/15 49


50/80

50

)ctor)ctor

)n actor de>ne roles that users canplay:

)ctors model anything that needs to

e5change information with the systemhe di!erent roles the actor

represents are the actual businessroles of users in a given system:

)n actor in a use case diagraminteracts with a use case:


51/80

51

)ctor @)ctor @

)ctors are e5ternal to the system: )ctorsinteract with the system:

)ctor classes have actors instances or objectsthat represent speci>c actors:

)n actor is shown as a stic9 >gure in a usecase diagram depicted VoutsideV the systemboundary:

o identify an actor' search in the problemstatement for business terms that portrayroles in the system:


52/80

52

U&+ C)&+&U&+ C)&+&

) use case is a speci>c way of using thesystem by performing some part of thefunctionality:

) visual representation of a distinctbusiness functionality in a system:

he business process is discrete in nature:) use case describes what a system

doesW not how.List the discrete business functions in

your problem statement - potential usecase:4emember that identifying use cases is a

discoeryrather than a creation:


53/80

53

U&+ C)&+& @U&+ C)&+& @

Use cases have the following characteristics1

Use case are interactions or dialogs between a system and actors'including the messages e5changed and the actions performed bythe system: Use cases may include variants of these se*uences'including alternative and e5ception se*uences:

Use cases may be initiated by actors and may involve theparticipation of numerous other actors:

Use cases may have e5tension points that de>ne speci>c pointswithin an interaction at which other use cases may be inserted

Use cases classes have use case instances or objects calledscenarios that represent speci>c interactions:

A use case is shown as an ellipse in a use case diagram

d ibi h


54/80

Use-Cases1 describing howUse-Cases1 describing howthe user will use the systemthe user will use the system) use caseis a typical se*uence

of actions that a user performs inorder to complete a given tas9

he objective of use case analysisisto model the system from the pointof view of

@ how users interact with this system

@ when trying to achieve their objectives:

It is one of the 9ey activities inre*uirements elicitation and analysis

54


55/80

Use casesUse cases

) use case should Cover the full sequence of stepsfrom

the beginning of a tas9 until the end:

#escribe the users interactionwith

the system ::: 7ot the computations the system performs:

(e written so as to be as independentas possible from any particular user

interface design: Only include actions in which the actor

interacts with the computer:

12/06/15 55


56/80

&cenarios&cenarios

) scenario is an instanceof a usecase ) specic occurrenceof the use case

a speci>c actor ::: at a speci>c time :::

with speci>c data:

12/06/15 56


57/80

57

4+L)IO7&,I3&4+L)IO7&,I3&

4elationships between actors anduse cases are represented by directional or

nondirectional edges May be annotated by stereotypes

May relate two use cases

May relate two actors' or May relate a use case and anactor


58/80

58

4+L)IO7&,I3&4+L)IO7&,I3&

)ssociation denoted as solid lines or paths:

)rrowheads may be used to indicate whoinitiates communication in the interaction:

Includes Indicates that the base use case will contain

the inclusion use case:

) base use case de>nes the location at whichthe inclusion use case is included:

#enoted as dashed lines with an open arrow-head pointing at the inclusion use case andare labelled with the QQincludeRR 9eyword$stereotype%:


59/80

59

4+L)IO7&,I3& @4+L)IO7&,I3& @

+5tends

Indicates that the base use case may beaugmented by the e5tension use caseW i:e:' the

inclusion use case will augment the base use

case if an e5tension condition is satis>ed: ) base use case de>nes the e5tension point:

#enoted as dashed lines or paths with an open arrow-head

pointing an e5tension use case

labelled with the e5tension condition in s*uarebrac9ets'

the QQe5tendRR 9eyword $stereotype%' and

the e5tension point name in parentheses:


60/80

60

4+L)IO7&,I3& @4+L)IO7&,I3& @

eneraliAation "rom specialiAation to generaliAed use case

Indicate the specialiAation use cases are consistent withthe generaliAed use case and may add additionalinformation:

) specialiAed use case may be used in place of a

generaliAed use case and may use any portions of theinteraction of the generaliAed use case: #enoted as solid lines or paths with a hollow arrow-head

pointing at the generaliAed use case: "rom specialiAation to generaliAed )ctor

he specialiAed actor are consistent with the generaliAed

actor and may add additional information: ) specialiAed actor may be used in place of a generaliAed

actor and receives the characteristics of the generaliAedactor:

#enoted as solid lines or paths with a hollow arrow-headpointing at the generaliAed actor:


61/80

61

4+L)IO7&,I3& @4+L)IO7&,I3& @

QQincludesRR

QQincludesRR


62/80

62

&ystem (oundary&ystem (oundary

he use case describes the functionality of asystem from an outside point of view D fromthe users point of view:

Only the interaction between actors andsystem are shown' what happens inside the

system is hidden:his boundary is clari>ed by the system

boundary#e>nes the scope of what a system will be:

) system boundary of a use case diagramde>nes the limits of the system:

he system boundary is shown as a rectanglespanning all the use cases in the system


63/80

63

&H&+M (OU7#)4H&H&+M (OU7#)4H

) use case diagram depicting the systemboundary of a clinic application


64/80

64

4+L)IO7&,I3& @4+L)IO7&,I3& @


65/80

65

ood 3racticeood 3ractice

#evelop a use case diagram atdi!erent levels whereverappropriate:

MinimiAes comple5ity &ystem level

Module level

Class

Interface etc


66/80

66

"LOE O" ++7&"LOE O" ++7&

&pecify the behavior of a use case bydescribing the 6ow of events in te5t clearlyenough for an outsider to understand iteasily:

Include ,ow and when the use case starts and ends

Ehen the use case interacts with the actors

Ehat objects are e5changed

he basic 6ow and alternative 6ows of thebehavior

"LOE O" ++7& $ j"LOE O" ++7& $major


67/80

67

"LOE O" ++7&@$major"LOE O" ++7&@$majorelements%elements%

2ntroduction: Describe a quick background of the usecase. Actors: List the actors that interact and participate in

this use case. Actor !escri'tion!e/nition: Dene/Describe each

actor.

7re-conditions: re!conditions that need to be satisedfor the use case to perform.

7ost-conditions: Dene the di"erent states in #hichyou e$pect the system to be in, after the use casee$ecutes.

#asic 6lo,: List the primary events that #ill occur #hen

this use case is e$ecuted. Alternatie 8o,s: %ny subsidiary events that can

occur in the use case should be separately listed. Listeach such event as an alternative &o#. % use case canhave as many alternative &o#s as required.


68/80

68

COMMO7 MO#+LI7 +C,7IXU+COMMO7 MO#+LI7 +C,7IXU+ he most common thing for which you will

apply use case is to model the "unctionalbehavior of an element W ) system as a whole'a subsystem' or a class

"ocus on what that element does' not how it does 4easons for applying use cases to elements


69/80

69

,I7& )7# I3&1,I7& )7# I3&1 "or developing use cases"or developing use cases

he goal is to develop a well-structured use

case that1 7ames a single identi>able' and reasonably

atomic behavior of the system or part of thesystem:

"actors common behavior by pulling such

behavior from other use cases that itincludes:

"actors variants by pushing such behaviorinto other use cases that e5tend it:

#escribes the 6ow of events clearly enoughfor an outsider to easily understand it:

Is described by a minimal set of scenariosthat specify the normal and variantsemantics of the use case:


70/80

70

,I7& )7# I3&,I7& )7# I3&

) well-structured use case diagram Is focused on communicating one aspect

of a systems static use case view:

Contains only those use cases that areessential to understanding that aspect:

3rovides detail content with its level ofabstraction:

Is not so minimalist as to misinform thereader about semantics that areimportant:


71/80

+5ample+5ample11

On-line (oo9store is a web application that can beaccessed by the stores registered customer'whereby each customer can order boo9s' reviewone or more boo9s sold in the boo9 store' and sellused boo9s to other customers: (efore performingany one of these transactions' the customer must>rst log-in into the system using their user id andpassword 9ept in their account: he customer canalso ta9e a boo9 he/she ordered:

3roblems1#evelop a use case model$system use case%-3rovide your

reason to pic9 Tone as a component of your model

#ocument one of the use cases you have identi>ed Tsell

used boo9

On-line Bookstore SystemOn-line Bookstore System


72/80

Z

RegisterRegister

Order booksOrder books

Sell usedSell used

booksbooks

Review booksReview books

CustomerCustomer

On line Bookstore Systemy

Log-inLog-in


73/80

ZJ

Use case1 &ell used boo9s

Main 6ow of events1 -

rmation page listing theinformation that

the CU&OM+4 has entered:B: he CU&OM+4 chec9s that the information displayed areaccurate:

If yes' the CU&OM+4 clic9s the OK button on the web page:Z: he system updates the U&+# (OOK& table in the database:

he bene>ts of basinghe bene>ts of basing


74/80

he bene>ts of basinghe bene>ts of basingsoftware development onsoftware development on

use casesuse caseshey can ,elp to de>ne the scopeof the system

(e used toplanthe development

process (e used to both develop and validate

the re*uirements

"orm the basis for the de>nition of test

cases (e used to structure user manuals

12/06/15 74

UUse cases must not be seense cases must not be seen


75/80

UUse cases must not be seense cases must not be seenas a solutionas a solution

he use cases themselves must bevalidated Using the re*uirements validation

methods:

&ome aspects of software are notcovered by use case analysis:

Innovative solutions may not be

considered:

12/06/15 75


76/80

TO # O3T23.!TO # O3T23.!

12/06/15 76


77/80

+5ercise-one+5ercise-one he cloc9 shows the time of day: Using buttons'

the user can set the hours and minutes >eldsindividually' and choose between res' it will sound some

noise: he user can turn it o!' or choose tosnooAe: If the user does not respond at all' thealarm will turn o! itself after minutes:&nooAing means to turn o! the sound' but the

alarm will >re again after some minutes ofdelay: his snooAing time is pre-adjustable:

9: 2denti%y the to'-leel %unctional requirement %or thecloc&" and model it ,ith a use case diagram0

12/06/15 77

i


78/80

+5ercise-two+5ercise-two Open Road Insurance (ORI) is an independent agency that

receives policy contracts from various insurance companies.The purpose of the ORI system is to provide automotive

insurance to car owners. Initially, a customer applies for

coverage via an application. The agency reuests a driver!s

record report from the local police department. The agency also

reuests vehicle registration confirmation from the "epartment

of #otor $ehicles. %n agent determines the best policy for the

type and level of coverage desired and sends the customer a

copy of the insurance policy along with an insurance coverage

card. The customer information is stored. &eriodically, thesystem generates a fee statement, which ' along with

addendums to the policy ' is sent to the customer, who responds

by sending in a payment with the fee stub.

12/06/15 78

id i


79/80

uide Linesuide LinesAsk who& what& and whereabout t!e tasks and

t!eir in'uts and out'uts()!at are t!e major tasks 'er*ormed+

)!at triggers t!is task+ )!at tells you to 'er*orm

t!is task+)!at in*ormation,*orms,re'orts do you need to

'er*orm t!is task+

)!o gives you t!ese in*ormation,*orms,re'orts+

)!at in*ormation,*orms,re'orts does t!is 'roduce

and w!ere do t!ey go+

12/06/15 79


80/80

object oriented sad-2 part i

Documents