Vgl. Oestereich Kap 2.1 Seiten

Transkript

1 Vgl. Oestereich Kap 2.1 Seiten

2 Ein Use Case ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt). Use Case Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel Daten erfassen, Adresse ändern, Auto reservieren, Konto löschen, (oder Verb/Subjekt in anderen Sprachen: change address ). Häufig sind die (System-) Anwendungsfälle die computerunterstützten Teile der Geschäftsprozesse. 2

3 Es werden mit dem Use Case Diagramm aber keine Abläufe und kein Verhalten beschrieben. 3

4 Die einzelnen können später noch verfeinert und aufgegliedert werden. Kunde erfassen --> Name erfassen, Geburtsdatum erfassen, Rechnungs-Adresse erfassen, Liefer-Adresse erfassen, Das Use Case Diagramm beschreibt nicht, wie die Umsetzung oder Realisierung dieser geschehen soll. Zur Ablaufbeschreibung von dienen Verhaltens- oder Interaktionsdiagramme (Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, ) 4

5 Das Use Case Diagramm kann helfen, die verschiedenen benötigten Masken anzudenken. Diese werden aber nicht hier definiert. Es sollen keine Details der Benutzeroberfläche (wie z.b. eine Save-Taste, welche zum Speichern gedrückt werden soll) vorweggenommen werden. Im Zentrum steht allein der Nutzen des Systems für den Benutzer. 5

6 Ein Geschäftsanwendungsfall beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders. Aus einem fachlichen Geschäftsanwendungsfall (Ferien planen) können sich mehrere konkrete Systemanwendungsfälle ergeben (Hotelzimmer reservieren, Flug buchen, Informationsmaterial bereitstellen, ) Der Systemanwendungsfall bündelt alle möglichen Fälle (Szenarien), die eintreten können, wenn ein Akteur versucht, ein bestimmtes Ziel zu erreichen (Kundendaten erfassen, Konto eröffnen, Bestellung bearbeiten, ). Man spricht hier oft auch von einem primären Anwendungsfall. Sekundäre Anwendungsfälle sind normalerweise Teil eines anderen Systemanwendungsfalls und haben keine eigenes unabhängiges Ziel (Hilfs- Aufgaben). Der Anwendungsfall beschreibt nur sehr grob, was beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen. 6

7 Ein Akteur (actor) ist eine an verschiedenen beteiligte, aber außerhalb des zu realisierenden Systems agierende Einheit. Normalerweise ist ein Akteur ein Mensch, ein technisches System oder ein Ereignis. Akteure werden nicht personifiziert, relevant ist nur ihre Rolle in diesem Umfeld. Akteure können untereinander Generalisierungs- oder Spezialisierungs- Beziehungen haben. Akteure werden normalerweise als Strichmännchen, Zeitereignis-Akteure manchmal auch als Uhr, Fremdsystem Akteure als Würfel oder als Box gezeichnet. Akteure können eine Multiplizität haben. Diese gibt an, wie viele Akteure der angegebenen Rolle am Anwendungsfall beteiligt sein müssen (Default Wert: 1). Auf der Seite des Anwendungsfalls gibt die Multiplizität an, wie oft dieser Anwendungsfall gleichzeitig ausgeführt werden darf (Default Wert: 0..1). 7

8 Jeder Akteur und jedes Fremdsystem benötigt eine Schnittelle zum System. Bei menschlichen Akteuren braucht es ein User Interface, andernfalls muss das nötige technische Interface bestimmt werden. 8

9 Fehlen die Multiplizitätsangaben, geht man von den Default-Werten 1 beim Akteur und 0..1 beim Anwendungsfall aus. 9

10 Der enthaltene Anwendungsfall ist oft ein sekundärer Anwendungsfall (vgl. Beispiel oben). Sekundäre Anwendungsfälle werden nur indirekt, durch einen primären Anwendungsfall benutzt. Ein Systemanwendungsfall kann aber ebenfalls in einer Include Beziehung zu einem anderen Anwendungsfall stehen. Beispiel: Der Gast möchte etwas essen (und trinken) oder nur etwas trinken. 10

11 Die Erweiterung ist von einer Bedingung abhängig, diese muss angegeben werden. Die Bedingung (Erweiterungspunkt, extension point) wird als Notiz neben den Anwendungsfall geschrieben. Vorsicht! Die umgekehrte Pfeilrichtung im Diagramm gibt oft zu Fehlern Anlass. Eine andere Schreibweise erlaubt das Anbringen der Bedingungen im Use Case selber. Dies ist aber unübersichtlich und darum nicht empfehlenswert. 11

12 12

13 Die Vererbung von wird relativ selten verwendet. Häufiger findet man die Vererbung/Spezialisierung auf der Seite der Akteure, um damit die Rechte der Akteure (welche Rolle darf was) zu spezifizieren. 13

14 Jeder Anwendungsfall braucht (direkt oder indirekt) einen Akteur, welchen den Anwendungsfall anstösst. Ein Akteur darf nicht eine konkrete Person sein, sondern muss eine Rolle oder ein System repräsentieren (Customer, Consultant, Assistant, Accountant, ). Der Name des Anwendungsfalls sollte von der Art Verb Subjekt sein, also zum Beispiel create Account, send Message, print Report, Der Name des Anwendungsfalls sollte so formuliert sein, dass man ihn im der Ablaufbeschreibung direkt benutzen kann: The system has to create an account, send a message, and print a report, 14

15 Diese Auflistung ist nicht vollständig und nicht Teil von UML. Es bewährt sich, bei der Anwendungsfall Beschreibung gewisse Formalismen einzuhalten, damit nichts Wichtiges vergessen geht. Ein Auslöser ist eine äusseres Ereignis, das den Anwendungsfall auslöst (z.b. ein Gast möchte etwas Essen). Eine Vorbedingung beschreibt den Zustand des Systems, bevor der Anwendungsfall eintritt (eintreten kann). Nachbedingung, Resultat (Ergebnis) ist das, was dem Akteur geliefert wird (z.b. die Bedienung hat die Bestellung entgegen genommen). Essentielle Schritte sind die einzelnen Ablaufschritte, welche eventuell genauer mit Hilfe eines Verhaltensdiagramms (Zustandsdiagramm, Aktivitätsdiagramm, ) beschrieben werden ( Verweis auf entsprechendes Diagramm). Ausnahmen, Fehlersituationen (Anwenderfehler, fachliche Fehler, z.b. fehlende Berechtigung, Eingabedaten fehlen, ). Weitere mögliche Angaben sind: Invarianten (Bedingungen, welche stets erfüllt sind/sein müssen). Nicht funktionale Anforderungen (Plattform Voraussetzungen, qualitative/ quantitative Aussagen, Antwortzeiten, Prioritäten, Häufigkeitsschätzungen, Benutzbarkeit, Änderbarkeit, ). Eingabedaten wie ID des Gastes oder des Tisches. 15

16 Ein Use-Case Diagramm enthält zwar rudimentäres Wissen über das System und seine Akteure. Allerdings beschränkt sich die Information bei Use-Case Diagrammen hauptsächlich auf den Namen des Use-Case und die beteiligten Akteure. Für detailliertere Informationen über die Use-Cases benutzt man die Use-Case Beschreibungen. Diese werden üblicherweise in einer Tabelle aufgelistet. Der Inhalt der Use-Case Beschreibung, also die auszufüllenden Felder in der Tabelle können dabei (je nach gewünschtem/nötigem Detaillierungsgrad) variieren. Im diesem Beispiel sind die essentiellen Inhalte einer Use-Case Beschreibung enthalten. Es zeigt das empfohlene Minimum an Informationen in einer Use-Case Beschreibung (Vgl. Oestereich p ). 16

17 Es empfiehlt sich zuerst festzulegen, welche der vorhin aufgelisteten Punkte in unserer Use Case Beschreibung verwendet werden sollen. 17

18 Als Test werden für jeden Anwendungsfall sogenannte Szenarien erstellt. In diesen wird ein konkreter Vorgang (mit konkreten Werten) detailliert beschrieben, und zwar so wie der Benutzer ihn am Ende im System durchführen wird (Benutzer- Interaktion). Es kann für einen Anwendungsfall mehrere Szenarien (für alle Varianten von Abläufen) geben. Szenarien dienen dazu, den Anwendungsfall detailliert und aus verschiedenen Perspektiven zu betrachten. So wird verhindert, dass wichtige Funktionen des Systems übersehen werden. Aus den Szenarien können auch direkt die Test-Fälle für diesen Use Case abgeleitet werden. 18

19 Use Case Szenarien dienen als Grundlage für Ablauf-Tests. Falls hier alle möglichen Ablaufe genau dokumentiert sind, kann der Tester daraus die Testfälle ablesen und entsprechend implementieren/durchführen. 19

20 20

21 21

22 22

23 23

24 24

25 25