Markus Völter voelter@acm voelter.de

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2 0 0 5 M a rk u s V ö l t e r. - 1 -

The Role of Patterns in Modern Software Engineering

Markus Vö[email protected]

The Role of Patterns The Role of Patterns in Modern Software in Modern Software

EngineeringEngineering



Markus Völter

[email protected]

www.voelter.de

• Independent Consultant

• Based out of Heidenheim, Germany

• Focus on

• Software Architecture

• Middleware

• Model-Driven SoftwareDevelopment

About me



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



C O N T E N T S

• Introduction







• Summary



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



C O N T E N T S

• Introduction





• Patterns as a form of literature


• Summary



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.



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

• …



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


• 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).



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 technology

the patterns help to understand the structure, challenges, key issues and proven solutions; i.e. the patterns help learning to master the domain



C O N T E N T S

• Introduction







• Summary



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



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.

Process A

Client

Requestor

Mac

hine

Bou

ndar

yProcess B

Invoker

RemoteObject

Marshaller

1) submit request

2) marshal request 3) forward

Marshaller

4) unmarshal

5) invoker operation



Example: Remoting II

• Basic Remoting Infrastructures

INVOKER

disp

atch

esin

voca

tion

to

CLIENT PROXYMARSHALLER

uses f

or

marshallin

g

requests

uses for

de-marshalling

requests

INTERFACE DESCRIPTION

disp

atch

esre

ques

ts to

desc

ribes

inter

face

of describes

interface of

CLIENT REQUEST

HANDLERuses to

send

request

SERVER REQUEST

HANDLERcommunicates

with

REQUESTOR

uses to build

up request

REMOTING

ERROR

raises

raisesraises

raise

s

Remote Object



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, …)



Example: Remoting IV: Server Request Handler 2

Client Process Server Process

InvokerInvokerInvoker

Server RequestHandler

Mac

hine

Bou

ndar

y

OS APIsconnection

pool

thread pool

ClientProxyClientProxyRequestor

Client RequestHandler



Example: Remoting V

• Basic Remoting Infrastructures

ServerClient

Client

Requestor

Client RequestHandler

Server RequestHandler

Invoker

RemoteObject

invocation messages

result messages

invocation data

result data

invocation

result

Marshaller Marshaller

ClientProxy

invokeoperation

invokeoperation

forwardmessage

forwardmessage

Ap

plic

atio

nL

aye

rIn

voc

atio

nL

aye

rM

ess

agin

g/

Re

qu

est

Lay

er



Example: Remoting VI

• Interactions

<<create>>

ServerRequestHandler

<<receive>>

m:Message

<<create>>

Invoker

invoke(m)

Marshalleri:Invocation

DataRemoteObject

invokeMethod(i)

someMethod(x)

i := unmarshal(m)



Example: Remoting – Technology Projection; .NET Example

REMOTE

OBJECT

Client Server

Client

Real Proxy

.NET Runtime .NET Runtime

invocation msg

FormatterSink

TransparentProxy

Ap

p.

Lay

er

Invo

cati

on

Lay

erM

essa

gin

g/

Req

ues

t L

ayer

Channel Sink

Sink

Channel Sink

FormatterSink

Sink

DispatcherSink

RemoteObject

result msg

INTERFACE

DESCRIPTION

ServerApp

DISCOVERY

INVOKER

LIFECYCLE

MANAGER

CLIENT PROXY

REQUESTER

INVOCATION

INTERCEPTOR

INVOCATION

CONTEXT

MARSHALLER

PROTOCOL

PLUGINS

CLIENT

REQUEST

HANDLER

SERVER

REQUEST

HANDLER



Example: Remoting - Identification

Remote Object

ABSOLUTE OBJECT

REFERENCE

maps properties to

OBJECT ID

identifies

is part of

uniquely identifie

s

REQUESTOR

uses

LOOKUP

Clientlo

oks

upob

ject

s in

SERVER

APPLICATION

regi

ster

sob

ject

s in

INVOKER

cons

truc

ts

assigns uses



Example: Remoting - Lifecycle

STATIC INSTANCE PER-REQUEST INSTANCECLIENT-DEPENDENT

INSTANCE

LAZY ACQUISITION

o pti m

i ze s

implie

s

POOLING

o pti m

i ze s

LEASING

requiresoptim

izes

Client

instantiates

instantiates

SERVER APPLICATION

instantiates

LIFECYCLE MANAGER

PASSIVATIONmay usemay use



Example: Remoting - Extension

INVOCATION

INTERCEPTOR

transports

creates/uses

trans

ports

communicates w ith

INVOCATION CONTEXT

Client

SERVER REQUEST

HANDLER

CLIENT REQUEST

HANDLER

INVOKERREQUESTOR

pluged into

provideshooks for

PROTOCOL

PLUG-IN

pluged into

uses

usesuses

uses

provides

hooks for

CLIENT

PROXY

uses

uses

Remote Object



Example: Remoting – Extended Infrastructure

Remote Object

grou

ps and

orga

nizes

sets o

f

LIFECYCLE MANAGER

man

ages

lifec

ycle

for

monitors

CONFIGURATION

GROUP

LOCAL OBJECT

QOS OBSERVER

optim

izes

reso

urc

eco

nsum

ptio

n

mon

itors

REQUEST HANDLER

INVOKER

mon

itors

appears likeim

plemented as

SERVER APPLICATION

LOCATION

FORWARDER

provides location

transparency for

ABSOLUTE OBJECT

REFERENCE

upda

tes

clie

nt's



Example: Remoting – Asynchrony

FIRE AND FORGET SYNC WITH SERVERextends reliably

POLL OBJECT RESULT CALLBACK

MESSAGE QUEUEprovides result viaprovid

es resu

lt via

extends with result

REQUEST HANDLER

queuingrequests and

responses

alternatives

extends with

result




• 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.



C O N T E N T S

• Introduction







• Summary



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)



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)

Iterative Dual-TrackDevelopment

Scope Tradingbenefits from

Validate Iterations

controlledby

Extract theInfrastructure

precedes

Process &Organization

Formal Metamodel

leadsto

Architecture-Centric Metamodel (P)

specializes

DomainModelling

Implementthe Metamodel

requires

Ignore ConcreteSyntax

simplifiedby

ToolArchitecture

Two StageBuild

Separate Generatedand Non-Generated Code

Rich Domain-SpecificTarget Platform

evolvesinto

TechnicalSubdomains

consistsof

Model-DrivenIntegration

is specialcase of

Produce Nice-Looking code...

whenever possible

DecriptiveMetamobjects

benefits from

Generator-Based AOP

ApplicationPlatform

Development

precedes

Fixed BudgetShopping

Basketmodifiescontent

poceed tocheckout

Modular,AutomatedTransforms simplified

by

GeneratedReflectionLayer (P)

part of

GatewayMetaclasses (P)

uses

ExternalModel

Markings (P)

simplifies Leveragethe Model (P)

uses

Select fromBuy, Build or

Open Source (P)

balances

uses

Build aWorkflow (P)

Believe inReincarnation (P)

Gentime/Runtime

Bridge (P)

Gentime/Runtime

Bridge (P)

simplifies

Talk Metamodel (P)

validates

cansimplify




• 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.



C O N T E N T S

• Introduction







• Summary



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.



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



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”



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)



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).




Tool Kind Is this useful? Should it be used in SW-Engineering?

Classical UML Tools

Not very useful, since the “pattern meta information” gets lost – you usually cannot easily reverse the pattern’s applicationIf you want to generate code from that, why do you want to see all the details in your model?

Simple MDA Tools

Not very useful, since non-trivial transformations cannot be expressed by simple template/pattern expansion.Specifically, a query mechanism is missing

Code Generators

Very useful, the quality of the generated code improves. Often, it also helps to simplify the generator design

DSLs Very useful, it helps to make the DSLs more understandable and brief



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.



C O N T E N T S

• Introduction







• Summary



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




• 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



C O N T E N T S

• Introduction







• Summary



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].


• Blackboard

• Pipes and Filters

• Microkernel

• Components & Connectors




• 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.



C O N T E N T S

• Introduction







• Summary



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”).



C O N T E N T S

• Introduction







• SummaryTHE END.

THANK YOU!



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

Markus Völter voelter@acm voelter.de

Documents

Transcript of Markus Völter voelter@acm voelter.de