Embed Size (px)
Citation preview
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?
