Menu Close

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.

 

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.

Index