Semantisches ARIS Teil 2
Tags: aris, ontology, semanticaris, super
Kategorie Promotion | Keine Kommentare »
Dies ist nun der zweite Teil einer kleinen Serie über die Diplomarbeit von Christian. Ziel der Diplomarbeit war es, die Idee des semantischen Geschäftsprozessmanagement empirisch zu evaluieren. Dazu musste z.B. ARIS prototypisch erweitert werden, damit es die semantische Modellierung unterstützt. Genau diese Erweiterung von ARIS beschreibt der heutige Teil dieser Serie. Einen Überblick über das gesamte Vorhaben findet man im ersten Teil dieser Serie.
ARIS ist leider ein etwas vielfältig verwendeter Begriff, hinter dem sich verschiedene Sachen verstecken. So ist ARIS zum Beispiel ein Vorgehensmodell, das es auch noch in unterschiedlichen Varianten je nach Anwendungsfall (etwa SOA oder allgemeines BPM) gibt. ARIS ist auch eine Modellierungssprache, um alle Aspekte eines Unternehmensmodells zu beschreiben. Die Modellierungssprache umfasst dabei eine Vielzahl anderer Sprachen wie UML oder BPMN und fügt nur da eigene Konstrukte hinzu, wo es keinen anerkannten Standard gibt. Und dann ist ARIS auch noch eine Familie von Softwarewerkzeugen, die das Vorgehensmodell und die Modellierungssprache unterstützen. In der Diplomarbeit wurden primär diese Softwarewerkzeuge erweitert, keine Änderungen am Vorgehensmodell vorgenommen und lediglich Modellierungselemente wiederverwendet.
Die semantische Modellierung sollte auf der EPK Notation aufsetzen. Wir hätten auch BPMN nehmen können, aber da BPMN bereits ausreichend im Forschungsprojekt SUPER von anderen Partnern untersucht wird, war es naheliegend, die Tauglichkeit von EPKs auch mal zu beleuchten. Ziel der semantischen Modellierung ist es, dass ein Computer den Inhalt einer EPK analysieren und „verstehen“ kann. So soll ein Computer in der Lage sein, für jede Funktion im Geschäftsprozess einen passenden Web Service zur Automatisierung dieser Funktion zu finden.
Für die Definition von solchen semantischen Beschreibungen haben wir WSMO verwendet, weil es im Forschungsprojekt SUPER eben primär eingesetzt wird. Allerdings soll der Prototyp soweit wie möglich vom semantischen Formalismus unabhängig sein. Deshalb wird die WSMO Beschreibung nicht direkt an den einzelnen Funktionen des Geschäftsprozess gespeichert, sondern durch ein eigenes Modellierungsobjekt repräsentiert. In der folgenden Abbildung (ja, ich war nicht zu faul!) sieht man eine Funktion, die semantisch annotiert ist.
Das WSMO Goal wird durch das untere Objekt dargestellt. Dies ist eine Fähigkeit (Capability). Fähigkeiten werden genutzt, um die funktionalen Eigenschaften von Services zu beschreiben. Man kann Fähigkeiten aber auch wie hier in diesem Fall nutzen, um anzugeben, welche Fähigkeit eine Funktion verlangt, damit man sie automatisieren kann. Die beiden grauen Objekte sind Fachbegriffe. Diese repräsentieren die im WSMO Goal beschriebenen Eingabe- und Ausgabedaten. Ändert sich nun der semantische Formalismus, so bleibt dieses Bild konstant und die Modellierung ist damit unabhängig vom genutzten Formalismus.
Nun ist natürlich die Frage, wie man als Fachmodellierer das richtige WSMO Goal auswählt. Um diesen Schritt während der Modellierung zu unterstützen, wurde eine kleine Hilfsoberfläche entwickelt, die in der folgenden Abbildung zu sehen ist.
Zugegeben, lesen kann man da nichts in der Grafik, aber das Prinzip lässt sich trotzdem erklären. Zunächst wählt man in Bereich 1 einen Ordner auf der Festplatte aus, der Dateien mit WSMO Goals enthält. Im Bereich 2 werden dann alle gefundenen WSMO Goals angezeigt. Klickt man auf ein WSMO Goal im Bereich 2, dann wird im Bereich 3 der Inhalt angezeigt. Hat man das gewünschte WSMO Goal gefunden, dann bestätigt man seine Auswahl mit dem OK Button und das WSMO Goal wird entsprechend der ersten Grafik an die Funktion gehängt. Der Dialog ist natürlich alles andere als perfekt, da ein Fachmodellierer trotzdem sich den kryptischen WSML Code anschauen muss. Aber wie gesagt, es ist ja nur ein Prototyp und wir wollen ja schließlich noch Stoff für zukünftige Arbeiten haben :-)
Wurden alle Funktionen entsprechend semantisch beschrieben, muss man noch den Datenfluss vervollständigen. Dazu gibt es auch eine Unterstützungsfunktionalität und ein Bild, damit man besser versteht, was hier passiert.
In einer EPK ist der Datenfluss nur implizit definiert. Will man aber einen Prozess ausführen, dann muss man konkret sagen, woher eine Eingabe kommt. Deshalb wählt man in diesem Beispiel die beiden Fachbegriffe aus und „mappt“ sie aufeinander. Dabei wird automatisch ein Modell hinterlegt, das das Mapping beschreibt. Das ist alles zwar keine sehr saubere Lösung, hat aber wiederum seinen Zweck erfüllt.
Neben dem Datenfluss muss man zum Beispiel auch noch den Kontrollfluss vervollständigen, indem man etwa Bedingungen an Entscheidungspunkten im Prozessfluss pflegt. Das ist jetzt aber weniger spannend und ich spar das einfach mal aus. Am Ende hat man ein semantisch angereichertes Prozessmodell. Man könnte dieses Prozessmodell nun zum Beispiel in die sEPC Ontologie exportieren, damit man das Modell auf Basis der SUPER Architektur weiterverarbeiten kann. Da aber zum Zeitpunkt der Diplomarbeit noch nicht alle notwendigen Komponenten zur Verfügung standen, haben wir einen anderen Weg zur Ausführung ersonnen. Diesen beschreibe ich dann allerdings im nächsten Teil dieser Serie.