User:Bluehat

Introduction

The onset of the object oriented paradigm in the software industry brought about a big change in the basic approach to system design and the software development life cycle.The major task in the development of any application using the object oriented paradigm is to identify ‘classes’, and how these classes interact and collaborate with each other in the system scope.

Whenever a system is designed with classes, each class has a specific role to play in the system, it has certain responsibilities and each class collaborates with other classes to provide the complete system functionality. In such a scenario, identifying classes becomes the key to a good system design. Although it seems to be a simple, intuitive process, identifying classes can be quite complex when it comes to large scale systems.

One such technique for identification of classes that make up the system and its public interfaces, collaborations is the ‘CRC Card’ technique. The concept of CRC cards was first put forth by Kent Beck and Ward Cunningham and it became very popular as it is easy to use and it supports development of any kind of object oriented development regardless of its scale, the method used, the technology or the language used for development

Definition

Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other objects). The cards provide an informal, intuitive way for group members to work on object design together.

More about CRC Cards: http://www.hsanchez.net/repository/hsanchez-PLCRC-plop04.pdf

The process and principle

CRC modeling process includes the users, analysts, and developers in a modeling and design process, bringing together the entire development team to form a common understanding of an OO development project.

The CRC Principle: A CRC model includes a collection of cards and each card is divided into three sections.

• Class Name:
  • Appears on the top of the CRC card
  • Class denotes a set of similar objects that are being modeled in the system

• Responsibilities:
  • Appears on the left hand side of the CRC card
  • It is a list of the responsibilities of the class, ie what the class knows and things it can do with the knowledge it has

• Collaborator:
  • Appears on the right hand side of the CRC card
  • Collaborators are other classes that the class works with to get information or perform a certain function

The CRC Team

• Domain Experts:
  • Core team that writes the cards
  • Have good business domain knowledge for which the system is being designed
  • Usually are 3-5 people

• Object Oriented Design Analyst:
  • Analysts and developers those are familiar with object oriented design methodologies
  • Usually are 1-2 people

• Facilitator:
  • Most important member who conducts the CRC modeling session
  • Acts as an intermediary when there is difference of opinion regarding class responsibilities and paths of collaboration
  • Usually a single person

• Scribe:
  • Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process.
  • This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage

The CRC Process

• Explanation of the CRC Technique

• • The facilitator explains the purpose of the CRC modeling session
  • It can include explanation of CRC Cards and creation of sample CRC Cards

• Brainstorming
  • A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved.
  • Every team member can contribute with innovative ideas
  • A list of candidate classes can be drawn up from this activity

• Selecting a scenario and Core classes
  • The scenario chosen at the beginning of the session should be simple, clear and well documented
  • Related scenarios should be identified and dealt with separately
  • Identification of critical classes from the candidate class list is also very important
  • This helps to eliminate irrelevant classes and review remaining classes
  • This also helps clarify the system scope

• Create initial CRC cards
  • From the information gathered in the step above, CRC cards are written

• Creating a CRC Model
  • From the CRC cards written, they are placed appropriately, with collaborating classes closer to each other
  • Accordingly, place each card in position till the entire picture of the system is finalized.
  • This process may have to be done in several iterations to get a refined view of the system to be modeled

Using CRC Cards: http://alistair.cockburn.us/Using+CRC+cards

Case study

http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

Metrics for CRC Analysis

CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. These metrics can be calculated easily and quickly without the need of special tools.[Mrinal]

Maximum depth of inheritance

This metric gives an idea of the class hierarchy. It is a count of how many times subtypes of objects is created. E.g. Car is the parent class for Toyota, BMW, and Mercedes .Each subclass shares the overall functions defined in Car class. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.

Number of responsibilities

This is the count of clearly defined set of duties to each class. One class should not have a huge set of responsibilities covering the whole system. This situation in a CRC card would indicate an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common. The design should be reviewed if this count is more than twelve.

Number of collaborators

This is the count of all the supporting classes to help the main classes. Sometimes beginners confuse between collaborators and subclasses. This will create too many collaborators .A check in this case will help correct the inheritance and encapsulation to reduce collaboration. Typical value for this metric is eight.

Advantages

• CRC cards create a first-cut analysis for complex systems, and let analysts and users examine the operation of discrete subsystems.
• CRC cards are invaluable input into more formal methods. Agile development methods often use CRC cards. They are popular as a front end to UML
• CRC cards are a great way to build teamwork and common understanding.
• Part of the CRC card attraction is their simplicity. Developers can use them with little formal training and just paper and pencil for tools

Software for CRC card

It is difficult to maintain, change, share paper based cards for large projects. Software for CRC cards offer many advantages in such scenarios such as

• Easy Revision: As CRC cards are part of development process, constant changes are made by developers to edit the information .Change to one card might require changes to other cards. It becomes difficult to handle such interdependent changes for various fields such as attribute, responsibility, collaboration on paper based system. Software will reflect one change to every corresponding reference in the design. This saves a lot of time and also avoids the manual errors that may be evident on paper based system.

• Easy sharing: Paper based systems make sharing difficult by necessitating team members to be physically present at one location. Using software, team members can work from different locations.

• Better representation: It is possible to group cards from different perspective such as hierarchy, attributes, parent. This helps better understanding and thinking. Some software also aid graphical display of data.

• Inputs to methodologies: Software for CRC cards can provide the input files for UML class diagram generation software saving lot of time in the development cycle.

• Making additions to existing code: Many projects make addition to existing code or reuse already developed code in their project. Software can produce CRC cards with existing source code as an input. This would help the team to understand the code in efficient manner and less time.

However,it comes with a cost.Based on required features and cost,team may select from various commercially available software products.Below are few links:

• quickCRC:http://www.excelsoftware.com/
• CRC card support is part of Visual Paradigm for UML: http://www.visual-paradigm.com/

CRC cards Limitations and formal object modeling methodologies(UML)

CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and users is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:

http://www.math.gordon.edu/courses/cs211/ATMExample/