1. Engr 691 Special Topics in Engineering Science Software Architecture Spring Semester 2004 Lecture Notes

2. Introduction to Patterns Created: 19 August 2004

3. Pattern Describes a particular recurring design problem that arises in specific design contexts Presents a well-proven generic scheme for its solution   The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate 1

4. Characteristics of Patterns Describe solutions to recurring problems that arise in specific design situations. Distilled from practical experience Describe a group of components (e.g., classes or objects), how the components interact, and the responsibilities of each component.  Higher level abstractions than classes or objects. Provide vocabulary for communication among designers  Choice of name for pattern is very important. 2

5. Characteristics of Patterns (cont.) Help document architectural vision of a design. If vision clearly understood  less likely violated when the system is modified Provide conceptual skeleton for a solution, encourage the construction of software with well- defined properties Are building blocks for construction of complex designs Help designers manage complexity of software 3

6. Descriptions of Patterns ContextProblemSolution 4

7. Descriptions of Patterns Context Describes situation in which design problem arises 5

8. Descriptions of Patterns Problem Describes problem that arises repeatedly in context   set of forces some aspect that must be considered when attempting a solution  requirements the solution must satisfy e.g., efficiency  constraints that must be considered e.g., use of a certain algorithm or protocol  desirable properties of a solution e.g., easy to modify 6

9. Descriptions of Patterns Solution Describes a proven solution to the problem Specifies a configuration of elements to balance the forces associated with the problem  Describes static structure of the configuration, identifying components and connectors relationships among the components relationships among the components  Describes dynamic runtime behavior of the configuration, identifying control structure of components and connectors 7

10. Categories of Patterns Architectural patterns Design patterns Idioms Idioms 8

11. Categories of Patterns Architectural patterns “ 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 ” High-level abstraction Fundamental design decision in development of a software system Independent of the implementation language Example  Pipes and Filters pattern 9

12. Categories of Patterns Design patterns “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” Mid-level abstraction Affect the structure of a subsystem Independent of the implementation language Example   Adapter (or Wrapper) pattern   Iterator pattern   Strategy (or Policy) pattern 10

13. Categories of Patterns Idioms “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” Low-level abstraction Language-specificExample   language-specific iterator defined to implement interface Iterator in Java   Counted Pointer for storage management of shared objects in C++ 11

14. 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. 12

15. Acknowledgement 13 This work was supported by a grant from Acxiom Corporation titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE).” This work was supported by a grant from Acxiom Corporation titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE).”