SOFTWARE- 4. Kapitel ARCHITEKTUR & ENTWURF TEIL...

SoftwareEngineeringProf.Dr.WolfgangSchramm

SOFTWARE-ARCHITEKTUR&ENTWURF

TEIL2

4.Kapitel

1

Inhalt

1. Einführung2. Begriffe3. Entwerfen4. Architektur5. Feinentwurf6. Entwurfsprinzipien7. Muster

2

Das(De)sign bestimmtdasBewusstsein!

WiekommenwirzueinemgutenDesign?WoranerkenneicheingutesDesign?

www.swr3.de

Es gibt 4 sog. allgemeineDesignprinzipien (enabling techniques).

EigentlichgibtessovieleDesignprinzipien,wiesichLeutedarüber

Gedankengemachthaben.

3

PrinzipiendesEntwurfs

o Principle :„abasic truth or general law ….that is used as abasis ofreasoning or aguide to action.“

o DiesePrinzipienwerdeninvielen,sog.gängigenAnsätzenals„grundlegend“bezeichnet.

4

AllgemeineDesign-Prinzipien

o Abstraktiono Kapselungo Modularisierungà Kopplung,Kohäsiono Hierarchie

PHAME=Principles of Hierarchy,Abstraction,Modularizationand Encapsulation.

G.Booch

5

Design-Prinzip:Abstraktion1/2

„…“Abziehen“oderHerauslösenvonTeilgehalten,Aspekten,MerkmalenauseinemkonkretemGanzen,inderAbsicht,dasGleichbleibende,WesentlicheverschiedenerGegenständezuerkennen“.(Quelle:MeyersLexikon)

6

Design-Prinzip:Abstraktion2/2

VorgehenderAbstraktion:o VerallgemeinertdurchVernachlässigenvonunwesentlichen

Eigenschaften.o TrenneWesentlichesvomUnwesentlichen.

o InderKonzipierungwerdenhauptsächlichvierAbstraktionsartenverwendet:¤ Komposition¤ Benutzung¤ Generalisierung¤ Aspekte.

Waswesentlich/unwesentlichist,hängtvondenAnforderungenab

7

8

9

Design-Prinzip:Abstraktion(Wieundwo)

o Abstraktion=VerstehendurchsystematischesVergröbern/Verfeinern=derProzess,Informationzuvergessen:¤ AbstraktiondurchParametrisierung,durchSpezifikation.¤ ProzeduraleAbstraktion,Datenabstraktion,Kontrollabstraktion.¤ GewinnungvonÜbersicht;WeglassungderDetails.¤ DieDarstellungeinesDetails;Weglassung/VergröberungdesRests¤ HerstellungeinessystematischenZusammenhangszwischen

ÜbersichtenundDetailsichten.

10

Design-Prinzip:Abstraktion(Vor- undNachteile)

VorteilederAbstraktiono DurchWeglassenunwichtigerEigenschaftenkanndie

Systemkomplexitätreduziertwerden.o AbstraktionerreichtinderRegeleinegrößere

Allgemeingültigkeit.

NachteilederAbstraktiono EskönnenwichtigeDetailsvergessenwerden.o ModellbildungundModellverständnissetzten

Erfahrung/Übungvoraus.

11

Übung

ErläuternSiedasPrinzipAbstraktion.BegründenSie,waseineguteAbstraktionausmacht,underklärenSiezweiBeispielefürAbstraktionen:EinBeispielausderSoftwareentwicklung(denkensiehierinsbesondereandieObjektorientierung)undeinsausdemAlltag.

12

Design-Prinzip:Kapselung

o Kapselung,InformationHiding (nach[Par72])¤ VerbergenderDetailseinerKomponente.¤ UnzugänglichmachenderDetails.¤ KriteriumzurGliederungeinesGebildesinKomponenten,sodass

n jedeKomponenteeineLeistung(odereineGruppelogischengzusammenhängenderLeistungen)vollständigerbringt,

n außerhalbderKomponentenurbekanntist,wasdieKomponenteleistet,n nachaußenverborgenwird,wiesieihreLeistungenerbringt.n fundamentalesPrinzipzurBeherrschungkomplexerSysteme.n liefertguteModularisierungen.

13

DesignPrinzip:Kapselung

Zugriff direkt auf die Daten

Gekapselte Daten

15

Modularisierung&Kapselung 1/2

o WarumistModularisierungundKapselunggut?¤ DieVerwendungdesModulserfordertkeineKenntnisseüberseinen

innerenAufbau.¤ DieGefahrvonunbeabsichtigtenFehlmanipulationensinkt.¤ DatenstrukturenundZugriffsoperatorenliegenineinemModul.Dies

verbessertdieLokalitätdesProgramms:Siewerdenbesserverstanden,sindeinfacherzuüberblicken,....

¤ ÄnderungenimInnereneinesModuls,welcheseineSchnittstelleunverändertlassen,habenkeineRückwirkungenaufdasübrigeSystem.

¤ Zugriffekönnenüberwachtwerden,ohnedassmanintiefereAbstraktionsschichteneindringt

¤ DieKorrektheitdesModulsistohneKenntnisseinerEinbettunginsGesamtsystemnachprüfbar.

außen

innen

16

Modularisierung&Kapselung2/2

o GibtesNachteilebeiModularisierungundKapselung?¤ AufrufvermittelnderOperationenkostetRechenzeit¤ ZugriffeerschwertbeinichtoptimalenSchnittstellen

n Maßnahmenn Refactoring (VerbessernderSchnittstellen)

18

Design-Prinzip:Modularisierung

o Dekomposition undModularisierung¤ ZerlegeneinesgroßenSystemsinkleinere,

beherrschbareEinheiten.¤ VerteilenvonFunktionalitätaufKomponenten

(Module).

o Modul: benannte,klarabgegrenzteKomponenteeinesSystems.

BeiderModularisierungkommteswesentlichdaraufan,dassnichtirgendwiezerlegtwird,sondernso,dassdieModuleinsichgeschlosseneTeillösungenmitmöglichstwenigen,wohldefiniertenInteraktionenzuanderenModulenbilden.

o Vollständigkeit undPrimitivität¤ Komponentenenthaltenalles,waszueiner

Abstraktiongehört,abernichtmehr.

19

PrinzipderModularisierung

o ModulinternstarkerZusammenhang.

o ModulexternschwacheKopplung.

o KommunikationnurüberSchnittstellen.

o Modulinternesvonaußennichtsichtbar.

20

Design-Prinzip:Modularisierung

o WarumistModularisierunggut?

- Die Verwendung des Moduls erfordert keine Kenntnisse über seinen inneren Aufbau.

- Änderungen im Inneren eines Moduls, welche seine Schnittstelle unverändert lassen, haben keine Rückwirkungen auf das übrige System.

- Die Korrektheit des Moduls ist ohne Kenntnis seiner Einbettung ins Gesamtsystem nachprüfbar.

21

Design-Prinzip:Kohäsion&Kopplung

o Kohäsion (cohesion)¤ EinMaßfürdieStärkedesinnerenZusammenhangs(innerhalb)der

Komponente.¤ JehöherdieKohäsion,destobesserdieModularisierung.

n schlecht:zufällig,zeitlichn gut:funktional,objektbezogenn esgibtverschiedeneKohäsionsstufen(s.[SMC74],[PJ88])

o Kopplung(coupling)¤ EinMaßfürdenZusammenhangzwischenzweiKomponenten.¤ JegeringerdiewechselseitigeKopplungzwischendenKomponenten,

destobesserdieModularisierung.n schlecht:Inhaltskopplung,globaleKopplungn akzeptabel:Datenbereichskopplungn gut:Datenkopplung

Keine Design-Prinzipien,sondern Maß für die Güte der Modularisierung

22

Metriken:Kohäsion&Kopplung

o CBO(Coupling Between Object Classes)¤ EineKlasseistmiteineranderenKlassegekoppelt,wennsiederen

Methodenund/oderAttributebenutztoderdirektvonihrerbt.CBOgibtdieAnzahlderaneineKlassegekoppeltenKlassenan.

o LCOM(Lackof Cohesion inMethods)¤ AnzahlderPaarevonMethodenderKlasseohnegemeinsame

Instanzvariablen minusAnzahlderPaarevonMethodendieserKlassemitgemeinsamenInstanzvariablen.

23

MetrikfürKohäsion

class X {

int A, B, C, D, E, F;

void f(){ … uses A, B, C … }

void g(){ … uses D, E … }

void h(){ … uses E, F … }

}

Aa B C

A

A B C

D E F

f()

g() h()

LCOM: Lack of Cohesion in Methods

LCOM = 2 -1 = 1

24

Übung

1. BestimmteVariablensindzugänglich– globaloderdurchexplizitenEx- undImport.2. AufalleDatenkannzugegriffen.3. EsbestehtkeineBeziehungzwischendenModulen,derZugriffistsyntaktischunmöglich.4. DieMethodenverschiedenerModulesindnurdurchParameterundFunktionen

gekoppelt.

Die folgenden Aussagen beschreiben Programmeigenschaften mit unterschiedlichen Kopplungsstärken. Sortieren sie die Aussagen von „starke Kopplung“ nach „geringe Kopplung“.

26

StufenderKoppelung

Stufe Zwischen Methoden/Modulen Erreichbar für

Einbruch Der Code kann verändert werden. Einbrecher

Volle Öffnung Auf alle Daten kann zugegriffen. Methoden

Selektive Öffnung Bestimmte Variablen sind zugänglich –global oder durch expliziten Ex- und Import

Module, Methoden

Methodenkopplung Die Methoden verschiedener Module sind nur durch Parameter oder Funktionen gekoppelt.

Module (Methoden)

Funktionskopplung Die Methoden verschiedener Module sind nur durch Werteparameter und Funktionsresultate gekoppelt.

Module (Methoden)

Keine Kopplung Es besteht keine Beziehung zwischen den Modulen, der Zugriff ist syntaktisch unmöglich.

Module

27

StufenderKohäsion

Stufe Innerhalb einer Methode / eines Moduls Erreichbar für

Keine Zusammenarbeit Zufällige Zusammenstellung. Module

Ähnlichkeit Die Teile dienen einem ähnlichen Zweck. Module

Zeitliche Nähe Die Teile werden zur selben Zeit ausgeführt.

Module, Methoden

Gemeinsame Daten Die Teile sind durch gemeinsame Daten verbunden, auf welche sie nicht exklusiven Zugriff haben.

Module, Methoden

Hersteller/Verbraucher Der eine Teil erzeugt, was der andere verwendet.

Module, Methoden

Einziges Datum (Kapselung)

Die Teile realisieren alle Operationen, die auf eine gekapselte Datenstruktur möglich sind.

Module, Methoden

Einzige Operation Operationen, die nicht mehr zerlegbar sind.

Methoden

28

Hierarchie

o ...durchschrittweiseVerfeinerung(à TopDown).¤ AussagekräftigeKlassifikation(bzgl.desVerhaltensà ).¤ SinnvolleGeneralisierung(gemeinsameEigenschaftenherausziehen,

Code-Redundanzvermeiden,à DRY).¤ SicherstellenderErsetzbarkeit(à Liskov‘sches Substitutionsprinzip).¤ VermeidenredundanterPfade(beiderVererbungshierarchie)à

Verständlichkeit.¤ GarantiederrichtigenReihenfolge(dasseinSubtypvomObertyp

abhängigist,istintuitivzuverstehen,derumgekehrtFallnicht).

Vorlesung Software Engineering

29

PrinzipiendesobjektorientiertenEntwurfs

o Single-Responsibility-Prinzip(SRP)o Open-Closed-Prinzip(OCP)o Liskovsches Substitutionsprinzip(LSP)o Interface-Segregation-Prinzip(ISP)o Dependency-Inversion-Prinzip(DIP)

SOLID-Prinzipien

Und noch weitere Prinzipien

(teilweise schon in den genannten

enthalten)

30

Diskussion

¨ WiefindensiefolgendenEntwurf?

31

Diskussion

Besser: mehrere Verantwortlichkeiten aufspüren

32

SingleResponsibility PrinzipundDon‘t RepeatYourself

1. SingleResponsibility Principle (SRP)¤ JedesObjekthateineeinzelneVerantwortung¤ TesteinerKlassebzgl.SRP

n Der/Die/Das «Klasse»«Methode»selbern DasAutostartetselbern DasAutowechseltReifenselber

2. Don‘t RepeatYourself (DRY)¤ EsgibtkeinendoppeltenCode¤ TesteinerKlassebzgl.DRYà offensichtlich

üû

SRPverletzt?à Klassenspalten/zusammenfügenDRYverletzt?à Codeauslagern(Klasse,Methode)

33

Offen-geschlossen-Prinzip1/3

o Geschlossen:(à besservollständig)¤ DieSchnittstelleeinesModulsdecktalleAnforderungendesClient-

Moduleab¤ SiekannvondenClientsohneAnpassungverwendetwerden.¤ Sieiststabil.

o Offen:(à bessererweiterbar)¤ EinModullässtsichohneÄnderungderClient-Moduleerweitern

o UmEntwürfenachdemoffen-geschlossen-Prinzipzuerstellen,müssendierichtigenAbstraktionengefundenunddieveränderbarenunderweiterbarenAspekteimplizitmodelliertwerden.

35

Offen-geschlossen-Prinzip2/3

B

A

DC

AA

E F

AwirderweitertdurchSubklasseAAAbleibtstabilfürB,C,DAAliefertE,FzusätzlicheFunktionalität

36

Design-Prinzip:Offen-geschlossen-Prinzip3/3

Beispiel Klassen sollten für Erweiterungen offen und für Veränderungen geschlossen sein

«abstract» Spielervariable1 : String...

schieben(stein, ziel) : void...

niemand soll etwas ändern!

...KI

variable1 : String...

schieben(stein, ziel) : void...

Menschvariable1 : String...

schieben(stein, ziel) : void...wird überschrieben durch

38

Inwiefern wirdhierdasOCPverletzt?

public void draw(Form form) {

if (form.type == CIRCLE) {drawCircle(form);

}else if (form.type == SQUARE) {drawSquare(form);

}}

Falls draw ein Dreieck zeichnen soll, muss draw erweitert werden.

40

WiefindensiediesenEntwurf?

Spielbrettbreite : inthöhe : intfelder : Feld [*][*]

addStein (x, y)removeStein (x, y)

3DSpielbretttiefe : int3dFelder : Feld [*][*][*]

addStein (x, y, z)removeStein (x, y, z)

41

Problem!

Diese Methoden arbeiten mit (x, y, z) Koordinaten,

Diese Methoden haben im 3-D Kontext keine Bedeutung,

Spielbrettbreite : inthöhe : intfelder : Feld [*][*]

addStein (x, y)removeStein (x, y)

3DSpielbretttiefe : int3dFelder : Feld [*][*][*]

addStein (x, y, z)removeStein (x, y, z)

42

Liskov‘sches Substitutionsprinzip1/2

o Eigenschaften, die anhand der Spezifikation des vermeintlichenTyps eines Objektes bewiesen werden können, sollten auch danngelten, wenn das Objekt einem Untertyp dieses Typs angehört: Seiq(x) eine beweisbare Eigenschaft von Objekten x des Typs T. Dannsoll q(y) für Objekte y des Typs S wahr sein, wobei S ein Untertypvon T ist. Damit ist garantiert, dass Operationen, die auf ein Objektdes Typs T vom Typ S anwendet werden, auch korrekt ausgeführtwerden. In einigen den heute übliche Programmiersprachen, diePolymorphie unterstützen, kann dieses Prinzip durch Vererbungvon mehr als einem Objekt auf ein anderes, verletzt werden. Dannließe sich nicht stets bedenkenlos ein Objekt vom Typ T durch einObjekt vom Typ S ersetzen.

vereinfacht:o Bei Vererbung: Subklassen müssen ihre Basisklassen ersetzen

können – ohne dass die Basisklassen davon wissen müssen.

[LW93]

43

Liskov‘sches Substitutionsprinzip2/2

o Washierbenötigtwird,istetwaswiediefolgendeErsetzungseigenschaft[6]:WennesfürjedesObjekto1vomTypSeinObjekto2vomTypTgibt,sodassfüralleProgramme,dieaufTermenderArtTbasieren,sichdasVerhaltenvonPnichtändert,wenno2durcho1ersetztwird,dannistSeinSubtypvonT.

o EineMethodesolltenichtsoüberschriebenwerden,dasssicheinObjekteinerabgeleitetenKlasseüberraschendandersverhält,alsmanesaufgrundderDefinitionderBasisklasseerwartenwürde.

o M.a.W:¤ Methoden,dieinabgeleitetenKlassenneudefiniertwerden,müssenalle

Integritätsbedingungen(d.h.dieSpezifikation)derBasisklassebeachten.¤ EineUnterklassedarfErweiterungenenthalten,nichtabergrundlegende

Änderungen.ÜbersetzungvonW.Kowarschick

44

Interface-Segregation-Prinzip

o „Clientssolltennichtdazugezwungenwerden,vonInterfacesabzuhängen,diesienichtverwenden.“

o ZugroßeInterfaceswerdenaufgeteilt.o DieAufteilungsollgemäßderAnforderungenderClientsan

dieInterfacesgemachtwerden¤ DieneuenInterfacespassengenauaufdieAnforderungender

einzelnenClientspassen.¤ DieClientsmüssenalsonurmitInterfacesagieren,diedas,undnur

daskönnen,wasdieClientsbenötigen.

o Softwarewirdinentkoppelteundsomitleichterrefaktorisierbare Klassenaufgeteiltà zukünftigefachlicheodertechnischeAnforderungenandieSoftwareerfordernnurgeringeÄnderungen.

45

Dependency-Inversion-Prinzip(DIP)

o ReduktionderKopplungvonModulen.o AbhängigkeitensollenimmervonkonkreterenModulen

niedrigerEbenenzuabstraktenModulenhöhererEbenengerichtetsein.

o AbhängigkeitsbeziehungenverlaufenimmerineineRichtung:vondenkonkretenzudenabstraktenModulen,d.h.vondenabgeleitetenKlassenzudenBasisklassen.

o ReduzierungderAbhängigkeitenzwischendenModulen,VermeidungzyklischerAbhängigkeiten.

46

UndnochPrinzipien...

o TrennungvonSchnittstelleundImplementierung:DesignbyContract.

o Separationof Concerns:fachlichenundtechnischenCodesowiefachlicheBelangeinderDomänetrennen.

o Composition over Inheritance:wichtigeralsAufmerksamkeitaufVererbung.

o DRYstattDIP:Code-WiederverwendungvielgrundlegenderalsUmkehrvonAbhängigkeiten.

o KISSundYAGNIaufallenEbenenundinallenPhasen¤ KeepIt Simple,Stupid(KISS)undYou Ain't Gonna NeedIt (YAGNI)

teilweise in Konkurrenz zu den

anderen genannten

47

Design-Prinzip:TrennungvonSchnittstelleundImplementierung

o TrennenvonSchnittstelle(interface)undImplementierung¤ KomponentendurchihreSchnittstellenspezifizieren.¤ Schnittstelle=BeschreibungdesLeistungsangebotseiner

Komponente.¤ Beschreibungmöglichstrealisierungsneutral.¤ LeistungsbeschreibunginderRegeldurchOperationenund

Datentypen.¤ Typische(realisierungsneutrale)Beschreibungsmittel:

n Voraussetzungen(Vorbedingungen,preconditions),n Ergebniszusicherungen(Nachbedingungen,postconditions,assertions),n Invarianten(invariants),n Verpflichtungen(obligations).

¤ BedingungenundZusicherungenbildenzusammeneinenVertragzwischenModulalsLeistungserbringerundKlientalsLeistungsverwender. Design by Contract

48

GeheimnisprinzipimSoftwareentwurf

o Komponente– Modulo Leistung– FunktionalitätdesModulso WAS– Modulschnittstelleo WIE– EntwurfsentscheidungenundderenRealisierungo ViertypischeArtenvonEntwurfsentscheidungenbei

Software:¤ WieeineFunktionrealisiertist.¤ WieeinObjektausdemAnwendungsbereichrepräsentiert/realisiert

ist.¤ WieeineDatenstrukturaufgebautist/bearbeitetwerdenkann.¤ WieLeistungenDritterrealisiertsind.

49

TrennungvonZuständigkeiten– separations ofconcern

o KomponenteistnurfüreinenganzbestimmtenAufgabenbereichzuständig.

o Komponenten,diegleichzeitigfürmehrereAufgabenzuständigsind,sindoftunnötigkomplex.

è Separationof concerns:ProzesseinProgramminverschiedeneFeatures,diesichinihrerFunktionalitätsowenigwiemöglichüberschneiden,aufzuteilen.

o Zuständigkeiten(concerns)werdenoftsynonymzuFeaturesoderVerhaltenverwendet.

o Kriterien,umZuständigkeitenzutrennen:unterschiedlich.EineZuständigkeit(concern)kannjederAusschnittineinemProgrammsein.

o OOEntwurf:ZusammenfassungvonDatenunddenOperationenaufdiesenDatenzueinerKlasse.

50

WashatSRPmitKohäsionzutun?

o WenndieSoftwareeinenhohenKohäsionsgradbesitzt,wurdedasSRP(SingleResponsibility Principle)befolgt!

50

SoftwareEngineeringProf.Dr.WolfgangSchramm

SOFTWARE- ARCHITEKTUR&ENTWURFTEIL2

4.Kapitel

52

Übersicht

1. EinführungindasSoftwareEngineering

2. Softwareprozesse3. Anforderungsanalyseund-

Spezifikation4. Softwareentwurf5. Programmierung6. Software-Qualitätssicherungund-

Prüfung7. Konfigurationsverwaltung8. Software-Wartung

53

Inhalt

1. Einführung2. Begriffe3. Entwerfen4. Architektur5. Feinentwurf6. Entwurfsprinzipien7. Muster

54

Wiederverwendnung

o IndenmeistentechnischenDisziplinen:àEntwurfsprozessbasiertaufderWiederverwendungbestehender

Systeme.

o BasisderWiederverwendung:Komponenten,diebereitsinanderenSystemenausprobiertundgetestetwurden.

o DieKomponentensindvonunterschiedlicherGranularität.

o Softwareentwicklung:erstseitca.10JahrenÜbergangvonderEntwicklungvonOriginalsoftwarezuEntwicklungmitsystematischerWiederverwendung.

55

WiederverwendungvonSoftware- Einheiten

o Anwendungssysteme¤ IntegrationinandereSystemeohneVeränderung.¤ KonfigurationderAnwendungfürverschiedeneKunden.¤ EntwicklungvonAnwendungsfamilienmitgemeinsamerArchitektur.

o Komponenten(Subsysteme– einzelneObjekte)¤ IsolationgleicherAufgabenineinemSubsystemundEinsatzdiesesSubsystemsin

verschiedenenAnwendungssystemen.

o Objekte/Funktionen¤ EinzelneKlassenoderFunktionenwerdeninFormvon(Standard-)Bibliothekenzur

Verfügunggestellt.¤ EinfacheVerwendung,indemsiemitanderemAnwendungscodeverknüpftwerden.

o Konzepte¤ WiederzuverwendendeEinheitistabstrakteralseineKomponente.¤ EinheitkannfürverschiedeneSituationenkonfiguriertundangepasstwerden.

[Som06]

56

WiederverwendungvonSoftware- Vorteile

Höhere Zuverlässigkeit

Wiederverwendbare Komponenten, die in der Praxis getestet wurden, sollten zuverlässiger sein, denn Fehler im Entwurf und in der Implementierung sind bereits aufgespürt und beseitigt worden.

Geringeres Risiko

Die Kosten für bestehende Software sind bekannt, während die Kosten für die Entwicklung stets geschätzt werden müssen. Dies verringert Unsicherheiten bei der Projektkostenschätzung, besonders dann, wenn große Softwarekomponenten wiederverwendet werden.

Effektiver Einsatz von Spezialisten

Anwendungsspezialisten können wiederverwendbare Komponenten ent-werfen, die ihr Wissen enthalten, statt ständig die gleiche Arbeit zu verrichten.

Übereinstim-mung mit Standards

Einige Standardlösungen (z.B. Bedienoberflächen) können als Menge von wieder verwendbaren Standardkomponenten implementiert werden. Bei einer Standard-Bedienoberfläche weisen alle Anwendungen dasselbe Menüformat auf. Die Benutzer machen bei der Verwendung standardisierter Bedienoberflächen weniger Fehler, da sie mit ihr vertraut sind. Das verbessert die Zuverlässigkeit der Software.

Kürzere Entwicklungs-zeit

Die frühest mögliche Markteinführung eines Systems ist oft wichtiger als die Gesamtkosten der Entwicklung oder die Effizienz des Systems. Wieder-verwendung kann sowohl die Entwicklungszeit als auch die Validierungsphase verkürzen. [Som06]

57

WiederverwendungvonSoftware-Schwierigkeiten

HöhereWartungs-kosten

Wenn der Quellecode eines wiederverwendeten Subsystems nicht verfügbar ist, werden die die wiederverwendeten Elemente in zunehmenden Maße inkompatibel mit Systemänderungen.

Mangel an Unter-stützung durch Werkzeuge

SE-Werkzeugsammlungen unterstützen die Wiederverwendung meist nicht. Der den Werkzeugen zugrunde liegende Prozess unterstützt Wiederverwendung nur unzureichend.

„Nicht-hier-erfunden“-Syndrom

Viele Softwareentwickler schreiben Software lieber entweder neu oder schreiben bestehende Komponenten um. Das Erstellen neuer Software hat einen höheren Stellenwert. Man vertraut nicht selbst erstellter Software nicht.

Aufbau und Wartung einer Komponenten-bibliothek

Aktuelle Techniken zur Klassifizierung, Katalogisierung und Abrufen von Software sind unausgereift.

Auffinden, Ver-stehen und An-passen wieder-verwendbarer Komponenten

Passende Komponenten müssen in einer Bibliothek gefunden, verstanden und angepasst werden. Das Suchen passender Komponenten muss von den Softwareentwicklern verinnerlicht und in den Softwareprozess aufgenommen werden.

[Som06]

58

WiederverwendungvonSoftware- Schlüsselfaktoren

o Entwicklungszeitplan¤ WenndieSoftwareschnellentwickeltwerdenmussà Einsatzfertiger(Sub-)Systeme.Anpassungan

dieAnforderungenmussnichtperfektsein.

o VoraussichtlicheLebensdauerderSoftware¤ SystememitlangerLebensdauerà Hauptaugenmerk=Wartung.LangfristigmussdasSystemimmer

wiederanneueAnforderungenangepasstwerdenà ZugriffaufQuellcodeistwahrscheinlich.DieVerwendungvonKomponentenexternerHerstelleristriskant.

o FähigkeitendesEntwicklungsteams¤ WiederverwendungstechnologiensindkomplexundverlangeneinenhohenAufwandbissie

eingesetztundverstandenwerden.

o BedeutungderSoftware¤ MussdieSoftwarezertifiziertwerden(evtl.mitZuverlässigkeitstest),dannmussmanZugriffaufden

Quellcodehaben.

o Anwendungsdomäne¤ InvielenProblembereichen(Bsp.Fabrikautomation)gibteseineReihegenerischerProdukte,diean

denkonkretenEinsatzbereichangepasstwerdenkönnen.

o Basissoftware¤ MancheKomponentenmodellesindausschließlichfürbestimmteBasissoftware-Plattformen

geeignet.SiesindimmernurimKontextdieserBasissoftwareeinsetzbar. [Som06]

59

WiederverwendungvonSoftware–Ansätze1/2

Entwurfsmuster Allgemeine, anwendungsübergreifende Abstraktionen werden als Entwurfsmuster dargestellt und zeigen abstrakte und konkrete Objekte und Interaktionen.

Komponenten-basierte Entwick-lung

Systeme werden durch die Zusammenstellung von Komponenten (Mengen von Objekten) entwickelt, die den Standards des Komponentenmodells entsprechen.

Anwendungsrahmen Zusammenstellungen von abstrakten und konkreten Klassen, die angepasst und erweitert werden können, um Anwendungssysteme aufzubauen.

Wrapper um Legacy-Systeme

Kapselung von Legacy-Systemen, indem ein Satz von Schnittstellen definiert wird. Der Zugriff auf diese Systeme erfolgt ausschließlich über diese Schnittstellen.

Dienstorientierte Systeme

Systeme werden durch die Verknüpfung mit gemeinsam genutzten Diensten entwickelt, die von externen Anbietern bereitgestellt sein können.

Produktlinien Ein Anwendungstyp wird mit Hilfe einer gemeinsamen Architektur verallgemeinert, so dass er an verschiedene Kunden angepasst werden kann.

[Som06]

60

WiederverwendungvonSoftware–Ansätze2/2

COTS-Integration Systeme werden durch die Integration bestehender Anwendungs-systeme entwickelt.

Konfigurierbare vertikale Anwendungen

Ein generisches System wird so entworfen, dass es an die Bedürfnisse eines Kunden angepasst werden kann.

Programm-bibliotheken

Klassen- und Funktionsbibliotheken, die allgemein verwendete Abstraktionen implementieren, stehen für die Wiederverwendung zur Verfügung.

Programm-generatoren

Ein Generatorsystem erzeugt aus einer geeigneten Wissensreprä-sentation des Anwendungsbereichs Systeme bzw. Systemfragmente

Aspektorientierte Software-entwicklung

Gemeinsam genutzte Komponenten werden bei der Kompilierung des Programms an verschiedene Stellen eingewoben.

[Som06]

61

Muster/Pattern

o MusterbeiGebäudeentwürfenvonC.Alexander[Ale77].

o ArchitektureinesRahmenwerksfürEditoren(ET++)vonErichGamma[Gam92].

o EsgibtauchEntwurfsmuster-KatalogeandererAutorenundMusterausanderenGebieten(nichtnurEntwurf).

o ErmöglichenWiederverwendungaufEntwurfsebene.

62

Muster/Pattern

o Problembeschreibung+KernderProblemlösung.

o KeinegenaueSpezifikation.o DieLösungkanninverschiedenen

Umgebungenwiederverwendetwerden.

o GenerischeLösungfüreinhäufigauftretendesEntwurfsproblem.

63

Entwurfsmuster- DefinitionnachE.Gamma

Design patterns are descriptions of communicating objects and classes thatare customized to solve a general design problem in a particular context. Adesign pattern names, abstracts, and identifies the key aspects of a commondesign structure that make it useful for creating a reusable object-orienteddesign. [GHJV95]

Vereinfacht:Ein Entwurfsmuster beschreibt das Schema einer Lösung für ein bestimmtes,in verschiedenen konkreten Zusammenhängen wiederkehrendesEntwurfsproblem.

64

Muster- Bewertung

o EröffnendieMöglichkeit,dieErfahrungandererzunutzenunderprobteLösungeneinzusetzen.

o UnterstützendieUmsetzungnicht-funktionalerAnforderungen(z.B.Änderbarkeit,Wiederverwendbarkeit).

o SchaffeneinVokabular(Idioms)fürdenEntwurfà erleichternDokumentationvonArchitekturen.

o KapselnWissenüberguteEntwurfspraktiken.

65

Muster- Bewertung

SindkeinAllheilmittel.Sindzwareinfachzuverstehen,aber

manbrauchtvielErfahrung,umdieEntwurfsmustersinnvolleinzusetzen.

66

Entwurfsmuster– AmBeispiel

Aufgabenstellung:o EntwicklungeinerinternetbasiertenWetterstation.o Basis:WetterDaten-Objekt– zeichnetdieaktuellen

Wetterbedingungen(Temperatur,LuftfeuchtigkeitundLuftdruck)auf.

o ErsteProgrammversion:3Anzeigeelemente– aktuelleWetterbedingungen+Wetterstatistiken+einfacheWettervorhersage.

o Die3AnzeigeelementesolleninEchtzeitaktualisiertwerden,wenndasWetterDaten-ObjektdieneuestenMesswerteerhält.

o DieWetterstationsollerweiterbarsein.EssolleineAPIveröffentlichtwerden,damitandereEntwicklerihreeigenenWetteranzeigenschreibenundproblemloseinstöpselnkönnen.

o EsexistiertschoneinProgrammfürdieWetterstation.

67

Entwurfsmuster– Beispiel:Aufgabenstellung2/2

Sensor für Luftfeuchtigkeit

Wetter-station

Aktuelle Wetter-bedingungen:

Temp: 17°Feucht: 45%Druck: 975

Sensor für Luftdruck

Sensor für Temperatur

ruft Daten ab

zeigt an

Wetter-Daten-Objekt

zu implementierenexistent

weitereAnzeigen

68

Entwurfsmuster– Beispiel:VorhandenerCode

public class WetterDaten {float getTemparatur () { . . . }float getLuftfeuchtigkeit () { . . . }float getLuftdruck () { . . . }

void messwerteGeändert () {/** Diese Methode wird aufgerufen, wenn die Wetter-* Messungen aktualisiert wurden.**/// Hier den Code einfügen

}

}

Aufgabe: messwerteGeändert ist so zu implementieren, dass die drei Anzeigen für die aktuellen Bedingungen, die Wetterstatistiken und die Vorhersage aktualisiert werden.

69

Entwurfsmuster– Beispiel:AnalysedesvorhandenenCodes

o Die Klasse WetterDaten hat Getter-Methoden für drei Messwerte (Temperatur,Luftfeuchtigkeit, Luftdruck).

o Die Methode messwerteGeändert () wird jedes Mal aufgerufen, wenn neueWetterdaten verfügbar sind.

o Es müssen drei Anzeigeelemente implementiert werden, die Wetterdatenverwenden: eine Anzeige „Aktuelle Bedingungen“ eine Anzeige „Statistiken“ undeine Anzeige „Vorhersage“. Diese Anzeigen müssen aktualisiert werden, sobaldsich WetterDaten neue Messwerte hat.

o Das System muss, durch andere Entwickler erweiterbar sein. Es sollen weitereAnzeigeelemente entwickelt werden und der Benutzer soll Anzeigeelementehinzufügen und entfernen können. Zur Zeit kennen wir nur die drei genanntenAnzeigetypen.

70

Entwurfsmuster– Beispiel:DerersteEntwurf

public class WetterDaten {

// Deklaration der Instanzenvariablen

void messwerteGeändert () {

float temp = getTemparatur ();

float feuchtigkeit = getLuftfeuchtigkeit ();

float druck = getLuftdruck ();

aktuelleBedinungsAnzeige.aktualisieren(temp, feuchtigkeit, druck);

aktuelleStatistikAnzeige.aktualisieren(temp, feuchtigkeit, druck);

aktuelleVorhersageAnzeige.aktualisieren(temp, feuchtigkeit, druck);

}

}

Was fällt bei dieser Lösung auf?

71

Entwurfsmuster– Beispiel:KritikamerstenEntwurf

o 3xwirdaktualisierenaufgerufen.o Dieaktualisieren-Schnittstelleder3Anzeigeelementeist

identisch.o EswirdaufeinekonkreteImplementierungprogrammiertà

sollenAnzeigeelementehinzugefügtodergelöschtwerden,mussdasProgrammgeändertwerden,indemeinAufrufderaktualisieren-MethodedesneuenAnzeigeelementsaufgerufenwird.

73

Entwurfsmuster– Beispiel:Observer- Muster

+registriereBeobachter()+entferneBeobachter()+benachrichtigeBeobachter()

Subjekt

+aktualisieren()

Beobachter-hatBeobachter

1

-beobachtet

*

Das Observer-Muster definiert eine Eins-zu-viele-Abhängigkeit zwischen Objekten in der Art, dass alle abhängigen Objekte benachrichtigt werden müssen, wenn sich der Zustand des einen Objekts ändert.

Weiterhin ungelöst: Das Subjekt muss alle möglichen konkreten Beobachter kennen, um sie benachrichtigen zu können.

C

D

74

Entwurfsmuster– Beispiel:Observer- Muster- verbessert

+registriereBeobachter()+entferneBeobachter()+benachrichtigeBeobachter()

KonkretesSubjekt

+aktualisieren()

KonkreterBeobachter

+registriereBeobachter()+entferneBeobachter()+benachrichtigeBeobachter()

«Schnittstelle»Subjekt

+aktualisieren()

«Schnittstelle»Beobachter

-hatBeobachter

1

-beobachtet

*

75

Entwurfsmuster– Beispiel:Observer- Muster

o DasSubjektweißübereinenBeobachter,nureineSache:dassereinebestimmteSchnittstelleimplementiert.

o WirmüssendasSubjektnieändern,wennwirneueBeobachterhinzufügen.o SubjektundBeobachterkönnenunabhängigvoneinanderwiederverwendetwerden.o ÄnderungenamkonkretenSubjektoderamkonkretenBeobachterhabenkeinen

Einflussaufdenjeweilsanderen.

Lose Kopplung à minimiert die Abhängigkeiten zwischen Objekten.

76

Übung

¨ ÜbertragenSiedieIdeedesObserver-PatternaufdieWetterstation–¤ WerspieltwelcheRolle?¤ WermusswelchesInterface

implementieren–WiesiehtdieImplementierung.aus?

¤ WernutztwelchesInterface?

76

77

Entwurfsmuster– Beispiel

o DieWetterstationerhältneueWerte,dasWetterDaten-ObjektbieteteinenDienstan:esbeliefertdieAnzeigeelementemitdenneuenDaten.

o DasWetterDaten-Objektmusswissen,anwenesdieaktualisiertenDatenschickenmuss.

o DazumussdasWetterDaten-ObjektdieAbnehmerseinerDatenselbstverwalten.

o DieAbnehmerderDaten(=Anzeigeelemente)könnendieWetterDaten-DienstebeimWetterDaten-Objektabonnierenundauchwiederabbestellen.

o DazumussdasdasWetterDaten-ObjektentsprechendeMethodenbereitstellen.

78

Entwurfsmuster– Beispiel:Observer- MusterfürWetterDaten

+registriereBeobachter()+entferneBeobachter()+benachrichtigeBeobachter()+getTemperartur()+getLuftfeuchtigkeit()+getLuftdruck()+messwerteGeändert()

WetterDaten

+anzeigen()+aktualisieren()+anzeigen()

AktuelleBedingungen

+registriereBeobachter()+entferneBeobachter()+benachrichtigeBeobachter()

«Schnittstelle»Subjekt

+aktualisieren()

«Schnittstelle»Beobachter

-hatBeobachter

1

-beobachtet

*

+aktualisieren()+anzeigen()

StatistikAnzeige

+anzeigen()

«Schnittstelle»AnzeigeElement

+aktualisieren()+anzeigen()

VorhersageAnzeige

+aktualisieren()+anzeigen()

DrittanbieterAnzeige

80

Observer-Pattern:AktionenbeiÄnderungenamobserviertenObjekt

81

Entwurfsmuster– Beispiel:Observer- Interfaces

interface Subject {

public void registriereBeobachter (Beobachter b);

public void entferneBeobachter (Beobachter b);

public void benachrichtigeBeobachter ();

}

interface Beobachter {

public void aktualisieren (float temp, floatfeuchtigkeit, float druck);

}

interface AnzeigeElement {

public void anzeigen();

}

82

Entwurfsmuster– Beispiel:Observer- Subject1/2

class WetterDaten implements Subject {

private ArrayList beobachter;private float temp;private float feuchtigkeit;private float druck;

public WetterDaten () {beobachter = new ArrayList();

}

public void registriereBeobachter (Beobachter b) {beobachter.add(b);

}

public void entferneBeobachter (Beobachter b){int i = beobachter.indexOf(b);if (i >= 0) beobachter.remove(i);

}

83

Entwurfsmuster– Beispiel:Observer- Subject2/2

public void benachrichtigeBeobachter (){for (int i = 0; i < beobachter.size(); i++) {

Beobachter b = (Beobachter) beobachter.get(i);b.aktualisieren(temp, feuchtigkeit, druck);

}}

public void messwerteGeändert () {benachrichtigeBeobachter();

}

public void setMesswerte (float temp, float feuchtigkeit, float druck) {

this.temp = temp;this.feuchtigkeit = feuchtigkeit;this.druck = druck;messwerteGeändert();

}

}

84

Entwurfsmuster– Beispiel:Observer- Beobachter

class BedienungsAnzeige implements Beobachter, AnzeigeElement {

private float temp;private float feuchtigkeit;private Subject wetterDaten;

public BedienungsAnzeige (Subject wetterDaten) {this.wetterDaten = wetterDaten;wetterDaten.registriereBeobachter(this); // bei Subject registrieren

}

public void aktualisieren (float temp, float feuchtigkeit, float druck) {this.temp = temp;this.feuchtigkeit = feuchtigkeit;anzeigen();

}

public void anzeigen () {System.out.println("Aktuelle Wetterbedingungen: " + temp + "Grad C°, " +

feuchtigkeit + " % Luftfeuchtigkeit");}

}

Wozu wird eine Referenz auf das

Subjekt gespeichert?

85

Observer-PatterninJava

o JavaseingebautesObserver-Muster¤ InterfaceObserver unddieabstrakteKlasseObservable imPackage

java.utiln java.util.Observer undjava.util.Observable

WarumeinmalInterface,einmalabstrakteKlasse?

¤ InSwingundJavaBeansn Listener-Methoden(à KlasseJButton):dortgibtesadd/removeListener-Methoden

86

BekanntvonSwing:Observer-Pattern(auch:Publish/Subscribe,Listener-Patterngenannt)

Observable,Publisher,---,Subjekt

Observer,Subscriber,Listener,Beobachter

*

87

VerallgemeinerteFormdesObserver-Patterns:ObserverbeimObservableeintragen

88

VerallgemeinerteFormdesObserver-Patterns:eingetrageneObserverbenachrichtigen

90

Übung

¨ BeschreibenSiefürjedesderfolgendenEntwurfsprinzipien,wiedasObserver-MusterdasPrinzipumsetzt.1. AspekteeinerAnwendung,die

sichändernkönnensolltenvondenendiekonstantsind,getrenntsein.

2. MannsollteaufdieSchnittstelle,nichtaufdieImplementierungprogrammieren.

3. KompositionistderVererbungvorzuziehen.

90

91

Lösung

1. DerZustanddesObjektesvariiert,sowiedieAnzahlunddieTypenderBeobachter.MitdemPatternkönnendieObjektevariiertwerden,dievomZustanddesObjektesabhängigsind,ohnedasSubjektverändernzumüssen.

2. SubjektundBeobachternutzenbeideInterfaces.DasSubjekthältObjektevor,diedasInterfaceObserverimplementieren,währenddieBeobachtersichregistrierenundvomSubjektInterfacebenachrichtigtwerden.

3. DurchKompositionwirdeinebeliebigeAnzahlvonBeobachternmitihrenSubjektenverbunden.DieseBeziehungenwerdennichtdurchVererbungshierarchieimplementiert,sondernzurLaufzeitdurchKomposition.

91

92

WichtigeEntwurfsmuster

o Einzelstück (Singleton): von einer Klasse darf nur genau ein Objekt erzeugtwerden, das global verfügbar sein muss.

o Memento: Der Zustand eines Objekts muss so archiviert werden, dass dasObjekt wieder in diesen Zustand zurückversetzt werden kann. Das Prinzipder Kapselung darf dabei nicht verletzt werden.

o Adapter: Eine Klasse soll verwendet werden, obwohl ihre Methoden-Signaturen nicht passen und auch nicht verändert werden können.

o Fassade (Facade): Ein Komponente soll nicht den gesamten, sondern nureinen eingeschränkten Funktionsumfang anderer Komponenten kennen.

o Beobachter (Observer): Mehrere Objekte müssen ihren Zustand anpassen,wenn sich ein bestimmtes Objekt ändert.

o Fabrikmethode (Factory Method): In einer Anwendung müssen Objekteerzeugt werden, deren Klassen zum Zeitpunkt der Entwicklung nochunbekannt sind.

Verwalten von

Objekten

Anbindung vorhandener

Klassen

Entkopplung von

Komponenten

Trennung unterschiedl-

icher und gemeinsamer

Merkmale

93

Entwurfsmuster– 4wesentlicheElemente

Name Liefert eine bedeutungsvolle Bezeichnung für das Muster.

Beschreibung des Problembereichs

Erläutert, wann das Muster angewendet werden soll.

Lösungs-beschreibung

Beschreibt Teile der Entwurfslösung, ihre Beziehungen und Verantwortlichkeiten. Das ist keine konkrete Entwurfsbeschreibung, sondern eine Schablone für eine Entwurfslösung.

Aussage zu den Konsequenzen

Aussagen zu den Ergebnissen und Kompromissen der Musteranwendung. Entwickler können entscheiden, ob ein Muster in einer bestimmten Situation effektiv angewendet werden kann.

94

Entwurfsmuster-Katalog1/2

Vorlesung Software Engineering

¨ Erzeugungsmuster¤ AbstractFactory¤ Builder¤ FactoryMethod¤ Prototype¤ Singleton

¨ Strukturmuster¤ Adapter¤ Bridge¤ Decorator (Wrapper)¤ Facade¤ Flyweight¤ Composite¤ Proxy

95

Entwurfsmuster-Katalog2/2

Vorlesung Software Engineering

Vorlesung Software Engineering

¨ Verhaltensmuster¤ Command¤ Observer¤ Visitor¤ Interpreter¤ Iterator¤ Memento¤ TemplateMethod¤ Strategy¤ Mediator¤ State¤ ChainofResponsibility

96

Strategy Pattern

Quelle: http://www.oodesign.com/strategy-pattern.html

Roboter soll verschiedene Verhalten haben können Verhalten wird in Interface

gekapselt

Verschiedene Verhalten in versch. Klassen implementiert

Bei der Erzeugung des „Robot“ wird Verhalten z.B. mit „setStrategy“

festgelegt

97

Strategy Pattern:TestenmitMockObjects

Dan Pilone, Russ Miles:Head First Software Development, 2008

@Testpublic void testSimple () {//create processorOrderProcessor op = new Orderprocessor ();op.setDBAccessor(new TestDBAccessor())

98

Literatur

98

99

Inhalt

1. Einführung2. Begriffe3. Entwerfen4. Architektur5. Feinentwurf6. Entwurfsprinzipien7. Muster(Architekturmuster)

100

Architektur

…istdiegrundlegendeOrganisationeinesSystems,dargestelltdurchdiedessenKomponenten,derenBeziehungenzueinanderundzurUmgebung.

101

Architekturmuster

o Architektur-MustersindDesign-MusteraufeinemhöherenLevelderAbstraktion.¤ SielegeneineMengevordefinierterSubsystemefest.¤ IhreVerantwortung.¤ SowieRegelnundRichtlinienfürdieOrganisation/Beziehungzwischen

denSubsystemen.

o DieWahleinesArchitekturmustersisteinezentraleEntwurfsentscheidung.

o DieEignungeinesArchitekturmustershängtvonderErfüllungseinerspeziellenRandbedingungenundVoraussetzungenab.

o EsgibteinenengenZusammenhangzwischenArchitekturmusternundNichtfunktionalenAnforderungen.

102

Architekturmuster

o Unterscheidungin¤ Verteilungsmuster¤ Strukturierungsmuster¤ MusteradaptierbarerSysteme

o MusterderSoftware-Schichten.¤ Subsystemewerdeni.d.R.inaufeinanderaufbauendenSchichten

angeordnet.¤ TypischeArchitekturenfürAnwendungssysteme:

2-Schicht– 4-Schicht-Architekturen.o MusterderPipe-Filter:Datenwerdenaufeinemvirtuellen

Fließbandverarbeitet.o Model-View-Controller-Architekturmuster:saubereTrennungvon

InteraktionundFunktion.o Plug-in-Architekturmuster:einKern(Host,Wirt)kanndurchsog.

Plug-insandafürvorgesehenenStellenumneueFunktionenerweitertwerden.DerHostdefiniertspezielleSchnittstellen,diesog.Erweiterungspunkte.

103

Zwei-Schichten-Architektur(2-tier)

• Typisch für einfache Informationssysteme.

<<layer>>

Anwendungsschicht

<<layer>>

Datenhaltungsschicht

104

Drei-Schichten-Architektur(3-tier)

• Aufteilung der Anwendungsschicht in Benutzungsoberfläche und Anwendungsdomäne.

<<layer>>

Dialogschicht

<<layer>>

Fachkonzeptschicht

<<layer>>

Datenhaltungsschicht

105

Vier-Schichten-Architektur(4-tier)

• Einführung einer Schicht von vorgefertigten Komponenten, etwa zur Verteilung von Datenobjekten (z.B. CORBA)

<<layer>>

Dialogschicht

<<layer>>

Fachkonzeptschicht

<<layer>>

Datenhaltungsschicht

<<layer>>

Systemsoftwareschicht

106

Verteilung

• Lokales System (auch Stand-Alone-System): System, das auf einemeinzelnen Rechner ausgeführt wird.

• Verteiltes System: Teile des Systems werden auf verschiedenen Rechnernausgeführt, die miteinander über ein Rechnernetz kommunizieren.

• Client-Server-Architektur: zentrale Dienste (z.B. Datenhaltung) werden aufeinem Rechner (Server) ausgeführt; diese zentralen Dienste werden vonAnwendungsprogrammen, die auf Klienten ausgeführt werden, genutzt.

• Master/Slave-Architektur: eine Anwendung (Master) übt die Kontrolle überandere Anwendungen (Slaves) aus.

• Peer-to-Peer-Architektur: alle Anwendungen besitzen ähnlicheKompetenzen. Jede Anwendung bietet Dienste an und nutzt Dienste andererPeers.

107

Model-View-Controller-Architekturmuster

o Benutzer¤ ÜberdieViewistderBenutzermitdemSystemverbunden.

o Model (Modell/Verarbeitung)¤ FachlicheFunktionalitätderAnwendung(Geschäftslogik).¤ KapseltdieDatenderAnwendung.¤ UnabhängigvonViewundController.¤ ZugriffaufdieDatennurüberZugriffsoperationen.

o View (Präsentation/Ausgabe)¤ DarstellungderDatenausdemModellfürdenBenutzerundEntgegennahmevon

Benutzerinteraktion.¤ FürdieDateneinerAnwendung(Model)kannesmehrereDarstellungengeben.¤ ÄnderungderDatenimModelà Viewwirdbenachrichtigtundaktualisiertihre

Darstellung.o Controller(Steuerung/Eingabe)

¤ JederViewisteinControllerzugeordnet.¤ EmpfängtdieEingabendesBenutzers(überdieView)undreagiertdarauf,

→ indemdieDarstellunggeändertwird(à View).→ indemdiegewünschteFunktionderAnwendungaufgerufenwird(àModel).

108

MVC– ZusammenwirkenderKomponenten

Controller View

Model

Veränderung der Visualisierung

Aufruf von Anwendungsfunktionen

Zugriff auf darstellende Daten

Information über Änderung

109

MVC– keineindeutigesMuster

o MVCistinverschiedenenProgrammiersprachenunterschiedlichrealisiert.

o Deshalb:keinegenaueDefinitionüberdiePositionierungderGeschäftslogikà entwederimControlleroderimModel(abhängigvomjeweiligenMVC-Framework).

o WodieValidierungderBenutzereingabenstattfindet,istnichtdefiniert.¤ EinfacheFormatvalidierungenà View.¤ Validierungen,welchestärkerdieGeschäftslogikberücksichtigenmüssen

àModeloderController.o FormatierungderRohdaten/Internationalisierungistnicht

definiert,wodieseerfolgen.¤ Entwicklungseffizienzà imModelzuintegrieren(mankannsichbeim

ViewaufdieErstellungvonWidgets oderTemplatesbeschränken).¤ DadurchVerlagerungderAspektederDarstellungindasModelà

WiderspruchzurGrundidee.¤ AlsVariante:eigenständigeFunktionsbereiche,diemandannweder

Model,ViewoderControllerzurechnenmuss.

110

Modell-View-Controller

111

Model-View-Controller:Beispiel1/3

112

Model-View-Controller:Beispiel2/3

Bei jedem Modell können sich mehrere Beobachter (= Sichtenund Kontrollen) registrieren

Bei jeder Änderung des Modell-Zustands werden dieregistrierten Beobachter benachrichtigt; sie bringen sich dannauf den neuesten Stand.

113

Model-View-Controller:Beispiel2/3

Controller: verarbeitet Eingaben und ruftpassende Dienste der zugeordneten Sicht oder des Modells auf.

Model: Kernfunktionalität liefern und registrierte Komponenten bei Datenänderungbenachrichtigen

114

MVC-Architekturmuster

o Vorteile¤ MehrereView-Controller-PaarefürdasselbeModell.¤ Sichtensindsynchron.¤ AnsteckbareSichtenundKontrollen.¤ Change-Update-Mechanismusbewirkt,dassdasModelinallenViews

immeraktuelldargestelltwird.

o Nachteile¤ ErhöhteKomplexität.¤ StarkeKopplungzwischenModellundSicht.¤ StarkeKopplungzwischenModellundKontrollen(kannmitCommand-

Musterumgangenwerden).

o Beispiele:GUI-Bibliotheken,Smalltalk,MicrosoftFoundationClasses,Web-Architektur

115

DasPlug-In-Architekturmuster1/2

o BenutzerkönnenanspeziellenPunkteneinvorhandenesSystemerweitern,ohneeszumodifizieren.

o Anwendung=Kern(Host-System)+erweiterndeFunktionen(Plug-Ins).o DerHostdefiniertdiesog.Erweiterungspunkte,aufwelcheeinPlug-InBezug

nehmenkann.

Plug-In

Schn

ittst

elle

A

Plug-In Plug-InSc

hnitt

stel

le B

Schn

ittst

elle

E

Schn

ittst

elle

F

Schn

ittst

elle

C

Schn

ittst

elle

D

Ker

n (H

ost)

116

DasPlug-In-Architekturmuster2/2

o Plug-InwirdimKontextdesHost-Systemsausgeführtè¤ IstgemäßdenvorgegebenentechnischenKonventionendesHosts

realisiert.¤ Codemussentsprechendabgelegtsein.¤ DasPlug-InmussbeimHostregistriertsein.¤ BeimStartdesHostswerdenalleregistriertenPlug-Insidentifiziertund

ggf.sofortodernachBedarfgeladen.¤ Plug-Inskönnenkaskadiertwerden,d.h.einPlug-Inkann

entsprechendeErweiterungspunktedefinierenunddamitselbstHostfürweiterePlug-Inssein.

117

Diskussion

¨ DieArchitekturhateinengroßenEinflussaufdienichtfunktionalenAnforderungenderSoftware.VersuchensiedieSchichten-ArchitekturenimBezugaufdieAnforderungenanPerformanzbzw.Sicherheitzubeurteilen.

117

118

ArchitekturundNFRs

o DieSystemarchitekturhateinenstarkenEinflussaufNichtfunktionaleAnforderungen.

o EinigeBeispiele:¤ Performanz:ArchitekturmitvielenkleinenKomponentenundeiner

hohenKommunikationzwischendieseKomponentensindschlechteralsSysteme,indenenaufwendigeOperationenlokalineinergrößerenKomponentenzusammengefasstwerden.

¤ Verfügbarkeit:RedundanteKomponentenerlaubeneseinzelneKomponentenauszutauschen,ohnedasgesamteSystemzustoppen.

¤ Security:EineSchichtenarchitekturerlaubteskritischeObjekteinderinnersten(ammeistengeschützten)Schichtanzuordnen.

118

133

NochFragen?