Aufbau der Buildtime-Komponente

Die Buildtime-Komponente ist aus Teilen aufgebaut, die die Aufgaben aus Abbildung 7.3 erledigen. Diese Komponenten sind in Abbildung 7.4 zu sehen.

Buildtime

Abbildung 7.4 Aufbau der Buildtime-Komponente

Durch die unterschiedlichen Systemklassen und dadurch unterschiedlichen Ausgangssi-tuationen zwischen diesen, ist keine klare Schichtenarchitekur möglich. Dennoch ist es sinnvoll, den Aufbau so weit wie möglich in Schichten oder zumindest Teilschichten zu gliedern, da so deutlicher wird, wo die gemeinsamen Schnittstellen zwischen den Kom-ponenten sind. Durch die Bedingungen, dass Prozeduraufrufe nur von oben nach unten, der Datenfluss jedoch nur von unten nach oben erlaubt sind und die Vorgabe dass keine

Schichten übersprungen werden dürfen, wird die Abhängigkeit der Komponenten von-einander deutlich gemacht. Eine Beschreibung der Komponenten und ihrer Abhängig-keit voneinander findet im Folgenden statt.

- Daten-Manager: Der Daten-Manager befindet sich auf der untersten Ebene der Architektur. Dieser greift auf die Datenquellen von Klasse-2- und -3-Systemen zu. Dabei lädt er die Modell- und Log-Daten der Systeme und beseitigt syntakti-sche Heterogenitäten. Dafür braucht der Daten-Manager Informationen, die Me-tadaten über die Quellsysteme bzw. über ihre Daten erhalten. Die Umsetzung kann mit den aus Kapitel 3 bekannten Technologien erfolgen. Als Output liefert der Daten-Manager syntaktisch einheitliche Daten, die vom Prozesstransforma-tor weiterverarbeitet werden.

- Prozesstransformator: Transformiert Modelldaten und Log-Daten in ein vorge-gebenes Zwischenmodell und beseitigt dabei die Heterogenitäten zwischen den Modellen, die aus Kapitel 4 bekannt sind. Log-Daten sind zwar Laufzeitdaten, können aber, wie bereits erklärt, auch für Process Mining benutzt werden und werden somit auch von der Buildtime-Komponente benötigt. Die Transformati-on der Daten ist analog zu der der Modelldaten und somit ist der Transformator ein Teil des Prozesstransformators. Die transformierten Log-Daten sind allerdings über eine andere Schnittstelle zu erreichen, da diese dem Process Miner (s.u.) als Input dienen, anders als die transformierten Modellda-ten, die vom Modellierungswerkzeug benötigt werden (s.u.).

Die Transformationen beider Arten von Daten werden nach Transformationsre-geln durchgeführt, die in einer eigenen Datenquelle abgelegt sind (s. Datenspei-cher - Transformationsregel). Nach Durchführung jeder Transformation wird die durchgeführte Änderung am Quellmodell in einer Tabelle gespeichert, die später von der Runtime-Komponente benutzt wird (s. Tabelle - durchgeführte Ände-rungen).

- Wrapper: Wie in Abbildung 7.4 zu sehen ist, ist der Daten-Manager nicht die einzige Komponente, die auf die Quellsysteme zugreift. Der Wrapper ist für Klasse-1-Systeme zuständig. Wie bereits beschrieben, kapselt er die Systeme, indem er alle Ereignisse beobachtet, die mit dem jeweiligen System in Verbin-dung stehen. Ereignisse, die für die Erzeugung von Prozessmodellen benötigt werden, werden von ihm syntaktisch und semantisch in einer Form aufgezeich-net, die vom Process Miner benötigt wird.

- Process Miner: Diese Komponente führt das Process Mining durch (s. Abschnitt 2.2.1.3). Die dafür benötigten Daten erhält er entweder vom Prozesstransforma-tor (genauer Log-TransformaProzesstransforma-tor) oder vom Wrapper. Unabhängig davon, ob die-se Daten von Klasdie-se-2-Systemen kommen und transformiert wurden oder ob sie

basierend auf den Applikationsdaten von Klasse-1-Systemen generiert wurden, sind sie syntaktisch und semantisch immer in der gleichen Form. Dadurch reicht die Implementierung eines einzigen Process Miners.

Wichtig beim Process Miner ist, dass er Modelle auf Basis des Metamodells er-zeugt, das vom Modellierungswerkzeug als Input benutzt werden kann. Ansons-ten müssAnsons-ten die erzeugAnsons-ten Prozessmodelle zunächst unnötigerweise durch den Prozesstransformator transformiert werden.

- Modellierungswerkzeug: Mit Hilfe eines Modellierungswerkzeugs kann man die durch den Prozesstransformator transformierten oder durch den Process Miner generierten Prozessmodelle überprüfen und gegebenenfalls nachbearbeiten. Wie der Process Miner bekommt auch das Modellierungswerkzeug von den beiden darunter liegenden Komponenten die benötigten Daten syntaktisch und seman-tisch in der gleichen Form. Diese bieten also die gleiche Schnittstelle an.

Können von den beiden Komponenten gar keine Modelldaten geliefert werden, dann kann an dieser Stelle der Prozess manuell modelliert werden.

Der Output des Modellierungswerkzeuges dient als Input für den Prozessintegra-tor.

- Prozessintegrator: Nachdem die Modelldaten alle auf Basis eines vorher festge-legten Metamodells vorliegen, werden die Prozessfragmente, die von den ein-zelnen Systemen stammen, vom Prozessintegrator zu einem Gesamtprozess zu-sammengefügt. Neben der Identifikation und Herstellung von Beziehungen zwi-schen den Prozessfragmenten, werden an dieser Stelle alle aus Kapitel 5 bekann-ten Aufgaben durchgeführt. Analog zum Prozesstransformator hat auch diese Komponente eine Regelbasis (s. Datenspeicher - Integrationsregel), anhand de-rer die Integrationen vorgenommen werden. Die für die Integration durchgeführ-ten Änderungen werden zusammen mit den Änderungen des Prozesstransforma-tors in einer Tabelle gespeichert (s. Tabelle - durchgeführte Änderungen).

Das Ergebnis des Prozessintegrators ist das globale Prozessmodell, das der Ren-dering-Komponente als Grundlage für die Visualisierung dient (s. Abschnitt 7.1). Das Modell wird allerdings zuvor im Modellspeicher zwischengespeichert, damit es nicht jedes Mal erzeugt werden muss, wenn es benötigt wird.

- Datenspeicher: Für Daten, die in größeren Mengen vorkommen, werden eigene Datenspeicher vorgesehen. Diese gibt es für drei verschiedene Zwecke:

- Transformationsregel: Die Transformationsregeln werden vom Prozesstrans-formator für das Mapping von einem Quell- auf ein Zielmodell benötigt. Eine Transformationsregel beschreibt dabei für jedes Konstrukt des Quellmodells auf welches Konstrukt des Zielmodells dieses abgebildet werden kann und

welche Vorbedingungen dafür gegeben sein müssen. Für jedes Paar von Quell- und Zielmodellen gibt es eigene Regeln, da diese von den Metamodel-len der beiden Modelle abhängen.

Durch Erweiterungen der Regelbasis können neue Transformationen einge-führt werden.

- Integrationsregel: Die Integrationsregeln werden vom Prozessintegrator bei der Integration von Prozessfragmenten benutzt. Sie beschreiben welche Vor-bedingungen für Aktionen bei der Integration erfüllt sein müssen und welche Aktionen möglich sind.

Durch Erweiterung der Regelbasis können neue Aktionen auf den Prozess-fragmenten durchgeführt werden.

- Modellspeicher: Diese Datenbank speichert die integrierten Modelldaten zu-sammen mit Informationen zu den Quellsystemen, von denen sie stammen.

(Die Speicherung der Quellsysteme wird von der Laufzeitkomponente (s.u.) benötigt.) Eine Zwischenspeicherung der Modelldaten an dieser Stelle soll verhindern, dass nicht bei jeder Visualisierung eines Prozesses die ganze Pro-zedur der Modellerzeugung durchlaufen werden muss. Stattdessen kann die-ser einfach aus dem Modellspeicher geladen werden.

- Generierte Log-Daten: Die generierten Log-Daten werden vom Wrapper auf-gezeichnet. Sie werden vom Process Miner der Buildtime-Komponente und vom Instanzdaten-Integrator der Runtime-Komponente (s.u.) benötigt.

- Weitere externe Daten:

- Dokumente mit Systeminformationen werden vom Data-Manager benötigt, da die zu verarbeitenden Informationen systemspezifisch sind. Mit Hilfe der Systeminformationen, u.a. dem Metamodell, auf dem die Daten des Systems basieren, können die Daten der einzelnen Systeme in ein syntaktisch einheit-liches Format gebracht werden.

- Eine Tabelle mit den durchgeführten Änderungen des Prozesstransformators und -integrators wird benötigt, damit die Runtime-Komponente die entspre-chenden Anpassungen für die Integration der Instanzdaten vornehmen kann.

Die protokollierten Änderungen sollen die Lösung der Probleme aus Ab-schnitt 6.2.2 ermöglichen.