Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester Teil 2-

Transkript

1 Systemanalyse - Folien zur Vorlesung für AI3 im Sommersemester Teil 2- Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken

2 Einführung Fallbeispiel / Aktivitätsdiagramme Anwendungsbeispiel Pizza-Service Aktivitätsdiagramm für Pizzabestellung Aktivitätsdiagramme: Elemente und Beispiele Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

3 Anwendungsbeispiel: Pizza Service Der Inhaber eines Pizza-Service beauftragt Sie mit der Entwicklung eines Systems zur Unterstützung der Bestellaufnahme und Auslieferung Mit Hilfe dieses Systems soll es auch möglich sein, Pizza über das Internet zu bestellen. Erwartungen an das System Schnellere Bestellaufnahme Kunden-, Adress- und Speisedaten im System Bessere Planung der Lieferzeiten Kochdauer, Fahrtdauern Bessere Statusinformationen Wo befindet sich meine Bestellung jetzt? Wie lange dauert es noch? Das System soll die Daten für die Buchhaltung und die Lohnabrechnung liefern Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

4 Pizza Service (2) Musskriterien: Aufnahme von Bestellungen Durch Verkäufer Durch den Kunden selbst über das Internet Ermittlung der Auslieferungszeit Erfassen und Information über Bestellstatus Abrechnung von Bestellungen Arbeitszeiterfassung der Fahrer Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

5 Ermittlung der Anforderungen Interview mit Auftraggeber Interviews mit Fachleuten / zukünftigen Benutzern Ist-Analyse: Wie werden die Aufgaben heute durchgeführt (ohne System / mit einem Alt-System)? Dokumentenanalyse Analyse von benutzten Formularen und Belegen (Auftrag, Rechnung,...) Nutzung von Beispielen Analyse vergleichbarer Lösungen und Systeme Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

6 Pizza Service (3) Wunschkriterien: Statistische Auswertungen Personalplanung Abgrenzungskriterien: Buchhaltung zunächst nicht integriert Personalabrechnung zunächst nicht integriert. Weitere betriebliche Funktionen, wie Einkauf, Fahrzeugverwaltung u. ä. werden nicht betrachtet. Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

7 Aktivitätsbereiche Aktivitätsbereiche (Partitionen) Auch quer (oder Matrix, s.u.) Weiter unterteilbar Können darstellen: Mitarbeiter, Organisationseinheiten, Benutzer, Systeme, Prozesse,... Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

8 Aktivitätsdiagramm Bestellabwickl. mit Objektfluss Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

9 Aktivitätsdiagramme (Activity Diagrams) Darstellung von zeitlich-logischen Abläufen in Form von aufeinanderfolgenden Aktionen incl. Verzweigungen und parallelen Vorgängen Mögliche Einsatzgebiete: Darstellung übergreifender Abläufe über das Gesamtsystem. Hierin können auch manuelle Aktivitäten enthalten sein. Ziel ist es, die zu unterstützenden Abläufe (Geschäftsprozesse) im Überblick zu verstehen. Genauere Spezifizierung des Ablaufs einzelner von einem Benutzer mit einem System durchgeführten Aufgaben ( Use Cases nächste Vorlesung) Detail-Abläufe innerhalb des Systems Aktivitätsdiagramme werden nur dort eingesetzt, wo sie zum Verständnis des Systems beitragen Keine vollständige Modellierung des gesamten Systems Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

10 Aktivitätsdiagramme Es gab eine Reihe von Änderungen gegenüber UML 1.4 Man kann sich die Ablauflogik so vorstellen: Die Aktionen geben Marken ( Tokens ) weiter. Eine Aktion wird ausgeführt, wenn über alle eingehenden Kanten Marken zur Verfügung stehen. Die Aktion verarbeitet die Marken und stellt wiederum Marken an ihren ausgehenden Kanten zur Verfügung. Objektknoten speichern Marken, wobei die Marken einen bestimmten Typ haben müssen. Es werden hier nur die wichtigsten Konstrukte der Aktivitätsdiagramme besprochen Komplette Beschreibung siehe UML 2(!)-Literatur Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

11 Parallele Abläufe Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

12 Bedingte Parallelisierung Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

13 Geschachtelte Aktion Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

14 Schleifenknoten - allgemein Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

15 Übergabeparameter (als Objektflüsse) Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

16 Übergabeparameter (als Objektflüsse) Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

17 Entscheidungsknoten Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

18 Entscheidungsknoten - Beispiel Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

19 Use Case-Diagramme Elemente von Use Case-Diagrammen Beschreibungen von Use Cases Erweiterungen Finden von Use Cases Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

20 UML Use Case-Diagramme Nächster Schritt bei der Anforderungsanalyse: Use Case-Diagramme und -Beschreibungen Use Cases (Anwendungsfälle) beschreiben Systemfunktionalität aus Anwendersicht Beantworten die Frage Wer macht was mit dem System? Zusammenhang mit dem Aktivitätsdiagramm: Aktionen von übergreifenden Aktivitätsdiagrammen können Use Cases entsprechen Es können aber auch mehrere Aktionen zu Use Cases zusammengefasst werden, oder umgekehrt eine Aktion in mehrere Use Cases aufgeteilt werden Nur die mit dem System durchgeführten Aktionen werden als Use Cases dargestellt Kriterium für die Bildung von Use Cases: Durchführung einer abgeschlossenen Aufgabe am System durch einen Benutzer Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

21 Elemente von Use Case-Diagrammen Actor (Akteur) Ist eine Rolle, die ein Benutzer des Systems spielt. Ist häufig eine Person, kann aber auch eine Organisationseinheit oder ein externes System sein. Externes System: Darstellung als Computer Use Case (Anwendungsfall) Beschreibt die Durchführung einer konkreten Aufgabe mit dem System aus Anwendersicht. Kann aus mehreren Einzelaktivitäten bestehen, die von einem Akteur durchgeführt werden, um ein bestimmtes Ergebnis zu erreichen. System Systemgrenzen können eingezeichnet werden Assoziation zwischen Akteur und Use Case Der Akteur kommuniziert mit dem Use Case (z. B. er führt ihn durch, muss Eingaben machen o. ä.) Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

22 Beschreibung von Use Cases Die Use Case-Diagramme alleine reichen nicht aus, um die Systemfunktionalität aus Anwendersicht ausreichend zu beschreiben Daher ist zu jedem Use Case eine textuelle Beschreibung erforderlich Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

23 Muster für die Beschreibung von Use Cases Name des Use Case (z. B. Substantiv + Verb) Vorbedingung Nachbedingung im Erfolgsfall Nachbedingung im Falle eines Fehlschlags Akteure Auslösendes Ereignis Beschreibung 1 Aktion 1 2 Aktion 2,... Erweiterungen / Alternativen a Alternative (zu Aktion x) b Alternative (zu Aktion y) c... Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

24 Bemerkungen zu Beschreibungen der Use Cases (1) Das Verhalten ist immer aus der Sicht des Benutzers zu Beschreiben Wie erlebt der Benutzer das System: Was gibt er ein? Was gibt das System aus? Was der Benutzer nicht sieht, gehört nicht in die Use Case- Beschreibungen Falsch: Nach Abschluss der Eingabe aktualisiert das System den Kundendatensatz in der Datenbank. Besser: Der Benutzer wählt speichern, damit werden die Eingaben dauerhaft gespeichert. Ggf. Skizzen der Benutzungsoberfläche Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

25 Bemerkungen zu Beschreibungen der Use Cases (2) Es wird das Zusammenspiel mit dem System beschrieben, keine Aktionen außerhalb des Systems Wir betrachten hier nur System-Use Cases, keine sog. Business Use Cases, die z. T. im Vorfeld der eigtl. Systemanalyse betrachtet werden Beispiel: Falsch: Der Sachbearbeiter vergleicht jeden Eintrag in dem Reisekostenabrechnungsformular mit dem zugehörigen Beleg und hakt ihn ab. Dann trägt er den Betrag ins System ein. Besser: Der Sachbearbeiter trägt in die tabellarische Eingabemaske für jede Position einen Text und den Betrag ein. Das System zeigt jeweils den aktualisierten Gesamtbetrag an. Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

26 Bemerkungen zu Beschreibungen der Use Cases (3) Das Systemverhalten soll möglichst vollständig beschrieben werden Was nicht beschrieben ist, wird nicht umgesetzt! Alle bei ordnungsgemäßem Betrieb des Systems möglichen Ausnahmen sind aufzuführen Zuerst das normale Verhalten bei erfolgreichem Ablauf Anschließend Verhalten bei Ausnahmen: Z. B. Nichterreichbarkeit eines anderen Systems, Drucker ist nicht an, kein Speicherplatz mehr, Datei nicht vorhanden, Abbruch durch den Benutzer, unvollständige oder unzulässige Eingaben,... Ggf. Nutzung von Aktivitätsdiagrammen zur Darstellung von komplexen Abläufen innerhalb eines Use Cases Use Cases dienen als Grundlage für die Entwicklung von Testfällen Beim Testen werden die Use Cases durchgespielt und es wird überprüft, ob sich das System so verhält wie beschrieben Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

27 Bemerkungen zu Beschreibungen der Use Cases (4) Vorbedingungen Sind Bedingungen, die erfüllt sein müssen, damit der Use Case überhaupt starten kann Beispiel: Für einen Use Case Buch suchen ist Gewünschtes Buch im System vorhanden keine Vorbedingung. Ist das Buch nämlich nicht vorhanden, wird der Use Case trotzdem durchgeführt, nur eben mit dem Ergebnis Buch nicht gefunden. Beispiel: Für den Use Case Rechtschreibprüfung durchführen in Word ist es eine Vorbedingung, dass ein Dokument geöffnet ist. Sonst kann der Use Case überhaupt nicht gestartet werden (im Menü ausgegraut). Keine trivialen Vorbedingungen Falsch: System läuft. Keine Vorbedingungen außerhalb des Systems Falsch: Benutzer hat ausreichend Geld auf dem Konto (um eine Bestellung durchzuführen) oder Benutzer hat Kreditkarte vorliegen (um die Daten bei der Durchführung einer Bestellung einzugeben). Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

28 Bemerkungen zu Beschreibungen der Use Cases (5) Nachbedingungen Im Erfolgsfall: Gewünschtes Ergebnis Im Misserfolgsfall Dass das gewünschte Ergebnis nicht eingetreten ist, ist weniger interessant Wichtiger: Bereits stattgefundene Änderungen sind rückgängig gemacht (wie z. B. Geldeinwurf im Automaten) Es wird ein sinnvoller, für den Benutzer nachvollziehbarer Zustand hergestellt Beispiel: Die bereits erfolgten Eingaben sind zwischengespeichert und können später vervollständigt werden. Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

29 Bemerkungen zu Beschreibungen der Use Cases (6) Akteure Im Ggs. zum UC Diagramm kann in der Beschreibung bei mehreren Akteuren dargestellt werden, ob sie gemeinsam am UC beteiligt sind, oder alternativ der eine oder andere den UC durchführt Auslösendes Ereignis Ereignis, das die Durchführung des UC am System startet Beispiele: Benutzeraktion: Benutzer wählt neues Spiel oder Benutzer wirft Geld ein Eintreten eines bestimmten Zeitpunktes bzw. Ablaufen einer bestimmten Frist Eintreten eines bestimmten Zustandes (z. B. Überschreiten einer bestimmten Temparatur). Keine Ereignisse, die nicht auf das System einwirken Falsch: Benutzer hat Hunger (beim Pizza Service-System) Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

30 Beispiel: Fahrplanauskunft einholen Name des Use Case: Fahrplanauskunft einholen Vorbedingung: Keine Nachbedingung (Erfolg): Fahrplanauskunft erhalten Nachbedingung Fahrplanauskunft nicht erhalten, (Fehlschlag): abgebrochen Akteure: Fahrgast Auslösendes Ereignis: Fahrgast will Fahrplanauskunft Beschreibung: 1. Fahrgast wählt Fahrziel 2. System ermittelt mögliche Verbindungen Erweiterungen / Alternativen a) (zu 1-2): Fahrgast bricht Aktion ab, System geht nach Wartezeit in Ausgangszustand zurück b) (zu 2): Fahrgast lässt persönlichen Fahrplan ausdrucken Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

31 Vergleich der Use Cases Beide Use Cases haben eine gemeinsam Aktivität: Verbindungen ermitteln Hierfür können eigene Use Cases gebildet und über die include- Beziehung eingebunden werden Kriterien für Bildung eigener Use Cases: Umfassen selbst einen abgeschlossenen Ablauf Werden mehrfach benötigt (oder sie könnten in Zukunft mehrfach verwendet werden) Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

32 Include-Beziehung im Beispiel Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

33 Include-Beziehung in den UC-Beschreibungen Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

34 Erweiterungen von Use Cases Sonderfälle können mit Hilfe von eigenen Use Cases dargestellt werden, die über extend-beziehungen eingebunden werden Im Beispiel: Ausdruck von Verbindungen Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

35 Extend-Beziehung im Beispiel Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

36 Extend-Beziehung in den UC-Beschreibungen Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

37 Generalisierung von Use Cases Use Cases, die viele Gemeinsamkeiten haben, können verallgemeinert werden Beispielsweise könnte für die Use Cases Einzelkarte kaufen und Monatskarte kaufen ein allgemeiner Use Case Fahrkarte kaufen definiert werden. In den speziellen Use Cases braucht dann nur noch beschrieben werden, wie sich diese vom allgemeinen Fall unterscheiden Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

38 Generalisierung im Beispiel Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

39 Generalisierung in den UC-Beschreibungen Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

40 Wie findet man Use Cases? (1) 1. Akteure ermitteln Wer führt die Aufgaben heute / künftig durch? Welche Rollen gibt es? Was gehört zum System / nicht zum System? 2. Use Cases für den Standardfall ermitteln a) Mittels Akteuren: Welche Aufgaben führen Sie durch? An welchen Aufgaben wirken sie mit? b) Mittels Ereignissen: Erstellen einer Ereignisliste Welche Aktivitäten lösen diese aus? Für jedes Ereignis Use Case ermitteln. c) Mittels Aufgabenbeschreibungen: Was sind die Gesamtziele des Systems? Welches sind die zehn wichtigsten Aufgaben? Was ist das Ziel jeder Aufgabe? Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

41 Wie findet man Use Cases? (2) 3. Use Cases für Sonderfälle ermitteln Erweiterungen und Alternativen in Use Case-Beschreibungen definieren Aufbauend auf Standardfälle die Sonderfälle formulieren und mit extend einbinden 4. Aufteilen komplexer Use Cases Komplexe Schritte als eigene Use Cases definieren und über include einbinden Komplexe Use Cases mit vielen Sonderfällen in mehrere Use Cases zerlegen und Gemeinsamkeiten mit extend modellieren 5. Gemeinsamkeiten von Use Cases ermitteln Gemeinsame Teilabläufe in eigenen Use Cases darstellen und über include einbinden Mehr Gemeinsamkeiten als Unterschiede Ggf. Generalisierung nutzen Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS

42 Kriterien für Use Cases Gute Use Cases: Verständlich für Auftraggeber Extern wahrnehmbares Verhalten Fachliche Beschreibung des Arbeitsablaufs Trennung von Standard- und Sonderfällen Beschreibung max. 1 Seite pro Use Case Häufige Fehler: Zu kleine und damit zu viele Use Cases Zu frühe Betrachtung von Sonderfällen Zu detaillierte Beschreibung Verwechseln von include und extend Es wird versucht, im Use Case-Diagramm eine Ablaufreihenfolge zu modellieren Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS