CSC/ECE 517 Fall 2009/wiki3 10 OT

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

CRC Cards

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process [1].

CRC Cards are usually created from index cards which contain the following information:

• Class name - the name of the class
• Responsibilities - anything that the class knows or does
• Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

Object Think

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.[2]

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" [3] suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

Guidelines for Design Using Object Think

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

Benefits of Object Thinking

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

Alternatives to CRC Cards

Unified Modeling Language (UML)

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:

1. You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
2. You can easily visualize the relationship between classes or objects.
3. The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

OMT

The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

1. Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
2. Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
3. Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors. OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

Booch Method of OOAD

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems. Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

Coad, Yourdon and Nicola OOAD

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

FUSION

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [8]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation. The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

Example of a fusion process is explained in [7].

Example

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

Figure 1 Sequence Diagram.

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

References

[1] Introduction to CRC Cards by David M. Rubin

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] Object Think: A Perspective on Objects by Mike Abney

[4] "OBJECT THINK" A Step toward Object Oriented Implementation

[5] Object Think

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] Fusion Example

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] A Survey of Object-Oriented Methods by Peter Biggs