Parallele Ausführung unterschiedlicher BTAs

 Zur Demonstration der parallelen Ausführung unterschiedlicher BTAs wurde eine einfache Beispielanwendung erstellt, die zwei BTAs anbietet, die jeweils eine gegebene Menge von Zahlen sortieren und dies grafisch veranschaulichen. Die eine der beiden BTAs bedient sich hierfür des BubbleSort-Algorithmus (BubbleSortBTA), während die zweite BTA den QuickSort-Algorithmus verwendet ( QuickSortBTA). Um die gemeinsame Verwendung eines Bausteins in unterschiedlichen BTAs zu demonstrieren, wurde die sogenannte DelayBean eingesetzt. Diese wird bei Anstoß jeder der beiden BTAs aufgerufen und simuliert beliebige Verarbeitung durch eine konfigurierbare Verzögerung. Der eigentliche Sortiervorgang wird erst nach Abschluß dieser Verzögerung gestartet.

Abbildung  stellt die Beanbox nach Erstellung einer entsprechenden Anwendung dar. Man erkennt zwei Buttons (Starte BubbleSort und Starte QuickSort), mit denen die jeweilige BTA angestoßen werden kann. Weiterhin ist eine Instanz der DelayBean (mit einer konfigurierten Verzögerung von sechs Sekunden) sowie zwei Beans für die Veranschaulichung der Sortiervorgänge, sogenannte SortItems zu erkennen.

 

Abbildung: Einfache Beispielanwendung in der Beanbox 

47#47

Es wurde ein Testlauf durchgeführt, bei dem zunächst eine BubbleSortBTA angestoßen wurde. Diese führt - wie konfiguriert - zunächst eine Verzögerung von sechs Sekunden aus. Anschließend wird der Sortiervorgang gestartet, der in einem separaten Kontrollfluß ausgeführt wird. Nach Anstoß des Sortiervorgangs kehrt der ursprüngliche Kontrollfluß somit zur Oberfläche zurück und es können weitere BTAs gestartet werden. Unmittelbar nach Rückkehr des Kontrollflusses zur Oberfläche (also während die eigentliche Sortierung noch läuft) wird eine BTA vom Typ QuickSortBTA angestoßen, die somit parallel zur ersten BTA ausgeführt wird.

 

Abbildung: Visualisierung einer Instanz der BubbleSortBTA 

48#48

 

Abbildung: Visualisierung einer Instanz der QuickSortBTA 

49#49

Die Meßergebnisse des Testlaufes wurden an die prototypische Managementanwendung übermittelt. Auf der rechten Seite des Fensters in Abbildung  erkennt man, daß die BubbleSortBTA zunächst mit einer BI innerhalb des StartButtons beginnt, der daraufhin synchron zunächst die DelayBean und dann die Methode starteSort der Bean SortItem aufruft (zu erkennen an den horizontal leicht versetzten, vertikalen Linien zu DelayBean bzw. SortItem, die die serielle Ausführung der beiden Transaktionen durch den StartButton veranschaulichen). Der Aufruf von SortItem führt zu einem Start eines neuen Kontrollflusses, der wiederum die Bean SortItem ausführt (diesmal aber deren run-Methode). Ein ähnliches Bild ergibt sich für die in Abbildung  dargestellte Visualisierung der QuickSortBTA.

Ein wesentlicher Unterschied, der sich zwischen den beiden BTAs ergibt, ist die gemessene Antwortzeit. Wie zu erwarten war, benötigte die QuickSortBTA erheblich weniger Zeit (15049ms) als die BubbleSortBTA (36046ms). Dies ist im linken oberen Teil der Abbildungen zu erkennen. Durch Selektieren der Subtransaktion, die die eigentliche Sortierung durchführt, könnte dieser Unterschied noch wesentlich detaillierter bestimmt werden (im Beispiel 9029ms vs. 30029ms, in den Abbildungen nicht dargestellt).

Weiterhin ist jeweils im linken unteren Bereich der Fenster die Detailinformation zur von der DelayBean erbrachten Subtransaktion angegeben. Die Subtransaktion dauerte in beiden Fällen (wie konfiguriert) annähernd sechs Sekunden. Man erkennt (an der identischen Instance ID), daß tatsächlich bei beiden BTAs dieselbe Instanz der DelayBean zum Einsatz kam und daß beide Male die DelayBean im Thread der Oberfläche ( AWT-EventQueue-0) ausgeführt wurde. Dennoch war eine korrekte Zuordnung zur jeweiligen BTA durch die dynamische Zuordnung von Kontrollflüssen zu BTAs problemlos und automatisch möglich. Dies wäre bei statischer Beschreibung der Abhängigkeiten zwischen den einzelnen Bausteinen nicht möglich gewesen.

Die Abläufe während der Ausführung dieser Beispielanwendung werden durch das Sequenzdiagramm in Abbildung  nochmals verdeutlicht. Aufgrund des Umfangs des Diagramms mußte auf eine Darstellung der Aufrufe der DelayBean verzichtet werden. Die grundsätzliche Funktionsweise ist aber dennoch zu erkennen. Zunächst wird der Button zum Start des BubbleSort (Button1) im Thread der Oberfläche ausgeführt. Button1 meldet den Start einer BTA an das Meßobjekt. Das Meßobjekt erzeugt einen eindeutigen Identifikator für die Instanz der BTA (im Beispiel Bubble1) und speichert diesen gemeinsam mit der Information über den ausführenden Thread (die Liste mit der Zuordnung von BTA-Instanzen zu Threads ist jeweils am linken Rand des Sequenzdiagramms veranschaulicht). Nach Rückkehr zum Button ruft dieser die Anwendungslogik auf, die ihrerseits die eigentliche BubbleSort-Bean aufruft. Vor Aufruf dieser Bean wird allerdings wiederum das Meßobjekt vom Start der neuen Subtransaktion verständigt. Anhand des Threads, in dem diese Subtransaktion gestartet wird, ist es dem Meßobjekt möglich, die Zuordnung dieser Subtransaktion zur BTA-Instanz Bubble1 vorzunehmen. Die BubbleSortBean erzeugt einen neuen Thread durch Aufruf einer Bibliotheksfunktion der Java Virtual Machine. Diese informiert das Meßobjekt über die Hinzunahme des weiteren Threads. Das Meßobjekt hat somit Kenntnis über die beiden Threads, die zu diesem Zeitpunkt die BTA-Instanz Bubble1 ausführen. Der Start des neuen Threads wird vom Meßobjekt gleichzeitig als der Start einer neuen Subtransaktion interpretiert (in der Abbildung nicht dargestellt). Während der ursüprüngliche Thread über die BubbleSortBean zur Anwendungslogik zurückkehrt, wird im neu generierten Thread nunmehr die eigentliche Sortierung ausgeführt. Die Anwendungslogik meldet die Rückkehr des Threads als das Ende einer Subtransaktion, die wiederum problemlos der BTA-Instanz Bubble1 zugeordnet werden kann (Die Zuordnung zum zugehörigen startTA erfolgt anhand der Reihenfolge der Aufrufe innerhalb eines Threads). Nach Rückkehr zum Button1 meldet dieser das Verlassen des Kontrollflusses aus der Bearbeitung dieser Instanz einer BTA. Das Meßobjekt löst folglich die Zuordnung des Oberflächen-Threads zur Instanz Bubble1.

Im Anschluß daran folgt ein analoger Ablauf zum Anstoß des zweiten Sortiervorgangs mit Hilfe des QuickSort-Algorithmus. Man erkennt an der Tabelle für die Zuordnung, daß weiterhin eine Zuordnung von Instanz Bubble1 zu dem Thread existiert, der den BubbleSort-Algorithmus ausführt. Darüberhinaus enthält die Tabelle nun aber auch einen Eintrag für die zweite BTA-Instanz Quick1. Zunächst existiert eine Zuordnung der BTA-Instanz Quick1 zum Thread der Oberfläche. Nach Hinzunahme eines weiteren Threads für den eigentlichen Sortiervorgang erscheint auch dieser in der Tabelle. Der Oberflächen-Thread verläßt daraufhin die Bearbeitung und die beiden BTA-Instanzen werden weiter in jeweils einem Thread ausgeführt.

Endet nun einer dieser beiden Threads (im Beispiel zunächst der Thread der BTA-Instanz Quick1), so meldet die JVM dies an das Meßobjekt, das die Zuordnung zur BTA-Instanz auflöst und dies gleichzeitig als Ende des Sortiervorgangs erkennt. Analog erfolgt die Auflösung der Zuordnung bei Ende des verbliebenen Threads. Nach Abschluß dieses Threads verbleibt keine aktive BTA-Instanz mehr in der Tabelle.