CSC/ECE 517 Fall 2009/wiki3 10 pz

CRC Card

Introduction

CRC (Class-Responsibility-Collaborator) Card is a simple yet powerful object-oriented analysis technique served as a brainstorming tool. Kent Beck and Ward Cunningham first introduced CRC cards at OOPSLA 1989 in their paper “A Laboratory for Teaching Object-Oriented Thinking”. The original purpose of CRC Card was to teach the object-oriented programming at Tektronix.

The CRC Card is composed of three components: Class, Responsibity and Collaborator.

Class

A Class represents a collection of similar objects. Objects are things of interest in the system being modeled. They can be a person, place, thing, or any other concept important to the system at hand. The Class name appears across the top of the CRC card.

Responsibility

A Responsibility is anything that the class knows or does. These responsibilities are things that the class has knowledge about itself, or things the class can do with the knowledge it has.

Collaborator

A Collaborator is another class that is used to get information for, or perform actions for the class at hand. It often works with a particular class to complete a step (or steps) in a scenario. The Collaborators of a class appear along the right side of the CRC card.

Examples

Here is a simple example of CRC Card to illustrate the concept of CRC Card: Floor Plan.

Now, we consider a floor plan of a house. The floor plan is an overview of the house, it has several properties, such as the name of the floor plan, the plan positioning, the locations of all kinds of stuff. Before moved in, the house only contains some basic elements: door, window, wall, roof, security camera. The floor plan should collaborates with all of these elements, and all of these elements have their only property design, such as the style of door, the color of walls, the shape of roof, the brand and resolution of security camera, etc. However, the positioning of these elements should be defined in the floor plan. So, there are many properties in floor plan and it also has to collaborate with other elements. To illustrate the above relationships, we could use CRC Card, the sample of this simple example is posted aside.

Here is a complicated example of CRC Card to further illustrate the concept of CRC Card: Address Book [1].

We think a more complicated example: Address Book. To construct a full functional address book, we need many complicated part, such as person, address book, controller, graphic user interface, file system. It's not like the previous example that only the floor plan incorporates all other elements. In this example the elements are all inter reactive.

The person class should contain basic properties and serves as data base to the whole structure. The properties of a person in address book contain: individual's first name, individual's last name, individual's address, individual's city, the individual's state, individual's ZIP, individual's phone number, etc. All these properties could be used and edited by other classes.

There will be many instances of person in the address book, so we need address book class to manage so many entries. And the address book class should also respond to the requests of other classes. So, the properties in address book class would be: Get number of a person, Print entries, Get other person information, Add person and related properties, Get full name of a person, Update person, Remove person, etc. All these operations are directly related to the person class.

The CRC card of class: Address Book controller

To fulfill full functions of address book, we need a controller to perform all kinds of tasks and send requests to address book class. This class has many functions due to the many functions of address book in the real world, such as: Allow the user to perform the Add a Person Use Case, Allow the user to perform the Edit a Person Use Case, Allow the user to perform the Delete a Person Use Case, Allow the user to perform the Sort Entries by Name Use Case, Allow the user to perform the Sort Entries by ZIP Use Case, Allow the user to perform the Create New Address Book Use Case, Allow the user to perform the Open Existing Address Book Use Case, Allow the user to perform the Save Address Book Use Case, Allow the user to perform the Save Address Book As ... Use Case, Allow the user to perform the Print Entries Use Case, etc. As we can see, the controller mainly functions with address book class, so we could think it as the bridge between address book class this concept and the user.

The File System class is coordinating the program and file system the program is runnig on. It contains properties: Read a stored address book from a file, given its file name, Save an address book to a file, given its file name, etc.

The GUI class is to provide user a friendly interface to use. It contains properties: Keep track of the address book object it is displaying, Display a list of the names of persons in the current address book, Allow the user to request the performance of a use case, Display the title of the current address book, etc. It interacts with address book and address book controller.

Object Think

Introduction

Object Think is first introduced by Peter Coad and Jill Nicola in the book “Object-oriented Programming” published in 1993. It is an approach to Object-oriented Programming that is based on the practice of object personification. Object Think requires developers to adopt a radically different way of thinking and tends to result in fewer objects and its primary objective is an accurate domain model made of composable objects that communicate with each other.

An object is an entity with state and behavior. For example, a counter has a state (what is the value) and behavior (it can be incremented or decremented). The state is also referred to as attributes or fields, and the behavior is also referred to as methods or functions. A class is a template for creating objects.

It is important to begin believing objects in a computer systems are like us: they know things and know how to do things. We need to have faith in them, to rely on them, to trust them. For example, let us consider a button appears on a window in a GUI. The window knows “my title and height and width”, “what button is attached to me”, “how to move and resize” and “how to open and close”. The button knows “what my label says”, “what window I am attached to”, “my location on the window” and “how to be closed”.

In the beginning, programmers were thought to be more artistic, so only a handful of people could create software. The mainstream believed that better tools and languages would allow average people to write software. The original concepts behind Object-oriented Programming were all but lost along the way, as scientific thought prevailed.

Traditional developers coding and formulating solutions tend to think like machines. This is known as formalism and has philosophical roots in the 18th century (The Age of Reason) which is also described as rationalism, determinism, or mechanism. So, western thought was strongly influenced by formalism, such as “CRC Card is good” and “Object Think is good”.

Object Think developers think like objects when coding and formulating solutions. This is based in a school of thought known as hermeneutics, which is literally the study of interpretation. Hermeneutic philosophy is based largely on linguistics and semantic theory but extends beyond that to include theory of self-organized and evolutionary systems.

Object Think differs from formalist thought by:

It believes that better tools will never offer advantages over better developers.
It also believes that domain expertise and domain modeling is the key importance to software design.
Agile software development (like Extreme Programming) is more similar to the Object Think approach than traditional approaches such as Waterfall Development.
It promotes a new way of thinking which does not rely on Design Patterns, UML, or any other structured approach.
Paper Prototyping and Semantic Net diagrams are most useful when modeling an application.

An Example

Here is a very good example: Milking an Object-oriented Cow

It considers the following case:

Every morning at 4:30 am, Farmer Jones gets up, goes to the barn, and milks his cow.

Then it models this case in a procedural system and an Object-oriented system respectively to compare the two systems. Finally, it concludes that what are the benefits of the Object-oriented Model and Object-oriented Thinking is really different from Procedural Thinking.

Some Guidelines of Object Think

Everything is an object.
Think like an object – “anthropomorphism”.
Objects are composable.

 1. Objects lower in object taxonomy are more specialized.
 2. Object capabilities do not vary by context.
 3. Language common to the domain is used to describe an object.
 4. The purpose and capabilities of an object are clearly stated and implementation decisions must meet that statement.

Applications are made by distributed cooperation and communication between objects – “think hive”.
Simulation of a problem domain drives object discovery and definition.
Incorrect objects and relationships can even be useful in semantic diagrams – the goal of planning on paper is brainstorming.
Functionality is placed as close to the data it needs as possible.
Objects are behavioral – not mechanical.
Design Patterns are useful as a learning tool – not a solution.

Comparison of CRC Card and Object Think

One biggest problem with CRC cards is that they are designed for use with a group, but Object Think can be achieved by individuals.

Some advantages of CRC Card are listed below:

Portable - Cards can be used anywhere, even away from the computer or office.
Anthropomorphic - No computer program can capture the essence of the interactions forced by passing the cards.
Level of involvement felt by each team member increases.
Useful throughout the life cycle - For designer, it's very clearly.
It provides a basis for more formal analysis and design methodologies.
It serves as input to a formal method - a starting point.
It makes more easier for the transition from process orientation to object orientation - most formal methods are overwhelming.
It gives a general bound on the size of a class - a card.

Also, some advantages of Object Think are listed below: