|
Introduction Use QuickCRC to design object-oriented software with CRC cards on Mac OS X or Windows. Projects can be directly edited and shared from either platform. This introduction illustrates windows and dialogs captured from QuickCRC running on Windows. QuickCRC automates CRC (Class, Responsibilities and Collaborations) cards. Software designers can quickly identify object classes, relationships and related information before writing code. CRC cards are well suited to agile methods or as a front-end to UML. Books describing CRC cards include:
In its simplest form, CRC cards can be applied to a design project using a stack of index cards and a pencil. Each card identifies a class and its properties and relationships with other cards. As a project grows, automated tool support for CRC cards can save time and reduce design errors. As information is entered or modified, references between cards can be instantly updated. Verification checks ensure consistency and completeness. Design scenarios can be identified and simulated. An automated tool can graphically illustrate relationships between cards, making it easier to manage large projects. General Concepts The CRC card represents an object class and its properties. The words card, class and object are often used interchangeably although technically they are not the same thing. A class is a type from which an object is instantiated and a card is a collection of information about a class.
 The card, named TWindow for the class it represents, currently has one superclass named TEventHandler and no subclasses. This class has several responsibilities. A responsibility represents a function the object must perform for itself or to service the requests of other objects. This card must collaborate with other cards to accomplish some of its responsibilities, for example, TWindow's Draw responsibility collaborates with TWindow, TPalette and etc. The backside of a CRC card includes its description and a list of its attributes representing data the class must keep track of.
 With an automated tool, CRC card data is entered into a property dialog, much like writing it on a paper index card. One big advantage in using a tool is that new cards can be automatically created for you for undefined superclass, subclass or collaborating class references. Information can easily be inserted, changed or deleted and the card can be resized. When renaming a card, all references on other cards are instantly updated. To discover the data each class knows about and the responsibilities it must perform, scenarios are created. A scenario is a list of steps outlining the interaction between a group of classes to implement a mechanism in the design. Below the scenario name and description is three columns titled Client, Server and Responsibility. For each scenario step, a client class uses a responsibility of a server class. As an example, the Read Document scenario is shown below. TDocument is a class that holds data about a list of shapes read from disk into memory. This scenario has three steps starting with any client class calling the Read responsibility of TDocument. TDocument then uses the Initialize and Read responsibilities of TShape to create shape objects and read in their data from disk.
 During the early design process, developers usually focus on the normal interactions between objects when creating scenarios. Special situations often arise due to error conditions that must be handled, but usually these can be deferred until detailed design. If an error condition is significant to the overall design, it can be dealt with as a separate scenario. Scenarios can also refer to other scenarios. For example, the Open Document scenario shown below uses two other scenarios, Initialize Document and Read Document (illustrated above).
 Designing an object-oriented system using cards and scenarios is an iterative refinement process. An automated tool allows a designer to exercise part of a design expressed by a group of cards and scenarios by using high-level simulation. The designer can single step forwards or backwards through each design mechanism to locate errors and make changes before writing any code. A Design Example The following example will illustrate the process of designing a program using QuickCRC. The program to be designed allows the user to edit a diagram using a tool palette for drawing box and circle shapes. To model this program, the designer creates a card for each class, establishes relationships, assigns responsibilities and attributes, defines and simulates scenarios, checks the model for errors and illustrates interesting relationships between objects. Create CRC Cards A CRC model is usually created by an individual or small group of designers during the early phase of an object-oriented development project. Each CRC card can be added to a diagram workspace by clicking with a palette tool and typing information into a property dialog. The Card Properties dialog shown here indicates that TShape has a superclass called TObject and two subclasses, TBox and TCircle. Superclass or subclass cards are added by typing the name or by selecting from a popup list of existing cards. Each referenced class that doesn't already exist and corresponding superclass and subclass relationships get added when the dialog is dismissed.
Each card has a namespace prefix. The base namespace is used by default, but the designer can define and use up to 1000 namespaces. Namespaces are used to partition cards into different functional areas and provide selectivity when listing specifications, printing cards or exporting information to other tools. The CRC diagram below shows two more classes TList and TWindow each derived from the superclass TObject. Obvious relationships can be added at the beginning of a CRC card session. However, if designers are uncertain as to whether or not a relationship exists, it is better to keep classes separate, and see if a superclass or collaboration relationship arises out of the design scenarios. Assuming a relationship too early may force a particular decision and bias the distribution of responsibilities. The emphasis and strength of the CRC card technique and responsibility driven design in general lies in deriving the behavior of the class. The class structure comes naturally from the design process.
Assign Responsibilities Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. Responsibilities that are derived from the requirements or that are obvious from the name of the class can be listed before any scenario execution commences. The responsibilities of a class are also referred to as its functions, operations or methods. For example, the TShape card has responsibilities Initialize to create it, Free to dispose of its memory, Read to load its data from disk into memory, Write to save it to disk and Draw to illustrate it on the diagram. Give each responsibility a short description that indicates what it accomplishes. Other responsibilities may be discovered later after creating scenarios to work through mechanisms in the design. Add Attributes Attributes of classes may also be identified early in a CRC session. Often, nouns that are not classes but rather characteristics of classes are best represented as attributes. Attributes can be assigned to classes as they are discovered, but should be done in moderation and only when it becomes apparent that the class must know that information. The TShape class has attributes fPosition, fType and fSelected. Each attribute can be given a short description. This information is added to the back of the CRC card.
 On-Screen Editing You've seen how the Card Properties dialog is used to edit cards, relationships, attributes and responsibilities. Some editing changes can be made directly on-screen with the Drag tool. This tool can be used to add, edit, move or delete information on cards. For example, the TBox class will override and implement many of the responsibilities introduced by its parent, TShape. Position the Drag tool over the name Read in the responsibility list for TShape. With the Ctrl key pressed, press the mouse button and drag that name to the responsibility list for the TBox card. The Read responsibility is copied to TBox. If the Ctrl key is not press, the Read responsibility is moved from the TShape to the TBox card, rather than copied. In addition to adding or moving responsibilities, you can use the Drag tool for attribute names or card names in the Subclass, Superclass or Collaboration fields. The Drag Tool can also be used for adding or editing names. To do this, click on an empty line in the responsibility list of a card. Type the responsibility name and press the Enter key. As a shortcut, you can add a list of names by separating each name with a comma and pressing the Enter key at the end. Define a Scenario A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities. Assign responsibilities to classes by exploring how the system responds to external events. Scenarios are detailed examples of the functions of the system, where each function refers to visible, testable behavior. A scenario describes what happens in the system from a high-level, user point of view. For example, the Open Document scenario involves only those classes and the subset of their responsibilities involved in opening a disk document. The goal of walking through scenarios is to discover where additional classes, responsibilities and collaborations are required, or where existing items have become redundant or inconsistent. Consider the scenario named Draw Window. The TWindow class draws itself by looping through a list of shapes in the document, drawing each one and then drawing the tool palette. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class. A designer adds each step in a scenario to a property dialog by selecting class names and responsibilities from a popup list of what is already defined in the model. A new class or responsibility can be added to the model by typing its name.
 Simulate Scenarios Scenarios can use other scenarios to get their work done. Initialize Document and Read Document are both subscenarios related to the server class TDocument. The Open Document scenario references these subscenarios.
 Using QuickCRC, a designer can simulate a selected scenario. By single stepping forwards, backwards or through each subscenario, bugs in the design can be identified and corrected early. An active scenario list shows your position within a hierarchical stack of scenarios. This list helps you keep your bearings in a complex simulation and allows you to change to a different spot in the simulation path.
Partition The Design As the number of CRC cards in the design grows, they can be grouped by function. Separate diagrams are used to partition the model into subject areas. The Contents view is used to navigate or move cards between diagrams. As illustrated below, the Contents view at the left of the CRC window has a folder icon that can expand or collapse to represent each diagram level.
Inheritance Graph QuickCRC can generate inheritance graphs from information on CRC cards. These diagrams concisely illustrate the big picture of a large project that might contain thousands of classes and hundreds of diagrams.
Verify Your Work Creating and simulating scenarios will help verify that a design is correct and complete. QuickCRC can perform error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed. Summary CRC cards provide a simple approach to identifying classes and related information for an object-oriented development project. Design scenarios identify how mechanisms in the design work. QuickCRC is an automated tool that supports the process by instantly updating references between cards and scenarios, providing scenario simulation, error checking, instant inheritance graphs and making it easy to locate or modify information. While this tutorial covers the basics of using CRC cards, QuickCRC adds some advanced features. The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design. QuickCRC makes it easy to link cards and scenarios to foreign documents so they can be easily accessed with a mouse click. Information can be imported from or exported to other development tools. This enables generation of CRC cards from source code with WinTranslator or MacTranslator. Data from CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams. QuickCRC can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file. In today's world of pressing deadlines and distributed development teams, there are huge advantages to using electronic design documentation. It provides instant network access for peers, reviewers, management or customers. It provides a means to communicate across geographic boundaries, time zones and can streamline the development process. |