DHBW Stuttgart Informatik SWEngineering Kapitel 2 5 1

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Inhaltsübersicht • • • Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Verhaltensmodellierung Seite 5

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Verhaltensmodellierung Seite 6

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Verhaltensmodellierung Seite 7

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Bedeutung der Use Cases Anwendung im Projekt • • 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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 UML 1. 1) – Generalisierungsbeziehung (seit UML 1. 3). Seite 9

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Use Case Diagramm Beispiel für eine Generalisierung (Innovator): Es existieren drei (konkrete) Anwendungsfälle, die eine Spezialisierung des abstrakten Anwendungsfalles Kfz reservieren darstellen. Christoph Riewerts Ebenfalls ist die Generalisierung zwischen den Akteuren eingezeichnet. Für den Prozeß der Reservierung bedeutet das, daß entweder 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). Seite 11

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Use Case Diagramm Übung (Flugbuchung): 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Use Case Diagramm Übung (Bibliothekssystem): 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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 Use case Titel: __________ Nummer: ……… Kurzbeschreibung (Ziel): ……… Akteure: ……… Auslösendes Ereignis: ……… Vorbedingung: ……… Nachbedingung (bei Erfolg / bei Fehlerfall): 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. Standardablauf (Abfolge der Aktionen): 1. 2. 3. ……. . Seite 14

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Use Case Beschreibung Beispiel für einen 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: 1 a. Kundendaten aktualisieren Alternativen: 1 a. Neukunden erfassen 3 a. Rechnung mit Nachnahme erstellen 3 b. Rechnung mit Bankeinzug erstellen Seite 15

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Use Case Beschreibungen Beispiele für verbesserungsfähige Use Cases: Seite 16

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) 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

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Anhang: Lösungen der Übungen Übung Flugbuchung Seite 12: Seite 18

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2. 5. 1 Okt 2010 Objektorientierte Analyse (OOA) Anhang: Lösungen der Übungen Übung (Bibliothekssystem) Seite 13 Seite 19