The interactions diagrams for only simple use cases that involve collaboration among a limited number of classes can be drawn from an inspection of the use case description. More complex use cases require the use of CRC cards where a number of team members participate to determine the responsibility of the classes involved in the use case realization.
CRC (Class-Responsibility-Collaborator) technology was pioneered by Ward Cunningham and Kent Becka at the research laboratory of Tektronix at Portland, Oregon, USA. CRC cards are index cards that are prepared one per each class. On each of these cards, the responsibility of each class is written briefly. The objects with which this object needs to collaborate its responsibility are also written.
CRC cards are usually developed in small group sessions where people role play being various classes. Each person holds the CRC card of the classes he is playing the role of. The cards are deliberately made small (4 inch ´ 6 inch) so that each class can have only limited number of responsibilities. A responsibility is the high- level description of the part that a class needs to play in the realization of a use case. An example CRC card for the Book Register class of the Library Automation System.
After assigning the responsibility to classes using CRC cards, it is easier to develop the interaction diagrams by flipping through the CRC cards.
CRC card for the Book Register class
Develop sequence diagram for any given use case.
Consider the Tic-tac-toe computer game discussed earlier. The step-by-step workout of this example is as follows:
• The use case model
• The initial domain model
• The domain model after adding the boundary and control classes
• Sequence diagram for the play move use case
(a) Initial domain model (b) Refined domain model
Sequence diagram for the play move use case
Identify how sequence diagrams are useful in developing the class diagram.
Consider the Supermarket prizes scheme software discussed earlier. The stepby-step analysis and design work out of this problem is as follows:
• The use case model is.
• The initial domain model
• The domain model after adding the boundary and control classes
• Sequence diagram for the select winner list use case.
• Sequence diagram for the register customer use case .
• Sequence diagram for the register sales use case. In this use case, since the responsibility of the Register Sales Controller is trivial, the controller class can be deleted and the sequence diagram can be redrawn after incorporating this change.
• Class diagram. The messages of the sequence diagrams of the different use cases have been populated as the methods of the corresponding classes.
Use case model for Super Market Prize Scheme
(a) Initial domain model (b) Refined domain model
Sequence diagram for the select winner list use case
Sequence diagram for the register customer use case
Sequence diagram for the register sales use case
Refined sequence diagram for the register sales use case
Class diagram
Identify five important criteria for judging the goodness of an object-oriented design.
It is quite obvious that there are several subjective judgments involved in arriving at a good object-oriented design. Therefore, several alternative design solutions to the same problem are possible. In order to be able to determine which of any two designs is better, some criteria for judging the goodness of a design must be identified. The following are some of the accepted criteria for judging the goodness of a design.
• Coupling guidelines. The number of messages between two objects or among a group of objects should be minimum. Excessive coupling between objects is determined to modular design and prevents reuse.
• Cohesion guideline. In OOD, cohesion is about three levels:
# Cohesiveness of the individual methods. Cohesiveness of each of the individual method is desirable, since it assumes that each method does only a well-defined function.
# Cohesiveness of the data and methods within a class. This is desirable since it assures that the methods of an object do actions for which the object is naturally responsible, i.e. it assures that no action has been improperly mapped to an object.
# Cohesiveness of an entire class hierarchy. Cohesiveness of methods within a class is desirable since it promotes encapsulation of the objects.
• Hierarchy and factoring guidelines. A base class should not have too many subclasses. If too many subclasses are derived from a single base class, then it becomes difficult to understand the design. In fact, there should approximately be no more than 7±2 classes derived from a base class at any level.
• Keeping message protocols simple. Complex message protocols are an indication of excessive coupling among objects. If a message requires more than 3 parameters, then it is an indication of bad design.
• Number of Methods. Objects with a large number of methods are likely to be more application-specific and also difficult to comprehend – limiting the possibility of their reuse. Therefore, objects should not have too many methods. This is a measure of the complexity of a class. It is likely that the classes having more than about seven methods would have problems.
• Depth of the inheritance tree. The deeper a class is in the class inheritance hierarchy, the greater is the number of methods it is likely to inherit, making it more complex. Therefore, the height of the inheritance tree should not be very large.
• Number of messages per use case. If methods of a large number of objects are invoked in a chain action in response to a single message, testing and debugging of the objects becomes complicated. Therefore, a single message should not result in excessive message generation and transmission in a system.
• Response for a class. This is a measure of the maximum number of methods that an instance of this class would call. If the same method is called more than once, then it is counted only once. A class which calls more than about seven different methods is susceptible to errors.
