The document discusses the CRC (Class-Responsibility-Collaboration) card workshop technique for modeling the dynamic behavior of a software architecture. It involves: 1) Creating CRC cards for each candidate subsystem/module, listing its name, type, responsibilities, and collaborations. 2) Identifying new responsibilities and collaborations by role-playing scenarios using the CRC cards. 3) Capturing the results in static component diagrams and dynamic sequence diagrams to document the software architecture.

1. Software Architecture
CRC Card workshop
Vakgroep Informatietechnologie – IBCN

2. CRC Workshops
 The CRC card workshop is a brainstorm
technique using scenario walkthroughs to model
the dynamic behavior of a software architecture.
 For each candidate subsystem, module or
submodule in the architecture, a CRC-card is
made, featuring :
 Class name
 Class type : subsystem, module or sub module
 Responsibilities : which functionality does the class perform ? (list
attributes and methods)
 Collaborations : which other classes are needed to realize this
functionality ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

3. Module Identification and Function Allocation
CRC-cards
= Class - Responsibility - Collaboration card
= Container for responsibilities
Class name :
Class type : <system> <subsystem> <module> …
Class characteristic :
Responsibilities : Collaborations :
Describe the functionality List other modules needed
of the module to achieve this functionality
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3

4. CRC identification
CRC cards:
 Show collaborations between the child modules
 Find new responsibilities based on role play
 Driven by scenarios and sequence diagrams.
 Identify new child modules
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4

5. CRC Role play
 Once CRC-cards have been drawn up for each candidate,
collaborations can be shown in a (sequence) diagram
 Often, CRC-cards are put on a whiteboard, and are
grouped according to the level of collaboration.
 A technique to check whether all classes, responsibilities
and collaborations are identified, consists of assigning
each member of the group a set of CRC-cards, and to
“play” the scenarios.
 Each time an operation is needed, the team member holding the
CRC-card of the class involved, checks whether the functionality is
listed, which other classes are needed (and which functionality of
these collaborating classes is required).
 If functionality, attributes or an entire class is missing, the CRC-
model is updated, and the role play starts all over again .
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5

6. Example
Class name : Device Context Manager <module>
Responsibilities : Collaborations :
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

7. Example
Class name : Transcoder <module>
Responsibilities : Collaborations :
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7

8. Software Architecture Document
 At the end of the session the results of the
workshops have to be captured in static &
dynamic views.
 Static views : component diagrams
 Dynamic views : white box sequence diagrams
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8