CSC/ECE 517 Fall 2012/ch2a 2w23 sr
Responsibility-Driven Design
Introduction
Object-oriented programming(OOP) language enables 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
Responsibility-Driven Design is defined as follows:
It 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
The basic principles of Responsibility-Driven Design are:
- 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 i.e. have them behave intelligently, not just hold bundles of data.
- Preserve Flexibility
Design objects such that interior details can be readily changed.
Analysis
The analysis stage of Responsible-Driven Design 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 usecases. It then assigns responsibilities to objects/classes for use cases realization. Suppose the given use case for POST is represented in Figure 1. Then the RDD methodical context for POST is given by Figure 2.
Figure 1. Usecase diagram of POST
Figure 2. RDD Methodological context of POST Usecase
Here, the figure 2. shows the considerations made while designing a model which is responsibility driven for POST. It includes business modelling,requirements and design of functionality.
Advantages
- Increases 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.It improves encapsulation with respect to subclass clients, ensuring that the 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.
Example of Responsibility-Driven v/s Data-Driven Design
Let us consider a class of raster image objects which stores visual images as two-dimensional array of bits. The operations of raster image include basic image manipulations like rotation, orientation, scaling etc. Now, we can define a RasterImage class which will include methods for each possible operation it can perform:
class Rasterlmage is
bitArray : ByteArray;
width : Integer;
height : Integer;
rotateBy(degree : Integer) : void;
scaleBy(x : Integer, y : Integer) : void;
bitAt(index : Point) : Integer;
bitAtPut(index : Point, bitValue : Integer) : void;
Rasterlmage structure:
bitArray : ByteArray;
bitArray(bits : ByteArray) : void;
width0 : Integer;
width(aNumber : Integer) : void;
height0 : Integer;
height(aNumber : Integer) : void;
end Rasterlmage;
The same requirement can be modified through responsibility driven desgn. The responsibilities of RasterImage class are: knowing and maintaining the smallest rectangle that completely contains its image, knowing and maintaining all individual bit values within its image and rotating and scaling the image. Therefore, the RasterImage class based on responsibilities is as follows:
class Rasterlmage is
boundingRectangle() : Rectangle;
boundingRectangIe(bounds : Rectangle) : void;
bitAt(index : Point) : Integer;
bitAtPut(index : Point, bitvalue : Integer) : void;
scaleBy(x : Integer, y : Integer) : void;
rotateBy(degrees : Integer) : void;
end Rasterlmage;
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. It increases encapsulation by focusing on the contractual responsibilities of a class and facilitates polymorphism by encouraging the designer to focus on responsibilities independently of implementation.
References
<references/>