Anwendungsfall: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Zeile 14: Zeile 14:
ausformuliert sein. Die Beschreibung erfolgt aus der Perspektive des Benutzers.
ausformuliert sein. Die Beschreibung erfolgt aus der Perspektive des Benutzers.
Bei der Beschreibung sollen sowohl Anwendungsfälle berücksichtigt werden die das Ziel des Akteurs erreichen und auch fehlschlagen. Beim aufzeigen von Spezialfällen ist es zum besserem Verständnis wichtig pro Spezialfall ein konkretes Beispiel anzugeben.
Bei der Beschreibung sollen sowohl Anwendungsfälle berücksichtigt werden die das Ziel des Akteurs erreichen und auch fehlschlagen. Beim aufzeigen von Spezialfällen ist es zum besserem Verständnis wichtig pro Spezialfall ein konkretes Beispiel anzugeben.
== Definition (Spezifikation der „UML 2.5“, S. 637<ref name="UML 2.5">{{Quelle|UML 2.5}}</ref>) ==
== Definition (Spezifikation der „UML 2.5“, S. 637<ref name="UML 2.5">{{Quelle|OMG (2015)}}</ref>) ==
<div class="quote">
<div class="quote">
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts

Version vom 1. Juni 2017, 16:46 Uhr

Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nicht:

Korrektheit: 0
(nicht überprüft)
Umfang: 0
(viel zu gering)
Quellenangaben: 0
(fehlen vollkommen)
Quellenarten: 0
(ungenügend)
Konformität: 0
(ungenügend)

Ein Anwendungsfall, oft besser bekannt unter dem englischen Begriff Use Case, beschreibt wie sich ein System oder eine Anwendung unter bestimmten Bedingungen verhält. Er wird beschrieben um Einigung über das Verhalten und den Umfang eines Systems zwischen den Beteiligten eines Projekts zu erhalten. Die Anzahl von Anwendungsfällen ist nicht vorgeschrieben, es sollten so viele gemacht werden wie für die Anwendung notwendig ist und alles abgedeckt ist. Der einzelne Fall sollte dabei genau genug beschrieben werden um ihn konstruieren zu können, aber auch nicht zu genau, da es sonst auch zu unübersichtlich werden kann. Da das schreiben von use-cases noch in die Entwicklungsphase eines Systems gehört, ist es angebracht use-cases noch vor der eigentlichen Programmierung zu schreiben. Jeder Anwendungsfall muss ein Endziel haben und einfach, klar und verständlich als Text ausformuliert sein. Die Beschreibung erfolgt aus der Perspektive des Benutzers. Bei der Beschreibung sollen sowohl Anwendungsfälle berücksichtigt werden die das Ziel des Akteurs erreichen und auch fehlschlagen. Beim aufzeigen von Spezialfällen ist es zum besserem Verständnis wichtig pro Spezialfall ein konkretes Beispiel anzugeben.

Definition (Spezifikation der „UML 2.5“, S. 637[1])

UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.

A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

Bestandteile

Hauptbestandteile

- Szenario:

Ein Szenario beschreibt eine Folge von Aktionen unter bestimmten Bedingungen.

- Konkretes Szenario:

Beschreibt den Testfall konkreter, mit konkreten Akteuren, Werten und einem konkreten Ablauf.

- Akteure:

Der Akteur ist der Nutzer des Systems. Er gehört nicht dazu, sondern er interagiert mit ihm. Es muss sich aber nicht immer um eine Person handeln, sondern kann auch ein anderes System sein. Jeder Use Case hat nur genau einen Hauptakteur. Falls mehrere Akteure an dem Szenario beteiligt sind, wird noch einmal unterschieden in:

Primären Akteur:

Nennt den Hauptakteur des Anwendungsbeispiels.

Sekundären Akteur:

Nennt den Akteur der an zweiter Stelle steht, zum Beispiel das System mit dem der Kunde arbeitet.

- Vorbedingungen:

Zählt die Vorbedingungen auf, die erfüllt sein müssen um mit dem Programm zu arbeiten.

- Nachbedingungen im Erfolgsfall:

Gibt an was passiert und das System aus gibt wenn dieses spezielle Szenario erfolgreich abgeschlossen wurde.

- Nachbedingungen im Fehlerfall:

Beschreibt alle möglichen Fehlerfälle.

- Ablauf der Interaktion:

Es wird Schritt für Schritt beschrieben, wie die Interaktion mit dem System abläuft.


weitere Bestandteile

Wenn es nötig ist können auch noch mehr Bestandteile hinzugefügt werden, wie zum Beispiel:

- Betroffene:

Welche anderen Personen sind noch betroffen, zum Beispiel wenn die Anwendung länger benötigt als geplant.

- Risiken:

Was kann passieren wenn das System nicht so reagiert wie es soll.

- Laufzeit:

Wie lange darf oder soll eine bestimmte Anfrage dauern.

- Anzahl Benutzer:

Wenn es mehrere Benutzer des Systems gibt, muss darauf geachtet werden das es nicht überlastet.

Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.

Definition

Ein Use Case, oder auch Anwendungsfall, ist eine Darstellung einer Interaktion zwischen einem Anwender und einem System. Es soll den Beteiligten an einem Softwareprojekt einen ersten Eindruck über die Funktionalität des Systems geben, welches entwickelt werden soll. Dabei wird durch das Use Case Diagramm die Funktion des Systems als auch die der Benutzergruppen, Akteure, klar dargestellt. Auf Grund des hohen Abstraktionsgrades wird sichergestellt, dass nicht nur Experten (meist Informatiker und Systemarchitekten) verstehen können, um was es sich bei dem System handelt, sondern auch Laien, wie z.B. Manager, Designer, spätere Benutzer.

Aufbau

Um einen Anwendungsfall aufzubauen, gibt es die Möglichkeit, zunächst alle wichtigen Bestandteile des Diagramms zu notieren

Ziel: Welches Ziel soll das der Benutzer mit dem System erreichen?

Kontext: Was ist das überhaupt für ein System?

Einschränkungen: Gibt es Aufgaben, die das System selbst nicht ausführt? Ausführung durch externe Atkeure?

Primärer Akteur: In der Regel der Benutzer

Sekundärer Akteur: Systeme oder Akteure die nicht Bestandteil des eigentlichen Systems sind.

Betroffene: Gibt es Akteure, die durch die Funktionen des Systems betroffen sind?

Vorbedingungen: Welche Bedingungen müssen gegeben sein, damit dieser Anwendungsfall möglich ist?

Nachbedingung im Erfolgsfall: Was passiert wenn der Anwendungsfall erfolgreich durchgeführt wurde?

Nachbedingung im Fehlerfall: Was passiert wenn Fehler auftreten? Exceptionhandling.

Zuletzt kann der eigentliche Ablauf, in grafischer oder schriftlicher Form dargestellt werden.

Typische Fehler

Use-Cases: Akteure und Aktionen
 
Falsch Richtig Use-Cases 1.png
Use-Cases: Include und Extend
 
Falsch Richtig Use-Cases 2.png
Use-Cases: Vererbung
 
Falsch Richtig Use-Cases 3.png

Quellen

  1. OMG (UML 2.5): Object Management Group; OMG Unified Modeling Language – Version 2.5; http://www.omg.org/spec/UML/2.5; 2015; Quellengüte: 5 (Web)