Objektorientierte Analyse und Design (Vorlesung 13)

Start: Seite 308

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.

 

Maximilian
Maximilian

Herzlich willkommen! Ich bin Max, ein Informatiker mit über 15 Jahren Berufserfahrung. Hier teile ich meine Leidenschaften, Erlebnisse und Perspektiven. Ich lade dich ein, gemeinsam mit mir auf eine Entdeckungsreise zu gehen.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie, wie Ihre Kommentardaten verarbeitet werden.