Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] CRC Modeling
This material was covered during lectures on March 17, 1997.
As previously mentioned, the line between ``object-oriented analysis'' and ``object-oriented design'' can be quite blurry. Some of the activities you perform during analysis are continued (or extended) during design.
Class-Responsibility-Collaborator modeling is a ``low tech'' method for allocating ``responsibilities'' to classes, and identifying the ``collaborators'' whose services classes must request, in order to fulfill their own responsibilities.
This is useful for identifying the services that classes must provide as well as the message connections between classes. Thus, this method can be considered to be part of object-oriented analysis. On the other hand, the guidelines that this method includes are clearly motivated by an attempt to produce designs that easy to change, so they should certainly be considered as well during object-oriented design.
Quite a bit of information about this method is included in the following.
R. Wirfs-Brock, B. Wilkerson, and L. Wiener
Designing Object-Oriented Software
Prentice-Hall, 1990
The fourth edition of Pressman's Software Engineering: A Practitioner's Approach includes a brief discussion of this topic (which includes everything presented on this page), in Section 20.4.2 (pages 594-599).
On completion of this method, you should have produced a ``CRC index card'' for each one of the classes you've identified. This can actually be a recipe card, sticky note, overhead, etc., but it should have the following format (shown in a picture based on a figure appearing in Pressman's text).
Guidelines for selecting classes have already presented. We'll assume that this have been followed, and that a set of ``problem domain'' classes have been identified.
One of the above index cards should be created for each of these; the ``class name'' to be entered should be the same as the name of the class that is shown on the class diagram that's been (or that is being) created.
A few ``types'' of things that can be problem domain classes have already been identified. A few more can be added, to obtain the following list (which will be sufficient for this course).
Here are some ``characteristics'' of problem domain classes that might be noted on the index cards. (This list is also taken from Pressman's text.)
If these types and characteristics can be identified then they should be noted on the class's index card in the spaces provided for this.
Some information about the selection of attributes and services was presented in the notes for object-oriented analysis.
Wirfs-Brock, et. al, present some additional guidelines that appear to be quite useful.
System intelligence should be evenly distributed. Each application includes a certain amount of ``intelligence,'' relating to what the system knows and can do. This can be distributed among classes in more than one way.
One approach is to use a (usually, large) number of ``dumb'' classes that act as servants for a (usually, smaller) number of ``intelligent'' classes. Wirfs-Brock, et. al., note that this can make the flow of control in an object-oriented system simpler, but that
Thus they recommend that you try to distribute intelligence more evenly among the classes in the model, instead.
Each responsibility should be stated as generally as possible. This relates to the allocation of attributes and services for classes in a generalization-specialization structure,, and is a rule that we've seen before: Allocate an attribute or service to a generalization whenever it's common to all of that class's specializations (instead of allocating it to each of the specializations that have it in common).
Information and the behaviour that is related to it should reside within the same class. Data and the processes that manipulate it should be packaged as a cohesive unit.
Information about one thing should be localized within a single class, not distributed among multiple classes. Quoting Pressman: ``A single class should take on the responsibility for storing and manipulating a specific type of information. This responsibility should not, in general, be shared across a number of classes. If information is distributed, software becomes more difficult to maintain and more challenging to test.''
Share responsibilities among related classes, when appropriate. This concerns cases when a variety of related objects must all exhibit the same behaviour at the same time. For example, it might imply that all the classes in a whole-part structure might be required to provide a service (assume part of a responsibility) in order to respond to an external event.
In order to identify responsibilities (especially, services), identify the external events that the system will need to respond to. You should be able to identify a class in your model that is somehow ``informed'' of the fact that this event has occurred; this class will certainly have at least part of the ``responsibility'' of responding to it. It's likely that (if you attempt to follow the guidelines given above, and the system's response is nontrivial) this class will need to send messages to other classes, who will help respond to the event; you should add responsibilities for all the classes that receive these messages, and so on, as well.
List the responsibilities for each class that you identify on the class's index card, in the left column shown on the bottom of the card (as shown in the figure above).
A ``collaborator'' for a class (``class A'') is another class (``class B'') that receives a message from class A, sent because the class A needs one of the class B's services to be performed, in order for one of class A's responsibilities to be fulfilled. When you realize that this happens, you should list class B as a collaborator of class A, by listing class B in the ``collaborator'' column on class A's index card, to the right of the listing for the responsibility that required the message to be sent.
Note that this goes in one direction: We don't automatically consider class A to be a collaborator for class B in this case as well.
Once you've identified each class's responsibilities (attributes, as well as services), you should be able to write a prototype for each (problem domain) class.
When a set of CRC cards for a system has been completed it can be used by a group to ``walk through'' the model, using the following approach. It's assumed that the group includes a ``review leader'' who guides the process, as well as several other participants. As described below, a ``token'' representing system control is passed from participant to participant. (Again, this is described in a bit more detail in Pressman's text.)
This will be applied to an example on a separate page.
A lab exercise based on this material is now available.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] CRC Modeling