CSC/ECE 517 Fall 2009/wiki3 17 VR: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 154: Line 154:
     method rotate {....}
     method rotate {....}
     method draw {....}
     method draw {....}
     method fillup {....}  // NEW
     method fillup {....}  // NEW METHOD
   }
   }
   class Rectangle inherits Shape {
   class Rectangle inherits Shape {
Line 160: Line 160:
     method rotate {....}
     method rotate {....}
     method draw {....}
     method draw {....}
     method fillup {....}  // NEW
     method fillup {....}  // NEW METHOD
   }
   }
   class Polygon inherits Shape {
   class Polygon inherits Shape {
Line 166: Line 166:
     method rotate {....}
     method rotate {....}
     method draw {....}
     method draw {....}
     method fillup {....}  // NEW
     method fillup {....}  // NEW METHOD
   }
   }
</pre>
</pre>
Line 174: Line 174:
Hence the Single Choice Principle:
Hence the Single Choice Principle:
<pre>
<pre>
<center> <b> SINGLE CHOICE PRINCIPLE </b> </center>
<b> SINGLE CHOICE PRINCIPLE </b>  
Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.
Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.
</pre>
</pre>

Revision as of 02:25, 19 November 2009

Single choice principle
Bertrand Meyer is the author of the book, "Object Oriented Software Construction", which is considered a foundational text of object-oriented programming book. In this book, he has mentioned about the five principles which explain modularity requirements. This wiki will explore through the Single Choice Principle in particular and its usage.

Introduction

In 1978, Yourdon and Constantine defined a software module as “a lexically contiguous sequence of program statements, bounded by boundary elements, having an aggregate identifier.” They had also proposed two important techniques namely – “Coupling” and “Cohesion” for measuing the dependability between modules. The various fundamental requirements resulting from a "modular" design method are :

  • DECOMPOSABILITY
    Meyer defined decomposability as :
    " A software construction method satisfies Modular Decomposability if : 
    it helps in the task of decomposing a software problem into a small number of less complex sub problems, connected by a simple structure, and
    independent enough to allow further work to proceed separately on each of them."
    

  • COMPOSABILITY
    Meyer defined composability as :
    A method satisfies Modular Composability if it favors the production of
    software elements which may then be freely combined with each other to
    produce new systems, possibly in an environment quite different from the
    one in which they were initially developed.
    

  • UNDERSTANDABILITY
    Meyer defined understandability as :
    A method favors Modular Understandability if it helps produce software in
    which a human reader can understand each module without having to know
    the others, or, at worst, by having to examine only a few of the others.
    
  • CONTINUITY
    A method satisfies Modular Continuity if, in the software architectures that
    it yields, a small change in a problem specification will trigger a change of
    just one module, or a small number of modules.
    
  • PROTECTION
    Meyer defined Protection as:
    A method satisfies Modular Protection if it yields architectures in which the
    effect of an abnormal condition occurring at run time in a module will remain
    confined to that module, or at worst will only propagate to a few neighboring
    modules.
    

In order to ensure modularity the following five rules must be followed:

  • Direct mapping:
  • Small interfaces(weak coupling):
  • Explicit interfaces:
  • Information Hiding:
  • Few interfaces:

There are five principles of software construction which are to be followed along with the above stated requirements and rules. They are:

The Linguistic Modular Units principle  :

This principle states that modules must correspond to syntactic units in the language used.

The self-documentation principle

 :

This principle states that the designer of a module should strive to make all information about the module part of the module itself.

The uniform access principle

 :

This principle states that all services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

The open-closed principle

 :

This principle states that the modules should be both open and closed.

The single choice principle

 :

This principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.

In detail

Consider the following Object oriented example stated by Meyer.

class Circle inherits Shape {
    method scale {....}
    method rotate {....}
    method draw {....}
  }
  class Rectangle inherits Shape {
    method scale {....}
    method rotate {....}
    method draw {....}
  }
  class Polygon inherits Shape {
    method scale {....}
    method rotate {....}
    method draw {....}
  }

The operations used in the three classes are scale, rotate and draw. These methods have been repeated in all the three classes. If a new method, for e.g., fillup() needs to be added, then, it must be added in all the three shapes and then the code becomes:

class Circle inherits Shape {
    method scale {....}
    method rotate {....}
    method draw {....}
    method fillup {....}  // NEW METHOD
  }
  class Rectangle inherits Shape {
    method scale {....}
    method rotate {....}
    method draw {....}
    method fillup {....}  // NEW METHOD
  }
  class Polygon inherits Shape {
    method scale {....}
    method rotate {....}
    method draw {....}
    method fillup {....}  // NEW METHOD
  }

In the process of software evolution, a programmer must accept that there is a possibility for certain methods or variants to arise. In such a case, to support the software over long term, there must be a method for protecting the structure of the software in order to overcome such changes.

Hence the Single Choice Principle:

<b> SINGLE CHOICE PRINCIPLE </b> 
Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.

Conceptual Analysis

Examples

Conclusion

References