CRC Cards - Tutorial Jun

1
CRC Cards - TutorialJun Azene
2
OBJECTIVES

• After completing this tutorial, you shall be able
  to
• Know what CRC card is and its history
• Know a CRC card session and run
• Use CRC for analysis and design of a real
  object-oriented application
• Know CASE tools for CRC cards
• Know its strengths and limitations

3
OUTLINE

• IntroductionOO Concepts and Vocabulary
• CRC Overview
• CRC Cards for Analysis
• CRC Cards for Design
• Documenting a CRC Card Design
• CASE Tools for CRC Card Design
• Exercise ATM Simulation using CRC
• Discussions on the results of the exercise

4
INTRODUCTIONOO CONCEPTS AND VOCABULARY
5
INTRODUCTION
Object-oriented programming offers a new and
powerful model for writing computer software.
This approach speeds the development of new
programs, and, if properly used, improves the
maintenance, reusability, and modifiability of
software. O-O programming requires a major shift
in thinking by programmers, however. The C
language offers an easier transition via C, but
it still requires an O-O design approach in order
to make proper use of this technology. .
Sourcehttp//catalog.com/softinfo/objects.html
6
OO Concepts and Vocabulary

• OO v/s Non-OO
• Non-Object-Oriented (Traditional)
• Data and Procedures are kept Separate
• Procedures work on Data to produce results
• Object-oriented
• Focus on Responsibilities - to be satisfied by
  Objects
• Responsibilities translate into Data and
  Functions within an Object
• Objects have behavior

Procedures
Data
Procedures
Data
Source Dr. Seamans Lecture Note
7
OO Concepts and Vocabulary(Cont.) Phases of OO
Systems Development Cycle

• Implementation
• programming
• database access

• System Design
• system architecture
• database access
• data structure
• algorithms
• controls
• Object Design

• Analysis
• application
• what

Source Jeffrey(1999). Advanced System Analysis
and Design
8
OO Concepts and Vocabulary (Cont.)

• ObjectsState,Behavior,Identity
• Object-Oriented Model
• Encapsulation
• InstantiationClasses and Objects
• InheritanceClasses,Super-classes,and Subclass
• Abstract Classes
• Polymorphism
• Framework and Patterns

9
THE CRC CARDOVERVIEW
10
WHATS CRC Card?

• CRC stands for Class,Responsibility,and
  Collaboration.
• Class
• A set of objects that share common structure and
  common behavior
• Super-class a class from which another class
  inherits
• Subclass a class that inherits from one or more
  classes
• Responsibility
• Some behavior for which an object is held
  accountable.
• Collaboration
• process whereby several objects cooperate to
  provide some higher-level behavior.

11
WHATS CRC CARD? (Cont.)

• An index card that is annotated in a group
  setting to represent a class of objects,its
  behavior,and its interactions.
• An informal approach to OO modeling
• Created through scenarios,based on the system
  requirements,that model the behavior of the
  system.

12
WHATS CRC MODELING

• CRC Modeling is used
• to develop an OO system more easily 
• to teach people about objects and their
  relationships without teaching them an entire
  programming language (or even mention
  programming)
• CRC is implemented using the requirements given
  to a team
• Each class is written down on a 3x5 (4x6) inch
  index card

13
Sample CRC Card (Front Back)
14
REQUIREMENTS

• Cards should be physical cards, not virtual
  cards.
• CASE tools for support of CRC cards are
  useful,but cannot replace the interaction that
  physical cards facilitate.
• 3x5 or 4x6 inch are the perfect size. But you can
  really use anything you want. .Napkins???Dennys?
  ??
• Refreshment (Optional)

15
HISTORY

• Introduced at OOPSLA in 1989 by Kent Beck and
  Ward Cunningham as an approach for teaching
  object-oriented design.
• In 1995,CRC cards are used extensively in
  teaching and exploring early design ideas.
• CRC cards have become increasingly popular in
  recent years. As formal methods proliferate, CRC
  cards have become, for some projects,the simple
  low-risk alternative for doing object-oriented
  development.

16
THE CRC CARD SESSION

• The session includes a physical simulation of the
  system and execution of scenarios.
• Principles of successful session
• All ideas are potential good ideas
• Flexibility
• Group Dynamic

17
BEFORE THE SESSION

• Forming the Group
• The ideal size for the CRC card team
• 5 or 6 people
• The team should be composed of
• One or two domain experts
• two analysts
• an experienced OO designer
• one groups leader/facilitator

18
The CRC Card Team
SourceThe CRC Card Book by Bellin et.al (1997)
19
DURING THE SESSION

• All the group members are responsible for
  holding,moving and annotating one or more cards
  as message fly around the system.
• Group members create,supplement,stack,and wave
  cards during the walk-through of scenarios.
• A session scriber writes the scenarios.

20
PROCESS

• 1.Brainstorming (Productive thinking)
• One useful tool is to find all of the nouns and
  verbs in the problem statement.
• 2. Classes Identification
• The list of classes will grow and then shrink as
  the group filters out the good ones.
• 3. Scenario execution(Role play)
• The heart of the CRC card session

21
STRENGTHS

• The cards and the exercise are non-threatening
  informal
• Provide a good environment for working and
  learning.
• Inexpensive,portable,flexible,and readily
  available
• Allow the participants to experience first hand
  how the system will work
• Useful tool for teaching people the
  object-oriented paradigm

22
LIMITATIONS

• Provide only limited help in the aspects of
  design.
• Do not have enough notational power to document
  all the necessary components of a system.
• Do not specify implementation specifics.
• Can not provide view of the states through which
  objects transition during their life cycle.

23
CRC GOOD PRACTICE

• Start with the simplest scenarios.
• Take the time to select meaningful class names.
• Take the time to write a description of the
  class.
• If in doubt,act it out!
• Layout the cards on the table to get an intuitive
  feel for system structure.
• Be prepared to be flexible.

24
CRC CARDS FOR ANALYSIS

• Overview
• Analysis techniques to OO development focus on
  discovering
• problem and application domains objects and
  classes
• relationships that exist between these objects
  classes
• way that objects undergo state changes and/or
  interact with each other over time

25
CRC for Analysis

• CRC Elements in Analysis
• classes, scenarios, responsibilities
  collaborators
• Use the CRC Card sessions to elicit analysis
  classes, responsibilities and collaborations
• Analysis classes
• are classes those describe what the system does
• reflect concepts and entities that are part of
  the domain of being modeled
• objects of these classes collaborate to describe
  what the application does
• To create an OO model of an application

26
Case Example A small technical library system
for an RD organization

• Requirement Statement
• The CRC Card Sessions
• Participants (Who? Why?)
• Brainstorming (Scope)
• Creating Classes (the first step)
• Brainstorming
• Suggesting Classes (your suggestions)
• Filtering

27
Case example Finding Classes

• Suggested Classes
• Library, Librarian, User, Borrower, Article,
  Material, Item, Due Date, Fine, Lendable, Book,
  Video, and Journal
• Classes after filtering
• Librarian, Lendable, Book, Video, Journal, Date,
  Borrower and User
• Assigning Cards
• A CRC Card per Class, put name description of
  the class

28
Scenarios execution

• Scenarios executions/Role Plays (For what?)
• Filter test identified classes
• Identify additional classes
• Identify Responsibilities and collaborators
• can be derived from the requirements/use cases
• responsibilities that are "obvious" from the
  name of the class (Cautious, avoid extraneous
  responsibilities)
• Filtering and testing R C
• Attributes
• (Only important ones are noted)

29
Finding Responsibilities

• Are things that the class has knowledge about
  itself, or things that the class can do with the
  knowledge it has
• Tips/Indicators
• Verb extractions in the problem or use case
• Ask what the class knows? What/how the class does
  ?
• Ask what information must be stored about the
  class to make it unique?

30
Finding Collaborators

• A class ask another class when
• needs information that it does not have or
• needs to modify information that it does not have
• Client (Requester for services) - Server
  (Services Provider) relationship
• Tips/Indicators
• Ask what the class does not knows and need to
  know? And who can provide that?

31
Case example Scenarios Execution(cont.)

• Identify Scenarios (By domain experts)
• Main Categories check-out, return and search
• CHECK-OUT SCENARIO
• Who should have the overall responsibilities for
  the task/check out? Librarian.
• What does the task/checking out a book entails?
• Refer to the Script to follow the process (handed
  to students)

32
Case example Scenarios Execution(cont.)

• Major Questions
• Shouldn't there be collaborations in the opposite
  direction?
• Collaborations in CRC cards are one-way
  relationships from the client to the server (OO)
• Who should do the checking out of the Book?
  Librarian or Book itself? (Controversial)
• Who should tell Borrower to update its knowledge
  about outstanding Book? Librarian or Book?

33
Case example Scenarios Execution(cont.)

• Do we need a collaboration between Book and
  Borrower for the know set of books
  responsibility?
• Collaborations are not usually needed for
  responsibilities that simply hold information.
  Instead, Collaboration is needed only for
  situations where an object actually sends a
  message to a Collaborator.
• Borrower does not need Book's help to put a Book
  in a set.

34
CRC Cards after the first scenario run
35
Case example Scenarios Execution(cont.)

• Remarks
• Domain experts have a lot contribution
• The first scenario takes the longest to
  walk-through and set the framework
• Related scenarios
• Superclass discovery
• Return scenarios
• Exceptional scenarios

36
Case example Scenarios Execution(cont.)

• Search Scenario
• "What happens when Ned comes to Library in search
  of a book entitled The Mythical Mammoth?"
• Discovery of new class Collection class (Why?)
• Book cant look for itself, identity of the book
  is not know
• Collection looks over a set Books to find the
  correct
• Attributes for searching (can be done at Design
  stage)
• When to end scenario execution?
• Get a stable model (does not cause new C or R to
  be added)

37
Grouping Cards

• CRC cards on the table provides a visual
  representation of the emerging model
• Classes with hierarchical (is-a relationship)
• Class who collaborate heavily placed closer
• Class included by other class (has-a
  relationship) e.g. Date in Lendable
• Card clustering based on heavy usage or
  collaborations can provide visual clues to
  subsystems

38
Deliverables

• Documenting a CRC Card Analysis
• Complete list of Library Application CRC Cards
• List of scenarios recorded as suggested and
  executed
• Collaboration Diagram
• Application Problem Model

39
Strength Limitation for Analysis

• Common Project Vocabulary
• Spreading Domain Knowledge
• Making the Paradigm Shift (Role play)
• Every participant is an object, everything
  happens does so because an object makes it
  happen (Wilkinson 1995)
• Live Prototyping
• to show what the system suppose to do to
  customers, new member, testers, developers, etc.
• Identify Holes in the Requirements
• Limitation

40
CRC CARDS for DESGIN

• Goal of CRC card design process
• Expansion and refinement of the Analysis CRC
• At level where implementation will be fairly
  clear
• Analysis Classes - describe what the system does.
  Design Classes - describe how the system works.
• 1..N Analysis Classes
• CRC Card design sessions Additional classes and
  mechanisms are built upon the existing analysis
  classes
• 0..N Design Classes

41
Design

• Design classes
• are classes those describe how the system does
• reflect concepts used by designers and
  programmers to describe their implementation
  techniques
• include classes that contain the data structures
  and operations used to implement the analysis as
  well as classes representing the user interfaces,
  DBMS, error handlers, etc.
• objects of these classes collaborate to describe
  how the application goals will be accomplished

42
Design

• Design Constraints
• Target Environment and Language
• Choice of Supporting Software Components GUI and
  DBM systems general and special purpose
  libraries and frameworks
• Class Libraries
• Performance Requirements response-time/ speed,
  expected availability, load in terms of number of
  users
• Errors/Exceptional Handling
• Other Security, Memory, etc. constraints

43
Applying CRC cards for Design

• Elements CRC, Attributes, scenarios,
  sub-responsibilities, Lifetime of objects
• Classes
• Additions that represent mechanisms that support
  implementation of the problem e.g. Search class
• Classes contain the data structures and
  operations used to implement the analysis classes
  e.g. Array, List
• Interface classes for UI and DBM subsystems
• Classes to handle error conditions

44
Applying CRC cards for Design

• Scenarios, Responsibilities Collaborators
• take the implementers point of view in
  fulfilling these scenarios, i.e., detailing all
  system functions (responsibilities), including
  those that provide support functions
  (collaborators)
• Sub-responsibilities to be added
• Collaborating sub-responsibilities to be added
• Message Data Passed (can be differed until the
  low-level design)
• The Process
• Problem-modeling scenarios are repeated along
  with additional new scenarios as needed
• High-level responsibilities collaborators are
  used, and detailed and expanded

45
Applying CRC cards for Design

• The distinction between objects and classes
  becomes more important, and the following
  questions, are answered will be an important part
  of its design.
• Who creates this object?
• What happens when it is created and adopted?
• What is the lifetime of the object vs. the life
  time of the information (persistence) held by an
  object?
• Attributes
• Discovery of attributes that are necessary to
  support the task during examination of each
  responsibility
• What attributes of objects need to be saved
  persistently
• Leads to a database design (database model)

46
Case Library Application Design

• Group Who and why?
• The two designers (Cecilia and Jim), OO expert
  (Nancy) as a facilitator, Betty (a domain
  expert/user)
• Input CRC cards, Scenarios, diagrams, etc. from
  Analysis stage Design Constraints
• The Session/Process
• Brainstorming
• Add sub-responsibilities while revising the
  analysis classes
• Add data/object that is passed with the message
  being sent (can be differed at the end of the
  design stage as it takes the design to low level)
• Figure 5.3. pp. 116

47
Case Library Application Design

• Brainstorming any classes that comes to mind
  based on design constraints such as
• User Interface, Database access, Mechanisms for
  implementation of analysis classes, error
  handlings
• User Interact class DB interface Classes
• Scenarios identification and executions
• Object creation scenarios
• Check-out Scenario
• Return Scenario
• Search Scenario
• Output Design classes

48
Case Library Application Design

• Classes that serves as interfaces to other
  subsystems (UI and DBMS)
• Principles
• make independent of specific hardware and
  software products
• use specific class names instead of generic names
  such as GUI and DBMS
• User interface to get input from and display to
  user using GUI software classes
• UI manager, User Interacter classes are
  suggested.

49
Case Library Application Design

• Database To obtain and store Borrower objects
  and objects of the Lendable classes using DBMS
  software
• Scenario Executions (Scripts given)
• Creation Scenarios (System start-up)
• Check-out scenario
• Others

50
Case Library Application Design

• some important issues during Scenarios execution
• How to verify the ID? Who? Librarian? A new
  class?
• How the Lendables set are stored and manipulated?
  Data Structure issues? List is chosen
• Scenarios, Scenarios, Scenarios
• Work on normal and exceptional (Error handling
  class)
• When to start Prototyping?

51
Deliverables

• Documenting a CRC Card Design
• List of design classes (pp. 130-2)
• Class models Hierarchies and collaboration
  graphs (pp. 142-3)
• Scenario Descriptions (pp. 145-7)

52
Strength Limitation for Design

• Common project vocabulary
• Spread of domain knowledge
• Spreading OO design expertise
• Design Reviews
• Frame for implementation
• Informal notation
• Designing is not the act of drawing a diagram
  (Booch)
• Limitations

53
CASE tools for CRC Card

• An automated tool to support CRC cards
• Quick CRC from Excel Software www.excelsoftware.co
  m
• From SpiralSoft http//www.spiralsoft.com/Html/D
  ownloadCRC.html
• Rational others Modeling Methods and CASE
  Tools. http//mlwww.diee.unica.it/TABOO/OO-CASE-t
  ools.html
• Features

54
Class Exercise

• Case Simulation of AMT

55
References

• Wilkinson, N. C. (1995). Using CRC cards An
  informal approach to object-oriented development.
  SIGS Book, USA
• Bellin, D. and Simone, S. S. 1997. The CRC Card
  Book. Addison Wesley Longman, Inc. USA.
• Beck, Kent, and Ward Cunningham. " A Laboratory
  for Teaching Object-Oriented Thinking." OOPSLA-89
  Proceedings, SIGPLAN Notices 24 (10) 1-6
  (October 1989). URL http//www.
• Jeffrey, H. and et al. (1999). Modern systems
  analysis and design. Reading, Mass
  Addison-Wesely.
• Bjork, R. C. 2000. ATM Simulation Links - by
  Topic. http//www.cs.gordonc.edu/local/courses/cs
  211/ATMExample/index.htm
• Techniques for Object Oriented Analysis and
  Design. http//www.aw.com/cseng/titles/0-201-89542
  -0/techniques/index.htm
• Object-Oriented Design Using CRC Cards.
  http//www.d.umn.edu/gshute/ood/
• Malan, R., et al. (1995). Lessons from the
  Experiences of Leading-Edge Object Technology
  Projects in Hewlett-Packard. OOPSLA'95 Conference
  Proceedings, Austin, Texas.
• Hutt, A.(1994). Object Analysis and Design
  Description of Methods. JohnWilley Sons, Inc.,
  New York.
• Fowler, Martin. (1997). A survey of object
  oriented analysis and design methods.
  http//ourworld.compuserve.com/homepages/Martin_Fo
  wler/

56
Reference (Cont.)

• A tool for designing Java programs with UML .
  Proceedings of the 4th annual SIGCSE/SIGCUE on
  Innovation and technology in computer science
  education, June 27 - 30, 1999, Krakow Poland
  www.acm.org/pubs/articles/proceedings/cse/305786/p
  180-armentrout/p180-armentrout.pdf
• Object-oriented practice in 1998 (panel) does
  it help or hinder collaboration? Pages 45-47.
  http//www.acm.org/pubs/articles/proceedings/oops/
  286936/p45-artim/
• CRC CARD CONSTRUCTOR. http//www.engin.umd.umich.e
  du/CIS/tinytools/cis375/f00/crc/crc.htm
• Techniques for Object Oriented Analysis and
  Design. http//www.aw.com/cseng/titles/0-201-89542
  -0/techniques/index.htm
• Cockburn, A. (March 1999) Using CRC Cards
  Online. http//members.aol.com/humansandt/techni
  ques/crc.htm 03/29/2001.
• SpiralSoft Home Page. http//www.spiralsoft.com/H
  tml/DownloadCRC.html
• Object-Oriented Design Using CRC Cards.
  http//www.d.umn.edu/gshute/ood/
• Object-Oriented Analysis Phase www.cdt.luth.se/pvt
  /courses/smd114/2000/lectures/Schach/ch11/index.ht
  m
• Modeling Methods and CASE Tools.
  http//mlwww.diee.unica.it/TABOO/OO-CASE-tools.htm
  l