Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation...

Post on 08-Sep-2019

1 views 0 download

Transcript of Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation...

Detailed DesignDetailed Design

© 2010 Bennett, McRobb and Farmer 1

Based on Chapter 14Bennett, McRobb and Farmer

Object Oriented Systems Analysis and Design Using UML

4th Edition, McGraw Hill, 2010

In This Lecture You Will Learn:

• how to design attributes• how to design operations• how to design classes • how to design associations

© 2010 Bennett, McRobb and Farmer 2

• how to design associations• the impact of integrity constraints on

design.

Attribute and Operation Specification

• Deciding the data type of each attribute.• Deciding how to handle derived attributes.• Adding primary operations.• Defining the signature of operations

© 2010 Bennett, McRobb and Farmer 3

• Defining the signature of operations including the types of parameters.

• Deciding the visibility of attributes and operations.

Attribute Data Types • An attribute’s data type is declared in a UML class

diagram using the following syntax:

<property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity> ‘]’] [‘=’ <default>] [‘{‘ <property-string > [‘,’ <property-string >]* ’}’]

© 2010 Bennett, McRobb and Farmer 4

[‘{‘ <property-string > [‘,’ <property-string >]* ’}’]Where

– name is the attribute name– prop-type is its data type– default is the value the attribute is set to when the object is first

created– property-string describes a property of the attribute, such as

constant or fixed

Class Specification: Attributes

BankAccount class with the attribute data types included

Shows a derived attribute

BankAccount

nextAccountNumber: IntegeraccountNumber: IntegeraccountName: String {not null}balance: Money = 0/availableBalance: Money

© 2010 Bennett, McRobb and Farmer 5

includedattribute/availableBalance: MoneyoverdraftLimit: Money

open(accountName: String):Booleanclose(): Booleancredit(amount: Money): Booleandebit(amount: Money): BooleanviewBalance(): MoneygetBalance(): MoneysetBalance(newBalance: Money)getAccountName(): StringsetAccountName(newName: String)

Class Specification: Attributes

• The attribute balance in a BankAccount class might be declared with an initial value of zero using the syntax

balance:Money = 0.00

© 2010 Bennett, McRobb and Farmer 6

• Attributes that may not be null are specifiedaccountName:String {not null}

• Arrays are specifiedqualification[0..10]:String

Primary Operations

• Constructor – operation to create an instance of a class. Usually has the same name as the class.

• Destructor – operation to delete an • Destructor – operation to delete an instance of a class from memory. C# and C++ have explicit destructors named the same as the class with a tilde at the beginning, e.g. ~BankAccount.

7© 2010 Bennett, McRobb and Farmer

Primary Operations

• get operation – operation to get the value of an attribute, also known as an Accessor.

• set operation – operation to set the value • set operation – operation to set the value of an attribute, also known as a Mutator.

8© 2010 Bennett, McRobb and Farmer

Operation Signatures

• An operation’s signature is determined by the operation’s name, the number and type of its parameters and the type of the return value if any. The syntax used for an

© 2010 Bennett, McRobb and Farmer 9

return value if any. The syntax used for an operation is:

[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] [‘{‘ <property-string> [‘,’ < property-string >]* ‘}’]]

Operation Signatures

• The part that is mandatory is the name of the operation followed by a pair of brackets.

• The parameter-list is optional.

© 2010 Bennett, McRobb and Farmer 10

• The parameter-list is optional.

Operation Signatures

• If included, it is a list of parameter names and types separated by commas:

<parameter-list> ::= <parameter> [‘,’<parameter>]* [‘,’<parameter>]*

<parameter> ::= [<direction>] <parameter-name> ‘:’ <type-expression> [‘[‘<multiplicity>’]’]

[‘=’ <default>] [‘{‘ < property-string > [‘,’ < property-string >]* ‘}’]

11© 2010 Bennett, McRobb and Farmer

Operation Signatures

• BankAccount might have a credit() operation that would be shown in the diagram as:

credit(amount: Money): Boolean credit(amount: Money): Boolean

• credit() message sent to a BankAccount object could be written in a program as:

creditOK = accObject.credit(500.00)

12© 2010 Bennett, McRobb and Farmer

Operation Signatures

• In Java the operation would be designed to throw an exception if it failed as in the following snippet of code.

try{accObject.credit(500.00);} catch (UpdateException){ //some error handling; }

13© 2010 Bennett, McRobb and Farmer

Operation Signatures

BankAccount

nextAccountNumber: IntegeraccountNumber: IntegeraccountName: String {not null}

© 2010 Bennett, McRobb and Farmer 14

BankAccount class with operation signatures included.

accountName: String {not null}balance: Money = 0/availableBalance: MoneyoverdraftLimit: Money

open(accountName: String):Booleanclose(): Booleancredit(amount: Money): Booleandebit(amount: Money): BooleanviewBalance(): MoneygetBalance(): MoneysetBalance(newBalance: Money)getAccountName(): StringsetAccountName(newName: String)

Which Operations?

• Show primary operations where it is necessary

• Only show constructors where they have special significance

© 2010 Bennett, McRobb and Farmer 15

special significance• Varying levels of detail at different stages

in the development cycle

Visibility

Visibility symbol

Visibility Meaning

+ Public The feature (an operation or anattribute) is directly accessible by aninstance of any class.

© 2010 Bennett, McRobb and Farmer 16

- Private The feature may only be used by aninstance the class that includes it.

# Protected The feature may be used either by theclass that includes it or by a subclassor descendant of that class.

~ Package The feature is directly accessible onlyby instances of a class in the samepackage.

VisibilityBankAccount class with alternative visibility specifications

BankAccount

- nextAccountNumber: Integer- accountNumber: Integer- accountName: String {not null}- balance: Money = 0.0- /availableBalance: Money- overdraftLimit: Money

BankAccount

- nextAccountNumber: Integer- accountNumber: Integer- accountName: String {not null}- balance: Money = 0.0- /availableBalance: Money- overdraftLimit: Money

private attributes

derived attribute

class-scope attribute(a) (b)

class-scope operation

BankAccount

- nextAccountNumber: Integer- accountNumber: Integer- accountName: String {not null}- balance: Money = 0.0- /availableBalance: Money- overdraftLimit: Money

BankAccount

- nextAccountNumber: Integer- accountNumber: Integer- accountName: String {not null}- balance: Money = 0.0- /availableBalance: Money- overdraftLimit: Money

BankAccount

- nextAccountNumber: Integer- accountNumber: Integer- accountName: String {not null}- balance: Money = 0.0- /availableBalance: Money- overdraftLimit: Money

BankAccount

- nextAccountNumber: Integer- accountNumber: Integer- accountName: String {not null}- balance: Money = 0.0- /availableBalance: Money- overdraftLimit: Money

private attributes

derived attribute

class-scope attribute(a) (b)

class-scope operation

© 2010 Bennett, McRobb and Farmer 17

+ open(accountName: String):Boolean+ close(): Boolean+ credit(amount: Money): Boolean+ debit(amount: Money): Boolean+ viewBalance(): Money- getBalance(): Money- setBalance(newBalance: Money)- getAccountName(): String- setAccountName(newName: String)

+ open(accountName: String):Boolean+ close(): Boolean+ credit(amount: Money): Boolean+ debit(amount: Money): Boolean+ viewBalance(): Money# getBalance(): Money# setBalance(newBalance: Money)# getAccountName(): String# setAccountName(newName: String)

private operations

protected operations

public operations+ open(accountName: String):Boolean+ close(): Boolean+ credit(amount: Money): Boolean+ debit(amount: Money): Boolean+ viewBalance(): Money- getBalance(): Money- setBalance(newBalance: Money)- getAccountName(): String- setAccountName(newName: String)

+ open(accountName: String):Boolean+ close(): Boolean+ credit(amount: Money): Boolean+ debit(amount: Money): Boolean+ viewBalance(): Money- getBalance(): Money- setBalance(newBalance: Money)- getAccountName(): String- setAccountName(newName: String)

+ open(accountName: String):Boolean+ close(): Boolean+ credit(amount: Money): Boolean+ debit(amount: Money): Boolean+ viewBalance(): Money# getBalance(): Money# setBalance(newBalance: Money)# getAccountName(): String# setAccountName(newName: String)

+ open(accountName: String):Boolean+ close(): Boolean+ credit(amount: Money): Boolean+ debit(amount: Money): Boolean+ viewBalance(): Money# getBalance(): Money# setBalance(newBalance: Money)# getAccountName(): String# setAccountName(newName: String)

private operations

protected operations

public operations

Grouping Attributes and Operations in Classes

• Checking that responsibilities have been assigned to the right class.

• Defining or using interfaces to group together well-defined standard behaviours.together well-defined standard behaviours.

• Applying the concepts of coupling and cohesion.

• Applying the Liskov Substitution Principle.

18© 2010 Bennett, McRobb and Farmer

Interfaces

• UML supports two notations to show interfaces– The small circle icon showing no detail– A stereotyped class icon with a list of the operations

supported– Normally only one of these is used on a diagram

© 2010 Bennett, McRobb and Farmer 19

– Normally only one of these is used on a diagram

• The realize relationship, represented by the dashed line with a triangular arrowhead, indicates that the client class (e.g. Advert) supports at least the operations listed in the interface

Interfaces for the Advertclass - staffNo

- staffName- staffStartDate- qualification

CreativeStaff

+ calculateBonus()+ linkToNote()

- title

Advert

- companyName- companyAddress- companyTelephone- companyFax- companyEmail- contactName- contactTelephone- contactEmail

Client

+ assignStaffContact()+ changeStaffContact()

Usage dependency - staffNo

- staffName- staffStartDate- qualification

CreativeStaff

+ calculateBonus()+ linkToNote()

- title

Advert

- companyName- companyAddress- companyTelephone- companyFax- companyEmail- contactName- contactTelephone- contactEmail

Client

+ assignStaffContact()+ changeStaffContact()

Usage dependency

© 2010 Bennett, McRobb and Farmer 20

- title- type- targetDate- estimatedCost- completionDate

+ getCost()+ setCompleted()+ view()

Realize relationship

« interface»Manageable

+ getCost()+ setCompleted()

Viewable

‘Ball and socket’notation

- title- type- targetDate- estimatedCost- completionDate

+ getCost()+ setCompleted()+ view()

Realize relationship

« interface»Manageable

+ getCost()+ setCompleted()

Viewable

‘Ball and socket’notation

Coupling

• Coupling describes the degree of interconnectedness between design components – reflected by the number of links an object has

© 2010 Bennett, McRobb and Farmer 21

– reflected by the number of links an object has and by the degree of interaction the object has with other objects

Cohesion

• Cohesion is a measure of the degree to which an element contributes to a single purpose

• The concepts of coupling and cohesion are not mutually exclusive but actually support each

© 2010 Bennett, McRobb and Farmer 22

mutually exclusive but actually support each other

• Coad and Yourdon (1991) suggested several ways in which coupling and cohesion can be applied within an object-oriented approach

Interaction Coupling

• A measure of the number of message types an object sends to other objects and the number of parameters passed with these message types.

© 2010 Bennett, McRobb and Farmer 23

these message types.• Should be kept to a minimum to reduce

the possibility of changes rippling through the interfaces and to make reuse easier.

Inheritance Coupling

Vehicle

decription serviceDate maximumAltitude takeOffSpeed

checkAltitude()

Inheritance Coupling describes the degree to which a subclass

Poor inheritance coupling as unwanted attributes and operations are inherited

© 2010 Bennett, McRobb and Farmer 24

checkAltitude() takeOff()

LandVehicle

numberOfAxles registrationDate register()

to which a subclass actually needs the features it inherits from its base class.

Inheritance Coupling

Vehicle

descriptionserviceDate

Inheritance Coupling is better here – all inherited attributes are needed.

25© 2010 Bennett, McRobb and Farmer

AirVehicleLandVehicle

numberOfAxlesregistrationDate

register()

takeOffSpeed

maximumAltitude

checkAltitude()

takeOff()

Operation Cohesion

Lecturer

lecturerName lecturerAddress

© 2010 Bennett, McRobb and Farmer 26

lecturerAddress roomNumber roomLength roomWidth

calculateRoomSpace()

{return roomLenght* roomWidth;}

Good operation cohesion but poor class cohesion

Poor Specialization Cohesion

Address

number street town county country

Specialization Cohesion addresses the

© 2010 Bennett, McRobb and Farmer 27

country postCode

Person

personName age gender

Company

companyName annualIncome annualProfit

addresses the semantic cohesion of inheritance hierarchies

Improved Structure

Address

number street town county

Improved structure

© 2010 Bennett, McRobb and Farmer 28

county country postCode

Person

personName age gender

Company

companyName annualIncome annualProfit

lives at is based at

usingAddressclass .

Liskov Substitution Principle

• Essentially the principle states that, in object interactions, it should be possible to treat a derived object as if it were a base object without integrity problems

© 2010 Bennett, McRobb and Farmer 29

object without integrity problems • If the principle is not applied then it may be

possible to violate the integrity of the derived object

Liskov Substitution Principle

ChequeAccount

accountName balance

credit()

Account

accountName balance

Restructuring to

Disinheritance of debit()means that the left -hand

© 2010 Bennett, McRobb and Farmer 30

credit() debit()

MortgageAccount

interestRate

calculateInterest() - debit()

credit()

ChequeAccount

debit()

MortgageAccount

interestRate

calculateInterest()

to satis fy LSP left -hand

hierarchy is not Liskov compliant

Designing Associations

• An association that has to supportmessage passing in both directions is atwo-way association

• A two-way association is indicated with

© 2010 Bennett, McRobb and Farmer 31

• A two-way association is indicated witharrowheads at both ends

• Minimizing the number of two-wayassociations keeps the coupling betweenobjects as low as possible

Designing Associations

Owner

- name : String- address : Address owns

Car

- registrationNumber : Registration

Arrowhead shows the direction in which messages can be sent.

© 2010 Bennett, McRobb and Farmer 32

One-way one-to-one association

- address : Address- dateOfLicence : Date- numberOfConviction : Integer- ownedCar : Car

owns

1

- registrationNumber : Registration- make : String- model : String- colour : String1

carObjectId

is placed in the Owner class

Fragment of class diagram for the Agate case study

- staffNo

- staffName

- staffStartDate

- qualification

CreativeStaff

+ calculateBonus()

+ linkToNote()

*

1

1..*

manage campaign

work on campaign

owns*

1

- title

- campaignStartDate

- campaignFinishDate

- estimatedCost

- completionDate

Campaign*

Two - way

association

© 2010 Bennett, McRobb and Farmer 33

- completionDate

- datePaid

- actualCost

+ assignManager()

+ assignStaff()

+ checkBudget()

+ checkStaff()

+ completed()

+ getDuration()

+ getTeamMembers()

+ linkToNote()

+ listAdverts()

+ recordPayment()

- title

- type

- targetDate

- estimatedCost

- completionDate

Advert

+ getCost()

+ setCompleted()

+ view()

One - way

association

Collection Classes

• Collection classes are used to hold the object identifiers when message passing is required from one to many along an association

• OO languages provide support for these

© 2010 Bennett, McRobb and Farmer 34

• OO languages provide support for these requirements. Frequently the collection class may be implemented as part of the sending class (e.g. Campaign ) as some form of list

One-to-many association using a collection class.

has1

1

- title: String- campaignStartDate: Date- campaignFinishDate: Date- estimatedCost: Money- completionDate: Date- datePaid: D ate

- actualCost: Money- ownedAdvertCollection: AdvertCollection

Campaign

+ assignManager()+ assignStaff()+ checkBudget()

- ownedAdvert : Advert [*]

AdvertCollection

+ findFirst()+ getNext()+ addAdvert()+ removeAdvert()

1

© 2010 Bennett, McRobb and Farmer 35

*

+ checkBudget()+ checkStaff()+ completed()+ getDuration()

+ getTeamMembers()+ linkToNote()+ listAdverts()+ recordPayment() - title : String

- type : String- targetDate : Date- estimatedCost : Money- completionDate : Date

Advert

+ getCost()+ setCompleted()+ view()

owns

Sequence diagram for listAdverts()

This sequence diagram shows the interaction

:Campaign :AdvertCollection advert[i]:Advert

listAdverts

sd listAdverts()

findFirst

advert[1] = findFirst

opt [0<ownedAdvert.size()]

© 2010 Bennett, McRobb and Farmer 36

the interaction when using a collection class

getTitleadvert[1] = findFirst

advertTitle[1] = getTitle

loop (2,*)

getNext

getTitleadvert[i] = getNext

advertTitle[i] = getTitle

[i<=ownedAdvert.size()]

Two-way Many-to-many Associations

CreativeStaff

- staffCampaigns: CampaignCollection

+ listCampaigns()

* 1StaffCollection

- campaignStaff: Staff [*]

+ findFirst()

+ getNext()

+ addStaff()

+ removeStaff()

+ findStaff()

work on

has

1

© 2010 Bennett, McRobb and Farmer 37

This is the design for the works On Campaign association

work on

CampaignCollection

- staffCampaign: Campaign [*]

+ findFirst()

+ getNext()

+ addCampaign()

+ removeCampaign()

+ findCampaign()

+ findStaff()

Campaign

- staffCollection: StaffCollection

+ listStaff()

has1

1

1

1

*

Integrity Constraints

• Referential Integrity that ensures that an object identifier in an object is actually referring to an object that exists

• Dependency Constraints that ensures that

© 2010 Bennett, McRobb and Farmer 38

• Dependency Constraints that ensures that attribute dependencies, where one attribute may be calculated from other attributes, are maintained consistently

• Domain Integrity that ensures that attributes only hold permissible values

Constraints Between Associations

Is a member of*

© 2010 Bennett, McRobb and Farmer 39

Is a member of

Employee

chairs

{subset of}

0..1

*

*

Committee

memberCollection[*]committeeChair

assignChair()

Designing Operations

• Various factors constrain algorithm design:– the cost of implementation– performance constraints– requirements for accuracy

© 2010 Bennett, McRobb and Farmer 40

– requirements for accuracy– the capabilities of the implementation platform

Designing Operations

• Factors that should be considered when choosing among alternative algorithm designs– Computational complexity

© 2010 Bennett, McRobb and Farmer 41

– Computational complexity– Ease of implementation and understandability– Flexibility– Fine-tuning the object model

Summary

In this lecture you have learned about:• how to design attributes• how to design operations• how to design classes

© 2010 Bennett, McRobb and Farmer 42

• how to design classes • how to design associations• the impact of integrity constraints on

design.

References

• Coad & Yourdon (1991)• Yourdon (1994)• Howe (2001)• Meyer (1997)

© 2010 Bennett, McRobb and Farmer 43

• Meyer (1997)(For full bibliographic details, see Bennett, McRobb and Farmer)