S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 1 S E 2 Patterns Frank Buschmann Siemens AG, Corporate Technology Dept. Software & Engineering

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 2 S E 2 Software Architecture Many Concepts Support Software Architecture Processes, such as the Unified Software Development Process; Notations, such as UML; Technologies, such as frameworks and distributed object computing; Enabling Techniques like separation of concerns; and Programming paradigms, such as object technology. Each approach addresses a specific aspect in the process of constructing high-quality software architectures.

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 3 S E 2 Technologies and Systems However all these concepts do not tell you how to solve a very specific problem that arises during the construction of a particular software system. For example, how to keep two cooperating components consistent to each other, or how to organize the event handling in a distributed system? Solving such problems is still left to your own intuition and experience in software construction.

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 4 S E 2 Experts Know Solutions That Work Experts Do Not Construct Solutions When experts work on a particular problem it is unusual for them to tackle it by inventing a new solution that is completely distinct from existing ones. Experts know, from their own and others experience, a large body of proven solutions to many design problems. Confronted with a ‘new’ problem they often remember a similar one they once solved successfully and adapt the ‘old’ solution to the new context. Experts think in Problem/Solution pairs! Proxy DBMS ProxyBroker Bridge Proxy * ** 0..1 ViewController Client Communication Infrastructure User Interface Functional Core Model Persistence Gotcha!

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 5 S E 2 Let’s take a look at a well-known pattern

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 6 S E 2 Observer (1) Observer (GoF) Problem Changing the internal state of a component may cause inconsistencies to the state of other components. How can we restore consistency effectively in a way that: the information provider must not depend on information consumers; and the information consumers that depend on the information provider must not be known a priori. House1 Door_A; Window_1a Window_1b... is presented as depends on

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 7 S E 2 Observer (2) Solution-Structure Implement a change propagation mechanism between the information provider, the subject, and the information consumers, the observers. The Subject maintains a registry of observers and notifies all registered observers about changes to its state. An Observer declares an update function to be called by the subject’s change propagation mechanism. Concrete Observers implement the update function in an observer-specific manner. Subject attach detach notify setData getData s->getData() Observer update ConcreteObserver update doSomething state = X; notify(); state observerList for all observers in observerList do notify(); *

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 8 S E 2 Observer (3) Solution-Dynamics The Observers register with the subject’s change propagation mechanism. A Client modifies the subject’s data. The Subject starts its change propagation mechanism. The Subject calls the update function of every registered observer. The Observers retrieve the changed data from the subject and update themselves. SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 9 S E 2 Observer (4) Benefits Defined handling of dependencies between otherwise strongly coupled components Support for dynamic configuration of a subject with observers Adding new observers does not affect the subject or the change propagation mechanism Liabilities Indirection Unnecessary updates Update cascades

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 10 S E 2 Let’s Reflect

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 11 S E 2 Properties A Pattern presents a concrete solution schema for recurring design problems; documents proven design experience; specifies concepts above the level of individual classes and objects; describes structure and behavior of cooperating objects; provides a common vocabulary and concept understanding; and addresses specific quality properties of the problem’s solution. Subject attach detach notify setData getData s->getData() Observer update ConcreteObserver update doSomething state = X; notify(); state observerList for all observers in observerList do notify(); * SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData Observer House1 Door_A; Window_1a Window_1b... is presented as depends on Problem Solution

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 12 S E 2 Process and Thing Pattern are both: A Process and A Thing every pattern tells you what to do, in terms of the structure to create and the behavior that performs in this structure; and it tells you how to do it, by providing a process that helps creating the structure. Subject attach detach notify setData getData s->getData() Observer update ConcreteObserver update doSomething state = X; notify(); state observerList for all observers in observerList do notify(); * SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData Observer The Process The “Thing” 1. Identify the Subject 2. Identify the Observers 3. Add registration functionality to the Subject 4. Add Observer repository to the Subject 5. Add update functionality to the Observers 6. Implement the Subject’s Change Propagation Mechanism

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 13 S E 2 Forces Forces: The Heart of Every Pattern complete the general problem; describe requirements, constraints, and desired properties to the solution; influence the concrete solution; tell you why the problem is a hard problem; tell you why the solution is as is and not something different. Observer Force 1: The information provider must not depend on information consumers. Solution: All Observers share the update() interface. Force 2: The information consumers that depend on the information provider must not be known a priori. Solution: Subject provides registration and unregistration functionality; Change propagation mechanism only calls the “anonymous” update() function.

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 14 S E 2 Object-Technology Patterns are NOT Necessarily Object-Oriented Object technology simplifies the implementation of a pattern, but is not essential. Instead of using inheritance you may use C function pointers, for example, to implement the change propagation mechanism of Observer. Many other patterns, such as Layers, do not build on object technology at all. Subject attach detach notify setData getData Observer update doSomething state observerList *

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 15 S E 2 Genericity Patterns are Generic No two implementations of a pattern are likely to be the same. A pattern provides a generic solution schema. It is not carved in stone. A pattern is a mental design aid. You should be able to reuse the solution schema a million times over, each implementation being different, but all of them sharing the essential core. A pattern introduces roles, NOT classes! Subject attach detach notify setData getData Observer update ConcreteObserver update doSomething state observerList 2 Observer Design Options Subject notify setData getData Observer update ConcreteObserver update doSomething state Event Channel attach detach notify * observerList * 11

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 16 S E 2 Scale and Abstraction Pattern Categories Architectural patterns express fundamental structural organizations of systems into subsystems. Design patterns help with refining subsystems and components of a software system, or the relationships between them. Idioms are low-level patterns specific to a programming language. Analysis patterns describe how work is organized in a specific domain. Organizational patterns describe how software development should be organized. Leaky Bucket Counter (by James Coplien et al.) Problem: Distinction between transient and hard errors that may occur on a unit. Solution: Provide the unit to be observed with an error-counter, initialized with 0. Whenever an error occurs, increase the counter by 1. If the counter reaches a unit- specific threshold, issue an alarm. If no error occurs for a unit-specific period of time, decrease the counter by 1. threshold leak error Use in Siemens: Engine Control Switches: Fault Management

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 17 S E 2 Relationships Pattern Relationships Refinement. For example, Observer can be used to refine the relationship between the model and its views. Combination. For example, Proxy can be combined with Forwarder-Receiver on the same level of abstraction to provide the stub concept. Variation. For example, Event Channel is a variation of Observer. * Observer update Model (Subject) attachObs detachObs notify getData service observers coreData Controller init handleEvent update myModel myView View init makeController activate display update myModel myController 11

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 18 S E 2 Experiences

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 19 S E 2 Projects Project Siemens Hot Rolling Mill Process Automation Medical Imaging Network Management Passenger Information Car Dealing Warehouse Management Object Request Brokers many more

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 20 S E 2 Observation (1) Using Patterns may lead to Frameworks For most projects the primary goals were extensibility and adaptability. Through careful ‘design for evolution and change’ we received software architectures that are stable in their core, yet being extensible with new structures, modifiable with respect to existing structures, and adaptable to customer- specific requirements. In other words, we ended with frameworks. DoorBin Composite Storage * Equipment Abstract Iterator Abstract Visitor * Abstract Strategy LoadInLayersLeafsOnlyOccupation SOC 1 1 Storage Manager * Telegram Office 1 Abstract Storage DBMS Storage Original Telegram Factory

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 21 S E 2 Observation (2) One Size Does Not Fit All Patterns alone are NOT sufficient enough for building systems that meet today’s tough requirements. DOC provides the communication infrastructure. Frameworks support building architectures for system families. Patterns help designing the frameworks. Components help configuring the frameworks to a customer-specific application. DoorBin Composite Storage * Equipment Abstract Iterator Abstract Visitor * Abstract Strategy LoadInLayersLeafsOnlyOccupation SOC 1 1 Storage Manager * Telegram Office 1 Abstract Storage DBMS Storage Original Telegram Factory

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 22 S E 2 Benefits Solutions to design problems are based on well-proven standard concepts. Consideration of alternatives are possible. Explicit consideration of non-functional aspects. Improved communication. Improved documentation. Knowledge is available to the whole organization.

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 23 S E 2 Problems Hype. Finding the right patterns is not always easy. Implementing a pattern correctly needs some experience. Using patterns does not necessarily result in a high-quality design. People often see patterns as blueprints.

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 24 S E 2 Lessons Learned Patterns help, but are no silver bullet. Patterns complement but do not replace existing technology and methods. Education is crucial for success. Don’t force developers in using the patterns. Apply patterns carefully. JUST DO IT!

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 25 S E 2 The End

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 26 S E 2 References (1) References C. Alexander: The Timeless Way of Building, Oxford University Press, 1979 M. Fowler: UML Distilled, Addison-Wesley, 1997 R.P. Gabriel: Patterns of Software, Oxford University Press, 1996 E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns – Elements of Reusable Object-Oriented Software, Addison- Wesley, 1995 Various Eds. : Pattern Languages of Program Design, Vol. 1- 3, Addison-Wesley, 1995, 1996, 1997 F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture—A System of Patterns, John Wiley and Sons, 1996

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 27 S E 2 References (2) References M. Fowler: Analysis Patterns, Addison-Wesley, 1997 K. Beck: Smalltalk Best Practice Patterns, Prentice Hall, 1997 J.O. Coplien: Advanced C++ Styles and Idioms Addison-Wesley, 1992 D. Lea: Concurrent Programming in Java, Design Principles and Patterns, Addison- Wesley, 1997 J. Vlissides: Pattern Hatching, Addison-Wesley, coming soon The Patterns Home Page

S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 28 S E 2 Questions?