Anwendungsfalldiagramm Flashcards
1
Q
allgemein
A
- Anwendungsfälle sind Ausgangspunkt vieler objekt-orientierter Entwicklungsmethoden
- dienen zusätzlich sie oft auch als Basiskonzept, das sich über den kompletten Analyse- und Designprozess hinweg spannt
- konzentrieren sich auf das fundamentale Problem bei der Entwicklung eines Systems, der Entwicklung einer Lösung für den Kunden bzw. Anwender, die der Kunde bzw. der Anwender auch gewünscht hat
- repräsentieren die Anforderungen der Kunden
- „Ein Anwendungsfall ist eine Sequenz von Transaktionen innerhalb eines Systems, deren Aufgabe es ist, einen für den einzelnen Akteur (Anwender) identifizierbaren Nutzen zu erzeugen.“ [Ivar Jacobson]
- Transaktionen innerhalb eines Systems implizieren, dass dem Akteur eine
Reihe von Möglichkeiten geboten wird um mit dem System zu kommunizieren
und dass durch sie ein messbarer Nutzen erzeugt wird - in messbarer Nutzen impliziert, dass die Ausführung einer Transaktion eine
sichtbare, quantifizierbare und/oder qualifizierbare Auswirkung auf jene Dinge
hat, die außerhalb des Systems liegen, im speziellen auf den Akteur.
2
Q
allg. zu Akteur
A
- interagieren mit dem System im Kontext der Anwendungsfälle
- Rolle, die jemand oder etwas einnimmt und die in Beziehung zum
Geschäftsbereich steht, oder - alles, das mit dem System interagiert
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
- die Assoziation ist binär und kann Multiplizitäten aufweisen
3
Q
Beispiel: Calendarium
A
System: der Onlinekalender Calendarium
Akteur: Benutzer des Kalenders
Anwendungsfälle des Benutzers:
- Abfragen von Terminen
- Exportieren von Terminen
- Löschen von Terminen
- Ändern von Terminen
- Erfassen von Terminen
4
Q
Aktuer - Eigenschaften
A
- repräsentieren Rollen der Benutzer
- Konkrete Benutzer können gleichzeitig mehrere Rollen spielen, annehmen und ablegen
- Akteure befinden sich klar außerhalb der Systemgrenzen
- Üblicherweise werden Benutzerdaten auch innerhalb des Systems verwaltet.
- diese werden als Objekte bzw. Klassen innerhalb des Systems modelliert
5
Q
Beispiel. Kassier
A
- als Akteur am Kassenterminal
- die Rolle, in der die Person mit dem Kassensystem interagiert
- die Klasse Kassier umfasst Objekte, welche die Benutzerdaten beinhaltet (Name, SouVersNr, …)
6
Q
Akteur - Klassifikation
A
- menschlich (z.B. Anfänger, geübter Benutzer, Admin)
- nicht-menschlich (z.B. Fax-System, E-Mail-System)
- primär: Hauptnutznießer der Anwendung
- sekundär: notwendig für das Funktionieren des Systems
- aktiv: stößt selbst Anwendungsfälle an
- passiv: stößt selbst keine Anwendungsfälle an
7
Q
Anwendungsfall
A
- Anwendungsfälle beschreiben das Verhalten, das von dem entwickelnden System erwartet wird
- Identifizierung durch Sammeln von Kundenwünschen und Analyse der textuellen Problemstellung
8
Q
<> - Beziehung
A
- das Verhalten des benutzten Anwendungsfalls (includierter Anwendungsfall) wird in den benutzenden Anwendungsfall (Basis-Anwendungsfall) eingebunden:
- B ist unbedingt notwendig, um die Funktionalität von A sicher zu stellen
- B kann separat ausgeführt werden
Bsp.:
A: Termin erfassen —> <> B
B: Kalender aktualisieren
9
Q
<> - Beziehung
A
- das Verhalten von B kannin A inkludiert werden
- Somit entscheidet A, ob B ausgeführt wird
- B kann von A aktiviert werden, muss aber nicht
- A bzw. B können auch separat ausgeführt werden
- Angabe des »Wo« durch Erweiterungsstellen in A
- Angabe des »Wann« durch Bedingung in A bzw. als Teil der «extend»-Beziehung
Bsp.:
A: CD erstellen —> <> B
B: CD beschriften
10
Q
«extend» - Beziehung: Erweiterungsstellen
A
- mehrere Erweiterungsstellen (extension points) je Anwendungsfall möglich
- Namen von Erweiterungsstellen müssen:
- eindeutig sein
- nicht mit den Namen der erweiternden Anwendungsfälle übereinstimmen
Bsp.: Kaugummiautomat
- Kaugummi kaufen (extension points: Automat schütteln)
11
Q
Analogien zu Programmiersprachen
A
<>
- entspricht Unterprogrammaufruf bzw. Makroexpansion
<>
- entspricht bedingtem Unterprogrammaufruf
Genralisierung von Anwendungsfällen
- entspricht etwa dem super-Konstrukt von Java
12
Q
Generalisierung bei Anwendungsfällen
A
- B erbt das Verhalten von A und kann dieses überschreiben oder ergänzen
- B erbt alle Beziehungen von A
- B benötigt A (übernimmt Grundfunktionalität von A)
- B entscheidet, was von A ausgeführt bzw. geändert wird
- Modellierung abstrakter Anwendungsfälle möglich: {abstract}
- abstrakte Anwendungsfälle sind nicht ausführbar!
Bsp.: {abstract} Eintrag erfassen
13
Q
Generalisierung bei Akteuren
A
- Akteur A erbt von Akteur B
- A kann mit den Anwendungsfällen X und Y kommunizieren
- B kann nur mit Y kommunizieren
- Mehrfachvererbung ist erlaubt
Bsp.:
- Akteur A: Administrator — Benutzer anlegen
- Akteur B: Benutzer — Termin erfassen
- Unterscheidung, ob mehrere Akteure gemeinsam mit einem Anwendungsfall kommunizieren können oder müssen
14
Q
Identifikation von Akteuren
A
- Wer benutztdie wesentlichen Anwendungsfälle?
- Wer braucht Systemunterstützung für die tägliche Arbeit?
- 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?
15
Q
Identifikation von Anwendungsfällen
A
- nach der Identifikation der Akteure
- Trigger für Anwendungsfälle suchen
- Trigger: Ereignisse, die eintreten müssen, damit das System veranlasst
wird ein Ergebnis zu produzieren - der Aufruf des Systems erfolgt oft durch einen Akteur, der damit Akteur des Anwendungsfalles wird
- es werden folgende Trigger unterschieden: interne, externe und zeitliche
Trigger
