Sys464 Object-oriented analysis and design

1. Sys464Object-oriented analysis and design CRC Cards

2. CRC Cards • CRC Cards were developed by Rebecca Wirfs-Brock to help her students identify classes

3. Goal of Scenarios • Describe the requirements of the system • Develop an execution scenario that captures important behaviour in theapplication domain • to determine the objects involved in the execution scenario

4. Scenarios • Many Use cases and their associated Scenarios are required to cover the complete behaviour of the objects • we instruct the objects how to react to each new situation

5. CRC Cards • CRC Cards describe each class in terms of its • responsibilities • collaborators

6. CRC Cards • 4 x 6 Index Cards • severely restricts the amount of information • easy to manipulate, shuffle around • allows you to “touch” the object

7. Notes on CRC Description • Find specific, concrete objects from the application domain • tangible and visible things

8. Notes on CRC Description • Choose names corresponding to nouns or noun-phrases in the Scenarios • Use terms a domain expert would use, not a programmer

9. Notes on CRC Description • Use singular names, not plural • Don’t worry about different varieties of similar objects (at this stage) • they often appear as adjective-noun phrases like check in screen, main library screen

10. Notes on Class Responsibilities • “A responsibility is anything that a class knows or does.” • “Important: A class is able to change the values of the things it knows, but it is unable to change the values of what other classes know.” • Source:Scott W. Ambler, Agile Modeling

11. Notes on Class Responsibilities • Responsibilities should be action verbs • Important to flesh out, “Keep track of…” type of responsibility • Responsibilities often come in pairs; you should note them in this style

12. Notes on CRC Descriptions • More than one class may seem to have the same responsibility • This is fine since one object may simply forward the responsibility to the other • e.g. both the car and an engine may have “starts itself when requested” responsibility. The car simply forwards its request to the engine; the engine does the real work

13. Notes on CRC Descriptions • Collaborators should be associated with individual responsibilities • Don’t try to capture ‘flow of control” with CRC’s • We will use sequence diagrams to capture that information

14. Notes on CRC Descriptions • Some objects will necessarily be busier than others • You may find improvements to the real-world model • but it is always the best place to begin

15. Notes on CRC Descriptions • Expect CRC descriptions to change over time • they should always describe your current system • Model only the “front end”; I.e. We don’t need to worry about the host-side of the computation

16. Notes on CRC Descriptions • Think about the real objects which exist in the domain

17. Summary of CRC Process • Purpose is to identify important types of objects (classes). • Responsibilities act as a “contract” between the objects • Collaborators illustrate explicit dependencies to fulfill responsibilities

18. Summary of CRC Process • CRC’s represent a contract between team members as well as objects. • Everyone must be on board!