In diesem Kapitel wird die Kurzbezeichnung Methode AF für alle Theorieelemente zur Erfassung und Darstellung von Anwendungsfällen eingeführt.

11.1 Einführung

Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Anwendungsfälle (use cases) informelle Beschreibungen von Verhalten [OMG 2003a, S. 370].

Einordnung

Um was geht’s?

Anwendungsfälle [Anmerkung] (use cases) beschreiben, was ein System leisten soll. Da diese Leistung immer mit den Nutzern des Systems zu tun hat, erläutern sie damit das Zusammenwirken von Anwendern mit dem System. Dies drückt auch die Definition der UML-Autoren aus:

“A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.” [OMG 2003a, S. 519]

Damit ist es die Aufgabe der Anwendungsfälle, die durch ein System benötigte Funktionalität zu erfassen:

“The purpose of use cases is to identify the required functionality of a system” [OMG 2003a, S. 522].

Dass die Beschreibung des Umgangs mit einem System durchaus zwei Aspekte hat, sehen auch die Urheber der UML: zum einen die von „außen“ kommenden Anforderungen an das System („specification of the (external) requirements on a subject “ [OMG 2003a, S. 519]), zum anderen die Funktionalität, die das System anbietet („specification of the functionality offered by a subject“ [ebenda]):

Zwei Aspekte

• Anforderungen an das System (Ausgangspunkt: Systemaußenwelt)
• Verhalten (Leistung) des Systems (Ausgangspunkt: das System als solches)

Beides kann, muss aber nicht übereinstimmen. Die praktischen Beispiele in der Literatur zeigen allerdings fast immer nur die zweite Sicht. Dabei wäre die erste, gerade wenn man an die Modellierung von Geschäftsprozessen denkt, auch wichtig. Denn die Modellierung von Geschäftsprozessen ist sehr stark dadurch geprägt, dass auch Verhalten beschrieben wird, das noch nicht in der Software (die ja hier letzendlich aus dem System entstehen soll) verankert ist oder dort gar nie verankert werden kann.

Exkurs: Subject (im Sprachgebrauch der UML)

„subject“

In den Texten der UML-Autoren spürt man nur selten Unsicherheit. Eine dieser Stellen findet sich bei den Ausführungen zu Anwendungsfällen (use cases). Hier ist, bei der Aufzählung der Elemente, die einen Anwendungsfall ausmachen, recht unvermittelt von „subject“ die Rede: “The key concepts associated with use cases are actors, use cases, and the subject” [OMG 2003a, S. 503]. Dies wird dann auch gleich präzisiert: “The subject is the system under consideration to which the use cases apply” [ebenda].

In früheren Texten und an anderen Stellen war und ist hier von „system“, „subsystem“ oder auch „class“ die Rede, wie z.B. das folgende Zitat zeigt: „A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested ….” [OMG 1999, S. 3-91]

Die Hervorhebungen wurden vom Verfasser vorgenommen.

Dem Sprachgebrauch kann entnommen werden, dass mit dem Begriff subject hier tatsächlich ein Teilsystem gemeint ist: der Teil des System, auf den sich die Anwendungsfälle beziehen.

Teilsystem

normalxxx

normal

Es wird nicht ganz klar in den Texten der UML-Autoren, aber die Wahl des neuen Begriffs „subject“ könnte – in Bezug auf die Anwendungsfälle – eine teilweise Loslösung vom Systembegriff bedeuten, hin zu etwas, was man mit „inhaltlichem Gegenstand“ oder „Vorgang“ oder auch „Geschäftsprozess“ übersetzen kann [Anmerkung] . Darin könnte der Versuch zum Ausdruck kommen, etwas näher an die Beschreibung von Abläufen zu kommen.

Der Sprachgebrauch zeigt aber auch sehr deutlich, dass die Autoren ein subject als etwas aktives ansehen, etwas das Verhalten hat. Dies wäre dann nicht so sehr mit dem Geschäftsprozesskonzept vereinbar. Ein Geschäftsprozess ist selbst nicht aktiv (in diesem Sinne), aber in ihm sind Systeme und Menschen tätig, die für sich und für ihn (den Geschäftsprozess) aktiv sind.

Um die Verwirrung nicht zu groß werden zu lassen, wird im folgenden von System die Rede sein, wenn im UML-Text subject steht. Sollte die Nutzung des Begriffs subject allerdings eine Überwindung des engeren Systembegriffs andeuten wird darauf hingewiesen.

11.2 Grundlagen

11.2.1 Elemente

Ein Anwendungsfalldiagramm besteht in der Grundstruktur aus (normalerweise mehreren) Anwendungsfällen (die Funktionalität/Verhalten benennen), Strichmenschen (die die Nutzer des gesamten Anwendungsfalls darstellen) und verbindenden Linien.

Begrifflich gibt es in der Literatur manchmal eine Unklarheit. Da wird die Gesamtbeschreibung (das gesamte Anwendungsfalldiagramm) ebenfalls als Anwendungsfall bezeichnet, obwohl dies eigentlich die Bezeichnung für die einzelnen Komponenten ist.

Hinweis

11.2.2 Anwendungsfälle (im engeren Sinn)

Jeder Anwendungsfall repräsentiert ein Verhalten (so sehen es die UML-Autoren tatsächlich), ein einzelnes Verhalten, das ein System leisten kann in Zusammenarbeit mit einem oder mehreren Akteuren. Die interne Struktur des Verhaltens wird nicht dargestellt.

Dieses Verhalten (im Englischen können die UML-Autoren hier die Mehrzahl “behaviors” verwenden) kann zu Änderungen im Zustand des Systems führen und zur Kommunikation mit der Systemumgebung.

Verhaltensweisen, die Änderungen bewirken

Ein Anwendungsfall kann Variationen seines Grundverhaltens enthalten, darunter auch solche zu Sonderfällen und zur Fehlerbehandlung. Dazu unten mehr.

Varianten

Wechselt man die Perspektive, kann man auch definieren, dass jeder Anwendungsfall ein Stück sinnvolle Funktionalität festlegt, die das System dem Nutzer liefert.

Um eine Beschreibung, die stärker das Umfeld von Geschäftsprozessen berücksichtigt, bemüht sich Oestereich. Er beschreibt den Umfang dessen, was Anwendungsfälle leisten, wie folgt:

„Der Kontext eines Anwendungsfalls ist normalerweise begrenzt durch das, was ein Benutzer in einem Arbeitsgang an einem Anwendungssystem macht, um einen Geschäftsvorfall aus einem Geschäftsprozess zu bearbeiten.“ [Oestereich 1998, S. 207]

„Ein Anwendungsfall beschreibt einen typischen Arbeitsablauf.“ [ebenda]

Hier würde besser „benennt“ statt „beschreibt“ stehen, denn natürlich wird mit diesem Modellinstrumentarium der jeweilig Ablauf nicht beschrieben.

Geschäftsvorfälle definiert er wie folgt:

Beispiele für Anwendungsfälle

„...beispielsweise die schriftliche Schadensmeldung eines Hausrat-Versicherten. Der Geschäftsprozess (z.B „Schadensmeldung Hausrat“) beschreibt den gesamten Ablauf, um ein solches Ereignis zu verarbeiten. Der Geschäftsprozess enthält dabei unter Umständen auch Aktivitäten, die nicht direkt durch die zu entwickelnde Anwendung unterstützt werden (z.B. „Besichtigung des Schadenortes durch einen Sachverständigen“).“ [Oestereich 1998, S. 215]

Damit sind auch wichtige Abgrenzungen gegeben. Es ist aber auch geklärt, dass Anwendungsfälle nicht Geschäftsprozesse beschreiben, sondern einzelne Aufgaben.

Zurück zu den UML-Autoren, die wesentlich näher am Systembegriff sind. Dies zeigt auch die Antwort auf die Frage, was alles Gegenstand eines Anwendungsfalls sein kann, was also Verhalten haben kann [OMG 2003a, S. 519]:

Was kann alles Verhalten haben?

• ein physisches System
• eine Komponente eines Systems
• ein Subsystem
• eine Klasse

Nun hat so ein Anwendungsfalldiagramm mit seiner Sammlung von Anwendungsfällen recht wenig Aussagekraft. Es legt lediglich die geforderte bzw. geleistete Funktionalität fest. Deshalb weisen die UML-Autoren auf die verschiedenen Möglichkeiten hin, einen Anwendungsfall (genauer: sein Verhalten) näher zu beschreiben:

• durch Interaktionen, Aktivitäten und Zustandsautomaten
• durch Vor- und Nachbedingungen
• durch natürlichsprachigen Text
• indirekt durch eine Kollaboration, die den Anwendungsfall benutzt.

Die grafische Darstellung ist wie folgt: Jeder Anwendungsfall ist in einer beschrifteten Ellipse, zusammengehörige Anwendungsfälle sind mit einem Rechteck umrandet, Strichmenschen stellen die Akteure dar, Strichmenschen und Anwendungsfälle sind durch Linien in Beziehung gesetzt.

Grafische Darstellung

Die Kurzbezeichnung in der Ellipse oder darunter kann natürlich nur andeuten, um was es bei der jeweiligen Tätigkeit geht. Etwa so wie bei Ereignisgesteuerten Prozessketten die Bezeichnung einer Funktion. Deshalb schlagen die UML-Autoren die oben angeführten zusätzlichen Beschreibungen des „detaillierten Verhaltens“ des Anwendungsfalls vor, abhängig von der Beschreibungstechnik als Diagramm oder als Textdokument [OMG 2003a, S. 522].

Abschließend noch ein Hinweis von Fowler und Scott, wie man Anwendungsfälle findet:

„Eine gute Quelle zur Identifikation von Anwendungsfällen sind externe Ereignisse. Denken sie über alle Ereignisse aus der Außenwelt nach, auf die reagiert werden soll.“ [Fowler und Scott 1998, S. 57]

11.2.3 Akteure

Als Akteure (actors) werden die Nutzer des Systems bezeichnet. Dies sind (menschliche) Nutzer oder auch andere Systeme. Wichtig ist, dass beide extern, d.h. außerhalb des (Teil-)Systems, angesiedelt sind:

Nutzer der
Anwendungsfälle

“Actors always model entities that are outside the system.” [OMG 2003a, S. 511]

Die Akteure (actors) werden mithilfe der spezifischen Aufgaben, die sie im Umgang mit dem System haben (Rollen) definiert:

„An actor specifies a role played by a user or any other system that interacts with the subject.” [OMG 2003a, S. 512]

Damit kann ein Akteur mehrfach mit unterschiedlichen Rollen auftreten.

Die Interaktion eines Akteurs mit dem System kann z.B. darin bestehen, Signale oder Daten auszutauschen. Dies können die Eingaben eines Menschen am Geldautomaten sein oder die Daten, die eine externe Software vom Geldautomaten anfordert um den Zahlungsausgang zu überwachen.

Interaktion

Grafische Darstellung

Ein Akteur wird durch einen Strichmenschen dargestellt, dem die Bezeichnung des Akteurs zugeordnet wird.

Eine alternative Darstellung für Akteure ist die als „Klassenrechteck“ (class rectangle) mit dem Schlüsselwort <<actor>> und der Bezeichnung des Akteurs.

11.3 Einführende Beispiele

Prozessbeispiel Personalwesen

Auch Anwendungsfälle werden grafisch dargestellt. Ein solches Anwendungsfalldiagramm zeigt die folgende Abbildung. Es ist sehr einfach, gibt aber die Grundstruktur wieder.

Abbildungen für Anwendungsfälle

Dabei bedeuten die Ellipsen mit ihrer Beschriftung die einzelnen Anwendungsfälle, die mit bestimmten Objekten (hier den Angestellten eines Unternehmens) stattfinden können. Das Rechteck um die beschrifteten Ellipsen drückt die Zusammengehörigkeit aus (und grenzt somit das System oder das „subject“ ab, vgl. oben). Die ebenfalls beschrifteten Strichmenschen symbolisieren diejenigen, die mit dem System (bzw. subject) umgehen. Die Linien zwischen Strichmenschen und Ellipsen drücken aus, wer welche Anwendungsfälle nutzt, d.h. welche Tätigkeit ausführt.

Systembeispiel Mahnwesen

Hier geht es um die Aktivitäten rund um das Mahnwesen eines Unternehmens. Bei der Erstellung muss die Frage geklärt werden, welche Aufgaben ein solches System zu leisten hat. Hier sind ohne Schwierigkeit folgende erkennbar:

• Feststellen der Zahlungsrückstände durch einen Abgleich von Zahlungseingängen und offenen Posten.
• Gegebenenfalls Erstellen und Versenden eines Zahlungshinweises (Erinnerung, 2. Erinnerung, 1. Mahnung, 2. Mahnung).
• Gegebenenfalls Senden eines Hinweises an die Abteilung Buchhaltung (z.B. wenn „Nichteintreibbarkeit“ geklärt werden muß).
• Gegebenenfalls Beauftragung eines Inkassobüros durch die Abteilung Buchhaltung.
• Verarbeiten eines Widerspruches, den ein Kunde eingelegt hat, z.B. mit dem Hinweis, dass schon bezahlt wurde.
• Verarbeiten einer Zahlung durch einen Kunden, die nach einem Zahlungshinweis erfolgt.

Damit ergibt sich das folgende Anwendungsfalldiagramm.

Anmerkung zum Strichmenschen Client: In der objektorientierten Programmierung wird mit Client das Programm bezeichnet, das die Methoden einer Klasse nutzt. Deshalb hier der ensprechende Strichmensch.

Soweit die Grundstruktur. Im folgenden wird diese nun schrittweise erweitert und vertieft.

11.4 Vertiefung

11.4.1 Extend-Beziehung

Zwischen Anwendungsfällen kann es Beziehungen geben. Eine davon wird benutzt, wenn zusätzliches Verhalten zum Verhalten eines anderen Anwendungsfalls hinzugefügt werden soll. Sie wird Extend - Beziehung genannt. Liegen z.B. zwei Anwendungsfälle AF1 und AF2 vor, besagt diese Beziehung, dass AF1 in AF2 eingefügt werden kann, aber nicht muss. Die UML-Autoren sprechen dann von dem extending use case und dem extended use case und definieren die Beziehung so, dass ...

Beziehung zwischen Anwendungsfällen

„… the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case” [OMG 2003a, S. 515].

extending use case
und
extended use case

Die Beziehung ist gerichtet. Man benutzt sie bei Anwendungsfällen, „die einem anderen Anwendungsfall ähnlich sind, aber noch ein wenig mehr bewerkstelligen“ [Fowler und Scott 1998, S. 58]. Sie führen das Beispiel eines Anwendungsfalls an, der Handel durchführen modelliert. Dieser beschreibt dann den Standardfall, bei dem alles glatt geht. Modelliert man auch Nicht-Standardsituationen (z.B. die Überschreitung des Maximalbetrags oder andere mögliche Abweichungen) werden diese in den Erweiterungen des Anwendungsfalles festgehalten.

Standard-
und
Nicht-Standard-Situationen

Fowler und Scott empfehlen, bei der Beschreibung des „normalen“ Anwendungsfalls bei jedem Schritt zu überlegen, was schief gehen kann und diese Variationen als Erweiterungen des Anwendungsfalles zu modellieren [Fowler und Scott 1998, S. 58].

Extension Point

Ein extension point gibt die Stelle im Verhalten eines Anwendungsfalls an, bei der sein Verhalten erweitert werden soll im Sinne der oben beschriebenen Extend-Beziehung. Er wird an der Pfeillinie, die die Extend-Beziehung angibt (vgl. unten), als kleiner Kreis angebracht und mit einem Text versehen, der die Bedingung angibt, unter der es zur Weiterung kommt.

Gezielte Erweiterung

Wird der erweiterte Anwendungsfall dann ausgeführt und der extension point erreicht, erfolgt die Prüfung, ob die Bedingung wahr ist. Falls ja, wird das Verhalten der Erweiterung ebenfalls ausgeführt.

Die grafische Darstellung einer Extend-Beziehung erfolgt durch einen gestrichelten gerichteten Pfeil, der mit <<extends>> beschriftet ist. Die Pfeilrichtung ist von dem Anwendungsfall, der die Erweiterung liefert, zu dem, der sie erhält [OMG 2003a, S. 516].

Grafische Darstellung der Extend-Beziehung

Beispiele

Das erste Beispiel enthält zwei Anwendungsfälle: Online-Hilfe und Geldautomat-Transaktion. Der zweitgenannte Anwendungsfall hat einen extension point „Auswahl“. Durch diesen wird der Anwendungsfall erweitert, und zwar um die Online-Hilfe. Damit wird dokumentiert, dass der Nutzer im Bedarfsfall die Online-Hilfe des Systems aufrufen kann.

Das zweite Beispiel entstammt wieder dem Anwendungsbereich Mahnwesen. Stellen wir uns vor, dass die Anwendung bei der Bearbeitung der Zahlungsrückstände (Abgleich Offene Posten mit Zahlungseingängen) normalerweise klar kommt, insbesondere weil bei den Zahlungshinweisen ausdrücklich ein Text für den Betreff der Überweisung vorgegeben wird. In Ausnahmefällen kommt es aber vor, dass der Betreff falsch ist. Dann muss die Funktionalität hinter dem Anwendungsfall Unklaren Betreff bearbeiten hinzugezogen werden.

Unklarer Betreff im Mahnwesen

11.4.2 Include - Beziehung

Eine Include - Beziehung (include relationship) wird verwendet, wenn ein Verhaltensanteil in verschiedenen Anwendungsfällen gleich ist. Dann wird dieser aus allen, in denen er vorkommt, ausgelagert in einen eigenen Anwendungsfall. Damit handelt es sich um eine gerichtete Beziehung, z.B. von einem Anwendungsfall AF1 zu einem Anwendungsfall AF2. Sie besagt (in diesem Beispiel), dass bei Ausführung des Falls AF1 der Anwendungsfall AF2 immer ebenfalls ausgeführt werden muss. AF1 enthält (als Aufgabe) AF2. Somit gilt:

Auslagerung von Verhalten

„An include relationship defines that a use case contains the behavior defined in another use case” [OMG 2003a, S. 517].

Die grafische Darstellung erfolgt durch einen gerichteten gestrichelten Pfeil mit der Beschriftung <<includes>>.

Beispiele

Das erste Beispiel zeigt zwei Anwendungsfälle. Zum einen Abhebung, zum anderen einen unabhängig davon definierten Anwendungsfall Kartenidentifikation. Die Beziehung ist wie folgt: Soll eine Abhebung am Geldautomaten stattfinden, muss eine Kartenidentifikation erfolgen. Dies kann wie in der folgenden Abbildung modelliert werden.

Die Include-Beziehung erlaubt somit, Teilaufgaben in einen eigenen Anwendungsfall auszugliedern, sei es zur Hierarchisierung der Gesamtaufgabe, sei es als Hinweis auf eine Mehrfachverwendbarkeit. Dies zeigt auch das zweite Beispiel.

11.5 Beispiele

11.5.1 Systembeispiel Mahnwesen – integriert

Das erste Beispiel fasst die oben schon angeführten Anwendungsfälle zusammen und ist um weitere Include-Beziehungen erweitert. In diesen ist jeweils ein Anwendungsfall für das Formulieren des Zahlungshinweises (Erinnerung, 1. Mahnung, usw.) modelliert.

Das Beispiel zeigt auch, dass Anwendungsfälle fast beliebig erweiterbar sind. Durch Ausnahmen bzw. Sonderfälle (Extend-Beziehung), durch Abgrenzung von Teilaufgaben (Include-Beziehung) sowie ganz allgemein durch die mehr oder weniger große Detaillierung von Aufgaben.

Sinnvoll ist aber tatsächlich, wie ja oben schon ausgeführt, eine Orientierung an den vom System oder Geschäftsprozess erwarteten Funktionalitäten.

11.5.2 Prozessbeispiel Kunde und Lieferant

Das Beispiel stammt aus [Marshall 2000]. Es wurde auch deshalb ausgewählt, weil es bewusst auf Geschäftsprozesse zielt und eine hohe Aggregierung in den Anwendungsfällen aufweist. Die vier Anwendungsfälle

• Anfrage
• Kalkulation
• Auftrag
• Lieferung

bedürfen sicher keiner Erläuterung. Zwei davon werden von Kunden, die anderen zwei von Lieferanten genutzt.

Die Aussagekraft eines solchen Anwendungsfalldiagramms ist gering. Es kann höchstens dazu dienen, ganz grob die gewünschte Funktionalität einer Anwendung zu beschreiben.

11.5.3 Prozessbeispiel Versicherungswesen

Auch das folgende Beispiel (von [Eriksson und Penker 2000]) ist eher bei Geschäftsprozessen angesiedelt als bei Systemen. Beschrieben wird, so die Autoren, ein Modell für ein Versicherungsinformationssystem. Folgende Anwendungsfälle liegen vor:

• Versicherungsangebote, genutzt vom Kunden, mit den durch Include angebundenen Anwendungsfällen Kfz-Versicherungen und Lebensversicherungen.
• Versicherungsrate bezahlen, genutzt vom Kunden
• Schadensmeldung, genutzt vom Kunden und vom Gutachter
• Auszahlung Versicherungssumme, genutzt vom Kunden
• Kundenstatistik, Versicherungsstatistik, Schadensstatistik, alle genutzt vom Versicherungsverkäufer.

Weitere Beispiele finden sich in WebZumBuch_UM01.

11.6 Anwendungsfälle und Unternehmensmodellierung

Welchen Beitrag können Anwendungsfälle zu einer Unternehmensmodellierung leisten? Und welchen nicht?

Anwendungsfalldiagramme gehören zu den ersten Diagrammen, die im Rahmen einer objektorientierten Systemanalyse erstellt werden. Sie stellen überblicksartig die Gesamtfunktionalität des zu entwickelnden Systems dar und beschreiben das Zusammenwirken von Anwender und System.

Aufgabe in der Systementwicklung

Sie gehen nicht auf die interne Struktur der jeweils beschreibenen Abläufe ein, sie beschreiben nicht die geplante Implementierung:

Kein Eingehen auf die innere Struktur

„Anwendungsfälle beschreiben das externe Systemverhalten, d.h. was das System leisten soll. Wie dieses entsteht, d.h. welches Systemdesign und welche Realisierung zu diesem äußeren Systemverhalten beiträgt, darüber treffen die Anwendungsfälle keine Aussage.“ [Oestereich 1998, S. 215f]

Die Abgrenzung der Tätigkeiten, die zu einem Anwendungsfall gehören, ist immer subjektiv, genauso wie es in der Diskussion um Ereignisgesteuerte Prozessketten die Abgrenzung von Funktionen ist. Dasselbe gilt für den Detaillierungsgrad der Modellierung. Die Ursache liegt darin, dass hier einer der Berührungspunkte mit der zu modellierenden Realität ist und diese sich nun mal nicht formal fassen lässt.

Absolute Definition möglich?

Anwendungsfall = Geschäftsprozess?

Nach der Beschreibung in diesem Kapitel kann man schon verstehen, dass manche bei Anwendungsfällen an Geschäftsprozessmodellierung denken, v.a., wenn Booch, Rumbaugh und Jacobson noch betonen, dass ein Anwendungsfall ein greifbares Arbeitsergebnis liefert [Booch, Rumbaugh und Jacobson 1999, S. 249], dass dieses Konzept auf das ganze System anwendbar ist und eine Menge von Folgen beschreibt,

Geschäftsprozesse?

„... in der jede Folge eine Interaktion von etwas außerhalb des Systems (seinen Akteuren) mit dem System selbst ... ist“ [Booch, Rumbaugh und Jacobson 1999, S. 248].

Es überrascht deshalb nicht, dass einige Autoren den Begriff use case mit Geschäftsprozess gleichsetzen ([Balzert 2001, S. 126ff], [Balzert 1999, S. 63], [Meier und Wüst 1997, S. 42]). Für Meier und Wüst sind die Begriffe Anwendungsfall (sie sprechen von Anwenderfunktion) und Geschäftsprozess synonym. Den Gesamtzusammenhang sehen sie so, dass der Gesamtumfang der Anwendung durch die Systemziele und Systemgrenzen festgelegt ist und die Geschäftsprozesse oder Anwenderfunktionen zur Erfüllung der Systemziele dienen.

Hinzu kommt, dass eine detailliertere (i.d.R. textliche) Beschreibung der Anwendungsfälle tatsächlich gefordert wird. Unter der Überschrift „vom Groben zum Detail“ beschreiben z.B. Meier und Wüst den Einsatz von Anwenderfunktionen durch Geschäftsprozesskarten ([Meier und Wüst 1997, S. 41f]). Dabei wird jeder spezifische Anwendungsfall durch Geschäftsprozesskarten erfasst, d.h. textlich beschrieben.

Zusätzliche textliche Beschreibung

Anwendungsfälle modellieren keine Geschäftsprozesse

Trotzdem kann der Gleichsetzung von Geschäftsprozessen und Anwendungsfällen nicht zugestimmt werden. Anwendungsfälle beschreiben nur einige wenige Aspekte von Geschäftsprozessen. Sie benennen Teilaufgaben und definieren damit Anforderungen an das System bzw. den Geschäftsprozess. Sie zeigen evtl. Beziehungen zwischen Anwendungsfällen (vgl. oben) aus. Damit ist die Modellaussage aber schon erschöpft.

Benennung,
nicht Beschreibung

Die evtl. angehängten textlichen Beschreibungen sind da (für die Prozessbeschreibung) keine zeitgemäße Antwort. Textliche Beschreibungen erreichen bei weitem nicht die Aussagekraft geeigneter Prozessmodelle.