Grundlagen der Modellierung - Objektorientierte Modelle - Versionsgeschichte

KLAUSNER Daniela: /* Beziehungen zwischen Use Cases */

2023-10-31T18:04:30Z

Beziehungen zwischen Use Cases

KLAUSNER Daniela: /* Darstellung */

2023-10-31T18:03:33Z

Darstellung

KLAUSNER Daniela: /* Mehrfachvererbungen */

2023-10-31T18:02:41Z

Mehrfachvererbungen

← Nächstältere Version		Version vom 31. Oktober 2023, 18:02 Uhr
Zeile 329:		Zeile 329:
	=== Mehrfachvererbungen ===		=== Mehrfachvererbungen ===

	UML unterstützt auch die Notation von '''Mehrfachvererbungen'''. Siehe hierzu das folgende Beispiel in der Abbildung UML Mehrfachvererbung:		UML unterstützt auch die Notation von '''Mehrfachvererbungen'''. Siehe hierzu das folgende Beispiel in der Abbildung "UML Mehrfachvererbung":

	[[Datei:Wiba mt233 201607 a.100.png\|300px\|none\|thumb\|UML Mehrfachvererbung]]		[[Datei:Wiba mt233 201607 a.100.png\|300px\|none\|thumb\|UML Mehrfachvererbung]]
	<span id="aggregation"></span>		<span id="aggregation"></span>

	=== Aggregation ===		=== Aggregation ===

KLAUSNER Daniela: /* UML Klassendiagramm */

2023-10-31T18:02:18Z

UML Klassendiagramm

← Nächstältere Version		Version vom 31. Oktober 2023, 18:02 Uhr
Zeile 252:		Zeile 252:
	Attribute und Operatoren können ebenfalls mit Eigenschaften versehen werden, wie beispielsweise { static } zur Kennzeichnung als statisches Element auf Klassenebene.		Attribute und Operatoren können ebenfalls mit Eigenschaften versehen werden, wie beispielsweise { static } zur Kennzeichnung als statisches Element auf Klassenebene.

	Es können weiter auch bei den Operationen Stereotype angegeben werden, die helfen, die Operationen zu gruppieren. Ein entsprechend erweitertes Beispiel ist in Abbildung "Erweitertes Klassendiagramm" abgebildet.		Es können weiter auch bei den Operationen Stereotype angegeben werden, die helfen, die Operationen zu gruppieren. Ein entsprechend erweitertes Beispiel ist in der Abbildung "Erweitertes Klassendiagramm" abgebildet.

	[[Datei:Wiba mt233 201607 a.090.png\|300px\|none\|thumb\|Erweitertes Klassendiagramm]]		[[Datei:Wiba mt233 201607 a.090.png\|300px\|none\|thumb\|Erweitertes Klassendiagramm]]

KLAUSNER Daniela: /* UML Klassendiagramm */

2023-10-31T18:01:53Z

UML Klassendiagramm

KLAUSNER Daniela: /* UML Diagrammtypen */

2023-10-31T17:58:49Z

UML Diagrammtypen

← Nächstältere Version		Version vom 31. Oktober 2023, 17:58 Uhr
Zeile 136:		Zeile 136:
	Die zentrale Eigenschaft der Notation ist die Unterstützung von verschiedenen Sichten auf das zu modellierende System. Hierzu stellt UML eine Reihe von unterschiedlichen Diagrammtypen, sogenannten Spracheinheiten (language units), zur Verfügung. Diese Diagrammtypen erlauben es dem Benutzer einen ausgewählten Aspekt eines Systems mit einem bestimmten Formalismus zu modellieren.		Die zentrale Eigenschaft der Notation ist die Unterstützung von verschiedenen Sichten auf das zu modellierende System. Hierzu stellt UML eine Reihe von unterschiedlichen Diagrammtypen, sogenannten Spracheinheiten (language units), zur Verfügung. Diese Diagrammtypen erlauben es dem Benutzer einen ausgewählten Aspekt eines Systems mit einem bestimmten Formalismus zu modellieren.

	UML 2.0 stellt hierzu insgesamt 13 Diagrammtypen zur Verfügung, die grundsätzlich in zwei Gruppen eingeteilt werden können, in sechs '''Strukturdiagramme''', die die statischen Aspekte darstellen, und sieben '''Verhaltensdiagramme''' für die dynamischen Aspekte, wobei drei allgemeines Verhalten und vier Interaktionen beschreiben. Im Folgenden werden diese 13 Diagramme kurz erläutert <ref>Die graphischen Darstellungen sind aus Wikipedia, http://de.wikipedia.org/</ref> . In den nachfolgenden Abschnitten [[#UML_Klassendiagramm \| UML Klassendiagramm]] und [[#UML_Anwendungsfalldiagramm_(Use_Case_Diagramm) \| UML Anwendungsfalldiagramm (Use Case Diagramm]] werden das Objektdiagramm und das Anwendungsfalldiagramm genauer behandelt.		UML 2.0 stellt hierzu insgesamt 13 Diagrammtypen zur Verfügung, die grundsätzlich in zwei Gruppen eingeteilt werden können, in sechs '''Strukturdiagramme''', die die statischen Aspekte darstellen, und sieben '''Verhaltensdiagramme''' für die dynamischen Aspekte, wobei drei allgemeines Verhalten und vier Interaktionen beschreiben. Im Folgenden werden diese 13 Diagramme kurz erläutert <ref>Die graphischen Darstellungen sind aus Wikipedia, http://de.wikipedia.org/</ref> . In den nachfolgenden Abschnitten [[#UML_Klassendiagramm \| UML Klassendiagramm]] und [[#UML_Anwendungsfalldiagramm_(Use_Case_Diagramm) \| UML Anwendungsfalldiagramm (Use Case Diagramm)]] werden das Objektdiagramm und das Anwendungsfalldiagramm genauer behandelt.

	<span id="strukturdiagramme"></span>		<span id="strukturdiagramme"></span>

KLAUSNER Daniela: /* UML Diagrammtypen */

2023-10-31T17:58:28Z

UML Diagrammtypen

← Nächstältere Version		Version vom 31. Oktober 2023, 17:58 Uhr
Zeile 136:		Zeile 136:
	Die zentrale Eigenschaft der Notation ist die Unterstützung von verschiedenen Sichten auf das zu modellierende System. Hierzu stellt UML eine Reihe von unterschiedlichen Diagrammtypen, sogenannten Spracheinheiten (language units), zur Verfügung. Diese Diagrammtypen erlauben es dem Benutzer einen ausgewählten Aspekt eines Systems mit einem bestimmten Formalismus zu modellieren.		Die zentrale Eigenschaft der Notation ist die Unterstützung von verschiedenen Sichten auf das zu modellierende System. Hierzu stellt UML eine Reihe von unterschiedlichen Diagrammtypen, sogenannten Spracheinheiten (language units), zur Verfügung. Diese Diagrammtypen erlauben es dem Benutzer einen ausgewählten Aspekt eines Systems mit einem bestimmten Formalismus zu modellieren.

	UML 2.0 stellt hierzu insgesamt 13 Diagrammtypen zur Verfügung, die grundsätzlich in zwei Gruppen eingeteilt werden können, in sechs '''Strukturdiagramme''', die die statischen Aspekte darstellen, und sieben '''Verhaltensdiagramme''' für die dynamischen Aspekte, wobei drei allgemeines Verhalten und vier Interaktionen beschreiben. Im Folgenden werden diese 13 Diagramme kurz erläutert <ref>Die graphischen Darstellungen sind aus Wikipedia, http://de.wikipedia.org/</ref> . In den nachfolgenden Abschnitten ~~5.4~~ und ~~5.5~~ werden das Objektdiagramm und das Anwendungsfalldiagramm genauer behandelt.		UML 2.0 stellt hierzu insgesamt 13 Diagrammtypen zur Verfügung, die grundsätzlich in zwei Gruppen eingeteilt werden können, in sechs '''Strukturdiagramme''', die die statischen Aspekte darstellen, und sieben '''Verhaltensdiagramme''' für die dynamischen Aspekte, wobei drei allgemeines Verhalten und vier Interaktionen beschreiben. Im Folgenden werden diese 13 Diagramme kurz erläutert <ref>Die graphischen Darstellungen sind aus Wikipedia, http://de.wikipedia.org/</ref> . In den nachfolgenden Abschnitten [[#UML_Klassendiagramm \| UML Klassendiagramm]] und [[#UML_Anwendungsfalldiagramm_(Use_Case_Diagramm) \| UML Anwendungsfalldiagramm (Use Case Diagramm]] werden das Objektdiagramm und das Anwendungsfalldiagramm genauer behandelt.

	<span id="strukturdiagramme"></span>		<span id="strukturdiagramme"></span>
Zeile 225:		Zeile 225:

	<span id="uml-klassendiagramm"></span>		<span id="uml-klassendiagramm"></span>

	== UML Klassendiagramm ==		== UML Klassendiagramm ==

KLAUSNER Daniela: /* Kapselung */

2023-10-31T17:55:48Z

Kapselung

← Nächstältere Version		Version vom 31. Oktober 2023, 17:55 Uhr
Zeile 56:		Zeile 56:
	* Protected und		* Protected und
	* Private.		* Private.
	Um eine Variable oder Methode mit einem Kapselungs-Level zu versehen wird dieser meist direkt bei ihrer Definition angegeben. In UML geschieht dies vor dem Variablen- oder Methoden-Namen (siehe ~~5.4~~).		Um eine Variable oder Methode mit einem Kapselungs-Level zu versehen wird dieser meist direkt bei ihrer Definition angegeben. In UML geschieht dies vor dem Variablen- oder Methoden-Namen (siehe [[#UML_Klassendiagramm \| UML Klassendiagramm]]).

	Der offenste Level ist der Level '''Public'''. Er ermöglicht einen direkten Zugriff von außerhalb des Objektes oder der Klasse. Ein Beispiel für Methoden, welche diesem Level unterliegen sind die Getter- und Setter-Methoden.		Der offenste Level ist der Level '''Public'''. Er ermöglicht einen direkten Zugriff von außerhalb des Objektes oder der Klasse. Ein Beispiel für Methoden, welche diesem Level unterliegen sind die Getter- und Setter-Methoden.
Zeile 67:		Zeile 67:

	<span id="abstrakte-klassen"></span>		<span id="abstrakte-klassen"></span>

	=== Abstrakte Klassen ===		=== Abstrakte Klassen ===

KLAUSNER Daniela: /* Klassen, Objekte und Vererbung */

2023-10-31T17:54:57Z

Klassen, Objekte und Vererbung

← Nächstältere Version		Version vom 31. Oktober 2023, 17:54 Uhr
Zeile 32:		Zeile 32:
	<span id="_Ref406416460" class="anchor"></span>[[Datei:Wiba mt233 201607 a.073.png\|300px\|none\|thumb\|Klasse mit Vererbung]]		<span id="_Ref406416460" class="anchor"></span>[[Datei:Wiba mt233 201607 a.073.png\|300px\|none\|thumb\|Klasse mit Vererbung]]

	Eine Klasse kann zusätzlich zu Variablen auch '''Methoden''' enthalten. Es handelt sich dabei um Methoden, welche innerhalb der jeweiligen Instanz der Klasse ausgeführt werden. Sie können daher auf die jeweiligen Daten der Objekte zugreifen und diese verarbeiten und verändern. Im Rahmen der objektorientierten Modellierung ist es üblich, die Variablen eines Objektes nicht direkt abzurufen und zu befüllen, sondern dies über eigene Methoden zu bewerkstelligen. Dabei handelt es sich meist im eine Get- und eine Set-Methode. Sie werden daher auch als '''Getter und Setter''' bezeichnet. Für das Beispiel in Abbildung 68 werden daher Get- und Set-Methoden für die Variablen ''Name'', ''E-Mail'', ''KundenNr'' für die Klasse ''Kunde'' und für ''UstId'' und ''Firmenname'' der ihrer Tochterklasse ''Geschäftskunde'' angelegt. Das neue Modell ist in der Abbildung "Klassen mit Get- und Set-Methoden" ersichtlich.		Eine Klasse kann zusätzlich zu Variablen auch '''Methoden''' enthalten. Es handelt sich dabei um Methoden, welche innerhalb der jeweiligen Instanz der Klasse ausgeführt werden. Sie können daher auf die jeweiligen Daten der Objekte zugreifen und diese verarbeiten und verändern. Im Rahmen der objektorientierten Modellierung ist es üblich, die Variablen eines Objektes nicht direkt abzurufen und zu befüllen, sondern dies über eigene Methoden zu bewerkstelligen. Dabei handelt es sich meist im eine Get- und eine Set-Methode. Sie werden daher auch als '''Getter und Setter''' bezeichnet. Für das Beispiel in der Abbildung "Klasse mit Vererbung" werden daher Get- und Set-Methoden für die Variablen ''Name'', ''E-Mail'', ''KundenNr'' für die Klasse ''Kunde'' und für ''UstId'' und ''Firmenname'' der ihrer Tochterklasse ''Geschäftskunde'' angelegt. Das neue Modell ist in der Abbildung "Klassen mit Get- und Set-Methoden" ersichtlich.

	<span id="_Ref406419448" class="anchor"></span>[[Datei:Wiba mt233 201607 a.074.png\|300px\|none\|thumb\|Klassen mit Get- und Set-Methoden]]		<span id="_Ref406419448" class="anchor"></span>[[Datei:Wiba mt233 201607 a.074.png\|300px\|none\|thumb\|Klassen mit Get- und Set-Methoden]]

KLAUSNER Daniela: /* Klassen, Objekte und Vererbung */

2023-10-31T17:53:43Z

Klassen, Objekte und Vererbung

← Nächstältere Version		Version vom 31. Oktober 2023, 17:53 Uhr
Zeile 20:		Zeile 20:
	Eine Klasse gibt es daher immer nur einmal, da es sich dabei um die Definition möglicher Objekte handelt. Zu einer Klasse kann es beliebig viele Objekte geben.		Eine Klasse gibt es daher immer nur einmal, da es sich dabei um die Definition möglicher Objekte handelt. Zu einer Klasse kann es beliebig viele Objekte geben.

	Ein Beispiel für eine Klasse mit dazugehörigen Objekten ist in Abbildung 67 dargestellt. Es handelt sich dabei um die Klasse ''Kunde'', welche den Aufbau der Kundenobjekte definiert. Davon existieren zwei Instanzen, welche nun konkrete Kunden-Objekte repräsentieren.		Ein Beispiel für eine Klasse mit dazugehörigen Objekten ist in der Abbildung "Klasse mit instanziierten Objekten" dargestellt. Es handelt sich dabei um die Klasse ''Kunde'', welche den Aufbau der Kundenobjekte definiert. Davon existieren zwei Instanzen, welche nun konkrete Kunden-Objekte repräsentieren.

	Jedes der beiden ''Kunden''-Objekte hat eigene Daten. Eine Änderung der Daten eines Kunden hat weder Auswirkung auf die anderen ''Kunden''-Objekte, noch auf die Klasse.		Jedes der beiden ''Kunden''-Objekte hat eigene Daten. Eine Änderung der Daten eines Kunden hat weder Auswirkung auf die anderen ''Kunden''-Objekte, noch auf die Klasse.
Zeile 28:		Zeile 28:
	<span id="_Ref406415468" class="anchor"></span>[[Datei:Wiba mt233 201607 a.072.png\|300px\|none\|thumb\|Klasse mit instanziierten Objekten]]		<span id="_Ref406415468" class="anchor"></span>[[Datei:Wiba mt233 201607 a.072.png\|300px\|none\|thumb\|Klasse mit instanziierten Objekten]]

	Bei der '''Vererbung''' handelt es sich um einen der wesentlichsten Teile der Objektorientierung. Es handelt sich dabei um die Möglichkeit einzelne Klassen, und damit ihre Objekte, zu gliedern und zu konkretisieren oder in die andre Richtung weiter zu abstrahieren. Soll beispielsweise die Klasse ''Kunde'' aus Abbildung 67 weiter konkretisiert werden um zwischen normalen ''Kunden'' und ''Geschäftskunden'' zu unterscheiden, könnte diese neue Klasse mittels Vererbung von der Klasse Kunde '''abgeleitet''' werden. Sie erbt damit alle Variablen und Methoden der Klasse ''Kunde'' und ergänzt diese um weitere, für den Zweck der neuen Klasse konkretere, Variablen. Da die Klasseneigenschaften immer von einer Klasse zur nächsten weitervererbt werden, spricht man in diesem Zusammenhang oft von einer '''Mutterklasse''' und '''Tochterklasse'''. Ein entsprechendes Beispiel findet sich in Abbildung 68. Dabei wurde die neue Klasse ''Geschäftskunde'' um eine ''Umsatzsteuer-Identifikationsnummer'' und einen ''Firmennamen'' erweitert. Sie erbt dabei alle Eigenschaften ihrer Mutterklasse und kann diese wiederum selbst verwenden.		Bei der '''Vererbung''' handelt es sich um einen der wesentlichsten Teile der Objektorientierung. Es handelt sich dabei um die Möglichkeit einzelne Klassen, und damit ihre Objekte, zu gliedern und zu konkretisieren oder in die andre Richtung weiter zu abstrahieren. Soll beispielsweise die Klasse ''Kunde'' aus der Abbildung "Klasse mit instanziierten Objekten" weiter konkretisiert werden um zwischen normalen ''Kunden'' und ''Geschäftskunden'' zu unterscheiden, könnte diese neue Klasse mittels Vererbung von der Klasse Kunde '''abgeleitet''' werden. Sie erbt damit alle Variablen und Methoden der Klasse ''Kunde'' und ergänzt diese um weitere, für den Zweck der neuen Klasse konkretere, Variablen. Da die Klasseneigenschaften immer von einer Klasse zur nächsten weitervererbt werden, spricht man in diesem Zusammenhang oft von einer '''Mutterklasse''' und '''Tochterklasse'''. Ein entsprechendes Beispiel findet sich in der Abbildung "Klasse mit Vererbung". Dabei wurde die neue Klasse ''Geschäftskunde'' um eine ''Umsatzsteuer-Identifikationsnummer'' und einen ''Firmennamen'' erweitert. Sie erbt dabei alle Eigenschaften ihrer Mutterklasse und kann diese wiederum selbst verwenden.

	<span id="_Ref406416460" class="anchor"></span>[[Datei:Wiba mt233 201607 a.073.png\|300px\|none\|thumb\|Klasse mit Vererbung]]		<span id="_Ref406416460" class="anchor"></span>[[Datei:Wiba mt233 201607 a.073.png\|300px\|none\|thumb\|Klasse mit Vererbung]]

	Eine Klasse kann zusätzlich zu Variablen auch '''Methoden''' enthalten. Es handelt sich dabei um Methoden, welche innerhalb der jeweiligen Instanz der Klasse ausgeführt werden. Sie können daher auf die jeweiligen Daten der Objekte zugreifen und diese verarbeiten und verändern. Im Rahmen der objektorientierten Modellierung ist es üblich, die Variablen eines Objektes nicht direkt abzurufen und zu befüllen, sondern dies über eigene Methoden zu bewerkstelligen. Dabei handelt es sich meist im eine Get- und eine Set-Methode. Sie werden daher auch als '''Getter und Setter''' bezeichnet. Für das Beispiel in Abbildung 68 werden daher Get- und Set-Methoden für die Variablen ''Name'', ''E-Mail'', ''KundenNr'' für die Klasse ''Kunde'' und für ''UstId'' und ''Firmenname'' der ihrer Tochterklasse ''Geschäftskunde'' angelegt. Das neue Modell ist in Abbildung 69 ersichtlich.		Eine Klasse kann zusätzlich zu Variablen auch '''Methoden''' enthalten. Es handelt sich dabei um Methoden, welche innerhalb der jeweiligen Instanz der Klasse ausgeführt werden. Sie können daher auf die jeweiligen Daten der Objekte zugreifen und diese verarbeiten und verändern. Im Rahmen der objektorientierten Modellierung ist es üblich, die Variablen eines Objektes nicht direkt abzurufen und zu befüllen, sondern dies über eigene Methoden zu bewerkstelligen. Dabei handelt es sich meist im eine Get- und eine Set-Methode. Sie werden daher auch als '''Getter und Setter''' bezeichnet. Für das Beispiel in Abbildung 68 werden daher Get- und Set-Methoden für die Variablen ''Name'', ''E-Mail'', ''KundenNr'' für die Klasse ''Kunde'' und für ''UstId'' und ''Firmenname'' der ihrer Tochterklasse ''Geschäftskunde'' angelegt. Das neue Modell ist in der Abbildung "Klassen mit Get- und Set-Methoden" ersichtlich.

	<span id="_Ref406419448" class="anchor"></span>[[Datei:Wiba mt233 201607 a.074.png\|300px\|none\|thumb\|Klassen mit Get- und Set-Methoden]]		<span id="_Ref406419448" class="anchor"></span>[[Datei:Wiba mt233 201607 a.074.png\|300px\|none\|thumb\|Klassen mit Get- und Set-Methoden]]

	Eine weitere Möglichkeit bei der Vererbung von Klassen und ihrer Methoden ist die '''Überlagerung oder Polymorphie'''. Dabei können bereits in der Mutterklasse definierte Methoden erneut definiert und damit überlagert werden. Dies kann erforderlich sein, wenn der Methodenzweck sich durch die abgeleitete Klasse und ihrer konkreteren Daten verändern muss, um weiterhin ein korrektes Ergebnis zu liefern. Zur Veranschaulichung dieses Prinzips wird das Kundenbeispiel um eine Methode ''getKundenString'' erweitert. Der Zweck der Methode soll die Rückgabe einer Zeichenkette sein, welche immer alle relevanten Kundendaten enthalten soll, um sie beispielsweise später in einer Liste anzudrucken. Je nachdem, ob es sich um einen ''Kunden'' oder einen ''Geschäftskunden'' handelt, sollen die Werte ''Name'' und ''Kundennummer'', und gegebenenfalls auch der ''Firmenname'' enthalten sein. Dazu wird die neue Methode nun sowohl in der Mutterklasse ''Kunde'', als auch in der Tochterklasse ''Geschäftskunde'' definiert und dadurch für jede Instanz der Klasse ''Geschäftskunde'' in der Mutterklasse überlagert. Die Definition der überlagerten Methode ''getKundenString'' ist in Abbildung 70 ersichtlich.		Eine weitere Möglichkeit bei der Vererbung von Klassen und ihrer Methoden ist die '''Überlagerung oder Polymorphie'''. Dabei können bereits in der Mutterklasse definierte Methoden erneut definiert und damit überlagert werden. Dies kann erforderlich sein, wenn der Methodenzweck sich durch die abgeleitete Klasse und ihrer konkreteren Daten verändern muss, um weiterhin ein korrektes Ergebnis zu liefern. Zur Veranschaulichung dieses Prinzips wird das Kundenbeispiel um eine Methode ''getKundenString'' erweitert. Der Zweck der Methode soll die Rückgabe einer Zeichenkette sein, welche immer alle relevanten Kundendaten enthalten soll, um sie beispielsweise später in einer Liste anzudrucken. Je nachdem, ob es sich um einen ''Kunden'' oder einen ''Geschäftskunden'' handelt, sollen die Werte ''Name'' und ''Kundennummer'', und gegebenenfalls auch der ''Firmenname'' enthalten sein. Dazu wird die neue Methode nun sowohl in der Mutterklasse ''Kunde'', als auch in der Tochterklasse ''Geschäftskunde'' definiert und dadurch für jede Instanz der Klasse ''Geschäftskunde'' in der Mutterklasse überlagert. Die Definition der überlagerten Methode ''getKundenString'' ist in der Abbildung "Klassen mit überlagerter Methode ''getKundenString()''" ersichtlich.

	<span id="_Ref406421446" class="anchor"></span>[[Datei:Wiba mt233 201607 a.075.png\|300px\|none\|thumb\|Klassen mit überlagerter Methode <em>getKundenString()</em>]]		<span id="_Ref406421446" class="anchor"></span>[[Datei:Wiba mt233 201607 a.075.png\|300px\|none\|thumb\|Klassen mit überlagerter Methode <em>getKundenString()</em>]]

← Nächstältere Version		Version vom 31. Oktober 2023, 18:04 Uhr
Zeile 406:		Zeile 406:
	Die '''include-Beziehung''' besteht zwischen Use-Cases, die ein ähnliches Verhalten zeigen. Sie wird verwendet, um Aktionsfolgen nur einmal zu beschreiben, die aber in mehreren Use-Cases vorkommen.		Die '''include-Beziehung''' besteht zwischen Use-Cases, die ein ähnliches Verhalten zeigen. Sie wird verwendet, um Aktionsfolgen nur einmal zu beschreiben, die aber in mehreren Use-Cases vorkommen.

	In unserem Reisebüro Beispiel liegt eine include-Beziehung zwischen dem Use Case „Storniere Gruppenreise“ und „Storniere Einzelreise“ vor, da im Fall der Stornierung einer gesamten Gruppenreise alle in ihr enthaltenen Einzelreisen storniert werden müssen. Das Gruppenreisestornieren verwendet („include“) das Verhalten des Einzelreisestornieren. Graphisch lässt sich das folgendermaßen darstellen (Abbildung 89):		In unserem Reisebüro Beispiel liegt eine include-Beziehung zwischen dem Use Case „Storniere Gruppenreise“ und „Storniere Einzelreise“ vor, da im Fall der Stornierung einer gesamten Gruppenreise alle in ihr enthaltenen Einzelreisen storniert werden müssen. Das Gruppenreisestornieren verwendet („include“) das Verhalten des Einzelreisestornieren. Graphisch lässt sich das folgendermaßen darstellen (Abbildung "Include Beziehung"):

	[[Datei:Wiba mt233 201607 a.111.png\|300px\|none\|thumb\|Include Beziehung]]		[[Datei:Wiba mt233 201607 a.111.png\|300px\|none\|thumb\|Include Beziehung]]
Zeile 414:		Zeile 414:
	Die '''extend-Beziehung''' wird verwendet, um Spezialfälle zu beschreiben, d.h. Aktionsfolgen in einem durch eine extend-Beziehung verknüpften Use-Case sind optional. Man spricht auch davon, dass der Use-Case A ein zusätzliches Verhalten zum Use Case B zeigt (Hauptfall B - Nebenfall A).		Die '''extend-Beziehung''' wird verwendet, um Spezialfälle zu beschreiben, d.h. Aktionsfolgen in einem durch eine extend-Beziehung verknüpften Use-Case sind optional. Man spricht auch davon, dass der Use-Case A ein zusätzliches Verhalten zum Use Case B zeigt (Hauptfall B - Nebenfall A).

	In unserem Beispiel des Reisebüros könnte zum Beispiel bei der Buchung einer Gruppenreise eine Erweiterung zu einer Luxus-Gruppenreise durchgeführt werden. Das bedeutet, dass der Use Case der normalen Gruppenbuchung durch den Luxus-Upgrade erweitert (extend) wird. Dies lässt sich graphisch durch die <<extend>>-Beziehung darstellen (Abbildung 90):		In unserem Beispiel des Reisebüros könnte zum Beispiel bei der Buchung einer Gruppenreise eine Erweiterung zu einer Luxus-Gruppenreise durchgeführt werden. Das bedeutet, dass der Use Case der normalen Gruppenbuchung durch den Luxus-Upgrade erweitert (extend) wird. Dies lässt sich graphisch durch die <<extend>>-Beziehung darstellen (Abbildung "Extend Beziehung"):

	[[Datei:Wiba mt233 201607 a.112.png\|300px\|none\|thumb\|Extend Beziehung]]		[[Datei:Wiba mt233 201607 a.112.png\|300px\|none\|thumb\|Extend Beziehung]]
Zeile 422:		Zeile 422:
	Die '''Generalisierungsbeziehung''' ist ähnlich der Vererbung im objektorientierten Ansatz und kann auf Aktivitäten (Funktionen) und Teilnehmer (Aktors) angewendet werden. Sie sollte vor allem eingesetzt werden, um Beziehungen zwischen abstrakten und konkreten Use Cases darzustellen.		Die '''Generalisierungsbeziehung''' ist ähnlich der Vererbung im objektorientierten Ansatz und kann auf Aktivitäten (Funktionen) und Teilnehmer (Aktors) angewendet werden. Sie sollte vor allem eingesetzt werden, um Beziehungen zwischen abstrakten und konkreten Use Cases darzustellen.

	In unserem Beispiel könnten wir daher unsere Gruppenstornierung und Einzelstornierung als Spezialisierung eines abstrakten Stornierungsfalls sehen (Abbildung 91):		In unserem Beispiel könnten wir daher unsere Gruppenstornierung und Einzelstornierung als Spezialisierung eines abstrakten Stornierungsfalls sehen (Abbildung "Use Case Generalisierung"):

	[[Datei:Wiba mt233 201607 a.113.png\|300px\|none\|thumb\|Use Case Generalisierung]]		[[Datei:Wiba mt233 201607 a.113.png\|300px\|none\|thumb\|Use Case Generalisierung]]

	Wir können jetzt diese Beziehungen in unser ursprüngliches Anwendungsfalldiagramm eintragen und dadurch die Beschreibung erweitern (Abbildung 92):		Wir können jetzt diese Beziehungen in unser ursprüngliches Anwendungsfalldiagramm eintragen und dadurch die Beschreibung erweitern (Abbildung "Erweiterter Use Case Reisebüro Buchungssystem"):

	[[Datei:Wiba mt233 201607 a.114.png\|300px\|none\|thumb\|Erweiterter Use Case Reisebüro Buchungssystem]]		[[Datei:Wiba mt233 201607 a.114.png\|300px\|none\|thumb\|Erweiterter Use Case Reisebüro Buchungssystem]]
Zeile 437:		Zeile 437:

	<span id="einsatz-von-use-cases"></span>		<span id="einsatz-von-use-cases"></span>

	=== Einsatz von Use Cases ===		=== Einsatz von Use Cases ===

← Nächstältere Version		Version vom 31. Oktober 2023, 18:03 Uhr
Zeile 365:		Zeile 365:
	=== Darstellung ===		=== Darstellung ===

	Beginnen wir mit einem einfachen Beispiel für ein Anwendungsfalldiagramm, das die wichtigsten Elemente dieser Notationsform enthält (siehe Abbildung 87):		Beginnen wir mit einem einfachen Beispiel für ein Anwendungsfalldiagramm, das die wichtigsten Elemente dieser Notationsform enthält (siehe Abbildung "Anwendungsfalldiagramm Beispiel (nach Jacobson)"):

	[[Datei:Wiba mt233 201607 a.105.png\|300px\|none\|thumb\|Anwendungsfalldiagramm Beispiel (nach Jacobson)]]		[[Datei:Wiba mt233 201607 a.105.png\|300px\|none\|thumb\|Anwendungsfalldiagramm Beispiel (nach Jacobson)]]
Zeile 375:		Zeile 375:
	Wir wollen das Anwendungsfalldiagramm anhand eines weiteren Beispiels erläutern. Es soll ein Softwaresystem zur Unterstützung der Buchungen in einem Reisebüro entwickelt werden. Wir betrachten hierzu einen speziellen Aktor, nämlich den Reisebüroagenten. Die Funktionen dieses Aktors (Reisebüroagenten) sind die folgenden:		Wir wollen das Anwendungsfalldiagramm anhand eines weiteren Beispiels erläutern. Es soll ein Softwaresystem zur Unterstützung der Buchungen in einem Reisebüro entwickelt werden. Wir betrachten hierzu einen speziellen Aktor, nämlich den Reisebüroagenten. Die Funktionen dieses Aktors (Reisebüroagenten) sind die folgenden:

	{\| style="border-collapse: collapse;" border="1"		{\| style="border-collapse: collapse;" border="1"
	! width="67%" \| * Eine Reise für eine Gruppe buchen:		! width="67%" \| * Eine Reise für eine Gruppe buchen:
	<blockquote>Der Reisebüroagent bucht eine Gruppenreise, die aus mehreren Einzelreisen besteht. Die Bezahlung erfolgt erst nach der Buchung (z. B. über Kreditkarte). Jede gebuchte Einzelreise wird vom vorhandenen Reisekontingent des Reisebüros abgezogen.</blockquote>		<blockquote>Der Reisebüroagent bucht eine Gruppenreise, die aus mehreren Einzelreisen besteht. Die Bezahlung erfolgt erst nach der Buchung (z. B. über Kreditkarte). Jede gebuchte Einzelreise wird vom vorhandenen Reisekontingent des Reisebüros abgezogen.</blockquote>
Zeile 395:		Zeile 395:
	\| [[Datei:Wiba mt233 201607 a.109.png\|300px\|thumb]]		\| [[Datei:Wiba mt233 201607 a.109.png\|300px\|thumb]]
	\|}		\|}
	Wir können daher diesen Use cases in das folgende Anwendungsfalldiagramm eintragen (Abbildung 88):		Wir können daher diesen Use cases in das folgende Anwendungsfalldiagramm eintragen (Abbildung "Use Case Reisebüro Buchungssystem"):

	[[Datei:Wiba mt233 201607 a.110.png\|300px\|none\|thumb\|Use Case Reisebüro Buchungssystem]]		[[Datei:Wiba mt233 201607 a.110.png\|300px\|none\|thumb\|Use Case Reisebüro Buchungssystem]]
	<span id="beziehungen-zwischen-use-cases"></span>		<span id="beziehungen-zwischen-use-cases"></span>

	=== Beziehungen zwischen Use Cases ===		=== Beziehungen zwischen Use Cases ===

← Nächstältere Version		Version vom 31. Oktober 2023, 18:01 Uhr
Zeile 230:		Zeile 230:
	Ein '''Klassendiagramm''' beschreibt den strukturellen Aspekt des zu modellierenden Systems. Es unterstützt die objektorientierte Betrachtungsweise indem es Modellierungselemente für Klassen, ihre Eigenschaften (Attribute), ihr Verhalten (Operationen, Methoden) und ihre Beziehungen zur Verfügung stellt. Neben reinen Assoziationen wird auch die Beschreibung von Generalisations- und Aggregationsbeziehungen unterstützt.		Ein '''Klassendiagramm''' beschreibt den strukturellen Aspekt des zu modellierenden Systems. Es unterstützt die objektorientierte Betrachtungsweise indem es Modellierungselemente für Klassen, ihre Eigenschaften (Attribute), ihr Verhalten (Operationen, Methoden) und ihre Beziehungen zur Verfügung stellt. Neben reinen Assoziationen wird auch die Beschreibung von Generalisations- und Aggregationsbeziehungen unterstützt.

	Eine Klasse wird in UML durch ein Rechteck dargestellt, das in horizontale Abschnitte gegliedert wird, die den Namen der Klasse, die Attribute, Operationen und optionalen weiteren, nicht normierte, „Compartments“ für textuelle Beschreibungen, wie Verantwortlichkeiten, Ausnahmen, etc. enthalten (siehe Abbildung 71). Mit Ausnahme des Namens der Klasse können alle weiteren Beschreibungselemente fehlen.		Eine Klasse wird in UML durch ein Rechteck dargestellt, das in horizontale Abschnitte gegliedert wird, die den Namen der Klasse, die Attribute, Operationen und optionalen weiteren, nicht normierte, „Compartments“ für textuelle Beschreibungen, wie Verantwortlichkeiten, Ausnahmen, etc. enthalten (siehe Abbildung "Klassendiagramm"). Mit Ausnahme des Namens der Klasse können alle weiteren Beschreibungselemente fehlen.

	<span id="_Ref208639486" class="anchor"></span>[[Datei:Wiba mt233 201607 a.089.png\|300px\|none\|thumb\|Klassendiagramm]]		<span id="_Ref208639486" class="anchor"></span>[[Datei:Wiba mt233 201607 a.089.png\|300px\|none\|thumb\|Klassendiagramm]]
Zeile 252:		Zeile 252:
	Attribute und Operatoren können ebenfalls mit Eigenschaften versehen werden, wie beispielsweise { static } zur Kennzeichnung als statisches Element auf Klassenebene.		Attribute und Operatoren können ebenfalls mit Eigenschaften versehen werden, wie beispielsweise { static } zur Kennzeichnung als statisches Element auf Klassenebene.

	Es können weiter auch bei den Operationen Stereotype angegeben werden, die helfen, die Operationen zu gruppieren. Ein entsprechend erweitertes Beispiel ist in Abbildung 72 abgebildet.		Es können weiter auch bei den Operationen Stereotype angegeben werden, die helfen, die Operationen zu gruppieren. Ein entsprechend erweitertes Beispiel ist in Abbildung "Erweitertes Klassendiagramm" abgebildet.

	[[Datei:Wiba mt233 201607 a.090.png\|300px\|none\|thumb\|Erweitertes Klassendiagramm]]		[[Datei:Wiba mt233 201607 a.090.png\|300px\|none\|thumb\|Erweitertes Klassendiagramm]]
Zeile 258:		Zeile 258:
	Klassen erlauben auch abgeleitete Attribute zu spezifizieren. Das bedeutet, dass solche Attribute aus anderen Informationen berechnet werden. Diese Attribute werden durch einen vor den Namen gestellten Schrägstrich gekennzeichnet. Es kann auch die Berechnungsvorschrift in geschwungenen Klammern angegeben werden. Feldartige Attribute werden über eine Intervallschreibweise vereinbart.		Klassen erlauben auch abgeleitete Attribute zu spezifizieren. Das bedeutet, dass solche Attribute aus anderen Informationen berechnet werden. Diese Attribute werden durch einen vor den Namen gestellten Schrägstrich gekennzeichnet. Es kann auch die Berechnungsvorschrift in geschwungenen Klammern angegeben werden. Feldartige Attribute werden über eine Intervallschreibweise vereinbart.

	Ein Beispiel, das diese Möglichkeiten veranschaulicht, ist in der Abbildung 73 angegeben.		Ein Beispiel, das diese Möglichkeiten veranschaulicht, ist in der Abbildung "UML Klasse Angestellter" angegeben.

	[[Datei:Wiba mt233 201607 a.091.png\|300px\|none\|thumb\|UML Klasse Angestellter]]		[[Datei:Wiba mt233 201607 a.091.png\|300px\|none\|thumb\|UML Klasse Angestellter]]
Zeile 271:		Zeile 271:
	* verwendet die andere Klasse als Typ eines Attributes		* verwendet die andere Klasse als Typ eines Attributes
	* ...		* ...
	Betrachten wir hierzu folgendes Beispiel (Abbildung 74):		Betrachten wir hierzu folgendes Beispiel (Abbildung "Assoziation"):

	[[Datei:Wiba mt233 201607 a.092.png\|300px\|none\|thumb\|Assoziation]]		[[Datei:Wiba mt233 201607 a.092.png\|300px\|none\|thumb\|Assoziation]]
Zeile 279:		Zeile 279:
	UML unterstützt auch weitere Formen der Assoziationen, wie		UML unterstützt auch weitere Formen der Assoziationen, wie

	{\| style="border-collapse: collapse;" border="1"		{\| style="border-collapse: collapse;" border="1"
	! width="42%" \| * Reflexive Assoziation		! width="42%" \| * Reflexive Assoziation
	<blockquote>Diese Assoziationsform besteht zwischen Objekten derselben Klasse. Es müssen aber Rollennamen angegeben werden (Abbildung 75).</blockquote>		<blockquote>Diese Assoziationsform besteht zwischen Objekten derselben Klasse. Es müssen aber Rollennamen angegeben werden (Abbildung 75).</blockquote>
Zeile 306:		Zeile 306:
	=== Objektdiagramm ===		=== Objektdiagramm ===

	Ein '''Objektdiagramm''' zeigt eine mögliche Systemkonfiguration durch ein Menge von Objekten und ihre Verbindungen. Es stellt quasi einen Snapshot einer prototypischen Systemsituation dar. Ein Objektdiagramm muss dem Klassendiagramm entsprechen und zeigt eine mögliche Interpretation (von vielen). UML verwendet eine einheitliche Darstellung, um Instanzen von dem dazugehörigen Typ zu unterscheiden, indem die Instanz dasselbe graphische Symbol wie der Typ verwendet, jedoch der Name unterstrichen wird. Siehe hierzu Abbildung 79, die die Klasse und das entsprechende Objekt darstellt.		Ein '''Objektdiagramm''' zeigt eine mögliche Systemkonfiguration durch ein Menge von Objekten und ihre Verbindungen. Es stellt quasi einen Snapshot einer prototypischen Systemsituation dar. Ein Objektdiagramm muss dem Klassendiagramm entsprechen und zeigt eine mögliche Interpretation (von vielen). UML verwendet eine einheitliche Darstellung, um Instanzen von dem dazugehörigen Typ zu unterscheiden, indem die Instanz dasselbe graphische Symbol wie der Typ verwendet, jedoch der Name unterstrichen wird. Siehe hierzu die Abbildung "Objektdiagramm", die die Klasse und das entsprechende Objekt darstellt.

	[[Datei:Wiba mt233 201607 a.097.png\|300px\|none\|thumb\|Objektdiagramm]]		[[Datei:Wiba mt233 201607 a.097.png\|300px\|none\|thumb\|Objektdiagramm]]
Zeile 315:		Zeile 315:
	=== Generalisierung und Spezialisierung ===		=== Generalisierung und Spezialisierung ===

	Die '''Generalisierung''' stellt eine hierarchische Beziehung zwischen einer allgemeineren Klasse (Oberklasse) und einer spezialisierten Klasse (Unterklasse) dar. Wir bezeichnen diese Generalisierung als eine IS-A Beziehung. Die Unterklasse erbt die Eigenschaften der Oberklasse, kann aber weitere spezifische Eigenschaften hinzufügen. In UML kennzeichnet man diese Generalisierungshierarchie durch einen nicht ausgefüllten Pfeil. Siehe hierzu folgendes Beispiel (Abbildung 80):		Die '''Generalisierung''' stellt eine hierarchische Beziehung zwischen einer allgemeineren Klasse (Oberklasse) und einer spezialisierten Klasse (Unterklasse) dar. Wir bezeichnen diese Generalisierung als eine IS-A Beziehung. Die Unterklasse erbt die Eigenschaften der Oberklasse, kann aber weitere spezifische Eigenschaften hinzufügen. In UML kennzeichnet man diese Generalisierungshierarchie durch einen nicht ausgefüllten Pfeil. Siehe hierzu folgendes Beispiel (Abbildung "UML Generalisierung"):

	[[Datei:Wiba mt233 201607 a.098.png\|300px\|none\|thumb\|UML Generalisierung]]		[[Datei:Wiba mt233 201607 a.098.png\|300px\|none\|thumb\|UML Generalisierung]]
Zeile 323:		Zeile 323:
	* überlappend / exklusiv entspricht overlapping / disjoint (UML) und		* überlappend / exklusiv entspricht overlapping / disjoint (UML) und
	* Total / Partiell entspricht complete / incomplete (UML).		* Total / Partiell entspricht complete / incomplete (UML).
	Siehe hierzu das erläuternde Beispiel in Abbildung 81:		Siehe hierzu das erläuternde Beispiel in der Abbildung "UML Überdeckung":

	[[Datei:Wiba mt233 201607 a.099.png\|300px\|none\|thumb\|UML Überdeckung]]		[[Datei:Wiba mt233 201607 a.099.png\|300px\|none\|thumb\|UML Überdeckung]]
Zeile 329:		Zeile 329:
	=== Mehrfachvererbungen ===		=== Mehrfachvererbungen ===

	UML unterstützt auch die Notation von '''Mehrfachvererbungen'''. Siehe hierzu das folgende Beispiel in Abbildung 82:		UML unterstützt auch die Notation von '''Mehrfachvererbungen'''. Siehe hierzu das folgende Beispiel in der Abbildung UML Mehrfachvererbung:

	[[Datei:Wiba mt233 201607 a.100.png\|300px\|none\|thumb\|UML Mehrfachvererbung]]		[[Datei:Wiba mt233 201607 a.100.png\|300px\|none\|thumb\|UML Mehrfachvererbung]]
Zeile 335:		Zeile 335:
	=== Aggregation ===		=== Aggregation ===

	Die '''Aggregation''' ist eine spezielle Form der Assoziation, die anzeigt, dass ein Objekt einer Klasse Teil eines Objektes einer anderen Klasse ist. Wir bezeichnen dieses Beziehung daher als „part-of“ / “has-a“ Beziehung („teil-von“ / „hat-ein“). Auch Aggregationen können (und sollten) einen Namen haben. Es kann auch hier die Multiplizität angegeben werden. Wir verwenden hierzu in UML die nicht ausgefüllte Raute. Siehe hierzu das folgende Beispiel (Abbildung 83):		Die '''Aggregation''' ist eine spezielle Form der Assoziation, die anzeigt, dass ein Objekt einer Klasse Teil eines Objektes einer anderen Klasse ist. Wir bezeichnen dieses Beziehung daher als „part-of“ / “has-a“ Beziehung („teil-von“ / „hat-ein“). Auch Aggregationen können (und sollten) einen Namen haben. Es kann auch hier die Multiplizität angegeben werden. Wir verwenden hierzu in UML die nicht ausgefüllte Raute. Siehe hierzu das folgende Beispiel (Abbildung "UML Aggregration"):

	[[Datei:Wiba mt233 201607 a.101.png\|300px\|none\|thumb\|UML Aggregation]]		[[Datei:Wiba mt233 201607 a.101.png\|300px\|none\|thumb\|UML Aggregation]]
Zeile 341:		Zeile 341:
	=== Komposition ===		=== Komposition ===

	Eine strengere Form der Aggregation ist die '''Komposition''', bei der der Teil nur Kompositionsteil '''eines''' Ganzen sein darf. Das Kompositum ist auch für das Erzeugen und Zerstören des Teils verantwortlich. In UML wird dazu die ausgefüllte Raute verwendet. Siehe das folgende Beispiel (Abbildung 84):		Eine strengere Form der Aggregation ist die '''Komposition''', bei der der Teil nur Kompositionsteil '''eines''' Ganzen sein darf. Das Kompositum ist auch für das Erzeugen und Zerstören des Teils verantwortlich. In UML wird dazu die ausgefüllte Raute verwendet. Siehe das folgende Beispiel (Abbildung "UML Komposition"):

	[[Datei:Wiba mt233 201607 a.102.png\|300px\|none\|thumb\|UML Komposition]]		[[Datei:Wiba mt233 201607 a.102.png\|300px\|none\|thumb\|UML Komposition]]
Zeile 347:		Zeile 347:
	Das Kompositum („Ganze“) darf in der Kompositionsassoziation nur einmal oder keinmal auftreten, daher darf die Multiplizität auf Seiten des Kompositums nur 1 oder 0..1 sein.		Das Kompositum („Ganze“) darf in der Kompositionsassoziation nur einmal oder keinmal auftreten, daher darf die Multiplizität auf Seiten des Kompositums nur 1 oder 0..1 sein.

	In den nachfolgenden, etwas umfangreicheren, Beispielen (Abbildung 85 und Abbildung 86) sind die Ausschnitte zweier Realitäten modelliert, eine Fachhochschule und eine Bank. Sie erkennen hier den Einsatz von Generalisation und Aggregation.		In den nachfolgenden, etwas umfangreicheren, Beispielen (Abbildung " UML Beispiel Fachhochschule" und Abbildung " UML Beispiel Bank") sind die Ausschnitte zweier Realitäten modelliert, eine Fachhochschule und eine Bank. Sie erkennen hier den Einsatz von Generalisation und Aggregation.

	[[Datei:Wiba mt233 201607 a.103.png\|300px\|none\|thumb\| UML Beispiel Fachhochschule]][[Datei:Wiba mt233 201607 a.104.png\|300px\|none\|thumb\|UML Beispiel Bank]]		[[Datei:Wiba mt233 201607 a.103.png\|300px\|none\|thumb\| UML Beispiel Fachhochschule]][[Datei:Wiba mt233 201607 a.104.png\|300px\|none\|thumb\|UML Beispiel Bank]]
	<span id="uml-anwendungsfalldiagramm-use-case-diagramm"></span>		<span id="uml-anwendungsfalldiagramm-use-case-diagramm"></span>

	== UML Anwendungsfalldiagramm (Use Case Diagramm) ==		== UML Anwendungsfalldiagramm (Use Case Diagramm) ==