Ein übergeordneter Anwendungsfall kann in mehrere untergeordnete Anwendungsfälle unterteilt werden, die spezifische
Formen des übergeordneten Anwendungsfalls darstellen. Weder der übergeordnete noch der untergeordnete Anwendungsfall
müssen zwingenderweise abstrakt sein, obwohl es der übergeordnete in den meisten Fällen ist. Ein untergeordneter
Anwendungsfall erbt die gesamte Struktur, das Verhalten und die Beziehungen des übergeordneten Anwendungsfalls.
Untergeordnete Anwendungsfälle desselben übergeordneten Anwendungsfalls sind alles spezialisierte Versionen des
übergeordneten Anwendungsfalls. Diese Generalisierung gilt für Anwendungsfälle. Weitere Informationen zum Konzept der
Generalisierung für Klassen finden Sie auf der Seite Richtlinie:
Generalisierung.
Generalisierung wird verwendet, wenn Sie zwei oder mehr Anwendungsfälle finden, die Gemeinsamkeiten in Verhalten,
Struktur und Zweck aufweisen. In diesem Fall können Sie die gemeinsam Teile in einem neuen, häufig abstrakten
Anwendungsfall beschreiben, der anschließend in untergeordneten Anwendungsfällen spezialisiert wird.
Beispiel:
Die Anwendungsfälle "Telefonische Bestellung" und "Internet-Bestellung" sind spezialisierte Versionen des abstrakten
Anwendungsfalls "Bestellung aufgeben".
In einem Auftragsverwaltungssystem haben die Anwendungsfälle "Telefonische Bestellung" und "Internet-Bestellung" viele
Gemeinsamen in Struktur und Verhalten. Es wird ein allgemeiner Anwendungsfall "Bestellung aufgeben" definiert, in dem
diese Struktur und das gemeinsame Verhalten definiert werden. Der abstrakte Anwendungsfall "Bestellung aufgeben" muss
an sich nicht vollständig sein, sondern ist ein allgemeines Verhaltens-Framework, das von den untergeordneten
Anwendungsfällen vervollständigt werden kann.
Der übergeordnete Anwendungsfall ist nicht immer abstrakt.
Beispiel:
Stellen Sie sich das Auftragsverwaltungssystem aus dem vorherigen Beispiel vor. Sagen wir, Sie möchten einen Akteur
"Auftragserfasser" hinzufügen, der Aufträge oder Bestelllungen für einen Kunden in das System eingeben kann. Dieser
Akteur würde den allgemeinen Anwendungsfall "Bestellung aufgeben" einleiten, für den jetzt ein vollständiger
Ereignisablauf beschrieben sein muss. Der untergeordnete Anwendungsfall kann der Struktur des übergeordneten
Anwendungsfalls Verhalten hinzufügen und das Verhalten im übergeordneten Anwendungsfall ändern.
Der Akteur "Auftragserfasser" kann den allgemeinen Anwendungsfall "Bestellung aufgeben" instanzieren. Der
Anwendungsfall "Bestellung abgeben" kann auch von den Anwendungsfällen "Telefonische Bestellung" und
"Internet-Bestellung" spezialisiert werden.
Der untergeordnete Anwendungsfall ist von der Struktur (siehe Richtlinie:
Anwendungsfall, wo der Ereignisablauf beschrieben wird) des übergeordneten Anwendungsfalls abhängig. Der
untergeordnete Anwendungsfall kann dem übergeordneten Anwendungsfall zusätzliches Verhalten hinzufügen, indem
Verhaltenssegmente in das geerbte Verhalten eingefügt werden oder indem Einschluss- und Erweiterungsbeziehungen für den
untergeordneten Anwendungsfall deklariert werden. Der untergeordnete Anwendungsfall kann vom übergeordneten
Anwendungsfall geerbte Verhaltenssegmente ändern. Hierbei muss jedoch mit Sorgfalt vorgegangen werden, um den Zweck des
übergeordneten Anwendungsfalls nicht zu beeinträchtigten. Die Struktur des übergeordneten Anwendungsfalls wird vom
untergeordneten Anwendungsfall beibehalten. Das bedeutet, dass alle Verhaltenssegmente, die als Schritte oder
untergeordnete Abläufe des übergeordneten Ereignisablaufs geändert werden kann.
Wenn der übergeordnete Anwendungsfall abstrakt ist, können die Verhaltenssegmente unvollständig sein. Der
untergeordnete Anwendungsfall muss dann diese Verhaltenssegmente vervollständigen und sie für den Akteur mit Bedeutung
füllen.
Ein übergeordneter Anwendungsfall muss keine Beziehung zu einem Akteur haben, wenn er ein abstrakter Anwendungsfall
ist.
Wenn zwei untergeordnete Anwendungsfälle denselben übergeordneten (oder Basis-) Anwendungsfall spezialisieren, sind die
Spezialisierungen voneinander unabhängig, d. h. sie werden in gesonderten Anwendungsfallinstanzen ausgeführt. Dies
unterscheidet sich von Erweiterungs- und Einschlussbeziehungen, bei denen mehrere Zusätze eine Anwendungsfallinstanz
implizit oder explizit ändern, die denselben Basisanwendungsfall ausführt.
Anwendungsfallgeneralisierung und Einschlussbeziehung können verwendet werden, um Verhalten in mehreren
Anwendungsfällen im Modell wiederzuverwenden. Der Unterschied besteht darin, dass bei der Anwendungsfallgeneralisierung
die Ausführung des untergeordneten Anwendungsfalls von der Struktur und dem Verhalten des übergeordneten
Anwendungsfalls (dem wiederverwendeten) Teil abhängig ist, während in einer Einschlussbeziehung die Ausführung des
Basisanwendungsfalls nur vom Ergebnis der Funktion abhängig ist, die der Einschlussanwendungsfall (der wiederverwendete
Teil) ausführt. Ein weiterer Unterschied ist der, dass in einer Generalisierung die untergeordneten Anwendungsfälle
Gemeinsamkeiten in Zweck und Struktur aufweisen, während in der Einschlussbeziehung die Basisanwendungsfälle, die
denselben Einschlussanwendungsfall verwenden, völlig unterschiedliche Zielsetzungen haben können und nur voraussetzen,
dass dieselbe Funktion ausgeführt wird.
Eine Anwendungsfallinstanz, die einen untergeordneten Anwendungsfall ausführt, folgt dem Ereignisablauf, der für den
übergeordneten Anwendungsfall beschrieben ist, und fügt zusätzliches und geändertes Verhalten ein, das im
Ereignisablauf des untergeordneten Anwendungsfalls beschrieben ist.
Die Anwendungsfallinstanz folgt dem übergeordneten Anwendungsfall und fügt neues und geändertes Verhalten ein, das im
untergeordneten Anwendungsfall beschrieben ist.
Im Allgemeinen wird die Generalisierungsbeziehung selbst nicht beschrieben. Stattdessen geben Sie im Ereignisablauf des
untergeordneten Anwendungsfalls an, wie neue Schritte in das geerbte Verhalten eingefügt werden und wie das geerbte
Verhalten geändert wird.
Wenn der untergeordnete Anwendungsfall mehrere übergeordnete Anwendungsfälle spezialisiert (Mehrfachvererbung), müssen
Sie in der Spezifikation des untergeordneten Anwendungsfalls explizit angeben, wie die Verhaltenssequenzen der
übergeordneten Anwendungsfälle im untergeordneten Anwendungsfall verzahnt werden.
Schauen Sie sich die folgenden schrittweisen Anleitungen für Anwendungsfälle für ein einfaches Telefonsystem an:
Ortsgespräch führen
-
Anrufer hebt den Hörer ab.
-
System lässt einen Wählton ertönen.
-
Anrufer wählt eine Ziffer.
-
System schaltet den Wählton ab.
-
Anrufer wählt den Rest der Nummer.
-
System analysiert die Nummer.
-
System findet den entsprechenden Teilnehmer.
-
System verbindet die Teilnehmer.
-
Teilnehmer legen auf.
Ferngespräch führen
-
Anrufer hebt den Hörer ab.
-
System lässt einen Wählton ertönen.
-
Anrufer wählt eine Ziffer.
-
System schaltet den Wählton ab.
-
Anrufer wählt den Rest der Nummer.
-
System analysiert die Nummer.
-
System sendet Nummer an anderes System.
-
System verbindet die Leitungen.
-
Teilnehmer legen auf.
Der in blau angezeigte Test ist in den beiden Anwendungsfällen sehr ähnlich. Wenn die
beiden Anwendungsfälle so ähnlich sind, sollten Sie sie zu einem zusammenführen, in dem alternative untergeordnete
Abläufe den Unterschied zwischen Ortsgesprächen und Ferngesprächen aufzeigen.
Wenn die Unterschiede zwischen den beiden Anwendungsfällen jedoch erheblich sind und es Sinn macht, die Beziehung
zwischen Ortsgespräch und Ferngespräch im Anwendungsfall klar aufzuzeigen, kann das gemeinsame Verhalten in einen
neuen, allgemeineren Anwendungsfall, z. B. Anruf tätigen, extrahiert werden.
In einem Anwendungsfalldiagramm wird die erstellte Generalisierungsbeziehung wie folgt veranschaulicht:
Die Anwendungsfälle "Ortsgespräch führen" und "Ferngespräch führen" werden aus dem abstrakten Anwendungsfall "Anruf
tätigen" übernommen.
|