Markus Völter voelter@acm voelter.de

1. The Role of Patterns in Modern Software Engineering Markus Völtervoelter@acm.orgwww.voelter.de

2. About me Markus Völter voelter@acm.org www.voelter.de • Independent Consultant • Based out of Heidenheim, Germany • Focus on • Software Architecture • Middleware • Model-Driven SoftwareDevelopment

3. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

4. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

5. Introduction • Today patterns are not a hype anymore. • Patterns themselves are not a selling point anymore – what counts is the actual content. • A while ago, any book with “patterns” on it sold well • Today, there are books on certain topics that use the notion of patterns to make their point: • Evans: Domain-Driven Development • Binder: Testing Object-Oriented Systems • I think this is good. • Patterns have become a tool for the software developer, comparable to programming languages:very important, but nobody makes a fuzz about them (anymore) • And in both areas, there are exceptions 

6. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Patterns as a form of literature • Using Patterns to Architect Systems • Summary

7. Well-Known complex technical domains • Patterns are used do document well-known solutions in domains have been worked on in IT for a long time. • Examples include • Distributed Objects Systems [POSA2] • Resource Management [POSA3] • Patterns of Enterprise Application Architecture [PoEAA] • Enterprise Integration Patterns [EIP], Integration Patterns [IP] • As of their nature, these patterns are interesting to a large number of developers; thus, they are typically documented in book form.

8. Well-Known functional domains • Also, functional domains use patterns for documenting their best practices. • Some of these patterns aren’t published at all for reasons of competitive advantages • I know of patterns for • Telecoms • Safety-Critical Software • Mobile Phone Infrastructure • …

9. New Technologies • New and promising technologies use patterns to document the experience (of typically few) experienced developers to help others learn the topic – and thus spread the new technology • Examples include • Model-Driven Software Development [MDSD] • Aspect-Oriented Software Development [AOP, AOP-MDSD] • You’ll find those patterns typically in the proceedings of patterns conferences, or at the conferences for the respective technologies (AOSD).

10. How to use in Software Engineering…? • For people who work in the respective domain or with the respective technology, the patterns help to solve certain key problems they might stumble about when working in the domain. • For newbies who want to “get into” the respective domain or technologythe patterns help to understand the structure, challenges, key issues and proven solutions; i.e. the patterns help learning to master the domain

11. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

12. Inner Structures of complex Systems • Pattern Languages are collections of patterns that describe a “whole”, • The overall structure is too complicated to be described in one pattern – thus the language. • Sometimes there are alternative sequences through the pattern language describing various alternatives of the “whole” • A pattern language thus describes how to build sich a complex system of a certain type • There are various examples of such pattern languages, • Many cover middleware technology [SCP, REMO] , and • They are published in various forms

13. Example: Remoting • Describes the internal architecture of remoting middleware such as CORBA, WebServices or .NET Remoting [REMO] • It can be seen as a pattern language thatdescribes the internal workings of Brokerarchitectures in industrial practice.

14. Example: Remoting II • Basic Remoting Infrastructures

15. Example: Remoting III: Server Request Handler • Context: You are providing remote objects in a server application, and invokers are used for message dispatching • Problem: • The request message has to be received from the network; • Managing communication channels efficiently and effectively is essential • Network communication needs to be coordinated and optimized • Solution: • Server request handler deals with all communication issues of a server application: • Receives messages from the network • Combines the message fragments to complete messages • Dispatches the messages to the correct invoker • Manages all the required resources (connections, threads, …)

16. Example: Remoting IV: Server Request Handler 2

17. Example: Remoting V • Basic Remoting Infrastructures

18. Example: Remoting VI • Interactions

19. Example: Remoting – Technology Projection; .NET Example

20. Example: Remoting - Identification

21. Example: Remoting - Lifecycle

22. Example: Remoting - Extension

23. Example: Remoting – Extended Infrastructure

24. Example: Remoting – Asynchrony

25. How to use in Software Engineering…? • You can use those pattern languages to gain a deep understanding of the respective type of system. • Typically, those PL’s are described in a technology-independent fashion; so the PL teaches the concepts and principles, and not the technology. • This is necessary in case you may have to build such a system yourself – maybe for an environment (embedded?) where such technology is not available off-the-shelf. • PL’s also often help to compare different technologies/implementations since they are (usually) technology independent.

26. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

27. Interesting Aspects of new paradigms • Patterns are used as a form for describing best practices for using new or emerging paradigms • Aspect Oriented Programming (Arno’s Work) • Patterns for Model-Driven Development (my own) • The well known (often GoF-Patterns) are used to describe the structure of new Frameworks and tools (such as the Spring framework)

28. Example: MDSD Patterns • Collects industrybest practices formodel-driven softwaredevelopment and MDA;see [MDSD] • They cover • Process issues • Tool architecture • Domain modelling • Application Platformdevelopment (trans-formations, generators)

29. How to use in Software Engineering…? • If you work with the new paradigm, you can use the patterns to get a feel of how this new paradigm can be used efficiently. • You typically don’t find these things in the beginner’s tutorials • Or, if you have a problem with the tool or paradigm, you can use the patterns to find a solution.

30. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

31. Use of Patterns in Tools • Tool support for patterns in mainly relevant for modelling, transformation and code generation tools. • There are various forms of how patterns can be used in tools, however, all have the following aspects in common: • The pattern is reduced to it’s “solution UML diagram”. • The tools never consider applicability, consequences and the forces. • It’s up to the tool users (or, in the case of generators) of the tool designers to decide which pattern to use when.

32. Use of Patterns in Tools: Classical UML Tools • You can select a pattern from a patterns’ palette. • Typically, the GOF patterns are supported, as well as a couple of technology-specific ones. • You then define which model elements play which of the pattern’s role. • The tool then “implementes” the pattern by • Creating additional model elements, • Modifying the role players according to the pattern’s role definitions

33. Use of Patterns in Tools: Simple MDA Tools • The term “pattern” is used here more in the sense of template, i.e. a template that defines how to “expand” a certain model element to another one. • This is relevant specifically in the PIM to PSM transformation world, where (simple) expansion patterns define the transformation • i.e. a UML class stereotyped “Entity Bean” is expanded into a Class with stereotype “Seployment Descriptor”, “Remote Interface” and “Bean Implementation”

34. Use of Patterns in Tools: Code Generators • In code generators, the generated code has to be structured reasonably • people have to use it for debugging • It has to perform acceptably • Sometimes it has to be runtime-flexible • So, the well known patterns are used in the generated code. • The generator developer decides about a pattern’s use. • In most cases the use of the pattern is not visible in the generator input (i.e. the model)

35. Use of Patterns in Tools: Domain-Specific Languages • Sometimes it is necessary to let the generator user (i.e. the application developer) choose whether to use a certain pattern, or at least specify how to use the pattern. • Often these patterns aren’t really patterns, but rather certain structures and behavior defined in the metamodel • In that case you will not expose the patterns implementation structure to the model (generator input) layer. • Rather you use specific notations in the model to denote the pattern’s use (tags, stereotypes, UML 2 collaborations).

36. How to use in Software Engineering…?

37. How to use in Software Engineering…? cont‘d • In all cases be advised that you rather use the pattern solution. Patterns, however, are much more: • Context, applicability, forces, consequences, etc. • All these things typically get lost when a pattern is supported in tools.

38. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

39. Use of Patterns in Tools: Code Generators • If you come up with certain recurring best practices in your domain (technical or functional) you may want to write these down as patterns. • The pattern forms (there are various forms) all have in common that they require the author to structure the content very strictly. • This forces the author to think hard about stuff such as applicability, forces or consequences • For readers, well-structured content becomes easier to comprehend

40. How to use in Software Engineering…? • Writing things up in pattern form improves the effectiveness of communication, provides a means to break down complex structures and generally improves writing style. • Once you’re accustomed to the patterns form, you will use it implicitly when writing any kind of technical documentation, i.e. • Start by setting the context, • Explain when and for who the following stuff is interesting • Describe the problem and the solution • And then elaborate on the consequences. • Finally, you’ll point to related material

41. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

42. Architectural Patterns • Architectural patterns can be used to describe well-working architectural styles and blueprints. • Many have been described in the POSA series books, for example, specifically in [POSA1]. • Examples include • Blackboard • Pipes and Filters • Microkernel • Components & Connectors

43. How to use in Software Engineering…? • Architictural Patterns serve as fix points in the design space of an architecture. • You understand the requirements • You design an initial architecture • You find it resembles a certain architectural pattern • You analyze the differences. Are they essential? • You then use the patterns consequences to see if they are acceptable. • Then you may want to iterate… until you maybe hit another pattern in the architectural design space. • When using MDSD, architectural patterns can be used as a basis for architectureal metamodels. • The solution of an architectural patterns can be described as a metamodel.

44. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary

45. Summary • Patterns are everywhere. They have moved into many domains and “corners” where you’d not expect them. • Maybe we could summarize: • The less hyped uses of patterns (architecture, writing your own patterns) • are more important than the hyped ones (“our UML tool comes with patterns support”).

46. C O N T E N T S • Introduction • Describing challenges of systems in certain domains • Describing the structures of certain kinds of systems • Describing interesting aspects of new paradigms • Use of Patterns in Tools • Writing your own patterns • Using Patterns to Architect Systems • Summary THE END. THANK YOU!

47. References • AOP Arno Schmidmeier, various AOP Patterns, available through www.aspectsoft.de • AOP-MDSD Markus Voelter, Patterns for Handling Cross-Cutting Concerns in MDSD, http://www.voelter.de/data/pub/ModelsAndAspects.pdf • EIP Gregor Hohpe, Bobby Woolf; Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions; Addison-Wesley 2003 • IP Integration Patterns, Microsoft Corporation, 2004 • MDSD Markus Voelter, Patterns for Model-Driven Software Development; http://www.voelter.de/data/pub/MDDPatterns.pdf • PoEAA Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley 2002 • POSA1 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Peter Sommerlad, Michael Stal; Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, Wiley 1996 • POSA2 Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann; Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects; Wiley 2000 • POSA3 Michael Kircher, Prashant Jain; Pattern-Oriented Software Architecture, Volume 3, Patterns for Resource; Management, Wiley 2004 • REMO Voelter, Kircher, Zdun; Remoting Patterns; Wiley 2004 • SCP Voelter, Schmid, Wolff; Server Component Patterns; Wiley 2002