8.1 Grundlagen

8.1.1 Definition

Die UML-Autoren definieren eine Aktion als eine elementare Verhaltenseinheit (“the fundamental unit of behavior specification”) und fahren fort:

Elementare Verhaltenseinheit

“An action takes a set of inputs and converts them into a set of outputs, though either or both sets may be empty.” [OMG 2003a, S. 203]

Dies klingt sehr datentechnisch, ja fast nach Programmmodulen, kann aber mit ein wenig Abstraktion auch auf Handeln/Tätigkeiten in Geschäftsprozessen übertragen werden.

Die Beschreibung als „fundamental unit“ macht auch deutlich, dass die UML-Autoren Aktionen als Elementareinheiten sehen, wobei dies bei Programmmodulen leicht (z.B. als der Programmcode der kleinsten Module), ansonsten aber nur schwer absolut definiert werden kann.

Bezogen auf die Aktivitäten (activities), in denen die Aktionen ja eingebettet sind, definieren die UML-Autoren eine Aktion als etwas, das ausführbar ist (es wird angestoßen) und das ein einzelnes Element der ausführbaren Gesamtfunktionalität einer Aktivität darstellt:

“An action is an executable activity node that is the fundamental unit of executable functionality in an activity, as opposed to control and data flow among actions.” [OMG 2003a, S. 280]

Der zweite Teil des Zitats deutet schon an, dass die Aktionen auch in einen Kontroll- und Datenfluss eingebettet sind. Dazu unten mehr.

Aktionen stellen also im Rahmen der Aktivitäten (vgl. den nächsten Abschnitt) „ausführbare“ Knoten dar, die mit einem Kontroll- und Datenfluss zwischen den Aktionen zusammenwirken. Ergänzend fahren die UML-Autoren dann fort, dass die Ausführung einer Aktion Veränderungen im modellierten System bewirkt:

Aktionen als
ausführbare Knoten

„The execution of an action represents some transformation or processing in the modeled system, be it a computer system or otherwise.” [ebenda]

Aktionen verändern

Damit sind die wichtigsten Merkmale von elementaren Verhaltens- oder Handlungseinheiten zusammengestellt.

Die Formulierungen der UML-Autoren sind sehr von der Sichtweise der objektorientierten Systemanalyse geprägt, können aber auch auf Anwendungsbereiche außerhalb der engeren Systemanalyse angewendet werden. So hat z.B. eine Kalkulation (als Tätigkeit in einem Geschäftsprozess) einen Input und einen Output, könnte als ausführbares Element des Geschäftsprozesses aufgefasst werden und ist eingebettet in einen Kontroll- und Datenfluss in einem größeren Ganzen, dem Geschäftsprozess. Außerdem stellt sie, das wollen wir nicht vergessen (oben bei den Zitaten der UML-Autoren ist es unausgesprochen dabei) auch „Verarbeitung“ dar. Schließlich muss der Input auf kompetente Weise zu einem Output (z.B. dem Preis für ein neues Produkt) finden.

Bezug zu Geschäftsprozessen

Beispiele für Aktionen finden sich in großer Zahl in den Aktivitäten des nächsten Kapitels.

8.1.2 Grafische Darstellung

Aktionen werden als Rechtecke mit abgerundeten Ecken dargestellt. Der Name der Aktion wird in das Rechteck eingefügt.

Die UML-Autoren sehen vor, dass eine Aktion auch in einer formalen Sprache, z.B. einer Programmiersprache, ausgedrückt werden kann. Die folgende Abbildung zeigt ein Beispiel.

Festlegung durch eine formale Sprache

Ebenfalls ist es möglich, bei Aktionen Vor- und Nachbedingungen für deren Ausführung zu hinterlegen. Diese lokalen Vor- und Nachbedingungen können als Anmerkungen an das grafische Symbol angehängt werden, so wie es die folgende Abbildung zeigt.

Die in der Abbildung ebenfalls angegebenen Pfeillinien an der Aktion verweisen schon auf die Einbettung jeder Aktion in den übergeordneten Kontrollfluss ihrer Aktivität (vgl. das nächste Kapitel).

8.1.3 Aktionen im Kontrollfluss

Aktionen sind in Aktivitäten (vgl. Kapitel 10) enthalten. In diesen stehen sie im Zusammenhang, werden z.B. in eine Reihenfolge gebracht. Dass hinter diesem „sequencing of actions”, wie die UML-Autoren schreiben, (natürlich) mehr als nur eine Anordnung in lineare Abfolgen steht, wird deutlich, wenn sie von Aktionen als Knoten und von „control edges“ und „object flow edges“ sprechen, also von Kanten, die den Kontrollfluss und den Fluss von Objekten modellieren.

Sequentielle
Anordnung von
Aktionen

Dahinter steckt ein umfassendes Kontrollflusskonzept, das im nächsten Abschnitt vertieft vorgestellt wird. Hier wird dies nur kurz betrachtet, um Eigenschaften von Aktionen ableiten zu können.

Auf welche Art sind also Aktionen in Aktivitäten eingebettet? Am wichtigsten sind hierbei die Aktivitätskanten (activity edges). Eine Aktion wird durch eine solche zu ihr führende Kante aktiviert. Sie startet dann, wenn u.a. alle ankommenden Kanten mit Kontrollinformationen, die Kontrollkanten (control edges), aktiv wurden. Und sie hat von ihr wegführende Kanten, die z.B. andere Aktionen anstoßen. Dazwischen leistet die Aktion ihren eigenen Beitrag zur Leistungserbringung. Die UML-Autoren sprechen dabei von Aktionsausführung (action execution) und definieren:

Kanten hin,
Kanten weg

“An action execution represents the run-time behavior of executing an action within a specific activity execution.” [OMG 2003a, S. 280]

In diesem Kontrollflusskonzept sind Aktionen also aktive Elemente, die angestoßen werden, etwas „tun“ und etwas weitergeben.

Die Aktionsausführung steht in einem engen Zusammenhang mit der Ausführung der gesamten Aktivität, der Aktivitätsausführung (activity execution). Diese besteht darin, einzelne Aktionen auszuführen. Jede Aktion kann bei einer bestimmten Aktivitätsausführung mehrfach, einmal oder auch nicht aktiviert werden.

Ausführen von Aktionen und Aktivitäten.

Mit der Wortwahl run-time behavior sind die UML-Autoren thematisch bei der Softwareentwicklung und bei der Systemanalyse. Dies ist bei vielen Textstellen so, der Anspruch auf die anderen Bereiche (siehe oben) wird zwar erhoben, im Text aber nicht immer bedacht.

Laufzeitverhalten

8.2 Vertiefung

8.2.1 Pins an Aktionen

Um den Input und den Output für Aktionen zu modellieren, wird in der UML das Konzept der Pins verwendet. Es sind so etwas wie Schaltstellen für die Aufnahme oder die Abgabe von Werten. Ein Pin repräsentiert jeweils entweder einen Input für eine Aktion (Input-Pin) oder einen Output (Output-Pin). Durch einen Pin fließen Objekte oder Daten.

Die Pins werden in der grafischen Darstellung als kleine Rechtecke dargestellt, die mit den Rechtecken der Aktion verbunden sind, wie es die folgende Abbildung zeigt. Die Bezeichnung des Pin wird neben das Rechteck gesetzt.

Grafische Darstellung

Zumindest in der Praxis der grafischen Darstellung legen die UML-Autoren den Kontrollfluss meist von links nach rechts. Deshalb ist das Pinsymbol für den Input auf der linken Seite der Aktion angebracht.

Entsprechend ist das Pinsymbol für den Output auf der rechten Seite angefügt.

Soweit ein erstes Kennenlernen der Pins. Eine vertiefte Darstellung folgt im folgenden Kapitel, wenn die weiteren dafür notwendigen Voraussetzungen vorgestellt sind.

8.2.2 Start einer Aktion

Wann kann eine Aktion starten? Eine Bedingung für den Start einer Aktion ist, dass alle Input-Pins Objekttoken haben. Die Aktion startet dann, indem sie Token von den zuführenden Kontrollkanten und den Input-Pins nimmt. Wenn die Durchführung beendet ist, bietet die Aktion den wegführenden Kontrollkanten und Output-Pins Token an, wo sie für andere Aktionen verfügbar sind bzw. andere Aktionen anstoßen [OMG 2003a, S. 280f].

8.2.3 Elementaraktionen

Mit Elementaraktion bezeichnen  die UML-Autoren die kleinsten Einheiten der Verhaltensmodellierung. Sie werden so elementar gefasst, dass sie entweder eine Berechnung oder einen Speicherzugriff beschreiben, niemals beides auf einmal [OMG 2003a, S. 203]. Damit ist eine eindeutige Abbildung auf ein physikalisches Modell möglich. Folgende Untertypen werden u.a. unterschieden [OMG 2003a, S. 204f]:

• Aufrufaktionen (invocation actions), die Operationen aufrufen und Signale senden.
• Leseaktionen (read actions), die Ausprägungen (values) erhalten und die in der Lage sind, diese zu erkennen.
• Schreibaktionen (write actions), die Ausprägungen (values) verändern und Objekte erzeugen und zerstören können.
• Objektaktionen (object actions), die Objekte erzeugen und zerstören.
• Strukturaktionen (structural feature actions), die das Lesen und Schreiben von Strukturmerkmalen von Objekten unterstützen.
• Assoziationsaktionen (association actions), die auf Assoziationen und Verknüpfungen (links) agieren.
• Variablenaktionen (variable actions), die das Lesen und Schreiben von Variablen unterstützen.
• Rechenaktionen (computation actions), die durch Aufruf einer Funktion eine Menge von Eingabewerten in eine Menge von Ausgabewerten tranformieren.

Beispiele für Elelementaraktionen

Folgende Beispiele für Elementaraktionen werden in [OMG 2003a, S. 284] genannt:

• Arithmetische Funktionen (als sog. Elementarfunktionen (primitive functions))
• Aufruf von Verhalten, z.B. in Aktivitäten
• Kommunikation, z.B. das Senden eines Signals
• Manipulation von Objekten, z.B. Lesen oder Schreiben von Attributen oder Assoziationen

8.2.4 Aktionen und Variable

Variablen sind uns ja bekannt aus der Mathematik und der Programmierung. Hier im Zusammenhang mit Aktionen sind sie Elemente, um Daten zwischen Aktionen “indirekt” weiterzugeben.

Indirekte
Weitergabe
von Daten

Eine lokale Variable speichert Werte, die von mehreren Aktionen einer zusammenwirkenden Gruppe benötigt werden. Nach außen stehen sie nicht zur Verfügung. Die Ausgabe einer Aktion kann in eine Variable geschrieben werden und als Eingabe einer nachfolgenden Aktion dienen. Dies meinen die UML-Autoren, wenn sie von einem indirekten Datenflussweg sprechen (vgl. [OMG 2003a, Abschnitt 12.3.40 (S. 363ff)]).

8.2.5 Untereinheiten

Aktionen sind die Grundelemente von Aktivitäten. Neben diesen definieren die UML-Autoren noch zusätzliche Untereinheiten, die subordinate units.

Dies sind Gruppen zusammengefasster Aktionen, die ebenfalls Elemente einer Aktivität sein können. Jede dieser subordinate units besteht wiederum aus einzelnen Aktionen, den Elementaraktionen (primitive actions).

Untereinheiten

Anmerkung:
Die Darstellung ist hierzu in [OMG 2003a] nicht einheitlich. An vielen Stellen wird diese mittlere Ebene der subordinate units nicht genannt, sondern die Aktivitäten einfach als aus Aktionen bestehend definiert. An vielen anderen wird aber diese mittlere Ebene bewusst erwähnt, z.B. auf Seite 4 bei einer Kurzdefinition von activity: „A specification of parameterized behavior that is expressed as a flow of execution via a sequencing of subordinate units (whose primitive elements are individual actions).”

Mit diesem Konzept ist es möglich, wie in allen Ansätzen der Unternehmensmodellierung, die Modellbildung auf verschiedenen Aggregationsniveaus vorzunehmen. Insgesamt liegen damit in der UML bezüglich der Abläufe folgende Aggregationsniveaus vor:

Aggregations-
niveaus

• Aktionen
• Subordinate Units
• Aktivitäten (vgl. Kapitel 10)

Das durch die subordinate unit abgedeckte Verhalten nennen die UML-Autoren dann subordinate behavior. Diese einzelnen Verhaltenskomponenten können gleich wie Aktionen in das Geschehen eingebunden werden. Gestartet werden sie z.B. dadurch dass ...

subordinate behavior

• andere Verhaltenskomponenten ihre Tätigkeit beenden.
• Objekte und / oder Daten verfügbar werden.
• externe Ereignisse eintreten.