Software Engineering Requirements Engineering

Document Sample
Software Engineering Requirements Engineering Powered By Docstoc
					Introduction to
Design Patterns
1. Introduction to Design Patterns

   To understand the Design Patterns we
   find the answer to the following
 • What is Design Patterns?
 • Why do we need the Design Patterns?
 • How Design Patterns can solve the
   design problem?

What is Design Patterns?
                 Business Needs and Constraints

                     The pattern
                     being use in                 Requirements Analysis
                   design phase to
                    solve common
  Deployment       design problem
                                             Architecture Design

                         Design              Detailed Design
                          Implementation                              3
Why do we need Design Patterns?
• To capture and document software
  design knowledge which helps
  designers acquire design expertise.
• To provide a common vocabulary for
  software developers to communicate
  their designs.
• To support reuse in design and boost
  confidence in software development.
• To offer significant help for the design
  of complex (and non-complex) systems.
Why do we need Design Patterns?
• To increase efficiency, reliability,
  extensibility, maintainability and reuse
  of a design.
• To represent optimized solutions to
  particular partial design problems.
• To maintain quality in design - each
  solution developed over time and many
  refinements into its optimized form.
• To make code easier to understand.
How Design Patterns can solve the problem?
 • Design pattern
    – describes a common design problem
    – demonstrates a solution to the problem
    – discusses the results and trade-offs applying
      the pattern
    – provide the capability to reuse successful
 • Design Pattern helps to visualize the design
   solution using UML as a template model or a
   parameterized collaboration and provide object
   creational, behavior and structural aspects of
Lets listen to the grandmasters…
What is a Design Pattern?
 “A design pattern names, abstracts, and
 identifies the key aspects of a common
 design structure that make it useful for
 creating a reusable objects design. The
 design pattern identifies the participating
 classes and instances, their roles and
 collaborations, and the distribution of
     (Design Pattern – Elements of reusable object oriented software,
     GOF, (Erich Gamma, Richard Helm, Ralph Johnson and John
     Vlissides, p. 4-5)
2.     Defining the Design Patterns
       - If you can remember my definitions…
 “   Patterns represent solutions to problem that arise when
     trying to solve the problem within a specific context.”
     Pattern = (Problem + Solution )in a context

 “   Software Patterns represent solutions to software
     engineering problems that arise when engineering software
     within a specific context.”
     Software Pattern = (Software Engineering Problem + Solution )in a

 “   Design patterns represent schematic descriptions of design
     solutions to recurring software design problems within a
     specific context.”
     Design Pattern = (Software Design Problem + Solution )in a context
Grandmasters definition…

“ Descriptions of communicating objects
  and classes that are customized to
  solve a general design problem in a
  particular context ” - GoF

 Patterns support the modularity. So that
 changes can be made internally without
 affecting other things.
3. Types of Design Pattern
• As the number of design patterns increases,
  it becomes more difficult to keep track of
  them, to know whether there is a pattern that
  solves a determined problem, and, if there
  exists, to find it. Let revise few of them …

• 1987 Cunningham & Beck develop a pattern
  language for Smalltalk and introduced Model
  View Controller (MVC) as the Design Pattern.

Design Pattern Catalogues (1)
In 1996, the new Object Oriented Design
technique was originated by GoF which now
known as GOF Design Pattern

  GoF design pattern
  catalogue contains 23

Design Pattern Catalogues (2)
 • Small memory design
   pattern created by James
   Noble and Charles Weir
 • Contains 26 design
   patterns primarily
   intended for resource-
   constraint systems
 • But also very useful for
   “normal” systems
Design Pattern Catalogues (Others)
• The first hypermedia design patterns
  were presented by Rossi [19]; since
  then many more have been published.
• TinyOS design patterns by David Gay,
  Philip Levis & David Culler - contains 6
• Information Visualization Design
  Patterns by Jeffrey Heer and Maneesh
  Agrawala – contains 12 patterns
• Etc...
Preserving Design Pattern
 • The documentation for a design pattern should
   contain enough information about the problem
   that the pattern addresses, the context in which
   it is used, and the suggested solution.
 • Nonetheless, authors use their own layouts to
   document design patterns, and these layouts
   usually resemble the essential parts.
 • The authors usually include additional sections
   to provide more information, and organize the
   essential parts in different sections, possibly with
   different names.
 • A commonly used format is the one used by the
   Gang of Four.
Preserving Design Pattern
Pattern Name and Classification
   The pattern's name conveys the essence of the pattern
   succinctly. A good name is vital, because it will become part
   of your design vocabulary. Every pattern should have a
   descriptive and unique name that helps in identifying and
   referring to it. Additionally, the pattern should be classified
   according to a classification. This classification helps in
   identifying the use of the pattern.
   A short statement that answers the following questions:
   What does the design pattern do? What is its rationale and
   intent? What particular design issue or problem does it
   address? This describe the goal behind the pattern and the
   reason for using it. It resembles the problem part of the
   pattern.                                                       15
Preserving Design Pattern
 Also Known As
   A pattern could have more than one name. These
   names should be documented in this section.
 Motivation (Forces): This section provides a
   scenario consisting of a problem and a context in
   which this pattern can be used. By relating the
   problem and the context, this section shows when
   this pattern is used.
 Applicability: This section includes situations in
   which this pattern is usable. It represents the
   context part of the pattern.
 Structure: A graphical representation of the pattern.
   Class diagrams and Interaction diagrams can be
   used for this purpose.                           16
Preserving Design Pattern
 A listing of the classes and objects used in
 this pattern and their roles in the design.
 Describes how classes and objects used in
 the pattern interact with each other.
 This section describes the results, side
 effects, and trade offs caused by using this
Preserving Design Pattern
   This section describes the implementation of the pattern,
   and represents the solution part of the pattern. It provides
   the techniques used in implementing this pattern, and
   suggests ways for this implementation.
 Sample Code
   An illustration of how this pattern can be used in a
   programming language
 Known Uses
   This section includes examples of real usages of this
 Related Patterns
   This section includes other patterns that have some relation
   with this pattern, so that they can be used along with this
   pattern, or instead of this pattern. It also includes the
   differences this pattern has with similar patterns.         18
Thank You

Extension of the design vocabulary
• Each design pattern carries a distinct and
  well known name
• The name reflects the key characteristic of
  the pattern
• The name represents and substitutes the
  pattern in design discussions
“QWaN means that, when applied correctly to solve an
applicable problem, the resulting solution provides a
structure that can evolve over time to meet unanticipated
future needs.”                                          20
                         -'A Timeless Way of Building.'
  Design Pattern Description (1)
• Standard set by the “Design Patterns”
   book (Gamma, et al.):
1. Pattern Name - An easy memorizable
   designator for a particular pattern, which
   reflects the essence of the solution.
   The name acts like a type name for the
   pattern and typically becomes part of the
   “designer’s language”

  Design Pattern Description (2)
2. Problem - Describes when to apply the
   pattern, the problem it intends to solve,
   and the associated context. This section
   may contain restrictions and conditions.
3. Solution - Describes the elements and
   strategies of the solution, but does not
   dictate a particular implementation.
   Represents an abstract and platform-
   independent solution
  Design Pattern Description (3)
4. Consequences - Describes the results,
   trade-offs and side-effects of applying the
   pattern. These are among others:
  –   Time / space trade-offs
  –   Impact on flexibility
  –   Impact on portability
  –   Impact on extensibility
  –   ...
A list of known usages concludes the
   Model – View – Controller (1)
• One of the most important patterns for
  interactive software systems
• Actually more an architecture pattern than
  a regular design pattern
• Utilizes “normal” design patterns for its

   Model – View – Controller (2)
• Interactive software systems have
   typically three major responsibilities:
1. A set of information to be processed or
2. A facility for information presentation
3. A facility for user interaction
• In (too) many cases these three functions
   are muddled together into a single
   system design                           25
   Model – View – Controller (3)
• The Model-View-Controller pattern
  separates these three responsibilities into
  separate units
• This provides a much cleaner system in
  terms of:
  –   Functionality
  –   Adaptability
  –   Maintainability
  –   Portability
  –   Evolvability
Model – View – Controller (3)



   Model – View – Controller (4)
• Represents the information to be
• Consists of model-specific information
  structures and the associated
  management and manipulation methods
• All operations are input-, output- and
• The model format is optimized for
  processing (and storage)               28
   Model – View – Controller (5)
• Presentation of the model to the user
• May require model transformation into
  one or multiple view model(s)
• May contain derived information
• View operations have no influence on
• The view model format is optimized for
  presentation and visual manipulation     29
   Model – View – Controller (6)
• Command and control for all operations
• Controls and operates all I/O channels
  (devices) of the software system
• Translates all user commands and
  actions into (neutral) internal actions
• Is in most cases the main controller of the
  software system
  Model – View – Controller (7)
• Model component only dependent on the
  model itself and its operations
• View component can be adapted to
  particular needs or usages without
  affecting the model
• Controller component and a small part of
  the view component are the only strongly
  platform-dependent components
• Support of new devices has only limited 31

Shared By: