7.1 Werkzeuge für Dynamik

In diesem Kapitel wird überblicksartig beschrieben, welche Werkzeuge die objektorientierte Theorie für die Modellierung von Vorgängen, Tätigkeiten, Tätigkeitsfolgen, kurz: für die dynamischen Aspekte der Anwendung oder des Anwendungsbereichs anbietet.

In der objektorientierten Terminologie wird dabei von der Modellierung von Verhalten (behavior) gesprochen. Dies gilt auch für die UML-Autoren, die konsequent den Begriff behavior verwenden, wenn es um diese dynamischen Aspekte geht. Dies tun sie auch in Situationen, wo im deutschen Sprachgebrauch die Übersetzung Verhalten nicht passend erscheint, weil das modellierte System nicht handelt, sondern nur reagiert (dann aber natürlich handelt). Nehmen wir das hier im folgenden öfters angeführte Beispiel eines Geldautomaten. Er handelt zwar („Geldausgabe“), er wartet aber auch oft auf Eingaben („Warten auf EC-Karte“, „Warten auf Geheimzahl“, usw.) und stellt da höchstens Verhalten zur Verfügung.

Verhalten – behavior

Noch größer ist die begriffliche Unstimmigkeit bei Geschäftsprozessen. Geschäftsprozesse („Angebotserstellung“, „Personaleinstellung“) haben kein „Verhalten“, sondern sie beschreiben Tätigkeiten, die – von Mensch oder Maschine / Programm – erledigt werden. Auch einzelne Funktionen von Geschäftsprozessen („Kalkulation durchführen“, „Personalbogen ausfüllen“) haben kein Verhalten, sondern beschreiben kleinere, eng zusammhängende Tätigkeiten.

7.2 Tätigkeiten, Tätigkeitsfolgen, Abläufe, Geschäftsprozesse

Der Begriff Verhalten wird daher in den folgenden Abschnitten zwar benutzt, aber nicht in der Ausschließlichkeit, wie es die UML-Autoren tun. Hier wird öfters auch von Tätigkeiten, Tätigkeitsfolgen, Abläufen oder eben auch Geschäftsprozessen die Rede sein, die vom jeweiligen Modell erfasst werden.

Exkurs: Systemdenken

Wie kommen die UML-Autoren dazu, die dynamischen Aspekte eines Anwendungsbereichs ganz unter den Begriff „Verhalten“ zu packen?

Die Antwort findet man, wie so oft bei der UML, wenn man sich in die Situation eines Softwareentwicklers versetzt. Bei dessen Arbeit sind die dynamischen Aspekte (Angestellte können eingestellt, entlassen, befördert und mit Gehältern versehen werden) zu Methoden von Klassen geworden, die von der Klasse zur Verfügung gestellt werden. Dann ist auch „Einstellen“ eine solche Methode, genauso wie „Kündigen“ (durch den Angestellten), obwohl aus der Geschäftsprozessperspektive ersteres mit dem Angestellten geschieht und nur zweiteres eine aktive Handlung eines „Objekts“ darstellt.

Zur Verfügung gestellte Methoden können aber, egal welchen Hintergrund sie haben, durchweg als das Verhalten der Klasse (bzw. ihrer Objekte) aufgefasst werden. Insgesamt machen sie das „Gesamtverhalten“, die einzelnen Methoden die Verhaltensaspekte aus.

Die Antwort auf die zu Beginn dieser Anmerkung gestellte Frage ist daher, dass die UML-Autoren die Perspektive von Softwareentwicklern einnehmen und mit dieser ihr Theoriegebäude erstellen.

In den folgenden Kapiteln werden nun alle Konstrukte vorgestellt, die die objektorientierte Theorie für die Modellierung von Verhalten / Tätigkeitsfolgen anbietet. Und dies in einer solchen Tiefe, dass sie erstens verstanden und zweitens auf ihre Tauglichkeit für die Modellierung von Geschäftsprozessen geprüft werden können. Damit wird dann auch geklärt, ob sie für eine integrierte Unternehmensmodellierung taugen.

Inhalt der folgenden
Kapitel

Betrachtet wird der objektorientierte Ansatz in seiner Ausprägung in der Unified Modeling Language (UML). Auch hier bei der Verhaltensmodellierung haben die UML-Autoren einen hohen Anspruch, wie die gegenüber früheren Versionen wesentlich ausführlichere und konsequentere Behandlung der Verhaltensmodellierung in der Version 2.0 zeigt. Dabei liegt aber natürlich der Schwerpunkt in der UML weiterhin auf der Systemanalyse, wie der Sprachgebrauch (sehr oft ist bei der Vorstellung der einzelnen Konstrukte direkt von Systemen die Rede) und auch das folgende Zitat zeigt:

“The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e.g., J2EE, .NET).” [OMG 2003b, S. 22]

In der Version 1.5 war der übergeordnete Anspruch, auch für die Unter­nehmensmodellierung tauglich zu sein, noch wesentlich deutlicher:

“Note that UML can be used to model different kind of systems: software systems, hardware systems, and real world organizations. Business modeling models real-world organizations.” [UML 1997a, S. 1]

Allerdings wird auch in der Version 2.0 dieser Anspruch wieder formuliert, im Sprachgebrauch[1], in den Beispielen (vgl. unten) und auch direkt, wie das folgende Zitat aus dem Kapitel zu den Aktivitäten zeigt:

“Activities may describe procedural computation. In this context, they are the methods corresponding to operations on classes.

Activities may be applied to organizational modeling for business process engineering and workflow. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call.” ([OMG 2003a, S. 284], Hervorhebung durch den Verfasser).

Das Zitat zeigt auch wiederum sehr deutlich den “Spagat” auf, den die UML-Autoren leisten wollen. Zum einen soll die klassische Aufgabe bezüglich Systemanalyse und Systemdesign erfüllt werden, zum anderen die rund um Geschäftsprozesse.

7.3 Verhalten

Im Gegensatz zum vorigen Kapitel geht es hier also nicht um Informationsstrukturen, nicht um statische Aspekte eines Systems (oder auch eines Geschäftsprozesses), sondern um die dynamischen Aspekte, das Systemverhalten bzw. die Tätigkeitsfolgen in Geschäftsprozessen. Die UML-Au­to­ren schreiben in diesem Zusammenhang auch konsequent von Verhaltensmodellierung (behavioral modeling).

Struktur vs. Verhalten

Sie definieren Verhalten als die beobachtbaren Wirkungen eines Vorgangs (operation) oder Ereignisses, einschließlich seiner Ergebnisse [OMG 2003a, S. 5].

Definition Verhalten

  • Ein Beispiel für einen Vorgang bei einem Geldautomaten: Kunde schiebt EC-Karte rein.

Sie präzisieren dann dahingehend, dass Verhalten in diesem Sinne die Programmschritte (computation) festlegt, die die Effekte des Verhaltens (der Verhaltenseigenschaft / behavioral feature) erzeugen.

  • Beispiel für Verhalten + Effekte desselben bei einem Geldautomaten: Karte wird geprüft. Falls gültig, wird die Auszahlung angestoßen, falls ungültig, wird die Karte einbehalten, das Personal informiert und dem Kunden eine Nachricht angezeigt.

Im dritten Teil dieser Definition [OMG 2003a, S. 5] geben sie auch gleich an, welche Formen das Beschreiben eines Verhaltens annehmen kann: „interaction, statemachine, activity, or procedure (a set of actions)“. Diese Begriffe werden unten erläutert.

Verhalten bedeutet hier also in erster Linie Systemverhalten. Und zwar auf Anforderungen von außerhalb des Systems (Kunde schiebt EC-Karte in den Geldautomaten) oder von innerhalb (digitale Auszahlkomponente startet mechanische Auszahleinrichtung).

Es ist also der „gute, alte“ Systembegriff, der hier wieder zugrundeliegt. Etwas anderes wäre auch nicht möglich, wenn man den Hauptzweck der UML sieht, die Systemanalyse und die Unterstützung der Softwareentwicklung.

Bei jeder Verhaltensmodellierung werden automatisch auch die Anwender mit betrachtet, da ein Teil der „Dynamik“ von ihnen kommt: Unter Umständen starten sie den zum Verhalten gehörenden Vorgang, oftmals nutzen sie das entstehende System.

Mit dabei:
die Anwender

Dieses Einbinden der Anwender geschieht stärker bei der Geschäftsprozessmodellierung, etwas weniger bei der Systemanalyse, wo ein Teil „der Dynamik“ auch vollautomatisch zwischen den Systemkomponenten abläuft.

7.4 Starke Verknüpfung von Objekten und Verhalten

In der objektorientierten Theorie sind Objekte und Verhalten untrennbar miteinander verknüpft:

Verhalten = Aktion von Objekten.

Jedes Verhalten ist das direkte Ergebnis der Aktion mindestens eines Objekts [OMG 2003a, S. 369]. Beispiele dafür bei einem Geldautomaten sind „Einzug EC-Karte um sie zu lesen“, „Ausgabe Geldscheine nach erfolgter Prüfung“. Das Wort „mindestens“ deutet aber schon an, dass die UML-Autoren auch das Zusammenwirken mehrerer Objekte (bzw. des Verhaltens mehrerer) als Grundlage eines modellierten Verhaltens sehen.

Die UML-Autoren prägen für das Objekt, von dem das Verhalten stammt, den Begriff Host-Objekt (host object).

Host-Objekt

Der Zusammenhang zwischen Objektstruktur und Verhalten wird so gesehen, dass das Verhalten Objektzustände verändert:

Verhalten = Änderung von Objektzuständen.

Objekte haben Zustände, die durch Struktureigenschaften fixiert sind. Diese Zustände können sich im Zeitablauf ändern. Genau diese „Zustandsveränderungen“ stellen Verhalten dar.

Nehmen wir als Beispiel das Karteneinzugsgerät bei einem Geldautomaten. Zustand 1 könnte sein: Bereit Karte anzunehmen. Zustand 2: Gesperrt. Usw.

Fast schon philosophisch werden die UML-Autoren, wenn sie darauf hinweisen, dass Verhalten in diesem Sinn somit nicht für sich alleine existiert und nicht kommuniziert [OMG 2003a, S. 369]. Verhalten ist untrennbar mit seinem Träger, dem Objekt (oder den Objekten), verbunden.

Diese enge Verknüpfung bleibt natürlich auch bestehen, wenn es um die Verarbeitung von Daten geht: Hat Verhalten mit Daten zu tun, dann kommen die Daten vom „Host-Objekt“. Damit ergibt sich eine sehr enge Definition von Verhalten, deren Eignung für die Geschäftsprozessmodellierung in Kapitel 9 diskutiert wird.

Daten vom
Host-Objekt

Eine Ausnahme gibt es von dieser stringenten Definition. Das sog. executing behavior, das gleich hier unten eingeführt wird. Dieses kann auch selbst ein Objekt sein [OMG 2003a, S. 369].

7.5 Executing und Emergent Behavior

Die UML-Autoren unterscheiden zwei Arten von Verhalten: executing behavior und emergent behavior.

emergent vs. executing

Executing Behavior

Executing behavior wird durch ein Objekt ausgeführt, seinen Host. Es stellt die Beschreibung des Verhaltens dieses Objektes dar und wird direkt verursacht durch den Aufruf einer Verhaltenseigenschaft dieses Objekts oder durch dessen Erzeugung. In beiden Fällen ist es die Konsequenz der Ausführung einer Aktion durch ein Objekt. Ein Verhalten hat Zugriff auf die Strukturmerkmale seines Host-Objekts.

Emergent Behavior

Emergent behavior entsteht aus dem Zusammenwirken von Objekten. Es stellt also das Verhalten einer Gruppe von Objekten, die Summe ihrer executing behaviors dar. Beispiele für ein emergent behavior ist die Ausführung eines Anwendungsfalles oder einer Interaktion (vgl. unten).

7.6 Konstrukte für die Verhaltensmodellierung

Die Version 2.0 der UML, die nun schon seit einiger Zeit vorliegt, enthält gegenüber den früheren Versionen verbesserte Konzepte für die Modellierung der dynamischen Aspekte eines Systems (oder eines Geschäftsprozesses). Folgende Grundkonzepte bieten die UML-Autoren nun an:

  • Aktionen (actions)
  • Aktivitäten (activities)
  • Interaktionen (Interactions)
  • Zustandsautomaten (state machines)
  • Anwendungsfälle (use cases)

Dass hier tatsächlich teilweise Neues vorlag, sahen auch die Autoren der UML. Unter dem Titel “Changes from previous UML“ führen sie aus:

„Explicitly modeled actions as part of activities are new in UML 2.0, and replace ActionState, CallState, and SubactivityState in UML 1.5. They represent a merger of activity graphs from UML 1.5 and actions from UML 1.5. Local pre and postconditions are new to UML 2.0.“ [OMG 2003a, S. 283]

Den Zusammenhang zwischen diesen Konstrukten, die im Rahmen der Metamodellierung der UML als Klassen modelliert sind, deutet die folgende Abbildung an. Dabei dient common behaviors (Klasse: CommonBehaviors) als Generalisierung der Klassen mit den eigentlichen Konstrukten. Diese werden in den folgenden Kapiteln erläutert.


 

Abbildung 7.6-1:

Die Konstrukte der UML für die Modellierung von Verhalten und ihr Zusammenhang.
Quelle: [OMG 2003a, S. 201], grafisch verändert, Übersetzung durch den Verfasser

7.7 Token – eine erste Annäherung

In Zusammenhang mit der Verhaltensmodellierung spielt bei den UML-Autoren der Begriff des Token eine sehr große Rolle. Bei der Ausarbeitung des Kontrollflusskonzepts (vgl. unten) dient er sogar der methodischen Fundierung. Da er auch schon sehr früh bei den folgenden Ausführungen vorkommt, wird er hier erläutert.

In der Informatik taucht dieser Begriff im Zusammenhang mit formalen Sprachen auf, im engeren Bereich der Compiler bzw. Parser:

Token in der
Informatik

„Die erste von einem Compiler zu lösende Aufgabe besteht darin, das Programm in Token zu zerlegen; Token sind Teilstrings, die logisch zusammenpassen. Beispiele sind Bezeichner, Konstanten, Schlüsselwörter wie then und Operatoren wie + oder <=. Jedes Token kann als regulärer Ausdruck spezifiziert werden;“ [Aho und Ullmann 1996, S. 751]

Etwas detaillierter bei [Horn, Kerner und Forbrig 2001, S. 409] in Bezug auf das Beispiel C++:

„Der Eingabestrom wird ... in Abschnitte (Lexeme) zerlegt. Dabei gibt es Lexeme, die herausgefiltert werden, weil sie syntaktisch keine Bedeutung haben, wie z.B. Kommentare, und solche, die zusammen mit einigen Zusatzinformationen ... an die syntaktische Analyse weitergegeben werden. Diese werden auch Token genannt.“ Die syntaktische Analyse erzeugt „... einen Tokenstrom, der ... dem Parser übergeben wird, der die eigentliche syntaktische Analyse vornimmt. In der Sprechweise der formalen Sprachen sind die Token (in der Literatur auch Morpheme genannt) die Terminalsymbole für den Parser. Typische Token sind Wortsymbole (Schlüsselwörter, reservierte Wörter), Klammern, Operatoren, Literale (Zahlwörter, Zeichenketten) und Bezeichner (Namen für Konstanten, Variablen und Funktionen).“

Dasselbe meinen [Gumm und Sommer 1998, S. 542], wenn sie Token als elementare Bestandteile eines Programmes definieren.

Zusammengefasst kann damit festgehalten werden, dass in der Informatik Token kleinste interpretierbare Einheiten einer formalen Sprache sind.

Die UML-Autoren erläutern bei der Beschreibung der Semantik von Aktivitäten, was sie unter einem Token verstehen (alle nachfolgenden Zitate stammen von [OMG 2003a, S. 286] und sind vom Verfasser übersetzt):

Nun die UML-
Autoren:

Ein Token enthält ein Objekt, einzelne Daten oder Kontrollinformation.

Entsprechend ist die Wortwahl: Objekttoken, Datentoken und Kontrolltoken.

Dabei geht es um Objekte von Objektklassen aus dem objektorientierten Modell, das den dynamischen Bereich umgibt, oder um etwas virtuelles, was direkt aus der Modellbildung kommt, um die Information, wo der Kontrollfluss gerade steht. Die UML kennt mittlerweile, wie unten erläutert wird, ein Kontrollflusskonzept und zu diesem gehört natürlich dann auch die Information, an welcher Stelle (typischerweise Knoten) der Kontrollfluss bei einer konkreten Realisierung wann steht.

Ein Token ist im Aktivitätsdiagramm (das eine Tätigkeitsfolge beschreibt) einem bestimmten Knoten zugeordnet.

Das ergänzt obiges. Die Token wandern entlang der verschiedenen Kontrollflusszweige durch “die Aktivität” bzw. durch das Aktivitätsdiagramm.

Token haben Ausprägungen.

So hat z.B. ein Objekt der Objektklasse Angestellte bestimmte Ausprägungen, genauso eine Ausprägung des Attributs Gehalt und auch der Token, der die Kontrollinformation enthält, ist immer an einer bestimmten Position und hat damit eine Ausprägung.

Alle Token sind verschieden, auch wenn sie dieselbe Ausprägung haben.

Dies korrespondiert mit der Tatsache, dass im objektorientierten Ansatz Objekte einer Objektklasse auch dann verschieden sind, wenn sie dieselben Attributsausprägungen haben.

Soweit eine erste Annäherung an den Token-Begriff der UML-Autoren. Wie man sehen kann, geht es auch hier – wie in der allgemeinen Definition – um elementare Informationseinheiten, wenngleich auch in drei sehr verschiedenen Varianten. Objekt- und Datentoken haben, wie in Kapitel 10 zu sehen sein wird, eine durchaus praktische Bedeutung im Kontrollfluss. Etwas abgehobener ist das Konzept der Kontrolltoken. Es kann allerdings, wenn man Kontrollflüsse modelliert, durchaus von Wert sein, ein Mittel zu haben, den konkreten Kontrollfluss zu beschreiben. V.a. wenn, wie hier, neben dem Kontrollfluss auch Daten und Objekte fließen. Dazu unten mehr.

Elementare
Informations-
einheiten und Steuerinformation

In den folgenden Abschnitten wird dieser Token-Begriff immer wieder thematisiert, da er eine der Grundlagen des Kontrollflusskonzeptes ist.