1. © Bennett, McRobb and Farmer 2005 1 System Design Based on Chapter 14 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (2 nd Edition), McGraw Hill, 2005.

2. © Bennett, McRobb and Farmer 2005 2 In This Lecture You Will Learn:  how to design classes  how to design associations  the impact of integrity constraints on design  how to design operations

3. © Bennett, McRobb and Farmer 2005 3 Detailed Design n Traditional detailed design consists of four main activities –designing inputs –designing outputs –designing processes –designing files and database structures

4. © Bennett, McRobb and Farmer 2005 4 Detailed Design n Traditional detailed design tried to maximise cohesion –elements of module of code all contribute to the achievement of a single function n Traditional detailed design tried to minimise coupling –unnecessary linkages between modules that made them difficult to maintain or use in isolation from other modules

5. © Bennett, McRobb and Farmer 2005 5 Detailed Design n Object-oriented detailed design adds detail to the analysis model –types of attributes –operation signatures –assigning responsibilities as operations –additional classes to handle user interface –additional classes to handle data management –design of reusable components –assigning classes to packages

6. © Bennett, McRobb and Farmer 2005 6 Class Specification : Attributes n An attribute’s data type is declared in UML using the following syntax name ‘:’ type-expression ‘=’ initial-value ‘{’property-string‘} ’ Where –name is the attribute name –type-expression is its data type –initial-value 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

7. © Bennett, McRobb and Farmer 2005 7 Class Specification: Attributes BankAccount class with the attribute data types included Shows a derived attribute BankAccount nextAccountNumber: Integer accountNumber: Integer accountName: String {not null} balance: Money = 0 /availableBalance: Money overdraftLimit: Money 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)

8. © Bennett, McRobb and Farmer 2005 8 Class Specification: Attributes n The attribute balance in a BankAccount class might be declared with an initial value of zero using the syntax balance:Money = 0.00 n Attributes that may not be null are specified accountName:String {not null} n Arrays are specified qualification[0..10]:String

9. © Bennett, McRobb and Farmer 2005 9 Class Specification: Operations n The syntax used for an operation is operation name ‘(’parameter-list ‘)’‘:’ return-type- expression n 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

10. © Bennett, McRobb and Farmer 2005 10 Class Specification: Operations BankAccount class with operation signatures included. BankAccount nextAccountNumber: Integer accountNumber: Integer accountName: String {not null} balance: Money = 0 /availableBalance: Money overdraftLimit: Money 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)

11. © Bennett, McRobb and Farmer 2005 11 Which Operations? n Generally don’t show primary operations n Only show constructors where they have special significance n Varying levels of detail at different stages in the development cycle

12. © Bennett, McRobb and Farmer 2005 12 Visibility Visibility symbol VisibilityMeaning + PublicThe feature (an operation or an attribute) is directly accessible by an instance of any class. - PrivateThe feature may only be used by an instance the class that includes it. # ProtectedThe feature may be used either by the class that includes it or by a subclass or descendant of that class. ~ PackageThe feature is directly accessible only by instances of a class in the same package.

13. © Bennett, McRobb and Farmer 2005 13 Visibility BankAccount class with visibility specified BankAccount - nextAccountNumber: Integer - accountNumber: Integer - accountName: String {not null} - balance: Money = 0 - /availableBalance: Money - overdraftLimit: Money + 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)

14. © Bennett, McRobb and Farmer 2005 14 Interfaces n 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 n 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

15. © Bennett, McRobb and Farmer 2005 15 Interfaces for the Advert class

16. © Bennett, McRobb and Farmer 2005 16 Designing Associations n An association that has to support message passing in both directions is a two-way association n A two-way association is indicated with arrowheads at both ends n Minimizing the number of two-way associations keeps the coupling between objects as low as possible

17. © Bennett, McRobb and Farmer 2005 17 Designing Associations One-way one-to-one association Owner - name : String - address : Address - dateOfLicence : Date - numberOfConviction : Integer - ownedCar : Car owns 1 Car - registrationNumber : Registration - make : String - model : String - colour : String 1 carObjectId is placed in the Owner class Arrowhead shows the direction in which messages can be sent.

18. © Bennett, McRobb and Farmer 2005 18 Fragment of class diagram for the Agate case study

19. © Bennett, McRobb and Farmer 2005 19 One-to-many association using a collection class. has 1 * 1 - title: String - campaignStartDate: Date - campaignFinishDate: Date - estimatedCost: Money - completionDate: Date - datePaid: Date - actualCost: Money - ownedAdvertCollection: AdvertCollection Campaign + assignManager() + assignStaff() + checkBudget() + checkStaff() + completed() + getDuration() + getTeamMembers() + linkToNote() + listAdverts() + recordPayment() - title: String - type: String - targetDate: Date - estimatedCost: Money - completionDate: Date Advert + getCost() + setCompleted() + view() owns - ownedAdvert: Advert [*] AdvertCollection + findFirst() + getNext() + addAdvert() + removeAdvert() 1

20. © Bennett, McRobb and Farmer 2005 20 Collection Classes n 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 requirements. Frequently the collection class may be implemented as part of the sending class (e.g. Campaign ) as some form of list

21. © Bennett, McRobb and Farmer 2005 21 Sequence diagram for listAdverts() This sequence diagram shows the interaction when using a collection class :Campaign :AdvertCollection advert[i] :Advert listAdverts sd listAdverts() findFirst getTitle advert[1] = findFirst advertTitle[1] = getTitle loop (2,*) getNext getTitle advert[i] = getNext advertTitle[i] = getTitle opt [i<=ownedAdvert.size()] [0<ownedAdvert.size()]

22. © Bennett, McRobb and Farmer 2005 22 Two-way Many-to-many Associations This is the design for the works On Campaign association CreativeStaff - staffCampaigns: CampaignCollection + listCampaigns() work on * 1 CampaignCollection - staffCampaign: Campaign [*] + findFirst() + getNext() + addCampaign() + removeCampaign() + findCampaign() StaffCollection - campaignStaff: Staff [*] + findFirst() + getNext() + addStaff() + removeStaff() + findStaff() Campaign - staffCollection: StaffCollection + listStaff() work on has 1 1 1 1 1 *

23. © Bennett, McRobb and Farmer 2005 23 Integrity Constraints n Referential Integrity that ensures that an object identifier in an object is actually referring to an object that exists n Dependency Constraints that ensures that attribute dependencies, where one attribute may be calculated from other attributes, are maintained consistently n Domain Integrity that ensures that attributes only hold permissible values

24. © Bennett, McRobb and Farmer 2005 24 Constraints Between Associations Is a member of Employee chairs {subset of} 0..1 * * * Committee memberCollection[*] committeeChair assignChair()

25. © Bennett, McRobb and Farmer 2005 25 Designing Operations n Various factors constrain algorithm design: –the cost of implementation –performance constraints –requirements for accuracy –the capabilities of the implementation platform

26. © Bennett, McRobb and Farmer 2005 26 Designing Operations n Factors that should be considered when choosing among alternative algorithm designs –Computational complexity –Ease of implementation and understandability –Flexibility –Fine-tuning the object model

27. © Bennett, McRobb and Farmer 2005 27 Summary In this lecture you have learned about:  how to apply criteria for good design  how to design associations  the impact of integrity constraints on design  how to design operations  the role of normalization in object design

28. © Bennett, McRobb and Farmer 2005 28 References n Rumbaugh et al (1991) n Coad & Yourdon (1991) n Yourdon (1994). n Howe (2001) (For full bibliographic details, see Bennett, McRobb and Farmer)