CRC Cards - Tutorial Jun & Azene

Slides:



Advertisements
Similar presentations
Object-Oriented Software Engineering Visual OO Analysis and Design
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
UML an overview.
Database Systems: Design, Implementation, and Management Tenth Edition
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Lecture # 2 : Process Models
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Requirements and Design
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Introduction To System Analysis and Design
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Lecture 4 Class Responsibility Collaboration Cards
Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
Chapter 1 Software Engineering. Homework ► Read Section 2.2 (pages 79-98) ► Answer questions: ► 7, 8, 11, 12, & 13 on page 134. ► Answer on paper, hand.
Methodology Conceptual Database Design
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
1 INTRODUCTION TO OOP Objective: Know the difference between functional programming and OOP Know basic terminology in OOP Know the importance of OOP Know.
UML and Object Oriented Concepts
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
The chapter will address the following questions:
Introduction To System Analysis and design
OO Analysis and Design CMPS OOA/OOD Cursory explanation of OOP emphasizes ▫ Syntax  classes, inheritance, message passing, virtual, static Most.
Object-oriented Design CSCI 5801: Software Engineering.
Lesson 7 Guide for Software Design Description (SDD)
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
OHTO -99 SOFTWARE ENGINEERING LECTURE 5 Today: - An overview to OO Analysis and OO Design - Introduction of Assignment 2.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Introduction To System Analysis and Design
11 Partnership for Performance How to hear this lecture Click on the icon: to hear the narration for each slide.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
CS Overview of CRC CS 4311 B. Beck and W. Cunningham, A Laboratory for Teaching Object-Oriented Thinking, OOPSLA ’89, October 1-6, R. Wirfs-Brock,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
1 What is OO Design? OO Design is a process of invention, where developers create the abstractions necessary to meet the system’s requirements OO Design.
Liang, Introduction to Java Programming, Eighth Edition, (c) 2011 Pearson Education, Inc. All rights reserved COS240 O-O Languages AUBG,
CIS 112 Exam Review. Exam Content 100 questions valued at 1 point each 100 questions valued at 1 point each 100 points total 100 points total 10 each.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Chapter 17 – Object- Oriented Design. Chapter Goals To learn about the software life cycle To learn about the software life cycle To learn how to discover.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
McGraw-Hill/Irwin© 2008 The McGraw-Hill Companies, All Rights Reserved Chapter 17 Object-Oriented Design and Modeling Using the UML.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
OBJECT-ORIENTED TESTING. TESTING OOA AND OOD MODELS Analysis and design models cannot be tested in the conventional sense. However, formal technical reviews.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Adapted from (Zenebe & Miao, 2001) CRC Cards A tool and method for systems analysis and design Part of the OO development paradigm Highly interactive and.
An informal, team oriented, OO design system
Algorithms and Problem Solving
DATA REQIREMENT ANALYSIS
Object-Oriented Analysis and Design
Week 10: Object Modeling (1)Use Case Model
Reference: COS240 Syllabus
Chapter 20 Object-Oriented Analysis and Design
Analysis models and design models
Copyright 2007 Oxford Consulting, Ltd
Algorithms and Problem Solving
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Presentation transcript:

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 object-oriented 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) 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 SIMILARITIES AND DIFFERENCES Procedures Data Source: Dr. Seaman’s Lecture Note

OO Concepts and Vocabulary(Cont 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

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 3x5 (4x6) 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. 3x5 or 4x6 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 Principles (Similar to the JAD Session)

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 Roles of the participants and the rule of the game

The CRC Card Team Source:The CRC Card Book by Bellin et.al (1997) Forewords by Kent Beck & Ward Cunningham 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 With CRC cards,a group of people throw together their ideas about what a system should do,compare them,and synthesize them into a set of classes recorded on CRC cards. HOW? 3. mean? Where to Start? When to stop? What to Identify? What Scenario is?What Role Plays

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.

Analysis techniques to OO development focus on discovering: 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: Analysis classes: 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 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, 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

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, 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 www.excelsoftware.com From SpiralSoft http://www.spiralsoft.com/Html/DownloadCRC.html Rational & others Modeling Methods and CASE Tools. http://mlwww.diee.unica.it/TABOO/OO-CASE-tools.html Features

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/cs211/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_Fowler/

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/p180-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.edu/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/techniques/crc.htm [03/29/2001]. SpiralSoft Home Page. http://www.spiralsoft.com/Html/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.htm Modeling Methods and CASE Tools. http://mlwww.diee.unica.it/TABOO/OO-CASE-tools.html