1. Lecture 4 Class Responsibility Collaboration Cards
Object Oriented Analysis and Design
K268 SENG2100
Pat Browne 57
Lecture 2
Fact Finding

2. Lecture 2
Fact Finding

3. CRC
Object oriented systems are modeled using objects which initially reflect the abstractions identified in the problem domain.
CRC cards capture the object model in terms of classes, responsibilities and collaborations, and the class model in terms of subclass and superclass relationships.
CRCs are suited to dynamic team work with particular emphasis on role playing. The team member act out the actions of a particular class. CRCs encourage an antropomorphic view.
Fact Finding

4. Class Responsibility Collaboration cards
A CRC card is a physical index card that is annotated and used in a group setting to represent a class of objects the behaviour and interactions of both class and object.
There is a card for each class, on which we write the responsibilities and other classes collaborated with.
Role play during “brainstorming session”.
Model three dimensions of a problem.
Portable and anthropomorphic.
Fact Finding

5. Class Responsibility Collaboration cards
Side 1 Typical Card has:
Class name
Subclasses
Superclasses
Responsibilities Collaborators
Side 2 has brief textual description of class and its attributes.
Fact Finding

6. Class Responsibility Collaboration cards
As with real-world classification, a class groups together objects that the programmer considers to be similar.
The class gives the description of a set of objects with similar characteristics and attributes. One class description serves to describe all instances (members) of that class. The class describes the common protocol followed by the individual members (instances).
Fact Finding

7. Class Responsibility Collaboration cards
Objects of the same class respond to the same set of messages (the instance protocol), have the same attributes and respond in the same way to each message.
(in analysis) A class describes the behaviour of a set of objects of the same kind.
What are classes in design and programming?
Fact Finding

8. Class Responsibility Collaboration cards
Responsibilities
Responsibilities are the information or data that a class maintains and services that it provides. With a bank account these could include to ‘know balance’ or ‘perform credit’
Collaborators
A collaborator is is a class whose services are needed to fulfil a responsibility.
Fact Finding

9. Class Responsibility Collaboration cards
Collaborators are listed directly across from the responsibilities that they help fulfil.
Collaborators may be listed on more than one card if they help fulfil responsibilities for several classes (1:M).
Collaborations only exist to fulfil responsibilities.
Collaborations will only be listed when one object actually sends a message to its collaborators .
Collaborations are modelled as one way communications from initiator class to collaborator , the response is a message answer.
Fact Finding

10. Creating a classes
The Classes can be listed as a group before any cards are used. Alternatively, classes can be encountered and created as part of execution of scenarios. New classes may be discovered at any time during analysis.
One person should write the names of classes as they are suggested, not much discussion here. When list is complete remove redundancies.
Lecture 2
Fact Finding

11. Creating a classes Use textual analysis techniques.
How about user-interface design?
Filtering Classes: classes examined more closely e.g. Book class could be defined as the set of objects that represent books borrowed from a library.
Lecture 2
Fact Finding

12. Assigning Cards After filtering, classes are assigned to cards.
Each participant takes an index card which they annotate with the class name and check for agreement. Annotate side 2.
Lecture 2
Fact Finding

13. Assigning Subclass/Superclass
Only obvious subclass/superclass relations should be developed at this stage.
Lecture 2
Fact Finding

14. Responsibilities/Attributes
We can now assign behaviours.
Attributes can be identified by reading the negotiated statement of requirement. Nouns that are not classes but characteristics of classes are best represented as attributes (e.g. the Book class may have a ‘known due date’ attribute).
Lecture 2
Fact Finding

15. Scenarios
Next follows a set of walk-throughs of the relevant scenarios from the application area. Scenarios are detailed examples of functions of the system. They describe what happens in the system from a high level point of view. For example in a library: checking out an item, returning an item, searching for an item. A generic scenario is sometimes called a use case.
Lecture 2
Fact Finding

16. Scenarios
The simulation for the scenario should be dynamic and anthropomorphic. The cards on the table are static classes. When the cards are held they represent dynamic objects. While executing a scenario the team should be holding the relevant cards.
Raising and lowering cards provides visual clues about execution.
Note related scenarios.
Lecture 2
Fact Finding

17. CRC uses CRC used during: Can also be used to:
Analysis: Looking at problem domain.
Design: Refining responsibility.
Can also be used to:
Select core classes
Act out class relationships and scenarios
Refine project requirement.
Assist project management(giving a idea of the number and complexity of the required classes)
Serve as a guide to coding (to some degree)
Fact Finding

18. CRC uses Role play during “brainstorming session”.
Model three dimensions of a problem CRC.
 Analysis: Exploring at problem domain
Design: Refining responsibility.
Lecture 2
Fact Finding

19. CRC session
The Classes can be listed as a group before any cards are used. Alternatively, classes can be encountered and created as part of execution of scenarios. New classes may be discovered at any time during analysis. One person should write the names of classes as they are suggested, not much discussion here. When list is complete remove redundancies. Use textual analysis as described.
Lecture 2
Fact Finding

20. CRC session
Filtering Classes: classes examined more closely e.g. Book class could be defined as the set of objects that set that represent books borrowed from a library
After filtering classes are assigned to cards. Each participant takes an index card which they annotate with the class name and check for agreement. Annotate side 2.
Lecture 2
Fact Finding

21. CRC session
Only obvious subclass/superclass relations should be developed at this stage.
Assigning behaviours.
Attributes can be identified by reading the negotiated statement of requirement. Nouns that are not classes but characteristics of classes are best represented as attributes (the Book class may have a ‘known due date’ attribute).
Lecture 2
Fact Finding

22. CRC session
Next follows the walk-throughs (scenarios) of the application area. Scenarios are detailed examples of functions of the system. They describe what happens in the system from a high level point of view. For example in a library: checking out an item, returning an item, searching for an item.
Lecture 2
Fact Finding

23. CRC session
The simulation for the scenario should be dynamic and anthropomorphic. The cards on the table are static classes. When the cards are held they represent dynamic objects. While executing a scenario the team should be holding the relevant cards.
Physically raising and lowering cards provides visual clues about execution. This promotes an anthropomorphic view of classes and objects. Note related scenarios
Lecture 2
Fact Finding

24. A quick look at UML use cases
Use cases describe the behaviour of a system from a user's standpoint by using actions and reactions. They facilitate the definition of the system's boundary, and the relationships between the system and the environment. A use case diagram consists of an actor linked with one or more uses cases. A use case corresponds to a specific kind of system use. It is an image of a system's functionality, which is triggered in response to the stimulation of an external actor. Use cases have good support tools and standard UML notation Use case is well integrated into RUP.
Lecture 2
Fact Finding

25. CRC and use cases.
Use cases alone are not sufficient to build systems;
· developers may focus use cases losing sight of class structure and architecture.
·  mistaken design for requirement, user requirement may be improved by design.
·   missing a requirement, not all requirements can be found by identifying actors. and their associated use case.
Lecture 2
Fact Finding

26. CRC and use cases.
The examination of use cases on its own is not a good way to find objects and classes. A class model is also required, techniques such as CRC cards are still useful. For example, a customer may never directly interact with a sales system (say its done by a sales person), however a customer would certainly be a class in a sales system. Also other concepts such as architecture need to be developed.
Lecture 2
Fact Finding

27. CRC and use cases.
With the emphasis on interaction and anthropomorphism CRC are more appropriate for team collaboration. CRC can be used to develop both the class diagram (structural model) and the sequence diagram (dynamic model). Use case focus more on the requirements from the actors perspecitve.
Lecture 2
Fact Finding

28. Case study (Requirement)
A bank plans a new to build ATM system using OO methods. The ATM system will interface with the customers through a display screen, numeric and special input keys, a bank card reader, a deposit slot, and a receipt printer. Customers may make deposits, withdrawals, and balance enquiries using the ATM machine but the update of acounts will be handled by an interface to the Accounts system. Customers will be assigned a PIN and a clearance level by the Security system which can be verified prior to transactions. In the future we would also like to allow customers to update routine information such as change of address or phone number using the ATM.
Fact Finding

29. ATM candidate classes ATM Financial Tranasction CashDispencer
Screen Message
Display
Fact Finding

30. Lecture 2
Fact Finding

31. Lecture 2
Fact Finding

32. Lecture 2
Fact Finding

33. CRC Summary
Class A class describes the behaviour of a set of objects of the same kind. The class is essential when acting out scenarios.
Responsibilities are the knowledge that a class maintains and services that it provides. Again when acting out scenarios analyst must be able to develop or know the current responsibilities of a class.
Collaborators
A collaborator is is a class whose services are needed to fulfil a responsibility.
Fact Finding

34. CRC Summary Use of card during development
High level description of role at different stages:
1) Analysis: Exploring at problem domain
2) Design: Refining responsibility.
Fact Finding

35. CRC Summary Use of card during development
Details of usage: Teams can use the CRC technique to accomplish a variety of tasks, including:
Initially discovering classes
Selecting the core classes
Acting out class relationships and scenarios or role play during “brainstorming session”.
Refining the project requirements
Furthering project management, can be used to estimate the number of classes required.
Serving as a guide to the design of code.
Fact Finding

36. CRC on the web For further information see:
Fact Finding