The document discusses the concept of patterns in software development, emphasizing their role in capturing and communicating experience. It categorizes patterns into conceptual, design, and programming types, explaining their relationships with software engineering models. The document also analyzes different description forms of patterns and their contexts, aiming to enhance understanding and usability for developers.

1. Understanding and using
Understanding and using
patterns in software
patterns in software
development
development
EEL 6883
EEL 6883
Software Engineering Vol. 1 Chapter
Software Engineering Vol. 1 Chapter
4 pp.235-248
4 pp.235-248
Presenter: Sorosh Olamaei
Presenter: Sorosh Olamaei

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

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

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

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

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

7. 3 Patterns and Models
3 Patterns and Models
 Software engineering main models:
Software engineering main models:
 Application domain model
Application domain model
 Software design model
Software design model
 Implementation model
Implementation model
 Relate pattern types to models
Relate pattern types to models
 Conceptual Patterns
Conceptual Patterns
 Design Patterns
Design Patterns
 Programming Pattern
Programming Pattern

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

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

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

11. 3.3 Programming Patterns
3.3 Programming Patterns
 Are patterns whose forms are described
Are patterns whose forms are described
by means of programming language
by means of programming language
constructs.
constructs.
 Example: for loop
Example: for loop

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

13. 4 Pattern Description Forms
4 Pattern Description Forms
 Every abstraction needs a notation to
Every abstraction needs a notation to
give it a form
give it a form
 The best way to describe a pattern
The best way to describe a pattern
depends on the intended usage of the
depends on the intended usage of the
pattern
pattern
 The Alexandrian form
The Alexandrian form
 The design pattern catalog form
The design pattern catalog form
 A general form
A general form

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

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

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

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

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

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

20. My thoughts on the paper
My thoughts on the paper
 Later definitions of concepts introduced
Later definitions of concepts introduced
earlier in the paper. (ex: form and
earlier in the paper. (ex: form and
context)
context)
 Not a good coverage on design
Not a good coverage on design
patterns
patterns

21. Question !?
Question !?