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

Introduction Patterns are effective means of capturing and communicating experience. Patterns are effective means of capturing and communicating experience. Patterns work for software development on several levels. Patterns work for software development on several levels. Different pattern types and their relationship with models built during software development 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 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 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. 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 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 The form of a pattern consists of a finite number of visible and distinguishable components and their 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 and compare concrete instances of it which helps with better understanding of an application domain. 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 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 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. 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. 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 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 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 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 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) 2.3 Consolidated example (the distinction of Tools and Materials)

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

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 described by means of the terms and concepts from an application domain 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 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 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) 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 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 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 should fit or complement conceptual space opened by conceptual patterns.

Design Patterns Creational Patterns Creational Patterns Singleton: Ensure a class only has on instance and provide a global point of access to it Singleton: Ensure a class only has on instance and provide a global point of access to it Structural Patterns Structural Patterns Proxy: Provide a placeholder for another object to control access to it Proxy: Provide a placeholder for another object to control access to it Behavioral Patterns Behavioral Patterns State: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class 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. Are patterns whose forms are described by means of programming language constructs. Example: for loop Example: for loop

3.4 Model and pattern interrelationship All 3 pattern types should be brought together in a coherent approach All 3 pattern types should be brought together in a coherent approach Ex: Ex: Conceptual pattern: the Distinction of Tools and Materials Conceptual pattern: the Distinction of Tools and 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

4 Pattern Description Forms Every abstraction needs a notation to give it a form 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 best way to describe a pattern depends on the intended usage of the pattern The Alexandrian form The Alexandrian form The design pattern catalog form The design pattern catalog form A general 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 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 Emphasis on when to apply the pattern 4.2 The design pattern catalog form: Gamma et al. (1995); template with number of sections 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 Emphasis on static and dynamic aspect of the pattern; descriptive rather than generative Best for OOD, well understood, stand alone Best for OOD, well understood, stand alone

4.3 A general form Two section: Context, Pattern 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 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 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 description core is to adapted to different use situations: additional sections can be added (how to use) 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: Aim is to: Ease understanding and usability of patterns Ease understanding and usability of patterns Restrict design space for the various types of software systems Restrict design space for the various types of software systems Pattern ordering into sets, background and leitmotif for software development Pattern ordering into sets, background and leitmotif for software development Pattern emerges from “background” which is captured by “leitmotif” 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 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 Pattern/Context pair Each pattern/context pair is preceded by all pattern/context pairs that are needed to understand it 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 Conceptual patterns logically precede design patterns which logically precede programming patterns Fig 3 on page 243 VOL 1 Fig 3 on page 243 VOL 1

5.2 Pattern Background Infinite embedded contexts Infinite embedded contexts Context of the first pattern/contact pair in the directed graph 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) 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 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 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) Later definitions of concepts introduced earlier in the paper. (ex: form and context) Not a good coverage on design patterns Not a good coverage on design patterns

Question !?