of 40/40
Vorlesung Softwaretechnologie 2007/8 Dr. Günter Kniesel R O O T S Dr. Günter Kniesel Kapitel 9 Objektorientierte Modellierung (Æ nicht in Brügge & Dutoit) Vermeide Redundanzen Vermeide Bezug auf nicht-Inhärente Typen Vermeide nicht-einheitliches Verhalten Vermeide Verwirrung von Klasse und Instanz Vermeide fehlende Ersetzbarkeit in Typhierarchien Vermeide Abhängigkeiten © 2000-2007 Dr. Günter Kniesel Was sind akzeptable Abhängigkeiten?

Kapitel 9 Objektorientierte Modellierung · Kapap te 9 Obje to e t e te ode e u gitel 9: ... Pbl K it tProblem: Konsistent-Hlt ddt iht DtHaltung von redundant gespeicherten Daten

  • View
    1

  • Download
    0

Embed Size (px)

Text 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?

    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/ volumevolume

    Cuboid/ volumevolume volumevolume

    Cylinder/ volumevolume

    Cuboid/ volumevolume

    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 EndangeredSpeciesSpeciesAnimal

    name: Name/ isEndangered : Boolean

    {disjoint, complete}{incom plete}

    PandaBear EndangeredSpecies

    NonEndangeredSpecies

    / 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 abstraktstabilsehr 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 abstraktstabilsehr 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 wiederverwendbareKR

    ET

    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 wiederverwendbareKR

    ET 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