Chapter 1 Introduction to Software Patterns

1
Chapter 1 - Introduction to Software Patterns
CIS 476/566 Software Architecture and Design
Patterns

• Dr. Brahim Medjahed
• brahim_at_umich.edu

2
Motivation

• Software architecture
• Consists of software components, their external
  properties, and their relationships with one
  another.
• It also refers to documentation of a system's
  software architecture
• Developing software is hard but developing
  reusable software is even harder
• Reusability Likelihood that a module can be used
  again to add new functionalities with slight or
  no modification.
• Software Patterns provide proven solution
• Reusable elements

3
Patterns in the Webster Dictionary

• A form or model proposed for imitation
• Something designed or used as a model for making
  things (e.g., a dressmaker's pattern)

4
Learning from Experts

• Experts think in problem/solutions pairs
• They typically do not invent a new solution.
• They know from their own experience and the
  experience of other people a set of design
  solutions.
• If they face a new problem
• they often remember how they solved similar
  problem and adopt an old solution to a new
  context

5
Becoming a Chess Master

• First learn rules and physical requirements
• Names of pieces, legal movements etc.
• Then learn principles
• Relative values of certain pieces, strategic
  value of center squares, power of threat etc.
• However, to become master of chess one must study
  the games of other masters
• These games contains patterns that must be
  understood, memorized and applied repeatedly
• There are hundreds of such patterns

6
Becoming a Software Design Master

• First learn the rules
• Algorithms, data structures, etc.
• Then learn the principles
• Structured programming, modular programming, OOAD
  etc.
• However, to truly master software design, one
  must study designs of other masters
• These designs contains patterns that must be
  understood, memorized and applied repeatedly in
  context.
• There are hundreds of such software patterns

7
Software Patterns

• Represent solutions to problems that arise when
  developing software
• Pattern problem/solution pair applied in
  context
• Capture the static and dynamic structure and
  collaboration among key participants in software
  designs
• Facilitate reuse of successful software
  architectures and designs

8
Origins of Patterns

• 1970s Christopher Alexander, a bricks-and-mortar
  architect, wrote that desirable farmhouses in the
  Bernese Oberland area of Switzerland used these
  patterns
• North South Axis
• West Facing Entrance Down The Slope
• Two Floors
• Hay Loft At The Back
• Bedrooms In Front
• Garden To The South
• Pitched Roof
• Half-Hipped End
• Balcony Toward The Garden
• Carved Ornaments
• Alexander claimed that following these patterns
  when designing a farmhouse produces a structure
  that blends with the environment and the community

9
Origins of Patterns (contd)

• 1987 Kent Beck and Ward Cunningham presented an
  OOPSLA paper titled Using Pattern Languages for
  Object-Oriented Programs
• They described a project that applied Alexander's
  work to the problem of user-interface design
  guided by these patterns
• Window Per Task
• Few Panes Per Window
• Standard Panes
• Short Menus
• Nouns and Verbs

10
Origins of Patterns (contd)

• 1988-1991 Erich Gamma, Ph. D. thesis
• 1989 -1991 James Coplien, Advanced C Idioms
  book
• 1994-present PLoP Conferences and books
• 1995 Group of Four (GoF) - Design Pattern
  Elements of Reusable OO software
• 1996 Buschmann, Meunier, Rohnert, Sommerland,
  Stal - Pattern-Oriented Software Architecture A
  System of Patterns (POSA book)

11
Origins of Patterns (contd)

• Nowadays
• Many reports and published articles support the
  benefit of use of patterns
• ACM software engineering curriculum has included
  software design pattern topic

12
Patterns Definition I

• Christopher Alexander, A Pattern Language, 1977
• Context City Planning and Building architectures
• Each pattern describes a problem which occurs
  over and over again in our environment and then
  describes the core of the solution to that
  problem, in such a way that you can use this
  solution a million times over, without ever doing
  it in the same way twice

13
Patterns Definition II

• A general repeatable solution to a commonly
  occurring problem in software design.
• It is not a finished design that can be
  transformed directly into code.
• It is a description or template for how to solve
  a problem that can be used in many different
  situations.
• Object-oriented design patterns typically show
  relationships and interactions between classes or
  objects, without specifying the final application
  classes or objects that are involved.

14
Patterns Definition III

• GoF
• A design pattern is a description of
  communicating objects and classes that are
  customized to solve a general design problem in a
  particular context

15
Design Pattern Example

• A system that uses a number of temperature
  sensors to monitor the condition of a hardware
  device.
• The system uses specific sensors TempTek, Inc.
  TS7000 sensors.
• TempTek supplies a simple Java class to interface
  with the sensors
• Class TS7000
• native double getTemp()
• ...

Inspired From William H. Mitchells presentation
16
Design Pattern Example (contd)

• Monitoring code that simply calculates the mean
  temperature reported by the sensors.
• double sum 0.0
• for (int i 0 i lt sensors.length i)
• sum sensorsi.getTemp()
• double meanTemp sum / sensors.length
• Sensors is declared as an array of TS7000
  objects.
• (TS7000 sensors new TS7000...)

17
Design Pattern Example (contd)

• Assume now that the system uses a mix of TS7000s
  and sensors from a new vendor, Thermon.
• The Thermon sensors are SuperTemps and a hardware
  interfacing class is supplied
• Class SuperTempReader
• // NOTE temperature is Celsius tenths of a
  degree
• native double current_reading()
• ...

18
Design Pattern Example (contd)

• Here is the monitoring code
• For (int i 0 i lt sensors.length i)
• If (sensorsi instanceof TS7000)
• sum ((TS7000)sensorsi).getTemp()
• Else
• // Must be a SuperTemp!
• sum
• ((SuperTempReader)sensorsi).current_reading()
  10
• Sensors is an array of Objects.
• The type is tested with instanceof and an
  appropriate cast and method call is performed.

19
A Pattern to the Rescue

• Problems arose when a component from a second
  vendor was introduced.
• More vendors may be involved in the future.
• We have no control over the name of the
  temperature-reporting method in the
  vendor-supplied classes.
• The value produced may need scaling, unit
  conversion, etc.
• All that we can really expect is that a
  temperature can be read from each sensor.

The Adapter Pattern Provides a Solution to This
Problem
20
When to Use Patterns?

• Solutions to problems that recur with variations
• No need for reuse if problem only arises in one
  context
• Solutions that require several steps
• Not all problems need all steps
• Patterns can be overkill if solution is a simple
  linear set of instructions
• Solutions where the solver is more interested in
  the existence of the solution than its complete
  derivation
• Patterns leave out too much to be useful to
  someone who really wants to understand
• They can be a temporary bridge

21
What Makes It A Pattern?

• A Pattern must
• Solve a problem and be useful
• Have a context and can describe where the
  solution can be used
• Recur in relevant situations
• Provide sufficient understanding to tailor the
  solution
• Have a name and be referenced consistently

22
Benefits of Patterns

• Developers can have some confidence that the
  solution chosen is not entirely off the wall and
  has been used with success in similar situations
  in other systems.
• Patterns enable large-scale reuse of software
  architectures and also help document systems
• Patterns explicitly capture expert knowledge and
  design tradeoffs and make it more widely
  available
• Patterns help improve developer communication

23
Drawbacks of Patterns

• Patterns are not a panacea
• Teams may suffer from pattern overload
• Patterns are validated by experience and
  discussion rather than by automated testing
• Integrating patterns into a software development
  process is a human-intensive activity.

24
Anti-Patterns

• Also referred to as pitfalls,
• Classes of commonly-reinvented bad solutions to
  problems.
• They are studied, as a category, in order that
  they may be avoided in the future, and that
  instances of them may be recognized when
  investigating non-working systems.

25
Pattern Categories

• Architectural Patterns
• Design Patterns
• Idioms

26
Architectural Pattern

• Expresses a fundamental structural organization
  or schema for software systems.
• Provides a set of predefined subsystems,
  specifies their responsibilities, and includes
  rules and guidelines for organizing the
  relationships between them.

27
Design Pattern

• Provides a scheme for refining the subsystems or
  components of a software system, or the
  relationships between them.
• Describes commonly recurring structure of
  communicating components that solves a general
  design problem within a particular context.

28
Idiom

• Low-level pattern specific to a programming
  language.
• It describes how to implement particular aspects
  of components or the relationships between them
  using the features of the given language.

29
Elements of A Pattern

• Design patterns have four essential elements
• Pattern name
• Problem
• Solution
• Consequences

30
Pattern Name

• Describe a design problem and its solutions in a
  word or two
• Used to talk about the pattern with our
  colleagues
• Used in the documentation
• Increase our design vocabulary
• Have to be coherent and evocative

31
Problem

• Describes when to apply the pattern
• Explains the problem and its context
• May contain a list of preconditions that must be
  met before it makes sense to apply the pattern

32
Solution

• Describes the elements that make up the design,
  their relationships, responsibilities and
  collaborations
• Does not describe a concrete design or
  implementation
• Has to be well proven in some projects

33
Consequences

• Results and trade-offs of applying the pattern
• Helpful for describe design decisions, for
  evaluating design alternatives
• Benefits of applying a pattern (performance,
  time, size,).
• Impacts on a systems flexibility, extensibility,
  or portability

34
Describing Design Patterns in GoF

• Pattern name and classification
• Contains the essence of pattern succinctly
• Become part of your design vocabulary
• Intent
• What does the pattern do ?
• What particular problem does it address ?
• AKA Other well-known names

35
GoF Description (contd)

• Motivation
• Illustrate a design problem and how the class and
  the object structures solve the problem
• Applicability
• In which situations the pattern can be applied?
• How can you recognize these situations?

36
GoF Description (contd)

• Structure
• Graphical representation of the classes and their
  collaborations in the pattern
• Participants
• Class
• Objects
• Responsibilities

37
GoF Description (contd)

• Collaborations
• How the participants collaborate to carry out
  their responsibilities
• Consequences
• How does the pattern support its objectives?
• What are the trade-offs and results of using the
  pattern?

38
GoF Description (contd)

• Implementation pitfalls, hints
• Sample Code a sketch
• Known Uses
• Examples of the pattern found in real systems
• Related Patterns
• What design patterns are closely related to this
  one?
• What are the important differences?

39
Design Pattern Classification
40
Purpose of a Design Pattern

• Creational patterns
• Deal with initializing and configuring classes
  and objects
• Structural patterns
• Deal with decoupling interface and implementation
  of classes and objects
• Composition of classes or objects
• Behavioral patterns
• Deal with dynamic interactions among societies of
  classes and objects
• How they distribute responsibility

41
Scope of a Design Pattern

• Scope is the domain over which a pattern applies
• Class Scope relationships between base classes
  and their subclasses (static semantics)
• Object Scope relationships between peer objects
• Some patterns apply to both scopes.

42
Architectural Patterns Classification
43
Architectural Patterns Classification (contd)

• From Mud to Structure Support a controlled
  decomposition of an overall system task into
  cooperating subtasks
• Distributed Systems Provides an infrastructure
  for distributed application
• Interactive Systems Support the structuring of
  software systems that feature human-computer
  interaction
• Adaptable Systems Support extension of
  applications and their adaptation to evolving
  technology and changing functional requirements