7. developing the structural model (2).pptx

8/16/2019 7. Developing the Structural Model (2).pptx

1/67

Developing the Structural

Model

Dr Kristin Stock


2/67


3/67

∗ More on class diagrams:

∗ Diferent tpes o! associations

∗ "ssociation classes∗ More on o#$ect diagrams.

∗ %ackage diagrams.

∗ &omposite structure diagrams.

∗ 'nsuring consistenc in class diagrams.

∗ &ase stud.

(utline


4/67

∗ )n a class diagram* the o#$ects in the sstem

+concepts in the conceptual model, arerepresented as classes.

∗ " class is a group o! individual o#$ects.

∗ '.g. the class road* person* customer* cake.

∗ )n -M* we create class diagrams to show theclasses involved in a sstem* and theirinteractions.

&lasses


5/67

∗ We create classes to model categories o! o#$ects

in the real world.∗ Which o#$ects?

∗ /ow much detail?

∗ )t all depends on the application. What is its

purpose?∗ Which objects are needed to support that

purpose.

&lasses !rom the 0eal World


6/67

∗ What people and organi1ations does the sstem

keep track o!?∗ &ustomer* card holder* #oard mem#er2

∗ What events and transactions does the sstem keepa record o!?

∗ Sale2

∗ What products and services does the sstem keep arecord o!?

∗ &hecking account +product,* check returns +services,2

)nterview 3uestions !or 4inding&lasses


7/67

∗ )s it important that the #usiness track this class?

∗

e.g. Do ou actuall keep track o! our customers?∗ Do apparentl similar classes var in attri#utes*

operations* methods or relationships?

∗ )! not* the are one class

∗ )s a candidate class $ust in!ormation a#out something

else?∗ Ma #e an attri#ute* not a class

∗ )s one class name an alias !or another?

∗ -se one class 5 record the alias in the glossar

∗ e.g. customer 6 client

&hallenge 3uestions


8/67

Classes, Attributes, & Operations

∗ Classes

•Templates for instances of people,

places, or things∗ Attributes

•Properties that describe the state

of an instance of a class (an object)

∗ Operations

•Actions or functions that a class

can perform


9/67

∗ &haracteristics o! a class.

∗ (!ten in a textual descriptions* the

are ad$ectives +the red car* thechocolate cake* the !ast deliver,.

∗ )t is not alwas clear whethersomething should #e modelled as

an attri#ute or a class:∗ Make it a class i! it has other

attri#utes or operations o! its own*otherwise an attri#ute.

∗ camel&ase* singular

"ttri#utes


10/67

Attribute Appendages

∗ Attributes can be derived

∗ Preceded with a slash ()

∗ e!g!, age is derived from date of birth

∗ "isibilit# of an attribute$

∗ %estricts access to attributes to ensure consistenc#

∗ Public attributes ()$ visible to all classes

∗ Private attributes (')$ visible onl# to an instance of the class in which

the# are defined

∗ Protected attributes ()$ visible onl# to an instance of the class in

which the# are defined and its descendants


11/67

'xample

/ouse

7street8um#er

9housepe9#uildDate7;age9owner


12/67


13/67

Operation T#pes

∗ Common operations are not shown

∗ Create or delete an instance

∗ %eturn or set a value

∗ T#pes of operations$

∗ Constructorcreates an object

∗

*uer#ma+es information about the state of an objectavailable

∗ pdatechanges values of some or all of an object-s attributes

∗ .estructordeletes or removes an object


14/67

∗ "ssociations #etween classes.

∗ )ndicate some link or dependenc.

∗ here are man kinds o! associations* usuall thecan #e descri#ed with a ver# +has* contains* is parto!* etc,.

∗ Should #e a#le to @read throughA the diagram with

classes and associations.

0elationships

house street cit

is in is in


15/67

'xample

/ouse

street8um#erhousepe#uildDateowner

re#uildrenovate

Street

streetpeoneWasu#ur#

is in

=>..


16/67

/ultiplicities

.epartment 0oss

1mplo#ee Child

0oss 1mplo#ee

2 2

2 3!!4

2 2!!4

Exactly one:

A department has one and

onl# one boss

Zero or more:

An emplo#ee has 5ero to

man# children

One or more:

A boss is responsible for

one or more emplo#ees


17/67

Multiplicity Indicator Meaning

>..= ero or one

>.. ero or more

ero or more +an alternative to >..,

=.. (ne or more

= (ne and onl onen 'xactl n* as in C

a..b 4rom a through b* as in =..

0ules 0egarding Multiplicit


18/67

∗ Dependenc

∗ "ssociation:∗ Eeneralisation

∗ "ggregation

∗ &omposition

pes o! 0elationships in

-M


19/67

∗ )ndicates that one class uses the other.

∗ his is the most general tpe o! relationship 5#etter to #e more speciFc i! possi#le* with anassociation +including name and multiplicit,*generalisation* composition or aggregation.

∗ More common in some other tpes o! diagrams

Dependencies


20/67

∗ Binar "ssociations

∗ "n o#$ect o! one class is related to an o#$ect +or o#$ects,o! a diferent class

∗ e.g. each &ase o#$ect is associated with %amento#$ects

∗ 0eGexive +or sel!9re!erencing, "ssociations

∗ "n o#$ect o! a class is associated with other o#$ects o!the same class

∗ e.g. one emploee +the manager, manages otheremploees +team mem#ers,

"ssociations


21/67

'xample

/ouse

street8um#erhousepe#uildDateowner

re#uildrenovate

Street

streetpeoneWasu#ur#

is in

=>..

intersects with

What kind o! multiplicit might the

intersects with association have?


22/67


23/67

6enerali5ation Associations

∗ 6eneralisation means$

∗ 7is a-

∗ 7is a t#pe of-

∗ subclass

∗ subt#pe

∗ Generalization denotes inheritance∗ Properties and operations of the superclass are valid for the sub'class

∗ .epicted as a solid line with a hollow arrow pointing at the superclass


24/67

'xample

/ouse

7street8um#er



25/67

∗ Wh model generali1ation?

∗ 0educed redundanc in the reHuirements

∗ Eenerali1ed classes can #e reused !or !uture speciali1edclasses

∗ 0ules:

∗ he speciali1ed class inherits all the attri#utes* operationsand relationships o! the generali1ed class

∗ he speciali1ed class ma add attri#utes* operations andrelationships

∗ he speciali1ed class ma have polmorphic methods

∗ Multiple inheritance is possi#le +#ut not supported # alllanguages,

Modeling Eenerali1ation


26/67

∗ 4und"ccount

and&ash"ccountwould inheritall the !eatures

o!)nternal"ccount

Eenerali1ation in the -M

InternalAccount

FundAccount CashAccount

Generalized

Class

Specialized

classes


27/67

Aggregation and Composition

Associations

∗ Aggregation and Composition mean$

∗ 7is part of-

∗ Aggregation denotes a logical 8a'part'of9 relationship

∗

Composition denotes a ph#sical 8a'part'of9 relationship


28/67

∗ "ggregation and composition descri#e the relationship

#etween a @wholeA and its @partsA∗ )! a @partA can #elong to more than one @wholeA* and

continues to exist i! the @wholeA is destroed* model asaggregation

∗ @&ollectionA* @listA* @groupA2

∗ )! the @partA is owned # the @wholeA and ceases to exist i!the @wholeA is destroed* model as composition

∗ @composed o!A* @componentA2

∗ )! in dou#t* use aggregation

Model Whole;%art 0elationships


29/67

∗ "n unFlled diamond indicates the @wholeA

end o! the relationship

"ggregation in the -M

Inventory Product

ProfessionalAssociation

Company


30/67

∗ " Flled diamond indicates the @wholeA end o!

the relationship

&omposition in the -M

Vehicle

VehiclePart

Order LineItem


31/67

∗ "nother wa o! showing composition !rom -M I

∗ his example shows component @partsA in a vehicle@wholeA

&omposite StructureDiagram

heel A!le

"#

attached to

# "

Jehicle


32/67

∗ 4or generalisation* it must make sense to sa @x is

a tpe o! A∗ 4or aggregation and composition* it must make

sense to sa @x is a part o! A

∗ )! x can survive without * it is aggregation*

otherwise composition.∗ )! neither generalisation or aggregation* then

unadorned association.

Eeneralisation vs "ggregation vs&omposition vs "ssociation


33/67

∗ eg 5 Bod

∗ Knee 5 eg

∗ eg 5 im#

∗ Kneecap 5 Knee

∗ &racked Kneecap 5Kneecap

∗ &clone 5 8aturalDisaster

∗ &clone 5 Bush 4ire

∗ &clone 5 &asualties

∗ &clone 5 Storm

∗ Soldier 9 "rm

Which is which?

Generalisation

Association

Aggregation

Composition


34/67

Association Classes

∗ Common in man#'to'man# relationships

∗ sed when attributes about the relationship between twoclasses needs to be recorded

∗ :tudents are related to courses; a 6rade class provides an attribute

to describe this relationship

∗


35/67

'xample

/ouse

7street8um#er



36/67

(#$ect Diagrams

∗ &lass diagrams with instantiated classes∗ 'xample: instead o! a Doctor class* create an

actual doctor* sa Dr. Smith

∗ %lace values into each attri#ute

∗ -sed to discover additional attri#utes*relationships and;or operations or thosethat are misplaced


37/67

1=ample Object .iagram


38/67

∗ Sometimes an o#$ect diagram can help to show

reHuirements #etter than class diagrams alone∗ e.g. where classes have multiple associations

∗ /ere* a trans!er has associations with two diferentaccounts

Modeling (#$ect inks with(#$ect Diagrams

$ransfer Account

debited from

credited to%receivin&Account

%sendin&Account


39/67

∗ he names inside the rectangle are o! o#$ects* not

classes∗ (#$ect names are underlined

∗ he !ull !ormat is object-name : class-name

∗ e.g fromAccount : Account

∗

he o#$ect name can #e omitted∗ " relationship #etween o#$ects is known as a link * as

opposed to an association

∗ ink names should #e underlined

(#$ect Diagrams in -M


40/67

∗ /ere* the links #etween a single +anonmous,

rans!er o#$ect and two +named, "ccount o#$ectare descri#ed

(#$ect Diagram 'xample

:rans!er !rom"ccount:"ccount

to"ccount:"ccount

de#ited !rom

credited to


41/67

∗ -se packages i! there are man classes

∗ " package ma contain other packages

∗ %ut all o! them on a single diagram

∗ "ppl a suita#le grouping

∗ e.g. @GavoursA o! #usiness classes

Erouping &lasses into %ackages

%eople and(rgani1ations

%roducts andServices

'vents; ransactions


42/67

∗ " large package with the classes inside

∗ Keep it simple 9 do not include class relationships in

these diagrams∗ 'xcept perhaps generali1ation

he %ackage Diagram

%roducts and Services

Digital&ell%hone &all0eturn


43/67

pkg HDMv2 Overview

'ApplicationSchema(


44/67

'Application Schema(

HDM_Core

% Core)lements

% Feature$ypeCatalo&ue

% *etadataProfile

% *etadataStructures +to ,e removed -hen metadataprofil e is complete.

% Presentation/ules

% VersionAndAudi t


HDM_Admininstrative Interests

% Admini nstrativeInterest

% Admini strativeInterest$ype


HDM_AdministrativeAreas

% Admini nstrativeArea$ype

% Admi nistrativeArea


HDM_Cadastre

+ CoexistingEstate

% Coe!istin&)state$ype

% )asement

% Primary)state

% Primary)state$ype

% SecondaryInterest

% SecondaryInterestLifecycle% SecondaryInterest$ype

% $itle

% CadastralLite

% Property


HDM_Env ironmentalInterests

% )nvi ronmentalInterest

% )nvironmental Interest$ype


HDM_Geodesy

% 0ei&ht1atum


HDM_Native Title

% Indi &enousLand2seA&reements

% 3ative$itle FutureActs

% 3ative$itleApplications

% 3ative$itle1eterminations

% 3ative$itle$enureOpinions

'Application Schema(HDM_la!eNames

% 1isplayPoint

% Place3ame


HDM_"ig#ts"estri!tions"esponsi$ilities

% AnticipatedLifecycleSta&e

+ Interest

% InterestFunction

% InterestGeometry

% Interest0older

% Interest0older$ype

% Interest/elationship

% Interest/elation ship$ype

% Interest$ype

% Le&al1ocument

% LifecycleSta&e

% /elationship$ ype)!ists


HDM_%treetAddresses

% Address

% AddressGeocode

% Geocode$ype


HDM_%&rve ys

% SurveyO,servations

% SurveyPlans


HDM_Tidal"ealm

% $ idalGau&e*etadata

% $idal0ei&ht

% $idalInterface


HDM_Topograp#y

% )arthSurface

% GeneralFeature

% Inl andaterFeature

% /ail-ay

% /oad

% /oute

% /outeSe&ment

% $an4

% $opoCompCurve)lement

% $opo&raphicFeature

% $ opoPoint)lement

% $opoSimpleCurve)lement

% $opoSurface)lement

% 2tility

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'import(

'access(

'access(

'import(


45/67

pkg a!kageDependen!ies

'Leaf(

NativeTitle'&t&reA!ts

% FutureActLifecycle

% FutureAct

% /i&ht$o3e&otiate

% CompulsoryA5uisition

'Leaf(

Indigeno&s(and)seAgreements

% Indi&enousLand2seA&reementLifecycle

% Indi&enousLand2seA&reement

% Surrender

'Leaf(

NativeTitleAppli!ations

% Appli cation1ocument

% Appli cationLifecycle

% Application$ype

% /e&isterOf3ative$itleClaims/e&istrationLifecycle

% Application

'Leaf(

NativeTitleDeterminations

% 1etermination$ype

% 3ational3ative$itle/e&isterLifecycle

% 1etermination

% 3ative$itleInterest

% 3ative$itleA,sence% 1etermined3ative$itle/i&ht

% 1eterminationOutcome

'Leaf(

NativeTitleTen&reOpinions

% AssessmentOr)!tin&uishmentCate&ory

% 3ative$itle)!tin&uishmentOpinionLifecycle

% 3ative$itle)!tin&uishmentOpinion


HDM_"ig#ts"estri!tions"esponsi$ilities

% AnticipatedLifecycleSta&e

+ Interest

% In terestFunction

% InterestGeometry

% Interest0older

% Interest0older$ ype

% Interest/elati onship

% Interest/elationship$ype

% Interest$ype

% Le&al 1ocument

% LifecycleSta&e

% /elationship$ype)!ists

(from ICSM)

'import( 'import(

'import('import(

'import(

'access(

'access(


46/67

(ptimi1ing &onsistenc in the

0eHuirements Documentation


47/67

∗ 'nsure a candidate attri#ute is not alread +or could

#e, a separate class∗ )t i! is* it will #e an association* not an attri#ute

∗ 'nsure that the attri#ute needs to #e applied to eacho#$ect* not have the same value !or the whole class

∗ )t could #e a class +static, attri#ute

∗ ist attri#utes as !ar up a generali1ation hierarch aspossi#le

∗ So the can #e inherited # speciali1ations

"ssigning "ttri#utes to &lasses


48/67

∗ &an #e derived !rom other parts o! the model

∗)mportant not to store values that should #e calculated toavoid data integrit pro#lems

∗ e.g. an @ageA attri#ute should #e derived

∗ )ndicated # a !orward slash

∗ ;derived attribute

∗ e.g. a line item total might #e derived !rom @unit%riceA and@HuantitA attri#utes

∗ Document somewhere how it can #e derived* e.g.

∗ ;line)temotal 6 unit%rice Huantit

Derived "ttri#utes


49/67

∗ he !ull notation !or an attri#ute in -M !ollows the !orm

∗attri#ute8ame:attri#utepe Lmultiplicit 6 de!ault

∗ (nl the name is essential !or analsis

∗ Both name and tpe reHuired !or design

∗ Jarious com#inations are possi#le

∗ 'xamples might #e

∗ color : String

∗ middle)nitials : &haracter L>..I

∗ credit%oints : int 6 =

"ttri#ute 8otation


50/67

∗ hese ma #e an o! the !ollowing:

∗

-ser deFned @valueA tpe∗ e.g. %hone8um#er

∗ " generic* complex data tpe +has its own attri#utes,

∗ 8ot an association with a #usiness o#$ect +entit class,

∗ " unit o! measurement

∗

e.g. @KilometreA +spelling to match coding guidelinesN,∗ &an #e assumed at the analsis stage

∗ Will need to #e deFned more speciFcall at design time

∗ " data tpe supported # the target programming language

"ttri#ute pes


51/67

∗ )nteger

∗ " whole num#er +no !ractions,

∗ Boolean

∗ rue;4alse* es;no

∗ &haracter

∗ " single +-nicode, character

∗ String

∗

ext 5 an string o! characters∗ 4loat ; Dou#le ; Decimal

∗ " decimal num#er

∗ Date ; imestamp

∗ " speciFc date and time

=O.II Sstems "nalsis and Design I>=C =

&ommon %rogramming Data pes


52/67

∗ "ttri#utes o! attri#utes

∗

JeriFcation rules and other attri#ute properties∗ pe* multiplicit and de!ault values are all meta9attri#utes

∗ So is the deFnition o! an attri#ute as #eing derived

∗ hese are part o! the standard attri#ute notation

∗ (ther meta9attri#utes will need to #e recorded more

in!ormall∗ &an add a constraint +in #races, to an attri#ute

∗ e.g. account8ame : String Pnot nullQ

Meta9"ttri#utes


53/67

∗ 0eHuired +not null,

∗ Does the attri#ute alwas have to have a value?

∗-niHueness∗ Does an attri#ute have to have a uniHue value* like a primar ke?

∗ "ccepta#le range o! values

∗ e.g. num#er o! hours worked in a da cannot #e less than 1ero or exceed IC

∗ ist o! accepta#le values

∗ e.g. @sexA can onl #e @maleA or @!emaleA

∗ "ccurac

∗

e.g. rounding o! Goating point values∗ ength

∗ e.g. the maximum si1e o! a text +String, attri#ute

∗ Dependencies on other attri#utes

∗ e.g. one date value might have to occur a!ter another +outward Gight occurs #e!ore inward Gight,

Meta9"ttri#ute 'xamples


54/67

"ttri#utes o! a &lass

∗ " Bank"ccount class with attri#utes

account3um,er 6 Inte&er

account3ame 6 Strin& 7not null8,alance 6 *oney 9 :

;availa,le


55/67

)s )t "n "ttri#ute?

∗ )! a concept is not represented as a num#er

or text in the real world* it is pro#a#l aclass* not an attri#ute

∗ "re these all attri#utes?

3ualiFcation

level : )ntegername : Stringinstitution : String


56/67

∗ "n activit that pertains to a class and is consistent

across use cases∗ e.g. a &ash"ccount class might have a Withdraw4unds

operation

∗ 0arel added at the #usiness analsis stage

∗ )ncreasingl important as we move towards design

∗ )! an operation applies to all su#tpes* add it to agenerali1ation

∗ e.g. all tpes o! "ccount

∗ Speciali1ations ma use polmorphic methods

(perations


57/67

∗ he !ull notation !or an operation in -M !ollows the !orm

∗

operation8ame+argument=:argument=pe*argumentI:argumentIpe*2, : 0eturnpe

∗ "n operation ma have 1ero or more parameter arguments

∗ hese are values passed to the operation to ena#le it toper!orm its tasks

∗ he return tpe speciFes the tpe o! value that is returned

!rom the operation when it has Fnished its work

∗ his ma #e nothing +a @voidA tpe,

(peration 8otation


58/67

∗ 'xamples o! operations might #e

∗ withdraw&ash+amount:Mone,

∗ get"ge+, : )nteger

∗ calculate)nterest+principal:Mone* )nterest:Dou#le*%eriod:)nteger, : Mone

∗ get'nrolmentDetails+id : Student)D, : 'nrolment

∗ is'nrolled+, : Boolean

∗ 8ote that parameter arguments and return tpes can #eo#$ects as well as simple data tpes

∗ "n operation will onl make sense in the context o! the classit #elongs to

(peration 'xamples


59/67

∗ We create lookup ta#les !or controlled lists o!values !or an attri#ute

∗ e.g. sets o! codes that are used

∗ -sers can add;edit the list themselves.

∗ But:

∗

)! overused* the are meaningless #ecause people $ust add codes !or everthing

∗ )! underused* makes search more diRcult* data ismess and diRcult to analse

ookup a#les


60/67


61/67

)8S%)0'


62/67

∗ 'uropean Directive.

∗ http:;;inspire.ec.europa.eu;∗ Develops standards and processes to share data

across C themes important !or environmentalmanagement* among IO mem#er states.

)8S%)0'


63/67


64/67

∗ &onvened thematic experts !rom around

'urope.∗ /ad workshops to identi! relevant classes

and attri#utes.

∗ "lso several existing domain models in use

around 'urope.

%rotected Sites


65/67


66/67


67/67

:ummar#

∗ :tructural /odels

∗ Classes, Attributes, Operations, Associations!∗ /ore detail on these ne=t time!

∗ "erif#ing and validating!

7. developing the structural model (2).pptx

Documents