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