Kapitel 9 Objektorientierte Modellierung · Kapap te 9 Obje to e t e te ode e u gitel 9: ... Pbl K...
Transcript of Kapitel 9 Objektorientierte Modellierung · Kapap te 9 Obje to e t e te ode e u gitel 9: ... Pbl K...
Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel
Kapitel 9Objektorientierte Modellierung
( nicht in Brügge & Dutoit)
Vermeide RedundanzenVermeide Bezug auf nicht-Inhärente Typen
Vermeide nicht-einheitliches VerhaltenVermeide Verwirrung von Klasse und Instanz
Vermeide fehlende Ersetzbarkeit in TyphierarchienVermeide Abhängigkeiten
© 2000-2007 Dr. Günter Kniesel
Was sind akzeptable Abhängigkeiten?
Vorlesung Softwaretechnologie 2007/8Kapitel 9: Objektorientierte Modellierung R O O T Sap te 9 Obje to e t e te ode e u g
Objekt-Orientierte Modellierung
– Ein Quiz –
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
return conflicts
Konflikt KonfliktKonflikte conflicts
ReservationReservations ReservationReservations
getConflicts()
Reservationres : Resourcestart: Timeend: Time
Reservations
getConflicts()
Reservationres : Resourcestart: Timeend: Time
Reservations
getConflicts()
berechnet die zeitlich überlappenden Reservierungen
hasConflict : bool
berechnet die zeitlich überlappenden Reservierungen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-3 R O O T S
überlappenden Reservierungen überlappenden Reservierungen
Prinzip: Keine Redundanzen im Modell!
Redundantes ModellMehrfache Wege um die gleiche Information zu erhaltenS i h b l it t I f tiSpeicherung abgeleiteter Informationen
ProblemProblemBei Änderungen zur Laufzeit, müssen die Abgeleiteten Informationen / Objekte konsistent gehalten werdenZ t f d b i I l ti (B h i hti h i )Zusatzaufwand bei Implementierung (Benachrichtigungsmechanismus) und zur Laufzeit (Benachrichtigung über Änderung und Aktualisierung abgeleiteter Infos)Ä d i D i ü tl i l St ll hÄnderungen im Design müssen evtl. an vielen Stellen nachgezogen werden
BehandlungRedundanz entfernen
f ll i i ht l L f it ti i i htb i t d di
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-4 R O O T S
... falls sie nicht als Laufzeitoptimierung unverzichtbar ist, da die Berechnung der abgeleiteten Informationen zu lange dauert
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
<<utility>><<utility>>Trigonometry
...
arcTan(Real):AnglearcTan(Real):Angle
Real...
Real......
arcTan() : Angle
...
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-5 R O O T S
Prinzip: Kein Bezug auf nicht-inhärente Klassen!
Inhärente KlasseEine Klasse A ist für eine Klasse B inhärent, wenn sie Charakteristika von B definiert
Anders ausgedrückt:Eine Klasse A ist für eine Klasse B inhärent wenn B nicht ohne A definiertEine Klasse A ist für eine Klasse B inhärent, wenn B nicht ohne A definiert werden kann
P blProblemBezug auf nicht-inhärente Klassen führt unnötige Abhängigkeiten ein
BehandlungBezug auf nicht-inhärente Klasse entfernenEventuell Teile der Klasse in andere Klassen auslagern
siehe Refactorings (z.B. „Move Method“, „Move Field“, „Split Class“)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-6 R O O T S
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
Vertreter VertreterVertreteraufKomissionsbasis:bool
komissionsZahlung()
if (aufKomissionsbasis) // zahle Komission;
{disjoint, complete}
return; VertreterAufKomission
komissionsZahlung()g()
VertreterMitFestgehalt
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-7 R O O T S
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
BankKunde BankKundeBankKundegeschlecht : int
BankKundekundenNr : intname : String
geschlecht = 1 bedeutet "Mann"geschlecht = 2 bedeutet "Frau"
{disjoint, complete}
geschlecht = 2 bedeutet Fraugeschlecht = 3 bedeutet "Firma" MenschlicherKunde
geschlecht : intgesetzlicherVertreter : Person
FirmenKundeFirmenWert : double
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-8 R O O T S
Prinzip: Nicht einheitliche Eigenschaften vermeiden!
Symptombestimmte Eigenschaften (Methoden oder Variablen) einer Klasse sind nur für manche Instanzen gültigfür manche Instanzen gültig
KonsequenzenAbhängigkeit von bestimmten Fallunterscheidungen Unklare FunktionalitätWartung erschwertWartung erschwert
BehandlungKl f littKlasse aufsplittenEvtl. Klasse einführen die „alle anderen Fälle“ darstellt
Beispiel: „VertreterMitFestgehalt“Dadurch komplette Partition möglichKlarere Bedeutung der Klassen
– Walter Hürsch: „Should superclasses be abstract?“, p. 12-31, ECOOP 1994 Proceedings LNCS 821 Springer Verlag
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-9 R O O T S
1994 Proceedings, LNCS 821, Springer Verlag.
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
Room
volume
Cylinder/ volume
volume
Cuboid/ volume
volume volumevolume
Cylinder/ volume
volume
Cuboid/ volume
volume
Room
volume
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-10 R O O T S
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
Cuboid 3DCl dShR shapeCuboid/ volumevolume()stretch (...)
3DClosedShape
/ volume: Volume
volume(): Volume
Room
/ volume: Volume
volume(): Volume
0..* 1shape
( )rotate (...)...
()stretch(...)rotate(...)...
()
Room CylinderCuboid
volume(): Volumestretch(...)
( )
volume(): Volumestretch(...)
t t ( )
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-11 R O O T S
rotate(...)...
rotate(...)...
Problem: Fehlende Ersetzbarkeit
Unterklasse hat eine stärkere Invariante als die OberklasseDreidimensionale Körper dürfen rotiert werdenRäume dürfen nicht rotiert werden!
Daraus resultiert fehlende ErsetzbarkeitDaraus resultiert fehlende ErsetzbarkeitIn einem Kontext wo man Rotierbarkeit erwartet darf kein nicht-rotierbares Objekt übergeben werden
Wichtig: Frühzeitig auf Interfaces achtenSie sind das Kriterium um über Ersetzbarkeit zu entscheidenSie sind das Kriterium um über Ersetzbarkeit zu entscheiden
Frage: Wie finden wir Interfaces?CRC Cards!
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-12 R O O T S
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
Endangered SpeciesAnimal0..* 1
Bear EndangeredSpecies
SpeciesAnimalname: Name
/ isEndangered : Boolean
{disjoint, complete}{incom plete}
PandaBear Endangered
SpeciesNonEndangered
Species
/ isEndangered = trueMiouMiou:Species
Hallo, ich bin
MiouMiou
{incom plete}
/ isEndangered = truewhenFirstEndangered:Date / isEndangered = false
MiouMiou:Panda
Wer hat behauptet ichPandaIch bin ein Panda!
☺
Wer hat behauptet ich sei eine Spezies?
Prinzip: Keine Verwirrung von Klassen und Instanzen!
Falle: Natürliche Sprache unterscheidet oft nicht zwischenFalle: Natürliche Sprache unterscheidet oft nicht zwischenKlasse: "Panda" als Name einer SpeziesInstanz: "Panda" als Bezeichnung für ein einzelnes Tierg
Ähnlich im technischen Bereich"P d kt" P d ktli ( B T l f )"Produkt" Produktline (zB. Telefone)"Produkt„ einzelnes Produkt (zB. mein Handy)
Frage: „Wer ist Instanz wovon?“"Miou-Mio ist ein Bär": OK
O"Miou-Mio ist ein Panda": OK"Miou-Mio ist eine Spezies": FALSCH!
Alternatives KriteriumErsetzbarkeitB K i h "Mi Mi " üb ll d i t i h i S i
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-14 R O O T S
Bsp: Kann ich "Miou-Miou" überall da einsetzen, wo ich eine Spezies erwarte?
OOM-Quiz
Was halten Sie hiervon? Und hiervon?
Circle CircleCircle# center
+ move()center := ...
Circle# center
+ move() center := ...
AS bCl AS bClASubClass
aMethod()center := ...
ASubClass
aMethod() move(...)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-16 R O O T S
Prinzip: Abhängigkeiten vermeiden!
Eine Abhängigkeit zwischen A und B besteht wennÄnderungen von A Änderungen von B erfordern (oder zumindestens erneute Verifikation von B) ... um Korrektheit zu garantieren
Eine Kapselungseinheit isteine Methode: kapselt Algorithmuseine Klasse: kapselt alles was zu einem Objekt gehört
PrinzipPrinzipAbhängigkeiten zwischen Kapselungseinheiten reduzierenAbhängigkeiten innerhalb der Kapselungseinheiten maximieren
NutzenW t f dli hk it
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-17 R O O T S
Wartungsfreundlichkeit
Beispiele: Abhängigkeiten von ...
Konventionif order.accountNumber > 0 // was bedeutet das?
WertP bl K i t t H lt d d t i h t D tProblem: Konsistent-Haltung von redundant gespeicherten Daten
AlgorithmusAlgorithmusa) implizite Speicherung in der Reihenfolge des Einfügens wird beim Auslesen vorausgestztb) Ei fü i H ht bl d S h i H ht bl ü l i h h hb) Einfügen in Hashtable und Suche in Hashtable müssen gleichen hash-Algorithmus benutzen
Impliziten AnnahmenWerte die Hash-Schlüssel müssen unveränderlich sein
Achtung bei Aliasing
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-18 R O O T S
Achtung bei Aliasing
Reduktion von Abhängigkeiten durch „Verbergen von Informationen“ („information hiding”)(„ g )
“Need to know” Prinzip „Schlanke Schnittstelle“Zugriff auf eine bestimmte Information nur dann allgemein zulassen wennZugriff auf eine bestimmte Information nur dann allgemein zulassen, wenn dieser wirklich gebraucht wird. Zugriff nur über wohldefinierte Kanäle zulassen, so dass er immer bemerkt
i dwird. Je weniger eine Operation weiß...
... desto seltener muss sie angepasst werden... desto seltener muss sie angepasst werden
... um so einfacher kann die Klasse geändert werden.
Zielkonflikt Verbergen von Informationen vs. Effizienz
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-20 R O O T S
Information Hiding (2)
Verbergen von internen Objekten an den Grenzen des SubsystemsDefiniere abstraktes Schnittstellen die zwischen dem System und der externen Welt sowie zwischen Subsystemen vermitteln ( Facade)
Verberge Datenstrukturen einer Klasse Nur Methoden der selben Klasse dürfen auf deren Attribute zugreifenNur Methoden der selben Klasse dürfen auf deren Attribute zugreifen
Führe eine Operation nicht auf dem Ergebnis einer anderen aus.Schreibe eine neue Operation, die die Navigation zu der Zielinformation kapselt. ( „Law of Demeter“: keine „transitiven“ Abhängigkeiten)
Law of Demeter („Talk only to your friends!“)• Klasse sollte nur von „Freunden“, d.h. den Typen der eigenen Felder, Methoden-
und Ergebnisparameter abhängig sein.
• Insbesondere sollte sie nicht Zugriffsketten nutzen, die Abhängigkeiten von den Ergebnistypen von Methoden der Freunde erzeugen. Beispiel:
Zielkonflikt
g yp g p
• Nicht: param.m().mx().my()….;
• Sondern: param.mxy(); wobei die methode mxy() den transtiven Zugriff kapselt.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-21 R O O T S
Verbergen von Informationen vs. „schlanke“ Schnittstellen.
Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel
Gibt es „gute“ Abhängigkeiten?
Kriterien für „problematische“ und „akzeptable“ Abhängigkeiten am Beispiel des Visitor Patterns
© 2000-2007 Dr. Günter Kniesel
Literatur
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: “Design Patterns - Elements of Reusable Object-Oriented Software”Addisson-Wesley 1999.
Robert C. Martin: “Design Principles and Design Patterns”http://www.objectmentor.com/resources/articles/Principles and Patterns.pdfhttp://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
Martin E. Nordberg: “Aspect-Oriented Dependency Inversion.” OOPSLA 2001 Workshop on Advanced Separation of Concerns inOOPSLA 2001 Workshop on Advanced Separation of Concerns in Object-Oriented Systems, October 2001http://www.cs.ubc.ca/~kdvolder/Workshops/OOPSLA2001/submissions/12-nordberg.pdf
Jan Hannemann and Gregor Kiczales: “Design Pattern Implementation in Java and AspectJ”, http://www cs ubc ca/~jan/papers/oopsla2002/oopsla2002 htmlhttp://www.cs.ubc.ca/~jan/papers/oopsla2002/oopsla2002.html
Wes Isberg: Tutorial, AOSD 2004 (Folien nicht öffentlich verfügbar) http://aosd net/2004/tutorials/goodaop php
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-23 R O O T S
http://aosd.net/2004/tutorials/goodaop.php
Das Visitor-Pattern: Motivation
BeispielCompiler für eine gegebene Programmiersprache enthalten Klassen für verschiedene Ausdrücke in dieser Sprache.
ProblemZusammengehöriger Code ist über alle Klassen verteiltEs ist schwer, ein neue Facette der Sprache zu implementieren
jede Klasse der Objektstruktur müsste geändert werden (zB um die
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-24 R O O T S
jede Klasse der Objektstruktur müsste geändert werden (zB, um die Typüberprüfung anzupassen)
Das Visitor-Pattern: Idee
Zi lZielNeue Operationen auf Objekten sollen definiert werden, ...
h d di Kl di... ohne dass die Klassen dieser Objekte geändert werden müssen!
IdeeZusammenfassung dieses C OCodes in Visitor-Objekte...... und Bereitstellung von "akzeptierenden" Methoden in der betroffenender betroffenen Klassenhierarchie.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-25 R O O T S
Das Visitor-Pattern: Allgemeine Struktur
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-26 R O O T S
Das Visitor-Pattern: Implementierung
Abstrakter VisitorJede Objektstruktur besitzt eine (abstrakte) Visitor-Klasse.j ( )Für jeden Typ T in der Objektstruktur, enthält die Visitor-Klasse je eineMethode mit einem Parameter vom Typ T visitT(T)
Konkrete VisitorsJede Unterklasse der Visitor-Klasse redefinieren die visit-Methoden umJede Unterklasse der Visitor-Klasse redefinieren die visit-Methoden, um ihre jeweilige Funktionalität zu realisieren.Jede konkrete visitT(T) Methode benutzt dabei die spezifischen Operationen des besuchten Objekttyps T
Tra ersier ng der Objektstr kt rTraversierung der Objektstruktur kann in der Objektstruktur (accept(...) Methoden) definiert sein
oder im Visitor-Objekt (visit ( ) Methoden)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-27 R O O T S
... oder im Visitor Objekt (visit...(...) Methoden).
Das Visitor-Pattern: Zusammenarbeitauf
welche Operation
welchem Objekt
... ist wie implementiert
accept(aVisitor)
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-28 R O O T S
Das Visitor-Pattern: Zusammenarbeitauf
welche Operation
welchem Objekt
... ist wie implementiert
accept(aVisitor)
Double dispatch
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-29 R O O T S
Das Visitor-Pattern: Konsequenzen
Hinzufügen neuer Operationen ist einfach.
Hinzufügen neuer Objektklassen ist sehr aufwendig. Folglich ist die entscheidende Frage: Werden häufiger neue Operationen oder neue Klassen eingeführt?g
Sammeln von Zuständen Visitor Objekte können Zustände der besuchten Objekte aufsammeln undVisitor-Objekte können Zustände der besuchten Objekte aufsammeln und (evtl. später) auswerten.Eine Übergabe von zusätzlichen Parametern ist dafür nicht nötig.
Verletzung von KapselungDie Schnittstellen der Klassen der Objektstruktur müssen ausreichend jFunktionalität bieten, damit Visitor-Objekte ihre Aufgaben erledigen können.Oft muss mehr preisgegeben werden als (ohne Visitor) nötig wäre.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-30 R O O T S
Abhängigkeiten im Visitor-Pattern
ConcreteVisitor1 und ConcreteVisitor2 haben gleiche Abhängigkeiten.ConcreteElementA und ConcreteElementB ebenso.Ab jetzt in der Darstellung nur ein RepräsentantAb jetzt in der Darstellung nur ein RepräsentantBei Vererbung sind damit immer mehrere abgeleitete Klassen gemeint.
ElementVisitor
Concrete Concrete ConcreteConcrete ConcreteVisitor2
ConcreteElementA
ConcreteElementB
ConcreteVisitor1
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-31 R O O T S
Stabilität und Abstraktheit im Visitor-Pattern
Abstraktheit:Grad der Unabhängigkeit von einer bestimmten Anwendung
Stabilität:Geringe Wahrscheinlichkeit sich ändernder Kundenanforderungen
Abstrakte Klassen, Interfaces [Hoher Anpassungsaufwand wegen vieler abhängiger Klassen]
ElementVisitor abstraktsehr abstrakt
stabilsehr stabilÄnderungen an
ConcreteElementÄnderungen an
ConcreteElement stabilsehr stabilerzwingen wegen
ungünstiger AbhängigkeitÄnderungen am Visitor
ConcreteConcrete Häufige Änderung ConcreteElement
ConcreteVisitor
sehr konkret konkret
sehr instabil instabil
Häufige Änderung unproblematisch,
weil keine anderen Klassen hiervon
abhängig
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-32 R O O T S
abhängig.
Bewertung der Abhängigkeiten im Visitor-Pattern
TRAC
TA
BS
T
ElementVisitor abstraktsehr abstrakt
stabilsehr stabil stabilsehr stabil
ConcreteConcreteCR
ETE
ConcreteElement
ConcreteVisitor
sehr konkret konkret
sehr instabil instabil
CO
NC
STABLE UNSTABLE
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-33 R O O T S
Bewertung der Abhängigkeiten im Visitor-Pattern
TRAC
T
VisitorA
BS
T Visitor
zyklische,problematische Abhängigkeit
Elementproblematische Abhängigkeit
Concrete
CR
ETE
ConcreteElement
ConcreteVi it
CO
NC
STABLE UNSTABLE
Visitor
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-34 R O O T S
Ungünstige Abhängigkeiten mit einem Blick erkannt
besser wiederverwendbareTR
AK
T
wiederverwendbare Klasse
AB
ST
schwer wiederverwendbareK
RET
wiederverwendbare Klasse
KO
N
STABIL INSTABIL
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-35 R O O T S
Vorzeichen von schlechtem Design(Bad Signs of Rotting Design, Robert C. Martin, 1996)( g g g , , )
StarrheitCode ist schwierig zu ändernDie Zurückhaltung etwas zu ändern wird zur Regel
ZerbrechlichkeitS lb t kl i Ä d kö k tt t Eff kt füh E llSelbst kleine Änderungen können zu verkettetn Effekten führenEven small Der Code wird an unerwartet Stellen inkonsistent
UnbeweglichkeitgDer Code ist so verworren, dass es unmöglich ist etwas wiederzuverwendenEin Modul könnte in einem anderen System wiederverwendet werdenEin Modul könnte in einem anderen System wiederverwendet werden, jedoch ist der Aufwand und das Risiko zu groß das Modul aus seinem Umfeld zu lösen
Zähi k itZähigkeitEinfacher zu “hacken”als das Ausgangs Design zu erhaltenMuch easier to hack than to preserve original design.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-38 R O O T S
Brauchen ein Abhängigkeits-Management
Entwicklungs - Prinzipien(Design Principles, Robert C. Martin, 1996)( g p , , )
Dependency Inversion Principle (DIP)Abhängigkeiten nur zu Abstrakterem, nicht zu Konkreterem!
Acyclic Dependencies Principle (ADP)D Abhä i k it h öff tli ht K t kli hDer Abhängigkeitsgraph veröffentlichter Komponenten muss azyklisch sein!
Stable Dependencies Principle (SDP)Abhängigkeiten nur zu Stabilerem, nicht zu Instabilerem!
Stable Abstractions Principle (SAP)Abstraktion und Stabilität eines Paketes sollten zueinander proportionalAbstraktion und Stabilität eines Paketes sollten zueinander proportional sein. Maximal stabile Pakete sollten maximal abstrakt sein. Instabile Pakete sollten konkret sein.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-39 R O O T S
Dependency Inversion Principle (DIP) & Stable Dependency Principle (SDP)p y p ( )
besser wiederverwendbareTR
AK
T
Nutzlose Klassewiederverwendbare Klasse
AB
ST Nutzlose Klasse
schwer wiederverwendbareK
RET Unwartbare
Kl wiederverwendbare Klasse
KO
N
STABIL INSTABIL
Klasse
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-41 R O O T S
Vorlesung Softwaretechnologie 2007/8Kapitel 9: Objektorientierte Modellierung R O O T Sap te 9 Obje to e t e te ode e u g
Zusammenfassung & Ausblick
OO Modellierung: Rückblick
CRC-Cards Identifikation KlassenOperationenenOperationenenKollaborationen
Design by Contract Verfeinerung des VerhaltensDesign by Contract Verfeinerung des VerhaltensVorbedingungenNachbedingungenInvariantenInvariantenErsetzbarkeit
Prinzipien Strukturierung von OO Modellen: Vermeiden vonPrinzipien Strukturierung von OO-Modellen: Vermeiden vonRedundanzenNicht-einheitlichem VerhaltenVerwirrung von Klasse und InstanzVerwirrung von Klasse und InstanzFehlender Ersetzbarkeit Abhängigkeiten von nicht-inhärenten TypenAbhängigkeiten von spezielleren oder instabileren Typen
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-43 R O O T S
Abhängigkeiten von spezielleren oder instabileren Typen
OO Modellierung: Weiterführende Informationen
Modellierungs-Prinzipien („Quiz“) Page-Jones, „Fundamentals of Object-Oriented Design in UML“, Addison Wesley, 1999Sehr empfehlenswert!
CRC-CardsKonzentriert: Fowler & Scott, „UML distilled“ (2te Ausgabe), Addison WesleyOriginal-Artikel: http://c2.com/doc/oopsla89/paper.html
Design by ContractKonzentriert: Fowler & Scott, „UML distilled“ (2te Ausgabe), Addison W lWesleyOriginal-Buch: Bertrand Meyer, „Object-oriented Software Construction“, Prentice Hall, 1997.
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-44 R O O T S
Ein Klassiker!
OO Modellierung: Weiterführende Informationen
Abhängigkeiten (Stable dependency principle, …)Robert C. Martin: Design Principles and Design Patternshttp://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
Brechen von Abhängigkeiten mit Hilfe Aspektorientierter ProgrammierungMartin E. Nordberg: A t O i t d D d I iAspect-Oriented Dependency Inversion. OOPSLA 2001 Workshop on Advanced Separation of Concerns in Object-Oriented Systems, October 2001http://www cs ubc ca/ kdvolder/Workshops/ OOPSLA2001/submissions/12http://www.cs.ubc.ca/~kdvolder/Workshops/ OOPSLA2001/submissions/12-nordberg.pdfVorlesung AOSD, Wintersemester 2006, Universität Bonnhtt // t i i i b d /t hi / l /2006 dhttp://roots.iai.uni-bonn.de/teaching/vorlesungen/2006aosd
Vorlesung Softwaretechnologie, Wintersemester 2007/8 09-45 R O O T S