CSC/ECE 517 Fall 2009/wiki2 12 01: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(27 intermediate revisions by 2 users not shown)
Line 4: Line 4:


== Design Patterns ==
== Design Patterns ==
A design pattern in software engineering can be described as a reusable solution template to a frequently occurring software design problem.
A design pattern in software engineering can be described as a reusable solution template to a frequently occurring software design problem. [8]


==== Desirable Properties of Pattern Classification Schemes ====
==== Desirable Properties of Pattern Classification Schemes ====
We now present the desirable qualities for classification schemes of design patterns [7]
* The schemes ought to be simple and easy to learn and use
* The schemes ought to be simple and easy to learn and use
* The criteria should be few in number  
* The criteria should be few in number  
Line 15: Line 18:


== Classification of Design Patterns ==
== Classification of Design Patterns ==
Design patterns can be classified along the following schemes
Design patterns can be classified along the following schemes [7]


*Purpose
*Purpose
Line 25: Line 28:
*Paradigm
*Paradigm
*Domain-Dependent
*Domain-Dependent
*Process
*Re-engineering
*Analysis
*Reengineering
*Performance
*Performance
*Maintenance
*Maintenance
Line 34: Line 35:
Design patterns can also be classified according to what they are intended to achieve. This is in fact one of the most useful schemes of classification since it meets all the desirability requirements mentioned earlier.
Design patterns can also be classified according to what they are intended to achieve. This is in fact one of the most useful schemes of classification since it meets all the desirability requirements mentioned earlier.


In the book  Design Patterns: Elements of Reusable Object-Oriented Software written by Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides design patterns are classified into three types based on purpose.
Design patterns are classified into three types based on purpose.[3]


*Creational Patterns  
*Creational Patterns  
**Examples: Factory Method, Singleton
**Examples: [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
 
*Structural Patterns
*Structural Patterns
**Examples: Adapter, Facade
**Examples: [http://en.wikipedia.org/wiki/Adapter_pattern Adapter],[http://en.wikipedia.org/wiki/Facade_pattern Facade]
*Behavioral Patterns
*Behavioral Patterns
**Examples: Chain of Responsibility, Iterator
**Examples: [http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern Chain of Responsibility],[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]


== Scope ==
== Scope ==
Design patterns can also be classified based on the features implementing the patterns. In the book Design Patterns: Elements of Reusable Object-Oriented Software patterns are classified into the following two categories based on scope
Design patterns can also be classified based on the features implementing the patterns.[3]


*Class representation: Uses inheritance
*Class representation: Uses inheritance
**Examples: Adapter
**Examples: [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
*Object representation: Uses composition
*Object representation: Uses composition
**Examples: Singleton, Adapter
**Examples: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton], [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]




== Functionality ==
== Functionality ==
Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann classify patterns based on the functionality they are intended to achieve. The following are the categories
Design patterns can be classified based on the functionality they are intended to achieve.[4]
* creation
*Creation
* communication
**Example: [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
* access
*Communication
* organizing the computation of complex tasks  
**Example: [http://en.wikipedia.org/wiki/Blackboard_system Blackboard]
*Access
**Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
*Organizing the computation of complex tasks  
**Example: [http://en.wikipedia.org/wiki/Command_pattern Command]


== Structural Principles ==
== Structural Principles ==


In the book "Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects" by Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann patterns are classified based on the architectural principles they rely on. The categories are
Design patterns can also be classified based on the architectural principles they rely on.[4]


* Abstraction
* Abstraction
**Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade]
* Encapsulation
* Encapsulation
**Example:[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
* Separation of concerns
* Separation of concerns
* Coupling and cohesion  
* Coupling and cohesion  
**Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]


== Granularity ==
== Granularity ==
Patterns can also be classified based on the level of granularity at which they can be applied. However several patterns can be applied at different levels of granularity. Based on this patterns are classified into the following types
Patterns can also be classified based on the level of granularity at which they can be applied. However several patterns can be applied at different levels of granularity. Based on this patterns are classified into the following types


*Architectural patterns: These are applied to software systems at a very high level
*[http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural patterns]: These are applied to software systems at a very high level
*Design patterns: These are applied to components and subsystems
**Example: [http://en.wikipedia.org/wiki/Blackboard_system Blackboard System]
*Idioms: These are coding patterns applied at the lowest level
*[http://en.wikipedia.org/wiki/Design_patterns Design patterns]: These are applied to components and subsystems
 
*[http://en.wikipedia.org/wiki/Programming_idiom Idioms]: These are coding patterns applied at the lowest level
**Example: [http://en.wikipedia.org/wiki/Programming_idiom#Incrementing_a_counter Incrementing a Counter]
== Domain Specific Pattern Classification ==
== Domain Specific Pattern Classification ==
Most of the patterns in the software engineering are known, but not restricted to, solving architectural and design problems. Patterns have been identified and proposed to address domain specific problems. Patterns have been applied to domains like Real Time Software System, User Interface, Embedded System and Distributed System etc… It is naturally easier for a Software engineer or Designer to remember the pattern according to domain and apply it on the problem at hand. This also reduces the overhead to looking up patterns that are not remotely related to domain.
Most of the patterns in the software engineering are known, but not restricted to, solving architectural and design problems. Patterns have been identified and proposed to address domain specific problems. Patterns have been applied to domains like Real Time Software System, User Interface, Embedded System and Distributed System etc… It is naturally easier for a Software engineer or Designer to remember the pattern according to domain and apply it on the problem at hand. This also reduces the overhead to looking up patterns that are not remotely related to domain.
Below are two of the patterns classified for Real-time Systems by B. P. Douglass
Below are two of the patterns classified for Real-time Systems by B. P. Douglass
*Latch : Remember that a pre-conditional state has been achieved for later synchronization  
*Latch : Remember that a pre-conditional state has been achieved for later synchronization  
*Polling : Periodically perform an action.
*[http://en.wikipedia.org/wiki/Polling_%28computer_science%29 Polling] : Periodically perform an action.


== Paradigm based Classification ==
== Paradigm based Classification ==
Although patterns were initially a hit in object oriented software development, but the notion of patterns can be applied to other paradigms of programming languages. This provides opportunity for the programmers to lookup the patterns available for the paradigm they are using and apply the appropriate pattern suiting the problem at hand.
Although patterns were initially a hit in object oriented software development, but the notion of patterns can be applied to other paradigms of programming languages. This provides opportunity for the programmers to look up the patterns available for the paradigm they are using and apply the appropriate pattern suiting the problem at hand.


Following are examples of patterns that have been classified by S. Antoy and M. Hanus for “Functional logic languages”
Following are examples of patterns that have been classified by S. Antoy and M. Hanus for “Functional logic languages”[1]


*Opaque Type : Ensure that values of a datatype are hidden.
*Opaque Type : Ensure that values of a data type are hidden.
*Locally Defined Global Identifier:Ensure that a local name is globally unique.
*Locally Defined Global Identifier:Ensure that a local name is globally unique.
*Incremental Solution : Compute solutions in an incremental manner.
*Incremental Solution : Compute solutions in an incremental manner.
*Concurrent Distinct Choices : Ensure that a mapping from indexes to values is injective.
*Concurrent Distinct Choices : Ensure that a mapping from indexes to values is injective.
*Constrained Constructor : Prevent invoking a constructor that might create invalid data.
*Constrained Constructor : Prevent invoking a constructor that might create invalid data.
==Domain Dependent==
This classification is based on the patterns that can only be implemented in a particular domain. However not all of the patterns can be classified strictly into it, as the pattern represent solution to a generalized problem. It is worthwhile to notice that due to inherent reasons in a domain a solution can be generalized over a class of problems in a domain. The generalized solution that are domain specific bring forth the need to classify these patterns. This classification also assists the programmer, if he encounters a problem he can look up if there exists a design pattern available to solve it elegantly.
* The most widely known example for a domain dependent design pattern [http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html Session-Façade] in J2EE 
==Re-engineering Patterns==
To add to the classes of pattern classification, Re-engineering Patterns can be thought of as a good candidate. These patterens facilitate the improvement in maintainability, performance and to accommodate further changes
to legacy systems.[5]
*For example the ”Split Up God Class”pattern addresses the problem of application functionality being concentrated in only one class, which uses other classes as data structures.
*Suggested solution includes:
**Incrementally moving some functionality of the god class to other classes.
**Creation of new classes.
**Finally the god class remains as a facade or can be removed.
== Performance Patterns ==
This classification aims at identifying patterns that facilitate to improve performance and scalability of software.[6]
* Fast Path pattern
** aims at improving the response time by reducing processing required to access main functionality.
==Maintenance Patterns==
Also known as [http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf Evolution Patterns], these patterns aim at describing typical changes during lifetime of a software system. The name given to  these patterns might force reader to get confused with Re-engineering Patterns. However, maintenance patterns are different from Re-engineering patterns. While Re-engineering patterns aims at identifying patterns based on addressing problematic situations during system's evolution, Maintenance patterns aims at finding common general rules how the system evolves
* Maintenance Patterns also document system-specific problems and code points where the system may be maintained.


== References ==
== References ==
Line 97: Line 140:
*[3] [Gamma95] E. Gamma, R. Helm, R. Johnson  and J. Vlissides.  “Design Patterns – Elements of Reusable Object-Oriented  Software”, Addison-Wesley 1995.
*[3] [Gamma95] E. Gamma, R. Helm, R. Johnson  and J. Vlissides.  “Design Patterns – Elements of Reusable Object-Oriented  Software”, Addison-Wesley 1995.
*[4]Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 0-471-60695-2.
*[4]Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 0-471-60695-2.
*[5]S. Demeyer, S. Ducasse and O. Nierstrasz. “Object-oriented Reengineering Patterns”, Elsevier Science 2003.
*[6]C. U. Smith and L. G. Williams. “Performance Solutions –A Practical guide to Creating Responsive, Scalable Software”, Addison-Wesley 2001.
*[7] http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf
*[8] http://en.wikipedia.org/wiki/Design_patterns

Latest revision as of 00:25, 10 October 2009

Problem Statement

Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?


Design Patterns

A design pattern in software engineering can be described as a reusable solution template to a frequently occurring software design problem. [8]

Desirable Properties of Pattern Classification Schemes

We now present the desirable qualities for classification schemes of design patterns [7]

  • The schemes ought to be simple and easy to learn and use
  • The criteria should be few in number
  • The main properties of the patterns should be represented
  • The classification scheme should facilitate easy selection of patterns
  • Using the classification scheme it should be easy to classify new patterns
  • The classification scheme should also capture the relationships between different patterns

Classification of Design Patterns

Design patterns can be classified along the following schemes [7]

  • Purpose
  • Scope
  • Functionality
  • Structural Principles
  • Granularity
  • Domain
  • Paradigm
  • Domain-Dependent
  • Re-engineering
  • Performance
  • Maintenance

Purpose

Design patterns can also be classified according to what they are intended to achieve. This is in fact one of the most useful schemes of classification since it meets all the desirability requirements mentioned earlier.

Design patterns are classified into three types based on purpose.[3]

Scope

Design patterns can also be classified based on the features implementing the patterns.[3]

  • Class representation: Uses inheritance
  • Object representation: Uses composition


Functionality

Design patterns can be classified based on the functionality they are intended to achieve.[4]

Structural Principles

Design patterns can also be classified based on the architectural principles they rely on.[4]

  • Abstraction
  • Encapsulation
  • Separation of concerns
  • Coupling and cohesion

Granularity

Patterns can also be classified based on the level of granularity at which they can be applied. However several patterns can be applied at different levels of granularity. Based on this patterns are classified into the following types

Domain Specific Pattern Classification

Most of the patterns in the software engineering are known, but not restricted to, solving architectural and design problems. Patterns have been identified and proposed to address domain specific problems. Patterns have been applied to domains like Real Time Software System, User Interface, Embedded System and Distributed System etc… It is naturally easier for a Software engineer or Designer to remember the pattern according to domain and apply it on the problem at hand. This also reduces the overhead to looking up patterns that are not remotely related to domain. Below are two of the patterns classified for Real-time Systems by B. P. Douglass

  • Latch : Remember that a pre-conditional state has been achieved for later synchronization
  • Polling : Periodically perform an action.

Paradigm based Classification

Although patterns were initially a hit in object oriented software development, but the notion of patterns can be applied to other paradigms of programming languages. This provides opportunity for the programmers to look up the patterns available for the paradigm they are using and apply the appropriate pattern suiting the problem at hand.

Following are examples of patterns that have been classified by S. Antoy and M. Hanus for “Functional logic languages”[1]

  • Opaque Type : Ensure that values of a data type are hidden.
  • Locally Defined Global Identifier:Ensure that a local name is globally unique.
  • Incremental Solution : Compute solutions in an incremental manner.
  • Concurrent Distinct Choices : Ensure that a mapping from indexes to values is injective.
  • Constrained Constructor : Prevent invoking a constructor that might create invalid data.

Domain Dependent

This classification is based on the patterns that can only be implemented in a particular domain. However not all of the patterns can be classified strictly into it, as the pattern represent solution to a generalized problem. It is worthwhile to notice that due to inherent reasons in a domain a solution can be generalized over a class of problems in a domain. The generalized solution that are domain specific bring forth the need to classify these patterns. This classification also assists the programmer, if he encounters a problem he can look up if there exists a design pattern available to solve it elegantly.

  • The most widely known example for a domain dependent design pattern Session-Façade in J2EE


Re-engineering Patterns

To add to the classes of pattern classification, Re-engineering Patterns can be thought of as a good candidate. These patterens facilitate the improvement in maintainability, performance and to accommodate further changes to legacy systems.[5]

  • For example the ”Split Up God Class”pattern addresses the problem of application functionality being concentrated in only one class, which uses other classes as data structures.
  • Suggested solution includes:
    • Incrementally moving some functionality of the god class to other classes.
    • Creation of new classes.
    • Finally the god class remains as a facade or can be removed.

Performance Patterns

This classification aims at identifying patterns that facilitate to improve performance and scalability of software.[6]

  • Fast Path pattern
    • aims at improving the response time by reducing processing required to access main functionality.

Maintenance Patterns

Also known as Evolution Patterns, these patterns aim at describing typical changes during lifetime of a software system. The name given to these patterns might force reader to get confused with Re-engineering Patterns. However, maintenance patterns are different from Re-engineering patterns. While Re-engineering patterns aims at identifying patterns based on addressing problematic situations during system's evolution, Maintenance patterns aims at finding common general rules how the system evolves

  • Maintenance Patterns also document system-specific problems and code points where the system may be maintained.

References

  • [1] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.
  • [2] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.
  • [3] [Gamma95] E. Gamma, R. Helm, R. Johnson and J. Vlissides. “Design Patterns – Elements of Reusable Object-Oriented Software”, Addison-Wesley 1995.
  • [4]Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 0-471-60695-2.
  • [5]S. Demeyer, S. Ducasse and O. Nierstrasz. “Object-oriented Reengineering Patterns”, Elsevier Science 2003.
  • [6]C. U. Smith and L. G. Williams. “Performance Solutions –A Practical guide to Creating Responsive, Scalable Software”, Addison-Wesley 2001.
  • [7] http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf
  • [8] http://en.wikipedia.org/wiki/Design_patterns