Use Component Responsibility Cards (CRC cards) to propose architectural elements, describe their responsibilities, and show how they come together to form a view of the architecture. This exercise is an extension of the Class Responsibility Collaborator cards described by Kent Beck and Ward Cunningham in A Laboratory for Teaching Object-Oriented Thinking [BC89] and Scott Ambler in The Object Primer: Agile Model-Driven Development with UML 2.0 [Amb04]. This technique also works well for modeling domain concepts.

Benefits

• Quickly iterate through design alternatives.

• Create group buy-in and shared understanding of the architecture.

• Create a connection between architecturally significant requirements and design alternatives.

• Identify potential gaps in the architecture.

Activity Timing

30--90 minutes

Participants

The development team works in small groups of 3--5 people. This is also a good exercise for solo work.

Preparation and Materials

• Index cards and markers for writing components and responsibilities. Host the activity at a large table where all participants can see the cards.

• Before starting this activity, you should know some of your system’s functional requirements (use cases, stories, or similar) and quality attribute scenarios.

Steps

1. Introduce the goals for the exercise and share an example CRC card.

2. Read aloud a functional requirement or quality attribute scenario.

3. Create a card to represent the user or source for a quality attribute scenario. Write the user or source’s name at the top of the card. Underneath write the trigger that initiates the use case or scenario.

4. Add a new card to the table to represent the architectural element with which the trigger card first interacts. Write the name of the element at the top of the card.

5. Evolve the architecture by adding cards for known elements or creating new elements as needed. Write the responsibilities of each element directly on the cards. Record relationships to other elements on the side of each card. During the session, physically arrange cards to visualize relationships.

6. As design alternatives emerge, keep all the cards on the table. Move cards to the side in case they are needed later. This lets you see and quickly evaluate alternatives.

7. Pick a new functional requirement or quality attribute scenario and walk through the architecture again. Add or change cards as needed. Alternatively, change assumptions about scenarios and see how that affects the architecture.

8. Repeat steps 4--8 until time runs out or the available functional requirements and quality attribute scenarios are addressed.

9. At the end of the session, record the elements and their assigned responsibilities. Also record key decisions and design principles that emerged during the session.

Guidelines and Hints

• Use index cards or sticky notes to represent elements.

• Keep the exercise fun and fresh by drawing pictures, not only text.

• It’s OK to informally mix structures (static, dynamic, and physical) if it helps with reasoning.

• Use digital collaboration tools to work with remote teammates or create an instant digital record.

• Every card should have at least one responsibility by the end of the activity. Consider carefully whether cards without responsibilities have a place in the architecture. Are there cards with too many responsibilities?

Example

Here is an example of how CRC cards can be used to flesh out architectural elements and their responsibilities:

Once the cards were laid out, a few interesting things became apparent. First, the Transformer (second column from the left) seems to have a lot of responsibilities and collaborators. What would happen if we split those responsibilities into different elements? See the top figure.

We moved the original Transformer to the side and split the element in two pieces. The new Transformer will only transform data while a new element, Training Prep, will prepare the transformed data for the Trainer element. We also identified a new element, the Training Monitor, but it’s not relevant in this current flow.

Again examining the emerging model, the Training Data Repo (top of third column) appears to have overloaded responsibilities. Can those responsibilities be reasonably moved to new elements?

It turns out we can focus only on the jobs workflow and remove all responsibilities for writing user data from this element. We moved the old Training Data Repo card to the side and added a new element with fewer responsibilities named Jobs Service (top of the third column from the left).

Next we will record a snapshot of these models, introduce a new scenario, and adjust or create CRC cards to support the new scenario.