Abschlussarbeit Im Studiengang Informatik SS 2014 Erweiterung einer Konfigurationsdatenbank zur Abhängigkeitsanalyse und Abbildung einer Service-orientierten Architektur

4.1.1 Subkategorie

In das hier betrachtete Tool sind folgende Kategorien integriert, die auch Abbildung 15 zu entnehmen sind: Software, Hardware, Backend-Technologien, Frontendtechnologien, Service und Protokolle. Dabei werden CIs in unterschiedlichen Publikationen jeweils in verschiedene Subkategorien eingeteilt.

Die Gruppe „Services“ beinhaltet die gleichnamigen Komponenten und lässt sich z. B. in drei Subkategorien unterteilen: Basis-, Composed- oder Prozess-Services.

Die Kategorie „Protokolle“ kann ebenfalls in Unterkategorien aufgeteilt werden, und zwar in Netzwerkprotokolle, Kommunikationsprotokolle sowie in asynchrone oder synchrone Protokolle. Das Backend wird untergliedert in die drei Kategorien „Datenbanken“, „Webserver“ und „Applikationsclient“. Die Hardware besteht ebenfalls aus mehreren Komponenten wie Server, PC-Teilen usw. Die Software lässt sich in die folgenden Unterkategorien unterteilen: Programm-Language, WebApplication-Clients, Web-Komponenten wie Java Servlets oder JavaServer Pages (JSP) und Enterprise JavaBeans. Wie im vorigen Kapitel bereits erläutert, kann es sich bei Dateien entweder um Klassen oder um J´Konfigurationsdateien handeln. Daneben gibt es noch weitere Unterkategorien, die in das Tool integriert werden können.

Abbildung 23 zeigt den Aufbau der neuen Konfigurationsdatenbank. Zu dem Grundgerüst des ursprünglichen Tools kommen nun noch die Subkategorien sowie Beziehungsarten und Server-Attribute hinzu.

Abbildung 1: Aufbau der Konfigurationsdatenbank

4.1.1 Subkategorie

Erstellt von sebaii vor 9 Jahren

Die Gruppe „Services“ beinhaltet die gleichnamigen Komponenten und lässt sich z. B. in drei Subkategorien unterteilen: Basis-, Composed- oder Prozess-Services.

Abbildung 1: Aufbau der Konfigurationsdatenbank Die Daten, die für die Aufbereitung und Analyse erforderlich sind, werden von den Models in neun Konfigurationsdatenbanken geladen und an den Controller weitergegeben, der sie aufbereitet und sie anschließend in Form eines Arrays zur Darstellung an die Views (Front-End) übergibt. Die Tabelle „Unterkategorien“ besteht aus den Attributen „idKategorie“, „idUnterKategorie“ und „Name“; den Primärschlüssel bildet das ID-Attribut. In dieser Tabelle werden alle Unterkategorien, die in der Design-Analyse angelegt werden, mit Namen gespeichert. Die Tabelle ist über einen Fremdschlüssel mit den Tabellen „Beziehungsarten“ und „Kategorie“ verbunden. Das Attribut „UnterKategorie“ enthält die ID einer UnterKategorie aus der Tabelle „Unterkategorien“. Beim Aufruf des Menüeintrags „Unterkategorie Kategorie“ wird im Controller die Funktion „showlistUnterKategorie“ (siehe Abbildung 24) aufgerufen.

Abbildung 2: Funktion show UnterKategorie Diese Funktion legt zuerst für den nächsten Datenbank-Aufruf eine „Order By“-Bedingung für das Feld „idUnterKategorie“ fest. Anschließend wird in dem assoziativen Array „data“ ein neuer Index mit der Bezeichnung „Subkategorie“ angelegt, der die Daten einer Abfrage aufnimmt. Diese Daten bezieht das System über den Aufruf der Funktion „getRecordsubKategorie“ aus dem Subkategorie-Modell.

Abbildung 3: Funktion getRecord UnterKategorie Diese Funktion schickt eine Abfrage an die Tabelle „UnterKategorie“ der Datenbank und erhält alle Daten dieser Tabelle zurück. Anschließend werden die Daten als assoziatives Array zurückgeliefert, wobei die Attributnamen als Schlüssel dienen. Anschließend werden alle Views zur Darstellung aufgerufen. Der View, den die Liste der Unterkategorien erstellt, wird an das zuvor angelegte Array mit den Daten zu den Subkategorien übergeben. In Bezug auf Subkategorien gibt es noch zwei weitere Funktionen zum Erstellen und Löschen einer Kategorie.

Nun erstellt die Funktion „CreateUnterKategorie“ die folgenden neuen Unterkategorien:

Abbildung 4: Funktion create UnterKategorie Zu diesem Zweck legt sie zunächst eine Validierungsregel fest, die verhindert, dass das Eingabefeld mit dem Namen „name“ später im Formular der View leergelassen wird. Anschließend entscheidet eine If-Anweisung, ob die Validierungsregel eingehalten wurde. Wenn dies nicht der Fall ist, wird die View zum Erstellen einer neuen Subkategorie erneut aufgerufen. Wird die Validierung positiv beendet, so erfolgt die Verarbeitung der Else-Anweisung. Hier wird zunächst der Wert für den Namen der neuen Subkategorie in ein Array gespeichert. Anschließend werden alle in der View eingetragenen Attribute dieser Subkategorie mit Hilfe einer Schleife in einem neuen Array gespeichert und daraufhin mit diesen beiden Arrays zwei Funktionen aus dem Subkategorien-Modell aufgerufen.

Die erste Funktion erzeugt eine neue Tabelle mit dem Namen der Subkategorie und allen übergebenen Zusatzattributen in der Datenbank. Die zweite Funktion erstellt einen Eintrag in der Tabelle „Kategorien“.

Nachdem diese beiden Funktionen ausgeführt wurden, wird ein sogenanntes Template für die neue Subkategorie erstellt. Das Template wird in einer Variable zusammengesetzt und dann unter folgendem Pfad gespeichert: „application/views/SubKategorie/templates/“. Sein Dateiname setzt sich aus den drei Buchstaben „tpl“ für Template, dem Namen der Subkategorie und der Endung „.php“ zusammen. Zuletzt wird die Funktion „showsubKategorie“ aufgerufen.

Die letzte Funktion zum Bereich der SubKategorie ist die „deleteKategorie“ (siehe Abbildung 27).

Abbildung 5: Funktion deleteUnterKategorie Diese Funktion holt sich zuerst über das Subkategorien-Modell die Daten zu dem zu löschenden Datensatz und speichert sie in einem Array zwischen. Mit Hilfe dieser Daten wird nun der Name der betreffenden Subkategorie ermittelt. Da der Name einer Subkategorie immer identisch mit demjenigen der dazugehörigen Tabelle ist, wird nun unter dieser Voraussetzung und der ID der Subkategorie die Funktion „deletesubKategorie“ aus dem Subkategorien-Modell aufgerufen. Diese löscht den dazugehörigen Eintrag in der Tabelle „Unterkategorien“ und die zur Unterkategorie gehörende Tabelle. Nach dieser Löschung wird mit Hilfe des Subkategorienamens noch der zugehörige Template-Name ermittelt und anschließend das Template gelöscht. Zuletzt wird die Funktion „listUnterKategorie“ (siehe Abbildung 16) aufgerufen.

4.1.2 Attribute Zu einer CI werden zahlreiche Attribute definiert. Durch eine eindeutige Bezeichnung der Version „Status CI-Typ“ wird die Beziehung zu anderen CIs beschrieben. Daneben gibt es noch weitere Attribute, die an dieser Stelle unbedingt erwähnt werden müssen, weil sie für bestimmte Komponenten relevant sind, und zwar die folgenden: Plattform, Webcontainer, OSGI, JAX-WS oder JAX-RS. Für die Unterkategorie „Server“ z. B. sind diese Attribute von großer Bedeutung. Sie ergänzen die von Grewer [2012] in seiner Arbeit

erwähnten Service- und Basis-Attribute, die in Abbildung 28 dargestellt sind. CIs sollten möglichst alle, zumindest jedoch einige dieser Attribute besitzen.

Abbildung 6: Allgemeine Attribute, Service-, Basis- und Serverattribute Die Basis- und Service-Attribute werden von Grewer übernommen. Abbildung 28 zeigt die zusätzlichen Serverattribute, die in das Tool integriert werden. Dies betrifft die Relationen und Beziehungen sowie den Status der CI, die ebenfalls aus der Arbeit von Lukas Grewer übernommen werden.

4.1.3 Beziehungsarten Die Beziehungen werden analog zum alten Tool erfasst. Zur Erfassung der Beziehungsarten im Menü wird ein neues Dropdownfeld eingerichtet, das vom Grundprinzip her genauso funktioniert wie die äquivalente Funktion im Bereich „Unterkategorie“. In der Funktion werden zunächst zwei Kategorien von Beziehungsarten eingefügt. Die erste Kategorie umfasst Beziehungsarten, die in der Analyse rot gefärbt sind, und deutet auf eine Konfigurations- bzw. Implementierungsbeziehung hin. Die zweite Kategorie bilden die Referenzbeziehungen, wie bereits in Kapitel 3 erläutert. Sie werden dann im Analyse-Graph gelb markiert.

4.2 Front-End Startet man die Schnittstelle der Design-Analyse, so werden durch die Index-Funktion fünf Views aufgerufen. Zuerst wird die „head“-View geladen. Im Head-Bereich werden die CSS-Dateien geladen und zusätzlich die Javascript-Datei. Anschließend wird die „menu“-View aufgerufen und dann die View „vDatoolStart“, die lediglich eine Willkommensmeldung enthält. Zum Schluss wird die „foot“-View aufgerufen. Diese enthält die Copyright-Angabe sowie den schließenden Body und das HTML-Tag. Begonnen wird mit dem Menüpunkt „Configuration Items“, der um zusätzliche Attribute ergänzt wird. Zu jedem CI existieren

ganz rechts vier mögliche Aktionen. Klickt man auf das Plus-Symbol, so lässt sich in zwei Schritten ein neues CI anlegen. Im ersten Schritt gelangt man zu einer Kategorieauswahl (siehe Abbildung 29).

Abbildung 7: CI anlegen, Kategorieauswahl Hier muss die Kategorie des neuen CIs ausgewählt werden. Anschließend gelangt man zu einem Formular, in dem alle Attribute eines CIs aufgelistet sind. Dazu gehören die Grundattribute, die jedes CI besitzt, die Unterkategorie und zusätzliche Attribute, die das alte Tool ergänzen − wie etwa das Attribut „Konfig-Dateien“. Diese Felder sind optional und somit nicht zwingend auszufüllen. Abbildung 30 zeigt das Eingabeformular, bei dem als Kategorie „Software“ und als Unterkategorie „Workflowsysteme“ gewählt wurde.

Abbildung 8: CI anlegen, Kategorie- und Unterkategorieauswahl Wählt man die Unterkategorie „Server“, so werden rechts nebenan zusätzliche Attribute und Felder gezeigt (Abbildung 31).

Abbildung 9: Erfassung der Unterkategorie Server Wurde ein obligatorisches Feld nicht ausgefüllt, so wird eine entsprechende Meldung gezeigt (siehe Abbildung 32).

Abbildung 10: Erzeugung einer Fehlermeldung beim Ausfüllen des Formulars Darunter befinden sich zwei Dropdownfelder.

Nun wird die Unterkategorie „Punkt“ betrachtet. In diesem Bereich bekommt man zuerst alle bestehenden Unterkategorien aufgelistet (siehe Abbildung 33).

Abbildung 11: Auflistung aller Unterkategorien

Durch das Plus-Symbol gelangt man zu dem Formular, mit dem sich eine neue Unterkategorie anlegen lässt (siehe Abbildung 34).

Abbildung 12: Neue Kategorie anlegen Zuerst muss ein Name für die dazugehörige Kategorie gewählt und die neue Unterkategorie erfasst werden. Anschließend können die Attribute angegeben werden.

Um nach dem Anlegen einer neuen Kategorie und Unterkategorie die Beziehungsarten zu erfassen, müssen diese vor dem Erstellen der CIs noch gespeichert werden. Wie auch bei den anderen Bereichen werden zunächst alle bestehenden Beziehungsarten in einer Liste dargestellt.

Die nächste Abbildung (Abbildung 35) zeigt die statische Struktur der Anwendung, die Eigenschaften der Klassen (Attribute), das Verhalten (Operationen) der Klassen und die Beziehungen zwischen allen Klassen. Nach dem Klick auf das Klassendiagrammsymbol zeigt diese optionale Funktion das Klassendiagramm der Anwendung an.

Abbildung 13: Klassendiagramm anzeigen

Anschließend folgt die Analyse. Dieser Bereich ist speziell für die Analyse von CIs gedacht. Hier muss zunächst die Kategorie ausgewählt werden, die analysiert werden soll. Im nächsten Schritt werden alle CIs der entsprechenden Kategorie aufgelistet, die eine Beziehung zu einem andern CI besitzen. Zu jedem dieser CIs kann eine Abhängigkeits- und eine Szenarioanalyse durchgeführt werden. Zudem ist es möglich, für jede Analyse einen Graphen zu erstellen, der alle Kategorien, Unterkategorien und Config-items sowie die Beziehungen darstellt.

5 Grafische Umsetzung der Ergebnisse

5.1 Visualisierung der Analyse

5.1.1 Abhängigkeitsanalyse Zur Ansteuerung des Analysewerkzeugs wurde mit Hilfe von jQueryWidget und PHP die grafische Benutzeroberfläche des bisher entwickelten Tools weiterentwickelt. In diese wurde eine Visualisierung der Abhängigkeitsstruktur der SOA-Komponenten integriert, über die zwei Graphen zur Analyse erzeugt werden. Der eine bildet alle Komponenten zusammen mit Kategorie und Subkategorie ab und der andere zeigt die Abhängigkeiten zwischen allen Komponenten. Das vorliegende Kapitel erläutert, wie dies umgesetzt worden ist. Im vorangegangenen Abschnitt wurde bereits das Frontend beschrieben. Auf diesem baut nun die Visualisierung auf. Nachdem der Nutzer die zu analysierende Komponente ausgewählt hat, wird zuerst die passende Kategorie und Unterkategorie gewählt. Über die GUI können nun die gewünschten Attribute selektiert werden.

Abbildung 36 zeigt die fertige Visualisierung dieses Vorgangs. Ihre genaue Realisierung wird im Folgenden beschrieben.

Abbildung 14: Darstellung der Kategorie, Unterkategorie, CI und der Beziehungen Da es zwei Kategorien von Relationen gibt, werden diese entsprechend rot (Implementierungsbeziehung) oder gelb (Referenzbeziehung) gefärbt. Die grünen Kästchen symbolisieren die Konfigitems, die weißen die Unterkategorien und die blauen Kästchen stellen die Kategorien dar.

In Abschnitt 4 wurde bereits eine Datenstruktur zur Darstellung oder Einrichtung einer Datasource oder Konfiguration und zur Installation eines Servers in Form eines Graphen beschrieben. Hierauf baut nun die Visualisierung auf.

Nachdem der Nutzer die zu analysierende Komponente ausgewählt hat, wird als Erstes der erwähnte Graph in Abbildung 36 erzeugt. Die gewünschte Kategorie kann über die GUI selektiert werden. Die Visualisierung der Analyse erfolgt mit Hilfe einer JavaScript-Komponente, die es ermöglicht, den Graphen als Baum darzustellen. Mittlerweile existieren zahlreiche JavaScript-Bäume, und die meisten von ihnen haben eine bessere Cross-Browser-Kompatibilität als der hier dargestellte und sind schneller und besser optimiert. Das Ziel dieses Kodex ist es, eine Client-seitige Umsetzung der Walker-Layout-Algorithmus zu präsentieren. Nun wird anhand des Codes erklärt, wie diese Baumstruktur aufgebaut ist. Zunächst müssen das Script für die Komponente und der Link des Style-sheet in der <head> Sektion für die HTML-Seite der Analyse integriert werden:

<head>

</head>

Um verschiedene Browser nutzen zu können (z. B. den Internet-Explorer oder Mozilla-Firefox) wird das Skript in die <head> Sektion der HTML-Seite integriert:

<head>

</head>

Anschließend wird der Block-Container für die HTML-Seite eingerichtet, zusammen mit dem Tag <div> und dessen ID. Um die Baumstruktur erstellen und die Knoten der Datenbank-Daten einfügen zu können, muss jetzt die <script> block integriert werden. Dann wird der Baum gezeichnet:

myTree = new ECOTree("myTree","myTreeContainer");

myTree.UpdateTree();

Es muss sichergestellt werden, dass das Skript-Block ausgeführt wird, sobald die Seite geladen wird, oder zumindest dann, wenn der Behälter geladen ist. Hier besteht die Möglichkeit, das Skript nach dem Container einzufügen oder den Baum mit einer Funktion zuerstellen, die jeweils aufgerufen wird, wenn das OnLoad-Ereignis für das Dokument oder Body-HTML eintritt. Hier ist zu beachten, dass die Komponente „Standardwerte“ für fast alle Bereiche gilt. Im nächsten Code-Abschnitt kann der Baum erstellt oder erweitert werden. So können Aussehen und Verhalten des Baums optimal an die Bedürfnisse des Nutzers angepasst werden. Dies erfolgt in der Szenario-Analyse mit Hilfe der Config-Instanz „Mitglied des Baumes“. Wir ändern nun das vorherige Beispiel durch das Einfügen einiger Zeilen:

Abbildung 15: Erzeugung einer Baumstruktur Wie bereits erläutert, gibt es zwei Beziehungsarten, die entweder gelb oder rot markiert sind.

Abbildung 38 illustriert die Struktur des Baumes und zeigt die fertige Visualisierung der allgemeinen Analyse. Dabei handelt es sich nur um einen Ausschnitt des Analyse-Graphen, und zwar für das Configurations-Item BPEL.

Abbildung 16: Visualisierung der Abhängigkeitsstruktur Nun wird die Abhängigkeitsanalyse der Java-EE-Anwendung auf einem weiteren Graphen visualisiert. Hier ist eine Auflistung der Komponenten in Form einer Baumstruktur zu sehen. Die unterschiedlichen Arten von Beziehungen sind jeweils durch verschiedenfarbige Kästchen gekennzeichnet, und zwar entweder mit roter oder gelber Farbe.

5.1.2 Scenarioanalyse Bei der Scenarioanalyse können Konfigurationsitem,Kategorien,Unterkategorien oder Beziehungen in der Analysegraph gelöscht bzw. Geändert werden.Man wählt das Icon für die Scenarioanalyse dann wählt man zwischen Ändern oder Löschen-Option wie in Abbildung 39 gezeigt.

Abbildung 39 : Löschen und Ändern –Option bei der Scenarioanalyse

Danach wie in Abbildung 40 dargestellt ist kann man durch das Kreuz die Konfigitem löschen dann wird der neue Graph für die Analyse gezeigt ohne die gelöschte Konfigurationsitem sowie die dazugehörigen Beziehungen zu andere Komponente,sodass alle untergeordnete Komponente in der Baum gelöscht werden.

Abbildung 40 : Löschen–Option bei der Scenarioanalyse Bei Der Änderung-Option können neue Konfigitem zur Graph hinzugefügt werden durch das Icon(+ADD) sowie können die schon bestehende Konfig iten direkt geändert werden,die nächste Abbildung zeigt ein Auschnitt von der Graph der Scenario-Analyse.

Abbildung 41 : Ändern–Option bei der Scenarioanalyse

6. Evaluation In der vorliegenden Arbeit wurde das Tool zur Abhängigkeitsanalyse von SOA-Komponenten vorgestellt. Das Ziel bestand darin, Graphen zu erschaffen, die SOA-Komponenten und deren Abhängigkeiten voneinander perfekt nachbilden. Das Tool sowie das Analyseverfahren sollen nun durch Testpersonen getestet werden, die mit Hilfe einer Usability dazu aufgefordert werden, einen typischen Ablauf durchzuspielen. Zunächst sollen die Testpersonen jeweils eine neue Kategorie und Unterkategorie anlegen, dann mehrere CIs. Anschließend gilt es, diese zu ändern und eine oder mehrere Beziehungsarten anzulegen, um die Beziehungen zwischen den betreffenden Komponenten zu erstellen. Für die Scenario-Analyse sollen auf die gleiche Weise die Beziehungen oder CIs in der Graphanalyse geändert oder gelöscht werden.

6.1 Vorgehensweise

Die Ergebnisse der Evaluation sind in zwei Sektionen aufgeteilt. Zunächst findet eine detaillierte Auswertung statt, anschließend wird gesondert auf Bugs im Tool eingegangen. Die Erzeugung von Analyse-Graphen dient vordergründig dem Zweck, das Tool hinsichtlich seiner Bedienung zu untersuchen und seine Eignung zur Erzeugung von visualisierten Abhängigkeiten zu prüfen. Eine Liste von Vorschlägen zu weiteren Funktionen, die derzeit noch fehlen, ergänzt diesen ersten Abschnitt.

Anschließend wird geklärt, ob die Visualisierung hinreichend gut erkennbar ist, und untersucht, ob das Tool im Praxiseinsatz Vorteile bringt. Zu diesem Zweck werden bestimmte Usability-Testpersonen aufgefordert, einen typischen Ablauf durchzuspielen. Die erzeugten Modelle werden diskutiert und die Ergebnisse aus dem Diskurs fließen mit in die Evaluation ein. Zuletzt werden die Ergebnisse der Arbeit vorgestellt sowie Bugs aufgeführt und bewertet.

6.2 Ergebnisse der Evaluation

6.2.1 Qualitative Auswertungen

Dieser Abschnitt befasst sich mit dem Tool als Werkzeug zur Visualisierung von Abhängigkeiten der SOA-Komponenten. Zuerst werden ausgewählte Guidelines diskutiert, danach die Bedienung vom Tool kritisch untersucht und zuletzt Empfehlungen für weitere sinnvolle, bislang noch nicht implementierte Funktionen gegeben.

Die Erstellung neuer Modelle durch Hinzufügen von Konzepten samt ihren Abhängigkeiten ist eine zentrale Funktion des Tools. Die Eingabe sollte einfach und unkompliziert sein und so zügig wie möglich erfolgen.

Auswertung:

Ein Analysegraph lässt sich schnell erzeugen. Die Abhängigkeiten lassen sich ebenso rasch einpflegen. Die Bestimmung der Beziehungsart ist ebenfalls wenig intuitiv gestaltet. Die Integration neuer Beziehungen erfordert jedoch im gesamten Tool immer wieder Korrekturen, da nicht immer eine automatische Verbindung zu allen CIs möglich ist. Das nachträgliche Editieren von Beziehungen, CIs, Kategorien oder Unterkategorien und die nachträgliche Bearbeitung der Analyse-Modelle im Ganzen sollten einfach möglich sein. Das Tool enthält keinen speziellen Editier-Modus. Alle Änderungen müssen daher im Manipulations-Modus durchgeführt werden. Aufgrund dessen gelten hier die gleichen Einschränkungen wie bei der Eingabe eines neuen CI. Bei dem Graphen handelt es sich um einen Verständnisgraphen für das jeweilige Komplexitätslevel; deshalb werden die Analysegraphen nicht zwingend die Reihenfolge der Kategorien einhalten. Dies könnte man umgehen, indem man Graphen für jede Kategorie und Unterkategorie erzeugt. Modelle, die Komplexitätslevel einzeln abbilden, sind zu diesem Zweck besser geeignet. Solche Modelle beinhalten inhaltlich verwandte Kernbegriffsblätter und zeigen alle Abhängigkeiten der jeweiligen Kategorie.

Die Graphen, die im Rahmen dieser Bachelorarbeit gebildet wurden, orientieren sich ohnehin an den Kernbegriffen und Abhängigkeiten der SOA-Komponenten und bilden diese nach. Für einen solchen Fall ist das Tool gut geeignet, um die entsprechenden Abhängigkeiten zu visualisieren. Im Folgenden wird gesondert auf die Bedienbarkeit des Tools eingegangen. Zuerst werden die Probleme aufgezeigt, die sich bei der Arbeit mit dem Tool ergeben haben, und anschließend Vorschläge zu fehlenden oder zu verbessernden Funktionen gemacht.

Probleme:

Es gibt keine Buttons oder sonstige visuelle Hinweise, wie z. B. Tooltips. Eine kontextabhängige Bedienung ist ebenfalls nicht implementiert, sodass alle Funktionen auswendig gelernt werden müssen. Auch eine Kurzanleitung ist nicht verfügbar. Zudem hat das Tool Probleme, Graphen zu erstellen, die viele Kategorien und Abhängigkeiten zugleich beinhalten.

Das Tool verfügt auch nicht über benutzerfreundliche Eingabehilfen. Die Eingabe von CIs und besonders deren nachträgliche Modifikation muss immer manuell erfolgen. An dieser Stelle werden über die allgemeinen Probleme hinaus bestimmte Funktionen des Tools betrachtet und Vorschläge gemacht, die die Arbeit mit dem Konfigurationdatenbank erleichtern. werden kann. Soweit nicht anders notwendig, werden sie stichwortartig aufgelistet.

Visualisierung:

 Zoomfunktion: Das Zoomen des sichtbaren Analyse-Bereichs ist eine unverzichtbare Funktion, die es ermöglicht, große Modelle effektiv zu betrachten.  Automatisches Layout im Analyse-Graphen: Dies ist eine Funktion, die Konzepte automatisch im Graphen anordnet und durch Verschieben der Komponente eine manuelle Positionierung ermöglicht. Kleine Änderungen haben meist eine große Änderung im Layout zur Folge, sodass das Positionieren sehr viel Zeit in Anspruch nimmt. Das Problem verschärft sich noch, wenn man große Modelle benutzt, da es keine Zoomfunktion gibt und große Modelle nur sehr langsam und mit einer schlechten Reaktionszeit aktualisiert werden. Grundsätzlich sollten inhaltlich eng zusammenhängende bzw. abhängige Konzepte auch visuell zusammen platziert werden.

 Reaktionsgeschwindigkeit: Die Arbeitsgeschwindigkeit des Tools bei großen Projekten muss erhöht werden. Befinden sich viele Komponenten im momentan sichtbaren Arbeitsbereich, ist die Reaktionsgeschwindigkeit des Tools auf Eingaben sehr langsam.

 Kommentarfelder: Die Texteingabefelder bzw. Konzeptbeschreibungsboxen sollten sich in der Graphanalyse anzeigen lassen, sodass auch zusätzliche Beschreibungen der CI und von deren Beziehungen möglich sind.

 Art der Abhängigkeit: Eine Möglichkeit bestände darin, die Art der Relation durch verschiedene Pfeilverbindungen, durch eindeutige Symbole oder weitere Farben anzeigen zu lassen.

 Visuelle Ausdruckskraft: Die visuelle Ausdruckskraft ist im Tool gegeben. Die verschiedenen CIs und Beziehungen werden durch farbliche Unterscheidungen deutlich hervorgehoben. Auch die möglichen Abhängigkeiten, die durch die Graphen zur Verfügung gestellt werden, werden abgebildet. Leider fehlt es den Verbindungen jedoch an intuitiver Ausdruckskraft. Anhand der Farbe ist zwar sofort ersichtlich,

welche Art von Beziehung vorliegt. Es ist aber nur eingeschränkt möglich, die Art der Relation der jeweils anderen Perspektive zu erkennen. Gestrichelte und gepunktete Linien sind Beispiele für eine mögliche Lösung. Ausnahmen stellen die implizierten Mindestabhängigkeiten dar.

Leider könnte das Hinzufügen von neuen CI-Items und deren Beziehungen dazu führen, dass diese ohne Abhängigkeiten frei im Graphen stehen. Das liegt daran, dass es zwar CIs aus mehreren Kategorien gibt, ihre gesamten Abhängigkeiten aber nur in jeweils einer Kategorie enthalten sind.

Das Tool ist dazu geeignet, besondere Anwendungen wie etwa JAVA-EE auf ihre Funktionalität hin zu analysieren. Gerade solche kleinen Mängel und Ungereimtheiten in der Konzeption des Lehrkonzepts wurden in dem Diskurs mit Schmolitzky thematisiert. Weil nicht nur jedes Modell, sondern insbesondere auch jedes Konzept aufgrund der vielen Abhängigkeiten mehrfach betrachtet wurde, treten auch kleinste Mängel oder Ungereimtheiten in den Kernbegriffstexten deutlich hervor. Ein Vorschlag, um die angesprochenen Probleme zu lösen oder zumindest zu verbessern, bestände darin, bei der JAVA-EE-Anwendung innerhalb einer Klassendefinition die Methoden der eigenen Klasse direkt aufzurufen (d. h. ohne Objektname und Punkt). Auch innerhalb einer Klassendefinition können die Methoden der eigenen Klasse direkt aufgerufen werden. Die Einarbeitungszeit im Tool gestaltet sich wenig aufwendig, da sich die Netto-Zeit zur reinen Eingabe von CIs und zum Erstellen von Analyse-Graphen nach der Einarbeitungsphase auf maximal 5 Minuten pro Analyse beläuft, wobei sich die Anzahl der CIs und Abhängigkeiten in größeren Modellen auf diese Zeitspanne auswirkt. Je nach Komplexität und bereits vorliegenden Ergebnissen der zu untersuchenden Anwendungen oder SOA-Komponenten differiert die Dauer erheblich. Sie lässt sich nicht quantifizieren. Ein weiteres Ergebnis ist die Anzahl an Modellen, die zu einem bestimmten Thema erzeugt werden können. Sie schwankt sehr stark. Zwar geben die SOA-Konzepte einen Rahmen vor, aber gerade die Möglichkeit der verschiedenen SOA-Architekturen und Software-Anwendungen lässt viel Spielraum für unterschiedliche Modelle.

Die im Rahmen dieser Bachelorarbeit erzeugten Modelle bilden eine gute Grundlage für weitere Diskussionen. Zum gegenwärtigen Zeitpunkt eignen sich die Graphen zur Analyse

lediglich für den experimentellen Einsatz. Ein möglicher Einsatz im Firmen-Umfeld ist noch nicht zu empfehlen.llenverzeichnis ACTIVE ENDPOINTS ActiveBPEL Designer Version: 4.1 [S:ActiveBPEL]: http://www.active-endpoints.com/active-bpel-designer.htm.

ALLWEYER, T. (2008): BPMN. Business Process Mo deling Notation. Einführung in den Standard für die Geschäftsprozessmodellierung , Books on Demand, Norderstedt.

APACHE SOFTWARE FOUNDATION: Ant Version: 1.7.0 [S: Ant]: http://ant.apache.org/. APACHE SOFTWARE FOUNDATION: Apache Axis2/Java Version: 1.3 [S:ApacheAxis2]: http://ws.apache.org/axis2/. GREWER, Lukas (2012): Konzeption einer Konfigurationsdatenbank für eine serviceorientierte Architektur zum Zweck der Analyse von Abhängigkeiten, Bachelorarbeit im Fachbereich Informatik, Department of Computer Science der Fachhochschule Bonn-Rhein-Sieg.

HESS, Andreas/ Humm, Bernhard/ Voß, Markus (2006): Regeln für serviceorientierte Architekturen hoher Qualität, Informatik Spektrum. HUNTER, JASON (2000): JDOM. Online: http://www.jdom.org/, zuletzt abgerufen am: 31.03.2013.

HUVAR, Martin/ Falter, Timm/ Fiedler, Thomas/ Zubev, Alexander (2008): Anwendungsentwicklung mit Enterprise SOA, Galileo Press, Bonn. JBOSS (2007): JBoss J2EE DTDs. Online: http://www.jboss.org/j2ee/dtd/, zuletzt abgerufen am: 31.03.2013.

JOSUTTIS, Nicolai (2009): SOA in der Praxis. System-Design für verteilte Geschäftsprozesse, Dpunkt-Verl., Heidelberg.

KÖHLER, Peter T (2007): ITIL: Das IT-Servicemanagement Framework. 2., überarbeitete Auflage, Springer-Verlag, Berlin/Heidelberg.

LIEBHART, Daniel (2007): Service-orientierte Architekturen erfolgreich planen und einführen, Hanser, München.

MELZER, Ingo (Hrsg.) (2010): Service-orientierte Architekturen mit Web Services. Konzepte – Standards – Praxis, Spektrum Akademischer Verlag, Berlin.

DERS. (2008): Service-orientierte Architekturen mit Web Services 3, Spektrum, Heidelberg.

MUEHLEN zur,Michael (2007) [Mueh07]: BPM Conference Tutorials – Business Process Management Standards, 5th International Conference on Business Process Management September 2007; Online: http://bpm07.fit.qut.edu.au/program/slides/Thursday/Thursday-

Tutorials/Muehlen.pdf.

STOIKE, Christoph (2007): Konfiguration von Java-Applikationen durch Abhängigkeitsanalyse, Diplomarbeit am Institut für Informatik, Lehrstuhl für Programmiersprachen und Übersetzerkonstruktion der Christian-Albrechts-Universität zu Kiel.

SUN MICROSYSTEMS, INC. (2007): JAXB. Online: https://jaxb.dev.java.net/, zuletzt abgerufen am: 31.03.2013.

SUN MICROSYSTEMS, INC. (2007): J2EE DTDs. Online: http://java.sun.com/dtd/, zuletzt abgerufen am: 31.03.2013.SUN MICROSYSTEMS: Java Standard Edition (J2SE) JDK 5.0 Update 14

Version: 1.5.0_14 [S:JDK5]: http://java.sun.com/javase/downloads/index_jdk5.jsp:.

ZÖLLER-GREER, Peter (2010): Software-Architekturen, Grundlagen und Anwendungen, Composia-Verl., Wächtersbach.

9 Anhang

9.1 Evaluierungsbogen

Evaluation (Usability-Test) Bitte führt die folgenden Punkte aus und gebt ein Feedback, was ihr von dem Programm haltet und wo es eurer Meinung nach noch Verbesserungsmöglichkeiten gibt.

1) Anlegen einer neuen Kategorie.

Als Namen verwendet bitte euren Namen. Bitte beachtet bei den Attributen, dass mit Typ-Werten solche Werte wie VARCHAR oder INT gemeint sind (also die Datentypen aus einer Datenbank).

Legt für eure Kategorie bitte 2-3 Attribute an.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

2) Anlegen einer neuen Unterkategorie.

Ordnet der Unterkategorie euren Namen zu.

Verbesserung / Was ist euch aufgefallen?

___________________________________________________________________

3) Beziehungsarten anlegen

Hier gibt es 2 Möglichkeiten: Yellow- oder Red-Beziehungen. Red: Die Implementierungs-beziehung betrifft alle Beziehungen und ist im Allgemeinen das Ergebnis von Entwurfsentscheidungen, bei denen jeder Entwurf jedes einzelnen Konfigurationsitems auf realisierende Konfigurationsitems abgebildet wird.

Yellow: Bei der Aggregationsbeziehung werden die Komponenten vom Aggregat existenzabhängig, das heißt, eine Erzeugung des Aggregats erzeugt auch die Komponenten und die Löschung des Aggregats löscht auch die Komponenten.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

3) Anlegen neuer Configurationsitems.

Legt bitte mindestens vier Configurationsitems an.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

4) Editieren von Configurationsitems.

Editiert bitte einige eurer Configurationsitems.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

5) Beziehungen erstellen

Erstellt einige Beziehungen zwischen euren CIs. Es gibt zwei mögliche Arten.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

6) Analyse durchführen (alle vier bitte)

Führt bitte zu eurer Kategorie alle Analysen durch.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

Wer noch Lust und Zeit hat, darf gerne alles testen. Nur, löscht bitte keine Kategorien oder CIs, die ihr nicht angelegt habt.

Allgemeines Feedback:

__________________________________________________________________

Die Daten, die für die Aufbereitung und Analyse erforderlich sind, werden von den Models in neun Konfigurationsdatenbanken geladen und an den Controller weitergegeben, der sie aufbereitet und sie anschließend in Form eines Arrays zur Darstellung an die Views (Front-End) übergibt.

Die Tabelle „Unterkategorien“ besteht aus den Attributen „idKategorie“, „idUnterKategorie“ und „Name“; den Primärschlüssel bildet das ID-Attribut. In dieser Tabelle werden alle Unterkategorien, die in der Design-Analyse angelegt werden, mit Namen gespeichert. Die Tabelle ist über einen Fremdschlüssel mit den Tabellen „Beziehungsarten“ und „Kategorie“ verbunden. Das Attribut „UnterKategorie“ enthält die ID einer UnterKategorie aus der Tabelle „Unterkategorien“.

Beim Aufruf des Menüeintrags „Unterkategorie Kategorie“ wird im Controller die Funktion „showlistUnterKategorie“ (siehe Abbildung 24) aufgerufen.

Abbildung 2: Funktion show UnterKategorie

Diese Funktion legt zuerst für den nächsten Datenbank-Aufruf eine „Order By“-Bedingung für das Feld „idUnterKategorie“ fest. Anschließend wird in dem assoziativen Array „data“ ein neuer Index mit der Bezeichnung „Subkategorie“ angelegt, der die Daten einer Abfrage aufnimmt. Diese Daten bezieht das System über den Aufruf der Funktion „getRecordsubKategorie“ aus dem Subkategorie-Modell.

Abbildung 3: Funktion getRecord UnterKategorie

Diese Funktion schickt eine Abfrage an die Tabelle „UnterKategorie“ der Datenbank und erhält alle Daten dieser Tabelle zurück. Anschließend werden die Daten als assoziatives Array zurückgeliefert, wobei die Attributnamen als Schlüssel dienen. Anschließend werden alle Views zur Darstellung aufgerufen. Der View, den die Liste der Unterkategorien erstellt, wird an das zuvor angelegte Array mit den Daten zu den Subkategorien übergeben.

In Bezug auf Subkategorien gibt es noch zwei weitere Funktionen zum Erstellen und Löschen einer Kategorie.

Nun erstellt die Funktion „CreateUnterKategorie“ die folgenden neuen Unterkategorien:

Abbildung 4: Funktion create UnterKategorie

Zu diesem Zweck legt sie zunächst eine Validierungsregel fest, die verhindert, dass das Eingabefeld mit dem Namen „name“ später im Formular der View leergelassen wird. Anschließend entscheidet eine If-Anweisung, ob die Validierungsregel eingehalten wurde. Wenn dies nicht der Fall ist, wird die View zum Erstellen einer neuen Subkategorie erneut aufgerufen. Wird die Validierung positiv beendet, so erfolgt die Verarbeitung der Else-Anweisung. Hier wird zunächst der Wert für den Namen der neuen Subkategorie in ein Array gespeichert. Anschließend werden alle in der View eingetragenen Attribute dieser Subkategorie mit Hilfe einer Schleife in einem neuen Array gespeichert und daraufhin mit diesen beiden Arrays zwei Funktionen aus dem Subkategorien-Modell aufgerufen.

Die letzte Funktion zum Bereich der SubKategorie ist die „deleteKategorie“ (siehe Abbildung 27).

Abbildung 5: Funktion deleteUnterKategorie

Diese Funktion holt sich zuerst über das Subkategorien-Modell die Daten zu dem zu löschenden Datensatz und speichert sie in einem Array zwischen. Mit Hilfe dieser Daten wird nun der Name der betreffenden Subkategorie ermittelt. Da der Name einer Subkategorie immer identisch mit demjenigen der dazugehörigen Tabelle ist, wird nun unter dieser Voraussetzung und der ID der Subkategorie die Funktion „deletesubKategorie“ aus dem Subkategorien-Modell aufgerufen. Diese löscht den dazugehörigen Eintrag in der Tabelle „Unterkategorien“ und die zur Unterkategorie gehörende Tabelle. Nach dieser Löschung wird mit Hilfe des Subkategorienamens noch der zugehörige Template-Name ermittelt und anschließend das Template gelöscht. Zuletzt wird die Funktion „listUnterKategorie“ (siehe Abbildung 16) aufgerufen.

4.1.2 Attribute

Zu einer CI werden zahlreiche Attribute definiert. Durch eine eindeutige Bezeichnung der Version „Status CI-Typ“ wird die Beziehung zu anderen CIs beschrieben.

Daneben gibt es noch weitere Attribute, die an dieser Stelle unbedingt erwähnt werden müssen, weil sie für bestimmte Komponenten relevant sind, und zwar die folgenden: Plattform, Webcontainer, OSGI, JAX-WS oder JAX-RS. Für die Unterkategorie „Server“ z. B. sind diese Attribute von großer Bedeutung. Sie ergänzen die von Grewer [2012] in seiner Arbeit

erwähnten Service- und Basis-Attribute, die in Abbildung 28 dargestellt sind. CIs sollten möglichst alle, zumindest jedoch einige dieser Attribute besitzen.

Abbildung 6: Allgemeine Attribute, Service-, Basis- und Serverattribute

Die Basis- und Service-Attribute werden von Grewer übernommen. Abbildung 28 zeigt die zusätzlichen Serverattribute, die in das Tool integriert werden. Dies betrifft die Relationen und Beziehungen sowie den Status der CI, die ebenfalls aus der Arbeit von Lukas Grewer übernommen werden.

4.1.3 Beziehungsarten

Die Beziehungen werden analog zum alten Tool erfasst. Zur Erfassung der Beziehungsarten im Menü wird ein neues Dropdownfeld eingerichtet, das vom Grundprinzip her genauso funktioniert wie die äquivalente Funktion im Bereich „Unterkategorie“. In der Funktion werden zunächst zwei Kategorien von Beziehungsarten eingefügt. Die erste Kategorie umfasst Beziehungsarten, die in der Analyse rot gefärbt sind, und deutet auf eine Konfigurations- bzw. Implementierungsbeziehung hin. Die zweite Kategorie bilden die Referenzbeziehungen, wie bereits in Kapitel 3 erläutert. Sie werden dann im Analyse-Graph gelb markiert.

4.2 Front-End

Startet man die Schnittstelle der Design-Analyse, so werden durch die Index-Funktion fünf Views aufgerufen. Zuerst wird die „head“-View geladen. Im Head-Bereich werden die CSS-Dateien geladen und zusätzlich die Javascript-Datei. Anschließend wird die „menu“-View aufgerufen und dann die View „vDatoolStart“, die lediglich eine Willkommensmeldung enthält. Zum Schluss wird die „foot“-View aufgerufen. Diese enthält die Copyright-Angabe sowie den schließenden Body und das HTML-Tag. Begonnen wird mit dem Menüpunkt „Configuration Items“, der um zusätzliche Attribute ergänzt wird. Zu jedem CI existieren

Abbildung 7: CI anlegen, Kategorieauswahl

Hier muss die Kategorie des neuen CIs ausgewählt werden. Anschließend gelangt man zu einem Formular, in dem alle Attribute eines CIs aufgelistet sind. Dazu gehören die Grundattribute, die jedes CI besitzt, die Unterkategorie und zusätzliche Attribute, die das alte Tool ergänzen − wie etwa das Attribut „Konfig-Dateien“. Diese Felder sind optional und somit nicht zwingend auszufüllen. Abbildung 30 zeigt das Eingabeformular, bei dem als Kategorie „Software“ und als Unterkategorie „Workflowsysteme“ gewählt wurde.

Abbildung 8: CI anlegen, Kategorie- und Unterkategorieauswahl

Wählt man die Unterkategorie „Server“, so werden rechts nebenan zusätzliche Attribute und Felder gezeigt (Abbildung 31).

Abbildung 9: Erfassung der Unterkategorie Server

Wurde ein obligatorisches Feld nicht ausgefüllt, so wird eine entsprechende Meldung gezeigt (siehe Abbildung 32).

Abbildung 10: Erzeugung einer Fehlermeldung beim Ausfüllen des Formulars

Darunter befinden sich zwei Dropdownfelder.

Nun wird die Unterkategorie „Punkt“ betrachtet. In diesem Bereich bekommt man zuerst alle bestehenden Unterkategorien aufgelistet (siehe Abbildung 33).

Abbildung 11: Auflistung aller Unterkategorien

Durch das Plus-Symbol gelangt man zu dem Formular, mit dem sich eine neue Unterkategorie anlegen lässt (siehe Abbildung 34).

Abbildung 12: Neue Kategorie anlegen

Zuerst muss ein Name für die dazugehörige Kategorie gewählt und die neue Unterkategorie erfasst werden. Anschließend können die Attribute angegeben werden.

Abbildung 13: Klassendiagramm anzeigen

5 Grafische Umsetzung der Ergebnisse

5.1 Visualisierung der Analyse

5.1.1 Abhängigkeitsanalyse

Zur Ansteuerung des Analysewerkzeugs wurde mit Hilfe von jQueryWidget und PHP die grafische Benutzeroberfläche des bisher entwickelten Tools weiterentwickelt. In diese wurde eine Visualisierung der Abhängigkeitsstruktur der SOA-Komponenten integriert, über die zwei Graphen zur Analyse erzeugt werden. Der eine bildet alle Komponenten zusammen mit Kategorie und Subkategorie ab und der andere zeigt die Abhängigkeiten zwischen allen Komponenten. Das vorliegende Kapitel erläutert, wie dies umgesetzt worden ist. Im vorangegangenen Abschnitt wurde bereits das Frontend beschrieben. Auf diesem baut nun die Visualisierung auf. Nachdem der Nutzer die zu analysierende Komponente ausgewählt hat, wird zuerst die passende Kategorie und Unterkategorie gewählt. Über die GUI können nun die gewünschten Attribute selektiert werden.

Abbildung 36 zeigt die fertige Visualisierung dieses Vorgangs. Ihre genaue Realisierung wird im Folgenden beschrieben.

Abbildung 14: Darstellung der Kategorie, Unterkategorie, CI und der Beziehungen

Da es zwei Kategorien von Relationen gibt, werden diese entsprechend rot (Implementierungsbeziehung) oder gelb (Referenzbeziehung) gefärbt. Die grünen Kästchen symbolisieren die Konfigitems, die weißen die Unterkategorien und die blauen Kästchen stellen die Kategorien dar.

Nun wird anhand des Codes erklärt, wie diese Baumstruktur aufgebaut ist. Zunächst müssen das Script für die Komponente und der Link des Style-sheet in der <head> Sektion für die HTML-Seite der Analyse integriert werden:

<head>

</head>

Um verschiedene Browser nutzen zu können (z. B. den Internet-Explorer oder Mozilla-Firefox) wird das Skript in die <head> Sektion der HTML-Seite integriert:

<head>

</head>

myTree = new ECOTree("myTree","myTreeContainer");

myTree.UpdateTree();

Abbildung 15: Erzeugung einer Baumstruktur

Wie bereits erläutert, gibt es zwei Beziehungsarten, die entweder gelb oder rot markiert sind.

Abbildung 16: Visualisierung der Abhängigkeitsstruktur

Nun wird die Abhängigkeitsanalyse der Java-EE-Anwendung auf einem weiteren Graphen visualisiert. Hier ist eine Auflistung der Komponenten in Form einer Baumstruktur zu sehen. Die unterschiedlichen Arten von Beziehungen sind jeweils durch verschiedenfarbige Kästchen gekennzeichnet, und zwar entweder mit roter oder gelber Farbe.

5.1.2 Scenarioanalyse

Bei der Scenarioanalyse können Konfigurationsitem,Kategorien,Unterkategorien oder Beziehungen in der Analysegraph gelöscht bzw. Geändert werden.Man wählt das Icon für die Scenarioanalyse dann wählt man zwischen Ändern oder Löschen-Option wie in Abbildung 39 gezeigt.

Abbildung 39 : Löschen und Ändern –Option bei der Scenarioanalyse

Abbildung 40 : Löschen–Option bei der Scenarioanalyse

Bei Der Änderung-Option können neue Konfigitem zur Graph hinzugefügt werden durch das Icon(+ADD) sowie können die schon bestehende Konfig iten direkt geändert werden,die nächste Abbildung zeigt ein Auschnitt von der Graph der Scenario-Analyse.

Abbildung 41 : Ändern–Option bei der Scenarioanalyse

6. Evaluation

In der vorliegenden Arbeit wurde das Tool zur Abhängigkeitsanalyse von SOA-Komponenten vorgestellt. Das Ziel bestand darin, Graphen zu erschaffen, die SOA-Komponenten und deren Abhängigkeiten voneinander perfekt nachbilden.

Das Tool sowie das Analyseverfahren sollen nun durch Testpersonen getestet werden, die mit Hilfe einer Usability dazu aufgefordert werden, einen typischen Ablauf durchzuspielen. Zunächst sollen die Testpersonen jeweils eine neue Kategorie und Unterkategorie anlegen, dann mehrere CIs. Anschließend gilt es, diese zu ändern und eine oder mehrere Beziehungsarten anzulegen, um die Beziehungen zwischen den betreffenden Komponenten zu erstellen. Für die Scenario-Analyse sollen auf die gleiche Weise die Beziehungen oder CIs in der Graphanalyse geändert oder gelöscht werden.

6.1 Vorgehensweise

Die Ergebnisse der Evaluation sind in zwei Sektionen aufgeteilt. Zunächst findet eine detaillierte Auswertung statt, anschließend wird gesondert auf Bugs im Tool eingegangen.

Die Erzeugung von Analyse-Graphen dient vordergründig dem Zweck, das Tool hinsichtlich seiner Bedienung zu untersuchen und seine Eignung zur Erzeugung von visualisierten Abhängigkeiten zu prüfen. Eine Liste von Vorschlägen zu weiteren Funktionen, die derzeit noch fehlen, ergänzt diesen ersten Abschnitt.

Zuletzt werden die Ergebnisse der Arbeit vorgestellt sowie Bugs aufgeführt und bewertet.

6.2 Ergebnisse der Evaluation

6.2.1 Qualitative Auswertungen

Auswertung:

Das Tool enthält keinen speziellen Editier-Modus. Alle Änderungen müssen daher im Manipulations-Modus durchgeführt werden. Aufgrund dessen gelten hier die gleichen Einschränkungen wie bei der Eingabe eines neuen CI.

Bei dem Graphen handelt es sich um einen Verständnisgraphen für das jeweilige Komplexitätslevel; deshalb werden die Analysegraphen nicht zwingend die Reihenfolge der Kategorien einhalten. Dies könnte man umgehen, indem man Graphen für jede Kategorie und Unterkategorie erzeugt.

Modelle, die Komplexitätslevel einzeln abbilden, sind zu diesem Zweck besser geeignet. Solche Modelle beinhalten inhaltlich verwandte Kernbegriffsblätter und zeigen alle Abhängigkeiten der jeweiligen Kategorie.

Im Folgenden wird gesondert auf die Bedienbarkeit des Tools eingegangen. Zuerst werden die Probleme aufgezeigt, die sich bei der Arbeit mit dem Tool ergeben haben, und anschließend Vorschläge zu fehlenden oder zu verbessernden Funktionen gemacht.

Probleme:

Das Tool verfügt auch nicht über benutzerfreundliche Eingabehilfen. Die Eingabe von CIs und besonders deren nachträgliche Modifikation muss immer manuell erfolgen.

An dieser Stelle werden über die allgemeinen Probleme hinaus bestimmte Funktionen des Tools betrachtet und Vorschläge gemacht, die die Arbeit mit dem Konfigurationdatenbank erleichtern. werden kann. Soweit nicht anders notwendig, werden sie stichwortartig aufgelistet.

Visualisierung:

 Zoomfunktion: Das Zoomen des sichtbaren Analyse-Bereichs ist eine unverzichtbare Funktion, die es ermöglicht, große Modelle effektiv zu betrachten.

 Automatisches Layout im Analyse-Graphen: Dies ist eine Funktion, die Konzepte automatisch im Graphen anordnet und durch Verschieben der Komponente eine manuelle Positionierung ermöglicht.

Kleine Änderungen haben meist eine große Änderung im Layout zur Folge, sodass das Positionieren sehr viel Zeit in Anspruch nimmt. Das Problem verschärft sich noch, wenn man große Modelle benutzt, da es keine Zoomfunktion gibt und große Modelle nur sehr langsam und mit einer schlechten Reaktionszeit aktualisiert werden. Grundsätzlich sollten inhaltlich eng zusammenhängende bzw. abhängige Konzepte auch visuell zusammen platziert werden.

 Art der Abhängigkeit: Eine Möglichkeit bestände darin, die Art der Relation durch verschiedene Pfeilverbindungen, durch eindeutige Symbole oder weitere Farben anzeigen zu lassen.

welche Art von Beziehung vorliegt. Es ist aber nur eingeschränkt möglich, die Art der Relation der jeweils anderen Perspektive zu erkennen.

Gestrichelte und gepunktete Linien sind Beispiele für eine mögliche Lösung. Ausnahmen stellen die implizierten Mindestabhängigkeiten dar.

Das Tool ist dazu geeignet, besondere Anwendungen wie etwa JAVA-EE auf ihre Funktionalität hin zu analysieren.

Gerade solche kleinen Mängel und Ungereimtheiten in der Konzeption des Lehrkonzepts wurden in dem Diskurs mit Schmolitzky thematisiert. Weil nicht nur jedes Modell, sondern insbesondere auch jedes Konzept aufgrund der vielen Abhängigkeiten mehrfach betrachtet wurde, treten auch kleinste Mängel oder Ungereimtheiten in den Kernbegriffstexten deutlich hervor.

Ein Vorschlag, um die angesprochenen Probleme zu lösen oder zumindest zu verbessern, bestände darin, bei der JAVA-EE-Anwendung innerhalb einer Klassendefinition die Methoden der eigenen Klasse direkt aufzurufen (d. h. ohne Objektname und Punkt). Auch innerhalb einer Klassendefinition können die Methoden der eigenen Klasse direkt aufgerufen werden.

Die Einarbeitungszeit im Tool gestaltet sich wenig aufwendig, da sich die Netto-Zeit zur reinen Eingabe von CIs und zum Erstellen von Analyse-Graphen nach der Einarbeitungsphase auf maximal 5 Minuten pro Analyse beläuft, wobei sich die Anzahl der CIs und Abhängigkeiten in größeren Modellen auf diese Zeitspanne auswirkt. Je nach Komplexität und bereits vorliegenden Ergebnissen der zu untersuchenden Anwendungen oder SOA-Komponenten differiert die Dauer erheblich. Sie lässt sich nicht quantifizieren.

Ein weiteres Ergebnis ist die Anzahl an Modellen, die zu einem bestimmten Thema erzeugt werden können. Sie schwankt sehr stark. Zwar geben die SOA-Konzepte einen Rahmen vor, aber gerade die Möglichkeit der verschiedenen SOA-Architekturen und Software-Anwendungen lässt viel Spielraum für unterschiedliche Modelle.

Die im Rahmen dieser Bachelorarbeit erzeugten Modelle bilden eine gute Grundlage für weitere Diskussionen. Zum gegenwärtigen Zeitpunkt eignen sich die Graphen zur Analyse

lediglich für den experimentellen Einsatz. Ein möglicher Einsatz im Firmen-Umfeld ist noch nicht zu empfehlen.llenverzeichnis

ACTIVE ENDPOINTS ActiveBPEL Designer

Version: 4.1 [S:ActiveBPEL]: http://www.active-endpoints.com/active-bpel-designer.htm.

ALLWEYER, T. (2008): BPMN. Business Process Mo deling Notation. Einführung in den Standard für die Geschäftsprozessmodellierung , Books on Demand, Norderstedt.

APACHE SOFTWARE FOUNDATION: Ant Version: 1.7.0 [S: Ant]: http://ant.apache.org/.

APACHE SOFTWARE FOUNDATION: Apache Axis2/Java Version: 1.3 [S:ApacheAxis2]: http://ws.apache.org/axis2/.

GREWER, Lukas (2012): Konzeption einer Konfigurationsdatenbank für eine

serviceorientierte Architektur zum Zweck der Analyse von Abhängigkeiten, Bachelorarbeit im Fachbereich Informatik, Department of Computer Science der Fachhochschule Bonn-Rhein-Sieg.

HESS, Andreas/ Humm, Bernhard/ Voß, Markus (2006): Regeln für serviceorientierte Architekturen hoher Qualität, Informatik Spektrum.

HUNTER, JASON (2000): JDOM. Online: http://www.jdom.org/, zuletzt abgerufen am: 31.03.2013.

HUVAR, Martin/ Falter, Timm/ Fiedler, Thomas/ Zubev, Alexander (2008): Anwendungsentwicklung mit Enterprise SOA, Galileo Press, Bonn.

JBOSS (2007): JBoss J2EE DTDs. Online: http://www.jboss.org/j2ee/dtd/, zuletzt abgerufen am: 31.03.2013.

JOSUTTIS, Nicolai (2009): SOA in der Praxis. System-Design für verteilte

Geschäftsprozesse, Dpunkt-Verl., Heidelberg.

KÖHLER, Peter T (2007): ITIL: Das IT-Servicemanagement Framework. 2., überarbeitete Auflage, Springer-Verlag, Berlin/Heidelberg.

LIEBHART, Daniel (2007): Service-orientierte Architekturen erfolgreich planen und einführen, Hanser, München.

MELZER, Ingo (Hrsg.) (2010): Service-orientierte Architekturen mit Web Services. Konzepte – Standards – Praxis, Spektrum Akademischer Verlag, Berlin.

DERS. (2008): Service-orientierte Architekturen mit Web Services 3, Spektrum, Heidelberg.

Tutorials/Muehlen.pdf.

SUN MICROSYSTEMS, INC. (2007): JAXB. Online: https://jaxb.dev.java.net/, zuletzt abgerufen am: 31.03.2013.

SUN MICROSYSTEMS, INC. (2007): J2EE DTDs. Online: http://java.sun.com/dtd/, zuletzt abgerufen am: 31.03.2013.

SUN MICROSYSTEMS: Java Standard Edition (J2SE) JDK 5.0 Update 14

Version: 1.5.0_14 [S:JDK5]: http://java.sun.com/javase/downloads/index_jdk5.jsp:.

ZÖLLER-GREER, Peter (2010): Software-Architekturen, Grundlagen und Anwendungen, Composia-Verl., Wächtersbach.

9 Anhang

9.1 Evaluierungsbogen

Evaluation (Usability-Test)

Bitte führt die folgenden Punkte aus und gebt ein Feedback, was ihr von dem

Programm haltet und wo es eurer Meinung nach noch Verbesserungsmöglichkeiten gibt.

1) Anlegen einer neuen Kategorie.

Als Namen verwendet bitte euren Namen.

Bitte beachtet bei den Attributen, dass mit Typ-Werten solche Werte wie VARCHAR oder INT gemeint sind (also die Datentypen aus einer Datenbank).

Legt für eure Kategorie bitte 2-3 Attribute an.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

2) Anlegen einer neuen Unterkategorie.

Ordnet der Unterkategorie euren Namen zu.

Verbesserung / Was ist euch aufgefallen?

___________________________________________________________________

3) Beziehungsarten anlegen

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

3) Anlegen neuer Configurationsitems.

Legt bitte mindestens vier Configurationsitems an.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

4) Editieren von Configurationsitems.

Editiert bitte einige eurer Configurationsitems.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

5) Beziehungen erstellen

Erstellt einige Beziehungen zwischen euren CIs. Es gibt zwei mögliche Arten.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

6) Analyse durchführen (alle vier bitte)

Führt bitte zu eurer Kategorie alle Analysen durch.

Verbesserung / Was ist euch aufgefallen?

__________________________________________________________________

Wer noch Lust und Zeit hat, darf gerne alles testen. Nur, löscht bitte keine Kategorien oder CIs, die ihr nicht angelegt habt.

Allgemeines Feedback:

__________________________________________________________________

Gefällt dir was du siehst? Teile es!

Kommentare

Registeren oder anmelden um zu kommentieren.

Glossar > Nach Fachbereich

Job einer Lektorin: Anmerkungen notieren

Job Lektor

Glossar > Nach Anwendung

Interview transkribieren

Glossar > Nach Anwendung

Auf Lass-andere-schreiben.de kannst du einen Schreibauftrag kostenfrei & unverbindlich einstellen und Angebote von verifizierten Textexperten erhalten.

Jetzt Schreibauftrag erstellen

Aufträge vergeben

Aufträge finden

Service

Unternehmen

Kontaktiere uns

+49 (0) 30/ 5 490 650 - 20

info@lass-andere-schreiben.de

Erhalte unseren Newsletter

International

Zahlungsarten

Partner & Freunde

Abschlussarbeit Im Studiengang Informatik SS 2014 Erweiterung einer Konfigurationsdatenbank zur Abhängigkeitsanalyse und Abbildung einer Service-orientierten Architektur

Kommentare

Neueste Beiträge

Zufällige Beiträge

Zufällige Glossareinträge