Flbkwikiadmin:

== Einführung ==
Die [[UML]] kennt insgesamt 14 Diagrammtypen. Ein Sequenzdiagramm ist ein Diagrammtyp der UML. Das Wort Sequenz beschreibt laut Duden eine Reihenfolge oder kurz Folge von Dingen. In Sequenzdiagrammen wird eine zeitliche Folge von Kommunikationsbeziehungen zwischen [[Objekt|Objekten]] grafisch dargestellt. Eine Kommunikationsbeziehung ist das Senden einer Nachricht von einem [[Objekt]] zu einem anderen. Denn [[Objekt|Objekte]] tauschen Nachrichten aus, um miteinander zu kommunizieren (Heide Balzert: Lehrbuch der Objektmodellierung. Analyse und Entwurf S. 71 ff).

'''Was zeigt ein Sequenzdiagramm?'''
* '''Interaktionen:''' Es visualisiert, wie [[Objekt|Objekte]] miteinander kommunizieren und in welcher Reihenfolge Nachrichten ausgetauscht werden.
* '''Zeitliche Abfolge:''' Die vertikale Achse repräsentiert die Zeit, sodass man den Ablauf der Interaktionen gut nachvollziehen kann.
* '''Objekte:''' Jedes [[Objekt]] wird als eine Lebenslinie dargestellt.
* '''Nachrichten:''' Nachrichten, die zwischen [[Objekt|Objekten]] gesendet werden, sind als Pfeile dargestellt.

'''Was ist der Hauptzweck?'''

Der Hauptzweck eines Sequenzdiagramms besteht darin, den Ablauf von Prozessen darzustellen, nicht die konkreten Werte, die bei der Ausführung von [[Methode|Methoden]] zurückgegeben werden.
Abstraktion: [[Methode#Rückgabeparameter|Rückgabeparameter]] sind oft implementationsspezifische Details, die für das Verständnis des allgemeinen Ablaufs nicht immer relevant sind. Sie können dargestellt werden, falls relevant, müssen es aber nicht.

{{#ev:youtube|-ZswbawGWzg}}

== Grundsätzlicher Aufbau ==
Ein Sequenzdiagramm besitzt zwei Dimensionen: Die Vertikale repräsentiert die Zeit, auf der Horizontalen werden die [[Objekt|Objekte]] eingetragen. Die zugehörigen [[Klasse|Klassen]] werden mit aufgeführt. Die Lebensdauer eines jeden [[Objekt|Objektes]] wird durch eine gestrichelte Linie – die Lebenslinie oder Objektlinie – dargestellt. Diese Linie repräsentiert die Existenz eines Objekts während einer bestimmten Zeit.

[[Datei:Schematische Darstellung Sequenzdiagramm.png|mini]]
[[Datei:Beschriftetes Beispiel Sequenzdiagramm.png|mini]]

=== Objekte ===
Die [[Objekt|Objekte]] werden durch Rechtecke visualisiert. Im [[Instanz|Objekt]] steht der zugehörige [[Klasse]]nname (zum Beispiel Mail). Falls erforderlich, wird auch der Objektname (zum Beispiel Bestellung) aufgeführt. Objektname und Klassenname werden durch einen Doppelpunkt getrennt (zum Beispiel Bestellung: Mail).

Von den Objekten gehen die senkrechten Lebenslinien aus. Sie werden durch gestrichelte Linien dargestellt. Die Nachrichten werden durch waagerechte Pfeile zwischen den Objektlebenslinien beschrieben. Auf diesen Pfeilen werden die Nachrichtennamen in der Form: Nachricht(Argumente) notiert. Die Angabe von Argumenten ist optional.

=== Nachrichten ===
Durch eine Nachricht wird meist eine [[Methode]] des Empfängers aufgerufen. Hier kann auch die Übergabe von [[Methode#Eingabeparameter|Eingabeparametern]] kenntlich gemacht werden. Es wird zwischen synchronen und asynchronen Nachrichten unterschieden.

[[Datei:Nachrichten im Sequenzdiagramm.png|mini]]

'''Synchrone Nachrichten:''' Dabei pausiert der aufrufende Kommunikationspartner die Programmfortführung, bis er eine Antwort erhält. Synchrone Nachrichten werden durch einen Pfeil mit gefüllter Spitze dargestellt.

[[Datei:Synchrone und Asychrone Nachrichten.png|mini]]

'''Asynchrone Nachrichten:''' Dabei führt der Sender sein Programm fort. Trifft die Antwort ein, wird der Programmfluss unterbrochen und die Antwort verarbeitet. Sie werden durch einen Pfeil mit offener Spitze dargestellt.

=== Antworten ===
Die Darstellung der Antworten ist optional. Antworten werden durch eine gestrichelte Linie mit offener Pfeilspitze dargestellt. Das Erzeugen und Entfernen von Objekten kann in Sequenzdiagrammen ebenfalls dargestellt werden. Die [[Konstruktor|Konstruktion]] eines neuen Objektes wird durch eine Nachricht, die auf den Kopf des Objektsymbols trifft, angezeigt.

Die Entscheidung, ob Antworten in einem Sequenzdiagramm dargestellt werden, ist eine gestalterische Entscheidung, die vom jeweiligen Anwendungsfall abhängt. Es gibt keine strikten Regeln, sondern vielmehr Richtlinien, die es ermöglichen, klare und aussagekräftige Diagramme zu erstellen.

=== Statische Aufrufe ===
Statische (static) Methodenaufrufe werden mit unterstrichenem Methodennamen dargestellt. Der Aufruf erfolgt dann auf einer [[Klasse]] und nicht auf einem [[Objekt]].

=== Dekonstruktion ===
Die Destruktion bzw. Zerstörung eines Objektes wird durch ein Kreuz am Ende der Lebenslinie angezeigt.

=== Aktivierung ===
Die Überlagerung der gestrichelten Lebenslinien durch breite, senkrechte Balken symbolisiert die Aktivierung, d. h. es zeigt, welches Objekt gerade aktiv ist und somit für den Kontrollfluss des Programms verantwortlich ist.

=== Kontrollstrukturen ===
[[Datei:Bespiel Kontrollstrukturen im Sequenzdiagramm.png|mini]]
Auch [[Kontrollstruktur|Kontrollstrukturen]] lassen sich durch ein Sequenzdiagramm darstellen (siehe Zeichnung).

==== Verzweigung ====
Der mit alt (für alternative) markierte Block beschreibt eine Alternative ([[Verzweigung]]). Ist die Bedingung [b=wahr] erfüllt, wird der Bereich oberhalb der gestrichelten Linie in dem alt-Block ausgeführt. Im else-Fall wird der Bereich unterhalb der gestrichelten Linie ausgeführt.

==== Schleife ====
Der Teil des Sequenzdiagramms, der sich im Kasten mit dem Titel [[Schleife|loop]] befindet, wird solange ausgeführt, solange die Ausführbedingung in den eckigen Klammern [] wahr ist.

== Zeitliche Ordnung der Ereignisse ==
Ein Sequenzdiagramm beschreibt das Verhalten eines Systems, indem es die zeitliche Ordnung von Ereignisauftritten spezifiziert. Nicht der präzise Zeitpunkt, wann ein Ereignis auftritt, ist dabei ausschlaggebend, sondern welche Ereignisse vor und welche nach einem bestimmten Ereignisauftritt auftreten müssen (Quelle: https://de.wikipedia.org/wiki/Sequenzdiagramm).

[[Datei:Zeitliche Eindordnung Nachrichten im Sequenzdiagramm.png|mini]]

Die Abbildung links zeigt ein Sequenzdiagramm mit zwei synchronen Operationsaufrufen. Blau eingekreist sind die vier Ereignisauftritte. S1 und E1 stehen für das Sende- und das Empfangs-Nachricht-Ereignis für die Nachricht m1, S2 und E2 für die entsprechenden Ereignisse, die mit m2 in Verbindung stehen. Die Zeitachse läuft in einem Sequenzdiagramm von oben nach unten, sollte aber nicht als absolute Zeit verstanden werden.

Zu den Ereignisauftritten in diesem Sequenzdiagramm lassen sich folgende Aussagen machen:
* E1 tritt nach S1 auf, weil das Empfangs- immer nach dem Sende-Nachricht-Ereignis vorkommt. Analog tritt E2 nach S2 auf.
* S2 tritt nach S1 auf, weil S2 unter S1 gezeichnet ist.

Alles in allem modelliert dieses Sequenzdiagramm also eine Interaktion, die durch genau eine Folge von Ereignisauftritten spezifiziert ist: <S1, E1, S2, E2>.

Das Sequenzdiagramm in der Abbildung links unterscheidet sich nur geringfügig vom vorangehenden Sequenzdiagramm. Der einzige Unterschied besteht darin, dass statt zwei synchronen zwei asynchrone Nachrichten dargestellt sind. Hier gilt weiterhin, dass E1 nach S1 und E2 nach S2 auftritt, weil das Empfangs- immer nach dem Sende-Nachricht-Ereignis vorkommt. Weil es sich um asynchrone Kommunikation handelt, könnte E1 hier jedoch nicht nur vor, sondern auch erst nach S2 oder E2 vorkommen.

Das Sequenzdiagramm spezifiziert also eine Interaktion, in der drei Folgen von Ereignisauftritten zulässig sind: <S1, E1, S2, E2>, <S1, S2, E1, E2> und <S1, S2, E2, E1>.

Falls nötig, kann man die zulässigen Abfolgen von Ereignisauftritten mit zusätzlichen Ordnungsbeziehungen einschränken. Eine Ordnungsbeziehung spezifiziert nicht eine Nachricht, die zwischen zwei Lebenslinien ausgetauscht wird, sondern die Tatsache, dass ein Ereignisauftritt nach einem anderen Ereignisauftritt vorkommen muss. Im Beispiel modelliert die Ordnungsbeziehung, dass S2 immer nach E1 erfolgt.

Mit dieser zusätzlichen Einschränkung stellt dieses Sequenzdiagramm erneut eine Interaktion mit genau einer zulässigen Folge dar: <S1, E1, S2, E2>.

[[Kategorie:Modellierung]]
[[Kategorie:Programmierung]]
[[Kategorie:FI_I_TP2]]
[[Kategorie:AHR_I_Informatik_LK]]

Anwendungsfalldiagramm

2026-05-27T08:59:24Z

Flbkwikiadmin:

== Einführung ==
Die [[Unified Modeling Language]] (Vereinheitlichte Modellierungssprache), kurz '''UML''', ist eine standardisierte grafische Modellierungssprache zur Beschreibung, Spezifikation und Dokumentation von Anforderungen und Softwarearchitekturen. Das '''Anwendungsfalldiagramm''' (engl. '''Use Case Diagramm''') ist ein elementares Verhaltensdiagramm der UML.

Ziel des Anwendungsfalldiagramms ist es, in der Analysephase (Requirements Engineering) die funktionalen Anforderungen des Auftraggebers aus fachlicher Sicht für alle Beteiligten verständlich, übersichtlich und vollständig zu modellieren. Es dient als zentrales Kommunikationsmittel, um barrierefrei zwischen potenziellen Anwendern, Auftraggebern (Fachseite) und Auftragnehmern (Entwicklungsteam) zu vermitteln. Als strukturierte funktionale Anforderungsbeschreibung sind Anwendungsfalldiagramme ein fester Bestandteil des [[Lastenheft]]s und bilden die primäre Grundlage für das [[Pflichtenheft]].

Das Anwendungsfalldiagramm besteht aus drei wesentlichen Elementen:
# '''Akteure (engl. ''actors''):''' Sie identifizieren die externen Benutzer oder Systeme, die mit dem System interagieren. Jeder Akteur repräsentiert eine '''Rolle''' und keine konkrete Person.
# '''Anwendungsfälle (engl. ''use cases''):''' Sie beschreiben die vom System angebotenen Funktionalitäten und Aufgaben, die für den Akteur ein Ergebnis von messbarem, fachlichem Wert erzeugen.
# '''Beziehungen (engl. ''relations''):''' Sie definieren die Kommunikationspfade zwischen Akteuren und Anwendungsfällen sowie die strukturellen Abhängigkeiten der Anwendungsfälle untereinander.

''Hinweis zur Abgrenzung:'' Ein Anwendungsfalldiagramm bildet '''keine''' zeitlichen, logischen oder prozessualen Abläufe ab. Für die Modellierung von Kontrollflüssen und sequentiellen Prozessen sind stattdessen UML-Aktivitätendiagramme oder Sequenzdiagramme zu verwenden.

== Gesamtbeispiel (Systemkontext) ==
Ein vollständiges Anwendungsfalldiagramm führt alle Funktionseinheiten innerhalb eines umschließenden '''Systemrahmens (Systemgrenze / System Boundary)''' zusammen. Der Rahmen grenzt das zu entwickelnde System strikt von seiner Umwelt ab: Akteure stehen als externe Entitäten immer außerhalb des Systems, während die Anwendungsfälle die interne Funktionalität definieren.

[[Datei:AnwendungsfallSys.png|mini|Gesamtbeispiel eines Use-Case-Diagramms mit Systemgrenze, Akteuren und verknüpften Beziehungen]]

== Notation ==
Der methodische Aufbau eines standardkonformen Anwendungsfalldiagramms folgt drei sequentiellen Schritten:

# '''Akteure identifizieren:''' Es wird festgelegt, welche unterschiedlichen Rollen das System nutzen werden. Menschliche Rollen werden grafisch als Strichmännchen dargestellt, externe Software- oder Hardwaresysteme als Rechtecke mit dem Stereotyp <code>«system»</code>. Jeder Akteur muss einen eindeutigen, selbsterklärenden Namen im Singular erhalten (z. B. ''Kunde'', ''Administrator''). Allgemeine Bezeichnungen wie „User“ oder „Akteur“ sind zu vermeiden, da sie für fast jedes Softwaresystem gültig sind und keine spezifische Rolle beschreiben.
# '''Anwendungsfälle definieren:''' Es wird geklärt, welche fachlichen Ziele das System erfüllen muss. Anwendungsfälle werden als horizontale Ellipsen dargestellt, die eine kurze Inhaltsbeschreibung enthalten. Die Formulierung muss kurz, aussagekräftig und im Infinitiv bzw. im Format ''Subjekt-Prädikat-Objekt'' erfolgen (z. B. ''Artikel suchen'', ''Passwort zurücksetzen'').
# '''Beziehungen verknüpfen:''' Erst im letzten Schritt werden die Akteure und Anwendungsfälle über strukturierte Beziehungslinien miteinander verbunden, um die Interaktionskanäle visuell zu definieren.

== Beziehungen ==

=== Assoziation ===
Assoziationen bilden die grundlegenden Kommunikationspfade zwischen Akteuren und Use Cases. Eine Assoziation signalisiert, dass der verknüpfte Akteur die Aktion des Use Cases ausführen oder mit diesem interagieren kann. Es handelt sich um eine binäre Beziehung, die exakt zwei Elemente miteinander verbindet. Ein einzelner Use Case darf mit mehreren Akteuren und ein einzelner Akteur mit mehreren Use Cases verbunden sein.

==== Ungerichtete Assoziation ====
Ungerichtete Assoziationen werden als einfache, durchgehende Linie dargestellt. Sie stellt die offenste Form der Interaktion dar und signalisiert einen bidirektionalen Informationsfluss, lässt jedoch die Richtung der Initiierung (wer die Aktion startet) offen.

[[Datei:AnwendungsfallEinweihungsfeier.png|mini|Ungerichtete Assoziation als einfache Verbindungslinie]]

==== Gerichtete Assoziation ====
Eine gerichtete Assoziation verwendet eine offene Pfeilspitze, um die Navigierbarkeit und den Initiator des Prozesses eindeutig festzulegen.
* Ein Pfeil, der '''auf den Use Case gerichtet''' ist, besagt, dass der Akteur den Anwendungsfall aktiv initiiert.
* Ein Pfeil, der '''auf den Akteur zeigt''', besagt, dass der Use Case (bzw. das System) die Interaktion zum Akteur hin anstößt (häufig bei sekundären Systemen oder Benachrichtigungsdiensten).
* Können beide Seiten die Aktion unabhängig voneinander initiieren, werden die Pfeile weggelassen.

[[Datei:AnwendungsfallHotelreservierung.png|mini|Gerichtete Assoziation mit Pfeil zur Kennzeichnung des Initiators]]

=== Multiplizitäten ===
Multiplizitäten (Kardinalitäten) geben an, wie viele Instanzen eines Akteurs mit wie vielen Instanzen eines Anwendungsfalls in einer konkreten Systeminteraktion in Beziehung stehen können. Sie werden direkt an den Enden der Assoziationslinien notiert.

[[Datei:AnwendungsfallTischtennis.png|mini|Modellierung von Multiplizitäten am Beispiel eines Tischtennis-Rundlaufs]]

Die Multiplizitäten des Beispiels sind gemeldet nach UML-Standard wie folgt zu interpretieren:
* An einem Tischtennis-Rundlauf (Use Case) sind mindestens 3 Spielerinnen beteiligt. Die Untergrenze ist <code>3</code>, die Obergrenze ist als <code>*</code> (beliebig viele) definiert (Notation: <code>3..*</code>). Jede Spielerin kann jedoch zeitgleich an exakt einem Rundlauf-Spiel teilnehmen (Notation: <code>1</code>).
* An einem Rundlaufspiel können keine oder beliebig viele Schiedsrichterinnen beteiligt sein (Notation: <code>0..*</code>). Jede Schiedsrichterin kann wiederum an höchstens einem Rundlaufspiel aktiv beteiligt sein (Notation: <code>0..1</code>).

''Hinweis für die Praxis:'' Da diese Detailinformationen die Adressaten eines Use-Case-Diagramms häufig überfordern, werden Multiplizitäten hier selten notiert. Ihre zentrale und fundamentale Bedeutung entfalten sie im strukturellen [[Klassendiagramm]].

=== Includes (Inklusion) ===
Eine '''Include-Beziehung''' (dt. ''beinhalten'' oder ''einschließen'') beschreibt eine zwingende Abhängigkeit zur Vermeidung von funktionaler Redundanz (Wiederverwendung von Use Cases).

Die Beziehung wird durch eine gestrichelte Linie mit einer offenen Pfeilspitze dargestellt, die mit dem Stereotyp <code>«include»</code> gekennzeichnet ist. Der Pfeil startet immer beim '''Basis-Use-Case und zeigt in Richtung des zu inkludierenden Use Cases'''.
* '''Semantik:''' Der inkludierte Anwendungsfall wird '''immer (zu 100 %)''' ausgeführt, sobald der Basis-Anwendungsfall aufgerufen wird. Der Basis-Use-Case ist ohne das Inkludat funktional unvollständig.

[[Datei:AnwendungsfallHotelreservierungKomplex.png|mini|Zwingende Include-Beziehung zur Auslagerung gemeinsamer Funktionalitäten]]

=== Extend (Erweiterung) ===
Eine '''Extend-Beziehung''' (dt. ''erweitern'') beschreibt ein '''optionales''' Verhalten, das den Basis-Use-Case nur unter ganz bestimmten Bedingungen ergänzt.

Die Beziehung wird durch eine gestrichelte Linie mit einer offenen Pfeilspitze dargestellt, die mit dem Stereotyp <code>«extend»</code> gekennzeichnet ist. Die Pfeilrichtung verhält sich umgekehrt zum Include: Der Pfeil startet beim '''Extension-Use-Case (Erweiterung) und zeigt in Richtung des Basis-Use-Cases'''.

Der Basis-Use-Case deklariert sogenannte '''Erweiterungspunkte (Extension Points)''', die den präzisen Ort innerhalb des Ablaufs definieren, an dem die Erweiterung eingreifen darf. Grafisch wird hierzu in der Ellipse des Basis-Use-Cases eine horizontale Trennlinie eingezogen, unter der das Schlüsselwort <code>extension points:</code> gefolgt von den Namen der Punkte steht.

Optional wird an die Extend-Linie über eine fein gestrichelte Linie ein UML-Notizsymbol angeheftet. Dieses enthält das Schlüsselwort <code>Condition:</code> gefolgt von der logischen Bedingung in geschweiften Klammern <code>{...}</code> sowie den Verweis auf den zugehörigen Erweiterungspunkt.
* '''Semantik:''' Der Basis-Use-Case ist auch ohne die Erweiterung vollkommen autark lauffähig. Der Extension-Use-Case wird nur dann ausgeführt, wenn die definierte Bedingung am Erweiterungspunkt wahr (true) ist.

[[Datei:AnwendungsfalldiagrammHotelreservierungKomplexErkl.png|mini|Optionale Extend-Beziehung mit expliziten Extension Points und Notizfeld für die Bedingung (Condition)]]

=== Generalisierung (Vererbung) ===
Zwischen Akteuren untereinander sowie zwischen Anwendungsfällen untereinander kann eine Generalisierungsbeziehung existieren. Sie modelliert eine klassische '''"Ist-ein"-Beziehung''', analog zur Vererbung in der objektorientierten Programmierung.

Die Generalisierung wird grafisch durch eine durchgehende Linie mit einer '''geschlossenen, hohlen Dreieckspfeilspitze''' dargestellt. Der Pfeil zeigt immer '''vom spezialisierten Element (Unterklasse) zum allgemeinen Element (Oberklasse)'''.

[[Datei:AnwendungsfallCD.png|mini|Strukturelle Generalisierung zwischen Akteuren oder Funktionseinheiten]]

* '''Generalisierung von Akteuren:''' Im Beispiel ist der Akteur ''Fahrer'' eine Spezialisierung von ''Anwender''. Der Fahrer erbt bedingungslos alle Fähigkeiten, Use Cases und Attribute des allgemeinen Anwenders (z. B. Stammdaten und die Interaktion mit dem Use Case ''Login durchführen''), konkretisiert oder erweitert diese Rolle jedoch um spezifische Eigenschaften.
* '''Generalisierung von Anwendungsfällen:''' Ein abstrakter Anwendungsfall wie ''„Medium brennen“'' kann durch spezialisierte Anwendungsfälle wie ''„CD brennen“'' oder ''„DVD brennen“'' geerbt und ausdifferenziert werden.

[[Kategorie:Modellierung]]
[[Kategorie:FI_I_SDM]]
[[Kategorie:AHR_I_Informatik LK]]