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


• 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


• 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 >]* ’}’]


[‘{‘ <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


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


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


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


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

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


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

• The parameter-list is optional.


• The parameter-list is optional.


• 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 >]* ‘}’]



• 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)



• 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; }



BankAccount

nextAccountNumber: IntegeraccountNumber: IntegeraccountName: String {not null}


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


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.


- 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


private attributes

derived attribute

class-scope attribute(a) (b)

class-scope operation

BankAccount


BankAccount


BankAccount


BankAccount


private attributes

derived attribute

class-scope attribute(a) (b)

class-scope operation


+ 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)



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.


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


– 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


- title- type- targetDate- estimatedCost- completionDate

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

Realize relationship

« interface»Manageable

+ getCost()+ setCompleted()

Viewable

‘Ball and socket’notation

- title- type- targetDate- estimatedCost- completionDate


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


– 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


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.


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


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.


AirVehicleLandVehicle

numberOfAxlesregistrationDate

register()

takeOffSpeed

maximumAltitude

checkAltitude()

takeOff()

Operation Cohesion

Lecturer

lecturerName lecturerAddress


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


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


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


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


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


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


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


- 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


• 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


*

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

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

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

Advert


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()]


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


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


• 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*


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


– requirements for accuracy– the capabilities of the implementation platform

Designing Operations

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


– 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


• 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)


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

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

Documents

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