UML 2: AKTIVITÄTEN UND AKTIONEN

Transkript

1 mehr zum thema: von conrad bock UML 2: AKTIVITÄTEN UND AKTIONEN der autor Im Sommer 2003 wurde die Spezifikation der UML 2 von der OMG angenommen. Derzeit werden die offenen Punkte geklärt und Mitte 2004 sollen die Arbeiten an der Spezifikation abgeschlossen sein. Die Aktivitätsdiagramme wurden in der neuen Version komplett überarbeitet worden. Ihre vielfältigen Einsatzmöglichkeiten machen sie zu einer der wichtigsten Diagrammformen der UML. Im JOT Magazin hat Conrad Bock eine Artikelreihe über die neuen UML-2-Aktivitäten und -Aktionen veröffentlicht. Der erste Teil wurde für OBJEKTspektrum aus dem Englischen übersetzt. Conrad Bock ( conrad.bock@nist.gov) ist IT- Spezialist am National Institute of Standards and Technology in den USA. Seine Schwerpunkte liegen im Bereich Prozessmodelle und Ontologien. Er ist Leiter der Arbeitsgruppe zu den Aktivitäten und Aktionen der UML 2. Dies ist der erste Artikel einer im Journal of Object Technology 2003 erschienen Reihe über das Aktivitätsmodell der Unified Modeling Language Version 2 (UML 2) und die Integration des Aktionsmodells (vgl. [U2P03]). Die Reihe begleitet den Standard mit Hintergrund- und Basisinformationen und Beispielen und führt die Konzepte in einer logischen Reihenfolge ein. Dieser Artikel stellt die Motivation und Architektur der neuen Modelle dar, zeigt Grundlagen der UML 2 Aktivitäten und Aktionen und erklärt die Idee des Verhaltens in der UML 2. Hintergrund Bei den neuesten Entwicklungen in der UML lag der Fokus unter anderem auf der Unterstützung von Prozeduren und Prozessen. In der UML 1.5 wurde mit der Kontroll- und Datenflusssemantik ein Modell für parametrisierbare Prozeduren eingeführt. Das Modell ergänzt die vorhandenen Zustands- und Interaktionsmodelle (vgl. [OMG03]). Damit unterstützte die UML zum ersten Mal vollwertige Prozeduren, die als Methoden in Objekten oder auch alleine stehend, z.b. zur Modellierung von Funktionsbibliotheken, verwendet werden können. Die Neuerungen ermöglichten auch den Einsatz der UML für Benutzer, die noch keine Objektorientierung verwenden (beispielsweise Systemingenieure oder Geschäftsprozessmodellierer), und eröffneten ihnen einen Weg, objektorientierte Konzepte inkrementell zu adaptieren. Mit der Flexibilität, objektorientierte und funktionale Ansätze zu kombinieren, wurden die Einsatzmöglichkeiten der UML erweitert. Die UML 1.5 enthält, wie auch ihre Vorgängerversionen, Aktivitätsdiagramme. Sie sind eine spezielle Art von Zustandsdiagramm, um Abläufe darzustellen. Leider schränkt die zu Grunde liegende Semantik der Zustandsdiagramme die Ausdrucksmöglichkeiten ein und wirkt verwirrend für den Anwender. Insbesondere die Anwender, die keinen objektorientierten Ansatz verfolgen, halten die Aktivitätsdiagramme der UML 1.x für ungeeignet. Es gibt auch Bedenken, da die UML 1.5 mehrere Modelle für Kontroll- und Datenfluss hat. Im Hinblick auf diese Erfahrungen wur- de das Aktivitätsmodell der UML 2 überarbeitet. Es basiert nun auf einer ablauforientierten Semantik und integriert das Aktionsmodell der UML 1.5. Das neue Modell unterstützt die Kontroll- und Datenflusssemantik der UML-1.5-Prozeduren sowie weitere allgemeine Eigenschaften, wie z. B. Schleifen und Warteschlangen. Das Aktivitätsmodell der UML 2 unterstützt die Ablaufmodellierung in vielen Bereichen, sowohl für systembasierte als auch für manuelle Abläufe. Somit ist die UML 2 geeignet für die Spezifizierung von Systemen, unabhängig davon, wo die Systemgrenze liegt und ob die Implementierung Hard- oder Software ist. Die Kombination von Aktivitäten und Aktionen erhält die Fähigkeit der UML 1.x, auf Ereignisse zu reagieren. Diese Eigen- Abb. 1: Paketabhängigkeiten des UML-Aktivitätsmodells

2 schaft wird beispielsweise für den Einsatz in eingebetteten Systemen benötigt. Anwendungen Obwohl die UML 2 Aktivitäten und Aktionen unabhängig von speziellen Anwendungsgebieten definiert, sind einige Eigenschaften für bestimmte Domänen besser geeignet als andere. Beispielsweise werden Aktionen für Ausnahmebehandlungen (Exceptions) eher von Programmierern verwendet werden, während Geschäftsprozessmodellierer mehr Techniken für spezielle Abläufe, wie z. B. Ausnahmeparameter und unterbrechbare Aktivitätsbereiche, einsetzen werden. Diese Redundanz ist unvermeidbar, wenn man eine Abstraktion über mehrere disjunkte Anwendergruppen erstellt. Jedoch ist es sehr von Vorteil in der Kommunikation, wenn verschiedene Bereiche eines Systems auf einem gemeinsamen Modell beruhen. Um Tool-Hersteller für spezielle Anwendergruppen zu unterstützen, ist die Paketstruktur des Aktivitätsmodells granularer als die der anderen Verhaltensmodelle der UML und hat komplexere Abhängigkeiten, wie Abbildung 1 zeigt. Die Basis des Aktivitätsmodells bilden die Eigenschaften, die alle Anwendungsgebiete gemeinsam haben: das abstrakte Konzept der Aktionen, Kontroll- und Datenfluss sowie Ein- und Ausgaben. Hiervon ausgehend verzweigen die Paketabhängigkeiten in zwei Richtungen: eine vorwiegend für die Softwaremodellierung (StructuredActivities) und die andere für die allgemeine Prozessmodellierung (IntermediateActivities und CompleteActivities). Das Paket StructuredActivities definiert Strukturen für bedingte Abläufe, Variablen, Ausnahmebehandlungen usw. IntermediateActivities und CompleteActivities definieren Strukturen für Nebenläufigkeit, Partitionen, eine ablaufbasierte Form für Ausnahmen und weitere Konstrukte zur detaillierten Ablaufmodellierung. Beide Zweige sind orthogonal zueinander, d. h. sie können auch miteinander kombiniert verwendet werden. Beispielsweise ermöglicht die Kombination von 1 ) Das Aktionsmodell müsste fein granular paketiert sein, um mit dem Aktivitätsmodell zu korrespondieren. Derzeit ist es aber nur in die Pakete IntermediateActions und CompleteActions unterteilt. Diese enthalten vordefinierte Aktionen zum Erstellen von Objekten, Setzen von Attributen usw. Der abstrakte Kern der Aktionen ist im Paket BasicActivities definiert, da es fester Bestandteil des Ablaufmodells ist. Abb. 2: Knoten StructuredActivities und Intermediate- Activities die gemeinsame Verwendung von bedingten Abläufen und Nebenläufigkeit 1 ). Die Artikelreihe in [JOT] beschäftigt sich mit den Eigenschaften der einzelnen Pakete. Die Unterstützung einer großen Bandbreite von Anwendungsgebieten erfordert unterschiedliche Notationsmöglichkeiten. Beispielsweise bevorzugen Programmierer textuelle Notationen, während Fachanalytiker lieber grafische Notationen verwenden. Die UML unterstützt diese Anforderung, da das Modell in einem Repository gespeichert wird, das von unterschiedlichen Notationen verwendet werden kann. Programmierer können eine textuelle Notation benutzen, um Aktivitätsmodelle im Repository zu lesen oder zu erstellen, und Geschäftsprozessmodellierer können eine grafische Notation wählen. Das UML-Repository ist ein Kommunikationsmedium zwischen verschiedenen Notationen und Ausgangspunkt für Compiler (vgl. [Boc03]). Ablaufmodelle Verhaltensmodelle beschreiben, wann ein Verhalten ausgeführt wird und welche Daten dazu erforderlich sind (vgl. [Boc99]). Die Aktivitätsmodelle UML 2 entsprechen klassischen Kontroll- und Datenflusskonzepten. Ein Verhalten wird ausgeführt, wenn ein anderes Verhalten beendet wurde und die Eingangsdaten vorhanden sind. Typischerweise visualisieren Anwender von Kontroll- und Datenflussmodellen das Laufzeitverhalten, indem sie sich vorstellen, das sich Kontrollund Dateneinheiten entlang der Linien bewegen. Entsprechend eignet sich für diese Anwender die Token-Flusssemantik der Petrinetze, wobei Token ein allgemeiner Ausdruck für Kontroll- und Dateneinheiten ist. Die UML 2 verwendet wie die UML 1.x virtuelle Maschinen zur Beschreibung der Semantik von Verhaltensmodellen. Das ermöglicht es Anwendern und Werkzeugherstellern das Laufzeitverhalten der Modelle vorherzusagen. In UML 2 definieren Aktivitäten eine virtuelle Maschine auf Basis von Regeln, die beschreiben, wie sich Token durch ein Diagramm aus Knoten und Kanten bewegen. Jeder Knoten und jede Kante definiert, wie Token sich an ihnen entlang bewegen dürfen. Die Summe aller Regeln beschreibt das Verhalten des gesamten Diagramms 2 ). Die Token-Flussregeln beschreiben nur das Laufzeitverhalten, d. h. wann ein Verhalten mit welchen Daten ausgeführt wird. Es werden keine weiteren Vorgaben für die Implementierung definiert. Insbesondere geben die Regeln nicht vor, das Aktivitätsmodelle als virtuelle Maschinen entsprechend der Token-Analogie implementiert werden müssen. Es ist lediglich erforderlich, dass in der Implementierung das Laufzeitverhalten auftritt, das von der virtuellen Maschine vorgegeben wird. Knoten und Kanten UML-2-Aktivitäten sind Ablaufdiagramme bestehend aus Knoten, die mit Kanten verbunden sind. Kontroll- und Dateneinheiten bewegen sich entlang der Kanten und werden in den Knoten verarbeitet, zu anderen Knoten geschickt oder temporär gespeichert. Es gibt drei Arten von Knoten: Aktionsknoten verarbeiten empfangene Kontroll- und Dateneinheiten und geben Einheiten zu anderen Aktionen. Kontrollknoten leiten Kontroll- und Dateneinheiten durch das Diagramm. 2 ) Die Regeln sind hoffentlich ausreichend präzise, um in eine formale Semantik übersetzt werden zu können. Damit könnten modellierte Prozesse überprüft werden. Dies ist ein noch offener Punkt für zukünftige Arbeiten. 4/2004

3 Abb. 3: Kanten Es sind Elemente, um zwischen alternativen Abläufen zu entscheiden (Entscheidungsknoten), um mehrere parallele Abläufe zu starten (Splitting), usw. Objektknoten halten temporär Dateneinheiten, während sie warten, um sich weiter durch das Diagramm zu bewegen. Abbildung 2 zeigt Notationen für einige Knoten, die hier besprochen werden. Trotz des Namens können Kontrollknoten sowohl den Daten- als auch den Kontrollfluss im Diagramm koordinieren und Objektknoten können Objekte und Daten enthalten 3 ). Die Knoten werden mit zwei verschiedenen Arten gerichteter Kanten verbunden: Spätere Artikel in [JOT] behandeln andere Arten von Knoten und weitere Eigenschaften von Aktionen und Kanten. Aktionen Aktivitätsmodelle koordinieren Aktionen. Einige Aktionen rufen anwenderdefiniertes Verhalten auf, insbesondere andere Aktivitäten. Alle Aktionen sind vordefiniert. UML 2 spezifiziert beispielsweise Aktionen, um Objekte zu erzeugen, Attributwerte zu setzen, Objekte miteinander zu verbinden und um anwenderdefiniertes Verhalten aufzurufen. Aktionen können Ein- und Ausgabeparameter so genannte Pins haben. Pins werden mit Objektflusskanten verbunden, um darzustellen, wie Objekte und Daten durch die Aktivität fließen, die von Aktionen ausgegeben oder aufgenommen werden. Im einfachsten Fall sind alle Eingabeparameter einer Aktion erforderlich, damit die Aktion ausgeführt werden kann. in Abbildung 4 sind Ein- und Ausgabe- Pins. Neben dem Pin-Symbol steht der Typ der Objekte, die als Eingabe akzeptiert bzw. als Ausgabe zurückgegeben werden. Die Notation im unteren Teil von Abbildung 4 kann verwendet werden, wenn Ein- und Ausgabetyp identisch sind. Pins sind Objektknoten, d. h. sie speichern temporär Daten des Ablaufes. Wie bereits erwähnt, ist es nicht zwingend notwendig, die Notation aus Abbildung 4 zu verwenden. Programmierer bevorzugen häufig eine textuelle Notation (vgl. [Boc03]), wie z. B.: Bestellung b; b = new Bestellung; BestellungAusfuellen(b); Das Repository-Modell der UML 2, wie in Abbildung 5 gezeigt, ist für beide Notationen dasselbe (unter der Annahme, dass die Variable der textuellen Notation als Datenfluss modelliert ist 5 ). Jedes Element Kontrollflusskanten verbinden Aktionsknoten und spezifizieren, dass die Aktion, auf die die Kante zeigt, nicht ausgeführt werden kann, bevor die vorherige Aktion beendet ist. Entlang einer Kontrollflusskante können sich nur Kontroll-Token bewegen. Objektflusskanten verbinden Objektknoten, um Aktionen Parameter zu übergeben. Entlang einer Objektflusskante können sich nur Objektund Daten-Token bewegen. Abbildung 3 zeigt Notationen für Kanten. Kontroll- und Objektflusskanten werden anhand ihrer Verwendung unterschieden. Kontrollflusskanten verbinden direkt Aktionsknoten, während Objektflusskanten Ein- und Ausgangsparameter von Aktionen verbinden (siehe nächster Absatz). Im Folgenden stellt der Artikel Aktionen und Kanten mit kleinen Beispielen vor. 3 ) Die UML abstrahiert Daten und Objekte in der Metamodellklasse Classifier. Abb. 4: Aktionen und Objektfluss Abbildung 4 zeigt das Beispiel einer Aktion, die ein neues Exemplar der Klasse Bestellung erzeugt, und eine weitere Aktion, die anwenderdefiniertes Verhalten aufruft, um das Exemplar Bestellung auszufüllen. Die Objekterzeugungsaktion erstellt ein leeres Bestellungsexemplar, das von Bestellung ausfüllen vervollständigt wird. Aktionsknoten werden durch Rechtecke mit abgerundeten Ecken notiert 4 ). Die kleinen Rechtecke an den Aktionsknoten 4 ) Der Name im Aktionsknoten ist nicht normativ. Eine textuelle Standardnotation für Aktionen ist bisher nicht aufgenommen. Vor allem können Aktionsknoten Namen bekommen, die aussagekräftiger als die vordefinierten Aktionsnamen sind. Die Notation wird unglücklicherweise ebenfalls in Zustandsdiagrammen für Zustände verwendet. Das ist keine wünschenswerte Situation. Es ist jedoch für diejenigen Anwender von Vorteil, die mit Zustandsdiagrammen versuchen, Ablaufmodellierung zu betreiben, da es bis jetzt hierfür keinen anderen Standard gab. des Repositorys ist Exemplar einer Metaklasse der UML-Spezifikation, deren Name rechts vom Doppelpunkt steht. Links vom Doppelpunkt steht der Name des Repository-Exemplars. Dieser wird weggelassen, wenn es sich um ein anonymes Exemplar handelt. Das Modell zeigt eine CreateObjectAction mit einem Ausgabe-Pin, dessen Daten zum Eingabe-Pin der CallBehaviorAction gereicht werden. CreateObjectAction ist mit der anwenderdefinierten Klasse Bestellung und CallBehaviorAction mit dem anwenderdefinierten Verhalten Bestellung ausfüllen verbunden. Die elementaren Aktionen, um Objekte zu erzeugen, anwenderdefiniertes Verhalten aufzurufen usw. sind keine techni- 5 ) UML 1.5 und UML 2 unterstützen auch Variablen

4 Abb. 5: Repository-Modell der Abbildung 4 sche Implementierung, sondern Artefakte der Metamodellierung. Um unterschiedliche Verwendungen derselben Spezifikation zu unterstützen, wird zwischen der Spezifikation des Verhaltens und seiner Implementierung unterschieden. Beispielsweise kann dasselbe Verhalten Bestellung ausfüllen in unterschiedlichen Aktivitätsdiagrammen oder mehrfach im gleichen Aktivitätsdiagramm aufgerufen werden. Aber jeder Aufruf wird durch ein eigenes Exemplar von CallBehaviorAction im Repository repräsentiert, die alle dasselbe Verhalten referenzieren. Jede Verwendung von Bestellung ausfüllen befindet sich in unterschiedlichen Abläufen oder an verschiedenen Positionen im selben Ablauf, d.h. jede Verwendung kann verschiedene Vorgänger- und Nachfolgeraktionen haben. Zum Beispiel ist in Abbildung 5 CreateObjectAction Vorgänger von Bestellung ausfüllen, während es in anderen Abläufen nicht der Fall sein muss 6 ). Aktionen sind auch wiederverwendbar, aber das wird anders modelliert als anwenderdefiniertes Verhalten. Jede Aktion in einem Ablauf ist ein neues Exemplar einer Klasse des UML-Metamodells. Wenn zum Beispiel eine Aktivität zwei Aktionen zur Erzeugung eines Objekts enthält, dann enthält das Repository zwei Exemplare der Klasse CreateObjectAction des UML-Metamodells mit jeweils verschiedenen Pins. Wiederverwendung ist dadurch gegeben, dass die Aktionen Exemplare derselben UML-Metaklasse sind. Aktivitäten Aktivitäten sind anwenderdefiniertes Verhalten. Wie jedes Verhalten in der UML 2 können sie durch Aufrufaktionen gestartet werden und unterstützen Parameter, um Daten aufzunehmen oder an den Aufrufer zurückgeben. Die Parameter sind Teil der wiederverwendbaren Definition einer Aktivität. Aktivitätsparameter sind keine Pins. Pins werden zum Verknüpfen von Aktionen in einem Ablauf verwendet. Eine Aktivität ist ein Verhalten, das von Aktionen aufgerufen wird (siehe oben). Damit die Aktionen einer Aktivität auf die Parameterwerte zugreifen können, sind Aktivitätsparameter als eine spezielle Form der Objektknoten modelliert. Sie können temporär die vorhandenen Parameterwerte, die von der Aktivität aufgenommen bzw. zurückgegeben werden, speichern. Abbildung 6 zeigt eine parametrisierbare Aktivität mit einem Parameterobjektknoten, der mit dem Pin einer Aktion verbunden ist. Parameterobjektknoten werden auf den Rahmen einer Aktivität notiert. Objektflusskanten verbinden sie mit Pins. Normalerweise wird der Typ der Objekte, die im Objektknoten gespeichert werden, als Name notiert. In diesem Beispiel wurden die Daten zum Ausfüllen der Bestellung als Eingabeparameter modelliert und werden dem Aufruf des Verhaltens Bestellung ausfüllen übergeben. Die Kontrollknoten am Anfang und am Ende des Ablaufs in Abbildung 6 sind Start- und Endknoten. Sobald die Aktivität Bestellung ausfüllen aufgerufen wird, wird ein Kontroll-Toke auf dem Startknoten und ein Daten-Token mit Bestellinformationen auf dem Eingabeparameter-Objektknoten platziert. Der Kontroll-Token fließt zur Aktion Bestellung erzeugen, die damit gestartet wird. Der Daten-Token fließt zur Aufrufaktion Bestellung ausfüllen, die noch auf das Ende der Aktion Bestellung erzeugen warten muss, um die anderen Eingabedaten zu erhalten. Wenn die Aktion Bestellung ausfüllen beendet ist, fließt ein Kontroll-Token zum Endknoten, der damit die Aktivität terminiert und die Kontrolle dem Aufrufer der Aktivität zurückgibt. Ein Ausschnitt des Repository-Modells der Aktivität aus Abbildung 6 ist in Abbildung 7 zu sehen. Es ist mit dem Repository-Modell in Abbildung 5 über die CallBehaviorAction cb1 verbunden. Die Aktion Bestellung erzeugen und ihr Ablauf wurde der Einfachheit halber weggelassen. Verhalten in der UML 2 Die UML 2 unterstützt das Konzept des parametrisierbaren Verhaltens für alle Arten von Verhalten, nicht nur für Aktivitäten. Das heißt Zustandsauto- 6 ) Programmiersprachen machen dieselbe Unterscheidung zwischen Deklaration einer Prozedur und Aufruf mit aktuellen Parameterwerten. In UML 2 gesprochen ist die Prozedurdeklaration ein Verhalten und der Aufruf eine Aktion. Abb. 6: Beispiel Aktivität 4/2004

5 Abb. 7: Teil des Repository-Modells aus Abbildung 6 maten, Interaktionen und Aktivitäten können parametrisiert werden. Sie können Methoden von Objekten sein oder direkt aufgerufen werden. Oben rechts in Abbildung 8 sieht man ein Aktivitätsmodell für das Verhalten Post austragen (der gebogene Pfeil ist keine besondere Notation). Post austragen kann mit einer CallBehaviorAction oder als eine Methode der Klasse Postmitarbeiter mit einer CallOperationAction aufgerufen werden. In beiden Fällen enthält das Verhalten ein Exemplar der Klasse Schlüssel als Eingabe. Da Verhalten sowohl direkt als auch als Operation aufgerufen werden kann, eröffnet die UML 2 einen Weg, Objektorientierung inkrementell einzusetzen (vgl. [Boc99]). Anwenderdefiniertes Verhalten in der UML 2 sind auch Klassen. Immer wenn zur Laufzeit ein Verhalten ausgeführt wird, wird ein neues Exemplar der Klasse des anwenderdefinierten Verhaltens erzeugt. Das Exemplar wird gelöscht, sobald das Verhalten beendet ist. Verhaltensklassen unterstützen wie alle Klassen Attribute, Assoziationen, Operationen und auch anderes Verhalten, z.b. Zustandsautomaten. Das ist allgemeine Praxis in Systemen, die Prozesse verwalten, z. B. Workflow- und Betriebssysteme. Im unteren Teil von Abbildung 8 sieht man die Verhaltensklasse für die Aktivität Post austragen mit einer Operation, um die Ausführung abzubrechen, und einer Assoziation zur Klasse Postwagen, die in der Aktivität verwendet wird. Es können auch Zustandsautomaten mit der Verhaltensklasse verbunden werden, um den Status der Ausführung zu beschreiben, z.b. NICHT_GESTARTET, UNTERBROCHEN usw. UML 2 Verhaltensklassen ermöglichen die Definition von Standardfunktionen für Prozessmanagementsysteme, obwohl die UML 2 selbst keine Standardeigenschaften definiert. Die Eigenschaften der Verhaltensklassen können von Domänenstandards, Herstellern oder Benutzergruppen als wiederverwendbare Modellbibliotheken mit abstrakten Klassen mit Attributen und Operationen wie abbruch() usw. definiert werden. Die Klassen können dann als Basisklassen für anwenderdefiniertes Verhalten wie Post austragen in Abbildung 8 verwendet werden. Zusammenfassung und Dank Dieser Artikel betrachtet die Entwicklung der UML-Ablaufmodellierung, die benötigten Paketstrukturen, um die große Bandbreite an Anwendungsgebieten zu bedienen, sowie das Konzept der UML- Semantik und stellt dann elementare Elemente der Aktivitätsmodellierung sowie das Verhaltensmodell der UML 2 vor. Ich danke Evan Wallace und James Odell für ihre Ideen zu diesem Artikel. Übersetzung aus dem Englischen von Tim Weilkiens ( tim.weilkiens@oose. de) mit Genehmigung des Herausgebers JOT (Journal of Object Technology), Band 2, Nummer 4, Juli-August 2003 (siehe [JOT]) Abb. 8: UML-2-Verhalten Literatur & Links [Boc99] C. Bock, Three Kinds of Behavior Model, in: Journal of Object-Oriented Programming, 12:4, July/August 1999 [Boc03] C. Bock, UML Without Pictures, in: IEEE Computer Special Issue on Modeldriven Development, September/Oktober 2003 [JOT] Journal of Object Technology, (siehe: [OMG03] Object Management Group, OMG Unified Modeling Language, Version 1.5, März 2003 (siehe: [U2P03] U2 Partners, Unified Modeling Language: Superstructure, Version 2.0 (3. Überarbeitung), April 2003 (siehe: www. omg.org/cgi-bin/doc?ad/ )