CSC/ECE 517 Fall 2012/ch1 1w11 ap: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(35 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Introduction==
==Introduction==
<b> CRC Cards </b> also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card <b> Class-Responsibility-Collaboration <sup></sup></b>] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was  proposed by <b>Ward Cunningham</b> and <b>Kent Beck</b><sup>[http://c2.com/doc/oopsla89/paper.html]</sup>. The CRC card can be viewed as an index card, with the following details:
<b> CRC Cards, </b> also known as [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card <b> Class-Responsibility-Collaboration <sup></sup></b>] cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was  proposed by <b>Ward Cunningham</b> and <b>Kent Beck</b><sup>[http://c2.com/doc/oopsla89/paper.html]</sup>. The CRC card can be viewed as an index card, with the following details:
[[Image:crc-card.gif|frame|right|CRC Card Structure]]
[[Image:crc-card.gif|frame|right|CRC Card Structure]]


Line 7: Line 7:
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.
:* The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.


Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. <br> <br> According to <sup>[http://www.extremeprogramming.org/rules/crccards.html]</sup><i>A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.</i>
Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular [http://en.wikipedia.org/wiki/Use_case Use case]. <br> <br> According to <sup>[http://www.extremeprogramming.org/rules/crccards.html]</sup><i>A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process' weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.</i>


===A CRC Example===
===A CRC Example===
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the <b>Student CRC Card</b> as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the <b>Course</b> class. The <b>Course CRC Card</b> can in turn be visualized as having its own responsibilities, such as having attributes like Course Id, course name and the collaborating class would be the <b>Instructor  
To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the <b>Student CRC Card</b> as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the <b>Course</b> class. The <b>Course CRC Card</b> can in turn be visualized as having its own responsibilities, such as having attributes like Course id, course name and the collaborating class would be the <b>Instructor  
class</b>. The CRC cards for the Student class and the Course Class are shown below.<br><br>
class</b>. The CRC cards for the Student class and the Course Class are shown below.<br><br>
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
[[Image:Stud_enr_Crc.jpg|frame|center|Student and Course CRC Card]]
Line 16: Line 16:
There are also several practical designs that use the CRC card model to design Object oriented software design. The  [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.
There are also several practical designs that use the CRC card model to design Object oriented software design. The  [http://www.extremeprogramming.org/example/crcsim.html Simulator for Coffee Maker] explores an [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] approach combined with CRC card technique to come up with a design for the coffee maker.


Another interesting approach using CRC cards explores a design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]
Another interesting approach using CRC cards is the design for the [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html ATM Machine]


===Advantages of CRC cards===
===Advantages of CRC cards===
There are quite a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
There are a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are
<br>
<br>
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modelling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]
:* CRC can be used with other formal object oriented design methodologies such as [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming] (an [http://en.wikipedia.org/wiki/Agile_Modeling Agile] development Technique) and can be used along with modeling languages such as [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language(UML)]


==Why need a Software for CRC Cards==
==Software for CRC Cards==
CRC cards are limited by their scope. If we go about designing a huge project, the scope spans many classes and interactions between them. The tedious task of maintaining are CRC cards and to properly formulate interaction can get overwhelming.  
CRC cards have limited scope. If we go about designing a huge project, the scope may span many classes and there might be numerous interactions between them. The tedious task here is to maintain the CRC cards and formulate appropriate interaction between them.  
Following reasons propel use for software for CRC Cards :
We need software for CRC Cards for the following reasons:
:* <b>Designing Scenario:</b>  A scenario represents series of steps in which classes and objects communicate. There are be references to other cards or scenarios.  
:* <b>Designing Scenario:</b>  A scenario represents a series of steps in which classes and objects communicate. There can be references to other scenarios.  
:* <b>Modeling :</b>  Software provide an easy way to segregate cards and objects into different diagrams. Thus we can model our software with different functionality very easily.
:* <b>Modeling :</b>  Software provides an easy way to segregate cards and objects into different diagrams. Thus we can model our problem with different functionality very easily.
:* <b>Simulation :</b> Software can provides simulation of an software design. This might include single stepping backwards, forwards a scenario or jumping to a specific location in the scenario stack of a multiple scenario simulation
:* <b>Simulation :</b> Software can provide simulation of the design. This might include single-stepping a scenario forward or backwards or jumping to a specific location in the scenario stack of a multiple scenario simulation.
:* <b>Synchronization and Dependencies:</b> Software can maintain relationships between cards, scenarios as design changes take place. If a card references other cards or classes, those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.  
:* <b>Synchronization and Dependencies:</b> Software can maintain relationships between cards and scenarios as design changes take place. If a card references other cards or classes, any changes in those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.  
:* <b>Revision history and Version Control :</b> Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC cards. This is extremely helpful in realizing the design changes to CRC cards.
:* <b>Revision history and [http://en.wikipedia.org/wiki/Revision_control Version Control] :</b> Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC card. This is extremely helpful in tracking design changes.


==Designing Software==
==Designing Software==
The following steps proceed while designing Software for CRC cards:
The steps to design software for CRC cards are:


*<b>Create CRC Cards</b>
*<b>Create CRC Cards</b> : A CRC model is usually created by an individual (or small group of designers) during the early phase of an object-oriented development project. The figure shows the design of hierarchy of classes. The set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Let us assume we create new class TWindow derived from the superclass TObject.  [[Image:Design.png|thumb|Description]]
A CRC model is usually created by an individual or small group of designers during the early phase of an object-oriented development project.The figure shows the design of hierarchy of classes. These set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Lets assume we create new class TWindow derived from the superclass TObject.  [[Image:Design.png|thumb|Description]]


*<b>Assign Responsibilities</b>
*<b>Assign Responsibilities</b> : Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities ''Initialize'' to create it and ''Draw'' to illustrate it on the diagram.


Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities Initialize to create it and Draw to illustrate it on the diagram.
*<b>Add Attributes</b> : Attributes of classes may also be identified in a CRC Card. The TShape class has attributes fPosition, fType and fSelected.


*<b>Add Attributes</b>
*<b>Define and simulate Scenario</b> : A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities. A scenario describes what happens in the system from a high-level, user's point of view.
[[Image:Scenario.png|thumb|Description]]
 
Consider the situation to the right. We have defined two CRC cards with their responsibilities. A scenario defines several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class
 
The Open Document scenario in the picture references the Initialize Document sub-scenario by specifying its server class ''Document'' in the server field and its scenario name in the Responsibility field. The first step in the Initialize Document sub-scenario uses ''Document'' as the server class name. By single-stepping forward, backwards or through each sub-scenario, bugs in the design can be identified and corrected early.
 
*<b>Partition the Design</b> : As the number of CRC cards in the design grow, they can be grouped by function. By using Software for CRC cards, we can draw separate diagrams to partition the model into different subject areas.
 
*<b>[http://www.google.com/search?q=what+is+an+inheritance+graph&rlz=1C1CHFX_enUS460US460&sugexp=chrome,mod=14&sourceid=chrome&ie=UTF-8#hl=en&rlz=1C1CHFX_enUS460US460&q=inheritance+graph&tbs=dfn:1&tbo=u&sa=X&ei=IyFdUK_wAZLw8ATD8oHgCw&ved=0CB8QkQ4&bav=on.2,or.r_gc.r_pw.r_qf.&fp=99d6414d69e5a888&biw=1517&bih=783 Inheritance Graph]</b> : An automated tool can generate an inheritance graph from information on CRC cards. This diagram can concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.
 
*<b>Verify Your Work </b> : Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software can perform other error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed.
 
==Software Development Process for Object Oriented Development<sup>[6]</sup>==
 
Software Development Life Cycles are different for a standard development process and for Object Oriented development. This difference needs to be understood in order to know how to meet the benchmarks set for the project. There are multiple processes that are used in software development, the most common ones in use being Waterfall model and Spiral model. The Waterfall model is progression based and the Spiral model is iterative.


Attributes of classes may also be identified in a CRC Card.The TShape class has attributes fPosition, fType and
We need to understand that the uniqueness of Object Oriented SDLCs comes from the fact that it is more user centric as compared to standard SDLCs that are more system centric. We will now see which models work for Object Oriented SDLCs (OO SDLCs) and which don’t. CRC cards play a very important role in an Object Oriented SDLC. Thus, figuring out which models work well for OO SDLCs will result in understanding which models use CRC cards and why.
fSelected.
====The Waterfall Model====


*<b>Define and simulate Scenario</b>
The Waterfall model is implemented in multiple phases with each phase having a clear demarcation in terms of its functionality and deliverable. It uses clear stepping stones to come up with deliverables for each deadline. In this case, there are multiple ways to measure progress and methods by which to audit internally and apply checkpoints.


A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating
The downside of the Waterfall model lies in the fact that it is a very rigid model that does not offer much in terms of leeway when it comes to deliverables and what each phase in the cycle has to offer. The process is also overly mechanical and over time, just ends up being boring.
classes. Collaboration between classes refers to a client object that uses a responsibility performed
by a server object. Often a class must call upon several collaborating classes to implement one of its
responsibilities.A scenario describes what happens in the system from a high-level, user point of view.
[[Image:Scenario.png|thumb|Description]]
Consider situation to the right. We have defined two CRC cards with their responsibility. A scenario deinfes several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step,
a client class uses a responsibility of a server class


The Open Document scenario in the picture references the Initialize Document subscenario
Owing to the emphasis on checkpoints and deliverables with strict deadlines, in most cases the analysis and design phases are usually cut short and thus, the project may veer very far from reality. The users are involved only in the requirement gathering phase. This might result in mistranslation of the requirements of the user into what may be an amazing final product but something that the user did not even ask for.
by specifying its server class Document in the server field and its scenario name in the Responsibility field.
The first step in the Initialize Document subscenario uses Document as the server class name.
====The Spiral Model====
This model iteratively goes through the phases of analysis, design, prototyping and testing after the initial requirements gathering phase. With each iteration, the product is improved based on the feedback from testing in the previous iteration. If required, the outcome of each phase is analyzed, revised and the next prototype is developed after the design is revised, if pertinent. The products from the first phase are not abandoned, they are revised. Evidently, this model is non-linear in nature.


By single stepping forwards, backwards or through each subscenario, bugs in the design can be identified and corrected early.
After the first pass through the checkpoint, we can conclude that the work so far is adequate, but not final. The model places emphasis on the iterative process and on the development of standard prototypes at the end of each iteration. At the end of every cycle, we notice the shortcomings from the previous cycle and might end up having to redo all the work in the previous cycle. This proves to be a complete waste of time and effort. All the effort now goes into developing the end point for an older cycle, which makes the model ineffective for the current cycle.


*<b>Partition the Design</b>
One of the major drawbacks of such a non linear model is that the cost effectiveness and risk analysis cannot be analyzed thoroughly.
As the number of CRC cards in the design grows, they can be grouped by function. Using Software for CRC cards,
separate diagrams are used to partition the model into different subject areas.
====Why CRC cards are not useful in Waterfall and Spiral Models====


*<b>Inheritance Graph</b>
The strength of OO model depends on the idea that, here, design and deployment come together. In the case of a spiral model, this works to make the spiral tighter. Since the waterfall model places over importance on deliverables and user involvement is minimal, which is one of the key focuses of OO SLDCs using CRC cards, the model is considered ineffective. The Spiral model involves multiple revisions of the same idea. When a set of cards have been developed, it would make sense to refine the idea presented in the card but not to redefine them over and over, which may be the case. This does not serve the purpose of actually convening a CRC discussion among the team to draw up cards corresponding to the user requirement. Moreover, in the case of the Spiral model, we would need to convene multiple such meetings at each iteration, which would drastically bring down the overall productivity of the team.
An automated tool can generate an inheritance graph from information on CRC cards. This diagram can
concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.


*<b>Verify Your Work </b>
==CRC Cards in Software Development Process==


Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software
===Agile Methodology and CRC Cards===
can perform other error checks to locate design problems.
For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete
or perhaps the responsibility isn't needed.Likewise, a card that is not used by any collaboration
may not be needed.


Agile development is a model that has resurfaced and is gaining fame for its incremental cum iterative process. The iteration is carried over the processes of discovery, analysis, design and coding. In each iteration, the old model is worked on in each of the overlapping mini-cycles. The overlap of the cycles makes the process apparently iterative in nature. The model is considered incremental since every step acts as a value-add and this is emphasized by the capacity of classes for reuse. The idea that each phase is repeated ensures that the project is constantly working on a higher level of understanding. Moreover, the OOPS concept of reuse can be used to our advantage such that when we are continuously using OO development models in all our projects, the next implementation can be started  far ahead in the SDLC.


The model focuses on analysis and design phase predominantly. Within each of these are mini phases of analysis->prototype->revision-> implementation cycles. The advantage of this model compared to other models described is that, being incremental, this also results in tightening of the spiral at the end of each iteration using concepts such as reusability and polymorphism. Thus, the progression from one point to another in the cycle is seamless from start to deployment.


==CRC Cards in Software Development==
CRC cards can be very effectively and efficiently used in the Agile model of OO SDLC owing to the fact that it is incremental as well as iterative and not just a repetitive process. Thus, we would not have to redefine the cards from the scratch at any point. Being incremental, we would refine our current model and proceed to refine the entire system as a whole at the end of all iterations. We would essentially be adding value to the cards written out in the previous cycle and if perfected, would never have to discard cards from any of the precious cycles.
The power of CRC cards for OOP development is in the group session that employs them. The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach.  
           
Agile also practices active customer involvement. In every phase, the user is involved. This is one of the key characteristics of the CRC card design method. This not only ensures that the final product is as per the customer's requirements, but also that the customer is thoroughly satisfied, since they are aware of the changes and increments at each level. Another key aspect of Agile methodology is that it is feature driven. A CRC card holds details as to the feature of each class and how it collaborates with the rest of the system. Since this information is readily available to the developer and is highly fine-tuned by the end of the SDLC process, the cards can guarantee focus on 80/20 principle (i.e. pay more attention to 20% of the features which will used 80% of the times).  


CRC cards are used in a few steps of the software development process such as Analysis and Design.
The power of CRC cards for OOP development is in the group session that employs them.  The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach. CRC cards are used in a few steps of the software development process such as Analysis and Design.


'''CRC Cards for Analysis'''
===CRC Cards for Analysis===


CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase.  When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem.  In this phase, the group identifies the objects that are relevant to the application.  Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.
CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase.  When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem.  In this phase, the group identifies the objects that are relevant to the application.  Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.
Line 107: Line 114:
At the end of the analysis phase, the CRC elements that will be available are:
At the end of the analysis phase, the CRC elements that will be available are:


'''Classes:''' The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.
* '''Classes:''' The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.
 
'''Responsibilities:'''  The responsibilities that are assigned to the classes in this phase are of relatively higher level.


----
* '''Responsibilities:'''  The responsibilities that are assigned to the classes in this phase are of relatively higher level.


'''CRC Cards for Design'''
===CRC Cards for Design===
   
   
During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[] A CRC card tool may be helpful for saving, illustrating and documenting a design.
During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[5] A CRC card tool may be helpful for saving, illustrating and documenting a design.


Advantages of using CRC cards in Design phase:
'''Advantages of using CRC cards in Design phase:'''


* These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.
* These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.
Line 128: Line 133:


==Summary==
==Summary==
Software for CRC cards are immensely helpful in designing and modeling Software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.
Software for CRC cards are immensely helpful in designing and modeling software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.


==See Also==
==See Also==
Line 136: Line 141:


==References==
==References==
[1] A Laboratory For Teaching Object-Oriented Thinking: [http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html]
[1] [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]


[2] CRC Cards: [http://www.extremeprogramming.org/rules/crccards.html http://www.extremeprogramming.org/rules/crccards.html]
[2] [http://www.extremeprogramming.org/rules/crccards.html CRC Cards]


[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]
[3] [http://www.extremeprogramming.org/example/crcsim.html A Simulator for Coffee Maker]


[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]
[4] [http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html CRC Card for ATM]
[5] "Using CRC Cards: An Informal Approach to Object-Oriented Development" by Nancy M.Wilkinson
[6] [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone


==External Links==
==External Links==
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking] by Ward Cunningham and Kent Beck
* [http://books.google.com/books?id=SGOyQai2TboC&printsec=frontcover&dq=CRC+card+book&hl=en&ei=xSOaTKSaNISclgfRqtkK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDYQ6AEwAA#v=onepage&q&f=false The CRC card book] by David Bellin, Susan Suchman Simone
* [http://books.google.com/books?id=baopCOstm_kC&pg=PA29&lpg=PA29&dq=creating+software+for+CRC+cards&source=bl&ots=hABGQbbmXV&sig=CTHPtCN1GmZEyTAIPWvKE--8-M4&hl=en&ei=7ReaTISDKYL68Aadtq08&sa=X&oi=book_result&ct=result&resnum=9&ved=0CEsQ6AEwCDgK#v=onepage&q&f=false Using CRC Cards: An Informal Approach to Object-Oriented Development]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.agilemodeling.com/artifacts/crcModel.htm Modelling CRC Cards]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]
* [http://www.excelsoftware.com/quickcrcwin.html Quick CRC]
* [http://www.indicthreads.com/1439/quick-introduction-to-agile-software-development Quick Introduction to Agile Software Development]

Latest revision as of 02:41, 22 September 2012

Introduction

CRC Cards, also known as Class-Responsibility-Collaboration cards are a brainstorming tool to enable collaboration across different teams or individuals in contribution to design, usually used in Object Oriented Software development. This was proposed by Ward Cunningham and Kent Beck[1]. The CRC card can be viewed as an index card, with the following details:

CRC Card Structure
  • The Top of the card usually bears the name of the class.
  • The Left side of the card has the responsibilities of the class.
  • The Right side of the card has the collaborating classes corresponding to each of the responsibilities listed in the left side.

Thus in general, a CRC session can be viewed as the interaction between a set of collaborating classes for a particular Use case.

According to [2]A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects. By stepping through the process' weaknesses and problems are easily uncovered. Design alternatives can be explored quickly by simulating the design being proposed.

A CRC Example

To better understand how the CRC cards work together, let us consider a simple student enrollment problem,where we are required to model the students enrolled in different courses. We can easily define the Student CRC Card as having attributes such as student name, student id and responsibilities that enable a student to enroll in a course or drop the course. In this particular instance, the collaborating class would be the Course class. The Course CRC Card can in turn be visualized as having its own responsibilities, such as having attributes like Course id, course name and the collaborating class would be the Instructor class. The CRC cards for the Student class and the Course Class are shown below.

Student and Course CRC Card


There are also several practical designs that use the CRC card model to design Object oriented software design. The Simulator for Coffee Maker explores an Extreme Programming approach combined with CRC card technique to come up with a design for the coffee maker.

Another interesting approach using CRC cards is the design for the ATM Machine

Advantages of CRC cards

There are a few advantages of CRC cards that make it a preferable model in many designs. Some of the advantages of the CRC card design method are

  • CRC cards can allow designers to easily make audience understand a very complex system. In essence it allows for building more complex designs by slowly building the interactions between the collaborating classes, one by one.
  • CRC cards are a simple technique and it can be easily used by anyone with very little training and does not require any expensive computing resources(a board or a paper and a pen would suffice).
  • CRC is fundamentally a brainstorming tool, enabling different people in a team to come up with the design by collaborating, enabling everyone in the team to contribute
  • CRC can be used with other formal object oriented design methodologies such as Extreme Programming (an Agile development Technique) and can be used along with modeling languages such as Unified Modeling Language(UML)

Software for CRC Cards

CRC cards have limited scope. If we go about designing a huge project, the scope may span many classes and there might be numerous interactions between them. The tedious task here is to maintain the CRC cards and formulate appropriate interaction between them. We need software for CRC Cards for the following reasons:

  • Designing Scenario: A scenario represents a series of steps in which classes and objects communicate. There can be references to other scenarios.
  • Modeling : Software provides an easy way to segregate cards and objects into different diagrams. Thus we can model our problem with different functionality very easily.
  • Simulation : Software can provide simulation of the design. This might include single-stepping a scenario forward or backwards or jumping to a specific location in the scenario stack of a multiple scenario simulation.
  • Synchronization and Dependencies: Software can maintain relationships between cards and scenarios as design changes take place. If a card references other cards or classes, any changes in those cards are generated automatically. Also any name changes and cross references between objects are instantly updated.
  • Revision history and Version Control : Software for CRC cards supports changes to CRC cards. It is easy to model and keep track of all changes to a CRC card. This is extremely helpful in tracking design changes.

Designing Software

The steps to design software for CRC cards are:

  • Create CRC Cards : A CRC model is usually created by an individual (or small group of designers) during the early phase of an object-oriented development project. The figure shows the design of hierarchy of classes. The set of class used for drawing objects are shown. We can see TShape class has a superclass called TObject and two subclasses, TBox and TCircle. Let us assume we create new class TWindow derived from the superclass TObject.
    Description
  • Assign Responsibilities : Once a set of classes are defined, behaviors can be assigned that will provide the functions of the application. For example, the TShape card has responsibilities Initialize to create it and Draw to illustrate it on the diagram.
  • Add Attributes : Attributes of classes may also be identified in a CRC Card. The TShape class has attributes fPosition, fType and fSelected.
  • Define and simulate Scenario : A scenario describes a sequence of steps in the design using the responsibilities of a group of collaborating classes. Collaboration between classes refers to a client object that uses a responsibility performed by a server object. Often a class must call upon several collaborating classes to implement one of its responsibilities. A scenario describes what happens in the system from a high-level, user's point of view.
Description

Consider the situation to the right. We have defined two CRC cards with their responsibilities. A scenario defines several steps. Each step in a scenario has a Client, Server and Responsibility field. For each step, a client class uses a responsibility of a server class

The Open Document scenario in the picture references the Initialize Document sub-scenario by specifying its server class Document in the server field and its scenario name in the Responsibility field. The first step in the Initialize Document sub-scenario uses Document as the server class name. By single-stepping forward, backwards or through each sub-scenario, bugs in the design can be identified and corrected early.

  • Partition the Design : As the number of CRC cards in the design grow, they can be grouped by function. By using Software for CRC cards, we can draw separate diagrams to partition the model into different subject areas.
  • Inheritance Graph : An automated tool can generate an inheritance graph from information on CRC cards. This diagram can concisely illustrate the big picture of a large project that might contain hundreds of classes and dozens of diagrams.
  • Verify Your Work  : Creating and simulating scenarios will help verify that a design is correct and complete. A CRC software can perform other error checks to locate design problems. For example, responsibilities that are not used in any scenarios may indicate that the design is incomplete or perhaps the responsibility isn't needed. Likewise, a card that is not used by any collaboration may not be needed.

Software Development Process for Object Oriented Development[6]

Software Development Life Cycles are different for a standard development process and for Object Oriented development. This difference needs to be understood in order to know how to meet the benchmarks set for the project. There are multiple processes that are used in software development, the most common ones in use being Waterfall model and Spiral model. The Waterfall model is progression based and the Spiral model is iterative.

We need to understand that the uniqueness of Object Oriented SDLCs comes from the fact that it is more user centric as compared to standard SDLCs that are more system centric. We will now see which models work for Object Oriented SDLCs (OO SDLCs) and which don’t. CRC cards play a very important role in an Object Oriented SDLC. Thus, figuring out which models work well for OO SDLCs will result in understanding which models use CRC cards and why.

The Waterfall Model

The Waterfall model is implemented in multiple phases with each phase having a clear demarcation in terms of its functionality and deliverable. It uses clear stepping stones to come up with deliverables for each deadline. In this case, there are multiple ways to measure progress and methods by which to audit internally and apply checkpoints.

The downside of the Waterfall model lies in the fact that it is a very rigid model that does not offer much in terms of leeway when it comes to deliverables and what each phase in the cycle has to offer. The process is also overly mechanical and over time, just ends up being boring.

Owing to the emphasis on checkpoints and deliverables with strict deadlines, in most cases the analysis and design phases are usually cut short and thus, the project may veer very far from reality. The users are involved only in the requirement gathering phase. This might result in mistranslation of the requirements of the user into what may be an amazing final product but something that the user did not even ask for.

The Spiral Model

This model iteratively goes through the phases of analysis, design, prototyping and testing after the initial requirements gathering phase. With each iteration, the product is improved based on the feedback from testing in the previous iteration. If required, the outcome of each phase is analyzed, revised and the next prototype is developed after the design is revised, if pertinent. The products from the first phase are not abandoned, they are revised. Evidently, this model is non-linear in nature.

After the first pass through the checkpoint, we can conclude that the work so far is adequate, but not final. The model places emphasis on the iterative process and on the development of standard prototypes at the end of each iteration. At the end of every cycle, we notice the shortcomings from the previous cycle and might end up having to redo all the work in the previous cycle. This proves to be a complete waste of time and effort. All the effort now goes into developing the end point for an older cycle, which makes the model ineffective for the current cycle.

One of the major drawbacks of such a non linear model is that the cost effectiveness and risk analysis cannot be analyzed thoroughly.

Why CRC cards are not useful in Waterfall and Spiral Models

The strength of OO model depends on the idea that, here, design and deployment come together. In the case of a spiral model, this works to make the spiral tighter. Since the waterfall model places over importance on deliverables and user involvement is minimal, which is one of the key focuses of OO SLDCs using CRC cards, the model is considered ineffective. The Spiral model involves multiple revisions of the same idea. When a set of cards have been developed, it would make sense to refine the idea presented in the card but not to redefine them over and over, which may be the case. This does not serve the purpose of actually convening a CRC discussion among the team to draw up cards corresponding to the user requirement. Moreover, in the case of the Spiral model, we would need to convene multiple such meetings at each iteration, which would drastically bring down the overall productivity of the team.

CRC Cards in Software Development Process

Agile Methodology and CRC Cards

Agile development is a model that has resurfaced and is gaining fame for its incremental cum iterative process. The iteration is carried over the processes of discovery, analysis, design and coding. In each iteration, the old model is worked on in each of the overlapping mini-cycles. The overlap of the cycles makes the process apparently iterative in nature. The model is considered incremental since every step acts as a value-add and this is emphasized by the capacity of classes for reuse. The idea that each phase is repeated ensures that the project is constantly working on a higher level of understanding. Moreover, the OOPS concept of reuse can be used to our advantage such that when we are continuously using OO development models in all our projects, the next implementation can be started far ahead in the SDLC.

The model focuses on analysis and design phase predominantly. Within each of these are mini phases of analysis->prototype->revision-> implementation cycles. The advantage of this model compared to other models described is that, being incremental, this also results in tightening of the spiral at the end of each iteration using concepts such as reusability and polymorphism. Thus, the progression from one point to another in the cycle is seamless from start to deployment.

CRC cards can be very effectively and efficiently used in the Agile model of OO SDLC owing to the fact that it is incremental as well as iterative and not just a repetitive process. Thus, we would not have to redefine the cards from the scratch at any point. Being incremental, we would refine our current model and proceed to refine the entire system as a whole at the end of all iterations. We would essentially be adding value to the cards written out in the previous cycle and if perfected, would never have to discard cards from any of the precious cycles.

Agile also practices active customer involvement. In every phase, the user is involved. This is one of the key characteristics of the CRC card design method. This not only ensures that the final product is as per the customer's requirements, but also that the customer is thoroughly satisfied, since they are aware of the changes and increments at each level. Another key aspect of Agile methodology is that it is feature driven. A CRC card holds details as to the feature of each class and how it collaborates with the rest of the system. Since this information is readily available to the developer and is highly fine-tuned by the end of the SDLC process, the cards can guarantee focus on 80/20 principle (i.e. pay more attention to 20% of the features which will used 80% of the times).

The power of CRC cards for OOP development is in the group session that employs them. The use of CRC cards is an excellent way for people to begin to grasp the underlying idea of object oriented approach. CRC cards are used in a few steps of the software development process such as Analysis and Design.

CRC Cards for Analysis

CRC cards and CRC card sessions are good at organizing and spreading domain knowledge in the analysis phase. When building an object–oriented application, the focus of the CRC card sessions is on analyzing and describing the problem. In this phase, the group identifies the objects that are relevant to the application. Before going to the CRC card session, the team must be aware of the domain classes and frameworks that exist to help them model the problem. During the session, they can decide if the existing ones can be used for the new application.

Advantages of using CRC cards in Analysis phase:

  • People from all phases of the project are involved in the card sessions for problem modeling. The names of the classes and responsibilities are created, argued and agreed upon by the team members at the start itself in order to avoid conflicts later. This gives rise to common project and product vocabulary across different roles.
  • Domain knowledge already known is shared in the sessions. Also, missing domain knowledge is identified.
  • Role plays are conducted during these sessions that help spread knowledge about OO concepts.
  • These sessions can be used to create a live prototype of what the application is supposed to do. This can be shown to clients as well so that the team receives feedback on their understanding of the requirements.
  • A CRC card session will help the team walk through the requirements and identify any ambiguities.

At the end of the analysis phase, the CRC elements that will be available are:

  • Classes: The classes identified in this phase directly reflect the concepts of the application that is being analyzed. It may not be modeled in terms of software system but it is useful in describing how the application works. However, at this stage the distinction between objects and classes may not be clear.
  • Responsibilities: The responsibilities that are assigned to the classes in this phase are of relatively higher level.

CRC Cards for Design

During the CRC cards design sessions, other relevant classes are added, if any. "While an analysis must reflect the real world of the user, the design must reflect the real world of the implementers."[5] A CRC card tool may be helpful for saving, illustrating and documenting a design.

Advantages of using CRC cards in Design phase:

  • These sessions help the team members concentrate on taking the design decisions for the application. These design decisions also include performance, efficiency and other constraints.
  • By walking through the scenarios that were seen during the analysis phase, the implementers can give the testers an overview of how the application should work.
  • Using CRC cards forces decision to be made up front in front of the team, thus any conflicts can be resolved right there.
  • Design constraints such as target environment, language, UI, performance etc., can be discussed during these sessions to check if the design can be implemented.

Summary

Software for CRC cards are immensely helpful in designing and modeling software development using CRC cards.As the size of object-oriented system grow, it becomes increasingly difficult to model the problem with index based CRC cards. Thus an automated tool is required to maintain design and clear functionality.

See Also

References

[1] A Laboratory For Teaching Object-Oriented Thinking

[2] CRC Cards

[3] A Simulator for Coffee Maker

[4] CRC Card for ATM

[5] "Using CRC Cards: An Informal Approach to Object-Oriented Development" by Nancy M.Wilkinson

[6] The CRC card book by David Bellin, Susan Suchman Simone

External Links