Identifizieren Sie Anwendungsfälle aus dem Geschäftsprozess

Entwicklungsteams können Geschäftsprozessmodelle verwenden, um Geschäftsabläufe visuell zu dokumentieren, und Anwendungsfälle diesen Geschäftsprozessen zuordnen, um die gewünschten Funktionen zu modellieren, die das System erreichen soll. In diesem Tutorial erklären wir ausführlich, wie die Funktion Model Transitor genutzt werden kann, um die Rückverfolgbarkeit zwischen Anwendungsfällen und Geschäftsprozessen herzustellen.

Was sind BPMN und BPD?

BPMN bietet Business Analysten eine Reihe grafischer Notationen zur Modellierung von Geschäftsprozessen. Sie wurde ursprünglich entwickelt von der Business Process Management Initiative (BPMI) und wird derzeit von der Object Management Group (OMG). Eine der Motivationen für die Entwicklung von BPMN ist es, eine gemeinsame grafische Sprache für Personen in verschiedenen Rollen, aus verschiedenen Ländern und/oder mit unterschiedlichen gesprochenen Sprachen bereitzustellen, damit sie denselben Geschäftsprozess ohne Barrieren verstehen können.

BPD, Abkürzung für Geschäftsprozess-Diagramm, ist der Ort, an dem der Geschäftsprozess mit BPMN modelliert wird. Es handelt sich um ein flussdiagrammähnliches Diagramm, das den Ablauf des Prozesses, die beteiligten Parteien und den Nachrichtenaustausch zwischen ihnen darstellt. Business Analysten zeichnen BPD(s), um darzustellen, wie verschiedene Parteien zusammenarbeiten, um ein Geschäftsziel zu erreichen. Nachdem das fertige Geschäftsmodell mit den Endbenutzern abgestimmt wurde, kann der Systemanalyst dann mit der Planung des Systems beginnen.

Das Folgende ist ein einfaches BPD eines Registrierungsprozesses für eine Organisation. Es umfasst die meisten typischen Modellierungsnotationen, die Sie sehen würden. Schauen wir uns das an.

Notation	Beschreibung
	Pool – Stellt eine Partei innerhalb eines Prozesses dar. In BPMN werden sowohl Pools als auch Lanes verwendet, um Parteien darzustellen. Eine Lane ist in einem Pool enthalten, um eine Unterteilung des übergeordneten Pools zu modellieren.
	Startereignis – Der Beginn eines Prozesses. Trigger können definiert werden, um den Lesern mitzuteilen, in welcher Situation der Prozess ausgelöst wird. Zum Beispiel, wenn eine E-Mail empfangen wurde / wenn es Montagmorgen ist / wenn ein Fehler aufgetreten ist.
	Aufgabe – Eine atomare Aktivität, die bestimmte Teilnehmer (durch Pool/Lane modelliert) ausführen könnten. Aufgaben und andere Flussobjekte werden miteinander verbunden, um einen vollständigen Geschäftsablauf zu bilden.
	Endereignis – Das Ende eines Prozesses. Ein Ergebnis kann definiert werden, um den Lesern mitzuteilen, was passiert, wenn der Prozess endet. Zum Beispiel, ein Signal auszugeben / einen Fehler zu erzeugen, usw.

In diesem Tutorial werden wir uns nicht stark auf BPD oder die Geschäftsprozessmodellierung konzentrieren. Wenn Sie mehr über BPMN, BPD oder die Geschäftsprozessmodellierung erfahren möchten, lesen Sie bitte das Tutorial Einführung in BPMN Teil I bis IV.

Was ist ein Anwendungsfalldiagramm?

Die Anwendungsfalldiagrammierung bezieht sich auf die Technik, hochwertige Benutzeranforderungen mit Hilfe von UML-Anwendungsfalldiagrammen zu erfassen. Das Anwendungsfalldiagramm ist für Software- oder Systemdesigner konzipiert, nicht für Geschäftsleute.

Es gibt drei Hauptelemente in einem Anwendungsfalldiagramm.

Notation	Beschreibung
	Use Case – Jedes Use Case stellt ein Benutzerziel dar, das ein Ziel ist, das der Benutzer des Systems erreichen möchte. Beachten Sie, dass Use Cases nur dazu verwendet werden können, zu zeigen, was der Benutzer tun möchte, anstatt was der Entwickler entwickeln muss, obwohl dies in einigen Fällen identisch sein kann. Wenn Sie die in einem Use Case beteiligten Funktionen dokumentieren oder modellieren möchten, können Sie das Werkzeug „Ablauf der Ereignisse“ verwenden oder ein Use Case mitSequenzdiagramm/Aktivitätsdiagramm. Behalten Sie bitte im Hinterkopf, dass die Use Case-Modellierung darauf abzielt, zu modellieren, was der Benutzer erreichen möchte.
	Aktor – Benutzer des Systems. Das Wort „Benutzer“ bezieht sich hier nicht nur auf Menschen. Es kann sich auch um ein System handeln, das mit unserem System interagiert, um ein bestimmtes Geschäftsziel zu erreichen.
	Kommunikationsverbindung/Assoziation – Verbindet Aktor und Use Case, um den Zugriff des Aktores auf das System anzuzeigen. Jede Kommunikationsverbindung impliziert eine Folge von Transaktionen zwischen Aktor und System.

Übergang von BPD und Use Case-Diagramm

Obwohl BPD und Use Case-Diagramm nicht unbedingt aufeinander angewiesen sein müssen, könnten sie auf eine ergänzende Weise miteinander verbunden sein. Gewöhnlich entwickeln wir Software, um bestimmte Arbeitsabläufe von Geschäftsprozessen zu automatisieren oder zu optimieren. Mit Hilfe des BPD können Sie verstehen, wie die Beteiligten zusammenarbeiten und wer für was verantwortlich ist. Dadurch können wir identifizieren, welche Funktionen das System unterstützen muss. Diese Systemfunktionen (Workflow oder Geschäftsprozess), die der Benutzer benötigt, können mit Use Cases modelliert und anschließend vom Team entwickelt werden. Infolgedessen können wir sagen, dass das BPD Ihnen hilft, Use Cases für ein zu entwickelndes System zu identifizieren.

Visual Paradigm ist ein visuelles Modellierungswerkzeug, das von der Durchführung von Geschäftsprozessen bis hin zur Use Case-Modellierung (von Geschäftsanforderungen zu Anwendungsanforderungen) unterstützt, indem es die Nachvollziehbarkeitsverbindungen zwischen den beiden Modellen durch die Modell-Übergabefunktion herstellt. Wir benötigen die Nachvollziehbarkeit aus folgenden Gründen:

• Wir können sicherstellen, dass das System in die reale Nutzung passt, indem wir den Teil des Prozessablaufs untersuchen, den ein Use Case beinhaltet.
• Um Fragen wie „Warum benötigen wir diese (System-)Funktion?“ zu beantworten, indem man den Teil des Prozesses verfolgt, aus dem ein Use Case stammt.
• Um Fragen wie „Wurde eine bestimmte Operation bereits implementiert?“ zu beantworten, indem man vom BPD zum Use Case-Diagramm verfolgt.

BPD im Vergleich zu Use Case-Diagramm

Wenn Sie ein BPD in ein Use Case-Diagramm übertragen, können Sie einen Aktor aus Lane/Pool und ein Use Case aus Aufgabe/Unterprozess ableiten. Die folgende Tabelle zeigt Ihnen die Eigenschaften von Pool, Lane, Aktor, Aufgabe, Unterprozess und Use Case im Hinblick auf die Modellübertragung.

Von	Zu	Beschreibung
		Pool/Lane zu Aktor Im BPD steht ein Pool für einen Teilnehmer eines Geschäftsprozesses, während eine Lane eine Unterteilung des Pools darstellt. Jeder, der eine Aktivität ausführt, die mit dem Prozess zusammenhängt, gilt als Teilnehmer. Im Use Case-Diagramm steht ein Aktor für einen Benutzer des Systems. Beachten Sie, dass jede Person oder Rolle, die kein Benutzer des Systems ist, nicht als Aktor betrachtet werden sollte.
		Aufgabe/Unterprozess zu Use Case Im BPD bezeichnet eine Aufgabe/Unterprozess (Aktivität) jede Handlung, die ein Teilnehmer ausführen könnte, um einen Geschäftsprozess abzuschließen. Im Use Case-Diagramm stellt ein Use Case ein Ziel dar, das der Benutzer erreichen möchte, indem er das System nutzt. Beachten Sie, dass eine Aktivität nicht unbedingt mit einer Systemfunktion zusammenhängen muss, und ein Use Case mehrere Aktivitäten erfüllen kann.

Einige Menschen könnten meinen, dass ein Use Case-Diagramm einem BPD ähnlich sei, aber in Bezug auf Notationen und Zwecke ganz anders sei. Denken Sie daran, dass BPMN für Geschäftsleute konzipiert ist, während das Use Case-Diagramm für Systemanalysten oder Systementwickler gedacht ist. Sie dienen unterschiedlichen Zwecken und betrachten ein Geschäftsprozess aus zwei unterschiedlichen Perspektiven. Deshalb habe ich in der vorherigen Abteilung die Beziehung zwischen BPD und Use Case-Diagramm zusammengefasst mit der Aussage: „BPD hilft Ihnen, Use Cases zu identifizieren“. Das BPD kann Ihnen lediglich Hinweise geben, wenn Sie Use Cases identifizieren. Es gibt keine Regel, die besagt, dass jede Aufgabe, die in einem BPD existiert, einem Use Case entspricht. Doch wir könnten einen Geschäftsprozess durch ein Use Case erweitern, um eine Funktion durch das Zielsystem zu automatisieren.

Im Fallbeispiel werde ich Ihnen einige Hinweise geben, auf die Sie achten sollten, wenn Sie ein BPD in ein Use Case-Diagramm übertragen. Danach werden Sie verstehen, wie unterschiedlich sie sind.

Fallstudie: Die True Aqua Destilliertwasser-Gesellschaft

Die True Aqua Destilliertwasser-Gesellschaft ist ein junger Lieferant von Destilliertwasser in der Stadt. Sie verkaufen Destilliertwasser für gewerbliche und private Nutzung. Im Folgenden finden Sie eine textuelle Beschreibung ihres Wasserlieferprozesses.

Ein Geschäftsprozessmodell wurde auf Basis der Beschreibung erstellt. Nun werden Sie gebeten, ein Computersystem zu entwickeln, um den gesamten Prozess zu optimieren. Das Erste, was Sie tun müssen, ist, ein Use Case-Modell zu entwickeln. Unterstützt durch das BPD versuchen Sie, ein Use Case-Diagramm zu erstellen.

1. Herunterladen Destilliertes-Wasser-Lieferung.vpp. Sie können diese Datei auch am Ende dieses Tutorials finden.
2. Öffnen Sie die heruntergeladene .vpp-Datei in Visual Paradigm. Wählen Sie zum Öffnen eines Projekts Projekt > Öffnen aus der Anwendungswerkzeugleiste.
3. Öffnen Sie das BPD Verfahren zur Bestellung von destilliertem Wasser. Studieren Sie den Ablauf sorgfältig.
   
4. Der Prozess beginnt, wenn ein Kunde eine Bestellung aufgibt. Hier können wir an einen Use Case denken – Bestellung aufgeben. Der Use Case unterstützt die Automatisierung des Prozesses, indem er eine Schnittstelle bereitstellt, über die der Kunde eine Bestellung ohne die Unterstützung eines Kundenservice-Mitarbeiters aufgeben kann, die Identität des Kunden überprüft und ein Konto erstellt, falls der Kunde noch nicht existiert. Klicken Sie mit der rechten Maustaste auf „Bestellung aufgeben“ und wählen Sie Verwandte Elemente > Übergang zu neuem Use Case… aus dem Popup-Menü.
   
5. Dies ruft das Fenster Modell-Element übertragenauf, in dem Sie das Modell auswählen können, in dem der Use Case und der Akteur platziert werden sollen, sowie deren Umbenennung vornehmen können. In diesem Fall sind wir mit den Namen des Use Cases und des Akteurs zufrieden. Lassen Sie sie unverändert. Klicken Sie auf OK.
   
   Dies erstellt ein neues Use Case-Diagramm in UeXceler.
   
6. Gehen Sie zurück zum BPD.
7. Betrachten wir die Aufgabe Kundenkonto erstellen. Im Geschäftsprozess muss der Kundenservice-Mitarbeiter ein Konto für jeden neuen Kunden erstellen. Im neuen System kann dies entweder Teil des Bestellung aufgebenUse Case sein oder ein separater Use Case sein, der manuell vom Kundenservice-Mitarbeiter ausgelöst wird. In der realen Welt sollten Sie diese Art von Zweifel mit dem Stakeholder klären, da ein falsches Use Case-Modell zur Entwicklung von Funktionen führen würde, die nicht den Erwartungen des Benutzers entsprechen. In diesem Beispiel nehmen wir an, dass der Benutzer möchte, dass die Aufgabe Kundenkonto erstellenvon dem Kundenservice-Mitarbeiter ausgeführt wird. Lassen Sie uns einen Use Case daraus erstellen. Klicken Sie mit der rechten Maustaste auf Kundenkonto erstellen und wählen Sie Verwandte Elemente > Übergang zu neuem Use Case… aus dem Popup-Menü.
   
8. Wiederum sind wir mit dem Namen des Use Cases und des Akteurs zufrieden. Lassen Sie alles im Fenster Modell-Element übertragenunverändert. Klicken Sie auf OK. Der Use-Case-Diagramm wurde mit einem neuen Use-Case und einem Akteur aktualisiert. Schauen wir uns das an.
   
9. Gehe zurück zum BPD. Gehen wir zum Unterprozess überLieferung organisieren. Der Leiter der Logistikabteilung kann das System nutzen, um die Planung durchzuführen und die Mitarbeiter über die Wasserlieferung zu informieren. Daher ist dies ebenfalls ein Use-Case des Systems. Klicken Sie mit der rechten Maustaste auf den UnterprozessLieferung organisieren und wählen SieVerwandte Elemente > Übergang zu neuem Use-Case…aus dem Popup-Menü.
10. Überprüfen Sie den Akteur Manager imÜbergangs-Modell-Element Fenster. Wenn wir den Namen des Akteurs alsManager belassen, ist dies im Use-Case-Modell mehrdeutig, da es in der Firma möglicherweise viele Abteilungen mit verschiedenen Managern geben kann. Benennen Sie den Akteur daher inLeiter der Logistikabteilung.
    
11. Klicken Sie aufOK. Der Use-Case-Diagramm wurde aktualisiert.
    
12. Gehe zurück zum BPD. Die letzte AufgabeWasser liefernist eine Aufgabe, die nur von Menschen ausgeführt werden kann und nichts mit der Interaktion des Systems zu tun hat. Daher müssen wir dafür keinen Use-Case erstellen.
13. Angenommen, der Regionalmanager möchte, dass das System eine neue Funktion unterstützt, die einen Bericht erstellen kann, um die Statistiken zu den Bestellungen anzuzeigen. Diese Funktion kann ihm helfen, die Marketingstrategie zu überprüfen und zu verfeinern. Obwohl diese Funktion im Geschäftsprozessmodell nicht modelliert wurde, können wir sie direkt im Use-Case-Diagramm zeichnen. Öffnen Sie das Use-Case-Diagramm. Zeichnen Sie einen AkteurRegionalmanager. Erstellen Sie einen Use-CaseStatistischen Bericht generierendavon mit einer Verbindung dazwischen.
    
14. Angenommen, der Kunde möchte dem Kunden erlauben, die Rechnungsunterlagen einzusehen und Bestellungen zu stornieren. Außerdem möchte der Kunde dem Leiter der Logistikabteilung erlauben, Logistikberichte auszudrucken. Zeichnen Sie die Use-Cases jeweils entsprechend.
    
15. Ordnen Sie das Diagramm.
    
16. Die Übergangsbeziehung ermöglicht es Ihnen, das Geschäftsprozessmodell aus dem Use-Case-Modell (und umgekehrt) nachzuverfolgen. Versuchen wir es. Platzieren Sie den Mauszeiger überBestellung aufgeben Anwendungsfall.
    
17. Klicken Sie auf die Modell-Transitor Ressource in der rechten unteren Ecke der Form. Wählen Sie Transit von > Bestellprozess für destilliertes Wasser<.Bestellung aufgeben aus dem Popup-Menü.
    
    Dies öffnet die BPD mit der Aufgabe Bestellung aufgeben ausgewählt.