Chapter 1 Introduction to Software Patterns - PowerPoint PPT Presentation

Loading...

PPT – Chapter 1 Introduction to Software Patterns PowerPoint presentation | free to view - id: 95f79-ODU1O



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 1 Introduction to Software Patterns

Description:

1989 -1991: James Coplien, Advanced C Idioms book. 1994-present: PLoP Conferences and books ... Idiom. Low-level pattern specific to a programming language. ... – PowerPoint PPT presentation

Number of Views:241
Avg rating:5.0/5.0
Slides: 44
Provided by: brahimm
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com