CRC Cards — Tutorial Jun Azene

CRC Cards - Tutorial Jun & Azene

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 objectoriented application – Know CASE tools for CRC cards – Know its strengths and limitations

OUTLINE • Introduction: OO 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

INTRODUCTION OO CONCEPTS AND VOCABULARY

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. …. ” Source: http: //catalog. com/softinfo/objects. html

OO Concepts and Vocabulary OO v/s Non-OO • Non-Object-Oriented (Traditional) Procedures – 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 Data Functions within an Object Procedures – Objects have behavior Source: Dr. Seaman’s Lecture Note Data

OO Concepts and Vocabulary(Cont. ) Phases of OO Systems Development Cycle Implementation System Design Analysis -application -what -system architecture -database access -programming -database access -data structure -algorithms -controls Object Design Source: Jeffrey(1999). Advanced System Analysis and Design

OO Concepts and Vocabulary (Cont. ) • • Objects: State, Behavior, Identity Object-Oriented Model Encapsulation Instantiation: Classes and Objects Inheritance: Classes, Super-classes, and Subclass Abstract Classes Polymorphism Framework and Patterns

THE CRC CARD OVERVIEW

WHAT’S 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.

WHAT’S 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.

WHAT’S 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 3 x 5 (4 x 6) inch index card

Sample CRC Card (Front & Back)

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. • 3 x 5 or 4 x 6 inch are the perfect size. But you can really use anything you want. …. Napkins? ? ? Denny’s? ? ? • Refreshment (Optional)

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.

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

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 group’s leader/facilitator

The CRC Card Team Source: The CRC Card Book by Bellin et. al (1997)

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.

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

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

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.

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.

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

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

Case Example: A small technical library system for an R&D organization • • • Requirement Statement The CRC Card Sessions Participants (Who? Why? ) Brainstorming (Scope) Creating Classes (the first step) – Brainstorming – Suggesting Classes (your suggestions) – Filtering

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

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)

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?

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?

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)

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?

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.

CRC Cards after the first scenario run

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

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 can’t 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)

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

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

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

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

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

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

Applying CRC cards for Design • Elements: CRC, Attributes, scenarios, subresponsibilities, 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

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

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)

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

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

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.

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

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 – Work on normal and exceptional (Error handling class) • When to start Prototyping?

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)

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

CASE tools for CRC Card • • An automated tool to support CRC cards Quick CRC from Excel Software From Spiral. Soft Rational & others Modeling Methods and CASE Tools. • Features www. excelsoftware. com http: //www. spiralsoft. com/Html/Download. CRC. html http: //mlwww. diee. unica. it/TABOO/OO-CASE-tools. html

Class Exercise Case: Simulation of AMT

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 -895420/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. John. Willey & Sons, Inc. , New York. Fowler, Martin. (1997). A survey of object oriented analysis and design methods. http: //ourworld. compuserve. com/homepages/Martin_Fowler/

Reference (Cont. ) A tool for designing Java programs with UML. Proceedings of the 4 th 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. 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/p 45 -artim/ CRC CARD CONSTRUCTOR. http: //www. engin. umd. umich. edu/CIS/tinytools/cis 375/f 00/crc. htm Techniques for Object Oriented Analysis and Design. http: //www. aw. com/cseng/titles/0 -201 -895420/techniques/index. htm Cockburn, A. (March 1999) Using CRC Cards [Online]. http: //members. aol. com/humansandt/techniques/crc. htm [03/29/2001]. Spiral. Soft Home Page. http: //www. spiralsoft. com/Html/Download. CRC. html Object-Oriented Design Using CRC Cards. http: //www. d. umn. edu/~gshute/ood/ Object-Oriented Analysis Phase www. cdt. luth. se/pvt/courses/smd 114/2000/lectures/Schach/ch 11/index. htm Modeling Methods and CASE Tools. http: //mlwww. diee. unica. it/TABOO/OO-CASE-tools. html