1. CRC CARDS 1 Sys464 Object-oriented analysis and design

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

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

4. Scenarios 4 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 5 CRC Cards describe each class in terms of its  responsibilities  collaborators

6. CRC Cards 6 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 7 Find specific, concrete objects from the application domain  tangible and visible things

8. Notes on CRC Description 8 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 9 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 10 “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 11 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 12 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 13 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 14 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 15 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 16 Think about the real objects which exist in the domain

17. Summary of CRC Process 17 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! 18