Untitled
Werbung
1 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. Use Cases 2 Es werden mit dem Use Case Diagramm aber keine Abläufe und kein Verhalten beschrieben. Use Cases 3 Die einzelnen Use Cases 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 Use Cases geschehen soll. Zur Ablaufbeschreibung von Use Cases dienen Verhaltens- oder Interaktionsdiagramme (Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, …) Use Cases 4 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. Use Cases 5 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 (HilfsAufgaben). Der Anwendungsfall beschreibt nur sehr grob, was beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen. Use Cases 6 Ein Akteur (actor) ist eine an verschiedenen Use Cases 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 SpezialisierungsBeziehungen 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). Use Cases 7 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. Use Cases 8 Fehlen die Multiplizitätsangaben, geht man von den Default-Werten 1 beim Akteur und 0..1 beim Anwendungsfall aus. Use Cases 9 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. Use Cases 10 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. Use Cases 11 Eine Generalisierung oder Vererbung (engl. Generalization) kann in Anwendungsfalldiagrammen zwischen Akteuren oder Anwendungsfällen modelliert werden und definiert eine Beziehung zwischen einem spezifischen (spezialisierten) und einem allgemeinen (abstrakten) Element. Use Cases 12 Die Vererbung von Use Cases 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. Use Cases 13 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“, Use Cases 14 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. Use Cases 15 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. Use Cases 16 Es empfiehlt sich zuerst festzulegen, welche der vorhin aufgelisteten Punkte in unserer Use Case Beschreibung verwendet werden sollen. Use Cases 17 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 (BenutzerInteraktion). 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. Use Cases 18 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. Use Cases 19 20 Use Cases 21 Use Cases 22 Use Cases 23 Use Cases 24 Use Cases 25
