User:Bluehat

From Expertiza_Wiki
Revision as of 03:41, 7 September 2010 by Bluehat (talk | contribs)
Jump to navigation Jump to search

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


Software for CRC card

It is difficult to maintain, change, share paper based cards for large projects. Software for CRC cards offer many advantages in such scenarios such as

  • Easy Revision: As CRC cards are part of development process, constant changes are made by developers to edit the information .Change to one card might require changes to other cards. It becomes difficult to handle such interdependent changes for various fields such as attribute, responsibility, collaboration on paper based system. Software will reflect one change to every corresponding reference in the design. This saves a lot of time and also avoids the manual errors that may be evident on paper based system.
  • Easy sharing: Paper based systems make sharing difficult by necessitating team members to be physically present at one location. Using software, team members can work from different locations.
  • Better representation: It is possible to group cards from different perspective such as hierarchy, attributes, parent. This helps better understanding and thinking. Some software also aid graphical display of data.
  • Inputs to methodologies: Software for CRC cards can provide the input files for UML class diagram generation software saving lot of time in the development cycle.
  • Making additions to existing code: Many projects make addition to existing code or reuse already developed code in their project. Software can produce CRC cards with existing source code as an input. This would help the team to understand the code in efficient manner and less time.

However,it comes with a cost.Based on required features and cost,team may select from various commercially available software products.Below are few links:


CRC cards Limitations and formal object modeling methodologies(UML)

CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,interprocess communication functionality,algorithm design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML are used.UML captures the bigger picture.It provides more detailed mapping of use cases(operations),subtypes and super types,object state transitions and specific message methods.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and interfaces is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:

http://www.math.gordon.edu/courses/cs211/ATMExample/



Summary

Reference