CSC/ECE 517 Fall 2012/ch2a 2w23 sr

Responsibility-Driven Design

Introduction

Object-oriented programming(OOP) language enable software to be reusable, refinable, testable, maintainable, and extensible by supporting encapsulation. In order to realize these advantages, encapsulation should be maximized during the design process. other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Definition

RDD is defined as follows:

Responsibility-driven design is inspired by the client/server model. It focuses on the contract by asking:

• What actions is this object responsible for?
• What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

Responsibility-driven design principles and analysis

Principles

• Maximize Abstraction

Initially hide the distinction between data and behavior.

Think of objects responsibilities for “knowing”, “doing”,and “deciding”.

• Distribute Behavior

Promote a delegated control architecture.

Make objects smart—-have them behave intelligently, not just hold bundles of data.

• Preserve Flexibility

Design objects so interior details can be readily changed.

Analysis

The analysis stage of RDD consists of three phases

• System Definition

High-level view of system

• Detailed Description

Detailed view of development process, functional requirements, and non-functional requirements.

• Object Analysis

Construction of domain objects。<ref>http://www.wirfs-brock.com/ RRD principles and constructs</ref>

Example

The basic example of Responsibility-driven design is Point Of Sale Terminal (POST). It is basically driven by use cases and requirements which include domain models and system operations derived from use cases. It then assigns responsibilities to objects/classes for use cases realization.

Advantages

• Increased encapsulation:

The responsibility-driven approach emphasizes the encapsulation of both the structure and behavior of objects by focusing on the contractual responsibilities of a class. l It improves encapsulation with respect to subclass clients, ensuring that all inherited behavior is part of the contract of the subclass. The benefit is increased encapsulation, since the specification of the exact way in which a request is carried out is private to the server. Encapsulation is compromised when the structural details of an object become part of the interface. Responsibility-driven designs maximize encapsulation by ignoring the structural details.

• Facilitates polymorphism:

By encouraging the designer to focus on responsibilities independently of implementation, the responsibility driven approach can help a designer identify standard protocols (message names), which facilitates polymorphism. It makes abstract classes easier to identify. One difficulty in identifying abstract classes lies in determining what parts of the protocol of existing classes are parts of the type of those classes, and what parts are implementation details. Because the protocol of a class includes only those messages which form the type of the class, this problem is eliminated.

Comparison of Responsibility-driven design with Data-driven design

Adapting abstract data type design methods to object-oriented programming results in a data-driven design. On the other hand, Responsibility-driven design is in direct contrast with Data-driven design, which promotes defining the behavior of a class along the data that it holds.

Why responsibility-driven design over data-driven design?

While data-driven design does prevent coupling of data and functionality, in some cases, data-driven programming has been argued to lead to bad object-oriented design, especially when dealing with more abstract data. This is because a purely data-driven object or entity is defined by the way it is represented. Any attempt to change the structure of the object would immediately break the functions that rely on it. As a, perhaps trivial, example, one might represent driving directions as a series of intersections (two intersecting streets) where the driver must turn right or left. If an intersection (in the United States) is represented in data by the zip code (5-digit number) and two street names (strings of text), you might run into bugs when you discover a city where streets intersect multiple times. While this example may be over simplified, restructuring of data is fairly common problem in software engineering, either to eliminate bugs, increase efficiency, or support new features. In these cases responsibility-driven design may be promoted as a better approach, where functionality and data can be coupled together, so functions don't have to deal with the data representation itself.

Conclusion

Responsibility-Driven Design is A way to design software that emphasizes modeling of objects’ roles, responsibilities, and collaborations. Its principle is to maximize abstraction, delegate control and preserve flexibility. RDD increased encapsulation by focusing on the contractual responsibilities of a class and it facilities polymorphism by encouraging the designer to focus on responsibilities independently of implementation.

References

<references/>