Download Prozessorientierte Integration von Softwarekomponenten durch XML

7.3 UML-Profil für Prozessdiagramme
139
Aktivitäten zur Komponentenintegration
Für die Aktivitäten im Prozessdiagramm wird das Stereotyp «serviceState» definiert. Es
basiert auf der Basisklasse CallState, die dazu gedacht ist, die Methode einer Klasse
aufzurufen (siehe Abschnitt 6.2.1). Bei einem «serviceState» wird die Einschränkung
gemacht, dass nur eine als «service» deklarierte Operation aufgerufen werden darf
(siehe Constraint 1). Beim Aufruf des Service müssen Werte für geforderte Parameter
übergeben werden. Das UML-Metamodell (siehe [Omg01] 2.9.2.3) sieht als Wert für
ein Argument einen beliebigen Ausdruck vor. Es wird keine Einschränkung bezüglich
der möglichen Sprache getroffen. Somit sind für die Argumente auch Ausdrücke möglich, die für das WFMS verständlich sind und vor Aufruf der Methode ausgewertet werden können, um etwa Daten aus dem Migrationsdokument oder der Prozessumgebung
(vgl. Abschnitt 6.2.2) zu übernehmen.
Stereotyp
serviceState
Basisklasse
UML::ActivityGraphs::CallState
Ober-Stereotyp
stateWithPorts
Tag Definitionen
keine
Einschränkungen
(Constraints)
1. Die zugeordnete Operation muss vom Stereotyp «service» sein:
Erläuterung
CallStates, die als «serviceState» klassifiziert sind, symbolisieren die Ausführung einer komponentenbasierten Aktivität. Jedem «serviceState» ist ein «service» zugeordnet, an den die
Ausführung der Aktivität delegiert wird.
Darstellung
Standardmäßig wie ein CallState. Wenn der zugehörige «service» im Tag image ein Symbol
spezifiziert, kann dieses zur Darstellung benutzt werden.
context serviceState inv:
let state : CallState = self.extendedElement.oclAsType(CallState)
state.entry.oclAsType(CallAction).operation.isStereotypedAs(service)
Tab. 7.7: Definition des Stereotyps «serviceState»
Die Ausführung der korrespondierenden Service-Operation in einem «serviceState»
führt zu Änderungen auf dem Migrationsdokument. Deshalb müssen für einen
«serviceState» bzw. die durch ihn definierte Service-Aktivität die erlaubten Eingangsund die möglichen Ausgangsdokumenttypen durch die Angabe von Ports modelliert
werden. Dies geschieht durch das Erben der entsprechenden Attribute von
«stateWithPorts». Beim Setzen der Ports kann ein Werkzeug als Vorgabe die Werte für
die Portattribute aus dem «service» übernehmen, der diesem «serviceState» zugeordnet
ist (vgl. Abschnitt 9.2.5, Hinzufügen von Zuständen). Bei manchen Services kann es
allerdings sein, dass ihre Portspezifikation die zulässigen Dokumentmengen nur sehr
wage oder bei der Verwendung von Platzhaltern gar nicht einschränkt, weil bei diesen
generischen Services die Dokumenttypen von konkreten Parameterwerten abhängen. In
solchen Fällen können die Portspezifikationen für den «serviceState» vom Benutzer
angepasst werden, nachdem die Werte der Parameter gesetzt sind (vgl. Abschnitt 6.3.1,
Einbindung von Ports in Prozessdiagramme).