User:Bluehat: Difference between revisions
No edit summary |
No edit summary |
||
Line 14: | Line 14: | ||
This is the count of all the supporting classes to help the main classes. Sometimes beginners confuse between collaborators and subclasses. This will create too many collaborators .A check in this case will help correct the inheritance and encapsulation to reduce collaboration. Typical value for this metric is eight. | This is the count of all the supporting classes to help the main classes. Sometimes beginners confuse between collaborators and subclasses. This will create too many collaborators .A check in this case will help correct the inheritance and encapsulation to reduce collaboration. Typical value for this metric is eight. | ||
==Advantages== | |||
* CRC cards create a first-cut analysis for complex systems, and let analysts and users examine the operation of discrete subsystems. | |||
* CRC cards are invaluable input into more formal methods. Agile development methods often use CRC cards. They are popular as a front end to UML | |||
* CRC cards are a great way to build teamwork and common understanding. | |||
* Part of the CRC card attraction is their simplicity. Developers can use them with little formal training and just paper and pencil for tools |
Revision as of 18:46, 6 September 2010
Metrics for CRC Analysis
CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. These metrics can be calculated easily and quickly without the need of special tools.[Mrinal]
Maximum depth of inheritance
This metric gives an idea of the class hierarchy. It is a count of how many times subtypes of objects is created. E.g. Car is the parent class for Toyota, BMW, and Mercedes .Each subclass shares the overall functions defined in Car class. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.
Number of responsibilities
This is the count of clearly defined set of duties to each class. One class should not have a huge set of responsibilities covering the whole system. This situation in a CRC card would indicate an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common. The design should be reviewed if this count is more than twelve.
Number of collaborators
This is the count of all the supporting classes to help the main classes. Sometimes beginners confuse between collaborators and subclasses. This will create too many collaborators .A check in this case will help correct the inheritance and encapsulation to reduce collaboration. Typical value for this metric is eight.
Advantages
- CRC cards create a first-cut analysis for complex systems, and let analysts and users examine the operation of discrete subsystems.
- CRC cards are invaluable input into more formal methods. Agile development methods often use CRC cards. They are popular as a front end to UML
- CRC cards are a great way to build teamwork and common understanding.
- Part of the CRC card attraction is their simplicity. Developers can use them with little formal training and just paper and pencil for tools