Diplomarbeit. Entwurf eines Architekturmodells zur Integration heterogener Systeme in MeDIC. Andreas Steffens. Februar, 2013

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit. Entwurf eines Architekturmodells zur Integration heterogener Systeme in MeDIC. Andreas Steffens. Februar, 2013"

Transkript

1 Fakultät für Mathematik, Informatik und Naturwissenschaften Lehr- und Forschungsgebiet Softwarekonstruktion Diplomarbeit Entwurf eines Architekturmodells zur Integration heterogener Systeme in MeDIC Andreas Steffens Februar, 2013 Gutachter: Prof. Dr. rer.nat. Horst Lichter Prof. Dr. rer.nat. Bernhard Rumpe Betreuer: Dipl.-Inform. Matthias Vianden

2

3 Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Aachen, den 13. Februar 2013 Andreas Steffens Erkl.

4

5 Inhaltsverzeichnis I. Einleitung 1 1. Einleitung Übersicht über die Arbeit MeDic - Metric-Based Project and Process Management ISO Das Messinformations-Modell Metriken Dashboards Informationsbedürfnisse Architektur Praktische Grundlagen - Java Enterprise Edition JEE-Server Enterprise Java Beans Dienste und APIs II. Integration Integration - Definition und Eigenschaften Definition Qualitätskriterien einer Integrationslösung Anforderungen an den Entwurf Heterogenität Datenheterogenität Systemheterogenität Funktionsheterogenität Kommunikationsheterogenität Heterogene Interpretation Verfügbarkeit oder Verteilte Heterogenität Asynchrone oder autonome Integration Performance Operationelle Sensibilität Erweiterbarkeit Zusammenfassung i

6 III. Integrationsarchitektur für MeDIC Integrationsarchitekturen Typen von Integrationslösungen Integration über Dateien Gemeinsame Datenbank Service-Orientierte-Architektur (SOA) Messaging Integration mit Agenten Zusammenfassung Vorhandene Lösungen für Projektdashboards Software Process Dashboard Project PSP - Personal Software Process Integrationseigenschaften Bewertung Pentaho Business Intelligence Suite Integrationseigenschaften Bewertung Rational Insight Integrationseigenschaften Bewertung Weitere Lösungen QMetric SiSSy/QBench CAST Zusammenfassung Architekturentwurf für MeDic Systemumgebung Schichten Datenfluss Enterprise Metric Data Bus Enterprise Service Bus Anpassungen für MeDIC Komponenten und Schnittstellen Scheduler Gateway Adapter Monitor Message Archiv EOMDirectory Messagebroker Metrikmodelle Nachrichten Namensräume Architektur Hot-Spots ii

7 7.8. Dynamische Modellierung Pull-Forward Push-Forward Invoke-Push Zusammenfassung IV. Prototyp und Bewertung Prototyp Vorhandene Frameworks Messaging in JEE JMS Message Model JMS-Topologie Konfiguration der Kanäle Nachrichten EMDB-Client Implementierung der Metrikmodelle Heterogene Datenmodelle MetricReferenceFilter Implementierung Scheduler Excel JDBC SONAR Implementierung Gateway CI Server Hudson VCS Subversion bzw. GIT Implementierung Adapter Implementierung DataStoreProviderMetricModel Zusammenfassung Architekturbewertung Qualitätsmerkmale Kopplung von Applikationen Sensibilität Technologieauswahl Datenformat Zuverlässigkeit Weitere Qualitätsmerkmale Anforderungen Datenheterogenität Systemheterogenität Funktionsheterogenität Kommunikationsheterogenität Heterogene Interpretation Operationelle Sensibilität Zusammenfassung iii

8 10.Integrationsszenarien Einführung Architekturbewertung Integrationsszenario Integrationsproblemszenario Integrationlösungsszenario Szenarioäquivalenz Integrationevaluation Lösungskomplexität Beispiel - Integration von Pentaho V. Zusammenfassung und Ausblick Zusammenfassung Ausblick 179 VI. Anhang 183 A. Notion - Enterprise Service Bus 185 Abkürzungsverzeichnis 187 Literaturverzeichis 188 iv

9 Abbildungsverzeichnis 2.1. ISO Messrozess ISO Messinformationsmodell MeDIC Screenshot MeDIC Grobarchitekur nach Evers [41] MeDIC Datenfluss nach Evers [41] JEE Container im Überblick EJB Container und seine Dienste Datenfluss Integration über Dateien nach [59] Integration über eine gemeinsame Datenbank nach [59] Service-Paradigma nach Krafzig [77] SOA-basierte Integration Enterprise Information Integration Integration per Messaing Intgration über Agenten PSP-Entwicklungs-Phasen PSP Größen-Schätzformular Entwicklungsscript Software Process Dasbboard Integration von Subversion zur Größenmessung Pentaho Demo Dashboard Pentaho Data Integration mit Spoon Pentaho Dashboard - Query Rational Insight Rational Insight - Dashboard Rational Insight - Integrationsarchitektur QMetric Komponentendiagramm nach [104] QMetric - MetricQueryTool SISSy Architektur nach [114] CAST Übersicht CAST Dashboard Systemumgebung Schichtenarchitektur von MeDIC MeDIC-Datenfluss als UML-Aktivitätendiagramm Integration von 2 Systemen via ESB Gewünschte Datenquellen für MeDIC nach [41] v

10 7.6. Architektur der Schedulerkomponente Gateway Pattern adaptiert nach Fowler [49] Architektur des Gateway ESB Service Container Architektur der Adapter-Komponente EOMDirectory EMDB Kanäle Architektur eines Metrikmodells Nachrichtentypen Framework-Konzept nach Pree [96] Laufzeitverhalten Integration über den Scheduler Gateway mit Push-Forward Adapter mit Invoke-Push Komplett Architektur Point-To-Point Topologie nach [59] Publish-Subscribe-Topologie Glassfish - JMS Kanalkonfiguration Aktiviätendiagramm für die Nachrichtenverarbeitung Excel-Sheet mit 3 Metrikwerten JDBC-Datenbanken im Container Hudson-Konfiguration GenericDataProviderMetricModel Punkt-zu-Punkt SOA Integration SAAM Prozess nach Clements et al.[29] MeDIC Integration Problem Evaluation Process vi

11 Tabellenverzeichnis 5.1. Vergleichsmatrix Vergleichsmatrix Qualitätsimpactfaktoren für Qualitätsmerkmale vii

12

13 Quelltextverzeichnis 2.1. Eine Persistence Entity für JPA JAX-WS XML Darstellung einer DateMetricMessage Java POJO MetricDataMessage MedicMessageFactory als EJB Komponente EMDB Client als EJB Implementation MeDICMessageListener Interface MetricModelDataStore implementiert mit JPA als DAO MessageSelector Definition über Annotations Abstrakte Job-Klasse mit JaXB Annotationen Beispielkonfiguration eines Excel-Integrationsjobs JDBC XML Config Gatway als JAX-RS Implementierung MeDIC-Notifer Plugin für Hudson GIT Hook: MeDIC Notifier TracIntegration über eine Apdapter-Komponente GenericDataProviderMetricModel für das MeDIC-Dashboard Struktur des URI Standards ix

14

15 Teil I. Einleitung 1

16

17 1. Einleitung Software zu entwickeln bedeutet, Projekte durchzuführen, an deren Ende eine lauffähige Software steht. Der Prozess der Softwareentwicklung ist geprägt von einer Vielzahl von Aktivitäten (Planen, Dokumentieren, Entwerfen, Entwickeln und Testen), Artefakten, Ressourcen und Personen. Das macht das Management eines Softwareentwicklungsprojektes komplex und schwierig. Zusätzlich erschwert wird dieser Umstand dadurch, dass es sich bei Software um immaterielle Güter handelt. Die Erfahrung der letzten Jahre hat gezeigt, dass es notwendig ist, den Softwareentwicklungsprozess transparenter und verständlicher zu gestalten. Ein relativ neues Instrument stellen dabei Projekt-Dashboards dar, die den Projektverantwortlichen über den aktuellen Status des Projekts auf dem Laufenden halten. MeDIC ist eine Plattform, die Beteiligten am Softwareentwicklungsprozess helfen soll, diesen Prozess und ihre Arbeit zu bewerten. MeDIC wird am Lehrund Forschungsgebiet Software Konstruktion der RWTH Aachen entwickelt. Alleine mit dem Namen sind Assoziationen verbunden. Laut der englischen Wikipedia[120] wird jemand, der im Bereich der Medizin arbeitet, als medic bezeichnet. Mediziner haben normalerweise ein bestimmtes Vorgehen, sie stellen Fragen (Anamnese), veranlassen Tests und Messungen, werten die Ergebnisse aus und treffen daraufhin eine Entscheidung für die Therapie. Soweit die Analogie, aber MeDIC ist ein Akronym. Es steht für Metric Description Integration and Configuration. Mittels der Artefakte des Softwareentwicklungsprozesses ist es schwierig, aussagekräftige Bewertungen über die Qualität des Produktes, den Entwicklungsstand oder die Leistungsfähigkeit zu erhalten. Der Entwicklungsprozess hat mit ähnlichen Problemen zu kämpfen. Um diese Probleme zu beheben, wurden Metriken entwickelt. Metriken sind in der Lage, komplexe Objekte zu vermessen und eine Bewertung auf einfache, am besten numerische Werte zu reduzieren. Metriken bilden den Kern der MeDIC-Plattform. Mittels Metriken werden sowohl Artefakte des Softwareentwicklungsprozesses als auch der Prozess selber vermessen. MeDIC soll dem Anwender helfen, die korrekten Metriken auszuwählen und auszuwerten. Metriken basieren auf Daten, und die notwendigen Daten, die für die Vermessung notwendig sind, sind nicht zentral gespeichert, sondern liegen verteilt in der Systemlandschaft des Unternehmens vor. Diese verteilten Daten sind heterogen, d.h. sie unterscheiden sich voneinander in technischer, struktureller und auch semantischer Hinsicht. Die Aufgabe für die Integration ist die Zusammenführung dieser Daten innerhalb der MeDIC-Plattform, sodass die vom Nutzer 3

18 1. Einleitung spezifizierten Metriken berechnet werden können. Die Integrationsproblematik erweist sich im Verlaufe dieser Arbeit als vielschichtiges und komplexes Problem. Heterogenität hat Ausprägungen auf alle Ebenen von MeDIC. Integration ist mittlerweile ein gut erforschtes Gebiet, über die Jahre entwickelten sich eine Vielzahl von Ansätzen und Architekturen. Zur Bewertung dieser Ansätze im MeDIC-Kontext werden Qualitätsmerkmale von Integrationslösungen und konkrete Anforderungen der MeDIC-Integrationsproblematik genutzt. Das Ziel dieser Arbeit ist ein Entwurf der Softwarearchitektur für das Projektdashboard MeDIC, die insbesondere die Problematik der Integration erfassen soll. An einem Prototypen sollen wichtige Konzepte des Entwurfs verifiziert werden Übersicht über die Arbeit Die Arbeit gliedert sich in insgesamt fünf Teile, die jeweils Aspekte der Aufgabenstellung umfassen. Teil 1: Einleitung Dieser Teil enthält neben diesem Einleitungskapitel eine Einführung in die fachlichen und technischen Hintergründe von MeDIC. Dazu wird der zugrundezulegende Messprozess der ISO-NORM vorgestellt. Im weiteren Verlauf werden wichtige Begriff im MeDIC-Kontext wie Metrik oder Informationsbedürfnis erläutert, bevor in den letzten Abschnitten die bisherige Architektur der MeDIC-Implementierung und ihre technischen Grundlagen erläutert werden. Teil 2: Integration Dieser Teil befasst sich mit dem Problem der Integration im Allgemeinen und den Anforderungen an die Integration im MeDIC-Kontext. In Kapitel 3 wird das Problem der Integration für diese Arbeit definiert und es werden Qualitätseigenschaften vorgestellt, mit denen sich Integrationslösungen bewerten lassen. Im folgenden Kapitel 4 werden die Anforderungen für MeDIC konkretisiert und die besonderen Eigenschaften der Heterogenität für die Integration definiert. Teil 3: Integrationsarchitektur für MeDIC Dieser Teil beginnt mit einer Vorstellung von bisher entwickelten Softwarearchitekturen für das Integrationsproblem. Die vorhandenen Architekturen werden bewertet hinsichtlich der Qualitätskriterien und den Anforderungen von MeDIC. Im folgenden Kapitel werden drei vorhandene Lösungen im MeDIC-Umfeld vorgestellt und ihre Integrationseigenschaften analysiert und bewertet. Im letzten Kapitel folgt dann der Entwurf für die Integrationsarchitektur von MeDIC. 4

19 1.1. Übersicht über die Arbeit Teil 4: Prototyp und Bewertung Kapitel 8 beschreibt den für MeDIC entwickelten Prototypen, der dem Entwurf folgende Beispielsysteme in MeDIC integriert. Nach dem Prototypen folgt die Bewertung des Architekturentwurfs auf Basis der Qualitätsmerkmale und den gestellten Anforderungen. Aus der Erkenntnis um die Komplexität des Problems der Integration wird im letzten Kapitel ein Prozess zur Bewertung von neuen im MeDIC-Umfeld auftretenden Integrationsszenarien vorgestellt, der als Ergebnis neben einer Aufwandsbewertung auch konkrete Implementierungshilfen anbieten soll. Teil 5: Zusammenfassung und Ausblick Die Arbeit schließt mit einem zusammenfassenden Fazit und über mögliche Ansatzpunkte für weitergehende Forschung und Entwicklung ab. 5

20

21 2. MeDic - Metric-Based Project and Process Management Inhalt 2.1. ISO Das Messinformations-Modell Metriken Dashboards Informationsbedürfnisse Architektur Praktische Grundlagen - Java Enterprise Edition JEE-Server Enterprise Java Beans Dienste und APIs Java Persistence Api (JPA) Java API for XML Webservices (JAX-WS) Das Thema dieser Diplomarbeit ist die Modellierung einer Integrationsarchitektur für die Projektmanagementplattform MeDIC. Bevor in Teil 2 und Teil 3 die Begriffe Integration und Architektur betrachtet werden, ist es notwendig die fachliche Domäne für die Architektur zu identifizieren und zu charakterisieren. Daher wird in den folgenden Abschnitten die MeDIC-Plattform mit ihren fachlichen Grundlagen, wie der zugrundeliegende Messprozess in der ISO-Norm 15939, eingeführt. Da es sich bei MeDIC um ein existierendes System handelt, das im Zuge mehrerer Arbeiten [41, 56] entstanden ist, ist es zusätzlich notwendig die schon getroffenen technischen und architektonischen Entscheidungen zu identifizieren. Aus diesen dargestellten Grundlagen ergeben sich für Kapitel 4, welches sich mit den Anforderungen an die Architektur befasst, grundlegende Rahmenbedingungen ISO Die Erfahrung hat gezeigt, dass der Prozess der Softwareentwicklung komplex und unübersichtlich sein kann. Daher wurden in den letzten Jahren Anstren- 7

22 2. MeDic - Metric-Based Project and Process Management gungen unternommen, diesen Prozess transparent und verständlich zu gestalten; insbesondere in Hinblick auf die betriebswirtschaftlichen Rahmenbedingungen unter denen Softwareentwicklungsprozesse ablaufen. Hauptverantwortlich und federführend bei der Steuerung eines solchen Prozesses ist der Projektleiter. Da es sich bei Softwareprodukten um keine materiellen Güter handelt, ist die Bewertung des Prozesses für den Projektleiter immens schwierig. Der ISO Standard Systems and Software engineering - Measurement Process (im Folgenden als ISO5939 bezeichnet) [72] definiert Aktivitäten und Aufgaben um Messungen innerhalb eines Projektes zu definieren und durchzuführen. Durch iterative Anwendung kann dieser Prozess dann auch weiter verbessert werden. Zusätzlich definiert er eine einheitliche Terminologie zur Beschreibung von Messungen und eines eigentlichen Messprozesses. Der Standard beschreibt ein einheitliches Vorgehensmodell, ohne die konkrete Details der Messungen zu definieren. Die Ergebnisse, die solch ein Messprozess für ein Projekt bieten soll, werden folgendermaßen definiert. Organisationsübergreifende Verpflichtung zur Etablierung und Erhaltung von Messungen Informationsbedürfnisse für übergeordnete technische und organisatorische Prozesse werden identifiziert Passende Messungen, basierend auf diesen Informationsbedürfnissen, werden definiert bzw. entwickelt Notwendige Tätigkeiten für die Messungen werden identifiziert Messtätigkeiten werden geplant Die notwendigen Daten werden erhoben, gesammelt, gespeichert, analysiert und interpretiert Ergebnisse werden zur Entscheidungsfindung genutzt und dienen als objektive Kommunikationsbasis Die Messungen und der Messprozess selber werden bewertet Verbesserungen am Messprozess werden kommuniziert Mit diesen Zielen erfüllt der Standard die Anforderungen der ISO und auch von CMMI. Das bedeutet, ein Unternehmen, welches erfolgreich diesen Messprozess implementiert, erfüllt alle notwendigen Bedingungen für Stufe 1 von CMMI. Weiterhin bildet es eine belastbare Grundlage zu Erfüllung der weiteren Bedingungen von höheren Stufen. Abbildung 2.1 zeigt den kompletten Messprozess, wie er durch ISO15939 beschrieben wird. Darin finden sich die schon in den Zielbeschreibung vorgekom- 8

23 2.1. ISO Abbildung 2.1.: ISO Messrozess menen Aktivitäten wie Planung und Durchführung des Messprozesses. Diese bilden im Zentrum den Kernmessprozess. Umgeben wird dieser Prozess von weiteren Aktivitäten, die weitere Prozesse symbolisieren. Oberhalb finden sich die übergeordneten Technik- und Managementprozesse, die ihre Informationsbedürfnisse in den Kernprozess speisen. Da es sich beim Begriff Informationsbedürfnis auch um einen Kernbegriff im MeDIC-Umfeld handelt, wird dieser in einem späteren Abschnitt separat eingeführt. Die Semantik ist in ISO15939 und in MeDIC identisch. Die Ergebnisse des Kernprozesses, hier als Information Products bezeichnet, fließen zurück in die Managementprozesse, in denen dann auf Basis der Messergebnisse die projektrelevanten Entscheidungen getroffen werden. Es ist daher wichtig festzustellen, dass innerhalb dieses Prozesses ein Ergebnis zwar interpretiert, aber keinerlei Entscheidung getroffen wird. Der Messprozess liefert nur die relevanten Daten für operative und strategische Entscheidungen. Ein weitere Aktivität, die die Messergebnisse nutzt, ist die Messevaluation auf der rechten Seite, diese dient als Retrospektive auf den gesamten Prozess und als Basis für Feedback und Verbesserungen am Prozess selber. Verbesserungen werden wieder als zusätzliche Eingabe für den Kernprozess verwendet. Die dritte und letzte Aktivität, die als Eingabe für den Kernmessprozess dient, ist die Etablierung und Aufrechterhaltung der Messungen innerhalb der Organisation. Aus dieser Aktivität fließen z.b. die Rahmenbedingungen für die Messungen ein. Dazu gehören die Bereitstellung von Ressourcen wie Personal und Infrastruktur. Da es sich beim Gesamtprozess um ein iteratives Verfahren handelt, welches wie- 9

24 2. MeDic - Metric-Based Project and Process Management derholt angewendet werden muss, um den Prozess an sich zu verbessern, werden alle konkreten Messergebnisse in einer Erfahrungsdatenbank gespeichert, damit deren Inhalte in weiteren Iterationen dem Kernprozess zur Verfügung steht. Zusätzlich werden die Resultate der Evaluation des Prozesses selber in der Datenbank hinterlegt; in einer erneuten Iteration werden dann Vergleiche zwischen diesen und vergangenen Evaluationen durchgeführt. Die Erfahrungsdatenbank ist damit ein wichtiger Bestandteil, weil nur durch ihn die positive Entwicklung des Gesamtprozesses verifiziert werden kann Das Messinformations-Modell Abbildung 2.2 zeigt eine Modellierung der Beziehungen zwischen zu vermessenden Objekten und den Ergebnissen. Grundlage für das Modell ist das sogenannte Messkonzept, dahinter steckt eine abstrakte Vorstellung zwischen Eigenschaften von Messobjekten und den vorhandenen Informationsbedürfnissen. Um den Begriff Messkonzept besser zu erläutern, soll er an einem Beispiel illustriert werden. Das zu beantwortende Informationsbedürfnis ist in diesem Beispiel der Vergleich der Entwicklungsproduktivität eines Projektes, d.h. das zugehörige Messkonzept heißt Entwicklungsproduktivitätsrate. Inhalt dieses Konzeptes wäre demnach die Untersuchung relevanter Objekte, die über ihre Eigenschaften Aussagen über die Produktivität erlauben, dazu gehören beispielsweise die momentane Größe des Softwaresystems oder die verwendeten Ressourcen in Form von Personal und Infrastruktur. Andere Messkonzepte befassen sich mit der Produkt- sowie der Prozessqualität oder Risiken innerhalb des Softwareentwicklungsprozesses. Der Begriff Messobjekt oder verkürzt Objekt ist ein abstrakter Begriff für relevante Bestandteile des Softwareentwicklungsprozesses. ISO15939 definiert unterschiedliche Klassen von solchen Objekten. Produkte sind typischerweise produzierte Artefakte des Softwareentwicklungsprozesses wie Dokumente und der Quellcode. Prozesse sind Objekte organisatorischer Art, die die im Unternehmen definierten Abläufe wie zum Beispiel den Entwurf, die Entwicklung und einen Test einer Software beschreiben. Als dritte Klasse kennt ISO15939 Ressourcen, darunter fallen das Personal und die Infrastruktur. Jedes Messobjekt besitzt Eigenschaften, die zur Beantwortung des Informationsbedürfnisses relevant sind. Wichtig ist hierbei, dass es sich um messbare Eigenschaften handelt. Nicht messbare Eigenschaften werden in diesem Modell nicht betrachtet. Erhoben werden diese Eigenschaften mit Messmethoden, diese beinhalten das genaue Verfahren zur Vermessung des Objektes und der spezifischen Eigenschaft. Ergebnis dieser Messmethode ist eine sogenannte Basismessung. Basismessungen sind unabhängig von anderen Messungen und basieren rein auf mittels Messmethoden erhobenen Werten. Durch Kombination mehrerer Basismessungen wird eine abgeleitete Messung hergestellt, diese Messung ist Ergebnis der Messfunktion, welche die genaue Vorschrift zur Kombination der Basismessungen enthält. 10

25 2.1. ISO Abbildung 2.2.: ISO Messinformationsmodell Abgeleitete Messungen dienen dann wieder als Eingabe an das Analysemodell, wo die ermittelten Werte dann interpretiert werden. Zur Bewertung der Messwerte dienen Entscheidungskriterien. Entscheidungskriterien umfassen Schwellwerte sowie Zielwerte, entweder berechnet aus vorhandenen oder durch einen Experten bereits definierte Zielwerte. Ergebnisse des Analysemodells bezeichnet man als Indikatoren, diese werden selber wieder als Messungen betrachtet. Im letzten Schritt werden die Indikatoren nun im Sinne des zu erfüllenden Informationsbedürfnisses bewertet. Diese Aktivität bezeichnet das Messinformationsmodell als Interpretation. Ergebnis der Interpretationsschritts sind die Informationsprodukte, im weiteren Sinn wieder Messwerte, die genau das Informationsbedürfnis beantworten. Das Messinformationsmodell beschreibt zusätzlich zu dem Beziehungsgeflecht zwischen Objekten, Messungen und Informationsbedürfnissen einen konkreten Daten- und Informationsfluss. Prinzipiell werden in diesem Modell erhobene Messwerte in nachfolgenden Schritten weiterverarbeitet, bis aus ihnen nutzbare Informationen zur Beantwortung der grundlegenden Fragestellung in Form des Informationsbedürfnisses entstanden sind. In Abbildung 2.2 fließen die Messda- 11

26 2. MeDic - Metric-Based Project and Process Management ten von den Objekten am unteren Rand in Richtung der Informationsbedürfnisse am oberen Rand der Darstellung. Die vorgestellte ISO-Norm bildet die Grundlage für MeDIC. MeDIC orientiert sich in seinen Begrifflichkeiten und Komponenten stark am hier vorgestellten Messprozess bzw. dem Messinformationsmodell. Daher bildet auch diese Norm eine Basis für die zu entwickelnde Integrationsarchitektur, diese Arbeit bildet prinzipiell das Messinformationsmodell als Softwarearchitektur ab. In den folgenden Abschnitten werden die wesentlichen fachlichen Begriffe und Komponenten im Kontext von MeDIC eingeführt. An passender Stelle werden dann wieder Referenzen zur ISO-Norm aufgezeigt Metriken Projekt-Dashboards wie MeDIC sind ein relativ neues Mittel zur quantitativen und qualitativen Bewertung eines Softwareentwicklungsprozesses. MeDIC nutzt dazu bekannte Metriken und visualisiert diese in einer ansprechenden graphischen Form. Das IEEE [67] definiert eine Metrik folgendermaßen: metric. A quantitative measure of the degree to which a system, component, or process possesses a given attribute. See also: quality metric. quality metric. (1) A quantitative measure of the degree to which an item possesses a given quality attribute. (2) A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the software possesses a given quality attribute. Folgt man dieser Definition, so sind Metriken ein Mittel, um quantitative Aussagen über eine Software und insbesondere über die Qualität einer Software zu erlangen. Solche Aussagen werden benötigt, um Softwareartefakte zu vergleichen und auch die Entwicklung über einen längeren Zeitraum zu beobachten. Im Softwareentwicklungsprozess haben sich Metriken zu einem Standardwerkzeug entwickelt, um sowohl Artefakte, aber auch den Prozess als solchen zu vermessen und damit bewertbar zu machen. Weitere Definitionen eines Metrik wie die ISO/IEC-Norm betonen den funktionalen Charakter einer Metrik, als set of operations having the object of determing a value of a measure [72], d.h. eine Metrik beschreibt auch die Art und Weise wie der quantitative Wert einer Metrik erhoben wird. Im vorangegangen Abschnitt wurde eine Metrik auch als Messfunktion bezeichnet. 12

27 2.2. Metriken Erweiternd zu diesen Industriestandards beschreiben Ludewig und Lichter, dass zusätzlich zu den technischen Eigenschaften einer Metrik immer eine Vorstellung verbunden [ist], wie eine Metrik zu interpretieren ist [81]. Zusammenfassend lassen sich die grundlegenden Eigenschaften von Metriken folgendermaßen zusammenfassen 1. Merkmal: Eine Metrik umfasst genau ein bestimmtes Merkmal bzw. eine bestimmte Qualitätseigenschaft. 2. Abbildung: Eine Metrik definiert eine Abbildung eines reellen Elementes des Softwareentwicklungsprozesses auf skalare Größe oder Symbole. 3. Skala: Die Metrik definiert eine Skala, in der die Werte der Metrik liegen dürfen. 4. Interpretation: Die Metrik bringt unterstützende Informationen mit, wie ihre Werte zu interpretieren sind. Im Normalfall gehen diese Interpretationshilfe mit der Beschreibung der Qualitätseigenschaft einher, die die Metrik umfassen soll. Norman Fenton [43] beschreibt im Bereich des Software-Engineerings grundsätzlich in drei Teilbereiche, in denen Messungen durch Metriken möglich sind. Daraus resultieren drei Klassen an Metriken, Produkt- und Prozess- und Ressourcenmetriken, wobei letztere zumeist auch als Projektmetriken bezeichnet werden [118] Produktmetriken Quantifizieren Eigenschaften der Artefakte des Softwareentwicklungsproduktes, wie Größenumfang der Software durch Zählung der Codezeilen oder Komplexität durch Messung der zyklomatischen Komplexität (siehe [86, 70]). Projekt-/Ressourcenmetriken Zu dieser Klasse von Metriken gehört die Messungen von Kosten und Aufwänden, die während des Softwareentwicklungsprozesses anfallen. Prozessmetriken Diese Klasse umfasst Metriken, deren Ziel die Quantifizierung von Aktivitäten innerhalb des Prozesses ist. Metriken basieren auf einem dem Software Entwicklungsprozess unterliegenden Prozessmodell, sodass sich Aktivitäten hinsichtlich dieses Prozessmodells messen lassen. Der Sinn und Zweck von Metriken ist die Quantifizierung von Qualitätseigenschaften. Die vorausgegangene Unterscheidung folgt demnach der Unterscheidung, die auch bei Softwarequalitätseigenschaften durchgeführt wurden. Die ISO-Normen 9126 und [70, 71] definieren einen umfangreichen Katalog an Qualitätseigenschaften und Metriken für den Software-Entwicklungsprozess 13

28 2. MeDic - Metric-Based Project and Process Management und dessen Produkte. Die bekannteste Produktmetrik ist sicher Lines of Codes (LOC). Diese Metrik umfasst als Abbildungsvorschrift die Zählung aller Zeilen der Quellcodedokumente eines Softwareproduktes. Als Skala dient hier eine rationale Skala, in der Addition-, Subtraktion- und Verhältnisoperationen auf den Werten der Skala erlaubt sind. So kann zum Beispiel das arithmetische Mittel von LOC über einzelne Dokumente berechnet werden. Die Metrik LOC kann für mehrere unterschiedliche Produktmerkmale verwendet werden. z.b. Komplexität einer Software oder Kostenumfang einer Software. In der Interpretation der Werte, in der grundlegend ein höherer LOC-Wert erhöhte Kosten bzw. eine erhöhte Komplexität darstellt, werden dann auch die Schwächen und Probleme dieser Metrik deutlich. Metriken bergen das Risiko, dass ihre Werte zu falschen Interpretationen und Aussagen führen. An dieser Stelle setzt MeDIC ein und unterstützt den Projektleiter bei Auswahl und Interpretation von Metriken. Darüber hinaus gibt es zusätzliche Klassifizierungen, die unterschiedliche Eigenschaften einer Metrik in den Vordergrund heben. Obige Unterscheidung orientiert sich an den möglichen Merkmalen, die eine Metrik umfassen kann. Klassifizierungen bezüglich der Abbildung und deren Vorschrift unterscheiden z.b., wie diese Metriken erhoben werden können, dazu definieren Ludewig und Lichter [81] drei unterschiedliche Klassen von Metriken: 1. objektive Metriken werden durch Zählen bzw. durch eine Messung erhoben 2. subjektive Metriken werden durch Schätzen oder Begutachten durch einen Experten erhoben 3. Pseudometriken werden durch Berechnung auf Basis von vorgelagerten Metriken erstellt Pseudometriken entsprechen den abgeleiteten Metriken im Messmodell der ISO- Norm 15939, subjektive und objektive Metriken werden an dieser Stelle nicht unterschieden. Innerhalb von MeDIC ist es nur möglich, objektive und Pseudometriken zu berechnen. Subjektive Metriken können als reine Datenwerte verarbeitet werden und entsprechen dann objektiven Metriken, nur innerhalb der Interpretation kommt dann diese Unterscheidung zum Tragen. Für die Integrationsarchitektur spielt dies aber keine Rolle. Weitere Klassifizierungen bzw. Verfeinerungen finden sich im Buch von Ludewig und Lichter [81]. Da es sich bei MeDIC um eine metrikbasierte Plattform handelt, haben Metriken und ihre Eigenschaften einen entscheidenden Einfluss. Die Unterscheidung zwischen objektiven/subjektiven und Pseudometriken hat Auswirkungen auf die Modellierung von Metriken in MeDIC und damit auch auf den Architekturentwurf. In Kapitel 4 werden diese Klassifizierung und ihre Auswirkungen auf die Architektur der Integration diskutiert. 14

29 2.3. Dashboards 2.3. Dashboards Abbildung 2.3.: MeDIC Screenshot Die im vorherigen Abschnitt eingeführten Metriken und ihre Interpretation sind effektive Werkzeuge, um Transparenz in die komplexen Abläufe innerhalb eines Softwareentwicklungsprozesses zu bringen. Im nächsten Schritt müssen diese Metriken für den Projektleiter effektiv zugänglich sein. Hier bedient man sich innerhalb MeDIC dem Dashboardansatz. Der Einsatz von Dashboards entstammt der Zeit, als in die Softwareentwicklung ingenieurmäßige Methoden und Prozesse Einzug hielten, auch die Metriken entstammen dem Ingenieurwesen. Dashboards sollen die zugänglichen Informationen in einer übersichtlichen und kompakten Art und Weise visualisieren. Innerhalb der Informatik sind sie mit Entscheidungsunterstützungssystemen, wie sie z.b. Anfang der 1970er Jahre entwickelt wurden, entstanden. Innerhalb der Entscheidungsunterstützungssysteme erlangten sie der Kategorie der data-driven decision support systems Bedeutung. Power [95, 94] definiert ein data-driven decision support systems folgendermaßen: Data-driven DSS is a type of DSS that emphasizes access to and manipulation of a time-series of internal company data and sometimes external data. Als Standardbeispiel für ein solches System sind Data-Warehouses oder Business Intelligence (BI) Systeme. In Kapitel 6 werden darauf beruhende Systeme 15

30 2. MeDic - Metric-Based Project and Process Management und ihre Integrationseigenschaften mit denen von MeDIC verglichen und bewertet. MeDIC kann man sogar genauer als metric-driven decision support system bezeichnen. MeDIC und artverwandte Systeme, die im späteren Kapitel 6 noch ausführlich behandelt werden, unterscheiden sich im Vergleich zu diesen Systemen darin, dass klassische Entscheidungsunterstützungssysteme ein Softwareprodukt darstellten, welches sich einer definierten Problemdomäne außerhalb der Informatik widmen. MeDIC ist aber ein Softwareprodukt zur Bewertung von Software und seinen Entwicklungsprozess und um für die wichtigen Entscheidungen des Projektleiters effektive Grundlagen zu bieten. Hierbei ist anzumerken, dass ein Dashboard wie MeDIC zunächst keine Entscheidungen vorgibt oder vorschlägt. Es beschränkt sich rein auf die Visualisierung der Metriken Stephen Few definierte eine Klassifikation von Dashboards anhand ihres Einsatzzweckes innerhalb des Unternehmens [44]. 1. Strategische Dashboards 2. Analytische Dashboards 3. Operationelle Dashboards Münch et al. definieren für ihre Software Process Control Center [91] eine viel umfangreichere Klassifikation basierend auf unterschiedlichen Sichtweisen auf das System. Die Klassifikation von Few wird unter der Klasse Zweck (Purpose) zusammengefasst. Die Klassen von Few sind demnach nur Charakteristiken dieser Klasse Zweck. Weitere Klassen zielen auf die technische Ebene oder auf die User und Stakeholder, die mit dem Control Center arbeiten. Diese Arbeit nutzt im Folgenden die Klassifikation von Few. MeDIC lässt sich nicht ohne weiteres einer dieser Klassen zuordnen, je nach Benutzergruppe von MeDIC ergeben sich andere Anforderungen an das System. Ein Projektleiter wird MeDIC für analytische und operationelle Zwecke nutzen, ein Entwickler eher rein für die operationellen Aspekte. Auf Managementebene sind die Daten aus dem Entwicklungsprozess eher von strategischem Interesse, insbesondere um das weitere Vorgehen des Unternehmens zu entscheiden oder ggf. den Softwareentwicklungsprozess zu stoppen. Für die verschiedenen Benutzergruppen sind auch unterschiedliche Daten und Visualisierungen notwendig. MeDIC klassifiziert die Anforderungen in sogenannte Informationsbedürfnisse, die im nächsten Abschnitt näher definiert und erläutert werden. Durch seinen integrativen klassenübergreifenden Ansatz ergeben sich offensichtlich bestimmte Anforderungen an die Softwarearchitektur. MeDIC muss in der Lage sein, als Hybridsystem zwischen den Klassen zu fungieren. Dies stellt eine große Herausforderung dar. 16

31 2.4. Informationsbedürfnisse 2.4. Informationsbedürfnisse Der ISO-Standard [72] definiert ein Informationsbedürfnis ( information need ) folgendermaßen: 2.12 information need insight necessary to manage objective, goals, risks and problems. Basali und Rombach [8, 83] definieren den Goal-Question-Metric (im folgenden GQM) zur Auswahl sinnvoller Metriken und deren Messung innerhalb eines Projektes. Dieser Ansatz basiert auf der schrittweisen Definition folgender Komponenten. Ziel (Goal): Im ersten Schritt müssen die Ziele des Projektes und die Ziele, die mit der Erhebung der Metriken verfolgt werden sollen, definiert werden. Beispiele für diese Ziele sind z.b. Wissen über Kostendeckung ermitteln Fragen (Question): Im nächsten Schritt werden Fragen definiert, die bei Beantwortung das notwendige Wissen zur Erfüllung der Ziele erbringen. Im Kontext des Beispiel Kostendeckung wäre dann eine mögliche Frage Wie ist der Fertigstellungsgrad der Software? bzw. Wie viel Aufwand ist schon in die Software geflossen? Es ist offensichtlich, dass ein Ziel nicht immer durch eine Frage beantwortet werden kann, sondern es mehrere Fragen und der Kombination ihrer Antworten bedarf. Metrik (Metric): Aufbauend auf den definierten Fragestellungen werden nun Metriken gesucht, die Antworten auf die entsprechenden Fragen liefern. Für das Beispiel wären die Metriken Anzahl abgeschlossener Arbeitspakete und Anzahl gebuchter Stunden der Mitarbeiter möglich. Es ist aber ersichtlich, dass auch andere Metriken in Frage kommen könnten, die konkreten gewählten Metriken hängen wieder sehr eng mit der Struktur des Projektes zusammen und mit der Möglichkeit, welche Metriken überhaupt erhoben werden können. Prinzipiell implementiert MeDIC diesen GQM-Ansatz, erweitert ihn um zwei Komponenten. Erstens strukturiert es die eher oberflächlichen Ziele in eine etwas feingranularere Hierarchie, die Informationsbedürfnisse. Diese führen den Benutzer, indem zu bestimmten Informationsbedürfnissen passende Fragen vorgeschlagen werden. Informationsbedürfnisse sowie der Fragenkatalog und die entsprechenden Metriken werden vor Nutzung von MeDIC von einem Metrikexperten spezifiziert und konfiguriert. Mehrere Arbeiten im MeDIC-Umfeld befassen genau mit dieser Thematik, für nähere Ausführungen wird auf die Arbeiten von Evers [41], Guha [54] und Emelyanova [40] verwiesen. Gleichzeitig kann MeDIC auch fertig konfigurierte Dashboard-Vorlagen anbieten. Parallel zu dieser Arbeit beschäftigt sich Hutter[64] mit der Evaluation von solchen Vorlagen und der fachlichen Integration von MeDIC in einen Unternehmensprozess. 17

32 2. MeDic - Metric-Based Project and Process Management Über die Informationsbedürfnisse können die gewünschten Metriken geführt bzw. explorativ konfiguriert werden. Darüber hinaus kennt MeDIC ein Rollenkonzept, mit für den User je nach seinem Kontext bzw. Rolle innerhalb des Projektes ein personalisiertes Dashboard angeboten werden kann. Wie im letzten Abschnitt definiert, kann MeDIC somit als analytisches, strategisches aber 7. Architektur auch operationelles Tool im Projekt eingesetzt werden. Dieser Sachverhalt verdeutlicht den integrativen Ansatz den MeDIC verfolgt und dieser Ansatz muss sich auch ständlich zwangsläufig ist. in der Softwarearchitektur wieder spiegeln. Verschiedene Modelle für verschiedene Zwecke Die Anwendung des Separation of Concerns ist ein weiteres Ziel, um die Erweiterbarkeit und Wartbarkeit zu gewährleisten. Da es zwei grundsätzlich verschiedene Sichten 2.5. Architektur auf das System gibt, sollten diese auch in separaten Modellen modelliert sein. Bei MeDIC handelt es sich um eine Software, die als solche innerhalb mehrerer Forschungsarbeiten Simple Schnittstelle (siehe für den [41, Datenabruf 27, 26, 40, 53, Ein54, weiteres 87, 88, Ziel 112]) iststetig eine möglichst entwickelt wurde. flexible Die MeDIC-Version, Ankopplung vondie Messsystemen. zum Zeitpunkt Das Abrufen dieser Arbeit von Messdaten den aktuellen sollte über eine einfache wurdeschnittstelle von Evers infunktionieren, seiner Masterarbeit deren Implementierung [41] implemen- Stand repräsentierte, tiert. leicht ausgetauscht werden kann, so dass eine flexible Datenankopplung möglich ist. Abbildung 2.4 zeigt die verwendete Grobarchitektur des MeDIC-Dashboard- Prototypen. Aufgrund dieser Sie beruht Anforderungen auf einemwurde Schichtenarchitekturmuster die Architektur erstellt. Eine mit drei Übersicht unterschiedlichen der Komponenten Schichten. ist injede FormSchicht eines Komponentendiagramms implementiert eine andere in Abbildung Funktionalität 7.1 für zudas sehen. Dashboard. Präsentation Kern Daten Abbildung 7.1.: Grobgranulare Sicht der Architektur des Abbildung 2.4.: MeDIC Grobarchitekur nach Evers [41] Dashboard-Prototypen auf Komponentenbasis 1. Präsentationschicht Hier In ist dieser zu erkennen, Schicht dass liegen sich die der zur Prototyp Visualisierung aus zehn des Teilen Dashboards zusammensetzt. notwendi- Für eine bessere Übersicht wurden weitere referenzierte Projekte ausgelassen, da diese keine essenziellen Funktionen liefern. 18 In der Übersicht ist eine Dreiteilung der Webanwendung in drei Oberflächen zu erkennen. Es wird zwischen den Architekturbausteinen JSF-Frontend, JSF- Backend und JSF-DataStore unterschieden. Das Frontend beinhaltet XHTML-

33 2.5. Architektur gen GUI-Komponenten. Innerhalb dieser befindet sich die wichtige Komponente Frontendmodell. In diesem Modell werden Messdaten und die Dashboardkonfiguration des Anwenders in ein aktuelles Dashboard integriert. Es stellt das Domänenmodell 7.2. für Modelle das MeDIC-Dashboard dar. Dieses Dashboard mit seinen DashboardItems wird dann über das JSF- Frontend als Webanwendung visualisiert. e Erweiterungsfassade nutzt die Funktionalität der Anwendungsfassade, um thilfe einer Konverter-Komponente 2. Kern die Backend-Modellelemente in Frontendodellelemente zu konvertieren. Der Zusätzlich Kern einhaltet greift eine der vom Konverter Codegenerator auf den Dalieferanten (DataProvider) Gargoyle (siehe [80]) generierte zu, um Komponente, die Backend-Modelle die das Messdatennmodell mit Messdaten zu (Backenddomänenmodell) rknüpfen. Hierzu greift der für Datenlieferant MeDIC und auf entsprechende das Subsystem Zugriffsmethoden Datensystem bereitstellt.. Die Messdaten liegen ebenfalls in einer Datenbank. Der Kontrollfluss des shboard-prototypen läuft 3. von Daten oben nach unten. Das heißt, innerhalb der celets ist angeben, wie eindiese Dashboard Schichtschablonenhaft stellt die Zugriffsfunktionalität aufgebaut ist. Dazu für die unter MeDIC liegende rd auf die ManagedBeans zugegriffen, Datenbankdie bereit. wiederum Da der auf DataStores die Fassaden explizit zugrei- als Prototyp gedacht ist,. Dabei wird vor allem auf wird die Erweiterungsfassade er hinter einer Fassade zugegriffen, (DataProvider) die danngekapselt. die wendungsfassade verwendet. Die Anwendungsfassade greift zunächst auf die ntroller und DAOs zu, Abbildung die dann2.5 den zeigt Datenfluss den Datenfluss von unten innerhalb nach oben des MeDIC-Dashboards bemmen. Das heißt, es beteiligten werden Backend-Modellelemente Komponenten. Das MeDIC-Dashboard von unten nach oben wurde mittels Komponenten und die itergereicht. auf Basis der Java Enterpris Editon implementiert. Die notwendigen Technologien werden im folgenden Abschnitt erläutert. Folgenden gibt die Erweiterungsfassade die pfangenen Backend-Modellelemente an den nverter weiter, der daraus Frontend-Mollelemente erzeugt, wobei er dabei einen Kon- *+,-!"#$%&"'() llfluss nach unten zum Datenlieferanten erugt, der wiederum die Kontrolle weiter an s Datensystem delegiert. Dort werden die 3'&/21/() 4&(155- ten aus der Datenbank geholt und angesst und wieder nach oben bis zum Konvergegeben. Der Konverter verbindet die Da- (siehe Abbildung 7.3) mit den Frontendodellelementen und gibt die fertigen Front-.&/01'21'- d-modellelemente weiter nach oben, so dass Datenfluss vom Konverter zu den Facelets tsteht. Diese visualisieren schließlich die Elente des Frontend-Modells. chdem in diesem Abschnitt ein grober Überck über die Architektur gegeben wurde, foln in den kommenden Abschnitten präzise- Erläuterungen. Dabei wird zunächst auf bereits angesprochenen Modelle Bezug gemmen. 2. Modelle!"#"$%"& 6"781/()4&(15-9.&/:;<'"=&/>- 41##("21/- Abbildung 2.5.: MeDIC Abbildung Datenfluss 7.3.: nach Konvertierung Evers [41] der Modelle Konsequenz für den Entwurf einer Integrationsarchitektur und die Implementierung eines Prototypen ist die Nutzung der identischen technischen Basis. Damit eser Abschnitt widmet sich den unterschiedlichen Modellen, die im Prototypen nutzt werden. Dabei wird auch auf Teile eingegangen, die im Rahmen dieser asterarbeit nicht mehr implementiert, aber bereits konzeptioniert wurden. Die odelle werden von der GUI ausgehend erläutert. Demzufolge wird zunächst das 19

34 2. MeDic - Metric-Based Project and Process Management ist gewährleistet, dass MeDIC sich auch in Zukunft weiter entwickeln kann und für die Entwicklung keine großen technologischen Hürden vorhanden sind Praktische Grundlagen - Java Enterprise Edition In den bisherigen Abschnitten wurde die theoretische und fachliche Basis für diese Diplomarbeit vorgestellt, diese umfasste sowohl das fachliche Modell von MeDIC in Form des ISO-Standards als auch die wesentlichen Komponenten von MeDIC in jetzigen Form. Zur Entwicklung eines Prototypen für die Integrationsarchitektur wurden die vorhandenen technischen Entscheidungen übernommen. In diesem Abschnitt werden daher die grundlegenden Techniken wie Java Enterprise Beans und Webservices eingeführt und erläutert. Die Java Enterprise Edition (JEE) umfasst eine Vielzahl von Spezifikationen 1 für die Entwicklung großer, verteilter und vielschichtiger Anwendungen im Unternehmensumfeld. Die Standardimplementierungen der JEE wird in Programmiersprache JAVA zur Verfügung gestellt. JEE hat sich zum Ziel gesetzt einen Standard für die Entwicklung von Softwaresystemen zu definieren, daher beschreibt es eine Vielzahl an Diensten und Komponenten zum Bau dieser Systeme. Wichtigste Prämisse ist dabei eine durchgehende Modularisierung der Softwarekomponenten und deren Kommunikation über definierte Schnittstellen. In diesem Sinne handelt es sich bei JEE um eine Komponententechnologie. Konsequenz aus diesem Vorgehen ist die Interoperabilität von Softwarekomponenten verschiedener Hersteller, die sich dem JEE-Standard unterwerfen JEE-Server Alle JEE-Softwarekomponenten werden in einem JEE-Container ausgeführt. Die JEE-Container werden von einem JEE-Applikationsserver bereitgestellt. Innerhalb der JEE-Standards in Version 6 [25] sind folgende Container vorgesehen. EJB-Container Hierbei handelt es sich um die Laufzeitumgebung für die Komponentenklasse der Enterprise Java Beans (kurz: EJB). Diese Komponenten bilden zumeist die Kernfunktionalitäten einer JEE-Anwendung ab. Der EJB- Container bietet seinen EJBs mehrere definierte Dienste an, darunter fallen Transaktionsmanagement, Persistenzdienste zum Zugriff auf Datenbanken und Protokollimplementierungen zu Kommunikation mit externen Anwendungen

35 2.6. Praktische Grundlagen - Java Enterprise Edition Web-Container Diese Laufzeitumgebung dient zur Ausführung von Webanwendungen. Dafür wurden innerhalb der JEE mehrere Standards entwickelt. Grundlegend sind die Ausführung von Java Server Pages (JSP) und Servlets. Bei JSP handelt es sich um dynamisch interpretierte Sprache, die mittels einer deklarativen Auszeichnungssprache, ausgelegt als XML-Dialekt, eine Webanwendung bereitstellen kann. Bei Servlets handelt es sich um einen Standard zur Verarbeitung von HTTP-Requests direkt in Java-Code. Aufbauend auf diesen Techniken wurden weitere Technologien für den Web- Container entwickelt. Als moderne Alternative bietet sich zur Zeit Java Server Faces (kurz: JSF) an. In Form der Komponentenbibliothek Prime Faces nutzt MeDIC momentan diese Technik. Applet-Container Beim Applet-Container handelt es sich um eine auf dem Client im Browser implementierte Umgebung zur Ausführung von Java Applets. Dieser Container und die darauf basierende Technik der Applets wird zumeist nicht mehr genutzt. Application Client Container Bei diesem Container handelt es sich um eine autark vom JEE-Server laufen Java Virtual Machine auf dem Client, der JEE-Komponenten ausführt. Damit lassen sich im JEE-Umfeld native Clientlösungen schaffen. 6 Applet Container Web Container EJB Container Applet HTTP SSL JSP Servlet EJB Java SE HTTP SSL JAX-RPC SAAJ Web Services CDI & DI JACC JASPIC JAXR JAX-RS JAX-WS Management WS Metadata JTA Connectors JMS Java Persistence JSTL JSF JavaMail JAX-RPC SAAJ Web Services CDI & DI JACC JASPIC JAXR JAX-RS JAX-WS Management WS Metadata JTA Connectors JMS JavaMail Java Persistence Application Client Container Java SE Java SE Application Client JAX-RPC JAX-WS SAAJ JMS JAXR Web Services CDI & DI WS Metadata Java Persistence Management Database Java SE New in Java EE 6 Figure EE.2-1 Java EE Architecture Diagram Abbildung 2.6.: JEE Container im Überblick The following sections describe the Java EE Platform requirements for each kind of Java EE platform element. Ein klassischer JEE-Server implementiert zumeist die ersten zwei Container, den EJB-Container und den Web-Container, und stellt diese den Anwendungen EE.2.2 Profiles zur Verfügung. Zusätzlich zu dieser Bereitstellung hat der JEE-Server noch folgende The Dienste Java EE 6 und specification Funktionalitäten. introduces the notion of profiles (see Chapter EE.9, Profiles ). A profile is a configuration of the Java EE platform targeted at a specific class of applications. Profiles are not a new concept, nor are they unique to the Java EE platform. The Java Community Process Document (version 2.6) gives the following definition of a profile: A Specification that references one of the Platform Edition Specifications and zero or more other JCP Specifications (that are not already a part of a Platform Edition Specification). APIs from the referenced 21

36 2. MeDic - Metric-Based Project and Process Management Transaktionsmanagement Namens- und Verzeichnisdienste Kommunikation zwischen JEE-Komponenten Bereitstellung von Persistenzdiensten Management des Lebenszyklus von JEE-Komponenten Unterstützung von Installationmechnismen Bereitstellung von Sicherheitsdiensten für Authentifizierung und Authorisierung Diese Dienste werden über den Container an die Anwendungen weitergereicht. Dadurch werden Dienste und Anwendung entkoppelt. Abbildung 2.6 zeigt eine Übersicht der verschiedenen Container und der dazugehörigen Dienste, die vom JEE-Server bereitgestellt im Container zur Verfügung stehen. Jeder Dienst wird durch eine Programmschnittstelle (engl. application programming interface, kurz API) spezifiziert. Die JEE definiert eine Vielzahl von Diensten und ihre entsprechenden APIs. Jeder vollständige JEE-Server muss konforme Implementierungen für diese Dienste mitbringen. In einem späteren Abschnitt werden die für MeDIC relevanten Dienste und APIs kurz vorgestellt. Da es sich bei der JEE um einen offenen Standard handelt, existieren eine Vielzahl unterschiedlicher Implementierungen und damit auch viele unterschiedliche JEE-Server. JEE wird in einem offenen Prozess, dem Java Community Process, kontinuierlich weiterentwickelt. In diesem Prozess engagieren sich zumeist alle größeren Hersteller von JEE-Server sowie JEE-Lösungen. Dazu gehören Oracle (ehemals SUN) als JAVA-Erfinder, IBM, RedHat, Springsource, Apache Foundation und viele weitere mehr. An JEE-Servern steht eine Vielzahl an freien, aber auch kostenpflichtigen Produkten bereit. 1. Oracle/SUN: Glassfish Application Server 2 und Weblogic 3 2. IBM: Websphere 4 3. RedHat: JBoss 5 4. Apache: Geronimo

37 2.6. Praktische Grundlagen - Java Enterprise Edition MeDIC wird auf der freien Referenzimplementierung von Oracle, Glass fish, entwickelt und betrieben. Durch die Konformität zum JEE-Standard lässt es sich aber auch ohne Probleme auf anderen JEE-Servern betreiben Enterprise Java Beans Enterprise Java Beans (folgend: EJB) gehören zu den Kerntechnologien der JEE, sie basieren auf normalen Java-Objekten, auch Plain Old Java Objects (kurz: POJO) genannt. Martin Fowler 7 definierte den Begriff POJO als Bezeichnung für die Nutzung normaler Java-Objekte um Geschäftslogik innerhalb einer Anwendung zu implementieren. Das Ziel dieser Vorgehensweise ist die Minimierung der wichtigen fachlichen Logik von externen Abhängigkeiten, die durch die Einbettung der Logik in einem komplexen Framework entstehen können. Diese Abhängigkeiten machen die Anwendung wenig portabel und sehr von der verwendeten Technologie abhängig. Dem KISS-Prinzip ( Keep it stupid simple [119]) folgend sollten die Abhängigkeiten verringert werden. Da diese POJOs aber nicht ohne die Anbindung an externe Systeme beispielsweise arbeiten können, wurde das Prinzip der Inversion of Control [47] geboren, bei dem ein externer Container die Verwaltung dieser externen Dienste und auch der POJOs übernimmt und diese bei Bedarf zur Laufzeit mit einander verbindet. Dieses Prinzip der Container gesteuerten Lebenszyklen findet sich seit Version 3.0 auch in der EJB-Spezifikation wieder. EJBs sind demnach auch simple Java-Objekte, die aber vom Container gesteuert werden, d.h. Erstellung und Instanziierung bzw. Zerstörung und Dereferenzierung geschehen über den EJB- Container. Da die Kommunikation mit EJBs nur über den EJB-Container und dort nur über die definierten APIs erfolgen kann, ist der EJB-Container jederzeit in der Lage entsprechende EJBs zu erzeugen und diese mit den Diensten zu verbinden. Die Verbindung geschieht meistens über einen Injektionsmechanismus. Das bedeutet bei oder nach Instanziierung des EJBs werden entsprechende Referenzen auf gewünschte Dienste des EJBs vom Container im EJB erzeugt. Da die EJBs Schnittstellen nutzen, ist die konkrete Implementierung unwichtig, durch die JEE-Spezifikation und die entsprechenden APIs kann das EJB mit jeglicher JEE-konformen Implementierung korrekt interagieren. Die JEE-Spezifikation kennt drei unterschiedliche Typen von EJBs. Session-Bean Diese Beans dienen als grundlegender Baustein einer JEE-Anwendung, in ihnen wird üblicherweise die Geschäftslogik implementiert. Daten innerhalb dieses Beantypus sind nicht persistent, d.h. ein Absturz des JEE- Server zerstört diese Informationen. Session-Beans gibt es in zwei Ausprägungen. Stateless Session-Beans implementieren Funktionalitäten, die im 7 23

38 2. MeDic - Metric-Based Project and Process Management Bezug auf den aufrufenden Klienten zustandslos sind. Dies impliziert, dass die Zuordnung Klient zu EJB nur für den einen konkreten Aufruf gilt. Im Gegensatz dazu implementieren stateful Session-Beans zustandsbehaftete Funktionalitäten für ihre Klienten. Session-Beans bestehen in JAVA stets aus Interface und einer implementierenden Klasse. Das Interface kann als Remote oder als Local-Interface ausgelegt sein, je nachdem ob und welche Methoden exportiert werden können. Wie alle EJBs sollen Session Beans über den Deployment-Descriptor oder aber über Annotationen definiert und konfiguriert werden. Message-Driven-Bean Hier bei handelt es sich prinzipiell um eine besondere Klasse des stateless Session-Beans. Message-Driven-Beans sind in der Lage Nachrichten (Messages) nach dem JMS-Standard zu empfangen und zu verarbeiten. JMS wird in einem späteren Kapitel genauer diskutiert. Persistence Entity Als Artefakt der Jave-Persistence API ist dieser EJB-Typus die Implementierung von Domänen-Objekten der Anwendung, die dauerhaft persistiert werden sollen. Über die Java Persistence API ist eine JEE-Anwendung in der Lage Objekte in Datenbanken abzulegen oder Daten als konkrete Objekte aus einer Datenbank zu instanziieren. Bei relationalen Datenbanken, die in heutigen Umgebungen vorherrschen wird dieser Prozess mit Object-Relational-Mapping bezeichnet (OR-Mapping/ORM). Der Anwendung wird hierbei die Verantwortung entzogen, die genaue Speicherung ihrer persistenten Daten selbst zu implementieren Dienste und APIs Wie zu Beginn des Abschnitts beschrieben, kommunizieren JEE-Anwendungskomponenten über den Container mittels definierter Schnittstellen mit anderen JEE-Containern und deren Anwendungen. Im Folgenden werden die in MeDIC verwendeten Dienste und APIs kurz charakterisiert. Abbildung 2.7 zeigt eine Übersicht über den EJB-Container und die Dienste, die laut JEE-Spezifikation für diesen Container-Typ vorgeschrieben sind. Da MeDIC mit EJBs implementiert wurde, laufen wichtige Komponenten innerhalb dieses Containers. MeDIC nutzt daher auch die bereitgestellten Dienste und APIs des Containers. Java Persistence Api (JPA) Die Java-Persistence Api bietet Zugriffsmöglichkeiten auf Datenbankfunktionalitäten zur dauerhaften Speicherung von relevanten Daten. Dafür spezifiziert diese API ein Mapping-Schnittstelle, um Objekte direkt in Datenbankobjekte 24

39 2.6. Praktische Grundlagen - Java Enterprise Edition EJB Container rvlet EJB Connectors Java Persistence JTA JSF JSTL JavaMail JAX-RPC JAX-WS SAAJ JAX-RS JAXR JASPIC JACC CDI & DI Web Services WS Metadata Management JMS Connectors JTA JavaMail Java Persistence Java SE Abbildung 2.7.: EJB Container und seine Dienste zu transformieren. Der vorgestellte EJB-Typ Persistence Entity ist das Codeartefakt von JPA. Diese EJBs werden dann über den sogenannten Entity-Manager verwaltet. Dieser kann die Datenobjekte laden, d.h. instanziieren, suchen, speichern und löschen. Zusätzlich lassen sich über eine domänenspezifische Sprache (kurz: DSL) Anfragen an das Datenbanksystem stellen. Diese DSL, die Java Query Language (JQL) ist an die Standard-Abfrage-Sprache für relationale Datenbanken SQL angelehnt. Listing 2.1 zeigt ein MeDIC-Informationsbedürfnis in seiner Implementierung als JPA-Entity. ava EE 6 Diagram Database Quelltext 2.1: Eine Persistence Entity für JPA 1 package de.rwth.swc.medic.dashboard.ejb.backend.domain; public class InformationNeedConfig 6 { = GenerationType.IDENTITY) 9 private int id; private String question; Java EE Platform requirements for each 25

40 2. MeDic - Metric-Based Project and Process Management Java API for XML Webservices (JAX-WS) JAX-WS bietet eine API zur Erstellung von XML-basierten Webservices, mit ihnen sind EJBs in der Lage, mit externen Anwendungen zu kommunizieren. Die Kommunikation basiert auf SOAP-Nachrichten, einem XML-Schema für standardisierte Nachrichtenübermittlung von Objekten. EJBs lassen sich über Annotation in entsprechende Webservices verwandeln. Öffentliche Methoden werden zu Webservice-Methoden. Der JEE-Container sorgt auf Serverseite für die entsprechende Bereitstellung der WSDL und die entsprechende Transformation von SOAP-Anfragen. Auf Clientseite ist es mit Tools der JEE möglich, aus einer entsprechenden JAX-WS konformen WSDL einen Client automatisiert zu generieren. Im besten Fall unterscheidet sich die Verwendung eines EJBs als Webservices nicht von seiner Benutzung als interner Service. Listing 2.2 zeigt die MeDIC DataStore-Komponente, die mit Annotation als Webservice veröffentlicht wird. Der Prototyp in Kapitel 8 nutzt diesen Webservice zur Übergabe von Metrikwerten an das MeDIC-Dasboard. Quelltext 2.2: JAX-WS public class MedicDataStoreFacadeBean implements MedicDataStoreFacadeLocal { 5 6 StringDataSeriesDBControllerLocal stringdataseriesdbcontroller; 7 8 DoubleDataSeriesDBControllerLocal doubledataseriesdbcontroller;

41 Teil II. Integration 27

42

43 3. Integration - Definition und Eigenschaften Inhalt 3.1. Definition Qualitätskriterien einer Integrationslösung Das Hauptproblem, mit dem sich diese Diplomarbeit befasst, ist das Problem der Integration von Systemen in die MeDIC-Plattform. Dieses Kapitel wird dieses Problem definieren und seine Eigenschaften analysieren. Im Folgenden werden Qualitätskriterien aufgestellt mit denen sich Integrationslösungen bewerten lassen Definition Um das Problem der Integration zu lösen, muss zunächst einmal klar sein, was mit diesem Begriff eigentlich gemeint ist. In vielen Bereichen der Informatik tritt der Begriff Integration auf. Datenbanken: Datenintegration [117] Business Intelligence: Informationsintgration [117] Software Test: Integrationstest [15] Das IEEE Glossary [67] definiert Integration wie folgt: integration. The process of combining sofware components, hardware components, or both into an overall system. Diese Definition beschreibt abstrakt die Integration als Prozess der Zusammenführung von Systemen zu einem kombinierten System. Die Abstraktion vermittelt leider nicht die Eigenschaften der Integration. Deshalb soll im Folgenden die nachstehende Definition mit den danach ausgeführten Eigenschaften gelten. Integration bezeichnet den Prozess der Zusammenführung eigentlich inkompatibler Systeme in eine gemeinsame Struktur, sodass die Daten systemübergreifend weiterverarbeitet werden können. Eine weitere Eigenschaft der Integration ist, dass die zugrundeliegenden Systeme an sich nicht verändert werden. Jedes kann auf seine eigene Weise autark 29

44 3. Integration - Definition und Eigenschaften von anderen Systemen arbeiten. Integrierte Systeme sind daher immer eigenständig lauffähig. Der Grund für diese Eigenschaft liegt an zwei wesentlichen Merkmalen von Softwareprodukten. Jedes Softwareprodukt kapselt eine gewisse Funktionalität und normalerweise sind die Komponenten innerhalb dieses Systems aufeinander abgestimmt, es handelt sich im eigentlichen Sinne um abgeschlossene Systeme. Abgeschlossenheit beinhaltet die fehlende Möglichkeit, Veränderungen an internen Datenstrukturen oder Verarbeitungskomponenten vorzunehmen. Folgende Gründe sind dafür verantwortlich. Kompilat: Das Softwaresystem liegt oft nur als Kompilat vor, und es steht kein Quellcode zur Verfügung um ein neues verändertes Kompilat zu erzeugen. Spezialwissen: Software kapselt Lösungen für Probleme, für die oft ein großes Spezialwissen notwendig ist, meistens besitzen nur die Entwickler entsprechendes Know-How in Bezug auf die Problemdomäne und die implementierte Lösung, sodass eine Veränderung ohne diese Wissen nicht von Erfolg gekrönt wäre. Lizenzen: Viele Softwareprodukte und das darin enthaltene Know-How sind durch entsprechende Verträge und Lizenzen vor nicht gewünschter Veränderung und Nutzung geschützt. Im Gegensatz zu geschlossenen Systemen sind offene Systeme einfacher zu integrieren bzw. eine Integration ist an vielen Stellen nicht notwendig, da sich diese Systeme entsprechend den Integrationsbedürfnissen anpassen und erweitern lassen. Jedes Integrationsproblem für zwei beliebige Systeme besteht aus zwei Komponenten 1. Kommunikation Der Begriff Kommunikation bezeichnet hier die Art und Weise, wie Systeme miteinander interagieren können. Eine funktionierende Kommunikation zwischen Systemen ist die grundlegendste Bedingung für eine erfolgreiche Integration. Interaktionsparadigmen, wie das Service-Paradigma (siehe Abschnitt 5.1.3) oder das Agenten-Paradigma (siehe Abschnitt 5.1.5) sind im Laufe der Zeit viele entstanden, und es entstanden eine ganze Reihe von Protokollen und Standards. Bei der Entwicklung eines Systems kann sich der Entwickler jedes dieser Protokolle und Standards bedienen. Insbesondere ältere Systeme bedienen sich Standards, die heute nicht mehr üblich in Gebrauch sind. Trotzdem sind diese Systeme für ein Unternehmen immens wertvoll. 2. Daten Der Begriff Daten bezeichnet die Probleme, die durch unterschiedliche Datenformate entstehen. Das interne Datenformat, das ein System wählt, ist oft geprägt von der Fachlichkeit der konkreten Anwendung. Eine Über- 30

45 3.2. Qualitätskriterien einer Integrationslösung tragung zu anderen Systemen ist normalerweise nicht vorgesehen. Ein Integrationssystem überwindet diese unterschiedlichen Datenformate und ermöglicht so einen Datenaustausch zwischen vorher nicht kompatiblen Systemen. In seinem Buch über Refactoring beschreibt Michael Feathers eine wichtige Eigenschaft von Softwaresystemen: Behaviour is the most important thing about software. It is what the user depend on. [...], but if we change or remove behaviour, behaviour they depend on (introduce bugs), they stop trusting us. Das Verhalten einer Software wird bestimmt durch ihre Daten und ihre Kommunikationsweise. Das bedeutet, Softwaresysteme werden über ihre Lebensdauer hinweg ihr Verhalten nicht oder nur minimal ändern. Unterstützt wird diese Aussage von Untersuchungen im Bereich der Application Programming Interface (API)-Evolution, also der Änderung von Schnittstellen. Die Autoren um D. Dig haben in Studien gezeigt, dass über die Zeit bis 97% und im Minimum 81% der Änderungen an einer Software keinerlei Verhaltensänderungen nach sich gezogen haben [35, 36]. Das hat für die Integration zwei Konsequenzen, erstens bleiben inkompatible Systemen auch inkompatibel und zweitens bleiben integrierte Systemen integriert. Aus der ersten Konsequenz leitet sich ein zentraler Begriff dieser Diplomarbeit ab, der Begriff der Heterogenität. In Kapitel 4 wird dieser Begriff als eine der Kernherausforderungen für eine erfolgreiche Softwarearchitektur für MeDIC definiert und analysiert. Die zweite Konsequenz birgt eine immense Motivation für den Bau von Integrationslösungen, denn stabile Systeme bedeuten stabile Integration Qualitätskriterien einer Integrationslösung Für die Auswahl einer entsprechenden Integrationslösung finden sich im Buch Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions [59] von Hohpe und Wolf entsprechende Kriterien: Kopplung von Applikationen: Eine Integrationslösung soll die Abhängigkeiten zwischen Applikationen minimieren. Das heißt konkret, eine spezifische Applikation soll bei ihrer Weiterentwicklung eine Auswirkungen auf kein anderes System haben. Insbesondere sollten viele und spezifische Annahmen über andere Systeme vermieden werden. Das Integrationssystem sollte als einzige Referenz bestehen, damit ähnelt dieses lose Kopplungsprinzip dem Mediatorpattern [50, 113] 31

46 3. Integration - Definition und Eigenschaften Sensibilität: Bei einer Integration sollte, möglichst keine gravierenden Änderungen an den zu integrierenden Softwareprodukten selber notwendig sein. Natürlich sind Änderungen notwendig, ansonsten wäre auch eine Integration nicht notwendig, diese Änderungen sollten aber gut gekapselt und am besten autark durchgeführt werden können. Im Sinne des ersten Prinzips ist ja auch die Kopplung zu minimieren. Technologieauswahl: Ein entscheidendes Kriterium bei der Auswahl von Integrationslösungen sind die technischen Rahmenbedingungen aus Hard- und Software innerhalb des Unternehmens. So wäre es möglich, dass für eine bestimmte Lösung ein Softwareprodukt mit immensen Lizenz- oder Betriebskosten notwendig wäre. Das Know-How innerhalb des Unternehmens über eine gewisse Technologie kann weiterhin die Auswahlmöglichkeiten einschränken. Dem gegenüber steht die Neu- bzw. Eigenentwicklung, deren Kosten normalerweise nur schwer geschätzt werden können. Grade Integrationsprojekte kämpfen mit vielen nicht vorhersehbaren dynamischen Problemen. Datenformat: Damit unterschiedliche Anwendungen miteinander interagieren können, müssen Daten ausgetauscht werden, aus den Kriterien der Kopplung und Sensibilität lässt sich ableiten, dass die Nutzung applikationsspezifischer Datenformate zu vermeiden ist. Eine Integrationslösung fungiert eher als Übersetzer zwischen diesen Formaten. Daher ist ein entscheidendes Kriterium für die Integrationslösung ihre Unterstützung bei der Definition bzw. Nutzung eines vereinheitlichten Datenformates. Latenz: Interagierende Systeme müssen ihre Daten schnell und effizient weitergeben können. Die Latenz zwischen Datenabgabe und Verarbeitung der Daten im Empfängersystem muss minimiert werden. Um so größer die Latenz, umso wahrscheinlicher sind die Daten veraltet. Entscheidungen auf Basis von veralteten Systemen können fatal sein. Für Chappell [22] ist dies sogar eines der wichtigsten Argumente für seine Integrationslösung, den Enterprise Service Bus. Daten und Funktionalität: Zusätzlich zur Weitergabe von Daten können Systeme auch Funktionalitäten für andere Systeme exportieren. Im Software Engineering spricht man an dieser Stelle von Trennung der Zuständigkeiten ; diese gehört dort zu den wichtigsten Entwurfsprinzipien für Softwarekonstruktionen. Das höhere Maß an Abstraktion, das dadurch erreicht wird, findet sich bei Integrationslösungen, die eine Integration von Funktionalitäten zulassen. Dieses Entwurfsprinzip gilt auch auf Ebene von interagierenden Softwaresystemen. 32

47 3.2. Qualitätskriterien einer Integrationslösung Asynchronität: Die normalerweise synchrone Kommunikation zwischen Softwarekomponenten - eine Klasse schickt eine Nachricht an eine andere Klasse und wartet auf das Ergebnis - kann sich auf Ebene von interagierenden Systemen als problematisch erweisen. Zunächst ist nicht prognostizierbar, wie lange eine Nachricht zum Zielsystem braucht. Da integrierte Systeme auch weit entfernt voneinander arbeiten können, kann sich diese Zeit der Übermittlung erhöhen. In dieser Zeit werden Ressourcen im aufrufenden System gebunden und stehen erst nach Ablauf eines Timeouts oder nach Antwort durch das Zielsystem wieder zur Verfügung. Asynchronität ist eines der wichtigsten Entwurfsprinzipien für Integrationslösungen. Zuverlässigkeit/Verfügbarkeit: Zusätzlich zum Problem der Übermittlungsdauer ist es nicht sicher, dass entfernte Systeme überhaupt verfügbar sein. Eine Integrationslösung muss in der Lage, diese Probleme abzufedern, indem sie z.b. die zu übermittelnden Daten für die Empfängersysteme vorhält, bis diese wieder verfügbar sind. Im besten Falle merkt das Quellsystem nichts von diesen Problemen. Diese Qualitätsmerkmale dienen als Beurteilungsbasis auch für die vorgestellte Integrationsarchitektur von MeDIC. Gleichzeitig können daraus auch Anforderungen abgeleitet werden, die beim Design der Lösung beachtet werden sollten. 33

48

49 4. Anforderungen an den Entwurf Inhalt 4.1. Heterogenität Datenheterogenität Systemheterogenität Funktionsheterogenität Kommunikationsheterogenität Heterogene Interpretation Verfügbarkeit oder Verteilte Heterogenität Asynchrone oder autonome Integration Performance Operationelle Sensibilität Erweiterbarkeit Zusammenfassung In den vorangegangen Kapiteln wurden die theoretischen und fachlichen Grundlagen für MeDIC und die Integration als Problem von verteilten Softwaresystemen diskutiert. Aus den Erkenntnissen der letzten Kapitel werden in diesem Kapitel die Anforderungen für eine Integrationsarchitektur für MeDIC diskutiert, die mittels der Integrationsqualitätskriterien von Hohpe et al. [59] als positiv bewertet werden kann. Sie soll anders als bisherige Systeme als echte Integrationslösung fungieren. In der bisherigen Forschung über die Möglichkeiten zur Entwicklung eines Software-Dashboards ist das Integrationsbedürfnis stets von nachrangigen Interesse. Der grundsätzliche Ablauf vieler Ansätze impliziert einen drei-stufigen Ansatz [91]: 1. Datensammlung 2. Datenvalidierung und -integration 3. Datenanalyse und -visualisierung Dieser Ansatz ähnelt den bekannten Strategien aus dem Bereich des Data- Warehousing und dem KDD-Process ( Knowledge Discovery in Databases ). Data Warehousing wird einem späteren Abschnitt als eine Form der Integration 35

50 4. Anforderungen an den Entwurf nochmals genauer beleuchtet. Viele der verfügbaren Softwaresysteme, insbesondere die kommerziellen Systeme, basieren auf diesem Ansatz, da in den Unternehmen die relevanten Daten oft schon in solchen strukturierten Datenbanken vorliegen. Der Softwarehersteller muss dann nur noch eine entsprechende Analyseoberfläche bereitstellen Heterogenität Wie in Kapitel 3 beschrieben, ist das Ziel einer Integrationslösung die Zusammenführung und -arbeit eigentlich inkompatibler Systeme in eine gemeinsame Struktur, sodass Daten und ggf. auch Funktionen geteilt werden können. Diese zu integrierenden Systeme sind normalerweise in sich abgeschlossen, ihre internen Datenstrukturen proprietär, ihre gegebenenfalls vorhandenen Schnittstellen sind technologisch und strukturell sehr unterschiedlich. Im Integrationskontext definiert das ein heterogene Systemlandschaft [52, 18]. Heterogenität ist damit eines der Hauptprobleme für eine Integrationslösung. Die entsprechende Anforderung an eine neue Integrationslösung lautet daher, eine möglichst einfache und flexible Struktur anzubieten mit dieser Heterogenität umzugehen. Heterogenität findet sich auf verschiedenen Ebenen eines Softwaresystems, in der Technologie, in der Struktur oder auch in der Semantik der Anwendung. Wache et al [117] sprechen von struktureller Heterogenität und semantischer Heterogenität. Die erste Art umfasst Unterschiede im Schema der Daten, also in der Beschreibung und Strukturierung. Die zweite Art umfasst Unterschiede in der beabsichtigten Bedeutung der Daten. Diese zwei Klassen von Heterogenität umfassen aber nicht alles, was in Bezug auf ein Integrationsproblem relevant ist. In einer Softwarelandschaft gibt es zusätzlich das Verhalten der Systeme, das beachtet werden muss. Zusätzlich spielt die Technologie der Systeme eine wichtige Rolle, strukturelle und semantisch identische Daten können in technologisch unterschiedlichen Systemen vorliegen und dadurch inkompatibel bleiben, obwohl die Daten an sich kompatibel sind. Diese Problematik tritt insbesondere bei der Integration von älteren Softwaresystemen auf. In den folgenden Abschnitten wird eine erweiterte Klassifikation der Heterogenität anhand dieser vorkommenden unterschiedlichen Ebenen in den zu integrierenden Systemen eingeführt. Insgesamt finden sich vier Klassen: Datenheterogenität Systemheterogenität Funktionsheterogenität Kommunikationsheterogenität Kishore et al. [76] stellen eine ähnliche Unterteilung fest. Sie definieren drei 36

51 4.1. Heterogenität Ebenen für die Integrationsanforderungen Technology Integration, Data Integration und Word Systems Integration. Diese Bereiche korrespondieren mit den bisher definierten Heterogenitätsbereichen. Die Eigenschaften der Systemheterogenität werden bei Kishore unter Technology Integration zusammengefasst. Der Bereich Data Integration ist identisch, mit Word Systems Integration wird die Koordination zwischen den Systemen bzw. Akteuren und ihren Aktivitäten innerhalb eines Prozesses bezeichnet. Dies kombiniert die Kommunikations- und Funktionsheterogenität Datenheterogenität Datenheterogenität bezeichnet die Unterschiede in den Daten an sich, d.h. in ihren Strukturen, Formaten, Wertebereichen und ihrer Komplexität. Selbst Daten, die eine ähnliche Semantik haben, können durch die Unterschiede in diesen Bereichen untereinander inkompatibel sein. Strukturelle Datenheterogenität Softwaresystemen liegen immer Datenstrukturen zu Grunde, auf welchen diese Systeme operieren. Grundlegende Datenstrukturen in Softwaresystemen sind Listen, Bäume, Graphen und Objekte. Jedes Softwaresystem kombiniert diese und weitere Strukturen in ihre fachliche Datenstruktur, dieser Schritt wird gemeinhin als Datenmodellierung bezeichnet. Die Datenmodellierung ist ein elementarer Schritt beim Design eines Softwaresystems. Bei der Integration von Softwaresystemen finden sich nun eine Vielzahl unterschiedlicher Datenstrukturen, die integriert bzw. von anderen Systemen verarbeitet werden müssen. In Bezug auf MeDIC besteht die Anforderung, dass diese Datenstrukturen als Messobjekte dienen, die mittels Metriken vermessen und dann weiter analysiert werden können. Die Notwendigkeit der Integration von unterschiedlichen Datenstrukturen wird in der ISO-Norm nicht berücksichtigt. Für den Prozess und das Messmodell spielen diese strukturellen Unterschiede keine Rolle, es handelt sich um eine Anforderung auf technischer Ebene des Messprozesses. Im Datenbankumfeld, insbesondere in Data-Warehousebereich, spielen die strukturellen Unterschiede eine größere Rolle. Das Ziel eines Data-Warehouses ist die Zusammenführung aller Daten unter einem gemeinsamen Datenmodell. Das daraus resultierende Problem des Schema- Mapping ist ein gut erforschtes Gebiet in der Forschung, konnte aber nie vollends zur Zufriedenheit gelöst werden. Bernstein [12] spricht in seiner Betrachtung von 10 Jahren Forschung von vielversprechenden neuen Ansätzen, definiert das Problem aber als ergebnisoffen. Was MeDIC von dem Data-Warehouse unterscheidet und die Anforderung nach einem gemeinsamen Datenmodell abschwächt, ist die Ebene der Zusammenführung. In MeDIC bzw. im Messprozess können Metriken unabhängig voneinander betrachtet werden, sie sind im Sinne der Datenintegration autonom. Beispiele für Strukturelle Datenheterogenität. 37

52 4. Anforderungen an den Entwurf Tief verschachtelte semi-struktuierte Daten im Gegensatz zu flachen relational geprägten Daten oder auch simplen unstrukturierten Daten Zeit: Zeitzonen Offene und geschlossene Datenstrukturen (.doc,.docx) Semantische Datenheterogenität Die Semantik der Daten ist immer applikationsspezifisch und damit im Kontext dieser Applikation zu sehen. Goh [52] identifiziert drei Ursachen für semantische Konflikte, erstens durch die Verwechslung von Begriffen, zweitens durch unterschiedliche Bezugswerte bei Messungen und drittens durch unterschiedliche Terminologie von semantisch identischen Daten, z.b. durch Verwendung von Synonymen. Begegnet wird dieser Heterogenität in Form von Ontologien, formalen Spezifikation zur Darstellung von Begriffen und ihren Beziehungen. Wache et al. [117] präsentieren in ihrer Arbeit eine Übersicht der Nutzung von Ontologien im Bereich der Integration. Beispiele für semantische Datenheterogenität Verwechslung: Der Begriff der Integration im Bereich der Informatik Bezugssysteme: Finanztransaktionen in unterschiedlichen Währungen. Terminologie: Remote Procedure Call und Service Systemheterogenität Die Auswahl an Softwaresystemen für eine konkrete Problemstellung ist immens. Für fast alle Aufgabenstellungen innerhalb des Softwareentwicklungsprozesses gibt es passende Softwaresysteme. MeDIC soll daher in die Lage sein viele unterschiedliche Softwaresysteme zu integrieren bzw. ihre Integration leicht und mit möglichst wenig Aufwand zu ermöglichen. Verkompliziert wird der Umstand, dass sich die Technologien vieler Systeme immens unterscheiden kann, da sich über die Jahre neue Technologien und Paradigmen entwickelt haben. Beispiele für die Systemheterogenität: Softwarekonfigurationmanagement (SCM): CVS, Subversion, GIT, Mercurial Changerequestmanangement: Trac, Bugzilla, Jira Planungsmanagement: MS Projekt Anforderungsdokumente: UML, Word, Excel 38

53 4.1. Heterogenität Funktionsheterogenität Als Funktionsheterogenität werden die Unterschiede in den Problemlösungen definiert, die verschiedene Softwaresysteme bearbeiten. Grundlegend existieren in Bezug auf MeDIC drei unterschiedliche Klassen von Systemen. Datenbanken Dabei handelt es sich um Systeme die Daten verwalten, Beispiele sind die SCM-Systeme,CRM-Systeme oder Data-Warehouse-Systeme mit unternehmensrelevanten Daten. Messsysteme Bei Messsystemen handelt es sich um Systeme, die Metriken berechnen können. Dazu gehören Systeme wie SONAR [109] oder QMetric [104, 103] Verarbeitungssysteme Dabei handelt es sich um Systeme, die Daten verarbeiten und damit neue Daten produzieren. Beispiele sind hier Compiler aber auch ein CI-Server wie Hudson Kommunikationsheterogenität In Kapitel 3 wurde der Bereich Kommunikation als zweite Komponente für die Definition eines Integrationsproblems benannt. Im vorherigen Abschnitt wurden Systeme nach ihrer Funktionalität bzw. Technologien unterschieden. Unterschiedliche Funktionen basieren auch auf unterschiedlichen Paradigmen. Da in einem Integrationsproblem grundsätzlich bestehende Systeme unterschiedlichen Paradigmen folgen können, besteht die Anforderung darin, diese unterschiedlichen Paradigmen zu adaptieren. Grundsätzlich unterscheidet diese Arbeit nicht anhand des tatsächliches Paradigmas, sondern anhand des Verhaltens gegenüber anderen Systemen in einer verteilten Softwarelandschaft. Die Kommunikationsstrukturen korrespondieren mit den Integrationsarchitekturen aus Kapitel 5. Das erste Paradigma ist die Schleifen-Kommunikation, d.h. ein System kommuniziert prinzipiell nur mit sich selber. Daher kann es seine internen Datenstrukturen beliebig wählen. Eine Kommunikation nach außen ist nicht vorgesehen. Diese Schleifenkommunikation korrespondiert mit der Dateibasierten Integrationsarchitektur. Die zweite Variante ist die Punkt-zu-Punkt-Kommunikation, d.h. ein System implementiert eine Kommunikation nur zu einem einzigen zweiten System. Klassischer Partner ist dabei ein Datenbanksystem, damit korrespondiert diese Kommunikationsart mit dem Integrationspattern Gemeinsame Datenbank. Das Kommunikationsverhalten in dieser Konstruktion ist Aktiv-Passiv, d.h. die Datenbank ist der passive Partner und agiert nicht von selbst aus. Die dritte Variante basiert auf dem Service-Paradigma. Systeme sind dort als 39

54 4. Anforderungen an den Entwurf Services angelegt, die als Service Provider Daten und Businesslogik über Servicemethoden nach außen für Klienten bereitstellen. Das Kommunikationsverhalten ist in diesem Fall umgekehrt, das zu integrierende System ist passiv, der Integrator der aktive Part der Kommunikation. Die Kommunikation besteht auch aus vielen Kommunikationspartnern, die gegeben falls parallel auf einen Service zugreifen. Die vierte Variante basiert auf einem Kommunikationsverhalten, wo alle Parteien in einer Aktiv-Aktiv-Konfiguration vorliegen. Alle Kommunikationspartner können Nachrichten konsumieren und auch verschicken. Die jeweilige Kommunikation zwischen je zwei Agenten ist dann wieder eine Punkt-zu-Punkt- Kommunikation. Agenten-basierte Kommunikation erfolgt durch eine Folge spezifischer Nachrichten, bei Kischore und anderen [76, 122, 58] auch als Verhandlung oder Unterhaltung bezeichnet. Agentensysteme nutzen auch eine gemeinsame Sprache, die sich aus einem gemeinsamen System zusammensetzt, den Ontologien. Barret et al. sprechen in ihrem Paper [7] über ereignisorientierte Integration von Softwaremodulen auch von Punkt-zu-Punkt, aber zusätzlich von Multicast als primärer Kommunikationsmethode. Multicast beinhaltet die Propagation einer Nachricht von einem Sender zu mehreren Empfänger. Da Multicast insbesondere im Messprozess von MeDIC eine wichtige Rolle spielt, wird es als fünftes und letztes Kommunikationsverhalten für ein Integrationsproblem definiert Heterogene Interpretation Die ISO-Norm [72], vorgestellt in Kapitel 2, definiert vier Klassen von Messungen bzw. Metriken: Basismetriken, abgeleitete Metriken, Indikatoren (analysierte Metriken) und insbesondere Informationsprodukte (interpretierte Metriken). Der Messprozess bildet einen linearen Datenfluss, basierend auf den Basismetriken hin zu Informationsprodukten als Endstufe. Aus der im vorherigen Abschnitt definierten Anforderung der Integration von heterogenen Daten und Systemen, ergibt sich automatisch eine neue Anforderung, die der heterogenen Interpretation. Heterogene Interpretation bedeutet, dass erweiternd zur ISO-Norm Me- DIC nicht nur Basismetriken integrieren soll, sondern auch Metriken von externen Systemen erhoben, abgeleitet und interpretiert werden dürfen. Insbesondere Messsysteme wie Sonar und QMetric (siehe Kapitel 6 können solche Informationen liefern. MeDIC soll also Metriken aus allen vier Klassen integrieren. Gleichzeitig beinhaltet dies, dass ergänzend zur ISO-Norm MeDIC auch abgeleitete Metriken aus abgeleiteten Metriken erzeugen kann. Es handelt sich also nicht mehr um einen linearen Datenfluss, sondern eher um ein Datenflussnetzwerk. Abbildung 4.1 zeigt diesen ergänzten Datenfluss. Die Darstellung nutzt 40

55 4.2. Heterogene Interpretation Datenfluß Attribut Metrik erheben Basismetrik Metrik berechnen Metrik analysieren Abgeleitete Metrik Indikator Abbildung 4.1.: Datenfluss den UML-Diagrammtyp des Aktivitätendiagramms zur Darstellung des Datenflusses wie von Störrle[111]. definiert. Die Integration von Metriken aus allen Metrikklassen erhöht die Flexibilität des Systems und verhindert den redundanten Aufwand in der Entwicklung von Messmethoden, Messfunktionen und Interpretationsfunktionen innerhalb von MeDIC. Gleichzeitig erhöht es aber auch die strukturelle Komplexität des Systems, da es erstens keinen einfachen Datenfluss mehr gibt und zweitens die Integration von Messsystemen komplexer ist als die Integration von Datenbanken. Die Integrationsarchitektur von MeDIC muss daher eine möglichst einfache und flexible Struktur aufweisen, um dies zu gewährleisten. Diese Anforderung fordert ein ähnliches Prinzip wie das Architekturprinzip Trennung der Zuständigkeiten im Objekt-orientierten Softwareentwurf. Dort wird, wie von Laplante in seinem Buch [79] beschrieben, durch Kapselung und Information Hiding, zwei weiteren Prinzipien des OO-Softwareentwurfs, eine Dekomposition der Software in modulare Einheiten unter Beibehaltung der Funktionalität und des Verhaltens angestrebt. Auch moderne Refactoring Methoden setzen auf eine Zerlegung der Software zur besseren Wartbarkeit und der Verringerung von Abhängigkeiten, Feather und Fowler erstellen in ihren Büchern [42, 48] einen ganzen Katalog solcher erprobter Refactoring-Methoden. 41

56 4. Anforderungen an den Entwurf 4.3. Verfügbarkeit oder Verteilte Heterogenität Bei der Identifikation relevanter Systeme und Datenquellen für die Etablierung eines Messprozesses ergibt sich eine neue Anforderung, die flexible Handhabung der volatilen Verfügbarkeit externer Systeme. Ein Grundproblem der Integration ist die Tatsache, dass es sich bei den zu integrierenden Systemen um ein verteiltes Informationsnetzwerk handelt und dass alle Systeme auch autonom von einander agieren können. Für ein Integrationssystem ist daher die Sicherstellung von Hochverfügbarkeit nicht möglich. Service-Orientierte-Architekturen (SOA),wie von Papazoglou beschrieben [51], setzen auf das ein Qualitätsmodell, das den Service und seine Verfügbarkeit beschreibt. Dieser wird zwischen den Integrationspartnern zu einem Servicevertrag erweitert, in welchem der Service Zusicherungen bezüglich Verfügbarkeit, Sicherheit und Zuverlässigkeit liefert. Für MeDIC wird kein solches Qualitätsmodell vorgeschrieben, da es sich bei den zu integrierenden Partnern leider nicht nur um Systeme handelt, die dem Serviceparadigma folgen (siehe Abschnitt 5.1.3) Asynchrone oder autonome Integration Hohpe et al. [59] definieren die asynchrone Datenverarbeitung als wichtiges Qualitätsmerkmal. Da es sich auch in der Bewertungsmatrix für Integrationlösungen befindet, ergibt sich für einen Architekturentwurf für MeDIC die Anforderung, Systeme wenn möglich auf asynchronem Wege zu integrieren. Bei der asynchronen Integration sind Quelle und Ziel der Integration soweit von einander entkoppelt, dass sie keinerlei Kenntnis über sich haben. Bei asynchroner Integration ergeben sich eine Vielzahl von Eigenschaften des Systems, die sich auch als hilfreich hinsichtlich der Umsetzung des Messprozesses [72] erweisen. Multiple dynamische Ziele Die asynchrone Integration ermöglicht die dynamische Änderung der Ziele für ein bestimmtes Datum, dabei muss das Quellsystem gar nicht über alle Ziele Kenntnis haben. Das Management der Ziele kann das Integrationssystem übernehmen, im Kontext der Enterprise Application Integration (EAI) wird dieses Management als Routing bezeichnet. Ein weiterer Vorteil z.b. in Bezug auf eine Webservice-basierte Integration ist die höhere Effizienz der Aufrufe, da bei synchroner Bearbeitung eine Produktion des Datums und der Aufruf der entsprechenden Schnittstelle beim Service für jedes Ziel individuell durchgeführt werden muss. Bei komplexen Operationen hilft das Routing Ressourcen zu sparen. In Bezug auf den Messprozess unterstützt das Routing die Möglichkeit, 42

57 4.5. Performance Basismetriken gleichzeitig verschiedenen abgeleiteten Metriken zur Verfügung zu stellen, wenn diese die Basismetrik nutzen. So wird ein oft kostenintensiver Aufruf der Messmethode zur Produktion der Basismetrik vermieden. Gleichzeitig kann durch Routing auch die Verarbeitungsrichtung koordiniert werden. Im Abschnitt über die Integration 4.2 wurde festgelegt, dass abgeleitete Metriken als Eingabemetriken (quasi als Pseudeo-Basismetrik) fungieren können, das Routing ermöglicht die Weiterleitung des Metrikergbnisses an das Analysemodell zur Produktion eines Indikators, aber auch gleichzeitig die Weiterleitung zu anderen abgeleiteten Metriken. Im optimalen Falle stellt die Metrik ihre Werte im Kontext der Messfunktionen bzw. Analysefunktionen nur zur Verfügung, ob sie tatsächlich genutzt werden ist dabei irrelevant Transformation während des Transports Ein weiterer nicht zu unterschätzender Vorteil einer asynchronen Übertragung ist die Möglichkeit Anfrage und Antwort der Kommunikationspartner während des Transports zu verändern. Über solche eine Transformation können Änderungen in der Datenstruktur korrigiert bzw. angepasst werden oder Sicherheitsaspekte wie Validierung oder Authentifizierung durchgeführt werden Performance Ein wesentliche Eigenschaft von verteilten Systemen ist nicht nur ihre ungewisse Verfügbarkeit, sondern auch ihre ungewisse Leistungsfähigkeit. Die Latenz zwischen Aufruf einer Geschäftskomponente und ihrer Antwort kann leider selten garantiert werden. In SOA-Architekturen definiert das Qualitätsmodell [51] solche nicht-funktionalen Anforderungen in einem sogenannten Service Contract [77]. Für MeDIC schwächen wir diese Anforderungen ab Operationelle Sensibilität In seinem Buch über den Enterprise Service Bus (ESB) [22] prägt Chappell den Begriff der operational awareness (dt: Operationelle Sensibilität). Damit bezeichnet er einen großen Vorteil des ESB gegenüber anderen Architekturmustern. Anders als bei Webservices sind die Systeme nicht passiv und warten auf Service-Clients, sondern sind aktive Komponenten. Die Latenz zwischen Auftreten eines relevanten Ereignisses und der Integration durch abhängige Systeme ist dadurch sehr gering. MeDIC wurde, wie in Kapitel 2 definiert, unter anderem als operationelles Dashboard designet, d.h. die Aktualität der Daten innerhalb des Dashboards ist für den Nutzer aus operationeller Sicht von immenser Bedeutung. Im Data- 43

58 4. Anforderungen an den Entwurf Warehouseumfeld ist diese Anforderung auch aufgetreten, dort hat sich eine Klasse von Real-Time DWH gebildet [13, 115, 125]. Eine Integrationsarchitektur für MeDIC muss daher versuchen, die Aktualität der Daten zu gewährleisten Erweiterbarkeit Die Menge an externen Systemen, die als Integrationsquelle für MeDIC zur Verfügung stehen, ist immens. Im Abschnitt über die Funtionsheterogenität haben sich mehrere Klassen an Softwareprodukten ergeben, die für eine Integration in Frage kommen. Eine wesentliche Anforderung an die Architektur ist demnach die flexible Erweiterung des Systems für die Integration neuer unbekannter Systeme. Wie schon vorher ausgeführt besteht bei der Integration das Problem, dass sich bestehende externe Systeme nicht ohne weiteres für die Integration anpassen lassen, sei es aus technischen, juristischen oder organisatorischen Gründen. Daher müssen systemspezifische Anpassungen gegebenenfalls in der Integrationslösung implementiert werden. Damit die Entwicklung dieser Komponenten ohne großen Aufwand durchgeführt werden kann, muss die Architektur einen flexiblen Mechanismus besitzen, um diese Komponenten sauber zu kapseln und lokal zu begrenzen. Die Architektur muss damit die Anforderungen von Rahmenwerken und deren Eigenschaften umsetzen Zusammenfassung Die Anforderungen, die an die Integrationsarchitektur von MeDIC gestellt werden, lassen sich insgesamt in drei Bereiche aufteilen. 1. Kompatibilität zum Messprozess der ISO-Norm [72] 2. Kompatibilität zur funktionalen Ausrichtung von MeDIC als Dashboardsoftware [44] 3. Umgang mit Heterogenität auf technischer sowie struktureller Ebene Alle Anforderungen lassen sich nicht disjunkt auf diese drei Bereiche aufteilen, da sie wie z.b. die Asynchronität eine technische sowie eine funktionale Komponente besitzen. Zusätzlich folgt aus vorliegenden Anforderungen ein interessanter Sachverhalt. Zunächst wird eine Überwindung der Heterogenität gefordert, um dann direkt anschließend mit Entwurfsprinzipien wie der Trennung der Zuständigkeiten mittels Kapselung, Information Hiding und Modularisierung wieder eine Dekomposition zu erreichen. Auch die Qualitätskriterien für Integrationslösungen fordern mit der losen Kopplung und der Asynchronität auch eine möglichst vollständige Trennung. Die Anforderungen für die Integrationsarchitektur lässt 44

59 4.8. Zusammenfassung sich unter folgendem Motto stellen: Miteinander, aber nicht zusammen!. 45

60

61 Teil III. Integrationsarchitektur für MeDIC 47

62

63 5. Integrationsarchitekturen In Kapitel 3 wurde die Integration als ein Problem bestehend aus beiden Teilproblemen Dateninkompatibilität und Kommunikationsinkompatibilität beschrieben. In diesem Kapitel werden die bisher entwickelten Ansätze zur Lösung des Integrationsproblems dargestellt. Dabei wird ein Fokus auf die Architektur der Ansätze gelegt und mit den bestehenden Qualitätskriterien für Integrationslösungen und den im letzten Kapitel entstandenen Anforderungen für Me- DIC bewertet. Die Reihenfolge ist chronologisch von den älteren Ansätzen, wie der Datei-basierten bis zu heutigen Lösungsmöglichkeiten über Services und Agenten. Trotzdem sind auch die älteren Ansätze immer noch relevant. Eine Umfrage im MeDIC Umfeld von Evers [41] förderte als Ergebnis den Wunsch vieler Nutzer nach der Integration von einfachen Datenstrukturen wie CSV oder Exceldateien. Zur besseren Übersicht werden die Architekturen am Ende innerhalb einer Bewertungsmatrix gegenübergestellt. Mit der Vorstellung der Architekturen werden einige wichtige Begrifflichkeiten vorgestellt und in den Kontext des Integrationsbegriffs gestellt. Über die Jahre etablierten sich viele Begrifflichkeiten und Terminologien, was zu einer gewissen babylonische Sprachverwirrung geführt hat Typen von Integrationslösungen Integration über Dateien Die erste und einfachste Möglichkeit besteht darin, dass eine Applikation von sich aus eine Datendatei erstellt und diese anderen Daten zur Verfügung stellt. Dabei produziert bzw. exportiert eine Applikation ein bestimmtes definiertes Datenformat als Datei. Die Übertragung kann dann auf datei-basierte Protokolle und Standards aufbauen, beispielsweise FTP 1. Beliebt in diesem Zusammenhang sind die Produktion von CSV-Datein, einer flachen Datenstruktur auf ASCII-Basis, bei Datenwerte über ein Separierungszeichen getrennt werden. Eine Zeile entspricht dort üblicherweise einem Datensatz. Abbildung 5.1 zeigt eine Darstellung der Funktionsweise der dateibasierten Integration, in der Applikation A seine Daten als Dateien exportiert und Applikation B diese verarbeitet

64 5. Integrationsarchitekturen Dateibasiert Applikation A EXPORT BIN TEXT IMPORT Applikation B Geteilte Daten Abbildung 5.1.: Integration über Dateien nach [59] Dieser Typus einer Integrationslösung hat Vorteile, aber auch eine ganze Reihe von Nachteilen. Bei den Vorteilen überwiegt, dass bei den Entwicklern kein spezifisches Applikations-Know-How vorhanden sein muss, um die Applikation zu integrieren. Rein das fachliche Verständnis des Datenformats reicht dort aus. Daher sind datei-basierte Integrationslösungen prinzipiell lose gekoppelt und entsprechen damit diesem Qualitätskriterium für eine gute Integrationslösung. Nachteilig wirken sich dagegen die Asynchronität der Integration aus. Produktion und Konsum sind entkoppelt, d.h. eine direkte Kommunikation zwischen den Systemen findet nicht statt. Um trotzdem erfolgreich arbeiten zu können, muss vorher zwischen Applikationen bestimmt werden, wie Dateien erzeugt und konsumiert werden. Üblicherweise wählt man hier eine gemeinsame Periodizität, wonach z.b. Exporte nachts erzeugt und danach verarbeitet werden. Durch längere Exportlaufzeiten kann die Integration fehlschlagen, da z.b. der Produzent seinen Export noch nicht fertiggestellt hat, der Konsument aber schon beginnt, die Daten abzuarbeiten. Ein weiteres Problem ist dadurch gekennzeichnet, dass relevante Ereignisse beim Eintreten nicht direkt in einen neuen Export fruchten, sondern erst nach einer gewissen Zeit exportiert werden. Die produzierte Datei ist damit schon veraltet. Das Thema der Asynchronität und der hier dargestellten Verzögerung der Kommunikation ist ein wichtiger Faktor für Integrationslösungen. Ein weiterer Nachteil besteht darin, dass prinzipiell die Last der Integration alleine beim Konsumenten liegt. Im Hinblick auf die Anforderungen für MeDIC ist die Architektur denkbar schlecht geeignet, da sie wesentliche Heterogenitätsanforderungen nicht abbilden kann. So gibt es nur ein einziges Kommunikationsmuster. Wenige Anforderungen wie die Unterstützung von mehreren Zielen für die Daten oder die Autonomie der Systeme, sind erfüllt. Auch eine Einbindung in den Messprozess der ISO15939 ist gegeben. 50

65 5.1. Typen von Integrationslösungen Datenbank Applikation A Applikation B Applikation C Gemeinsame Daten Abbildung 5.2.: Integration über eine gemeinsame Datenbank nach [59] Gemeinsame Datenbank Der Typus der gemeinsamen Datenbank gehört mit zu den verbreitetsten Integrationslösungen. Moderne Unternehmenssoftware nutzt oft ein Datenbankmanagementsystem zur persistenten Verwaltung und Speicherung von Daten. Daher liegt es nahe, die Datenbasis auch anderen Applikationen zugänglich zu machen. In vielen Fällen liegt der Datenbank ein relationales Modell zu Grunde. Über eine gemeinsame Datenbank könnten Applikationen Daten in bidirektionaler Weise verarbeiten. Darin liegt ein großer Vorteil dieses Typus. Abbildung 5.2 visualisiert die Integration von drei Applikationen über eine gemeinsame Datenbank. Zu den Nachteilen gehören die fehlende Kontrolle des Zugriffes durch die Applikationen, da der Zugriff meistens über das Datenbankmanagementsystem stattfindet. Des weiteren benötigen beide Applikationen Know-How über die internen Strukturen der Applikationen. Da dies im Sinn der Kopplungsminimierung eigentlich nicht gewünscht ist, wird oft versucht, über Zwischenschichten die Kopplung zu minimieren. Grundlegend bleibt der Nachteil aber bestehen. Darüber hinaus muss ein drittes System, hier die Datenbank, als Integrationskomponente mit betrachtet werden; da es sich bei diesen oft auch selber um komplexe Systeme handelt, wird der Komplexitätsgrad der Integration noch weiter erhöht. Die Integrationsarchitektur unterstützt die Anforderungen für MeDIC nur zum Teil. Zur Handhabung der Funktionsheterogenität wird ein globales Schema 51

66 5. Integrationsarchitekturen für alle Anwendungen benötigt, was die Komplexität der Architektur immens steigen lässt. Data-Warehouse & BI Das Data-Warehouse (DWH) ist das bekannteste Beispiel für die Integration über eine gemeinsame Datenbank. Als DWH bezeichnet man eine Datenbank, die Daten aus unterschiedlichen Quellen integriert und als einen konsistenten Datenbestand zur Verfügung stellt. Dabei werden die Daten über den sogenannten ETL-Prozess integriert. Im nächsten Abschnitt wird der ETL-Prozess näher beleuchtet. Grundgedanke eines DWHs ist die Möglichkeit, Daten auf definierten Aggregationsebenen darzustellen. Grundlage dieser Darstellung ist das sogenannte Sternschema [24], ein nicht normalisiertes Datenmodell für multi-dimensionale Daten. Das Sternschema ermöglicht den Aufbau von sogenannten OLAP-Würfeln, in denen die Daten entsprechend der Dimensionen aggregiert vorliegen. Für den Kontext der Integration ist die Tatsache relevant, dass das DWH dieses Datenmodell implementieren muss. Ein DWH dient oft als Basis für Business Intelligence Systeme (BI), deren Ziel die Auswertung von Datenbeständen für die operative und strategische Unternehmensführung ist. Zielgruppe von DWH- bzw. BI-Anwendungen sind keine Entwickler oder Projektleiter sondern Personen aus der strategischen Unternehmensführung. ETL - Extract Transform Load Der ETL-Prozess beschreibt die grundsätzliche Vorgehensweise bei der Integration von Datenquellen in ein DWH. Die Kernkomponenten, woraus sich auch das Akronym ETL zusammensetzt, sind: 1. Extract Extract umfasst das Auslesen der unterschiedlichen Datenquellen 2. Transform Transform beinhaltet die Anpassung der ausgelesenen Daten auf ein vorher definiertes Zieldatenschema und die damit verbundenen Operationen wie Datenbereinigung, -normalisierung und -transformation. 3. Load Load bezeichnet den Prozess der Integration der neuen angepassten Daten in das vorhandene DWH. Damit einhergehend müssen ggf. vorberechnete Aggregationen neu erstellt werden. Insbesondere die Transformkomponente des ETL-Prozesses kann sich sehr komplex darstellen. Die Thematik der Schema-Mappings, also der Anpassung der Datenquellen an ein globales Datenschema hat sich mittlerweile zu einem eige- 52

67 5.1. Typen von Integrationslösungen nen Forschungsbereich innerhalb der Datenbankcommunity entwickelt [12]. Mittels der Extractkomponente können auch Dateien innerhalb des ETL-Prozesses in das DWH importiert werden. Damit wird zusätzlich die Dabei-basierte Integration von Systemen möglich. Der DWH-Ansatz bietet eine vollständige und auch ausgereifte Lösung, was durch seinen langjährigen Erfolg unterstrichen wird. Jede große Datenbanksoftware präsentiert integrierte DWH-Funktionen. Wichtig zu nennen ist die Tatsache, dass DWH eine reine Datenintegration anbietet Service-Orientierte-Architektur (SOA) Der Begriff der Services bezieht sich bei Softwaresystemen auf die Bereitstellung von Funktionalitäten, Datenstrukturen und die Ausführung von Geschäftslogik [51, 92]. Service im Integrationskontext sind Softwaresysteme, die über einen definierten Standard ihre internen Funktionalitäten nach außen über eine standardisierte Schnittstelle für externe Klienten anbieten. In der Anfangszeit der Netzwerktechnik entstanden so Standards wie CORBA, COM und Java RMI. All diese Standards wurden unter dem Begriff Remote Procedure Call (kurz: RPC) zusammengefasst. Der Begriff RPC spiegelt das Verständnis wider, dass ein lokaler Methodenaufruf, wie er üblicherweise durchgeführt wurde, sich für einen Entwickler nicht sehr unterschiedlich zu einem entfernten Methodenaufruf über eine RPC-Methode unterscheiden sollte. Im besten Falle ist es schlicht für den Entwickler nicht relevant. Ein oft unterschätztes Problem mit entfernten Methodenaufrufen sind die erhöhte Latenz und die Probleme, die der Transport über Netzwerke wie Verbindungsprobleme oder Bandbreitenprobleme, mit sich bringt. In den letzten Jahren, mit dem Aufkommen des Internets und seinen neuen Technologien wie XML/HTML, HTTP, Browser und Webserver gab es Bestrebungen Service-basierte Integration auch über diese Technologien zu lösen. Es entstand die Klasse der Webservices, die mittels Standards wie SOAP/XML und REST neue Möglichkeiten anbot. Zusammengefasst wurde dies alles unter dem neuen Begriff der Service Orientied Architecture (SOA). SOA galt eine lange Zeit als die beste Lösung, um verteilte, komplexe aber trotzdem verständliche und modulare Softwaresysteme zu bauen. Ein wesentlicher Vorteil von SOA ist die Kapselung von Daten und Funktionalitäten. Dies verringert die Entstehung von Redundanzen und vermindert die Kopplung, ganz ähnlich dem Prinzip der Kapselung beim Entwurf eines Objekt-orientierten Softwaresystems. 53

68 5. Integrationsarchitekturen Requires work Does work Service consumer Delivers result Service provider Abbildung 5.3.: Service-Paradigma nach Krafzig [77] Service Paradigma Der Begriff Service wird im kommerziellen Umfeld und auch in der Forschung in unterschiedlichen Kontexten genutzt. Ähnlich wie der Begriff Integration ist er in jedem Feld der Informatik zu finden. Er besitzt eine intuitive Bedeutung, derzufolge ein Service eine Dienstleistung darstellt, die für einen Klienten von einem Anbieter erbracht wird. Diese Dienstleistung besitzt einen genauen Umfang. Schon diese intuitive Definition fasst die wesentlichen Merkmale des Service-Paradigma im Kontext der Softwareentwicklung zusammen. D. Krafzig [77] definierte eine abstrakte Beschreibung für das Service Paradigma, Abbildung 5.3 beschreibt das Service Paradigma anschaulich. Ein Service consumer (Klient) forder bei einem Service provider eine Leistung an, die dieser als Ergebnis seiner Arbeit an den Klienten zurück liefert. Demnach besitzt ein Service folgende Eigenschaften: 1. Selbst-beschreibend 2. Öffentlich 3. Kapslung und Komposition der Funktionalitäten 4. Request/Response Pattern Diese Eigenschaften wurden von Papazoglou [51] noch um den sogenannten Service Contract erweitert. In diesem werden bestimmte Qualitätseigenschaften des Services festgelegt. Wichtig beim Service-Paradigma ist, dass der Service Provider immer eine genaue Definition seiner Services liefert, technisch geschieht dies bei Webservices in Form des W3C Standards WebService Description Language (WSDL)

69 5.1. Typen von Integrationslösungen Kopplung SOA verringert die Kopplung zwischen Anwendungen trotzdem existieren Kopplungseigenschaften mit negativen Auswirkungen auf die Integrationsqualität für SOA-basierte Lösungen. Diese Kopplungseigenschaften werden im Buch von R. Daigneau [33] wie folgt formuliert: Funktionskopplung Der Service Client erwartet vom Service Provider bei Aufruf einer Funktionalität ein bestimmtes Ergebnis, ändert sich dieses Resultat oder sind Fehler enthalten, hat dies unmittelbare Auswirkungen auf den Client. Auf dieser Ebene sind die Systeme dann noch eng gekoppelt. Zeitliche Kopplung Services, insbesondere Web-Services arbeiten nach dem Request/Response Pattern, was nach Aufruf des Services ein sofortiges Ergebnis erwartet. Asynchrone Verarbeitung ist oft nicht möglich, eine Anwendung des Response/Acknowledge-Patterns nicht immer möglich. Datenstrukturkopplung Ein Klient muss für jeden aufgerufenen Service die genaue Datenstruktur verstehen und entsprechend verarbeiten. Da die Datenstruktur vom Service Provider geliefert wird, wird sie sich an der Fachlichkeit des Services orientieren. Ansätze wie die Komposition von Services, wie von Rao [98] dargestellt, versuchen die Probleme zu minimieren. URI-Kopplung Jeder Service wird eindeutig über seinen Uniform Resource Identifier (URI) identifiziert, diese URI muss dem Client bekannt sein. Die Clients sind demnach eng mit dieser URI gekoppelt. Änderungen verhindern den Serviceaufruf Diese noch vorhandenen Kopplungseigenschaften haben direkte negative Auswirkungen auf die Integrationskriterien. Abbildung 5.4 zeigt eine SOA-basierte Integration für drei Applikationen. Eine der Applikationen fungiert dabei als Serviceprovider für die anderen. Die Übertragung fungiert nach dem Request/Response- Pattern. Bezüglich der eingeführten Qualitätskriterien für Integrationslösungen erfüllt SOA viele der Kriterien wie lose Kopplung, Export von Daten und Funktionalität. Andere Kriterien wie ein einheitliches Datenformat oder die gewünschte Asynchronität der Lösung werden nur unzureichend unterstützt. Diese Nachteile entstehen durch enge Kopplungen auf Kommunikationsebene. Zunächst müssen Service und Klient einander kennen und auch die Sprache der bereitgestellten Funktionalitäten austauschen. Mit SOAP 3 hat sich da ein XML-basierter Protokollstandard entwickelt, über den sich entfernte Serviceaufrufe realisieren 3 55

70 5. Integrationsarchitekturen SOA Applikation A Klient Request A Response A Request B Service Applikation C Applikation B Klient Response B Abbildung 5.4.: SOA-basierte Integration lassen, die WSDL fungiert dabei als Beschreibungssprache für Datenstrukturen und Funktionalitäten in Form von Methodensignaturen. Auf Basis der WSDL kann der Klient dann die Kommunikation mit dem Service aufnehmen. Es ist offensichtlich, dass dadurch das Prinzip der Sensibilität verletzt wird. Historisch sind die Begriffe RPC und SOA einander sehr ähnlich. SOA in Form von Webservices ergänzt RPC um XML, den Service Contract und die Übertragung mittels HTTP. SOA sieht sich auch nicht nur als technische Architektur, sondern auch als organisatorische Infrastruktur wie von Mazak [85] formuliert. Im Folgenden wird daher auch immer auf den etwas aktuelleren Begriff der SOA Bezug genommen, wobei dort auch die etwas älteren Techniken wie CORBA und die neuen Techniken der Web-Services einbezogen sind. Die Unterschiede liegen dort nur auf technologischer Ebene. Enterprise Information Integration Die Enterprise Information Integration (EII) kann als Spezialfall der Servicebasierten Integration angesehen werden. Kernmotivation für den Bau einen EII- Systems war laut Halevy et al. [55] der Wunsch eine Datenintegration zu ermöglichen, ohne vorher alle Daten in eine zentrale Datenbank zu laden. Damit zielt EII auf einen der kritischsten Punkte der bisherigen Integrationsarchitekturen ab, der zu hohen Latenz und der mangelnden Aktualität der Daten. Abbildung 5.5 visualisiert die Arbeitsweise von EII. Eine Anfrage einer Appli- 56

71 5.1. Typen von Integrationslösungen kation A wird durch den Query-Processor in drei Teilanfragen aufgesplittet. Diese Teilanfragen, werden dann an drei Systeme geschickt, die diese Anfragen beantworten können. Alle Teilantworten werden dann vom Query-Processor integriert und als ein Ergebnis der anfragenden Applikation bereitgestellt. Die Datenextraktion und Datenintegration findet also erst zum Anfragezeitpunkt statt. Der Query-Processor basiert auf einem virtuellen Datenmodell, welches ein gemeinsames Datenmodelle der integrierten Systeme abbildet, aber keinerlei Daten beinhaltet das Datenmodell wird dynamisch gefüllt. Die Probleme bei dieser Architekturvariante sind offensichtlich. Erstens muss es wieder ein gemeinsames Datenmodell geben, aber im Gegensatz zum DWH z.b. stehen die Daten nicht sofort zur Verfügung. Die ungewisse Zuverlässigkeit und Performance der Systeme ist der Preis für die erhöhte Aktualität der Daten. EII Service Applikation C Result Query Query Applikation A Rsult Query Processor Service Applikation C Service Applikation C Abbildung 5.5.: Enterprise Information Integration In den letzten Jahren ist die Grenze zwischen DWH und EII verschwommen, da DWH-Systeme Echtzeit-ETL-Prozesse entwickelt haben. Akbay, Beyer und Vaisman [2, 13, 115] beschreiben Architekturen für ein Real-Time Data-Warehousing. 57

72 5. Integrationsarchitekturen Messaging Applikation A Sender Applikation B Empfänger Applikation C Empfänger Event Message Bus Abbildung 5.6.: Integration per Messaing Messaging Integration mittels Messaging ist ein Architekturansatz, der als Antwort auf die Probleme der Entwicklung verteilter aber integrierter Anwendungen entstanden ist. Er kombiniert die lose Kopplung der Datei-basierten Integration mit der schnellen Integration, die SOA-Systeme bieten. Zusätzlich können ähnlich wie bei SOA oder RPC auch Funktionalitäten integriert werden. Die Kernbegriffe beim Messaging sind Nachricht und Kanal. Daten werden in Form von Nachrichten über Kanäle an andere Anwendungen übermittelt. Dazu bedarf es eines Übermittlungsmediums, welches diese Kanäle bereitstellt und die Übermittlung gewährleistet. Diese steht in Form eines Messaging Brokers zur Verfügung. Dieses System verwaltet die Kanäle und alle eingehenden und ausgehenden Nachrichten. Anwendungen können in Kanäle senden oder aber aus Kanälen empfangen und das sogar bidirektional, d.h. eine Anwendung kann gleichzeitg senden und empfangen. Abbildung 5.6 verdeutlicht die Funktionsweise der Messaging-basierten Integration wieder für ein Beispiel mit drei Applikationen. Nachrichten werden über den Message Bus (den Kanal) von einer Sendeapplikation zu einer oder mehreren Empfängerapplikation übermittelt. Sender und Empfänger von Nachrichten sind also von der Verantwortung für die korrekte Übermittlung befreit. Damit wird direkt die zentrale Eigenschaft des Messaging deutlich; es ist asynchron, genauso wie bei der Datei-Integration 58

73 5.1. Typen von Integrationslösungen kann der Nachrichten-Sender nach Absetzen der Nachrichten mit seiner weiteren Arbeit fortfahren. Die Verfügbarkeit des Empfängersystems hat keine Auswirkungen auf den Sender, was in großen verteilten Systemen mehr Vorteile als Nachteile mit sich bringt. Zusätzlich zur Asychronität ist die Latenz zwischen einem Ereignis, das für die integrierten Systeme relevant ist, minimal. Nach Absetzen der Nachricht, wird die Nachricht umgehend zum Empfänger transportiert, der diese dann direkt verarbeiten kann. Es sollten hier nicht alle Eigenschaften des Messaging beschrieben werden, da es sich um einen integralen Bestandteil der neuen Integrationsarchitektur für MeDIC handelt. In Kapitel 7 werden die weiteren Eigenschaften des Messaging diskutiert. In seiner Ausprägung als Enterprise Service Bus ist das Messaging- Pattern momentan die meistgenutzte Integrationsarchitektur für neue Integrationsprojekte. Enterprise Application Integration Im Zuge der Entwicklung von Software-Patterns wurde auch die Integrationsthematik einer Strukturierung unterzogen. Der Begriff der Enterprise Application Integration (EAI) umfasst im eigentlichen Sinne die Gesamtheit aller Integrationsthematiken. Erweiternd zum DWH oder zur EII fokussiert man aber nicht auf ein Integration in einen Zielzustand bzw. -datenbank, sondern betrachtet die Integration zwischen Applikationen einer Applikationslandschaft. Darüber hinaus sind nicht nur Daten von Interesse bei der Integration, sondern auch die Integration von Funktionalitäten. Der Begriff EAI wurde durch das Buch von Hohpe und Wolf [59] mit dem Messaging-Pattern assoziert. Event-Driven Architecture Event-Driven Architecture (EDA) ist ein weiterer Begriff, der im Umfeld von Enterprise-Systemen immer wieder im Zusammenhang mit Integrationsthemen genannt wird. Michelson [89] definiert ein EDA als Architekturmuster für Systeme, die Ereignisse verarbeiten. Als Ereignis definiert sie: WHAT IS AN EVENT? An event is a notable thing that happens inside or outside your business. Ähnlich wie Services bei SOA sind Ereignisse erstmals nicht unbedingt technische Konstrukte. Das erklärt, warum EDA auch immer wieder als event-driven SOA bezeichnet wird. Im Gegensatz zu Michelsen ordnen wir EDA aber in den Bereich der Messaging-basierten Architekturen ein. Das hat folgenden Grund. 59

74 5. Integrationsarchitekturen Die von Michelsen beschriebenen Komponenten eines EDA-Systemns sind identisch mit Komponenten und Mustern aus dem Messaging. Beispielsweise die technische Definition eines Ereignis lautet: WHAT IS IN AN EVENT? Each event occurrence has an event header and event body. Diese Definition deckt sich mit der Definition nach Nachrichten beim Messaging, in Kapitel 7 wird die genaue Bedeutung dieser Struktur näher erläutert. Darüber hinaus benötigt ein EDA-System Kanäle. EDA bringt als neuen Aspekt in das Messaging-Pattern den Fokus auf die Verarbeitung von Nachrichten bzw. Ereignissen. So kennt es eine zentrale Regeldatenbank, die die Ereignisse auswertet und entsprechende gegebene neue Ereignisse generiert oder fachliche Services aufruft. Damit existieren weit mehr Gemeinsamkeiten mit dem Messaging Pattern als mit SOA. Michelsen weist sogar am Ende darauf hin, dass sie ein ESB als Basis für EDA nutzt. Marechaux [84] bezeichnet den ESB als Kombination zwischen EDA und SOA. Insgesamt verschwimmen bei EDA die Grenzen zwischen Messaging und SOA. Da EDA vornehmlich im kommerziellen Umfeld als eigenständiger Begriff eine Bedeutung erlangt hat, kann er getrost als Marketing- Instrument bezeichnet werden, um einer schon vorhandenen Architektur den Anschein von Neuem zu geben. MeDIC kann von EDA profitieren. Die Analogie zwischen einem Ereignis und einem Commit z.b. in einem Versionskontrollsystem wie GIT ist offensichtlich. In Kapitel 7 wird deutlich, dass die hier vorgestellt, Architektur als EDA bezeichnet werden kann Integration mit Agenten Ein Agentensystem oder auch Multiagentensystem/Multi Agent System (MAS) ist eine neue Technologie innerhalb der Forschung oder der Industrie. Agentensysteme basieren auf einem neuen Paradigma, welches als Erweiterung des Serviceparadigmas für den SOA-Bereich betrachtet werden kann. Sowohl Kishore [76] als auch Wooldrige [122] finden keine einheitliche Definition eines Agenten. Die Ursprünge des Agentenparadigmas finden sich in einem Bereich der Informatik, der mit einer Integrationthematik, wie sie in Kapitel 3 vorgestellt wurde, auf den ersten Blick nur wenig gemein hat. Der Bereich der Künstlichen Intelligenz definiert einen Agenten nach Russel und Norwig [102] folgendermaßen: An agent is just something that acts (agent comes from the Latin agere, to do). Of course, all computer programs do something, but computer agents are expected to do more: operate autonomously, 60

75 5.1. Typen von Integrationslösungen Agent Agent B Applikation B Applikation A Agent A Communication Agent Applikationsumgebung Applikationsumgebung Agent C Applikation C Applikationsumgebung Abbildung 5.7.: Intgration über Agenten perceive their environment, persist over a prolonged time period, adapt to change, and create and pursue goals. Aus dieser Beschreibung lassen sich drei Eigenschaften extrahieren, die auch für die Integrationsproblematik relevant sind. Zunächst agiert ein Agent in einer speziellen Umgebung, diese Umgebung kann er über Sensoren wahrnehmen und aufgrund dieser Daten Entscheidungen treffen. Mit Begrifflichkeiten aus Kapitel 3 kommuniziert ein Agent mit einem anderen System, seiner Umgebung. Er verarbeitet Daten aus diesem System und trifft daraufhin eine Entscheidung. Er zeigt also ein Verhalten und ein Multi-Agentensystem ist damit schon an sich ein Integrationsproblem. Die Fähigkeit, Entscheidungen zu treffen, erfordert, dass jeder Agent Daten integriert, also liegt es nahe, aus dieser Kompetenz von Agenten auch ein normales Integrationsproblem zu lösen. Architektonisch besetzt ein Agent die Rolle eines zu integrierenden Systems, er ersetzt damit das eigentliche Integrationssystem, das nun als seine Umgebung, die er mit Sensoren auswertet, fungiert. Abbildung 5.7 zeigt eine grundlegende Integrationsarchitektur nach dem Agentenparadigma. Alle Integrationsfunktionen innerhalb der Architektur werden von Agenten ausgeführt. Die Bewertung dieser neuen Integrationsarchitektur hinsichtlich der definierten Qualitätskriterien für Integrationslösungen liefert einige positive Ergebnisse; so ist die Latenz zwischen den integrierten Systemen minimal, alle Komponenten innerhalb der Architektur sind aktiv. Sie können selbstständig andere Agenten kontaktieren. Die Kopplung zwischen den zu integrierenden Anwendungen ist minimal, die Agenten agieren autonom. Agenten sind technologisch nicht festgelegt und können damit die Probleme der Systemheterogenität direkt in 61

76 5. Integrationsarchitekturen der Umgebung der zu integrierenden Anwendung lösen. Wie Wille [121] und Dumke et al. [38, 37] zeigen, lassen sich aufbauend auf dem Agentenparadigma Systeme bauen, die Daten des Softwareentwicklungsprozesses integrieren und vermessen. Sie implementieren dabei sogar sich selbst vermessende Systeme Zusammenfassung In Tabelle 5.1 sind die Ergebnisse der Bewertung der Integrationsarchitekturen gegenüber den Qualitätskriterien und den Anforderungen an eine MeDIC- Integrationslösung zusammengefasst. Zusätzlich wurden weitere Architekturqualitätsmerkmale wie Testbarkeit und Modifizierbarkeit, wie sie von Clements et al. [29] für ihre Architekturbewertungsmethoden SAAM [74] und ATAM [75] definiert wurden, betrachtet. Als letztes Qualitätsmerkmal wird die Verständlichkeit der Architektur bewertet. Verständlichkeit ist eine Produktqualität, die von Ludewig und Lichter[81] folgendermaßen definiert wurde: Verständlichkeit ist hoch, wenn der Benutzer rasch versteht, wie er mit der Software umgehen muss. Für die Bewertung von Integrationslösungen werden die Begriffe Benutzer und Software leicht anders interpretiert. Ein Benutzer ist im Kontext der Integration als Entwickler oder Architekt zu verstehen, dem ein Integrationsproblem vorliegt. Er muss nun vorhandene Lösungen evaluieren. Die Software kann demnach aus einer Architekturbeschreibung, einem Framework oder einer schon implementierten Software bestehen. Insbesondere Robliard [100], aber auch ältere Publikationen wie von Morisio [90] und Srinivasan [110] betonen, dass das Erlernen von Frameworks und APIs umso schwieriger ist, je komplexer sich die Architektur darstellt. Ein wesentliches Ergebnis dieses Kapitels ist, dass die Integrationsarchitekturen mit zunehmender Leistungsfähigkeit immer komplexer werden. Insbesondere die Asynchronität führt laut Hohpe et al. [59] zur Verwirrung bei Entwicklern, die eine Messaginglösung nutzen wollen. Die Entwickler müssen lernen, asynchron zu denken, was für die meisten eine ungewohnte Umstellung ist. Gamma et al. [50] beispielsweise definieren kein Design Pattern, das sich mit Asynchronität beschäftigt. Das Qualitätsmerkmal der Verständlichkeit ist ein wichtiger Grund für die Spezifikation des Integrationsbewertungsprozesses in Kapitel 10. Die Vergleichsmatrix zeigt für die Datei-basierte Integration nur wenige positive Bewertungen für die Asynchronität und die Möglichkeit, dass über Dateien Metrikwerte von allen Metrikstufen verarbeitet werden können. Darüber hinaus ist die Verständlichkeit der Architektur gut, da das Prinzip von Dateien ein alltägliches Paradigma im Umgang mit IT-Systemen ist. Die Verständlichkeit der Dateiinhalte, also die strukturelle und semantische Heterogenität, ist neutral zu bewerten, da an dieser Stelle die Architektur keine negativen,s aber auch 62

77 5.2. Zusammenfassung Kriterien Dateien Datenbank SOA Messaging Agenten Kopplung + + Sensibilität + Technologie + Datenformat Latenz Funktionalität n.a. n.a. + + Asynchronität Zuverlässigkeit - + Anforderungen Dateien Datenbank SOA Messaging Agenten Datenheterogenität Systemheterogenität + Funktionsheterogenität Komm.-Heterogenität Performance Interpretation Erweiterbarkeit + - Allg. Qualitäten Dateien Datenbank SOA Messaging Agenten Verständlichkeit + - Testbarkeit + + Modifizierbarkeit + + : Gut : Neutral : Negativ n.a. : Nicht vorhanden Legende: Tabelle 5.1.: Vergleichsmatrix keine positiven Auswirkungen hat. Die Integration basierend auf einer gemeinsamen Datenbank verbucht als positive Aspekte die Asynchronität, gute Latenz und Performance der Architektur. Negativ andererseits ist die enge Kopplung an die Datenbank in technischer und struktureller Hinsicht, so ist die Kopplung, Datenheterogenität und Systemheterogenität negativ bewertet. Die Verständlichkeit der Architektur ist grundsätzlich eher positiv, durch die möglichen komplexen Datenmodelle und Datenbank-Paradigmen erfordert dies trotzdem einen hohen Lernaufwand und wird damit nur als neutral gewertet. Service-orientierte Architekturen als Basis von Integrationslösungen basieren auf dem Service-Paradigma. Positiv an dieser Architektur ist insbesondere die Möglichkeit der Integration von Funktionalitäten; dies ist auch ein Hauptbestreben von SOA. Durch Kapselung der fachlichen Funktionalitäten in Services wird die Kopplung innerhalb des Systems verringert. SOA-Systeme sind prinzipiell lose gekoppelt, trotzdem existieren wie Daigneau [33] beschreibt Kopplungs- 63

78 5. Integrationsarchitekturen beziehungen zwischen den Services. Daher wir die Kopplung nur als neutral gewertet. Obwohl SOA-Services selbstbeschreibende Schnittstellen enthalten, sind deren Datenstrukturen applikationsspezifisch, deshalb wurde dieses Qualitätsmerkmal auch als negativ bewertet. Die Verständlichkeit der Architektur ist auf hohen Level eigentlich simpel, die technischen Komponenten und Standards zur Implementierung einer SOA lassen die Lernkurve trotzdem sehr steil werden. Insbesondere die Modellierung von Prozessen für SOA ist immens komplex. SOA Architekturen lassen sich gut testen, Fowler [49] beschreibt mit dem Service Stub ein Entwurfsmuster für das Testen von Services. Die Integration mittels Messaging löst viele der Kopplungseigenschaften, die z.b. bei SOA noch auftreten, deshalb ist es die erste Architektur die positiv für die Kopplungseigenschaft bewertet wird. Da eine Grundeigenschaft des Messaging die Asynchronität ist, profitieren auch viele der Eigenschaften, die mit der Asynchronität korrelieren, von dieser positiven Bewertung. Dazu gehören die Zuverlässigkeit und die Latenz. Eine Eigenschaft, bei der es schlechter als SOA bewertet wird, ist die Integration von Funktionalitäten. Das Request- /Response-Muster, auf dem ein Service aufbaut, wird vom Messaging nativ nicht unterstützt. Es kennt aber einen Adaption mittels Simulation über asynchrone Nachrichten mit spezifizierten Antwortendpunkten. Eine positive Eigenschaft vom Messaging ist die Handhabung von Datenstrukturen. Es fordert anders als SOA nicht die vollständige Kenntnis der Datenstrukturen, sondern kann Daten innerhalb von Nachrichten verpacken. Zwar verlangt es ein Messagingspezifisches Nachrichtenformat, dies ist aber minimal, trotzdem wird das Datenformatkriterium nur mit neutral bewertet. Die Verständlichkeit beim Messaging verschlechtert sich gegenüber SOA nochmals, besonders das Denken in asynchronen Strukturen bereitet vielen Entwicklern Schwierigkeiten. Agentensysteme gehören zu den neuesten Systemen im Integrationsbereich. Ihr größter Vorteil ist die nicht-invasive Kopplung mit den zu integrierenden Systemen. Daher ist die Agenten-basierte Architektur die einzige, die beim Punkt Sensibilität eine positive Wertung erhält. Gegenüber SOA haben Agentensysteme den Vorteil, dass sie als autonome Systeme den Ausfall von zu integrierenden Systemen bemerken und entsprechend behandeln können, ohne Seiteneffekte auf andere Integrationspartner. Da Agenten-Systeme oft hierarchisch strukturiert sind, können so Ausfälle auf unterschiedlichen Ebenen kompensiert werden. Da Agenten selbst Software sind und dementsprechend auch ausfallen können, müssen sie selbst in die Zuverlässigkeitsbetrachtung mit einbezogen werden, daher wird der Punkt Zuverlässigkeit negativ bewertet, weil durch neue Systeme die Bewertung der Zuverlässigkeit komplexer und weniger genau wird. Durch die Vielfalt, wie Agenten implementiert werden können, können die Heterogenitätsanforderungen komplett abgedeckt werden. In technologischer Hinsicht sogar besser als bei SOA oder Messaging, da z.b. kein beschränkendes Paradigma wie das Service-Paradigma zu Grunde gelegt wird. Agenten-Systeme sind durch die Individualität der Agenten das komplexeste Architekturmuster und damit das mit der geringsten Verständlichkeit. Die komplette Variabilität der Agenten muss durch den Entwickler erfasst werden 64

79 6. Vorhandene Lösungen für Projektdashboards Inhalt 6.1. Software Process Dashboard Project PSP - Personal Software Process Integrationseigenschaften Bewertung Pentaho Business Intelligence Suite Integrationseigenschaften Bewertung Rational Insight Integrationseigenschaften Bewertung Weitere Lösungen QMetric SiSSy/QBench CAST Zusammenfassung MeDIC ist nicht das erste Softwaresystem, das als Projektmanagement-Plattform mit Hilfe von Metriken den Softwareentwicklungsprozess verbessern möchte. Seit dem Aufkommen der Softwaremetriken für Qualitätsmessungen in den 1990er Jahren mit Veröffentlichungen von Fenton [43], Shepperd [108] und Humphrey [62, 61] sind freie und kommerzielle Softwaretools entstanden, die Metriken implementieren und zur Qualitätsmessung genutzt werden. Dieses Kapitel stellt einige wesentliche Systeme vor. Der Fokus liegt dabei auf den Integrationseigenschaften und der Integrationsarchitektur. Zur Bewertung der Systeme werden die bis hierhin definierten Anforderungen aus dem vorherigen Kapitel und Qualitätsmerkmale für Integrationslösungen aus Kapitel 3 genutzt Software Process Dashboard Project Dieses Tool, welches zunächst im Jahre 1998 für die US Airforce entwickelt wurde und danach als Open-Source-Projekt weitergeführt wird, setzt sich zum Ziel den Personal Software Process (kurz: PSP) von Humphrey Watts abzubilden [97]. Beim PSP handelt es sich um eine erste Prozessdefinition für einen 65

80 6. Vorhandene Lösungen für Projektdashboards mit dezidierten Messungen unterstützten Softwareentwicklungsprozess. Dabei zielt PSP auf den einzelnen Entwickler und seinen individuellen persönlichen Prozess PSP - Personal Software Process Watts definierte den PSP im Jahre 1996 [62] und legt darin folgende Prinzipien fest, auf denen der PSP beruht. Planung Jeder Entwickler muss seine Arbeit planen, und da jeder Entwickler ein Individuum ist, ist auch seine Planung individuell Verbesserung Um die Qualität seiner Arbeit und die Leistungsfähigkeit eines Entwicklers zu steigern, ist es notwendig, dass ein Entwickler einem definierten und messbaren Prozess folgt. Verantwortung Für eine hohe Softwarequalität ist es notwendig, dass ein Entwickler eine persönliche Verantwortung gegenüber seiner Arbeit entwickelt. Kostenminimierung Fehler früh zu finden und zu beheben, senkt die Gesamtkosten. Fehlervermeidung Es ist effizienter Fehler zu vermeiden als zu beheben. Gesamtprozess Die günstigste und beste Art und Weise eine Aufgabe, zu erfüllen, ist, sie richtig zu machen. Viele dieser Prinzipien sind erlernte Best-Practice-Erfahrungen aus der Historie der Softwareentwicklungen. Insbesondere der explizite Ansatz, auch eine Verbesserung anzustreben, d.h. einen fehlerhaften Softwareentwicklungsprozess aus sich selbst heraus zu verbessern, ist eine Kernkomponente von PSP. In seiner Tätigkeit für das Software Engineering Institute (SEI) war Humphrey Watts maßgeblich an der Entwicklung von CMM/CMMI beteiligt. Zwischen CMMI und PSP finden sich daher große Ähnlichkeiten, wobei die Zielsetzung identisch, die Methoden und insbesondere die betrachtete Organisationsgröße und -schicht jedoch unterschiedlich sind. CMM/CMMI zielen eher auf eine unternehmerische Managementebene [63]. PSP kann aber als CMMI für ein Individuum verstanden werden. PSP definiert ähnlich dem CMMI mehrere Stufen [61], die ein Entwickler während der Anwendung von PSP durchlaufen wird. Dabei sind auch die Inhalte mit denen von CMM/CMMI verwandt. 66

81 6.1. Software Process Dashboard Project PSP0: Der bisherige Prozess, es werden die Arbeitszeit und Anzahl der Fehler aufgezeichnet PSP1: Größenmessungen und -schätzungen werden durchgeführt PSP2: wiederholbar Projektplanung auf Basis von Größenmessungen und -schätzungen werden durchgeführt, erste Qualitätssicherungsmaßnahmen werden durchgeführt. PSP3: defined Prozessdefinition wird eingeführt, Schulungen werden durchgeführt, Softwarequalitätssicherungsmaßnahmen werden verstärkt auch im Team durchgeführt (Reviews) PSP4: managed Messungen werden während des Projekts erfasst, verfolgt, ausgewertet und entsprechende Steuerungsmaßnahmen durchgeführt PSP5: optimized Methoden und Prozess werden kontinuierliche vermessen und verbessert Im Gegensatz zu CMM/CMMI definiert PSP zusätzlich zu den vorgestellten Qualitätsstufen auch konkrete Methoden für die Softwareentwicklung und die notwendigen Messungen. Prinzipiell sieht PSP eine ganze Reihe von Produktund Prozessmetriken vor. Da diese aber im Kontext dieser Arbeit unerheblich sind, wird auf die Veröffentlichungen der SEI verwiesen, insbesondere den Body of Knowledge von Pomeroy-Huff et al. [93]. Einen detaillierten Messprozess wie die ISO umfasst der PSP zwar nicht, aber grundsätzlich sieht er die Erhebung von Daten und deren Auswertung durch Metriken vor [93]. PSP sieht demnach die Erhebung folgenden Daten vor: 1. Zeit 2. Größe der Software 3. Qualität in Form von Defekten 4. Planungsdaten Aufbauend auf diesen theoretischen Grundlagen wurde das Software Process Dashboard entwickelt, um einen Entwickler während seiner Arbeit im Sinne des PSP zu unterstützen. Dafür adaptiert es die wesentlichen Aktionen im PSP. Abbildung 6.1 zeigt die von PSP vorgegebenen Projektphasen eines Entwicklungsprojektes, diese folgen einem generischen Vorgehensmodell [93], wie z.b. dem Rational Unified Process [78]. Durch die Fokussierung auf den Entwickler 67

82 6. Vorhandene Lösungen für Projektdashboards entfallen beim Software Process Dashboard aber die Phasen für die Anforderungsanalyse, da diese nicht in den Aufgabenbereich des Entwicklers fallen. Sie werden als gegeben angenommen. Abbildung 6.1.: PSP-Entwicklungs-Phasen Zu jeder Phase definiert der PSP bestimmte Aktionen und darauf basierende Formulare um Daten für die Messungen zu erhalten. Der PSP basiert grundlegend auf zwei unterschiedlichen Messgrößen, Zeit und Größe; während der Planungsphase müssen deshalb diese Werte für das Gesamtprojekt geschätzt werden. Abbildung 6.2 zeigt ein solches Schätzformular für die Größe des Projektes; die Einheit für die Größe eines Projektes ist die Anzahl an Zeilen der Entwicklungsartefakte (LOC). Dabei kennt das Formular nicht nur die Gesamtgröße der Artefakte, sondern beachtet auch beispielsweise die Anzahl gelöschter sowie geänderter Zeilen, beides Werte, die z.b. auch ein Versionskontrollsystem wie GIT oder Subversion für jeden Commit des Entwicklers liefern. Mit diesen Werten sind detaillierte Messungen möglich. Die Software kennt verschiedene Methoden, um Schätzungen durchzuführen, die in PSP unter den PROBE-Methoden zusammengefasst werden. PROBE bedeutet Proxy Based Estimation, darunter versteht PSP die Schätzung mittels Alternativmessungen, wenn Daten für eine konkrete Messung nicht ausreichen. Dies ist insbesondere während der ersten Planungsphase und während der ersten Iteration von PSP gegeben, da dann z.b. keine historischen Daten zur Verfügung stehen. Innerhalb der Process Dashboards steht dem Entwickler ein Unterstützungstool zur Verfügung, das die Anwendung der unterschiedlichen PROBE-Methoden vereinfacht. Die letztendliche Entscheidung welcher konkreter Wert in die Planung bzw. in die auszufüllenden Dokumente einfließt, trifft 68

83 6.1. Software Process Dashboard Project Abbildung 6.2.: PSP Größen-Schätzformular aber der Entwickler selber. Die Zeit für bestimmte Tätigkeiten wird mittels einer implementierten Timeranwendung direkt mit aufgezeichnet. Der Entwickler wählt die aktuelle Phase, sprich Planung, Test, Implementierung, und startet jeweils bei Beginn seiner Tätigkeit den Timer und am Ende stoppt er ihn entsprechend. Diese Zeitdaten fließen dann direkt in die Datenbasis für die Phase und können dann entsprechend ausgewertet werden. Zusätzlich definiert das Process Dashboard für jede dieser Phasen ein sogenanntes Script, darin enthalten sind die Voraussetzungen zum Start dieser Phase, die konkreten Tätigkeiten sowie die Bedingungen für einen erfolgreichen Abschluss des Projektes. Abbildung 6.3 zeigt ein solches Script für die Entwicklungsphase. Als Voraussetzung zum Start dieser Phase definiert die Software folgende Bedingungen: zunächst einmal muss eine Planung existieren, in Form eines komplettierten Planungsformulars für die Größe und die Zeit des Projektes. 69

84 6. Vorhandene Lösungen für Projektdashboards Abbildung 6.3.: Entwicklungsscript Darüber hinaus werden die Existenz von Standards bezüglich der Implementierung, in Form eines externes Dokumentes, und für die Katalogisierung von gefundenen Fehlern im Projekt gefordert. Gefundene Fehler werden direkt im Software Process Dashboards dokumentiert. Fehler sind damit neben Zeit und Größe die dritte relevante Datenquelle für die Produkt- und Prozessbewertung, sie werden innerhalb von PSP als Qualitätsindiz interpretiert. Als vierte und letzte Größe werden Zeitplanungsdaten in die Bewertung mit aufgenommen. Schon während des Projektes, aber insbesondere nach Abschluss, steht dem Entwickler eine sogenannte Postmortem-Analyse zur Verfügung, um sich und seinen Prozess zu bewerten. Abbildung 6.4 zeigt eine solche Analyse, sie stammt aus der Produktdokumentation der Software selber. In dieser Übersicht visualisiert die Software eine Vielzahl von Produkt- und Prozessmetriken, die dem Entwickler in der Analyse helfen sollen Integrationseigenschaften Das Software Process Dashboard ist im Sinne der zu Beginn des Kapitels definierten Integrationsdefinition kaum als Integrationslösung anzusehen. Der 70

85 6.1. Software Process Dashboard Project Abbildung 6.4.: Software Process Dasbboard Hauptgrund für diese Tatsache ist die Fokussierung der Software auf den Entwicklungsprozess eines einzelnen Entwicklers. Zwar existiert eine Erweiterung des PSP hinsichtlich der Entwicklungsabläufe von Teams, dieser Team Software Process (TSP) basiert aber auf den gleichen Techniken wie der PSP. Die Software setzt diesen dann auch genau um. Trotzdem finden sich innerhalb der Software Integrationsstrukturen. Zunächst einmal kann die Größenmessung nicht nur manuell durchgeführt werden, sondern auch automatisiert über die Integration eines VCS-Systems. Die Software bietet dazu eine Schnittstelle zu Subversion an, zur Integration wird der aktuelle Stand des Source Codes von der Software geparsed und ausgewertet. Abbildung 6.5 zeigt diesen LOC-Counter und seine Konfigurationsmöglichkeiten. Im Sinne der Integrationsklassen geschieht hier die Integration auf Datei-Ebene. Es werden die Sourcecode-Dateien und die Subversion-spezifischen Dateien ausge- 71

86 6. Vorhandene Lösungen für Projektdashboards wertet. Abbildung 6.5.: Integration von Subversion zur Größenmessung Die Ausführung der Integration geschieht immer manuell durch den Entwickler selber, eine automatische regelmäßige Erhebung oder eine Erhebung auf Basis bestimmter Ereignisse, z.b. dem Abschluss einer bestimmten Phase, ist nicht möglich. Ansonsten finden sich keinerlei weitere Möglichkeiten zusätzliche Daten aus anderen Systemen außer dem Dashboard selbst zu integrieren. Durch die vorhandene Import-Funktion können Daten von mehreren Dashboards aber auch von historischen Projekten integriert werden. Dies ist insbesondere im Einsatz in einer verteilen Umgebung mit mehreren Entwicklern notwendig und sinnvoll. An dieser Stelle wird aus dem PSP der TSP, der Team Software Process. Import und Exporte können automatisiert durchgeführt werden. Die Integrationsklasse ist hier wieder Datei-basiert. Weiterhin sind alle Daten als manuelle Excelexporte verfügbar, was eine dateibasierte Integration in andere Systeme zumindest ermöglicht. Gegenüber anderen System verhält sich das Software Process Dashboard ansonsten recht verschlossen, die Dateneingabe ist strikt manuell organisiert. In einer der letzten Versionen wurde aber eine kleine Software-API zur Steuerung des implementierten Timers hinzugefügt. Über einen HTTP-Request ist es anderen Anwendungen möglich, den Timer für ein bestimmtes Projekt oder eine bestimmte Phase zu starten und zu stoppen. Technologisch entspricht dies der Integrationsklasse einer Service-basierten Integration, aber nur auf einer sehr rudimentären unidirektionalen Ebene. 72

87 6.1. Software Process Dashboard Project Bewertung Für Bewertung des Software hinsichtlich ihrer Integrationsfähigkeiten werden die in Kapitel 3 vorgeschlagenen Kriterien genutzt. Kopplung von Applikationen: Die Kopplung zwischen einzelnen Applikationen ist zunächst einmal nicht vorhanden bzw. nur sehr lose. Das liegt vor allem daran, dass für den Betrieb des Dashboards zunächst jegliche Integration optional ist, da sich alle notwendige Daten manuell erfassen lassen oder direkt mit der Software selber aufgezeichnet werden. Im Falle der Subversionintegration zur Größenmessung ist die Kopplung aber dann sehr eng, weil direkt Subversionspezifische Daten verarbeitet werden. Sensibilität: Für dieses Kriterium ist die Bewertung auch gespalten. Die manuelle Eingabe der Daten macht die Anwendung robust geben Änderungen, die Integrationsleistung wird hier direkt durch den Entwickler geleistet. Im Falle der Subversionintegration ist dies eher umgekehrt. Technologieauswahl: Die Software ist in JAVA implementiert und kann so mit eigenen Mitteln erweitert werden. Datenformat: Das Datenformat des Process Software Dasbboards ist proprietär. Zeitliche Faktoren: Dieses Qualitätskriterium ist die größte Schwäche des Softwareproduktes. Durch die manuelle Dateneingabe und die nicht automatisierbaren Integrationsmöglichkeiten werden Daten erst sehr spät verarbeitet. Daten und Funktionalität: Diese Kriterium wird nur sehr rudimentär unterstützt, als einzige Funktionalität wird die Timeranwendung exportiert und für andere Anwendungen geöffnet. Daten können nur in Form von Dateien exportiert und in anderen Systemen verarbeitet werden. Asynchronität: Durch die Arbeit auf Dateiebene wird eine asynchrone Verarbeitung erreicht. Zuverlässigkeit: Da sich alle integrierbaren Systeme grundsätzlich auf der identischen Infrastruktur befinden, ist dieses Kriterium nicht weiter relevant. Zusammenfassend handelt es sich beim Software Process Dasbboard um keine Integrationslösung, sondern um eine fachliche Anwendung mit rudimentären 73

88 6. Vorhandene Lösungen für Projektdashboards Integrationsfunktionalitäten. Auch die Hauptanforderung im Umgang mit den Heterogenätsklassen aus Kapitel 4 werden von der Software nicht vollständig erfüllt. Durch die Open-Source-Basis und die weitverbreitete Programmiersprache JAVA lassen sich zusätzliche Datenquellen einbinden. Durch die Beschränkung auf nur wenige Basismetriken ist damit auch die Funktionsheterogenität nur sehr gering ausgeprägt. Die Software implementiert nicht den Messprozess der ISO Pentaho Business Intelligence Suite Bei Pentaho 1 handelt es sich um einen klassischen Vertreter einer Business Intelligence Software Suite auf Basis einer relationalen Data-Warehouse-Architektur. Durch seine umfangreichen Analyse- und Reportingfunktionalitäten ist es damit auch ein Kandidat für den Gebrauch als Dashboard für die Analyse von Daten aus dem Softwareentwicklungsprozess. Pentaho besteht aus drei größeren Komponenten oder eher Subsystemen. Business Analytics Server (BA Server) Beim BA Server handelt es um eine JAVA-basierte Plattform zum Erstellen und Verwalten von Analysen, Reports und Visualisierungen in Form von Dashboards. Der Server besitzt eine web-basiertes GUI, über das die Plattform verwaltet werden kann. Abbildung 6.6 zeigt ein Beispieldashboard aus dem Demosystem von Pentaho. Data Integration Server Dieses System ging aus dem früheren Open-Source-Werkzeug Kettle hervor und implementiert eine Plattform für ETL-Prozesse. Es bietet Funktionen zur Integration und Transformation auf Datenebene. ETL-Prozesse können in Jobs verpackt und regelmäßig automatisiert ausgeführt werden. Bearbeitet werden die ETL-Prozesse durch ein Werkzeug namens Spoon, alle wesentlichen Schritte wie die Erstellung von Datenbankverbindungen, Transformationsprozesse und die Erstellung eines Meta- Datenmodells können über Spoon bearbeitet werden. Abbildung 6.7 zeigt einen Screenshot von Spoon für die Bearbeitung eines Transformationsprozesses. Als Ergänzung wurde die bekannte DataMining Plattform WEKA 2 integriert. Damit verfügt Pentaho über ein mächtiges Werkzeug aus dem KDD-Prozess. Enterprise Console Server Diese Komponente implementiert Funktionalitäten zur Bearbeitung administrativer Aufgaben innerhalb von Pentaho. Dazu gehören das Rechte

89 6.2. Pentaho Business Intelligence Suite Abbildung 6.6.: Pentaho Demo Dashboard und Lizenzmanagement. Pentaho unterstützt den Anwender durch eine Vielzal von graphischen Tools bei der Erstellung von Datenintegrationsprozessen und der Definition von aussagekräftigen Reports und Visualisierungen. Abbildung 6.8 zeigt eine Konfigurationsmaske zur Anlage einer neuen Visualisierung für ein Dashboard. Visualisierungen basieren auf einer Datenabfrage (Query), die in Pentaho Tool-gestützt erstellt werden kann. So können auch unerfahrene Nutzer relativ simpel neue Abfragen und Auswertungen für ihr individuelles Dasbboard anlegen. Technologisch basiert Pentaho auf Java bzw. JEE und wird wie MeDIC auf einem JEE-Applikationsserver deployed. Es kombiniert erfolgreiche Open-Source- Komponenten wie Kettle (ETL), JFreeReport (Report) und WEKA (Datamining) zu einer integrierten Business Intelligence Software Suite Integrationseigenschaften Aufgrund seiner technologischen Grundlagen bietet sich Pentaho ein immenses Spektrum an Integrationsmöglichkeiten. Am besten integriert und über graphische Tools unterstützt ist die Integration von relationalen Datenbanken, die über JDBC angebunden werden können. Dabei können Datenquellen per JNDI oder über eine direkte URI angesprochen werden. Zusätzlich bietet Pentaho die 75

90 6. Vorhandene Lösungen für Projektdashboards Abbildung 6.7.: Pentaho Data Integration mit Spoon Integration von Messaging-Lösungen sowohl als Quell- als auch als Zielsystem 3. Die Integration von JMS wird von Pentaho als Konzept zur Echt-Zeit Analyse bezeichnet. In den letzten Versionen ist zusätzlich die Unterstützung von BigData-Systemen und -Anwendungen hinzugekommen. Bei BigData handelt es sich um einen Begriff zur Klassifizierung von Datenbanken, die keinem relationalem Schema folgen und nur unzureichend auf Grund der Datenmenge von normalen Datenbanken verarbeitet werden können. BigData-Systeme wie Hadoop 4 und MongoDB 5 verwenden den MapReduce Ansatz. Das von Google eingeführte Verfahren [34] dient zur Verarbeitung sehr vieler Datensätze. Diese liegen als Key/Value-Paar vor und werden in parallellaufenden Map- und Reduce-Schritten verarbeitet. Mit den BigData-Systemen wurde eine neue Klasse von Datenbanken bekannt, die NoSQL Datenbanken (abgekürzt für: Not only SQL ). NoSQL-Datenbanken wie CouchDB 6, Apache Cassandra 7 und MongoDB beruhen nicht auf der relationalen Algebra (eingeführt von Codd[30], welches die theoretische Grundlage der bekannten relationalen Datenbanken darstellt. NoSQL Datenbanken haben

91 6.2. Pentaho Business Intelligence Suite Abbildung 6.8.: Pentaho Dashboard - Query in den letzten Jahren verstärkt Einzug in die Forschung enthalten. Sogar für Software Projekt Daten wurden NoSQL-Datenbank evaluiert, wie eine Arbeit aus Schweden zeigt [21]. Dort wurde insbesondere die erhöhte Performance der NoSQL-Lösung hervorgehoben. Pentaho ist in der Lage NoSQL-Datenbanken direkt anzusprechen und zu integrieren Bewertung Pentaho als Integrationsplattform erfüllt wesentliche Anforderungen wie sie auch an MeDIC gestellt werden. In Bezug auf die Integration heterogener Systeme liegt der Schwerpunkt von Pentaho eindeutig bei Datenbanksystemen, insbesondere relationalen Daten. Er erklärt sich aus der Historie von Pentaho, welches von Beginn an als Data-Warehouse konzipiert ist. Die Integration solcher Datenquellen ist überaus bequem, und die notwendigen Maßnahmen zur Datenintegration werden von Pentaho durch aufwendige Tools unterstützt. Pentaho ist dabei in der Lage, auch unterschiedliche Datenmodelle parallel zueinander zu betreiben, die ETL Prozesse sind so flexibel gestaltet, dass sie beliebige Meta-Modelle unabhängig voneinander erzeugen und verwalten können. Alle diese Modelle stehen dann in den Analysetools als gleichberechtigte Datenquellen zur Verfügung. Damit wird die Bedingung für ein globales Sternschema der Daten nicht erfüllt. Pentaho implementiert mit der parallelen Nutzung mehrerer Datenquellen ein EII-System. Pentaho besitzt kein vorgegebenes Modell zur Verwaltung von Softwareentwicklungsdaten, das komplette Know-How muss bei 77

92 6. Vorhandene Lösungen für Projektdashboards Initialisierung von einem Experten eingebracht werden. Um auch mit den Anforderungen der Systemheterogenität umzugehen, besitzt Pentaho Schnittstellen mit unterschiedlichen Technologieansätzen. So können Webservices als Datenquellen mittels REST oder SOAP aber auch Messagebasierte Systeme über JMS angebunden werden. Auch neue Paradigmen wie BigData und NoSQL lassen sich quasi out-of-the-box anbinden. Die ETL- Engine Kettle kann auch unabhängig von den Analysetools als Verarbeitungseninge eingesetzt werden, was das Einsatzspektrum von Pentaho immens erhöht. Pentaho unterscheidet grundsätzlich nicht die Datentypen im Sinne der ISO- Norm Der dort definierte Messprozess bzw. das Messmodell werden von Pentaho nicht explizit unterstützt. Durch seine generische Struktur ist Pentaho aber in der Lage, dieses Modell abzubilden. In Kettle, der ETL-Komponente, lassen sich Transformations-Workflows definieren, die die Repräsentation von Metrikberechnungen zulassen. Damit erfüllt Pentaho auch die Anforderung nach der Kompatibilität zum ISO-Prozess und der heterogenen Interpretation, wie sie für MeDIC beschrieben wurde. Die Anforderung nach einer asynchronen und autonomen Integration wird von Pentaho nur teilweise erfüllt. ETL-Prozesse lassen sich nur über eine Jobsteuerung managen, eine Möglichkeit diese Prozesse Ereignis-basiert zu starten existiert nicht. Die Integration über das Messaging-Pattern ist zwar möglich, aber momentan nur rudimentär ausgebildet. Damit erfüllt Pentaho auch nicht die Anforderung nach einer großen operationellen Sensibilität. Der Benutzer muss warten, bis das System alle ETL-Prozesse gestartet hat, um die aktuellen Daten zu ermitteln. Real-Time Data-Warehousing ist momentan nur ein Konzept bei Pentaho. Die letzte Anforderung nach Erweiterbarkeit ist bei Pentaho erfüllt, es besitzt eine Pluginschnittstelle, die in den ETL-Prozess sowie auch in die Analysetools integriert werden können. Als Integrationslösung gehört Pentaho zu einer Klasse von Hybridsystemen, die die Eigenschaften von dateibasierter-, datenbankbasierter- und service-orientierter Integration miteinander kombinieren kann. Damit erbt es die wesentlichen Eigenschaften und Qualitätsmerkmale dieser Integrationsarchitekturen. Die Mächtigkeit von Pentaho liegt in der Integrationskomponente Kettle Rational Insight Bei Rational Insight [65] handelt es sich um ein Produkt von Rational/IBM 8 zur Leistungsbewertung von Produkten und Projekten. Dazu werden Messwerte aus anderen Softwareprodukten in Rational Insight gesammelt, welches dann 8 78

93 6.3. Rational Insight Abbildung 6.9.: Rational Insight mittels Reports und Dashboards konsolidiert visualisiert werden. Abbildung 6.9 visualisiert den internen Datenfluss von Rational Insight und die grundlegende Architektur hinter dem Produkt. Ausgehend von bekannten IBM/Rational-Tools für den Softwareentwicklungsprozess werden diese als Service interpretiert mittels einer REST-Schnittstelle abgefragt, die Daten als XML dann innerhalb eines ETL-Prozesses entsprechend verarbeitet, um dann schließlich in einem Data-Warehouse konsolidiert zur Verfügung zu stehen. Aus dieser Datenbank können dann beliebige Reports in Form von Grafiken oder kompletten Dashboards generiert werden. Architektonisch gesehen basiert Rational Insight auf einem Data-Warehouse mit mehreren vorangehenden ETL-Prozessen, die die externen Datenquellen abfragt und deren Resultate integriert. Diese ETL-Prozesse sind anwendungsspezifisch, kapseln also die fachliche und technischen Strukturen der Anwendungen sauber von Rational Insight. Diese Daten werden in separaten Datentabellen innerhalb des DWH gespeichert. IBM bezeichnet diese Daten als operative Daten (ODS) [66], die aber auch innerhalb von Reports für Detailinformationen herangezogen werden können. Rational Insight nutzt ähnliche Konzepte und Begrifflichkeiten wie die ISO- Norm 15939; so werden Messungen durch Metriken repräsentiert, die bestimmte Ziele erfüllen sollen. Beispielsweise wird die Metrik Percent Code Rewritten dem Ziel Increase Productivty zugeordnet. Im Gegensatz zu MeDIC gibt es keine geführte Auswahl über von einem Experten vorgestellte Informationsbedürfnisse und zugehörige Metriken. Trotzdem kennt das Produkt Vorlagen für Dashboards und Reports. Im Reportbereich steht Rational Insight die komplet- 79

94 6. Vorhandene Lösungen für Projektdashboards Abbildung 6.10.: Rational Insight - Dashboard te Palette an Business Intelligence Produkten zur Verfügung, die IBM anzubieten hat. Abbildung 6.10 zeigt ein fertiges Dashboard für Softwareentwicklungsdaten innerhalb von Rational Insight. Insgesamt gesehen handelt es sich bei Insight um die Integrationskomponente, die Softwareprozessdaten aus festdefinierten Softwaretools über die BI-Programme von IBM/Rational auswertbar macht Integrationseigenschaften Rational Insight kennt drei unterschiedliche Wege. Daten aus externen Systemen zu integrieren. Rational Insight beschränkt sich auf die Integration der IBM-eigenen Produktlinie für den Softwareentwicklungsprozess Rational ClearCase 9 Das SCM Paket von Rational zur versionierten Verwaltung von Prozessund Projektartefakten wie Dokumenten, Sourcecode, etc. Rational ClearQuest 10 Das CRM Paket von Rational zur Erfassungen von Änderungen und Feh

95 6.3. Rational Insight Abbildung 6.11.: Rational Insight - Integrationsarchitektur lern während des Entwicklungsprozesses. Rational Team Concert 11 Projektmanagementplattform zum Tracken und Planen von Aktivitäten im Softwareentwicklungsprozess. Über Teamconcert lassen sich auch andere 3rd-Party-Systeme wie JIRA, GIT und Subversion integrieren. Ob deren Daten dann auch in Rational Insight zur Verfügung stehen bzw. wie sie zur Verfügung stehen, konnte nicht evaluiert werden. Rational Quality Manager 12 Eine Plattform zum Planen,Tracken und Ausführen von automatisierten Tests als Qualitätssicherungsmaßnahme. Rational Requirements Composer 13 Ein Packet zur Erfassung und Verwaltung von Anforderungen für ein Softwareprodukt. 11 jazz.net/products/rational-team-concert

96 6. Vorhandene Lösungen für Projektdashboards Diese Übersicht enthält nur die wichtigsten integrierten Systeme, weitere Informationen finden sich in der Dokumentation zu Rational Insight [66]. IBM deckt mit seinen integrierten Systemen alle relevanten Phasen des Softwareentwicklungsprozesses ab, daher ist Insight in der Lage, Reports für jede Phase anzubieten. Das fachliche Spektrum von Rational Insight ist daher immens, auf technologischer Ebene sind die Integrationseigenschaften aber eher beschränkt. IBM implementiert drei Mechanismen, um Daten aus den externen Systemen in das Insight Datawarehouse zu integrieren. Alle drei Mechanismen sind auf die Schnittstellen und Services der bekannten IBM Produkte zugeschnitten. Das erste Verfahren ist die Extraktion von Daten aus über einen REST-Service, der von dem zu integrierenden System angeboten wird. Die Daten stehen dann als XML zur Verfügung. Diese XML-Daten werden dann über einen XML-ODBC- Treiber dem Data Manager zur Verfügung gestellt. Der Datamanager kann dann auf diese Datenquelle einen applikationsspezifschen ETL-Prozess ausführen und so die Daten in das Data-Warehouse integrieren. Zusätzlich dazu kennt der Datamanger auch den Zugriff über eine direkte Datenbankschnittstelle. Die ETL-Prozesse werden als Jobs zeitgesteuert ausgeführt Bewertung Rational Insight gehört mit seinem Data-Warehouse zur Klasse der Integrationssysteme, die eine gemeinsame Datenbank verwenden. Damit erbt es alle Vorund Nachteile dieser Lösungsklasse. Um dem Nachteil der mangelnden Aktualität der Daten zu begegnen, kennt Insight den direkten Zugriff aus der Reportingkomponente auf die REST-Schnittstellen der externen Systeme. Dabei werden aber keine Daten integriert, sondern die Systeme liefern nur individuelle Daten, eine Integration wie es EII bietet, kennt Insight nicht. Das vorgegebene Datenmodell bietet das volle Spektrum an Softwareentwicklungsdaten vom Sourcecode, Kostenplanungen über Bugfunde bis hin zu Testergebnissen. Damit erfüllt es die Anforderung an die Integration funktional heterogener Systeme. Technologische Heterogenität (Systemheterogenität) wird kaum unterstützt, man beschränkt sich auf die IBM-Produktlinie mit wenigen spezifischen Technologien. Die Integration von Nicht-IBM-Produkten wird insofern unterstützt, dass das Datenmodell des Data-Warehouses dokumentiert zur Verfügung 14 steht, 3rd-Party sollen über einen direkten Zugriff auf diese Datenbank integriert werden. Eine Adaption der ETL-Prozesse ist laut IBM selber [4] nicht vorgesehen. Die Thematik operationelle Sensibilität wird von Rational Insight nur unzureichend erfüllt, zwar gibt es eine Datenbank für operationelle Daten, die aktuelle nicht durch ETL verarbeitete Daten bzw. live aus den externen Systemen extrahierte Daten enthält. Diese sind aber nur eindimensional und quasi im

97 6.4. Weitere Lösungen Roh-Format und zur Analyse daher nur mangelhaft geeignet. Es scheint sich dabei um eine schnelle Lösung zu handeln, um zumindest ein Minimalmaß zu erfüllen Weitere Lösungen In diesem Abschnitt werden noch weitere Lösungen vorgestellt, die dem MeDIC- Umfeld zu zuordnen sind. Da es sich aber um keine expliziten Dashboardanwendungen handelt, sondern eher um Systeme, die nur Teile der Anforderungen an MeDIC erfüllen, werden sie keiner intensiven Bewertung unterzogen. Viele dieser Systeme sind aber potenzielle oder sogar schon implementierte, wie Sonar[27], Integrationspartner von MeDIC QMetric QMetric ist ein quelloffenen Softwaresystem, das Schackmann im Zuge seiner Dissertation [103] entwickelt hat. Bei QMetric handelt es sich um eine Werkzeug Sammlung für die Spezifizierung von Metriken und ihrer Anwendung auf Daten aus dem Softwareentwicklungsprozess. Fig. 1. Architectural Overview of the QMetric Tool Suite own metrics Abbildung by using graphical 6.12.: QMetric wizards accommodated Komponentendiagramm assignment of a nach value based [104] on quantile classification to different expertise of the users. with respect to a set of empiric values. Different The Output Converter is a server-side component weighting of incoming edges is typically expressed by a that transforms metric results given in XML into several linear equation. output Abbildung formats, e.g charts, zeigt or spreadsheets. ein Komponentendiagramm Results can These functions für QMetric, enable to express welches a wide die vier range of be wesentlichen enriched with links Komponenten to related CRs von which QMetric eases beinhaltet. quality models. The fulfillment of an envisaged quality validation and interpretation of metric results. level can for example be modeled by using a threshold function at a sink node of a DAG. Different quality 3. User-defined MetricCalculator Quality Models levels can then be modeled in sub graphs of the DAG Der MetricCalculator ist die Kernkomponente with tightened thresholds von QMetric. in each level. In ihr wird In order to relate metrics to improvement goals we The Quality Evaluation Tool is used to evaluate the der metric evaluation algoithm ausgeführt. Er nutzt die angeschlossenen use hierarchical quality models that lean on the approach process quality with respect to a given quality model. In of bidirectional Datenquellen quality models (datasourcewrapper) introduced by Simon et um order Metrik to configure zuan berechnen. evaluation the user Metrikspezifikationen concepts are liegen on the als one side XML-Dateien quality inthe QMetric quality model vor. to be Sie used, können damit has to specify: al. [2]. Basic characteristics that reflect high-level requirements on the entity to be evaluated (by defining a filter on the deklarativ spezifiziert werden. the quality. An example of a quality characteristic is CRs related to a product or project) planning precision which can be subdivided into the and optionally the comparison data (e.g. a group of quality MetricQueryTool characteristics adherence to schedule, adherence similar projects, or an earlier time span) to planned effort, Eineand Webapplikation process transparency. zum DurchsuchenThe undquality Ausführen Evaluation undtool einzelnen can automatically Me- On the other side the quality indicators are used to trigger all required metric calculations. Results can be describe how quantitatively measurable attributes of an browsed in a tree view, drilled down to individual results entity (i.e. product, process, or system) can be for each time interval, and visualized. interpreted with respect to a quality characteristic. An The QMetric tool suite had been published open approach to guide interpretation is for example the source. Further information and related case studies can classification of measurement results according to the be found on value distribution in a peer group of measured entities. The Quality Model Editor enables to define such 4. References hierarchical quality models. In general the model is a directed acyclic graph (DAG). Source nodes represent [1] L. Grammel, H. Schackmann, and H. Lichter (2007), 83

98 6. Vorhandene Lösungen für Projektdashboards trikberechnungen. Die Exportschnittstelle (OutputConverter) erlaubt die Ausgabe von Metrikberechnungen in unterschiedlichen Formaten. QualityModelEvaluationTool Mittels QMetric können Qualitätsmodelle modelliert werden, die Metriken zur Berechnung einzelner Qualitätsmerkmale einsetzen. DataSourceWrapper Beim DataSourceWrapper handelt es sich um eine Komponente, die Daten aus CRM-Systemen oder VCS-Systemen extrahieren kann. Abbildung 6.13 zeigt einen Screenshot für das MetricQueryTool. Es können Metriken und Filterkriterien für die Datenquelle definiert werden. Abbildung 6.13.: QMetric - MetricQueryTool Das Datenmodell von QMetric ist eingeschränkt auf die Eigenschaften für CRMund VCS-Systeme. Weitere Systeme können nicht integriert werden. QMetric gehört zur Klasse der Messsysteme, wie Sie für die Funktionsheterogenität definiert wurden. Durch seine Möglichkeit deklarativ Metriken zu spezifizieren und auch berechnen zu lassen, ist es ein potenzieller Integrationspartner für MeDIC SiSSy/QBench QBench 15 ist ein Forschungsprojekt mit dem Ziel während des Softwareentwicklungsprozesses, die innere Qualität von Objekt-orientierter Software zu erhöhen. Im Zuge dieses Projektes entstand mit SISSy [114] ein Softwaretool zur Bewertung von Softwaresystemen. Die Arbeitsweise von Sissy ist in Abbildung

99 6.4. Weitere Lösungen dargestellt. SISSy analysiert den Sourcecode eines Softwareprojektes und baut daraus ein internes Objektmodell. Dies Objektmodell ist sprachunabhängig, über Sprach-spezifische Faktenextraktoren werden eine Vielzahl von Programmiersprachen unterstützt. Über weitere Tools werden Meta-Informationen über den Sourcecode wie Duplikate und Kommentarqualität hinzugefügt. Architektur von SISSy Java C / C++ Delphi Quellcode Faktenextraktoren Comment Analyzer Clone Analyzer Clone Extractor Objektmodell SQL Anfrage System Repository SQL Berichte Query Runner SQL Datenbank Mircea Trifu SISSy Abbildung Ein Open-Source 6.14.: Source-Werkzeug SISSy Architektur zur strukturellen nach Untersuchung [114] von Software-Systemen Systemen 10 QBench liefert für SISSy 52 Problemmuster, die automatisch ermittelt werden können. Die Software ist für den Batch-Betrieb ausgelegt, die Autoren empfehlen einen tägliche Ausführung. Ähnlich wie QMetric besitzt SISSy ein starres internes Datenmodell, was sowohl die Daten- also auch die Funktionsheterogenität massiv negativ beeinflusst. Aufgrund des großen Problemkatalogs, wäre es als Messsystem von Interesse. Leider ist das Projekt beendet und mangelnde Pflege der Webseite führt leider dazu, dass die Software momentan nicht mehr verfügbar ist CAST CAST 16 ist eine kommerzielle Anwendung die ein ähnlichen Weg einschlägt wie SiSSy. CAST verfügt über eine internen Datenbank von Problemmustern für die Code- und Architekturqualität von Softwaresystemen. Abbildung

100 6. Vorhandene Lösungen für Projektdashboards stammt aus einem WhitePaper [20] von CAST und visualisiert den grundsätzlichen Ablauf der Arbeit mit CAST. Basis der durch CAST durchgeführten Qualitätsmessungen sind die Quelltexte der Software. Dabei unterstützt CAST eine Vielzahl von Programmiersprachen. Innerhalb von CAST werden dann die Qualitätsmessungen durchgeführt, dabei dienen CAST hauptsächlich Codeund Architekturstandards als Grundlage. Abbildung 6.15.: CAST Übersicht Abbildung 6.16 zeigt einen Screenshot aus der Online-Dokumentation der Software. Leider konnte die Software aufgrund des kommerziellen Umfeldes nicht weiter evaluiert werden, aber die vorhandenen Quellen legen nahe, dass die Integrationseigenschaften nur sehr rudimentär ausgeprägt sind. Als Messsystem wäre es aber von nicht unerheblichen Interesse, da es auch oft im Zusammenhang mit Softwareleitständen referenziert wird [28] Zusammenfassung Tabelle 6.1 zeigt eine zusammenfassende Bewertung der vorgestellten Lösungen in Bezug auf die Anforderungen und die Qualitätsmerkmale für Integrationslösungen. Ein wichtiges Ergebnis ist die Tatsache, dass Integration von Daten aus der Softwareentwicklung und ihre Auswertung zu großen und komplexen Systemen führt. Mit Pentaho als Vertreter der klassischen Data-Warehousesysteme und mit Insight, einer speziell auf die Softwareentwicklung zugeschnittenen Lösung, stehen 86

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Application Server und Continuous Integration

Application Server und Continuous Integration Application Server und Continuous Integration Outline 2 Einleitung Application Server Java EE Enterprise Applikationen vs. Web Applikationen Web Application Life Cycle Servlets JavaServer Pages verschiedene

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Programmierung von Client/Server- Anwendungen

Programmierung von Client/Server- Anwendungen Programmierung von Client/Server- Anwendungen Komponenten des Web-Containers (Java EE) SoSe2015 Prof. Dr. Andreas Schmietendorf 1 Übersicht zur Vorlesung Entwicklung der Java Enterprise Edition Servlets,

Mehr

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Diplomarbeit. Fachliche Integration von Metrik-Dashboards und Dashboard-Vorlagen für bestehende Software-Projekte

Diplomarbeit. Fachliche Integration von Metrik-Dashboards und Dashboard-Vorlagen für bestehende Software-Projekte Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Fachliche Integration von Metrik-Dashboards und Dashboard-Vorlagen für bestehende Software-Projekte

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH Erfahrungen und Erkenntnisse Klaus Richarz, HBT GmbH Java Enterprise Edition 5.0 JBoss Seam Konsequenzen für Realisierung Qualitätssicherung Build & Deployment Fazit & Empfehlungen JBoss Seam in Projekten,

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10. J2EE eine Plattform für betriebliche Anwendungen Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Plattform Betriebliche Anwendung J2EE Kontrahenten J2EE im Überblick Was ist

Mehr

Integrating Architecture

Integrating Architecture Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Vorstellung und Einführung Ein beliebiger Zeitpunkt in einem beliebigen Unternehmen

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

Mufid Sulaiman mufidsulaiman@web.de

Mufid Sulaiman mufidsulaiman@web.de Mufid Sulaiman mufidsulaiman@web.de Überblick Frameworks Applikationsentwicklung mit Frameworks Komponentenbasierte Frameworks Einführung in Enterprise JavaBean Einführung in SanFrancisco Vergleich Enterprise

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Enterprise Edition Teil 4 Schnittstellen el0100 copyright W. G. Spruth, wgs 04-10

Mehr

Der SBB Online-Ticketshop Mit SOA zum Erfolg

Der SBB Online-Ticketshop Mit SOA zum Erfolg Der SBB Online-Ticketshop Mit SOA zum Erfolg BAT 03 Stefan Meichtry, Stefan Becker Bern, den 17.03.2006 SBB Informatik 1 Das Ziel SBB Informatik 2 Agenda Problemraum Lösungsraum Analyse Wir sind hier Synthese

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

MICHAEL RÜGER. Abschluss Diplom Fach Informatik. Geburtsjahr 1985 Profil-Stand April 2015

MICHAEL RÜGER. Abschluss Diplom Fach Informatik. Geburtsjahr 1985 Profil-Stand April 2015 MICHAEL RÜGER Abschluss Diplom Fach Informatik Geburtsjahr 1985 Profil-Stand April 2015 Triona Information und Technologie GmbH Wilhelm-Theodor-Römheld-Str. 14 55130 Mainz Fon +49 (0) 61 31 9 21-122 Fax

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Bachelorarbeit. Integration einer Metrik-Infrastruktur in die Projektverwaltung SSE-Lab

Bachelorarbeit. Integration einer Metrik-Infrastruktur in die Projektverwaltung SSE-Lab Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Bachelorarbeit Integration einer Metrik-Infrastruktur in die Projektverwaltung SSE-Lab vorgelegt von Arthur

Mehr

G s e a s m a t m ar a ch c i h tek e tur u I und IoC

G s e a s m a t m ar a ch c i h tek e tur u I und IoC Gesamtarchitektur I und IoC Schichten einer Web-Anwendung Initiiert durch J2EE und Spring: Strukturierte Sicht auf UI und Fachlogik (Domäne) Ergibt 5 Schichten: Man unterscheidet Präsentations- und Domänenmodell!

Mehr

Übungsaufgabe Transaktion als Middleware

Übungsaufgabe Transaktion als Middleware Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Android Kurs Online Kurs Entwicklung auf Android-Handys

Android Kurs Online Kurs Entwicklung auf Android-Handys Android Kurs Online Kurs Entwicklung auf Android-Handys Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses Modul Eins - Programmierung J2ee 1) Grundlegende Java - Programmierung : Grundlegende

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Softwarequalität: Definitionen, Wünsche, Grenzen

Softwarequalität: Definitionen, Wünsche, Grenzen Softwarequalität: Definitionen, Wünsche, Grenzen iks Thementag Mehr Softwarequalität Ausgewählte Themen 22.05.2014 Autor: Christoph Schmidt-Casdorff Agenda Einführung Was ist Softwarequalität? Qualität

Mehr

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Sommersemester 2013 Michael Theis, Lehrbeauftragter Java EE Spezifikation definiert ein Programmiermodell für Applikationen die Eigenschaften

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Empfehlungen für erfolgreiche ADF-Projekte. Volker Linz Oracle Deutschland B.V. & Co. KG

Empfehlungen für erfolgreiche ADF-Projekte. Volker Linz Oracle Deutschland B.V. & Co. KG Empfehlungen für erfolgreiche ADF-Projekte Volker Linz Oracle Deutschland B.V. & Co. KG Empfehlungen für erfolgreiche ADF-Projekte Architektur & Design Team & Skills Organisation & Entwicklungsprozess

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

Liste V Enterprise JavaBeans

Liste V Enterprise JavaBeans Liste V Enterprise JavaBeans Fachhochschule Wiesbaden, FB Design Informatik Medien Studiengang Allgemeine Informatik Vorlesung zur Vertiefungslehrveranstaltung Spezielle Methoden der Softwaretechnik SS

Mehr

Die Erkenntnis von gestern muss heute mit einem neuen. 19.06.2009 TEAM - Ihr Partner für IT 2

Die Erkenntnis von gestern muss heute mit einem neuen. 19.06.2009 TEAM - Ihr Partner für IT 2 Beratung Software Lösungen Integration von Reporting Tools in Oracle ADF 11g Applikation Der Inhalt dieses Vortrages beruht auf den Erfahrungen und Erkenntnissen zu einem bestimmten Zeitpunkt und unter

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Copyright 2014, Oracle and/or its affiliates. All rights reserved. 1 Oracle Fusion Middleware Ordnung im Ganzen Matthias Weiss Direktor Mittelstand Technologie ORACLE Deutschland B.V. & Co. KG 2 Agenda Begriffe & Ordnung Fusion Middleware Wann, was, warum Beispiel für

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Automatisiertes Testen von Java EE-Applikationen mit Arquillian

Automatisiertes Testen von Java EE-Applikationen mit Arquillian CONCEPTS DEVELOPMENT INTEGRATION Automatisiertes Testen von Java EE-Applikationen mit Arquillian Sebastian Lammering CDI AG Firmenkurzportrait Die CDI ist ein IT-Beratungsunternehmen mit Sitz in Dortmund.

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

Mehr

jbpm5 in Java EE 6 Marek Iwaszkiewicz Pascal Schaerf akquinet AG

jbpm5 in Java EE 6 Marek Iwaszkiewicz Pascal Schaerf akquinet AG jbpm5 in Java EE 6 Marek Iwaszkiewicz Pascal Schaerf akquinet AG Über uns Developer @ akquinet AG Marek Iwaszkiewicz marek.iwaszkiewicz@akquinet.de JBoss Compentence Center Pascal Schaerf pascal.schaerf@akquinet.de

Mehr

// Mehr, als Sie erwarten //

// Mehr, als Sie erwarten // // Mehr, als Sie erwarten // // Unitek entwickelt seit 1988 innovative Software, mitten in der Altstadt von Zürich. Gegründet von ETH-Absolventen, hat Unitek dank massvollem Wachstum, anhaltender Begeisterung

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.

Java und XML/XML und Java. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle. Java und XML/XML und Java Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.de XML und Programmiersprachen... Java ist... Programmiersprache

Mehr

ITS Business Integrator

ITS Business Integrator IBI Weboberfläche zur Datenintegration Location Viewer Asset-Management Smallworld GIS Monitoring Planung Bau Wartung Entstörung Integration Der ITS Business Integrator (IBI) ist eine offene Plattform

Mehr

Softwaremessung und -metrik

Softwaremessung und -metrik Softwaremessung und -metrik AW1 Votrag - Daniel Wojtucki Hamburg, 20. Januar 2010 Inhalt 1 Einleitung 2 Softwarequalität 3 Grundlagen der Softwaremetrik 4 Beispiele bestimmter Metriken 5 Zusammenfassung

Mehr

Prozessautomatisierung mit BPMN 2.0 und Java. bernd.ruecker@camunda.com

Prozessautomatisierung mit BPMN 2.0 und Java. bernd.ruecker@camunda.com Prozessautomatisierung mit BPMN 2.0 und Java bernd.ruecker@camunda.com Bernd Rücker camunda services GmbH Demo Was ist Prozessautomatisierung mit BPMN 2.0 Prozessautomatisierung mit Process Engine Monitoring

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Softwaretechnik Nicht funktionale Anforderungen

Softwaretechnik Nicht funktionale Anforderungen Softwaretechnik Nicht funktionale Anforderungen Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Will Turner: You swore she d go free! Barbossa: Don t dare impugn me honor boy! I agreed she go

Mehr

Security Technologien in Java EE 6

Security Technologien in Java EE 6 Security Technologien in Java EE 6 Java Forum Stuttgart 2010 Sebastian Glandien Acando GmbH sebastian.glandien@acando.de Agenda I. Einleitung II. Java Authentication SPI for Containers (JSR-196) I. Message

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Connection Architecture Teil 4 JCA

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Connection Architecture Teil 4 JCA UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Connection Architecture Teil 4 JCA el0100 copyright W. G. Spruth, wgs 04-09 Enterprise

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

3... SAP NetWeaver Developer Studio: Schritt für Schritt zur Beispielanwendung... 119

3... SAP NetWeaver Developer Studio: Schritt für Schritt zur Beispielanwendung... 119 1... SAP NetWeaver... 25 1.1... Plattform für die Enterprise Service-Oriented Architecture... 26... 1.1.1... Enterprise-SOA-Definition... 26... 1.1.2... Vorteile einer serviceorientierten Architektur...

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

JSP und Servlet Programmierung

JSP und Servlet Programmierung Seminarunterlage Version: 5.02 Copyright Version 5.02 vom 1. März 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Gemeinsam mehr erreichen.

Gemeinsam mehr erreichen. Gemeinsam mehr erreichen. Oracle ESS 12c Client Application mit ADF ADF Spotlight 6. März 2015 Ihr Ansprechpartner Carsten Wiesbaum Principal Consultant carsten.wiesbaum@esentri.com @CWiesbaum Schwerpunkte:

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

Kontinuierliche Architekturanalyse. in 3D

Kontinuierliche Architekturanalyse. in 3D Kontinuierliche Architekturanalyse in 3D Stefan Rinderle Bachelor an der HS Karlsruhe Master "Software Engineering" in München / Augsburg Seit 2013 bei Payback 2 Software-Visualisierung Visualisierung

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Softwarearchitektur als Mittel für Qualitätssicherung und SOA Governance

Softwarearchitektur als Mittel für Qualitätssicherung und SOA Governance Softwarearchitektur als Mittel für Qualitätssicherung und SOA Governance Mag. Georg Buchgeher +43 7236 3343 855 georg.buchgeher@scch.at www.scch.at Das SCCH ist eine Initiative der Das SCCH befindet sich

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

PRODATIS CONSULTING AG. Folie 1

PRODATIS CONSULTING AG. Folie 1 Folie 1 Führend im Gartner Magic Quadranten für verteilte, interagierende SOA Projekte Oracle ist weltweit auf Rang 1 auf dem Markt der Enterprise Service Bus Suiten (ESB) für SOA Software 2010 26,3 %

Mehr

Einbettung von Geoinformationen in E-Government-Prozesse

Einbettung von Geoinformationen in E-Government-Prozesse Einbettung von Geoinformationen in E-Government-Prozesse grit - graphische Informationstechnik Beratungsgesellschaft mbh Büro Berlin: Maxstr. 3a D-13347 Berlin +49-30-46606280 +49-30-46606282 Status und

Mehr

2. A reference architecture for business information systems Reference Architectures and Patterns

2. A reference architecture for business information systems Reference Architectures and Patterns 2. A reference architecture for business information systems Reference Architectures and Patterns Winter Semester 2008 / 2009 Prof. Dr. Bernhard Humm Darmstadt University of Applied Sciences Department

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr