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.

A sample of CRC card

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

A simple CRC card example: floor plan

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.

The CRC card of class: person

The CRC card of class: address book

The CRC card of class: address book controller

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

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.

To fullfill 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 CRC card of class: File System

The CRC card of class: Address Book GUI

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.

Some Guidelines of Object Think

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

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