Acknowledgements: These slides are based partially on 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. The research team consisted of Dr. Conrad Cunningham, PhD students Yi Liu and Pallavi Tadepalli, and MS students Mingxian Fu and Hui Xiong.

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 1996] approach. Others differ in structure but have same purpose.

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

Architectural Pattern Examples

From [Buschmann 1996] unless otherwise noted

• Pipes and Filters (or Pipeline)
• Model-View-Controller
• Blackboard (or Repository)
• Layers
• Data abstraction [Shaw 1996a]
• Communicating Sequential Processes [Shaw 1996a]
• Implicit Invocation pattern [Shaw 19996a]
• etc

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)

Design Pattern Examples (1)

Names from [Gamma 1995] unless otherwise noted

• Creational patterns
  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

Design Pattern Examples (2)

• Structural patterns
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

Design Pattern Examples (3)

• Behavioral patterns
  • Chain of Responsibility
  • Command
  • Interpreter (also architectural [Shaw 1996a])
  • Iterator
  • Mediator
  • Memento
  • Null Object [Woolf 1997]
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

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 (Reference Counting) for storage management of shared objects in C+

References

[Buschmann 1996]

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

[Gamma 1995]

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.

[Shaw 1996a]

Mary Shaw. Some Patterns for Software Architecture, In John M. Vlissides, James O. Coplien, and Norman L. Kerth, editors, Pattern Languages of Program Design 2, Addison Wesley, 1996, pages 255-270. [local]

[Shaw 1996b]

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

[Woolf 1997]

Bobby Woolf. Null Object, In Robert Martin, Dirk Riehle, and Frank Buschmann, Pattern Languages of Program Design 3, Addison-Wesley, 1997.