Lecture 2 1

Lecture 4Class Responsibility Collaboration Cards

Object Oriented Analysis and Design

K268 SENG2100

Pat Browne

Patrick.Browne@comp.dit.ie

http://www.comp.dit.ie/pbrowne/

Lecture 2 2

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.

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.

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.

Class Responsibility Collaboration cards

• CLASS

• 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).

Class Responsibility Collaboration cards

• CLASS

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

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.

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.

Lecture 2 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 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 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 13

Assigning Subclass/Superclass• Only obvious subclass/superclass relations

should be developed at this stage.

Lecture 2 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 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 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.

CRC uses

• CRC used during:– 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)

Lecture 2 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 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 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 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 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 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 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 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 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 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.

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.

ATM candidate classes

• ATM• Financial

Tranasction

CashDispencer

Screen Message

Display

Lecture 2 30

Lecture 2 31

Lecture 2 32

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.

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.

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.

CRC on the web

• For further information see:http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/

crc_b/

http://c2.com/doc/oopsla89/paper.html

http://www.extremeprogramming.org/rules/crccards.html

http://alistair.cockburn.us/crystal/articles/ucrcc/usingcrccards.html