OOP Programming UML Aktivitätsdiagramm

Mit Hilfe eines Aktivitätsdiagramms beschreibt man Aktivitäten, also allgemeine Abläufe und deren chronologische Reihenfolge, wie sie zur Laufzeit eines Programms vorkommen. Die Aktivitätsdiagramme sind von allen Beschreibungsdiagrammen für das Verhalten sehr wahrscheinlich das praktikabelste Modell, das zudem sicherlich am häufigsten eingesetzt wird.

Meist sind diese dynamischen Beschreibungen der Realität nicht ganz so einfach, wie es in manchen Abhandlungen beschrieben wird. Sicherlich kann auch dieses Buch keine Projektbeispiele aus der Praxis verwenden, da sie sehr schnell den Rahmen dieses Buches sprengen würde. In der natürlichen Sprache entsteht allerdings fast nie ein umfassender Überblick über die Abläufe, so dass ein Diagramm zur Beschreibung sicherlich bessere Dienste leistet. Die UML 2.0 stellt daher eine ganze Reihe an Notationselementen bereit, die dieser Aufgabe der komplexen Beschreibung Rechnung trägt. Eine Aktivität enthält dabei im Wesentlichen Knoten, gerichtete Kanten (Spezifikation: Flows), Aktionen und Kontrollknoten. Mit diesen zahlreichen Notationselementen kann man beispielsweise folgende Sachverhalte modellieren:

Aktivitätsdiagramme finden ihren Einsatz sowohl in der Analyse-Phase als auch in der Design-Phase eines Projektes. In der Analyse-Phase werden die Aktivitätsdiagramme genutzt, um Geschäftsprozesse genauer zu analysieren und schließlich auch zu modellieren. Dabei wird der genaue Ablauf, also das dynamische Verhalten, gezeigt. Zunächst aber soll diese Phase die Sichtweise der Auftraggeber darstellen. Natürlich lässt man in der Praxis die Feinheiten des Aktivitätsdiagramms bewusst außen vor und beschränkt sich auf grundlegende Elemente, um eine gemeinsame und zunächst einfache Sprache zwischen Entwickler und Anwender nutzen zu können. Später können dann je nach gewünschtem Grad die Diagramme mit größerem Detailreichtum versehen werden

Später, also in der Design-Phase, bieten die Aktivitätsdiagramme die Möglichkeit der Beschreibung von technischen Prozessen. An dieser Stelle kristallisieren sich auch die Lösungsansätze und Algorithmen heraus und somit werden die Aktivitätsdiagramme schnell zur präzisen Vorlage für den Entwickler.

Abbildung 4.1: Aktivitätsdiagramm zeigt eine Aktivität und ihre grundlegenden Bestandteile.

Im Folgenden werden wir natürlich noch alle dazugehörigen Notationselemente erläutern, die Sie insbesondere für die Prüfung benötigen. Allerdings verschafft das Beispiel in vorheriger Abbildung durchaus einen ersten Eindruck, wie Aktivitätsdiagramme grundsätzlich aufgebaut sind. Für die Prüfung ist es nicht unmittelbar wichtig, alles über Softwareentwicklung zu wissen, und die UML 2.0 ist nicht nur auf Softwareprojekte anwendbar. Man kann damit auch einfach die Geschäftsabläufe darstellen und analysieren, was natürlich auch bei einer nachfolgenden Softwareentwicklung durchaus der erste Schritt seien sollte. Ohne ein grundsätzliches Verständnis der Geschäftsvorfälle und der internen Abläufe kann Software nicht gelingen. Ganzheitlich betrachtet ist die Software das Mittel zum Zweck, nämlich zur Unterstützung des Geschäftsmodells. Wenn man sich in die Lage eines Seminarunternehmens versetzt, kann man dieses sehr simple Beispiel durchaus auf Anhieb verstehen:

Beispielsweise klingelt das Telefon und ein potenzieller Teilnehmer möchte ein Seminar buchen. Nun muss nachgesehen werden, ob das Seminar überhaupt stattfinden kann, ob also genügend Teilnehmer vorhanden sind. Wenn dies der Fall ist, endet der Vorgang mit dem Stattfinden des Seminars. Ansonsten wird ein anderer Termin angeboten. Wenn der neue Termin dem Teilnehmer zusagt, wird wiederum überprüft, ob für dieses Seminar genügend Teilnehmer vorhanden sind. Natürlich könnte man hier einwenden, dass Termine herausgesucht werden, die bereits genügend Teilnehmer haben, was an dieser Stelle aber mehr oder weniger eher ein SQL-Problem darstellt, weil solche Daten in einer Datenbank vorhanden seien sollten.

Abhängigkeiten

In Abbildung 4.2: Abhängigkeiten der Aktivitätspakete werden zunächst einmal die Abhängigkeiten der Aktivitätspakete aufgezeigt. Hierbei geht es erst einmal darum, einen groben Überblick zu erhalten.

Das Metamodell

CallBehaviourAction

Eine Aktion vom Typ CallBehaviourAction ruft ein anderes Verhalten direkt auf. Dies kann naturgemäß innerhalb des Kontextes Aktivitätsdiagramm eine weitere Aktivität sein und außerhalb dieses Kontextes ein Zustandsautomat.

CreateObjectAction

Hier geht es um die Erstellung von Objekten mit Aktionen und Aktivitäten, dies ist allerdings nicht Bestandteil der Fundamental- Prüfung. In weiteren Zertifizierungsstufen werden Sie sich damit allerdings sicher auseinandersetzen müssen.

Beschreibung der Kontrollknoten

Kontrollknoten (Spezifikation: ControlNodes) hängen eng mit den Konnektoren zusammen, die Verbindungen zwischen Aktivitäten strukturiert ausdrücken. Die Konnektoren sind nicht unmittelbar Thema der Prüfung.

Abbildung 4.3: ControlNodes (IntermediateActivities) zeigt die Vererbungshierarchie zwischen den einzelnen verschiedenartigen Knoten, die nachfolgend beschrieben werden.

Man sieht in Abbildung 4.3: ControlNodes (IntermediateActivities) sehr deutlich, welche Knoten für die Aktivitätsdiagramme relevant sind. In den folgenden Unterpunkten bieten wir Ihnen eine Übersicht über die einzelnen Knoten:

An dieser Stelle muss erwähnt werden, dass es natürlich auch einen Start-Knoten geben muss (Spezifikation: InitialNode). Dieser fehlt in vorheriger Abbildung, da es sich um die erweiterten Knoten handelt.

Start- und Endknoten

Start- und Endknoten sind von den Kontrollknoten gemäß der Spezifikation direkt abgeleitet, wie Sie in Abbildung 4.4: BasicActivities (Knoten) ersehen können:

Schaut man sich das Diagramm aus der Spezifikation einmal genauer an, so wird deutlich, dass sowohl ActivityFinalNode als auch InitialNode Kontrollknoten sind, die wiederum von den ActivityNodes erben. Auf der anderen Seite gibt es den Objektknoten, der einmal als Pin und einmal als Parameterknoten dargestellt werden kann.

Aktivität

Die Aktivität (Spezifikation: Activity) ist direkt von Behavior abgeleitet, wie Sie in Abbildung 4.5: FundamentalNodes leicht nachvollziehen können. Eine Aktivität kann beliebig viele Aktivitätsknoten (Spezifikation: ActivityNode) enthalten, wobei die Knoten durch eine Komposition mit ihrer Aktivität verbunden sind. Ein Aktivitätsknoten darf zu einer Aktivität gehören. Der Knoten kann aber formal auch für sich alleine stehen, was die Multiplizitäten angeben. Die Kanten (Spezifikation: ActivityEdges) stehen wiederum für den Kontroll- und Datenfluss, wie Sie später noch sehen werden. Mit dem Tokenkonzept lernen Sie nachfolgend den wesentlichen Mechanismus ausführlich kennen.

Eine Aktivität (Spezifikation: Activity) ist die gesamte Beschreibung einzelner Aktionen, die einen Kontrollfluss und zudem einen Objektfluss besitzen, wobei die Begriffe Objektfluss und Kontrollfluss nachfolgend erläutert sind.

Wie Abbildung 4.6: Kontroll- und Objektflüsse entnehmen können, gibt es zwei verschiedene Flüsse, nämlich einmal den Kontrollfluss (Spezifikation: ControlFlow) und den Objektfluss (Spezifikation: ObjectFlow). Beide sind von der Aktivitätskante (Spezifikation: ActivityEdge) abgeleitet, die diesen Fluss darstellt. Beide Flüsse gehören zu einer Aktivität, können aber auch für sich alleine stehen. Sie haben jeweils einen Aktivitätsknoten entweder als Ziel (Spezifikation: target) oder als Quelle (Spezifikation: source).

Hier sehen Sie sehr deutlich, dass der ActivityParameterNode grundsätzlich einen Parameter hat. Er erbt von TypedElement und von ActivityNode, was Sie in vorheriger Abbildung nicht ersehen. Die Daten des Objektknotens haben also einen bestimmten Datentyp.

Bei einer Aktion und damit natürlich auch bei einer Aktivität gibt es eine Vor- und eine Nachbedingung (Spezifikation: Precondition, Postcondition), wie wir bereits festgestellt haben. Abbildung 4.8: Constraints zeigt die genauen Verhältnisse.

Eine Aktion darf gemäß Abbildung 4.8: Constraints beliebig viele Vor- und Nachbedingungen besitzen. Die einzelnen Bedingungen (Spezifikation: Constraints) gehören fest zu der Aktion selbst, was durch die Kompositionsbeziehung dargestellt wird.

In Abbildung 4.9: Flows: Komplette Aktivitäten (CompleteActivities) ist noch einmal der Objektfluss und der Kontrollfluss im Metamodell aufgegriffen worden und wird genauer erläutert. So sieht dieser zwar aus wie der Kontrollflusspfeil, bedeutet allerdings, dass etwas transportiert wird. Die beiden Eigenschaften isMulticast und isMultireceive sind auf

Objektknoten werden nach dem FIFO-Prinzip geordnet, wie Sie in Abbildung 4.10: Objektknoten (CompleteActivities) aus der Spezifikation deutlich erkennen.

Dabei gibt es die Aufzählung ObjectNodeOrderingKind, die bei mehreren vorhandenen Objekten die Reihenfolge festlegt.

Wert	Bedeutung
unordered	Eine Reihenfolge ist nicht festgelegt.
ordered	Die Reihenfolge ist geordnet: a, b, c, d.
LIFO	Das Objekt, das als letztes hineingekommen ist, kommt als erstes wieder heraus (Last In First Out).
FIFO	Das Objekt, das als erstes hineingekommen ist, kommt als erstes wieder heraus (First In First Out).

Zentraler Puffer

In der Spezifikation erkennen Sie, dass der DataStoreNode von dem CentralBufferNode abgeleitet ist (siehe Abbildung 4.12: DataStore).

Aktivitätsgruppe

Eine Aktivitätsgruppe (Spezifikation: ActivityGroup) ist eine Zusammenfassung von Objekten, die zurzeit lebendig, also aktiv sind und somit einen eigenen Kontrollfluss besitzen. Die Klassen können mit den aktiven oder passiven Objekten zur Laufzeit verbunden sein. Abbildung 4.13: Fundamental groups soll den Zusammenhang einmal genauer erläutern:

Die Aktivitätsgruppe kann beliebig viele Aktivitätskanten (Spezifikation: ActivityEdge) enthalten. Umgekehrt kann eine Kante auch mehrere Aktivitäts-gruppen enthalten. Siehe Abbildung 4.14: Groups

Ein Objekt aus der ActivityGroup, das zum aktuellen Zeitpunkt die Programmkontrolle (Programmsteuerung) besitzt, nennt sich im Übrigen Control Object. Während der Programmausführung kann die Programmkontrolle innerhalb einer ActivityGroup von einem Objekt an ein anderes Objekt übergeben werden, wenn ein Methodenaufruf innerhalb der ActivityGroup passiert ist, andernfalls kann ein Objekt die Programmkontrolle nur dann verlieren, wenn es einen stabilen Zustand erreicht hat. Von einem stabilen Zustand wiederum spricht man, wenn das Objekt selbst aktiv ist und kein ungetriggerter Übergang möglich ist. Das würde bedeuten, dass die weitere Ausführung nur dann möglich ist, wenn man einen Signal- oder Operationsaufruf empfangen hat.

Partitionen

Partitionen (Spezifikation: ActivityPartition) gruppieren einzelne Aktionen einzelnen Verantwortlichkeitsbereichen zu. Dabei kann die Einteilung nach speziellen Eigenschaften erfolgen. Abbildung 4.15: Partitionen aus der Spezifikation erläutert die Zusammenhänge.

Das Konzept der Token

Das Konzept der Token (Spezifikation: tokenflow) ist vom Prinzip her einfach zu verstehen. Es gibt kein Notationselement, das die Token in der UML 2.0 notiert, daher gibt es der Verständlichkeit halber kleine durchnummerierte Punkte, beginnend mit T1 in den folgenden Abbildungen dargestellt. Diese Punkte sind allerdings keine Notationselemente der UML 2.0, sondern eine eigene Darstellung, wie sie häufig an Universitäten verwendet wird. Von den Token selbst ist jedoch durchaus in der UML-2.0-Spezifikation die Rede.

Unter einem Token versteht man in der UML 2.0 eine Marke, die einen Zeitpunkt darstellt, in dem sich der gesamte Ablauf gerade befindet. Der Token-Fluss bestimmt, dass der gesamte Ablauf einem bestimmten vorgegebenen Weg folgt, der durch die so genannten Kanten dargestellt wird. Eine neue Aktion kann nur dann ablaufen, wenn an der eingehenden Kante ein Token vorhanden ist. Dabei muss beim Durchlaufen einer Kante immer eine Bedingung (Spezifikation: Guard) erfüllt sein, um den Token weitergeben zu können. Standardmäßig ist der Wert dieser Bedingung auf

Beachten Sie bitte, dass in der Abbildung der Kreis mit T1 keine UML-2-konforme Syntax darstellt. Diese Darstellungsweise nutzen wir nur, um das Konzept zu erläutern. Wenn eine Aktion ihren Dienst erfüllt hat und beendet ist und von ihr eine weitere Aktion aufgerufen wird, so wird an allen von der betreffenden Aktion ausgehenden Kanten ein neuer Token zur Verfügung gestellt. Somit lassen sich auch nebenläufige Abläufe darstellen.

Abbildung 4.17: Token für einen Entscheidungszweig verdeutlicht die Vorgehensweise bei einer Entscheidung. Gleiches gilt aber auch bei der Zusammenführung von Kanten und für alle anderen Notationselemente der Aktivitätsdiagramme. Hierbei müssen die Regeln dieser notierten Kante erfüllt bleiben. Die nachfolgenden Aktionen müssen zudem in der Lage sein, den Token aufzunehmen und zu verarbeiten, und die vorherige Aktion muss wiederum einen Token zur Verfügung stellen. Es gibt auch den Fall, dass mehrere Token zu einem Token zusammengeführt werden, wie dies Abbildung 4.18: Zusammenführung von mehreren Token zu einem Token zeigt.

Neben den Alternativabläufen sieht die UML 2.0 auch die Aufteilung von Abläufen in nebenläufige Zweige vor. Die Aktionen werden dann dort parallel verarbeitet. Abbildung 4.19: Nebenläufige Aktionen zeigt die Aufspaltung in zwei nebenläufige Aktionen, in der ein Token vervielfältigt wird.

Nun gibt es den Fall der Zusammenführung von parallelen Abläufen. Hierbei werden mehrere Token zu einem Token zusammengefasst, sobald alle Token gesammelt vor der Synchronisation vorliegen, wie Abbildung 4.20: Zusammenführung von Aktionen: hier UND-Synchronisation demonstriert.

Bisher haben wir nur eine Art von Kanten beschrieben, nämlich die Kontrollflusskanten. Nachfolgend kümmern wir uns um die so genannten Objektflusskanten, die durchaus sehr ähnlichen Mechanismen folgen, wobei aber ein paar Dinge zu beachten sind.

Während die Token auf den Kontrollkanten Aktionsabläufe steuern, haben die Token auf den Objektkanten noch eine zusätzliche Aufgabe. Sie müssen die Daten von einer Aktion zur nächsten transportieren. Zwischen solchen Aktionen gibt es grundsätzlich immer mindestens einen Objektknoten, der für den Datentransport verantwortlich ist, wie Sie später noch genauer sehen werden. Der Unterschied ist, dass der Ausgangspunkt, beziehungsweise das Ziel einer Kante, ein Objektknoten ist. Token, die in den Objektknoten hineingehen, transportieren Parameter in das Objekt und stellen somit die Daten zur Verfügung. Der aus dem Objektknoten herauskommende Token transportiert das Objekt und dessen Daten in die nächste Aktion. Die Token verweilen dort in den Aktionen, bis sie abgearbeitet sind. Im Objektknoten nehmen Sie Werte auf und transportieren diese. Abbildung 4.21: Token bei Objektknoten verdeutlicht diesen Schritt.

Wenn man nun die gleiche Logik, wie in den vorherigen Abbildungen demonstriert, für Entscheidungsknoten, Zusammenführungsknoten, UND-Synchronisation und der Nebenläufigkeit haben möchte, gibt es beim Objektfluss im Gegensatz zum Kontrollfluss einen entscheidenden Unterschied. Der Objektknoten bewirkt, dass die Ausgangsparameter nicht nebenläufig verteilt werden können. Somit wird entschieden, welche Kante nachfolgend genutzt wird. Das Problem kann dadurch vereinfacht werden, dass man direkt einen Entscheidungsknoten nimmt, da der logische Sachverhalt exakt der gleiche ist. Abbildung 4.22: Parallelläufigkeit mit einem Objektknoten nicht möglich soll den Unterschied verdeutlichen.

Der andere Fall ist noch komplizierter darzustellen und das Ergebnis ist für den Modellierer definitiv unbrauchbar. Wenn man von zwei Aktionen aus jeweils einen Objektknoten hat, dann würde in der Zusammenführung die Aktion 3 in der Abbildung 4.23: Zusammenführung mit zwei Objektknoten nicht möglich zweimal aufgerufen werden.

Notation von Aktivitätsdiagrammen

Startknoten

Es gibt natürlich innerhalb jeder Aktivität einen Startknoten (Spezifikation: InitialNode). Dieser ist nicht direkt in der Abbildung der Kontrollknoten zu ersehen, allerdings hängt er mit den Endknoten (Spezifikation: FinalNode) zusammen. Mit dem Startknoten startet logischerweise der Ablauf der Aktivität. Dabei darf jeder Startknoten beliebig viele weiterführende Kanten besitzen. Der Startknoten generiert einen Token und bietet diesen allen Kanten an. Dabei ist der Startknoten der einzige Knoten, der den generierten Token eine Zeit lang halten darf, falls nachfolgende Notationselemente ihn nicht sofort übernehmen können. Es gibt am Startknoten keine eingehende Kante. Ein Startknoten ist nicht zwingend vorgeschrieben.

Endknoten

Ein Endknoten (Spezifikation: FinalNode) beschreibt das Ende der Aktivität und markiert sozusagen das Ende eines Ablaufs. Es können beliebig viele Kanten in den Endknoten hinein laufen, allerdings darf keine Kante davon weiterführen. Es gilt die so genannte Oder-Semantik, was bedeutet, dass der Ablauf dann zu Ende ist, wenn der Endknoten, egal über welche Kante, erreicht worden ist. Gibt es innerhalb einer Aktivität eine eigene Aktivität, so kann die innere Aktivität selbst irgendwann enden, was das Ende des Kontrollflusses bedeutet, aber sie kann natürlich auch die äußere Aktivität beenden. Im ersten Fall beendet der Endknoten die gesamte Aktivität für eine Aktivität, egal wie viele Aktivitäten parallel laufen. Bei dem anderen Fall wird nur der Kontrollfluss beendet. Abbildung 4.25: Gegenüberstellung der zwei Endknoten ist die Notation dargestellt.

Wie in Abbildung 4.26: Seminar buchen demonstriert, bucht ein Teilnehmer ein Seminar, es werden die Teilnehmerunterlagen bestellt, und wenn das Seminar beendet ist, werden alle Teilnehmer verabschiedet. Die Bestellung der Seminarunterlagen erfolgt gesondert in einer eigenen Aktivität.

Einen kleinen Unterschied kann man in der Notation der Aktivitäten erkennen, nämlich den, dass die entsprechende Aktivität, die einen eigenen Kontrollfluss hat, etwas anders notiert ist.

Abbildung 4.28: Seminarbuchung mit der Buchbestellung zeigt die beiden Verläufe vollständig. In der Praxis ist das häufig viel komplizierter, da die Aktivitätsdiagramme wesentlich umfangreicher sind und somit klarer gegliedert werden müssen.

Die Notation des Endknotens ist hierbei entscheidend. Laut Abbildung 4.28: Seminarbuchung mit der Buchbestellung besagt das Ende des Kontrollflusses, dass nur der Kontrollfluss innerhalb der untergeordneten Aktivität Buchbestellung beendet wird. Der äußere Kontrollfluss wird dadurch nicht beendet. Würde man den Endknoten in der Aktivität Buchbestellung am Ende unterbringen, so wäre der Kontrollfluss der äußeren Aktivität ebenfalls zu Ende.

Entscheidungsknoten

Der Entscheidungsknoten (Spezifikation: DecisionNode), der durch eine ausgefüllte Raute dargestellt wird, kann eine eingehende und mehrere ausgehende Kanten enthalten. Ein Token, der über die eingehende Kante ankommt und am Entscheidungsknoten eingeht, wird je nach der Bedingung (Spezifikation: Guard) weitergeleitet. Die Bedingung selbst wird an der ausgehenden Kante ausgewertet, wobei in der UML 2.0 keine Auswertungsreihenfolge definiert ist.

Dabei kann eine Entscheidung mit einem Kommentar noch näher beschrieben werden. Bei dem spezifizierten Verhalten kann somit zum Beispiel ein Wert auf wahr oder unwahr geprüft werden und die Entscheidung, welche Kante verfolgt wird beruht auf einem booleschen Wert.

Zusammenführung

Eine so genannte Zusammenführung (Spezifikation: MergeNode) wird mit dem gleichen Notationselement wie der Entscheidungsknoten dargestellt. In diesem Falle gibt es allerdings mehr eingehende Kanten und nur eine ausgehende Kante. Es werden also mehrere Kanten zu einer ausgehenden Kante zusammengeführt. Dabei wird nicht gewartet oder Ähnliches, wie dies bei den Synchronisierungsknoten der Fall ist (Synchronisierungsknoten sind nicht Teil dieser Fundamental-Prüfung). Im Übrigen können Entscheidungs- und Zusammenführungselemente kombiniert werden. Das Ergebnis sind dann mehrere eingehende und mehrere ausgehende Kontrollflüsse (siehe Abbildung 4.31: Zusammenführungskonten).

Gabelungsknoten

Der Gabelungsknoten (Spezifikation ForkNode) teilt einen Kontrollfluss in mehrere parallele Kontrollflüsse auf. Der Unterschied zum Entscheidungsknoten ist der, dass hier nicht ein spezieller Weg gewählt wird, sondern alle Kontrollflüsse quasi gleichzeitig ablaufen. Somit werden die einzelnen Abläufe parallel (in der Literatur meistens nebenläufig genannt) abgearbeitet. Diese Form nennt sich in namhaften Programmiersprachen wie C++, C# und Java Multithreading. Notwendig ist diese Form der Programmierpraxis bei Anwendungen, in denen mehrere Kontrollflüsse gleichzeitig ablaufen müssen. Ein Beispiel wäre das Versenden einer E-Mail in Outlook. Dabei kann das Versenden der E-Mail mit einem großen Anhang sehr lange dauern. Dennoch ist das Programm weiterhin bedienbar.

Die Notation der Gabelung in der Abbildung 4.32: Gabelung (Spezifikation: ForkNode) aufgezeigt:

Vereinigung

Die Vereinigung besagt genau das Gegenteil. Man spricht in diesem Zusammenhang auch von der UND-Synchronisation. Dabei wird gewartet, bis alle Token der betroffenen Knoten angekommen sind. Diese können dann wiederum zu einem neuen Token werden. Dieses Konzept wird nachfolgend noch ausführlicher genutzt.

Eine Vereinigung besteht wiederum aus mehreren Kontrollflüssen, aus dem ein einziger Kontrollfluss wird.

Aktivität

Eine Aktivität wird dargestellt durch ein Rechteck mit abgerundeten Ecken. Jede Aktivität enthält Kanten und Aktionsknoten, die auch Aktionen genannt werden. Innerhalb des Rechtecks befinden sich die Aktionen und Kanten. Innerhalb der Aktivität kann man Vorbedingungen und Nachbedingungen festlegen. Diese werden mit den Schlüsselwörtern <<precondition>> und <<postcondition>> in der Aktivität festgelegt. Die Eingangsparameter und Ausgangsparameter werden mit Rechtecken dargestellt, die sich über den Rand der Aktivität strecken. Sie nennen sich in der UML 2.0 auch Pins. Abbildung 4.35: Aktivität zeigt schematisch eine Aktivität mit mehreren Elementen:

Aktion (Spezifikation: Action)

Eine Aktion (Spezifikation: Action) wird dargestellt durch ein Rechteck mit abgerundeten Ecken. Eine Aktion implementiert den Aufruf eines Verhaltens oder deren Bearbeitung. Dabei werden beispielsweise Algorithmen abgearbeitet und zum Schluss meistens andere nachfolgende Aktionen aufgerufen. Innerhalb einer Aktivität kann die jeweilige Aufgabe nicht weiter sachlogisch zerlegt werden. Die Aktivität besteht aus der Summe der Aktionen und natürlich deren Reihenfolge. Die Reihenfolge wird wiederum durch die so genannten Kanten, die später noch ausführlicher erläutert werden, festgelegt und notiert. Die Aktion selbst ist der Hauptdarsteller in einer Aktivität, um die sich alles dreht. Alle weiteren Notationselemente dienen nur der Steuerung, dem Ablauf und der Notation der Parameterübergaben etc. Eine Aktion selbst kann auch eine andere Aktion aufrufen, also vom Prinzip her als Aufruf einer Operation dienen. Später werden wir Sie noch sehen, wie beispielsweise eine Aktion Signale sendet und empfängt. Zudem ist eine Aktion in der Lage, ein Objekt komplett zu erzeugen, zu löschen und zu ändern. Abbildung 4.36: Aktion zeigt noch einmal eine simple Aktion.

Mit einer Aktion kann auch eine Aktivität aufgerufen werden. Der Vorteil ist, dass man Sachaspekte herausstellen kann und auf andere Sachaspekte verweisen kann, die in einem neuen Diagramm dargestellt werden.

Kanten (Spezifikation: ActivityEdges)

Über die so genannten Kanten haben Sie schon einiges erfahren. Hier noch einmal zusammenfassend: Die Übergänge zwischen Aktionen und Objektknoten regeln die so genannten Kanten (Spezifikation: Flows). Die Kanten haben grundsätzlich eine Richtung und enden an einem Element mit einem offenen Pfeil. Sie können aus Gründen der Verständlichkeit mit einem Namen notiert werden. Wie schon bei dem Token-Konzept kennen gelernt, gibt es zwei Arten von Kanten:

Abbildung 4.37: Einfache Kante zwischen zwei Aktionen zeigt eine einfache Kante zwischen Aktion 1 und Aktion 2.

Objektknoten

Objektknoten sind Knoten, die Parameter übergeben können. Sie können von einer Aktivität ausgehen und sie werden grundsätzlich mit einem Rechteck gezeichnet.

Diese Objektknoten (Spezifikation: ObjectNode) modellieren die Übergabe von Objekten zwischen Aktionen. Der Objektfluss (ObjectFlow), der in den Aktivitäten vorgestellt wurde, sorgt dafür, dass die Objekte auch transportiert werden. Dabei bildet ein Objektknoten etwas ab, was ein Objekt darstellen könnte, dem ein Verhalten widerfahren kann (siehe Abbildung 4.39: Objektknoten und Objektfluss).

Aktion1 stößt also eine Veränderung des Objektes an, wobei das Objekt durch die vorhergehende Aktion durchaus eine Zustandsänderung durchlaufen haben könnte. Es besteht die Möglichkeit, den Zustand, in den das Objekt überführt wird, durch eine eckige Klammer zu beschreiben, wie in Abbildung 4.40: Objektknoten mit Zustandsangabe

Unter dem Zustand kann man nun sehr vieles verstehen, nehmen wir an, es handelt sich bei unserem Objekt um eine Rechnung. Eine Rechnung ist beispielsweise bezahlt oder eben noch nicht bezahlt. Sie befindet sich dann in einem der beiden Zustände.

Es gibt zudem noch die so genannte Pin-Notation, wobei die Zustände auf beiden Seiten zwingend gleich sein müssen (Abbildung 4.41: Pin-Notation mit Zustandsangabe).

Ein Beispiel für einen zentralen Puffer, der wie ein Objektknoten angegeben wird, der mit dem Stereotyp <<centralBuffer>> ausgezeichnet wird, wären alle Teilnehmer für ein Seminar, während jeder einzelne Teilnehmer ein Objekt vom Typ Teilnehmer darstellt.

Nunmehr würde solch ein centralBuffer aber gelöscht werden, wenn das Programm beendet oder der Rechner neu gestartet wird oder Ähnliches. Wir möchten aber, dass die Teilnehmerdaten entsprechend dauerhaft gespeichert werden. Jetzt kommt der Datenspeicher (Spezifikation: datastore) ins Spiel, der diese Daten entgegennimmt und speichert.

Kontrollfluss in der Praxis

Kanten sind immer gerichtet sind. Somit gibt es zwischen mehreren Aktionen einen genau definierten Ablauf und die einzelnen Aktionen werden in chronologischer Reihenfolge abgearbeitet. Kanten können natürlich auch zwischen einer Aktion und einem Kontrollelement, wie einem Verzweigungsknoten, eingesetzt werden, wie Sie bereits in vorherigen Beispielen gesehen haben. Gemäß dem Token-Konzept lösen die Token selbst die Ausführung der folgenden Aktionen aus. Umgekehrt bedeutet ein Pfeil von dem Objektknoten zur Aktion, dass Eingabeparameter für die nächste Aktion eine Rolle spielen. Zur Veranschaulichung folgendes Beispiel:

Stellen Sie sich vor, dass durch eine Aktion etwas entsteht, beispielsweise tut jemand etwas und es wird etwas produziert. Mit diesem Produkt kann dann etwas gemacht werden, das Produkt kann unter einer Aktion verändert werden. Der Objektknoten kann sich in einem bestimmten Zustand befinden. Für Zustandsänderungen würde man hier sicherlich eher das Zustandsdiagramm anwenden. Im Aktivitätsdiagramm gibt es allerdings durchaus eine Möglichkeit anzudeuten, dass sich ein Objektknoten in einem bestimmten Zustand befindet. Dieser Zustand selbst kann mit einer nachfolgenden Aktion verändert werden, wobei diese erst dann beginnt, wenn der Objektknoten sich in dem angegebenen Zustand befindet. Es gilt hier natürlich auch das bereits vorgestellte Token-Konzept, wobei nur dann vom Objektknoten aufgenommen wird, wenn die Daten kompatibel sind. Der Zustand eines Objektknotens wird unter dem Namen des Objektknotens notiert und in eckigen Klammern eingefasst.

Objektfluss in der Praxis

Es gibt neben dem Kontrollfluss auch einen so genannten Objektfluss. An einer Objektflusskante ist natürlich immer mindestens ein Objektknoten beteiligt, wenn von einem Objektfluss die Rede ist. Die Token auf der Kante helfen, alle Werte und Parameter über die Objektknoten zu transportieren. Die Kante selbst ist rein zeichnerisch mit der Kontrollflusskante identisch, hat aber in Bezug auf die Parameter eine etwas andere Bedeutung.

Folgendes Beispiel soll noch einmal den Zusammenhang genauer darstellen. Eine Aktivität besteht in Abbildung 4.45: Aktivität mit Eingabeparametern aus einem Objektknoten, der die Eingabeparameter repräsentiert, und einem weiteren Objektknoten, der die Ausgabeparameter repräsentiert. An dieser Stelle können natürlich auch optional die Zustände in den Objektknoten vermerkt werden, die zu dem Zeitpunkt repräsentiert werden sollen. Wenn Eingangsparameter vorhanden sind, wird im Übrigen auf einen Startknoten verzichtet. Wenn die Aktivität an ihr Ende gelangt, liegt ein Objekt-Token am Ausgang der Aktivität an, der von einem Null-Token repräsentiert wird, wenn kein Objekt anliegt.

Es gibt noch andere Formen der Notationen des Objektflusses. Für den Fundamental-Test ist es sehr wichtig, die Pin-Notation zu verstehen. Ein Pin ist immer einer Aktion direkt zugeordnet, wobei ein Pin immer an einer Aktion anliegt. Es wird zwischen einem Eingangspin und einem Ausgangspin unterschieden. Die Aktion selbst kann beliebig viele Pins haben.

Zusätzlich kann an dem Namen Objekt in eckigen Klammern der Zustand angegeben werden, in dem sich das Objekt befindet.

Die jeweiligen Ein- und Ausgabepins müssen grundsätzlich kompatibel sein. Das heißt nicht direkt, dass die Objekte vom gleichen Typ sein müssen. Allerdings muss eine Generalisierung vorliegen, so dass die Kompatibilität auf jeden Fall gewährleistet ist. Zusätzlich zum Namen gibt es aus diesem Grunde auch die Möglichkeit, den Typ zu notieren. Dieser würde mit einem Doppelpunkt getrennt hinter dem Namen stehen.

Nun gibt es den Fall, dass eine Aktion keine weiteren Kanten nach sich zieht. Um hier korrekt zu notieren, ob die Objektknoten Ausgabeparameter oder Eingabeparameter sind, gibt es die nachfolgende Notation wie in Abbildung 4.48: Pin ohne weiterführende Kante mit Eingangsparametern.

Für die Eingangspins gibt es zudem noch eine spezielle Form, die ValuePins. Hauptsächlich beschreiben diese Wertepins Konstanten, wie einen Umrechnungsfaktor zwischen Währungen. Zur Darstellung wird ein Eingangspin wie ausvorheriger Abbildung genommen und neben dem Parameternamen noch eine Wertspezifikation (Spezifikatikon: ValueSpecification) angegeben.

Partitionen (Spezifikation: ActivityPartition)

Die Partitionen dürfen sowohl vertikal als auch horizontal modelliert werden. Der Objektfluss darf beliebig viele Partitionen durchlaufen und ein Aktivitätsknoten darf ebenfalls in mehreren Partitionen vorhanden sein.

Das Beispiel in Abbildung 4.50: Partition Seminar soll den Zusammenhang und schließlich die Handhabung der Partitionen darstellen:

OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm OOP Programming UML Aktivitätsdiagramm

Aktivitätsdiagramme der UML

Kontakt

Aktivitätsdiagramme

Einsatzgebiete

Abhängigkeiten

Das Metamodell

CallBehaviourAction

CreateObjectAction

Beschreibung der Kontrollknoten

Start- und Endknoten

Aktivität

Zentraler Puffer

Aktivitätsgruppe

Partitionen

Das Konzept der Token

Notation von Aktivitätsdiagrammen

Startknoten

Endknoten

Entscheidungsknoten

Zusammenführung

Gabelungsknoten

Vereinigung

Aktivität

Aktion (Spezifikation: Action)

Kanten (Spezifikation: ActivityEdges)

Objektknoten

Kontrollfluss in der Praxis

Objektfluss in der Praxis

Partitionen (Spezifikation: ActivityPartition)