Verhaltensdiagramme mit der UML

Einsatzgebiete

Wenn Sie sich bisher bereits schon mit der UML beschäftigt haben, so sind Sie an dem Klassendiagrammen ganz sicher nicht vorbeigekommen. Sie lernen nachfolgend – fast schon selbstverständlich – die Klassendiagramme und das nähere Umfeld dazu auch in diesem Buch kennen, das sich im Übrigen auf die Statik des Systems bezieht. An dieser Stelle des Buches kommen wir nunmehr bei der Beschreibung der Verhaltensgrundlagen zur dynamischen Seite eines Systems, also zum Verhalten. Warum wir das im Gegensatz zu anderen Veröffentlichungen vorziehen, hat einen entscheidenden Grund. Der Kunde selbst wird sich vom Prinzip her nicht mit den Klassen und der genauen Umsetzung direkt beschäftigen wollen, und wenn überhaupt, dann eher rudimentär. Das Verhalten nebst Aktivitätsdiagramm und Interaktivitätsdiagramm eignen sich hervorragend für die Beschreibung eines Systems und dessen Abläufe. Somit sind diese in einer Besprechung mit dem Kunden relevant und wichtig, um in der frühen Phase, der – wie in diesem Buch bereits öfters erwähnten – Analysephase, überhaupt eine gemeinsame Sprache zu sprechen. Mit den Verhaltensdiagrammen werden im Wesentlichen die einzelnen Elemente und deren Veränderungen zur Laufzeit beschrieben. Mit den Verhaltensdiagrammen der UML 2.0 soll also Klarheit über die Geschäftsprozesse, internen Abläufe, des Zusammenspiels des Systems und vieles mehr geschaffen werden. Es geht sozusagen um die Veränderungen der einzelnen Classifier eines Systems zur Laufzeit. Für diese Veränderungen gibt es verschiedene Diagrammtypen, die jeweils einen anderen Aspekt genauer beleuchten.

Da die UML 2.0 komplett objektorientiert ist, gibt es immer nur Objekte, die ihre Zustände durch Verhalten ändern. Verhalten ist sozusagen beobachtbar, man kann sich also die Eigenschaften der beteiligten Elemente im Verlauf der Zeit ansehen und die Veränderungen beobachten. Dies wird in der Literatur auch Zustandsänderung genannt. Es gibt mit der UML 2.0 unterschiedliche Sichten auf Verhalten. Dabei kann Verhalten direkt als Klasse definiert werden, aber es ist ebenso möglich, Verhalten innerhalb einer anderen Klasse zu definieren, die wiederum das Verhalten besitzt. Im Metamodell werden mehrere verschiedene Formen der Beschreibung des Verhaltens durch die Bereitstellung von Paketen repräsentiert, wie das Modell aus Abbildung 1.1: Verhaltensbeschreibung aufzeigt.

Dabei gibt es, wie man leicht aus der Abbildung 1.1: Verhaltensbeschreibung ersieht, vier verschiedene Verhaltensdiagramme:

• Aktivitätsdiagramm (activitydiagram)
• Interaktionsdiagramm (interactiondiagram)
• Zusandsautomaten (state machines)
• Anwendungsfalldiagramme (use case diagram)

Grundlegende Modelle

Es gibt gemäß der UML-2.0-Spezifikation zwei unterschiedliche Verhaltensspezifikationen. In Abbildung 1.2: Common Behaviours Domain Model wird das Common Behaviors Domain Model aus der Spezifikation erläutert.

Das grundsätzliche Auftreten von Verhalten wird BehaviorPerformance genannt. Jedes Verhalten wird letztendlich von einem Objekt in der Rolle des invoker angestoßen. Das Verhalten beschreibt die grundsätzlichen strukturellen Merkmale eines Objektes über den Verlauf der Zeit. Abgeleitet von BehaviorPerformance gibt es wiederum zwei verschiedene Arten von Verhalten:

• BehaviourExecution:
  Ins Deutsche übersetzt heißt dies Ausführungsverhalten. Es wird in diesem Zusammenhang das Objekt und die Änderung dieses Objektes zur Laufzeit betrachtet. Dieses Objekt, in vorheriger in der Rolle host, arbeitet das Verhalten ab, das von einem anderen Objekt oder dem gleichen Objekt angefordert wird, das das Verhalten angestoßen hat. Das anstoßende Objekt ist gemäß vorheriger Abbildung in der Rolle des invoker. Somit wird hierbei das Verhalten direkt von einem Objekt aufgerufen. Angestoßen werden also Zustandsänderungen eines Objektes durch den Aufruf einer Operation durch ein anderes Objekt oder aber durch ein Ereignis oder durch die Erzeugung eines Objektes. Es gibt dabei – wie Sie gesehen haben –, immer einen host, der das Verhalten selbst abarbeitet, und einen invoker, der das Verhalten und den Zustand ändert.
• BehaviorEmergence:
  Hierbei resultiert das Verhalten aus der Interaktion von einem oder mehreren Objekten. Der Blickwinkel gilt an dieser Stelle der Interaktion der verschiedenen beteiligten Objekte. Es betrifft das Verhalten, das im Zusammenspiel zwischen den einzelnen Classifiern ausgelöst wird.

Das Aufrufmodell

Die Frage ist nunmehr, wie man grundsätzlich bei einem zunächst statischen Modell Verhalten beschreibt. Wenn man sich das Metamodell der Spezifikation einmal genauer ansieht, kann man jedem Classifier Verhalten mitgeben. In der Spezifikation ist hier die Rede von BehavioralFeatures, was als Begriff deutlich besser greift als das deutsche Wort »Verhaltensmerkmal«. Im Wesentlichen gibt es an dieser Stelle zwei Möglichkeiten von Verhalten. Zum einen kann im einfachsten Fall eine Operation ein Verhalten in einem Objekt bewirken. Zum anderen kann ein Signal (Spezifikation: Reception) empfangen werden. Ein Signal wird meistens im Zuge der ereignisorientierten Programmierung verwendet, das ein Konzept von allen modernen objektorientierten Programmiersprachen ist. Die UML 2.0 beschreibt Verhalten grundsätzlich auf der Basis von auftretenden Ereignissen. Dabei kann das Auftreten eines Ereignisses Verhalten auslösen, aber dies muss natürlich nicht sein. Andererseits wird umgekehrt das Ausführen von Verhalten immer durch ein Ereignis bewirkt.

Aus dem Klassenmodell heraus ergibt sich sachlogisch, dass eine Verhaltensimplementierung durch eine Operation konkretisiert wird. Dadurch, dass durch die Operationen die Werte der Attribute eines Objektes zur Laufzeit verändert werden können, gibt man dem Objekt die Zustände mit, in die es gebracht werden kann. Diese Veränderungen der jeweiligen Zustände lassen sich mit dem Zustandsautomaten (state machine) genau beschreiben, die allerdings derzeit nicht Gegenstand der Prüfung Fundamental ist. Die Operationen selbst können ebenfalls Verhalten besitzen, da sie ja bekanntlich eigene Attribute enthalten können, die nur während der Abarbeitung existieren.

Dass ein Verhalten in der UML 2.0 grundsätzlich über ein Ereignis startet, sehen Sie in Invocation Domain Model in Abbildung 1.3: Invocation Domain Model. Es gibt auf jeden Fall immer ein Ereignis, das so genannte Startereignis, und natürlich gibt es zudem auch immer das Endereignis.

Wie Sie in vorheriger aus der Spezifikation der OMG erkennen, gibt es grundsätzlich mehrere Wege, über die Verhalten ausgelöst werden kann. Zum einen kann Verhalten durch einen direkten Aufruf, also dem CallBehaviorEvent, ausgelöst werden, oder aber andererseits durch einen TriggerEvent. Der CallBehaviorEvent startet das Verhalten direkt, während bei einem Trigger das Starten indirekt erfolgt. Ein Trigger kann sehr spontan auftreten, wenn zum Beispiel eine Eigenschaft einen bestimmten Wert überschreitet. Wenn ein Trigger-Ereignis eintritt, so wird es nach vorheriger Abbildung in einem Ereignispool (Spezifikation: Event Pool) abgelegt. Die genaue Behandlung, die Verarbeitung der Ereignisse, ist natürlich von der konkreten Klasse und deren Aufbau abhängig. Eine genauere Beschreibung würde man in diesem Falle mit dem Zustandsdiagramm notieren. Diese beiden Wege, Verhalten anzustoßen, werden in der UML-2.0-Spezifikation grundsätzlich unterschieden. Ein Start Event, beschrieben in Abbildung 1.3: Invocation Domain Modeldurch Start Occurence, vermerkt den Beginn einer Verhaltensausführung und löst das Verhalten eben beim Start aus, während die Beendigung durch das Termination Event ausgelöst wird, das in obiger Abbildung durch Termination Occurence beschrieben wird.

Tabelle 1.1: Tabelle der Events gibt die einzelnen Ausprägungen der TriggerEvents an. Hierbei werden alle Verhaltensaufrufe durch Signale beschrieben, da sie im Gegensatz zu den CallBehaviorEvents, die ebenfalls in Tabelle 1.1: Tabelle der Events geschrieben sind, nicht durch einen direkten Operationsaufruf angestoßen werden.

Event	Bedeutung
CallBehaviorEvent	Direkter Verhaltensaufruf durch beispielsweise eine Operation
Trigger Event	Übergang von einem Zustand in einen anderen aufgrund von Bedingungen. Bei den Trigger-Ereignissen werden die Ereignisse in einem Pool (EventPool) zugeordnet. Dieser Pool ist dem Classifier zugeordnet.
TimeEvent	Übergang von einem Zustand in einen anderen aufgrund von Erreichen eines Zeitpunktes
Receiving Event	Übergang von einem Zustand in einen anderen aufgrund des Empfangs einer Nachricht
Change Event	Übergang von einem Zustand in einen anderen aufgrund der Änderung eines bestimmten Wertes

Tabelle 1.1: Tabelle der Events

Die Ausführung und der vorherige Aufruf des Verhaltens sind in der UML 2.0 grundsätzlich sachlogisch getrennt. Abbildung 1.4: Domain Model Showing Request Kindsaus der Spezifikation soll dieses Konzept grundsätzlich erläutern.

Wie Abbildung 1.4: Domain Model Showing Request Kinds verdeutlicht, wird beim Aufruf irgendeines Verhaltens durch das Auftreten eines Ereignisses (Invocation Occurence) ein oder mehrere so genanntes Request-Objekt angelegt. Dieses Request-Objekt verursacht nunmehr ein Empfangsereignis (SendRequest) beim Empfänger (ReceivceOccurance) und löst damit das Verhalten aus. Dieses Verhalten wird im Empfänger (host) ausgelöst, wobei Metainformationen durch das Request- Objekt, wie beispielsweise den Sender, mitgegeben werden. Bei den jeweiligen Objekten, die jeweils den Sender (Invocation Event) und den Empfänger (Receiving Event) repräsentieren, kann es sich sowohl um ein und dasselbe Objekt als auch um diverse unterschiedliche Objekte handeln.

Kommunikationsmodell

Schaut man sich einmal in der UML 2.0 den Sender und den Empfänger an, so stellt man fest, dass die UML 2.0 beides logisch unterscheidet. Das Senden und das Empfangen sind jeweils Ereignisse, wie nachfolgende Abbildung verdeutlicht. Bei dem Sendeereignis handelt es sich um das InvocationEvent und bei dem Empfangsereignis handelt es sich um das ReceivingEvent. Als Ergebnis eines Sendeereignisses steht ein Request-Objekt zur Verfügung, das zum Empfänger übertragen wird. Wenn dieses Request-Objekt im Empfänger eintrifft, verursacht es dort wiederum ein Empfangsereignis, das wiederum ein Verhalten nach sich ziehen kann. Das Request-Objekt enthält Informationen und kann auch dem Sender wiederum Informationen vom Empfänger zurückgeben, somit ist es verantwortlich für die Kausalität zwischen Ursache und Wirkung und Vermittler zwischen Sender und Empfänger Abbildung 1.5: Communication Model ist das Kommunikationsmodell dargestellt.

Abbildung 1.6: Abhängigkeiten von CommonBehaviors packages beschreibt die Abhängigkeiten der Pakete der CommonBehaviors, also des Verhaltens. Das so genannte SimpleTime-Paket repräsentiert die Zeit und die Dauer.

Das Metamodell

Wie man im Metamodell (siehe Abbildung 1.7: CommonBehavior) erkennt, kann Verhalten direkt als Klasse definiert werden, wobei Behavior selbst direkt von Class erbt. Eine Verhaltensbeschreibung kann wie schon erwähnt auch in einer anderen Klasse definiert werden, diese besitzt dann dieses Verhalten und ist gemäß dem nachfolgenden Metamodell in der Rolle des so genannten ownedBehavior. Der andere im Metamodell benannte BehavioredClassifier nimmt die Rolle des context für das Verhalten ein. Das Ergebnis ist in diesem Falle, dass Behavior auf das Verhalten von BehavioredClassifier zugreifen kann. Beachtet man im Folgenden noch die Multiplizitäten, so bedeutet dies, dass ein BehavioredClassifier mehrere Behavior besitzen kann. Andererseits darf jedes Behavior wiederum nur 0..1 context enthalten. Bei Operationen verhält es sich, wie man ebenfalls dem Metamodell entnehmen kann, so, dass das Verhalten von der Operation implementiert wird, da das Verhalten (Behavior) in die Rolle der Methode fällt. Die Operation ist aus Sicht des Verhaltens (Behavior) seine Spezifikation.

Natürlich können dem Verhalten auch Parameter mitgegeben werden, wie im Metamodell Abbildung 1.8: Reception noch genauer beschrieben wird.

Bei Verhalten können grundsätzlich Eingabe- und Ausgabeparameter mitgegeben werden. Bei dem Aufruf werden die Argumente des Aufrufs dem Verhalten über die Eingabeparameter zur Verfügung gestellt. Des Weiteren, aber das werden Sie noch genauer in dem Kapitel Aktivitäten sehen, können Vor- und Nachbedingungen gestellt und zusätzliche Einschränkungen definiert werden.

Eine Klasse, die ein BehavioredClassifierdarstellt und zudem einen eigenen Kontrollfluss enthält, wird in der UML 2.0 als aktiv bezeichnet. Dabei ist der Signalempfang im Übrigen ausschließlich von aktives Objekt möglich, wie in der Abbildung des Metamodells aufgezeigt wird. Dabei ist ein aktives Objekt ein Objekt, das unabhängig von anderen Objekten ausgeführt wird. Dies wird über die Eigenschaft isActive definiert, wie Sie in Abbildung 1.8: Reception erkennen . Diese Eigenschaft kann dem Objekt als Parameter mitgegeben werden. Ist dieser Wert auf

true

gesetzt, so kann das Objekt, das Verhalten aufweist, einen eigenen Kontrollfluss haben; wenn der Wert auf

false

gesetzt ist, darf das Objekt keinen eigenen Kontrollfluss besitzen. Die Frage ist natürlich die, was das genau zu bedeuten hat. Die Antwort ist: Ein so genanntes aktives Objekt, also ein Objekt, in dem die Eigenschaft isActive auf true gesetzt ist, kann und darf unabhängig von einem anderen Objekt auf ein Ereignis reagieren.

Schließlich gibt es noch zusätzlich ein Attribut namens isReentrant, das Verhalten ebenso als Parameter mitgegeben werden kann. Ist es auf

true

gesetzt, kann das Verhalten zur gleichen Zeit in mehrfacher Ausprägung aufgerufen werden. Ist es auf

false

gesetzt, muss ein vorheriger Verhaltensaufruf beendet werden, bevor ein neuer Verhaltensaufruf erfolgen kann.

Im Gegensatz dazu bedeutet es, dass ein Objekt, das kein aktives Objekt ist, ausgeführt wird, indem es von anderen Objekten aufgerufen wird. In diesem Falle kann man den Objekten Schlüsselwörter mitgeben, die besagen, wie man gleichzeitige Aufrufe behandelt:

Behandlung	Beschreibung
conncurrent	Alle Aufrufe werden unabhängig voneinander und gleichzeitig ausgeführt.
sequential	Alle Instanzen regeln die Koordination gleichzeitiger Aufrufe selbst. Es können also Konflikte auftreten.
guarded	Immer nur ein Verhalten wird zu einem bestimmten Zeitpunkt aufgerufen. Solange dieses Verhalten abgearbeitet wird, sind alle anderen Verhalten geblockt. Das Auftreten von Deadlocks liegt im Verantwortungsbereich des Administrators oder des Entwicklers.