Objektorientierte Analyse (OOA) Inhaltsübersicht

Transkript

1 Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1

2 Einführung In der Systemanalyse wird aus den fachspezifischen Anforderungen das Systemmodell erstellt; im Systemmodell ist spezifiziert, was das System leisten soll, d.h. statische Struktur und dynamisches Verhalten sind vollständig beschrieben. In der Systementwicklung wird aus dem Systemmodell und den ITspezifischen Anforderungen das Software-System erstellt; das Software-System beschreibt, wie die Anforderungen umgesetzt wurden Seite 2

3 Einführung UML ist die Notation für die OOA. Mit den UML-Diagrammen gliedert sich das Systemmodell in zwei Aspekte: (dynamische) Verhaltensmodellierung und (statische) Strukturmodellierung, für deren Beschreibung vier UML-Diagramme zuständig sind. Methodische Gliederung Komponenten Diagramm (UML 2) Verhaltensmodellierung (dynamisch) Ereignisse Kontrollfluss (Ablauf) Zustandsübergänge Use-Case-Diagramm Aktivitätsdiagramm Zustandsautomat Strukturmodellierung (statisch) Daten ( Strukturen) Schnittstellen (Kontext) Funktionen Datenfluss Klassendiagramm Aktivitätsdiagramm (nur Parameter/Objektfluß) Seite 3

4 Anforderungen an die UML-Diagramme Vollständigkeit der OOA Kontext, d.h. externe Schnittstellen Funktionshierarchie Konsistenz zwischen den Diagrammen Aktoren und Swimlanes Parameter und Klassen Ereignisse und Klassen Use Cases und Aktionen bzw Aktivitäten Verständlichkeit für die unterschiedlichen Nutzer Komplexität einer Aktivität Beschreibungsmöglichkeiten in einem Diagramm Seite 4

5 Verhaltensmodellierung Seite 5

6 Verhaltensmodellierung Seite 6

7 Verhaltensmodellierung Seite 7

8 Anwendung im Projekt Bedeutung der Use Cases Use Case Diagramm liefert die funktionelle Gliederung in form von Anwendungsfällen in der 1. Gliederungsebene; weitere Gliederungsebenen werden durch Aktivitätsdiagramme visualisiert Use Cases liefern den Kontext, d.h. sie beschreiben alle Systemgrenzen (externe Schnittstellen) Use Cases stellen keine objektorientierte Sicht auf das System dar, sondern beschreiben die funktionellen Anforderungen aus Anwendersicht (was statt wie) (und Entwicklersicht) Verständlichkeit wird erreicht durch: Sparsame Verwendung der include- und extend-beziehungen Vorgabe eines Templates zur textuellen Beschreibung der Use Cases Zu beachten Akteure (actors) werden nur dann eingeführt, wenn sie direkt mit dem System (inter-)agieren, d.h. aktiv beteiligt sind; es gibt somit nicht nur menschliche Akteure! Schnittstellen nach außen werden in den Aktivitätsdiagrammen als Ein- und Ausgabeparameter spezifiziert Für eine detaillierte(re) Spezifikation der Daten steht das Klassendiagramm zur Verfügung Bei einem gleichwertigen Auftreten von Abfolgen und Ereignissen im Use Case empfiehlt es sich, einen Zustandsautomaten zur Beschreibung hinzuzufügen Seite 8

9 Use Case Diagramm Das Use Case Diagramm hält fest, was Akteure/Aktoren, die sich außerhalb des Systems befinden) vom System erwarten. Es bildet des externe Verhalten des System ab. Es enthält die grafische Darstellung der Use Cases (Anwendungsfälle). Use Cases helfen, das System in logische Teile (planbare Einheiten) zu gliedern und liefern die Schnittstellen, so dass sie auch als Grundlage für das Testen des Systems nach der Erstellung bieten 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 9

10 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 10

11 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 11

12 Ü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 12

13 Ü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 13

14 Use Case Beschreibung (Template) Wann ist eine Funktion ausreichend beschrieben? Antwort: Wenn zu jeder Funktion folgende Angaben gemacht werden: Auslöser einer Funktion Input zu einer Funktion Output einer Funktion (bei komplexen Inhalten) einzelne Funktionsschritte Durchführender Der Standardablauf wird in der Regel als Aktivitätsdiagramm gezeichnet, da wir bei umfangreichen Use Cases die Ein- und Ausgabeparameter der Aktionen explizit benötigen. Use case Titel: Nummer: Kurzbeschreibung (Ziel): Akteure: Auslösendes Ereignis: Vorbedingung: Nachbedingung (bei Erfolg / bei Fehlerfall): Standardablauf (Abfolge der Aktionen): Seite 14

15 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 15

16 Use Case Beschreibungen Beispiele für verbesserungsfähige Use Cases: Seite 16

17 Use Case Beschreibungen Hier sind die verbesserten Use Cases: - Keine Lösungen (Oberflächen) beschreiben - Hauptablauf (mit Alternativen) kennzeichnen - Detaillierung der Daten (Attribute) ins Klassendiagramm übernehmen Seite 17

18 Übung Flugbuchung Seite 12: Anhang: Lösungen der Übungen Seite 18

19 Übung (Bibliothekssystem) Seite 13 Anhang: Lösungen der Übungen Seite 19