CSC/ECE 517 Fall 2012/ch2a 2w23 sr: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(32 intermediate revisions by the same user not shown)
Line 1: Line 1:
''Responsibility-Driven Design''
''Responsibility-Driven Design''
== Introduction ==
== Introduction ==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enable software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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.
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) 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 [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.
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 [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.


== Definition ==
== Definition ==
RDD is defined as follows:
Responsibility-Driven Design is defined as follows:


Responsibility-driven design is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:
It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:


* What actions is this object responsible for?
* 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>
* 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==
== Responsibility-Driven Design principles and analysis==
=== Principles ===
 
* Maximize Abstraction
'''''Principles'''''
 
The basic principles of Responsibility-Driven Design are:
 
*<b>Maximize Abstraction</b>


Initially hide the distinction between data and behavior.
Initially hide the distinction between data and behavior.
Line 21: Line 25:
Think of objects responsibilities for “knowing”, “doing”,and “deciding”.
Think of objects responsibilities for “knowing”, “doing”,and “deciding”.


* Distribute Behavior
*<b>Distribute Behavior</b>


Promote a delegated control architecture.
Promote a delegated control architecture.


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


*Preserve Flexibility
*<b>Preserve Flexibility</b>
 
Design objects such that interior details can be readily changed.
 
'''''Analysis'''''
 
The analysis stage of Responsible-Driven Design consists of three phases:
*<b>System Definition:</b> High-level view of system
*<b>Detailed Description:</b> Detailed view of development process, functional requirements, and non-functional requirements.
*<b>Object Analysis:</b> Construction of domain objects。<ref>http://www.wirfs-brock.com/ RRD principles and constructs</ref>


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 ==
== Example ==
Line 46: Line 50:
                         [[File:RDD2.jpg]]
                         [[File:RDD2.jpg]]


                                                 Figure 1. Usecase diagram of POST
                                                 Figure 1. [http://www.site.uottawa.ca/~ssome/Cours/SEG3202/rdd.pdf Usecase diagram of POST]


                         [[File:rdd1.jpg]]
                         [[File:rdd1.jpg]]


                                                 Figure 2. RDD Methodological context of POST Usecase
                                                 Figure 2. [http://www.site.uottawa.ca/~ssome/Cours/SEG3202/rdd.pdf 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.
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 ==
== Advantages ==
*Increased encapsulation:
*'''''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. 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.
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:
*'''''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.
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 ==
== 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.  
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.  
Line 67: Line 71:


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.
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 ==
== 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.
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 ==
<references/>
<references/>
== External Links ==
1. [http://www.ece.uprm.edu/~borges/CRC.pdf Responsibility Driven Design]
2. [http://nccastaff.bournemouth.ac.uk/jmacey/CA1/Papers/Responsibility-Driven%20Design.pdf Object-Oriented  Design: A  Responsibility-Driven  Approach ]

Latest revision as of 03:59, 27 October 2012

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:

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/>

External Links

1. Responsibility Driven Design

2. Object-Oriented Design: A Responsibility-Driven Approach