Menu Close

Objektorientierte Analyse und Design (Vorlesung 5)

Aktivitätsdiagramme

  • Anwendung
    • Aktivitätsdiagramme können in einem Projekt überall verwendet werden, wo Verhalten beschrieben werden muss, bzw. wo Datenflüsse oder Kontrollflüsse modelliert werden sollen
  • Symbole
    • Startzustand/Startknoten = Schwarzer Punkt
    • Ende = Schwarzer Punkt mit Kreis
      • Mehrere Enden für eine Aktivität sind möglich
    • Aktion = Ovales Objekt
    • Kontrollfluss / Kante = Linie
    • Entscheidungsknoten = Rechteck
      • Auftrennung nach einer Entscheidung (Log. XOR)
      • Erzeugt eine Parallelität
    • Synchronisation = Flacher Strich = Verbindungspunkt
      • Erst weiter machen wenn beide Sachen erfüllt sind (Log. Und)
      • Reihenfolge ist dabei egal
    • Tabellenartig = „swim(ming) Lanes“ für jeden Akteur

Tokenprinzip

  • Ablauf des Diagrammes verfolgen und auf gleicher Ebene ( gleiche Anzahl der Schritte ) werden „Tokens“ mit gleicher Wertigkeit hinterlegt.
  • An einem Synchronisationsknoten müssen alle „Eingänge“ mit einem Token belegt werden, bevor man weiter gehen kann.

Aktivitätsdiagramme als Alternative für Use-Case-Diagramme

  • Zeigen die Abhängigkeiten von Tätigkeiten zu ihren Akteuren
  • Erweitern den Funktionsumfang der Aktivitätsdiagramme

Unterscheidung

  • Use Case
    • Dynamik
    • Wann passiert was, in welcher Reihenfolge?
  • Analyse
    • Statik
    • Welche Komponenten sind miteinander verbunden?

Analysemodelle

  • Darstellung der Komponenten, die in Use-Case und Aktivitätsdiagramme auftreten (Pin, Karte, etc.)
  • Komponenten entsprechen wieder den Objekten (Klassen)
  • Objekte bzw. deren Klassen bestehen aus:
    • Attribute
    • Methoden
    • Beziehungen
  • Domänenklassen
    • jede Domainklasse muss in mindestens einem Anwendungsfall vorkommen
    • jede Domainklasse sollte mindestens ein Attribut haben
    • Domainklassen enthalten keine Realisierungsdetails einer potentiellen Lösung

Kontrollfragen

  • Welche Zielsetzung hat die Anforderungsanalyse?
    • Herausfinden was der Kunde eigentlich will? Einigen auf Begriffe, die gleich verstanden werden. Was ist für den Kunden relevant und was nicht? Was muss das Programm erfüllen und was nicht? Bilden einer Vertragsgrundlage.
  • Ist ein Dieb ein Stakeholder für einen Geldautomaten? Ein Aktor?
    • Weder noch, außer es gibt einen Use-Case der Diebe enthält
  • Was ist der Unterschied zwischen Include und Extend?
    • Extend erweitert, include zieht rein
  • Wie stellt man Use Cases in UML dar?
    • Sammlung von Use-Cases und Akteuren in Form von Diagrammen

Klassendiagramm

  • + public
  • – private
  • # protected
  • Attribute sind oben
  • Methoden sind unten
  • Set/Get-Methoden werden nicht mehr explizit genannt.

Identifizierung für Klassendiagramme

  1. Substantive aus einem Text heraus arbeiten (mögl. Kandidaten)
  2. Substantive nach Klassen und Attribute sortieren
  3. Attribute den Klassen zuordnen
  4. Nicht benötigte Substantive bzw. Klassen / Attribute aussortieren
  5. Doppler aussortieren
  6. Vereinen/Konsolidieren gleicher/ähnlicher Rollen/Personen/Objekte
  7. Ergänzung fehlender Klassen und Attribute

Beispiel

  • Kandidaten:
    • Kunde
    • Karte
    • System
    • PIN
    • Konto
    • Betrag
    • Geld
    • Versuch
  • Klassen:
    • Karte
    • Konto
  • Attribut:
    • Pin
  • Akteur (unwichtig):
    • Kunde
    • System

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