CSC/ECE 517 Fall 2012/ch1 1w11 ap

From Expertiza_Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch1_1w11_ap&oldid=65517"