Design Pattern SS 15 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee...

Design Pattern SS 15

Prof. Albert Zündorf

Fachgebiet für Software EngineeringWilhelmshöher Allee 73

34121 Kassel(Raum 1339)

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel 2

Organisatorisches

Umfang: 4 SWS teils Vorlesungen teils Übungen Übungsbetreuung: Marcel Hahn, … Ort und Zeit:

Vorlesung: Dienstags 16:00 - 19:00 Raum 1332(Erste Vorlesung:

14.04.15)Übung:? In obigem Zeitraum

Prüfung: Pflichtübungsaufgaben (korrigiert, bepunktet)

Folienskript / Screen Videos: http://www.se.eecs.uni-kassel.de.


Literatur

Elementar: Norbisrath, Zündorf, Jubeh: Story Driven Modeling,

Amazon 2014, ISBN 9781483949253 (Das Buch überhaupt ) Grundlegend: E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns

(Elements of Reusable Object-Oriented Software); Addison Wesley, Bonn, ISBN 0-201-63361-2 (1994)

Patterns Home Page: st-www.cs.uiuc.edu/users/patterns/patterns.html

Unified Modeling Language: Martin Hitz, Gerti Kappel: UML @ Work, dpunkt.verlag (ziemlich gut)

Hintergrund: Frederick P.\ Brooks: The Mythical Man Month, Addison Wesley 1975

(ist nur kurz aber ziemlich witzig, unbedingt mal lesen)


Gliederung

1. Einführung 2. Design Grundprinzipien

3. Grundlegende Pattern

4. Weitere Pattern

5. Zusammenfassung


1. Einführung

Ziele der Veranstaltung: Design Know How für große Programme > 100 000 LOC Grundprinzipien der Wartbarkeit und Erweiterbarkeit sicherer Umgang mit Vererbung und Delegation Grundkenntnis der wichtigsten Design Pattern


Beispiel Composite Pattern

Realisierung hierarchischer Datenstrukturen kommt in praktisch allen Software-Anwendungen vor naiver Ansatz verursacht dramatische Wartungsprobleme Gute Lösung ist Ausgangspunkt für viele weitere Pattern


Gliederung

1. Einführung

2. Design Grundprinzipien3. Grundlegende Pattern

4. Weitere Pattern

5. Zusammenfassung


2. Design Grundprinzipien

Wartbarkeit Erweiterbarkeit ein Ort eine Design Entscheidung / eine Funktionalität lokale Änderungen

nur lokale Auswirkungen lokaler Änderung (Module/Klassen, Interfaces, Sichtbarkeiten)

"wenig" Vererbung


Vererbung

Substitutionsprinzip:Kinder müssen halten was die Eltern versprechen

anstelle eines Elternklassenobjektes kann man auch immer ein Unterklassenobjekt verwenden

EnterpriseEmployee

work (t : Task) : Product

Manager

work (t : Task) : Productmanage ( proj : Project ) : Presentation

has

Project

Task

Presentation

Product

createddoes


BeispielsituationenEnterpriseEmployee


Managerwork (t : Task) : Productmanage ( proj : Project ) : Presentation

has

Project

Task

Presentation

Product

createddoes

…prod = e.work (t);…

Struktur

Verhalten Daten :Employee

:Employee

:Manager

:Task

:Product

:Presentation :Project

:Task





has

Project

Task

Presentation

Product

createddoes


Struktur


:Employee

:Manager

:Task

:Product


:Task





has

Project

Task

Presentation

Product

createddoes


Struktur


:Employee

:Manager

:Task

:Product


:Task





has

Project

Task

Presentation

Product

createddoes


Struktur


:Employee

:Manager

:Task

:Product


:Task


Co- und Contravariante Redefinitionen:

wegen Substituierbarkeit: input Parameter (Lesen) in Unterklassen

nur verallgemeinern(Contravariante Redefinition)

output Parametern (Schreiben in Unterklassen) nur spezialisieren(Covariante Redefinition)


Delegation:

House

run ()alarm ()

FlashLightalarm()

Sirenealarm()

MailAlarmalarm()

alarmDevice

Struktur

Verhalten Daten

…this.alarm();… :House

:FlashLight

:Sirene

:MailAlarm

AlarmDevicealarm ()


Hausaufgabe 1:deliveryBoy

Struktur

Verhalten Daten…myCourier.deliver(p1, "WilliAllee73");… :CourierService

:CarBoy

:BikeBoy

:RollerBoy

DeliveryBoydeliver(pack, addr)

BikeBoy

deliver(pack, addr)

RollerBoy

deliver(pack, addr)deliver(pack, addr)

CarBoy

CourierService

deliver(package, address)


Hausaufgabe 1:

Implementiert obiges Klassendiagramm zur Delegation(z.B. mit SDMLib)

Implementiert die deliver(pack, addr) Methoden der DeliveryBoy–Unterklassen

macht jeweils unterschiedliche System.out Ausgaben Schreibt ein Testprogramm dass:

ein CourierService Objekt und ein Paket Kaffebohnen erzeugt,

nacheinander verschiedene DeliveryBoy Objekte einbaut

jeweils deliver(coffeeBeans, "WilliAlle73") aufruft


Abgabe:

Bis Eclipse Projekt "DPH01<matrnr>" Eclipse Projekte inklusive Quellcode JUnit Test start mit einem Click

Vererbungskonzepte





Gliederung

1. Einführung

2. Design Grundprinzipien

3. Grundlegende Pattern4. Weitere Pattern

5. Zusammenfassung


1. Referenzarchitektur interaktive System

Repository

Data Model

GUI(Commands)

Generators / Interpreters

QVT(Control)

Import/ Export

GUI(Unparsing)


Datenmodell mit Composite Pattern: naiv

Struktur

Verhalten Daten

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Datenmodell mit Composite Pattern: besser

Struktur

Verhalten Daten


Datenmodell mit Composite Pattern: gut

Struktur

Verhalten Daten


Hausaufgabe 2:

Ein Book besteht aus: Parts Chapters Sections Paragraphs Sentences

Implementiert ein Datenmodell für Books mit dem Composite Pattern

Lest die Kapitelstruktur des Buches ein. zählt die Anzahl der Objekte in euerer Composite Struktur macht euch für weitere Anforderungen bereit


Composite Pattern Problem:

Struktur

Verhalten Daten


Naiver Ansatz:

Struktur

Verhalten Daten


Visitor Pattern

rekursiver Durchlauf durch Composite Struktur durchreichen eines Visitor Objekts uniformerer Umgang mit Rekursionsparametern Trennung von Durchlauf und Aktion


Visitor Pattern

Struktur

Verhalten Daten


Visitor Pattern mit Reflection

Struktur

Verhalten Daten


Visitor Pattern Zusammenfassung

Ziemlich viele accept und visit Methoden

Double Dispatch möglich

Seperation of concern

Zustandsobjekt in der Rekursion


Hausaufgabe 3:


Strategy Pattern

ersetze if-then-else-if Ketten


If-then-else-if Kette:

Struktur

Verhalten Datenpublic void doMove () {

if (mode == AGGRESSIVE){ …}else if (mode == DEFEND){ …}else if (mode == PLAN){ …}…

Player

main ()doMove()

mode : int


AStarStratdoMove()

Strategy Pattern:

Playermain()doMove ()

MoveStrategydoMove()

DefensiveStratdoMove()

strategy 0..1

Struktur

Verhalten Daten

class Player{

public void doMove (){

strategy.doMove ();}

…

:Player :AttackStrat

:DefensiveStrat

:AStarStrat

AttackStratdoMove()


Strategy Pattern

Struktur

Verhalten Daten


Hook Pattern (nicht im Gof-Buch)

zusätzliches Verhalten nachträglich einbauen


Hook Pattern:

Struktur

Verhalten Daten

public void doMove(){

produceFood();

for (strat in strategies){

strat.doMove();}

}

n

ResearchStratdoMove()


StrategyPartdoMove()


strategies


:DefensiveStrat

: ResearchStrat

AttackStratdoMove()


Chain of Responsibility

im wesentlichen Hook aber Abbruch wenn erfolgreich bearbeitet


< next

Chain of Responsibility, original

Struktur

Verhalten Daten

class Player{public boolean doMove () {

if (next != null){

return next.doMove();}return false;

}}

1





next


:DefensiveStrat

: ResearchStrat

AttackStratdoMove()


Chain of Responsibility, original :

Struktur

Verhalten Datenclass AttackStrat{

public boolean doMove () {// try itif (canAttack ()) {

doAttack ();return true;

}else {

super.ring ();} } }

1





next


:DefensiveStrat

: ResearchStrat

AttackStratdoMove()

next


Chain of Responsibility, besser debugbar:

Struktur

Verhalten Datenclass Player{

public boolean doMove () {boolean success = false;for (h in handlers) {

success = h.doMove();if (success)

return true;}return false;

} }

{ordered}

handlers[1]

handlers[2]

handlers[3]

n





handlers


:DefensiveStrat

: ResearchStrat

AttackStratdoMove()


Chain of Responsibility, besser debugbar:

Struktur

Verhalten Datenclass AttackStrat {

public boolean doMove() {// try itif (canAttack ()) {

doAttack ();return true;

}else {

return false;} } }

{ordered}

handlers[1]

handlers[2]

handlers[3]

n





handlers


:DefensiveStrat

: ResearchStrat

AttackStratdoMove()



Beobachtungen

typische Kombinationen von Assoc und Vererbung Unterklassen haben KEINE neue Methoden Unterklassen redefinieren geerbte Methoden


Beobachtungen


Hausaufgabe 4:


State

im wesentlichen Strategy aber systematische Strategy-Änderung nach Benutzung meist Implementierung von Statecharts


State:

Struktur

Verhalten Daten

TraficLightstate :Integer

timerTick()

Car

class TrafficLigth {void timerTick() {

if (state == RED) {car.setPos (…);state = GREEN;

}else if (state == GREEN) {

car.stop();state == YELLOW; }

else if (state == YELLOW)car.stop()state = RED;

} } }

green

yellow

redtimerTick() / car.setPos(…)

timerTick() / car.stop()

timerTick() / car.stop() car


State:

Struktur

Verhalten Daten

TLState

Green

Yellow

Red

currentTraficLight

timerTick()

Car

:TrafficLight

:Car

:Red

:Yellow

:Green

namestates

states["red"]

states["yellow"]

states["green"]

class Red {void timerTick() {

owner.current = owner.states["green"];car.setPos(…);

} }

class Green {void timerTick() {

owner.current = owner.states["yellow"];car.stop();

} }

car

car


Listener/Observer/Model-View-Controler/Mediator

im wesentlichen Hook aber Einsatz zur Überwachung von Änderungen


Listener/Observer/Model-View-Controler

Struktur

Verhalten Daten

Drive

usedSpace :Integer

propertyChange (obj, attrName, oldVal, newVal)

Filesize :Integer

write(bytes[])

:DriveusedSpace = 38

write ("aaaa")

class File {void write (bytes[]) {

…this.setSize (size+bytes.length());

}

void setSize (newVal) {if (this.size != newVal) {

int oldVal = size;size = newVal;firePropertyChange ("size", oldVal, newVal);

} }…

:Filesize = 23

:Filesize = 15

listenersnListener




Struktur

Verhalten Daten

Drive

usedSpace :Integer


Filesize :Integer

write(bytes[])


write ("aaaa")

class File {…void firePropertyChange (attrName, oldVal, newVal){

for (l in listeners){

l.propertyChange (this,attrName,oldVal,newVal); } }…

:Filesize = 23

:Filesize = 15

listenersnListener




Struktur

Verhalten Daten

Drive

usedSpace :Integer


Filesize :Integer

write(bytes[])


write ("aaaa"):Filesize = 23

:Filesize = 15

listenersnListener


class Drive {…void propertyChange (obj,attrName,oldVal,newVal){

usedSpace += newVal – oldVal;}

…

}


MVC

Struktur

Verhalten Daten

DriveusedSpace :Integer


write ("aaaa")

class SpaceUpdater {…void propertyChange (obj,attrName,oldVal,newVal){

for (t : targets) {t.usedSpace += newVal – oldVal;

}

}

…

}

:Filesize = 23

:Filesize = 15

targetsn

:SpaceUpdater

SpaceUpdater


Filesize :Integer

write(bytes[])

listenersnListener


Computer


Struktur

Verhalten Daten:Drive

usedSpace = 38

write ("aaaa")

class SpaceUpdater {…void propertyChange (obj,attrName,oldVal,newVal) {

Dir parent = obj.getParent();

while (parent != null) {

parent.usedSpace += newVal – oldVal;

parent = parent.getParent();}

}

…

}

:Filesize = 23

:Filesize = 15

:SpaceUpdater

SpaceUpdater


Filesize :Integer

write(bytes[])

listenersnListener


Computer

DirusedSpace :Integer

filesparentn

1

Drive

:DirusedSpace = 38

:DirusedSpace = 38

:ComputerusedSpace = 38


Struktur

Verhalten Daten


Hausaufgabe 5?:



Template Method

Motivation ähnlich wie Hook aber feste Vorgabe von abstrakten Template-Methoden alle Template-Methoden müssen überschrieben werden


Template Method: Alarm

+ ring ()~ start ()~ stop ()

Struktur

Verhalten Daten

class Alarm {void ring () {

start ();…stop ();…

} }

:FlashLight

:Sirene

:MailAlarm

MailAlarmring ()

Sirenering ()

FlashLight~ start ()~ stop ()

~ start ()~ stop ()

~ start ()~ stop ()


Template Method: Alarm

+ ring ()~ start ()~ stop ()

Struktur

Verhalten Daten

class FlashLigth {void start () {

powerOn ();}

void stop () {powerOff ()

} }

:FlashLight

:Sirene

:MailAlarm

MailAlarmring ()

Sirenering ()

FlashLight~ start ()~ stop ()

~ start ()~ stop ()

~ start ()~ stop ()


Decorator

ähnlich wie Composite mit nur einem Kind ähnlich wie Chain-of-Responsibility erweitere eine Strategy um zusätzliche Aktionen


Decorator:

Struktur

Verhalten Daten

class MailAlarm {ring () {

sendMail();orig.ring();

} }

:House

:Sirene

:MailAlarm

MailAlarmring ()

Houserun ()ring ()

Alarmring ()

Sirenering ()

alarm 0..1

FlashLightring ()

0..1 orig


Proxy

ähnlich wie Decorator aber kein Zusatzeffekt sondern remote, lazy oder cache Effekte


Proxy:

Struktur

Verhalten Daten :House

:Sirene

:MailAlarm


Adapter

ähnlich wie Decorator aber Schnittstellenanpassung


Adapter:

Struktur

Verhalten Daten

:House

:Sirene

:MailAlarm


Hausaufgabe:


Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Flyweight

Struktur

Verhalten Daten


Flyweight

Struktur

Verhalten Daten


Struktur

Verhalten Daten

Interpreter / Macro / Command


Command

Struktur

Verhalten Daten


Struktur

Verhalten Daten


Hausaufgabe: Command




Factory Method:

Struktur

Verhalten Daten


Prototype:

Struktur

Verhalten Daten


Komplexer Prototyp


Abstract Factory:

Struktur

Verhalten Daten


Hausaufgabe:



Facade:

Struktur

Verhalten Daten


Facade:

Struktur

Verhalten Daten



Plugins:

Struktur

Verhalten Daten


Import Umkehrung:

Struktur

Verhalten Daten


Import Umkehrung:

Struktur

Verhalten Daten


Daten Plugin:

Struktur

Verhalten Daten




Reuse Architekturen:

Bibliotheken Frameworks Plugin Architekturen Software Bus / ECMA Toaster Corba / RMI / REST Component & Connector Android Intents Product Line Architecture



Components & Connectors Architekturen










Wie erreicht man:

Wartbarkeit Erweiterbarkeit Qualität Produktivität Sicherheit Robustheit Usability Skalierbarkeit Verfügbarkeit


Date post:	06-Apr-2016
Category:	Documents
Upload:	caecilia-altenhofen
View:	213 times
Download:	0 times

Design Pattern SS 15 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee...

Documents