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
 
(38 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== 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 ==
== 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 ====


Purpose of Pattern Classification
We now present the desirable qualities for classification schemes of design patterns [7]
* The main goal of pattern classification is to make it easier forsoftware developers to select the right pattern to apply.
Example: In order to solve a certain designproblem, the right designpattern, if available, should be selected.
* For selecting a specific pattern, i.e. pattern selection, the nature of the problem should be matched with the right pattern category.
Hint: Match the description of the problem with the description of the pattern category, then with the description of the individual patterns.
* Classification schemas can be used to understand and perceive the main propertiesof patterns.
* It is usually impractical to go through all the details of all the patterns before picking up the right pattern.
* Classification schemas can be used to structurea pattern system and highlight the relationshipsbetween the constituent patterns.


Properties of Classification Schema
* The schemes ought to be simple and easy to learn and use
 
* The criteria should be few in number  
According to [Buschmann96]:
* The main properties of the patterns should be represented
* Simple and easy to learn: It should be easy to use the classification scheme to classify and select patterns.
* The classification scheme should facilitate easy selection of patterns
* Few classification criteria: In order to reduce complexity and ambiguity, the classification schema needs to be as compact as possible in terms of the number of criteria.
* Using the classification scheme it should be easy to classify new patterns
* Reflecting pattern properties: Using the classification schema, it should be possible to represent the main properties of the patterns to be classified.
* The classification scheme should also capture the relationships between different patterns
* Road map to pattern selection: The classification scheme should ease the pattern selection process.
* Openness to the integrationof new patterns: Using the classification schema, it should be possible to classify new patterns.
 
Additional Properties:
* Openness to new classification criteria: It should be possible to extend the classification scheme by either increasing its dimension or by modifying a given dimension.
* Reflecting the relationship between patterns: In addition to capturing their main properties, the classification schema should be able to highlight the relationships between the patterns.


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


*Purpose
*Purpose
Line 39: Line 28:
*Paradigm
*Paradigm
*Domain-Dependent
*Domain-Dependent
*Process
*Re-engineering
*Analysis
*Reengineering
*Performance
*Performance
*Maintenance
*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]
*Creational Patterns
**Examples:  [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
*Structural Patterns
**Examples: [http://en.wikipedia.org/wiki/Adapter_pattern Adapter],[http://en.wikipedia.org/wiki/Facade_pattern Facade]
*Behavioral Patterns
**Examples: [http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern Chain of Responsibility],[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
== Scope ==
Design patterns can also be classified based on the features implementing the patterns.[3]
*Class representation: Uses inheritance
**Examples: [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
*Object representation: Uses composition
**Examples: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton], [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
== Functionality ==
Design patterns can be classified based on the functionality they are intended to achieve.[4]
*Creation
**Example: [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
*Communication
**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 ==
Design patterns can also be classified based on the architectural principles they rely on.[4]
* Abstraction
**Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade]
* Encapsulation
**Example:[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
* Separation of concerns
* Coupling and cohesion
**Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
== 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
*[http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural patterns]: These are applied to software systems at a very high level
**Example: [http://en.wikipedia.org/wiki/Blackboard_system Blackboard System]
*[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 ==
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
*[http://en.wikipedia.org/wiki/Polling_%28computer_science%29 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 [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==


== Headline text ==
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.


== Headline text ==
== 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

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