CRC modelling

A card, not a diagram

Class-responsibility-collaborator (CRC) modelling is a simple means of identifying and organising the classes relevant to a system's requirements. The model is a collection of index cards — one per class. The class name goes at the top; the left side lists the class's responsibilities; the right side lists, alongside each responsibility that needs one, the collaborators that make it possible. That is the entire notation, and the low technology is deliberate: cards can be dealt out to a group of people, held, passed, re-written and re-dealt in a way that no diagram on a screen can be.

Responsibilities are attributes and operations

A responsibility is anything the class is answerable for — the attributes it must know and the operations it must perform. Hold one tool copy for two hours is a responsibility. So is know when the hold expires. Responsibilities are written in plain language, at the level of intent rather than signature, and the list is explicitly preliminary: it is expected to change as the model is reviewed.

Collaborators, and the two ways a responsibility is met

A class fulfils a responsibility in one of exactly two ways. Either it uses its own operations to manipulate its own attributes — in which case it needs no collaborator — or it must ask another class for information or action, and that class is a collaborator. The test is mechanical and it is the whole technique: can this class discharge this responsibility alone? If not, name who it needs, and write that name beside the responsibility. A collaborator is always a class, never an attribute and never an operation; putting an operation in the collaborator column is the single most common notational mistake.

The collaborator column is a coupling detector. A card whose right side lists five different classes is telling you either that the responsibilities have been piled onto the wrong card, or that the class is a controller doing too much.

The review is the point

A CRC model earns its keep in a review, not on a desk. Deal the cards out so that no reviewer holds two cards that collaborate. A review leader reads a use case aloud, deliberately; when they reach a named object, they pass a token to the person holding that class's card, who must then describe the responsibilities written on it. The group decides whether those responsibilities actually satisfy the requirement the sentence just stated. Where they do not, cards are edited on the spot: responsibilities move, collaborations appear or vanish, and occasionally a new class is written. You can also walk the model — start at one card, jump to a collaborator, then to its collaborator — which finds omissions quickly.

Entity, boundary, controller

Analysis classes are commonly taxonomised three ways, and the labels help when you are deciding where a responsibility belongs. Entity classes hold problem-domain information the system must remember (ToolCopy, Member). Boundary classes handle interaction across the system's edge, with an actor or an external system (LockerGateway, the reservation screen). Controller classes manage the flow of one use case, coordinating others without owning much themselves (CollectionService). A controller whose card lists ten responsibilities and eight collaborators has stopped coordinating and started doing.

Worked example — the Reservation card, and the fee that does not belong

The figure shows the Reservation card. Four of its five responsibilities are clean: holding a copy needs ToolCopy; checking the member may borrow needs Member; expiring after two hours needs nobody, because the expiry time is Reservation's own attribute; converting to a loan when the door opens needs Locker.

Then someone proposes a fifth: charge the late fee. Write it on the card and the collaborator column grows a Payments entry, and the card now touches four other classes. That growth is evidence, and it is the sort of evidence CRC exists to produce — the fee is not the reservation's business. It belongs on a loan, or on a billing class that the reservation never meets. Notice that you found a coupling problem in a review, with index cards, before a single line of code existed. That is the argument for the technique, and it is the argument you should make in an exam answer, because it is also the difference between CRC and a class diagram: the diagram records the structure you agreed on, the cards are how you argued about it.