Unformatted text preview: Understanding and using Understanding and using patterns in software development
Software Engineering Vol. 1 Chapter 4 pp.235248
Presenter: Sorosh Olamaei Introduction
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
2.1 Pattern definitions A pattern is the abstraction from a concrete form which keeps recurring in specific nonarbitrary 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
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 nontechnical 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
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
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
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
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 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 userelationship
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
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
3.3 Programming Patterns Are patterns whose forms are described by means of programming language constructs.
Example: for loop 3.4 Model and pattern 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
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
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
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
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
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
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 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
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 !?
Question !? ...
View Full Document
- Spring '08
- Patterns, application domain, Pattern Description Forms