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

S

© Siemens AG, 1998Frank Buschmann

ZT SE 2

Page 1

SE 2

Patterns

Frank BuschmannSiemens AG, Corporate Technology

Dept. Software & Engineering

[email protected]

S


ZT SE 2

Page 2

SE 2

Software Architecture

Many Concepts SupportSoftware 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


ZT SE 2

Page 3

SE 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


ZT SE 2

Page 4

SE 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

Proxy Broker

Bridge

Proxy*

** 0..1

View Controller

Client

CommunicationInfrastructure

UserInterface

FunctionalCore

Model

Persistence

1

11

1

1 1

Gotcha!

S


ZT SE 2

Page 5

SE 2

Let’s take a lookat a well-knownpattern

S


ZT SE 2

Page 6

SE 2

Observer (1)

Observer (GoF)

ProblemChanging 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 ondepends on

S


ZT SE 2

Page 7

SE 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

attachdetachnotifysetDatagetData

s->getData()

Observer

update

ConcreteObserver

updatedoSomething

state = X;

notify();

stateobserverList

for all observersin observerList do notify();

*

S


ZT SE 2

Page 8

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

Subject Observer 1 Observer 2

attach(this)

attach(this)

setDatanotify

update

getData

update

getData

S


ZT SE 2

Page 9

SE 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


ZT SE 2

Page 10

SE 2

Let’s Reflect

S


ZT SE 2

Page 11

SE 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


s->getData()

Observer

update

ConcreteObserver

updatedoSomething

state = X;notify();

stateobserverList


*Subject Observer 1 Observer 2

attach(this)

attach(this)

setDatanotify

update

getData

update

getData

ObserverHouse1 Door_A; Window_1a Window_1b ...

is presented as

depends ondepends on

Problem

Solution

S


ZT SE 2

Page 12

SE 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


s->getData()

Observer

update

ConcreteObserver

updatedoSomething

state = X;notify();

stateobserverList


*Subject Observer 1 Observer 2

attach(this)

attach(this)

setDatanotify

update

getData

update

getData

ObserverThe Process

The “Thing”

1. Identify the Subject2. Identify the Observers3. Add registration functionality to the Subject4. Add Observer repository to the Subject5. Add update functionality to the Observers6. Implement the Subject’s Change Propagation Mechanism

S


ZT SE 2

Page 13

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

ObserverForce 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


ZT SE 2

Page 14

SE 2

Object-Technology

Patterns are NOT NecessarilyObject-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


Observer

updatedoSomething

stateobserverList

*

S


ZT SE 2

Page 15

SE 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


Observer

update

ConcreteObserver

updatedoSomething

stateobserverList

2 Observer Design Options

Subject

notifysetDatagetData

Observer

update

ConcreteObserver

updatedoSomething

state

Event Channel

attachdetachnotify

*

observerList

*

1 1

S


ZT SE 2

Page 16

SE 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

errorUse in Siemens:

• Engine Control

• Switches: Fault Management

S


ZT SE 2

Page 17

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

attachObsdetachObsnotifygetDataservice

observerscoreData

Controller

inithandleEventupdate

myModelmyView

View

initmakeControlleractivatedisplayupdate

myModelmyController

1 1

S


ZT SE 2

Page 18

SE 2

Experiences

S


ZT SE 2

Page 19

SE 2

Projects

Project Experience @ Siemens

• Hot Rolling Mill Process Automation

• Medical Imaging

• Network Management

• Passenger Information

• Car Dealing

• Warehouse Management

• Object Request Brokers

• many more

S


ZT SE 2

Page 20

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

DoorBinComposite

Storage

*

Equipment

AbstractIterator

AbstractVisitor

*

AbstractStrategy

LoadInLayers LeafsOnly Occupation

SOC

1

1

StorageManager

*

TelegramOffice

1

AbstractStorage

DBMSStorageOriginal

TelegramFactory

S


ZT SE 2

Page 21

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

DoorBinComposite

Storage

*

Equipment

AbstractIterator

AbstractVisitor

*

AbstractStrategy

LoadInLayers LeafsOnly Occupation

SOC

1

1

StorageManager

*

TelegramOffice

1

AbstractStorage

DBMSStorage

Original

TelegramFactory

S


ZT SE 2

Page 22

SE 2

Benefits

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


ZT SE 2

Page 23

SE 2

Problems

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


ZT SE 2

Page 24

SE 2

Lessons Learned

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


ZT SE 2

Page 25

SE 2

The End

S


ZT SE 2

Page 26

SE 2

References (1)

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


ZT SE 2

Page 27

SE 2

References (2)

ReferencesM. Fowler: Analysis Patterns, Addison-Wesley,

1997

K. Beck: Smalltalk Best Practice Patterns, Prentice Hall, 1997

J.O. Coplien: Advanced C++ Styles and IdiomsAddison-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 Pagehttp://www.hillside.net/patterns/

S


ZT SE 2

Page 28

SE 2

Questions?

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

Documents