CSC/ECE 517 Fall 2011/ch4 4i sd
"CRC Card Tools"
Introduction
CRC Cards are the Class Responsibility Collaboration Cards which is a useful way to document collaborative design decisions. CRC Cards were invented by Kent Back and Ward Cunningham in 1989 as an approach for teaching object-oriented design.<ref name="paper"> Beck, Kent; Cunningham, Ward (October 1989), "A laboratory for teaching object oriented thinking", ACM SIGPLAN Notices (New York, NY, USA: ACM) 24 (10): 1–6, doi:10.1145/74878.74879, ISBN 0-89791-333-7</ref> Cunningham arrived at classes, responsibilities and collaborators as the essential dimensions of an object oriented model.<ref name="nancy">Nancy M. Wilkinson, "Using CRC Cards: An Informal Approach to Object-Oriented Development", ISBN 0-13-374679-8</ref> The intention was to come up the essential units of abstraction for the object-oriented approach analogous to the notions of processes, data flows, and data stores for procedural designs.<ref name="nancy" /> This wiki article will discuss about CRC cards, how they are made and a few software tools that are used to implement CRC cards.
CRC Cards
CRC Cards are the Class Responsibility Collaboration Cards which are used to interactively brainstorm an initial design of a program or a program segment. These are used as a tool used in the design on object oriented software.<ref name="crc">CRC Cards - Wikipedia</ref> It supports a rapid and thorough exploration of design alternatives. It is used during initial model construction as a brainstorming technique where it is used to determine which classes are needed and how they will interact among themselves, and again later to evaluate the design. Normally, it could be done by one person or may require up to five people.<ref name="alistair">CRC Cards</ref>
CRC cards explicitly represent multiple objects simultaneously. However, rather than simply tracing the details of a collaboration in the form of message sending, CRC cards place the designer’s focus on the motivation for collaboration by representing (potentially) many messages as a phrase of English text.<ref name="paper"></ref>
Description of CRC
The CRC cards are commonly created from 4 by 6 inch index cards and they contain:
- Class - the name of the object-oriented class
- Responsibility - the responsibilities of the class
- Collaborator - the relationship the class has with other classes in order to collaborate and fulfil its responsibilities
To identify the name of the classes, we look for the nouns in the requirements document. The class should be a singular noun, does not really have the same functionality as some other class, and is not a primitive type.
Responsibility-driven modelling can be done using CRC cards. These could also be used to form object interaction diagram. The advantage of using a small index card is that they are cheap, portable, readily available, and familiar.<ref name="paper" /> Since these cards are small in size, they help reduce the complexity of the design to minimum. It focuses the designer on the essentials of the class and prevents her/him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.
Steps in making CRC Cards
- Identify and assign candidate classes
- Determine a set of specific scenarios
- Walk through the scenario, naming cards and responsibilities
- Write the main responsibility for each class
- Identify the responsibilities for each class
- Identify one or more collaborators for each class
Then, essentially, these index cards become your class diagram. In your class diagram, you create a class for each card that was used. The responsibilities on the card become the method of the class. All collaborators indicate that an association between the two classes must be drawn (and the class will need to have an instance of the collaborating classes). Finally, the data members on the back of the card become the attributes of the class. You’ll probably need to make some adjustments to this initial design – for example recognizing and handling inheritance – but its usually a great start!
Example of a CRC Card
Here is an example of how a CRC Card looks.<ref name="dennis">Dennis, Wixom, Roth, "Systems Analysis and Design", 3rd Edition</ref> The CRC card here is for a Patient class. The Description of the class indicated the main responsibility associated with the class. Along with this information, the other responsibilities performed by this class is indicated in a separate Responsibilities section. If a collaborator is required to perform the responsibilities of the class, the name of the collaborator class is indicated in the Collaborators section associated with a particular responsibility. The back side of the card essentially displays the Attributes of the class and the Relationships of the class with other classes.
- Front Side of a CRC Card
- Back Side of a CRC Card
CRC Card Tools
There are a couple of CRC card tools available which are implemented in software packages to help users manage the different stories.
QuickCRC
QuickCRC is a tool developed by Excel Software for responsibility driven design of object-oriented software using CRC cards. CRC cards are used to discover and document classes, responsibilities, attributes and collaborations between classes. Design scenarios can be identified and simulated. Complex designs can be partitioned into multiple diagrams with easy navigation through a contents view. The inheritance graph automatically shows the class structure of the evolving design. The user can assign the attribute access of each card responsibility and the tool presents an attribute access graph.<ref name="quickcrc1">QuickCRC Tool</ref> This tool is available for both Windows and Mac OS X.
The features of QuickCRC<ref name="quickcrc2">QuickCRC by Excel Software</ref> are:
- Cards and scenario objects can be drawn in the diagram workspace. Each card has a class name, description, superclasses, subclasses, attributes, responsibilities and collaborating objects.
- The card information is entered through a dialog or edit on-screen by dragging or renaming cards, attributes, responsibilities and collaborations.
- Assign the attribute access of each card responsibility. Also shows an attribute access graph from the card information to help developers discover, refine and eliminate unnecessary card attributes.
- Scenarios can reference cards or other scenarios.
- Cut and paste cards and scenarios between diagrams or projects.
- Allows a designer to navigate between diagrams shown as folder icons that can be opened or closed. A card or scenario can be dragged between diagrams or double-clicked to edit its properties making it easy to locate and modify information as the model grows.
- Provides active simulation of an evolving design.
- Maintains relationships between cards, scenarios and external agents as fluid design changes take place. If a card references undefined subclasses or superclasses, those cards are generated automatically.
- Model other relationships between cards like aggregation and interface implementation.
- Name changes and cross references between objects are instantly updated.
- Has a rich search feature for locating design data within specific fields of any card or scenario in the project.
This software tool runs best on Windows XP, Vista or 7 with 1 GB RAM. The package includes both a Standard and Lite edition. The only difference between these two editions is the amount of data that a project can hold and the memory requirements of your machine.<ref name="quickcrc2" />
Software Ideas Modeler
Software Ideas Modeler is a lightweight and powerful CASE tool by Dusan Rodina. It supports UML 2.2 diagrams and a lot of other ones. Software Ideas Modeler is freeware (for non-commercial use). Commercial user may use this software only after buying a license.<ref name="modeler">Software Ideas Modeler</ref>
It supports various types of automatic alignment for diagram elements. Diagram can be zoomed. There are also implemented standard functions as undo/redo and work with clipboard. Diagram elements can be styled (background color, text color, fonts, border), grouped, placed in layers. There is an export to raster image formats (BMP, GIF, JPG, PNG, TIFF), vector image formats (Windows Metafile, SVG) and PDF. There is also export to XML. There is an import from XML.<ref name="simwiki">Software Ideas Modeler - Wikipedia</ref> It also provides support for various languages.
The application supports also style sets for the whole project. The diagrams can be exported to multiple image formats--vector formats WMF, EMF, SVG and bitmap format PNG. Very useful features of Software Ideas Modeler can be automatic scrolling, symbolic editing of elements or automatic size adjustment of the elements. The tool has support for source code generating (C#, VB.NET, SQL DDL).
Visual Paradigm
Visual Paradigm for UML (VP-UML) is a UML [CASE Tool supporting UML 2, SysML and Business Process Modeling Notation (BPMN) from the Object Management Group (OMG). In addition to modeling support, it provides report generation and code engineering capabilities including code generation. It can reverse engineer diagrams from code, and provide round-trip engineering for various programming languages.<ref name="visual">Visual Paradigm for UML</ref>
Class-Responsibility Collaborator (CRC) card is designed for identifying classes and operations in object-oriented approach. Visual Paradigm for UML provides a CRC Card diagram for software team to brainstorm, records, analyze and maintain CRC cards in systematic and collaborative way. This tool is very easy to use and intuitive. It allows easy addition of responsibilities to a class. Along with this, all fields on a crd can be edited inline.
Conclusion
CRC cards are used to give a useful and convincing experience with objects and the mechanisms of objects but do not yet see their value. Using CRC cards, one can speculate the designs, ensure that they are concrete and establish an explicit relationship between objects. This makes it easier to understand, evaluate, and modify a design. One of the major problem for using this is the integration of the cards with larger design methodologies and with particular language environments. The need to retain the value of physical interaction points to the need for a new kind of user interface and programming environment as far beyond what we have today as our current systems are beyond the tool-oriented environments of the past.<ref name="paper" />
See Also
References
<references/>