Introduction To Pattern

What is a Pattern

• Experience gain by experts from working on a particular problem

• If documented down in detail on how to solve the problem - we have a Pattern

• Pattern are also called Problem-Solution Pairs

• Can reapply the pattern to solve the same kind of problem

• Called 'expert behavior'

• Learn from mistake, not yours but others

• Patterns domain not bounded in software engineering but also architecture, economics, math or even social interaction

• We will study Design Pattern to start with

• Limited to a certain domain

• Other design overhead

Why Patterns ?

• A pattern addresses a recurring design problem that arises in specific design situation

• Patterns use higher level of abstractions that are above the level of abstract class, class library, packages or components

• Patterns provide a complete example with common vocabulary and design principles

• Patterns provide the framework for building software system with functional and non-functional behavior

• Patterns help you build complex and heterogeneous software system/design/architectures

• To sum it up: "Pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and 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" - Buschmann, Meunier, Rohnert, Sommerlad, Stal

• Co-exist with model design method - OOA, OOD

• Patterns is problem-oriented and fill the gap that is not covered by existing problem-independent techniques

Common Format in Pattern - Pattern Syntax

We should forward the following format, so we are at the same level as all the other people

• Name - The name and a short summary of the pattern

• Also Known As (aka) - Other names for the pattern, if any are known. For example Decomposition <-> Composition <-> Whole-Part

• Example - A real-world example demonstrating the existence of the problem and the need for the pattern

• Context - The situations in which the pattern may apply

• Problem - The problem the pattern addresses, including a discussion of its requirements

• Solution - The fundamental solution principle underlying the pattern

• Structure - A detail specification of the structural aspects of the pattern, including CRC-cards for each participating component and an OMT or Booch class diagram (Tools available www.rational.com called Rational Rose)

• Dynamics - Describe scenarios with scenarios diagram for run-time behavior of the pattern

• Implementation - Guidelines for implementing the pattern. Lay out a list of suggestion for other people to use. It should not be a set of firm rules

• Example Resolved - Discussion of how to solve the problem(s) in the "Example" session

• Variants - A brief description of variants or specializations of a pattern

• Known Uses - Examples of the use of the pattern, taken from existing systems

• Consequences - The benefits the pattern provides, and any potential liabilities

• See Also - References to patterns that solve similar problems, and to patterns that help us refine the pattern we are describing

What Else

• We will cover Architecture Pattern, Pattern System and the concept of Pattern Mining later in the course