CSC/ECE 517 Fall 2010/ch1 S6 CC: Difference between revisions
No edit summary |
No edit summary |
||
Line 57: | Line 57: | ||
== Class Collaborations == | == Class Collaborations == | ||
To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. | To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are used. An use case is a sequence of events performed in response to the request or event. |
Revision as of 03:57, 7 September 2010
Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.
Introduction
CRC stands for Class Responsibility Collaborator.CRC card modeling is one of the prominent Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.Class-Responsibility-Collaboration cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking". CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.
Structure of a CRC card
CRC card consists of three parts.
Class Name
The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand. The class name appears across the top of the card.
Class Responsibilities
A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.
For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.
Collaborators
A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.
A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.
CRC Session
The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are
1 . Domain Users
The Domain Users are the users of the system being designed.
2 . OO Design Analyst
Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques.
3 . Facilitator
Facilitator is the one who is responsible to keep the crc session progress forward
4 . Scribe
Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards.
Discovery of Class names
The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.
Class responsibilities
Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.
Class Collaborations
To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are used. An use case is a sequence of events performed in response to the request or event.