4 2 Aktivitätsdiagramm

1954.2 Aktivitätsdiagramm


4.2.1 Einführung

Der Schwerpunkt von Aktivitätsdiagrammen liegt auf prozeduralen Verar-beitungsaspekten. Ein Aktivitätsdiagramm spezifiziert den Kontroll- undDatenfluss zwischen verschiedenen Arbeitsschritten, den Aktionen, die zurRealisierung einer Aktivität notwendig sind.

In UML1 stellen Aktivitätsdiagramme eine spezielle Form von Zu-standsdiagrammen dar, deren Notation jedoch einen ablauforientiertenCharakter aufweist, wodurch die Ausdrucksmächtigkeit eingeschränkt istund der Einsatz nicht immer klar erscheint.

Dieser Kritik Rechnung tragend, wurden Aktivitätsdiagramme inUML2 auf eine völlig neue konzeptionelle Basis gestellt. Aktivitätsdia-gramme basieren nun nicht mehr auf Konzepten des Zustandsdiagramms,sondern verwenden ablauforientierte Sprachkonzepte, die ihre Wurzeln inaktuellen Sprachen zur Definition Web-Service-basierter Geschäftspro-zesse [BPEL03], aber auch in altbewährten Konzepten zur Beschreibungnebenläufiger, kommunizierender Prozesse haben, wie dem Tokenkonzeptaus Petrinetzen [Petr62]. Im Hinblick auf die Notation wurde jedoch dar-auf geachtet, soweit möglich an bestehenden Notationselementen festzu-halten, wenngleich die Bedeutung zum Teil neu definiert wurde.

Ein besonderes Merkmal von Aktivitätsdiagrammen liegt darin, dassneben der Modellierung objektorientierter Systeme inbesondere auch dieModellierung nicht-objektorientierter Systeme unterstützt wird. Aktivitä-ten können unabhängig von Objekten definiert werden, wodurch beispiels-weise auch Funktionsbibliotheken oder Geschäftsprozesse modelliert wer-den können.

Um diesen breiten Einsatzbereich abzudecken, stellen Aktivitätsdia-gramme zum Teil alternative Sprachkonzepte und Notationselemente zurVerfügung, die in dem einen oder anderen Anwendungsbereich besondersnützlich sind, jedoch auch miteinander kombiniert werden können. Bei-spielsweise ist zur Modellierung einer Fallunterscheidung einEntscheidungsknoten, der eine ablaufdiagramm-ähnliche Notationaufweist, eher für Geschäftsprozessmodellierer zweckmäßig, während einKonditionalknoten, für den eine struktogramm-ähnliche Notation verwen-det werden kann, eher den »Gewohnheiten« eines Softwareentwicklersentgegenkommt.

Prinzipiell ist der UML-Standard offen im Hinblick auf die, für die Re-präsentation von Aktivitäten, verwendete Notation und erlaubt neben denvorgeschlagenen ablauforientierten Notationselementen der Aktivitätsdia-gramme auch beliebige andere Notationsformen, wie z.B. Struktogrammeoder einfach nur Pseudocode.

Fokus auf prozeduralerVerarbeitung in Form vonKontroll- und Datenfluss

zwischen Aktionen

In UML1 Vermischung vonKonzepten aus Zustandsdia-

grammen und ablauf-orientierter Notation

Neue konzeptuelle Basis beigleichzeitigem Festhalten an

ablauforientierter Notation

Modellierung objektorien-tierter und nicht-

objektorien-tierter Systemegleicher-massen unterstützt

Sprachkonzepte und Notationsvarianten decken ein breites Anwendungs-gebiet ab

Neben vorgeschlagener grafischer Notation beliebige andere Formen – z.B. Pseudo-code erlaubt

196

Im Hinblick auf die Verwendung von Aktivitätsdiagrammen insbeson-dere für den Bereich der Geschäftsprozessmodellierung haben sich nebenablauforientierten Notationselementen auch eine Reihe von wiederkehren-den Kontroll- und Datenflusskonstrukten - sogenannte »Workflow Pat-terns« herausgebildet, deren Verwendung sich besonders bei komplexenAbläufen als sehr nützlich erwiesen hat. Für eine Übersicht derartiger Mu-ster und deren Modellierung auf Basis der Konzepte von UML2-Aktivi-tätsdiagrammen sei auf Wohed et al. verwiesen [Wohe04], ein Leitfadenzur Geschäftsprozessmodellierung auf Basis von UML2 wird in Oeste-reich et al. gegeben [Oest03].

4.2.2 Eigenschaften einer Aktivität

Ein Aktivitätsdiagramm erlaubt die Spezifikation von benutzerdefiniertembenanntem Verhalten in Form einer Aktivität. Eine Aktivität kann auf einerfein-granularen Ebene beispielsweise die Methode einer Operation inForm von einzelnen Anweisungen definieren, oder aber auf einer grob-gra-nularen Ebene beispielsweise einen Geschäftsprozess oder den Ablauf ei-nes Anwendungsfalls spezifizieren.

Eine Aktivität in UML2 unterscheidet sich damit grundlegend vondem in UML1 verwendeten Aktivitätsbegriff. In UML1 ist eine Aktivitätatomarer Bestandteil eines Aktivitätsdiagramms, während in UML2 eineAktivität die gesamte Verhaltensbeschreibung in einem Aktivitätsdia-gramm umfassen kann. Atomare Bestandteile eines Aktivitätsdiagrammssind in UML2 Aktionen. Vordefinierte Aktionen erlauben es, Operationenauf Objekte auszuführen oder anderes Verhalten aufzurufen, wodurch dieWiederverwendung anderer Aktivitäten und Verhaltensbeschreibungen un-terstützt wird (siehe Kapitel 4.2.13).

Aktionen leisten damit »die eigentliche Arbeit« für eine Aktivität,während entsprechende Kontroll- und Datenflusskonzepte eine Menge po-tentieller »Abläufe« einer Aktivität zur Laufzeit festlegen, d.h. wann eineAktion ausgeführt werden kann und welche Daten dazu erforderlich sind(vgl. dazu den Begriff des »Trace« in Kapitel 4.4.3, »Interaktion als Ab-folge von Ereignisspezifikationen«, S. 269). Von diesen potentiellen Ab-läufen kann zur Laufzeit entweder ein bestimmter auftreten oder aber eswerden aufgrund von Nebenläufigkeit oder einem Mehrfachaufruf der Ak-tivität mehrere Abläufe ausgeführt.

Im Sinne des objektorientierten Prinzips der Einheit von Struktur undVerhalten kann eine Aktivität einem Classifier zugeordnet werden und da-mit auf die Werte des Classifier-Objekts zugreifen. Die Aktivität fungiertdabei entweder als Methode des Classifiers oder ist diesem direkt zugeord-net und spezifiziert damit das Verhalten des Classifiers selbst.

»Workflow Patterns« als Basis komplexer Geschäfts-prozesse

Eine Aktivität spezifiziert benutzerdefiniertes Verhalten auf unterschied-lichen Granularitätsebenen

Eine Aktivität in UML1 entspricht einer atomaren Aktion in UML2

Eine Aktivität in UML2 umfasst Aktionen, Kontroll- und Datenflüsse

Aktionen leisten die Arbeit, Kontroll- und Datenflüsse legen potentielle »Abläufe« fest

Aktivitätszuordnung zu Classifier indirekt über eine Methode oder direkt


Fungiert die Aktivität als Methode des Classifiers, so wird sie ausge-führt, sobald die entsprechende Operation aufgerufen wird, die durch dieMethode und damit durch die Aktivität realisiert wird. Ist die Aktivitätdem Classifier direkt zugeordnet, beginnt die Aktivitätsausführung, sobaldder Classifier instanziert wird. In diesem Fall wird das Classifier-Objektam Ende einer Aktivitätsausführung gelöscht. Wird umgekehrt, vor Endeder Aktivitätsausführung, das Classifier-Objekt gelöscht, so wird auch dieAusführung der Aktivität beendet.

Um nicht nur das objektorientierte Paradigma zu unterstützen, kanneine Aktivität auch »autonom«, d.h. ohne Zuordnung zu einem Classifier,definiert werden. Für den Aufruf einer autonomen Aktivität muss eine spe-zielle vordefinierte Aktion CallBehaviorAction verwendet werden (sieheKapitel 4.2.13).

Eine Aktivität wird wie eine Aktion in Form eines abgerundetenRechtecks dargestellt, wobei deren Name in der linken oberen Ecke ange-geben wird. Alternativ dazu kann statt des abgerundeten Rechtecks, die beiallen UML-Diagrammarten verwendbare Rahmennotation verwendet wer-den, wobei das kleine Pentagon Diagrammart (ad) und Name der Aktivitätanzeigt (siehe Kapitel 2.4.5, »Offene Grenzen zwischen verschiedenenDiagrammarten«, S. 43).

Eine Aktivität kann, wie zum Beispiel bei Operationsaufrufen nütz-lich, parametrisiert werden. Formale Parameter werden durch Rechteckedargestellt, die die Ränder der Aktivität überlappen, wobei, zur besserenLesbarkeit, Eingabeparameter am linken oder oberen Rand und Ausgabe-parameter am rechten oder unteren Rand, dargestellt werden sollten (sieheKapitel 4.2.8, Arten von Objektknoten). Diese Konvention ermöglicht einintuitives Lesen des Diagramms von links oben nach rechts unten. Auchdie Angabe von Vor- und Nachbedingungen ist möglich, die zu Beginn derAusführung einer Aktivität bzw. bei deren Beendigung gelten müssen. DieEinschränkungen werden dabei jeweils neben den Schlüsselwörtern«precondition» und «postcondition» vermerkt. Schließlich stellt eine Akti-vität einen Namensraum dar, der die Sichtbarkeit von Variablen auf dieAktivität beschränkt.

4.2.3 Bestandteile einer Aktivität

Der Inhalt einer Aktivität ist – analog zu Petrinetzen – ein gerichteterGraph bestehend aus Aktivitätsknoten und Aktivitätskanten, in weitererFolge kurz als Knoten und Kanten bezeichnet. Dabei repräsentieren Kno-ten die einzelnen Aktionen einer Aktivität, sowie Kontrollkonstrukte undObjektspeicher, während Kanten die Abhängigkeiten von Vorgängerkno-ten ausdrücken und zwar in Form der Weitergabe von Kontrolle bzw. von

Aktivitätsausführung durch Operationsaufruf oder Classifier-Instanzierung

Löschen des Classifier-Objekts

»Autonome« Aktivität ohne Zuordnung zu einem Classifier

Aktivität kann Parameter (activity parameter nodes), sowie Vor- und Nachbeding-ungen aufweisen und defi-niert einen Namensraum

Aktivitäts- «precondition»«postcondition»name

Eingabe- Ausgabe-parameter parameter

Aktivität ist ein gerichteter Graph bestehend aus Knoten und Kanten

Aktivitäts- «precondition»«precondition»

... ...name

Aktivitäts-knoten

Aktivitäts-kante

198

Daten. Der Inhalt einer Aktivität kann auch ohne den Rahmen der umge-benden Aktivität dargestellt werden

Knoten

Prinzipiell werden drei Knotenarten unterschieden – Aktionsknoten,Kontrollknoten und Objektknoten.

Aktionsknoten repräsentieren vordefinierte UML-Aktionen, die Einga-ben empfangen und diese zu Ausgaben für andere Knoten verarbeiten kön-nen, oder andere Aktivitäten aufrufen. Aktionsknoten werden wie Aktivi-täten in Form eines abgerundeten Rechtecks dargestellt, wobei der Nameder Aktion als einziger Bestandteil, zentral innerhalb des abgerundetenRechtecks plaziert wird. Aktionen werden im Detail in Kapitel 4.2.13 er-läutert.

Kontrollknoten ermöglichen die Festlegung von Start und Ende einergesamten Aktivität oder eines bestimmten Ablaufs einer Aktivität, die Spe-zifikation von alternativen Abläufen durch Verzweigungen bzw. Vereini-gungen und die Modellierung von nebenläufigen Abläufen durch Paralleli-sierung bzw. Synchronisation. Tabelle 4–2 gibt einen Überblick über dieverschiedenen Arten von Kontrollknoten und deren Notation. Für eine de-taillierte Erläuterung sei auf die Kapitel 4.2.5 bis Kapitel 4.2.7 verwiesen.

Objektknoten stellen das Bindeglied zwischen der Verhaltensmodellierungin Form von Aktivitätsdiagrammen und der Strukturmodellierung, insbe-sondere in Gestalt des Klassendiagramms, dar. Objektknoten können Da-ten und Objekte aufnehmen. Sie dienen nicht nur als formale Ein- und Aus-gabeparameter für eine bestimmte Aktivität oder Aktion, sondern könnenauch eine zentrale Pufferfunktion für Aktionen übernehmen. Trotz der Be-zeichnung Objektknoten können darin nicht nur Instanzen von Classifierngespeichert werden, sondern ganz allgemein jegliche Art von Daten.

Ein Objektknoten wird prinzipiell als Rechteck dargestellt und kannim Falle einer Verwendung als Parameter direkt am Rahmen der Aktivität(überlappend) bzw. der Aktion (nicht überlappend in Form sogenannterPins) »angeheftet« werden. Für Details zu Objektknoten sieheKapitel 4.2.8.

Start und Ende von Abläufen

Alternative Abläufe

Nebenläufige Abläufe

Initialknoten Entscheidungs-knoten

Parallelisierungs-knoten

Aktivitätsend-knoten

Vereinigungs-knoten

Synchronisierungs-knoten

Ablaufend-knoten

Aktionsknoten repräsentie-ren vordefinierte Aktionen

Aktions-name

Kontrollknoten steuern Aktivitätsabläufe

Tab. 4–2Arten von Kontrollknoten

Objektknoten dienen als formale Ein- und Ausgabe-parameter sowie als zentrale Puffer

Aktion3 Aktion4

Ausgabe-Eingabe-

Aktivität_A

parameter parameter


Kanten

Allen Arten von Knoten einer Aktivität ist gemeinsam, dass sie durchKanten miteinander verknüpft werden können, die zusammen mit denKontrollknoten die zeitlich logische Reihenfolge der Aktionen und damitdie möglichen Abläufe der gesamten Aktivität festlegen. Kanten ersetzendabei das in UML1 zur Verknüpfung von Knoten verwendete Konzept derTransitionen, das ja eigentlich aus Zustandsdiagrammen stammt.

Eine Kante wird mit einer offenen Pfeilspitze dargestellt und kann ei-nen Namen aufweisen. Es gibt zwei verschiedene Arten von Kanten, diesich nur aufgrund ihrer Verwendung, nicht jedoch in ihrer Notation unter-scheiden. Je nachdem ob die Kante mit einem Objektknoten in Beziehungsteht oder nicht, handelt es sich um eine Objektflusskante oder eineKontrollflusskante.

Eine Kontrollflusskante erlaubt die Modellierung des Kontrollflussesund drückt so eine Abhängigkeit zwischen Vorgänger- und Nachfolgerkno-ten aus, d.h. der Nachfolgerknoten kann erst dann verarbeitet werden,wenn dessen direkte Vorgängerknoten die Kontrolle weitergeben. Kon-trollflusskanten können Aktionsknoten direkt oder über entsprechendeKontrollknoten miteinander verbinden, Verknüpfungen zu Objektknotensind nicht erlaubt.

Eine Objektflusskante repräsentiert nicht nur, wie der Name sugge-riert, den Objektfluss sondern ermöglicht auch den Transport reiner Daten.Zusätzlich zu dieser Transportfunktion für Daten bzw. Objekte wird aucheine Abhängigkeit zwischen Vorgänger- und Nachfolgerknoten ausge-drückt, da der Nachfolgerknoten erst dann verarbeitet werden kann, wennder Vorgängerknoten die geforderten Daten bzw. Objekte weitergegebenhat. Eine Objektflusskante kann Objektknoten direkt oder über entspre-chende Kontrollknoten miteinander verbinden. Eine direkte Verknüpfungvon zwei Aktionsknoten über eine Objektflusskante ist jedoch nicht er-laubt.

Sowohl für Kontroll- als auch für Objektflusskanten könnenÜberwachungsbedinungungen in Form boolscher Ausdrücke spezifiziertwerden. Eine Überwachungsbedingung legt fest, in welchem Fall die Kon-trolle bzw. entsprechende Daten und Objekte über eine bestimmte Kantean den entsprechenden Nachfolgerknoten weitergereicht werden können.

Schließlich existieren speziell für Objektflusskanten und Objektkno-ten eine Reihe von Mechanismen, die zusätzlich zum Kontrollfluss eineexplizite Steuerung des Objektflusses ermöglichen. Diese umfassen bei-spielsweise die Festlegung der maximalen Kapazität einer Objektflus-skante oder eines Objektknotens, sowie die Selektion und Transformationvon Daten. Für Details dazu, siehe Kapitel 4.2.9.

Um bei komplexen Aktivitätsdiagrammen die Übersichtlichkeit zu ge-währleisten, können Kreuzungen von Kontroll- und Datenflusskanten no-

Kanten verbinden Knoten und legen mögliche Abläufe einer Aktivität fest

Kontroll- vs.

Aktion3

...

Aktion1

Aktion2 Objekt-fluss

Kontroll-fluss

Kontrollflusskanten drücken eine reine Kontrollabhän-gigkeit zwischen Vorgänger- und Nachfolgerknoten aus

Objektflusskanten trans-portieren zusätzlich Daten und drücken dadurch auch eine Datenabhängigkeit zwischen Vorgänger- und Nachfolgerknoten aus

Überwachungsbedingung (guard) bestimmt, ob Kontroll- und Datenfluss weiterläuft oder nicht

Mechanismen zu Steuerung des ObjektflussesFortsetzungsmarken (connectors)

A

A

Aktion1

200

tationstechnisch dadurch vermieden werden, dass sie unterbrochen und ananderer Stelle fortgeführt werden. UML bietet dazu die Möglichkeit, ähn-lich wie bei Sequenzdiagrammen (siehe »Fortsetzungsmarke«, S. 297), so-genannte Fortsetzungsmarken zu definieren. Fortsetzungsmarken müssenimmer paarweise auftreten, einmal mit einer eingehenden Kante und einweiteres Mal mit einer ausgehenden Kante, sowie einen eindeutigen Na-men aufweisen. Eine Fortsetzungsmarke wird als kleiner Kreis angeschrie-ben, in dem sich der Name der Fortsetzungsmarke befindet.

Abbildung 4–10 zeigt zwei Aktionen einer AktivitätTerminkoordination die versuchen, einen passenden Terminvorschlag füreine Reihe von Teilnehmern zu finden.

Solange ein bestimmter Termin nicht bei allen Teilnehmern auf Zustim-mung stößt, werden neue Termine vorgeschlagen Erst wenn ein für alleTeilnehmer passender Termin gefunden ist, werden die Teilnehmer ent-sprechend informiert und die Aktivität wird abgeschlossen.

4.2.4 Token zur Koordination von Aktivitätsabläufen

Ein zentrales Konzept bei Aktivitätsdiagrammen stellen sogenannte Tokendar. Es handelt sich dabei jedoch weder um ein eigenes Sprachkonzept,noch um ein eigenes Notationselement, sondern vielmehr um eine Art»virtueller Koordinationsmechanismus«, mit dem Abläufe einer Aktivitätbeschrieben werden können, um so z.B. eine exakte Vorgabe für die Imple-mentierung der Aktivität zu liefern.

Ein Token fließt entlang der Kanten von Vorgängerknoten zu Nachfol-gerknoten und beschreibt somit einen möglichen Ablauf einer Aktivität zurLaufzeit. Durch die Spezifikation von Nebenläufigkeit sowie durch mehr-fachen Aufruf einer Aktivität (siehe weiter unten) können sich auch meh-rere Token zur gleichen Zeit in einem Aktivitätsdiagramm befinden, wobeijedes Token einem bestimmten Ablauf angehört.

Token werden in Kontroll- und Datentoken unterschieden. Währendein Kontrolltoken eine reine Ausführungserlaubnis für den Nachfolgerkno-ten darstellt, transportiert ein Datentoken einen Datenwert oder eine Refe-renz auf ein Objekt (deswegen oftmals auch Objekttoken genannt). Fallsdiese Unterscheidung für das Verständnis nicht notwendig ist, wird in wei-terer Folge nur von Token gesprochen oder aber in Kontroll- und Datento-

Terminvorschlagfinden

[else]

[Termingefunden] Teilnehmer

informieren

Terminkoordination

Abb. 4–10Beispiel einer Aktivität zur Terminkoordination

Token als »virtueller Koordi-nationsmechanismus« mit dem Aktivitätsabläufe beschrieben werden können

Token fliessen entlang der Kanten von Vorgänger- zu Nachfolgerknoten

Aktion1

Aktion2

Unterscheidung in Kontroll- und Datentoken


ken unterschieden. Die Ausführung eines Nachfolgerknotens kann auchdurch die Verfügbarkeit entsprechender Datentoken alleine veranlaßt wer-den, weshalb Datentoken ebenfalls den Kontrollfluss steuern. Damit stelltein Kontrolltoken eigentlich eine »degenerierte« Form eines Datentokensdar, der nur den Kontrollfluss steuert, jedoch keine Daten transportiert,während ein Datentoken beides leisten kann [Bock03].

Im Allgemeinen müssen an allen eingehenden Kanten eines Knotensdie erforderlichen Kontroll- bzw. Datentoken »angeboten« werden, d.h.zur Verfügung stehen, um dessen Ausführung zu ermöglichen. Sobald alleerforderlichen Token vorhanden sind, fließen diese in den Knoten ein unddieser kann ausgeführt werden. Die Token und damit auch die Kontrolleverbleiben solange bei diesem Knoten, solange dessen Ausführung dauertbzw. bis der nächste Knoten die Token akzeptiert. Eine Überwachungsbe-dingung kann beispielsweise die Weitergabe der Token verhindern, wo-durch sich beim Vorgängerknoten mehrere Token ansammeln können. To-ken können jedoch nur in Aktions- und Objektknoten verweilen,Kontrollknoten geben die Token im Allgemeinen sofort weiter, Ausnah-men von dieser Regel werden bei den entsprechenden Konzepten behan-delt.

Während die Ausführung eines Aktionsknotens eine endliche Zeit-dauer in Anspruch nimmt, wird die Ausführung von Kontrollknoten, sowiedie Weitergabe eines Tokens als zeitlos angesehen, da diese zur Laufzeitnicht tatsächlich erfolgen muss.

Eine Aktivität kann beliebig oft aufgerufen werden. Es wird dabeistandardmäßig für jeden Aufruf eine neue Ausführung der Aktivität gestar-tet, sodass sich die einzelnen Abläufe bzw. Tokenflüsse gegenseitig nichtbeeinflussen. Dies ist vergleichbar mit Betriebsystemprozessen, wobei je-der Prozess einen eigenen Adressraum verwendet. Als Alternative dazukann durch Angabe des Schlüsselworts «singleExecution» im oberen Teildes Aktivitätsrechtecks festgelegt werden, dass im Falle eines Mehrfach-aufrufs für alle Abläufe ein »gemeinsamer Adressraum« verwendet wird.Da dadurch gleichzeitig mehrere Abläufe, inklusive der zugehörigen To-ken gemeinsam verwaltet werden, können sich die verschiedenen Abläufegegenseitig beeinflussen.

Abschließend sei betont, dass UML2 zwar auf dem Tokenkonzept vonPetrinetzen aufbaut, sich aber im Detail von diesem unterscheidet. Für ei-nen Vergleich zwischen Aktivitätsdiagrammen und Petrinetzen sei auf[Stör04] verwiesen.

4.2.5 Start und Ende von Aktivitäten und Abläufen

Start und Ende von Abläufen werden einerseits durch Initialknoten und an-dererseits durch Aktivitätsend- und Ablaufendknoten festgelegt.

Anbieten und Aufbewahren von Token sowie Auslösen der Verarbeitung durch Token

Ausführung eines Aktions-knotens benötigt Zeit, Kon-trollknotenausführung, so-wie Tokenweitergabe ist zeitlos

Optionen bei Mehrfachaufruf einer Aktivität – getrennte vs. gemeinsame Tokenverwal-

Unterschiede zu Petrinetzen

202

Initialknoten

Ein Initialknoten ist eine spezielle Art eines Kontrollknotens der dazudient, den Beginn eines Ablaufs einer Aktivität zu kennzeichnen. Ein Initi-alknoten wird durch einen kleinen gefüllten Kreis dargestellt, ohne einge-hende und mit beliebig vielen ausgehenden Kanten.

Sobald eine Aktivität aufgerufen wird, werden an allen ausgehendenKanten eines Initialknotens Kontrolltoken zur Verfügung gestellt und so-mit der Ablauf der Aktivität gestartet.

Da Überwachungsbedingungen die Weitergabe der Kontrolltoken andie nachfolgenden Knoten beschränken können und gleichzeitig der Initi-talknoten keinen Vorgängerknoten hat, in dem nicht akzeptierte Token ge-sammelt werden könnten, ist es im Gegensatz zu anderen Kontrollknotenbei Initialknoten erlaubt, Kontrolltoken solange aufzubewahren bis dienachfolgenden Knoten die Token akzeptieren.

IWährend in UML1 der Start einer Aktivität eindeutig alsPseudozustand gekennzeichnet ist, kann eine Aktivität in UML2 auchmehrere Initialknoten besitzen, wodurch nebenläufige Abläufe gestartetwerden können. Diese Möglichkeit ist z.B. für die Modellierung von Ge-schäftsprozessen von großem Nutzen. Im Falle eines Aufrufs der Aktivitätwerden die ausgehenden Kanten aller Initialknoten gleichzeitig mit ent-sprechenden Kontrolltoken versorgt.

Umgekehrt muss eine Aktivität nicht zwangsläufig einen Initialknotenbesitzen. Auch über Parameter einer Aktivität (siehe Kapitel 4.2.8) könnenToken zur Verfügung stehen und somit Abläufe einer Aktivität gestartetwerden. Darüber hinaus werden jene Knoten, die keine eingehenden Kan-ten (und damit auch keinen Initialknoten) aufweisen, bei Aufruf der Akti-vität automatisch mit Kontrolltoken belegt. Im Unterschied zur Verwen-dung von expliziten Initialknoten ist dabei aber keine Angabe vonÜberwachungsbedingungen möglich.

Aktivitätsendknoten

Ein Aktivitätsendknoten ist ein Kontrollknoten, der die Beendigung derAusführung aller Abläufe einer Aktivität erzwingt. Ein Aktivitätsendkno-ten hat keine ausgehenden Kanten, kann aber mehrere eingehende Kantenaufweisen und wird durch einen kleinen Kreis, mit einem darin enthaltenengefüllten Kreis dargestellt. Dies wird auch häufig als »bull’s eye« bezeich-net.

Meist wird eine Aktivität nur einen Aktivitätsendknoten besitzen, siekann aber auch mehrere aufweisen. In diesem Fall beendet jener Ablauf,der als erstes einen Aktivitätsendknoten erreicht, die gesamte Aktivität.

Das Beenden einer Aktivität bedeutet, dass zum Einen gerade aktiveAktionen gestoppt und aufgrund ihrer Atomarität allfällige Effekte rück-

Initialknoten (initial node) kennzeichnet den Beginn eines Aktivitätsablaufs

Versorgt ausgehende Kanten mit Kontrolltoken

Aufbewahrung von Token erlaubt, da Überwachungs-bedingungen die Weiter-

Mehrere Initialknoten pro Aktivität erlaubt – ermöglicht

Auch Aktivitäten ohne Inititalknoten erlaubt

Aktivitätsendknoten (activity final node) beendet alle Abläufe einer Aktivität

Mehrere Aktivitätsend-knoten pro Aktivität erlaubt

Keine Ausführung weiterer Aktionen


gängig gemacht werden und dass zum Anderen keine weiteren Aktioneneventuell noch aktiver Abläufe der Aktivität ausgeführt werden. Wurdedurch Aktionen anderes Verhalten eingebunden, so wird im Falle einessynchronen Aufrufs das eingebundene Verhalten ebenfalls beendet, wäh-rend im asynchronen Fall das eingebundene Verhalten von der Beendigungder Aktivität nicht betroffen ist.

Durch die Beendigung der Aktivität werden alle Kontrolltoken ge-löscht. Datentoken, die bereits an den Ausgabeparametern der Aktivitätanliegen, werden an den Aufrufer der Aktivität zurückgegeben, andere Da-tentoken werden gelöscht. Ausgabeparameter an denen zur Zeit der Been-digung der Aktivität noch kein Datentoken anliegt, werden mit einem so-genannten »Null-Token« – einer Art Nullwert – belegt.

Repräsentiert die Aktivität den Lebenszyklus eines Objekts, so wirddurch Erreichen des Aktivitätsendknotens das Objekt selbst ebenfalls ge-löscht.

Ablaufendknoten

Oftmals ist es nicht wünschenswert, alle Abläufe einer Aktivität zu been-den, sondern nur einen bestimmten Ablauf. Dies ist nicht nur im Falle ne-benläufiger Abläufe von Nutzen, sondern auch dann, wenn eine Aktivitätals «singleExecution» spezifiziert ist, da in diesem Fall einAktivitätsendknoten alle Abläufe beenden würde und somit auchdiejenigen, die durch mehrmalige Aufrufe der Aktivität initiiert wurden.Mit einem Ablaufendknoten kann spezifiziert werden, dass nur eineinziger dieser Abläufe beendet wird. Ein Ablaufendknoten wird durch ei-nen kleinen Kreis mit einem darin enthaltenen Kreuz dargestellt und weistausschließlich eingehende Kanten auf.

Abbildung 4–11 zeigt eine Aktivität zum Erstellen und Versenden vonEinladungen zu einem Termin. Dazu werden die Einladungen einzeln ge-druckt und eine nach der anderen adressiert, wobei parallel zum Adressie-ren in einem eigenen Ablauf die nächste Einladung gedruckt wird.

Sind alle Einladungen gedruckt, wird der Ablauf zum Drucken der näch-sten Einladung durch einen Ablaufendknoten beendet, die Adressierungkann jedoch weiterlaufen. Ist die Adressierung einer Einladung abge-schlossen, so wird der entsprechende Ablauf beendet, außer es handelt sichum die lezte Einladung. Sobald diese adressiert ist, können die Einladun-

Kontrolltoken gelöscht, Datentoken an Ausgabeparametern der Aktivität nicht

Ende des Lebenszyklus’ eines Objekts

Ablaufendknoten (flow final node) beendet einen Ablauf einer Aktivität

[else]

Einladungdrucken

Einladungadressieren

Einladungenabschicken

[else]

[alle Einladungenadressiert]

[alleEinladungengedruckt]

Abb. 4–11Beispiel mit Initialknoten, Aktivitätsend- und Ablaufendknoten

204

gen abgeschickt werden und anschließend wird die gesamte Aktivitätdurch einen Aktivitätsendknoten beendet.

4.2.6 Alternative Abläufe

Zur Modellierung von alternativen Abläufen dienen Entscheidungsknotenund Vereinigungsknoten.

Entscheidungsknoten

Ein Entscheidungsknoten ermöglicht es, einen Ablauf in beliebig viele al-ternative Zweige aufzuspalten, und kann damit als eine Art »Weiche« fürdie Token im Ablauf verstanden werden. Ein Token das den Entschei-dungsknoten über die eingehende Kante erreicht, wird nur an genau eineausgehende Kante weitergegeben.

Die Entscheidung, an welcher ausgehenden Kante ein Token weiter-fließt, wird mit Hilfe von Überwachungsbedingungen spezifiziert, die deneinzelnen Kanten zugeordnet sind. In welcher Reihenfolge die Überwa-chungsbedingungen geprüft werden, ist nicht festgelegt.

Es ist daher erforderlich, dass alle ausgehenden Kanten wechselseitigausschließende Überwachungsbedingungen aufweisen. Eine ausgehendeKante kann mit der vordefinierten Bedingung [else] versehen werden, diedann zutrifft, wenn keine der anderen Bedingungen gültig ist.

Entscheidungsknoten können auch zur Modellierung von Schleifenverwendet werden, indem durch den Entscheidungsknoten das (neuerli-che) Ausführen von Aktionen bestimmt wird. Eine weitere Möglichkeitzur Schleifenmodellierung stellen spezielle Schleifenknoten dar (sieheSchleifenknoten, S. 226).

Ein Entscheidungsknoten wird durch eine Raute dargestellt und weisteine eingehende Kante und mehrere ausgehende Kanten auf. Alle Kanteneines Entscheidungsknotens müssen dabei entweder ausschliesslich Ob-jektflüsse oder ausschliesslich Kontrollflüsse repräsentieren. Die Überwa-chungsbedingungen werden den jeweiligen Kanten in eckigen Klammernzugeordnet.

Überwachungsbedingungen können die Auswahl des Zweiges auf Ba-sis des eingegangenen Tokens treffen. Ist es notwendig, komplexere Aus-wahlentscheidungen zu spezifizieren und z.B. vor Auswahl des Zweigesnoch eine Berechnung auf Basis des eingegangenen Tokens durchzufüh-ren, kann ein sogenanntes Entscheidungsverhalten spezifiziert werden.Durch die Möglichkeit der zentralen Spezifikation beim Entscheidungs-knoten selbst, können darüber hinaus auch redundante Evaluierungen ein-facher Bedingungen vermieden werden, die andernfalls in Form von Über-

Ein Entscheidungsknoten (decision node) spezifiziert alternative Zweige und repräsentiert eine »Weiche«

Ein Entscheidungsknoten (decision node) definiert alternative Zweige und repräsentiert eine »Weiche« für den Tokenfluss

Überwachungsbedingun-gen wählen den Zweig aus

Überwachungsbedin-gungen müssen wechsel-seitig ausschliessend sein, [else] ist vordefiniertEntscheidungsknoten zur Modellierung von

[B] [¬B]

Aktion1

Aktion2 Aktion3

Entscheidungsknoten

Entscheidungsverhalten (decision input behavior) ermöglicht detailliertere Spezifikation der Auswahl-entscheidung an zentraler Stelle


wachungsbedingungen an den ausgehenden Kanten modelliert werdenmüssten. Das Entscheidungsverhalten darf jedoch keine Nebeneffekte, d.h.Änderungen an Daten oder Objekten, aufweisen.

Entscheidungsverhalten wird immer dann ausgeführt, wenn der Ent-scheidungsknoten ein Token erhält, wobei ein eventuelles Datentoken denEingabeparameter für das Entscheidungsverhalten darstellt, während imFalle eines Kontrolltokens das Entscheidungsverhalten ohne Parameteraufgerufen wird. Das Ergebnis des Entscheidungsverhaltens steht dann anden ausgehenden Kanten für die Evaluierung eventuell vorhandener Über-wachungsbedingungen zur Verfügung.

Entscheidungsverhalten wird in einem Notizsymbol mit dem Schlüs-selwort «decisionInput» beim entsprechenden Entscheidungsknoten anno-tiert.

Abbildung 4–12 zeigt einen Entscheidungsknoten mit einem Entschei-dungsverhalten, das prüft, ob die Teilnehmer mit einem bestimmten Ter-minvorschlag einverstanden sind.

Das Ergebnis des Entscheidungsverhaltens wird von den Überwachungs-bedingung zur Auswahl des Zweiges genutzt, wodurch entweder erneut einweiterer Termin vorgeschlagen, oder aber der Termin fixiert wird.

Vereinigungsknoten

Ein Vereinigungsknoten ermöglicht es, alternative Abläufe, die durch ei-nen Entscheidungsknoten aufgespalten wurden, bei Bedarf wieder zu ei-nem Zweig zusammenzuführen.

Sobald der Nachfolgerknoten zur Aufnahme von Token bereit ist, ak-zeptiert der Vereinigungsknoten den Token vom Vorgängerknoten und gibtdiesen an den Nachfolgerknoten weiter.

Für einen Vereinigungsknoten wird das gleiche Symbol wie für einenEntscheidungsknoten – eine Raute – verwendet. Ein Vereinigungsknotenbesitzt mehrere eingehende Kanten und nur eine ausgehende Kante. Ana-log zu Entscheidungsknoten müssen dabei alle Kanten ausschließlich Ob-jektflüsse oder ausschließlich Kontrollflüsse repräsentieren.

Schließlich besteht die Möglichkeit, durch ein und das selbe grafischeNotationssymbol – die Raute – einen Vereinigungsknoten und einen Ent-

Ankunft von Token startet das Entscheidungs-verhalten – Datentoken fungieren als Parameter

«decisionInput»Entscheidungsverhalten

Abb. 4–12Beispiel mit Entscheidungs-knoten und

h lTerminvorschlagen

[true] Terminfixieren

[false]«decision Input»

Teilnehmer mit Termineinverstanden?

Ein Vereinigungsknoten (merge node) führt alter-native (keine neben-läufigen!) Abläufe wieder zusammen

Token werden, sobald möglich, an den Nachfol-gerknoten weitergereicht

...

Vereinigungsknoten

Kombinierter Entscheidungs-und

......

206

scheidungsknoten miteinander zu kombinieren, wodurch mehrere einge-hende und mehrere ausgehende Kanten erlaubt sind.

Abbildung 4–13 zeigt eine Aktivität, die eine Erweiterung der Aktivi-tät Terminkoordination aus Abbildung 4–10 vornimmt, indem in einer ei-genen Aktion etwaige Kollisionen geprüft werden. Im Falle einer Kollisionbzw. solange noch kein Termin gefunden wurde (erster Vereinigungskno-ten), wird nach einem entsprechenden alternativen Terminvorschlag ge-sucht.

Falls keine Kollisionen erkannt wurden oder ein neuer Termin gefundenwerden konnte (zweiter Vereinigungsknoten), werden die Teilnehmer überden Termin informiert.

4.2.7 Nebenläufige Abläufe

Zur Modellierung von nebenläufigen Abläufen dienen Parallelisierungs-und Synchronisierungsknoten.

Parallelisierungsknoten

Ein Parallelisierungsknoten ermöglicht es, einen Ablauf in beliebig vielenebenläufige Zweige aufzuspalten, die jedoch nicht notwendigerweise par-allel ablaufen müssen, wie der Name suggeriert. Allein die Reihenfolge, inder die Zweige durchlaufen werden, ist beliebig.

Um eine Aufspaltung des Ablaufs in mehrere Zweige zu erreichen,werden die am Parallelisierungsknoten anliegenden Token für alle ausge-henden Kanten dupliziert. Dies erfolgt allerdings nicht automatisch sobaldein Token an der eingehenden Kante anliegt, sondern erst, wenn minde-stens eine der ausgehenden Kanten unter Berücksichtigung eventuell vor-handener Überwachungsbedingung das Token akzeptiert. Ist dies der Fall,werden Token sofort auch für jene Kanten dupliziert, bei denen die Evalu-ierung der Überwachungsbedingungen erfolglos war.

Diese Token bleiben in der Reihenfolge ihrer Erzeugung (FIFO-Prin-zip) erhalten, bis sie von den Überwachungsbedingungen akzeptiert wer-den. Dies stellt (neben Initialknoten) eine weitere Ausnahme von der Regeldar, dass Kontrollknoten keine Token aufbewahren dürfen.

Abb. 4–13Beispiel für Vereinigungsknoten


[else]

[Kollisionerkannt]

[else]

[Termingefunden]Kollision

prüfenTeilnehmerinformieren

Parallelisierungsknoten (fork node) zur Model-lierung nebenläufiger Abläufe

Eingehende Token werden für alle ausgehenden Kanten dupliziert, sobald zumindest eine Überwach-ungsbedingung diese akzeptiert

Nichtakzeptierte Token werden aufbewahrt


Ein Parallelisierungsknoten wird als schwarzer Balken mit einer ein-gehenden Kante und mindestens zwei ausgehenden Kanten dargestellt.Analog zu Entscheidungsknoten müssen alle Kanten entweder ausschlies-slich Objektflüsse oder ausschliesslich Kontrollflüsse repräsentieren.

Abbildung 4–14 zeigt einen Parallelisierungsknoten, durch den im An-schluss an das Eintragen eines Termins gleichzeitig die entsprechendenTeilnehmer informiert werden und geprüft wird, ob ein weiterer Termineinzutragen ist.

Falls ja, wird der Termin eingetragen, falls kein weiterer Termin vorhandenist, wird dieser Ablauf durch einen Ablaufendknoten terminiert, es könnenaber weiterhin Teilnehmer informiert werden. Sobald alle Teilnehmer ei-nes Termins informiert sind, wird geprüft, ob dies der letzte zu bearbei-tende Termin war. Ist dies der Fall, so kann die gesamte Aktivität beendetwerden. Andernfalls wird nur dieser eine Ablauf beendet.

Synchronisierungsknoten

Ein Synchronisierungsknoten agiert sozusagen als Gegenstück zum Paral-lelisierungsknoten, da eine Zusammenführung nebenläufiger Abläufe zueinem Ablauf erfolgt, indem die eingehenden Token entsprechend verei-nigt werden.

Die Vereinigung der Token erfolgt standardmäßig auf Basis einer vor-definierten, konjunktiven Synchronisierungsbedingung, d.h. sobald an al-len eingehenden Kanten Token anliegen. Details der Vereinigung hängendavon ab, ob es sich um Kontroll- und/oder Datentoken handelt, bzw. anwelchen Kanten die Token anliegen:

❑ In einem allerersten Schritt werden alle Kontrolltoken, die an einund der selben eingehenden Kante anliegen, zu einem Kontrollto-ken vereinigt.

❑ Liegen Kontrolltoken auch an verschiedenen Kanten an, so werdendiese ebenfalls zu einem Kontrolltoken vereinigt. Liegen keine Da-tentoken an, so wird dieses Kontrolltoken an der ausgehendenKante angeboten.

❑ Liegen Datentoken an, so werden alle diese Datentoken auf derausgehenden Kante angeboten. Dies erfolgt in der Reihenfolge, inder die Datentoken den Synchronisierungsknoten erreichen (FIFO-

Parallelisierungsknoten

...

Termineintragen

[else]

Teilnehmerinformieren

[weiterer Terminvorhanden]

[letzter Terminbearbeitet]

[else]

Abb. 4–14Beispiel für einen Parallelisierungsknoten

Synchronisierungsknoten (join node) führt neben-läufige Abläufe zusammen

Vereinigung der Token sobald an allen Kanten vorhanden

An einer Kante anliegende Kontrolltoken werden vereinigt

Kontrolltoken verschiede-ner Kanten werden ver-einigt und nur ein einzel-nes Token weitergereicht

Datentoken werden alle weitergereicht

208

Prinzip). Falls die Datentoken Objekte gleicher Identität beinhal-ten, werden diese standardmäßig zu einem Objekt vereinigt, bevorsie angeboten werden.

❑ Liegen Kontroll- und Datentoken an, werden nur die Datentokenweitergereicht.

Token werden vom Nachfolgerknoten akzeptiert oder zurückgewiesen,wobei in diesem speziellen Fall ausnahmsweise zurückgewiesene Tokenverloren gehen.

Der Synchronisierungsknoten wird, analog zum Parallelisierungskno-ten, als dicker schwarzer Balken mit mehreren eingehenden Kanten undgenau einer ausgehenden Kante dargestellt. Anders als bei allen bisher be-handelten Kontrollknoten ist es beim Synchronisierungsknoten möglich,Kontrollflüsse mit Objektflüssen zu synchronisieren. Dabei muss, sobaldeine der eingehenden Kanten einen Objektfluss darstellt, auch die ausge-hende Kante einen Objektfluss repräsentieren.

Analog zu Entscheidungs- und Vereinigungsknoten können auch Par-allelisierungs- und Synchronisierungsknoten kombiniert und mit einemNotationselement – dem schwarzen Balken – dargestellt werden. In diesemFall sind demnach mehrere einund ausgehende Kanten erlaubt.

Abbildung 4–15 zeigt eine Aktivität mit einem Parallelisierungskno-ten, der im Anschluss an die erfolgreiche Prüfung einer Benutzerkennung,eine parallele Verarbeitung der Terminerfassung und der Teilnehmerzuord-nung ermöglicht.

Erst wenn beide Aktionen vollständig durchgeführt sind, erlaubt der Syn-chronisierungsknoten die Ausführung der Nachfolgeraktion zur Kollisi-onsprüfung. Bei diesem Beispiel wurden bewusst zwei Aktivitätsendkno-ten verwendet, da die Aktivität sowohl bei einer falschenBenutzerkennung, als auch nach der Kollisionsprüfung beendet werdensoll. Die beiden Aktivitätsendknoten könnten jedoch auch durch einen er-setzt werden, dem dann aber ein Vereinigungsknoten vorangestellt werdenmüsste. Ohne Vereinigungsknoten würde ein Modellierungsfehler vorlie-gen, da zwei Kanten in den Aktivitätsendknoten münden würden, wodurchdieser nur beim Anliegen von zwei Token aktiv werden könnte, was imvorliegenden Beispiel nicht eintreten kann.

Eine weitere inkonsistente Situation kann sich ergeben, wenn nach ei-nem Parallelisierungsknoten ein Vereinigungsknoten verwendet wird odernach einem Entscheidungsknoten ein Synchronisierungsknoten. Parallele

Bei Kontroll- und Daten-token werden nur die Datentoken weitergereicht

Nichtakzeptierte Token gehen verloren

Synchronisierungsknoten

...

Kombinierter Parallelisie-rungs- und Synchroni-sierungsknoten

... ...

BenutzerIDprüfen

Terminerfassen

Teilnehmerauswählen

Kollisionprüfen

[ok]

[else]

BenutzerIDprüfen

Terminerfassen


Kollisionprüfen

[ok]

[else]

Abb. 4–15Beispiel für einen Paralleli-sierungs- und einen

Falsche Modellierung


Abläufe können nur durch einen Synchronisierungsknoten wieder zusam-mengeführt werden und alternative Abläufe nur durch einen Vereinigungs-knoten.

Durch Angabe einer benutzerdefinierten Synchronisierungs-bedingung kann auf bestimmte Kombinationen anliegender Token gewar-tet und erst dann mit der Abarbeitung fortgesetzt werden.

Die Synchronisierungsbedingung ist eine boolsche Bedingung, die ingeschwungenen Klammern angeschrieben wird und auf die eingehendenKanten über deren Namen Bezug nehmen kann. Eine Synchronisierungs-bedingung wird immer dann ausgewertet, wenn ein neues Token an einerder eingehenden Kanten anliegt. Neu hinzukommende Token unterbrecheneine gerade laufende Auswertung nicht und starten erst dann eine neueAuswertung, wenn die aktuelle beendet ist.

Abbildung 4–16 zeigt weitere Aspekte der Aktivität Terminkoordina-tion. Parallel zum Finden eines Terminvorschlag wird nun eine Kontakt-person für den Termin ausgewählt.

In einer entsprechenden Synchronisierungsbedingung wird festgelegt, dassdie Synchronisierung beider Abläufe und damit die Ausführung der Nach-folgeraktion Teilnehmer informieren dann erfolgen kann, wenn die Kon-taktperson ausgewählt ist und bei zumindest 90% der Teilnehmer keineTerminkollisionen auftreten. Im vorliegenden Beispiel könnte statt derSynchronisierungsbedingung auch ein Verzweigungknoten verwendetwerden, der - ohne vorangehenden Parallelisierungsknoten - entweder wie-der auf Terminvorschlag finden verzweigt, oder - anstatt in einen Ablau-fendknoten zu münden - zum Synchronisierungsbalken vor der AktionTeilnehmer informieren führt.

4.2.8 Arten von Objektknoten

Allen Objektknoten ist gemeinsam, dass Sie Datentoken – und damit Da-ten und Objekte – aufnehmen können und ausschliesslich durch Objekt-flüsse miteinander verbunden sind. Datentoken werden zwischen zwei Ob-jektknoten oder zwischen einem Objektknoten und einer Aktionverschickt.

Synchronisierungs-bedingung (join specifi-cation) zur Steuerung des Zeitpunkts der Token-weitergabe

{joinSpec = A and B and X<Y}A

B ...

Kontaktpersonauswählen



Kontaktpersonausgewählt

Terminvorschlag gefunden

[Anzahl Teilnehmerohne Kollision < 90%]

{JoinSpec = Kontaktperson ausgewählt undTerminvorschlag gefunden undAnzahl der Teilnehmerohne Kollision >= 90%}

[else]

Abb. 4–16Beispiel für eine Synchroni-

Ein Objektknoten (object node) nimmt Datentoken auf und steht mit einem Objektfluss in Beziehung

210

Der Inhalt eines Objektknotens – die Datentoken – ist das Ergebnis dervorangegangenen Aktion bzw. kann von dieser verändert worden sein undist die Eingabe für die nachfolgende Aktion.

Für einen Objektknoten, dargestellt durch ein Rechteck, kann nebendem Namen optional ein Typ, durch Doppelpunkt vom Namen getrennt,angegeben werden. Dadurch kann ein Objektknoten nur Objekte des ange-gebenen Typs oder eines Subtyps aufnehmen. Da der Name in vielen Fäl-len bereits den Typ ausdrückt, wird meist nur der Name angegeben. Dar-über hinaus kann ein Objektknoten auch auf einen bestimmten Zustandeingeschränkt werden, sodass er nur Token aufnehmen kann, die Objekteim entsprechenden Zustand referenzieren. Eine Zustandseinschränkungkann in eckigen Klammern unterhalb des Namens angegeben werden. Istweder ein Typ noch eine Zustandseinschränkung spezifiziert, kann ein Ob-jektknoten beliebige Daten und Objekte aufnehmen. Wie bereits erwähntwird ein Objektknoten, im Falle einer Verwendung als Parameter, direktam Rahmen der zugehörigen Aktivität (überlappend) bzw. der Aktion(nicht überlappend in Form sogenannter Pins) »angeheftet«.

Die im folgenden beschriebenen Arten von Objektknoten unterschei-den sich im wesentlichen darin, ob sie als Parameter fungieren oder alszentrale Puffer existieren und in welcher Form sie Token aufnehmen bzw.weitergeben.

Objektknoten als Parameter von Aktivitäten und Aktionen

Objektknoten, die einer Aktion oder Aktivität zugeordnet sind, fungierenals formale Ein- und Ausgabeparameter.

Ein Aktivitätsparameterknoten ist ein Objektknoten der einer Aktivitätzugeordnet ist und als formaler Ein- bzw. Ausgabeparameter fungiert.Seine Aufgabe besteht demnach darin, einer Aktivität Datentoken zur Ver-fügung zu stellen bzw. Datentoken an deren Aufrufer zurückzugeben. Da-her muss der Typ des Aktivitätsparameterknotens auch jenem des Parame-ters des Aufrufers entsprechen. Je nachdem, ob einAktivitätsparameterknoten als Ein- oder Ausgabeparameter fungiert, darfer nur ausgehende Objektflüsse oder aber nur eingehende Objektflüsseaufweisen.

Formale Parameter von Aktionen werden als Pins bezeichnet.Eingabepins, ebenso wie Ausgabepins, werden als kleine Rechtecke darge-stellt, die an Aktionsknoten angefügt werden. Bei Aktionen die anderesVerhalten aufrufen, kann bei den Pins auch die vollständige Spezifikationdes entsprechenden Parameters des aufzurufenden Verhaltens verwendetwerden.

Ist der Objektfluss zwischen Pins nicht durch entsprechende Kantenersichtlich, dann kann die Kennzeichnung als Eingabe- bzw. Ausgabepin

Inhalt ist Ergebnis einer Aktion und Eingabe für eine weitere Aktion

Angabe eines Typs für einen Objektknoten sowie einer Zustandseinschrän-kung ist optional

ObjektKnoten:Typ[Zustand]

Aktivitätsname


Aktions-


name

Unterscheidung verschie-dener Arten von Objekt-knoten

Ein- und Ausgabeparameter für Aktivitäten – Aktivitäts-parameterknoten (activity parameter node)

Aktivitäts-

Eingabe- Ausgabe-parameter parameter

name

Ein- und Ausgabeparameter für Aktionen (Pins)

Implizite vs. explizite Kenn-zeichnung als Ein- und

Ausgabepin

Aktion1 Aktion2

Aktion1 Aktion2


explizit durch kleine Pfeile im Pinsymbol erfolgen. Dabei zeigt bei Einga-bepins die Pfeilspitze zum Aktionsknoten, während bei Ausgabepins diePfeilspitze vom Aktionsknoten weg zeigt.

Obwohl die Pfeilrichtung der Objektflusskanten bzw. die in den Pinsdargestellten Pfeile bereits anzeigen, ob es sich bei einem Pin um einenEingabe- oder einen Ausgabepin handelt ist es üblich, wie auch bereits beiEin- und Ausgabeparametern von Aktivitäten angemerkt, einen Eingabe-pin links bzw. oberhalb eines Aktionsknotens darzustellen, während einAusgabespin üblicherweise rechts bzw. unterhalb des Aktionsknotens dar-gestellt wird.

Falls der Typ des Ausgabepins einer Aktion jenem des Eingabepinsder Nachfolgeraktion entspricht, können statt der Repräsentation in Formvon zwei Pins weitere alternative Darstellungen verwendet werden. Er-stens kann stattdessen ein einzelner Objektknoten in Form eines Rechtecksnotiert werden. Zweitens kann statt des Objektknotenrechtecks ein kleinesPinrechteck verwendet werden und der Name des Objektknotens oberhalbangegeben werden. Und als dritte Variante ist es auch möglich, nur eineeinzelne Objektflusskante vom Vorgänger- zum Nachfolgerknoten zuzeichnen, oberhalb ein kleines Pinrechteck anzugeben und auf den Namendes Pins zu verzichten, falls dieser bereits aus der Bezeichnung der betei-ligten Aktionen hervorgeht.

Für Ein- und Ausgabeparameter kann bei den entsprechenden Pins an-gegeben werden, welchen Effekt (create, read, update oder delete) eineAktion auf die entsprechenden Daten und Objekte hat. Dabei können na-turgemäß neu erstellte Daten und Objekte nur über einen Ausgabepin zurVerfügung gestellt werden, während Daten und Objekte, die von einer Ak-tion gelöscht werden sollen, an die Aktion durch einen Eingabepin überge-ben werden.

Abbildung 4–17 zeigt eine Aktion zur Terminerfassung, die einen Ter-min erzeugt und an einem Ausgabepin zur Verfügung stellt, sowie eine Ak-tion Teilnehmer auswählen, deren Ausgabepin einen Teilnehmer enthält.

Die Nachfolgeraktion ist dafür zuständig, den über Eingabepins eingehen-den Teilnehmern eine Einladung zum Termin zu senden.

Notationskonvention -Eingababepins links bzw.

oberhalb einer AktionAusgabepins rechts bzw.

unterhalb einer Aktion

Notationsvarianten für Pins

OKnoten1Aktion1 Aktion2

OKnoten1Aktion1 Aktion2

Aktion1on

OKnoten1Aktion2

onOKnoten1

Effekte einer Aktion – create, read, update und delete

Aktion1{create}

OKnoten1Aktion1{create}

TerminerfassenTerminerfassen

TeilnehmerauswählenTeilnehmerauswählen

EinladungversendenEinladungversenden

Termin

Teilnehmer

{create}

Abb. 4–17Beispiel für Ein- und Ausgabepins

212

Konstanter Eingabewert – Wertepin

Ein Wertepin ist eine spezielle Form eines Eingabepins. Dieser erlaubt es,für eine Aktion einen Wert, z.B. in Form einer Konstante, zur Verfügungzu stellen, ohne für dessen Erzeugung bzw. Weiterreichung eine eigeneAktion oder einen eigenen Objektfluss definieren zu müssen. Wertepinshaben daher auch keine eingehenden Objektflüsse.

Die Verarbeitung eines Knotens wird jedoch, im Gegensatz zu her-kömmlichen Eingabepins, durch Wertepins alleine nicht gestartet. DerWert wird erst dann an den Knoten weitergereicht, wenn dessen Verarbei-tung zum Beispiel durch Kontrolltoken gestartet wird.

Wertepins werden wie Eingabepins dargestellt, zusätzlich wird derWert neben dem Pinsymbol angegeben.

Pufferknoten

Objektknoten können zentral für verschiedene Aktionen als Pufferknotendefiniert werden. Derartige Objektknoten können zur Pufferung vonDatentoken beliebig vieler Vorgängerknoten verwendet werden und diesebeliebig vielen Nachfolgerknoten zur Verfügung stellen. Je nach Dauer derSpeicherung der eingehenden Datentoken können transiente Pufferknoten(Schlüsselwort «centralBuffer») und persistente Pufferknoten(Schlüsselwort «datastore») unterschieden werden.

Während ein transienter Pufferknoten gespeicherte Datentoken nichtweiter aufbewahrt, sobald sie an einen Knoten weitergegeben wurden,werden die Datentoken in einem persistenten Pufferknoten dupliziert, be-vor sie weitergereicht werden.

Ein persistenter Pufferknoten speichert somit alle eingehenden Daten-token, solange die Ausführung der Aktivität andauert, wodurch auf gespei-cherte Datentoken bei Bedarf jederzeit zugegriffen werden kann.

Ein eingehendes Datentoken, das ein Objekt referenziert, ersetzt beieinem persistenten Pufferknoten ein bereits vorliegendes Datentoken, dasein identes Objekt referenziert, d.h. idente Objekte liegen immer nur ein-mal vor. Dies ist ein wesentlicher Unterschied zu herkömmlichen Objekt-knoten, bei denen idente Objekte redundant gespeichert werden.

Selektionsverhalten ausgehender Objektflüsse (siehe Kapitel 4.2.9)kann dazu verwendet werden, um Datentoken aus dem persistenten Puffer-knoten zu selektieren und diese nachfolgenden Aktionen über Eingabepinszur Verfügung zu stellen. Somit können Daten für Aktionen zu beliebigenZeitpunkten »abgeholt« werden, anstatt darauf zu warten, dass die Daten-token automatisch weitergereicht werden, sobald sie vorliegen.

Wertepin (value pin) zur Übergabe konstanter Werte

Wertepin startet nicht die Verarbeitung eines Knotens

Aktion15

Zentrale Pufferung von Datentoken

Transiente Pufferknoten (central buffer node) löscht weitergegebene Datentoken

Aktion2Aktion1OK1

«centralBuffer»

Persistenter Pufferknoten (data store node) bewahrt sie auf und gibt Duplikate weiter

Aktion2Aktion1OK1

«datastore»

Keine Mehrfachspeicherung identer ObjekteExplizites »Abholen« der Datentoken möglich


Abbildung 4–18 erweitert die Aktivität aus Abbildung 4–15 um zweiPufferknoten.

Der persistente Pufferknoten Benutzer speichert im Sinne einer Datenbankalle Benutzer des Terminkalenders, aus denen im Zuge der Teilnehmeraus-wahl bestimmte Benutzer selektiert werden. Ausgewählte Benutzer wer-den in einem transienten Puffer zwischengespeichert und erst für die Ver-sendung von Einladungen wieder entnommen.

Ein- und Ausgabeparameter für Datenströme

Objektknoten die als Parameter von Aktionen verwendet werden, könnenzur Ein- und Ausgabe von Datenströmen verwendet werden. DerartigeDatenstromparameter erlauben das Weiterreichen von Datentoken an eineAktion bzw. aus einer Aktion heraus auch dann, wenn die Aktion geradeaktiv ist. Eine Aktion kann Datenströme sowohl nur als Eingabeparameter,als auch nur als Ausgabeparameter aufweisen oder als Ein- und Ausgabe-parameter.

Bevor die Aktion ausgeführt werden kann, müssen jedoch alle Einga-beparameter vorliegen, die nicht als Datenstromparameter gekennzeichnetsind. Weist das Verhalten ausschliesslich Eingabeparameter für Daten-ströme auf, so müssen zumindest Datentoken für einen dieser Parametervorliegen.

Datenstromparameter werden entweder mit {stream} gekennzeichnet,oder die ein- bzw. ausgehende Objektflusskante wird mit ausgefülltenPfeilspitzen versehen, oder aber das entsprechende kleine Pinrechteck wirdausgefüllt dargestellt.

Ausgabeparameter für Ausnahmen

Ausgabeparameter einer Aktion können als Ausnahmen gekennzeichnetwerden. Die darauffolgende Aktion wird nur durchgeführt, falls das Auf-treten einer Ausnahme durch das Vorhandensein eines solchen Ausnahme-parameters angezeigt wurde. Ausnahmeparameter werden nicht zusammen

Abb. 4–18Beispiel mit transienten und persistenten PufferknotenBenutzerID

prüfen

Terminerfassen


Kollisionprüfen

Einladungversenden

[ok]

[else]

«datastore»Benutzer

«centralBuffer»AusgewählteTeilnehmer

Ein- und Ausgabe von Datentoken während eine Aktion aktiv ist (streaming parameter)

Start der Aktion, sobald Datentoken für zumindest einen Eingabeparameter vorhanden

OK1

Aktion1

{stream} {stream}

{stream}

OK1Aktion1

OK1

OK1

Aktion1Aktion1

Aktion1Aktion1

Ausgabeparameter für Ausnahmen (exception parameter)

Aktion1 Aktion2

OK1Aktion1 Aktion2

OK1

214

mit gewöhnlichen Parametern am Ende einer Aktion weiter gegeben, son-dern nur im Falle des Auftretens einer Ausnahme, wobei in diesem Fall da-für keine gewöhnlichen Parameter weitergegeben werden. Das gleiche giltfür Ausnahmeparameter von Aktivitäten, wobei hier im Fall einer Aus-nahme alle Abläufe der Aktivität beendet werden. Die Kennzeichnung ei-nes Ausnahmeparameters erfolgt durch ein kleines Dreieck an jener Ob-jektflusskante, die von der Aktion, in der die Ausnahme ausgelöst werdenkann, wegführt.

Gruppierung von Parametern – Parametersatz

Ein Parametersatz erlaubt die Zusammenfassung von Parametern, um so-mit alternative, einander ausschließende Gruppen von Ein- bzw. Ausgabe-werten zu spezifizieren. Dies wird durch einen Rahmen um die zu gruppie-renden Parameter ausgedrückt. Die durch einen Parametersatzzusammengefassten Parameter müssen alle entweder Eingabeparameteroder aber Ausgabeparameter sein. Ein Parameter kann dabei mehreren Pa-rametersätzen zugeordnet sein, wobei jedoch unterschiedliche Parameter-sätze niemals genau dieselben Parameter aufweisen dürfen. Sobald zumin-dest ein Parametersatz existiert, müssen alle nicht durch einenParametersatz zusammengefassten Eingabeparameter Datenstromparame-ter repräsentieren.

Pro Ausführung der Aktion bzw. der Aktivität werden immer nur dieEingabeparameter eines der alternativen Parametersätze verwendet. Dasbedeutet, dass nicht an allen Pins Datentoken anliegen müssen, um dieAusführung des Verhaltens zu starten, es reichen Datentoken an allen Pinseines Parametersatzes. Eine Aktion mit Parametersätzen für Ausgabepara-meter kann wiederum nur Ausgabewerte für einen der Parametersätze ge-nerieren, d.h. nach Beendigung der Ausführung müssen nur an allen Pinseines Parametersatzes entsprechende Datentoken vorhanden sein.

Abbildung 4–19 zeigt eine Aktion zum Anlegen einesTerminkalendereintrags, der – abhängig von der Eintragsart – entwedereinen Todo-Eintrag, einen Termin oder einen Serientermin erzeugt. Dafürsind jeweils unterschiedliche Informationen notwendig, die durchentsprechende Parametersätze – benannt nach der Eintragsart – gruppiertwerden. Während für einen Todo-Eintrag Beginn- und Enddatumausreichend sind, ist bei einem Termin zusätzlich der Ort und bei einemSerientermin Wiederholungsdauer und -frequenz erforderlich.

Ein Parametersatz (parameter set) erlaubt die Gruppierung von Ein- bzw. Ausgabeparametern

Aktions-name

Nur ein ausgewählter Parametersatz ist jeweils für die Ausführung der Aktion relevant


Ist der Kalendereintrag angelegt, werden die betroffenen Teilnehmern in-formiert und parallel dazu werden entsprechende Notifikationen erstellt,um die Teilnehmer kurz vor dem Beginndatum nochmals zu erinnern.

4.2.9 Steuerung des Objektflusses

Ein Objektfluss hat, wie bereits erwähnt, zwei Aufgaben. Zum Einen wer-den Datentoken von Vorgängerknoten zu Nachfolgerknoten transportiert,zum Anderen werden durch die Zurverfügungstellung der Datentoken Ak-tionen gestartet.

Ein Objektfluss verknüpft Objektknoten, d.h. Aktionen können nichtdirekt durch einen Objektfluss verbunden werden. Der Objektfluss kanndabei aber auch über Kontrollknoten geleitet werden.

Falls die beteiligten Objektknoten eines Objektflusses typisiert sind,bestimmen diese, welche Daten bzw. Objekte transportiert werden dürfen.Ist kein Typ angegeben, so kann ein Objektfluss Daten bzw. Objekte belie-biger Typen transportieren.

Im einfachsten Fall werden die Datentoken an der Objektflusskanteunverändert zur Weiterverarbeitung angeboten. Dieses Standardverhaltenfür den Objektfluss kann jedoch durch verschiedene Sprachkonzepte be-einflusst werden, die beim Objektknoten bzw. bei der Objektflusskanteselbst spezifiziert werden können. Dabei handelt es sich um die Spezifika-tion von Reihenfolgen, Kapazitätsobergrenzen und Gewichten, sowieSelektions- und Transformationsverhalten.

Todo-Eintrag

Eintraganlegen

BeginnDatum

EndDatum

Ort

WhFrequenz

WhDauer

Termin

Serientermin


Notifikationenerstellen

Eintrag

EintragEintrag

Abb. 4–19Beispiel für Parametersätze

Ein Objektfluss hat eine Transport- und eine Kontrollfunktion

Ein Objektfluss verknüpft Aktionen nicht direkt, sondern über Objektknoten

Objektknoten bestimmen den Typ der zu transpor-tierenden Objekte

Weitergabe von Daten-token – Sortierung, Kapazi-tät, Gewicht, Filterung und

216

Reihenfolge der Tokenweitergabe

Die Reihenfolge, in der die Datentoken eines Objektknotens an eine ausge-hende Objektflusskante weitergereicht werden, kann explizit festgelegtwerden. Dabei können folgende Optionen innerhalb von geschwungenenKlammern beim Objektknoten spezifiziert werden:

❑ Standardmässig ist die Weitergabereihenfolge als FIFO definiert,d.h. die Token werden in jener Reihenfolge weitergereicht, in dersie den Objektknoten erreichen.

❑ Sollen jene Token die zuletzt eingegangen sind als erste weiterge-reicht werden, so kann dies durch die Option LIFO angegeben wer-den.

❑ Wird eine benutzerdefinierte Reihenfolge gewünscht, so kanndiese durch Angabe eines entsprechenden Selektionsverhaltensausgedrückt werden (siehe weiter unten).

❑ Schliesslich kann auch angegeben werden, dass die Reihenfolge inder Token eingehen, keinen Einfluss auf die Reihenfolge hat, in dersie weitergereicht werden.

Kapazitätsobergrenze und Gewicht

Objektknoten können bezüglich der Anzahl von Token, die sie aufnehmenkönnen, begrenzt werden. Die Kapazitätsobergrenze eines Objektknotensgibt in Form eines ganzzahligen Werts an, wieviele Token sich zu einembestimmten Zeitpunkt maximal im Objektknoten befinden dürfen, stan-dardmässig ist die Kapazität beliebig. Ist diese Obergrenze erreicht, sokann der Objektknoten keine weiteren Token mehr aufnehmen, diese ver-bleiben im Vorgängerknoten. Die Kapazitätsobergrenze der direkt über ei-nen Objektfluss verbundenen Objektknoten muss gleich sein. Die Kapazi-tätsobergrenze wird beim Objektknoten in Form einer Einschränkung(upperBound) angegeben.

Für eine Objektflusskante kann durch einen ganzzahligen Wert ein so-genanntes Gewicht angegeben werden. Das Gewicht gibt an, wie viele To-ken anliegen müssen, bevor diese an den Nachfolgerknoten weitergegebenwerden. Es ist zu beachten, dass das Gewicht kleiner oder gleich der Kapa-zitätsobergrenze des Nachfolgerknotens sein muss. Das Gewicht wird beider Objektflusskante ebenfalls in Form einer Einschränkung (weight) no-tiert.

Die Reihenfolge, in der die Token weitergereicht werden, kann festgelegt werden

FIFO (first in, first out){ordering = FIFO}

LIFO (last in, first out){ordering = LIFO}

Geordnet{ordering = ordered}

Ungeordnet{ordering = unordered}

Kapazitätsobergrenze (upper bound) limitiert die Anzahl der Token, die ein Objektknoten aufnehmen kann

OKnoten1 {upperBound=Wert}

Gewicht einer Objektflusskante (weight)

OKnoten2{weight=Wert}


Der in Abbildung 4–20 dargestellte Pufferknoten kann aufgrund derdefinierten Kapazitätsobergrenze maximal 20 Todo-Einträge aufnehmen.

Sollte diese Obergrenze erreicht werden, werden die Einträge – aus Über-lastungsgründen des Benutzers – aufgrund des Gewichts der ausgehendenKante an den Aktivitätsendknoten weitergeleitet und gelöscht.

Selektions- und Transformationsverhalten

Durch die Definition eines Selektionsverhaltens können, im Unterschiedzu einer Überwachungsbedingung, die nur über die Weitergabe aller Tokenentscheidet, bestimmte Token für die Weitergabe ausgewählt werden. Se-lektionsverhalten stellt damit eine Art von Tokenfilter dar und bestimmtdamit implizit auch die Reihenfolge, in der die Token weitergereicht wer-den.

Selektionsverhalten kann zum Einen beim Objektknoten selbstspezifiziert werden, wodurch an zentraler Stelle für alle Token bestimmtwerden kann, welche dieser Token an allen ausgehenden Objektflusskan-ten angeboten werden. Zum Anderen kann Selektionsverhalten bei einerObjektflusskante definiert werden, wodurch spezifiziert wird, welcheToken dem Objektknoten entnommen und über diese Kante an denNachfolgerknoten weiterfliessen sollen.

Selektionsverhalten kann durch eine beliebige Form der Verhaltens-spezifikation definiert werden, zum Beispiel durch eine andere Aktivität,die jedoch nebeneffektfrei sein muss. Das Verhalten muss einen Eingabe-parameter in Form einer Multimenge aufweisen und einen Ausgabepara-meter, der das ausgewählte Token enthält. Die Token des Eingabeparame-ters müssen dabei vom Typ des Objektknotens oder aber eines Supertypsdavon sein, der Ausgabeparameter vom Typ oder einem Subtyp.

Das Selektionsverhalten wird in einer Notiz mit dem Schlüsselwort«selection» dargestellt, die mit dem Objektknoten oder der Objektflus-skante verbunden ist.

Datentoken können vor ihrer Weitegabe nicht nur geordnet und gefil-tert, sondern auch transformiert werden. So kann ein entsprechendesTransformationsverhalten den Datenwert eines Tokens austauschen, dieReferenz auf ein Objekt durch eine andere austauschen oder aber ein ein-gehendes Datentoken in mehrere ausgehende Datentoken transformieren.

Abb. 4–20Beispiel für Kapazitätsober-grenzen und Gewicht

Todoeintragen

{upperBound=20}«centralBuffer»

Todos{weight=20}

[else][weitere Todosvorhanden]

Todoeintragen

{upperBound=20}«centralBuffer»

Todos{weight=20}

[else][weitere Todosvorhanden]

Selektionsverhalten (selection behavior) wählt bestimmte Token zur Weitergabe aus

Objektknoten und Objektflusskanten können Selektionsverhalten aufweisen

Selektionsverhalten – z.B. in Form einer Aktivität –muss einen Eingabe- und einen Ausgabeparameter aufweisen

«selection»filter1

OKnoten1

«selection»filter2

OKnoten2

Transformationsverhalten (transformation behavior) transformiert Datentoken

218

Transformationsverhalten kann analog zum Selektionsverhalten durcheine beliebige Form der Verhaltensspezifikation definiert werden und auchbezüglich Parameter und Nebeneffekten gelten diesselben Anforderungenwie beim Selektionsverhalten.

Transformationsverhalten wird in einer Notiz mit dem Schlüsselwort«transformation» an der Objektflusskante annotiert.

Abbildung 4–21 zeigt ein einfaches Selektionsverhalten, mit dembeim Zugriff auf den persistenten Pufferknoten Benutzer relevante Benut-zer für die endgültige Auswahl der Teilnehmer eines Termins vorselektiertwerden.

Selektionskriterium stellt dabei das Know-How des Benutzers dar, das mitdem für den Termin notwendigen Know-How übereinstimmen muss.

4.2.10 Partitionen

Eine Partition erlaubt die Gruppierung von Knoten und Kanten einer Akti-vität auf Basis gemeinsamer Eigenschaften. Betrachtet man beispielsweiseeinen Geschäftsprozess, so könnten durch eine Partition alle Aktionen zu-sammengefasst werden, deren Ausführung z.B. im Verantwortlichkeitsbe-reich eines bestimmten Standorts liegt. Weitere Gruppierungskriterien zurPartitionierung einer Aktivität wären beispielsweise Abteilungen, Ge-schäftsbereiche, Rollen, Ressourcen oder Subsysteme (siehe auch[Jeck04c]). UML ist hinsichtlich der potentiell verwendbaren Gruppie-rungskriterien sehr offen – eine Partition kann beliebige Modellelementeumfassen, wobei jedoch bei deren Verwendung einige Regeln zu beachtensind, um die Konsistenz zu gewährleisten (siehe weiter unten).

Partitionen beeinflussen nicht den Ablauf einer Aktivität, sondern stel-len lediglich eine logische Sicht auf deren Bestandteile dar. Sie erhöhen dieÜbersichtlichkeit, erlauben eine rasche Erkennung der Verantwortlich-keitsbereiche und bringen damit auch mehr Detailinformation in das Mo-dell ein.

Partitionen werden durch sogenannte »Schwimmbahnen« dargestellt,das sind zwei horizontale oder vertikale, parallel zueinandern verlaufendeLinien, die am Kopfende ein Rechteck mit dem Partitionsnamen tragen. Ineiner solchen Schwimmbahn werden all jene Bestandteile der Aktivität

Beliebige Verhaltensspezi-fikation verwendbar

«transformation»transform1

OKnoten1



«selection»Benutzer.knowHow() =Termin.BenötigtesKnowHow()

«selection»Benutzer.knowHow() =Termin.BenötigtesKnowHow()

Abb. 4–21Beispiel für Selektionsverhalten

Eine Partition (activity partition) erlaubt die Gruppierung von Knoten und Kanten einer Aktivität nach bestimmten Kriterien

Logische Sicht auf eine Aktivität zur Erhöhung der Übersichtlichkeit und Semantik des Modells

»Schwimmbahnen«-Notation (swimlanes)

Part

ition

s-

nam

e

«cla

ss»

Partitions- name

«class»


platziert, die der Partition zugeordnet sind. Der Partitionsname kann zu-sätzlich mit einem Schlüsselwort versehen werden, mit dem das Meta-modellelement angegeben wird, auf dem die Partition basiert. Es sei andieser Stelle darauf hingewiesen dass Kanten, die Knoten aus unterschied-lichen Partitionen miteinander verbinden, aus notationstechnischen Grün-den nicht eindeutig einer Partition zugeordnet werden können.

Hierarchische, multidimensionale und externe Partitionen

Im Unterschied zu UML1 können Partitionen in UML2 auch hierarchischangeordnet werden. Eine hierarchische Partition ist auf beliebig vielenHierarchieebenen in weitere Subpartitionen unterteilt. Damit können Ak-tionen einer Aktivität beispielsweise nicht nur einem bestimmten Standortzugeordnet werden, sondern auf einer weiteren, darunterliegenden Hierar-chieebene auch den entsprechenden zuständigen Abteilungen. Die Parti-tion, die die Wurzel einer derartigen Verschachtelung repräsentiert, kanndabei als Dimension ausgezeichnet werden. Eine Dimension stellt einen»Diskriminator« dar, der eine disjunkte Partitionierung der Subpartitionenerfordert.

Betrachtet man die Notation für eine hierarchische Partition, so wirdeine Schwimmbahn in weitere Bahnen unterteilt, sowie jede dieser Bahnenam Kopfende mit einem eigenen Rechteck inklusive Partitionsnamen undoptional dem Schlüsselwort des verwendeten Metamodellelements verse-hen. Darüber wird der Name der Dimension und optional wiederum dasSchlüsselwort des verwendeten Metamodellelements angegeben.

Eine weitere Neuerung in UML2 stellt die Möglichkeit zur Definitionmultidimensionaler Partitionen dar. UML2 erlaubt die Verwendung meh-rerer, orthogonaler Dimensionen auf der gleichen Hierarchieebene, wobeiein bestimmter Knoten innerhalb einer Dimension – wie auch bei hierar-chischen Partitionen – ausschliesslich einer der Partitionen zugeordnetsein darf. So können z.B. die Partitionen Produktion, Verkauf und Servicezu einer Dimension Geschäftsbereich zusammengefasst werden, währenddie Partitionen Linz, Wien, Klagenfurt zu einer, dazu orthogonalen Dimen-sion Standort zusammengefasst werden können.

Die Einteilung in zwei orthogonale Dimensionen lässt sich ebenfalls inForm von Schwimmbahnen, die in Rasterform angeordnet werden, darstel-len. Obwohl der UML-Standard mehr als zwei Dimensionen erlaubt, lässtsich dies mit Hilfe von Schwimmbahnen nicht mehr übersichtlich veran-schaulichen.

Daher wird als Notationsalternative eine textuelle Angabe der Parti-tion, innerhalb von runden Klammern, oberhalb des Namens des jeweili-gen Aktionsknotens angeboten. Weist eine Aktion zwei oder mehr durcheinen doppelten Doppelpunkt getrennte Partitionsnamen auf, so wird da-

Hierarchische Partitionen zur Schachtelung auf verschie-denen

Subpartition

Name der Subpartition

DimensionsnameName der

Multidimensionale Partitionen zur Zuordnung von Partitionen zu mehreren Dimensionen

Parti

tions

-na

me

Parti

tions

-na

me

Dim

ensi

onsn

ame

Partitions-name

Partitions-name

Dimensionsname

Textuelle Notationsform(Partitionsname)

Aktion(Partitionsname1::

AktionPartitionsname2)

(Partitionsname1,

AktionPartitionsname2)

Hierarchisch

Multi-dimensional

220

durch eine hierarchische Partitionierung (Schachtelung von links nachrechts) ausgedrückt, handelt es sich um eine durch Kommata separierte Li-ste von Partitionsnamen, so wird dadurch eine multidimensionale Partitio-nierung dargestellt.

Knoten, die ausserhalb der Partitionsstruktur liegen, können in einereigenen Partition zusammengefasst werden, die mit dem Schlüsselwort«external» gekennzeichnet wird.

.

Abbildung 4–22 zeigt eine weitere Variante einer Terminkoordination,wobei in diesem Fall zwei Partitionen – Benutzer und Calendarium – zumEinsatz kommen und die beteiligten Aktionen entsprechend gruppiert wur-den Zusammenhang zwischen Partitionen und Modellelementen

Wie bereits erwähnt, kann eine Partition ein beliebiges UML Metamodell-element repräsentieren. Voraussetzung ist jedoch, dass eine Partition unddie dadurch gruppierten Knoten und Kanten der Aktivität, der Definitiondes entsprechenden Modellelements nicht widersprechen dürfen. Im fol-genden werden die zu beachtenden normativen Regeln für einige zentraleMetamodellelemente im Überblick dargestellt.

Repräsentiert die Partition einen Classifier, so muss ein eventuelldurch die Partition gruppierter Verhaltensaufruf in der Verantwortlichkeitdes verwendeten Classifiers liegen, d.h. der Classifier muss den Kontextfür den Verhaltensaufruf darstellen. Demzufolge müssen Prozeduraufrufe

Benutzer CALENDARIUM

Terminanlegen


Eckdaten desTermins erfassen

Kollisionprüfen

Termin [erzeugt]

Termin

Termin

Termin[erfasst]

Termin[ausgewählt]

BenutzerID prüfen


Termin[zugeordnet]

[ok][else]

Abb. 4–22Beispiel für Partitionen

Partitionsdefinition muss der Definition des Modell-elements entsprechen

Classifier als Partition – repräsentiert Verhaltens-kontext und muss bei hierarchischer Partitio-nierung Kompositions-beziehungen aufweisen


und Ereignissignale zur Laufzeit eine Instanz des Classifiers als Ziel ha-ben. Ist die Partition in einer anderen Partition geschachtelt, die ebenfallseinen Classifier repräsentiert, so muss zwischen den beiden Classifierneine Kompositionsbeziehung bestehen oder der Classifier der eingebette-ten Partition muss in dem übergeordneten Classifier definiert sein.

Im Falle der Verwendung einer Rolle als Partition, liegt das gruppierteVerhalten in der Verantwortlichkeit der Instanzen, die die betreffende Rollespielen. Es gelten dabei zunächst alle Regeln, die bereits beim Classifierbeschrieben wurden, wobei Prozeduraufrufe und Ereignissignale als Zielsolche Instanzen verwenden müssen, die zur Laufzeit die entsprechendeRolle spielen. Ist die Partition hierarchisch strukturiert, so muss die Struk-tur der internen Struktur des betreffenden Classifiers entsprechen.

Wird die Partition dazu verwendet, um eine Instanz zu repräsentiert, soist das gruppierte Verhalten auf diese eine Instanz eingeschränkt, d.h. dassProzeduraufrufe sowie Ereignissignale zur Laufzeit als Ziel die betref-fende Instanz haben müssen.

Eine Partition kann durch ein Attribut, und dessen Subpartitionendurch Werteausprägungen des Attributs, repräsentiert werden, wobei da-von ausgegangen wird, dass die Werte zur Laufzeit für die entsprechendenAktionen die sich in dieser Subpartition befinden, vorliegen.

4.2.11 Strukturierte Aktivitätsknoten

Ein strukturierter Aktivitätsknoten kann – analog zu Blöcken in Program-miersprachen – dazu verwendet werden, beliebige Teile einer Aktivität,d.h. Knoten und Kanten, zu einer in sich abgeschlossenen und strukturier-ten Ausführungseinheit zusammenzufassen. Strukturierte Aktivitätsknotenkönnen wiederum weitere strukturierte Aktivitätsknoten enthalten, wo-durch eine beliebige Schachtelung möglich ist.

Ein strukturierter Aktivitätsknoten ist – wie der Name ausdrückt –selbst wiederum ein Knoten der Aktivität und wird in Bezug auf die Ab-laufsemantik wie ein solcher behandelt. D.h. dass die in einem strukturier-ten Aktivitätsknoten befindlichen Aktionen erst dann gestartet werden,wenn alle erforderlichen Token am strukturierten Aktivitätsknoten anlie-gen. Ein strukturierter Aktivitätsknoten gibt die Kontrolle und damit dieentsprechenden Token an nachfolgende (ausserhalb liegende) Knoten solange nicht weiter, solange die Abarbeitung von Aktionen die innerhalbliegen andauert. Token befinden sich nur während der Ausführung inner-halb des strukturierten Aktivitätsknotens. Aktivitätsendknoten und Ablau-fendknoten können auch in strukturierten Aktivitätsknoten modelliert wer-den.

Es ist dabei zu beachten, dass Aktivitätsendknoten innerhalb einesstrukturierten Aktivitätsknotens nur lokale Auswirkungen haben, d.h. nur

Rolle als Partition -gesamtes gruppiertes Verhalten auf Instanzen der Rolle beschränkt, Partitions-struktur muss Classifier-Struktur entsprechen

Instanz als Partition -gesamtes gruppiertes Verhalten auf diese eine Instanz beschränkt

Attribute als Partition -Werte als Subpartitionen

Ein strukturierter Aktivitäts-knoten (structured activity node) dient zur Festlegung einer in sich abgeschlossenen

Ein strukturierter Aktivitäts-knoten wird wie ein herkömmlicher Knoten einer Aktivität behandelt

Nur lokale Auswirkungen von Aktivitätsendknoten

222

den strukturierten Aktivitätsknoten beenden, nicht jedoch die gesamte Ak-tivität.

Ebenso unterstützen strukturierte Aktivitätsknoten Ein- und Ausgabe-parameter in Form von Pins. Sind für den strukturierten AktivitätsknotenEingabepins vorhanden, so können die eingehenden Datentoken über ent-sprechende Objektflusskanten an die Knoten innerhalb der Aktivität wei-tergereicht werden.

Kanten ausserhalb des strukturierten Aktivitätsknotens können Vor-gänger- oder Nachfolgerknoten innerhalb des strukturierten Aktivitätskno-ten besitzen, allerdings nicht beides zugleich.

Im Unterschied zu herkömmlichen, nicht-strukturierten Knoten habenstrukturierte Aktivitätsknoten folgende Merkmale:

❑ Ein strukturierter Aktivitätsknoten bildet für seine Bestandteile ei-nen eigenen Namensraum. Damit können beispielsweise Variablenfür den strukturierten Aktivitätsknoten definiert werden, die nur in-nerhalb des Knotens sichtbar sind.

❑ Ein strukturierter Aktivitätsknoten kann zur Isolation von Aktio-nen verwendet werden. Dazu wird, falls zwei Aktionen gleichzei-tig auf ein und dasselbe Objekt innerhalb und ausserhalb des struk-turierten Aktivitätsknotens zugreifen, die Aktion ausserhalbverzögert, bis die gesamte strukturierte Aktivität in der die konkur-rierende Aktion ausgeführt wurde, beendet ist. Um dies sicherzu-stellen, muss in einer Notiz am strukturierten Aktivitätsknoten dasMetaattribut isolate auf true gesetzt werden.

Ein strukturierter Aktivitätsknoten wird als strichliertes, abgerundetesRechteck mit dem Schlüsselwort «structured» dargestellt. Darin werdendie Knoten und Kanten gezeigt, die Teile des strukturierten Aktivitätskno-tens darstellen.

UML stellt drei spezielle Formen strukturierter Aktivitätsknoten zurVerfügung, nämlich Expansionsbereiche zur Verarbeitung von Kollektio-nen, sowie Entscheidungs- und Schleifenknoten zur Realisierung von Kon-trollkonstrukten, wodurch eine kompaktere Modellierung als mit Entschei-dungsknoten möglich ist.

Expansionsbereich

Eine spezielle Form eines strukturierten Aktivitätsknotens ist ein soge-nannter Expansionsbereich, der es erlaubt, die Elemente einer eingehendenKollektion, einzeln zu verarbeiten, bzw. die Einzelelmente bei deren Aus-gabe wieder zu einer Kollektion zusammenzufügen. Dabei können unter-schiedliche Arten von Kollektionen verwendet werden, wie z.B. eine ein-fache Wertemenge, ein Multiset oder eine Liste von Werten.

Ein- und Ausgabeparameter möglich

Verknüpfung mit Knoten ausserhalb des strukturierten

Merkmale im Unterschied zu nicht-strukturierten Knoten

Namensraum für Bestandteile

Isolation konkurrierender Zugriffe

Strukturierter, isolierter Aktivitätsknoten

«structured»... ...

isolate=true

3 Arten strukturierter Aktivitätsknoten - Expan-sionsbereiche, Entschei-dungs- und Schleifenknoten

Ein Expansionsbereich (expansion region) dient zur Verarbeitung von Kollektionen


Zur Aufgliederung in die einzelnen Elemente bei der Eingabe bzw.zum Zusammenfügen bei der Ausgabe werden spezielle Objektknoten –sogenannte Expansionsknoten – verwendet. Ein Expansionsbereich kannbeliebig viele Expansionsknoten für die Ein- und Ausgabe von Kollektio-nen besitzen.

Besitzt ein Expansionsbereich mehrere eingehende Expansionsknoten,so müssen alle die gleiche Kollektionsart aufweisen. Der Typ der in denverschiedenen Kollektionen enthaltenen Elemente kann allerdings unter-schiedlich sein.

Die Anzahl der Elemente einer Kollektion bestimmt die Anzahl derAbläufe innerhalb des strukturierten Aktivitätsknotens. Dabei werden dieElemente ein und derselben Position in verschiedenen Kollektionen in ei-nem einzelnen Ablauf abgearbeitet.

Daher müssen alle eingehenden Kollektionen die gleiche Anzahl vonElementen aufweisen. Das Ergebniselement eines Ablaufs muss im Ausga-beexpansionsknoten an dieselbe Position platziert werden die auch das, dieAusführung startende Element im Eingabexpansionsknoten aufweist. DieAnzahl der Elemente der ausgehenden Kollektion kann von der Anzahl derElemente der eingehenden Kollektion abweichen, wenn z.B. ein Ablauf fürein Element der eingehenden Kollektion keine Ausgabe produziert, wo-durch der Expansionsbereich als eine Art Filter agiert.

Existieren Objektflüsse, die ausserhalb des Expansionsbereichs lie-gende Objektknoten direkt, d.h. ohne »Umweg« über einen Expansions-knoten, mit Objektknoten innerhalb des Expansionsbereichs verbinden, sowerden für diese bei jedem Ablauf die gleichen Eingabewerte zur Verfü-gung gestellt.

Für einen Expansionsbereich kann festgelegt werden, in welcher Rei-henfolge die einzelnen Abläufe abzuarbeiten sind. Dabei werden drei ver-schiedene Möglichkeiten unterschieden und durch entsprechende Schlüs-selwörter gekennzeichnet:

❑ Bei einer parallelen Abarbeitung können die einzelnen Abläufe ei-nes Expansionsbereichs parallel bearbeitet werden.

❑ Bei einer iterativen Abarbeitung werden die einzelnen Abläufe desExpansionsbereich nacheinander, gemäss der Position der Ele-mente im Eingabeexpansionsknoten, abgearbeitet. Ein Ablaufmuss vollständig beendet sein, bevor der nächste Ablauf gestartetwerden kann.

❑ Bei einer Datenstromverarbeitung werden die einzelnen Elementedes Eingabeexpansionsknotens einer Ausführung des Expansions-bereichs als Datenstrom zur einmaligen Abarbeitung zugeführt.

Ein Expansionsbereich wird gemäss der Notation strukturierter Aktivitäts-knoten als abgerundetes Rechteck mit strichlierter Linie dargestellt, das

Ein Expansionsknoten (expansion node) ist ein spezieller Objektknoten zum Aufgliedern und Zusammen-fügen von KollektionenGleiche Kollektionsart aber unterschiedliche Element-typen

Ein eigener Ablauf für alle Elemente einer bestimmten Position

Gleiche Anzahl an eingehen-den Elementen pro Kollektion - jedoch beliebig viele ausgehende Elemente

Eingehende Objektflüsse ohne Expansionsknoten

Abarbeitungsreihenfolge der einzelnen Abläufe

Parallele Abarbeitung«parallel»

Iterative Abarbeitung«iterative»

Datenstromverarbeitung«streaming»

Expansionsbereich

«parallel»

Explizite Kennzeichnung von Eingabe- und Ausgabe-expansionsknoten

224

Schlüsselwort zur Festlegung der Abarbeitungsreihenfolge der Abläufewird links oben angegeben.

Ein Expansionsknoten wird als kleines Rechteck überlappend mit denRändern des strukturierten Aktivitätsknoten dargestellt. Das Rechteck wirddurch eine beliebige Anzahl vertikaler Linien unterteilt, um eine Kollek-tion von Elementen zu symbolisiert. Die Unterscheidung in Eingabe- undAusgabeexpansionsknoten erfolgt implizit durch die eingehenden bzw.ausgehenden Objektflüsse ausserhalb des Expansionsbereichs, kann aberauch explizit, analog zu Pins, durch kleine Pfeile innerhalb der Abschnittedes Expansionsknotenrechtecks erfolgen (siehe Objektknoten als Parame-ter von Aktivitäten und Aktionen, S. 210).

Besteht der Expansionsbereich aus nur einer Aktion, so kann als Kurz-form anstatt eines strukturierten Aktivitätsknotens, ein Aktionsknoten be-nutzt werden, mit dem entsprechenden Abarbeitungsschlüsselwort und denExpansionsknoten an den Rändern.

Abbildung 4–23 zeigt einen parallelen Expansionsbereich zur Infor-mation der Teilnehmer eines Termins. Dazu wird zum Einen die Teilneh-merliste über einen Expansionsknoten an einen Eingabepin der Aktionweitergereicht und zum Anderen der fixierte Termin direkt an einen weite-ren Eingabepin übergeben.

Als Ausgabe liefert der Expansionsbereich eine Liste von benachrichtigtenTeilnehmern.

Konditionalknoten

Ein Konditionalknoten ist ein spezieller strukturierter Aktivitätsknoten, deres im Sinne einer if-then-else-Anweisung erlaubt, aus alternativen Zweigeneinen bestimmten Zweig auszuwählen. Ein Konditionalknoten stellt auf-grund seines blockorientierten Charakters das programmiersprachenspezi-fische Pendant zu einem Entscheidungsknoten dar, der aufgrund seiner ab-lauforientierten Natur eher dem Bereich der Prozessmodellierungzuzuordnen ist (siehe Entscheidungsknoten, S. 204). Gerade bei einer Viel-zahl von Alternativen bringt ein Konditionalknoten durch seine Kompakt-heit Vorteile.

Ein Konditionalknoten besteht aus ein oder mehreren Testbereichen (ifbzw. else if), die jeweils eine Alternative repräsentieren und die zur Bedin-

Expansionsbereich mit nur einer Aktion

«iterative»

AktionVariante 1:

Variante 2

«iterative»Aktion

(Kurznotation):

TerminfixierenTerminfixieren

Einladungversenden

EinladungenTeilnehmer

Termin

«parallel»TeilnehmerListe

Abb. 4–23Beispiel für einen Expansionsbereich

Ein Konditionalknoten (conditional node) dient zur Auswahl aus einer Reihe alternativer Zweige

Testbereiche (test sections) dienen zur Bedingungs-prüfung, Ausführungs-bereiche (body sections) zur Anweisungsausführung


gungsprüfung notwendigen Knoten und Kanten enthalten. DieAusführungsbereiche (then und else) eines Konditionalknotens enthaltenjene Knoten und Kanten, die bei erfüllter, bzw. im Falle eines else beinichterfüllter Bedingung, durchlaufen werden.

Damit im Testbereich mit der Bedingungsprüfung begonnen werdenkann, müssen an allen eingehenden Kanten des Konditionalknotens Tokenanliegen. Das Ergebnis der Bedingungsprüfung ist ein boolscher Wert.

Sind mehrere if-Testbereiche spezifiziert, so ist die Reihenfolge derBedingungsprüfung unbestimmt und eine einzige erfolgreiche Prüfungführt sofort zur Ausführung des entsprechenden Anweisungsteils und zumAbbruch aller übrigen Prüfungen. Ist keine der Bedingungen erfüllt, wirdder Konditionalknoten beendet ohne Ausgaben zu produzieren, es sei denndass ein else-Zweig existiert, der in diesen Fällen Abhilfe schafft.

Bei einem else if-Testbereich wird die Bedingung erst dann geprüft,wenn die Evaluierung der Bedingung des if-Testbereichs nicht erfolgreichwar. Ansonsten entspricht ein else if-Testbereich prinzipiell einem if-Test-bereich, es werden dadurch jedoch mehrere Prüfungen ineinander ge-schachtelt und damit die Reihenfolge der Prüfungen festgelegt.

Bei erfolgreicher Bedingungsprüfung wird der Ausführungsbereichgestartet, indem an allen darin enthaltenen Knoten die keine eingehendenKanten besitzen, Kontrolltoken zur Verfügung gestellt werden. Sind alledarin enthaltenen Knoten abgearbeitet, ist auch die Ausführung des Kondi-tionalknotens beendet. Werte, die im Testbereich oder im Ausführungsbe-reich generiert werden, können über Objektknoten als Ausgaben des Kon-ditionalknotens an dessen Nachfolgerknoten weitergegeben werden.

Der aktuelle UML-Standard sieht keine Notation für Konditionalkno-ten vor, dies wird voraussichtlich erst mit der UML-Version 2.1 der Fallsein. Es gab allerdings in früheren Versionen des Standards eine sehr einfa-che Notation, die sich in zahlreichen UML-Büchern wiederfindet und auchin diesem Buch zur grafischen Illustration von Konditionalknoten verwen-det werden soll. Ein Konditionalknoten wird dabei als Spezialform einesstrukturierten Aktivitätsknotens durch ein strichliertes Rechteck mit abge-rundeten Ecken dargestellt, wobei die einzelnen Bereiche durch strichlierteLinien voneinander getrennt und mit den Bezeichnungen der Testbereiche(if und else if) und der Ausführungsbereiche (then und else) versehen wer-den.

Ein Pin kann in einem Testbereich durch eine kleine Raute ausgezeich-net werden die angibt, dass dieser Pin in der Evaluierung der Bedingungverwendet wird. Wird die Raute bei einer Aktion ohne Pin verwendet,drückt dies aus, dass diese Aktion den endgültigen Wert der Bedingung be-rechnet (der jedoch nicht explizit angegeben wird).

Token starten die Bedingungsprüfung, die ein boolsches Ergebnis liefertMehrere if-Testbereiche

else if-Testbereich

Nach Abarbeitung der Knoten im Ausführungs-bereich ist die Aktivität beendet

»Inoffizielle« Notation für Konditionalknoten - Kombinationsbeispiele

thenif

thenif

else if

then

then

if

if

then

else ifthen

else

thenif

226

Schleifenknoten

Schleifen können in Aktivitätsdiagrammen durch Entscheidungsknotennur wenig intuitiv modelliert werden, sodass eine Schleife nicht immer aufden ersten Blick erkannt werden kann. Eine Alternative dazu stellt ein ei-gener Schleifenknoten dar, eine weitere spezielle Form eines strukturiertenAktivitätsknotens. Analog zu Entscheidungsknoten stellt auch der Schlei-fenknoten das programmiersprachenspezifische Pendant zu einem Ent-scheidungsknoten dar.

Ein Schleifenknoten besteht aus drei Teilbereichen - einemInitialisierungsbereich, einem Testbereich und einem Ausführungsbereich.Die Ausführung des Schleifenknotens bzw. der einzelnen Bereiche kanngestartet werden, wenn an allen eingehenen Kontroll- und Objektflusskan-ten Token anliegen. Für alle Knoten in dem jeweiligen Bereich, die keineeingehenden Kanten von ausserhalb des Bereichs aufweisen, werden auto-matisch Kontrolltoken zur Verfügung gestellt. Die Ausführung eines Be-reichs muss jeweils beendet sein (d.h. alle Knoten müssen ausgeführt sein,die keine Nachfolger im jeweiligen Bereich haben), bevor der nächste Be-reiche ausgeführt werden kann.

Der Initialisierungsbereich ermöglicht es, Aktionen auszuführen bevordie Schleife durchlaufen wird. Der Testbereich spezifiziert die Schleifen-bedingung und muss somit schlussendlich einen boolschen Wert erzeugender angibt, ob der Ausführungsbereich (erneut) durchlaufen wird. DerAusführungsbereich spezifiziert schliesslich die Aktionen, die bei jedemSchleifendurchlauf ausgeführt werden sollen.

Mit einem Schleifenknoten kann sowohl eine abweisende (while-)Schleife realisiert werden, d.h. der Testbereich wird bereits vor dem Aus-führungsbereich durchlaufen, als auch eine nicht-abweisende (do-while-)Schleife, d.h. der Testbereich wird erst nach der ersten Ausführung desAusführungsbereichs durchlaufen.

Schleifen können Schleifenvariablen aufweisen, die zunächst mit Ein-gabewerten initialisiert werden, während der Ausführung der Schleife dieaktuellen Werte der Schleifenvariablen beinhalten und am Ende derSchleife in Ausgabepins kopiert werden.

Bezüglich der Notation für Schleifenknoten gilt dasselbe wie für Kon-ditionalknoten. Gemäss der »inoffiziellen« Notation wird ein Schleifen-knoten als Spezialform eines strukturierten Aktivitätsknotens durch einstrichliertes Rechteck mit abgerundeten Ecken dargestellt, wobei die ein-zelnen Bereiche durch strichlierte Linien voneinander getrennt und mitentsprechenden Bezeichnungen für den Initialisierungsbereich -(for), denTestbereich (while) und den Schleifenrumpf (do) versehen werden.

In Abbildung 4–24 wird für die Aktivität Terminkoordination anstattder in Abbildung 4–13 verwendeten ablauforientierten Notation ein Kon-

Ein Schleifenknoten (loop node) dient zur kompakten Modellierung von Schleifen

3 Bestandteile: Initialisie-rungsbereich (setup section), Testbereich (test section), sowie Ausführungsbereich (body section)

Funktionsweise der drei Bereiche

Abweisende und nicht-abweisende Schleifen

Start des Initialisierungsbe-reichs des Schleifenknotens sobald Token anliegen

Schleifenvariablen

»Inoffizielle« Notation für Schleifenknoten

whilefor

do


ditionalknoten mit einem darin geschachtelten Schleifenknoten verwen-det.]

4.2.12 Ausnahmebehandlung und Unterbrechungsbereich

Während der Ausführung von Knoten können Ausnahmen auftreten, diedie vorgesehene Abarbeitung beeinträchtigen. Solche Ausnahmen könneneinerseits durch das Laufzeitsystem vorgegebene sein, wie zum BeispielZugriffe auf einen Feldindex ausserhalb des definierten Bereichs oder eineDivision durch Null. UML definiert allerdings nicht, welche vordefiniertenAusnahmen bei den verschiedenen Aktionen auftreten können.

Andererseits können Ausnahmen auch explizit durch den Modelliererdefiniert werden, um Situationen die vom Regelfall abweichen aufzuzei-gen. Diesem Zweck dient die vordefinierte Aktion RaiseExceptionAction.Diese empfängt als Eingabeparameter ein Objekt, dessen Typ die Aus-nahme die ausgelöst werden soll, bestimmt. Ausnahmen sind Objekte ei-nes beliebigen Modellelements, das auf einem Classifier basiert, wodurchAusnahmen z.B. in Form einer Generalisierungshierarchie organisiert wer-den können.

Tritt eine Ausnahme auf, so kann die »normale Ausführung« nichtfortgesetzt werden. Die Aktivität bzw. der strukturierte Aktivitätsknoten,der die Aktion welche die Ausnahme ausgelöst hat direkt umfasst, wird so-fort beendet. Wird hingegen eine aufgetretene Ausnahme explizit abgefan-gen und behandelt, kann danach wieder zum »normale Ablauf« zurückge-kehrt werden. Abhängig von der Art der Ausnahme, also dem Typ des


Terminnicht gefunden

do

while


Kollisionprüfen

if

then

Kollisionerkannt

Abb. 4–24Beispiel für einen Konditional- und einen Schleifenknoten

Vordefinierte Ausnahmen, beispielsweise durch das Laufzeitsystem

Benutzerdefinierte Ausnahmen - RaiseExceptionAction

Ablauf beim Auftreten einer Ausnahme

228

Ausnahmeobjekts, kann unterschiedliches Verhalten zur Behandlung derAusnahme eingebunden werden.

Eine Ausnahmebehandlung wird durch einen eigenenAusnahmebehandlungsknoten definiert, wobei ein solcher Knoten mehrereTypen von Ausnahmen behandeln kann. Ein ausführbarer Knoten (d.h.eine Aktion oder eine strukturierte Aktivität) für den eine Ausnahme defi-niert ist, wird als geschützter Knoten bezeichnet.

Tritt eine Ausnahme auf, so wird nach einem passenden Ausnahmebe-handlungsknoten gesucht. Dabei muss der Typ der Ausnahme gleich demAusnahmetyp sein der im Ausnahmebehandlungsknoten spezifiziert ist,oder aber ein Subtyp davon. Wird ein passender Ausnahmebehandlungs-knoten gefunden, so wird dieser ausgeführt, wobei das Ausnahmeobjektden Eingabeparameter darstellt.

Der Ausnahmebehandlungsknoten besitzt allerdings keine ausgehen-den Kontroll- oder Objektflüsse. Die Ergebnisse des Ausnahmebehand-lungsknotens werden nach dessen Ausführung, anstelle der Ergebnisse desgeschützten Knotens, zur Verfügung gestellt - d.h. der Ausnahmebehand-lungsknoten »substituiert« den geschützten Knoten. Die Ausführung kanndanach fortgesetzt werden.

Existiert keine entsprechende Ausnahmebehandlung für den Ausnah-metyp, so wird die betroffene Aktion beendet und die Ausnahme nach aus-sen propagiert, d.h. es wird in der umgebenden Aktivität bzw. dem umge-benden strukturierten Aktivitätsknoten nach passendenAusnahmebehandlungen gesucht. Wird trotz Propagierung bis auf dieoberste Ebene keine passende Ausnahmebehandlung gefunden, so ist dasVerhalten undefiniert.

Ein Ausnahmebehandlungsknoten wird - da es sich um einen Aktions-knoten handelt - durch ein Rechteck mit abgerundeten Ecken dargestellt.Der geschützte Knoten verweist über einen blitzartigen Pfeil auf den Aus-nahmebehandlungsknoten, wobei der Pfeil mit dem Typ der Ausnahmeversehen wird. Als Alternative kann eine herkömmliche Kante verwendetwerden, die mit einem kleinen blitzartigen Pfeil annotiert wird.

Ausnahmebehandlungsknoten werden häufig gemeinsam mitsogenannten Unterbrechungsbereichen verwendet. Ein Unterbrechungsbe-reich gruppiert Knoten und Kanten einer Aktivität, deren Ausführung ge-meinsam, z.B. durch eine Ausnahme, unterbrochen werden kann. Eine Un-terbrechung wird dabei durch das Fliessen eines Tokens über eineUnterbrechungskante angezeigt, die von einem Knoten des Unterbre-chungsbereichs zu einem ausserhalb liegenden Knoten derselben Aktivitätführt. Einem Unterbrechungsbreich können eine oder mehrereUnterbrechungskanten zugeordnet sein. Verlässt ein Token über eine Un-terbrechungskante den Unterbrechungsbereich, so werden alle Token und

Behandlung einer Ausnahme durch dezidierten Aus-nahmebehandlungsknoten (exception handler)

Finden passender Ausnahmebehandlungs-knoten

Der Ausnahmebehandlungs-knoten substituiert den geschützten Knoten und hat daher keine eigenständigen einoder ausgehenden Kanten

Propagierung von Ausnahmen

Zwei Notationsvarianten

Aktion ExceptionHandlerAusnahme

Typ

Aktion ExceptionHandler

AusnahmeTyp

Ein Unterbrechungsbereich (interruptible activity region) ist eine Gruppe von Knoten und Kanten, deren Ausfüh-rung gemeinsam unter-brochen werden kann


damit auch alle Abläufe innerhalb des Unterbrechungsbereich gelöscht,auch solche, die von verschiedenen Aufrufen stammen.

Ein Unterbrechungsbereich wird in Form eines abgerundeten Recht-ecks mit strichlierten Linien dargestellt, die Unterbrechungskante wird,wie auch bei Ausnahmen üblich, entweder durch einen »Blitz« symboli-siert oder aber durch eine herkömmliche gerichtete Kante mit einem klei-nen annotierten Blitzsymbol.

4.2.13 Aktionen

Aktionen sind, wie bereits erwähnt, die elementaren Bausteine einerbenutzerdefinierten Aktivität und dienen dem lesenden und schreibendenZugriff auf Objekte, sowie zum Aufruf anderen Verhaltens. Aktionenkönnen damit den Zustand des Systems verändern. Eine Aktion ist immereiner benutzerdefinierten Verhaltensbeschreibung - zum Beispiel einer Ak-tivität oder einer Transition in einem Zustandsdiagramm - zugeordnet undnur durch diese verfügbar. Die Verhaltensbeschreibung stellt den Kontextfür eine Aktion dar und koordiniert diese indem festgelegt wird, wann eineAktion mit welchen Eingabewerten ausgeführt wird. Damit lässt sich eineAnalogie zu Programmiersprachen ziehen, wo sich eine Prozedur aus einerReihe von elementaren Anweisungen zusammensetzt.

Aktionen sind atomar, wenngleich eine Unterbrechung einer Aktionmöglich ist. Atomarität bedeutet in diesem Fall, dass etwaige Effekte derAktion rückgängig gemacht werden, so als wäre die Aktion nie gestartetworden.

Aktionen können Eingabewerte verarbeiten, die durch den Datenflussüber Eingabepins empfangen werden, und können nach deren BeendigungAusgabewerte an den Ausgabepins zur Verfügung stellen. Werte werdendabei generell als Kopien zur Verfügung gestellt, Kopien von Objektrefe-renzen verweisen allerdings wiederum auf das Originalobjekt.

Zur Festlegung des Zeitpunkts, zu dem eine Aktion, die mehrere Aus-gabewerte erzeugt, diese zur Weiterleitung zur Verfügung stellt, gibt eszwei Optionen (es handelt sich dabei um einen semantischen Variations-punkt - siehe Kapitel 5.1.6 ab Seite 336). Entweder werden alle Ausgabe-werte einer Aktion gleichzeitig zur Verfügung gestellt sobald alle verfüg-bar sind oder jeder der Ausgabewerte wird sofort bei Verfügbarkeit zurVerfügung gestellt. In jedem Fall werden nach Beendigung einer Aktionneben den Ausgabewerten an allen ausgehenden Kontrollflusskanten derAktion Kontrolltoken angeboten.

In UML existieren eine Reihe vordefinierter, sprachunabhängiger Ak-tionen, die auf Grund ihrer Granularität einfach auf eine beliebige Ziel-sprache abgebildet werden können. Zusätzlich kann atomares Verhalten,sogenanntes OpaqueBehavior, in einer beliebigen Sprache definiert wer-

Unterbrechungsbereich mit Unterbrechungskante

Aktionen als elementare Bau-steine beliebigen benutzer-definierten Verhaltens, das den Kontext darstellt und die Aktionen

Aktionen sind atomar, können aber abgebrochen werden

Aktionen können Eingabewerte zu Ausgabewerten verarbeiten

Ein Ausgabewert kann ent-weder sofort zur Verfügung gestellt werden, oder erst nachdem alle verfügbar sind

Vordefinierte Aktionen sind sprachunabhängig, atomares Verhalten kann jedoch auch in einer belie-bigen Programmiersprache definiert werden

230

den. Beispiele dafür sind mathematische Funktionen (FunctionBehavior),die für Eingabewerte Ausgabewerte erzeugen, ansonsten aber nebeneffekt-frei sind.

Für einen Grossteil der vordefinierten Aktionen gibt es keine eigenenNotationselemente, sie werden einfach textuell innerhalb des für Aktionenüblichen Symbols angeschrieben.

Gemäss ihrer Funktion bzw. Komplexität können die in UML vordefi-nierten Aktionen in folgende Kategorien eingeteilt werden (siehe[Kath03]):

❑ Primitive Aktionen erlauben z.B. das Auslösen von Ausnahmen(siehe Ausnahmebehandlung und Unterbrechungsbereich, S. 227).

❑ Kommunikationsbezogene Aktionen umfassen die MöglichkeitObjekte und Signale an Empfängerobjekte zu übermitteln, Verhal-ten und Operationen aufzurufen und schliesslich das Auftreten ver-schiedener Arten von Ereignissen zu erkennen.

❑ Objektbezogene Aktionen umfassen Aktionen zum Erzeugen undLöschen von Objekten, zum Aufruf von Objektverhalten, zum Er-mitteln aller Objekte eines Classifiers bzw. um deren Zugehörig-keit oder Identität zu testen, sowie um das für die Ausführung einerAktion zuständige Objekt zu finden oder um ein Objekt zu reklas-sifizieren.

❑ Die Kategorie der strukturmerkmals- und variablenbezogenen Ak-tionen umfasst Aktionen zum Setzen und Löschen einzelner oderaller Werte von strukturellen Merkmalen, sowie von Variablen.

❑ Linkbezogene Aktionen ermöglichen das Erzeugen und Löschenbestimmter oder aller Links zwischen Objekten, sowie das Navi-gieren auf Basis von Links.

Im Folgenden werden die Aktionen, die diesen Kategorien angehören, nä-her erläutert, wobei auf eine detaillierte Behandlung von primitiven Aktio-nen verzichtet wird (dazu sei beispielhaft auf das Kapitel »Ausnahmebe-handlung und Unterbrechungsbereich«, S. 227 verwiesen).

Kommunikationsbezogene Aktionen

SendObjectAction und SendSignalAction erlauben ein Objekt oder ein Si-gnal und die dazugehörigen Argumentwerte an ein Empfängerobjekt zuübermitteln. Es obliegt dem Empfänger, entsprechend zu reagieren, z.B.durch Anstoßen weiteren Verhaltens. Nach der Sendetätigkeit wird die Ak-tion beendet und mit den nachfolgenden Aktionen der Aktivität fortgesetzt.Die Kommunikation erfolgt asynchron, eventuelle Antworten des Empfän-gers werden vom Aufrufer ignoriert. Als Notationselement kann für beideAktionsarten ein Blockpfeil verwendet werden.

Spezielle Notation für be-stimmte Aktionsarten selten

Kategorisierung der in UML vordefinierten Aktionen

Primitive Aktionen

Kommunikationsbezogene Aktionen

Objektbezogene Aktionen

Strukturmerkmals- und variablenbezogene Aktionen

Linkbezogene Aktionen

SendObjectAction und SendSignalAction erlauben das Versenden von Objekten bzw. Signalen an bestimmte Empfänger

SignalType

InformiereTeilnehmer


Während eine SendSignalAction dazu dient, eine Signalinstanz zu er-zeugen und an einen bestimmten Emfänger zu übermitteln, dient eineBroadcastSignalAction dazu, eine Signalinstanz an eine Reihe beliebigerEmpfänger zu übermittlen. UML gibt dabei nicht vor, ob und wie dieMenge der Signalempfänger eingeschränkt werden kann.

CallBehaviorAction und CallOperationAction werden verwendet, um be-liebiges Verhalten aufzurufen. Dies kann entweder im objektorientiertenSinn erfolgen, d.h. indirekt über den Aufruf der Operation eines Objekts(CallOperationAction) oder aber indem durch CallBehaviorAction unab-hängig von einem Objekt, ein eigenständiges Verhalten aufgerufen wird.Die beiden Aufrufaktionen stellen demnach eine Indirektionsstufe dar,durch die die Definition einer Verhaltensbeschreibung von deren Verwen-dung explizit getrennt wird, was zu einer Erhöhung der Wiederverwend-barkeit führt.

Die vom eingebundenen Verhalten benötigten Parameter müssendurch die Eingabepins der Aktion zur Verfügung gestellt werden, wobeidie Zuordnung implizit über die Reihenfolge von Pins und Parametern er-folgt. Ebenso werden Rückgabewerte, die nach Beendigung des aufgerufe-nen Verhaltens verfügbar sind, in den Ausgabepins der aufrufenden Aktionzur weiteren Verarbeitung bereitgestellt. Schliess-lich kann ein Aufruf ent-weder synchron mit Rückgabewerten oder asynchron und damit ohneRückgabewerte erfolgen.

Als Notation für eine CallBehaviorAction wird innerhalb einesabgerundeten Rechtecks der Name des aufgerufenen Verhaltenseingetragen, sowie durch ein »Rechensymbol« in der rechten unteren Eckeder Aufruf eines anderen Verhaltens im Sinne einer Dekompositionsymbolisiert. Für eine CallOperationAction gibt es drei verschiedeneNotationsvarianten. Zum Einen kann der Operationsname direkt in dasabgerundeten Rechteck hineingeschrieben werden, wobei optional inrunden Klammern der entsprechende Klassenname, gefolgt von einemdoppelten Doppelpunkt angegeben werden kann. Zum Anderen kann aberauch der Knoten, der die CallOperationAction repräsentiert, einen anderenNamen als die Operation aufweisen, wobei der eigentlicheOperationsname hinter dem Klassennamen angegeben wird.

Mit AcceptEventAction kann das Auftreten asynchroner Nachrichten undAufrufe erkannt werden, z.B. ein Signal, das durch SendSignalActiongeneriert wurde. Der Typ der zu erkennenden Ereigniseintritte wird derAktion über einen sogenannten »Trigger« zugeordnet. Prinzipiell werdenEreigniseintritte von jenen Objekten erkannt, die das entsprechende Ver-halten besitzten und auch bei diesen gespeichert. Wird AcceptEventActiondurch Anliegen entsprechender Token gestartet und liegt bereits ein pas-sendes Ereignis vor, so wird eine Beschreibung des Ereignisses an den aus-

BroadcastSignalAction erlaubt das Versenden von Signalen an beliebige Empfänger

CallBehaviorAction und CallOperationAction ermög-lichen den Aufruf von stand-alone-Verhalten bzw. von Operationen eines Objekts

Ein- und Ausgabeparameter für das aufgerufene Verhalten, sowie synchroner und asynchroner Aufruf

CallBehaviorActionVerhaltens-

name

Operations-CallOperationAction

nameOperations-

name(Klassenname::)

Knotenname(Klassenname::

Operationsname)

AcceptEventAction erkennt asynchrone Ereignisse und gibt diese zurück

232

gehenden Kanten zurückgegeben, liegt kein passendes Ereignis vor, wirdgewartet.

Als Notationselement für eine AcceptEventAction wird ein Rechteckmit einer Einkerbung verwendet, das keine eingehenden Kanten aufweisendarf. AcceptEventAction kann auch für absolute oder relative Zeitereig-nisse verwendet werden, wobei als Notation in diesem Fall eine Sanduhrverwendet wird.

AcceptCallAction ist eine spezielle AcceptEventAction, mit der Ereig-niseintritte, die synchrone Operationsaufrufe repräsentieren, behandeltwerden können. Die bei einem Aufruf durch CallOperationAction zur Ver-fügung gestellten Parameter sind als Ausgaben dieser Aktion verfügbar.

ReplyAction ermöglicht es nach einer AcceptCallAction die Kontrollewieder an den Aufrufer zurückzugeben und so die Ausführung des Aufrufszu beenden. Als Eingabeparameter erhält die ReplyAction die»Rückkehrinformation«, die als Ausgabe der AcceptCallAction zur Verfü-gung steht. Die vom Aufrufer geforderten Rückgabewerte müssen als Ein-gabewerte an die ReplyAction übergeben werden.

Objektbezogene Aktionen

Durch eine CreateObjectAction kann ein neues Objekt eines bestimmtenClassifiers erzeugt werden. Dabei wird jedoch keine Initialisierung durch-geführt, sodass dieses Objekt weder Werte noch Beziehungen zu anderenObjekten aufweist. Der Classifier der als Eingabeparameter der Aktionmitgegeben wird, darf weder abstrakt, noch eine Assoziationsklasse sein.Das neue Objekt steht als Ausgabeparameter zur Verfügung.

Durch DestroyObjectAction kann ein Objekt das der Aktion als Einga-beparameter übergeben wird zur Laufzeit gelöscht werden. Ist das Objektselbst ein Link, so wird automatisch auch eine DestroyLinkAction (sieheweiter unten) ausgeführt. Durch Kompositionsbeziehung verbundene Ob-jekte können optional mitgelöscht werden (kann durch das MetaattributisDestroyOwnedObjects festgelegt werden). Dasselbe gilt für Links die dasObjekt zu anderen Objekten aufweist (isDestroyLinks).

Das Verhalten eines Objekts kann explizit mitStartClassifierBehaviorAction gestartet werden. Die Aktion benötigt dazuein Objekt als Einabeparameter, für dessen Classifier Verhalten definiertist. Wurde das betreffende Verhalten bereits initiert, so hat diese Aktionkeine Auswirkungen.

Alle Objekte eines Classifiers (seine »Extension«), können durchReadExtentAction ermittelt werden.

Die Zugehörigkeit eines Objekts zu einem Classifier kann mit Hilfe derAktion ReadIsClassifierObjectAction überprüft werden. Das zu überprü-

AsynchronesZeitereignis

Terminbestätigt

Monats-Ende

AsynchronesEreignis

AcceptCallAction zur Behandlung synchroner Ereignisse

ReplyAction ermöglicht die Rückkehr zum Aurufer und die Beendigung des Aufrufs

CreateObjectAction erzeugt ein Objekt eines Classifiers

DestroyObjectAction löscht ein Objekt eines Classifiers

StartClassifierBehaviorAction startet das Verhalten eines Objekts eines Classifiers

ReadExtentAction ermittelt die Extension eines

ReadIsClassifierObjectAction überprüft die Zugehörigkeit eines Objekts zu einem bestimmten


fende Objekt sowie der Classifier werden dabei der Aktion als Eingabepa-rameter mitgegeben, das Ergebnis ist ein boolscher Wert. Standardmässigwird geprüft, ob das Objekt direkte oder indirekte Instanz des Classifiersist, was jedoch auf eine direkte Zugehörigkeit (isDirect) eingeschränktwerden kann.

Durch TestIdentityAction kann geprüft werden, ob zwei Objekte ident sind.

Mit der Aktion ReadSelfAction kann eine Aktivität bestimmen, welchesObjekt zur Laufzeit eine bestimmte Aktion ausführt. Dies setzt voraus,dass die Aktivität einem Classifier zugeordnet ist. Ist die Aktivität die Me-thode einer Operation, so darf diese nicht statisch sein.

Die Klassifizierung eines Objekts, d.h. dessen Zuordnung zu Classifiern,kann zur Laufzeit mit ReclassifyObjectAction geändert werden, wobei so-wohl die Identität des Objekts als auch eventuell existierende Werte undLinks gewahrt bleiben. Mit Hilfe dieser Aktion können dem Objekt einoder mehrere neue Classifier hinzugefügt werden, wobei standardmässigdie existierenden Klassifizierungen erhalten bleiben. Dieses Standardver-halten kann jedoch geändert werden (isReplaceAll). Ein neu hinzuzufügen-der Classifier darf nicht abstrakt sein und das Objekt muss letztendlich zu-mindest einem Classifier zugeordnet sein.

Strukturmerkmals- und variablenbezogene Aktionen

Die Aktionen AddStructuralFeatureValueAction erlaubt es einem struktu-rellen Merkmal, z.B. einem Attribut, neue Werte hinzuzufügen, wobeistandardmässig alte Werte erhalten bleiben (änderbar durch isReplaceAll).Da ein strukturelles Merkmal mehrwertig und geordnet sein kann, stelltdiese Aktion einen weiteren Eingabeparameter zur Verfügung, durch denin Form eines positiven Ganzzahlwertes die Position angegeben werdenkann, an der ein neuer Wert eingefügt werden soll (insertAt). Wird durchdie Aktion eine allfällige Multiplizitätseinschränkung des strukturellenMerkmals verletzt oder ist dieses als schreibgeschützt ausgewiesen, so istdie Semantik undefiniert. Analoges gilt für die AktionAddVariableValueAction in Bezug auf Variablen.

Sollen alle Werte eines strukturellen Merkmals gelöscht werden, so kanndies in einem Schritt durch ClearStructuralFeatureAction erfolgen. EinUnterschreiten der festgelegten Multiplizität wird dabei nicht überprüft. Istdas strukturelle Merkmal schreibgeschützt oder dürfen nur Werte hinzuge-fügt werden, so ist die Semantik dieser Aktion nicht definiert. Analogesgilt für die Aktion ClearVariableValueAction in Bezug auf Variablen.

Das gezielte Entfernen eines Werts eines strukturellen Merkmals oder ei-ner Variablen ist durch RemoveStructuralFeatureValueAction bzw.

TestIdentityAction überprüft zwei Objekte auf Identität

ReadSelfAction erlaubt die Bestimmung des Objekts, das eine Aktion ausführt

ReclassifyObjectAction ermöglicht die Reklassifi-zierung von Objekten

AddStructuralFeatureValue-Action und AddVariable- ValueAction erlauben das Setzen neuer Werte, bei Bedarf auf Basis von Positionsangaben

ClearStructuralFeatureValue-Action und ClearVariableValueAction erlauben das Löschen aller existierenden Werte

RemoveStructuralFeature ValueAction und RemoveVariableValueAction erlauben das Löschen bestimmter existierender Werte

234

RemoveVariableValueAction möglich, wobei eine entsprechende Positionangegeben werden muss (removeAt). Als weitere Option kann festgelegtwerden, dass beim Löschen eines Werts auch alle Duplikate entfernt wer-den (isRemoveDuplicates).

Linkbezogene Aktionen

Links zwischen zwei Objekten können durch CreateLinkAction erzeugtwerden. Weist die zugehörige Assoziation eine Assoziationsklasse auf,muss CreateLinkObjectAction zur Erzeugung des entsprechenden Linkob-jekts verwendet werden. Als Option kann für jede der zu erstellenden En-den des Links angegeben werden, ob bereits existierende Enden entferntwerden sollen. Bei geordneten Beziehungen kann eine Einfügeposition(insertAt) angeben werden.

Eine DestroyLinkAction löscht Links zwischen Objekten, sowie etwaigeLinkobjekte. Existieren Links zwischen gleichen Objekten mehrfach, sokann festgelegt werden, dass diese ebenfalls gelöscht werden(isDestroyDuplicates). Sind die Links geordnet, kann der zu löschendeLink über eine Positionsangabe (destroyAt) spezifiziert werden.

Sollen alle Links einer Assoziation an denen ein Objekt teilnimmt ge-löscht werden, so kann dies durch ClearAssociationAction erfolgen. DasObjekt, sowie die betreffende Assoziation repräsentieren die Eingabepara-meter der Aktion.

Schliesslich erlauben drei verschiedene Aktionen das Navigieren entlangvon Links, um ein entsprechendes Zielobjekt zurückzugeben. BeiReadLinkAction kann von einem Ausgangsobjekt zu einem Zielobjekt na-vigiert werden, wobei die zugehörigen Assoziationsenden, sowie die Aus-gangsobjekte als Eingabeparameter angegeben werden. Bei n-ären Bezie-hungen müssen alle beteiligten Objekte als Eingabeparameter übergebenwerden, mit Ausnahme des Zielobjekts der Navigation.

Bei ReadLinkObjectEndAction und ReadLinkObjectEndQualifierAction erfolgt die Navigation von einem Linkobjekt aus zu einemZielobjekt ohne bzw. mit Nutzung eines entsprechenden Qualifikators.

CreateLinkAction und CreateLinkObjectActionzur Erzeugung eines Links einer Assoziation ohne/mit Assoziationsklasse

DestroyLinkAction löscht bestimte Links und Linkobjekte

ClearAssociationAction löscht alle Links einer Assoziation eines Objekts

ReadLinkAction zur Navi-gation von einem beliebigen Objekt zu einem Zielobjekt

ReadLinkObjectEndAction und ReadLinkObjectEnd- QualifierAction zur Naviga-tion von einem Linkobjekt zu einem Zielobjekt ohne/mit Qualifikator

4 2 Aktivitätsdiagramm

Documents

Transcript of 4 2 Aktivitätsdiagramm