Transcript .ppt

Understanding and using
patterns in software development
EEL 6883
Software Engineering Vol. 1 Chapter 4
pp.235-248
Presenter: Sorosh Olamaei
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
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
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.
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
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)
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
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)
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.
Design Patterns

Creational Patterns


Structural Patterns


Singleton: Ensure a class only has on instance and
provide a global point of access to it
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
3.3 Programming Patterns


Are patterns whose forms are described
by means of programming language
constructs.
Example: for loop
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
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
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
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)
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
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
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)
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
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
Question !?