Understanding and using patterns in software development

1
Understanding and using patterns in software
development

• EEL 6883
• Software Engineering Vol. 1 Chapter 4 pp.235-248
• Presenter Sorosh Olamaei

2
Introduction

• Patterns are effective means of capturing and
  communicating experience.
• Patterns work for software development on several
  levels.
• Different pattern types and their relationship
  with models built during software development

3
2.1 Pattern definitions

• A pattern is the abstraction from a concrete form
  which keeps recurring in specific non-arbitrary
  context.
• A solution to a recurring problem in a context
• Christopher Alexander Pattern is a relationship
  between forces that keep recurring in a specific
  context and a configuration which resolves these
  forces.
• Pattern as a rule

4
2.2 Form and Context

• The form of a pattern consists of a finite number
  of visible and distinguishable components and
  their relationships
• Structural and dynamic properties
• Technical or non-technical entities
• Pattern of the Distinction of Tools and Materials
• Concrete instances of the pattern
• Form of the pattern as a template helps us to
  identify and compare concrete instances of it
  which helps with better understanding of an
  application domain.

5
Form and Context

• A pattern is used to create, identify and compare
  instances of this pattern
• Pattern instances appear only in specific
  contexts which raise and constrain the forces
  that give birth to the concrete form
• The form of a pattern is finite but the form of
  its instances need not to be finite. The context
  is potentially infinite.
• Example Chain of responsibility consist of the
  roles Client, handler and successor.
• A pattern can only be understood and properly
  used with respect to the background of experience
  and reflection in the domain of its context

6
Form and Context

• Transferring patterns to a new context requires
  experience and insight into both its original and
  new context
• The form describing a pattern can be formalized
  but not its context
• A pattern must be presented in such a way that
  can be understood and properly used by others in
  their work and professional language
• 2.3 Consolidated example (the distinction of
  Tools and Materials)

7
3 Patterns and Models

• Software engineering main models
• Application domain model
• Software design model
• Implementation model
• Relate pattern types to models
• Conceptual Patterns
• Design Patterns
• Programming Pattern

8
3.1 Conceptual Patterns

• Conceptual model of the application domain
• Viewpoints of the stakeholders
• A conceptual pattern is a pattern whose form is
  described by means of the terms and concepts from
  an application domain
• Conceptual patterns should be based on metaphors
  rooted in the application domain
• Linking metaphors to a certain pattern helps to
  bridge the gap between application domain and
  software design
• Conceptual patterns should be geared towards a
  restricted application domain ( not too generic
  or too concrete ex. The Distinction of Tools and
  Materials)

9
3.2 Design Patterns

• A design pattern is a pattern whose form is
  described by means of software design constructs
  such as objects, classes, inheritance,
  aggregation and use-relationship
• It reformulates the conceptual model in terms of
  the formal restrictions of a software system
• Design patterns should fit or complement
  conceptual space opened by conceptual patterns.

10
Design Patterns

• Creational Patterns
• Singleton Ensure a class only has on instance
  and provide a global point of access to it
• Structural Patterns
• Proxy Provide a placeholder for another object
  to control access to it
• Behavioral Patterns
• State Allow an object to alter its behavior when
  its internal state changes. The object will
  appear to change its class

11
3.3 Programming Patterns

• Are patterns whose forms are described by means
  of programming language constructs.
• Example for loop

12
3.4 Model and pattern interrelationship

• All 3 pattern types should be brought together in
  a coherent approach
• Ex
• Conceptual pattern the Distinction of Tools and
  Materials
• Design Pattern Tools and Material Coupling
• Fig 2 on page 241 VOL 1 use of aspect class

13
4 Pattern Description Forms

• Every abstraction needs a notation to give it a
  form
• The best way to describe a pattern depends on the
  intended usage of the pattern
• The Alexandrian form
• The design pattern catalog form
• A general form

14
Pattern Description Forms

• 4.1 The Alexandrian form In Coplien Schmidt
  (1995) form of presentation consisting of at
  least 3 sections Problem, Context and Solution
• Emphasis on when to apply the pattern
• 4.2 The design pattern catalog form Gamma et al.
  (1995) template with number of sections
• Emphasis on static and dynamic aspect of the
  pattern descriptive rather than generative
• Best for OOD, well understood, stand alone

15
4.3 A general form

• Two section Context, Pattern
• The intended use of this description form is to
  discuss the structure and dynamics of the
  recurring form and its context without promoting
  a specific way of using the pattern
• 4.4 Comparison and discussion
• Alexandrian form matching problems with
  solutions
• Design Pattern Catalog OOD
• Pattern/context general presentation in which a
  pattern description core is to adapted to
  different use situations additional sections can
  be added (how to use)

16
5 Pattern Sets

• Aim is to
• Ease understanding and usability of patterns
• Restrict design space for the various types of
  software systems
• Pattern ordering into sets, background and
  leitmotif for software development
• Pattern emerges from background which is
  captured by leitmotif
• A shared vision incorporating the views, believes
  and values of software developers that shape a
  software system as a whole

17
5.1 Ordering patterns

• Pattern/Context pair
• Each pattern/context pair is preceded by all
  pattern/context pairs that are needed to
  understand it
• Conceptual patterns logically precede design
  patterns which logically precede programming
  patterns
• Fig 3 on page 243 VOL 1

18
5.2 Pattern Background

• Infinite embedded contexts
• Context of the first pattern/contact pair in the
  directed graph
• Must be sufficiently understood by authors and
  readers to be communicated (it is the problem
  domain)

19
5.3 Leitmotif for software development

• A leitmotif is a general principle that guides
  software development. It is the broad picture
  which can evoke a vision of the future system. It
  makes the underlying beliefs and values explicit
  that drive software design as a whole
• Personal beliefs and values are driving forces
  for application design. They have significant
  impact on the form and content of a pattern

20
My thoughts on the paper

• Later definitions of concepts introduced earlier
  in the paper. (ex form and context)
• Not a good coverage on design patterns

21
Question !?