Acknowledgements: These slides are adapted from my notes titled “Introduction to Patterns”. The original version of these slides (in Powerpoint) was supported by a grant from the Acxiom Corporation titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE)” in 2004.

Advisory: The HTML version of this document may require use of a browser that supports the display of MathML. A good choice as of February 2018 is a recent version of Firefox from Mozilla.

Approach

• Observe that we solve a new problem by applying a solution that worked on similar problem in past

• Document problem and solution pair to enable reuse

Concept of Design Pattern

• Arose originally in field of (building) architecture in 1970’s – Christopher Alexander

• Imported into software architecture and design in late 1980’s and 1990’s

Pattern

• Describes particular recurring design problem that arises in specific design contexts

• Presents well-proven generic scheme for solution

  • specified by describing constituent components, their responsibilities and relationships, and ways they collaborate

Characteristics of Patterns (1)

• Describe solutions to recurring problems that arise in specific design situations

• Distilled from practical experience, not invented

• Describe group of components (classes or objects), how components interact, responsibilities of each

  • Higher level abstractions than classes or objects

• Provide vocabulary for communication among designers

  • Choice of name for pattern very important

Characteristics of Patterns (2)

• Help document architectural vision of a design

  • If vision clearly understood, then less likely violated when system modified

• Provide conceptual skeleton for solution, encourage construction of software with well-defined properties

• Are building blocks for construction of complex designs

• Help designers manage complexity of software

Description of Pattern

[Buschmann]

1. Context

2. Problem

3. Solution

Description of Pattern: Context

• Describes situation in which design problem arises

Description of Pattern: Problem

• Describes problem that arises repeatedly in Context

• Describes set of forces – aspects that must be considered when attempting solution

  • requirements solution must satisfy (e.g., efficiency)

  • constraints that must be considered (e.g., use of specific algorithm or protocol)

  • desirable properties of solution (e.g., easy to modify)

• Must balance complementary and contradictory forces to achieve good solution

Description of Pattern: Solution

• Describes proven solution to Problem

• Specifies configuration of elements to balance forces

  • Describes static structure of configuration, identifying components and connectors (relationships among components)

  • Describes dynamic runtime behavior of configuration, identifying control structure of components and connectors

Categories of Patterns

1. Architectural patterns

2. Design patterns

3. Idioms

Architectural Pattern

“An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them” [Buschmann]

• High-level abstraction

• Fundamental design decision in development of system

• Independent of implementation language

• Examples:
  • Pipes and Filters pattern
  • Model-View-Controller pattern
  • Blackboard pattern

Design Pattern

“A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context” [Buschmann]

• Mid-level abstraction

• Affects the structure of a subsystem

• Independent of implementation language (but might not be independent of paradigm)

• Examples:
  • Adapter (or Wrapper) pattern
  • Iterator pattern
  • Strategy (or Policy) pattern

Idiom

“An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language” [Buschmann]

• Low-level abstraction

• Examples:
  • Language-specific iterator defined to implement interface Iterator in Java
  • Counted Pointer for storage management of shared objects in C+

References

• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture: A System of Patterns, Wiley, 1996.

• Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, 1996