l12_objectmodeling_ch05lect2

8/20/2019 L12_ObjectModeling_ch05lect2

1/44

U s i n g

U M L , P a t

t e r n s , a n d

J a v a

b e c

t - r e n

t e d

o t w a r e

E n g n e e r n g

Chapter 5, Analiz:Obje Modelleme


2/44

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

İçerik

Sistem modeli = Fonksiyonel model + Obje modeli+ Dinamik modelSon ders: Fonksiyonel model

• Şimdi: Obje modeli• Obje modellemesi aktiviteleri• Obje tanımlama (identification)• Obje tipleri

• il!i ("ntity)# sınır (bo$ndary) ve kontrol objeleri• %bott tekni&i

• Obje tanımlamada k$llanılır'


3/44


Use Case’den ObjelereLevel 1 Use Case

Level 2 Use Cases

Level 3 Use Cases

Operations

ParticipatingObjects

Level 2

Level 1

Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

A B


4/44


Use Case’den Objelere : Fonksiyonelparçalama neden yetersiz

Scenarios

Level 1 Use Cases

Level 2 Use Cases

Operations

ParticipatingObjects

Level 2

Level 1

Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

A B


5/44


Obje Modellemesi s ras nda !erçekle"enakti#iteler%ma : nemli soy$tlamaları b$lmaktır• Obje modellemesi sırasındaki adımlar

*' Sınıf elirleme• Soy$tlamaların b$l$nmasına ba&lı

' ,%ttrib$te- b$lma

.' Operasyonları b$lma/' Sınıfların arasındaki ili0kileri b$lmak

• 1anlı0 soy$tlamalar b$l$rsak ne ol$r2• 3ekrar ederek modelli d45eltiri5'


6/44


$ n % &elirleme

Obje tabanlı modellemede sınıfların belirlenmesiok 6nemlidir• Sistemin i indeki 6nemli par aların b$l$nmasını sa&lar

• 3emel yakla0ımlar:

*' 1eni bir ya5ılım projesi i in sınıf belirleme(For7ard "n!ineerin!)' 8arolan bir sistem i in sınıfların belirlenmesi

(9everse "n!ineerin!)


7/44


$ n % belirleme

• 1akla0ımlar• y!$lama alanı yakla0ımı • y!$lama alanındaki $5manlara temel

soy$tlamaların neler old$&$n$ sormak• Syntactic yakla0ım

• se ;aselerle a0la• Sınıfları b$lmak i in teksti anali5 et• Olay akı0ına bakarak objeleri tespit et

• 3asarım deseni yakla0ımı

• omponent tabanlı yakla0ım

•


8/44


Class identi'(ation is a )ard*roblem

• One problem: Definition of t e systembo$ndary:• @ ic abstractions are o$tside# 7 ic abstractions are

inside t e system bo$ndary2• %ctors are o$tside t e system• ;lassesAObjects are inside t e system

• %n ot er problem: ;lassesAObjects are not j$stfo$nd by takin! a pict$re of a scene or domain

• 3 e application domain as to be analy5ed

• Dependin! on t e p$rpose of t e system differentobjects mi! t be fo$nd• Bo7 can 7e identify t e p$rpose of a system2• Scenarios and $se cases =C F$nctional model'


9/44


+ç tip obje belirleye(e iz

• "ntity Objeleri• 9epresent t e persistent information tracked by t esystem (%pplication domain objects# also called

, $siness objects-)• Sınır Objeleri

• 9epresent t e interaction bet7een t e $ser and t esystem

• >ontrol Objeleri • 9epresent t e control tasks performed by t e system'


10/44


-.ample: /&0at(h Modelin!

Year

Month

Day

ChangeDateButton

LCDDisplay

"ntity Objects ;ontrol Object o$ndary Objects

3o distin!$is different object types

in a model 7e $se t eE Stereotype mec anism


11/44

1amin! Obje(t 2ypes in UM3

Year

ChangeDate

Button

Month

Day

LCDDisplay

"ntity Object ;ontrol Object o$ndary Object


12/44


4(ons %or Obje(t 2ypes:-ntity, Control and &o ndary Obje(t

• We can also use icons to identify a stereotype• When the stereotype is applied to a UML model element, the

icon is displayed beside or above the name

"ntity Object ;ontrol Object o$ndary Object

Year ChangeDate Button

%ctor

WatchUser

SystemBoundary


13/44


UM3 is an -.tensible 3an! a!e• Stereotypes a llow you to extend the vocabulary o f the

UML so that you can create n ew model elements, derivedfrom existing ones• Other Examples:

• Stereotypes ca n also be used to classify m ethod behavior suchas < >, or

• To indicate the interface of a subsystem or system, one can usethe stereotype (Lecture System Design)

• Stereotypes c an be represented with icons a s w ell asgraphics:

• 3 is can increase t e readability of E dia!rams'


14/44


6raphi(s %or $tereotypes• One can also use graphical symbols to identify a

stereotype• When the stereotype is applied to a UML model element, the

graphic replaces the default graphic for the diagram element.

• Example: When modeling a network, we can dene graphicalsymbols t o represent classes o f type Switch, Server, Router andPrinter .

Graphics f orClass of type

Router

Graphics f orClass of type

SwitchGraphics f orServer Class


15/44


*ros and Cons o% $tereotype6raphi(s

• Advantages:• UML diagrams m ay b e easier to understand if they c ontain

graphics and icons for stereotypes• This c an increase the readability of the diagram, especially

if the client is n ot trained in UML

• And they a re still UML diagrams!• Disadvantages:

• If developers are unfamiliar ith the symbols being used, it canbecome much harder to understand hat is going on

• !dditional symbols add to the burden of learning to read thediagrams.


16/44


Obje(t 2ypes allo7 s to deal 7ithChan!e

• Bavin! t ree types of object leads to models t atare more resilient to c an!e• 3 e interface of a system c an!es more likely t an t e

control• 3 e 7ay t e system is controlled c an!es more likely

t an entities in t e application domain• Object types ori!inated in Smalltalk:

• odel# 8ie7# ;ontroller ( 8;) odel GC "ntity Object 8ie7 GC o$ndary Object;ontroller GC ;ontrol Object

• He?t topic: Findin! objects'


17/44


Findin! *arti(ipatin! Obje(ts in UseCases

• Iick a $se case and look at flo7 of events• Do a te?t$al analysis (no$nGverb analysis)• Ho$ns are candidates for objectsAclasses• 8erbs are candidates for operations• 3 is is also called %bbottJs 3ec niK$e

• %fter objectsAclasses are fo$nd# identify t eirtypes

•


18/44


-.ample %or sin! the 2e(hni8 e

The customer enters the store to buy a toyIt has to be a toy that his daughter likes

and it must cost less than 50 Euro

He tries a videogame, which uses a dataglove and a head-mounted display. He likesit

An assistant helps him

The suitability of the game depends on theage of the child

His daughter is 3 years oldThe assistant recommends another type of

toy, the boardgame “Monopoly".

Flow of Events:


19/44


Mappin! !rammati(al (onstr (ts tomodel (omponents 9Abbot’s2e(hni8 e Grammatical

construct Proper noun

Improper noun

UML model

componentobject

class

Example

“Monopoly”

ToyDoing verb operationBuy, recommend

being verb inheritanceIs ahaving verb aggregationhas an

modal verb constraintmust be

adjective attributedangerous

transitive verb operationenter

intransitive verb Constraint, class, association

depends on

6 i Cl i % l %


20/44

videogame

• The customer enters the store to buy

a toy. It has to be a toy that hisdaughter likes and it must cost lessthan 50 Euro. He tries a videogame,which uses a data glove and a head-mounted display. He likes it.

6eneratin! a Class ;ia!ram %rom Flo7 o%-#ents

An assistant helps him. Thesuitability of the game dependson the age of the child. Hisdaughter is only 3 years old.The assistant recommends anothertype of toy, namely a boardgame.The customer buy the game and

leaves the store

customer enters

depends

storeCustomer

?

enter()

toy

daughter

suitable

*

less than 50

store

enter()

toy

buy()

toy

age

videogame

daughter

boardgame

Flo7 of events:

toy

pricebuy()like()

buy

type of toyboardgame

daughter

age

Customer


21/44


0ays to 'nd Obje(ts• Syntactical investi!ation 7it %bbotLs tec niK$e:

• Flo7 of events in $se cases• Iroblem statement

• se ot er kno7led!e so$rces:• %pplication kno7led!e: "nd $sers and e?perts kno7t e abstractions of t e application domain• Sol$tion kno7led!e: %bstractions in t e sol$tion

domain• Meneral 7orld kno7led!e: 1o$r !eneric kno7led!e and

int$tion


22/44


Order o% A(ti#ities %or Obje(t4denti'(ation

*' Form$late a fe7 scenarios 7it t e elp froman end $ser or application domain e?pert' "?tract t e $se cases from t e scenarios# 7it

t e elp of an application domain e?pert

.' 3 en proceed in parallel 7it t e follo7in!:• %nalyse t e flo7 of events in eac $se case$sin! %bbotNs te?t$al analysis tec niK$e

• Menerate t e E class dia!ram'


23/44


$teps in 6eneratin! Class ;ia!rams

*' ;lass identification (te?t$al analysis# domaine?pert)

'


24/44


0ho ses Class ;ia!rams<

• I$rpose of class dia!rams• 3 e description of t e static properties of a system• 3 e main $sers of class dia!rams:

• 3 e application domain e?pert•

$ses class dia!rams to model t e applicationdomain (incl$din! ta?onomies)• d$rin! reK$irements elicitation and analysis

• 3 e developer • $ses class dia!rams d$rin! t e development of a

system• d$rin! analysis# system desi!n# object desi!n

and implementation'


25/44


0ho does not se Class ;ia!rams<

• 3 e client and t e end $ser are $s$ally notinterested in class dia!rams• ;lients foc$s more on project mana!ement iss$es• "nd $sers are more interested in t e f$nctionality of

t e system'


26/44


$ mmary

• System modelin!• F$nctional modelin!+object modelin!+dynamic modelin!• F$nctional modelin!

• From scenarios to $se cases to objects

• Object modelin! is t e central activity• ;lass identification is a major activity of object modelin!• "asy syntactic r$les to find classes and objects• %bbotJs 3ec niK$e

• ;lass dia!rams are t e ,center of t e $niverse-for t e objectGoriented developer• 3 e end $ser foc$ses more on t e f$nctional model and

and $sability'


27/44


Additional $lides


28/44


0hat is 2his<


29/44


0hat is 2his<

Face

Eye

1..2


30/44


Modelin! in A(tion

•


31/44


*ie(es o% an Obje(t Model

• ;lasses and t eir instances (,objects-)• %ttrib$tes• Operations• %ssociations bet7een classes and objects


32/44


Asso(iations

• 3ypes of %ssociations• ;anonical associations

• IartGof Bierarc y (%!!re!ation)• >indGof Bierarc y (


33/44


Attrib tes

• Detection of attrib$tes is application specific• %ttrib$tes in one system can be classes inanot er system

• 3$rnin! attrib$tes to classes and vice versa


34/44


Operations

• So$rce of operations• se cases in t e f$nctional model• Meneral 7orld kno7led!e• Meneric operations: MetASet• Desi!n Iatterns• %pplication domain specific operations• %ctions and activities in t e dynamic model


35/44


Obje(t #s Class

• Object (instance): "?actly one t in!• 3 is lect$re on object modelin!• % class describes a !ro$p of objects 7it similar

properties• Mame# 3o$rnament# mec anic# car# database

• Object dia!ram: % !rap ical notation formodelin! objects# classes and t eir relations ips

• ;lass dia!ram: 3emplate for describin! many instancesof data' sef$l for ta?onomies# patters# sc emata'''

•


36/44


;e#elopers ha#e di=erent >ie7s onClass ;ia!rams

• %ccordin! to t e development activity# adeveloper plays different roles:• %nalyst• System Desi!ner• Object Desi!ner•


37/44


2he >ie7 o% the Analyst

• 3 e analyst is interested• in application classes: 3 e associations bet7eenclasses are relations ips bet7een abstractions in t eapplication domain

• operations and attrib$tes of t e application classes(difference to "A9 models )

• 3 e analyst $ses in eritance in t e model toreflect t e ta?onomies in t e application domain

• 3a?onomy: %n isGaG ierarc y of abstractions in anapplication domain

• 3 e analyst is not interested• in t e e?act si!nat$re of operations• in sol$tion domain classes


38/44


2he >ie7 o% the ;esi!ner• 3 e desi!ner foc$ses on t e sol$tion of t e

problem# t at is# t e sol$tion domain• 3 e associations bet7een classes are no7

references (pointers) bet7een classes in t eapplication or sol$tion domain

• %n important desi!n task is t e specification ofinterfaces:

• 3 e desi!ner describes t e interface of classes and t einterface of s$bsystems

• S$bsystems ori!inate from mod$les (term often $sedd$rin! analysis):

• od$le : a collection of classes• S$bsystem: a collection of classes 7it an interface

• S$bsystems are modeled in E 7it a packa!e'


39/44


6oals o% the ;esi!ner

• 3 e most important desi!n !oals for t edesi!ner are desi!n $sability and desi!nre$sability

• Desi!n $sability : t e interfaces are $sable fromas many classes as possible 7it in in t esystem

• Desi!n re$sability : 3 e interfaces are desi!nedin a 7ay# t at t ey can also be re$sed by ot er(f$t$re) soft7are systems

=C ;lass libraries=C Frame7orks=C Desi!n patterns'


40/44


2he >ie7 o% the 4mplementor

•;lass implementor• $st reali5e t e interface of a class in a pro!rammin!

lan!$a!e•


41/44


0hy do 7e distin! ish di=erentUsers o% Class ;ia!rams<

• odels often donLt distin!$is bet7eenapplication classes and sol$tion classes• 9eason : odelin! lan!$a!es like E allo7 t e $se of

bot types of classes in t e same model• ,address book,# ,arrayR

• Ireferred : Ho sol$tion classes in t e analysis model• any systems donLt distin!$is bet7een t e

specification and t e implementation of a class• 9eason : ObjectGoriented pro!rammin! lan!$a!es allo7

t e sim$ltaneo$s $se of specification andimplementation of a class

• Ireferred : @e distin!$is bet7een analysis model andobject desi!n model' 3 e analysis desi!n model doesnot contain any implementation specification'


42/44


Analysis Model #s? Obje(t ;esi!nmodel

• 3 e analysis model is constr$cted d$rin! t eanalysis p ase• ain stake olders: "nd $ser# c$stomer# analyst• 3 e class dia!rams contains only application domain

classes

• 3 e object desi!n model (sometimes also calledspecification model) is created d$rin! t e objectdesi!n p ase

• ain stake olders: class specifiers# classimplementors# class $sers and class e?tenders• 3 e class dia!rams contain application domain as 7ell

as sol$tion domain classes'


43/44


Analysis Model #s Obje(t ;esi!nModel 9/

• 3 e analysis model is t e basis forcomm$nication bet7een analysts# applicationdomain e?perts and end $sers'

• 3 e object desi!n model is t e basis forcomm$nication bet7een desi!ners andimplementors'


44/44

$ mmary

• System modelin!• F$nctional modelin!+object modelin!+dynamic modelin!

• F$nctional modelin!• From scenarios to $se cases to objects

• Object modelin! is t e central activity• ;lass identification is a major activity of object modelin!• "asy syntactic r$les to find classes and objects• %bbotJs 3ec niK$e

• %nalysts# desi!ners and implementors ave different

modelin! needs• 3 ere are t ree types of implementors 7it differentroles d$rin!

• ;lass $ser# class implementor# class e?tender'

l12_objectmodeling_ch05lect2

Documents