CHAPTER 8 — Unit B

1. An Introduction toObject-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 8 — Unit B THE OBJECT-ORIENTED DESIGN WORKFLOW

3. Continued from Unit 8A

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

5. Responsibility-Driven Design: Osbert Oglesby • Allocation of getAuctionPrice

6. Inheritance: Osbert Oglesby Case Study • Consider operations • setTitle and • getTitle

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

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

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

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

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

12. CRC Cards • Since 1990, class-responsibility-collaboration (CRC) cards have been 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)

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

14. CRC Cards (contd) • Example:

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

16. CRC Cards (contd) • Consider the MSG collaboration diagram

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

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

19. CRC Cards (contd) • Consider the MSG collaboration diagram

20. CRC Cards (contd) • The message • 3: Update tax and date is passed from: Manage an Asset Class to : Mortgage Class • Then, the message • 4: Send successful completion message is passed back

21. CRC Cards (contd) • Third iteration of the MSG initial class diagram

22. CRC Cards (contd) • Mortgage Class has eight attributes (including annual real-estate tax), that might need to be changed by : Manage an Asset Class • All the attributes are initialized by : Manage an Asset Class • A complete set of scenarios includes all 16 set and get operations

23. CRC Cards (contd) • Each of the 16 scenarios in turn requires an interaction diagram of its realization • In addition, managing a mortgage includes adding a new mortgage and deleting an existing mortgage • For brevity, combine all these responsibilities into responsibility • Initialize, update, and delete mortgages with collaborator • Manage an Asset Class • This is the second entry in the CRC card

24. CRC Cards (contd) • Consider the MSG collaboration diagram

25. CRC Cards (contd) • The message • 3: Update income and date is passed from: Manage an Asset Class to : Mortgage Class • The message • 4: Send successful completion message is then passed back

26. CRC Cards (contd) • Attribute combinedWeeklyIncome is one of the eight attributes of Mortgage Class that might need to be changed by : Manage an Asset Class • This responsibility is already included in responsibility Initialize, update, and delete mortgages

27. CRC Cards (contd) • Consider the MSG collaboration diagram

28. CRC Cards (contd) • The message • 2: Transfer request [for list of mortgages] is passed from: User Interface Class to : Mortgage Class • Thus, Mortgage Class has the responsibility • Generate list of mortgages with collaborator User Interface Class • This is the third entry in the CRC card

29. CRC Cards (contd) • Also, the message • 3: Print list of mortgages is passed from : Mortgage Class to : Mortgages Report Class • Mortgage Class thus also has the responsibility • Print list of mortgages with collaborator Mortgages Report Class • This is the fourth entry in the CRC card

30. CRC Cards (contd) • As a check, consider the fourth iteration of the MSG class diagram

31. CRC Cards (contd) • In the class diagram there five classes with which Mortgage Class has a relationship • User Interface Class • Estimate Funds for Week Class • Mortgages Report Class • Asset Class • Manage an Asset Class • From the realizations it is clear that Mortgage Class no responsibility with Asset Class

32. CRC Cards (contd) • All four of the remaining classes are listed in the COLLABORATION column of the CRC card • This does not necessarily mean that every responsibility of every collaboration class has been included • However, it is likely that all the collaboration classes have been included

33. CRC Cards (contd) • CRC cards have been extended • A CRC card nowadays often contains the attributes and operations of a class, not its “responsibility” • The CRC card then contains the information of the complete class diagram

34. CRC Cards (contd) • The technology has changed • Instead of using cards, some organizations move Post-it notes around on a white board and draw lines between them to denote collaboration • Nowadays the whole process can be automated • Some CASE tools include modules for creating and updating CRC “cards” on the screen

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