1.  2001 Lodewijk Bergmans University of Twente Pattern Languages

2.  2001 Lodewijk Bergmans University of Twente What is a Pattern Language? A collection of patterns that build on each other to generate a 'system' vNot a programming language!

3.  2001 Lodewijk Bergmans University of Twente Generative Patterns vThe structure of the pattern is not the solution itself, but it generates the solution vGenerative patterns explicitly describe when & how they should be applied to generate an appropriate solution

4.  2001 Lodewijk Bergmans University of Twente Pattern Language Examples Examples: vDesign patterns  Telecommunications software  Finances, vAnalysis patterns:  Accountability (Fowler) vOthers:  Testing (Firesmith)  Process patterns (Coplien)

5.  2001 Lodewijk Bergmans University of Twente Pattern System (defined by Buschman et.al.) A pattern system for software architecture is: vA collection of patterns for software architecture vGuidelines for:  implementation, combination & practical use of patterns Thus, must be: vUniform representaion vOrganize (relations between) patterns vSupport its own evolution Difference with pattern language?

6.  2001 Lodewijk Bergmans University of Twente Pattern Language Example: "Evolving Frameworks"

7.  2001 Lodewijk Bergmans University of Twente Three Examples How to start designing a framework? vdevelop abstractions by generalizing concrete examples (‘too hard’ the other way around) Therefore, develop three applications in the domain of the framework vthese should pay for themselves vcommon abstractions should become apparent vdevelop in parallel or sequential

8.  2001 Lodewijk Bergmans University of Twente White-box Frameworks Problem & Forces: Context: develop 2nd application Use inheritance or aggregration? vinheritance:  stronger coupling, static  modify (override) reused component vaggregation (polymorphic composition)  fixed interfaces (must anticipate changes)  dynamically change  more difficult to understand (statically) white-box

9.  2001 Lodewijk Bergmans University of Twente White-box Frameworks Solution Therefore, use inheritance vgeneralize classes in the individual applications to abstract superclasses  Move all the common behavior there vThis is the most straightforward way to distinguish special cases from general

10.  2001 Lodewijk Bergmans University of Twente Component Library Context: developing 2nd+ examples based on the white-box framework Problem: similar objects have to be written for each example vThese are hard to predict Therefore, develop library of reusable (?) objects as you need them

11.  2001 Lodewijk Bergmans University of Twente Hot Spots Context: vAdding components to component library Problem: vSimilar code written (overridden) repeatedly Forces: vChangeable code scattered: difficult to manage vChangeable code grouped: program flow continuously involves the changeable code (object) Solution????

12.  2001 Lodewijk Bergmans University of Twente Hot Spots Solution Separate code that changes from code that doesn't vEncapsulate varying code in objects when possible: Easier to reuse Many examples exist:  Which pattern separates algorithms?  Which pattern separates Implementations?  What does Observer separate?  What does Abstract Factory Separate?

13.  2001 Lodewijk Bergmans University of Twente Hot Spots Examples What varies? vAlgorithms:  Strategy & Visitor vImplementations:  Bridge vResponse to change:  Observer vObject being created:  Factory Method, Abstract Factory, Prototype

14.  2001 Lodewijk Bergmans University of Twente Pluggable Objects Context: Adding components to your library Problem: Subclasses differ in trivial ways vE.g. just one method redefined Forces: vcomplex parameterized classes difficult vMany new classes reduce overview Therefore, design adaptable subclasses vOffer interface to change parameters

15.  2001 Lodewijk Bergmans University of Twente Fine-Grained Objects Context: refactoring your component library to make it more reusable Problem: How far to go in dividing into smaller objects? Forces: vMore objects -> more difficult to manage vApplications can be created by composing objects that implement desired functionality Therefore, break into smallest useful objects and offer tools to provide the composition (and manage many objects)

16.  2001 Lodewijk Bergmans University of Twente Black-box Framework Context: developing Pluggable objects by encapsulating hot spots and making fine-grained objects Problem: rely on inheritance or aggregation ('polymorphic composition')? Therefore, use inheritance to organize your component library and aggregation to construct applications black-box

17.  2001 Lodewijk Bergmans University of Twente Finally: Two Tool patterns Visual Builder vGraphically compose the configuration of all the components in your black-box framework Language Tools vDedicated tools are needed to inspect & debug your 'domain-specific language' programs

18.  2001 Lodewijk Bergmans University of Twente SummarySummary  Pattern Language: A collection of patterns that build on each other to generate a 'system' Coherence: domain specific v'any knowledge domain' Relations must be explicit & constructive A pattern language is much more than the sum of its parts!

19.  2001 Lodewijk Bergmans University of Twente when 2 patterns are parallel on time line, they may go in arbitrary order

20.  2001 Lodewijk Bergmans University of Twente Composition in OO  OO Frameworks OO library = (micro-)architecture + collection of variations (classes) e.g. MVC “ S ociety is composed of two great classes: those who have more dinners than appetite, and those who have more appetite than dinners.” --Sebastian Chamfort-- + framework:

21.  2001 Lodewijk Bergmans University of Twente Composition in OO White-box frameworks White-box frameworks vinheritance-based vadapt reused class by :  adding methods & variables  overriding methods  self calls with dynamic binding Characteristics: vmore dependencies to the reused classes  because the subclasses have more access vAutomatic (cascaded) updates of an interface to the classes that reuse it vStatic, composition relation cannot be adapted at run-time white-box

22.  2001 Lodewijk Bergmans University of Twente Composition in OO Black-box frameworks Black-box frameworks vaggregation-based vcomposition-interface equals message interface vadapt reused class by:  adding methods & variables  redefining methods  selective reuse of interface methods Characteristics: + more robust; depends only on the invocation interface + Supports dynamic reconfiguration. - Requires explicit message forwarding for interface reuse  requires adding many extra methods, lacks the notion of 'self' black-box