Wie erfülle ich die 5 Grundprinzipien / Wie modelliere ich „gut“?

Regel 1: Sparsames Einsetzen von Vererbung

• Viele Vererbungen lassen sich mit Assoziationen umgehen
• Vererbung nur bei echter “ist ein” Beziehung verwenden
• Wenn man Vererbungen verwendet, dann möglichst nur Einfachvererbungen
• Vererbungen nicht zu tief verschachteln

Regel 2: Normalisiere das Datenmodell

• 1. Normalform:
  • Jedes Attribut der Relation muss einen atomaren Wertebereich haben
• 2. Normalform:
  • jedes Nichtschlüsselattribut ist von jedem Schlüsselkandidaten voll funktional abhängig
• 3. Normalform:
  • kein Nichtschlüssel hängt von irgendeinem Schlüsselkandidaten transitiv ab
• Normalisiere das Datenmodell: Mindestens 3. NF

Regel 3: Vermeide transitive Assoziationen

• Durch Zyklen gibt es mehrere Wege für eine Beziehung zwischen zwei Objekten
• Man sollte versuchen solche Zyklen durch das entfernen von bestimmten Assoziationen aufzulösen
• Wenn das Auflösen eines Zyklus‘ nicht möglich ist, müssen Widersprüche mithilfe von Constrains verhindert werden

Regel 4: Analysiere m:n-Beziehungen genau

Beispiel: Lösung:

• m:n-Beziehungen werfen oft Probleme auf
• diese Beziehungen können jedoch meistens durch Assoziationsklassen dargestellt werden
  • Probleme können dadurch behoben werden
• n:m Beziehungen werden durch eine Assoziationsklasse ersetzt, die zu den verbundenen Klassen mit 1:* Multiplizität verbunden ist.

Weitere Regeln

• Vermeide 1:1-Beziehungen
  • Oft kann man sich diese Assoziation sparen und beide Entitäten zu einer zusammenfassen
• Es werden nie technische Aspekte modelliert
• Beschränkung bei der Modellierung auf die wirklichen Anforderungen

Entwurf von Operationen und Schnittstellen

Regel 1: Operationen sind unabhängig von der verwendeten Technologie !

• Versuche, möglichst wenig über die interne Funktionalität / Umsetzung einer Operation zu verraten
  • nichts über die Datenspeicherung, Datenstrukturen, die das System verwendet sichtbar machen
    • z.B. Stack
    • SAP
    • …
• Entwerfe Operationen so,
  • dass die Funktionalität intuitiv erkennbar sind
  • dass sie eigenständig funktionieren
    • so sind sie austauschbar
    • sie können gegebenenfalls für andere Systeme verwendet werden

Regel 2: Gib keine Referenzen nach außen!

• Versuche keine Pointer zu übergeben
  • Pointer sind nur innerhalb dieses Systems gültig
  • Pointer verraten Weiteres über die Funktionalität
• Referenzen erhöhen die Abhängigkeit zwischen Systemteilen
• Gefahr von Fehlern erhöht
• Ausnahme: Werden viele Daten benötigt, kann diese Regeln übergangen werden, da die Funktionalität ansonsten sehr umständlich wird

Regel 3: Normalisiere die Schnittstelle !

• Entwerfe eine Schnittstelle so, dass es nichtmehrere Möglichkeiten gibt, die gleiche Funktionalität umzusetzen
  • Redundanz wird verhindert
• Benenne die Schnittstelle so, dass ihre Funktionalität offensichtlich ist
  • Wartbarkeit wird verbessert
• Unterscheide schreibende und lesende Methoden

Regel 4: Mache die Operationen grobgranular !

• bietet mit einer Operation die Funktionalität, die der Aufrufer erwartet und braucht
• verbirgt vor dem Aufrufer die Komplexität, die in der Umsetzung einer Funktionalität durch atomare Operationen und Befehle steckt

Regel 5: Mache die Operationen idempotent !

• Auch wenn der Aufruf (versehentlich) mehrfach erfolgt, wird das gleiche Ergebnis geliefert
• Beugt Gefahr von unerwarteten Ergebnissen vor
• Zuverlässigkeit wird gefördert

Regel 6: Mache die Operationen kontextfrei !

• besorgt sich selbst die erforderliche Kontext-Information
• Aufruf wird einfacher
• viele Probleme werden im Vorfeld verhindert

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 15) erschien zuerst auf Maximilian Krieg.

• Aufzeichnungen von OOAD-Vorlesungen gibt es
  • Prof. Hahn hat im WS11/12 aufgezeichnet
  • Aufzeichnungen befinden sich auch seine Homepage (Link auch auf der Seite von Prof. Grieser)

Zur Klausur

• Es darf ein doppelseitig, handgeschriebenes A4 Blatt benutzt werden
• Ansonsten werden nur Stifte benötigt

Wann ist ein System gut?

1. Grundprinzip: Trennung von Zuständigkeiten

• Unterteilen des Systems, sodass jeder Teil nur eine Aufgabe hat

2. Grundprinzip: Minimierung von Abhängigkeiten

• Zusammenfassen von stark zusammenhängenden Teilen
• so wenige Aufrufe und Assoziationen wie möglich verwenden

3.Grundprinzip: Information Hiding / Geiheimnisprinzip

• Internes Wissen eines Systemteils wird gekapselt, sodass es keinem anderen Teil bekannt ist.
  • Abläufe, Daten, Strukturen
  • Der Systemteil muss nutzbar sein, ohne etwas über seine Realisierung zu verraten
  • Internes darf nicht von außen einsehbar sein
• Implementierung
  • „getter„/“setter“
    • Attribute und Methoden als „private“ deklarieren
• zusätzlicher Vorteil:
  • Trennung von Zuständigkeiten und Minimierung von Abhängigkeiten werden unterstützt / erleichtert
  • fördert Wartbarkeit, Änderbarkeit und Testbarkeit

4. Grundprinzip: Homogenität

• Es gibt Komponenten, die sehr Komplex sind uns Komponenten die sehr einfach zu realisieren sind. → Unterschiedliche hoher Arbeitsaufwand → inhomogen
• Löse ähnliche Probleme mit ähnlichen Lösungen
  • bereits bekannte Lösungen wiederverwenden, wenn möglich.
  • Systemteile innerhalb einer Strukturierungsebene so entwerfen, dass sie etwas gleich groß und komplex sind.

5. Grundprinzip: Redundanzfreiheit

• System so entwerfen, dass jeder Teil im System nur an einer Stelle umgesetzt wird.
  • Herausziehen von mehrfach verwendeten Teilen
    • Verfügbar machen dieser Teile für Andere
  • Finden einer sinnvollen „Heimat“ für den Systemteil
• fördert auch Trennung von Zuständigkeiten
• verringert die Aufwendigkeit von Änderungen / Korrekturen

→ Ein Entwurf ist gelungen („gut“), wenn er die 5 Grundprinzipien erfüllt

Wie erreiche ich diese Ziele?

Ein Beispiel:

• Ein Softwaresystem, dass Kunden, Lieferanten und Mitarbeiter verwalten soll
• Problem: Änderungen sind schwierig umsetzbar
  • z.B. Beförderung eines Arbeiters zum Manager

Eine ganz andere Lösung

• Nun kann eine Person mehrere Rollen einnehmen
• Beförderungen und Ähnliches sind nun kein Problem mehr
• Es können einfach neue Rollen hinzugefügt werden
• „Rolle“ wird nicht als Attribut von „Person“ dargestellt
  • Zuständigkeiten sind getrennt
  • Bei Änderung der Rolle einer Person kann die Person „unverändert“ bleiben

Regel 1: Sparsames Einsetzen von Vererbung

• Viele Vererbungen lassen sich mit Assoziationen umgehen
• Vererbung nur bei echter „ist ein“ Beziehung verwenden
• Wenn man Vererbungen verwendet, dann möglichst nur Einfachvererbungen
• Vererbungen nicht zu tief verschachteln

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 14) erschien zuerst auf Maximilian Krieg.

Kontrollfragen auf Seite 312

• möglicherweise Klausurrelevant!!

Objektdiagramm

• sieht aus wie Klassendiagramm
• beinhaltet die Instanzen der Klassen
• Objekte haben Werte!
• Arbeitet erstmals mit Pointern!

Klassendiagramme

• zeigen nur, was möglich ist
• es werden Vererbungsbeziehungen dargestellt
• zeigt Assoziationen in allgemeiner Form
• Es werden keine Werte dargestellt

Komponentendiagramm

• am Symbol rechts oben erkennbar
• GUI wird ausgelagert!
• Man arbeitet mit Schnittstellen
• Artefakte = reale Dateien
• Enthält abgeschlossene Einheiten
• Austauschbarkeit gewährleistet (z.B. Fake-Internet einbauen zum Test)
• Man teilt das System in einzelnen Komponenten auf, um diese evtl. verschiedenen Arbeitsgruppen zuzuordnen und gegebenenfalls einfacher Korrekturen durchführen zu können.
• Da die Komponenten möglichst unabhängig funktionieren, ist es relativ einfach, eine Komponente durch eine andere zu ersetzen/auszutauschen

Paketdiagramm

• Pakete nehmen eine ähnliche Funktion ein, wie Ordner in Dateisystemen
• In Pakete werden Modellelemente einsortiert
• Verschachtelung ist möglich
• Jedes Paket hat seinen eigenen Namespace
• Dienen zur logischen Strukturierung
• unterschiedliche Diagramme in verschiedene Pakete einordnen

Wann wird welches Diagramm verwendet?

• Es gibt nie nur eine Lösung. Mehrere sind möglich
• Ein Diagramm stellt nie das ganze System dar
  • Es werden immer nur Teile des Systems dargestellt
  • Durch Beschreibungen der Beziehungen zwischen diesen einzelnen Teilen kann das System als Ganzes betrachtet werden.

Woran erkennt man Gutes/Schlechtes Design?

Gutes Design

• Funktionalität, die gewünscht ist, ist gegeben
  • nicht viel mehr, da das System sonst zu komplex wird, zusätzliche Arbeit und Kosten entstehen und es dem Kunden evtl. nicht gefällt.
• Das System ist eindeutig und einfach zu verstehen
  • gute Dokumentation
  • Außenstehende sollten es verstehen können
• keine Redundanz von Elementen vorhanden
• Mögliche Änderungen sollten leicht umgesetzt werden können
  • einfache Integration muss möglich sein
• Änderungen, die im Nachhinein gemacht werden, sollten nur die Systemteile betreffen, in denen sie auftreten
• Der Aufwand einer Änderung muss proportional zur Größe der Änderung sein

→ Ein System ist dann gut, wenn es lange leben kann.

Über 90% der Kosten entstehen durch die Pflegung des Systems. Dementsprechend muss es so gebaut sein, dass diese Kosten möglichst gering gehalten werden können.

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 13) erschien zuerst auf Maximilian Krieg.

Zustandsübergänge

• Pfeile zwischen aktuellem und folgendem Zustand
• Details zum Übergang werden am Pfeil notiert

Übung: Ein C++ Kommentarfilter

• Zeichnen Sie das Zustandsdiagramm eines Filters, welcher einen C++-Text aus einem Eingabestrom einließt, alle C++ Kommentare entfernt und das Ergebnis in den Ausgabestrom schreibt.
• Tipps:
  • Überlegen sie sich zuerst, warum sie dafür ein Zustandsdiagramm brauchen.
  • Es müssen mehrzeilige Kommentage /*…*/ und einzeilige Kommentare // erkannt werden
  • Jede Zeile wird durch EOLN abgeschlossen. Der Eingabestrom wird durch EOF abgeschlossen
  • Passen sie auf Strings auf. s = „Hello /* world*.
  • Durch z = read() wird das nächste Zeichen aus dem Eingabestrom eingelesen und durch write (z) wird das nächste Zeichen in der Variable z in den Ausgabestrom geschrieben.

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 12) erschien zuerst auf Maximilian Krieg.

• am 30.5. das Praktikum findet statt, aber es wird verschoben

Start: Seite 227

Sequenzdiagramme

• Interaktionen zwischen Akteur und Objekten des Systems
• Lebenslinien enthalten Ablaufreihenfolge
• „Highlander“-Prinzip, es ist immer nur einer aktiv
• Beschreibung an den Pfeilen = Name der Methode / Aktivität
• Nachricht = Offener Pfeil
• Aufruf = Geschlossener Pfeil
• Sequenzdiagramme beschreiben einen Ausschnitt und kein komplettes Verhaltensdiagramm mehr.
• Es wird von Links nach Rechts gelesen und von oben nach unten
• Je Fall ein eigenes Sequenzdiagramm → Exmatrikulation klappt oder klappt nicht
• Rückgabe der Aktivität nur mittels return möglich!
• Zwischen Aufruf und Rückgabe, kann das Objekt nichts ausführen ( bei Synchron! )

Beispiel: Exmatrikulation

• Sachbearbeiter gibt Matrikelnr. ein
• Maske prüft, ob der Student existiert
• Studentenverwalter liefert den Student zurück
• Lösch-Bestätigung fehlt im Diagramm

Die beiden Sequenzdiagramme beschreiben nur erfolgreiche Anwendungsfälle. Um Fehlerfälle zu beschreiben müssten jeweils ein neues Diagramm erstellt werden.

• Die Aktivität eines Objekts beginnt immer mit dem Aufruf und endet mit einem Return
• Methodenaufrufe können nur von aktiven Objekten erfolgen
• Returns müssen zwar nicht eingezeichnet werden, sollten sie jedoch, damit das Ende einer Methode eindeutiger wird

Beispiel: Essen zahlen

• Notizen
  • Schreiben auf das Display ist eine Print-Funktion, somit ist auch nach Ende der Aktivität der Text noch zu lesen
  • Es werden nur Akteure und nötige Objekte beschrieben, das Essen und das Herantreten an die Kasse gehören nicht zu dem Anwendungsfall bzw. der Sequenz
  • Verarbeitung und Logik sollte der Kasse als Verantwortung gehören
  • Die Karte hat keine eigenen Methoden (z.B.: lies() )
  • Wenn die Verarbeitung im Lesegerät liegt, wird ein anderes Lese-/Schreibverfahren die Anforderung haben, dass die Methoden redundant implementiert werden.
• Welche Aktoren gibt es?
  • Mensakunde
  • Kassenfrau
• Wie laufen die Aufrufe?
  • Kunde geht zur Kasse ( Trigger )
  1. Mensafrau gibt Artikelnr. in Kasse ein
  2. Kasse zeigt Betrag auf Display an
  3. Kunde schiebt Karte in Lesegerät
  4. Kasse bucht Betrag von Mensakarte ab
  5. Alternative: Kasse zeigt Fehlermeldung auf Display an
  6. Kunde entnimmt Karte aus dem Lesegerät

Fehler

• Akteure haben keine Methoden ( Nur Nachricht senden möglich )
• Kapselungsbruch ( Nicht aufrufen, sondern informieren!)
• Zuviele Aktivitäten/Verzweigungen in einem Sequenzdiagramm ( Aufteilen! )
• Verzweigungen asynchron darstellen ( Sollten synchron sein )

Anwendung

• Alternativen (sparsam einsetzen)
• Ausgliederung komplexer Aktivitäten in neue Sequenz-Diagramme mittels ref (sparsam verwenden)
• Schleifen ( Auf Konstruktoren aufpassen )

Ende: Seite 255

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 11) erschien zuerst auf Maximilian Krieg.

Besprechung Schachspiel

• Komposition zwischen Figuren und Mannschaft nötig, damit man weiß, dass genau 1 König zu der Mannschaft gehört.

Multiplizitäten

• Umsetzung von Klassen und Assoziationen
  • Attribute und Methoden können in objektorientierten Sprachen direkt umgesetzt werden
  • Generalisierung wird mittels Vererbung umgesetzt
  • Schnittstellen finden sich in abstrakten Klassen mit rein virtuellen Methoden wieder
  • Umsetzung von einfachen Assoziationen geschieht über Referenz auf ein anderes Objekt
    • Die Multiplizitäten „0..1“ und „1..1“ werden mittels eines Zeigers umgesetzt
    • Die Multiplizitäten „0..*“ bzw. „1..*“ werden über Zeigermengen dargestellt, wie z.B. Vektoren oder Arrays
    • Der Name des Attributs  ist der Name der assoziierten Klasse
  Die obige Umsetzung kann automatisch mittels eines Generators durchgeführt werden.// Spezifikation von Veranstaltung class Veranstaltung { protected: Dozent* Referent; public: ... } } // Spezifikation von Dozent Liste<Veranstaltung*> gehaltene_Veranstaltung; public: class Dozent { protected: ... }

Assoziationsklassen

• Realisierung durch „Einschub“ einer Klassen zwischen den bestehenden Klassen
• Die Rollen-Namen werden auch in den Zwischenklassen-Zeigern beibehalten
• Die Zwischenklasse braucht Zeiger auf beide verbundenen Klassen
• Multiplizitäten an den Klassen werden substituiert und durch 1 ersetzt A *                    1..* B A 1  1..* C *  1 B

class Anstellung {
  protected:
    Firma* m_Arbeitgeber; // Referenz auf assoziiertes Objekt
    Person* m_Arbeitnehmer; // Referenz auf assoziiertes Objekt
    unsigned int Gehalt; // Attribut der Assoziation
    string urlaub_von_bis; // Attribut der Assoziation  ...
  public:
    virtual Person* getArbeitnehmer (void) const{ return (m_Arbeitnehmer); }
    virtual Anstellung* setArbeitnehmer (const Person* einArbeitnehmer){
      m_Arbeitnehmer = einArbeitnehmer;
      return (this);
    }
    virtual Firma* getArbeitgeber (void) const{ return (m_Arbeitgeber);}
    virtual Anstellung* setArbeitgeber (const Firma* einArbeitgeber){
      m_Arbeitgeber = einArbeitgeber;
      return (this);
    }
    virtual void Urlaub_beantragen (string anfang_ende){
      urlaub_von_bis = anfang_ende;
};
...
}

class Person {
  protected:
    Liste<*Anstellung> m_Arbeitgeber;
  public:
    Anstellung* getAnstellung (const Firma* dieFirma) const {
      // Navigieren auf dem Container gemäß gegebener Datenstruktur (Liste).
      // Liefert die Referenz auf das Objekt der Assoziationsklasse, das die
      // Referenz auf die übergebene Firma hält. So ist das Setzen und Lesen von
      // Attributen bzw. das Ausführen von Methoden der Assoziation möglich.
}
    virtual unsigned getAnstellungsGehalt (const Firma* derArbeitgeber) const {
      // Zugriff auf ein Assoziationsklassen-Attribut:
    return (getAnstellung (derArbeitgeber)-> getGehalt());
}
    void do_Anstellung_Urlaub_beantragen (const Firma* derArbeitgeber, string anfang_ende){
      // Ausführen einer Assoziationsklassen-Methode:
      getAnstellung(derArbeitgeber)->Urlaub_beantragen(string anfang_ende);
}
...

}

Gesprächs-Ebenen

• A: Analyse
• T: Design

Aggregation und Komposition

• Aggregation: Wird mit einem Zeiger realisiert
• Komposition: Teilklassen sind Member-Attribute der Komposition

Kommunikation zwischen Objekten

• Objekte kommunizieren mittels Methoden miteinander
  • Objekt X sagt Objekt Y „Führe y.a() aus“.
  • Objekt Y gibt den Wert zurück
• Aufrufe
  • Synchron: 
    • Während Y.a() ausgeführt wird, ist X im idle-Modus (tut nichts)
    • Deterministisch: a b
    • Ausgefüllter Pfeil
  • Asynchron: 
    • X arbeitet direkt weiter und übergibt Y die „Verantwortung“
    • Nicht deterministisch: / b a / a b / …
    • Pfeilspitzen

Klausur

• Sequenzdiagramme sind wichtig!

Sequenzdiagramme

• Objekte die oben stehen, existieren bereits zu beginn
• Objekte, die tiefer stehen, werden erst im Verlauf erzeugt
• Returnpfeile sind optional, aber sind empfohlen
• Jedes Objekt hat seine eigene Bahn
• So ist eindeutig, wer Nachrichten an wen übermittelt
• Nachrichten, die geschickt werden, sind genau die Methoden, die angeboten werden

Synchrone Nachrichten

• Nach Senden einer Nachricht, wartet der Sender, bis der Empfänger die Nachricht empfangen hat und diese vollständig abgearbeitet wurde. Dann kann er weitersenden.
• Die Kontrolle wird abgegeben
• Synchrone Nachrichten sind Methodenaufrufe.
  • Wird eine Methode aufgerufen, so wird gewartet, bis die Methode abgearbeitet wurde.
• Darstellung: schwarz gefüllter Pfeil

Asynchrone Nachrichten

• nach Senden einer Nachricht, kann der Sender sofort weitersenden, während der Empfänger die Nachricht abarbeitet.
• paralleles Arbeiten von Sender und Empfänger
• Benachrichtigungen an bzw. vom Benutzer sind immer asynchron.
  • Eingaben, Ausgaben
• Darstellung: normaler Pfeil

Der Unterschied zwischen synchronen und asynchronen Nachrichten ist wahrscheinlich Teilthema der Klausur. Objekte, die sich in einem Sequenzdiagramm am oberen Rand befinden, sind zu Beginn des Szenarios schon vorhanden. Objekte, die sich weiter unten befinden werden erst später erstellt.

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 10) erschien zuerst auf Maximilian Krieg.

Assoziationen

• Aggregation
• Komposition
• „A kommt vor K, das Leere kommt vor dem Tod ( Schwarz )“

Aggregation

• „ist Teil von“
•  leere Raute
• Aggregiertes Objekt ist ist zwar Bestandteil, existiert aber unabhängig vom aggregierenden Objekt
• „shared“ Aggregation (kann zu mehreren Objekten gleichzeitig gehören, d.h. die Multiplizität darf > 1 sein) → Mitglied in mehreren Vereinen

Komposition

•  „besteht aus“
• volle Raute
• Teilobjekte einer Komposition
  • werden beim Zerstören des „Ganzes-Objektes“ automatisch (kaskadierend) mitzerstört
  • dürfen nicht Teil anderer Kompositionen sein
  • dürfen nur von Operationen der „Ganzes-Klasse“ entfernt oder ersetzt werden
• Komposition (=“unshared“ Aggregation)
• Multiplizität kann auf der Seite der Komposition weggelassen werden

Constraints

• Ohne Constraints könnte laut Modell der Motor sowie das Getriebe ein anderes Kupplungsexemplar assoziieren als das übergeordnete Auto selbst
• Resultat:

Übung

• Entwerfen Sie ein Klassenmodell mit Attributen und Multiplizitäten! Sie entwickeln Software für ein Autoradio. Die folgenden Informationen sollen dargestellt werden:
  • Das Autoradio hat 3 „Ebenen“ von Stationstasten (z.B. „UKW“, „MW“ und „TRAVEL“). Jede dieser Ebenen enthält 6 Stationstasten.
  • Auf jeder Stationstaste kann in jeder Ebene ein Radiosender abgespeichert werden. Es gibt analoge und digitale Sender. Bei digitalen Sendern wird zur werden. Es gibt analoge und digitale Sender. Bei digitalen Sendern wird zur Erkennung ein Textstring (z.B. **FFH**) vom Sender übertragen und als Name angezeigt. Bei analogen Sendern wird stattdessen die Empfangsfrequenz als Text angezeigt.
  • Beim Abspeichern eines Senders werden die Empfangsfrequenz und auch der Erkennungstext abgespeichert und in Zukunft neben der Stationstaste angezeigt.
  • Ein Radiosender muss nicht wissen, ob er auf einer Stationstaste liegt.
  • Das Radio kennt immer den aktuell gehörten Radiosender. 

Hinweise:

• Assoziation = „Haben die was miteinander zu tun?“
• Nav. Richtung = „Von wo komme ich wohin?“
• Es wird nur für das System allein modelliert ( andere Radios werden nicht bedacht )
• Bei der Klausur werden Punkte für syntaktisch korrekte Modellierung vergeben, z.B.: sind Klassen Substantive und keine Adjektive ( Digital → Digital Sender )

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 9) erschien zuerst auf Maximilian Krieg.

• Steine:
  • Umsetzung ohne Steine ist möglich in der Umsetzung aber missverständlich im Design. Beim Schachspiel z.B. brauch man eigene Stein-Objekte mit ihren eigenen Funktionen.
• Brett:
  • Besteht aus seinen Feldern, die mittels x,y-Koordinaten identifiziert werden
• Spieler
  • Spieler darf keine eigene Farbe / Symbol als Attribut haben, da er sonst keine zwei Spiele gleichzeitig ( andere Spieltische ) spielen könnte. D.h. eine Verbindung zwischen Spieler und Stein muss erzeugt werden ( Farbe des Steins → Spieler )
• Spieler-Spiel
  • Zwischen Spieler und Spiel enthält eine Assoziationsklasse ein Attribut mit der Information: „Wer hat welchen Stein in welchem Spiel?“

Assoziationsklassen

• Kann es nur dort geben, wo es auch Assoziationen gibt
• Dient dazu um besondere individuelle Informationen zu speichern, die in keine der 2 verbundenen Klassen gehört, aber nicht irrelevant sind

Constraints

• zu dt. „Einschränkung“
• Auch für Assoziationen möglich
• Beispiel: Polygon
  • Vier Punkte, die eine definierte Reihenfolge haben.
  • Ohne die Reihenfolge lässt sich das Polygon beliebig darstellen.
  • Ein Constraint erlaubt es einheitliche Objekte zu erstellen.
• Beispiel: Vergütung
  • Je nach Typ wird durch den Constraint dem Vergütungs-Berechtigten eine entsprechende Vergütung zukommen.
  • Professor bekommt Professoren-Vergütung
  • Tutor bekommt Tutoren-Vergütung

Höherwertige Assoziationen

• Oft sind vermeintliche 3-er Beziehungen in Wahrheit drei 2-er Beziehungen!
• 3-er und höherwertige Assoziationen sollten, falls möglich, vermieden werden !
• Oft gibt es Alternativen zur 3-er bzw. höherwertigen Assoziation durch die Einführung einer Klasse statt 3er-Beziehung
• Bsp.: 
  • Fußballspieler – Mannschaft – Saison
  • Fußballspieler R spielt in Saison X bei Mannschaft A
  • Fußballspieler R spielt in Saison X+1 bei Mannschaft B

Zusatzfragen

• Sie sitzen in einer Vorlesung. Wo ist die Beziehung zu Ihrem Professor?
• Was verändert sich, wenn 2 Professoren eine Masterarbeit betreuen?
  • Eine Zwischenklasse anstelle der Assoziationsklasse muss eingeführt werden

[Student]^1  0..1 [MA] ^0..*  0..2 [Professor]

• Was verändert sich, wenn wir darstellen wollen, dass Lehrbeauftragte zu mehreren Fachbereichen gehören können, Professoren aber nur zu einem?
  1. Einführung einer Klasse Lehrbeauftragter (LB)
  2. Die Assoziation Fachbereich  Dozent muss aufgelöst werden
  3. Neue Assoziationen: Fachbereich  Professor & Fachbereich  LB
  4. Dozent vererbt seine Fähigkeit zu unterrichten an LB und Professor
  5. Dozent wird um ein Attribut Fachbereich ergänzt
• In Lehrveranstaltungen werden Werte von Attributen redundant gespeichert (In  der OOAD-LV von Herrn Weber, als auch in der OOAD-LV von Herrn Hahn stehen Titel und ECTS). Wie könnte man das vermeiden? stehen Titel und ECTS). Wie könnte man das vermeiden?
  • Einführung einer Klasse Modulhandbuch und Ausgliedern der Attribute

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 8) erschien zuerst auf Maximilian Krieg.

• Aufgaben:
  1. Klassen und Attribute identifizieren
  2. Generalisierungs und Spezialisierungs-Beziehungen identifizieren
  3. Klassendiagramm anfertigen
• Substantivmethode
  • Hochschulverwaltung
  • Personengruppen
  • Hochschule
  • Semester
  • Lehrveranstaltungen
  • Angestellte
    • Professoren
    • Labor-Ingenieure
    • Lehrbeauftragte
    • Sekretärinnen
    • Tutoren
    • Gehaltskonto
  • Dozenten
    • Akademischer Titel
    • Anzahl Semesterwochenstunden (SWS)
  • Studenten (auch als Tutor möglich )
    • Matrikelnummer
  • Person
    • Namen
    • Geburtsdatum
    • Geburtsort

Polymorphie

• Ein Objekt hat mehrere Typen bzw. Klassen und all deren Merkmale

Wechsel von Klassen innerhalb der Klassenhierarchie

• Petra, die eine Stundentin ist, und nun ihren Typen innerhalb der Hierarchie ändert ( von Student → Studentischen Tutor ) dann muss sein Objekt zerstört und neu erzeugt werden
• Der Laboringenieur Peter wird nun Lehrbeauftragter. Für ihn wird ein zweites Objekt des Typen Lehrbeauftragter angelegt, da er ja auch gleichzeitig noch Laboringenieur ist.

Assoziationen

• Keine genauere Definition, d.h. Klassen „kennen sich“
• Assoziationen werden zwar über Pointer und Pointerfelder realisiert ( aber als Assoziationen modelliert !! )
• Tätigkeiten
  • Beschriftung der Assoziation =  Beschreibung einer Tätigkeit
  • Assoziationen haben einen ausgefüllten Pfeil neben dem Namen stehen, der Pfeil steht für die Leserichtung der Tätigkeit „X arbeitet für Y“

• Die Assoziation zwischen Personal und seiner eigenen Klasse nennt man „Zyklische Assoziation„.
• Wenn mehrere Assoziationen zwischen zwei Klassen bestehen (z.B.: hat Aktien von) dann sind dies auch vollwertige Assoziation und werden mit einer eigenen Linie dargestellt.
• Navigationsrichtung
  • Wer kennt wen?
• Rollen
  • Firma hat in der Assoziation „Firma – Person“ die Rolle „Arbeitgeber“.
  • Person hat die Rolle „Arbeitnehmer“

Analyseklassen-Diagramm

• Nur Klassen, Assoziationen und Attribute
• Keine Methoden und keine Assoziationsrichtungen oder Multiplizäten

Designklassen-Diagramm

• Vollständiges Klassendiagramm

Navigationsrichtung

• Teil der Assoziation
• Kein Zeichen = unspezifiziert
• Kreuz = verbotene Navigationsrichtung
• Die Navigationsrichtung ist nicht das gleiche wie die Leserichtung!
• Bsp.: Der Auftrag kennt seine Artikel, die Artikel kennen aber ihre Aufträge nicht

Multiplizität

• Das Ausdrücken von Mengen-Beziehungen bei Assozitiationen
• Bsp.:„Dreieck braucht drei Ecken“, „Firma braucht mindestens einen Angestellten“

Interpretationsrichtung:  

• x kennt m mal y 
• y kennt n mal x

Finden von Assoziationen

• „Schauen was getan wird“
• Filtern nach relevanten Aktivitäten

Modellierungs-Regeln

• Kein Pointer-Attribut verwenden, sondern graphisch mit Assoziationen darstellen
  • übersichtlicher
  • Unabhängigkeit von Programmiersprachen
• Multiplizitäten sollten angegeben werden
  • Welche Attribute werden benötigt (Pointer / Container)
• Leserichtung angeben wenn nicht von links nach rechts / oben nach unten
• Implementierung geschieht später

Ende: Seite 176

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 7) erschien zuerst auf Maximilian Krieg.

• Substantivmethode zur Findung von Klassen, Attributen und Methoden
• Klassen sind die Bausteine des Systems
• Herausforderung: „Wie weiß man, wie man die Klassen „gut“ auftrennt?“
• Beispiel: „Geld abheben“
  • Kunde ( nicht Teil des Use-Case )
  • Karte ( Klasse )
  • System ( nicht Teil des Use-Case )
  • PIN ( Attribut )
  • Betrag ( mögl. Attribut )
  • Konto ( Klasse )
  • Geld ( nicht Teil des Use-Case )

Attribute und Methoden identifizieren

• Methode „geld_abheben ( betrag )“ definieren
• Einzahlen und Auszahlen sind Methoden mit unterschiedlichen Vorgängen und Berechtigungsstrukturen

Vererbung

• Subklassen verfügen über alle Eigenschaften der Superklassen
• Überschreiben von Merkmalen ist erlaubt
• Semantik von Operationen und Attributen dürfen nicht verändert werden
• Werte dürfen eingeschränkt, aber nicht erweitert werden ( Platz im Speicher? )
• Es muss eine „Ist ein“-Beziehung bestehen
  • Bsp.: „LKW ist keine Spezialisieurng von Rollstuhl„
• Beispiel: Membranpumpe-Attribute
  • Name
  • Hersteller
  • Gewicht
  • Preis
  • Ansaugdruck
  • Auslassdruck
  • Durchflussmenge
  • Membranmaterial

Notation

• Beliebige Instanz einer Klasse „:Klasse“

Kapselung / Sichtbarkeit

• + Public = Für Alle sichtbar
• – Private = Für Niemanden sichtbar
• # Protected = Nur für Unterklassen sichtbar
• ~ Package = Nur für Klassen im gleichen Paket sichtbar

Constraints

• Einschränkungen von Randbedingungen bei Vererbung
• Complete ( Vollständig )
• Incomplete ( nicht vollständig )
• overlapping ( Ein Objekt kann mehreres sein )
• disjoint ( Es darf nur eines sein ) 

Abstrakte Klassen

• Kursive Namen oder „abstract“ kennzeichnen

Der Beitrag Objektorientierte Analyse und Design (Vorlesung 6) erschien zuerst auf Maximilian Krieg.