detailed design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfattribute and operation...
TRANSCRIPT
![Page 1: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/1.jpg)
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
![Page 2: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/2.jpg)
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.
![Page 3: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/3.jpg)
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.
![Page 4: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/4.jpg)
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
![Page 5: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/5.jpg)
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)
![Page 6: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/6.jpg)
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
![Page 7: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/7.jpg)
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
![Page 8: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/8.jpg)
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
![Page 9: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/9.jpg)
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 >]* ‘}’]]
![Page 10: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/10.jpg)
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.
![Page 11: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/11.jpg)
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
![Page 12: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/12.jpg)
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
![Page 13: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/13.jpg)
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
![Page 14: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/14.jpg)
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)
![Page 15: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/15.jpg)
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
![Page 16: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/16.jpg)
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.
![Page 17: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/17.jpg)
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
![Page 18: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/18.jpg)
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
![Page 19: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/19.jpg)
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
![Page 20: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/20.jpg)
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
![Page 21: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/21.jpg)
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
![Page 22: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/22.jpg)
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
![Page 23: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/23.jpg)
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.
![Page 24: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/24.jpg)
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.
![Page 25: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/25.jpg)
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()
![Page 26: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/26.jpg)
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
![Page 27: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/27.jpg)
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
![Page 28: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/28.jpg)
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 .
![Page 29: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/29.jpg)
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
![Page 30: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/30.jpg)
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
![Page 31: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/31.jpg)
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
![Page 32: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/32.jpg)
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
![Page 33: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/33.jpg)
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
![Page 34: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/34.jpg)
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
![Page 35: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/35.jpg)
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
![Page 36: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/36.jpg)
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()]
![Page 37: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/37.jpg)
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
*
![Page 38: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/38.jpg)
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
![Page 39: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/39.jpg)
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()
![Page 40: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/40.jpg)
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
![Page 41: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/41.jpg)
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
![Page 42: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/42.jpg)
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.
![Page 43: Detailed Design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfAttribute and Operation Specification • Deciding the data type of each attribute. • Deciding how to](https://reader030.vdocuments.mx/reader030/viewer/2022041219/5e0842eeed20e96c692b629e/html5/thumbnails/43.jpg)
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)