Objektorientierte Analyse und Design

Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 4. Objektorientierte Analyse OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 51

4. Objektorientierte Analyse Zur Erinnerung: Abstraktionsebenen gedankliche Ebene Reale Welt Abstraktion logische Ebene (Modell) OOA-Ebene OOD-Ebene Implementierungskonzepte Codierung physische Ebene (Implementierungsebene) Programm Arzt.cpp Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell) OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 52

4. Objektorientierte Analyse Anforderungsanalyse Typische Situation: Der Kunde oder Auftraggeber kommt und erklärt was er haben will... d.h. er beschreibt mehr oder weniger präzise seine Anforderungen In seiner eigenen Sprache mit Hinweisen auf Vorgängersysteme mit Lösungsideen Anforderungen können sein funktionale Anforderungen: - Gesamtablauf (Workflow): Beschreibt auch interne Abläufe - Anwendungsfälle: Beschreiben das Verhalten eines "Systems" an der Systemgrenze nicht funktionale Anforderungen: - Qualitäten des zukünftigen Systems: z.b. Performance, Ausfallsicherheit, Benutzerfreundlichkeit, Robustheit,... - Fertigstellungstermin, HW, SW Wie schreibt man das auf??? OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 53

4. Objektorientierte Analyse Lernziele Sie sollen in diesem Kapitel verstehen, Wie die Ergebnisse der Anforderungsanalyse dokumentiert werden Was zur Dokumentation einer Anforderung gehört Welche Möglichkeiten Use Cases bieten Wie man Use Cases in Textform aufschreibt Wie man Use Cases in UML darstellt Wie man ein gesamtes System mit Use Cases beschreibt Welche alternativen Beschreibungsmöglichkeiten es gibt Hinterher wissen Sie wie man die Ergebnisse einer objektorientierten Analyse dokumentiert! OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 54

Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 4.1 Textuelle Beschreibung von Use Cases OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 55

Beispiel: Kundenanforderungen Geldautomat (ATM) Verbale Beschreibung eines (ungewöhnlich präzisen) Kunden: "Geld abheben" Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag eingegeben hat, wird der Betrag vom Konto abgebucht und die Karte und das Geld ausgegeben. Falls die PIN das 1. oder 2. Mal falsch eingegeben wurde, wird der Kunde benachrichtigt und die PIN wird erneut eingegeben. Falls die PIN ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht die Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist, wird dies dem Kunden mitgeteilt und die Karte wieder ausgegeben. Welche Teile müssen sequentiell ablaufen, was darf oder soll parallel laufen? Ist bei "oder" eventuell "entweder-oder" gemeint? Natürliche Sprachen sind oft nicht eindeutig genug für eine exakte Beschreibung! OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 56

Notation am Beispiel: Geldautomat Exakte Beschreibung: "Geld abheben" 1. Kunde schiebt Karte ein. 2. Das System stellt fest, dass die Karte gültig ist. 3. Kunde gibt PIN ein. 4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5. Kunde gibt gewünschten Betrag ein. 6. System bucht Betrag vom Konto ab. 7. System gibt Karte aus. 8. System gibt Geld aus. Ziel ("Goal") Ablauf ("Basic Course") "Aktionen" ("Action-Steps") Verwenden Sie einfache und klare Sätze! Aktive Formulierungen mit Subjekt, Prädikat, Objekt! OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 57

Ergebnis eines Anwendungsfalls (Use Case) Der Benutzer des Systems erwartet ein bestimmtes Ergebnis, wenn der Anwendungsfall erfolgreich verläuft Hier: Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht. Die Karte wurde vom Automat ausgegeben. Das System ist wieder bereit für den nächsten Kunden. "Success Guarantees" oder "Use Case-Business- Result" Alle Fehler und Transaktionsdaten wie z.b. Zeit und Datum der Transaktion wurden protokolliert. " Minimal Guarantees" Aber was passiert, wenn der Use Case nicht erfolgreich abläuft? OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 58

Alternativer Ablauf eines Use Cases Bedingung Alternative Course: 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Fehlversuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. Bezug zum Basic Course Alternative Course: 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. Das System protokolliert den Versuch. 4b2. Das System zieht endgültig die Karte ein. 4b3. Das System benachrichtigt den Kunden. 4b4. Use Case wird abgebrochen. "Alternative Course" "Aktionen" ("Action-Steps") OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 59

Alternative Course: Übung Es wird eine ungültige Karte in den Geldautomaten eingeschoben (z.b. die Mensakarte). Beschreiben Sie den alternativen Ablauf! Alternative Course: 2a. Das System erkennt, dass die Karte nicht gültig ist: 2a1. Das System protokolliert den Versuch. 2a2. Das System benachrichtigt den Kunden 2a3. Das System gibt die Karte aus. 2a4. Der Use Case wird abgebrochen. OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 60

Auslösung eines Use Cases Ein Use Case wird durch ein bestimmtes Ereignis gestartet ein Kunde ruft an um 19:00 Uhr startet die Datensicherung das System stellt einen Fehler fest Der "Trigger" ist die erste Aktion, die mit unserem System interagiert Der "Primary Actor" ist derjenige, der die erste Aktion des Use Case anstößt, um ein Ziel zu erreichen Das muss nicht derjenige sein, der selbst direkt mit dem System kommuniziert, sondern evtl. auch der Anrufer, der die Erfassung eines Auftrags durch einen Sachbearbeiter anstößt. Beispiel: Ein Kunde ruft an und will einen Auftrag vergeben. Die erste Aktion (mit unserem Auftragserfassungssystem) ist dann: Der Sachbearbeiter ruft das Auftragserfassungsprogramm auf "Trigger" "Primary Actor" "Actor" OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 61

Wer definiert Use Cases? Alle Personen, die ein berechtigtes Interesse an einem bestimmten Verhalten des Systems haben nicht nur die Akteure, sondern auch: Besitzer des zukünftigen Systems, der Abteilungsleiter, die interne Revisionsabteilung aber nicht der Einbrecher für eine Alarmanlage Die Akteure sind oft für die Definition der Use Cases gar nicht so wichtig Die Interessen der Stakeholder äußern sich in den Action-Steps z. B. Interesse des Kunden / der Bank: "keine unberechtigte Abhebung": - Einschieben EC-Karte, PIN-Überprüfung Interesse des Kunden: "Falls Karte / Geld nach Ausgabe nicht entnommen wird, soll dem Kunde kein Schaden entstehen": - Wieder-Einziehen der Karte / des Geldes und späteres Abholen der Karte am Schalter / Gutschrift des Gelds aufs Konto "Stakeholders" & "Interests" ist zwar Actor, aber kein Stakeholder! OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 62

Muster für Use Case-Spezifikation (I) Use Case Name Primary Actor Further Actors Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger <name = Use Case-Goal> <a role name for the primary actor or description> <Role Name for further actors or description> <list of stakeholders and their key interests in the use case> <the state of the world if goal succeeds> <how the interests are protected under all exits> <what starts the Use Case (may be a time event)> OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 63

Muster für Use Case-Spezifikation (II) Basic Course (Main Success Scenario) Alternative Course <put here the steps of the scenario from trigger to goal delivery and any cleanup after> <step#> <action description> <step#> <action description> <step# with reference to step in Basic Course (same step-number with following a. or b...., e.g. 2a.)> <Condition> <step# of the Alternative Course, e.g. 2a1.> <action description>... (Return point is specified in the action description in step(s) in the alternative Course) Es gibt diverse ähnliche Templates für die Beschreibung! Häufig mit weiteren Rubriken (z.b. Vor- & Nachbedingungen oder Ausnahmen) OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 64

Beispiel "Geld abheben": Use Case-Spezifikation (I) Use Case Name Primary Actor Further Actors Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger Geld abheben Kunde -- Bank: Schutz vor unberechtigtem Zugriff Kunde: Abbuchung nur nach Auszahlung Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht Die Karte wurde vom Automat ausgegeben. Das System ist bereit für den nächsten Kunden. Alle Fehler und Transaktionsdaten wurden protokolliert Kunde schiebt Karte ein OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 65

Beispiel "Geld abheben": Use Case-Spezifikation (II) Basic Course (Main Success Scenario) Alternative Course (2a) 1.Kunde schiebt Karte ein. 2.Das System stellt fest, dass die Karte gültig ist. 3.Kunde gibt PIN ein. 4.Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5.Kunde gibt gewünschten Betrag ein. 6.System bucht Betrag vom Konto ab. 7.System gibt Karte aus. 8.System gibt Geld aus. 2a. System erkennt, dass die Karte nicht gültig ist: 2a1. Das System protokolliert den Versuch. 2a2. Das System benachrichtigt den Kunden 2a3. Das System gibt die Karte aus. 2a4. Use Case wird abgebrochen. OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 66

Beispiel "Geld abheben": Use Case-Spezifikation (III) Alternative Course (4a) 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Versuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. Alternative Course (4b) 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. Das System protokolliert den Versuch. 4b2. System zieht die Karte endgültig ein. 4b3. Das System benachrichtigt den Kunden. 4b4. Use Case wird abgebrochen. OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 67

Gedanken zu Use Cases Ein Use Case beschreibt eine Menge von Aktionsfolgen, einschließlich Varianten, die ein System ausführt, um ein erkennbares, für einen Aktor nützliches Ergebnis zu erarbeiten. Ein Use Case stellt eine funktionale Anforderung an das System als Ganzes dar Ein Use Case beschreibt nicht, wie das Verhalten implementiert wird Use Cases sind geeignet um das Verhalten eines Systems zu visualisieren, zu spezifizieren, und zu dokumentieren Use Cases bieten eine Basis für die Verständigung von Entwicklern, Endanwendern und Fachleuten für den Anwendungsbereich; für die Requirements, für die Überprüfung der Architektur, und für den Test Die Sammlung der Use Cases ergibt noch keine vollständige Sammlung der Requirements! OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 68

Tipps für die Beschreibung des Ablaufs Benutze eine einfache Grammatik Zeige immer klar: Wer hat den Ball : System gibt Meldung... aus Kunde wählt am System... aus System führt... aus, bis... eintritt Schreibe aus der User- (bzw. Vogel)perspektive (keine System-Interna!) Vermeide Passiv und Konjunktiv ("Es sollte angezeigt werden") Zeige wie sich der Prozess fortbewegt Zeige was der Aktor will, nicht seine Bewegungen Benutze eine sinnvolle Menge von Aktionen Wähle exakte Begriffe und Wörter verwende z.b. validiere, und nicht überprüfe"! Das System validiert das Passwort und überprüft es nicht wenn sinnvoll, erwähne die Zeit OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 69