Anwendungsfalldiagramm: Unterschied zwischen den Versionen

Zeile 1:

== Einführung ==

Die '''Unified Modeling Language''' (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte grafische Modellierungssprache zur ~~Beschreibung~~ von ~~Anforderungen~~ und ~~Softwarearchitekturen~~. ~~Das~~ '''~~Anwendungsfalldiagramm~~''' (~~häufig~~ auch ''Use-Case-~~Diagramm~~'' genannt) ~~ist ein elementares Verhaltensdiagramm~~ der ~~UML~~.

Die '''Unified Modeling Language''' (Vereinheitlichte Modellierungssprache), kurz '''UML''', ist eine standardisierte, grafische Modellierungssprache zur Spezifikation, zum Entwurf und zur Dokumentation von Software- und anderen Systemen. Innerhalb der UML gehören '''Anwendungsfalndiagramme''' (auch ''Use-Case-Diagramme'' genannt) zu den Verhaltensdiagrammen. Sie beschreiben das erwartete Verhalten eines Systems aus der Perspektive eines externen Beobachters (Benutzers) heraus, ohne technische Implementierungsdetails offenzulegen.

~~Ziel des Anwendungsfalldiagramms ist es, in~~ der Analysephase die Anforderungen des Auftraggebers ~~aus fachlicher Sicht für alle Beteiligten verständlich~~, übersichtlich und vollständig zu ~~modellieren~~. ~~Es dient als zentrales~~ Kommunikationsmittel~~, um~~ zwischen potenziellen Anwendern, Auftraggebern und Auftragnehmern ~~zu vermitteln~~. Als strukturierte Anforderungsbeschreibung ~~können Anwendungsfalldiagramme~~ direkt in das ~~Lastenheft mit aufgenommen werden~~.

=== Zielsetzung im Software-Lebenszyklus ===

In der Analysephase eines Softwareprojekts dienen Anwendungsfalldiagramme dazu, die funktionalen Anforderungen des Auftraggebers strukturiert, übersichtlich und vollständig zu erfassen. Sie erfüllen dabei eine essenzielle Brückenfunktion:

* '''Kommunikationsmittel:''' Sie vermitteln barrierefrei zwischen fachlichen Laien (potenziellen Anwendern, Auftraggebern) und dem technischen Entwicklungsteam (Auftragnehmern).

* '''Anforderungsdokumentation:''' Als strukturierte und visuelle Anforderungsbeschreibung sind sie ein fundamentaler Bestandteil des '''Lastenhefts''' (was das System tun soll) und fließen direkt in das '''Pflichtenheft''' ein.

~~Das Diagramm besteht aus~~ drei ~~wesentlichen Elementen~~:<ref>Heide Balzer: ''Lehrbuch der Objektmodellierung - Analyse und Entwurf'', Spektrum Akademischer Verlag, S. 62 ff.</ref>

=== Die drei Kernelemente ===

* '''Akteure (~~engl. ''actors''~~):''' ~~Potentielle Benutzer oder~~ externe Systeme~~, die mit der Software interagieren~~.

Ein Anwendungsfalndiagramm lässt sich auf drei wesentliche Säulen reduzieren:<ref>Heide Balzer: ''Lehrbuch der Objektmodellierung - Analyse und Entwurf'', Spektrum Akademischer Verlag, S. 62 ff.</ref>

* '''Anwendungsfälle (~~engl. ''use cases''~~):''' ~~Aufgaben, die für den Anwender ein Ergebnis von messbarem Wert erzeugen und bei deren Lösung das~~ System ~~hilft.~~

# '''Akteure (Actors):''' Wer interagiert mit dem System? (Sowohl Personen als auch externe Systeme).

* '''Beziehungen (~~engl. ''relations''~~):''' ~~Verbindungen zwischen Akteuren~~ und ~~Anwendungsfällen~~ oder ~~zwischen Anwendungsfällen~~ untereinander.

# '''Anwendungsfälle (Use Cases):''' Was kann mit dem System getan werden? Welche Ziele werden erreicht?

# '''Beziehungen (Relations):''' Wie interagieren Akteure und Anwendungsfälle miteinander oder wie hängen Anwendungsfälle untereinander zusammen?

''Hinweis:'' ~~Der detaillierte~~, ~~prozessuale Ablauf~~ von ~~Anwendungsfällen~~ wird ~~in der UML typischerweise nicht hier, sondern in einem intern verlinkten~~ [[Aktivitätendiagramm]] ~~abgebildet~~.

''Hinweis zur Abgrenzung:'' Ein Use-Case-Diagramm zeigt '''nicht''', in welcher zeitlichen oder logischen Reihenfolge Prozesse ablaufen. Für die Modellierung von detaillierten, prozessualen Abläufen und Kontrollflüssen wird stattdessen das [[Aktivitätendiagramm]] verwendet.

== Notation und Aufbau ==

== Systematische Notation und Aufbau ==

~~Der systematische Aufbau~~ eines ~~Anwendungsfalldiagramms~~ folgt ~~in der Regel diesen drei Schritten~~:

Die Erstellung eines normkonformen Diagramms folgt einem klaren, dreistufigen iterativen Prozess:

# '''~~Akteure identifizieren~~:''' ~~Zuerst wird geklärt, welche unterschiedlichen Akteure das zu erstellende System nutzen werden. Akteure werden grafisch~~ als ~~„Strichmännchen“ dargestellt. Dies können Personen~~ (~~Kunden, Mitarbeiter, Administratoren~~) oder ~~angrenzende Software-Systeme sein. Jeder Akteur muss einen aussagekräftigen, selbsterklärenden Namen erhalten~~ (~~allgemeine Bezeichnungen wie „User“ sind zu vermeiden, da sie~~ für ~~jede~~ Software ~~gelten~~).

=== 1. Akteure identifizieren (Actors) ===

# '''~~Anwendungsfälle definieren~~:''' ~~Im zweiten Schritt wird festgelegt~~, ~~welche Aufgaben die Software erfüllen soll~~. ~~Anwendungsfälle werden als Ellipsen dargestellt und enthalten eine kurze, inhaltliche Beschreibung~~. ~~Die Formulierung sollte knapp, aber verständlich sein und bevorzugt im Format~~ ''~~Subjekt-Prädikat-Objekt~~'' ~~formuliert werden.~~

Akteure stellen Rollen dar, die außerhalb des betrachteten Systems liegen, aber mit diesem interagieren.

# '''~~Beziehungen herstellen:~~''' ~~Erst im letzten Schritt werden Akteure und Anwendungsfälle durch Linien miteinander verbunden~~, ~~um die konkrete Interaktion~~ zu ~~modellieren~~.

* '''Darstellung:''' Grafisch als klassisches Strichmännchen (für menschliche Rollen) oder als Rechteck mit dem Stereotyp <code>«system»</code> (für externe Software/Hardware).

* '''Namensgebung:''' Akteure müssen präzise, selbsterklärende Substantive sein (z. B. ''Kunde'', ''Systemadministrator'', ''Buchhaltungssystem''). Generische Bezeichnungen wie „User“, „Benutzer“ oder „Akteur“ sind strikt zu vermeiden, da sie keine differenzierte Rolle beschreiben.

== ~~Beziehungen~~ (~~Relationen~~) ==

=== 2. Anwendungsfälle definieren (Use Cases) ===

~~Beziehungen bilden~~ die ~~Interaktionen~~ und ~~Abhängigkeiten innerhalb des Systems ab~~.

Ein Anwendungsfall beschreibt eine Sequenz von Interaktionen, die für den Akteur ein Ergebnis von messbarem, fachlichem Wert liefert.

* '''Darstellung:''' Als horizontale Ellipse, in deren Zentrum die Beschreibung steht.

* '''Namensgebung:''' Die Formulierung erfolgt kurz, prägnant, im Infinitiv und folgt der sprachlichen Struktur: '''Subjekt-Objekt-Prädikat''' (z. B. ''Artikel in Warenkorb legen'', ''Passwort zurücksetzen'').

~~{| class~~="~~wikitable~~"

=== 3. Beziehungen verknüpfen (Relations) ===

|-

Akteure und Anwendungsfälle werden über Beziehungslinien verknüpft, um Interaktionskanäle aufzuzeigen. Das gesamte System wird optional durch einen rechteckigen '''Systemrahmen (System Boundary)''' umschlossen, welcher die Systemgrenze markiert: Akteure stehen außerhalb, Use Cases innerhalb des Rahmens.

~~! Beziehungstyp~~

~~! Notation~~

<html>

~~! Beschreibung~~

|-

| '''Ungerichtete Assoziation'''

<text x="190" y="40" font-family="Arial, sans-serif" font-size="14" font-weight="bold" fill="#222222">Systemgrenze (z.B. Webshop)</text>

~~| Durchgehende~~ Linie

~~| Verbindet Akteure~~ mit ~~Anwendungsfällen~~. Sie ~~drückt aus, dass~~ der ~~User~~ die ~~Aktion ausführen~~ kann und mit dem ~~System interagiert~~. Ein ~~Anwendungsfall darf~~ mit ~~mehreren~~ Akteuren ~~verbunden sein~~ und ~~umgekehrt~~. Eine ~~binäre Assoziation verbindet~~ immer ~~genau zwei Elemente~~. ~~Dies~~ ist die ~~offenste Form der Darstellung.~~

<text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Kunde</text>

</g>

<text x="175" y="110" font-family="Arial, sans-serif" font-size="12" fill="#555555" text-anchor="middle">Assoziation</text>

<text x="140" y="44" font-family="Arial, sans-serif" font-size="14" text-anchor="middle" font-weight="bold" fill="#222222">Artikel suchen</text>

</g>

</svg>

</html>

== Detaillierte Typisierung von Beziehungen ==

=== 1. Assoziationen (Akteur ↔ Use Case) ===

Assoziationen bilden das Fundament der Kommunikation zwischen Akteur und System. Es handelt sich um eine binäre Beziehung (verbindet genau zwei Elemente).

* '''Ungerichtete Assoziation:''' Eine einfache, durchgehende Linie. Sie signalisiert einen bidirektionalen Informationsfluss. Der Akteur interagiert mit dem Use Case, lässt jedoch offen, wer die Interaktion gestartet hat.

* '''Gerichtete Assoziation:''' Eine Linie mit einer offenen Pfeilspitze. Der Pfeil zeigt auf den Initiator des Datenflusses bzw. der Aktion:

** Pfeil zeigt zum ''Use Case'': Der Akteur initiiert den Anwendungsfall aktiv.

** Pfeil zeigt zum ''Akteur'': Der Anwendungsfall stößt eine Aktion beim Akteur an (häufig bei sekundären, externen Systemen wie z. B. Benachrichtigungsdiensten).

=== 2. Multiplizitäten ===

Multiplizitäten (Kardinalitäten) geben an, wie viele Instanzen eines Akteurs zeitgleich mit wie vielen Instanzen eines Anwendungsfalls interagieren können. Sie werden direkt an die Enden der Assoziationslinien geschrieben.

==== Praxisbeispiel: Das Tischtennis-Rundlaufspiel ====

Um die Logik von Multiplizitäten zu verdeutlichen, betrachten wir das Regelwerk eines Tischtennis-Rundlaufs:

* An einem Rundlauf-Spiel müssen '''mindestens 3 Spielerinnen''' teilnehmen, nach oben hin gibt es keine Grenze (<code>3..*</code>). Jede einzelne Spielerin nimmt jedoch zu einem Zeitpunkt an '''exakt 1''' Rundlauf-Spiel teil (<code>1</code>).

* Ein Spiel kann völlig ohne oder mit unbegrenzt vielen Schiedsrichterinnen stattfinden (<code>0..*</code>). Eine Schiedsrichterin kann maximal '''an höchstens 1''' Spiel gleichzeitig als Offizielle zugewiesen sein (<code>0..1</code>).

<html>

<text x="110" y="44" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Am Rundlauf-Spiel</text>

<text x="110" y="60" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">teilnehmen</text>

</g>

<text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Spielerin</text>

</g>

<text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Schiedsrichterin</text>

</g>

</svg>

</html>

''Hinweis für die Praxis:'' Da Multiplizitäten Use-Case-Diagramme schnell visuell überladen und für fachliche Auftraggeber oft sekundär sind, werden sie in dieser Diagrammart selten notiert. Ihre fundamentale Bedeutung entfalten sie im [[Klassendiagramm]].

=== 3. Include-Beziehungen (Abhängigkeiten) ===

Die <code>«include»</code>-Beziehung beschreibt eine zwingende Abhängigkeit (Einschluss). Wenn ein Basis-Anwendungsfall ausgeführt wird, '''muss''' der inkludierte Anwendungsfall zwingend ebenfalls ausgeführt werden. Sie dient dem Aufbrechen komplexer Use Cases und der Wiederverwendung von Funktionalitäten.

* '''Pfeilrichtung:''' Der gestrichelte Pfeil startet beim ''Basis-Use-Case'' und zeigt '''auf den inkludierten''' Use Case.

* '''Stereotyp:''' Die Beziehungslinie muss zwingend mit dem Schlüsselwort <code>«include»</code> gekennzeichnet werden.

<html>

<text x="110" y="44" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Bestellung aufgeben</text>

</g>

<g>

<text x="320" y="55" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">«include»</text>

</g>

<text x="110" y="44" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Identität prüfen</text>

</g>

</svg>

</html>

=== 4. Extend-Beziehungen (Erweiterungen) ===

Die <code>«extend»</code>-Beziehung modelliert ein '''optionales''' Verhalten. Der erweiternde Use Case wird nur unter präzise definierten Rahmenbedingungen ausgeführt.

* '''Pfeilrichtung:''' Der gestrichelte Pfeil verhält sich umgekehrt zur Include-Beziehung: Er startet beim ''erweiternden (optionalen) Use Case'' und zeigt '''auf den Basis-Use-Case'''.

* '''Stereotyp:''' Kennzeichnung erfolgt über das Schlüsselwort <code>«extend»</code>.

* '''Erweiterungspunkte (Extension Points):''' Im Basis-Use-Case wird unter einer horizontalen Trennlinie via <code>extension points</code> definiert, an welcher Stelle die Erweiterung eingreift.

* '''Bedingung (Condition):''' Ein umschließendes Notizfeld (als Notizzettel dargestellt) definiert die logische Bedingung. Es wird mit einer fein gestrichelten Linie an die Extend-Beziehung geheftet.

<html>

<text x="120" y="40" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Konto einrichten</text>

<text x="120" y="68" font-family="Arial, sans-serif" font-size="11" font-style="italic" text-anchor="middle" fill="#555555">extension points:</text>

<text x="120" y="82" font-family="Arial, sans-serif" font-size="11" text-anchor="middle" fill="#222222">Premium-Option</text>

</g>

<g>

<text x="350" y="135" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">«extend»</text>

</g>

<text x="110" y="48" font-family="Arial, sans-serif" font-size="12" font-weight="bold" text-anchor="middle" fill="#222222">Premium-Features</text>

<text x="110" y="64" font-family="Arial, sans-serif" font-size="12" font-weight="bold" text-anchor="middle" fill="#222222">auswählen</text>

</g>

<text x="10" y="20" font-family="Arial, sans-serif" font-size="11" font-weight="bold" fill="#222222">Condition: {Nutzer wählt</text>

<text x="10" y="35" font-family="Arial, sans-serif" font-size="11" font-weight="bold" fill="#222222">Premium-Abonnement}</text>

<text x="10" y="50" font-family="Arial, sans-serif" font-size="11" fill="#555555">Extension Point: Premium-Option</text>

</g>

</svg>

</html>

=== 5. Generalisierung (Vererbung / Spezialisierung) ===

Eine Generalisierungsbeziehung spiegelt das klassische Konzept der Vererbung (OOP) wider. Sie kann sowohl zwischen zwei Akteuren als auch zwischen zwei Anwendungsfällen existieren. Das spezialisierte Element erbt alle Eigenschaften, Attribute und Verhaltensweisen des allgemeinen Elements und konkretisiert diese.

* '''Darstellung:''' Eine durchgehende Linie mit einer '''großen, leeren und geschlossenen Pfeilspitze'''.

* '''Pfeilrichtung:''' Der Pfeil zeigt immer '''vom spezifischen (Unterklasse) zum allgemeinen (Oberklasse)''' Element.

==== Praxisbeispiel: Nutzerhierarchie ====

Ein ''Fahrer'' ist eine explizite Spezialisierung des allgemeinen ''Anwenders''. Der Fahrer besitzt implizit jede Eigenschaft des Standard-Anwenders (wie Stammdaten: Vorname, Nachname, Username) und erbt dessen Fähigkeit, den Use Case ''Login durchführen'' aufzurufen, ohne dass dies redundant gezeichnet werden muss.

<html>

<text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Anwender</text>

</g>

<text x="80" y="39" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Login durchführen</text>

</g>

<g>

<text x="85" y="185" font-family="Arial, sans-serif" font-size="12" font-style="italic" fill="#555555">Generalisierung</text>

</g>

<text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Fahrer</text>

</g>

</svg>

</html>

== Zusammenfassende Gegenüberstellung für die Klausur / Praxis ==

{| class="wikitable" style="width:100%; border:1px solid #aaa;"

|- style="background:#eeeeee;"

! Beziehungstyp !! Notation im Diagramm !! Semantik (Bedeutung) !! Typischer Anwendungsfall

|-

| '''~~Gerichtete~~ Assoziation'''

| '''Assoziation''' || Durchgehende Linie || Kommunikationspfad || Verknüpft primäre Akteure mit Kernfunktionen.

| Durchgehende Linie mit ~~Pfeil~~

| Gibt die Initiierungsrichtung an. Ein Pfeil zum Anwendungsfall bedeutet, dass nur der Akteur die Aktion initiieren kann. Ein Pfeil zum Akteur besagt, dass das System die Aktion anstößt. Können beide Seiten initiieren, wird auf Pfeile komplett verzichtet.

|-

| '''Include~~-Beziehung~~'''~~<br/>(dt. ''beinhalten'')~~

| '''Include''' || Gestrichelte Linie + Pfeil zum Ziel + <code>«include»</code> || Zwingende Ausführung (100% Pflicht) || Auslagerung von wiederkehrenden Funktionen wie Login oder Validierung.

| Gestrichelte Linie ~~mit~~ Pfeil zum ~~inkludierten Anwendungsfall und Schlüsselwort~~ <code>~~<<include>>~~</code>

| ~~Gibt an, dass der Basis-Anwendungsfall das Verhalten des inkludierten Anwendungsfalls zwingend mitbenutzt und immer ausführt~~.

|-

| '''Extend~~-Beziehung~~'''~~<br/>(dt. ''erweitern'')~~

| '''Extend''' || Gestrichelte Linie + Pfeil zur Basis + <code>«extend»</code> || Optionale Ausführung (0-100% je nach Bedingung) || Modellierung von Ausnahmefällen, Fehlermeldungen oder optionalen Zusatzfunktionen.

| Gestrichelte Linie ~~mit~~ Pfeil ~~zum~~ Basis~~-Anwendungsfall und Schlüsselwort~~ <code>~~<<extend>>~~</code>

| ~~Gibt an~~, ~~dass ein Anwendungsfall optional ist und den Basis-Anwendungsfall nur unter bestimmten Bedingungen erweitert~~.

|-

| '''Generalisierung'''~~<br/>~~(Vererbung)

| '''Generalisierung''' || Linie + geschlossene, leere Pfeilspitze || "Ist-ein"-Beziehung (Vererbung) || Abbildung von Benutzer-Rollenstrukturen (Rechtehierarchien).

| ~~Durchgehende Linie mit hohlem, geschlossenem Pfeil~~

| ~~Zeigt an, dass ein spezialisierter Anwendungsfall~~ (~~oder Akteur~~) alle Bestandteile des allgemeinen übernimmt und diese konkretisiert oder erweitert. Beispiel: Der Akteur ''Fahrer'' ist eine Spezialisierung des Akteurs ''Anwender'' und erbt dessen Attribute wie Vorname, Nachname und die Befähigung zum Login.

|}

~~=== Detaillierte Betrachtung spezifischer Konzepte ===~~

~~==== Multiplizitäten ====~~

~~Multiplizitäten geben an, wie viele Instanzen eines Akteurs mit wie vielen Anwendungsfällen in Beziehung stehen. Sie werden direkt an gerichteten oder ungerichteten Assoziationen notiert.~~

~~'''Pädagogisches Beispiel (Tischtennis-Rundlauf):'''~~

* An einem Tischtennis-Rundlauf sind mindestens 3 Spielerinnen beteiligt. Die Untergrenze ist <code>3</code>, die Obergrenze ist <code>*</code> (beliebig viele). Notation: <code>3..*</code>

* Jede Spielerin kann jedoch exakt an einem Rundlauf-Spiel teilnehmen. Ober- und Untergrenze sind exakt 1. Notation: <code>1</code>

* An einem Spiel können keine oder beliebig viele Schiedsrichterinnen beteiligt sein. Notation: <code>0..*</code>

* Jede Schiedsrichterin kann an höchstens einem Spiel beteiligt sein. Notation: <code>0..1</code>

''Anmerkung:'' Da diese feingranularen Informationen für die Adressaten des Use-Case-Diagramms häufig keine Rolle spielen, werden Multiplizitäten hier eher selten notiert. Eine weitaus wichtigere Rolle spielen sie beim [[Klassendiagramm]].

~~==== Erweiterungspunkte (Extension Points) und Bedingungen (Conditions) ====~~

~~Bei der optionalen '''Extend-Beziehung''' bestimmt der Basis-Anwendungsfall sogenannte Erweiterungspunkte (''Extension Points'').~~

* '''Extension Points:''' Sie geben den präzisen Ort innerhalb des Basis-Anwendungsfalls an, an dem Extensions hinzugefügt werden dürfen. Zur Darstellung wird innerhalb der Ellipse eine horizontale Linie gezogen. Darunter steht das Schlüsselwort <code>extension points</code>, gefolgt vom Namen des Erweiterungspunktes.

* '''Bedingung (Condition):''' Optional kann eine Bedingung hinzugefügt werden, die beschreibt, unter welchen Voraussetzungen der Extend-Use-Case ausgeführt wird. Die Bedingung wird als Notizzettel-Symbol dargestellt, das das Schlüsselwort <code>Condition</code> enthält. Darunter steht die Bedingung in geschweiften Klammern und der bezogene Erweiterungspunkt. Dieses Symbol ist über eine gestrichelte Linie mit der Extend-Anweisung verbunden.

[[Kategorie:Modellierung]]

[[Kategorie:FI_I_SDM]]

[[Kategorie:AHR_I_Informatik LK]]

@@ Zeile 1: / Zeile 1: @@
 == Einführung ==
-Die '''Unified Modeling Language''' (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte grafische Modellierungssprache zur Beschreibung von Anforderungen und Softwarearchitekturen. Das '''Anwendungsfalldiagramm''' (häufig auch ''Use-Case-Diagramm'' genannt) ist ein elementares Verhaltensdiagramm der UML.
+Die '''Unified Modeling Language''' (Vereinheitlichte Modellierungssprache), kurz '''UML''', ist eine standardisierte, grafische Modellierungssprache zur Spezifikation, zum Entwurf und zur Dokumentation von Software- und anderen Systemen. Innerhalb der UML gehören '''Anwendungsfalndiagramme''' (auch ''Use-Case-Diagramme'' genannt) zu den Verhaltensdiagrammen. Sie beschreiben das erwartete Verhalten eines Systems aus der Perspektive eines externen Beobachters (Benutzers) heraus, ohne technische Implementierungsdetails offenzulegen.
-Ziel des Anwendungsfalldiagramms ist es, in der Analysephase die Anforderungen des Auftraggebers aus fachlicher Sicht für alle Beteiligten verständlich, übersichtlich und vollständig zu modellieren. Es dient als zentrales Kommunikationsmittel, um zwischen potenziellen Anwendern, Auftraggebern und Auftragnehmern zu vermitteln. Als strukturierte Anforderungsbeschreibung können Anwendungsfalldiagramme direkt in das Lastenheft mit aufgenommen werden.
+=== Zielsetzung im Software-Lebenszyklus ===
+In der Analysephase eines Softwareprojekts dienen Anwendungsfalldiagramme dazu, die funktionalen Anforderungen des Auftraggebers strukturiert, übersichtlich und vollständig zu erfassen. Sie erfüllen dabei eine essenzielle Brückenfunktion:
+* '''Kommunikationsmittel:''' Sie vermitteln barrierefrei zwischen fachlichen Laien (potenziellen Anwendern, Auftraggebern) und dem technischen Entwicklungsteam (Auftragnehmern).
+* '''Anforderungsdokumentation:''' Als strukturierte und visuelle Anforderungsbeschreibung sind sie ein fundamentaler Bestandteil des '''Lastenhefts''' (was das System tun soll) und fließen direkt in das '''Pflichtenheft''' ein.
-Das Diagramm besteht aus drei wesentlichen Elementen:<ref>Heide Balzer: ''Lehrbuch der Objektmodellierung - Analyse und Entwurf'', Spektrum Akademischer Verlag, S. 62 ff.</ref>
+=== Die drei Kernelemente ===
-* '''Akteure (engl. ''actors''):''' Potentielle Benutzer oder externe Systeme, die mit der Software interagieren.
+Ein Anwendungsfalndiagramm lässt sich auf drei wesentliche Säulen reduzieren:<ref>Heide Balzer: ''Lehrbuch der Objektmodellierung - Analyse und Entwurf'', Spektrum Akademischer Verlag, S. 62 ff.</ref>
-* '''Anwendungsfälle (engl. ''use cases''):''' Aufgaben, die für den Anwender ein Ergebnis von messbarem Wert erzeugen und bei deren Lösung das System hilft.
+# '''Akteure (Actors):''' Wer interagiert mit dem System? (Sowohl Personen als auch externe Systeme).
-* '''Beziehungen (engl. ''relations''):''' Verbindungen zwischen Akteuren und Anwendungsfällen oder zwischen Anwendungsfällen untereinander.
+# '''Anwendungsfälle (Use Cases):''' Was kann mit dem System getan werden? Welche Ziele werden erreicht?
+# '''Beziehungen (Relations):''' Wie interagieren Akteure und Anwendungsfälle miteinander oder wie hängen Anwendungsfälle untereinander zusammen?
-''Hinweis:'' Der detaillierte, prozessuale Ablauf von Anwendungsfällen wird in der UML typischerweise nicht hier, sondern in einem intern verlinkten [[Aktivitätendiagramm]] abgebildet.
+''Hinweis zur Abgrenzung:'' Ein Use-Case-Diagramm zeigt '''nicht''', in welcher zeitlichen oder logischen Reihenfolge Prozesse ablaufen. Für die Modellierung von detaillierten, prozessualen Abläufen und Kontrollflüssen wird stattdessen das [[Aktivitätendiagramm]] verwendet.
-== Notation und Aufbau ==
+== Systematische Notation und Aufbau ==
-Der systematische Aufbau eines Anwendungsfalldiagramms folgt in der Regel diesen drei Schritten:
+Die Erstellung eines normkonformen Diagramms folgt einem klaren, dreistufigen iterativen Prozess:
-# '''Akteure identifizieren:''' Zuerst wird geklärt, welche unterschiedlichen Akteure das zu erstellende System nutzen werden. Akteure werden grafisch als „Strichmännchen“ dargestellt. Dies können Personen (Kunden, Mitarbeiter, Administratoren) oder angrenzende Software-Systeme sein. Jeder Akteur muss einen aussagekräftigen, selbsterklärenden Namen erhalten (allgemeine Bezeichnungen wie „User“ sind zu vermeiden, da sie für jede Software gelten).
+=== 1. Akteure identifizieren (Actors) ===
-# '''Anwendungsfälle definieren:''' Im zweiten Schritt wird festgelegt, welche Aufgaben die Software erfüllen soll. Anwendungsfälle werden als Ellipsen dargestellt und enthalten eine kurze, inhaltliche Beschreibung. Die Formulierung sollte knapp, aber verständlich sein und bevorzugt im Format ''Subjekt-Prädikat-Objekt'' formuliert werden.
+Akteure stellen Rollen dar, die außerhalb des betrachteten Systems liegen, aber mit diesem interagieren.
-# '''Beziehungen herstellen:''' Erst im letzten Schritt werden Akteure und Anwendungsfälle durch Linien miteinander verbunden, um die konkrete Interaktion zu modellieren.
+* '''Darstellung:''' Grafisch als klassisches Strichmännchen (für menschliche Rollen) oder als Rechteck mit dem Stereotyp <code>«system»</code> (für externe Software/Hardware).
+* '''Namensgebung:''' Akteure müssen präzise, selbsterklärende Substantive sein (z. B. ''Kunde'', ''Systemadministrator'', ''Buchhaltungssystem''). Generische Bezeichnungen wie „User“, „Benutzer“ oder „Akteur“ sind strikt zu vermeiden, da sie keine differenzierte Rolle beschreiben.
-== Beziehungen (Relationen) ==
+=== 2. Anwendungsfälle definieren (Use Cases) ===
-Beziehungen bilden die Interaktionen und Abhängigkeiten innerhalb des Systems ab.
+Ein Anwendungsfall beschreibt eine Sequenz von Interaktionen, die für den Akteur ein Ergebnis von messbarem, fachlichem Wert liefert.
+* '''Darstellung:''' Als horizontale Ellipse, in deren Zentrum die Beschreibung steht.
+* '''Namensgebung:''' Die Formulierung erfolgt kurz, prägnant, im Infinitiv und folgt der sprachlichen Struktur: '''Subjekt-Objekt-Prädikat''' (z. B. ''Artikel in Warenkorb legen'', ''Passwort zurücksetzen'').
-{| class="wikitable"
+=== 3. Beziehungen verknüpfen (Relations) ===
-|-
+Akteure und Anwendungsfälle werden über Beziehungslinien verknüpft, um Interaktionskanäle aufzuzeigen. Das gesamte System wird optional durch einen rechteckigen '''Systemrahmen (System Boundary)''' umschlossen, welcher die Systemgrenze markiert: Akteure stehen außerhalb, Use Cases innerhalb des Rahmens.
-! Beziehungstyp
-! Notation
+<html>
-! Beschreibung
+<svg width="600" height="220" viewBox="0 0 600 220" xmlns="http://www.w3.org/2000/svg" style="background-color: transparent;">
-|-
+  <rect x="180" y="20" width="380" height="180" rx="5" fill="none" stroke="#222222" stroke-width="2" />
-| '''Ungerichtete Assoziation'''
+  <text x="190" y="40" font-family="Arial, sans-serif" font-size="14" font-weight="bold" fill="#222222">Systemgrenze (z.B. Webshop)</text>
-| Durchgehende Linie
-| Verbindet Akteure mit Anwendungsfällen. Sie drückt aus, dass der User die Aktion ausführen kann und mit dem System interagiert. Ein Anwendungsfall darf mit mehreren Akteuren verbunden sein und umgekehrt. Eine binäre Assoziation verbindet immer genau zwei Elemente. Dies ist die offenste Form der Darstellung.
+  <g transform="translate(50, 60)">
+    <circle cx="30" cy="20" r="15" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="35" x2="30" y2="75" stroke="#222222" stroke-width="2"/>
+    <line x1="10" y1="50" x2="50" y2="50" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="10" y2="105" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="50" y2="105" stroke="#222222" stroke-width="2"/>
+    <text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Kunde</text>
+  </g>
+  <line x1="110" y1="120" x2="240" y2="120" stroke="#222222" stroke-width="2" />
+  <text x="175" y="110" font-family="Arial, sans-serif" font-size="12" fill="#555555" text-anchor="middle">Assoziation</text>
+  <g transform="translate(240, 80)">
+    <ellipse cx="140" cy="40" rx="120" ry="35" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="140" y="44" font-family="Arial, sans-serif" font-size="14" text-anchor="middle" font-weight="bold" fill="#222222">Artikel suchen</text>
+  </g>
+</svg>
+</html>
+== Detaillierte Typisierung von Beziehungen ==
+=== 1. Assoziationen (Akteur ↔ Use Case) ===
+Assoziationen bilden das Fundament der Kommunikation zwischen Akteur und System. Es handelt sich um eine binäre Beziehung (verbindet genau zwei Elemente).
+* '''Ungerichtete Assoziation:''' Eine einfache, durchgehende Linie. Sie signalisiert einen bidirektionalen Informationsfluss. Der Akteur interagiert mit dem Use Case, lässt jedoch offen, wer die Interaktion gestartet hat.
+* '''Gerichtete Assoziation:''' Eine Linie mit einer offenen Pfeilspitze. Der Pfeil zeigt auf den Initiator des Datenflusses bzw. der Aktion:
+** Pfeil zeigt zum ''Use Case'': Der Akteur initiiert den Anwendungsfall aktiv.
+** Pfeil zeigt zum ''Akteur'': Der Anwendungsfall stößt eine Aktion beim Akteur an (häufig bei sekundären, externen Systemen wie z. B. Benachrichtigungsdiensten).
+=== 2. Multiplizitäten ===
+Multiplizitäten (Kardinalitäten) geben an, wie viele Instanzen eines Akteurs zeitgleich mit wie vielen Instanzen eines Anwendungsfalls interagieren können. Sie werden direkt an die Enden der Assoziationslinien geschrieben.
+==== Praxisbeispiel: Das Tischtennis-Rundlaufspiel ====
+Um die Logik von Multiplizitäten zu verdeutlichen, betrachten wir das Regelwerk eines Tischtennis-Rundlaufs:
+* An einem Rundlauf-Spiel müssen '''mindestens 3 Spielerinnen''' teilnehmen, nach oben hin gibt es keine Grenze (<code>3..*</code>). Jede einzelne Spielerin nimmt jedoch zu einem Zeitpunkt an '''exakt 1''' Rundlauf-Spiel teil (<code>1</code>).
+* Ein Spiel kann völlig ohne oder mit unbegrenzt vielen Schiedsrichterinnen stattfinden (<code>0..*</code>). Eine Schiedsrichterin kann maximal '''an höchstens 1''' Spiel gleichzeitig als Offizielle zugewiesen sein (<code>0..1</code>).
+<html>
+<svg width="750" height="280" viewBox="0 0 750 280" xmlns="http://www.w3.org/2000/svg" style="background-color: transparent;">
+  <g transform="translate(265, 100)">
+    <ellipse cx="110" cy="40" rx="100" ry="35" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="110" y="44" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Am Rundlauf-Spiel</text>
+    <text x="110" y="60" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">teilnehmen</text>
+  </g>
+  <g transform="translate(40, 50)">
+    <circle cx="30" cy="20" r="15" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="35" x2="30" y2="75" stroke="#222222" stroke-width="2"/>
+    <line x1="10" y1="50" x2="50" y2="50" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="10" y2="105" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="50" y2="105" stroke="#222222" stroke-width="2"/>
+    <text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Spielerin</text>
+  </g>
+  <line x1="100" y1="130" x2="265" y2="135" stroke="#222222" stroke-width="2" />
+  <text x="115" y="120" font-family="Arial, sans-serif" font-size="14" font-weight="bold" fill="#b30000">1</text>
+  <text x="240" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" fill="#b30000">3..*</text>
+  <g transform="translate(640, 50)">
+    <circle cx="30" cy="20" r="15" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="35" x2="30" y2="75" stroke="#222222" stroke-width="2"/>
+    <line x1="10" y1="50" x2="50" y2="50" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="10" y2="105" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="50" y2="105" stroke="#222222" stroke-width="2"/>
+    <text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Schiedsrichterin</text>
+  </g>
+  <line x1="465" y1="135" x2="640" y2="130" stroke="#222222" stroke-width="2" />
+  <text x="480" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" fill="#b30000">0..*</text>
+  <text x="615" y="120" font-family="Arial, sans-serif" font-size="14" font-weight="bold" fill="#b30000">0..1</text>
+</svg>
+</html>
+''Hinweis für die Praxis:'' Da Multiplizitäten Use-Case-Diagramme schnell visuell überladen und für fachliche Auftraggeber oft sekundär sind, werden sie in dieser Diagrammart selten notiert. Ihre fundamentale Bedeutung entfalten sie im [[Klassendiagramm]].
+=== 3. Include-Beziehungen (Abhängigkeiten) ===
+Die <code>«include»</code>-Beziehung beschreibt eine zwingende Abhängigkeit (Einschluss). Wenn ein Basis-Anwendungsfall ausgeführt wird, '''muss''' der inkludierte Anwendungsfall zwingend ebenfalls ausgeführt werden. Sie dient dem Aufbrechen komplexer Use Cases und der Wiederverwendung von Funktionalitäten.
+* '''Pfeilrichtung:''' Der gestrichelte Pfeil startet beim ''Basis-Use-Case'' und zeigt '''auf den inkludierten''' Use Case.
+* '''Stereotyp:''' Die Beziehungslinie muss zwingend mit dem Schlüsselwort <code>«include»</code> gekennzeichnet werden.
+<html>
+<svg width="650" height="140" viewBox="0 0 650 140" xmlns="http://www.w3.org/2000/svg" style="background-color: transparent;">
+  <g transform="translate(10, 30)">
+    <ellipse cx="110" cy="40" rx="100" ry="35" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="110" y="44" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Bestellung aufgeben</text>
+  </g>
+  <g>
+    <line x1="210" y1="70" x2="420" y2="70" stroke="#222222" stroke-width="2" stroke-dasharray="6,6" />
+    <polygon points="430,70 415,63 415,77" fill="#222222" />
+    <text x="320" y="55" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">«include»</text>
+  </g>
+  <g transform="translate(430, 30)">
+    <ellipse cx="110" cy="40" rx="100" ry="35" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="110" y="44" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Identität prüfen</text>
+  </g>
+</svg>
+</html>
+=== 4. Extend-Beziehungen (Erweiterungen) ===
+Die <code>«extend»</code>-Beziehung modelliert ein '''optionales''' Verhalten. Der erweiternde Use Case wird nur unter präzise definierten Rahmenbedingungen ausgeführt.
+* '''Pfeilrichtung:''' Der gestrichelte Pfeil verhält sich umgekehrt zur Include-Beziehung: Er startet beim ''erweiternden (optionalen) Use Case'' und zeigt '''auf den Basis-Use-Case'''.
+* '''Stereotyp:''' Kennzeichnung erfolgt über das Schlüsselwort <code>«extend»</code>.
+* '''Erweiterungspunkte (Extension Points):''' Im Basis-Use-Case wird unter einer horizontalen Trennlinie via <code>extension points</code> definiert, an welcher Stelle die Erweiterung eingreift.
+* '''Bedingung (Condition):''' Ein umschließendes Notizfeld (als Notizzettel dargestellt) definiert die logische Bedingung. Es wird mit einer fein gestrichelten Linie an die Extend-Beziehung geheftet.
+<html>
+<svg width="700" height="300" viewBox="0 0 700 300" xmlns="http://www.w3.org/2000/svg" style="background-color: transparent;">
+  <g transform="translate(20, 100)">
+    <ellipse cx="120" cy="50" rx="110" ry="45" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="120" y="40" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Konto einrichten</text>
+    <line x1="30" y1="52" x2="210" y2="52" stroke="#555555" stroke-width="1" />
+    <text x="120" y="68" font-family="Arial, sans-serif" font-size="11" font-style="italic" text-anchor="middle" fill="#555555">extension points:</text>
+    <text x="120" y="82" font-family="Arial, sans-serif" font-size="11" text-anchor="middle" fill="#222222">Premium-Option</text>
+  </g>
+  <g>
+    <line x1="440" y1="150" x2="255" y2="150" stroke="#222222" stroke-width="2" stroke-dasharray="6,6" />
+    <polygon points="245,150 260,143 260,157" fill="#222222" />
+    <text x="350" y="135" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">«extend»</text>
+  </g>
+  <g transform="translate(450, 100)">
+    <ellipse cx="110" cy="50" rx="100" ry="45" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="110" y="48" font-family="Arial, sans-serif" font-size="12" font-weight="bold" text-anchor="middle" fill="#222222">Premium-Features</text>
+    <text x="110" y="64" font-family="Arial, sans-serif" font-size="12" font-weight="bold" text-anchor="middle" fill="#222222">auswählen</text>
+  </g>
+  <g transform="translate(250, 10)">
+    <polygon points="0,0 170,0 190,20 190,60 0,60" fill="#ffffff" stroke="#222222" stroke-width="1" />
+    <polygon points="170,0 170,20 190,20" fill="#ffffff" stroke="#222222" stroke-width="1" />
+    <text x="10" y="20" font-family="Arial, sans-serif" font-size="11" font-weight="bold" fill="#222222">Condition: {Nutzer wählt</text>
+    <text x="10" y="35" font-family="Arial, sans-serif" font-size="11" font-weight="bold" fill="#222222">Premium-Abonnement}</text>
+    <text x="10" y="50" font-family="Arial, sans-serif" font-size="11" fill="#555555">Extension Point: Premium-Option</text>
+  </g>
+  <line x1="345" y1="70" x2="345" y2="150" stroke="#555555" stroke-width="1" stroke-dasharray="3,3" />
+</svg>
+</html>
+=== 5. Generalisierung (Vererbung / Spezialisierung) ===
+Eine Generalisierungsbeziehung spiegelt das klassische Konzept der Vererbung (OOP) wider. Sie kann sowohl zwischen zwei Akteuren als auch zwischen zwei Anwendungsfällen existieren. Das spezialisierte Element erbt alle Eigenschaften, Attribute und Verhaltensweisen des allgemeinen Elements und konkretisiert diese.
+* '''Darstellung:''' Eine durchgehende Linie mit einer '''großen, leeren und geschlossenen Pfeilspitze'''.
+* '''Pfeilrichtung:''' Der Pfeil zeigt immer '''vom spezifischen (Unterklasse) zum allgemeinen (Oberklasse)''' Element.
+==== Praxisbeispiel: Nutzerhierarchie ====
+Ein ''Fahrer'' ist eine explizite Spezialisierung des allgemeinen ''Anwenders''. Der Fahrer besitzt implizit jede Eigenschaft des Standard-Anwenders (wie Stammdaten: Vorname, Nachname, Username) und erbt dessen Fähigkeit, den Use Case ''Login durchführen'' aufzurufen, ohne dass dies redundant gezeichnet werden muss.
+<html>
+<svg width="400" height="320" viewBox="0 0 400 320" xmlns="http://www.w3.org/2000/svg" style="background-color: transparent;">
+  <g transform="translate(40, 20)">
+    <circle cx="30" cy="20" r="15" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="35" x2="30" y2="75" stroke="#222222" stroke-width="2"/>
+    <line x1="10" y1="50" x2="50" y2="50" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="10" y2="105" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="50" y2="105" stroke="#222222" stroke-width="2"/>
+    <text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Anwender</text>
+  </g>
+  <g transform="translate(200, 45)">
+    <ellipse cx="80" cy="35" rx="70" ry="30" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <text x="80" y="39" font-family="Arial, sans-serif" font-size="13" font-weight="bold" text-anchor="middle" fill="#222222">Login durchführen</text>
+  </g>
+  <line x1="100" y1="80" x2="200" y2="80" stroke="#222222" stroke-width="2" />
+  <g>
+    <line x1="70" y1="195" x2="70" y2="165" stroke="#222222" stroke-width="2" />
+    <polygon points="70,150 60,165 80,165" fill="#ffffff" stroke="#222222" stroke-width="2" />
+    <text x="85" y="185" font-family="Arial, sans-serif" font-size="12" font-style="italic" fill="#555555">Generalisierung</text>
+  </g>
+  <g transform="translate(40, 180)">
+    <circle cx="30" cy="20" r="15" fill="#ffffff" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="35" x2="30" y2="75" stroke="#222222" stroke-width="2"/>
+    <line x1="10" y1="50" x2="50" y2="50" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="10" y2="105" stroke="#222222" stroke-width="2"/>
+    <line x1="30" y1="75" x2="50" y2="105" stroke="#222222" stroke-width="2"/>
+    <text x="30" y="125" font-family="Arial, sans-serif" font-size="14" font-weight="bold" text-anchor="middle" fill="#222222">Fahrer</text>
+  </g>
+</svg>
+</html>
+== Zusammenfassende Gegenüberstellung für die Klausur / Praxis ==
+{| class="wikitable" style="width:100%; border:1px solid #aaa;"
+|- style="background:#eeeeee;"
+! Beziehungstyp !! Notation im Diagramm !! Semantik (Bedeutung) !! Typischer Anwendungsfall
 |-
-| '''Gerichtete Assoziation'''
+| '''Assoziation''' || Durchgehende Linie || Kommunikationspfad || Verknüpft primäre Akteure mit Kernfunktionen.
-| Durchgehende Linie mit Pfeil
-| Gibt die Initiierungsrichtung an. Ein Pfeil zum Anwendungsfall bedeutet, dass nur der Akteur die Aktion initiieren kann. Ein Pfeil zum Akteur besagt, dass das System die Aktion anstößt. Können beide Seiten initiieren, wird auf Pfeile komplett verzichtet.
 |-
-| '''Include-Beziehung'''<br/>(dt. ''beinhalten'')
+| '''Include''' || Gestrichelte Linie + Pfeil zum Ziel + <code>«include»</code> || Zwingende Ausführung (100% Pflicht) || Auslagerung von wiederkehrenden Funktionen wie Login oder Validierung.
-| Gestrichelte Linie mit Pfeil zum inkludierten Anwendungsfall und Schlüsselwort <code><<include>></code>
-| Gibt an, dass der Basis-Anwendungsfall das Verhalten des inkludierten Anwendungsfalls zwingend mitbenutzt und immer ausführt.
 |-
-| '''Extend-Beziehung'''<br/>(dt. ''erweitern'')
+| '''Extend''' || Gestrichelte Linie + Pfeil zur Basis + <code>«extend»</code> || Optionale Ausführung (0-100% je nach Bedingung) || Modellierung von Ausnahmefällen, Fehlermeldungen oder optionalen Zusatzfunktionen.
-| Gestrichelte Linie mit Pfeil zum Basis-Anwendungsfall und Schlüsselwort <code><<extend>></code>
-| Gibt an, dass ein Anwendungsfall optional ist und den Basis-Anwendungsfall nur unter bestimmten Bedingungen erweitert.
 |-
-| '''Generalisierung'''<br/>(Vererbung)
+| '''Generalisierung''' || Linie + geschlossene, leere Pfeilspitze || "Ist-ein"-Beziehung (Vererbung) || Abbildung von Benutzer-Rollenstrukturen (Rechtehierarchien).
-| Durchgehende Linie mit hohlem, geschlossenem Pfeil
-| Zeigt an, dass ein spezialisierter Anwendungsfall (oder Akteur) alle Bestandteile des allgemeinen übernimmt und diese konkretisiert oder erweitert. Beispiel: Der Akteur ''Fahrer'' ist eine Spezialisierung des Akteurs ''Anwender'' und erbt dessen Attribute wie Vorname, Nachname und die Befähigung zum Login.
 |}
-=== Detaillierte Betrachtung spezifischer Konzepte ===
-==== Multiplizitäten ====
-Multiplizitäten geben an, wie viele Instanzen eines Akteurs mit wie vielen Anwendungsfällen in Beziehung stehen. Sie werden direkt an gerichteten oder ungerichteten Assoziationen notiert.
-'''Pädagogisches Beispiel (Tischtennis-Rundlauf):'''
-* An einem Tischtennis-Rundlauf sind mindestens 3 Spielerinnen beteiligt. Die Untergrenze ist <code>3</code>, die Obergrenze ist <code>*</code> (beliebig viele). Notation: <code>3..*</code>
-* Jede Spielerin kann jedoch exakt an einem Rundlauf-Spiel teilnehmen. Ober- und Untergrenze sind exakt 1. Notation: <code>1</code>
-* An einem Spiel können keine oder beliebig viele Schiedsrichterinnen beteiligt sein. Notation: <code>0..*</code>
-* Jede Schiedsrichterin kann an höchstens einem Spiel beteiligt sein. Notation: <code>0..1</code>
-''Anmerkung:'' Da diese feingranularen Informationen für die Adressaten des Use-Case-Diagramms häufig keine Rolle spielen, werden Multiplizitäten hier eher selten notiert. Eine weitaus wichtigere Rolle spielen sie beim [[Klassendiagramm]].
-==== Erweiterungspunkte (Extension Points) und Bedingungen (Conditions) ====
-Bei der optionalen '''Extend-Beziehung''' bestimmt der Basis-Anwendungsfall sogenannte Erweiterungspunkte (''Extension Points'').
-* '''Extension Points:''' Sie geben den präzisen Ort innerhalb des Basis-Anwendungsfalls an, an dem Extensions hinzugefügt werden dürfen. Zur Darstellung wird innerhalb der Ellipse eine horizontale Linie gezogen. Darunter steht das Schlüsselwort <code>extension points</code>, gefolgt vom Namen des Erweiterungspunktes.
-* '''Bedingung (Condition):''' Optional kann eine Bedingung hinzugefügt werden, die beschreibt, unter welchen Voraussetzungen der Extend-Use-Case ausgeführt wird. Die Bedingung wird als Notizzettel-Symbol dargestellt, das das Schlüsselwort <code>Condition</code> enthält. Darunter steht die Bedingung in geschweiften Klammern und der bezogene Erweiterungspunkt. Dieses Symbol ist über eine gestrichelte Linie mit der Extend-Anweisung verbunden.
 [[Kategorie:Modellierung]]
 [[Kategorie:FI_I_SDM]]
 [[Kategorie:AHR_I_Informatik LK]]