CRC Cards - Tutorial

1. CRC Cards - Tutorial Jun & 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 •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

4. INTRODUCTION OO 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. … .” Source:http://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 Data Procedures Source: Dr. Seaman’s Lecture Note

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

8. 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

9. THE CRC CARD OVERVIEW

10. 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.

11. 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.

12. 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 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???Denny’s??? • 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 group’s leader/facilitator

18. The CRC Card Team Source:The 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 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

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 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)

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 

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?