Objektorientierte Modellierung mit UML Anwendungsfalldiagramm Der vorliegende Foliensatz basiert auf: M. Seidl, M. Brandsteidl, C. Huemer, G. Kappel: UML@Classroom, dpunkt.verlag, 2012. C. Larman: UML 2 und Patterns angewendet, mitp-verlag, 2005. 1
Anwendungsfallmodellierung Einführung Funktionale Zerlegung des zu entwickelnden Systems in Anwendungsfälle und in Akteure Anwendungsfälle (Use Cases) repräsentieren die Anforderungen der Kunden Akteure interagieren mit dem System im Kontext der Anwendungsfälle Ergebnisse der Anwendungsfallmodellierung Globales Anwendungsfalldiagramm (Use Case Diagram) Weitere Anwendungsfalldiagramme nach Bedarf Für jeden Anwendungsfall detaillierte textuelle Beschreibung Anwendungsfallmodellierung 4
Diagrammart Strukturdiagramm Verhaltensdiagramm Anwendungsfalldiagramm Einführung Beispiel ONLINEKALENDER Klassendiagramm Paketdiagramm Komponentendiagramm Verteilungsdiagramm Anwendungsfalldiagramm Zustandsdiagramm Objektdiagramm Kompositionsstrukturdiagramm Interaktionsdiagramm Aktivitätsdiagramm Sequenzdiagramm Kommunikationsdiagramm Zeitdiagramm Interaktionsübersichtsdiagramm Akteur: Wer benutzt das System? Benutzer des Kalenders (Nutzer des Systems, befindet sich außerhalb des Systems, mit dem er interagiert.) abfragen e exportieren ONLINEKALENDER löschen Benutzer Beziehung: Der Akteur benutzt einen Use Case, um ein Ziel zu erreichen (z. B. er führt Use Case durch, muss Eingaben machen o. ä.). erfassen ändern Use Case: Was machen die Akteure? erfassen, ändern, löschen, abfragen, etc. System: Was wird beschrieben? Onlinekalender (= Systemgrenze) Anwendungsfallmodellierung 5
Anwendungsfalldiagramm Akteur (Actor) Akteure interagieren mit dem System indem sie das System benutzen, d.h. die Ausführung von Anwendungsfällen initiieren indem sie vom System benutzt werden, d.h. Funktionalität zur Realisierung von Anwendungsfällen zur Verfügung stellen Akteur wird durch Assoziationen mit Anwendungsfällen verbunden, d.h. er»kommuniziert«mit dem System Jeder Akteur muss mit mindestens einem Anwendungsfall kommunizieren Notationsvarianten: Benutzer «actor» E-Mail-System Anwendungsfallmodellierung 6
Anwendungsfalldiagramm Akteur Klassifikation Menschlich: z.b. Benutzer, Administrator, Lehrender Nicht menschlich: z.b. E-Mail-System, Datenbank Primär: Hauptnutznießer der Anwendung, hat Anwenderziele, die durch Nutzung der Dienste des Systems erfüllt werden Sekundär: Notwendig für das Funktionieren des Systems, stellt einen Dienst (bspw. Informationen) für das System zur Verfügung; oft ein Computersystem (bspw. E-Mail-Server) Aktiv: stößt selbst Anwendungsfälle an Passiv: stößt selbst keine Anwendungsfälle an menschlich primär aktiv Benutzer ONLINEKALENDER erfassen Teilnehmer verständigen «actor» E-Mail-System nicht-menschlich sekundär passiv Anwendungsfallmodellierung 8
Anwendungsfalldiagramm Akteur - Fragen zur Identifikation Wer startet und stoppt das System? Wer benutzt die wesentlichen Anwendungsfälle? Wer braucht Systemunterstützung für die tägliche Arbeit? Ist die "Zeit" ein Akteur, weil das System auf zeitliche Ereignisse reagiert? (Akteur Zeit einführen!) Wer ist für die Systemadministration zuständig? Mit welchen externen Geräten / (Software-) Systemen muss das System kommunizieren können? Wer oder was interessiert sich für die Ergebnisse des Systems? Wer wird bei Fehlern oder Misserfolgen benachrichtigt?... Akteure sind anfänglich beim Brainstorming wichtig, um Vollständigkeit zu erreichen! Frage sollte lauten: "Was sind Ihre Ziele, deren Ergebnisse einen messbaren Wert haben?" Primärakteur Benutzer Administrator... Akteur-Ziele-Liste Anwendungsfallmodellierung 9 Ziel erfassen abfragen löschen löschen
Anwendungsfalldiagramm Anwendungsfall (Use Case) Anwendungsfälle beschreiben das Verhalten, das von dem zu entwickelnden System erwartet wird Identifizierung durch Sammeln von Kundenwünschen und Analyse der textuellen Problemstellung Notationsvarianten: Kurzbeschreibung als Notiz: erfassen erfassen erfassen»ein kann für einen oder mehrere Teilnehmer von berechtigten Benutzern (müssen nicht notwendigerweise auch Teilnehmer sein) erfasst werden. Alle Teilnehmer müssen über diesen neuen verständigt werden. Neue e müssen sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden.«anwendungsfallmodellierung 10
Ablauf einer include-beziehung Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - «include» Das Verhalten des benutzten Anwendungsfalls (inkludierter Anwendungsfall) wird in den benutzenden Anwendungsfall (Basis-Anwendungsfall) eingebunden Der inkludierte Anwendungsfall B ist unbedingt notwendig, um die Funktionalität des Basis-Anwendungsfalls A sicherzustellen Der inkludierte Anwendungsfall B kann allerdings separat ausgeführt werden A erfassen Basis-Anwendungsfall - benötigt inkludierten Anwendungsfall um die Funktionalität sicher zu stellen «include» B Kalender aktualisieren Inkludierter Anwendungsfall - kann auch separat ausgeführt werden Anwendungsfallmodellierung 11
Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - «extend» Das Verhalten von B kann in A inkludiert werden Somit entscheidet A, ob B ausgeführt wird. Der erweiternde Anwendungsfall B kann von A aktiviert werden, muss aber nicht Angabe des»wo«durch Erweiterungsstellen in A Angabe des»wann«durch Bedingung in A bzw. als Teil der «extend»-beziehung A Programm verwalten «extend» B Zugriffsrechte verwalten Ablauf einer extend-beziehung A extension points EP1 Basis-Anwendungsfall - kann auch separat ausgeführt werden - entscheidet, ob B ausgeführt wird oder nicht Erweiternder Anwendungsfall - kann auch separat ausgeführt werden Anwendungsfallmodellierung 12
Anwendungsfalldiagramm Analogien zu Programmiersprachen «include» entspricht Unterprogrammaufruf void B () { } A «include» B void A () { } B(); } «extend» entspricht bedingtemunterprogrammaufruf A condition: { } «extend» B void B () { } void A () { } /* EP */ if Condition then B(); } Anwendungsfallmodellierung 14
Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - Generalisierung 1/2 Vergleichbar mit Generalisierungsbeziehung zwischen Klassen B erbt Verhalten von A und kann dieses überschreiben oder ergänzen B erbt alle Beziehungen von A Modellierung abstrakter Anwendungsfälle möglich - {abstract} A B Basis-Anwendungsfall - kann auch separat ausgeführt werden Abgeleiteter Anwendungsfall - benötigt A (übernimmt Grundfunktionalität von A) - entscheidet, was von A ausgeführt bzw. geändert wird Anwendungsfallmodellierung 15
Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - Generalisierung 2/2 Benutzer {abstract} Eintrag erfassen erfassen ToDoEintrag erfassen Anwendungsfallmodellierung 16
Anwendungsfalldiagramm Generalisierung bei Akteuren 1/2 Akteur A erbt von Akteur B A kann mit den Anwendungsfällen X und Y kommunizieren B kann nur mit Y kommunizieren A X B Y Bsp.: Administrator Benutzer Benutzer anlegen erfassen Anwendungsfallmodellierung 17
Anwendungsfalldiagramm Generalisierung bei Akteuren 2/2 Unterscheidung, ob mehrere Akteure gemeinsam mit einem Anwendungsfall kommunizieren können oder müssen. A X A X {abstract} C B A und B kommunizieren mit X B A oder B kommuniziert mit X Anwendungsfallmodellierung 18
Anwendungsfalldiagramm Beziehungen Beispiel: ONLINEKALENDER (verfeinert) Benutzer Administrator abfragen erfassen Programm verwalten «extend» Zugriffsrechte verwalten e exportieren ändern Teilnehmer verständigen Einstellungen verwalten typen verwalten ONLINEKALENDER löschen «include» «include» «extend» Benutzer verwalten Kalender aktualisieren «actor» E-Mail-System Anwendungsfallmodellierung 19
Anwendungsfalldiagramm Partitionierung des Anwendungsfalldiagramms 1/3 Anwendungsfalldiagramme werden schnell unübersichtlich Allgemeiner UML-Abstraktionsmechanismus: Paket «systemmodel» ONLINEKALENDER Systemverwaltung verwaltung Anwendungsfallmodellierung 20
Anwendungsfalldiagramm Partitionierung des Anwendungsfalldiagramms 2/3 verwaltung Benutzer abfragen erfassen Einträge exportieren aktualisieren «include» «include» «include» ändern löschen «include» «include» «include» Teilnehmer verständigen «actor» E-Mail-System Anwendungsfallmodellierung 21
Anwendungsfalldiagramm Partitionierung des Anwendungsfalldiagramms 3/3 Systemverwaltung verwaltung ::Benutzer Programm verwalten Benutzer verwalten «extend» «extend» Einstellungen verwalten Zugriffsrechte verwalten typen verwalten Administrator Anwendungsfallmodellierung 22
Anwendungsfalldiagramm Zusammenfassung Richtlinien Erstellen Sie eine Akteur-Ziele-Liste Zeichnen Sie einfache Anwendungsfalldiagramme Primärakteure stehen links Unterstützende Akteure stehen rechts Vorteile: Anwendungsfalldiagramme vermitteln ein ausgezeichnetes Bild des Systemkontextes bzw. der Systemgrenzen! Man hat sehr schnell ein Verständnis für das System (top-level). Man findet, wenn nötig, sehr schnell zu den relevanten Details. Anwendungsfalldiagramme sind leicht verständlich! Kunde/Anwender/Sponsor versteht, was er bekommen wird. Entwickler/Projektleiter versteht, was er bauen/liefern muss. Anwendungsfallmodellierung 23
Anwendungsfalldiagramm Lasst uns beginnen...... und folgende Fehlerquellen vermeiden: Zu kleine und damit zu viele Anwendungsfälle Zu frühe Betrachtung von Sonderfällen Zu detaillierte Beschreibung der Anwendungsfälle Verwechseln von Generalisierung und extend-beziehung Anwendungsfälle beschreiben Dialog(GUI)-Abläufe Es wird versucht, im Anwendungsfalldiagramm eine Ablaufreihenfolge zu modellieren Anwendungsfälle für Auftraggeber nicht verständlich Anwendungsfallmodellierung 24
Sind Anwendungsfalldiagramme ausreichend? Use-Case-Experten warnen:... NEIN!!! Anwendungsfalldiagramme und Beziehungen spielen bei der Anwendungsfall-Erhebung eine untergeordnete Rolle! Anwendungsfälle sind Textdokumente! Don t spend much time on diagramming. Use case work means to write text, not draw diagrams Anwendungsfall-Erhebung bedeutet, Text zu schreiben! (strukturierte und textuelle) Anwendungsfallbeschreibung Anwendungsfallmodellierung 25
Anwendungsfallbeschreibung Szenarien eines Anwendungsfalls Ein Anwendungsfall ist eine Abfolge von erfolgreichen und nicht erfolgreichen Aktivitäten. Alternative endet mit Fehler Alternative mündet wieder in Hauptszenario ein Hauptszenario Erfolg ("glücklicher Weg") Alternative endet mit Fehler Anwendungsfallmodellierung 26
Anwendungsfallbeschreibung Beschreibungsvorlage 1/2 Use-Case-Abschnitt Use-Case-Name/Nummer Kurzbeschreibung Primärakteur (mit Ziel) Sekundärakteur (mit Ziel) Vorbedingungen Ergebnis bei Erfolg (~Nachbedingung) Ergebnis bei Fehler Standardablauf (Hauptszenario) Alternativ- und Fehlerabläufe Spezielle Anforderungen Kommentar Nennen Sie das Objekt und dann das Verb. [ erfassen] Kurze, abstrakte Beschreibung des Ablaufs (ca. zwei bis drei Sätzen) Nutzt einen Dienst des Systems, um ein Ziel zu erfüllen. [AdministratorIn] Andere am Use Case beteiligte (unterstützende) Akteure und Systeme, die vom System während der Abarbeitung des Use Cases benötigt werden. [E-Mail-System] Bedingungen, die erfüllt sein müssen, damit der Use Case ausgeführt werden kann. Der Zustand des Systems nach erfolgreicher Beendigung des Use Cases. Der Zustand des Systems, wenn der Use Case nicht erfolgreich beendet wurde. Das Szenario für einen typischen, erfolgreichen Durchlauf durch den Use Case. Alternative Abläufe zum Hauptszenario für Erfolg oder Misserfolg. Zum System gehörige, nichtfunktionale Anforderungen Häufigkeit des Auftretens Status Beeinflusst die Untersuchung, das Testen und die zeitliche Gestaltung der Implementierung Status beschreibt, ob der Use Case ein Entwurf, bereit zum Review oder abgenommen ist. Offene Punkte Offene Punkte, die den Use Case betreffen. Anwendungsfallmodellierung 27
Anwendungsfallbeschreibung Beschreibungsvorlage 2/2 Standardablauf (Hauptszenario) ein typisches (erfolgreiches) Szenario des Ablaufs des Anwendungsfalls, ohne Verzweigungen (siehe Alternativabläufe) besteht aus einzelnen Schritten wie bspw. Interaktionen zwischen Akteuren Validierungen, normalerweise durch das System Zustandsänderungen durch das System (z.b. speichern, ändern) Aufruf anderer Anwendungsfälle Alternativ- und Fehlerabläufe (Erweiterungen) Konkretisierungen sowie Erweiterungen des Standardablaufs ein derartiger Ablauf kann sich auf mehrere Schritte im Standardablauf beziehen besteht meist aus einer Bedingung und Aktionen nach Ausführung Rückkehr in Standardablauf oftmals umfangreicher als der Standardablauf Anwendungsfallmodellierung 28
Anwendungsfallbeschreibung Beschreibung Beispiel: ONLINEKALENDER 1/3 erfassen UC 3 V1.1 Kurzbeschreibung: Ein kann für einen oder mehrere Teilnehmer von berechtigten Benutzern (müssen nicht notwendigerweise auch Teilnehmer sein) erfasst werden. Alle Teilnehmer müssen über diesen neuen verständigt werden. Neue e müssen sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden. Primärakteure (auslösende Akteure): Benutzer: Will für sich oder mehrere Teilnehmern erfassen. Will, dass alle Teilnehmer über diesen neuen verständigt werden. Will, dass neue e sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden. Sekundärakteure (unterstützende Akteure): E-Mail-System: Will Einladung zum im richtigem Format erhalten. Vorbedingungen: Benutzer ist dem System bekannt Ergebnis bei Erfolg: Neuer ist erfasst. Alle Teilnehmer sind verständigt und gegebenenfalls informiert, dass es aus Berechtigungsgründen nicht möglich war, ihren kalender zu verändern. Alle Sichten (Kalender) sind aktualisiert. Anwendungsfallmodellierung 29
Anwendungsfallbeschreibung Beschreibung Beispiel: ONLINEKALENDER 2/3 Entferne alle Fehlerbedingungen, die durch die Vorbedingungen ausgeschlossen sind. Anderes Use Case-Szenario ausführen Bedingung Handhabung/Reaktion (kann in einem oder mehreren Schritten beschrieben werden) Ergebnis bei Fehler: Fehler Ergebnis Bedingung, die dazu geführt hat a. Benutzer ist nicht berechtigt, zu erfassen. Standardablauf: 1. Benutzer identifiziert sich. Der Versuch den zu erfassen ist protokolliert. 2. Daten des neuen s (Zeit, Ort, Dauer, Teilnehmer, etc.) werden eingegeben. 3. Benutzer ist berechtigt, für alle Teilnehmer den zu erfassen. [a] 4. führt bei keinem Teilnehmer zu Kollisionen und wird erzeugt. 5. Alle Teilnehmer (ausgenommen der Benutzer, wenn dieser auch Teilnehmer ist) werden gemäß ihrer bevorzugten Kommunikationsart verständigt. («include» UC 5 Teilnehmer verständigen) 6. Alle geöffneten Kalender von Teilnehmern werden aktualisiert. («include» UC 9 Kalender aktualisieren) Erweiterungen (alternative Abläufe): Kalender wurde von Teilnehmer nicht an den Benutzer freigegeben. 3a Benutzer ist für mindestens einen Teilnehmer nicht berechtigt, den in seinem Kalender zu erfassen. 1. System signalisiert Benutzer fehlende Berechtigung 4a Analog zu (4) 5a Analog zu (5), wobei jene Teilnehmer, deren Kalender nicht änderbar waren, zusätzlich davon informiert werden, dass es aus Berechtigungsgründen nicht möglich war, ihren kalender zu verändern. 6a Alle geöffneten Kalender von jenen Teilnehmern werden aktualisiert, für die eine Anwendungsfallmodellierung Berechtigung zur Änderung des Kalenders vorliegt. 30 Fehlerbedingung leitet Alternative ein!
Anwendungsfallbeschreibung Beschreibung Beispiel: ONLINEKALENDER 3/3 Spezielle Anforderungen: Antwortzeit bei der Kollisionsprüfung der e anderer Teilnehmer innerhalb von 15 Sekunden in 90 % der Fälle bei max. 10 Teilnehmer. Aktualisierung betroffener Kalender innerhalb von 30 Sekunden in 70 % der Fälle. Häufigkeit des Auftretens: Beinahe laufend Status: In Arbeit/bereit zum Review/im Review/abgelehnt/abgenommen Offene Fragen: Wie und in welcher Form werden Teilnehmer informiert, bei denen aus fehlenden Berechtigungsgründen kein belegt werden konnte. Anwendungsfallmodellierung 31
Anwendungsfallbeschreibung Vorgehen Achte auf Zeit und Ressourcen gehe zuerst in die Breite zuerst Akteure und deren Ziele dann Hauptszenarien beschreiben gehe erst danach in die Tiefe erst dann Fehlerbedingungen und deren Behandlung in Alternativen beschreiben Benutzerschnittstelle nicht berücksichtigen In 4 Schritten vorgehen: 1. Primäre Akteure und Ziele identifizieren 2. Hauptszenarien schreiben 3. Fehlerbedingungen identifizieren 4. Alternativen schreiben Anwendungsfallmodellierung 32
Anwendungsfallbeschreibung Zusammenfassung Wie viel Anwendungsfall-Modellierung braucht man? Anwendungsfälle sind ein Vertrag zwischen Kunde und Entwicklerteam. Beide müssen diesem guten Gewissens zustimmen können, auch wenn sich Details später ändern können. Wie viele Anwendungsfälle sollte man haben? Hängt vom Projekt ab, z.b. 20-80 In der ersten Iteration ca. 20-30 % detaillierter beschreiben Wie lange soll ein Anwendungsfall sein? Hängt vom Anwendungsfall ab, 5-12 Schritte, 0.5 2 Seiten Was ist das beste Format? Es gibt nicht das beste Format! Anwendungsfallmodellierung 33
Anwendungsfälle sind eine gute Basis... für die Kommunikation zwischen Kunden und Entwicklern um zu verstehen, was das Problem des Kunden ist um das Problem spezifizieren und somit entwickeln zu können zum Identifizieren von Objekten, deren Funktionalität, Interaktion und Schnittstellen für die Aufwandschätzung für die Planung der Entwicklung Aufteilung in mehreren Releases/Interationen für die Definition der funktionalen Testfälle und der Akzeptanztests für die Erstellung von Dokumentation für den Endanwender Anwendungsfallmodellierung 34
Aufwandschätzung auf Basis von Anwendungsfällen Erstelle eine Liste der Anwendungsfälle Bewerte jeden Anwendungsfall (bspw. einfach / mittel / schwierig). Gewichte die Anwendungsfälle mit Aufwandsfaktor (z.b. 2 Tage für einfachen Anwendungsfall, 5 für mittleren, 15 für schwierigen, Faktoren müssen für Projekt und Projektmitarbeiter passen!). Teile die Anwendungsfälle Personen zu. Summiere, wer wie viel Arbeit hat. Anwendungsfallmodellierung 35
Aufwandschätzung Beispiel Aufwand pro Entwickler Use Cases Komplexität Aufwand Entwickler R1 R2 UC 4 Content und Playlisten zum Server übertragen m 5 R1 5 0 UC 5 Playlist aktivieren m 5 R1 5 0 UC 14 - Content-Verteilung per CD definieren m 5 R2 0 5 UC 15 Content versionieren l 2 R2 0 2 UC 18 Playlist und Content zur lokalen Abspielung vorbereiten m 5 R1 5 0 UC 19 Playlist und Content lokal kopieren e 2 R1 2 0 UC 20 Einstellungen definieren e 2 R1 2 0 UC 21 Content und Playlisten vom Server holen m 5 R1 5 0 UC 6 Benutzer, Hosts und Gruppen definieren e 2 R2 0 2 UC 7 Jobs definieren e 2 R2 0 2 UC 8 - Fehlerbenachrichtigung bearbeiten e 2 R2 0 2 UC 9 CD einspielen e 2 R2 0 2 UC 10 Job ausführen e 2 R1 2 0 UC 11 Job submitten e 2 R1 2 0 UC 12 Fehlerbenachrichtigung verschicken m 5 R2 0 5 UC 13 Content abspielen e 2 R1 2 0 UC 16 Content von CD installieren m 5 R2 0 5 UC 17 Playlist in der Bankstelle aktivieren m 5 R1 5 0 60 35 25 Aufwandsfaktor e 2 m 5 s 15 Anwendungsfallmodellierung 36
Zusammenfassung Sie haben Anwendungsfallmodellierung verstanden, wenn Sie wissen dass mit dem Anwendungsfallidagramm das Verhalten eines Systems aus der Sicht der Benutzer beschrieben wird. dass an einem Anwendungsfalldiagramm Akteure und Anwendungsfälle beteiligt sind. dass bei einem Anwendungsfalldiagramm die Grenzen des Systems klar definiert sein müssen und sich die Akteure immer außerhalb des Systems befinden. wie das Zusammenspiel zwischen Akteuren und Anwendungsfällen aussieht. dass es sowohl für Anwendungsfälle als auch für Akteure Generalisierungsbeziehungen gibt. worin der Unterschied zwischen <<include>> und <<extend>> besteht. Anwendungsfallmodellierung 37
Literaturhinweise Alistair Cockburn: "Use Cases effektiv erstellen", MITP Verlag (2003, ISBN: 3-8266-1796-6) Kurt Bittner, Ian Spence: Use Case Modeling, Addison-Wesley (2003, ISBN: 0201709139) Steve Adolph, Paul Bramble, Alistair Cockburn: Patterns for Effective Use Cases, Addison- Wesley (2003, ISBN: 0201721848) Daryl Kulak, Eamonn Guiney: Use Cases, Addision-Wesley (2004, ISBN 0201657678) Anwendungsfallmodellierung 38