% CSci 658: Software Language Engineering \
  Introduction to Patterns
% **H. Conrad Cunningham**
% **6 February 2018**

**Acknowledgements:** These slides are adapted from my notes
titled ["Introduction to Patterns" ](<Patterns.html>). 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