Softwaretechnologie für FortgeschritteneTeil Thaller

Stunde IV: Software Engineering I

Köln 24. Januar 2013

Systemdesign / Systemplanung

(1) Entsteht Software, entstehen Informationssysteme als Ergebnis eines künstlerischen Prozesses?

(2) Oder sind sie planbar?

01:55 2

Ein ernstes Problem …

Erfolg von IT Projekten laut Umfragen:

• 45,2 % aller Softwareprojekte erfolgreich.• 19,4 % Zeit- und Kostenüberschreitungen.• 35,4 % Fehlschläge.

01:55 3

Ein ernstes Problem …

In Abhängigkeit von der Teamgröße.Erfolgreiche Projekte bei einer Teamgröße von:

• Bis 4 Personen 60 %• 4 – 8 Personen 38 %• 8 – 20 Personen 32 %• Mehr als 20 Personen 18 %01:55 4

Ein ernstes Problem …

01:55 5

Design Patterns

(1) Eine „Kunstlehre“, die auf der Objektorientierung aufsetzt ...

(2) … so verbreitet, dass ich mir erlaubt habe, zwei sehr geringfügig modifizierte Vorlesungsfolien auswärtiger Kollegen zu benutzen.

01:55 6

Design Patterns

John Reekiejohn.reekie@uts.edu.au

Software Architecture 4843321st August 2003

Background

Gamma, Helm, Johnson, and Vlissides (the “Gang of Four”) – Design Patterns, Elements of Reusable Object-Oriented SoftwareThis book solidified thinking about patterns and became the seminal Design Patterns textSoftware design patterns are based (somewhat) on work by the architect Christopher Alexander

01:55 8

Purpose

A design pattern captures design expertise –patterns are not created from thin air, but abstracted from existing design examplesUsing design patterns is reuse of design expertiseStudying design patterns is a way of studying how the “experts” do designDesign patterns provide a vocabulary for talking about design

01:55 9

Why design patterns in SA?

If you’re a software engineer, you should know about them anywayThere are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: Mowbray and Malveau – CORBA Design

Patterns Schmidt et al – Pattern-Oriented Software

Architecture

Design Patterns help you break out of first-generation OO thought patterns

01:55 10

The seven layers of architecture*

Global architectureEnterprise architecture

System architecture

Application architecture

Macro-architecture

Micro-architecture

Objects

* Mowbray and Malveau

ORB

OO architecture

Frameworks

Subsystem

Design patterns

OO programming01:55 11

How patterns arise

ProblemProblem

Context

SolutionSolution

Benefits

Related Patterns

Consequences

Forces

01:55 12

Structure of a pattern

NameIntentMotivationApplicabilityStructureConsequencesImplementationKnown UsesRelated Patterns

01:55 13

Key patterns

The following patterns are what I consider to be a good “basic” set of design patternsCompetence in recognizing and applying these patterns will improve your low-level design skills(The slides are necessarily brief and do not follow the structure just given above!)

01:55 14

Composite

ComponentOperation()Add(Component)Remove(Component)

CompositeOperation()Add(Component)Remove(Component)

LeafOperation()

Client

children

0..*

For all c in children c.Operation();

Construct part-whole hierarchySimplify client interface to leaves/compositesEasier to add new kinds of components

01:55 15

Composite (2)

Figurepaint()translate()getBounds()

CompositeFigurepaint()addFigure(Figure))removeFigure(Figure))

BasicFigurepaint()

Viewchildren

0..*

For all c in children c.paint();

Example: figures in a structured graphics toolkit

LabelFigurepaint()

0..*

Controller

parent

01:55 16

FacadeProvide unified interface to interfaces within a subsystemShield clients from subsystem componentsPromote weak coupling between client and subsystem components

FacadeClient

01:55 17

Façade (2)

Entity

CompositeEntityAtomicEntity

PortRelation

BufferedRelation

GraphSchematicEditor

Example: graph interface to a simulation engine

Actor

Director0..*

2

Token

01:55 18

Strategy

StrategyOperation()

ConcreteStrategy2Operation()

Context

Make algorithms interchangeable---”changing the guts”Alternative to subclassingChoice of implementation at run-timeIncreases run-time complexity

ContextInterface()

ConcreteStrategy1Operation()

01:55 19

Strategy (2)

ConnectorRouterShape recalculate(Pt, Pt)

ArcRouterShape recalculate(Pt, Pt)

Connectorroute()

StraightRouterShape recalculate(Pt, Pt)

ManhattanRouterShape recalculate(Pt, Pt)

shape=router.recalculate(start,end);redraw(shape);

Example: drawing different connector styles

01:55 20

ObserverMany-to-one dependency between objectsUse when there are two or more views on the same “data”aka “Publish and subscribe” mechanismChoice of “push” or “pull” notification styles

Observerupdate()

Subjectattach(Observer)detach(Observer)notify()

ConcreteObserverupdate()

ConcreteSubjectgetState()

state=subject.getState();

forall o in observers o.update()

01:55 21

Factory Method

CreatorProduct createProduct()

Product

Defer object instantiation to subclassesEliminates binding of application-specific subclassesConnects parallel class hierarchiesA related pattern is AbstractFactory

operation()

ConcreteCreatorProduct createProduct()

ConcreteProductoperation()

return new ConcreteProduct();01:55 22

Factory Method (2)Example: creating manipulators on connectors

FigurecreateManipulator()

0..1Manipulator

attach(Figure)

ArcManipulatorattach(Figure)

BoundsManipulatorattach(Figure)

ConnectorcreateManipulator()

RectFigurecreateManipulator()

manip = new BoundsManipulator();

manip = new ArcManipulator();

Interactor

01:55 23

Chain of Responsibility

HandlerhandleRequest()

ConcreteHandler2handleRequest()

ClientContextInterface()

ConcreteHandler1handleRequest()

Decouple sender of a request from receiverGive more than one object a chance to handleFlexibility in assigning responsibilityOften applied with Composite

successor

01:55 24

Chain of Responsibility (2)

FigurehandleEvent(Event)

CompositeFigure

Interactorchildren

0..*

If interactor != null interactor.handle(event,this)else parent.handleEvent(event)

0..1

parent

Example: handling events in a graphical hierarchy

handle(Event,Figure)

0..*

01:55 25

Patterns vs “Design”

Patterns are design But: patterns transcend the “identify

classes and associations” approach to design

Instead: learn to recognize patterns in the problem space and translate to the solution

Patterns can capture OO design principles within a specific domainPatterns provide structure to “design”

01:55 26

Patterns vs Frameworks

Patterns are lower-level than frameworksFrameworks typically employ many patterns: Factory Strategy Composite Observer

Done well, patterns are the “plumbing” of a framework

01:55 27

Patterns vs Architecture

Design Patterns (GoF) represent a lower level of system structure than “architecture” (cf: seven levels of A)Patterns can be applied to architecture:

Mowbray and Malveau Buschmann et al Schmidt et al

Architectural patterns tend to be focussed on middleware. They are good at capturing:

Concurrency Distribution Synchronization

01:55 28

Online resources

Pattern FAQ http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html

Patterns home page http://hillside.net/patterns/

Beispiel einer (GUI) “Pattern Library”

http://www.welie.com/patterns/showPattern.php

01:55 29

Concluding remarks

Design Patterns (GoF) provide a foundation for further understanding of: Object-Oriented design Software Architecture

Understanding patterns can take some time Re-reading them over time helps As does applying them in your own designs!

01:55 30

Herzlichen Dank!

01:55 31