1. 1 of 53 THE OBJECT-ORIENTED DESIGN WORKFLOW

2. 2 of 53 Overview The Design Workflow Traditional versus Object-Oriented Design Formats of the Attributes Allocation of Operations to Classes Allocation of Operations: Osbert Oglesby Case Study CRC Cards

3. 3 of 53 The Design Workflow The input to the design workflow is the set of analysis workflow artifacts –These artifacts are iterated and incremented until they can be used by the programmers A major aspect of this iteration and incrementation is –The identification of operations, and –Their allocation to the appropriate classes

4. 4 of 53 The Design Workflow (contd) Many other decisions have to be made as part of the design workflow, including –Choice of programming language –Deciding how much of existing information systems to reuse in the new information system –Level of portability –The allocation of each software component to its hardware component The Unified Process was designed for developing large-scale information systems with 500,000 lines of code or more

5. 5 of 53 The Design Workflow (contd) During the analysis workflow, a large information system is partitioned into analysis packages –Each analysis package consists of a set of related classes that can be implemented as a single unit –Example: Accounts payable, accounts receivable, and general ledger are typical analysis packages The concept underlying analysis packages is: –It is easier to develop smaller information systems than larger information systems –A large information system will be easier to develop if it can be decomposed into independent packages

6. 6 of 53 The Design Workflow (contd) The idea of decomposing a large workflow into independent smaller workflows is carried forward to the design workflow The objective is to break up the upcoming implementation workflow into manageable pieces –Subsystems It does not make sense to break up the two case studies into subsystems—they are just too small

7. 7 of 53 The Design Workflow (contd) The architecture of an information system includes –The various component modules –How they fit together –The allocation of components to subsystems The task of designing the architecture is specialized –It is performed by an information system architect

8. 8 of 53 The Design Workflow (contd) The architect needs to make trade-offs –Every information system must satisfy its functional requirements (the use cases) –It also must satisfy its nonfunctional requirements, including Portability, reliability, robustness, maintainability, and security –It must do all these things within budget and within the time constraint The architect must assist the client by laying out the trade-offs

9. 9 of 53 The Design Workflow (contd) It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints –Some sort of compromises have to be made The client has to –Relax some of the requirements; –Increase the budget; and/or –Move the delivery deadline

10. 10 of 53 The Design Workflow (contd) The architecture of an information system is critical –The requirements workflow can be fixed during the analysis workflow –The analysis workflow can be fixed during the design workflow –The design workflow can be fixed during the implementation workflow But there is no way to recover from suboptimal architecture –The architecture must immediately be redesigned

11. 11 of 53 Traditional versus Object-Oriented Design In the traditional paradigm, the design phase consists of –Architectural design The information system is decomposed into modules –Detailed design Algorithms and data structures are designed for each module

12. 12 of 53 Traditional versus Object-Oriented Design (contd) Classes are modules –Much of traditional architectural design is performed as part of class extraction in the object-oriented analysis workflow

13. 13 of 53 The Design Workflow (contd) Much of object-oriented design requires knowledge of programming In this discussion a description is therefore given of just one design artifact, the complete class diagram

14. 14 of 53 Formats of the Attributes As part of the design workflow, the exact format of each attribute of the class diagram must be specified –Example: A date is usually represented by 10 characters –For instance, December 3, 1947 is represented as 12/03/1947 in the United States (MM/DD/YYYY format), and 03/12/1947 in Europe (DD/MM/YYYY format)

15. 15 of 53 Formats of the Attributes (contd) The formats could be determined during the analysis workflow However, the object-oriented paradigm is iterative –Information is added to models as late as possible Adding an item too early will make the next iteration unnecessarily burdensome –Formats are therefore added during the design workflow

16. 16 of 53 Formats of Attributes of Osbert Oglesby Class diagram with the formats of attributes added

17. 17 of 53 Formats of Attributes of Osbert Oglesby (contd) Examples: –First name of an artist is up to 20 characters in length, optionally followed by ? if there is uncertainty firstNameOfArtist : 21 chars –Title is up to 40 characters in length, optionally with ? title : 41 chars –Height and width are measured in centimeters height, width : 4 digits (up to 9999 centimeters, or 99.99 meters) –Prices targetSellingPrice, actualSellingPrice, maxPurchasePrice : 8 digits (up to $99,999,999) –Dates dateOfPurchase, dateOfSale, auctionDate : 10 chars

18. 18 of 53 Formats of Attributes of Osbert Oglesby (contd) Fashionability coefficient could be a large number or a small number The range can be determined only by computing coefficients from a sample of Osbert’s sales –High: 985 (Rembrandt van Rijn) –Low: 0.064 (Joey T. Dog) For safety, coefficient is of type 4 + 4 digits Range is –High: 9999.9999 –Low: 0.0001

19. 19 of 53 Formats of Attributes of MSG Case Study Class diagram with the formats of attributes added

20. 20 of 53 Formats of Attributes of MSG Case Study (contd) Example: –An asset number consists of 12 characters assetNumber : 12 digits –Annual operating expenses are up to $999,999,999.99 estimatedAnnualOperatingExpenses : 9 + 2 digits

21. 21 of 53 Allocation of Operations to Classes Third iteration of the initial MSG class diagram

22. 22 of 53 Allocation of Operations to Classes (contd) There are empty rectangles at the bottoms of the boxes to list the operations of the classes It is unwise to add an item to a UML diagram before it is strictly necessary to do so –The Unified Process is iterative The operations are deduced from the interaction diagrams of the realizations of the use cases –These are produced after the class diagram

23. 23 of 53 Allocation of Operations to Classes (contd) First the initial class diagram is determined –Then the interaction diagrams of the realizations of the use cases These interaction diagrams are used to deduce the operations –Only then can the operations be allocated to the classes

24. 24 of 53 Allocation of Operations to Classes (contd) Identifying the operations to be allocated to the various classes is easy Determining to which class each operation should be allocated is hard Three criteria are used –Responsibility-driven design –Inheritance –Polymorphism and dynamic binding

25. 25 of 53 Responsibility-Driven Design The principle of responsibility-driven design –If Class A sends a message to Class B telling it to do something, it is the responsibility of Class B to perform the requested operation

26. 26 of 53 Responsibility-Driven Design Example: –MSG Foundation case study

27. 27 of 53 Responsibility-Driven Design (contd) The weekly return on investments is computed by summing the estimated annual return of each investment and dividing by 52 –The sequence diagram includes the message 3: Request estimated return on investments for week The MSG Foundation case study must therefore include the operation getAnnualReturnOnInvestment –Thus, for each object of class Investment Class, the estimated annual return on that investment can be determined

28. 28 of 53 Responsibility-Driven Design (contd) It is not important which class sends that message What is important is that Investment Class has the responsibility of determining the annual return on an investment –Accordingly, operation getAnnualReturnOnInvestment must be allocated to Investment Class

29. 29 of 53 Responsibility-Driven Design (contd) l Allocation of getAnnualReturnOnInvestment

30. 30 of 53 Inheritance Suppose an operation is applicable to –An instance of a superclass; and to –Instances of subclasses of that superclass Allocate that operation to the superclass Then there is just one version of that operation It can be used by –Instances of the superclass and by –Instances of all its subclasses

31. 31 of 53 Inheritance (contd) Associated with each attribute of a class are operations setAttribute, assigns a value to that attribute; getAttribute, returns the current value of that attribute Example: In the MSG case study every asset has an asset number –Asset Class has an attribute assetNumber setAssetNumber is used to assign the number of the asset to the object that represents that asset getAssetNumber is used to obtain the asset number of the asset represented by that object

32. 32 of 53 Inheritance (contd) To which class should operation setAssetNumber be allocated? In the traditional paradigm, there would be two different versions of setAssetNumber, one for each of the two types of asset –That is, there would have to be setInvestmentNumber and setMortgageNumber Two separate functions are needed because the traditional paradigm does not support inheritance

33. 33 of 53 Inheritance (contd) l In the object-oriented paradigm –Consider the MSG inheritance hierarchy

34. 34 of 53 Inheritance (contd) Asset Class has attribute assetNumber –Inherited by Investment Class and Mortgage Class –Every instance of class Investment Class, and every instance of class Mortgage Class has 12 character attribute assetNumber Any operation of class Asset Class that could be applied to attribute assetNumber c an also be applied to attribute assetNumber of Every instance of class Investment Class, and Every instance of class Mortgage Class

35. 35 of 53 Inheritance (contd) l Allocation of setAssetNumber, getAssetNumber

36. 36 of 53 Inheritance (contd) Operation setAssetNumber can then be applied to instances of –Class Investment Class or –Class Mortgage Class

37. 37 of 53 Allocation of Operations: Osbert Oglesby Fifth iteration of the initial class diagram

38. 38 of 53 Responsibility-Driven Design: Osbert Oglesby Consider operation getAuctionPrice Irrespective of the source of the message requesting an auction price –Operation getAuctionPrice must be allocated to Auctioned Painting Class

39. 39 of 53 Responsibility-Driven Design: Osbert Oglesby l Allocation of getAuctionPrice

40. 40 of 53 Inheritance: Osbert Oglesby Case Study Consider operations –setTitle and –getTitle

41. 41 of 53 Inheritance: Osbert Oglesby Case Study (contd) Example: Osbert prints a list of all his paintings –Each object in the information system in turn is examined –A message is sent to operation getTitle to obtain the title of the painting represented by that object To which class must operations setTitle and getTitle be allocated?

42. 42 of 53 Inheritance: Osbert Oglesby Case Study (contd) First consider operation setTitle In the traditional paradigm, there would have to be three different versions of setTitle, one for each type of painting –set_masterpiece_title –set_masterwork_title –set_other_painting_title That is because the traditional paradigm does not support inheritance

43. 43 of 53 Inheritance: Osbert Oglesby Case Study (contd) In the object-oriented paradigm, consider the Painting Class inheritance hierarchy Painting Class has attribute title –This attribute is inherited by instances of its 5 subclasses Gallery Painting Class Auctioned Painting Class Masterpiece Class Masterwork Class Other Painting Class

44. 44 of 53 Inheritance: Osbert Oglesby Case Study (contd) Thus, operation setTitle must be allocated to Painting Class so that it can be inherited (and used) by instances of all five subclasses This applies to all operations, including getTitle

45. 45 of 53 Inheritance: Osbert Oglesby Case Study (contd) Allocation of operations setTitle and getTitle

46. 46 of 53 CRC Cards Class-responsibility-collaboration (CRC) cards can be utilized for object-oriented analysis and design For each class, fill in a card showing –The name of the class; –The functionality of that class (its responsibility); and –The other classes it invokes to achieve that functionality (its collaboration)

47. 47 of 53 CRC Cards (contd) CRC cards were originally introduced for performing requirements elicitation and analysis They are excellent for this purpose –Provided the team members are familiar with the domain For professionals who have no domain expertise –CRC cards are an extremely effective way of testing object-oriented analysis and design artifacts

48. 48 of 53 CRC Cards (contd) Example:

49. 49 of 53 CRC Cards (contd) The data for the CRC card are obtained from the realizations of all the use cases

50. 50 of 53 CRC Cards (contd) Consider the MSG collaboration diagram

51. 51 of 53 CRC Cards (contd) The message –7: Request estimated grants and payments for week is passed from : Estimate Funds for Week Class to : Mortgage Class, followed by the message –8: Return estimated grants and payments for week in the reverse direction

52. 52 of 53 CRC Cards (contd) Mortgage Class therefore has a responsibility to –Compute estimated grants and payments for week In order to do this, it must collaborate with Estimate Funds for Week Class –This is shown in the first entry in the CRC card

53. 53 of 53 CRC Cards (contd) When used by a team, CRC cards can highlight missing or incorrect attributes or operations Having the members of the team act out the responsibilities of each CRC card is an effective means of verifying that the classes are correct Example: –One team member acting out the responsibilities of a class may cause another member to realize that a needed responsibility has been omitted