CSC/ECE 517 Fall 2012/ch1 1w11 ap: Difference between revisions
No edit summary |
|||
Line 109: | Line 109: | ||
'''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. | ||
'''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. | |||
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== | ==Summary== |
Revision as of 01:04, 15 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:
- 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.
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 explores a design for the ATM Machine
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
- 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 modelling languages such as Unified Modeling Language(UML)
Why need a 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. Following reasons propel use for software for CRC Cards :
- Designing Scenario: A scenario represents series of steps in which classes and objects communicate. There are be references to other cards or scenarios.
- Modeling : Software provide an easy way to segregate cards and objects into different diagrams. Thus we can model our software with different functionality very easily.
- Simulation : 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
- Synchronization and Dependencies: 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.
- 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 cards. This is extremely helpful in realizing the design changes to CRC cards.
Designing Software
The following steps proceed while designing Software for CRC cards:
- 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. 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.
- 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 point of view.
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 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.
By single stepping forwards, backwards or through each subscenario, bugs in the design can be identified and corrected early.
- Partition the Design
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.
- 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.
CRC Cards in Software Development
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.
Analysis Phase:
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.
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.
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: http://c2.com/doc/oopsla89/paper.html
[2] CRC Cards: http://www.extremeprogramming.org/rules/crccards.html
[3] A Simulator for Coffee Maker
[4] CRC Card for ATM
External Links
- A Laboratory For Teaching Object-Oriented Thinking by Ward Cunningham and Kent Beck
- The CRC card book by David Bellin, Susan Suchman Simone