{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Riehle-Zullighoven-p235 - Understanding and using...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Understanding and using Understanding and using patterns in software development EEL 6883 Software Engineering Vol. 1 Chapter 4 pp.235­248 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 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 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 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 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 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

{[ snackBarMessage ]}

Ask a homework question - tutors are online