Analyse der Überführbarkeit zwischen fachlichen und technischen Prozessmodellen für eine service-orientierte Architektur

Diplomarbeit von Christoph Bley

Einleitung:

Die Konzepte der Service-orientierten Architektur (SOA) zeigen eine flexible Ausrichtung der IT an den Geschäftsprozessen eines Unternehmens. Typischerweise werden diese Geschäftsprozesse technisch und fachlich modelliert. Um eine effiziente, dauerhafte Ausrichtung der IT an den Geschäftsprozessen zu gewährleisten, müssen die jeweiligen technischen und fachlichen Prozessmodelle konsistent zueinander sein. Zur Sicherung dieser Konsistenz ist eine automatisierte Überführung zwischen den technischen und fachlichen Prozessmodellen anzustreben. Es existieren Ansätze für eine solche automatisierte Überführung, allerdings sind die realisierten Überführungsstrategien sehr ungenau oder gar nicht beschrieben.

Ziel dieser Arbeit ist Überführungsstrategien zu identifizieren bzw. zu definieren. Dafür ist es notwendig, geeignete technische und fachliche Modellierungsnotationen für die Entwicklung einer Service-orientierten Architektur (SOA) auszuwählen. Auf den geeigneten Überführungsstrategien aufbauend, sollen Überführungsregeln entwickelt werden, die durch eine geeignete Realisierungstechnik prototypisch umzusetzen sind. Damit wird die Funktionsweise der entwickelten Überführungsregeln nachgewiesen. Die Arbeit ist in vier Teile gegliedert. Der erste Teil fokussiert sich auf die Funktionsweise der Service-orientierten Architektur (Kapitel 2 - Service-orientierte Architektur). Dieses Verständnis ist notwendig, um die Anforderungen an eine fachübergreifende Modellierung im Umfeld einer SOA zu identifizieren.

Anhand dieser Anforderungen werden im zweiten Teil dieser Arbeit die verschiedenen Modellierungsnotationen untersucht (Kapitel 3 - Modelle). Ziel ist hierbei die Festlegung auf eine technische und eine fachliche Modellierungsnotation, um diese anschließend zu vergleichen. Dabei stehen die wesentlichen Differenzierungsmerkmale im Mittelpunkt. Auf Grundlage des Vergleiches werden Überführungsstrategien hergeleitet. Im dritten Teil der Arbeit werden diese Überführungsstrategien (Kapitel 4 - Überführung) analysiert und bewertet. Dabei liegt der Schwerpunkt auf der Entwicklung von Überführungsregeln. Im darauf folgenden praktischen Teil der Arbeit (Kapitel 5 - Realisierung) wird eine Überführungsstrategie mit Hilfe einer geeigneten Realisierungstechnik prototypisch implementiert.

Problemstellung:

Die Konzepte der service-orientierten Architektur (SOA) versprechen eine flexible Ausrichtung der IT an die Geschäftsprozesse eines Unternehmens. Grundprinzip der SOA sind lose gekoppelte, voneinander unabhängige Dienste (Services).

Durch ihren hohen Standardisierungsgrad bieten sich Webservices zur Realisierung von Services gerade in heterogenen Systemlandschaften an. Um Geschäftsprozesse flexibel zu unterstützen, können Webservices mit Hilfe vorwiegend XML-basierter Sprachen zu komplexen Aktivitäten orchestriert werden.

Für die fachliche Modellierung der Geschäftsprozesse eignen sich solche Sprachen hingegen nicht, da die erforderlichen technischen Details für die Geschäftsprozessmodellierung zu komplex sind und technische Aspekte für die fachliche Modellierung keine Rolle spielen. Für die fachliche Modellierung wird eine Notation benötigt, die von technischen Details abstrahiert und mit der einfach und flexibel Geschäftsprozessdiagramme (BPD) erstellt werden können.

Die Konsistenz fachlicher und technischer Prozessmodelle ist Voraussetzung für eine effiziente und dauerhafte Ausrichtung der IT an den Geschäftsprozessen. Um diese Konsistenz zu sichern, ist eine automatisierte Überführbarkeit zwischen den spezifischen Modellierungssprachen wünschenswert. Ansätze zur automatisierten Überführung sind vorhanden und auch spezifiziert, doch werden oft nur einfache Modelle überführt und die Spezifikation ist sehr oberflächlich bis ungenau. Ziel dieser Arbeit ist es zu analysieren, welche grundsätzlichen Differenzierungsmerkmale fachlicher und technischer Modellierungsnotationen existieren und in wieweit ausgewählte Notationen automatisiert in einander überführt werden können. Die Ergebnisse sollen anhand einer prototypischen Notationsüberführung an einem Beispielprozess belegt werden.

Schwerpunkte:

- Einordnung fachlicher und technischer Modellierungsnotationen in das Geschäftsprozessmanagement (BPM).

- Identifizierung wesentlicher Differenzierungsmerkmale technischer und fachlicher Modellierungsnotationen anhand ausgewählter Notationen.

- Analyse der ausgewählten Modellierungsnotationen hinsichtlich ihrer Eignung zur Transformation.

- Analyse bestehender Transformationsmechanismen auf deren Eignung und ihrer Grenzen.

- Realisierung einer prototypischen Notationsüberführung anhand eines Beispielprozesses.

Inhaltsverzeichnis:

Inhaltsverzeichnis:

Textprobe:

Kapitel 5.4.3, Abstraktionsstufen:

Aufbauend auf der angestrebten Überführungsrichtung BPMN zu BPEL und der Überführungsstrategie Element Preservation stellen die Prozessnotationen verschiedene Abstraktionsstufen eines Geschäftsprozesses dar. Entsprechend des MDA Ansatzes werden vier verschiedene Abstraktionsstufen unterschieden. Dabei beschreibt die Prozessnotationen BPMN einen Geschäftsprozess aus fachlicher Sicht. So liegt der Fokus bei der Modellierung nicht auf der technischen Umsetzung des Prozesses, sondern auf der fachlichen Korrektheit. Das Modell realisiert damit eine plattformunabhängige Sicht auf den Geschäftsprozess und wird deshalb in die Gruppe der plattformunabhängigen Modelle (PIM) eingeordnet. Die technische Prozessnotation BPEL legt den Schwerpunkt im Gegensatz zu BPMN auf die Realisierung des Geschäftsprozesses.

BPEL Modelle ermöglichen dabei eine technisch detaillierte Sichtweise auf den Geschäftsprozess und besitzen deshalb einen geringeren Abstraktionsgrad. Deswegen werden diese Modelle in die Gruppe der plattformabhängigen Modelle (PSM) eingeordnet. Mit Hilfe des MDA Ansatzes wird gemäß der Überführungsstrategie Element Preservation, basierend auf den Metamodellen, eine Modell zu Modell Überführung durchgeführt. Aufgrund der Überführungsrichtung wird so das abstraktionsstärkere Modell BPMN in das abstraktionsschwächere Modell BPEL überführt.

Kapitel 5.4.4, Modifikation der Metamodelle:

Da die zu implementierenden Überführungsregeln gemäß des MDA Ansatzes auf den jeweiligen Metamodellen basieren, können auch nur Modellinformationen überführt werden, welche entsprechend im Metamodell definiert wurden. So fehlt im verwendeten BPMN Metamodell die Guard Bedingung der „connection flow“ Elemente. Dieses gibt an, wann eine Verbindung benutzt wird und wann nicht. Damit werden beispielsweise die Verzweigungs- und Zusammenführungsbedingungen realisiert. Aufgrund der Verwendung des BPMN Editors für das Erstellen von metamodellkonformen Ausgangsmodellen kann das BPMN Metamodell nicht um die fehlende Guard Bedingung ergänzt werden. Deswegen muss für die prototypische Implementierung eine Möglichkeit gefunden werden, diese fehlenden Informationen mit den bestehenden Modellelementen des BPMN Metamodells abzubilden.

Aufgrund des Abstraktionsgrades des BPMN Prozessmodells und der Fokussierung auf den fachlichen Bereich, werden die Guard Bedingungen nicht durch die entsprechenden logischen Funktionen realisiert. Vielmehr ist es üblich, dass solche Bedingungen natürlichsprachig an das jeweilige „connection flow“ Element angefügt werden. Dafür bieten sich gemäß der BPMN Spezifikation die „artefact“ sowie die direkte Beschriftung der „connection flows“ Elemente an. Der verwendete BPMN Editor nutzt die Artefakte des BPMN Metamodells noch nicht, weswegen die Guard Bedingung mit Hilfe des „name“ Attributes der entsprechenden „Connection Flow“ Elemente modelliert wird. Die so natürlichsprachig identifizierten Guard Bedingungen werden auf der Abstraktionsstufe des BPEL Modells weiter spezialisiert. Der technische Bereich überführt diese natürlichsprachige Bedingung in eine Funktion, die mit Hilfe von Variablen und logischen Operatoren den Prozessfluss des BPEL Dokumentes steuert. Ein automatisiertes Anlegen solcher Bedingungen ist damit nicht möglich, da die benötigten Informationen im abstraktionsstärkeren BPMN Ausgangsmodell nicht vorhanden sind und durch den technischen Bereich hinzugefügt werden müssen.

Um dennoch den technischen Bereich bei der Realisierung der Guard Bedingungen zu unterstützen, werden entsprechende Variablen und „condition“ Elemente im BPEL Dokument automatisch angelegt. Durch die Markierung der „condition“ Elemente mit dem Namen der dazugehörigen Variable und der logischen Verzweigungsart wird der technische Bereich in der Entwicklung der eigentlichen logischen Auswahlfunktion unterstützt. Dabei erwartet das „body“ Attribut des jeweiligen „condition“ Elements die eigentliche logische Funktion und kann deshalb nicht für die natürlichsprachige Markierung genutzt werden. Da die Markierung für den technischen Bereich nur als eine Art „Eselsbrücke“ dienen soll und nach der Modellierung der eigentlichen Funktion entfernt wird, wird das Attribut „transitionLanguage“ für die Markierung der „condition“ Elemente zweckentfremdet.

Durch diese entsprechenden Festlegungen können die Guard Bedingungen ohne Änderung des BPMN Metamodells realisiert werden. Darüber hinaus wird durch die Markierung der BPEL „condition“ Elemente die Entwicklungsarbeit des technischen Bereiches unterstützt. Voraussetzung dafür ist, dass die jeweiligen Bereiche über diese Modifikation informiert sind, damit die Guard Bedingungen im BPMN Modell durch den fachlichen Bereich entsprechend modelliert werden und die Markierungen im BPEL Modell auch als solche durch den technischen Bereich zu erkennen sind.