Class – Reponsibility – Collaboration

The software development and modelling is an important discipline in computing field, where architects, developers and team projects aim to translate the business requirements (gathered from customers and stakeholders during meetings and interviews) to technical implementation with object models, databases schemas, tests plans …etc.
This task of translating requirements can be achieved by using different methods and approaches of analysis as the use-case diagram, object identification, responsibility allocations …etc. One of the important methods to review that the technical implementation covers the initial requirements is the CRC (class–responsibility–collaboration) method.
What is CRC?
The CRC technique was initially presented by Kent Beck and Ward Cunningham at OOPSLA in 1989, at that time it was completely different from others. The technique had not emerged from a formal approach or older techniques and instead of using diagrams and representations; it uses people and cards (Deacon, 2005).
The basic idea behind CRC method is that it helps identifying the candidate classes, once done; it is easier to identify redundant, duplicates and missing classes (Hunt, 2003).
The CRC sessions needs the use case scenarios of the requirements, where each session focuses in one use case. People involved in these sessions ‘play’ the role of objects and someone reads throw the use case requirements and for each scenario we check if an object is responsible of doing that task. The aim of this approach is to check that we have covered the whole requirements stated in the use case and if not, review the object model to create the appropriate classes or entities to perform the missing task.
Advantages
The advantages of this approach might be summarized in:
– CRC is a good method to be used as exploratory class identification; i.e. it helps the developers to understand and explore the field for which the system is designed. The example of ATM provided in the Lecture notes is a good example for developers to understand how the banking systems are designed and developed.
– It is a good method for object-oriented programming teaching; it shows how object encapsulates fields (properties and data), how objects expose their behaviours by methods, how the messaging process can be implemented between objects …etc. (Hunt, 2003).
– It is a simple method where non-developers can be involved to play roles in the scenario.
– It gives a clear idea about how the inner implementation is being performed to all participants.
Disadvantages   
The CRC method has some cons that can be summarized in the fact that it is not complete enough to base a real world development. In addition to some parts and possible uses that are not described clearly in the use-case requirements and initial scope of work (Hvam.et.al, 2002).
If I was involved in a team project, I would act out the scenarios and I would really appreciate using this method, as it shows things simply and easily and review the initial requirements described in the use-case and the SOW. However, another analysis should be performed in order to identify the hidden scenarios and the possible requirements and ways that were not clearly presented in the CRC method. I personally consider the CRC method as the first level of check, but should not be used as the only one.

References:

– John Deacon (2005). Object-Oriented Analysis and Design: A Pragmatic Approach. ISBN: 0-321-26317-0.
– John Hunt (2003) Guide to the Unified Process Featuring UML, Java and Design Patterns. ISBN: 1-852-33721-4.
– Lars Hvam, Jesper Rii, Benjamin Loer (2002). Hansen1 CRC cards for product modelling. ISSN: 0166-3615.