Vorlesung Software-Engineering I

Transkript

1 Vorlesung Software-Engineering I im 3. und 4. Semester 07. SW-Architektur Abläufe Workflows Szenarien Use Cases User Story s -> Betrachtung deterministischer Abläufe DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH Software-Architektur: Sichten Hierarchien: ConceptMap UML Abläufe: BPMN UML Entwurf Daten: ERM UML Zustände: UML DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 2

2 Abläufe in der Architektur Darstellung? Daten Vorgang 1 Vorgang 2 Vorgang 3 Ausgangsdaten Eingangsdaten Ausgangsdaten Vorgang 1 Vorgang 2 Anwender globale Daten => wie soll das richtig (formal) aussehen? DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 3 User Story s aus der Anforderungserhebung Frage: WER: Was für eine Rolle habe ich? WAS will ich machen? WARUM will ich das machen? Antwort: SW-Entwickler Reststundenschätzung eingeben Für die Berechnung des Fortschritts UML: Use Case, Anwendungsfall Story Card, User-Story DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 4

3 Ablauf := Einen Anwendungsfall näher beschreiben Beschreibung des Anwendungsfalls Eingabe-/Ausgabeparameter Abläufe von verschiedenen beteiligten Stellen Daten DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 5 Darstellungsmöglichkeiten UML UseCase-Diagramme Aktivitätsdiagramme BPMN EPK/VPK PAP Datenfluss-Diagramme (SA) Besondere Ausprägungen: Swimlanes (Schwimmbahnen) Textuelle Beschreibungen Simulationen Token DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 6

4 UML: Verhaltensdiagramme Statisch: Anwendungsfalldiagramme Aktivitätsdiagramme Zustandsdiagramme Dynamisch: Sequenzdiagramme Timingdiagramme Kommunikationsdiagramme Interaktionsübersichsdiagramme DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 7 UML: Aktivitätsdiagramm Aktivität Verzweigung Objekt- knoten Eingangs- Parameter/ -Daten Ausgangs- Parameter/ -Daten Startknoten Endknoten Kontrollfluss DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 8

5 BPMN - Business Process Modeling Notation Conversations-Diagramme Choreography-Diagramme DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 9 Vergleich: UML vs. BPMN Aktion, Aktivität Aktion Aufgabe Aufgabe, Arbeitseinheit Objekt, Daten, Ein-/Ausgabe-Parameter Objekt Datenobjekt Speicher Daten, Speicher, Input/Output, Nachrichten Knoten: Start / Ende Kontrollfluss Ereignisse: Start / Ende (es gibt noch einige mehr ) Sequenzfluss Nachrichtenfluss Assoziation Verzweigungen: (X)OR / AND X + O Gateways: XOR / AND / OR Gruppierung (zugeklappter Ablauf) Vorgang Teilprozess + Gruppierung (zugeklappter Ablauf) DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 10

6 Der Ablauf: Kontrollfluss/Sequenzfluss (UML/BPMN) Token XOR-Verzweigung: Nur ein Pfad ist möglich. 1 [1] [0] 2 3 Aktivität 1 Aktivität 2 4 DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 11 Der Ablauf: Kontrollfluss/Sequenzfluss (UML/BPMN) Token AND-Verzweigung: Alle Pfade werden durchlaufen. 1 [10 Sek.] 2 3 Aktivität 1 Aktivität [20 Sek.] 4 warten bis alle Token da sind! DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 12

7 Abläufe - Beispiel Ausleihliste Die Mitarbeiter leihen aus unserem Ausleihschrank verschiedene Geräte aus. Wir wollen wissen wer welches Gerät gerade ausgeliehen hat. Evtl. sollte der Mitarbeiter auch angeben bis wann er das Gerät wieder zurück gibt. Wir haben Notebooks, Beamer, Digitalkameras, Videokameras im Ausleihschrank. Was Wann Wer Notebook H. Apel Digitalkamera Notebook 1 Beamer H. Burgmüller H. Meier, Hans H. Meier, Hans Wenn die Mitarbeiter den zurück gebracht haben wird die Zeile durchgestrichen. Bei Mitarbeitern mit nicht eindeutigem Namen wird noch der Vorname hingeschrieben. Einige Geräte sind mehrfach vorhanden, dann sind sie mit Nummern gekennzeichnet. DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 13 End-to-End Verknüpfung Die Mitarbeiter leihen aus einem Ausleihschrank verschiedene Geräte aus. ausleihen zurückgeben <<extends>> benutzen User-Story: Als Mitarbeiter möchte ich verschiedene Geräte (z.b. Notebook, Beamer) ausleihen können, damit wir nicht jedes Gerät selbst kaufen müssen. Ausleihen benutzen Rückgabe Beispielanwendung Ausleihschrank DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 14

8 Beispiel Ausleihliste: Ausleihvorgang Einfach: Happy-Path -Ansatz aus Schrank entnehmen Vorgang in Ausleihliste eintragen [ ausleihbar] Besser: Statusabfrage aus Schrank entnehmen Vorgang in Ausleihliste eintragen Ist der überhaupt ausleihbar? Ist der schon ausgeliehen? [ nicht ausleihbar] DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 15 Beispiel Ausleihliste: Rückgabevorgang Einfach: Happy-Path in Schrank legen Vorgang aus Ausleihliste löschen [kein ausleihbarer ] Besser: in Schrank legen Status- abfrage Vorgang aus Ausleihliste löschen [ war nicht ausgeliehen] Dieb! DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 16

9 Beispiel Ausleihliste: Statusabfrage Anlass: Ein Mitarbeiter fragt an ob ein bestimmter ausgeliehen werden kann. Eingangsparameter: Ein bestimmter im Schrank [nicht gefunden] in Ausleihliste ist ausgeliehen von <Mitarbeiter> kann Ausgeliehen werden. Was fehlt? Erst in Ausleihliste dann im Schrank -> evtl. Architekturfehler Woher weis man ob der angefragte überhaupt ausleihbar ist? Was passiert wenn der auch nicht in der Ausleihliste steht? DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 17 Beispiel Ausleihliste: Statusabfrage - verbessert Anlass: Ein Mitarbeiter fragt an ob ein bestimmter ausgeliehen werden kann. Ziel: Info ob der ausgeliehen werden kann oder wer ihn gerade ausgeliehen hat. Eingangsparameter: Ein bestimmter im Schrank [nicht gefunden] in Ausleih- liste kann nicht ausgeliehen werden. ist ausgeliehen von <Mitarbeiter> kann ausgeliehen werden. Was fehlt? Erst in Ausleihliste dann im Schrank -> evtl. Architekturfehler Wie erkennt man ob ein nicht geklaut wurde, wenn er weder im Schrank noch in der Ausleihliste steht? DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 18

10 Beispiel Ausleihliste: Statusabfrage - ausführlich Anlass: Ein Mitarbeiter fragt an ob ein bestimmter ausgeliehen werden kann. Ziel: Info ob der ausgeliehen werden kann oder wer ihn gerade ausgeliehen hat. Eingangsparameter: Ein bestimmter [nicht gefunden] Kein ausleihbarer. in Bestandsliste in Ausleihliste [nicht gefunden] ist ausgeliehen von <Mitarbeiter> Statusabfrage Status im Schrank manuelle Suche! [nicht gefunden] kann ausgeliehen werden. ist geklaut worden. DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 19 Beispiel Ausleihliste: Parameter ID_ Name Statusabfrage Status Kein ausleihbarer ist ausgeliehen kann ausgeliehen werden ID_ Name Kein ausleihbarer Ausleihen Status ist ausgeliehen wurde ausgeliehen werden ID_ Name Gegen- stand Kein ausleihbarer Rückgabe Status ist nicht ausgeliehen wurde zurückgegeben DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 20

11 Schwimmbahnen (Swimlanes) Kunde Mitarbeiter System Anfrage zum Statusabfrage ob Ausleihen eines in Ausleihliste es verfügbar Info mitnehmen Info an Kunden dass ausgeliehen ist aus Schrank entnehmen [ausgeliehen] [verfügbar] in Ausleihliste eintragen DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 21 Beispiel: Ausleihliste als BPMN DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 22

12 yed UML: Aktitivätsdiagramm BPMN DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 23 Was fehlt uns noch? Ereignisse Senden Empfangen BPMN: Unterbrechungen Ausnahmen Abbruch Fehler UML: DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 24

13 Best-Practice: Funktionen und Rollen als Swimlanes Funktionen Rollen DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 25 Fragen: DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 26

14 UML: Verhaltensdiagramme - Aktivitätsdiagramm Das Aktivitätsdiagramm ist ein Verhaltensdiagramm. Es zeigt eine bestimmte Sicht auf die dynamischen Aspekte des modellierten Systems. Ein Aktivitätsdiagramm stellt die Vernetzung von elementaren Aktionen und deren Verbindungen mit Kontroll- und Datenflüssen grafisch dar. Mit einem Aktivitätsdiagramm wird meist der Ablauf eines Anwendungsfalls beschrieben, es eignet sich aber zur Modellierung aller Aktivitäten innerhalb eines Systems. In der UML2 hat sich die Semantik der Aktivitätsdiagramme stark den Petri-Netzen angenähert und ermöglicht nun besser die Darstellung von nebenläufigen Systemen durch die Einbindung von asynchronen Kommunikationsmechanismen (Signal senden und empfangen, Ausnahmebehandlung). Ein Aktivitätsdiagramm spezifiziert eine Aktivität. Die detaillierten Regeln dafür, wie Token in einer Aktivität fließen, bilden die Grundlage für die Interpretation eines Aktivitätsdiagramms. Das Aktivitätsdiagramm ist eine objektorientierte Adaption des Programmfluss-Diagramms. Eine Alternative ist BPMN (Business Process Modeling Notation) DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 27 Beispiel: Aktivitätsdiagramm Anlass: Ein Mitarbeiter fragt an ob ein bestimmter ausgeliehen werden kann. Ziel: Info ob der ausgeliehen werden kann oder wer ihn gerade ausgeliehen hat. Eingangsparameter: Ein bestimmter [nicht gefunden] Kein ausleihbarer. in Bestandsliste in Ausleihliste [nicht gefunden] ist ausgeliehen von <Mitarbeiter> Statusabfrage Status im Schrank manuelle Suche! [nicht gefunden] kann ausgeliehen werden. ist geklaut worden. Beispielanwendung Ausleihschrank DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 28

15 UML: Verhaltensdiagramme - Sequenzdiagramm Das Sequenzdiagramm ist ein Verhaltensdiagramm, genauer eines der vier Interaktionsdiagramme. Es zeigt eine bestimmte Sicht auf die dynamischen Aspekte des modellierten Systems. Ein Sequenzdiagramm ist eine grafische Darstellung einer Interaktion und beschreibt den Austausch von Nachrichten zwischen Ausprägungen mittels Lebenslinien. Ein Sequenzdiagramm stellt in der Regel einen Weg durch einen Entscheidungsbaum innerhalb eines Systemablaufes dar. Sollen Übersichten mit allen Entscheidungsmöglichkeiten entwickelt werden, so müsste hierzu für jeden möglichen Ablauf ein eigenständiges Sequenzdiagramm modelliert werden; deshalb eignet sich hierfür eher das Aktivitätsdiagramm oder Zustandsdiagramm. DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 29 Beispiel: Ablaufbeschreibung Beispiel: Ablauf eines Ausleihvorgangs :Mitarbeiter :Verwalter :Liste :Schrank Ausleihwunsch Verfügbarkeit prüfen Ausfassen Ausleihen Beispielanwendung Ausleihschrank DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 30

16 UML: Verhaltensdiagramme - Zustandsdiagramm Ein Zustandsdiagramm zeigt eine Übersicht der Zustände, die der dargestellte Zustandsautomat beispielsweise ein einzelnes Objekt oder auch ein (Teil-)System zur Laufzeit annehmen kann und gibt an, aufgrund welcher Ereignisse Zustandsänderungen bzw. -übergänge stattfinden. Damit beschreibt ein Zustandsdiagramm eine hypothetische Maschine (endlicher Automat), die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet. Die Zustände in einem Zustandsdiagramm werden durch Rechtecke mit abgerundeten Ecken dargestellt. Die möglichen Zustandsübergänge werden durch Pfeile zwischen den Zuständen symbolisiert. Sie sind mit den Ereignissen beschriftet, die zu dem jeweiligen Zustandsübergang führen. Der in einem Diagramm dargestellte Zustandsautomat besteht aus Knoten (engl. vertex) und (Zustands-)Übergängen (engl. transitions), die einen Quell- und einen Zielknoten verbinden. Jeder Knoten ist entweder ein Zustand (engl. state) oder aber ein so genannter Pseudo-Zustand (engl. pseudo state). Ein Zustand modelliert eine Situation, in der eine bestimmte, unveränderliche Bedingung gilt. Eine Transition (Übergang) verbindet einen Quell- und einen Zielknoten. Der Transition kann eine Verhaltensspezifikationen zugeordnet sein, die das Verhalten beschreibt, das ausgeführt wird, wenn die Transition durchlaufen wird. Siehe auch Zustandsautomat/endlicher Automat. DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 31 Beispiel: Verhaltensbeschreibung Beispiel: Zustände eines Ausleihgegenstandes in Liste aufnehmen ausleih hen ausleihbar ben zurückge als defekt einstufen kaputt aus Liste löschen ausgeliehen geklaut Beispielanwendung Ausleihschrank DHBW-Stuttgart/Frank M. Hoyer SWE1-07: Abläufe 16. Oktober 2010 geändert: 15. Oktober 2013, FMH 32