Anträge stellen und genehmigen in der Use Case-Modellierung

Bei der Modellierung von Anforderungen die eine Weiterleitung von Anträgen betreffen, gibt es eine Stolperfalle, die ich hier am Beispiel von Urlaubsanträgen einmal erläutern will. Wir wollen eine Anwendung entwickeln, mit der Urlaubsanträge gestellt und vom Vorgesetzten genehmigt werden können. Der Antragsteller soll sehen, ob der von ihm gestellte Antrag genehmigt oder abgelehnt wurde. Der Vorgesetzte soll die von Mitarbeitern gestellten Anträge sehen und genehmigen bzw. ablehnen können. Der Ablauf beim Zusammenspiel zwischen Mitarbeitern und Vorgesetzten ist offensichtlich. In der Use Case-Modellierung könnte man deshalb zu folgender Lösung kommen (vereinfacht, UML-Notation im Visual Studio):

anwendungsfaelle-keine-ablaeufe_falsch

Der Autor meint mit dieser Lösung, die Pfeile würden sehr gut die Weiterleitung des Antrags ausdrücken. Aber das ist falsch! Use Case-Diagramme (Anwendungsfalldiagramme) drücken keine Abläufe aus. Sie sollen ein möglichst einfaches Kommunikationsmittel sein, um mit dem Auftraggeber oder Endbenutzer, um über seine Anforderungen sprechen zu können. Deshalb verzichten Sie bewusst auf komplexe Modellierungselemente und sind ganz einfach.

Insbesondere drücken die Pfeile keinen Ablauf aus. Die Verbindung zwischen einem Akteur und einem Anwendungsfall drückt aus, dass der Akteur mit dem Anwendungsfall interagiert. Beispielsweise benutzt der Mitarbeiter das System, um einen Antrag zu stellen. Die dabei ablaufenden Schritte im Zusammenspiel zwischen System und Mitarbeiter „laufen über die Linie“. Am Ende werden die Daten des gesendeten Antrags vom System gespeichert.

Die Weiterleitung kann also nicht über einen Pfeil ausgedrückt werden. Besser wäre die folgende Modellieurng. Allerdings ist der Pfeil (den das Visual Studio standardmäßig einstellt) aus der Mode gekommen. Man verwendet schon lange eine Linie anstelle des Pfeils, weil es ein hin- und her im Rahmen der Interaktion ist und in der Regel nicht nur ein Aufruf der nur in eine Richtung geht. Hier aber noch einmal mit Pfeil die bessere Modellierung:

anwendungsfaelle-keine-ablaeufe_richtig

Es gibt auch überhaupt keine Weiterleitung(die mit Pfeilen ausgedrückt werden kann)! Warum? Weil die Akteure die gesendeten Anträge in „ihren eigenen“ Anwendungsfällen einfach sehen. Wenn also der Vorgesetzte den Anwendungsfall „Mitarbeiterurlaubsantrag genehmigen oder ablehnen“ startet, zeigt ihm das System die zur Genehmigung vorliegenden Anträge an. Nachdem er in Interaktion mit dem System den Antrag genehmigt/abgelehnt hat, werden die veränderten Daten gespeichert. Dabei wird der Status des Antrags gesetzt. Der Mitarbeiter sieht in einem eigenen Anwendungsfall „Genehmigen/Abgelehnte Urlaubsanträge einsehen“ dann das Ergebnis der Genehmigung bzw. Ablehnung des Vorgesetzten in Form einer eigenen Anträge, die den zuvor vom Vorgesetzten gesetzten Status haben.

Deshalb gibt es auch keine Weiterleitung, die durch Pfeile ausgedrückt werden kann. Erinnern Sie sich einfach daran, dass Anwendungsfalldiagramme keine Ablaufdiagramme oder Prozessdiagramme sind!

Wenn es erforderlich ist, dass ein Anwendungsfall erst dann gestartet werden kann, wenn ein anderer Anwendungsfall zuvor erfolgreich abgeschlossen wurde, muss das als Vorbedingung für den Anwendungsfall dokumentiert werden. Es darf aber trotzdem keine Linie zwischen den Anwendungsfällen gezogen werden!

Man könnte sich jetzt noch die Anforderung einbringen, dass der Vorgesetzte informiert wird, sobald ein Mitarbeiter einen Antrag gestellt hat bzw. der Mitarbeiter sobald der Vorgesetzte genehmigt oder abgelehnt hat. Also soll das System die Daten nicht nur speichern, sondern auch Benachrichtigungen ermöglichen. Das setzt voraus, dass das Programm ständig im Hintergrund läuft, um auf eingehende Bemerkungen reagieren zu können. Im Falle einer App für das Smartphone lässt sich das durch einen entsprechenden Anwendungsfall umsetzen. Für Desktop-Anwendungen oder Web-Anwendungen ist dieses Konzept weniger verbreitet. Hier wird häufig auf die Benachrichtigung per E-Mail gesetzt. Ein Beispiel für eine Lösung zeigt das folgende Use Case-Diagramm. Es stellt das E-Mailsystem als einen Akteur dar. Denn auch externe Systeme können Akteure sein. Die Interaktion (über eine entsprechende Schnittstelle) läuft dann zwischen dem zu entwickelnden System und dem E-Mailsystem, was die Benachrichtigung versendet.

anwendungsfaelle-keine-ablaeufe_ganz-richtig

Auf diese Weise kann die Modellierung von Antragsprozessen mit Anwendungsfalldiagrammen erfolgen, ohne dass die Anwendungsfalldiagramme als Prozessmodelle missbraucht werden.

Schreibe einen Kommentar