Now that we have covered the fundamental concepts of object-oriented systems analysis and design, we need to examine ways to create classes and objects from the business problems and systems we are facing. One way to begin enacting the object-oriented approach is to start thinking and talking in this new way. One handy approach is to develop CRC cards.
CRC stands for class, responsibilities, and collaborators. The analyst can use these concepts when beginning to talk about or model the system from an object-oriented perspective. CRC cards are used to represent the responsibilities of classes and the interaction between the classes. Analysts create the cards based on scenarios that outline system requirements. These scenarios model the behavior of the system under study. If they are to be used in a group, CRC cards can be created manually on small note cards for flexibility, or they can be created using a computer.
We have added two columns to the original CRC card template: the Object Think column and the property column. The Object Think statements are written in plain English, and the property, or attribute, name is entered in its proper place. The purpose of these columns is to clarify thinking and help move toward creating UML diagrams.
Interacting During a CRC Session
CRC cards can be created interactively with a handful of analysts who can work together to identify the class in the problem domain presented by the business. One suggestion is to find all the nouns and verbs in a problem statement that has been created to capture the problem. Nouns usually indicate the classes in the system, and responsibilities can be found by identifying the verbs.
With your analyst group, brainstorm to identify all the classes you can. Follow the standard format for brainstorming, which is not to criticize any participant’s response at this point, but rather to elicit as many responses as possible. When all classes have been identified, the analysts can then compile them, weed out the illogical ones, and write each one on its own card. Assign one class to each person in the group, who will “own” it for the duration of the CRC session.
Next, the group creates scenarios that are actually walk-throughs of system functions by taking desired functionality from the requirements document previously created. Typical systems methods should be considered first, with exceptions such as error recovery taken up after the routine ones have been covered.
As the group decides which class is responsible for a particular function, the analyst who owns the class for the session picks up that card and declares, “I need to fulfill my responsibility.” When a card is held in the air, it is considered an object and can do things. The group then proceeds to refine the responsibility into smaller and smaller tasks, if possible. These tasks can be fulfilled by the object if it is appropriate, or the group can decide that it can be fulfilled by interacting with other things. If there are no other appropriate classes in existence, the group may need to create one.
The four CRC cards depicted in the figure illustration below show four classes for course offerings. Notice that in a class called Course, the systems analyst is referred to four collaborators: the department, the textbook, the course assignment, and the course exam. These collaborators are then described as classes of their own on the other CRC cards.
The responsibilities listed will eventually evolve into what are called methods in UML. The Object Think statements seem elementary, but they are conversational so as to encourage a group of analysts during a CRC session to describe as many of these statements as possible. As shown in the example, all dialog during a CRC session is carried out in the first person, so that even the textbook speaks: “I know my ISBN.” “I know my author.” These statements can then be used to describe attributes in UML. These attributes can be called by their variable names, such as edition and publisher.
