Von einer benutzergerechten Software wird heute erwartet, dass sie die Worksflows in einem Unternehmen optimal unterstützt.

Bei der Entwicklung neuer Software sorgt eine frühzeitige und effektive Modellierung der Worksflows dafür, dass zukünftige Benutzer ihre Arbeitsabläufe zielgerichtet durchführen können, um die gewünschten Ergebnisse zu erhalten.

Eine beliebte Notation für die Modellierung von Workflows ist seit Jahren die UML (Unified Modeling Language), die sich als Standardnotation für die Modellierung objektorientierter Systeme durchgesetzt hat. Zur Zeit wird die Version 2.0 der UML von der OMG (Object Management Group) fertiggestellt. Während sich beispielsweise bei den Klassendiagrammen gegenüber der UML 1.x nicht viel geändert hat,  gibt es bei der sogenannten Verhaltensmodellierung, zu der auch die Worksflows zählen, einige grundlegende Änderungen.

Workflow

Der Begriff Workflow beschreibt die Automatisierung eines Geschäftsprozesses, somit also einen Geschäftsprozess auf technischer Ebene. Ein Geschäftsprozess  ist eine Transaktion oder eine planmäßige Folge von Transaktionen zwischen betrieblichen Objekten im Rahmen der Leistungserzeugung. Transaktionen können in Wechselwirkung mit einem oder mehreren Objekten oder Daten stehen. In diesem Fall können Eingabedaten unter Einsatz von Steuerinformationen und Ressourcen in Ausgabedaten transformiert werden, wobei ein Austausch von Leistungen und/oder Botschaften zwischen den Objekten stattfindet.

Bereits in der UML 1.x wurden Workflows mit Hilfe von Aktivitätsdiagrammen modelliert, das ein Sonderfall des Zustanddiagramms war /Balzert 01/.  Oberflächlich betrachtet bleibt das auch in der UML 2.0 so – aber Aktivitätsdiagramme sind jetzt konzeptionell etwas völlig Neues und auch in Punkto Notation ist viel mehr möglich als bisher /UML 2.0/.

Kernstück des neuen Konzepts ist die Aktivität. Eine Aktivität (activity) beschreibt die Ausführung von Funktionalität bzw. Verhalten. Sie wird durch mehrere Knoten modelliert, die durch gerichtete Kanten miteinander verbunden sind. Die UML 2.0 unterscheidet Aktionsknoten, Kontrollknoten und Objektknoten. Entsprechend besitzen Aktivitäten sowohl ein Kontrollfluss- als auch ein Datenmodell. Das Kontrollflussmodell spezifiziert die Reihenfolge von Funktionen und das Datenmodell die Daten, die zwischen ihnen den Funktionen ausgetauscht werden.

Aktivitäten sind in der UML 2.0 so konzipiert, dass sie für sehr unterschiedliche Spezifikationsebenen eingesetzt werden können. Für die Modellierung von Workflows wird naturgemäß ein relativ hohes Abstraktionsniveau gewählt. Bei den modellierten Informationen handelt es sich um die prozessrelevanten Daten. In Entwurf und Implementierung werden Aktivitäten besonders für die Beschreibung komplexer Operationen eingesetzt.

Aktionsknoten

Die kleinste ausführbare Funktionseinheit innerhalb einer Aktivität, die nicht weiter zerlegt wird,  wird als Aktion bezeichnet. Eine Aktion innerhalb einer Aktivität kann ausgeführt werden, wenn die Vorgänger-Aktion beendet ist, wenn notwendige Daten zur Verfügung stehen (zum Beispiel Bestellung liegt vor) oder wenn ein Ereignis auftritt (zum Beispiel Jahreswechsel).

Eine Aktion (action) kann nicht nur ein elementarer Verarbeitungsschritt, sondern auch ein Aktivitätsaufruf sein, das heisst, von der Ausführung her gesehen, kann sich hinter einem Aktionsknoten eine sehr komplexe Verarbeitung verbergen. Aktionen werden durch Rechtecke mit abgerundeten Ecken dargestellt. In das Rechteck werden der Name oder eine kurze Beschreibung der Aktion eingetragen. Steht eine Aktion für einen Aktivitätsaufruf, dann wird rechts unten ein kleines Symbol angegeben, das wie ein Rechen aussieht.

Eine Aktivität wird durch ein großes Rechteck mit abgerundeten Ecken modelliert, wobei links oben der Name der Aktivität eingetragen wird.  Die Verarbeitungsschritte der Aktivität werden durch einen Graphen dargestellt, der aus Knoten (nodes) und gerichteten Kanten (edges) besteht (Bild 2). Die Knoten entsprechen im einfachsten Fall den Aktionen.  Die Kanten verbinden die Knoten und stellen die Kontroll- und Datenflüsse der Aktivität dar.  Im einfachsten Fall geben sie die Reihenfolge der Aktionen an (Kontrollfluss). Eine Kante wirdals gerichteter Pfeil dargestellt, der zusätzlich mit einem Namen beschriftet werden kann. Der gleiche Aktionsname kann in einer Aktivität mehrfach vorkommen, beispielsweise, wenn die gleiche Aktion mehrere Male ausgeführt wird. Die Aktivität ist als Namensraum für die in ihr enthaltenen Aktionen zu sehen. Viele Aktivitäten benötigen Eingaben und produzieren Ausgaben. Sie werden durch Parameterknoten beschrieben.

Kontrollknoten

Im einfachsten Fall werden Aktionen sequenziell nacheinander ausgeführt. Es ist aber auch möglich, Verzweigungen des Kontrollflusses zu beschreiben. In Bild 3 wird durch die Aktion Auftrag prüfen  ermittelt, ob nur Lagerartikel bestellt wurden oder auch solche, die erst vom Lieferanten bezogen werden müssen. Im zweiten Fall wird die Aktion Artikel bestellen ausgeführt, andernfalls ist nichts zu tun. Vor der Weiterbearbeitung des Auftrags werden die Kontrollflüsse wieder zusammengeführt (Bild 3).

Die Verzweigung (decision mode) und die Zusammenführung der Alternativen (merge node) werden jeweils durch eine Raute dargestellt. Folgt auf eine Zusammenführung direkt eine neue Verzweigung, können beide in einem Symbol kombiniert werden. Es wird durch eine Raute mit vielen Eingangs- und vielen Ausgangspfeilen dargestellt. Die Reihenfolge, in der die angegebenen Bedingungen ausgewertet werden, ist nicht definiert.  Der UML-Modellierer muss dafür sorgen, dass nur eine einzige Alternative möglich ist. Der Einfachheit halber kann eine der Bedingungen mit Else beschriftet werden. Beim Ende einer Verzweigung (merge node) werden alternative Ströme wieder zusammengeführt. Die nachfolgende Aktion kann wird erst ausgeführt, wenn eine der Alternativen bearbeitet wurde.

In einigen Fällen müssen Aktionen zwar in einer festgelegten Reihenfolge ausgeführt werden, wobei die Reihenfolge aber aus fachlicher Sicht keine Rolle spielt. Aktionen können sowohl in beliebiger Sequenz oder auch zeitlich parallel ausgeführt werden. Eine weitere Verarbeitung soll aber erst dann möglich sein, wenn alle davor liegenden Aktionen beendet sind.

Beispielsweise ist in Bild 4 die Reihenfolge der Aktionen Rechnung drucken und Kreditkarte belasten gleichgültig.  Die UML bietet dafür die Notation der Gabelung (fork node) und der Zusammenführung (join node) an. Bei einer Gabelung wird der Kontrollfluss in mehrere parallele Ströme aufgesplittet. Bei einem join node werden parallele Flüsse synchronisiert. Das heißt, dass die nachfolgende Aktion erst ausgeführt wird, wenn alle Aktionen vor dem join node beendet sind. 

Beide Knoten werden durch einen senkrechten Balken modelliert. Eine Gabelung besitzt einen Eingangs- und mehrere Ausgangspfeile. Bei einem join node werden mehrere Eingangs- und ein Ausgangspfeil angetragen. Folgt auf ein join direkt eine Gabelung, dann können beide auch in einem Balken mit mehreren Eingangs- und Ausgangspfeilen kombiniert werden.

Wie bereits von der UML 1.x bekannt, wird bei einer Aktivität die erste Aktion mit einem Startknoten (initial node) markiert, der als kleiner schwarzer Kreis dargestellt wird. Eine Aktivität kann mehrere Startknoten besitzen. In diesem Fall startet die Aktivität in mehreren Pfaden. Ein Startknoten muss nicht unbedingt vorhanden sein. Das Bullauge (final node) kennzeichnet das Ende einer Aktivität. Das bedeutet, dass sämtliche Aktionen innerhalb der Aktivität sofort beendet werden. Eine Aktivität kann mehr als einen Endeknoten besitzen. Sie wird in diesem Fall dann beendet, wenn der erste Knoten erreicht ist.

Außerdem bietet die UML den Knoten flow final an. Dieser Knoten beendet den Pfad im Aktivitätsdiagramm und hat keinerlei Auswirkungen auf andere Pfade. Das bedeutet, dass Aktionen in anderen Pfaden weiter ausgeführt werden können.  Der Knoten flow final ist beispielsweise zu  wählen, wenn eine Aktivität zeitgleich mehrfach ausgeführt wird. Dann ist es nicht sinnvoll, dass alle Prozesse enden, nur weil einer der Prozesse den Endeknoten erreicht.

Eine andere Anwendung dieses speziellen Endeknotens zeigt Bild 5. Hier wird  das Prüfen von Teilrechnungen iterativ beschrieben. Sind alle geprüft, dann wird der final flow node erreicht. Obwohl die Verarbeitung an dieser Stelle zu einem Ende kommt, wird die nächste Aktion Gesamtbetrag anweisen ausgeführt.

Diese Elemente zur Modellierung – decision node, merge node, fork node, join node, initial node, final node, flow final  -  werden in der UML als Kontrollknoten bezeichnet, um sie von den Aktionsknoten zu unterscheiden.

Beispiel  

Als Beispiel für einen – zunächst vereinfachten - Workflow wird die Bearbeitung einer eingehenden Bestellung vom Kunden bzw. eines Auftrags betrachtet. Bild 6 zeigt, wie die Ausführung des Auftrags mit der UML 2.0 modelliert wird. Eingabeparameter ist der vorliegende Auftrag. Im ersten Schritt wird geprüft, ob der Kunde schon im System vorhanden ist (Kundendaten abrufen). Ist es ein Neu-Kunde, dann wird die Aktion Kunde neu erfassen ausgeführt. Haben sich bei einem „alten" Kunden die Daten geändert, dann werden die Kundendaten aktualisiert. Andernfalls ist nichts zu tun. Wenn die Auftragspositionen erfasst sind, können die Aktionen Rechnung drucken und Kreditkarte belasten in beliebiger Reihenfolge ausgeführt werden. Sind beide abgeschlossen, kann die Ware verpackt und versandt werden. Ausgabeparameter dieser Aktivität ist die Ware mit der Rechnung.

Objektknoten und –flüsse 

Außer den Aktions- und Kontrollknoten gibt es in der UML 2.0 das Konzept des Objektknotens. Ebenso  können mit einer Kante nicht  nur Kontrollinformationen (control edge), sondern auch Objektflüsse (object flow edge) verbunden sein. Während Kontrollflüsse die Ausführungsreihenfolge von Aktionen bestimmen, modellieren Objektflüsse Objekte und Daten, die von einem Knoten erzeugt und von einem anderen benötigt werden.

Objektflüsse besitzen an mindestens einem Ende einen Objektknoten. Objektknoten werden durch Rechtecke dargestellt und häufig mit dem Namen der Klasse benannt. Der Objektknoten kann während der Ausführung der Aktivität nur Werte annehmen, die konform mit der Klassenspezifikation sind.

Objektknoten können alternativ zur Rechteck-Notation als „Pins" modelliert werden. Das sind kleine Quadrate, die direkt auf der linken und rechten Seite einer Aktion angetragen werden. Sie stellen der Aktion Eingabewerte zur Verfügung und nehmen Ausgabewerte von ihr entgegen. Neben die Pins wird der Name des Objektknotens (zum Beispiel Klassenname) angetragen. Zusätzlich kann der Zustand, in dem sich das Objekt befindet, unter dem Namen in eckigen Klammer angegeben werden.
Sollten zwischen zwei Aktionen mehrere Objektflüsse stattfinden, so kann man auf beiden Seiten der Aktionen eine ganze Reihe von Pins eintragen. Um die Diagramme kompakt zu halten, bietet die UML eine Kurzform in Form eines kleinen Quadrats an, das über dem Pfeil angetragen wird und für alle Objektflüsse steht (Bild 8).
 
Außer den Daten, die in einem System von einer Aktion zur nächsten  durchgereicht werden, gibt es „ruhende" Daten. Man spricht von einem Datenspeicher, der in der UML 2.0  eine Sonderform des Objektknotens ist. Der Datenspeicher enthält alle Daten, die in ihn eingetragen werden und kopiert sie bei Bedarf in ausgehende Objektflüsse. Eingehende Daten können bereits vorhandene Daten im Datenspeicher ersetzen. Bild 9 modelliert eine Artikel-Datenbank als Datenspeicher. Er wird von der Aktion Artikel erfassen/ändern gefüllt und von der Aktion Artikelkatalog erstellen gelesen. Im Unterschied zum Objektknoten werden hier persistente, das heißt dauerhaft gespeicherte Daten, modelliert.