detailed design - homes.ieu.edu.trhomes.ieu.edu.tr/ysahin/lectures/04_14.pdfattribute and operation...
TRANSCRIPT
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)