Software Engineering

Transkript

1 Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1

2 Geeignete Größe der Use Cases Die UML macht keine genauen Vorschriften, wie umfangreich ein Use Case sein soll. Es gibt unterschiedliche Arten, wie Use Cases einsetzt und strukturiert werden. In dieser Vorlesung werden System-Use Cases betrachtet, für die folgendes gelten soll: Ein Use Case ist eine abgeschlossene Aufgabe, die zu einem Zeitpunkt mit dem System i.d.r. ohne Unterbrechungen komplett durchgeführt wird. Wenn mehrere Akteure beteiligt sind, arbeiten diese gemeinsam und gleichzeitig an dem Use Case. Größe der Use Cases Name eingeben oder Start drücken sind zu klein, da es keine abgeschlossenen Aufgaben sind. Dienstfahrzeug beschaffen ist zu groß, da i. d. R. mehrere Use Cases erforderlich sind (beantragen, genehmigen, Bestellung aufgeben ). 2

3 Zusammenfassen von Use Cases Soll man als drei Use Cases modellieren? Oder genügt ein Use Case? Das hängt davon ab, ob es große Unterschiede zwischen den einzelnen Use Cases gibt, z. B. umfangreiche Prüfungen beim Anlegen, die beim Bearbeiten wegfallen es sehr viele Use Cases gibt und das Diagramm unübersichtlich wird. 3

4 Wie erstellt man Use Cases? Akteure ermitteln Wer benutzt das System? Welche Aufgaben führt jeder Akteur durch? Weitere Anforderungen ermitteln Welche Ziele hat das System? Welche Ergebnisse sollen durch die Arbeit mit dem System erzielt werden? Welche Ereignisse spielen eine Rolle für das System? Was wird dadurch jeweils ausgelöst? Wie kommen die benötigten Daten ins System? Werden für die Eingabe weitere Use Cases benötigt? Prinzip: Zunächst den Normalfall ermitteln (Happy path) Im zweiten Schritt Sonderfälle, Ausnahmen, Erweiterungen identifizieren Diagramm verfeinern (include, extend, Generalisierung) 4

5 Gute Use Cases Gute Use Cases Sind verständlich für den Auftraggeber Fachliche Beschreibung extern wahrnehmbaren Verhaltens Was erlebt der Benutzer? Keine Interna der Software, keine technischen Details Vollständige Beschreibung des Systems Was nicht beschrieben ist, wird nicht umgesetzt! Alle bei ordnungsgemäßem Betrieb des Systems möglichen Ausnahmen sind aufzuführen 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, Beschreibung ca. 1 Seite pro Use Case Mit Hilfe der Use Cases sollte man das System später testen können Hinweis: Vollständigkeit lässt sich prima durch Checklisten sicherstellen! 5

6 Weitere Formen von Use Case Quelle: 6

7 System-Use Cases Es wird das Zusammenspiel mit dem System beschrieben, keine Aktionen außerhalb des Systems Beispiel: Ungünstig: 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. 7

8 Hinweise und Tipps Use Case-Diagramme nicht zu umfangreich Keine Screenflows mit allen Möglichkeiten modellieren! Auf die wichtigsten include- und extend-beziehungen konzentrieren Große Use Case-Diagramme in mehrere Diagramme aufteilen. In Use Case-Diagrammen kann man keine Abläufe modellieren Jeder Use Case enthält selbst einen kleinen, abgeschlossenen Ablauf Keine Datenflüsse modellieren Wenn Auftrag anlegen und Auftrag genehmigen zu verschiedenen Zeiten und von verschiedenen Personen durchgeführt werden, wird im Use Case-Diagramm keine Beziehung gezeichnet. Use Case mit mehreren Akteuren Hat ein Use Case mehrere Akteure, so führen diese ihn gemeinsam aus Soll ein Use Case von unterschiedlichen Akteuren jeweils alleine ausgeführt werden, so erstellt man einen generalisierten Akteur. 8

9 Modellierung von Use Cases Quelle: Balzert, Lehrbuch der Softwaretechnik. Basiskonzepte und Requirements Engineering, S.48 ff. Als Name eines Use Case sollte gewählt werden: Die Gerundiumform eines Verbs, z. B. Verkaufen, ein Substantiv gefolgt von einem Verb, z. B. Verkauf durchführen der Anfangs- und Endpunkt des Prozesses, z. B. Interessent bis Auftrag. 9

10 Fallstudie Geräteverwaltung (1) Es soll ein System zur Verwaltung von Geräten in einer Firma, einer Hochschule o. ä. entwickelt werden (z. B. Computer, Beamer, Musikanlagen, Messgeräte, medizinische Geräte etc.) Ein Gerät kann entweder fest einem Mitarbeiter und ggf. einem Raum zugeordnet sein, oder es kann von einem Mitarbeiter ausgeliehen werden. Die Zuordnungen zu Mitarbeiter und Raum können geändert werden, d. h. ein Gerät wird weitergegeben, oder es zieht um. Für die Pflege der Geräte im System ist ein Geräteverwalter zuständig. Er verwaltet auch Informationen über Inspektionen oder Reparaturen der Geräte. Um ein Gerät auszuleihen, kann man es zunächst über das System reservieren. Hierbei wird immer ein bestimmter Gerätetyp reserviert, zu dem es mehrere einzelne Geräte geben kann. Das Verleihen und das Zurücknehmen eines Gerätes werden vom Geräteverwalter durchgeführt. Ein Verleih ist auch ohne vorherige Reservierung möglich. 10

11 Fallstudie Geräteverwaltung (2) Mitarbeiter können sich Geräte anzeigen lassen, die eigene Gerätenutzung anzeigen lassen (Reservierungen, fest zugeordnete Geräte) und eigene Reservierungen ändern. Der Geräteverwalter kann die Gerätenutzung beliebiger Mitarbeiter anzeigen und auch deren Reservierungen ändern. Für manche der genannten Aufgaben ist es erforderlich, Geräte oder Mitarbeiter zu suchen. Hierbei handelt es sich um eigene Aufgaben, die an verschiedenen Stellen wiederverwendet werden können. Der Geräteverwalter soll auch Statistiken erstellen können (über Gerätenutzung o.ä.) 11

12 Aufgabe Erstellen Sie eine Liste möglicher Akteure und Use Cases Hinweis: Eventuell sind noch weitere Akteure und Funktionen als die beschriebenen notwendig (vgl. Folie Wie erstellt man Use Cases, Weitere Anforderungen ermitteln. ) Welche Ergebnisse sollen durch die Arbeit mit dem System erzielt werden? Überlegen Sie sich, wie die jeweils benötigten Daten ins System kommen. 12

13 1. Ziel: System zur Geräteverwaltung in einer Firma entwickeln 2. Geräte: Computer, Beamer, Musikanlagen, Messgeräte, medizinische Geräte, 3. Ein Gerät kann entweder fest einem Mitarbeiter und ggf. einem Raum zugeordnet sein, oder es kann von einem Mitarbeiter ausgeliehen werden. 4. Die Zuordnungen zu Mitarbeiter und Raum können geändert werden, d. h. ein Gerät wird weitergegeben, oder es zieht um. 5. Für die Pflege der Geräte im System ist ein Geräteverwalter zuständig. Er verwaltet auch Informationen über Inspektionen oder Reparaturen der Geräte. 1. Mitarbeiter können sich Geräte anzeigen lassen, die eigene Gerätenutzung anzeigen lassen (Reservierungen, fest zugeordnete Geräte) und eigene Reservierungen ändern. 2. Der Geräteverwalter kann die Gerätenutzung beliebiger Mitarbeiter anzeigen und auch deren Reservierungen ändern. 3. Für manche der genannten Aufgaben ist es erforderlich, Geräte oder Mitarbeiter zu suchen. Hierbei handelt es sich um eigene Aufgaben, die an verschiedenen Stellen wiederverwendet werden können. 4. Der Geräteverwalter soll auch Statistiken erstellen können (über Gerätenutzung o.ä.) 6. Um ein Gerät auszuleihen, kann man es zunächst über das System reservieren. Hierbei wird immer ein bestimmter Gerätetyp reserviert, zu dem es mehrere einzelne Geräte geben kann. 7. Das Verleihen und das Zurücknehmen eines Gerätes werden vom Geräteverwalter durchgeführt. Ein Verleih ist auch ohne vorherige Reservierung möglich. 13

14 1. Ziel: System zur Geräteverwaltung in einer Firma entwickeln 2. Geräte: Computer, Beamer, Musikanlagen, Messgeräte, medizinische Geräte, 3. Ein Gerät kann entweder fest einem Mitarbeiter und ggf. einem Raum zugeordnet sein, oder es kann von einem Mitarbeiter ausgeliehen werden. 4. Die Zuordnungen zu Mitarbeiter und Raum können geändert werden, d. h. ein Gerät wird weitergegeben, oder es zieht um. 5. Für die Pflege der Geräte im System ist ein Geräteverwalter zuständig. Er verwaltet auch Informationen über Inspektionen oder Reparaturen der Geräte. Mitarbeiter können sich Geräte anzeigen lassen, die eigene Gerätenutzung anzeigen lassen (Reservierungen, fest zugeordnete Geräte) und eigene Reservierungen ändern. Der Geräteverwalter kann die Gerätenutzung beliebiger Mitarbeiter anzeigen und auch deren Reservierungen ändern. Für manche der genannten Aufgaben ist es erforderlich, Geräte oder Mitarbeiter zu suchen. Hierbei handelt es sich um eigene Aufgaben, die an verschiedenen Stellen wiederverwendet werden können. Der Geräteverwalter soll auch Statistiken erstellen können (über Gerätenutzung o.ä.) 6. Um ein Gerät auszuleihen, kann man es zunächst über das System reservieren. Hierbei wird immer ein bestimmter Gerätetyp reserviert, zu dem es mehrere einzelne Geräte geben kann. 7. Das Verleihen und das Zurücknehmen eines Gerätes werden vom Geräteverwalter durchgeführt. Ein Verleih ist auch ohne vorherige Reservierung möglich. 14

15 1. Ziel: System zur Geräteverwaltung in einer Firma entwickeln 2. Geräte: Computer, Beamer, Musikanlagen, Messgeräte, medizinische Geräte, 3. Ein Gerät kann entweder fest einem Mitarbeiter und ggf. einem Raum zugeordnet sein, oder es kann von einem Mitarbeiter ausgeliehen werden. 4. Die Zuordnungen zu Mitarbeiter und Raum können geändert werden, d. h. ein Gerät wird weitergegeben, oder es zieht um. 5. Für die Pflege der Geräte im System ist ein Geräteverwalter zuständig. Er verwaltet auch Informationen über Inspektionen oder Reparaturen der Geräte. 1. Mitarbeiter können sich Geräte anzeigen lassen, die eigene Gerätenutzung anzeigen lassen (Reservierungen, fest zugeordnete Geräte) und eigene Reservierungen ändern. 2. Der Geräteverwalter kann die Gerätenutzung beliebiger Mitarbeiter anzeigen und auch deren Reservierungen ändern. 3. Für manche der genannten Aufgaben ist es erforderlich, Geräte oder Mitarbeiter zu suchen. Hierbei handelt es sich um eigene Aufgaben, die an verschiedenen Stellen wiederverwendet werden können. 4. Der Geräteverwalter soll auch Statistiken erstellen können (über Gerätenutzung o.ä.) 6. Um ein Gerät auszuleihen, kann man es zunächst über das System reservieren. Hierbei wird immer ein bestimmter Gerätetyp reserviert, zu dem es mehrere einzelne Geräte geben kann. 7. Das Verleihen und das Zurücknehmen eines Gerätes werden vom Geräteverwalter durchgeführt. Ein Verleih ist auch ohne vorherige Reservierung möglich. 15

16 Mitarbeiter UC Gerät anzeigen (incl. UC Gerät suchen) und ggfs. UC Gerät reservieren / ohne Reservierung (direkt) leihen UC Eigene Gerätenutzung anzeigen und darin ggfs. seine UC eigene Reservierung bearbeiten Geräteverwalter UC Statistik erstellen UC Gerät bearbeiten, darin ein UC Gerät suchen. Optional eine UC fremde Reservierung des Geräts bearbeiten UC Gerät verleihen, wozu er es (passend) suchen muss UC Gerätenutzung alle MA anzeigen, dabei Ggfs. ein Gerät verleihen Einen best. UC Mitarbeiter suchen und ggfs. danach dessen (fremde) Reservierung ändern UC Geräte zurücknehmen Raumverwalter UC Raum bearbeiten 16

17 Aufgabe Wo kann man in dem Use Case-Diagramm sinnvoll die folgenden Beziehungen verwenden? Include Extend Generalisierung 17

18 Use Case-Diagramm Geräteverwaltung 18

19 Aufgabe Erstellen Sie eine Beschreibung für den Use Case Gerät reservieren Erstellen Sie eine Beschreibung für den Use Case Gerät verleihen Überlegen Sie sich jeweils, welche verschiedenen Fälle es geben kann Überlegen Sie sich jeweils, was alles schief gehen kann. 19

20 UC Gerät reservieren Name Gerät reservieren Vorbedingungen Ausleihbarer Gerätetyp wird angezeigt Nachbedingung im Erfolgsfall Neue Reservierung angelegt Nachbedingung bei Fehlschlag Keine neue Reservierung angelegt Akteure Mitarbeiter Auslösendes Ereignis Mitarbeiter wählt in Geräteanzeige Gerät reservieren Beschreibung 1. Der Mitarbeiter gibt den gewünschten Zeitraum an. 2. Das System zeigt an, dass die Reservierung zu diesem Zeitraum möglich ist. 3. Der Mitarbeiter bestätigt die Reservierung. Erweiterungen /Alternativen a) Bis Schritt 3 ist ein Abbruch möglich b) Zu Schritt 2: Die Reservierung ist nicht möglich. Falls ein Teil des gewünschten Zeitraums möglich ist, wird dieser angezeigt. Zudem wird angezeigt, wann ein Gerät des gewünschten Typs anschließend wieder verfügbar ist. Der Mitarbeiter kann dann den gewünschten Zeitraum ändern. 20

21 UC Gerät verleihen Name Gerät verleihen Vorbedingungen Reservierung in Gerätenutzung Mitarbeiter anzeigen selektiert, falls Verleih ohne Reservierung, keine Vorbedingung Nachbedingung im Erfolgsfall Gerät verliehen Nachbedingung bei Fehlschlag Gerät nicht verliehen, Reservierung ggf. storniert oder geändert Akteure Geräteverwalter Auslösendes Ereignis Geräteverwalter wählt Verleihen Beschreibung 1. Das System zeigt verfügbare Geräte für reservierten Gerätetyp an 2. Der Geräteverwalter wählt das zu verleihende Gerät aus 3. Das System zeigt Mitarbeiter, Gerät, Zeitraum an. 4. Der Geräteverwalter bestätigt die Ausleihe. Erweiterungen /Alternativen a) Bis Schritt 4 ist ein Abbruch möglich b) Zu Schritt 1: Falls Verleih ohne Reservierung, -> UC Gerät suchen und -> UC Mitarbeiter suchen. Rückgabedatum eintragen. c) Zu 3: Rückgabedatum kann geändert werden. d) Zu 1: Kein Gerät verfügbar (z. B. wegen Defekt), Reservierung löschen oder ändern -> UC Fremde Reservierung bearbeiten. 21

22 Hinweise zu Use-Case Beschreibungen Name Vorbedingungen Keine trivialen Vorbedingungen ( System läuft ), keine Bedingungen außerhalb des Systems ( Benutzer hat genug Geld auf dem Konto ). Sondern: Bedingungen im System, damit der Use Case überhaupt starten kann. Z. B. ist die Vorbedingung für Rechtschreibung prüfen : Dokument geöffnet. Dagegen ist Gewünschtes Buch vorhanden keine Vorbedingung für Buch suchen denn dann bräuchte man es ja erst gar nicht mehr suchen. Nachbedingung im Erfolgsfall Gewünschtes Ergebnis. Nachbedingung bei Fehlschlag Dass das gewünschte Ergebnis nicht erreicht wurde, ist weniger interessant. Wichtiger: Bereits stattgefundene Änderungen sind rückgängig gemacht (z. B. Geldrückgabe bei Abbruch an einem 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. Akteure Auslösendes Ereignis 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 Temperatur). Keine Ereignisse, die nicht auf das System einwirken (z. B. Benutzer hat Hunger bei Pizza-Bestellung erfassen ) Beschreibung Erweiterungen /Alternativen 22

23 Fragen Es wird ein Flugbuchungssystem betrachtet. Dort sucht man zunächst einen Flug. Hat man den gewünschten Flug gefunden, kann man eine Buchung für diesen Flug durchführen. In welcher Beziehung stehen die Use Case Flug suchen und Flug buchen? Welche Vorbedingungen hat der Use Case Flug buchen? Was könnte schiefgehen bei der Flugbuchung? Wo wird dies in der Beschreibung des Use Case berücksichtigt? Welche anderen Use Case könnten mittels include, welche mittels extend in Flug buchen eingeschlossen sein? Überlegen Sie sich ein Beispiel für einen Use Case des Flugbuchungssystems, der nicht vom Benutzer gestartet wird, sondern ein anderes auslösendes Ereignis hat. 23