User:Bluehat: Difference between revisions
(43 intermediate revisions by 2 users not shown) | |||
Line 8: | Line 8: | ||
==Definition== | ==Definition== | ||
Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other | Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.[1] | ||
A typical CRC | A typical CRC card layout is shown below. | ||
[[Image:Crccard2.jpg|frame|center|CRC CARD Template]] | [[Image:Crccard2.jpg|frame|center|CRC CARD Template]] | ||
Example: Consider a Student | Example: Consider a Student class where a student can enroll for a seminar. In this case ‘Student’ will be one class and ‘Seminar’ can be another class that collaborates with the Student class. | ||
[[Image:CrcStudent.jpg|frame|center|Student CRC Card ]] | [[Image:CrcStudent.jpg|frame|center|Student CRC Card ]] | ||
To know more about CRC cards please refer to http://www.hsanchez.net/repository/hsanchez-PLCRC-plop04.pdf | |||
==Principle and Process== | ==Principle and Process== | ||
Line 32: | Line 32: | ||
*Responsibilities: | *Responsibilities: | ||
**Appears on the left hand side of the CRC card | **Appears on the left hand side of the CRC card | ||
**It is a list of the responsibilities of the class | **It is a list of the responsibilities of the class i.e. things a class can do with its knowledge | ||
* | *Collaborators: | ||
** | **Appear on the right hand side of the CRC card | ||
** | **They are other classes that the class works with to get information or perform a certain function | ||
===CRC Process=== | ===CRC Process=== | ||
CRC modeling process includes the users, analysts | CRC modeling process includes the users, analysts and developers bringing together the entire development team to form a common understanding of an OO development project.For e.g consider a software application to implement a game of blackjack. To implement the CRC technique to design this software, following steps are taken: | ||
*Explanation of the CRC Technique | *Explanation of the CRC Technique | ||
**The facilitator explains the purpose of the CRC modeling session | **The facilitator explains the purpose of the CRC modeling session | ||
**It can include explanation of CRC Cards and creation of sample CRC Cards | **It can include explanation of CRC Cards and creation of sample CRC Cards | ||
*Brainstorming | *Brainstorming | ||
**A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved. | **A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved. | ||
**Every team member can contribute with innovative ideas | **Every team member can contribute with innovative ideas | ||
**A list of candidate classes can be drawn up from this activity | **A list of candidate classes can be drawn up from this activity | ||
For e.g considering the above example, we can identify candidate classes by listing down the nouns relating to the game of blackjack. Say, game, blackjack, dealer, players, card, deck, hand, bet, king, queen, jack, ace, suit, winner, game. | |||
*Selecting a scenario and Core classes | *Selecting a scenario and Core classes | ||
**The scenario chosen at the beginning of the session should be simple, clear and well documented | **The scenario chosen at the beginning of the session should be simple, clear and well documented | ||
**Related scenarios should be identified and dealt with separately | **Related scenarios should be identified and dealt with separately | ||
Line 61: | Line 62: | ||
**This helps to eliminate irrelevant classes and review remaining classes | **This helps to eliminate irrelevant classes and review remaining classes | ||
**This also helps clarify the system scope | **This also helps clarify the system scope | ||
For e.g we can apply the elimination process to the candidate class list. We can eliminate blackjack as it is the name of the system. ‘House’ can be eliminated as it is another name for the dealer. Also, instead of making ace, king, queen and jack as separate classes, we can represent them as attributes of individual classes. | |||
*Create initial CRC cards | *Create initial CRC cards | ||
From the information gathered in the step above, CRC cards are written | |||
[[Image:Deck1.jpg |frame|center|Deck CRC Card]] | |||
[[Image:Dealer.jpg |frame|center|Dealer CRC Card]] | |||
[[Image:Player.jpg |frame|center|Player CRC Card]] | |||
*Creating a CRC Model | *Creating a CRC Model | ||
**After the CRC cards are written, they are placed appropriately, with collaborating classes closer to each other. | |||
** | |||
**Accordingly, place each card in position till the entire picture of the system is finalized. | **Accordingly, place each card in position till the entire picture of the system is finalized. | ||
**This process may have to be done in several iterations to get a refined view of the system to be modeled | **This process may have to be done in several iterations to get a refined view of the system to be modeled. | ||
For more information on using CRC Cards please refer to http://alistair.cockburn.us/Using+CRC+cards | |||
== | ==CRC Team== | ||
*Domain Experts: | *Domain Experts: | ||
Line 93: | Line 102: | ||
**Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process. | **Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process. | ||
**This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage | **This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage | ||
**Usually are 1-2 people | |||
==Case study== | |||
To understand the working of CRC card modeling better, here is an example of an ATM system designed using CRC cards. Here, the software system under consideration has to control an automated teller machine. The ATM has a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. Also, the ATM will communicate with the bank's computer over an appropriate communication link. | |||
To perform a transaction, a customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that there are no further transactions, at which point it will be returned. For more on the case study. | |||
http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html | http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html | ||
==Metrics for CRC Analysis== | ==Metrics for CRC Analysis== | ||
Line 114: | Line 124: | ||
===Maximum depth of inheritance=== | ===Maximum depth of inheritance=== | ||
This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. 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. | This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.[6] From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. 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 collaborators=== | ===Number of collaborators=== | ||
This is the count of all the supporting classes to help a class.In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly. | This is the count of all the supporting classes to help a class.[6] In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly. | ||
===Number of responsibilities=== | ===Number of responsibilities=== | ||
This is the count of clearly defined set of duties to each class.For example class Student may have functions like Attending Lectures, | This is the count of clearly defined set of duties to each class.[6] For example class Student may have functions like Attending Lectures, | ||
Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid 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. | Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid 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. | ||
Line 158: | Line 166: | ||
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,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.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 users 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: | 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,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.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 users 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/ | http://www.math.gordon.edu/courses/cs211/ATMExample/ [3] | ||
==Summary== | ==Summary== | ||
CRC cards are very useful to form the base of object oriented methodology.Techniques such as brain storming and role play enhance the understanding of requirements.CRC automation makes card handling and sharing quick and efficient.For large projects more formal technology such as UML is required but CRC cards can provide a very good starting point. | |||
==Reference== | |||
[1]Rubin,D.M, Introduction to CRC Cards, Methodologies and Practices.Revised January 1998,SOFTSTAR RESEARCH,INC: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf | |||
[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html | |||
[3]Bjork,R.C, ATMExample, Object-Oriented Software Development.Retrieved September 5,2010,from Computer Science Department, Gordon College: http://www.math.gordon.edu/courses/cs211/ATMExample/ | |||
[4]quickCRC:http://www.excelsoftware.com/ | |||
[5]Visual Paradigm: http://www.visual-paradigm.com/ | |||
[6]Bellin, D and Simone, S.S ‘The CRC Card Book’, Addison Wesley, 1997 |
Latest revision as of 17:55, 8 September 2010
Introduction
The onset of the object oriented paradigm in the software industry brought about a big change in the basic approach to system design and the software development life cycle.The major task in the development of any application using the object oriented paradigm is to identify ‘classes’, and how these classes interact and collaborate with each other in the system scope.
Whenever a system is designed with classes, each class has a specific role to play in the system.It has certain responsibilities and each class collaborates with other classes to provide the complete system functionality. In such a scenario, identifying classes becomes the key to a good system design.Although it seems to be a simple,intuitive process,identifying classes can be quite complex when it comes to large scale systems.
One such technique for identification of classes that make up the system and its collaborations is the ‘CRC Card’ technique. The concept of CRC cards was first put forth by Kent Beck and Ward Cunningham and it became very popular as it is easy to use and it supports development of any kind of object oriented development regardless of its scale,the method used, the technology or the language used for development
Definition
Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.[1] A typical CRC card layout is shown below.
Example: Consider a Student class where a student can enroll for a seminar. In this case ‘Student’ will be one class and ‘Seminar’ can be another class that collaborates with the Student class.
To know more about CRC cards please refer to http://www.hsanchez.net/repository/hsanchez-PLCRC-plop04.pdf
Principle and Process
CRC Principle
A CRC model includes a collection of cards and each card is divided into three sections.
- Class Name:
- Appears on the top of the CRC card
- Class denotes a set of similar objects that are being modeled in the system
- Responsibilities:
- Appears on the left hand side of the CRC card
- It is a list of the responsibilities of the class i.e. things a class can do with its knowledge
- Collaborators:
- Appear on the right hand side of the CRC card
- They are other classes that the class works with to get information or perform a certain function
CRC Process
CRC modeling process includes the users, analysts and developers bringing together the entire development team to form a common understanding of an OO development project.For e.g consider a software application to implement a game of blackjack. To implement the CRC technique to design this software, following steps are taken:
- Explanation of the CRC Technique
- The facilitator explains the purpose of the CRC modeling session
- It can include explanation of CRC Cards and creation of sample CRC Cards
- Brainstorming
- A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved.
- Every team member can contribute with innovative ideas
- A list of candidate classes can be drawn up from this activity
For e.g considering the above example, we can identify candidate classes by listing down the nouns relating to the game of blackjack. Say, game, blackjack, dealer, players, card, deck, hand, bet, king, queen, jack, ace, suit, winner, game.
- Selecting a scenario and Core classes
- The scenario chosen at the beginning of the session should be simple, clear and well documented
- Related scenarios should be identified and dealt with separately
- Identification of critical classes from the candidate class list is also very important
- This helps to eliminate irrelevant classes and review remaining classes
- This also helps clarify the system scope
For e.g we can apply the elimination process to the candidate class list. We can eliminate blackjack as it is the name of the system. ‘House’ can be eliminated as it is another name for the dealer. Also, instead of making ace, king, queen and jack as separate classes, we can represent them as attributes of individual classes.
- Create initial CRC cards
From the information gathered in the step above, CRC cards are written
- Creating a CRC Model
- After the CRC cards are written, they are placed appropriately, with collaborating classes closer to each other.
- Accordingly, place each card in position till the entire picture of the system is finalized.
- This process may have to be done in several iterations to get a refined view of the system to be modeled.
For more information on using CRC Cards please refer to http://alistair.cockburn.us/Using+CRC+cards
CRC Team
- Domain Experts:
- Core team that writes the cards
- Have good business domain knowledge for which the system is being designed
- Usually are 3-5 people
- Object Oriented Design Analyst:
- Analysts and developers those are familiar with object oriented design methodologies
- Usually are 1-2 people
- Facilitator:
- Most important member who conducts the CRC modeling session
- Acts as an intermediary when there is difference of opinion regarding class responsibilities and paths of collaboration
- Usually a single person
- Scribe:
- Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process.
- This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage
- Usually are 1-2 people
Case study
To understand the working of CRC card modeling better, here is an example of an ATM system designed using CRC cards. Here, the software system under consideration has to control an automated teller machine. The ATM has a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. Also, the ATM will communicate with the bank's computer over an appropriate communication link.
To perform a transaction, a customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that there are no further transactions, at which point it will be returned. For more on the case study.
http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html
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.These metrics can be calculated easily and quickly without the need of special tools. 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. With the example below an attempt has been made to explain these metrics.In the diagram, black line indicates inheritance while blue line indicates collaboration.
Maximum depth of inheritance
This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.[6] From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. 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 collaborators
This is the count of all the supporting classes to help a class.[6] In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.
Number of responsibilities
This is the count of clearly defined set of duties to each class.[6] For example class Student may have functions like Attending Lectures, Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid 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.
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:
- quickCRC:http://www.excelsoftware.com/
- CRC card support is part of Visual Paradigm for UML: http://www.visual-paradigm.com/
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,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.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 users 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/ [3]
Summary
CRC cards are very useful to form the base of object oriented methodology.Techniques such as brain storming and role play enhance the understanding of requirements.CRC automation makes card handling and sharing quick and efficient.For large projects more formal technology such as UML is required but CRC cards can provide a very good starting point.
Reference
[1]Rubin,D.M, Introduction to CRC Cards, Methodologies and Practices.Revised January 1998,SOFTSTAR RESEARCH,INC: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf
[2]Bjork,R.C, CRC cards for ATM, Object-Oriented Software Development.Retrieved September 6,2010,from Computer Science Department, Gordon College:: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html
[3]Bjork,R.C, ATMExample, Object-Oriented Software Development.Retrieved September 5,2010,from Computer Science Department, Gordon College: http://www.math.gordon.edu/courses/cs211/ATMExample/
[4]quickCRC:http://www.excelsoftware.com/
[5]Visual Paradigm: http://www.visual-paradigm.com/
[6]Bellin, D and Simone, S.S ‘The CRC Card Book’, Addison Wesley, 1997