Objektorientierte Analyse (OOA) Übersicht

Transkript

1 Übersicht UML ist die Notation für ein objektorientiertes Vorgehensmodell, sowohl für die Analyse als auch für das Design. Analyse (WAS?) Use Cases Aktivitätsdiagramme (für die Use Cases) Klassendiagramme Sequenz- und Zustandsdiagramme (für die Klassen/Objekte) Design (WIE?) Präzision der Klassen-, Sequenz- und Zustandsdiagramme weitere Diagramme wie z.b. Pakete Komponentendiagramme... Datei: OOAUseCaseVorlesung.ppt Seite 1

2 UML als Notation Use Cases Akteure, Szenarien Aktivitätsdiagramme Ablaufmöglichkeiten Klassendiagramme Klassen, Beziehungen Sequenzdiagramme Objekte, Interaktionen (Kollaborationsdiagramme) Zustandsdiagramme Internes Verhalten von Objekten Prozess-Modell (Anwendungsfälle) Statische Sicht: log. Aufbau des Systems Dynamische Sicht: Interaktionen, Abläufe Seite 2

3 Diagrammarten der UML Diagramm Strukturdiagramm Verhaltensdiagramm Klassendiagramm Komponentendiagramm Objektdiagramm Aktivitätsdiagramm Anwendungsfalldiagramm Zustandsdiagramm Paketdiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Interaktionsdiagramm Interaktionsübersicht Sequenzdiagramm werden in der Vorlesung behandelt Kommunikationsdiagramm Zeitdiagramm Seite 3

4 Use Cases (Anwendungsfälle) Use Case Diagramm zeigen die benötigten Interaktionen zwischen dem System und den Akteuren, die mit dem System kommunizieren sind die Grundlage für die Erstellung des Systems (müssen daher vollständig sein!) sind die Grundlage für das Testen des Systems nach der Erstellung Zu jedem Anwendungsfall gibt es eine Beschreibung in Textform Anwendungsfälle können hierarchisch geschachtelt werden. Notation: Anwendungsfälle werden durch Ellipsen, die den Namen des Anwendungsfalles - möglichst als Verb - tragen, und einer Menge von beteiligten Objekten (Akteure, häufig als Strichmännchen gezeichnet), die den Namen ihrer Rolle tragen. dargestellt. Zwischen den Anwendungsfällen existieren Kommunikations- Beziehungen, die durch Linien dargestellt werden, spezielle Beziehungen sind: <<extend>>-beziehung, <<include>>-beziehung (ersetzt die <<uses>>-beziehung aus der UML1.1) Generalisierungsbeziehung (seit UML 1.3). Seite 4

5 Use Case Diagramm Beispiel mit dem Case-Tool Innovator: Paket Verwaltung dient zur Gruppierung (Systemgrenze) Kommunikationsbeziehungen (einfache Striche) werden nicht benannt <<extend>>beziehung sagt, daß der Use Case Anmelden durch den Use Case Kontozugang sperren (unter bestimmten Umständen, siehe [ ] im Diagramm) erweitert wird (extension point) <<include>>beziehung sagt, daß der Use Case Abmelden den Use Case BLZ überprüfen enthält Der use case BLZ überprüfen gehört originär zum Paket Auskunft Seite 5

6 Use Case Diagramm Beispiel für eine Generalisierung (Innovator): Es existieren drei (konkrete) Anwendungsfälle, die eine Spezialisierung des abstrakten Anwendungsfalles Kfz reservieren darstellen. Ebenfalls ist die Generalisierung zwischen den Akteuren eingezeichnet. Für den Prozeß der Reservierung bedeutet das, daß entweder der Reservierungswunsch direkt vom Kunden im Anwendungsfall Kfz online reservieren bearbeitet wird oder daß der Reservierungswunsch vom Call- Center-Agenten (im Falle Kfz telefonisch reservieren) oder vom Niederlassungsmitarbeiter (im Falle Kfz persönlich reservieren) weitergeleitet wird (leider ist diese Datenschnittstelle Reservierungswunsch im Diagramm nicht sichtbar). Christoph Riewerts Seite 6

7 Übung (Flugbuchung): Use Case Diagramm Der Anwendungsfall Buchen eines Fluges verwendet die zwei Use Cases Beratung und Rechnung ausdrucken. Eine Beratung wird jedoch nur in Ausnahmefällen durchgeführt, während der Anwendungsfall Rechnung ausdrucken von allgemeiner Natur sein soll und somit auch von weiteren Use Cases benutzt werden kann. Entwerfen Sie ein Anwendungsfall-Diagramm. Seite 7

8 Übung (Bibliothekssystem): Use Case Diagramm Für ein Bibliothekssystem sind folgende Anwendungsfälle zu spezifizieren: Buch ausleihen, Buch vormerken, Buch zurückgeben, Buch inventarisieren, Buch suchen. Sollte ein Kunde zur Benutzung der Bibliothek noch nicht berechtigt sein, müssen seine Kundendaten aufgenommen werden. Definieren Sie die notwendigen Akteure und stellen Sie ein Use Case Diagramm auf. Seite 8

9 Use Case Beschreibung Wann ist ein Use Case ausreichend beschrieben? Antwort: Wenn zu jedem Use Case (Funktion) folgende Angaben gemacht werden: Auslöser einer Funktion Input zu einer Funktion Output einer Funktion (bei komplexen Inhalten) einzelne Funktionsschritte Durchführender Erweiterung: Statt einzelne Funktionsschritte in Textform anzugeben, kann man auch ein Aktivitätsdiagramm zeichnen. Use case Titel: Nummer: Kurzbeschreibung (Ziel): Akteure: Auslösendes Ereignis: Vorbedingung: Nachbedingung (bei Erfolg / bei Fehlerfall): Standardablauf (Abfolge der Aktionen): Seite 9

10 Beispiel für einen Use Case Use Case Beschreibung Use Case Titel: Auftrag ausführen Nummer: FREQ 21 Kurzbeschreibung (Ziel): Ware an Kunde geliefert Akteure: Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung Auslösendes Ereignis: Bestellung des Kunden liegt vor Vorbedingung: Bestellung Nachbedingung (bei Erfolg): Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei Buchhaltung Nachbedingung (bei Fehlerfall): Mitteilung an Kunden, dass nicht lieferbar Standardablauf: 1. Kundendaten abrufen 2. Lieferbarkeit prüfen 3. Rechnung erstellen 4. Auftrag vom Lager ausführen lassen 5. Rechnungskopie an Buchhaltung geben Erweiterungen: 1a. Kundendaten aktualisieren Alternativen: 1a. Neukunden erfassen 3a. Rechnung mit Nachnahme erstellen 3b. Rechnung mit Bankeinzug erstellen Seite 10

11 Aktivitätsdiagramm der UML Aktivitätsdiagramm ist eine Sonderform des Zustandsdiagramms. Während jedoch im Zustandsdiagramm die verschiedenen möglichen Zustände einer Klasse untersucht werden, werden im Aktivitätsdiagramm die Reihenfolge bzw. der Ablauf von Aktivitäten modelliert. In einem Aktivitätsdiagramm werden die Objekte eines Programms mittels der Aktivitäten, die sie während des Programmablaufs vollführen, beschrieben. Eine Aktivität ist ein einzelner Schritt innerhalb eines Programmablaufs, d.h. ein spezieller Zustand eines Modellelements, das eine interne Aktion sowie eine oder mehrere von ihm ausgehende Transitionen enthält. Aktivitätsdiagramme sind für Anwendungsfälle obligatorisch, wenn die Use Cases nur grob spezifiziert sind. Notation: Eine Aktivität wird durch ein Rechteck mit konvex abgerundeten Seiten visualisiert. Sie enthält eine Beschreibung der internen Aktion. Eine Transition wird durch einen Pfeil repräsentiert. Gehen mehrere Transitionen von der Aktivität aus, so müssen diese mittels Bedingungen voneinander zu unterscheiden sein. Seite 11

12 Aktivitätsdiagramm Beispiel eines Aktivitätsdiagramm im Innovator: Dargestellt sind vier Kommentare, zwei Aktivitäten, sechs Transitionen (zwei davon mit Bedingungen), kein Objekt, keine Zuständigkeit/Rolle, eine Synchronisation, eine Alternative und zwei Zustände (Anfang und Ende). Seite 12

13 Aktivitätsdiagramm Weitere Elemente eines Aktivitätsdiagramms: Rollen/Zuständigkeiten: Aufteilung des Hintergrundfeldes für z.b. Objekte, Akteure oder Organisationseinheiten (swimlane) Input/Output von Aktivitäten: Angabe eines Objekts, ggfs. mit Angabe des aktuellen Objektzustands (wichtig beim Übergang in eine andere swimlane) Transition/Kontrollfluß: Pfeile für die Reihenfolge der Aktivitäten, ggfs. mit Bedingungen oder auch Aktionen annotiert Anfangspunkt/Endpunkt Seite 13

14 Aktivitätsdiagramm Alternative Abläufe: durch wechselseitig ausschließende Bedingungen auf mehreren ausgehenden Transitionen einer Aktivität oder durch explizite Entscheidungszustände (Verzweigungssymbol wie bei einer If-Then- Else-Anweisung, hollow diamond) Parallele Abläufe: Bar Gabelung/Splitting (fork) für den Beginn einer Nebenläufigkeit und Zusammenführung/Synchronisieren (join) für das Ende Seite 14

15 Aktivitätsdiagramm Beispiel aus der Literatur (.): Geldabheben über einen Bankomat. swimlanes Kunde, Automat und Bank, zur Spezifikation der verantwortlichkeit en. debit account = Konto belasten Seite 15

16 Übung (Online-Banking): Aktivitätsdiagramm Folgender Ablauf ist in einem Aktivitätsdiagramm mit dem Titel Dauerauftrag einrichten darzustellen: Nachdem der Benutzer die Empfängerdaten: Name, Kontonummer und BLZ eingegeben hat, wird vom System geprüft, ob die BLZ korrekt ist; ist die BLZ falsch, muß sie nochmals eingegeben werden, ist sie richtig, gibt der Benutzer den Betrag ein und das Ausführungsintervall. Danach übernimmt das System diesen neuen Dauerauftrag und vervollständigt ihn, indem die Daten des Benutzers (Kontonummer und BLZ) dazugefügt werden. Der Benutzer muß dann noch die TAN eingeben, damit der Dauerauftrag, nachdem er vom System abgespeichert wird, in den Zustand aktiv überführt werden kann. Unterlegen Sie die Aktivitäten mit den zwei Rollen Benutzer und System und tragen Sie zusätzlich in das Aktivitätsdiagramm (als Objektfluss) das Objekt Dauerauftrag (incl. [Zustand]) als Schnittstelle zwischen Benutzer und System ein. Seite 16