Objektorientierte Analyse und Design (Vorlesung 7)

Beispiel „Hochschulverwaltung“

• 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