Integration betrieblicher Informationssysteme und modellgetriebene Entwicklung

Leipziger Beiträge zur Informatik | Band XXX Integration betrieblicher Informationssysteme und modellgetriebene Entwicklung Heiko Kern Stefan Kühne (Hrsg.) Integration betrieblicher Informationssysteme und modellgetriebene Entwicklung Herausgeber Heiko Kern Universität Leipzig Institut für Informatik Abteilung Betriebliche Informationssysteme Johannisgasse 26 04103 Leipzig Stefan Kühne Institut für Angewandte Informatik e.V. an der Universität Leipzig Johannisgasse 26 04103 Leipzig Integration betrieblicher Informationssysteme und modellgetriebene Entwicklung/ Heiko Kern, Stefan Kühne (Hrsg.). – Leipzig, 2012 ISBN: 978-3-941608-17-7 Vorwort In der „Reihe Leipziger Beiträge zur Informatik“ erscheinen Forschungsberichte aus Forschungsvorhaben, Herausgeberbände im Bereich innovativer und sich etablierender Forschungsgebiete, Habilitationsschriften und Dissertationen sowie herausragende Beiträge von Studenten. Die Arbeiten sind in der Angewandten Informatik und der Wirtschaftsinformatik angesiedelt. Schwerpunkte liegen dabei in den Bereichen betriebliche Informationssysteme, Content- und Wissensmanagement sowie IT-gestützte intra- und interorganisationale Kooperation mittels Internet-Technologien. Thematisch wird im vorliegenden Band die Integration von betrieblichen Informationssystemen sowie die Anwendung der modellgetriebenen Softwareentwicklung in diesem Bereich adressiert. Die Beiträge basieren auf den Ergebnissen der folgenden Forschungsprojekte. Ein Framework für das Integration Engineering im E-Business (EFIE) Ziel des Projekts war die Entwicklung eines Framework für das Integration Engineering im E-Business. Zu diesem Zweck wurde ein modellgetriebenes Integrationsframework – spezifisch für die Domäne E-Business – konzipiert und prototypisch implementiert. Die Projektergebnisse bilden die Grundlage für eine effizientere Erstellung von Integrationslösungen und damit eine verbesserte Erbringung von Integrationsdienstleistungen. Automatisierte Anpassung, Integration, Evolution und Migration von Full-Service-Anwendungen im E-Commerce (AutoFuSA) Im Forschungsprojekt autoFuSA wurde eine IT-Referenzlösung für die Umsetzung einer Full-Service-Strategie im Anwendungskontext E-Commerce konzipiert und realisiert. Full-Service bezeichnet dabei eine Geschäftsstrategie, bei der Anpassung, Einführung, Betrieb und Wartung eines E-Business-Systems vollständig von einem Anbieter übernommen werden. Somit wird der Full-Service-Anbieter in die Lage versetzt, Full-ServiceAnwendungen anzubieten. Advanced Model Repository (AMOR) Fragen der effizienten Verwaltung modellgetriebener Artefakte in komplexen, verteilten Entwicklungsprozessen sind bisher ungelöst. Im Projekt wurde ein Modell-Repository entwickelt, um Artefakte und Assets der modellgetriebenen Softwareentwicklung in geeigneter Form zu speichern, zu verwalten, zu versionieren, wiederzufinden und wiederzuverwenden. Die Forschungsvorhaben EFIE (Förderkennzeichen: 01IS08029D), AutoFuSA (Förderkennzeichen: 01IS08010B) und AMOR (Förderkennzeichen: 01IS08038C) wurden durch das BMBF im Rahmen der Fördermaßnahme „KMU-innovativ: Informations- und Kommunikationstechnologie (IKT)“ gefördert und vom Projektträger Softwaretechnik des Deutschen Zentrums für Luft- und Raumfahrt e.V. (DLR) betreut. Die Projektteams bedanken sich herzlich für die gebotene Möglichkeit, in diesem interessanten Forschungsbereich arbeiten zu können. Weiterhin bedanken sich die Herausgeber bei allen Autoren für die qualitativ hochwertigen Beiträge. Klaus-Peter Fähnrich Professur Betriebliche Informationssysteme Direktor Institut für Angewandte Informatik e. V. an der Universität Leipzig Sprecher des Leipziger Informatik-Verbund Leipzig, April 2012 Inhaltsverzeichnis Fred Stefan, Martin Gebauer Realität der Integration – eine empirische Bestandsaufnahme . . . . . . . . . . . . . . . . . 1 Martin Gebauer, Johannes Schmidt Problemadäquate Klassifikation und Systematisierung von Integrationsmustern . . . . . . . 21 Peter Hänsgen, Heiko Kern Softwareentwicklung im Full-Service E-Commerce . . . . . . . . . . . . . . . . . . . . . . 43 Rolf-Helge Pfeiffer und Peter Hänsgen Erweiterung eines MDSD-Systems zur Unterstützung von Produktlinien durch Feature-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Peter Hänsgen, Heiko Kern Modellbasierte Schichtenarchitektur zur Komposition von Geschäftsanwendungen . . . . . . 65 Heiko Kern Interoperabilität mittels M3-Level-basierter Transformationen . . . . . . . . . . . . . . . . 77 Peter Hänsgen, Stefan Kühne Anforderungen an ein Modell-Repository im Kontext eines MDSD-Entwicklungsprozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Steffen Dienst, Stefan Kühne Graph-basierte Speicherung und Versionierung von Modellen . . . . . . . . . . . . . . . . 101 Steffen Dienst, Steffen Stundzig MTF – Modeling Team Framework zur effizienten Unterstützung modellgetriebener Softwareentwicklungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 vii Realität der Integration - eine empirische Bestandsaufnahme Fred Stefan, Martin Gebauer Universität Leipzig, Institut für Informatik, Abteilung Betriebliche Informationssysteme Johannisgasse 26 04103 Leipzig {stefan | gebauer}@informatik.uni-leipzig.de Kurzfassung: Die wissenschaftliche Literatur liefert nur wenige Erkenntnisse über das praktische Vorgehen bei Integrationsprojekten. Um diese Diskrepanz zu beseitigen, hat die Universität Leipzig eine qualitative, empirische Untersuchung mit Integrationsdienstleistern durchgeführt. Dieser Beitrag beschreibt die Konzeption, Durchführung sowie erste Ergebnisse. Die Untersuchung wurde in Form von 30 Experteninterviews realisiert. Das Ziel war, zu überprüfen, ob einige im akademischen Bereich hoch gelobte Methoden auch wahrhaftig in der Praxis Anwendung finden und letztendlich herauszufinden, wie Integrationsdienstleistungen heute erbracht werden. Da bis zum heutigen Zeitpunkt keine vergleichbaren Untersuchungen in diesem Bereich bekannt sind, werden die einleitenden theoretischen Betrachtungen ebenso wie die angewandte Forschungsmethode ausführlicher beschrieben. Die durchgeführten Interviews hatten eine Dauer von ein bis drei Stunden und ergaben insgesamt 52 Stunden Audiomaterial, welches transkribiert, extrahiert und reduziert wurde. Circa zwei Drittel der Auswertung sind zum gegenwärtigen Zeitpunkt bereits abgeschlossen. 1 Einleitung Integration ist ein fortlaufendes, mit vielen Problemen behaftetes [Sum00, LF02, PM08] Forschungsthema. Neben Gefahren [MA08], Risiken [PPS07] und Herausforderungen [SOO10] werden auch verschiedene Architekturen untersucht [CDV08]. Aus technischer Sicht wurde Integration augenscheinlich umfassend untersucht, jedoch gibt es nur wenige Versuche zu verstehen wann und warum gewisse Methoden angewandt werden [LS04, TI06]. Überdies stammen die Ergebnisse noch aus dem akademischen Bereich. Durch viele Investitionen in den letzten Jahren ging man zahlreiche Lock-in-Effekte ein, sodass die Praxis von Mischarchitekturen vieler Architekturarten geprägt ist. In der Tat sind beispielsweise serviceorientierte Architekturen (SOA) eine technisch sehr gut verstandene Methode, um mit Integrationsproblemen umzugehen. Fragt man jedoch Praktiker, wer von ihnen über eine reine SOA-Architektur verfügt, so kann dies keiner bejahen. Diese Diskrepanz zwischen Forschung und Praxis führte uns zu der zentralen Forschungsfrage: • Wie wird gegenwärtig Integration durchgeführt? – Wenn mehr als eine Lösung existiert, aus welchen Gründen entscheidet man sich für eine bestimmte? 1 – Welche Schritte eines Integrationsprojektes, werden durch welche Methoden und Werkzeuge unterstützt? Im Folgenden stellen wir die angewandte Untersuchungsmethode in Form qualitativer Experteninterviews, die durchgeführten theoretischen Vorüberlegungen zur Forschungsmethode, die Auswahl der Untersuchungsteilnehmer sowie den Aufbau der Studie vor. Darin sind neben Erläuterungen zu den untersuchten Variablen, auch erste wesentliche Ergebnisse enthalten. Zum gegenwärtigen Zeitpunkt ist die Auswertung der Studie noch nicht vollständig abgeschlossen. Allein die Transkription der Interviews schlug mit Faktor sechs zur Interviewzeit zu Buche. Nachdem eine Reduktion der Ergebnisse erfolgte, sind gegenwärtig circa zwei Drittel der Auswertung abgeschlossen. Auf diesem Stand basieren die präsentierten Ergebnisse. 2 Studienaufbau 2.1 Untersuchungsmethode Die von uns adressierte Forschungsfrage ist auf das Wissen von Praktikern angewiesen. Daher sind empirische Methoden ein probates Mittel. Da wir mit dieser Studie untersuchen wollen, wie und warum Integration auf eine bestimmte Art und Weise gemacht wird, sind quantitative Erhebungsmethoden keine geeignete Wahl. Um die zugrundeliegenden Konzepte zu erheben, fiel die Wahl daher auf qualitative Methoden, obgleich sie keine weite Verbreitung in der Informatikforschung besitzen (unterhalb von 10 Prozent [WH07]). Bestehende Untersuchungen konzentrieren sich auf Fallstudien [SOO10] oder Fokusgruppeninterviews [PPS07]. Aus folgenden Gründe wurden diese beide Ansätze verworfen: Eine Fallstudie umfaßt das Problem eines einzelnen Unternehmens. Um für eine Vielzahl von Problemen eine Entscheidungsgrundlage zu schaffen, ist die Betrachtung vieler verschiedener Fallstudien nötig. Somit waren Fallstudien keine angemessene Methode für unsere Zwecke. Gleiches gilt für Fokusgruppeinterviews. Da sie ungefähr acht bis zwölf Teilnehmer benötigen und Integrationsexperten sehr beschäftigt sind, war die Organisation nicht realisierbar. Unsere Wahl fiel letztendlich auf geleitete Experteninterviews. Da jeweils nur eine Person gleichzeitig befragt wird. Darüber hinaus ist – im Gegensatz zu Fokusgruppeninterviews – eine gegenseitige Beeinflussung der Teilnehmer ausgeschlossen. Methodisch sind wir nach der aus den Sozialwissenschaften stammenden Methode von Glaeser und Laudel [GL09] vorgegangen, welche für die Rekonstruktion von unbekannten, kausalen Zusammenhängen Vorteile gegenüber der von Mayring [May04] besitzt. Die Schrittfolge stellt sich wie folgt dar: • theoretische Vorüberlegungen – Forschungsfrage aufstellen, – State-of-the-art aufnehmen, – Hypothesen formulieren, – Variablen (abhängige und unabhängige) konstruieren, 2 – hypothetisches Modell aufstellen, – Fragebogen erstellen, • Interviewpartner ermitteln • Pre-test – Test mit einer Testperson, – Fragebogen anpassen, • Interviews durchführen • Transkription • Extraktion • Analyse • Auswertung Die gegenwärtige Situation im Bereich Integration wurde in Abschnitt 1 kurz umrissen. Darauf aufbauend wurde die Forschungsfrage formuliert. Der weitere Beitrag gliedert sich wie folgt: Entsprechend der zuvor genannten Methodik schließt sich in Abschnitt 2.2 ein Überblick über einige Hypothesen an. Sie bilden den Ausgangspunkt um abhängige und unabhängige Variablen abzuleiten und sie in einem hypothetischen Modell einzuordnen. Im Anschluss daran wird in Abschnitt 2.3 der entwickelte Fragebogen kurz vorgestellt sowie unter 2.4 beschrieben, wie die Auswahl geeigneter Unternehmen erfolgte. Ein zeitlicher Überblick über die Untersuchungen ist in Abschnitt 2.5 enthalten, bevor unter 3 einige Ergebnisse vorgestellt werden. Der Beitrag schließt im Abschnitt 4 mit einer Zusammenfassung und gibt darüber hinaus einen Ausblick auf weitere interessante Forschungsthemen. 2.2 Hypothesen und hypothetisches Modell Die ausgewählte Forschungsmethode setzt einige theoretische Vorüberlegungen voraus. Dazu zählt das Formulieren von Hypothesen sowie das Ableiten von abhängigen und unabhängige Variablen. Diese Zusammenhänge werden in ein hypothetisches Modell überführt, welches vermutete kausale Zusammenhänge beinhaltet. Ziel der Vorüberlegungen ist es die Formulierung der Fragen anzuleiten. Das bestätigen oder Falsifizieren steht nicht im Zentrum, vielmehr soll das Modell modifiziert und ergänzt werden. Die folgende Aufzählung umfasst einen Auszug unserer Hypothesen. 1. Je mehr die Integrationsdienstleister unter Zeitdruck gesetzt werden, desto unstrukturierter ist das Vorgehen. 2. Kurzfristige Ziele stehen bei Integrationslösungen im Vordergrund. 3 unternehmensbezogene Faktoren Gewichtigkeit und Invasivität kundenspezifische Faktoren Integrationsprojekte Integrationsverständnis Integrationslösung persönliche Faktoren Mainframefaktoren Faktoren der Wiederholbarkeit Produktportfolio Abbildung 1: Hypothetic model 3. Je leichtgewichtiger das Integrationsvorgehen ist, um so schneller ist die Lösung erstellt und um so höher die Akzeptanz. 4. Zu Projektbeginn sind nicht alle Anspruchsgruppen der Lösung bekannt. 5. Integrationsmuster sind weitgehend unbekannt. 6. Domänenspezifische Konzepte (Systemklassen, Prozesse etc.) treten wiederholt in Integrationsprojekten auf, ohne Eingang in die Lösungsgestaltung zu finden. 7. Hostsysteme sind in vielen Integrationsszenarien großer Unternehmen zu finden. Da deren Ablösung nur selten eine Option ist, müssen Integrationsdienstleister diese Legacy-Systeme bei der Integration besonders berücksichtigen. Für ein besseres Vertändnis erläutern wir das hypothetische Modell als Ganzes (Abbildung 1) und beschreiben daran anknüpfend dann die einzelnen Variablen und deren Bezug zu den Hypothesen. Das bedeutet, dass die Darstellung in diesem Beitrag in umgekehrter Reihenfolge zum Forschungsprozess erfolgt, bei dem die Erstellung des hypothetischen Modells am Ende der Vorüberlegungen steht. Die Integrationslösung – unser eigentlicher Interessensbereich – befindet sich als abhängige Variable im Zentrum der Darstellung. Da Integrationsdienstleistungen in Projekten erbracht werden, stellt das umschließende Integrationsprojekt den vermittelnden Handlungsbereich dar. Um zu verstehen, warum eine bestimmte Lösung verwendet wird, müssen demzufolge die Einflussfaktoren eines Integrationsprojektes abgeleitet werden, um dann Kausalketten ermitteln zu können. Der äußere Teil der Abbildung stellt die von uns identifizierten unabhängigen Variablen dar, wobei jede einzelne aus mehreren Einflussfaktoren besteht. Die Abhängigkeit oder Unabhängigkeit einer Variable ist dabei eine analytische Setzung, welche durch unser Forschungsziel bestimmt wird. Selbstverständlich hängen diese unabhängigen Variablen auch wiederum von anderen Variablen ab. In den folgenden Abschnitten werden die Variablen näher erläutert. 4 2.2.1 Unternehmensfaktoren Die Variable stellt den Einfluss dar, den der Integrationsdienstleister auf das Projekt und indirekt auch auf die Integrationslösung hat. Die eigene Größe des Dienstleisters ist möglicherweise ein Indiz für die Größe der Projekte, welche er realisieren kann. Ein Fokus auf eine bestimmte Branche könnte ein Hinweis auf branchentypische Integrationsprobleme liefern. Ebenso hilft ein festgelegtes Rollenmodell, einzuschätzen, welche Rollen im Integrationsprojekt durch den Dienstleister besetzt werden können. Das Geschäftsmodell der Dienstleister deckt den Fokus auf spezifische Integrationsprojekte auf. Hersteller eines ERP-Systems bieten häufig Integrationsdienstleistungen rund um ihr Standardprodukt an. Ebenfalls interessierte uns ob Vorgehens-, Rollen- oder Referenzmodelle bei Integrationsprojekten zum Einsatz kommen. 2.2.2 Persönliche Faktoren Dieses Teil der Studie beschäftigt sich mit den demographischen Basisfaktoren der Interviewteilnehmer und klärt unter anderem die folgenden Punkte: gegenwärtige Position im Unternehmen, Dauer der Unternehmenszugehörigkeit, Ausbildung sowie Erfahrungen im Bereich der Integration. Damit soll neben dem Expertenstatus auch ein breites Spektrum an Wissen und Erfahrungen im Integrationsbereich untermauert werden. Ein Ziel der Studie besteht darin, vorzugsweise Personen mit leitenden Aufgaben zu befragen, da sie zukünftige Entwicklung ihrer Produkte, sowie Werkzeuge und Hilfsmittel1 unterscheiden zu können. 2.2.3 Integrationsverständnis Das Verständnis von Integration und Integrationsobjekten ist sehr heterogen. Es reicht von technischer Integration, über Anwendungsintegration, Prozessintegration bis hin zur Unternehmensintegration. Dieses gemeinsame Unternehmenswissen, was in den Köpfen aller Angestellten eines Dienstleisters verankert ist, hat einen Einfluss darauf, wie Integrationsprojekte durchgeführt werden. Bedeutet Integration die technische Verbindung von Systemen, werden Projekte mit einer sehr ausgeprägten Geschäftsprozessanalyse seltener angestrebt. 2.2.4 Kundenspezifische Faktoren Ein wichtiger Punkt, welcher entscheidend für die Auswahl der Integrationslösung ist, sind die Anforderungen der Kunden. Wir nehmen an, dass es im Wesentlichen eine Hand voll Anforderungen oder Ziele gibt, welche in jedem Projekt von Relevanz sind. Ebenso wird unter dieser Variable die typische Kundengröße untersucht, mit denen sich die Dienstleister auseinandersetzen. Kleine 1 Der Ausdruck Integrationswerkzeug wird benutzt, um eindeutig zwischen z. B. einer Entwicklungsumgebung (die ausschließlich für Entwicklungszwecke gedacht ist) und einem Integrationshilfsmittel, wie beispielsweise einem Broker (der installiert und betrieben werden muss, in die Lösung eingeht) zu unterscheiden. 5 und mittlere Unternehmen benötigen andere Integrationslösungen als große Unternehmen. Außerdem sind je nach Kundenstruktur auch die durch sie besetzen Rollen in den Integrationsprojekten verschieden. 2.2.5 Produktportfolio Die Festlegung auf bestimmte Werkzeughersteller oder die Partizipation an einem Partnernetzwerk führt zu einer Spezialisierung in den Integrationsprojekten. Eine Spezialisierung auf einen Hersteller kann durchaus erfolgreich sein. In solch einem Fall setzt der Dienstleister bei der Lösungserstellung vorzugsweise – häufig auch ausschließlich – auf Produkte dieses Herstellers. Ebenso werden unter dieser Variable die Werkzeuge betrachtet, welche einzelne Schritt des Integrationsprojektes unterstützen. 2.2.6 Wiederholbarkeit Eines unserer Forschungsgebiete ist es, Integration zu automatisieren. Hierfür kommen modellgetriebene Technologien zum Einsatz. Wie in der Industrie bekannt, ist es nur nützlich, Dinge zu automatisieren, die wiederholt vorkommen. Andernfalls sind die Automatisierungsbemühungen unbrauchbar. Daher interessierte uns an dieser Stelle, welche Probleme wiederkehrend in Integrationsprojekten auftreten und eine Automatisierung lohnenswert wäre. Der nächste Schritt der Wiederverwendung ist es, diesen wiederkehrenden Problemen mit Mustern zu begegnen. Wie in der Softwaretechnik haben sich Muster auch im Integrationsbereich in Form von Integrationsmustern etabliert [HW03]. Die Verwendung von Integrationsmustern wäre ein Indiz für wiederkehrende Integrationsprobleme. Eine unserer Hypothesen ist, dass Integrationsmuster auf einem sehr groben Niveau existieren, welche nicht den Anforderungen des Integrationsprojektes entsprechen, da sie für gewöhnlich in einer geschäftlichen Sprache formuliert sind. 2.2.7 Gewichtigkeit und Invasivität In der Softwaretechnik gibt es eine lange Diskussion über die Gewichtigkeit von Vorgehensmodellen. So stehen sich schwergewichtige (z. B. Wasserfallmodell) und leichtgewichtige (z. B. SCRUM) Vertreter gegenüber. Integrationsprojekte sind ähnlich wie Softwareentwicklungsprojekte hinsichtlich ihrer Größe, Komplexität und den verwendeten Technologien sehr unterschiedlich. Da die Vorgehensmodelle unterschiedliche Merkmale hinsichtlich Zeitbedarf, Qualität, Flexibilität, Invasivität oder Gewährleistung besitzen, stellt sich uns die Frage, welches Vorgehensmodell sich am besten für welche Art von Integrationsproblem eignet. In letzter Zeit ist auch immer häufiger im Integrationskontext von der Terminologie Invasivität die Rede. Seinen Ursprung hat der Begriff in der Medizin. Zu Beginn der 1990er Jahre kam die minimal-invasive Chirurgie auf, welche Eingriffe ohne große Operationswunden anstrebt. Da im Bereich der integration dafür bisher keine einheitliche Begriffsdefinition besteht, wollten wir von 6 den Experten wissen, was sie darunter verstehen und anhand welcher Größen Invasivität gemessen werden kann. 2.2.8 Mainframefaktoren Entgegen gängiger Vorurteile sind Großrechner aus vielen Unternehmen nicht wegzudenken. Besonders in sicherheitskritischen Branchen und in Unternehmen mit großen Datenmengen sind Mainframes von entscheidender Bedeutung und müssen folglich auch integriert werden. Da bisher keine Untersuchungen existieren, die der Rolle von Mainframes in Integrationsprojekten nachgehen, betrachten wir diesen Aspekt in der Studie gesondert. Wir wollten von den Befragten wissen, welche Probleme diese Plattform in Integrationsprojekten aufwirft und wie letztendlich damit umgegangen wird. 2.3 Interviewleitfaden Um sicherzustellen, dass alle Fragen in jedem Interview in gleicher Reihenfolge gestellt werden, haben wir einen 34-seitigen Interviewleitfaden entwickelt. Die Fragen wurden in die folgenden sechs Abschnitten kategorisiert: demografische Basisdaten, Verständnis zum Thema Integration, Integrationsproduke / -werkzeuge / -hilfsmittel, Integrationsmuster und Automatisierung, Gewichtigkeit / Invasivität sowie das Integrationsobjekt Mainframe. Umrahmt wurden die Fragen durch einen anfänglichen Prolog sowie einen abschließenden Epilog. Einleitend wurden den Teilnehmern der Interviewverlauf und der ungefähre Zeitbedarf geschildert, als auch die Erlaubnis zur Aufzeichung gebeten. Im Epilog bot sich den Teilnehmern die Möglichkeit, Anmerkungen zum Interview zu geben, sowie weitere zusätzliche Teilnehmer vorzuschlagen. Um den Interviewteilnehmern die Möglichkeit zu geben, sich einen Überblick über die Fragen zu verschaffen, übersandten wir ihnen vorab den Leitfaden. Einige Teilnehmer waren dann zum Interviewtermin derartig gut vorbereitet, dass sie vorab Definitionen mit ihrem Firmen-Wording abstimmten. Während der Befragung notierte sich der Interviewleiter im Fragebogen handschriftliche Notizen. Zusätzlich wurde ein digitales Protokoll angefertigt. Beides floss in die spätere Transkription der Interviews ein. 2.4 Auswahl der Firmen Wir befragten ausschließlich Integrationsdienstleister, in der Annahme, dass sie aufgrund ihrer vielen durchgeführten Projekte, über hinreichende Erfahrungen in diesem Bereich verfügen. Ein solch umfangreiches Wissen ist von Anwendern einer Integrationslösung nicht zu erwarten, da die Integrationslösung typischerweise einmal – möglicherweise von einem Integrationsdienstleister – erstellt wird und dann fortwährend zum Einsatz kommt. Somit verfügen Anwender lediglich über spezifisches Lösungswissen aber nicht über breites Know-how, um verschiedenartige Integrationsprobleme zu lösen. 7 Um potentielle Integrationsdienstleister zu identifizieren, nutzen wir die Unternehmensdatenbank Hoppenstedt [Hop11], die ca. 85% der deutschen Wirtschaft abdeckt. Darüberhinaus wird die Geschäftstätigkeit der Unternehmen in dieser Datenbank redaktionell klassifiziert. Um sicherzustellen, dass die potentiellen Unternehmen über ein umfangreiches Erfahrungswissen verfügen, beschlossen wir Integrationsdienstleister ab einer Mitarbeiterzahl von 10 Personen zu befragen. In wenigen Fällen reichten die Angaben der Datenbank nicht aus (z. B. fehlende Firmengröße, Gründungsjahr oder Ansprechpartner) und wurden aus anderen Datenbanken manuell ergänzt. Insgesamt konnten 544 Unternehmen identifiziert werden, deren Fokus auf der Erbringung von Integrationsdienstleistungen liegt. Letztendlich wählten wir 35 Unternehmen für eine Befragung aus. Da in fünf Fällen der Expertenstatus der Befragten nicht gegeben war, bzw. ein gravierend anderes Integrationsverständnis vorherrschte, konnte die Auswertung nur für 30 Interviews durchgeführt werden. 2.5 Zeitliche Einordnung der Befragung Die Informationstechnologie ist eine der schnelllebigsten Industrien, die wir heute kennen. Um dem Leser eine Einordnung in unsere Forschungsbemühungen zu geben, erfolgt an dieser Stelle eine kurze Schilderung des zeitlichen Ablaufs. Im Frühjahr 2010 wurden die 544 identifizierten Integrationsdienstleister per E-Mail angeschrieben. Zur gleichen Zeit erfolgte der Pre-Test. Daraufhin wurde der Fragebogen geringfügig angepasst und die Terminvereinbarungen für die Befragungen begann. Zwischen März und August 2010 wurden schließlich die 35 Interviews vorrangig in den Räumen der Unternehmen durchgeführt. Daran schloss sich die Transkription der gesammelten 52 Stunden Audiomaterials an. Der Zeitbedarf erwies sich mit Faktor sechs als eine nicht zu vernachlässigende Größe. Die 553 DIN-A4 seitige Transkription wurde gemäß der angewandten Methode auf 378 Seiten reduziert. Zum jetzigen Zeitpunkt sind ca. zwei Drittel davon ausgewertet. 3 Erste Ergebisse In diesem Abschnitt geben wir erste Einblicke in die Resultate der Studie. Dieser Abschnitt ist für eine leichtere Lesbarkeit entsprechend den analysierten Variablen gegliedert. Auf diese Art kann unser Untersuchungsaufbau unkompliziert mit den Resultaten verglichen werden. 3.1 Unternehmensbezogene Faktoren Wie bereits eingangs beschrieben, adressieren wir Integrationsdienstleister aller Größen. Da wir jedoch davon ausgehen, dass erst ab einer bestimmten Unternehmensgröße eine hinreichend große Zahl an Projekten durchgeführt werden kann und die Experten genügend Erfahrungen sammeln konnten, beschränkten wir uns auf Unternehmen mit mehr als 10 Mitarbeitern. Abbildung 2 gibt einen Überblick über die Größe der befragten Integrationsdienstleister. Grundlage dieser Einord- 8 nung bildet der jährliche Umsatz und die Mitarbeiterzahl gemäß der KMU-Definition der Europäische Gemeinschaften [Eur06]. kleines Unternehmen 3 großes Unternehmen 17 mittleres Unternehmen 10 Abbildung 2: Größe der untersuchten Integrationsdienstleister Demnach fallen 90% der befragten Integrationsdienstleister in die Kategorien mittlere und große Unternhemen. Unsere These, dass das Anbieten von Integrationsdienstleistungen erst ab einer bestimmten Unternehmengröße interessant wird, scheint sich somit zu bestätigen. Gleichfalls sind zahlreiche befragte Unternhemen bereits seit vielen Jahren am Markt etabliert. Deren Gründungsjahre liegen zwischen 1964 und 2004. Um sicherzustellen, dass die Unternehmen auch über ein profundes Integrationswissen verfügen, fragten wir sie, seit wann sie sich mit Integration beschäftigen. Demnach sind mehr als 73% seit über 10 Jahren mit Integraionsthemen konfrontiert. Zusammenfassend handelte es sich bei allen Unternehmen ausnahmslos um erfahrene Integrationsdienstleister. Damit ebenfalls gewährleistet ist, dass sich die Integrationsdienstleister selbst auch als solche sehen, baten wir die Teilnehmer um eine Selbsteinordnung ihrer Tätigkeitsschwerpunkte in die vorgegebenen Kategorien: Integrationsdienstleister, Standardprodukthersteller, Anwender und Werk‐ zeughersteller. Die Ergebnisse (Abbildung 3) bestätigen unsere Firmenauswahl, da sich nahezu alle Teilnehmer als Integrationsdienstleister einordnen. Aufschlussreich sind auch die Eingruppierungen als Standardprodukt, bzw. Werkzeug und Hilfsmittelhersteller, welche auf produktbegleitende Dienstleistungen hinweisen. Anwender 4 Standardprodukthersteller 10 Integrationsdienstleister 29 Werkzeug‐ und Hilfsmittelhersteller 13 0 10 20 30 Selbsteinordnung (Mehrfachnennung möglich) Abbildung 3: Selbsteinordnung der Unternehmen In unseren Hypothesen haben wir die Ansicht vertreten, dass es je nach Branche Unterschiede im Maß des IT-Einsatzes zur Unterstützung der Geschäftstätigkeit gibt. Je nach Grad der ITDurchdringung unterscheidet sich demnach auch der Bedarf an Integrationsdienstleistungen (Banken und Versicherungen haben eine höhere IT-Durchdringung als Einzelhändler). Dieser Umstand 9 könnte wiederum dazu führen, dass sich Integrationsdienstleister ausschließlich auf besonders lukrative Branchen konzentrieren. Um dies zu überprüfen wurden die Interviewteilnehmer nach dem Branchenfokus Ihres Unternehmens befragt. Fast die Hälfte der Unternehmen (14 Integrationsdienstleister) bevorzugen Kunden einer speziellen Branche, wobei die Branchen divergieren. Die restlichen Unternehmen adressieren Schwerpunktbranchen (acht Integrationsdienstleister) oder haben keinen Branchenfokus (acht Integrationsdienstleister). Ausblick auf die Studie: Neben den besonderen Eigenschaften der verschiedenen adressierten Branchen, werden die Geschäftsmodelle der befragten Integrationsdienstleister näher erläutert. Ebenso werden die Phasen eines Integrationsprojektes mit den jeweiligen Ergebnissen, sowie das Rollenmodell der Integrationsdienstleister genauer analysiert. Letztendlich sind wir somit in der Lage ein ausführliches Vorgehensmodell für Integrationsdienstleister zu beschreiben. 3.2 Persönliche Faktoren Nachdem im vorangegangenem Abschnitt Angaben zum Unternehmen untersucht wurden, beschäftigt sich dieser Teil der Studie mit demographischen Faktoren der Interviewteilnehmern. Abbildung 4 veranschaulicht die Position der Studienteilnehmer in ihren Unternehmen. Darin wird sehr gut deutlich, dass die Mehrheit der Befragten im mittleren bzw. oberen Management verankert ist. Somit wurde die avisierte Zielgruppe von Personen mit leitender Tätigkeit weitgehend erreicht. Von allen 30 Teilnehmern nehmen vier die Rolle des des Geschäftsführers, Gesellschafters, Eigentümers oder Miteigentümers ein. Weitere 15 Interviewteilnehmer besetzen sonstige leitende Positionen (wie z. B. Bereichs-, Gruppen-, Abteilungs- oder Entwicklungsleiter). Diese hochrangige Teilnahme ist für uns ein Indiz für die Brisanz des Integrationsthemas. Geschäftsführung / Gesellschafter / Eigentümer / Miteigentümer 4 Entwicklungsleiter / Produktmanager 5 Bereichs‐/Gruppen‐/Abteilungsleiter 10 Berater 4 Integrations‐/Systemarchitekt 7 0 4 8 12 Antworten Abbildung 4: Verteilung der befragten Experten nach ihrer Position im Unternehmen Fast die Hälfte der Teilnehmer weist eine Unternehmenszugehörigkeit zum gegenwärtigen Unternehmen von über 10 Jahren auf (14 Teilnehmer). Die Befragten hatten im aktuellen Unternehmen und in vorangegangenen Positionen verschiedene Funktionen und Rollen inne und waren in verschiedenen Bereichen tätig. Dabei konnten sie viel praktisches Wissen sowie zahlreiche wertvolle und nützliche Erfahrungen sammeln. Letztendlich haben alle das Integrationsgeschäft von der Pike auf gelernt. 10 Der Ausbildungsweg der interviewten Experten war Gegenstand der Untersuchung, da ein einschlägiges Studium auf eine fundierte theoretische Wissensbasis hindeuten würde. Abbildung 5 zeigt eine grafische Darstellung der jeweils höchsten Abschlüsse der Befragten. Die Umfrageteilnehmer weisen ein breites Spektrum an akademischen und nicht-akademischen Abschlüssen auf. Lehre 3 Ausbildung (mit Informatik Bezug) Studium 14 Promotion 3 Lehre 5 Studium 4 Promotion 1 Quereinsteiger (ohne Informatik Bezug) 0 5 10 15 Antworten Abbildung 5: Höchster Abschluss der befragten Teilnehmer Insgesamt haben zwei Drittel eine Ausbildung mit IT-Bezug (wie z. B. Informatik, Wirtschaftsinformatik, Mathematik oder Fachinformatiker Systemintegration) durchlaufen. Einige von Ihnen besitzen sogar mehrere Hochschulabschlüssen. Gleichwohl, wird das restliche Drittel, welches über keine IT-bezogene Ausbildung verfügt (z. B. Elektrotechnik, Maschinenbau oder Germanistik), ihrem Expertenstatus ebenfalls gerecht, da nahezu alle Teilnehmer auf eine mehr als 10 jährige Erfahrung im Bereich Systemintegration zurückgreifen können. So schilderten zwei Personen, dass sie bereits seit über drei Jahrzehnten in diesem Bereich aktiv sind. Insgesamt beschäftigt sich die Mehrheit der Befragten (83%) seit über 10 Jahren mit Integrationsthemen. Ausblick auf die Studie: Das breite Spektrum der Teilnehmer bildet eine solide Basis um den einleitenden Hypothesen und Forschungsfragen nachzugehen. In der Studie wird die Gruppe der Befragten detaillierter betrachtet und genauer auf ihre jeweiligen Spezialisierungen eingegangen. 3.3 Kundenbezogene Faktoren Dieser Abschnitt betrachtet die typischen Kundensituationen, mit denen die befragten Integrationsdienstleister tagtäglich bei ihren Kunden konfrontiert werden. Zu Beginn werfen wir einen nähren Blick darauf, was die eigentliche Motivation der Kunden ist, Integrationsprojekte durchzuführen. In unseren Annahmen vermuten wir eine starke Abhängigkeit von der Branche sowie der IT-Durchdringung der Kunden. Im Folgenden stellen wir einen kleinen Ausschnitt unserer – im Übrigen bestätigten – Vermutungen vor. Je nachdem wie die Kunden strukturiert sind und wo die IT im Unternehmen angesiedelt ist, besteht eine unterschiedliche Sichtweise auf Integrationsprojekte. Branchen mit hoher IT-Durchdringung ihrer Wertschöpfung (z. B. Banken, Versicherungs- oder Telekommunikationssektor) betrachten ihre IT als Kerngeschäft. Entsprechend hoch sind die Chief Information Officer (CIO) in den Unternehmen angesiedelt (meist auf der Vorstandsebene). Deren gesamte Wertschöpfungskette ist in großem Maße von ihrer IT abhängig, da es sich in diesen Bereichen letztendlich 11 um rein virtuelle Produkte wie beispielsweise Anlagen, Kredite und Versicherungen handelt. Die Folgen eines Systemausfalls wären fatal. Aus diesem Grund sind Integrationsprojekte oft auf der Managementebene aufgehangen, wodurch die Ziele anders gewichtet sind als bei normalen Mittelständlern. Auch Unternehmen mit hoher IT-Durchdringung werden häufig mit der Herausforderung konfrontiert, sich schnell an geänderte Marktanforderungen, Gesetze und Kundenwünsche anpassen zu müssen. Eine schnelle Anpassung der Geschäftsprozesse bedeutet eine Anpassung der IT Systeme und damit auch der Integrationsarchitektur. Gerade in den wirtschaftlich angespannten letzten Jahren, wurde versucht die IT-Kosten zu verringern. Die einheitliche Meinung der Experten ist, dass dieser Kundenstamm zunehmend erkennt, dass der Weg zu einer größeren Zufriedenheit ihrer eigenen Kunden und effizienteren internen Prozessabläufen nicht ohne eine Integration der Anwendungssysteme erfolgen kann. Drei Experten schilderten, dass mit zunehmender Größe dieser Kunden eine stark segmentierte Aufstellung der IT vorzufinden ist. Da in den Unternehmen oftmals nur der Business Value der einzelnen Fachbereiche im Vordergrund steht, besitzt jeder Fachbereich eine auf diesen spezialisierte IT-Abteilung. Diese Spezialisierung liegt in der zunehmenden Komplexität der Produkte begründet, welche IT-technisch realisiert werden müssen. Demzufolge fehlt diesen Unternehmen oft ein einheitliches Gesamtbild ihrer IT-Landschaft. Weiterhin tragen frühere OutsourcingBemühungen, durch die viel Know How verloren gegangen ist, zu dieser Entwicklung bei. Ein anderes Bild ergibt sich bei mittelständischen Kunden. Vier Teilnehmer gaben an, dass in diesem Bereich vorrangig problemgetrieben gehandelt wird. Stehen diese Unternehmen vor der Herausforderung neue oder geänderte Geschäftsanforderungen abbilden zu müssen (z. B. wenn ein neuer Lieferant angebunden werden soll), dann besteht die Herausforderung der Integrationsdienstleister oft darin, die neuen Funktionalitäten in die bereits vorhandene IT-Infrastruktur zu integrieren. Somit sind Integrationsprobleme lediglich ein Baustein eines Gesamtproblems. Geht es nur darum, Prozesse durch Integration „schöner“ zu gestalten, sinkt die Bereitschaft der mittelständischen Kunden für zusätzliche Investitionen schnell. An dieser Stelle werden aus Platzgründen nur die fünf meistgenannten Kriterien vorgestellt, die bei den Kunden die Auswahl der Integrationslösung beeinflussen. Wie aus Abbildung 6 ersichtlich, hat der Kostenfaktor, gefolgt von der Flexibilität der Lösung sowie die Zeit bis zur Erstellung der Integrationslösung (time-to-market) den größten Einfluss. Die Mehrheit der Befragten gab an, dass Kosten ein wichtiger Faktor sind, wenn nicht gar der entscheidende. Kleine und mittelständische Unternehmen achten dabei besonders auf die anfallenden Projektkosten, wohingegen Unternehmen mit einer langfristigen und strategischen Ausrichtung (also vorzugsweise Unternehmen mit hoher IT-Durchdringung) auf die Gesamtkosten der Integrationslösung achten. Knapp ein drittel der Experten gab an, dass ihre Kunden auch sehr auf die Zeit achten, die für die Erstellung der Lösung beansprucht wird. Ergänzend veranschaulicht Abbildung 7 alle weiteren genannten Kriterien. Ausblick auf die Studie: Die kundenbezogenen Faktoren werden in der Studie im Detail untersucht. Folgende Themen spielen daher eine wichtige Rolle: Umgang der Integrationsdienstleister mit der mangelnden Investitionsbereitschaft des Mittelstandes. Wer trifft auf Kundenseite die Entscheidungen in Integrationsprojekten? Wie wird mit Wachstumsbestrebungen der Kunden umgegangen? Welche Rolle spielt das Management für Integrationsprojekte? Einige Standardprodukt, wie auch Werkzeug- und Hilfsmittelhersteller versuchen neue Wege der Benutzbarkeit ihrer 12 20 20 15 15 10 5 project costs 11 8 8 7 TCO Anzahl der Nennungen (Mehrfachnennung möglich) 25 0 1. Kosten 2. Flexibilität, Änderbarkeit, Skalierbarkeit 3. Zeit 4. 5. Betreib‐, Zuverlässigkeit, Bedienbarkeit Stabilität Abbildung 6: Top 5 die bei der Auswahl der Integrationslösung im Vordergrund stehen Produkte einzuschlagen. Wir gehen diesem Gedanken nach und schildern, wie die Lösung von Integrationsproblemen von einem reinen Programmierthema, hin zur Konfiguration ganzer Integrationsstrecken verlagert wird. Weiterhin wird in der Studie betrachtet, inwieweit die zukünftig zu erwartende Unternehmensentwicklung bei der Auswahl der Integrationslösung Berücksichtigung findet. Als Gegenpol zu den Rollen, welche auf Dienstleisterseite bei den unternehmensbezogenen Faktoren ermittelten wurden, werden geläufige Rollen auf der Kundenseite identifiziert. Ebenso werden auch Rollen aufgedeckt, die typischerweise bei Integrationsprojekten vernachlässigt, bzw. ganz vergessen werden. 3.4 Gewichtigkeit und Invasivität Integrationsprojekte sind ähnlich wie auch Softwareentwicklungsprojekte häufig mit zahlreichen technischen, unternehmerischen und politischen Herausforderungen konfrontiert. Sie verlangen von einer Integrationslösung neben eine sorgfältige Planung auch die nötige Agilität, um auf im Integrationsprojekt auftretende Veränderungen reagieren zu können. In der Softwareentwicklung hat diese offensichtliche Dichotomie zwischen sorgfältiger Planung und und der Bestrebung mögliche Veränderungen abzufangen, viele Diskussionen hervorgerufen. In diesem Bereich begegnete man dieser Problematik mit agilen, oder auch leichtgewichtig genannten Vorgehensmodellen z. B. Adaptive Software Development, Extreme Programming oder SCRUM. Genau diese agilen, leichtgewichtigen Softwareentwicklungsmethoden bilden das Fundament, derartige Paradigmen auch im Integrationskontext zu untersuchen, da die Herausforderungen beider Bereiche sehr ähnlich sind. Ein weiterer wichtiger Aspekt im Integrationskontext ist die Veränderung von Integrationsobjekten. Unterscheidungen können diesbezüglich zwischen invasiven und nicht-invasiven Vorgehen getroffen werden [Fin99]. Im angloamerikanischen Sprachgebrauch wird diese Unterscheidung auch oft als „intrusive integration“ und „non-intrusive integration“ bezeichnet. Das grundlegende Verständnis eines nicht-invasiven Ansatzes besteht darin, das Anwendungssysteme verknüpft wer- 13 Anzahl der Nennungen (Mehrfachnennung möglich) 7 6 6 5 5 5 5 4 4 4 3 3 3 2 2 2 1 1 1 0 Abbildung 7: Weitere Kriterien die die Auswahl der Integrationslösung beeinflussen den, ohne dass die Notwendigkeit besteht, diese ändern oder erweitern zu müssen. Der Aspekt der Invasivität gewinnt besonders im Kontext von Großrechnersystemen und Legacy-Anwendungen an Bedeutung, da in diesem Bereich die Veränderung von Integrationsobjekten häufig ausgeschlossen ist (3.5). Da keine befriedigende Definition zu den Begriffen Gewichtigkeit und Invasivität existiert, versuchen wir zu klären, was in der Praxis darunter verstanden wird und wie letztendlich damit umgegangen wird. Eingangs wollten wir von den Teilnehmern wissen, ob ihnen eine Unterscheidung zwischen leicht- und schwergewichtigen Vorgehen im Integrationskontext bekannt ist. Wie Abbildung 8 zeigt, ist mehr als drei Viertel der Befragten diese Unterscheidung geläufig. sind nicht bekannt, nie gehört 6 ist bekannt 24 Abbildung 8: Unterscheidung leicht- und schwergewichtiger Integrationsvorgehen Um unser Begriffsverständnis zu schärfen, fragten wir die 24 Experten, die mit diesem Ausdruck vertraut sind, welche charakteristischen Eigenschaften sie mit leichtgewichtigen Integrationsansätzen verbinden (Abbildung 9). Die Mehrzahl der Befragten sieht ein inkrementelles und iteratives Vorgehen als wichtige Eigenschaft der Leichtgewichtigkeit. Sie schilderten uns, dass eine Ursache darin liegt, dass eine sog. Big-Bang-Integration [BNM10] meistens nicht gelingt. Ein inkrementelles und iteratives 14 inkrementelles und iteratives Vorgehen 13 (exploratives) Prototyping 9 kurze Zyklen 7 verzicht auf langwierige Planungsphase 6 Problemlösung in einem eingegrenzten Bereich 5 0 5 10 Antworten (Mehrfachnennung möglich) 15 Abbildung 9: Charakteristische Eigenschaften leichtgewichtiger Integrationsvorgehen Vorgehen wurde mit mehreren Argumenten begründet. Die Reduktion der Gesamtkomplexität ist eine davon. Um auch unter komplexen Rahmenbedingungen optimale Integrationsergebnisse zu erreichen, wird das Gesamtprojekt in verschiedene Phasen aufgeteilt. Diese Phasen werden in mehreren Schleifen nacheinander durchlaufen, sodass man sich durch verschiedene Inkremente (Teilintegrationen) mit jeder Schleife an das angestrebte Integrationsziel annähert. Gelingt es, einen kontinuierlichen Verbesserungsprozess zu etablieren, so verbessert sich mit jeder neuen Schleife auch die Integrationslösung. Wie bereits in der Einleitung zu diesem Abschnitt dargestellt, beschäftigt sich die Studie auch mit dem Thema Invasivität. Von den 30 Befragten ist 28 diese Begrifflichkeit im Integrationskontext geläufig (Abbildung10). nie gehört, nicht bekannt 2 ist bekannt 28 Abbildung 10: Bekanntheit des Invasivitätsbegriffs im Integrationskontext Analog zum Gewichtigkeitsbegriff, baten wir die Experten, uns genauer zu beschreiben, was sie unter Invasivität verstehen. Letztendlich kann Invasivität auf verschiedenen Ebene auftreten. So beschrieben uns 26 Teilnehmer Invasivität auf technischer Ebene (z. B. durch Veränderungen im Code der Integrationsobjekte oder durch hinzufügen neuer Systeme). Außerdem beschrieben 18 Befragte, wie Invasivität auch auf Geschäftsprozessebene auftreten kann. Hier liegt die Invasivität in der Veränderung von Geschäftsprozessen und Arbeitsabläufen begründet, was zu gravierenden Akzeptanzproblemen führen kann. Weiterhin beschrieben neun Personen Invasivität auf organisatorischer Ebene. Damit verbunden sind Veränderungen von Ablauf- und Organisationsstrukturen und letztendlich der Härtegrad, mit welchen man sich im Organismus des Kunden bewegt (z. B. einfaches Abschalten alter Systeme gegenüber einem gleitenden Übergang). Ausblick auf die Studie: Die Verständlichkeit der Begriffe Invasivität und Gewichtigkeit werden in der Studie weiter geschärft. Neben Vor- und Nachteilen von Lösungen mit besonders geringer Invasivität, werden auch Möglichkeiten aufgezeigt, wie Integrationslösungen möglichst leichtge- 15 wichtig entstehen können. Abgerundet wird dieser Fragenkomplex mit dem Aufzeigen möglicher Metriken um Invasivität und Gewichtigkeit zu messen. 3.5 Das Integrationsobjekt Mainframe In dieser Studie bilden Mainframefaktoren eine eigene Untersuchungsvariable, da diese Systeme unserer Auffassung nach besondere Integrationsobjekte darstellen. Aufgrund ihrer Zuverlässigkeit, Leistungsfähigkeit, Sicherheit und Unabkömmlichkeit sind sie weit davon entfernt, als Dinosaurier der IT abgestempelt zu werden [Ste08]. Vertreter dieser Gattung sind beispielsweise neben den IBM /360, /370 und zSeries Systemen, auch HPs Superdome oder Fujitsu Siemens’ BS/2000 Systeme [HKS04]. Entgegen der weitläufigen Annahme sind sie aus der betrieblichen Anwendungslandschaft nicht mehr wegzudenken. Glaubt man den Spezialisten, so befinden sich gegenwärtig zwischen 60 und 70% der weltweiten Geschäftsdaten auf diesen Maschinen [HKS04]. Für gewöhnlich laufen darauf geschäftskritische Anwendungen von Banken, Versicherungen, Versorgungsunternehmen, Behörden und einer Vielzahl anderer öffentlicher und privater Unternehmen [EKOO09]. Manche dieser – oft auch als Legacy Anwendungen bezeichneten – Applikationen sind bereits seit 10, 20 oder mehr Jahren im Einsatz. Daher sind sie oft in Programmiersprachen wie Cobol, JCL oder PL/I geschrieben. Im Laufe der Jahre wurden sie ständig verändert, sodass sich neue Modifikationen zunehmend schwerer gestalten. Diese Anwendungen können deshalb nicht einfach ersetzt werden, da dies mit hohen Kosten und Risiken behaftet ist. Die Weiterverwednung und Integration sind unausweichlich. Das gab den Ausschlag, Integrationsprobleme dieses Bereichs separat zu untersuchen. Als erstes wollten wir von den Integrationsdienstleistern wissen, wer von ihnen in seinem täglichen Integrationsgeschäft mit Mainframes konfrontiert ist (Abbildung11). Die Hälfte der Integrationsdienstleister (15) trifft oft bei Integrationsprojekten auf diese Systeme. Demgegenüber stehen acht Integrationsdienstleister, die nie Kontakt mit diesen Maschinen hatten. Der Rest der Befragten wird nur selten oder indirekt (Mainframe dient nur als Datenlieferant) vor diese Herausforderung gestellt. Zusammenfassend lassen die Ergebnisse den Schluss zu, dass vorzugsweise große mittelständische sowie große Integrationsdienstleister mit Mainframes und ihren speziellen Problemen konfrontiert sind. häufig selten 2 2 1 nur indirekt nie 9 5 1 1 1 1 kleines Unternehmen 2 mittleres Unternehmen 5 großes Unternehmen Abbildung 11: Konfrontation der befragten Integrationsdienstleister mit Mainframes 16 Zusammenfassend formuliert liegen die Probleme beim Umgang mit diesem Integrationsobjekt vor allem bei: fehlenden Schnittstellen, einem monolithischen Aufbau, unzeitgemäßem Programmierstil, ausgelasteten Mainframeabteilungen, nebulösen Verantwortlichkeiten, dem Fachkräftemangel oder in einer schlechten Dokumentation. Die Invasivität der Integrationslösung gewinnt in diesem Zusammenhang an besonderer Bedeutung. Da die zu integrierenden Anwendung für die Kunden einen gewissen Wert darstellen, sollen sie möglichst nicht, oder nur minimal verändert werden. Ein häufig diskutiertes Thema bei der Mainframeintegration ist eigentlich kein echtes Integrationsthema, sondern eher eines, welches zu Integrationsfragen führt. Auf Grund der Kostenproblematik des Mainframes steht das Thema Right-Sizing gegenwärtig im Vordergrund. Für welche Aufgabenstellungen ist der Mainframe notwendig – Stichwörter an der Stelle sind große Datenmengen, hohe Transaktionsszahlen, Ausfallsicherheit und Desaster-Recovery – und an welchen Stellen lässt sich eine gefahrlose Verlagerung von Funktionalität auf andere Systeme erreichen (bei denen z. B. Entwicklerressourcen nicht so knapp sind, wie im Mainframebereich)? Eine weiterer wichtiger Gesichtspunkt liegt in der zukünftigen Perspektive dieser Systeme. Daher fragten wir die 22 Teilnehmer, die mehr oder weniger oft mit diesen Maschinen zu tun hat, ob ihre Kunden über eine Ablösung dieser Systeme diskutieren. Schließlich ergab sich, dass zwar nahezu alle darüber diskutieren, aber nur sehr wenige es tatsächlich in die Tat umsetzen. Denn eine Vielzahl von Faktoren spricht dagegen: Kritikalität, Stabilität und Zuverlässigkeit sowie Komplexität und Aufwand der Ablösung. Ein Teilnehmer schilderte uns, dass Vorbehalte gegenüber Mainframes oft durch junge Manager hervorgerufen werden. Die heutigen IT-Leiter haben vor 10 oder 15 Jahren ihr Studium abgeschlossen. Da die Mainframesystemarchitektur inzwischen an nahezu allen Universitäten nicht mehr gelehrt wird, keine Kenntnisse über Mainframes vor, was die Vorteile der Systeme einschließt. Ausblick auf die Studie: Wir untersuchen detailliert, welche Integrationsdienstleister in welchen Branchen auf das Integrationsobjekt Mainframe treffen. Ebenso werden die in diesem Zusammenhang auftretenden Probleme, Lösungen und Werkzeuge näher untersucht. Abschließend werden Vor und Nachteile der Mainframes beleuchtet, sowie die Überlegungen reflektiert, die viele Kunden im Zusammenhang mit einer Ablösung tätigen. 3.6 Bis dato nicht ausgewertete Variablen und Korrelationen Wie bereits erläutert beschreibt dieser Beitrag die bis dato ausgewerteten Variablen. Die folgende Aufzählung legt dar, welche Bereiche noch auszuwerten sind. • Produktportfolio-Variable: Welche Werkzeuge und Hilfsmittel benutzen die Integrationsdienstleister? Gibt es firmeninterne Werkzeuge und Hilfsmittel, die für Integrationsprojekte eingesetzt werden. Was sind die Alleinstellungsmerkmale der verwendeten Produkte? • Wiederholbarkeits-Variable: Existieren wiederkehrende Integrationsprobleme? Welche Methoden und Werkzeuge werden verwendet um damit umzugehen? Wie erfolgt die Do- 17 kumentation? Letztendlich zielen wir mit dieser Untersuchungsvariable darauf ab, hochstehende Integrationsmuster abzuleiten. • Integrationsverständnis-Variable: Das Integrationsverständnis ist sehr heterogen, jedoch von essentieller Bedeutung für unsere Studie. Da wir uns durch diese Variable ein besseres Integrationsverständnis von den Teilnehmern verschaffen konnten, waren wir in der Lage, die Fragen im Interview besser zu unterlegen und die Teilnehmer mit ihrem Verständnis einzubeziehen. Im Epilog hoben einige Teilnehmer dies als äußerst positiv hervor. • Korrelationen: Sobald die Auswertung aller Untersuchungsvariablen abgeschlossen ist, werden verschiedene Korrelationen zwischen den Variablen gezogen und die Studie abgerundet. 4 Zusammenfassung Auch wenn die Studie zum gegenwärtigen Zeitpunkt nicht vollständig ausgewertet ist, lassen sich weitergehende Forschungsfragen mit Praxisbezug ableiten. So hat sich gezeigt, dass Integration eine Dienstleistung ist, welche von Integrationsdienstleistern erbracht wird. Weiterer Forschungsbedarf besteht dahingehend, beispielsweise die Ergebnisse der Service-Science und des Service-Engineerings – insbesondere der Servicemodellierung [BK11] – einzubeziehen. Gemeinsam mit den Ergebnissen aus der Studie würde sich somit die Möglichkeit ergeben, ein Service-Referenzmodell für Integrationsdienstleistungen zu definieren. Somit wird eine systematische Planung, Durchführung und Anpassung von Integrationsdienstleistungen aus technischer, Dienstleister- sowie Kundensicht ermöglicht. Integration findet immer in einer gewachsenen Architektur statt und ist letztendlich die Veränderung der Unternehmensarchitektur von einem Zustand in einen anderen. Der Forschungsbereich der Unternehmensarchitektur stellt Methoden und Werkzeuge bereit, um Architekturen zu beschreiben und zu planen. Im Hinblick auf die von den Interviewteilnehmern geschilderte Analysephase, könnten Unternehmensarchitekturmodelle die Basis für eine automatische Integrationsanalyse bilden. Ebenfalls können die Definitionen von Gewichtigkeit und Invasivität, sowie die zugrunde liegenden Metriken, verwendet werden, um besonders leichtgewichtige und minimal-invasive Integrationskonzepte zu beschreiben. Weiterhin zeichnt sich ab, dass Cloud-Computing basierte Integrationslösungen bisher kaum eruiert wurden. Eine Vermeherte Nutzung dieses Prinzips für geschäftliche Anwendungen führt jedoch eine herkömmliche Integration ad absurdum. Besonders der Migration zwischen herkömmlichen und cloud-basierten Integrationsplattformen wird beachtung zu schenken sein. Da die Studie auf den deutschen Raum limitiert war, ist deren Aussagekraft eingeschränkt. Zur Erhöhung der Repräsentativität, sollten ähnliche Untersuchungen in anderen Ländern erfolgen. 18 Literatur [BK11] Boettcher, Martin ; Klingner, Stephan: The Basics and Applications of Service Modeling. In: Annual SRII Global Conference (2011) [BNM10] Bygstad, B. ; Nielsen, P.A. ; Munkvold, B.E.: Four integration patterns: a socio-technical approach to integration in IS development projects. In: Information Systems Journal 20 (2010), Nr. 1, S. 53–80 [CDV08] Chen, D. ; Doumeingts, G. ; Vernadat, F.: Architectures for enterprise integration and interoperability: Past, present and future. In: Computers in Industry 59 (2008), Nr. 7, S. 647–659 [EKOO09] Ebbers, M. ; Kettner, J. ; O’Brien, W. ; Ogden, B.: Introduction to the New Mainframe: z/OS Basics. IBM, 2009 (IBM Redbook SG24-6366-01). http://www.redbooks.ibm.com/ abstracts/sg246366.html [Eur06] Europäische Gemeinschaften: Die neue KMU-Definition. (2006), 52. http://ec.europa. eu/enterprise/policies/sme/files/sme_definition/sme_user_guide_de.pdf [Fin99] Fincham, Martin: Application integration: to invade ... or not to invade? In: MiddlewareSpectra (1999), 22-27. http://www.mitem.com/resources/analyst/MidSpecToInvade.pdf. – ISSN 1356–9570 [GL09] Glaeser, J. ; Laudel, G.: Experteninterviews und qualitative Inhaltsanalyse: Als Instrumente rekonstruierender Untersuchungen. VS Verlag, 2009 [HKS04] Herrmann, P. ; Kebschull, U. ; Spruth, W. G.: Einfuehrung in z/OS und OS/390. 2., korrigierte Auflage. Muenchen : Oldenbourg, 2004. – ISBN 3–486–27393–0 [Hop11] Hoppenstedt: Version: 2011 [HW03] Hohpe, Gregor ; Woolf, Bobby: Enterprise integration patterns: Designing, building, and deploying messaging solutions. Boston, MA, USA : Addison-Wesley Professional, 2003. – ISBN 0321200683 [LF02] Lublinsky, Boris ; Farell, Michael J.: Top 10 Reasons why EAI fails. In: EAI Journal (2002) [LS04] Lam, Wing ; Shankararaman, Venky: An Enterprise Integration Methodology. In: IT Professional 06 (2004), Nr. 2, S. 40–48. – ISSN 1520–9202 [MA08] Moll, J.H. ; Ammerlaan, R.W.M.: Identifying Pitfalls of System Integration – An Exploratory Study. In: Software Testing Verification and Validation Workshop, IEEE International Conference on 0 (2008), S. 332–338. ISBN 978–0–7695–3388–9 [May04] Kapitel QuaIitative Content AnaIysis. In: Mayring, Phillip: A companion to qualitative research. Sage Publications Ltd, 2004, S. 266 – 269 [PM08] Panetto, Hervé ; Molina, Arturo: Enterprise integration and interoperability in manufacturing systems: Trends and issues. In: Computers in Industry 59 (2008), Nr. 7, 641 - 646. http://www.sciencedirect.com/science/article/B6V2D-4SJ9504-1/2/ bc0c65595577f763181899d3874c16bb. – ISSN 0166–3615. – Enterprise Integration and Interoperability in Manufacturing Systems [PPS07] Purao, S. ; Paul, S. ; Smith, S.: Understanding enterprise integration project risks: A focus group study. In: Database and Expert Systems Applications, 2007. DEXA’07. 18th International Conference on, 2007, S. 850–854 Hoppenstedt Firmeninformationen. http://www.hoppenstedt.de/. 19 [SOO10] Schmidt, A. ; Otto, B. ; Oesterle, H.: Integrating information systems: case studies on current challenges. In: Electronic Markets (2010), S. 1–14. – ISSN 1019–6781 [Ste08] Stephens, D.: What On Earth is a Mainframe? Longpela Expertise, 2008. – ISBN 978–1–4092– 2535–5 [Sum00] Sumner, Mary: Risk factors in enterprise wide information management systems projects. In: SIGCPR ’00: Proceedings of the 2000 ACM SIGCPR conference on Computer personnel research. New York, NY, USA : ACM, 2000. – ISBN 1–58113–212–X, S. 180–187 [TI06] Themistocleous, M. ; Irani, Z.: Towards a methodology for the development of integrated IT infrastructures. In: Proceedings of the 39th Hawaii International Conference on System Sciences (2006) [WH07] Wilde, T. ; Hess, T.: Forschungsmethoden der Wirtschaftsinformatik. In: Wirtschaftsinformatik 49 (2007), Nr. 4, S. 280–287 20 Problemadäquate Klassifikation und Systematisierung von Integrationsmustern Martin Gebauer, Johannes Schmidt Universität Leipzig, Institut für Informatik, Abteilung Betriebliche Informationssysteme Johannisgasse 26 04103 Leipzig {gebauer | jschmidt}@informatik.uni-leipzig.de Kurzfassung: Integrationsdienstleister stehen vor der Aufgabe, für unterschiedliche Kunden gleiche oder ähnliche Integrationsoperationen durchführen zu müssen. Integrationsmuster könnten diesen Anbietern helfen, methodisches und technisches Wissen aus bereits erfolgreich abgeschlossenen Integrationsprojekten auf ähnlich gelagerte Aufgabenstellungen zu übertragen. Eine Studie der Universität Leipzig hat jedoch gezeigt, dass diese Art der Wiederverwendung in der Praxis kaum Anwendung findet. Dies ist u. a. auf die große Anzahl und eine bislang fehlende praxisorientierte Systematisierung der Muster zurückzuführen. Dieser Beitrag möchte die Verwendung von Mustern im Rahmen von Integrationsprojekten motivieren. Dazu wird der Begriff des Integrationsmusters diskutiert und verschiedene Ansätze zur Klassifikation derartiger Muster vorgeschlagen. 1 Motivation Integrationsdienstleister geraten – bedingt durch Kundenwünsche – zunehmend unter Kosten- und Zeitdruck und müssen Integrationslösungen in immer kürzeren Zyklen entwickeln. Daraus resultieren Anstrengungen, die Erstellung von Integrationslösungen zu rationalisieren. In den Wirtschaftswissenschaften können zwei Arten der Rationalisierung unterschieden werden. Die eine ist die tayloristische Betrachtung im Sinne der Optimierung von Bewegungsabläufen. Auf der anderen Seite kann Rationalisierung auch aus Investitionssicht betrachtet werden. Dabei steht die Ablösung des Menschen durch eine Maschine im Vordergrund. Der Prozess einer Integration, den wir im Weiteren als Integrierung nach Thränert bezeichnen, kann nur schwer mit Bewegungsabläufen verglichen werden. Bei einer weiten Auslegung des tyloristischen Rationalisierungsbegriffes können Vorgehensmodelle als derartige Optimierungen interpretiert werden, da sie die notwendigen Schritte und deren Reihenfolge festlegen. Eine wesentlich größere Bedeutung haben die investitionsgetriebenen Überlegungen, welche prüfen, ob eine Automatisierung effizienter ist als eine manuelle Lösung. Insbesondere im Software Engineering haben sich mit der Generierung von Software derartige Ansätze herausgebildet. Eine abgeschwächte Form der Automatisierung ist die Verwendung einer Blaupause einer Lösung für ein vorliegendes Problem. Dieser Ansatz soll den individuellen Lösungsentwurf in einen strukturierten Lösungsentwurf – unter der Verwendung vorgefertigter Lösungsschemata – überführen. Gängige Mittel, welche wiederkehrende 21 Problemlösungen konservieren und dadurch den Grad der Wiederverwendung erhöhen und gleichzeitig Effizienzgewinne versprechen, sind Muster und Referenzarchitekturen. Im Bereich der Softwareentwicklung sind Muster – insbesondere Entwurfs- und Architekturmuster – ein anerkanntes Mittel der Wiederverwendung. Bei der Erstellung von Integrationslösungen haben sie sich jedoch nicht durchgesetzt, was auf der Basis einer Studie der Universität Leipzig nachgewiesen werden kann. Die Ergebnisse der Untersuchung zeigen, dass Muster den Integrationsdienstleistern zwar – häufig auf Grund einer IT-Ausbildung – bekannt sind, jedoch nicht bewusst eingesetzt werden. Daraus kann geschlussfolgert werden, dass der Zusammenhang zwischen Analyse der Problemstellung, Identifikation eines geeigneten Musters und der letztendlichen Implementierung des Musters – also der Abbildung in konkrete Lösungen – nicht hergestellt wird. Dieser Beitrag geht davon aus, dass es sich dabei um ein Problem des Zuganges zu vorhanden Mustern handelt. Diese sind in der Literatur bekannt, aber verstreut über eine große Menge an Publikationen. Darüber hinaus sind ähnliche Muster – besser Lösungsalternativen – auf Grund der unterschiedlichen Darstellungen in den verschiedenen Publikationen nicht als solche zu erkennen. Deshalb wird in diesem Beitrag zunächst eine Definition von Integrationsmustern entwickelt, welche geeignet ist, Integrationsmuster zu identifizieren, auch wenn diese nicht als solche ausgewiesen sind. Unter Nutzung dieser Definition wird anschließend eine Auswahl an Mustern auf Basis der vorhandenen Literatur zusammengestellt. Diese dient als Grundlage, um eine Klassifikation der Muster zu entwickeln, welche einen besseren Zugang und die Erkennbarkeit von Lösungsalternativen gewährleistet. Da es sich bei einer Klassifikation um eine Art der Abstraktion handelt, kann der vorliegende Beitrag auch als ein Ansatz zur Entwicklung abstrakterer – hochstehender – Integrationsmuster gewertet werden. 2 Grundlagen Betrachtungsgegenstand dieser Arbeit sind Integrationsmuster zur Unterstützung von Integrationsdienstleistern bei der Integrierung von betrieblichen Informationssystemen. Dieser Abschnitt gibt zunächst einen Überblick zum Integration Engineering. Anschließend wird eine Definition des Begriffs Integrationsmuster hergeleitet und diskutiert. Abschließend werden prinzipiell geeignete Ordnungssysteme beschrieben, die in Kapitel 3 für die Ordnung der Integrationsmuster eingesetzt werden. 2.1 Integration betrieblicher Informationssysteme Betriebliche Informationssysteme stellen den Rahmen der Betrachtungen in diesem Beitrag dar, wobei eine systemtheoretische Sichtweise vertreten wird, welche in diesem Zusammenhang nicht ungewöhnlich ist (vgl. [Thr08, Fis08]). Ein betriebliches Informationssystem umfasst demnach alle Informationssysteme eines wirtschaftlichen Betriebes. Ein Informationssystem umfasst nach Gabriel im engeren Sinne „ein computergestütztes Anwendungssystem, d. h. ein Programmsystem zur Ausführung betrieblicher Aufgaben“ [Gab08]. Im weiteren Sinn werden Menschen und 22 die für die Ausführung der Anwendungssysteme notwendige Hardware mit unter diesen Begriff subsummiert (vgl. [Gab08]). Die Ausführung der Geschäftsprozesse oder der untergeordneten Teilfunktionen wird verschiedenen ausführenden Einheiten – Aufgabenträgern – zugewiesen. Handelt es sich bei diesen Aufgabenträgern um Anwendungssysteme, so kann es sein, dass zwischen diesen Integrationsbeziehungen zu realisieren sind. Dies ist immer dann der Fall, wenn die Abwicklung der Aufgaben ein Überschreiten der Systemgrenzen notwendig macht. Das Themengebiet der Integration befasst sich mit dem dazu notwendigen Handwerkszeug. In der Vergangenheit standen dabei oft technische Lösungen für spezifische Probleme im Vordergrund, weshalb häufig bemängelt wurde, dass es kein methodisches Vorgehen gibt, welches bei der zielgerichteten Auswahl einer Lösungsstrategie hilfreich ist. Das Integration Engineering (IE) ist bemüht, ein derartiges Vorgehen mit zugehörigen Werkzeugen und Methoden im Sinne einer Ingenieurswissenschaft zu liefern. Für Industrieunternehmen ist es ökonomisch nicht sinnvoll, Wissen über die Erstellung von Integrationslösungen aufzubauen. Aus der Sicht des Industrieunternehmens gibt es nach der Lösung des Integrationsproblems keine Verwendung für diese Spezialkenntnisse mehr. Im Vergleich zum Einkauf einer Dienstleistung ist die Lösung auf Basis eigener Ressourcen vergleichsweise unrentabel. Diese Nachfrage hat dazu geführt, dass sich hochspezialisierte Integrationsdienstleister am Markt etablieren konnten. Für diese stellt das Lösen von Integrationsproblemen den Kern ihrer Geschäftstätigkeit – und damit eine wiederkehrende Aufgabe – dar. 2.2 Integrationsmuster Muster – im Englischen Patterns genannt – haben ihren Ursprung in den Arbeiten von Christopher Alexander, welcher sie verwendete, um erprobte Lösungen für eine bautechnische Architektur zu konservieren. Mit den Arbeiten zu Entwurfsmustern wurde dieses Konzept unter anderem von Gamma et al. auf die Softwareentwicklung übertragen (vgl. [GHJV95]). Neben einer Vielzahl an Mustern in unterschiedlichen Bereichen der Informatik gibt es auch Referenzarchitekturen (vgl. [EHH+ 08, EV08]) oder Architektur-Blaupausen (vgl. [LSL+ 08]), welche einen analogen Effizienzsteigerungsansatz verfolgen. In den folgenden Betrachtungen werden wir uns auf das Konzept der Muster beschränken. Diese werden auf einem bestimmten Abstraktionsniveau als Ausschnitte einer Architektur gesehen und können zu vollständigen Architekturen kombiniert werden. Damit ist zu erwarten, dass sich die Ergebnisse dieser Arbeit auf Referenzarchitekturen übertragen bzw. mit diesen kombinieren lassen. In einem ersten Schritt soll nachfolgend eine Definition für Integrationsmuster hergeleitet werden, welche explizit die qualifizierenden Merkmale dieser Musterart berücksichtigt. Ziel ist es, auf der Basis einer Definition möglichst auch diejenigen Muster als Integrationsmuster zu identifizieren, die nicht explizit als solche charakterisiert sind. Dazu soll die Prüfung der Existenz der entsprechenden Merkmale herangezogen werden. Im Rahmen einer Literaturanalyse wurden zahlreiche Definitionen untersucht, welche hier aus Platzgründen nicht im Einzelnen vorgestellt werden können. Stattdessen konzentrieren wir uns auf die extrahierten Merkmale. 23 Die Art der Elemente, welche in einem Integrationsmuster enthalten sind, werden wie folgt beschrieben. Der wesentliche Gegenstandsbereich der Integrationsmuster sind Komponentenarchitekturen (vgl. [EV08]). Damit wird implizit eine Grundvoraussetzung für die Notwendigkeit von Integration, die Verteilung, benannt. In den Musterbeschreibungen werden neben Integrationsmustern noch domainspezifische bzw. Business-Komponenten unterschieden (vgl. [Mul95, S. 443], [AKGV01]). Im Gegensatz zu den Business-Komponenten automatisieren Integrationsmuster keinerlei Geschäftsfunktionalität ([AKGV01], [ZMAV08, S. 1273]). Die Relationen der Elemente zueinander lassen sich aus dem Beschreibungsumfang eines Integrationsmusters ablesen, welcher das Verhalten der beschriebenen Komponenten enthalten muss, sowie deren Beziehungen untereinander, als auch die relative Positionierung in der Architektur (vgl. [Mul95, S. 443]) darlegen soll. Der Abstraktionsgrad von Integrationsmustern wird derart charakterisiert, als dass derartige Muster erprobte Lösungen für Integrationsprobleme (vgl. [JLSJ07, S. 52]), welche auch als Integrationskonflikte (vgl. [Mul95, S. 443] bezeichnet werden, darstellen. Die Granularität der Beschreibung wird widersprüchlich charakterisiert. Integrationsmuster werden auf der einen Seite als Architekturmuster bezeichnet (vgl. [Mul95, S. 443]), auf der anderen Seite aber auch als Standard-Integrationsarchitekturen (vgl. [EV08]). Da Integrationsmuster als Vertreter der Musterart Architekturmuster beschrieben werden, wurden in einem zweiten Schritt Definitionen von Architekturmustern untersucht, um weitere charakteristische Merkmale zu extrahieren. Auch hier stellen wir nur die extrahierten Merkmale vor. Ein Architekturmuster beinhaltet als Bestandteile sogenannte Architekturelemente (vgl. [Fie00, S. 13]), welche Rechenkomponenten oder einfach Komponenten (vgl. [GS93, S. 2]) darstellen. Komponenten können von unterschiedlicher Granularität sein, weshalb zu den vermutlich atomaren Komponenten noch vordefinierte Subsysteme (vgl. [BMR+ 96]) und Konnektoren (vgl. [GS93, S. 2]) gezählt werden. Mit dieser Eigenschaft wird die Parallelität zu den oben angeführten Eigenschaften von Integrationsmustern deutlich, wobei die Definitionen der Integrationsmuster die Art der Komponenten präziser eingeschränkt haben. Eine weitere Parallelität wird durch die Aussage deutlich, dass das Wesen eines Architekturmusters darin besteht, die strukturelle Organisation eines Systems in Form eines Schemas zu konservieren (vgl. [GS93, S. 2], [GAO95, S. 180], [BMR+ 96], [Has06, S. 48]). Diese Aussage steht in perfekter Übereinstimmung mit der Definition eines Integrationsmusters, welches die Komponenten, deren Beziehungen untereinander und die relative Positionierung in einer Architektur darlegen soll. Dies kann als weiterer Nachweis der Tatsache gewertet werden, dass es sich bei Integrationsmustern um Architekturmuster handelt. Die Beziehungen untereinander werden im Fall von Architekturmustern als die Beschreibung der Kombinationsmöglichkeiten der Elemente genannt. Dabei werden Restriktionen in Form von Rollen, Eigenschaften und den zwischen den Elementen erlaubten Beziehungen festgelegt (vgl. [GS93, S. 2], [Fie00, S. 13], [BMR+ 96]). Ein Architekturmuster beschreibt keine Lösung eines singulären Problems, sondern eine Lösung für eine Familie von Applikationen (vgl. [GAO95, S. 180]). Es wird also ein prinzipieller Lösungsansatz (vgl. [Fac09]) für Probleme dargestellt, die mehrfach vorkommen (vgl. [Heu07, S. 8]). Da wir aus den bisherigen Ausführungen Integrationsmuster auf eine Abstraktionsebene mit Architekturmustern gestellt haben, ist der Zusammenhang zu anderen Mustern interessant. Diesen 24 stellen Winter et al. her. Architekturmuster werden in einer Hierarchie eingeordnet, in der Entwurfsmuster eine einzelne objektorientierte Anwendung, Architekturmuster die Komposition von Komponenten zu Anwendungen und wiederum Architekturmuster für Unternehmensanwendungen die Vernetzung von Anwendungen (vgl. [WBF+ 09, S. 536]) beschreiben. Bisher konnten die Schlussfolgerungen gezogen werden, dass es sich bei Integrationsmustern um Architekturmuster handelt und dass ein Integrationsmuster und demzufolge auch ein Architekturmuster einen Ausschnitt oder eine vollständige Integrationsarchitektur beschreibt. Deshalb wird im Folgenden der Gestaltungsgegenstand, also Definitionen von Integrationsarchitekturen, untersucht, um im Umkehrschluss festlegen zu können, was ein Integrationsmuster als Lösungsbereich beschreiben darf. Für Integrationsarchitekturen wird durch mehrere Autoren bekräftigt, dass sich die beschriebenen Elemente einer Integrationsarchitektur auf der Abstraktionsebene von Softwarekomponenten bewegen (vgl. [KG98, S. 2], [DG02, S. 70], [PGKD00, S. 4]). Die Elemente werden des Weiteren als Systeme für die Präsentations-, Daten- und Funktionsintegration (vgl. [Gei06, S. 122]), Services (vgl. [EHH+ 08, S. 195]) bzw. als jede Technologie, Ressource oder Erweiterung beschrieben, die für die Erreichung der Integration notwendig sind (vgl. [Erl09, S. 28]). Dabei werden die Hauptfunktionen von Integrationselementen in der Überbrückung von Inkompatibilitäten (vgl. [KG98, S. 2]) bzw. von Heterogenität gesehen. Heterogenität kann in multiplen Formen auftreten und von Systemplattformen (vgl. [Heu07, S. 10]), Technologien und Organisationen [VAC+ 09, S. 55] ausgehen. Zusammenfassend dienen Integrationselemente der Lösung von Interoperabilitätsproblemen (vgl. [DG02, S. 70], [PGKD00, S. 4]). Darüber hinaus dienen die Elemente einer Integrationsarchitektur der Organisation einer transparenten Kommunikation (vgl. [Dou07, S. 176]). Verteilte Funktionen und Daten (vgl. [Heu07, S. 10]), Datenbanken (vgl. [Gei06, S. 122]), Anwendungen (vgl. [Dou07, S. 176]) bzw. Systeme eines Unternehmens (vgl. [VAC+ 09, S. 55], [Erl09, S. 28]) werden durch die Integrationsarchitektur, im Sinne der Verfeinerung einer Kopplungsarchitektur (vgl. [EHH+ 08, S. 195]), verbunden. Die Relationen der Elemente untereinander werden nicht detailliert beschrieben, es wird lediglich auf die Kombinierbarkeit der Elemente zu einer vollständigen Integrationsarchitektur hingewiesen (vgl. [KG98, S. 2], [PGKD00, S. 4]). Als Ziel wird die Schaffung einer integrierten Lösung bzw. eines Megakonnektors genannt (vgl. [PGKD00, S. 4]). Das Ausmaß der Konkretheit einer Integrationsarchitektur wird widersprüchlich beschrieben. Einige Definitionen verweisen darauf, dass es sich bei den beschriebenen Elementen um Middlewarekomponenten oder -dienste auf Basis standardisierter Schnittstellen und Protokolle handelt (vgl. [Dou07, S. 176], [Heu07, S. 10], [HS06, S. 276], [Gei06, S. 122], [Erl09, S. 28], [EHH+ 08, S. 207]), welche durch die Architektur geordnet werden (vgl. [Lut00, S. 66]). Im Wiederspruch dazu stehen Aussagen, welche betonen, dass eine Integrationsarchitektur sich von einer Middleware dahingehend unterscheidet, dass sie keine Funktionen beschreibt, welche über die Lösung des Konflikts hinausgehen. Diese Abstraktion – im Vergleich zu einer konkreten Realisierung – wird dadurch untermauert, dass die Elemente als Strategien und Pattern bezeichnet werden (vgl. [PGKD00, S. 4]). Diese Argumentation wird durch Hepner et al. unterstützt, die eine Integrationsarchitektur ebenfalls als Abstraktion hinsichtlich der Kernfunktionalität, die für eine Integrationsstrategie benötigt wird, sehen. Dabei wird dies auf funktionale Elemente heruntergebrochen (vgl. [HGK+ 06, S. 538]). 25 Hagen und Schwinn definieren Integrationsarchitekturen auf den Ebenen a) Infrastruktur, b) Methoden und Prozesse und c) Steuerungsmaßnahmen zur Verbesserung der Applikationslandschaft (vgl. [HS06]). Damit wird der Abstraktionsgedanke ebenfalls zum Ausdruck gebracht, der Gestaltungsbereich jedoch im Vergleich zu den anderen Definitionen wesentlich erweitert. Engels et al. tragen einen zusätzlichen Gesichtspunkt zur Abstraktion bei, indem sie eine Integrationsarchitektur als Verfeinerung einer Kopplungsarchitektur im Sinne einer Konkretisierung sehen (vgl. [EHH+ 08, S. 195]). Die Ergebnisse der Literaturrecherche und die extrahierten Eigenschaften der untersuchten Begriffe sind in der nachfolgenden Tabelle 1 zusammengefasst. Eigenschaft Integrationsmuster Architekturmuster Integrationsarchitekturen Art der Elemente Integrations- und Businesskomponenten Komponenten, Konnektoren, Subsysteme Softwarekomponenten für die Organisation von Kommunikation, Überbrückung von Heterogenität Umfang Verhalten der Komponenten, Beziehungen untereinander, relative Position in der Architektur Rollen, Eigenschaften, erlaubte Beziehungen zw. den Elementen Systeme für die Präsentations-, Daten- und Funktionsintegration, Services, alles zur Erreichung von Integration notwendige Funktion Lösung für Integrationskonflikt Beschreibung d. Organisation eines Systems in Form eines Schemas Überbrückung von Heterogenität, Organisation transparenter Kommunikation Abstraktionsgrad Architekturmuster oder Standard-Integrationsarchitektur Lösung für eine Familie von Applikationen, prinzipieller Lösungsansatz Middlewarekomponenten und -dienste i.G.z. beschreibt nur Funktionen zur Lösung von Integrationskonflikten, Verfeinerung einer Kopplungsarchitektur Tabelle 1: Zusammenfassung der Eigenschaften von Integrations- und Architekturmustern sowie Integrationsarchitekturen Quelle: Eigene Darstellung Die vorgestellten Eigenschaften lassen nun als Zusammenfassung die folgende Definition zu: Integrationsmuster sind Architekturmuster, welche ausschließlich Komponenten, deren Eigenschaften, Beziehungen untereinander, sowie die relative Positionierung in einer Architektur beschreiben, welche zur Organisation der Kommunikation und Überbrückung von Heterogenität benötigt werden. Je nach Abstraktionsgrad des Musters können die Komponenten Softwarekomponenten, Applikationen oder Subsysteme eines Systems sein. Eine Integrationsarchitektur entspricht der Komposition von Integrationsmustern bezüglich einer gegebenen Problemstellung. Die Problemstellung wird vornehmlich durch die Anforderungen des betrieblichen Informationssystems an seine digitalen Aufgabenträger formuliert. 26 2.3 Ordnungssysteme Grundsätzlich lassen sich Klassifikationen anhand der Anzahl der Wurzelelemente in monohierarchische und polyhierarchische Klassifikationen unterscheiden (vgl. [Uml99]). Weiterhin ist eine Unterscheidung in Präkombination bzw. Präkoordination und Postkoordination möglich, je nachdem, ob die Klassifikation vom Allgemeinen zum Besonderen oder vom Besonderen zum Allgemeinen ausgerichtet wird. Die erste Variante wird auch als analytisch und die zweite als synthetisch bezeichnet (vgl. [Uml99]). Es lassen sich verschiedene Ordnungssysteme nach Fettke und Loos unterscheiden. Dies sind Klassifikation ohne Überlagerung, Klassifikation mit Überlagerung, monohierarchische Klassifikation, polyhierarchicsche Klassifikation, Register, Facettenklassifikation, Begriffskombination, Schlagwortvergabe usw. (vgl. [FL00, S. 58]). 3 Problemadäquate Integrationsmusterklassifikation Im vorherigen Kapitel wurden verschiedene Ordnungssysteme vorgestellt. Dieser Abschnitt befasst sich mit der Auswahl eines Ordnungsansatzes für die Systematisierung von Integrationsmustern. Im Folgenden werden zunächst in Musterpublikationen eingesetzte Ordnungssysteme analysiert und ein Ansatz für unser Vorhaben ausgewählt. Anschließend wird der Ansatz im Detail vorgestellt und auf eine Auswahl von Integrationsmustern angewendet. Abschließend wird an einem Beispiel gezeigt, wie Integrationsmuster anhand des Ordnungssystems ausgewählt werden können. 3.1 Klassifikationsansatz Da wir uns im Bereich künstlicher Systeme befinden und uns mit der Klassifikation von Lösungsmustern für Integrationsprobleme befassen, ist damit zu rechnen, dass zu den vorhandenen Lösungsansätzen weitere hinzukommen werden. Aus diesem Grund stellt sich die Anforderung der Erweiterbarkeit an den zu wählenden Klassifikationsansatz. Da es sich bei der Klassifikation von Mustern um einen Ansatz der Wiederverwendung handelt, kann auf die Erfahrung der Nutzung von Klassifikationen im Bereich des Software-Reuse zurückgegriffen werden. Dort sind bereits Ansätze auf Basis von Facettenklassifikationen umgesetzt (vgl. [PD91]). Bereits in dem grundlegenden Werk von Gamma et al., welches Muster im Bereich des Software Engineering bekannt machte, sind Überlegungen zur Ordnung des auf diese Art dokumentierten Wissen enthalten (vgl. [GHJV95]). Fettke und Los vergleichen die angewandten Ordnungssysteme für eine Auswahl von Musterpublikationen (vgl. [FL01], Tabelle 2). Dabei fällt auf, dass eine Facettenklassifikation überproportional häufig eingesetzt wird. Die einzelnen Klassifikationen weichen jedoch in den Klassenanzahlen deutlich voneinander ab, auch gibt es keine publikationsübergreifende Klassifikation. Die Basis der Facettenklassifikation wurde von S. R. Ranganathan im Rahmen der Colon-Klassifikation zuerst publiziert (vgl. [Ran67]). Grundlegender Ansatz ist es, ein Objekt nach mehreren 27 Quelle Klassifikationsprinzip Anzahl Klassen [QC99] Facettenklassifikation mit 4 Facetten 576 [Bus94] Facettenklassifikation mit 3 Facetten 48 [GHJV95] Facettenklassifikation mit 2 Facetten 6 [CS95], [VCK96], [MRB98], [HFR99] Klassifikation ohne Überlagerung 8-10 [GHJV93] Hierarchische Klassifikation 7 [BMR 96] Facettenkalssifikation mit 2 Facetten 42 [Tic97] Hierarchische Klassifikation 111 [SRSS00] Facettenklassifikation mit 2 Facetten 21 [Ris00] Klassifikation mit Überlagerung 65 + Tabelle 2: Bestehende Klassifikationsansätze in Patternpublikationen Quelle: [FL01] Begriffssystemen (Facetten) einordnen zu können. Es werden also mehrere Konstruktionsprinzipien (Klassifikation und Facettierung) zusammengeführt (vgl. [SS08, S. 275]). „Jeder Focus einer jeden Facette wird durch eine Notation benannt, innerhalb der Facetten besteht – soweit sinnvoll und notwendig – eine hierarchische Ordnung und die Facetten werden in einer bestimmten Reihenfolge (Citation order) abgearbeitet.“ [SS08, S. 275] Die Kombinationsmöglichkeiten, die sich durch das Kombinieren von Foci der ersten mit denen der zweiten und weiteren Facetten ergeben, sind die Stärke dieses Ansatzes. Die Verknüpfung der Facetten entsteht erst, wenn man mit Hilfe einer solchen Klassifikation klassiert. Vickery beschreibt fünf Schritte, die zum Aufbau einer derartigen Klassifikation bzw. für eine Facettenanalyse des Gegenstandsbereiches notwendig sind: 1) Festlegen des Gegenstandsbereiches, 2) Formulierung von Facetten, 3) Strukturierung der Facetten, 4) Dokumentation der Entscheidungen und Niederschrift offener Punkte und 5) Bestimmen der Reihenfolge der Facetten (vgl. [Vic66] zitiert nach [LB06, S. 185]). 3.2 Facetten der Klassifikation Da wir uns für eine Facettenklassifikation entschieden haben und in der Einleitung der Gegenstandsbereich mit der Integration von Anwendungssystemen im Rahmen von betrieblichen Informationssystemen bereits festgelegt wurde, sind nun die einzelnen Facetten zu klären. Die Anforderungen an eine Facette bzw. die Facetten untereinander sind, dass sie disjunkt sind und dass jede Facette für sich ein homogenes System darstellt (vgl. [SS08, S.286]). Wir können im Wesentlichen zwei Typen von Facetten unterscheiden, welche sich aus der im Software Engineering allgemein üblichen Trennung in funktionale und nicht-funktionale Anforderungen herleiten und dem Umstand geschuldet sind, dass wir den Zugang der Integrationsarchitekten und -entwickler zu verfügbarem Lösungswissen verbessern wollen. Ebert unterscheidet funktionale Anforderungen, nicht-funktionale Anforderungen – auch Qualitätsanforderungen – sowie Randbedingungen 28 (vgl. [Ebe08, S. 28]). Demzufolge unterscheiden wir zum einen die Gruppe der funktionalen Facetten und zum anderen die Gruppe der nicht-funktionalen Facetten. Diese Differenzierung findet sich auch bei Wagner in den Ausführungen zu den Gestaltungsmerkmalen von Integrationslösungen (vgl. [Wag06]). Randbedingungen klammern wir in den folgenden Betrachtungen aus. 3.2.1 Funktionale Facetten Funktionale Anforderungen, die an eine Integrationslösung gestellt werden, lassen sich im Wesentlichen aus unserer Analyse der charakteristischen Merkmale von Integrationsmustern herleiten. An ein Integrationsmuster werden die Anforderungen der Überbrückung von Heterogenität und die Anforderung der transparenten Organisation der Kommunikation gestellt. Aus diesem Grund unterscheiden wir die Facette des Heterogenitätskonfliktes und die Facette der Kommunikation. Die funktionalen Gestaltungsmerkmale zur Kommunikation sind in Tabelle 3 dargestellt. Merkmal Ausprägungen Interaktionsschicht, Integrationsebene Benutzerschnittstelle Anwendungsfunktionalität Datenhaltung Beziehung zwischen den Integrationsobjekten Client/Server Peer-to-Peer push-pull publish and subscribe Kommunikationsmodell synchron asynchron verbindungsorientiert verbindungslos one to one many to one one to many many to many Interaktionsmechanismus Dateien Nachrichten Prozeduraufrufe verteilte Objekte Tabelle 3: Funktionale Gestaltungsmerkmale der Kommunikation Quelle: [Wag06, S. 53ff.] Die Merkmale der Interaktionsschicht können in eine eigene Facette übernommen werden. Das Merkmal Kommunikationsmodell kann in die drei Facetten Synchronität, Verbindungsorientierung und Kardinalität aufgespalten werden. Die Beziehung zwischen den Integrationsobjekten stellt aus unserer Sicht eine Kombination der Kardinalität der Kommunikationsteilnehmer in Verbindung mit der Interaktionsauslösung dar und wird deshalb nicht in die Klassifikation übernommen. Das Merkmal des Interaktionsmechanismus kann als Facette in die Klassifikation übernom- 29 men werden. Diese Aufspaltungen werden in Tabelle 4, welche die Facetten mit den zugehörigen Foci enthält, zusammengefasst dargestellt. Facette Foci Interaktionsschicht, Integrationsebene Benuzerschnittstelle Anwendungsfunktionalität Datenhaltung Synchronität synchron asynchron snyc.+async. Verbindungsorientierung verbindungsorientiert verbindungslos Kardinalität one to one many to one one to many many to many Interaktionsmechanismus Dateien Nachrichten Prozeduraufrufe verteilte Objekte Tabelle 4: Facetten und Foci der Kommunikation Quelle: Eigene Darstellung Zusätzlich benötigen wir noch weitere Facetten, die wir im Folgenden herleiten. Die Eigenschaft der Heterogenitätsüberbrückung erfassen wir hier in dem Fokus auf Transformation. Dabei sind als Ausprägungen nur Y für unterstützt und N für nicht unterstützt zulässig. Dies ist relativ ungenau, da in der wissenschaftlichen Literatur eine Vielzahl an differenzierten Heterogenitätskonflikten bekannt sind (vgl. [Vog06], [ABW+ 09]). Die Facette der Anbindung symbolisiert die Eignung eines Anwendungssystems an ein Integrationshilfsmittel o. ä. anzukoppeln. Ebenso wie bei der Transformation werden nur die Foci Y und N für unterstützt bzw. nicht unterstützt verwendet. Gleiches gilt für die folgenden Facetten. Die Facette der Kommunikationsindirektion kennzeichnet, ob die Kommunikation zwischen Quellen und Empfänger – bei Einsatz des Musters – nun immer über das durch das Muster eingefügte Architekturelement abgewickelt wird. Unter Kenntnis der Kommunikationspartner wird verstanden, ob – dies gilt auch bei Vorliegen einer Kommunikationsindirektion – der eigentliche Kommunikationspartner bekannt sein muss. Die dynamische Registrierung dokumentiert, ob es möglich ist, die Kommunikationspartner zur Laufzeit zu verändern, indem z. B. ein Kommunikationspartner durch einen Neuen ersetzt wird. Die Facette Abstraktionsart weist die Abstraktionsebene aus, auf der das Muster in der entsprechenden Quelle beschrieben wird und ist nur besetzt, wenn dies explizit genannt oder erkennbar ist. Streng genommen stellt Konstruktionsprinzip keine Facette im eigentlichen Sinne dar, sondern dient dem Aufbau einer solchen. Sofern in der Quelle dokumentiert wird hier das Konstruktionsprinzip des Musters festgehalten. Die Intention ist es, auf dieser Basis alle potentiellen Foci dieser potentiellen Facette zu erfassen. Tabelle 5 fasst die weiteren Facetten zusammen. 30 Facette Foci Transformation Y N Anbindung Y N Kommunikationsindirektion Y N Kenntnis der Kommunikationspartner Y N dynamische Registrierung Y N Abstraktionsart Explorativ zur Erfassung der Foki der Facette Konstruktionsprinzip Explorativ zur Erfassung der Foki der Facette Tabelle 5: Weitere funktionale Facetten Quelle: Eigene Darstellung 3.2.2 Nicht-funktionale Facetten Ein Ergebnis einer empirischen Untersuchung zu Integrationsdienstleistungen (vgl. [SG11]) ist die Auflistung der Top 5 Gründe für die Auswahl einer Integrationslösung. Es ist festzustellen, dass es sich dabei im Wesentlichen um nicht-funktionale Eigenschaften und Kostenfaktoren handelt. Die Kostenfaktoren können aus den Betrachtungen ausgeklammert werden, da sie auf der Abstraktionsebene von Mustern nicht entscheidbar sind, sondern von konkreten Hilfsmitteln und weiteren Faktoren abhängen. Die restlichen Qualitätsanforderungen lassen sich jedoch auf qualitativem Niveau auf der Ebene der Muster feststellen. Dabei können zwar nur Aussagen zur positiven oder negativen Beeinflussung jedoch keine quantitativen Aussagen getroffen werden, es ist jedoch so möglich, eine Auswahlentscheidung zu treffen, die auf der gezielten Selektion anhand dieser Merkmale beruht. In der Literatur existieren eine Vielzahl an Qualitätsbegriffen und Ausprägungen einzelner Facetten. Aus diesem Grund haben wir uns auf die ISO 9000 Norm als Standard fokussiert. Qualität ist die „Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen“ [SDW+ 10, S. 110]. Als Qualitätsmerkmale nach ISO/IEC 9126 lassen sich Funktionalität (Functionality), Zuverlässigkeit (Reliability), Benutzbarkeit (Usability), Effizienz (Efficiency), Änderbarkeit (Maintainability) und Übertragbarkeit (Portability) mit entsprechenden Qualitätseigenschaften identifizieren. Bei der Analyse der Muster wurden die beschriebenen Qualitätseigenschaften auf die ISO Definition abgebildet. Dabei konnten nicht alle Qualitätseigenschaften in den Patternbeschreibungen wieder gefunden werden (vgl. [Sch10, S. 18ff.]). 31 3.3 Auswahl bekannter Integrationsmuster Muster haben sich im Rahmen der Entwicklung von Softwarelösungen seit längerer Zeit etabliert. Die Anzahl an Publikationen, die sich mit der Beschreibung und Systematisierung von Mustern befasst, ist hoch. Zudem befassen sich unterschiedliche Konferenzen mit diesem Thema (vgl. PLoP [CS95, VCK96, MRB98, HFR99, MVN06] oder EuroPLoP [Mar05, LZ06, ZH07, NJ09, NJZ+ 11]). Aus der Vielzahl an Musterbeschreibungen sollen die Muster identifiziert werden, die für die Lösung eines Integrationsproblems relevant sind. Das Ergebnis der Literaturanalyse ist der Tabelle 6 zu entnehmen. Darin sind ausgewählte Quellen inklusive der Anzahl der beschrieben Muster zusammengefasst. Einige Muster sind in verschiedenen Patternsystemen beschrieben, was Quervergleiche zwischen verschiedenen Autoren ermöglicht. Zudem enthalten verschiedene Publikationen Patternbeschreibungen, die im Rahmen der Integrierung nicht relevant sind. Somit ist eine Aussage über die gesamte Anzahl von Integrationsmustern nicht möglich und die Zahlen haben hinweisenden Charakter auf die Menge der zu analysierenden Muster. Publikation Anzahl Patterns Anmerkungen [HWB04] [TRH+ 04] [Lut00] [AJ01] [Mul95] 65 18 5 6 4 [HGRZ06] 56 [Fow03] [TMQ+ 03] [Erl09] [HZ06] [AZ05] 51 19 78 11 24 [Sch06] 4 [SRSS00] [BHS07a] 17 114 Patternsystem für Integrationsmuster, nachrichtenorientiert Patternbeschreibungen Integrationsmuster, nachrichtenorientiert Musterbeschreibungen für EAI Beschreibung von Integrationsstilen für große verteilte Anwendungen Kein Bezug zu Mustern im Titel, aber Definition von Integrationsmuster enthalten Patternkatalog im Anhang des Buches, Auflistung von Mustern aus anderen Patternsystemen. Muster für die Entwicklung von Enterprise Applications Muster für die Entwicklung von Enterprise Applications Muster für service-orientierte Architekturen Muster für service-orientierte Architekturen Klassifikation von bestehenden Architekturmustern basierend auf dem Architektur-Sichtenmodell Betrachtung der Design-Patterns aus [GHJV95] aus Sicht der Anwendungsintegration, Ableitung von vier neuen Integrationsmustern Patternsystem für vernetzte Objekte Patternsystem für verteilte Systeme Tabelle 6: Übersicht der analysierten Patternliteratur Quelle: eigene Darstellung 3.4 Klassifikation der gewählten Muster Die folgenden Tabellen stellen die Klassifikation einer Auswahl an Mustern vor. Tabelle 7 bezieht sich auf die funktionalen undTabelle 8 auf die nicht-funktionalen Facetten. Eskonnten nicht alle Muster der zur Analyse vorgeschlagenen Literaturberücksichtigt werden, da dies aus Platzgründen nicht möglich ist. 32 Kenntnis der Kommunikationspartner dynamische Registrierung N OOP Y N N OOP Y N N Y N N Y Y Y N N N N N N Y Y Y N N N Y N Y Y Y Y Y Y Y N Y Y Y N N N N N Y Y Y Y Y 1:1 Y [BMR+ 96] FK [TRH+ 04] FK 1:1 1:1 Y Y divide large Y tasks in small steps divide tasks Y divide tasks Y [TMQ+ 03] FK 1:n N 1:n N Wrapper Facade FK sync. Wrapper [SRSS00, S. 47ff.] [Mul95] FK sync. Wrapper [Lut00] FK sync. Integration Mediator Mediator Mediator Style [Lut00] [BHS07a] [AJ01] FK FK Message Router Message Router Message Router [AJ01] [HWB04] [BHS07b] FK FK FK Broker [BMR+ 96] FK Broker Direct Broker Indirect Broker Message Broker Message Broker [TMQ+ 03] [TRH+ 04] [TRH+ 04] [TRH+ 04] [HWB04, S. 322ff.] FK FK FK FK FK Pipes and Filter [HWB04, S. 322ff.] FK Pipes and Filter Pipes and Filter Observer Publish and Subscribe [TRH+ 04] FK Transformation sync. Anbindung FK Y Y m:1 Func. calls m:1 Func. calls m:1 Func. calls m:1 Func. calls Y Y Y Y Y Y Y Y Y Y N Y Kardinalität [GZ02] Synchronität Component Wrapper 1:1 m:1 m:n versch. m:n versch. asyn.v.los 1:n asyn.v.los 1:n asyn.v.los 1:n Nachr. Nachr. Nachr. m:n Func. calls m:n m:n m:n asyn.v.los m:n Nachr. asyn.v.los m:n Nachr. Kapselung, Entkopplg. Kapselung, Entkopplg. Kapselung, Entkopplg. Kapselung, Entkopplg. Entkopplg. Entkopplg. Entkopplg. N N N Entkopplg. notify state N changes one way pro- Y pagation Abstraktionsart Kommunikationsindirektion N FK Konstruktionsprinzip Y [AJ01] Interaktionsmechanismus N Adapter Style Verbindungsorientierung N Quelle Interaktionsschicht Y Muster OOP N N N OOP N N OOP N (Y) Tabelle 7: Funktionale Klassifikation der Integrationsmuster Quelle: Eigene Darstellung 33 Mediator Integration Mediator Mediator Mediator Mediator Style [GHJV95, S. 277] [Lut00, S. 71] [BHS07a, S. 411] [KG08] [AJ01, S. 230] Broker Broker Broker Broker Broker [BMR+ 96, S. 119ff.] [TMQ+ 03, S. 207f] [KJ04, S. 581] [HA07, S. 267f] [MAR10] Message Broker [TRH+ 04, S. 240f] Pipes and Filters Pipes and Filters Pipes and Filters Pipes and Filters Pipes and Filters Pipes and Filters Pipes and Filters [GS93, S. 7f] [Meu95, S. 437] [BMR+ 96, S. 67ff.] [HWB04, S. 70ff.] [TRH+ 04, S. 292f] [HA07, S. 267f] [MAR10, S. 459] + Observer Publish/Subscribe [TMQ+ 03, S. 129f] [TRH+ 04, S. 280f] + Message Router Style Message Router Message Router [AJ01, S. 231] [HWB04, S. 81] [BHS07a, S. 232] - +/- + - + + + - - + + +/- + + - - - + + + + +/- + + - +/+ - +/+/- + + - +/- + + + + + + + + + + +/- +/- + + + - +/+ + - - + - + -/+ - - + - + + Tabelle 8: Nicht-funktionale Klassifikation der Integrationsmuster Quelle: [Sch10] 34 + + +/+/+/+/- - - + + + + - - - + Maintainability [BMR+ 96, S. 274f] [KG08] Security Proxy Proxy Interoperability [GZ02, S. 7ff.] [SRSS00, S. 47ff.] [KG08] Efficiency Component Wrapper Wrapper Facade Facade - Reusability [KG08] [AJ01, S. 229] Portability Adapter Adapter Style Analyzability Quelle Reliability Testability Muster -/+ 3.5 Patternauswahl mit Hilfe der Klassifikation Dieser Abschnitt dokumentiert das wesentliche Ergebnis dieses Beitrags und stellt den Nutzen der erarbeiteten Klassifikation dar. Nehmen wir an, ein Integrationsdienstleister steht im Rahmen seiner Tätigkeit vor der Aufgabe, ein Integrationsproblem zu lösen, welches eine Kommunikationsindirektion und eine Entkopplung der Kommunikationspartner beinhalten soll, so dass diese sich wechselseitig nicht kennen müssen. Basierend auf unserer Klassifikation ergäbe sich eine Vielzahl an potentiellen Lösungen, die von einem Wrapper bis zu Publish and Subscribe reichen. Deshalb erscheint eine Verfeinerung der Suche geboten. Wird keine dynamische Registrierung der Kommunikationspartner benötigt, so kommt immer noch das Wrapper Muster in Frage, als Alternative aber auch ein Mediator. Beide Muster weisen jedoch unterschiedliche Qualitätseigenschaften auf. So bekommt ein Wrapper in der Effizienz eine negative Bewertung, wohingegen ein Mediator indifferent – von einem Autor positiv und von einem anderem negativ – bewertet wird. Bemerkenswert an dem Ergebnis ist die Tatsache, dass Muster als Lösungsalternativen erscheinen, die unter normalen Umständen nicht direkt miteinander verglichen worden wären. Auf der Basis der vorgestellten Klassifikation ist es nun möglich, den Auswahlprozess besser zu strukturieren und Muster gezielt anhand von Qualitätsmerkmalen zu selektieren und ihre funktionalen Eigenschaften zu vergleichen. 4 Zusammenfassung und Ausblick In diesem Beitrag wurde der Einsatz von Integrationsmustern im Anwendungsbereich betrieblicher Informationssysteme motiviert, da diese in der Literatur zwar existieren, jedoch in der Praxis nur unzureichend genutzt werden. Als Ursache wurde ein problematischer Zugang identifiziert, welcher durch eine problemadäquate Klassifizierung behoben werden soll. Auf der Basis einer merkmalsbasierten Definition wurde eine Auswahl von Integrationsmustern aus gängigen Publikationen getroffen. Diese wurden entsprechend der erarbeiteten Facetten mit Hilfe einer Facettenklassifikation klassiert. Auf Basis dieser Klassierung konnte eine problemadäquate Auswahl von Mustern demonstriert werden. Die Suche nach Mustern hat eine größere Menge, als die hier klassierten Muster, ergeben. Für eine Erweiterung der hier vorgestellten Ergebnisse bieten sich zwei Ansatzpunkte. Erstens, die aus den Betrachtungen ausgeklammerten aber identifizierten Muster können in die Betrachtungen einbezogen werden. Zweitens, kann die Suche nach Integrationsmustern auf der Basis der vorgestellten Definition ausgeweitet werden, um die Grundgesamtheit der Muster weiter zu erhöhen. Die Klassierung der Muster bezüglich der einzelnen Facetten lässt sich verdichten, indem die unterschiedlichen Klassierungen identischer Muster durch unterschiedliche Autoren zusammengeführt werden. Darüber hinaus lassen sich der Klassifikation auf Grund der Tatsache, dass es sich um eine analytisch-synthetische Klassifikation handelt, weitere Facetten hinzufügen, um die Auswahl von Mustern auf dieser Basis zu verbessern. Die bereits enthaltenen Muster müssen dann bezüglich dieser Facette klassifiziert werden. Wie bereits angedeutet, lassen sich auf der Basis dieser Klassifikation unter Erweiterung um das Grundsätzliche Konstruktionsprinzip die Variabilitätspunkte der einzelnen Muster identifizieren. Diese können in einer separaten Systematik zusammengeführt werden. Als Beispiel sei stellvertretend das Konzept der Kommunikationsindirektion genannt, welches bei einer Vielzahl an Mustern Anwendung findet. 35 Literatur [ABW+ 09] Agt, Henning ; Bauhoff, Gregor ; Widiker, Jürgen ; Kutsche, Ralf-D. ; Milanovic, Nikola: Model-based semantic conflict analysis for software and data integration scenarios / TU Berlin, Professoren der Fak. IV. Berlin, 2009. – Forschungsbericht [AJ01] Andersson, Jonas ; Johnson, Pontus: Architectural Integration Styles for Large-Scale Enterprise Software Systems. In: 5th International Enterprise Distributed Object Computing Conference (EDOC 2001), 4-7 September 2001, Seattle, WA, USA, Proceedings, IEEE Computer Society, 2001. – ISBN 0–7695–1345–X, S. 224–236 [AKGV01] Adams, Jonathan ; Koushik, Srinivas ; Galambos, George ; Vasudeva, Guru: Patterns for e-business: A Strategy for Reuse. IBM Press, 2001 http://www.ibm.com/developerworks/patterns/. – ISBN 1–931182–02–7 [AZ05] Avgeriou, Paris ; Zdun, Uwe: Architectural Patterns Revisited - A Pattern Language. In: [LZ06], S. 431–470 [BHS07a] Buschmann, Frank ; Henney, Kevlin ; Schmidt, Douglas: Wiley Software Patterns Series. Bd. 4: Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing. John Wiley & Sons, 2007. – ISBN 978–0–470–05902–9 [BHS07b] Buschmann, Frank ; Henney, Kevlin ; Schmidt, Douglas: Wiley Software Patterns Series. Bd. 5: Pattern-Oriented Software Architecture: On Patterns and Pattern Languages. John Wiley & Sons, 2007. – ISBN 978–0–471–48648–0 [BMR+ 96] Buschmann, Frank ; Meunier, Regine ; Rohnert, Hans ; Sommerlad, Peter ; Stal, Michael: Wiley Software Patterns Series. Bd. 1: Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996. – ISBN 0–471–95869–7 [Bus94] Buschmann, Frank: Software architecture and reuse-an inherent conflict? In: Software Reuse: Advances in Software Reusability, 1994. Proceedings., Third International Conference on IEEE, 1994, S. 218–219 [CS95] Coplien, James O. (Hrsg.) ; Schmidt, Douglas C. (Hrsg.): Pattern Languages of Program Design. Bd. 1. Addison-Wesley, 1995 . – ISBN 0–201–60734–4 [DG02] Davis, L. ; Gamble, Rose: Identifying evolvability for integration. In: Dean, John C. (Hrsg.) ; Gravel, Andrée (Hrsg.): COTS-Based Software Systems, First International Conference, ICCBSS 2002, Orlando, FL, USA, February 4-6, 2002, Proceedings Bd. 2255. Berlin, Heidelberg : Springer-Verlag, 2002 (Lecture Notes in Computer Science). – ISBN 3–540–43100–4, S. 65–75 [Dou07] Dous, Malte: Kundenbeziehungsmanagement für interne IT-Dienstleister: Strategischer Rahmen, Prozessgestaltung und Optionen für die Systemunterstützung. Duv, zugl. Dissertation Universität St. Gallen, 2007 [Ebe08] Ebert, C.: Systematisches Requirements-Engineering und Management: Anforderungen ermitteln, spezifizieren, analysieren und verwalten. dpunkt-Verl., 2008 [EHH+ 08] Engels, Gregor ; Hess, Andreas ; Humm, Bernhard ; Juwig, Oliver ; Lohmann, Marc ; Richter, Jan-Peter ; Voss, Markus ; Willkomm, Johannes: Quasar Enterprise: Anwendungslandschaften serviceorientiert gestalten. dpunkt.verlag, 2008. – ISBN 978–3–89864–506–5 [Erl09] 36 Erl, Thomas: SOA Design Patterns. Prentice Hall International, 2009. – ISBN 0–13–613516–1 [EV08] Engels, Gregor ; Voss, Markus: Quasar Enterprise. In: Informatik-Spektrum 31 (2008), Nr. 6, S. 548–555 [Fac09] Fachgruppe Software Architektur: Glossar. http://sdqweb.ipd.kit.edu/mediawiki-fg/index.php/Kategorie:Glossar. Version: 2009 [Fie00] Fielding, Roy T.: Architectural styles and the design of network-based software architectures. Irvine, University of California, Diss., 2000 [Fis08] Fischer, Daniel.: Unternehmensübergreifende Integration von Informationssystemen: Bestimmung des Integrationsgrades auf elektronischen Marktplätzen. Gabler Verlag, zugl. Dissertation TU Ilmenau, 2008 [FL00] Fettke, Peter ; Loos, Peter: Komponentendokumentationen - Eine systematische Bewertung von Ordnungssystemen aus formaler Sicht. In: Turowski, Klaus (Hrsg.): Modellierung und Spezifikation von Fachkomponenten: Workshop im Rahmen der MobIS 2000 Modellierung betrieblicher Informationssysteme, Siegen, Deutschland, 12. Oktober 2000, Tagungsband. Siegen. Siegen, 2000, S. 51–70 [FL01] Fettke, Peter ; Loos, Peter: Zur Klassifikation von Patterns. Version: 2001. http://archiv.tu-chemnitz.de/pub/2001/0076. In: Net.ObjectDays, Organisatoren der (Hrsg.): Net.ObjectDays 2001 - Tagungsband, 10. - 13. September 2001, Messekongresszentrum Erfurt. 2001. – ISBN 3–00–008419–3, 251–252. – Erfurt [Fow03] Fowler, Martin: Patterns of Enterprise Application Architecture. Boston, MA, USA : Addison-Wesley, 2003. – ISBN 0–321–12742–0 [Gab08] Gabriel, Roland: Informationssystem. In: Kurbel, Karl (Hrsg.) ; Becker, Jörg (Hrsg.) ; Gronau, Norbert (Hrsg.) ; Sinz, Elmar (Hrsg.) ; Suhl, Leena (Hrsg.): Enzyklopädie der Wirtschaftsinformatik – Online-Lexikon. 4. Auflage. München : Oldenbourg Wissenschaftsverlag, 2008. – http://www.oldenbourg.de: 8080/wi-enzyklopaedie/lexikon/informationssysteme/uebergreifendes/ Kontext-und-Grundlagen/Informationssystem, Abruf: 26.07.2011 [GAO95] Garlan, David ; Allen, Robert ; Ockerbloom, John: Architectural mismatch or why it’s hard to build systems out of existing parts. (1995). – ISSN 0270–5257 [Gei06] Geib, Malte: Kooperatives Customer-Relationship-Management Fallstudien und Informationssystemarchitektur in Finanzdienstleistungsnetzwerken. Springer-Verlag, zugl. Dissertation Universität St. Gallen, 2006 [GHJV93] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Design patterns: Abstraction and reuse of object-oriented design. In: Nierstras, Oscar M. (Hrsg.): ECOOP’ 93 Object-Oriented Programming: 7th European Conference Kaiserslautern, Germany, July 26-30, 1993 Proceedings Bd. 707. Berlin, Heidelberg, New York : Springer-Verlag, 1993 (Lecture Notes in Computer Science). – ISBN 978–3–540–57120–9, S. 406–431 [GHJV95] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Design patterns: elements of reusable object-oriented software. Boston, MA, USA : Addison-Wesley, 1995. – ISBN 0–201–63361–2 [GS93] Garlan, David ; Shaw, Mary: An introduction to software architecture. In: Advances in software engineering and knowledge engineering 1 (1993), S. 1–40 [GZ02] Goedicke, Michael ; Zdun, Uwe: Piecemeal legacy migrating with an architectural pattern language: a case study. In: Journal of Software Maintenance and Evolution: Research and Practice 14 (2002), Nr. 1, S. 1–30 37 [HA07] Harrison, Neil B. ; Avgeriou, Paris: Leveraging architecture patterns to satisfy quality attributes. In: Oquendo, Flavio (Hrsg.): Software Architecture: First European Conference, ECSA 2007 Madrid, Spain, September 24-26, 2007 Proceedings Bd. 4758. Berlin, Heidelberg : Springer-Verlag, 2007 (Lecture Notes in Computer Science). – ISBN 3–540–75131–9, S. 263–270 [Has06] Hasselbring, Wilhelm: Software-Architektur. In: Informatik-Spektrum 29 (2006), Nr. 1, S. 48–52 [Heu07] Heutschi, R.: Serviceorientierte Architektur: Architekturprinzipien und Umsetzung in die Praxis. Springer-Verlag, 2007 [HFR99] Harrison, Neil (Hrsg.) ; Foote, Brian (Hrsg.) ; Rohnert, Hans (Hrsg.): Pattern Languages of Program Design. Bd. 4. Addison-Wesley, 1999 . – ISBN 0–201–31011–2 [HGK+ 06] Hepner, M. ; Gamble, R. ; Kelkar, M. ; Davis, L. ; Flagg, D.: Patterns of conflict among software components. In: J. Syst. Softw. 79 (2006), Nr. 4, S. 537–551. – ISSN 0164–1212 [HGRZ06] Herden, Sebastian ; Gómez, Jorge M. ; Rautenstrauch, Claus ; Zwanziger, André: Software-Architekturen für das E-Business: Enterprise-Application-Integration mit verteilten Systemen. Berlin Heidelberg : Springer-Verlag, 2006. – ISBN 10 3–540–25821–3 [HS06] Hagen, Claus ; Schwinn, Alexander: Measured Integration - Metriken für die Integrationsarchitektur. In: Schelp, Joachim (Hrsg.) ; Winter, Robert (Hrsg.): Integrationsmanagement - Planung, Bewertung und Steuerung von Applikationslandschaften. Berlin, Heidelberg : Springer-Verlag, 2006. – ISBN 978–3–540–20506–7, S. 267–292 [HWB04] Hohpe, Gregor ; Woolf, Bobby ; Brown, Kyle: Enterprise integration patterns: Designing, building, and deploying messaging solutions. Boston, MA, USA : Addison-Wesley Professional, 2004. – ISBN 0–321–20068–3 [HZ06] Hentrich, Carsten ; Zdun, Uwe: Patterns for Process-Oriented Integration in Service-Oriented Architectures. In: [ZH07], S. 141–198 [JLSJ07] Juric, M.B. ; Loganathan, R. ; Sarang, P. ; Jennings, F.: SOA Approach to Integration - XML, Web services, ESB, and BPEL in real-world SOA projects. Birmingham - Mumbai : Packt Publishing, 2007 [KG98] Keshav, R. ; Gamble, R.: Towards a taxonomy of architecture integration strategies. In: ISAW ’98: Proceedings of the third international workshop on Software architecture. New York, NY, USA : ACM, 1998. – ISBN 1–58113–081–3, S. 89–92 [KG08] Khomh, Foutse ; Guéhéneuc, Yann-Gaël: An empirical study of design patterns and software quality. Montreal, Quebec, Canada : University of Montreal, Januar 2008 (1315). – Forschungsbericht [KJ04] Kircher, Michael ; Jain, Prashant: Wiley Software Patterns Series. Bd. 3: Pattern-Oriented Software Architecture: Patterns for Resource Management. John Wiley & Sons, 2004. – ISBN 0–470–84525–2 [LB06] La Barre, Kathryn: The use of faceted analytico-synthetic theory as revealed in the practice of website construction and design, faculty of the University Graduate School in partial fulfillment of the requirements for the degree Doctor of Philosophy in the School of Library and Information Science, Indiana University, Diss., 2006 [LSL+ 08] Liebhart, D. ; Schmutz, G. ; Lattmann, M. ; Heinisch, M. ; Welkenbach, P. ; Könings, M. ; Pakull, P.: Integration Architecture Blueprint: Leitfaden zur Konstruktion von Integrationslösungen. Hanser Verlag, 2008 38 [Lut00] Lutz, Jeffrey C.: EAI Architecture Patterns. In: EAI Journal (2000) [LZ06] Longshaw, Andy (Hrsg.) ; Zdun, Uwe (Hrsg.): EuroPLoP’ 2005, Tenth European Conference on Pattern Languages of Programs, Irsee, Germany, July 6-10, 2005. UVK Universitätsverlag Konstanz, 2006 . – ISBN 978–3–87940–805–4 [Mar05] Marquardt, Klaus (Hrsg.): EuroPLoP’ 2004, Proceedings of the 9th European Conference on Pattern Languages of Programs, 2004. UVK - Universitätsverlag Konstanz, 2005 . – ISBN 3–87940–796–7 [MAR10] Majidi, E. ; Alemi, M. ; Rashidi, H.: Software Architecture: A Survey and Classification. In: Communication Software and Networks, 2010. ICCSN’10. Second International Conference on IEEE, 2010, S. 454–460 [Meu95] Meunier, Regine: The Pipes and Filters Architecture. In: [CS95], S. 427–440 [MRB98] Martin, Robert (Hrsg.) ; Riehle, Dirk (Hrsg.) ; Buschmann, Frank (Hrsg.): Pattern Languages of Program Design. Bd. 3. Addison-Wesley, 1998 . – ISBN 0–201–43304–4 [Mul95] Kapitel Pattern-based integration architectures. In: Mularz, Diane E.: Pattern Languages of Program Design. Addison-Wesley, 1995, S. 441 – 452 [MVN06] Manolescu, Dragos (Hrsg.) ; Völter, Markus (Hrsg.) ; Noble, James (Hrsg.): Pattern Languages of Program Design. Bd. 5. Pearson Education, 2006 . – ISBN 0–321–32194–4 [NJ09] Noble, James (Hrsg.) ; Johnson, Ralph (Hrsg.): Lecture Notes in Computer Science. Bd. 5770: Transactions on Pattern Languages of Programming I. Berlin, Heidelberg : Springer-Verlag, 2009. – ISBN 978–3–642–10831–0 [NJZ+ 11] Noble, James (Hrsg.) ; Johnson, Ralph (Hrsg.) ; Zdun, Uwe (Hrsg.) ; Wallingford, Eugene (Hrsg.) ; Avgeri, Paris (Hrsg.) ; Harrison, Neil B. (Hrsg.): Lecture Notes in Computer Science. Bd. 6510: Transactions on Pattern Languages of Programming II: Special Issue on Applying Patterns. Heidelberg, Dordrecht, London, NewYork : Springer-Verlag, 2011. – ISBN 978–3–642–19431–3 [PD91] Prieto-Diaz, Ruben: Implementing faceted classification for software reuse. In: Communications of the ACM 34 (1991), Nr. 5, S. 88–97 [PGKD00] Payton, Jamie ; Gamble, R. ; Kimsen, S. ; Davis, L.: The opportunity for formal models of integration. In: 2nd IEEE International Conference on Information Reuse and Integration (IRI-2000), 2000 [QC99] Quibeldey-Cirkel, Klaus: Entwurfsmuster: Design Patterns in der objektorientierten Softwaretechnik. Berlin, Heidelberg, New York : Springer-Verlag, 1999. – ISBN 3–540–65825–4 [Ran67] Ranganathan, S. R.: A descriptive account of the colon classification. Asia Pub., 1967 [Ris00] Rising, Linda: The pattern almanac 2000. Boston, MA, USA : Addison-Wesley, 2000. – ISBN 0201615673 [Sch06] Schwinn, Alexander: Entwurfsmusterbasierter Ansatz zur Systematisierung von Applikationsbeziehungen im Business Engineering. In: österle, H. (Hrsg.) ; Winter, R. (Hrsg.) ; Brenner, W. (Hrsg.): Integrationsmanagement - Planung, Bewertung und Steuerung von Applikationslandschaften, Springer-Verlag, 2006. – ISBN 978–3–540–29480–1, S. 31–59 [Sch10] Schmidt, Johannes: Integrationsmuster: übersicht und Vorschlag einer übergreifenden Systematisierung, Universität Leipzig, Diplomarbeit, 2010 39 [SDW+ 10] Schatten, Alexander ; Demolsky, Markus ; Winkler, Dietmar ; Biffl, Stefan ; Gostischa-Franta, Erik ; östreicher, Thomas: Best Practice Software-Engineering: Eine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen. Heidelberg : Spektrum Akademischer Verlag, 2010. – ISBN 978–3–8274–2486–0 [SG11] Stefan, Fred ; Gebauer, Martin: Stand der Integration aus der Sicht von Integrationsdienstleistern - Ergebnisse einer qualitativen empirischen Untersuchung. (2011) [SRSS00] Schmidt, Douglas C. ; Rohnert, Hans ; Stal, Michael ; Schultz, Dieter: Wiley Software Patterns Series. Bd. 2: Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects. New York, NY, USA : John Wiley & Sons, Inc., 2000. – ISBN 0–471–60695–2 [SS08] Stock, Wolfgang G. ; Stock, Mechtild: Wissenspräsentation: Informationen auswerten und bereitstellen. München : Oldenbourg, 2008. – ISBN 3486584391 [Thr08] Thränert, Maik: Integration-Engineering – Grundlagen, Vorgehen, Fallstudien, Universität Leipzig, Diss., 2008 [Tic97] Tichy, W.F.: A catalogue of general-purpose software design patterns. In: Technology of Object-Oriented Languages and Systems, 1997. TOOLS 23. Proceedings IEEE, 1997. – ISBN 081868383X, S. 330–339 [TMQ+ 03] Trowbridge, David ; Mancini, Dave ; Quick, Dave ; Hohpe, Gregor ; Newkirk, James ; Lavigne, David: Enterprise Solution Patterns Using Microsoft .NET - Version 2.0. Microsoft Press, 2003 (Patterns & Practices). http://msdn.microsoft.com/en-us/library/ms998469.aspx. – ISBN 0–7356–1850–X [TRH+ 04] Trowbridge, David ; Roxburgh, Ulrich ; Hohpe, Gregor ; Manolescu, Dragos ; Nadhan, E.G.: Integration Patterns. Microsoft Press, 2004 (Patterns & Practices). http://msdn.microsoft.com/en-us/library/ms978729.aspx. – ISBN 0–7356–1850–X [Uml99] Umlauf, Konrad: Einführung in die bibliothekarische Klassifikationstheorie und -praxis. http://www.ib.hu-berlin.de/~kumlau/handreichungen/h67/. Version: 1999 [VAC+ 09] Vogel, Oliver ; Arnold, Ingo ; Chughtai, Arif ; Ihler, Edmund ; Kehrer, Timo ; Mehlig, Uwe ; Zdun, Uwe: Software-Architektur Grundlagen - Konzepte - Praxis. Spektrum Akademischer Verlag, 2009 [VCK96] Vlissides, John M. (Hrsg.) ; Coplien, James O. (Hrsg.) ; Kerth, Norman L. (Hrsg.): Pattern Languages of Program Design. Bd. 2. Addison-Wesley, 1996 . – ISBN 0–201–89527–7 [Vic66] Vickery, B.C.: Faceted classification schemes. Bd. 5. Graduate School of Library Service, Rutgers, the State University, 1966 [Vog06] Vogler, P.: Prozess-und Systemintegration: Umsetzung des organisatorischen Wandels in Prozessen und Informationssystemen. Deutscher Universitätsverlag, zugl. Habilitation, Universität St. Gallen 2004, 2006 [Wag06] Wagner, Holger: Der Entwicklungsaufwand der Anwendungssystemintegration: Eine empirische Untersuchung der Einflussfaktoren, Universität zu Köln, Diss., 2006 [WBF+ 09] Winter, Robert ; Brocke, Jan v. ; Fettke, Peter ; Loos, Peter ; Junginger, Stefan ; Moser, Christoph ; Keller, Wolfgang ; Matthes, Florian ; Ernst, Alexander: Patterns in der Wirtschaftsinformatik. In: Wirtschaftsinformatik 51 (2009), Nr. 6, S. 535–542 40 [ZH07] Zdun, Uwe (Hrsg.) ; Hvatum, Lise B. (Hrsg.): EuroPLoP’ 2006, Eleventh European Conference on Pattern Languages of Programs, Irsee, Germany, July 5-9, 2006. UVK Universitätsverlag Konstanz, 2007 . – ISBN 978–3–87940–813–9 [ZMAV08] Zhao, L. ; Macaulay, L. ; Adams, J. ; Verschueren, P.: A pattern language for designing e-business architecture. In: The Journal of Systems & Software 81 (2008), Nr. 8, S. 1272–1287 41 42 Softwareentwicklung im Full-Service E-Commerce Peter Hänsgen1 , Heiko Kern2 1 Intershop Communications AG Intershop Tower 07740 Jena p.haensgen@intershop.de 2 Universität Leipzig, Institut für Informatik, Abteilung Betriebliche Informationssysteme Johannisgasse 26 04103 Leipzig kern@informatik.uni-leipzig.de Kurzfassung: E-Commerce ist ein komplexes Geschäftsmodell, welches in einem globalen Maßstab für kleine und mittlere Unternehmen nur schwer alleine erfolgreich zu bewältigen ist. Einen Ausweg bietet das Outsourcing der E-Commerce-Aktivitäten zu einem externen Dienstleister, dem Full-Service-Anbieter. Im Gegensatz zu herkömmlicher E-Commerce-Software, welche jeweils speziell für einen einzelnen Kunden erstellt und betrieben wird, stellt ein solches Mandanten-Szenario besondere Anforderungen an die Entwicklung der Software für den Full-Service-Anbieter, welche in diesem Artikel diskutiert werden. 1 Einleitung E-Commerce, also der elektronische Handel mit Gütern und Dienstleistungen über das Internet, ist ein aktuell mit enormem Tempo wachsender Wirtschaftszweig. Diese Entwicklung wird sich nach aktuellen Prognosen auch in den nächsten Jahren fortsetzen [Hau10]. Dennoch darf nicht darüber hinweggesehen werden, dass nach Erfahrung der Autoren die Einrichtung und der erfolgreiche Betrieb einer E-Commerce-Anwendung wie z. B. eines Online-Shops für B2C-Kunden oft mit beträchtlichen Hürden verbunden ist. Dabei sind einerseits technische Probleme zu lösen, andererseits auch operative Tätigkeiten und Schwierigkeiten zu meistern. Im Folgenden werden, ohne Anspruch auf Vollständigkeit, einige typische Bereiche exemplarisch benannt, die bei der Umsetzung einer E-Commerce-Strategie zwingend betrachtet und umgesetzt werden müssen: Shop-Technologie: Es wird eine Shop-Software benötigt, welche den Shop im Internet für die Kunden zur Verfügung stellt. Grundsätzlich kann die Software komplett neu entwickelt werden, aber oft ist es günstiger, ein existierendes Standardprodukt zu verwenden und anzupassen. 43 Implementierung: Die Software muss um fehlende Funktionen erweitert werden oder existierende Funktionen sind anzupassen. Die Integration mit einer bereits vorhandenen IT-Infrastruktur ist zu implementieren. Die Installation muss eingerichtet werden. Design: Der Webauftritt muss grafisch gestaltet werden, so dass er für die angepeilte Zielgruppe attraktiv ist. Ergonomie und Barrierefreiheit müssen gewährleistet werden. Hosting: Die Shop-Software muss in einem Rechenzentrum betrieben werden. Dabei fallen typische administrative Tätigkeiten an, wie die Bereitstellung und Wartung der benötigten Hardware, Betriebssysteme und weiteren Softwaresysteme wie Datenbanken usw. Weiterhin muss die Datensicherheit gewährleistet werden, es sind Backups zu erstellen usw. Inhaltserstellung: Die Inhalte, welche im Shop dargestellt werden sollen, müssen erstellt werden. Dies beinhaltet die Beschreibungen von Produkten, Abbildungen, Testberichte, technische Datenblätter, Pflegeanleitungen, Aufbauanleitungen usw. Oft müssen Daten von verschiedenen Quellen (z. B. Lieferanten, Herstellern) aggregiert und aufbereitet werden. Die Versionierung der Inhalte (z. B. für Sommer- und Winterkatalog) kann notwendig sein. Online Marketing: Der Shop muss im Netz beworben werden, um potentielle Kunden zu erreichen. Die Angebote müssen in Suchmaschinen gefunden werden, es müssen MarketingMaßnahmen durchgeführt werden, die Webseite sollte personalisiertes Verhaltung aufweisen, Gutscheine müssen verwaltet werden, Affiliates müssen angebunden werden. Fulfillment: Fulfillment bezeichnet die eigentliche logistische Abwicklung einer Bestellung. Es umfasst Dinge wie die Auftragserfassung, -bearbeitung und -korrektur, Fakturierung, Bestandsverwaltung, Lagerhaltung, Auslieferung, Exportbearbeitung, Frachtkoordination und Versand, Retourenannahme, Debitorenverwaltung und Inkasso. Bezahlvorgänge: Gekaufte Artikel müssen bezahlt werden, dazu sind verschiedene Zahlungsmethoden zu unterstützen. Der Bezahlvorgang muss weitere Faktoren berücksichtigen, wie Transportkosten, notwendige Bestellkorrekturen wegen Nichtlieferbarkeit, Rückbuchung nach Stornierungen usw. Validierungen und Bonitätsprüfungen: Angaben des Kunden wie z. B. Rechnungs- und Lieferadressen sind ggf. auf ihre Korrektheit zu überprüfen. Für bestimmte Zahlungsarten (z. B. Ratenzahlung) sind Informationen über die Bonität der Kunden einzuholen. Call Center: Für telefonische Rückfragen der Kunden nach einer Bestellung, z. B. zur Beratung, Reklamation, Stornierung oder zur Beantwortung von anderen Fragen ist eine Kontaktmöglichkeit bereitzustellen. Customer Relationship Management: Die Kundenbasis ist zu pflegen und zu analysieren, um den Online-Umsatz zu steigern. Multi-Channel Integration: Falls neben dem Online-Auftritt noch stationäre Niederlassungen existieren, sind möglicherweise verschiedene Absatzkanäle miteinander zu synchronisieren und zu vernetzen. Werbemaßnahmen zwischen der Online- und der Offline-Welt müssen abgestimmt werden, online erworbene Artikel können möglicherweise im Laden abgeholt oder zurückgegeben werden. 44 Business Intelligence: Der Erfolg des Auftritts ist zu messen, wichtige Kennzahlen sind zu erfassen und in geeigneten Reports auszuwerten. Mit den ermittelten Daten muss der gesamte Online-Auftritt sowie der Rest des Prozesses optimiert werden. Dazu ist ein Reporting über die gesamte Prozesskette notwendig. Rechtliche Situation: Für den jeweiligen Zielmarkt existieren rechtliche Rahmenbedingungen, welche einzuhalten sind. Dies betrifft Dinge wie AGB’s, Altersklassifikationen, Rückgabefristen usw. Für jeden der genannten sowie die zahlreichen weiteren Bereiche ist durch den Betreiber der ECommerce-Anwendung technisches und fachliches Wissen aufzubauen. E-Commerce ist ein sich ständig wandelndes Geschäft, so dass ein permanenter Aufwand zur Entwicklung und Pflege entsteht. Der Shop ist niemals „fertig“, sondern unterliegt einer ständigen Weiterentwicklung und Verbesserung. Wenn man dabei noch berücksichtigt, dass wir im Zeitalter der Globalisierung leben und die genannten Punkte in der Zukunft auch auf einer globalen Ebene betrachtet und gelöst werden müssen, wird verständlich, dass typische kleine oder mittlere Unternehmen, welche ECommerce betreiben und sich so einen neue Absatzkanal erschließen möchten, damit überfordert sind. 2 Full-Service E-Commerce als Geschäftsmodell Eine mögliche Lösung des Problems liegt in der Etablierung eines neuen Geschäftsmodells, bei dem E-Commerce als Outsourcing-Prozess betrachtet wird. Dabei werden die komplette Einrichtung und der komplette operative Betrieb der E-Commerce-Seite (also des Online-Shops) von einem Spezialisten, dem Full-Service-Anbieter übernommen. Das Modell stellt damit eine Fortsetzung des Outsourcing-Gedanken dar, welcher sich gegenwärtig unter dem Stichwort „Cloud Computing“ besonderer Popularität erfreut [Ree09]. In der aktuellen Diskussion geht es dabei vor allem um die Auslagerung von IT-Dienstleistungen in verschiedensten Formen wie Platformas-a-Service (PaaS), Infrastructure-as-a-Service (IaaS) oder Software-as-a-Service (SaaS). Das Full-Service-Modell ist die konsequente Fortführung dieses Trends über den Rahmen von ITDienstleistungen hinaus, indem vollständige Geschäftsprozesse ausgelagert werden. Es stellt nicht nur „weiche Dienste“ (also Software) bereit, sondern beinhaltet auch „harte Dienste“, wie Lagerhaltung, Transport usw. Jede E-Commerce-Anwendung ist einzigartig. Es gibt wesentliche Unterschiede im „Look & Feel“ für den Kunden und den verfügbaren Funktionen. Diese Unterschiede lassen sich auch nicht eliminieren, denn sie sind ein wesentliches Alleinstellungsmerkmal und ein grundlegender Bestandteil der Marketingstrategie jedes Unternehmens. Damit wird es immer erforderlich sein, eine Full-Service-Anwendung gemäß den Wünschen und den Bedürfnissen des Mandanten anzupassen. Es entsteht also ein grundlegender Interessenskonflikt zwischen dem Mandanten und dem Full-Service-Anbieter, für den ein geeigneter Kompromiss gefunden werden muss: Individualisierte Lösung: Der Mandant wünscht sich ein maßgeschneidertes System, welches exakt auf ihn zugeschnitten ist und seine Bedürfnisse erfüllt. Gleichzeitig möchte er von 45 den Vorteilen des Outsourcing profitieren, d. h. seine E-Commerce Aktivitäten vollständig auslagern, schnell online gehen und nach Bedarf skalieren können. Standardisierte Lösung: Aus Sicht des Full-Service-Anbieters muss jedoch so ein System aus möglichst vielen Standardkomponenten bestehen und möglichst wenig individuelle Merkmale enthalten, um die erforderlichen Implementierungsaufwände für ihn zu minimieren. Er möchte möglichst viele Mandanten auf einer einheitlichen Plattform betreiben. Der Full-Service-Anbieter kann in vielen Fällen selbst nicht die vollständige E-Commerce-Prozesskette aus einer Hand anbieten. Er tritt zwar gegenüber dem Mandanten als Generalunternehmer auf, ist aber gezwungen, selbst einzelne Bestandteile des Prozesses an andere Anbieter auszulagern bzw. von ihnen einzukaufen. Als Folge entsteht ein komplexes Geflecht von Integrationen mit Systemen weiterer Anbieter, welches in Abbildung 1 beispielhaft dargestellt ist. Die Integration muss einerseits auf einer technischen Ebene erfolgen, andererseits sind entsprechende organisatorische und vertragliche Voraussetzungen (z. B. Service Level Agreements) zu schaffen. Im Gegensatz zum klassischen E-Commerce, bei dem ein Softwareunternehmen, welches an der Programmierung und der Installation der Shop-Software beteiligt ist, vor allem über die Lizenzierung der Software und über Beratungsleistungen Umsatz generiert, ist bei einem Full-ServiceModell eine Beteiligung am Umsatz des Online-Shops üblich. Damit findet aus Sicht des Softwareunternehmens, welches als Full-Service-Anbieter auftreten möchte, eine Lastenumkehr statt: die Implementierungskosten für die Anpassung der Software äußern sich nicht mehr als Einnahmen, sondern als Kosten. Für eine erfolgreiche Umsetzung des Geschäftsmodells sind also zur klassischen Softwareherstellung völlig entgegengesetzte Ziele anzuvisieren: Maximierung des Online-Umsatzes: Der Full-Service-Anbieter ist aufgrund seiner Umsatzbeteiligung daran interessiert, den Umsatz des Shops zu steigern. Minimierung der Kosten: Der Full-Service-Anbieter muss gleichzeitig die Kosten für die Einführung neuer Mandanten und die Pflege existierender Systeme minimieren. Aus diesen Rahmenbedingungen ergeben sich Anforderungen an die Software für Full-ServiceSysteme, welche im folgenden Kapitel 3 näher betrachtet werden. Die Betrachtung beschränkt sich an dieser Stelle vorrangig auf nicht-funktionale Anforderungen, welche die wichtigsten Qualitätsmerkmale [Mic09] eines Full-Service-Systems betreffen. Die eigentlichen funktionalen Anforderungen bezüglich der konkreten E-Commerce-Prozesse würden den Rahmen dieses Beitrags sprengen. Sie sind auch nicht allgemeingültig für andere Full-Service-Scenarien, so dass sie an dieser Stelle nicht näher betrachtet werden können. 3 Anforderungen an Full-Service-Anwendungen 3.1 Integrationsfähigkeit Ein Full-Service-Anbieter kann in der Regel nicht alle benötigten Schritte aus der E-CommerceWertschöpfungskette selber anbieten. Er ist daher gezwungen, zahlreiche andere Systeme von 46 Fulfillment Versand Lager Warenwirtschaft Rücksendung Warenlieferung Produktdaten Berichte Retouren Lieferankündigung Bestellstatus Produktdaten Lagerbestand Kommunikation Berichte Mandant Bestellungen Buchhaltung Geld E-Mail Waren Kunde Bestellung E-Mail Payment-Anbieter Full-Service-Anwendung Kundendaten Shop Manager Steuerung Prüfung, Reservierung Kataloge Adressvalidierung Adressprüfung Produkte Preise Bonitätsprüfung Bonitätsprüfung Abbildung 1: Vereinfachtes Beispiel für ein Full-Service-E-Commerce-Szenario externen Dienstleistern in seine Plattform zu integrieren. Weiterhin wird es notwendig sein, auch die existierenden IT-Systeme der Full-Service-Mandanten zu berücksichtigen. Entsprechend der jeweiligen Zielarchitektur müssen auch hier zahlreiche Systeme miteinander verbunden werden. Es ist in Praxis in der Regel nicht möglich, die denkbaren Integrationen mit externen Systemen auf eine kleine Menge von Standardprotokollen (z. B. XML-Webservices) zu beschränken. Ganz im Gegenteil, in der Realität existieren oftmals eine große Zahl von proprietären Schnittstellen und Protokollen, welche jeweils separat für jedes anzubindende System zu implementieren und zu unterstützen sind. Lösungsstrategien: Existierende Konzepte aus dem Bereich der Service-orientierten Architekturen (SOA) [Lie07] können aufgegriffen und genutzt werden. Typische Integrationsmuster sind zu identifizieren und umzusetzen, um die Variantenvielfalt einzudämmen und den Pflegeaufwand zu reduzieren. Es muss eine Menge von Standardanbindungen entwickelt werden, die projektübergreifend wiederverwendet werden können und aus der für neue Projekte eine Auswahl getroffen werden kann. 47 3.2 Anpassbarkeit Die Individualisierung des Auftritts für einen Mandanten ist unumgänglich, also muss die Plattform so gestaltet sein, dass sie einfache Mechanismen zur Anpassung an spezifische Wünsche und zur Erweiterung um fehlende Funktionalitäten erlaubt. Betroffen sind alle Anwendungsteile, angefangen von der Präsentationsschicht bis hin zur Datenschicht oder zur Integration externer Mandantensysteme. Lösungsstrategien: Definition von expliziten Schnittstellen zur Anpassung. Klare Trennung von Anpassungen und Standardprodukt. Ev. Nutzung von MDSD-Konzepten zur Modellierung von Anpassungen [SV06]. 3.3 Wiederverwendbarkeit Die Kosten für die Einführung neuer Mandanten lassen sich nur minimieren, indem eine maximale Wiederverwendung von existierenden Software-Komponenten und Prozessen zwischen verschiedenen Mandanten erreicht wird. Lösungsstrategien: Ein gangbarer Weg ist es, für verschiedene Bereiche der Anwendung mehrere alternative Standardkomponenten anzubieten, aus welchen die für den Mandanten am besten geeignete Kombination ausgewählt werden kann. Dabei ist zu beachten, dass nicht alle Kombinationsmöglichkeiten zulässig sind. So kann beispielsweise nicht jeder Fulfillment-Anbieter mit allen Zahlungsmethoden umgehen, oder ein Anbieter von Bonitätsüberprüfungen kann diese Dienstleistungen nur für ein bestimmtes Land oder eine bestimmte Region zur Verfügung stellen. Die Zulässigkeit von Kombinationen muss daher vorab explizit ausgedrückt werden und bei der Planung des Systems überprüfbar sein. Abbildung 2 zeigt ein Beispiel für Abhängigkeiten bei der Komponentenauswahl. 3.4 Komposition zur Laufzeit Das herkömmliche Produktlinienvorgehen, bei dem mittels Featuremodellen und Variantenmodellen kundenspezifische Softwareprodukte gemäß der ausgewählten Feature-Kombination erzeugt werden [GCS04], kann in einer Full-Service-Anwendung oft nicht genutzt werden. Es soll schließlich nicht für jeden Mandanten ein völlig neues Softwareprodukt erzeugt werden, sondern er muss aus Gründen des Resourcen-Sharings gemeinsam mit anderen Mandanten in der gleichen Umgebung („Shared Environment“) gehostet werden. Damit ergibt sich die Notwendigkeit, aus der Gesamtheit der zur Verfügung stehenden Funktionalität eine spezifische Auswahl und Konfiguration für einen Mandanten erst zur Laufzeit zu kombinieren. Ein Mandantensystem ist also nur durch eine logische Sicht repräsentiert, aber nicht notwendigerweise durch eine physisch getrennte Installation. 48 Abbildung 2: Vereinfachtes Beispiel für ein Full-Service-E-Commerce-Szenario Neben dem Betrieb von verschiedenen Mandanten auf einer geteilten Instanz gibt es noch weitere Gründe, welche die Nutzung verschiedener Komponenten zur Laufzeit erfordern. So kann es beispielsweise notwendig sein, in einem System, welches eine globale Reichweite haben soll, je nach Herkunft des Kunden verschiedene externe Dienstleister zu integrieren oder einen unterschiedlichen Funktionsumfang des Shops anzubieten. So müssen z. B. für die Adressvalidierung von Kundenadressen je nach Region des Kunden verschiedene Dienstleister genutzt werden, weil jeder nur eine bestimmte Region abdecken kann. Prinzipiell könnte dabei jeder beliebige Laufzeitparameter als Kriterium für die Auswahl einer zu nutzenden Software- bzw. Prozesskomponente dienen. Lösungsstrategien: Die Anwendung für einen Mandanten muss komplett zur Laufzeit beschrieben werden, d. h. es wird ein Anwendungsmodell in der Full-Service-Plattform benötigt. Dies kann analog zu bekannten Konzepten aus Produktlinienvorgehen gestaltet sein, allerdings wird es zur Konfiguration des Systems zur Laufzeit benutzt und nicht zur Erzeugung seiner Implementierung. 3.5 Portabilität Ein primäres Ziel des Online-Shops ist sein Umsatzwachstum. Ausgehend von einem kleinen System wird bei steigenden Umsätzen und damit steigender Last eine immer größere und aufwändigere Systemlandschaft benötigt. Folgendes Szenario ist vorstellbar: • Shared Environment: Zu Beginn wird der Shop als ein neuer Mandant in einem „Shared Environment“ eingerichtet, d. h. viele Mandanten teilen sich die gleichen Ressourcen. 49 • Dedicated Environment: Bei erfolgreichem Wachstum wird der Ressourcenbedarf des Mandanten irgendwann zu groß für eine geteilte Umgebung, so dass er in einen eigenen Bereich („Dedicated Environment“) umzieht. • Insourcing: Theoretisch kann es bei weiterem Wachstum zu der Situation kommen, dass die ursprünglichen Vorteile, die sich für den Mandanten durch das Outsourcing ergeben haben, vollständig obsolet geworden sind. Damit kann es notwendig sein, dass gesamte System zum Mandanten zurückzuholen und unter seiner eigenen Regie „inhouse“ zu betreiben. Lösungsstrategien: Die Full-Service-Plattform kann aus Mandantensicht wie eine „virtual machine“ aufgefasst werden, welche die Laufzeitumgebung für seine spezifische Konfiguration darstellt. Ein Umzug würde damit die Instantiierung seiner Konfiguration (d. h. seiner mandantenspezifischen Daten und Anpassungen) in einer anderen Laufzeitumgebung bedeuten. Wird die Full-Service-Plattform als eigenständiges Softwareprodukt angeboten, ist ihr Betrieb auch außerhalb des Full-Service-Anbieters möglich. 3.6 Wartbarkeit Ein Full-Service-System kann potentiell auf eine große Anzahl von Mandanten, die auf der gleichen Plattform betrieben werden, anwachsen (»100). Die Menge an Mandanten stellt besondere Anforderungen und erfordert besondere Maßnahmen hinsichtlich der Migrationsfähigkeit und Wartbarkeit der Plattform. Es muss möglich sein, innerhalb kürzester Zeiträume das System auf eine neue Softwareversion zu heben, ohne den laufenden Betrieb der E-Commerce-Aktivitäten signifikant zu beeinträchtigen. Lösungsstrategien: Der Prozess der Migration kann in zwei Schritte zerlegt werden: in eine Vorbereitungsphase und in eine operative Phase. In der Vorbereitungsphase erfolgt zunächst die Ermittlung notwendiger Korrekturen, die Anpassung des mandantenspezifischen Codes an die neue Version, die Erprobung von automatischen Migrationsschritten mit Migrationswerkzeugen usw. Die operative Phase umfasst anschließend die eigentliche Migration des laufenden Systems. Die Migration lässt sich durch verschiedene Maßnahmen vereinfachen: • API-Stabilität: Das System sollte grundsätzlich eine stabile API besitzen. Neue Versionen sollten abwärtskompatibel sein, sofern möglich. Veraltete API’s müssen markierbar sein, um ihre weitere Nutzung schrittweise zu reduzieren. • Erweiterungskonzept: Das System sollte genau definierte Erweiterungspunkte bereitstellen, welche für Anpassungen genutzt werden können. Damit können die durchgeführten Anpassungen später sehr leicht identifiziert werden. Definierte Erweiterungspunkte sind auch einfacher noch langfristig zu unterstützen. • Differenzberechnung: Änderungen zwischen Versionen müssen genau ermittelbar sein, um Migrationsaufwände und potentielle Risiken rechtzeitig abschätzen zu können. 50 • Werkzeugunterstützung: Die Migration sollte möglichst durch automatische Werkzeuge unterstützt werden, welche Code- und Datenmigrationen durchführen können. 3.7 Verfügbarkeit Im Online-Handel, insbesondere im B2C-Handel, stellt die Verfügbarkeit des Shops eine zunehmend wichtigere Kenngröße dar. Einerseits steigen die erzielten Umsätze permanent, so dass der Shop immer wichtiger wird und Ausfallzeiten immer weniger toleriert werden können. Andererseits gibt es im Zuge der Globalisierung immer weniger Zeiträume, in denen Wartungsmaßnahmen durchgeführt werden können und das System zu diesem Zwecke einfach „offline“ geschaltet werden kann. Die Sicherstellung einer maximalen Verfügbarkeit ist damit ein primäres Entwurfsziel für Full-Service-Anwendungen. Lösungsstrategien: Die Gesamtverfügbarkeit eines Systems ergibt sich aus dem Produkt der Einzelverfügbarkeiten der Subsysteme. Um die Gesamtverfügbarkeit aus Sicht des Kunden, der einen Online-Shop benutzt, zu maximieren, muss also die Anzahl der Systeme, die an der Bearbeitung seiner Aktionen unmittelbar beteiligt sind, minimiert werden, sowie die Einzelverfügbarkeit maximiert werden. Dem gegenüber steht allerdings die Notwendigkeit der Integration zahlreicher externer Systeme, welche die Gesamtverfügbarkeit verschlechtern. • Redundanz: Mehrfache Auslegung aller Systeme, erhöht allerdings die Kosten. Eine Abwägung muss stattfinden, ob die erhöhten Einnahmen die erhöhten Kosten rechtfertigen. • Entkoppelung: Entkoppelung von nachgelagerten Systemen durch asynchrone Verarbeitung. • Erhöhung der Fehlertoleranz: Fehlertolerantes Design der Anwendung, so dass sie auf Fehler reagieren kann, ohne den kompletten Prozess abbrechen zu müssen. Beispielsweise kann eine Retry-Logik versuchen, einen Vorgang mehrfach zu wiederholen, bis er irgendwann erfolgreich war. 3.8 Skalierbarkeit Skalierbarkeit aus technischer Sicht bezeichnet die Fähigkeit des Systems, durch das Hinzufügen weiterer Ressourcen seine Verarbeitungskapazität zu erhöhen. Sehr oft wird dabei an die Erhöhung der Hardwarekapazität zur Erhöhung der möglichen Anzahl paralleler Nutzer gedacht, aber diese Sichtweise ist nicht ausreichend. Im E-Commerce existieren zahlreiche verschiedene Geschäftsmodelle, welche jeweils durch verschiedene Mengengerüste charakterisiert werden können. Im B2C-Umfeld sind beispielsweise sehr große Nutzerzahlen und „Page Impressions“ typisch, während im B2B-Bereich oft zahlreiche externe Systeme von Lieferanten und Geschäftspartnern zu integrieren sind. Große Unterschiede gibt es auch in den verschiedenen Industriebereichen. So sind in dem einen Online-Shop 51 mehrere Millionen verschiedene Produkte zu verwalten, während ein anderer Shop vielleicht nur wenige Hundert Produkte im Sortiment hat. Das Full-Service-System muss also hinsichtlich jeder denkbaren Größe skalieren können: von wenigen Nutzern bis zu Millionen von Nutzern, von wenigen Produkten bis zu Millionen von Produkten, von wenigen Artikeln pro Bestellung bis zu Hunderten von Artikeln pro Bestellung usw. Lösungsstrategien: Die typischen Maßnahmen zur technischen Skalierung (Redundanz, Load Balancing usw.) müssen natürlich unterstützt werden. Es ist aber nicht ausreichend, Skalierbarkeit nur als einen Parameter der Ausbaufähigkeit des Systems durch das Hinzufügen von neuer Hardware zu betrachten. Es muss auch eine funktionale Anpassung der Applikation an die jeweiligen Zielgrößen stattfinden. Dabei ist es oft nicht möglich, eine Lösung zu finden, die alle Kriterien gleichzeitig gleich gut erfüllen kann. Stattdessen muss die Plattform es erlauben, aus verschiedenen Alternativen, die jeweils für unterschiedliche Kennzahlen optimiert wurden, eine für den jeweiligen Mandanten geeignete Auswahl zu treffen. 3.9 Performance Der gleichzeitige Betrieb mehrere Mandanten auf der gleichen Laufzeitumgebung kann zu Performance-Interferenzen zwischen ihnen führen. Wenn einer oder mehrere Mandanten zugleich rechen- oder datenintensive Prozesse starten, kann sich dies auch negativ auf die Performance des Shops für andere Mandanten auswirken. Insbesondere für die Storefront, also das Web-Interface für die Online-Kunden, müssen solche Effekte vermieden werden. Lösungsstrategien: • Hardware-Skalierung: Einsatz von mehr Hardware zur Erhöhung der Verarbeitungskapazität, bedeutet aber auch höhere Kosten. • Offline-Processing: Durchführung von rechen- oder datenintensiven Vorgängen in separaten Backend-Systemen, Entkopplung der Online-Last von der Backend-Last. 3.10 Sicherheit Das Vertrauen der Kunden in die Sicherheit eines Shops ist essentiell für den Online-Handel. Daneben muss auch der Full-Service-Mandant darauf vertrauen können, dass seine Geschäftsdaten beim Full-Service-Anbieter in guten Händen sind. Die Full-Service-Plattform muss darum sicherstellen, dass sämtliche Daten und Funktionen nur für authorisierte Personen sichtbar und ausführbar sind, um Datenverluste, Datendiebstahl oder Datenmanipulationen auszuschließen. Mandanten müssen voneinander isoliert werden. 52 4 Zusammenfassung Full-Service E-Commerce ist ein neues Geschäftsmodell, welches besondere Herausforderungen an die Erstellung der Software hinsichtlich ihrer Qualitätsmerkmale, ihres Funktionsumfangs, ihres Entwicklungsprozesses und ihres Einsatzes stellt. Im Beitrag wurden einige wesentliche Punkte beschrieben und mögliche Lösungsstrategien aufgezeigt. Existierende Techniken wie SOA, Produktlinien-Technologien oder Modellgetriebene Softwareentwicklung sind für die Lösung der Teilprobleme zwar hilfreich, aber oftmals nicht ausreichend, weil sie sich vor allem auf die traditionelle Entwicklung von statischen Softwareanwendungen konzentrieren. Im Full-Service-Bereich tritt aber die Komposition von Anwendungen zur Laufzeit einer FullService-Plattform in den Vordergrund. Es ist daher notwendig, dieses Verhalten näher zu untersuchen und Softwarearchitekturen und Methoden zu entwickeln, welche die Dynamik und die spezifischen Anforderungen von Full-Service-Anwendungen in geeigneter Weise berücksichtigen. Neue Anwendungen müssen durch die Rekombination existierender Komponenten auf Basis einer einheitlichen Plattform als Laufzeitumgebung möglichst ohne jeglichen Programmieraufwand erstellbar sein. Literatur [GCS04] Greenfield, Jack ; Cook, Steve ; Short, Keith: Software factories: Assembling applications with patterns, models, frameworks, and tools. Indianapolis, Ind : John Wiley & Sons, 2004. – ISBN 978–0471202844 [Hau10] Hauptverband des Deutschen Einzelhandels: E-Commerce-Umsatz 2010: HDE erwartet 23,7 Mrd. Euro. http://www.ebusiness-handel.de/pb/site/eco/node/142076/Lde/index. html. Version: 2010. – letzter Aufruf 10.1.2011 [Lie07] Liebhart, Daniel: SOA goes real: Service-orientierte Architekturen erfolgreich planen und einführen. München : Hanser Fachbuchverlag, 2007. – ISBN 978–3446410886 [Mic09] Microsoft Application Architecture Guide. 2nd edition. [Redmond, Wash.] : Microsoft Press, 2009. – ISBN 978–0735627109 [Ree09] Reese, George: Cloud Application Architectures: Building Applications and Infrastructure in the Cloud]. Sebastopol, CA : O’Reilly Media, Inc., 2009. – ISBN 978–0596156367 [SV06] Stahl, Thomas ; Völter, Markus: Model-Driven Software Development – Technology, Engineering, Management. John Wiley & Sons Inc., 2006. – ISBN 978–0470025703 53 54 Erweiterung eines MDSD-Systems zur Unterstützung von Produktlinien duch Feature-Modelle∗ Rolf-Helge Pfeiffer, Peter Hänsgen Intershop Communications AG Intershop Tower 07740 Jena h.pfeiffer@uni-jena.de, p.haensgen@intershop.de Kurzfassung: Featuremodelle sind eine Schlüsseltechnologie für die Modellierung von Softwareproduktlinien. Sie können als höchste Abstraktionsstufe in der modellgetriebenen Softwareentwicklung eingesetzt werden. Besteht schon eine Infrastruktur zur modellgetriebenen Softwareentwicklung, d. h. Modelltransformatoren und Codegeneratoren existieren bereits, so wirft die Einführung von Softwareproduktlinien in eine solche Infrastruktur Probleme auf. Diese Arbeit beschreibt eine bestehende Infrastruktur zur modellgetriebenen Softwareentwicklung, mögliche Änderungen daran zur Unterstützung von Softwareproduktlinien und stellt eine Lösung mittels Aspektmodellen vor. 1 Einleitung Softwareproduktlinien werden bisher auf Quellcodeebene [pur08] oder auf einzelnen Modellen [AC04], die zur Quellcodegenerierung genutzt werden, implementiert. Das Konzept der Modellgetriebenen Softwareentwicklung (MDSD) wurde in den letzten Jahren so verbessert, dass es in der Praxis mehr und mehr akzeptiert und zur Softwareentwicklung eingesetzt wird. Im Zuge dieser Fortentwicklung sind Werkzeuge wie das Eclipse Modeling Framework (EMF) [emf08] oder openArchitectureWare (oAW) [oaw08b] entstanden und stehen für den Entwickler zur Verfügung. Das Hauptaugenmerk der Softwareentwicklung verschiebt sich deshalb von der Entwicklung von Quellcode hin zur Entwicklung von Modellen. Softwarehersteller wie Intershop tätigten hohe Investitionen, z. B. für die Entwicklung von Metamodellen, Modelltransformatoren und Codegeneratoren, um MDSD in den Softwareentwicklungsprozess zu integrieren. Aufgrund der Tatsache, dass Intershop Softwareprodukte herstellt, die eine Systemfamilie formen, und da einzelne Produkte einer Systemfamilie effizient duch den Einsatz von Produktlinien hergestellt werden können, ist der folgerichtige Schritt die Einführung der Unterstützung von Produktlinien in die bestehende MDSD-Infrastruktur. Diese Arbeit beschreibt, wie eine bestehende MDSD-Infrastruktur angepasst werden kann, um Softwareproduktlinien zu unterstützen. Dazu werden um Aspektmodelle angereicherte Feature∗ Publiziert in Proceedings of the Second Workshop on MDSD Today 2008, Hrsg.: Peter Friese, Simon Zambrovski, Frank Zimmermann. Shaker Verlag GmbH, Oktober 2008. 55 modelle genutzt. Es stellt sich die Frage, wie die Informationen über Variabilität, die in den Featuremodellen ausgedrückt sind, in den Prozess der automatischen Softwaregenerierung einbezogen werden können. Diese Arbeit ist wie folgt strukturiert: Im Abschnitt 2 werden wichtige Begriffe und Definitionen eingeführt. Abschnitt 3 stellt eine bestehende MDSD-Infrastruktur vor. Im darauffolgenden Abschnitt wird erklärt, wie Feature- und Aspektmodelle dazu genutzt werden können, um das Verhalten eines MDSD-Systems zu verändern. Anschließend werden themenbezogene Arbeiten in Abschnitt 5 vorgestellt und die Arbeit mit einem Fazit in Abschnitt 6 abgeschlossen. 2 Begriffe und Definitionen 2.1 Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung (MDSD) ist der Einsatz von Computerprogrammen zur Softwareentwicklung, welche Modelle ineinander transformieren oder beliebige textuelle Artefakte aus Modellen erzeugen. Modelle können u. a. verschiedene Abstraktionsebenen und technische Domänen beschreiben. Textuelle Artefakte sind Einheiten ohne ein präzise definiertes Metamodell, z. B. Quellcode in einer Programmiersprache, Konfigurationsdateien, Dokumentationen, usw. 2.2 Feature-Modellierung Wir benutzen den Begriff der Featuremodelle analog zu [CA05]. Featuremodelle sind Featurediagramme plus zusätzliche Informationen. Unter Features verstehen wir Systemeigenschaften, die Gemeinsamkeiten und Unterschiede von Systemen einer Familie ausdrücken und die für bestimmte Parteien von Bedeutung sind. Variantenmodelle sind Instanzen von Featuremodellen, die eine gültige Auswahl von Features enthalten. Featurediagramme sind grafische Repräsentationen von Features und deren Relationen. Zur Darstellung von Featurediagrammen gibt es eine Vielzahl von Notationen, z. B. [KCH+ 90, KLD02, Rie03, GFd98, KC04]. 2.3 Aspektorientierte Modellierung Aspektmodelle sind Modelle, die sich auf ein anderes Modell beziehen, nämlich auf ein Basismodell. Sie können als Differenzenmodelle verstanden werden. Sie beschreiben eine Differenz zwischen einem Basismodell und dem Modell, das beim Mischen von Aspektmodellen in ein Basismodell entsteht. Aspektmodelle können also positive und negative Variabilität in Bezug auf ein Basismodell ausdrücken. Dabei bedeutet positive Variabilität das Hinzufügen von Modellelementen und negative Variabilität das Entfernen von Modellelementen eines Basismodells. Wir nennen den Prozess der Anwendung von positiver und negativer Variabilität auf ein Basismodell, 56 anders als in aspektorientierten Programmiersprachen, nicht weben, sondern mischen, da aspektorientierte Programmiersprachen im Allgemeinen nicht das Entfernen von Programmkonstrukten erlauben. Analog zu [GV07] und da wir XWeave zur Implementierung der Transformation des Mischens von Modellen verwenden, werden in unserer Arbeit Aspekte asymmetrisch in Basismodelle gemischt, d. h. die Operation des Mischens von Modellen (Operator: ⊗) ist unidirektional. Beispiel: B ⊗ A = B’, wobei B ein Basismodell und A ein Aspektmodell ist. Die umgekehrte Reihenfolge der Operanden ist ungültig. 3 Ein existierendes MDSD-System Intershop ist ein führender Hersteller von E-Commerce-Software. MDSD wird als Schlüsseltechnologie zur Effizienzsteigerung in der Softwareentwicklung angesehen, darum wurde eine MDSD-Infrastruktur entwickelt, welche aus domänenspezifischen Modellen sowie kaskadierenden Modelltransformations- und Codegenerierungsschritten besteht. Abbildung 1 zeigt den schematischen Aufbau der aktuell verwendeten MDSD Infrastruktur. Die bunten Kästchen stellen domänenspezifische Modelle auf jeweils einem bestimmten Abstraktionsniveau dar. Die verschiedenen Abstraktionsniveaus werden in dieser Arbeit Modellierungsebenen genannt. Alle dargestellten Modelle wurden mit dem Eclipse Modeling Framework (EMF) entwickelt und basieren auf dem Metametamodell Ecore [emf08]. Abbildung 1: Ein MDSD System mit kaskadierender Transformation domänenspezifischer Modelle. Modelltransformatoren (vertikale Pfeile) und Codegeneratoren (horizontale Pfeile) wurden mittels openArchitectureWare [oaw08b] implementiert. Im Folgenden werden die verschiedenen Modellierungsebenen genauer beschrieben: DBM-Ebene: Auf dieser Modellierungsebene werden im Database Model (DBM) die Strukturen von Datenbanken definiert. Modelle dieser Ebene besitzen den geringsten Abstraktionsgrad innerhalb der Hierarchie, d. h. sie sind plattformspezifisch. Datenbankmodelle beschreiben z. B. Tabellen mit ihren Spalten und Constraints. ORM-Ebene: Modelle der Object Relational Mapping (ORM)-Ebene dienen der Modellierung von persistenten Geschäftsobjekten. Sie bieten einen höheren Abstraktionsgrad als Modelle 57 auf DBM-Ebene. Die zentralen Modellierungselemente sind ORM Beans und deren Relationen. Auf dieser Ebene sind z. B. Konzepte wie Vererbung von ORM Beans und 1-zu-n Relationen vorhanden. BOM-Ebene: Die Modelle der Business Object Model (BOM)-Ebene dienen der plattformunabhängigen Modellierung von persistenten Geschäftsobjekten und deren Relationen. BOMModelle bieten eine Sicht auf die darunter liegenden ORM-Modelle und eine Erhöhung des Abstraktionsgrades. So existieren z. B. Konzepte wie n-zu-m Relationen zwischen BOM Beans und Assoziations-BOM Beans. UML-Ebene: Zur Modellierung und Präsentation der Struktur von Softwaresystemen werden Unified Modeling Language (UML)-Klassendiagramme verwendet. Für Modelltransformationen von UML- auf BOM-Ebene werden die Modellelemente verwendet, die durch entsprechende Stereotypen, z. B. «BOM Bean», gekennzeichnet sind. Die Modelltransformatoren der bestehenden MDSD-Infrastruktur wurden mittels XTend [oaw08a] implementiert. Codegeneratoren zur automatischen Generierung von Java Quellcode, Dokumentationen, Konfigurationsdateien und anderer textueller Artefakte wurden mittels XPand [oaw08a] umgesetzt. Der in Abbildung 1 dargestellte Prozess von kaskadierenden Modelltransformationen und Codegenerierungsschritten wird durch einen openArchitectureWare-Workflow definiert. Die beschriebene MDSD-Infrastruktur ist zur Entwicklung verschiedenartiger, heterogener Softwaresysteme geeignet, welche die gleiche Architektur besitzen. Diese Infrastruktur ist folglich nicht dazu geeignet, verschiedene Produkte einer Softwaresystemfamilie, also Produkte, die viele Gemeinsamkeiten besitzen und sich nur in bestimmten Eigenschaften unterscheiden (homogene Systeme), effizient herzustellen. Intershop stellt E-Commerce-Systeme her, die alle Systeme einer Softwaresystemfamilie sind. Dadurch wird ein Produktlinienansatz zur Softwareherstellung interessant. Wie kann aber nun die bestehende MDSD-Infrastruktur verändert werden, um Variabilitäten zwischen einzelnen Produkten einer Familie zu berücksichtigen? Wie kann die existierende Infrastruktur angepasst werden, um Produktlinien zu unterstützen? Die folgenden Abschnitte stellen einen möglichen Lösungsansatz vor. 4 Steuerung eines MDSD-Systems durch Features Zur Modellierung von Gemeinsamkeiten und Unterschieden von Softwaresystemen einer Softwaresystemfamilie können Featuremodelle eingesetzt werden. Soll ein Featuremodell ein bestimmtes Softwaresystem definieren und soll weiterhin die bestehende MDSD-Infrastruktur verwendet werden, so muss ein Featuremodell in der Art angewendet werden, dass es alle nötigen Informationen zur automatischen Generierung eines Softwaresystems in Form von Modellen enthält, und es muss in der Lage sein, ein MDSD-System so zu steuern, dass die in Aspektmodellen ausgedrückte Variabilität berücksichtigt wird. Wir haben uns dazu entschieden, Features entsprechend der Definition von Featuremodellen mit zusätzlichen Informationen zu hinterlegen. Es sind unserer Ansicht nach zwei Arten von Features notwendig, um ein MDSD-System für die Entwicklung von Softwareproduktlinien einzusetzen. Das sind: 58 Aspektfeatures: Ein Feature, welches mit einem Aspektmodell hinterlegt wurde, ist ein Aspektfeature. In unserer Arbeit werden Aspektmodelle dazu verwendet, um Variabilität zwischen Softwaresystemen einer Familie zu kapseln. Weiterhin steuern Aspektfeatures die neu in das MDSD-System eingefügte Modelltransformation des Mischens von Modellen. Diese Transformation ist durch den Operator ⊗ in Abbildung 2 markiert. Steuerfeatures: Features, die steuern, ob ein bestimmter Modelltransformator oder Codegenerator in einem MDSD-System aufgerufen wird, heißen Steuerfeatures. In Abbildung 2 sind sie durch graue Kreise über Modelltransformatoren und Codegeneratoren symbolisiert. Zentral für die Umsetzung des Produklinienansatzes ist in unserem Fall die Implementierung einer Modelltransformation, die es erlaubt, Aspektmodelle, welche Informationen über Variabilität enthalten, in ein Basismodell zu mischen. Damit kann ein maßgeschneidertes Modell erzeugt werden, aus dem anschließend das Softwaresystem generiert werden kann. Der Ansatz der Einführung einer neuen Transformation zum Mischen erlaubt die Wiederverwendung bereits bestehender Modelltransformatoren und Codegeneratoren. 4.1 Implementierung des Mischens von Aspektmodellen Wie Abbildung 2 zeigt, nutzt unsere Implementierung zum Mischen von Modellen die oAW Komponenten XVar und XWeave. Im Folgenden wird erklärt, wie das Mischen von Modellen genau funktioniert. 4.1.1 Notation von Aspektmodellen Um das Modellieren von Aspekten auf UML-Ebene zu ermöglichen, wurde ein UML Profil um Stereotypen, die das Ausdrücken von Regeln zum Mischen von Aspekt- und Basismodellen und das Ausdrücken von positiver und negativer Variabilität erlauben, erweitert. Alle im Folgenden vorgestellten Stereotypen sind auf die UML-Modellelemente Class und Property anwendbar. Weiterhin ist es möglich, sie parallel zu der Notation, die von XWeave [GV07] bereitgestellt wird, zu verwenden. «BOMBaseElement» Ein Modellelement mit diesem Stereotypen bezieht sich auf genau ein Modellelement in einem Basismodell, das den gleichen Namen besitzt. Es wird genutzt, um einen Pointcut zu definieren, der genau einem Joinpoint im Basismodel entspricht. «BOM XVar» Der Stereotyp besitzt die Property nameOfOwningFeature. Er dient der Spezifikation eines Elements im Basismodel, welches aus diesem entfernt wird, sobald das in nameOfOwningFeature angegebene Feature nicht im entsprechenden Variantenmodel enthalten ist. «BOM XWeave» Der Stereotyp besitzt die Property pointcutSpec. Er markiert Modellelemente, die zum Basismodell hinzugefügt werden sollen. Die Property pointcutSpec enthält die Deklaration einer Pointcutspezifikation. Ist diese Property leer, so wird das markierte Element im Basismodell zu dem 59 Abbildung 2: Erweiterung des MDSD-Systems aus Abbildung 1 zur Unterstützung von Produktlinien. 60 Modellelement hinzugefügt, welches den gleichen Namen besitzt. Ist in der Property ein Stern (*) enthalten, so wird das markierte Modellelement zu allen Beans des Basismodells hinzugefügt. Zur beliebigen Deklaration von Pointcutspezifikationen wird der Property der Name einer Pointcutfunktion gegeben, die mittels der XWeave-spezifischen Syntax manuell definiert werden muss. 4.1.2 Feature Dependency Model Ein Feature Dependency Model (FDM) ist ein Modell, welches von XVar benötigt wird, um negative Variabilität auf ein Basismodell anzuwenden. Ein FDM stellt Abhängigkeiten zwischen einem Feature und einem oder mehren Modellelementen eines Basismodells dar. Für alle vorhandenen Aspektmodelle wird ein FDM genau einmal automatisch generiert. Dazu extrahiert eine Modelltransformation alle Elemente der Aspektmodelle, die mit dem Stereotyp «XVar» markiert sind, und erstellt aus dem Wert, der in der Property nameOfOwningFeature enthalten ist, einen entsprechenden Eintrag im FDM. XVar bekommt als Eingabe ein Basismodell auf BOM-Ebene, ein Variantenmodell und ein FDM und generiert daraus ein temporäres Basismodell auf BOM-Ebene. Die Anwendung von XVar hängt nicht von den Metamodellen der entsprechenden Modelle ab, sondern setzt nur voraus, dass diese auf Ecore basieren. 4.1.3 Generierung von Pointcuts Im Gegensatz zu aspektorientierten Programmiersprachen können alle Modellelemente eines Basismodells als Joinpoints fungieren. Dies wird durch die Nutzung von XWeave zur Implementierung des Mischens von Modellen möglich. Die Namen von Modellelementen in Aspektmodellen werden genutzt, um auf Pointcutspezifikationen zu verweisen, siehe dazu [oaw08a]. Für jedes Aspektmodell auf UML-Ebene wird automatisch eine Datei mit den entsprechenden Pointcutspezifikationen erstellt. Dies geschieht in Abhängigkeit zur Property pointcutSpec des Stereotyps «BOM XWeave». Ist diese leer, so wird eine Pointcutspezifikation generiert, die das markierte Modellelement zu genau dem Modellelement des Basismodells hinzufügt, welches den gleichen Namen besitzt. Ist in der Property pointcutSpec ein Stern (*) enthalten, so wird eine Pointcutspezifikation generiert, die das markierte Element des Aspektmodells zu allen Klassen des Basismodells hinzufügt. Ist eine beliebige Zeichenfolge angegeben, so muss die Pointcutspezifikation manuell in einer extra Datei unter diesem Namen implementiert werden. Unsere Transformation bezieht automatisch generierte und manuell implementierte Pointcutspezifikationen bei der Anwendung von XWeave ein. 4.1.4 Transformation von Aspekmodellen auf BOM-Ebene Alle Aspektmodelle werden einzeln von UML auf die BOM-Ebene transformiert. Dazu wurden die existierenden Transformatoren so erweitert, das aus der in Abschnitt 4.1.1 eingeführten Notation automatisch die von XWeave geforderte Notation erstellt wird. 61 Anschließend bekommt XWeave jeweils ein temporäres Basismodell auf BOM-Ebene, ein Aspektmodell auf BOM-Ebene sowie eine Datei mit Pointcutspezifikationen als Eingabe. Nachdem nacheinander, entsprechend ihrer Abhängigkeiten und wie vom Variantenmodell gefordert, die Aspektmodelle in das temporäre Basismodell gemischt wurden, ist der Prozess des Mischens von Modellen beendet und es ist ein Basismodell auf BOM-Ebene entstanden, das durch ein Variantenmodell definiert ist und welches für weitere Transformations- und Generierungsschritte verwendet wird. XWeave setzt ebenso wie XVar nur voraus, dass die Modelle, auf denen es angewandt wird, Ecore als Metametamodell besitzen. 4.1.5 Steuerfeatures Steuerfeatures werden mittels if -Komponenten in oAW-Workflows implementiert. So wird es möglich, den Aufruf von bestimmten Transformatoren und Generatoren in Abhängigkeit von den ausgewählten Features eines Variantenmodells zu steuern. In Abbildung 2 symbolisieren die vier grauen Kreise Steuerfeatures. 5 Themenbezogene Arbeiten 5.1 pure::variants pure::variants [pur08] ist ein Framework zum Variantenmanagement für Eclipse. Es bietet Möglichkeiten zur Erstellung von Featuremodellen und zur automatischen Generierung von Software aus bestimmten Variantenmodellen. Dazu werden textuelle Artefakte, z. B. Pakete, Klassen, Methoden und Aspekte einer Programmiersprache an bestimmte Features gekoppelt. Ein Transformator mischt die Artefakte entsprechend der Featureauswahl eines Variantenmodells. Wir benutzen pure::variants zur Erstellung von Featuremodellen und Variantenmodellen sowie einen entsprechenden Adapter, um Variantenmodelle in einem oAW-Workflow nutzen zu können. 5.2 FeaturePlugin FeaturePlugin [AC04] ist ein Eclipse Plug-In zum Modellieren von Featuremodellen. Es besteht die Möglichkeit, es mit dem Rational Software Modeler (RSM) zu koppeln und so Software, die in RSM modelliert wurde, entsprechend ausgewählter Features automatisch zu generieren. Dazu werden Teile von UML-Modellen auf Features gemappt. In [CA05] wird dieses Verfahren genauer beschrieben. Im Gegensatz zu pure::variants wird eine Modellebene zwischen Features und generierter Software eingefügt. Es wird aber nur negative Variabilität unterstützt. 62 5.3 openArchitectureWare oAW [oaw08b] ist ein modulares MDSD-Framework. Es bietet eine Sprachfamilie zur Implementierung von Modeltransformatoren, Codegeneratoren und Modellvalidierern. Zur Verarbeitung von Workflows steht eine sogenannte „Workflow Engine“ zur Verfügung. Diese ist beliebig erweiterbar, um proprietäre Workflowkomponenten zu unterstützen. oAW ist in der Lage, Modelle verschiedenster Metametamodelle, wie z. B. Ecore, XML und UML2 zu verarbeiten. Außerdem bietet es die Komponenten XWeave und XVar, um positive und negative Variabilität von Modellen auszudrücken. 6 Fazit Mit dieser Arbeit haben wir gezeigt, dass es möglich ist, eine existierende MDSD-Infrastruktur, welche auf Ecore basierende domänenspezifische Modelle verarbeitet, so anzupassen, dass Softwareproduktlinien unterstützt werden. Dazu kann die Variabilität der einzelnen Systeme der Familie in Aspektmodelle gekapselt werden. Momentan unterstützt die neu implementierte Modelltransformation zum Mischen von Modellen nur die von uns genutzten domänenspezifischen Modelle. Allerdings ist diese Transformation leicht so anpassbar, dass alle auf Ecore basierenden Modelle unterstützt werden können. Unser Ansatz kann auch zur Versionierung von Softwaresystemen verwendet werden, indem eine neue Version eines Systems durch die darin enthaltenen Features definiert wird. Der von uns verfolgte Ansatz kapselt Variabilität von Softwaresystemen in Aspektmodellen. Dies ist günstig, wenn feinkörnige Variabilität durch Features ausgedrückt werden soll. Für den Fall, dass Features nur grobkörnige Variabilität beschreiben, könnte Variabilität in Komponentenmodelle gekapselt werden, und die Aufgabe des Mischens von Modellen entfällt. Die Entscheidung, ob ein Feature ein Aspektfeature oder ein Steuerfeature ist und mit welchen Aspektmodellen ein Aspektfeature assoziert ist, wird momentan noch manuell vom Entwickler getroffen. Weiterhin werden Workflows wie in Abbildung 2 manuell implementiert. Zukünftig müsste untersucht werden, inwieweit oAW-Workflows automatisch generiert werden können. Gegenwärtig werden Basis- und Aspektmodelle unabhängig voneinander entwickelt. Der Entwicklungsprozess würde verbessert werden, wenn es möglich wäre, Features und Aspektmodelle während der Entwicklung miteinander zu verbinden, wie es z. B. FeatureMapper [HKW08] erlaubt. Zur Entwicklung von „großen“ Softwaresystemfamilien, bei denen Aspektmodelle viele Abhängigkeiten untereinander besitzen, wäre eine Visualisierung dieser, vielleicht mittels [vis08], hilfreich. Momentan wird nur eine Teilmenge von UML-Modellelementen für die Aspektmodellierung unterstützt. Diese Teilmenge ist ausreichend für unsere Zwecke, sie müsste allerdings noch für den allgemeinen Fall, z. B. für Verhaltensmodelle, angepasst werden. 63 Literatur [AC04] Antkiewicz, Michal ; Czarnecki, Krzysztof: FeaturePlugin: Feature Modeling Plug-In for Eclipse. In: eclipse ’04: Proceedings of the 2004 OOPSLA workshop on eclipse technology eXchange. New York, NY, USA : ACM, 2004, S. 67–72 [CA05] Czarnecki, K. ; Antkiewicz, M.: Mapping Features to Models: A Template Approach Based on Superimposed Variants. In: Glà 41 ck, Michael Robert; L. Robert; Lowry (Hrsg.): Generative Programming and Component Engineering Bd. Volume 3676/2005, Springer Berlin / Heidelberg, 2005 (Lecture Notes in Computer Science), S. 422–437 [emf08] Eclipse Modeling Framework http://www.eclipse.org/modeling/emf/ [GFd98] Griss, M. ; Favaro, J. ; d’Alessandro, M.: Integrating Feature Modeling with the RSEB. In: Proceedings of theFifthInternational Conference on Software Reuse. Vancouver, BC, Canada, 1998, 76–85 [GV07] Groher, Iris ; Voelter, Markus: XWeave: Models and Aspects in Concert. In: AOM ’07: Proceedings of the 10th international workshop on Aspect-oriented modeling. New York, NY, USA : ACM, 2007. – ISBN 978–1–59593–658–5, S. 35–40 (EMF) June website. 2008. – [HKW08] Heidenreich, Florian ; Kopcsek, Jan ; Wende, Christian: FeatureMapper: Mapping Features to Models. In: ICSE Companion ’08: Companion of the 30th international conference on Software engineering. New York, NY, USA : ACM, 2008. – ISBN 978–1–60558–079–1, S. 943–944 [KC04] K. Czarnecki, U. E. S. Helsen H. S. Helsen: Staged Configuration Using Feature Models. In: Software Product Lines Bd. Volume 3154/2004, Springer Berlin / Heidelberg, 2004 (Lecture Notes in Computer Science), S. 266–283 [KCH+ 90] Kang, K. C. ; Cohen, S. G. ; Hess, J. A. ; Novak, W. E. ; Peterson, A. S.: FeatureOriented Domain Analysis (FODA) Feasibility Study / Software Engeneering Institue, Carnegie Mellon University. 1990 (CMU/SEI-90-TR-21 ESD-90-TR-222). – Forschungsbericht. – http://selab.postech.ac.kr/ [KLD02] Kang, Kyo C. ; Lee, Jaejoon ; Donohoe, Patrick: Feature-Oriented Product Line Engineering. In: IEEE Software 19 (2002), Nr. 4, S. 58–65. – ISSN 0740–7459 [oaw08a] openArchitectureWare Documentation http://www.eclipse.org/gmt/oaw/doc/ June Website. 2008. – [oaw08b] openArchitectureWare Website. http://www.openarchitectureware.org/, June 2008 [pur08] pure::variants Website. June systems.com/Variant_Management.49.0.html [Rie03] Riebisch, M.: Towards a More Precise Definition of Feature Models. In: Modelling Variability for Object-Oriented Product Lines, BookOnDemand Publ. Co., 2003, 64–76 [vis08] The Visualizer Website. June 2008. – http://www.eclipse.org/ajdt/visualiser/ 64 2008. – http://www.pure- Modellbasierte Schichtenarchitektur zur Komposition von Geschäftsanwendungen Peter Hänsgen1 , Heiko Kern2 1 Intershop Communications AG Intershop Tower 07740 Jena p.haensgen@intershop.de 2 Universität Leipzig, Institut für Informatik, Abteilung Betriebliche Informationssysteme Johannisgasse 26 04103 Leipzig kern@informatik.uni-leipzig.de Kurzfassung: Durch den Einsatz modellgetriebener Entwicklungstechniken wie Codegenerierung können viele Vorteile bei der Softwareentwicklung erzielt werden. Im praktischen Einsatz gibt es allerdings auch eine Reihe von Nachteilen. In diesem Beitrag wird eine modellbasierte Schichtenarchitektur vorgeschlagen, welche eine flexible Komposition von Anwendungen aus einzelnen generischen wieder verwendbaren Schichten erlaubt und die eine Verbesserung bzgl. der im Beitrag beschriebenen Probleme bringen soll. 1 Einleitung Modellgetriebene Softwareentwicklung (Model-Driven Software Development, MDSD) [SV06] basiert auf den Konzepten Modellierung, Modellvalidierung, Modelltransformation und Codegenerierung. Ein Modell beschreibt dabei ein System auf einem abstrakten Niveau. Um die sog. semantische Lücke im Abstraktionsniveau zwischen der Modellierungsebene und der Implementierungsebene zu überbrücken, können Modelltransformationen angewendet werden, welche jeweils aus einem Eingangsmodell ein Ausgangsmodell erzeugen und so schrittweise die Abstraktionsunterschiede reduzieren. Mit Hilfe von Codegeneratoren kann man aus Modellen statische Implementierungsfragmente erzeugen wie z. B. Quellcode, Konfigurationsdateien, Dokumentationen usw. Modelle können durch ein Metamodell beschrieben werden, welches wiederum ein Modell darstellt. Für die Meta-Meta-Ebene wird dabei oft ein standardisiertes Modell wie EMOF bzw. Ecore verwendet. Vor der Verarbeitung durch Generatoren oder Transformatoren können Modelle einer Validierung unterzogen werden, um die Korrektheit und Konsistenz des Generats sicherzustellen. Die Ziele dieses Vorgehens bestehen darin, eine Trennung von Konzept und Implementierung zu erreichen, dabei das Abstraktionsniveau möglichst hoch anzusiedeln, Architekturen durch die 65 Wiederverwendung von einmal erstellten Transformatoren und Generatoren wieder verwendbar zu gestalten, Redundanz in den Modellen zu reduzieren und eine höhere Implementierungsqualität durch eine Reduktion von manuell erstelltem Code zugunsten des generierten Anteils, der weniger zufällige Fehler enthält, zu erreichen. Durch die Transformatoren und Generatoren kann ein Hebeleffekt erzielt werden, d. h. aus einem einzelnen Modellelement lassen sich potentiell viele Implementierungsartefakte automatisiert ableiten. Da die Generierungstemplates die Erzeugung des schematischen Codes übernehmen und das Modell nur noch aus den variablen Anteilen besteht, ist es kompakter und daher schneller durch einen Entwickler zu erstellen. 2 Probleme mit modellgetriebener Softwareentwicklung Trotz der verschiedenen Vorteile, die sich durch den Einsatz von MDSD ergeben, wurde eine Vielzahl an Problemen auf Basis von Erfahrungen der Autoren mit der Entwicklung von komplexen E-Commerce-Anwendungen und anderen Arbeiten (beispielsweise in [Uhl08]) identifiziert. Diese Probleme werden im Folgenden näher beschrieben. Werkzeugzentrierung: MDSD ist ein werkzeugzentrierter Ansatz. Um eine Anwendung zu entwickeln, ist zunächst die Entwicklung einer komplexen Werkzeuginfrastruktur notwendig, welche aus den benötigten Metamodellen, Modelleditoren, Modellvalidierern, Modelltransformatoren, Codegeneratoren und Transformationsworkflows besteht. Ohne diese Komponenten kann keine Anwendung entwickelt werden. Dadurch entstehen u. a. große Anfangsinvestitionen, die nur durch eine maximale Wiederverwendung der einzelnen Komponenten in verschiedenen Softwareprojekten gerechtfertigt werden kann. Synchronisierung Die Herauslösung der Architektur aus einem Softwareprojekt in ein Entwicklungswerkzeug führt zu Problemen, wenn Entwickler zwar die gleiche Codebasis bearbeiten, aber dabei verschiedene Versionen des MDSD-Werkzeugs benutzen, also in Folge aus dem gleichen Modell verschiedenen Code generieren. Dies muss ausgeschlossen werden, d. h. es muss ein synchronisiertes Update aller beteiligten Entwickler erzwungen werden, sobald sich in einer der MDSD-Komponenten und damit dem Entwicklungswerkzeug etwas geändert hat. Dieses kann, abhängig von der Anzahl der Entwickler und insbesondere bei Einbeziehung von externen Partnerfirmen oder Offshoring-Partnern, äußerst aufwändig sein. Wiederholbarkeit: Eine besondere Schwierigkeit entsteht bei der Weiterentwicklung von (älteren) Kundenprojekten. Es ist oft nicht möglich die Generierungsinfrastruktur auf Basis der alten Modelle und der inzwischen veralteten und nicht mehr verfügbaren Werkzeuge wiederherzustellen. Stabilität Generierter Code entspricht einer statischen Momentaufnahme der aktuellen Kombination der Modelle, Transformatoren und Generatoren. Änderungen in einer dieser Komponenten haben meistens globale Auswirkungen und erfordern eine (aufwändige) Neugenerierung des gesamten Systems. 66 Korrigierbarkeit: Wenn Codegenerierung genutzt wird, können Änderungen im generierten Code (z. B. nach einem Bugfix in einem Generatortemplate) nicht einfach als kompilierter binärer Patch an den Kunden ausgeliefert werden. Stattdessen erfordert jegliche Änderung ein aufwändiges Upgrade der MDSD-Werkzeuginstallationen aller beteiligten Entwickler, die Neugenerierung aller darauf aufsetzenden Projekte, jeweils mit den kompletten Zyklen zum Kompilieren, Testen und Installieren. Dieser Aufwand ist enorm und praktisch nicht mehr durchführbar. In Konsequenz muss jeglicher generierter Code möglichst trivial (und damit wahrscheinlich fehlerfrei) sein, um überhaupt wartbar zu bleiben. Komplexe Abläufe sind also als Teil des Plattformcodes generisch und manuell zu implementieren. Anpassbarkeit: Werden im generierten Code manuelle Änderungen oder Ergänzungen durchgeführt, muss auch der generierte Code im Versionierungssystem für das Softwareprojekt verwaltet werden, welches wiederum den Verwaltungsaufwand erhöht. Weiterhin kann es später schwierig werden, manuelle Änderungen in der Masse an Code wiederzufinden wiederzufinden oder ihre weitere Wirksamkeit sicherzustellen, nachdem sich im Generator etwas geändert hat und vielleicht manuell geänderte Methoden überhaupt nicht mehr aufgerufen werden. Es sollte daher möglichst auf manuelle Änderungen im Generat verzichtet werden. Redundanz: Die Erhöhung des Abstraktionsniveaus in der MDSD soll dazu dienen, Redundanzen im Code zu vermeiden bzw. zu verringern. Dies kann dadurch erreicht werden, dass ein Modellelement auf verschiedene Subsysteme abgebildet wird, die miteinander in Beziehung stehen bzw. „korrelieren“. So könnte beispielsweise der Name eines Attributs eines Datentyps sich einerseits in entsprechenden Zugriffsmethoden einer Java-Klasse und andererseits im Spaltennamen einer Datenbanktabelle wiederfinden. Eine Änderung des Namens würde bei manueller Programmierung Modifikationen in potentiell zahlreichen Subsystemen erfordern (also im Beispiel: in der Java-Klasse und im Datenbankschema). Dies wird im MDSD-Ansatz durch Codegeneratoren bzw. Modelltransformatoren erleichtert. Das bedeutet aber nicht, dass diese Korrelationen nun tatsächlich verschwunden sind. Im Gegenteil, sie sind immer noch vorhanden, nur sind sie jetzt in die Codegeneratoren bzw. Modelltransformatoren gewandert. Das Sicherstellen der Konsistenz von Generatoren und Transformatoren bei Änderungen stellt dabei ein Problem dar, da oftmals komplexe Abhängigkeiten zwischen den verschiedenen Transformationen bestehen. Neben den genannten Problemen gibt es noch zahlreiche weitere Schwierigkeiten, die aber aus Platzgründen nicht weiter diskutiert werden können. Um die Probleme zu lösen, wurde ein alternatives Konzept entwickelt, welches die Vorteile von MDSD beibehält, aber die Nachteile vermeidet. Dieses Konzept wird im folgenden Kapitel 3 erläutert. 3 Konzept für eine modellbasierte Schichtenarchitektur 3.1 Lösungsansatz Ausgangspunkt bei der Entwicklung des Lösungsansatzes sind die folgenden vier Prinzipien: 67 Ausnutzung von Selbstähnlichkeit: Unabhängig vom Abstraktionsgrad sind Metamodelle für ein bestimmtes Problemfeld (Daten, Prozesse, . . . ) strukturell ähnlich. Es ist also möglich, für ein bestimmtes Problemfeld (z. B. die Datenmodellierung) ein einheitliches Metamodell zu entwickeln, welches für verschiedene Abstraktionsstufen wiederverwendet werden kann. Das Schichten-Konzept soll so ein vereinheitlichtes Metamodell verwenden Damit verliert man zwar an Semantik, gewinnt aber an Universalität. Problemzerlegung: Komplexe Probleme können in einfache Probleme zerlegt werden. Technische Probleme können von fachlichen Problemen getrennt werden. Jedes dieser Teilprobleme soll durch eine spezielle Schichtenimplementierung auf Basis einer einheitlichen Infrastruktur gelöst werden. Modellinterpretierung: Statt auf statischem generiertem Code soll der Schichten-Ansatz auf der Interpretierung von Modellen basieren. Wiederverwendung von Infrastruktur-Code: Verschiedene Schichten benötigen immer wieder den gleichen Infrastruktur-Code, z. B. für die Initialisierung, für die Erzeugung und Abfrage von Objekten, für die Bereitstellung von Metainformationen usw. Das neue Konzept soll eine einheitliche Infrastruktur beinhalten, auf der die verschiedenen Abstraktionsebenen aufsetzen können. 3.2 Schichtenarchitektur Auf Basis dieser Entwicklungsziele wurde ein Konzept entwickelt, welches auf einer Schichtenarchitektur [Fow03] beruht, bei der die einzelnen architektonischen „Bausteine“ übereinander gestapelt und über Domänenmodelle [Eva04] konfiguriert werden können. Dabei findet keine Generierung von Code aus Modellen statt, sondern die gesamte Implementierung des Traversierens durch die Modelle und der Steuerung des Verhaltens einer Schicht wird aus dem Entwicklungswerkzeug in die Anwendung verlagert. Eine Schicht kann somit als ein Interpreter für ein Modell einer bestimmten Abstraktionsstufe betrachtet werden [V0̈7]. Zunächst wurde eine einheitliche Schnittstelle (Core-API) definiert, welche für die verschiedenen Schichten genutzt werden kann und durch diese implementiert wird. Im Fokus stand dabei die Abbildung und Verarbeitung von Daten. Die API besteht aus den folgenden fünf Elementen: Layer: Repräsentiert eine Schicht und erlaubt den Zugriff auf Node Spaces. Node Space: Stellt die Menge aller Nodes eines bestimmten Typs dar und dient ihrer Verwaltung. Node: Stellt ein konkretes Objekt dar. Ein Node hat einen Typ, eine eindeutige ID sowie beliebig viele Properties und Relationen mit anderen Nodes. Property: Ist ein einfaches atomares Attribut eines Nodes. Relation: Ist eine Beziehung zwischen Nodes. 68 Weil es für die Anwendungsprogrammierung ungünstig ist, nur reflexiv auf die Datenstrukturen der Core-API zuzugreifen, wurde zusätzlich ein Mapping eingeführt, welches Typen aus der Anwendungsdomäne in Form von Java-Interfaces ausdrückt und diese über Proxies automatisch auf die Core-API, also auf Nodes, Properties und Relations, abbildet. Zusätzlich gibt es eine generische Factory, welche zur Erzeugung, zum Entfernen und zur Suche von Domänenobjekten dient und die dazu auf dem jeweiligen Node Space des entsprechenden Typs operiert. Die Core-API wird von verschiedenen Schichten (Layers) implementiert (siehe Abbildung 1), welche jeweils ein bestimmtes Verhalten bereitstellen. Eine Schicht löst dabei genau ein einzelnes Teilproblem, welches entweder technischer Natur (z. B. Übertragung über ein Kommunikationsprotokoll) oder fachlicher Natur (z. B. Unterstützung von Mehrsprachigkeit) sein kann. Das Problem wird dabei immer bezüglich der Core-API gelöst. So kann beispielsweise eine Schicht implementiert werden, welche die Versionierung von Node Spaces und Nodes sowie ihren Relations und Properties implementiert. Dadurch ist die Schicht in der Lage, die Versionierung für jegliche Domänenobjekte zu übernehmen. Dabei kann die Schicht wiederum einer bestimmten Problemdomäne zugeordnet werden, d. h. sie besitzt selbst ein schichtenspezifisches Domänenmodell. Im Beispiel der Versionierungsschicht könnte dies Begriffe wie „Branch“, „Revision“, „VersionedObject“ oder „ObjectVersion“ umfassen. Dieses Domänenmodell wird, wie bereits für die oberste Ebene geschildert, in genau der gleichen Weise mittels Java-Interfaces implementiert und kann damit generisch auf die Core-API der nächsten unterliegende Schicht abgebildet werden. 3.3 Komposition von Anwendungen Aufgrund der einheitlichen Core-API können Schichten beliebig miteinander kombiniert und übereinander gestapelt werden. Eine Schicht kann dabei entweder die oberste Schicht (top layer), eine Zwischenschicht (intermediate layer) oder die unterste Schicht (bottom layer) in einem Stapel bilden. Je nach ihrer Funktion kann sie Aufrufe an unterschiedlich viele andere Schichten delegieren. Das Verhalten der gesamten Applikation ergibt sich damit aus der Gesamtheit des Verhaltens der einzelnen übereinander gestapelten Schichten. Neben der eigentlichen Implementierung des Verhaltens durch eine Schicht wird eine Beschreibung der Datenstrukturen auf einer Metaebene benötigt. Zum Start des Systems wird dazu das Anwendungsdomänenmodell in ein solches Modell umgewandelt und der Top-Layer damit initialisiert. Dieser Layer transformiert das Modell und kombiniert es mit einem Modell seiner eigenen ausgehenden Domänen-API. Das transformierte Modell dient als Input für die nächsten unterliegenden Schichten, welche sich auf die gleiche Weise rekursiv initialisieren. Eine Schicht stellt also die Implementierung für verschiedene Transformationen dar: Datentransformation: Diese stellt das eigentliche Verhalten der Schicht dar. Eingehende Daten werden entsprechend der beabsichtigten Funktion und unter Einbeziehung von Kontextinformationen umgeformt und an die unterliegenden Schichten weitergeleitet. Datenmodelltransformation: Das Datenmodell stellt die Metaebene der eigentlichen Daten dar und beschreibt ihre Struktur. Wenn die Schicht eine strukturelle Veränderung der Daten 69 Domain Model (Java Interfaces with Annotations) generic mapping Core API Layer Node Space Node Relation outbound Layer Domain Model Property Layer Implementation Abbildung 1: Core-API und Layer-Implementierung Application Code Application Domain API Layer Stack Node Descriptions Layer Instance delegate Context Objects delegate Node Descriptions Layer Instance ... delegate ... ... Abbildung 2: Layer Stack 70 (Language, Currency, User, Transaction, ...) vornimmt, kann dies durch eine Datenmodelltransformation beschrieben werden. Das eingehende Datenmodell wird dabei umgewandelt; mit dem transformierten Modell werden die unterliegenden Schichten konfiguriert. Query-Transformation: Abfragen auf Daten können entweder durch eine Schicht selbst beantwortet werden, oder sie können durch eine unterliegende Schicht bearbeitet werden. Im Falle von strukturellen Unterschieden der Datenmodelle und zur Einbeziehung von Kontextinformationen in die Abfrage müssen die Queries ebenfalls transformiert werden. Die umgewandelte Abfrage kann dann an die unterliegende Schicht weitergeleitet werden und wird von dieser beantwortet. Welche dieser Transformationen notwendig sind und durch die Schichtenimplementierung bereitgestellt werden müssen, hängt von der jeweiligen Funktionalität der Schicht ab. Einige Schichten werden überhaupt keine Strukturänderungen vornehmen, weil sie lediglich ein technisches Verhalten bereitstellen. In diesem Falle sind keine Transformationen notwendig, sondern die eingehenden Daten, Metadaten oder Abfragen können einfach durchgereicht werden. Andere Schichten lösen vielleicht ein fachliches Problem und stellen dabei eine Veränderung des Abstraktionsniveaus dar. In diesem Falle könnten alle drei genannten Transformationen notwendig sein. Weiterhin gibt es Schichten, welche die unterste Ebene der Kette darstellen, wie z. B. eine Persistenzschicht für die Datenhaltung in einer relationalen Datenbank. Diese Schichten müssen Features wie Abfragen unterstützen und können sie nicht mehr an einen Delegate weiterleiten. Dabei kann eine Übersetzung der Datenmanipulationen, der Metabeschreibungen und der Abfragen in eine andere Form notwendig sein, z. B. nach SQL. 3.4 Anwendungsbeispiel Um das vorgestellte Schichtenkonzept zu testen, wurden mehrere Schichten aus verschiedenen Bereichen sowie eine gemeinsame Infrastruktur zur Verwaltung der Schichten implementiert. Mit den Schichten wurde eine Beispielanwendung für ein Online-Shopping-System umgesetzt. Dabei können die benötigten Schichten gemäß den gewünschten Features der Anwendung aus der zur Verfügung stehenden Bibliothek ausgewählt und zusammengesetzt werden. Dafür ist keinerlei Codegenerierung notwendig, sondern es werden lediglich fertige Komponenten miteinander verschaltet und konfiguriert. Im Folgenden sollen zwei konkrete Layer-Implementierungen und deren Kombination genauer beschrieben werden. Currency Layer: Der Currency Layer ist eine Schicht, welche eine zusätzliche Währungsdimension für Properties einführt, d. h. sie erlaubt die Speicherung von währungsspezifischen Werten. Dies könnte z. B. der Preis eines Produktes sein, der in Euro und in US-Dollar anzugeben ist. Im Prototyp werden nur wenige verschiedene Währungen erwartet, die sich nicht zur Laufzeit ändern, darum werden entsprechend markierte Properties einfach in separate Properties im Delegate-Layer gemappt, welche den ISO-Code der repräsentierten Währung als Bestandteil des Property-Namens enthalten (siehe Abbildung 3). Nichtwährungsspezifische Properties bleiben unverändert.] 71 Product_CU Product price_USD:double <<Currency>> price:double price_EUR:double Abbildung 3: Strukturveränderung durch den Currency Layer Product_OL Product Product_LO * <<Localized>> name:String locale:Locale name:String Abbildung 4: Strukturveränderung durch den Localization Layer Localization Layer: Der Localization Layer erlaubt die Einführung von mehrsprachigen Properties, wie z. B. dem Namen oder der Beschreibung eines Produkts. Im Prototyp wurde angenommen, dass eine große Zahl von Sprachen unterstützt werden muss, darum werden lokalisierte Properties auf eine andere Art behandelt als durch den Currency Layer. Sie werden in eine zusätzliche Klasse ausgelagert, welche alle Werte einer bestimmten Sprache enthält (siehe Abbildung 4). Kombination von Schichten: Die beiden Schichten können nun in einer konkreten Anwendung alleine oder gemeinsam benutzt werden. Sollen in der Zielanwendung sowohl mehrere Währungen als auch mehrere Sprachen unterstützt werden, so werden beide Schichten miteinander kombiniert (siehe Abbildung 5). Durch die sequentiellen Transformationen ergibt sich eine resultierende Datenstruktur, welche am unterliegenden Delegate-Layer registriert wird (z. B. einer Persistenzschicht). Das Domänenmodell der Anwendung ist von der Schichtenkombination selbst nicht betroffen und muss nicht geändert werden. Die LayerImplementierungen bleiben ebenfalls unverändert und können auch für andere Anwendungen benutzt werden. 4 Zusammenfassung und Diskussion Im Beitrag wurden verschiedene Probleme genannt, welche beim praktischen Einsatz von MDSD zur Entwicklung komplexer Softwaresysteme auftreten. Als Lösung wurde die Komposition von Anwendungen auf Basis einer modellbasierten Schichtenarchitektur vorgeschlagen, bei der die einzelnen Schichten mit Modellen konfiguriert werden können und interpretativ arbeiten. Das vorgestellte Schichtenkonzept wurde in einer Beispielanwendung für ein Online-ShoppingSystem umgesetzt. Dabei können die benötigten Schichten gemäß den gewünschten Features der Anwendung aus einer zur Verfügung stehenden Bibliothek ausgewählt und zusammengesetzt werden. Dafür ist keinerlei Codegenerierung notwendig, sondern es werden lediglich fertige Komponenten miteinander verschaltet und konfiguriert. 72 Product_CU Product <<Localized>> name:String <<Localized>> name:String price_USD:double <<Currency>> price:double Application Domain Model Currency Layer Product_CU_LO price_EUR:double Localization Layer * ... Product_CU_OL price_USD:double locale:Locale price_EUR:double name:String Abbildung 5: Kombination von Currency Layer und Localization Layer Das Konzept bewirkt eine Verlagerung des Schwerpunktes von der Werkzeugentwicklung zurück in die Anwendungsentwicklung. Dabei findet eine Wiederverwendung von Applikationscode anstelle der Wiederverwendung von Werkzeugen statt. Durch eine einheitliche Core-API der Schichten und eine gemeinsam genutzte Infrastruktur kann eine beliebige Kombination der Schichten miteinander erfolgen, d. h. aufgrund ihrer Selbstähnlichkeit bildet ein solches System letztendlich eine fraktale Struktur. Die Entwicklung der Anwendungslogik kann, sofern sie sich nicht weiter in wieder verwendbare Schichten verlagern lässt, mittels einer konkreten domänenspezifischen API auf einem hohen Abstraktionsniveau durchgeführt werden, welches durch die Schichtenbausteine schrittweise reduziert wird. Bezugnehmend auf die in der Einleitung geschilderten Probleme, konnten diese mit der Schichtenarchitektur verbessert werden. Werkzeugzentrierung: Für eine Umsetzung des Konzeptes sind keine speziellen Werkzeuge notwendig, d. h. der Entwicklungsaufwand für MDSD-Werkzeuge entfällt vollständig. Die Beispielanwendung wurde komplett in Java mit den dafür verfügbaren ausgereiften Entwicklungswerkzeugen umgesetzt. Stabilität: Eine Anpassung der Anwendung an geänderte Anforderungen kann sehr leicht durch Neukombination oder Austausch einzelner Schichten erreicht werden. Dazu ist keinerlei Änderung im eigentlichen Domänenmodell der Anwendung notwendig. Anderseits führen 73 Änderungen im Domänenmodell zu keinen weiteren Änderungsaufwänden in den unterliegenden Schichten, denn die Schichtenimplementierungen bleiben davon unberührt. Synchronisierung: Die Entwicklung von Anwendungen oder Schichten ist unabhängig vom verwendeten Entwicklungswerkzeug. Jeder Entwickler kann eine eigene Umgebung nutzen. Wiederholbarkeit: Ältere Projekte können einfach weiterentwickelt werden, weil keine komplexen Werkzeuge gebraucht werden. Korrigierbarkeit: Schichtenbausteine können in binärer Form ausgeliefert werden. Sie können jederzeit durch das Einspielen von Patches korrigiert werden. Dabei ist keinerlei Neugenerieren der Kundenprojekte notwendig. Anpassbarkeit: Schichten sind generisch, d. h. sie können derzeit nicht an Spezialfälle angepasst werden. Es ist aber möglich, eine Schicht komplett durch eine andere Schicht zu ersetzen. Optimierbarkeit: Für die gleiche fachliche oder technische Funktionalität können alternative Schichtenimplementierungen erstellt werden, welche das gleiche Problem auf unterschiedliche Weise lösen. Die verschiedenen Lösungen können sich dabei hinsichtlich ihres Optimierungsziels unterscheiden. Beispielsweise könnte eine Implementierungsvariante optimal für sehr große Datenmengen sein, während eine andere Implementierung für geringe erwartete Datenmengen besser geeignet ist. Dabei kann, je nach Projektanforderungen, die für das aktuelle Projekt optimale Variante ausgewählt und verwendet werden. Redundanz: Redundanz kann vermieden werden, indem oft benötigte Features als einzelne Schicht implementiert werden. Diese Schicht kann dann in unterschiedlichen Konstellationen wiederverwendet werden. Weiterhin kann eine gemeinsame Infrastruktur für alle Schichten benutzt werden und muss nicht mehrfach implementiert werden. Im Moment wurde vorrangig die Bearbeitung und Speicherung von Daten betrachtet. Es wird aber angenommen, dass sich auch in anderen Bereichen wie z. B. in der Prozessmodellierung ein ähnliches Prinzip anwenden lässt, welches Prozessmodelle verschiedener Abstraktionsstufen abbilden kann. Wenn es gelingt, auch in diesem Feld eine generische API zu definieren, könnten darauf ebenfalls generische Werkzeuge aufsetzen. Literatur [Eva04] Evans, Eric: Domain-driven design: Tackling complexity in the heart of software. Boston , AddisonWesley, 2004. – ISBN 0321125215 [Fow03] Fowler, Martin: Patterns of Enterprise Application Architecture. Boston, MA, USA : AddisonWesley, 2003. – ISBN 0–321–12742–0 [SV06] Stahl, Thomas ; Völter, Markus: Model-Driven Software Development – Technology, Engineering, Management. John Wiley & Sons Inc., 2006. – ISBN 978–0470025703 [Uhl08] Uhl, Axel: Model-Driven Development in the Enterprise. In: IEEE Software Vol. 25 (2008), S. 46–49. – ISSN 0740–7459 74 [V0̈7] Völter, Markus: Generieren vs. Interpretieren – Die andere Seite von MDSD. Vortrag auf der OOP 2007. http://www.voelter.de/data/presentations/GenerierenVsInterpretieren. pdf. Version: 2007. – Letzter Aufruf 14.06.2010 75 76 Interoperabilität mittels M3-Level-basierter Transformationen Heiko Kern Universität Leipzig, Institut für Informatik, Abteilung Betriebliche Informationssysteme Johannisgasse 26 04103 Leipzig kern@informatik.uni-leipzig.de Kurzfassung: Die Transformation von Modellen und dazugehörigen Metamodellen stellt in verschiedenen Anwendungsbereichen eine Herausforderung dar. Ein häufig verwendeter Ansatz zur Lösung dieses Transformationsproblems kann in der M3-Level-basierten Transformation (M3T) gesehen werden. Dieser Beitrag definiert eine Formalisierung des M3T-Ansatzes, beschreibt verschiedenen Eigenschaften und diskutiert Vor- und Nachteile. 1 Einleitung Die Transformation von Modellen und dazugehörigen Metamodellen stellt in verschiedenen Anwendungsbereichen eine Herausforderung dar. Ein häufig verwendeter Ansatz zur Lösung dieses Transformationsproblems kann in der M3-Level-basierten Transformation (M3T) gesehen werden. Typische Beispiele für M3Ts sind u. a. die Integration von relationalen Datenbanken und objektorientieren Systemen, die Entwicklung von Cross-Compilern zwischen verschiedenen Programmiersprachen oder der Austausch von Modellen zwischen Modellierungswerkzeugen. Eine konkrete M3T-Anwendung im Bereich von Modellierungswerkzeugen ist bspw. der Modellaustausch zwischen Microsoft Visio und dem Eclipse Modeling Framework [KK09]. Visio ist ein Modellierungswerkzeug, das die Konfiguration von Modellierungssprachen erlaubt. Das Eclipse Modeling Framework (EMF) [SBPM09] ist eine Implementierung der von der Object Management Group propagierten Meta Object Facility im Kontext der Model-Driven Architecture. EMF bietet mit Ecore die Möglichkeit Metamodelle zu definieren und entsprechende Modelle zu erstellen. Die implementierte M3T erlaubt die Transformation von Stencils und Visio-Modellen nach EMF. Dadurch können Visio-Modelle mit Hilfe von EMF-Werkzeugen verarbeitet werden. Bisher wurde der M3T-Ansatz in den verschiedenen Anwendungsbereichen isoliert betrachtet (bspw. in [KK09, KK07, Ker08, Wim08, BCC+ 10]) und Anwendungsübergreifende Untersuchungen vernachlässigt. Dieser Beitrag widmet sich genau dieser Problematik. Aufbauend auf verschiedenen M3T-Ausprägungen wird zunächst eine formalisierte Beschreibung erstellt (siehe Kapitel 2.1 und 2.2). Aufbauend darauf werden Eigenschaften des M3T-Ansatzes untersucht (siehe Kapitel 2.3 bis 2.5) sowie Vor- und Nachteilen des M3T-Ansatzes diskutiert (siehe Kapitel 4). 77 2 M3-Level-basierte Transformation 2.1 Modellhierarchie Das adressierte Problem einer M3T besteht in der Transformation von Modellen und Metamodellen auf Basis der zugrunde liegenden Metametamodelle. Die Menge aller Modelle bzw. Modellelemente werden zu einem Modellraum M zusammengefasst. Alle Modelle eines Modellraumes M können hinsichtlich ihrer Hierarchie und ihrer Modellebene klassifiziert werden. Hierfür führen wir zwei Funktionen ein, wobei die erste Funktion h : M → {q, z} (1) jedes Modellelement der Menge M auf eine der beiden Modellhierarchien Quelle q und Ziel z abbildet. Durch die Zuordnung von Modellelementen zu einer Hierarchie ergibt sich eine Äquivalentrelation ∼H mit e1 , e2 ∈ M : e1 ∼H e2 ⇔ h(e1 ) = h(e2 ) . Die zweite Funktion l : M → {1, 2, 3} (2) bildet jedes Modellelement der Menge M auf eine von drei Modellebenen ab. Durch die Zuordnung von Modellelementen zu einer Ebene ergibt sich eine Äquivalentrelation ∼L mit e1 , e2 ∈ M : e1 ∼L e2 ⇔ l(e1 ) = l(e2 ). Durch die Definition der beiden Äquivalenzrelationen ∼L und ∼H ergibt sich die Äquivalenzrelation ∼ M mit e1 , e2 ∈ M : e1 ∼L e2 ∧ e1 ∼H e2 . Die Relation ∼ M partitioniert somit M in Äquivalenzklassen M/ ∼ M . Durch die beiden Hierarchien Quelle q und Ziel z und den ndrei Ebenen ergeben sich 2 · 3 =o 6 Äquivalenzklassen. Diese Äquivalenzklassen sind M/ ∼ M := Mq,3 , Mz,3 , Mq,2 , Mz,2 , Mq,1 , Mz,1 . Weiterhin definieren wir die Funktion type : M x → M x+1 mit M x ∈ M/ ∼L und x = 1, 2. (3) Diese Funktion ordnet jedem Modellelement (M1-Ebene) ein Metamodellelement (M2-Ebene) zu. Analog zur nächst höheren Ebene, wird jedem Metamodellelement (M2-Ebene) ein Element aus dem Metametamodell (M3-Ebene) zugeordnet. Somit wird die Ist-Typ-Modell [K0̈6] zwischen Modell und Metamodell abgebildet. Bezogen auf das Visio-EMF-Beispiel aus der Einleitung kann der Modellraum M in die beiden Hierarchien Visio und EMF sowie den einzelnen Ebenen aufgeteilt werden. Das Metametamodell von Visio ist nicht explizit beschrieben kann aber aus der Definition von Stencils extrahiert werden. Metamodelle in Visio sind Stencils und Modelle sind Visio-Dokumente. In EMF ist das Metametamodell explizit durch Ecore definiert. Metamodelle sind demnach Ecore-Modelle und Modelle sind Instanzen dieser Ecore-Modelle. Es ergeben sich somit beispielhaft (siehe Abbildung 1) die folgenden Mengen: MVisio,3 := {Master} , MEMF,3 := {EClass}, ′ ′ MVisio,2 := {Event, Function} , MEMF,2 := {Event , Function o }, n MVisio,1 := {E1 , E2 , F1 , F2 }, MEMF,1 := E1′ , E2′ , F1′ , F2′ . 78 Visio (Quelle) Metametamodell Master Metamodell Event E1 E2 Function F1 Modell F2 M3T EMF (Ziel) Metametamodell M3-Mapping (M3T) M2-Transformation (M2T) Transformation (M1T) EClass Metamodell Event’ E’1 Function’ E’2 Modell F’2 F’1 Abbildung 1: M3-Level-basierte Transformation zwischen Visio und EMF 2.2 Transformationsansatz Eine M3-Level-basierten Transformation setzt sich aus zwei Teilen zusammen. Der erste Teil ist die Transformation der Metamodelle. Allgemein besteht eine Transformation aus einer Definition und einer Ausführung. Die Definition wird in Form von Regeln beschrieben, welche Elemente der Metametamodelle in Beziehung zueinander setzen. Die Ausführung wertet diese Regeln aus und setzt entsprechend konkrete Elemente des Quellmetamodells und des Zielmetamodells miteinander in Beziehung. Sind die Elemente noch nicht vorhanden, dann werden neue Elemente erzeugt. Bezogen auf die zuvor eingeführten Äquivalenzklassen kann eine Relation für die Transformationsdefinition zwischen Elementen der Metametamodelle wie folgt definiert werden: M3 T ⊆ Mq,3 × Mz,3 . (4) Bei der Ausführung dieser Transformation werden konkrete Quellmetamodelle in Zielmetamodelle transformiert. Das Ergebnis dieser Transformation kann wiederum in Form der folgenden Relation angeben werden: M2 T := {(a, b) ∈ Mq,2 × Mz,2 | (type(a), type(b)) ∈ M3 T }. (5) Typischerweise besteht die Herausforderung bei der Metamodelltransformation semantisch äquivalente Konzepte aufeinander abzubilden. Nur so kann ein Verlust von Modellstruktur und -inhalt während der Transformation vermieden werden. Der zweite Teil der Transformation transformiert Modelle des Quellraums in Modelle des Zielraums. Die Transformationsregeln sind durch die Transformation auf M2-Ebene (M2T) vorgegeben. Die Ausführung lässt sich wiederum durch die folgende Relation beschreiben: M1 T := {(a, b) ∈ Mq,1 × Mz,1 | (type(a), type(b)) ∈ M2 T }. (6) Bei der Transformation auf M1-Ebene sind die Abbildungsregeln bereits aus der M2-Transformation vorgegeben und müssen lediglich implementiert werden. 79 Bezogen auf die Visio-EMF-Transformation (siehe Abbildung 1) kann eine Transformationsregeln definiert werden, die Master auf EClass abbildet. Beide Konzepte sind semantisch gleich, da sie die Definition einer Klasse von eigenständigen Modellierungselementen ermöglichen. Aus diesem Grund wird eine Transformationsregel definiert, die alle Master in EClass transformiert, was die Relation M3 T := {(Master, EClass)} ergibt. Die Ausführung der Transformation erzeugt darauf hin auf M2-Ebene die folgenden Tupel:  M2 T := (Event, Event′ ), (Function, Function′ ) . (7) Die Transformation auf M1-Ebene erzeugt die Tupel:  M1 T := (E1 , E1′ ), (E2 , E2′ ), (F1 , F1′ ), (F2 , F2′ ) . 2.3 (8) Transformationsrichtung Eine entscheidende Eigenschaft von M3Ts sind die unterstützten Transformationsrichtungen. Die einfachste Variante ist in Abbildung 2(a) dargestellt. Diese ermöglicht den Export von Metamodellen und Modellen von der Quell- zur Zielhierarchie. Der Import von Metamodellen und Modellen ist nicht möglich. Die zweite Variante (siehe Abbildung 2(b)) erlaubt zusätzlich zur ersten Varianten den Re-import von Modellen unter der Voraussetzung, dass diese konform zu einem vorher exportierten Metamodell sind: ∃Mq,2 : (Mq,2 , type(Mz,1 )) ∈ M2 T. (9) Diese Variante kann auch kombiniert werden, so dass Metamodelle und Modelle in beide Richtungen transformiert werden können, allerdings muss die zuvor definierte Bedingung erfüllt sein. Die dritte Variante erlaubt die Transformation der Metamodelle in beide Richtungen. Anders als Variante 2 können somit Modelle ohne Einschränkungen in beide Richtungen transformiert werden. type type type type type type type type type type type type (a) Export von Metamodellen und Modellen (b) Bedingter Re-Import von Modellen Abbildung 2: Transformationsrichtung 80 (c) Vollständiger Modellaustausch 2.4 Vollständigkeit Die Betrachtung von Vollständigkeit bezieht sich auf die Transformation auf M2-Ebene. Sie gibt an inwieweit ein Quellmetamodell in ein Zielmetamodell transformiert werden kann und wie verschiedenen Konzepte aufeinander abgebildet werden können. Bei der Definition von M2Transformationen gibt es im Wesentlichen vier Möglichkeiten. (1) Konzepte der Metametamodelle können direkt 1-zu-1 aufeinander abgebildet werden. (2) Elemente des Quellmetamodells können mit Hilfe der vorhandenen Metametamodellkonzepte in der Zielhierarchie nachgebildet werden. (2.1) Hierbei können alle Eigenschaften abgebildet werden. (2.2) Es können aber auch Eigenschaften der Metamodelle verloren gehen. (3) Die letzte Möglichkeit besteht darin, dass Konzepte der Metametamodelle nicht aufeinander abgebildet werden können. Die Vollständigkeit der Transformation hängt somit davon ab, ob die Konzepte und Eigenschaften bei einer Transformation erhalten bleiben können. Eine Transformation zwischen ein und demselben Metametamodell ist somit vollständig, da jedes Konzept 1-zu-1 abgebildet werden kann. In der Praxis ist dies oftmals nicht möglich. Hier können nicht immer alle Konzepte und deren Eigenschaften aufeinander abgebildet werden. 2.5 Abbildung auf ein spezifisches Zielmetamodell Da die Abbildungsregeln einer M3T auf Basis der Metametamodelle definiert werden, ist die Transformation zwar generisch, so dass jedes mögliche Metamodell und dazugehörige Modell transformieren werden kann, allerdings kann dabei nicht auf ein spezifische Zielmetamodell eingegangen werden. Dies kann bspw. der Fall sein, wenn bereits ein Metamodell in der Zielhierarchie besteht und die Modelle in dieses Zielmetamodell transformiert werden sollen. Als Lösung hierfür kann eine Modelltransformation zwischen dem exportierten und bereits vorhanden Zielmetamodell definiert werden (siehe Abbildung 3(a)). Eine andere Möglichkeit ist die Konfiguration der M3T. Hierbei können die definierten Abbildungsregeln in eingeschränkten Maß angepasst werden. Somit können bspw. bestimmte Elemente des Quellmetamodells auf Elemente des Zielmetamodells abgebildet werden. Eine M3T kann diese Eigenschaft unterstützen bzw. nicht unterstützen. Quelle M3T Ziel Quelle Metametamodell M3-Mapping (M3T) Metametamodell Metamodell M2-Transformation (M2T) Modell Transformation (M1T) Metamodell Metamodell M3T Ziel Metametamodell M3-Mapping (M3T) Metametamodell Metamodell M2-Transformation (M2T) + Konfiguration Metamodell Modell Transformation (M1T) Modell Transformation Modell (a) Anschließende Modelltransformation Modell (b) Konfiguration Abbildung 3: Abbildung auf ein spezifisches Metamodell 81 3 Implementierungsaspekte 3.1 Werkzeugintegration Für die Implementierung einer M3T muss der Zugriff auf Modelldaten möglich sein. Hierzu gibt es im Wesentlichen zwei Möglichkeiten. Es kann ein Zugriff auf Datenebene über Dateiaustausch oder über Funktionsebene über ein Application Programming Interface (API) geben. Prinzipiell können über beiden Ebenen alle Modelldaten ausgetauscht werden, allerdings gibt es verschiedene Vor- und Nachteile. Der Austausch über Datenebene hat gegenüber der Funktionsebene einen entscheidenden Nachteil. Es müssen entsprechende Funktionen für die Abfrage von Modellen und das Erstellen von Modellelementen nachgebildet werden. Dies kann kompliziert werden, wenn ein Modellelement mit mehreren Daten korreliert. Weiterhin kann es sein, dass Modellelemente eine eindeutige ID besitzen, die global vom Werkzeug verwaltet wird. Die Erstellung von IDs außerhalb des Werkzeuges stellt ein Problem dar. Somit ist die Funktionsebene vorzuziehen, wobei allerdings die Funktionsebene eine stärkere Abhängigkeit zum Werkzeug bedeutet. Neben der Integrationsebene ist die Wahl einer geeigneten Integrationstopologie von Bedeutung. Davon hängt auch die Wahl eines geeigneten Austauschformates ab. Man kann zwei sinnvolle Topologien unterscheiden: eine Punkt-zu-Punkt-Topologie und eine Stern-Topologie. Bei einer Punkt-zu-Punkt Topologie können Modelle direkt transformiert werden. Bei einer Punkt-zuPunkt-Struktur wird für jedes Format eine Konvertierung zu jedem anderen Format definiert. Hier kann bei den einzelnen Konvertierungen sichergestellt werden, dass der größtmögliche Informationsumfang tatsächlich konvertiert wird, allerdings werden n(n − 1)-Konvertierungen benötigt. Diese Zahl reduziert sich auf 2n, wenn eine Stern-Topologie mit einem zentralen Intermediärformat definiert wird, über das sämtliche Konvertierungen vorgenommen werden. Hierbei bestimmt das Intermediärformat, inwiefern die Abbildungen zwischen den Formaten verlustfrei realisierbar werden können. 3.2 Transformationen Für die Umsetzung einer M3-Level-basierten Transformation ist ein detailliertes Verständnis über die Implementierung einer Modellhierarchie notwendig. Konkret bedeutet dies, dass der Zugriff auf Metamodelle und Modelle von Interesse ist. Aus diesem Grund haben wir verschiedene Modellhierarchien untersucht und sind zu einem einheitlichen Ergebnis bekommen. Die in Kapitel 2.1 definierten Modellhierarchie stellt eine logische Sicht dar. Diese muss noch um eine physische Sicht ergänzt werden, die sich mehr auf die Implementierung bezieht und den Zugriff der Modelle betrachtet. Im Wesentlichen ist die Datenstruktur der Metamodelle und Modelle von Interesse. Aus diesem Grund führen wir eine zweite Typ-Beziehung ein, die das konkrete Element der Datenstruktur zurückliefert. Betrachtet man zunächst die Beziehung zwischen Metametamodell und validen Instanzen, sprich Metamodellen, kann feststellt werden, dass die physische Typ-Beziehung gleich der logischen Typ-Beziehung ist. Dies bedeutet, dass das Metametamodell die Datenstruktur zur Speicherung 82 von Metamodellen vorgibt. Die Transformation der Metamodelle kann auf dieses spezifische Format bzw. API aufbauen. Bei Modellen ist dies nicht der Fall. Die physisch implementierte Datenstruktur für Modelle entspricht nicht notwendigerweise der Struktur der Metamodelle. Dies kann es auch nicht, da zur Implementierung der Datenstruktur die konkreten Metamodelle nicht feststehen. Vielmehr gibt es eine generische Datenstruktur, die von dem Metametamodell abgeleitet wird. Das Metametamodell gibt im Wesentlichen die Menge aller Modelle vor, welche durch die Metamodelle weiter eingeschränkt werden können. Somit ist die physische Typ-Beziehung nicht gleich der logischen Typ-Beziehung. Der physische Typ zeigt auf ein Element der Datenstruktur zur Modellspeicherung. Dies kann auch wiederum das Metametamodell sein. Oftmals gibt es aber noch zusätzliche Elemente zur Strukturierung von Modellen (Projekte oder Gruppen). Somit kann man Modellelemente unabhängig von konkreten Metamodellen zugegriffen werden. Eine Transformation baut somit auf der generischen Speicherstruktur auf und muss entsprechende Elemente durchlaufen. Bezogen auf das Visio-EMF-Beispiel kann die Transformation von Masters in EClasses mit dem Quellcode aus Listing 1 realisiert werden. Es werden alle Master-Elemente durchlaufen und entsprechende EClasses erzeugt. Auf Modellebene muss auf die generische Speicherstruktur zugegriffen werden (siehe Listing 2). Somit werden alle Shapes (korreliert zu Master) durchlaufen und entsprechende EObjects (korreliert zu EClass) erzeugt. Listing 1: Transformation von Master nach EClass (M2-Ebene) for ( IVMaster v i s i o M a s t e r : v i s i o M a s t e r s ) { EClass emfMaster = createEmfMaster ( v i s i o M a s t e r ) ; } Listing 2: Transformation von Shape nach EObject (M1-Ebene) f o r ( IVShape v i s i o S h a p e : v i s i o S h a p e s ) { EObject emfVisioShape = createEmfElement ( visioShape ) ; } 4 Diskussion In diesem Kapitel werden einige Vor- und Nachteile des M3T-Ansatzes gegenüber einer einfachen Modelltransformation diskutiert. 4.1 Implementierungsaufwand Die Anzahl und Komplexität von Transformationsregeln schlägt sich auf den Entwicklungsaufwand und der Komplexität der Transformation nieder. Bei einer M3T werden maximal vier Transformationen benötigt. Zwei dienen zur Transformation der Metamodelle, wobei eine die Hinrichtung und die andere die Rückrichtung realisiert. Analog ist dies für die Transformationen auf Modell-Ebene. Diese vier decken alle Metamodelle und dazugehörige Modelle ab. Würde man 83 eine einfache Modelltransformation verwenden, dann bräuchte man für jedes Metamodell eine Transformation in Hin- und Rückrichtung. Betrachtet man lediglich die Anzahl der Transformationen, würde sich der Aufwand zur Implementierung einer M3T ab einer Transformation von zwei Metamodellen lohnen. Betrachtet man anstatt der Transformation die zu implementierenden Transformationsregeln, dann kommt man zu einem ähnlichen Ergebnis. Bei einer M3T wird mindestens für jedes Element des Metametamodells eine Transformationsregel für die zwei Modellebenen benötigt. Somit ist die Anzahl der Transformationsregeln konstant. Bei einer einfachen Modelltransformation wird für jedes Element eines Metamodells eine Transformationsregel benötigt. Die Transformationsregeln steigen somit mit jeder Transformation für ein spezifisches Metamodell an. 4.2 Abstraktionsgrad Eine M3T ist gegenüber einer einfachen Modelltransformation ein generischer Ansatz. Grund hierfür ist, dass die Regeln auf einer abstrakteren Ebene, der Metametamodell-Ebene, als bei einer einfachen Modelltransformation definiert werden. Vorteil ist das alle Metamodelle und somit auch alle Modelle transformiert werden können. Nachteil ist, dass eine M3T nicht ohne weiteres auf spezifische Abbildung zwischen Metamodellen eingehen kann. Dies ist bspw. notwendig, wenn ein spezielles Zielmetamodell erreicht werden soll. Damit eine M3T dennoch auf spezifische Metamodelle angewendet werden kann, gibt es die im Kapitel 2.5 beschriebenen Möglichkeiten. 4.3 Wiederverwendung und Qualität Da die M3T auf einer hohen Abstraktionsebene ansetzt, ist auch der Grad der Wiederverwendung höher als bei einer auf ein bestimmtes Metamodell zugeschnitten Modelltransformation. Durch eine erhöhte Wiederverwendung ist dadurch letztendlich die Qualität höher, da Fehler bei mehrmaliger Verwendung behoben werden können. Des Weiteren wird durch die einheitliche Transformation der Metamodelle eine höhere Qualität erreicht. 5 Zusammenfassung In diesen Beitrag wurde der Ansatz der M3-Level-basierten Transformation vorgestellt, welche die Transformation von Modellen und Metamodellen zwischen Modellräumen ermöglicht. Bisher wurde der M3T-Ansatz in den verschiedenen Anwendungsbereichen nur unzureichend und oftmals in Abhängigkeit der zu integrierenden Werkzeuge betrachtet. In diesem Beitrag haben wir eine technologisch unabhängige Beschreibung gegeben, verschiedenen Eigenschaften sowie Vor- und Nachteile diskutiert. Entscheidend für den M3T-Ansatz ist Definition von Abbildungen auf einer höheren Abstraktionsebenen als bei einer normalen Modelltransformation. Entsprechend kann die Transformation 84 lediglich nur generisch Modelle abbilden. Für die reine Übernahme von Modelldaten ist dies unproblematisch. Wird allerdings eine Transformation auf ein spezielles vorgegebenes Metamodell benötigt, muss man von der generischen Transformation wieder zu dem spezifischen Metamodellformat kommen. Dies kann durch eine entsprechende Metamodell-Migration erreicht werden. Bisher gibt es keine Transformationssprache bzw. -system, was diese Transformationsart direkt unterstützt. Dies stellt einen Ansatzpunkt für weitere Arbeiten dar. Literatur [BCC+ 10] Brunelière, Hugo ; Cabot, Jordi ; Clasen, Cauê ; Jouault, Frédéric ; Bézivin, Jean: Towards Model Driven Tool Interoperability: Bridging Eclipse and Microsoft Modeling Tools. In: Kühne, Thomas (Hrsg.) ; Selic, Bran (Hrsg.) ; Gervais, Marie-Pierre (Hrsg.) ; Terrier, Francois (Hrsg.): Modelling Foundations and Applications 6th European Conference, ECMFA 2010, Paris, France, June 15-18, 2010. Proceedings Bd. 6138, Springer-Verlag, 2010 (LNCS), S. 32–47 [K0̈6] Kühne, Thomas: Matters of (Meta-) Modeling. In: Software and Systems Modeling 5 (2006), Nr. 4, S. 369–385 [Ker08] Kern, Heiko: The Interchange of (Meta)Models between MetaEdit+ and Eclipse EMF Using M3-Level-Based Bridges. In: Tolvanen, Juha-Pekka (Hrsg.) ; Gray, Jeff (Hrsg.) ; Rossi, Matti (Hrsg.) ; Sprinkle, Jonathan (Hrsg.): 8th OOPSLA Workshop on Domain-Specific Modeling at OOPSLA 2008, 2008 [KK07] Kern, Heiko ; Kühne, Stefan: Model Interchange between ARIS and Eclipse EMF. In: Tolvanen, Juha-Pekka (Hrsg.) ; Gray, Jeff (Hrsg.) ; Rossi, Matti (Hrsg.) ; Sprinkle, Jonathan (Hrsg.): 7th OOPSLA Workshop on Domain-Specific Modeling at OOPSLA 2007, 2007 [KK09] Kern, Heiko ; Kühne, Stefan: Integration of Microsoft Visio and Eclipse Modeling Framework Using M3-Level-Based Bridges. In: 2nd ECMDA Workshop on Model-Driven Tool & Process Integration, 24 June 2009, at Fifth European Conference on Model-Driven Architecture Foundations and Applications 2009. Enschede, Netherlands, 2009 [SBPM09] Steinberg, Dave ; Budinsky, Frank ; Paternostro, Marcelo ; Merks, Ed: EMF: Eclipse Modeling Framework. 2. Boston, MA : Addison-Wesley, 2009. – ISBN 978–0–321–33188–5 [Wim08] Wimmer, Manuel: From Mining to Mapping and Roundtrip Transformations – A Systematic Approach to Model-based Tool Integration, Vienna University of Technology, Diss., 2008 85 86 Anforderungen an ein Modell-Repository im Kontext eines MDSD-Entwicklungsprozesses Peter Hänsgen1 , Stefan Kühne2 1 2 Intershop Communications AG Intershop Tower 07740 Jena p.haensgen@intershop.de Institut für Angewandte Informatik e.V. an der Universität Leipzig Johannisgasse 26 04103 Leipzig kuehne@infai.org Kurzfassung: Die modellgetriebene Software-Entwicklung basiert auf den Prinzipien formale Modellierung und Ausnutzung von Modellen durch Modelloperationen wie beispielsweise Modelltransformationen und Code-Generierung. Modelle tragen damit im Gegensatz zu herkömmlichen modellbasierten Vorgehensweisen verstärkt den Charakter eines Implementierungsartefakts. Im industriellen Kontext ergibt sich hieraus die Anforderung, modellgetriebene Artefakte versioniert zu verwalten. Im Beitrag werden exemplarisch am Beispiel des Vorgehens bei der Entwicklung des E-Commerce-Systems Intershop Enfinity Suite die typischen benötigten Entwicklungswerkzeuge und die üblichen Arbeitsläufe erläutert, um daraus die Anforderungen an ein Modell-Repository abzuleiten. 1 Einleitung Der elektronische Handel mit Gütern und Dienstleistungen über das Internet, der auch als ECommerce bezeichnet wird, ist ein Wirtschaftszweig, welcher derzeit einem rasanten Wachstum unterliegt. Nach aktuellen Prognosen wird sich diese Entwicklung auch in den nächsten Jahren fortsetzen [Hau10]. Für Intershop als einen der führenden Hersteller von Software für dieses Marktsegment ist es daher notwendig, schnell auf wechselnde Anforderungen des Marktes reagieren zu können und mit geeigneten und innovativen Produkten die Bedürfnisse seiner Kunden zu erfüllen. Software für E-Commerce-Systeme muss es üblicherweise erlauben, für jeden Shop eines Kunden ein einzigartiges „Look & Feel“ zu erzeugen sowie spezifische Funktionen zur Verfügung zu stellen. Jedes System muss auf die Bedürfnisse des Kunden maßgeschneidert werden und die speziellen Anforderungen erfüllen, die sich beispielsweise aus der Integration in nachfolgende Prozessketten ergeben. Dabei ist zu beachten, dass es kein endgültig fertiges System gibt. Jedes E-Commerce-System unterliegt einer permanenten Pflege, Weiterentwicklung, Umgestaltung und Optimierung. 87 Um die Implementierungsaufwände für solche Shop-Systeme zu minimieren und die Wiederverwendung von bereits erstellten Software-Komponenten und bewährten Architekturen in verschiedenen Anwendungen zu maximieren, wurde bei Intershop in der Vergangenheit der Einsatz der modellgetriebenen Softwareentwicklung (engl. model-driven software development, MDSD) [SV06] intensiv untersucht. Dabei entstand eine umfangreiche Infrastruktur zur Modellierung, Validierung, Transformation und Generierung von Modellen. Die grundsätzliche Machbarkeit einer MDSD-basierten Entwicklung von E-Commerce-Systemen wurde dabei festgestellt [HB08]. Im praktischen Einsatz dieser Methodik bei der Entwicklung realer Produkte gibt es aber trotzdem noch ernsthafte Hindernisse, die sich insbesondere aus der Verwaltung der Modellartefakte und ihrer Handhabung in einem typischen Entwicklungsprozess ergeben. Die bisher existierenden Werkzeuge zur Verwaltung von traditionellem textbasiertem Programmcode sind dafür nur bedingt geeignet. Stattdessen wird zur Speicherung, Versionierung und Verwaltung von Modellen ein besonderes Modell-Repository benötigt [GH08]. Welche Anforderungen sich an ein solches Repository aus Sicht der Entwicklungstätigkeiten bei Intershop ergeben, wird im Folgenden näher beschrieben. 2 Entwicklung des E-Commerce-Systems Intershop Enfinity Suite 2.1 Modelle und Modelltypen Bei der Entwicklung von Enfinity kommen verschiedene Arten von Modellen zum Einsatz, die auf unterschiedlichen Technologien beruhen [Int10]. Exemplarisch sollen zwei Typen näher vorgestellt werden, welche den größten Anteil bei der Entwicklung ausmachen. Enfinity-Pipeline-Modelle Enfinity Pipelines sind Modelle von Programmabläufen, die durch den Server zur Laufzeit interpretiert werden können. Die Entwicklung von Pipelines erfolgt mit einem grafischen Editor im Enfinity Studio, der Entwicklungsumgebung für Enfinity (siehe Abbildung 1). Pipelines sind sowohl Bestandteil des Standardproduktes Enfinity als auch von darauf basierenden kundenspezifischen Lösungen. Die Standardpipelines sind in der Installation von Enfinity enthalten. Die projektspezifischen Pipelines sind in den jeweiligen Cartridges für das Kundenprojekt enthalten. Sie können entweder Standardpipelines ersetzen, ergänzen oder diese benutzen (z. B. als Subpipeline aufrufen). Die Speicherung von Pipeline-Modellen erfolgt in XML-Dateien. Für jede Pipeline existieren dabei mindestens zwei Dateien – eine zur Definition der eigentlichen Pipeline-Struktur und mindestens eine weitere zur Lokalisierung von Bezeichnern und Kommentaren in verschiedenen Sprachen. Die darstellungsbezogenen Daten (z. B. die Koordinaten von visuellen Abbildungen im Diagramm) werden ebenfalls in der Strukturdatei gespeichert. Das Metamodell der Pipelines ist proprietär und basiert auf Intershop-Technologien, d. h. es liegt derzeit kein standardkonformes EMF-Modell o. ä. vor [emf08]. Der XML-Serialisierungs- 88 Abbildung 1: Pipeline Editor bzw.-Deserialisierungsmechanismus der Pipeline-Dateien ist ebenfalls Intershop-spezifisch, d. h. es werden derzeit keine EMF-Resourcen verwendet. UML-Modelle Eine weitere Enfinity-typische Art von Modellen sind UML-Modelle [Groa]. Hierzu wurde auf Basis des Eclipse-UML2-Frameworks ein grafischer UML-Editor entwickelt, der die Erstellung von UML-Modellen und ihre Konfiguration mit UML-Profilen ermöglicht (siehe Abbildung 2). Es existieren UML-Profile für die Modellierung von verschiedenen Elementen, die als Eingabe für einen Code-Generator dienen. So wird beispielsweise die komplette Persistenzschicht aus den Modellen generiert. UML-Modelle sind ebenfalls in Enfinity-Cartridges abgelegt. Die Modelle des Standardproduktes sind Teil der binären Distribution von Enfinity, d. h. sie stehen in der Enfinity-Installation zur Verfügung und können durch Modelle aus Kundenprojekten referenziert werden, um z. B. Vererbungsbeziehungen zu allgemeinen Superklassen einrichten zu können. Typischerweise enthält eine Cartridge eine UML-Datei, die das Hauptmodell repräsentiert, welches dann weiter in UML-Packages zerlegt ist. Jede UML-Package wird in einer extra UML-Datei gespeichert. Damit können mehrere Entwickler verschiedene Packages parallel bearbeiten, ohne 89 miteinander in Konflikt zu geraten. Die Modelle werden konform zum UML2-Metamodell im XMI-Format abgespeichert [Grob]. Abbildung 2: Intershop UML-Editor 2.2 Werkzeuge zur Entwicklung von Intershop Enfinity Suite Die Entwicklung der E-Commerce-Software Intershop Enfinity Suite basiert auf einer umfangreichen Werkzeugkette. Im Folgenden werden einige der für die fokussierte Problemstellung relevanten Werkzeuge aufgeführt. Die Darstellung der Werkzeuge dient dem Problemverständnis und dokumentiert den Integrationsbedarf eines noch zu entwickelnden Modell-Repositories. Feature-Management Eingehende Feature- und Erweiterungswünsche werden zunächst in einer Feature-Request-Datenbank gesammelt und gespeichert. Die Einträge können mit wichtigen Informationen angereichert werden, z. B. mit ausführlichen Beschreibungen in Textform, Use-Case-Beschreibungen, Abbildungen, Diagrammen, Links auf andere Quellen usw. Featurewünsche werden durch ein Gremium bewertet, priorisiert und gegebenenfalls in der Projektplanung berücksichtigt. Projektplanung 90 Die Projektplanung erfolgt mit einem spezialisierten Werkzeug. Dabei werden einzelne Arbeitspakete identifiziert und Ressourcen (Entwicklern) zugeteilt. Mit dem Tool können die tatsächlich geleisteten Aufwände der Mitarbeiter erfasst und ihre Auswirkungen auf den geplanten Fertigstellungstermin ermittelt werden. Die Projektplanung unterliegt gewissen Unsicherheiten und muss regelmäßig dynamisch den aktuellen Erfordernissen angepasst werden. Geplante Features können beispielsweise gekürzt, neue Features müssen aufgenommen werden. Versionierungssystem Zur Speicherung und Versionierung aller Entwicklungsergebnisse (Dokumente, Quelltext, Modelle, u. ä.) wird ein Source-Code-Management-System (SCM) verwendet. Die zentralen Konzepte von SCM-Systemen, wie z. B. Locking, Branches, Mergen von Branches usw. haben sich in den vielen Jahren der Nutzung bei Intershop bewährt. Problematisch aus Sicht von Intershop sind Schwächen im Rechte-Management, welches insbesondere für die Steuerung des Zugriffs von externen Entwicklern benötigt wird, und bei der Versionierung von Modellen. Wie mit einem Versionierungssystem gearbeitet wird, hängt erheblich von der Art des Entwicklungsvorhabens ab. So ist bei einer Standardsoftware wie Intershop Enfinity Suite von einer mehrjährigen Pflege und Wartung mit vielen verschiedenen Versionen in eigenständigen Zweigen auszugehen, während vielleicht in einem kleineren Vorhaben im Rahmen eines Kundenprojektes die Weiterentwicklung tendenziell auf einem einfachen linearen Hauptstamm erfolgt. Entwicklungsumgebung Bei Intershop kommt die Entwicklungsumgebung Enfinity Studio zum Einsatz. Sie stellt eine Erweiterung von Eclipse um zahlreiche Enfinity-spezifische Editoren, Views usw. dar. Dabei werden die Enfinity-Architektur und die Besonderheiten bei der Entwicklung von Enfinity-Anwendungen (z. B. Teile der Modelle liegen in der Enfinity-Installation vor, andere Teile in den Projekt-Cartridges) voll unterstützt. Enfinity Studio kommt sowohl bei der Entwicklung von Enfinity selbst als auch in Kundenprojekten zum Einsatz. Es ist dabei nicht Bestandteil einer Enfinity-Installation, sondern wird separat ausgeliefert. Damit kann es bei der Entwicklung von verschiedenen Zielsystemen (z. B. gleichzeitige Arbeit an verschiedenen Enfinity-Versionen, je nach aktuellem Projekt) eingesetzt werden, ohne es mehrfach installieren zu müssen. Typischerweise wird durch die Entwickler im Enfinity Studio ein zusätzliches Plugin installiert, um den Zugriff auf im SCM versionierte Dateien zu erleichtern. Weitere Eclipse-Erweiterungen können verwendet werden. Bug-Tracking Fehler werden in einem Bug-Tracking-Werkzeug erfasst. In diesem Tool werden ausschließlich Fehler verwaltet, aber keine neuen Features oder ungeplante Erweiterungswünsche organisiert. Ein Bugeintrag beinhaltet beschreibende Informationen zu den Umständen des Fehlers, um eine Reproduzierbarkeit zu erreichen. Weiterhin ist ersichtlich, ob und wann der Fehler durch wen in welcher Release beseitigt wurde und welche Änderungen in der Codebasis dazu notwendig waren. Build-Werkzeuge Neben der Verwaltung der Quelltexte und Quellmodelle ist eine umfangreiche Werkzeugunterstützung für den Build-Prozess notwendig. Dabei müssen Teilprojekte in ihre binäre Form übersetzt, 91 abgelegt und als auslieferbare Distribution zusammengefügt werden. Hierbei muss nachvollziehbar bleiben, in welcher Distribution welche Änderungen enthalten sind. 2.3 Typische Arbeitsabläufe Im Folgenden werden zwei für die Entwicklung bzw. Weiterentwicklung von Enfinity typische Arbeitsabläufe vereinfacht geschildert, um die notwendigen Interaktionen mit einem ModellRepository zu verdeutlichen. Entwicklung eines neuen Features Der folgende Ablauf schildert die exemplarische modellgetriebene Entwicklung eines neuen Enfinity-Features. 1. Feature-Request: Ein Auftraggeber (z. B. ein Entwickler, Kunde, Support-Mitarbeiter) wünscht sich ein neues Feature. Das Feature wird in Textform beschrieben und in der FeatureRequest-Datenbank abgelegt. 2. Feature-Auswahl: Bei der Planung der Entwicklung einer neuen Enfinity-Version werden durch ein Planungsgremium die zu entwickelnden Features ausgewählt. 3. Task: Ein Entwickler erhält den formalen Auftrag, das Feature zu entwickeln. Dazu wird im Projektplanungstool eine Task angelegt und dem Entwickler zugewiesen. 4. Feature-Branch: Es wird ein neuer Branch im Repository angelegt, der das neue Feature enthalten soll. Der Branch zweigt vom Integrationsbranch der gewählten Enfinity-Ausgangsversion ab. Die Konfiguration des Branches wird dem Entwickler mitgeteilt, der seine Arbeitsumgebung so anpasst, dass er auf diesem Branch arbeiten kann. 5. Implementierung des Features: Der Entwickler führt die notwendigen Arbeiten im FeatureBranch durch. Dazu werden existierende Modellelemente geändert und/oder neue Modellelemente hinzugefügt. Die Arbeitszeit wird im Projektplanungstool eingetragen. 6. Fertigstellung des Features: Der Entwickler ist mit der Arbeit fertig und hat alle Arbeitsergebnisse in das Repository eingecheckt. Ein Feature-Review durch ein entsprechendes Gremium hat stattgefunden und die Entwicklungsergebnisse wurden akzeptiert. 7. Merge des Feature-Branches in den Release-Branch: Das Feature kann nach seiner Fertigstellung in den Integrationsbranch der neuen Enfinity-Release übernommen werden. Dazu müssen die veränderten Elemente ermittelt und mit dem Zielbranch zusammengeführt werden. Konflikte während des Merges sind manuell zu lösen. 8. Build der Release: Der automatische Buildprozess liest den Repository-Inhalt für den Integrationsbranch aus und erzeugt eine neue Enfinity-Release. Das entstandene Produkt wird automatisch getestet. 92 9. Release: Bei erfolgreichem Abschluss und Test der Arbeiten erfolgt eine Release. Es werden alle Änderungen, die in der neuen Version enthalten sind, anhand der Checkin-Kommentare aus dem Repository automatisch ermittelt und zu einer Release-Dokumentation (z. B. in HTML-Form) zusammengefasst. 10. Labeling: Die Revision, die zum erfolgreichen Bau der Release führte, wird mit einem speziellen symbolischen Label versehen, um sie später eindeutig adressieren zu können. 11. Merge in den Hauptbranch: Alle Artefakte der Release werden vom Integrationsbranch in den Hauptbranch überführt. Anschließend kann ein neuer Branch für die nächste Release abgezweigt werden. Entwicklung eines Bugfixes Der folgende Ablauf schildert (vereinfacht) die Korrektur eines Fehlers eines existierenden Features. 1. Bug-Report: Es wird ein Fehlverhalten des Systems festgestellt. Die Symptome werden in einem Bug-Report beschrieben und im Bugtracker abgelegt. Weiterhin werden Informationen zu den Umständen des Bugs (z. B. betroffene Produktversion) und Hinweise zur Nachvollziehbarkeit gegeben. 2. Bug-Priorisierung: Die Notwendigkeit eines Fixes wird festgestellt. 3. Task: Ein Entwickler erhält den Auftrag, das Problem zu lösen. Eine entsprechende Task wird im Projektmanagement-Tool angelegt. Der Bug wird dem Entwickler zugewiesen. 4. Ursachenforschung: Der Entwickler stellt sich eine geeignete Umgebung (z. B. eine Enfinity-Installation der spezifischen Version) zusammen, um den Bug nachvollziehen zu können. Die Ursache wird identifiziert. 5. Bugfix-Branch: Es wird eine Enfinity-Release ausgewählt, in der der Fehler behoben werden soll. Typischerweise ist dies der Integrationsbranch für eine in der Entwicklung befindliche Release. Der Entwickler passt seine Arbeitsumgebung an, so dass er auf diesem Branch arbeiten kann. 6. Implementierung des Fixes: Das Problem wird gelöst und der Fix in das Repository eingecheckt. Beim Checkin wird ein Bezug zum Bug hergestellt. 7. Dokumentation des Fixes: Die gefundenen Ursachen werden im Bugtracker im Bugeintrag dokumentiert. Die im Fix veränderten versionierten Objekte werden aufgelistet bzw. referenziert. Der weitere Ablauf entspricht dem ersten Szenario ab Punkt 8). Der weitere Ablauf entspricht dem ersten Szenario ab Punkt 8). Um die Beispielszenarien in der genannten Weise durchführen zu können, ergeben sich aus Prozesssicht verschiedene Anforderungen an die Funktionalität des Modell-Repositories, die im Folgenden diskutiert werden. 93 3 Anforderungen an ein Modell-Repository 3.1 Berechnung von Modelldifferenzen Das derzeit verwendete Versionierungssystem ist nicht in der Lage, Modelldateien als strukturierte Modelle zu verarbeiten. Es findet vielmehr immer ein Vergleich / Merge von Textfragmenten statt. D.h. zum Vergleich wird nicht die abstrakte Syntax des Modells verwendet, sondern die konkrete syntaktische Ausprägung in Form von Text. Dabei kann es zur Feststellung von Differenzen im Text kommen, die eigentlich keinerlei Unterschied in der Struktur oder Semantik des Modells darstellen. So werden unterschiedliche Whitespaces (Leerzeichen, Tabs) sowie veränderte Zeilenumbrüche als Differenz zwischen zwei Texten wahrgenommen. Eine Veränderung der Reihenfolge von Modellelementen ist zwar textuell unterschiedlich, hat aber inhaltlich nicht unbedingt eine Auswirkung auf das Modell (allerdings gibt es auch Fälle, wo die Reihenfolge wichtig ist). Beispielsweise ist die Veränderung der Reihenfolge von Attributen in einem XML-Element inhaltlich irrelevant, als Text betrachtet aber ein signifikanter Unterschied. Die Probleme treten auf, weil das Repository kein „Verständnis“ über die enthaltenen Strukturen und Bedeutungen der Textdateien hat. 3.2 Repräsentation von Differenzen zwischen grafischen Modellen Grundlage zur manuellen Auflösung von Merge-Konflikten ist die benutzeradäquate Darstellung (Visualisierung) von Differenzen zwischen Modellen. Eine textuelle Darstellung führt insbesondere bei grafischen Modellen zu Problemen, da diese für den Entwickler eine ungewohnte Perspektive darstellt. Der dadurch nur unzureichend hergestellte Bezug zu den Artefakten erschwert dem Entwickler die Identifikation von Konfliktursachen und deren Auflösung (siehe Abbildungen 3 und 4). Bei den Modellen, die in Enfinity verwendet werden, sind die Informationen über die grafische Darstellung des Modells Bestandteil der Modelldatei (z. B. als Annotationen in UML-Dateien, als XML-Elemente in Pipeline-Dateien). Eine Änderung eines Modells erfolgt in einem grafischen Editor und hat daher neben der Änderung in der abstrakten Syntax des Modells (z. B. Umbennennung einer Klasse) auch eine Änderung in der konkreten graphischen Syntax (z. B. Vergrößerung der Figur für die Klasse wegen längerem Namen) zur Folge. Diese Unterschiede werden bei der Differenzbildung auf Basis von Textdateien erkannt, können aber durch den Entwickler nicht visuell erfasst und richtig interpretiert werden. 3.3 Identifikation von Merge-Konflikten Beim Mergen von zwei Versionen einer Textdatei (z. B. aus unterschiedlichen Branches) gibt es verschiedene Fälle, die unterschieden werden können: 94 Trivialer Merge: Beide Versionen stimmen überein. Es sind keine inhaltlichen Veränderungen notwendig. Einfacher Merge: Das Element wurde in einem der Branches seit der Abzweigung nicht mehr verändert, d. h. es erfolgten lediglich Änderungen in dem anderen Branch, die konfliktfrei übernommen werden können. Alternativ können auch in beiden Branches Änderungen erfolgen, die sich aber nicht widersprechen und nicht die gleichen Bereiche der Textdatei betreffen. Als Spezialfall können in beiden Branches auch die gleichen Änderungen parallel durchgeführt worden sein, so dass der textuelle Inhalt wieder übereinstimmt. Einfache Merges können automatisiert werden. Merge-Konflikt: Es wurden Änderungen durchgeführt, die überlappende Bereiche im Text betreffen. Solche Konflikte müssen durch einen Entwickler manuell und interaktiv im MergeWerkzeug aufgelöst werden. Abbildung 3: Textuelle Differenz von Pipelines Es ist zu beachten, dass die obigen Definitionen und Merge-Konflikte daraus resultieren, dass die Differenzbildung und das Mergen bisher auf Textvergleichen beruhen. Bei einem ModellRepository, welches intern die Modellstrukturen versteht, könnten Merge-Konflikte anderweitig verursacht werden. So hat beispielsweise die Art der Identifizierung von vergleichbaren Modellelementen einen großen Einfluss auf das Ergebnis der Operation. Durch die textuelle Verarbeitung 95 Abbildung 4: Textuelle Differenz von UML-Modellen können, genau wie bei der Differenzbildung, Merge-Konflikte festgestellt werden, die eigentlich aus Modellsicht keine sind, da sich inhaltlich nichts geändert hat, sondern es nur syntaktische Unterschiede gibt. 3.4 Manuelle Auflösung von Merge-Konflikten Zur Auflösung von Merge-Konflikten hat sich die Nutzung eines 3-Wege-Merge-Systems bewährt, mit dem der Entwickler verschiedene Versionen einer Datei textbasiert zusammenführen und gegebenenfalls manuell korrigieren kann (siehe Abbildung 3). Ein manueller Merge kann nicht nur der Auflösung von Konflikten dienen, sondern erlaubt auch die selektive Übernahme von ausgewählten Änderungen in die Zielversion. Wenn beispielsweise in einem Branch mehrere Features implementiert wurden, von denen aber nur eins in die Zielversion übernommen werden soll, kann dies selektiv durch die Übernahme von ausgewählten Textpassagen erreicht werden. Bei den anderen Passagen behält man den originalen Inhalt bei. Ein manueller Merge von Modellen ist auf diesem Wege derzeit aber praktisch nicht möglich. 96 3.5 Automatisierte Auflösung von Merge-Konflikten Die weitgehend automatisierte Durchführung von Merges ist Voraussetzung für den effizienten Umgang mit großen Datenmengen und einer großen Zahl von Dateien (6-stellige Anzahl). Ein manueller Merge kann daher nur die Ausnahme sein, und nicht die Regel. Zur Vermeidung von Merge-Konflikten müssen daher auch organisatorische Maßnahmen beitragen. Beispielsweise ist es häufig einfacher, öfters kleinere Änderungen zusammenzuführen, als selten große. „Echte“ Merge-Konflikte können nicht automatisiert behandelt werden, sondern erfordern immer eine Entscheidung bzw. Maßnahmen des Entwicklers. Allerdings wäre eine Automatisierung der gezielten Übernahme von Teiländerungen (z. B. Merge von einzelnen Features) denkbar. Dazu müsste das Repository aber Änderungen in einen Zusammenhang stellen können, was derzeit nicht möglich ist. Abbildung 5: Manueller 3-Wege-Merge mit Rational Clearcase 3.6 Granularität von Artefakten Um eine Änderung eines versionierten Elementes durchführen zu können und Merge-Aufwände beim Commit zu vermeiden, muss es vorher explizit im aktuellen Branch für alle anderen Nutzer 97 gesperrt werden. Das Sperren erfolgt dabei auf den Elementen, die das SCM unterstützt, also auf Dateien und Verzeichnissen. Die explizite Sperrung ist beabsichtigt, weil dadurch nachträgliche ungewollte und möglicherweise aufwändige Merge-Operationen vermieden werden können. Das Sperren kann sich nachteilig auf die parallele Entwicklung auswirken, wenn mehrere Entwickler Zugriff auf die gleichen Dateien benötigen. Dies verschärft sich insbesondere dann, wenn wenige große Dateien (z. B. UML-Modelle) anstatt vieler kleiner Dateien bearbeitet werden müssen. Für eine hohe Parallelität bei der Entwicklung ist daher ein feingranulares Sperren notwendig. Um trotz der expliziten Sperren wenigsten Teilmodelle durch verschiedene Entwickler parallel bearbeitbar zu machen, wurden die Enfinity-UML-Modelle in kleinere Pakete zerlegt. Derzeit wird jedes UML-Package (äquivalent zu einem Java-Package) in einer eigenen Datei gespeichert. Dies erschwert jedoch den Umgang mit UML-Modellen, da aus der Zerlegung zahlreiche Verlinkungen zwischen abhängigen Dateien resultieren. Zu einem möglichst konfliktfreien Sperren von Dateien können ebenfalls organisatorische Maßnahmen notwendig sein, z. B. die Aufteilung der Entwicklerkapazitäten auf verschiedene unabhängige Features. 3.7 Unterstützung von Refactoring-Prozessen Refactoring, also die Umstrukturierung von Source-Code und Modellen, betrifft einerseits die Inhalte von Textdateien, als auch andererseits den Speicherort (z. B. bei Dateiverschiebungen) und die Dateinamen (z. B. bei Umbenennung einer Java-Klasse). Bei Umbenennungen und Verschiebungen müssen daher Änderungen sowohl „außerhalb“ als auch „innerhalb“ der Datei synchronisiert durchgeführt werden. Oftmals sind mehrere Dateien betroffen, z. B. abhängige Java-Klassen. Bei textuellen Sprachen, wie z. B. Java oder textuellen domänenspezifischen Sprachen (DSL), ist ein Refactoring noch vergleichsweise einfach lösbar, weil es keine statische Verlinkung zwischen den Dateien gibt. Es wird nur Text entwickelt, der erst zum Zeitpunkt des Compilierens einen konsistenten Zustand haben muss. Die Bearbeitung des Textes ist jederzeit möglich, auch wenn er beispielsweise inhaltlich zwischenzeitlich keinen gültigen Java-Code ergibt. Bei UML-Modellen hingegen, insbesondere wenn sie in viele kleinere UML-Packages zerlegt wurden, gibt es direkte Referenzen auf Modellelemente zwischen den Dateien, z. B. in Form von URIs auf Objekte. Wenn ein UML-Modell umbenannt wird, müssen sämtliche abhängigen UMLModelle ebenfalls korrigiert werden, weil sie ansonsten – im Gegensatz zu textuellen Artefakten – inkonsistent werden und nicht mehr vom UML-Editor geladen werden können. Darum ist das Refactoring von Modellen auf Basis von XMI-Dateien derzeit ein gravierendes Problem, welches durch ein Modell-Repository geeignet zu lösen ist. 3.8 Abbildung von Abhängigkeitsbeziehungen zwischen Modellen Abhängigkeiten zwischen Modellen (also Modelldateien) sind derzeit, wie im obigen Beispiel beschrieben, meist explizit ausgedrückt, z. B. durch URIs. Es gibt verschiedene Dimensionen, in 98 denen Abhängigkeiten bestehen können, z. B. die Kompositionsdimension von Gesamtmodellen aus Teilmodellen, die Instance-of-Dimension bei Beziehungen eines Modells zu seinem Metamodell usw. Die Ablage von Modellen erfolgt nicht einheitlich in einem globalen Repository, sondern es gibt verschiedene Medienbrüche. Beispielsweise ist das UML-Metamodell in einem Eclipse-Plugin definiert, die Enfinity-UML-Modelle liegen hingegen in der Enfinity-Installation oder in dem aktuellen Entwicklungsprojekt vor. Das erschwert die korrekte Auflösung von Abhängigkeiten. Neben dem Refactoring (also der Umstrukturierung) von Modellen findet natürlich auch eine Evolution (also eine Weiterentwicklung) der Modelle statt, d. h. es entsteht zusätzlich ein Versionierungsproblem. Zur Lösung müssen Abhängigkeiten ggf. durch eine Migration korrigiert werden. Derzeit gibt es keine geeignete Werkzeugunterstützung für Modellmigrationen. 3.9 Werkzeugintegration Die Werkzeuge, die in Entwicklungsprojekten zum Einsatz kommen, stammen in der Regel von verschiedenen Herstellern, basieren auf unterschiedlichen Architekturen, arbeiten autark und haben keine gemeinsame Plattform. Daraus ergeben sich Probleme bei der Integration der Werkzeuge miteinander. Für einen Entwickler wäre die Unterstützung eines ganzheitlichen „EntwicklungsWorkflows“ gemäß dem vordefinierten Entwicklungsprozess und eine einheitliche Sicht auf alle relevanten Artefakte wichtig, bei der die Informationen aus den einzelnen Werkzeugen miteinander verknüpft werden und damit eine einfache Zuordnung von Aktivitäten, ihren Ursachen und ihren Auswirkungen möglich ist (wer hat was wann warum gemacht und was hat die Änderung für Seiteneffekte und Nachwirkungen?) 4 Zusammenfassung Die modellgetriebene Software-Entwicklung basiert auf den Prinzipien formale Modellierung und Ausnutzung von Modellen durch Modelloperationen wie z. B. Modelltransformationen. Modelle tragen damit im Gegensatz zu herkömmlichen modellbasierten Vorgehensweisen verstärkt den Charakter eines Implementierungsartefakts. Im industriellen Kontext ergibt sich hieraus die Anforderung, modellgetriebene Artefakte versioniert zu verwalten. Die aufgezeigten Problemstellungen einer bisher praktizierten textuellen Versionskontrolle für grafische Modelle führen dazu, dass sich die Potenziale modellgetriebener Entwicklung (insbesondere zur Verbesserung der Produktivität, Qualität, Wartbarkeit) schnell relativieren. Eine adäquate Versionsverwaltung für modellgetriebene Artefakte wird damit zum kritischen Erfolgsfaktor. 99 Literatur [emf08] Eclipse Modeling Framework Project (EMF). Version: June 2008. – Abruf: 27.4.2011 http://www.eclipse.org/modeling/emf/. [GH08] Gebauer, Martin ; Hänsgen, Peter: Ein Repository für die modellgetriebene Softwareentwicklung. Version: September 2008. http://orvia.informatik.uni-leipzig.de/Projekt/ OrviaBuch2008. In: Fähnrich, Klaus-Peter (Hrsg.) ; Kühne, Stefan (Hrsg.) ; Thränert, Maik (Hrsg.): Model-Driven Integration Engineering – Modellierung, Validierung und Transformation zur Integration betrieblicher Anwendungssysteme Bd. XI. Leipzig : Eigenverlag Leipziger Informatik-Verbund (LIV), September 2008. – ISBN 978–3–941152–02–1, 291–300 [Groa] Group, Object M.: Unified Modeling Language. Object Management Group. http://www.uml. org. – Abruf: 27.4.2011 [Grob] Group, Object M.: XML Metadata Interchange (XMI). Object Management Group. http://www. omg.org/spec/XMI/index.htm. – Abruf: 27.4.2011 [Hau10] Hauptverband des Deutschen Einzelhandels: E-Commerce-Umsatz 2010: HDE erwartet 23,7 Mrd. Euro. http://www.ebusiness-handel.de/pb/site/eco/node/142076/Lde/index. html. Version: 2010. – Abruf 27.4.2011 [HB08] Hänsgen, Peter ; Budich, Thomas: Konzept für die modellgetriebene Entwicklung von Geschäftsanwendungen. Version: September 2008. http://orvia.informatik.uni-leipzig.de/ Projekt/OrviaBuch2008. In: Fähnrich, Klaus-Peter (Hrsg.) ; Kühne, Stefan (Hrsg.) ; Thränert, Maik (Hrsg.): Model-Driven Integration Engineering – Modellierung, Validierung und Transformation zur Integration betrieblicher Anwendungssysteme Bd. XI. Leipzig : Eigenverlag Leipziger Informatik-Verbund (LIV), September 2008. – ISBN 978–3–941152–02–1, 171-187 [Int10] Intershop Communications AG: Intershop Enfinity Suite 6.4 – Application Programming Guide. Intershop Communications AG, 2010 [SV06] Stahl, Thomas ; Völter, Markus: Model-Driven Software Development – Technology, Engineering, Management. John Wiley & Sons Inc., 2006. – ISBN 978–0470025703 100 Graph-basierte Speicherung und Versionierung von Modellen Steffen Dienst, Stefan Kühne Institut für Angewandte Informatik e.V. an der Universität Leipzig Johannisgasse 26 04103 Leipzig {dienst | kuehne}@infai.org Kurzfassung: Die Speicherung, Versionierung und Traversierung von Modellen mit herkömmlichen VCS ist nicht zureichend. Aufgrund ihrer inhärenten Graphstruktur bietet sich jedoch eine Persistierung in native Graph-Datenbanken an. Dieser Beitrag untersucht die notwendigen Abbildungen und betrachtet Graph-Transformationen, die verschiedene Arten der Speicherung von Graphversionen erlauben. 1 Anforderungen an Modell-Persistierung und -versionierung 1.1 Grundbegriffe Im Kontext dieses Beitrags werden Modelle im Sinne von automatisiert les- und inter-pretierbaren Repräsentationen von Aspekten und Sichten von Anwendungdomänen gebraucht. Nach Herbert Stachowiak [Sta73] ist ein Modell gekennzeichnet durch: Abbildung: Ein Modell ist immer ein Abbild bzw. eine Repräsentation eines Originals Verkürzung: Ein Modell erfasst nicht alle Attribute eines Originals, sondern nur diefür einen Einsatzzweck relevanten. Pragmatismus: Ein Modell wird vom Modellierer zu einem bestimmten Zweck statt des Originals eingesetzt. Dabei wird im ISO-Standard 19502 [Int05] zwischen vier Ebenen unterschieden: 0: M0 - Elemente der Realität, im Allgemeinen unverkürzt. 1: M1 - Instanzmodelle, Abbildung der Realität 2: M2 - Metamodell, Sprachelemente zur Definition von M1-Modellen 3: M3 - Metametamodell, übergreifende Sprachkonzepte zur Definition von M2-Modellen 101 1.2 Versionierung auf Strukturebene Die Struktur von Modellen unterscheidet sich deutlich von unstrukturierten Textdateien, welche in herkömmlichen VCS verwaltet werden. Die Granularität, die bei Textdateien versioniert wird, erstreckt sich über Verzeichnisstrukturen, Dateien bis hin zu einzelnen Textzeilen. Die Struktur der Informationen, die in diesen Textzeilen enthalten ist, ist für die Versionierung im Allgemeinen irrelevant. Modelle lassen sich mit diesen Werkzeugen nicht ausreichend komfortabel verwalten. Textuelle Repräsentationen von Modellen sind für Datenaustausch und maschinelle Interpretationen ausreichend, sind jedoch für Menschen nur schwer verständlich. Wird ein solches Modell nun konkurrierend verändert und muss manuell zu einem gemeinsamen Änderungsstand gemischt werden, können auf Textzeilenebene Konflikte auftreten, die semantisch im Modell keine Entsprechung haben und umgekehrt. Dazu ist eine textuelle Repräsentation eines Modells meist sehr detailliert und umfangreich, so dass die Art der Änderungen im Modell durch Inspektion des Textes nicht oder nur sehr aufwendig erkannt werden können. Diese Problematik resultiert aus einer unangemessenen Repräsentation von Modellen für Versionierungszwecke. Es lassen sich folgende Anforderungen an ein Versionierungssystem erkennen: • Die Granularität der Versionierung sind die Modellstrukturen (genauer: Elemente des M3/ M2-Modells). • Beziehungen (Referenzen) zwischen Modellelementen und zwischen verschiedenen Modellen müssen versioniert werden. • Beziehungen (Referenzen) zwischen Modellelementen und zwischen verschiedenen Modellen müssen versioniert werden. • Unterschiede zwischen Modellversionen müssen • Eine Unterstützung für automatisches Mischen von konfliktfreien konkurrierenden Modelländerungen soll unterstützt werden. • Änderungen an Metamodellen sollen unterstützt werden. 1.3 Abgrenzung von Metamodellevolution Ein spezielles Problem der Versionierung von Instanzmodellen ist die Notwendigkeit der Konformität zu einem fixen Metamodell. Sobald sich die Struktur dieses Metamodells ändert, werden existierende Instanzmodelle meist ungültig. Existierende Werkzeuge, die versuchen, automatisiert Änderungen des Metamodell in Instanzmodellen nachzuvollziehen, arbeiten meist auf der Ebene der einzelnen Editieroperationen des Anwenders. Ein Beispiel dafür ist COPE [Her10]. Diese Problematik lässt sich durch die Art der Speicherung von Versionsdaten nicht beheben und ist deshalb nicht Bestandteil dieses Beitrags. 102 2 Existierende Persistierungs- und Versionierungssysteme für Modelle 2.1 Textbasiert: XML/MOF Textuelle Repräsentation können unterschieden werden in domänenspezifische Sprachen und Serialisierungen, etwa in MOF1 bzw. XML. Während die Versionierung in herkömmlichen VCS von DSLs im Allgemeinen problemlos möglich ist, stellt sich die Versionierung und vor allem die konkurrierende Bearbeitung von XML problematisch dar. Einfache semantische Änderungen eines Modells können zu unübersichtlichen Änderungen der XML-Repräsentation führen. So ergibt etwa die Umkehrung einer Beziehung zwischen zwei Klassen in einem UML-Klassendiagramm mit dem Werkzeug Eclipse UML2 Änderungen an sechs verschiedenen XML-Elementen. Wenn nun zwei Änderungen dieses Modells miteinander kombiniert werden sollen, ist selbst bei semantischer Konfliktfreiheit oftmals die Kombination der beiden XML-Dokumente nicht konfliktfrei möglich. Ein weiteres Problem ist, dass Referenzen zwischen Modellen aufwendig zu pflegen sind. Eine Verletzung von Referenzen ist nur zu erkennen, indem alle beteiligten Modelle deserialisiert und auf Konsistenz untersucht werden. 2.2 Relational Das relationale Datenbankmodell eignet sich augenscheinlich gut für den Einsatz zur Persistierung von Modellen. Jede Klasse wird als Tabelle abgebildet, Attribute als Spalten, Modellreferenzen als Referenzen auf Tabellenzeilen. Praktisch ergeben sich jedoch eine Reihe von Problemen. Das Metamodell ist in Form der Tabellenstruktur fixiert. Eine Änderung ist im Allgemeinen nicht möglich. Die Tabellen selbst sind häufig nur sehr dünn besetzt, da Instanzmodelle nicht für alle im Metamodell definierten Attribute Werte enthalten müssen. Dies führt zu einem hohen und unnötig aufgeblähten Speicherverbrauch sowie einer schlechteren Abfrageperformanz. Zuletzt ist der Aufwand der Wiederherstellung eines Modells unter Umständen sehr hoch, da etwa für die Rekonstruktion von mehrwertigen Attributen mitunter sehr komplexe Join-Operationen notwendig sind. 2.3 Objektorientiert Objektdatenbanken erlauben die Serialisierung von konkreten Instanzen einer objektorientierten Programmiersprache. Vorteilhaft ist die hohe Performanz bei Speicherung und Wiederherstellung von Modellen. Es ist jedoch nicht bzw. nur aufwendig möglich (etwa durch Verwendung des Proxy-Entwurfsmusters), Teile von Objekten zu deserialisieren. Auch die Iteration über serialisierte Modelle ist schwierig da stark von den konkreten binären Speicherstrukturen abhängig. Die Austauschbarkeit von serialisierten Modellen ist ebenfalls stark beschränkt, da nur dieselbe Programmiersprache genutzt werden kann, in der das Modell gespeichert wurde. 1 http://www.omg.org/spec/MOF/2.0/ 103 2.4 Operationsbasiert Eine weitere Möglichkeit, Modelle zu versionieren ist es, Änderungsoperationen, die bei der Bearbeitung verwendet werden, zu speichern. Zur Wiederherstellung einer Modellversion braucht man die Ursprungsversion und eine Sequenz von Operationen, die sequentiell angewendet werden müssen. Für die Aufzeichnung ist eine geeignete Editorunterstützung notwendig. Änderungen an Modellen außerhalb dieses Editors können nicht erfasst werden und führen zu Inkonsistenzen in der Versionierung. 3 Graph-basierte Speicherung 3.1 Grundlagen Ein Graph G ist ein Tupel (V, E), wobei V eine Menge von Knoten darstellt und E eine Menge von Paaren von Elementen aus V, genannt Kanten. Diese Kanten stellen gerichtete Verbindungen zwischen den Knoten aus V dar. Ein Graph heißt azyklischer, gerichteter Graph (directed acyclic graph DAG), wenn er zusätzlich zu obiger Definition keine Zyklen hat. Es gibt also keinen Pfad, der ausgehend von einem Knoten gerichtete Kanten verfolgt und zu demselben Knoten zurückführt. 3.2 Versionierungsinformationen Ein Versionierungsverwaltungssystem muss neben den eigentlichen Inhalten, die versioniert werden, auch Informationen über Revisionen, Entwicklungszweige (Branches), Metadaten und den Beziehungen zwischen diesen Konzepten verwalten. Abbildung 1 zeigt exemplarisch drei Entwicklungszweige mit den entsprechenden Revisionen. Die enthaltenen Elemente sind im Einzelnen: Revisionen, Branches und Tags (benannte Zeiger auf Revisionen). Revisionen enthalten Metainformationen über eine einzelne Version, wie etwa Name des Commiters, einen Zeitstempel, eine Beschreibung der Änderungen und Informationen darüber, welche Modelle in dieser Revision verändert wurden. Jede Revision, bis auf die erste, hat mindestens einen Vorgänger. Stellt eine Revision die Wiedervereinigung zweier Branches dar (Merge), hat sie zwei Vorgänger. Diese gesamte Struktur stellt einen gerichteten azyklischen Graphen dar (siehe Abschnitt 4.1), lässt sich also direkt homomorph in einer graphbasierten Datenbank speichern. 104 HEAD main commit 11 Release 1 (Tag) Branch3 HEAD Branch 3 commit 8 (merge) commit 10 commit 5 commit 9 Branch 2 commit 7 commit 4 commit 6 commit 3 commit 2 commit 1 author ... date ... Versionsbaum Abbildung 1: Entwicklungszweige und Revisionen 3.3 Speicherungsstrukturen Modelle sind konform zu einem Metamodell, dieses wiederum zu einem Meta-Metamodell (M3Modell, siehe [Int05]). Dieser Betrachtung soll ein hypothetisches, vereinfachtes M3-Modell zugrunde liegen: Es besteht aus Klassen mit Attributen und Referenzen auf andere Klassen. Attribute und Referenzen können geordnet sein, die Reihenfolge ihrer Elemente kann signifikant sein oder nicht (Listensemantik). Damit ergeben sich folgende Abbildungen von Modellelementen auf Graphstrukturen: • Klassen/Instanzobjekte → Knoten • Attributwerte → Eigenschaften von Knoten • Referenzen → gerichtete Kanten 105 • Geordnete Attribute → verkettete Liste von Knoten, die jeweils einen Attributwert enthalten und auf ihren Nachfolger verweisen 3.4 Komplettkopie Die einfachste Variante der Versionierung ist die Speicherung vollständiger Modellversionen. Dazu werden in jeder Revision die aktuell gültige Version eines Modells mit Hilfe der Abbildungsvorschriften aus Abschnitt 4.3 graph-basiert gespeichert. Vorteilhaft ist dabei, dass die Wiederherstellung der einzelnen Modellversionen unproblematisch ist: jede Revision referenziert vollständige persistierte Modelle. Eine Rekonstruktion ist nicht notwendig. Abbildung 2: Speicherung kompletter Modelle Diese Vorgehensweise weist jedoch zwei gravierende Nachteile auf: Der Speicherverbrauch ist hoch. Selbst bei geringen Unterschieden zwischen zwei Revisionen müssen die Modelle komplett gespeichert werden. Außerdem ist es nur aufwendig möglich, diese Unterschiede zu rekonstruieren. Im Allgemeinen ist dazu ein externes dediziertes Werkzeug notwendig. 3.5 Mengenwertige Deltas Um die Nachteile einer Komplettspeicherung von Modellen pro Revisionen auszugleichen, gibt es die Möglichkeit, dediziert die Menge der Unterschiede pro Modell zwischen zwei Revisionen zu speichern. Der notwendige Speicherplatz pro Revision ist dann nur noch proportional zum Umfang der Änderungen und nicht zur Modellgröße. Auch lassen sich so die eigentlichen Änderungen problemlos ermitteln, etwa zwischen Revisionen, die zeitlich aufeinander folgen, jedoch nicht unmittelbar. Dazu muss nur eine Vereinigung der beiden Änderungsmengen berechnet werden, wobei eventuell auftretende Konflikte zu berücksichtigen sind (etwa das Löschen eines zuvor geänderten Elementes). 106 Nachteil dieser Speicherungsart ist jedoch der Aufwand, der notwendig ist, um ein Modell aus einer Revision zu rekonstruieren. Dazu sind, ausgehend von der initialen Komplettspeicherung des Modells, die jeweiligen Änderungen in allen Vorgängerrevisionen auf dieses Modell anzuwenden. Der Aufwand ist dabei proportional zur Länge der Historie und zum Umfang der Modelländerungen. Wünschenswert ist also eine Kombination der beiden Speicherungsarten: Die unmittelbare Sicht auf vollständige Modellversionen pro Revisionen bei gleichzeitiger Speicherung von Änderungen pro Revision. Notwendig ist hierfür eine Datenstruktur, die die Wiederverwendung von Strukturen erlaubt, um Speicherplatz zu sparen, dabei jedoch eine Sicht auf ein komplettes Modell erlaubt. Datenstrukturen mit dieser Eigenschaft heißen „persistent“ und werden ausführlich in [Oka03] beschrieben. Die Abbildung 3 zeigt auf der rechten Seite beispielhaft zwei Modellversionen. In Version 2 wurde das Modellelement obj2 mitsamt allen beteiligten Referenzen entfernt. Um dies zu erreichen, muss die den Modellen inhärente Graph-Struktur in einen DAG umgewandelt werden. original graph v1 obj2 in obj1 out in v2 package changed graph package package subpackage subpackage out in in out subpackage obj1 obj2 obj1 out Nested structures Abbildung 3: Speicherung von geänderten Modellelementen Die Umwandlung in einen DAG erfolgt durch die Auflösung von möglichen Schleifen, indem Referenzen zwischen Knoten nicht mehr als Kante gespeichert werden, sondern als eigenständige Knoten mit min. zwei eingehenden Kanten, die typisiert sind mit einem der beiden Typen „in“ oder „out“. Um nun ein Modell in einer Revision zu rekonstruieren, müssen alle vom Revisionsknoten aus erreichbaren Knoten und Kanten des Graphen traversiert und markiert werden. Dabei werden nur die Referenzknoten berücksichtigt, die über genau zwei Kanten erreichbar sind („in“ und „out“). Zur Verdeutlichung soll hier Abbildung 4 dienen: Ausgehend von Revision v2 sind drei Objektknoten und vier Referenzknoten erreichbar. Dabei sind jedoch nur bei zwei dieser Referenzknoten sowohl „in“ als auch „out“-Kanten markiert. Damit ergibt sich ein Modell mit drei Objekten, die linear zusammenhängen (siehe Abbildung 3 rechts). 107 original graph v1 obj2 in obj1 out in v2 package changed graph package package subpackage subpackage out in in out subpackage obj1 obj2 obj1 out Nested structures Abbildung 4: Rekonstruktion einer Modellversion Analog dazu lässt sich Version v1 als geändertes Modell interpretieren, bei welchem ein Objekt (ob j2 ) und zwei Referenzen (ob j1 ↔ ob j2 ) hinzugefügt wurden. Die Rekonstruktion erfolgt analog zu dem im obigen Absatz spezifizierten Algorithmus. 3.6 Speicherung von vorwärtsgerichteten operationalen Deltas Die in Abschnitt 4.5 beschriebene Speicherung von Modellversionen in Form von Modelländerungen erlaubt zwar eine schnelle Rekonstruktion von Modellen, jedoch ist die Analyse der Art der Änderungen aufwendig. Um Herauszufinden, welche Elemente gelöscht oder hinzugefügt wurden (Änderungen lassen sich prinzipiell als Kombination von Löschen und Hinzufügen darstellen), müssen beide Modellversionen betrachtet werden. Ein alternativer Ansatz ist hier die explizite Speicherung von Änderungsoperationen, die notwendig sind, um eine Modellversion in eine Nachfolgerversion zu überführen. Dies wird demonstriert in Abbildung 5. Voraussetzung hierfür ist eine Editorunterstützung, die Änderungsoperationen bei der Editierung eines Modells aufzeichnet bzw. einer robusten Erkennung von Modelländerungen und einer Überführung dieser Änderungen in äquivalente Änderungsoperationen. Pro Revision gibt es zwei Mengen von Änderungen: Neu hinzugefügte und gelöschte Modellelemente ([Ohs04]). Zur Wiederherstellung eines Modells zum Zeitpunkt einer Revision ist eine Rekonstruktion aller Änderungsoperationen seit dem initial komplett gespeicherten Modell notwendig. Im obigen Beispiel wird demnach ausgehend von der Zielrevision, die wiederhergestellt werden soll die Vorgängerrevision ermittelt, in der das Modell vollständig vorlag. Von dieser Version ausgehend werden nun für alle Nachfolgerrevisionen die gespeicherten Änderungsoperationen auf diesem Modell ausgeführt. Das Endresultat stellt dann die gesuchte Modellversion dar. 108 v3 msg v2 removed ref1 add msg del v1 changed obj2 add msg del obj2’ add obj2 in in initial checkin del obj1 out Versions refer to former version contents+deletions+additions Abbildung 5: Speicherung von Änderungsoperationen (vorwärts) Vorteil der Speicherung von vorwärtsgerichteten operationalen Deltas ist der direkte Zugriff auf die Unterschiede zwischen zwei Modellversionen zusammen mit der Information, welcher Art diese Unterschiede sind. Nachteil ist die aufwendige Rekonstruktion des Modellinhaltes. In einem VCS wird die jeweils aktuellste Revision am häufigsten ausgelesen. Wegen des so sehr häufig anfallenden Aufwandes eignet sich diese Speicherungsart also im Allgemeinen nicht für einen Einsatz in einem VCS. 3.7 Speicherung von rückwärts gerichteten operationalen Deltas Alternativ zur Abschnitt 4.6 ist auch eine Speicherung von Operationen denkbar, die ausgehend von der aktuellsten Modellversion die Vorgängerversionen wiederherstellt. Dazu müssen die tatsächlichen, in der korrekten chronologischen Reihenfolge durchgeführten Änderungsoperationen entsprechend umgeschrieben werden. Voraussetzung hierfür ist, dass alle Operationen symmetrisch und bijektiv und daher umkehrbar sind. v5 msg v4 del obj2,del ref del msg add del obj1 in v3 added obj3+ref msg del add obj3 out v2 changed obj2’ msg add del obj2 out in v1 added ref msg add initial checkin del add obj2’ in Abbildung 6: Speicherung von Änderungsoperationen (rückwärts) 109 Jede Version enthält damit die operationalen Änderungen, die notwendig sind, um die Modellversion aus der Nachfolgerversion zu rekonstruieren. Die gespeicherten Operationen sind also das Gegenteil der tatsächlich erfolgten Änderungen des Benutzers. Der Aufwand für die Rekonstruktion von Modellversionen entspricht dem Aufwand für die Speicherung von vorwärts gerichteten operativen Deltas, jedoch wächst der Aufwand mit dem Alter der Version. Die jeweils aktuellste Version eines Entwicklungszweiges lässt sich nach dem in Kapitel 4.4 beschriebenen Algorithmus direkt auslesen. Die Vorgängerversionen müssen iterativ anhand der gespeicherten Änderungsoperationen rekonstruiert werden. Problematisch ist bei dieser Vorgehensweise jedoch, dass gespeicherte Graphstrukturen bei einer neuen Revision im Gegensatz zu Kapitel 4.6 verändert werden müssen. Ein Einsatz dieser Speicherungsart in dezentralen Repositories kommt daher nicht in Betracht. 3.8 Optimierung Der Aufwand für die Rekonstruktion von Modellversionen bei Einsatz einer der Methoden aus Kapitel 4.6 oder 4.7 steigt linear mit der Länge der Historie. Dieser Aufwand lässt sich begrenzen, indem an geeigneten Stellen in der Historie jeweils Komplettkopien der Modelle zum entsprechenden Zeitpunkt gespeichert werden. Zeitlich bieten sich hier Revisionen an, zu denen Entwicklungszweige erstellt werden bzw. wieder zusammengeführt werden. Der Speicherverbrauch erhöht sich dadurch proportional zur Modellgröße. Der Performanzgewinn ist deshalb gegen diesen Mehrbedarf an Speicherplatz abzuwägen. 4 Zusammenfassung und Bewertung Die Anforderung, Modelle kollaborativ und konkurrierend bearbeiten und versionieren zu können ist mit herkömmlichen VCS nicht zufriedenstellend möglich. Die Graphenstruktur von Modellen und Modellbeziehungen untereinander lässt sich nur umständlich auf hierarchische oder flache Speicherstrukturen abbilden. Die Verwendung einer graph-basierten Nosql-Datenbank bietet hier ein Werkzeug, um die Anforderungen an Modellversionierung aus Kapitel 2 optimal umzusetzen. Dieser Beitrag beschreibt dafür Abbildungsstrukturen für Modelle, Referenzen zwischen Modellelementen, Änderungen von Modellen und Versionierungsmetadaten auf Graphen. Diese graph-basierten Speicherungsformate erlauben eine direkte Navigation auf Modellstrukturen und ermöglichen damit weitergehende Mehrwertfunktionen. Hier sei etwa auf Anfragesprachen wie OQL [Cat00] verwiesen oder auch Indexierungswerkzeuge wie EMF Index2 die direkt auf Graphdatenbanken operieren könnten. Durch diesen reduzierten „impedance mismatch“ [IBNW09] ergeben sich eine Vielzahl von Anwendungsmöglichkeiten bei deutlich reduziertem technischem Aufwand. 2 110 http://www.eclipse.org/emfindex/ Literatur [Cat00] Cattell, Roderic Geoffrey Galton: The object data standard: ODMG 3.0. San Francisco : Morgan Kaufmann, 2000 (The Morgan Kaufman series in data management systems). – ISBN 978–1558606470 [Her10] Herrmannsdoerfer, Markus: COPE - A Workbench for the Coupled Evolution of Metamodels and Models. In: Proceedings of the 3rd International Conference on Software Language Engineering (SLE), 2010, S. 286–295 [IBNW09] Ireland, Christopher ; Bowers, David ; Newton, Mike ; Waugh, Kevin: A classification of object-relational impedance mismatch. In: First International Conference on Advances in Databases, Knowledge, and Data Applications (DBKDA), 2009 [Int05] International Organization for Standardization (ISO): ISO/IEC 19502:2005 / International Organization for Standardization (ISO). 2005. – Forschungsbericht [Ohs04] Ohst, Dirk: Versionierungskonzepte mit Unterstützung für Differenz- und Mischwerkzeuge. Siegen, Univ., Diss., 2004 [Oka03] Okasaki, Chris: Purely functional data structures. 1. paperback ed., transf. to digital printing. Cambridge : Cambridge Univ. Press, 2003. – ISBN 978–0521663502 [Sta73] Stachowiak, Herbert: Allgemeine Modelltheorie. Wien [u.a.] : Springer, 1973. – XV, 494 S. : graph. Darst. https://aleph.ub.uni-kl.de/F/?func=full-set-set&set_number= 002380&set_entry=000012&format=999. – ISBN 3–211–81106–0 111 112 MTF - Modeling Team Framework zur effizienten Unterstützung modellgetriebener Softwareentwicklungsprozesse Steffen Dienst1 , Steffen Stundzig2 1 Institut für Angewandte Informatik e.V. an der Universität Leipzig Johannisgasse 26 04103 Leipzig dienst@infai.org 2 itemis AG Ludwig-Erhardt-Str. 51 04103 Leipzig steffen.stundzig@itemis.com Kurzfassung: Modellgetriebene Softwareentwicklung verspricht die Erstellung qualitativ hochwertiger Software mit geringer Fehlerdichte und preiswerter Erweiterbarkeit bei neuen Anforderungen bei gleichzeitig geringerer Komplexität und niedrigeren Kosten, als bei herkömmlichen Methoden. Dafür ist jedoch der konzertierte Einsatz einer Vielzahl von Werkzeugen in verteilten Entwicklungsteams unabdingbar. Speziell die konsistente Versionierung aller anfallenden Artefakte wie Modelle, Code, Konfigurationsdaten und besonders Werkzeugversionen ist ein nach aktuellem Stand der Entwicklung aufwendiger, vorwiegend manueller Prozessschritt. Auch die Sicherstellung der Integrität dieser Artefakte und insbesondere ihrer Beziehungen und Abhängigkeiten erfolgt nur unzureichend automatisiert. MTF bietet hier eine automatisierte Unterstützung, die es erlaubt, alle im Rahmen von MDSD anfallenden Artefakte zentral zu versionieren. Die Speicherung erfolgt hierbei in dedizierten, für die Artefakttypen geeigneten Repositories. Zusammen mit einer Aufbereitung der Abhängigkeiten und Beziehungen zwischen den versionierten Artefakten, etwa zur Analyse von Fehlerursachen oder zur Konsistenzprüfung, sowie einer Unterstützung für die automatisierte Aktualisierung von Werkzeugkonfigurationen bei den beteiligten Entwicklern bietet MTF einen wichtigen bisher fehlenden Open-Source-Baustein im Werkzeugmarkt. MTF reduziert damit die technische Komplexität von MDSD und erschließt diese Vorgehensweise größeren Kundenkreisen. 1 Thema und Zielsetzung des Vorhabens 1.1 „Model Driven Software Development“ – Nutzen und Chance Die Entwicklung von Software geschieht in einem Spannungsfeld aus der Forderung nach qualitativ hochwertigen Lösungen bei möglichst niedrigen Kosten. Zusammen mit Problemen wie zunehmender technischer Komplexität, schnell wechselnden Technologien und dem Druck, sich 113 kontinuierlich ändernden Anforderungen gerecht zu werden, stellt sich nach wie vor die Frage, wie diesen Herausforderungen begegnet werden kann. Die Entwicklung des Softwareengineerings zeigt einen stetigen Trend zur Abstraktionserhöhung. Angefangen von hardwarenahen Programmiersprachen über höherwertige Sprachen, Ansätze wie strukturierte und objektorientierte Programmierung ist der Wunsch erkennbar, die Trennung von inhärenter Domänenkomplexität („essential complexity“) von Komplexität, die durch Programmiersprachen und Werkzeuge verursacht werden („accidental complexity“ [Bro86]) zu trennen. Modelle repräsentieren das eigentliche, für den Endkunden relevante, Domänenwissen ohne dass technische Implementierungsdetails dem Verständnis im Wege stehen. Speziell durch die Verwendung von domänenspezifischen Sprachen lassen sich Anforderungen elegant erfassen und mit Hilfe von technologiespezifischen Transformationen direkter in technische Lösungen überführen, als durch klassische manuelle Softwareentwicklungsverfahren. Die Verwendung von Generatoren für die schrittweise automatische Überführung von Modellen in ausführbare Software führt zusammen mit der automatischen Validierbarkeit von Modellen [BLW05] zu einer geringeren Fehlerhäufigkeit und damit zu reduzierten Entwicklungs- und Wartungskosten sowie einer geringeren „Time to market“ [KDZ10]. Weitere Vorteile sind die Reduktion von Wartungsaufwänden für Dokumentationen, da Modelle als kanonische Beschreibung dienen und immer mit den daraus generierten Produkten übereinstimmen. MDSD erlaubt einfachere Anpassung der Software bei Änderungen an den Anforderungen und nicht zuletzt eine höhere Technologieunabhängigkeit durch austauschbare Templates. Die Einführung eines modellgetriebenen Ansatzes ist im Allgemeinen mit einem hohen Aufwand verbunden. Schulungsaufwand für die einzusetzenden Werkzeuge ist nötig, die prototypische manuelle Erstellung von Anwendungen als Grundlage für die Ableitung von Templates, das Aufsetzen und die Konfiguration von Transformationsketten, Definition von Modelltransformationen und die parallele Entwicklung von eigenen, domänenspezifischen Werkzeugen wie etwa Editoren für DSLs. Ein prototypischer Prozess für MDSD wird in Abbildung 1 dargestellt. Domain Engineering Metamodelle definieren DSLs definieren Editoren generieren Templates erstellen Application Engineering Modelle definieren Quellcode generieren Anwendung ausliefern Quellcode anpassen Editoren anpassen Legende: Metamodelle Domain Specific Languages Anwendungen Templates Modelle Quellcode Buildskripte Werkzeuge Abbildung 1: Prototypischer MDSD-Prozess Ein großer Teil nichtdomänenspezifischer Komplexität von Softwareengineering wird durch modellgetriebene Ansätze in Werkzeuge auslagert. Diese Verlagerung bedeutet jedoch nicht notwendigerweise auch eine Reduktion der Komplexität selbst. Dies führt zu praktischen Fragestellungen wie: Wie verwaltet und versioniert man etwa die Konfigurationen von Werkzeugen, die konzer- 114 tiert eingesetzt werden müssen? Oder: Wie findet man die Fehlerursache in Modellen, wenn der Fehler selbst erst zur Laufzeit der resultierenden Software auftritt? 1.2 Unzureichende Werkzeugunterstützung Trotz der umfangreichen Auswahl an Technologien und Werkzeugen für Kernaufgaben von MDSD wie etwa Modellierung und Generierung sind essentielle Prozessbestandteile noch unzureichend maschinell unterstützt. Die eindeutige semantische Versionierung anfallender Artefakte etwa erfolgt manuell in einzelnen dedizierten Repositories (siehe Beispiele in Abbildung 2). Da eine Vielzahl heterogener Artefakte entstehen und versioniert werden müssen, die zudem nicht zwingend in nur einem Repository verwaltet werden, ergibt sich zusätzlicher Aufwand durch die Notwendigkeit der manuellen Synchronisation von Versionsnamen, Entwicklungszweigen, Konfigurationen, Rollen und Rechten, Hooks etc. zwischen den einzelnen verwendeten Repositorien. Ebenso wird die verzweigte Entwicklung, etwa für unterschiedliche Lebenszyklusphasen der Produkte oder verschiedene Kunden erschwert. Es kann leicht geschehen, dass Änderungen an einem Modell zu Inkonsistenzen etwa in darauf aufbauenden Editoren oder Templates führen, die erst zu einem wesentlich späteren Zeitpunkt erkannt werden können und damit im Allgemeinen nur mit höheren Kosten auflösbar sind. Wenn nun ein Fehler in einem finalen Softwareartefakt festgestellt wurde, stellt sich die Frage nach der Lokalisation der Ursache desselben. Mit Hilfe klassischer Debuggingverfahren lässt sich feststellen, an welcher Stelle des zugrundeliegenden Quellcodes der Fehler liegt. Da dieser Code selbst jedoch generiert wurde, müssen rekursiv alle Generierungsketten manuell nachverfolgt werden, um herauszufinden, in welchem Template bzw. welcher Transformation der eigentliche Fehler liegt. Diese Rückrichtung ist im Allgemeinen nur sehr aufwändig rekonstruierbar, die Fehlersuche selbst ist damit deutlich teurer als bei manuell geschriebenem Quellcode. Speziell für Software, die als Produktlinie entwickelt wird, kann sich diese fehlende Traceability negativ auswirken, etwa wenn es darum geht, nach einem Fehler, der bei einem speziellen Produkt bei einem Endkunden entdeckt wurde zu entscheiden, welche weiteren Produkte und Kunden davon ebenfalls betroffen sein könnten. Wie in [GF94] beschrieben ist an dieser Stelle eine Unterstützung von „Post-requirements specification traceability“ wünschenswert, also einer Möglichkeit, Anforderungen durch alle technischen Artefakte hindurch nachverfolgen zu können. Aufgrund der Vielzahl von Werkzeugen am Markt und der häufig unzureichenden Interoperabilität derselben ist keine durchgängige Unterstützung für die automatische Pflege von Beziehungen bzw. von Abhängigkeiten zwischen den entstehenden Artefakten verfügbar. MDSD und Softwareproduktlinien sind zwei Paradigmen, die speziell bei IT-Dienstleistern mit einer großen Anzahl von Kunden häufig gemeinsam verwendet werden. Dabei werden ausgehend von einer gemeinsamen Grundplattform kundenspezifische Anforderungen modelliert und in eigenständigen Entwicklungszweigen angepasste Produkte generiert. Neben der fehlenden Unterstützung von Traces ergeben sich in diesem Kontext weitere Probleme: Die unterschiedlichen Entwicklungszweige pro Kunde werden zu unterschiedlichen Zeitpunkten angelegt. Damit ergibt sich eine im Laufe der Zeit verschärfende Divergenz zwischen den verschiedenen Versionen und 115 Werkzeugketten zwischen der Hauptentwicklung und dem kundenspezifischen Zweig. Treten Fehler auf oder wünscht ein Kunde zu einem späteren Zeitpunkt eine Änderung, ist es aufgrund der Werkzeugabhängigkeit von modellgetriebenen Entwicklungsansätzen notwendig, die entsprechenden Arbeitsumgebungen wiederherzustellen. Dafür ist es notwendig, komplette Werkzeugketten zu pflegen und zu versionieren [HK10]. 1.3 Eclipse Modeling Project Das Eclipse Modeling Project1 (EMP) bietet eine Alternative aus dem Open-Source-Bereich zu proprietären Werkzeugketten. Dieses Umbrella-Projekt umfasst eine Vielzahl von robusten Werkzeugen zur Unterstützung von MDSD, angefangen von verschiedenen graphischen und textuellen Modellierungswerkzeugen, Query- und Transformationssprachen, Validatoren bis hin zu einer Reihe von Persistierungs- und Versionierungswerkzeugen. Alle Unterprojekte basieren auf einem gemeinsamen Meta-modell, EMF [SBPM09], einem Modellierungsstandard ähnlich dem MOF 2.02 der OMG. Mit diesem gemeinsamen Datenformat zur Verarbeitung und Austausch von Modellen ist eine wesentliche Voraussetzung für Interoperabilität vorhanden. 2 Überblick zum Markt für MDSD-Werkzeuge Trotz der Vielzahl von Einzelprojekten im Eclipse Modeling Project ist aufgrund der Open-SourceNatur desselben und der damit verbundenen informellen Projektverwaltung die Interoperabilität unzureichend. Aus diesem Grund wurde Anfang 2010 die „Industry Working Group Eclipse Modeling Platform“ ins Leben gerufen, einem Zusammenschluss von namhaften Anwendern und Werkzeugentwicklern, die sich in der Eclipse-Plattform engagieren. In diesem Rahmen wurde eine Gap-Analyse durchgeführt [EMM+ 10], deren Ziel eine Darstellung der frei verfügbaren Modellierungswerkzeuge des EMP sowie der noch fehlenden Teile sein sollte. Neben dem wichtigsten Punkt der flexiblen Unterstützung für eine Vielzahl von Modellierungskonventionen und -formaten (wie etwa UML, BPMN oder SysML) wurde als größte Lücke das Versionsmanagement von modellgetriebenen Artefakten sowie die fehlende Traceability dazwischen identifiziert. Diese Beobachtung deckt sich mit unabhängigen Beobachtungen aus der Industrie, wie etwa bei Motorola [BLW05]. Versionierung ist ein zentrales Anliegen von Softwareengineering. Es existieren dedizierte Implementierungen für die unterschiedlichen Artefakttypen: Texte, wie etwa Dokumentationen und Quellcode werden durch klassische VCS wie CVS, SVN, GIT, Mercurial etc. verwaltet. Sie unterscheiden sich im Wesentlichen durch ihre Lokalisation (zentral oder verteilt) und ihre unterschiedliche Unterstützung für verzweigte Entwicklungsprozesse. Modelle lassen sich mit diesen VCS nur unzureichend verwalten. Dedizierte Repositories wie etwa AMOR, CDO oder EMFStore für EMF bzw. herstellerspezifische wie ARIS3 sind hier besser geeignet, da sie nicht auf einer textuellen Repräsentation agieren sondern auf der Struktur der Modelle. Alle Repositories unterscheiden 1 2 3 116 http://www.Eclipse.org/modeling/ http://www.omg.org/spec/MOF/2.0/HTML/ http://www.softwareag.com/corporate/products/aris_platform/default.asp sich in den zugrundeliegenden Anforderungen, angebotenen Lösungen und Art der Benutzung. Eine integrierte Verwendung, etwa für MDSD, ist nicht vorgesehen und manuell umzusetzen. Es fehlt an koordinierenden Werkzeugen, die die Integrität von Beziehungen zwischen den einzelnen Artefakten sicherstellen, welche in verschiedenen Repositories verwaltet werden. Weiterhin wird die Problematik des Aufwandes der Pflege von kompletten Arbeitsumgebungen etwa für verschiedene Kunden, die Produkte in verschiedenen Versionsständen nutzen, in der Literatur nicht betrachtet. Es gibt nach unserem Erkenntnisstand keine frei verfügbare Lösung, die Unterstützung hierfür bietet. Damit liegt ein erhebliches Kostenoptimierungspotenzial brach. Existierende Standards für Versionierung von Artefakten wie etwa JSR-1474 operieren auf Dateien und sind nicht geeignet für den Einsatz zur Versionierung von Artefakten, die sich nur aufwendig auf Dateien abbilden lassen, wie etwa verknüpfte Modelle. Die Automatisierung von Buildprozessen, also die Transformation von Quellcode in ausführbare und auslieferbare Artefakte sowie das Anstoßen von Tests und Deployment wird in Form von „continuous integration“-Werkzeugen unterstützt. Dazu zählen etwa Open-Source wie Jenkins5 oder CruiseControl6 und kommerzielle Implementierungen, z. B. TeamCity7 . Da diese Werkzeuge beliebige Skripte ausführen, ist ein Einsatz in modellgetriebenen Kontexten möglich, jedoch ist eine durchgängige Unterstützung, wie etwa semantisch relevantes Feedback bei Fehlern im Build und entsprechendes Zurückspielen z. B. in Entwickler-IDEs nur mit hohem Aufwand realisierbar. Das Projekt Flowr8 beinhaltet eine prototypische Implementierung eines Metarepositories. Dabei werden Quellcodeartefakte in ein SVN gespeichert und Modelle in eine Datenbank. Es werden jedoch keine homogene Versionierung und Verzweigung unterstützt, weitere Artefakttypen sind nicht vorgesehen. Die in MTF angestrebte Versionierung von z. B. generierten Editoren parallel zu anderen Artefakten ist nicht möglich. Es zeigt allerdings deutlich den Bedarf für diese Art von zentraler Verwaltung. Es existieren verschiedene Ansätze zur Realisierung von Traceability. Traditionell geht es dabei um die Rückverfolgbarkeit von Kundenanforderungen (pre-RS aus [GF94]). Aber auch die Generierung von Traces zwischen verschiedenen Artefakten der MDSD wird in der Literatur betrachtet, wie etwa in [GK10]. Allen Ansätzen ist jedoch gemein, dass Traces jeweils paarweise für Artefakttypen implementiert werden, z. B. für die Generierung von Java-Quellcode aus UML2-Modellen eines bestimmten Herstellers mit Hilfe einer proprietären Transformationssprache. Meist müssen deshalb dedizierte Lösungen für einen Anwender erst individuell implementiert werden [WP10]. Insgesamt sind speziell im Technikraum EMF keine robusten industriell nutzbaren Implementierungen verfügbar. Der in diesem Projekt angestrebte Ansatz soll hier durch seine Umsetzung in einem homogenen Technikraum Abhilfe schaffen. Der in MTF verfolgte Ansatz, Traceability fest im Softwareentwicklungsprozess zu verankern, indem es ohne kontinuierliche manuelle Intervention an einer zentralen Stelle umgesetzt wird, wird in der Literatur als anzustrebende Lösung beschrieben [WP10]. 4 5 6 7 8 http://jcp.org/en/jsr/detail?id=147 http://jenkins-ci.org/ http://cruisecontrol.sourceforge.net/ http://www.jetbrains.com/teamcity/ http://flowr.org/ 117 3 MTF In MTF ist ein Werkzeug für die integrierte Versionierung und Verwaltung von Modellen, EclipseWerkzeugen und modellgetriebenen Artefakten, wie Templates, Transformationen, manuellem Code sowie der intrinsischen Beziehungen. Das Ziel ist dabei eine Reduktion der nicht domänenspezifischen Komplexität von MDSD-Prozessen durch ein zentrales, delegierendes Meta-Repository, welches kollaborative und verteilte modellgetriebene Softwarenentwicklungsprozesse vereinfacht, indem große Teile der technischen Komplexität durch einen integrierten Server gekapselt werden. Eine schematische Darstellung des angestrebten Funktionsumfangs zeigt Abbildung 2. Modeling Metarepository Team Framework Abbildung 2: Schematische Darstellung von MTF Die einzelnen Artefakte werden zur Speicherung an dedizierte, für den Artefakttyp spezialisierte Repositories delegiert. Im Einzelnen sind hier traditionelle textorientierte Versionsverwaltungssysteme wie „SVN“ [PCSF09] oder „GIT“ [Loe09] für manuellen Quellcode oder Konfigurationsdaten geplant, für Modelle und DSLs ein Modellrepository wie „EMFStore“9 oder „CDO“10 , für generierte Artefakte Backupsysteme für Binärdaten (z. B. „bup“11 ), für verwendete Werkzeug9 10 11 118 http://emfstore.org http://www.Eclipse.org/cdo/ https://github.com/apenwarr/bup versionen Updatesites, etwa „P2“12 für Eclipse. Das Metarepository MTF ermöglicht die einheitliche Vergabe von Versionsnummern und -kennzeichnungen (Tags), Rechten und Rollen, ohne die Notwendigkeit der manuellen Synchronisation zwischen den verschiedenen beteiligten konkreten Repositories. Aufbauend auf dieser integrierten Gesamtsicht auf alle Artefakte wird eine flexible semiautomatisierte Erkennung von Abhängigkeiten zwischen modellgetriebenen Artefakten implementiert. Aufgrund der allen Teilprojekten des EMP gemeinsamen Technikbasis EMF kann an dieser Stelle auf eine Reihe von Trace-Beschreibungssprachen aus der Literatur zurückgegriffen werden. Diese extrahierten Traces erlauben die Nachvollziehbarkeit der Auswirkungen von Änderungen etwa an Modellen auf andere abhängige Artefakte und damit die automatisierte Validierung von Transformationsketten. In einem zweistufigen Check-In-Verfahren können Fehler, die entlang der Transformationskette auftreten so ursächlich einer Änderung zugeordnet werden und damit sichergestellt werden, dass die Konsistenz der modellierten Informationen konsistent bleibt. Das Repository wird aufgrund von konfigurierbaren Erweiterungspunkten weiterhin in der Lage sein, nachfolgende Teilprozesse der modellgetriebener Softwareentwicklung anzustoßen. Dazu gehören automatische Validierungen (etwa von Konformitätsbeziehungen oder syntaktische Korrektheit von Templates nach Modelländerungen), Unterstützung von Reviews durch Einbindung entsprechender Werkzeuge, Protokollierung der Urheberschaft von Änderungen für Auditingzwecke und das Anstoßen von Generierungsworkflows. MTF wird weiterhin die Möglichkeit bieten, Werkzeugkonfigurationen (auf Eclipse-Basis) zu versionieren. Zusammen mit einer geeigneten Hook-Implementierung zur automatischen Aktualisierung der Werkzeuginstallationen bei den Entwicklern lassen sich so verteilte Entwicklungsprozesse effektiver und robuster entwickeln, als bei herkömmlichen Herangehensweisen, die diesen Aspekt manuell behandeln. 3.1 Nutzen Es soll ein Open-Source-Werkzeug auf Basis von Eclipse geschaffen werden, welches die bestehende Werkzeuglandschaft des Eclipse Modeling Projects effektiv kombiniert und deren Zusammenspiel verbessert und vereinfacht. Damit wird die Einstiegshürde für die Umstellung von Softwareentwicklungsprozessen von manuellen hin zu effizienten modellgetriebenen Ansätzen reduziert. Durch die geringere Einstiegshürde werden auch mittelständische Unternehmen in die Lage versetzt, kosteneffizient den Automatisierungsgrad ihrer Softwareentwicklungsprozesse zu erhöhen. Aktuell verwendete, in industriellen Kontexten erprobte Werkzeuge für Versionierung und Buildautomation können nahtlos integriert und durch Anreicherung um Abhängigkeitsinformationen sowie konsolidierte Sichten auf diese optimal genutzt werden. MTF liefert einen wichtigen Baustein, um einen zentralen Vorteil von MDSD für Kunden zu manifestieren: Reduktion von technischer Komplexität durch ein integriertes Werkzeug. Dieses senkt sowohl die Kosten für die Einführung von MDSD als auch für den laufenden Betrieb des Prozesses. 12 http://wiki.Eclipse.org/Equinox/p2 119 4 Marktpotenzial für MTF Ein wesentliches Problem für den Erfolg von MDSD entsteht aus der fehlenden Interoperabilität von Werkzeugen verschiedener Hersteller [KDZ10]. Trotz teilweise vorhandener Standards für den Austausch von Modellen, etwa auf Basis von MOF13 , ergibt sich in der Praxis regelmäßig die Notwendigkeit, Werkzeuge genau eines Herstellers zu verwenden, um einen durchgehenden Prozess aufsetzen zu können. Durch diese Investition in einen einzigen Hersteller ergibt sich jedoch auch eine Abhängigkeit von demselben, dessen Supportangeboten, dessen Angeboten zur individuellen Anpassung seiner Software und nicht zuletzt auch von dessen Präsenz am Markt in der Zukunft. Um diese Abhängigkeiten zu reduzieren bietet sich der Einsatz von Open-SourceProdukten an, da meist ein komplettes Ökosystem von Dienstleistern existiert und damit keine Abhängigkeit vom wirtschaftlichen Fortbestand eines einzelnen Herstellers eingegangen werden muss. Selbst unter günstigen Umständen, d. h. bei MDSD-erfahrenen Entwicklungsteams, treten immer wieder Fehler auf, die auf unzureichende Werkzeugunterstützung zurückzuführen sind. Ein Beispielszenario: Bei einer verzweigten Entwicklung besteht im Allgemeinen die Notwendigkeit, pro Entwicklungszweig angepasste Editoren zu verwenden, da die zugrundeliegenden Metamodelle oft divergieren. Allein die derzeit fehlende Werkzeugunterstützung zur Sicherstellung, dass jeder Mitarbeiter die korrekte Editorenversion verwendet, führt zu etwa einer Stunde Produktivitätsverlust alle zwei Wochen. Bei einer angenommenen Teamgröße von 40 Entwicklern in einem KMU und einem Tagessatz von 500 e pro Entwickler entsteht so ein Verlust von 60.000 e pro Jahr. Diese Zahl ist eine konservative Schätzung, die bei unerfahrenen Teams deutlich höher liegen kann. Das Einsparungspotential, das durch die von MTF gebotene Komplexitätsreduktion realisiert werden kann, wird sich in einer niedrigeren Einstiegshürde für Kunden auswirken und damit MDSD erweiterten und auch völlig neuen Kundenkreisen zugänglich machen. In Gesprächen mit Kunden, die mit dem Wunsch nach Einführung von MDSD an die itemis AG herantreten, werden häufig Sorgen über die Komplexität des Managements der beteiligten Werkzeugketten als hauptsächlicher Hindernisgrund für die Nichteinführung genannt. Diese Kundenschicht ließe sich mit MTF zusätzlich erschließen. Die Verwendung von MTF für die Kapselung und damit die Reduktion der Komplexität der Verwaltung und Versionierung von MDSD-Werkzeugen und -artefakten wird zu geringeren Einstiegskosten führen. Damit werden auch kleinere mittelständische Unternehmen in die Lage versetzt, ihre internen Entwicklungsprozesse kosteneffizient auf modellgetriebene Vorgehensweisen umzustellen. Dies erschließt MDSD einem vergrößerten Anwenderkreis. 5 Aktueller Stand 5.1 Forschungsprojekt AMOR Im vorgelagerten, vom BMBF geförderten Forschungsprojekt AMOR wurde wesentliche wissenschaftliche und technische Vorarbeiten für die Entwicklung von MTF gelegt. Dabei wurden die 13 120 http://www.omg.org/spec/MOF/2.0/ angrenzenden Technologien und Konzepte zu Traceability und performanter Speicherung untersucht. Ebenfalls wurde im Rahmen der Open-Source-Werkzeugplattform Eclipse untersucht, welche vorhandenen bestehenden Modellierungs- und Programmierwerkzeuge zu integrieren sind. Fokus lag dabei auf der technischen Basis für den Datenaustausch zwischen den Werkzeugen. Das Eclipse Modeling Framework EMF, dass bereits weltweit verbreitet und in verschiedenen Projekten im Einsatz ist, hat sich als sehr vorteilhaft herausgestellt. Abbildung 3: Logo Eclipse modeling PROJECT 5.2 Eclipse Projekt MTF Im Rahmen der Arbeiten zum Forschungsprojekte wurde ebenfalls versucht ein möglichst breite Community zu finden, die Interesse daran hat, MTF zu nutzen oder gar mit zu entwickeln. Dazu wurde ein Proposal innerhalb der Eclipse Foundation eingereicht, um ein neues Projekt zu initiieren. Ein solches Projekt erreicht ein sehr große Sichtbarkeit innerhalb der ständig wachsenden Eclipse Community. Die Initiierung eines solchen Projektes durchläuft auch einen stark qualitätsgetriebenen Prozess. Dieser läuft wie im Folgenden beschrieben ab. 5.2.1 Ideenfindung Der erste Schritt ist natürlich die Entwicklung der Projektidee selbst. Diese war sehr leicht zu finden, da aus den Vorarbeiten bereits bekannt war, was das Ziel von MTF ist. Das Proposal selbst wurde in englischer Sprache verfasst, um weltweit Interessenten zu adressieren. Inhaltlich wurde dargestellt, was das Ziel von MTF ist, welche weiteren Projekte integriert werden und wie sich MTF von anderen Lösungen abgrenzt. 5.2.2 Projektpaten Damit ein Projekt innerhalb der Eclipse Community überhaupt eingebracht werden darf, müssen 2 Projektpaten aus der Eclipse Community gefunden werden, die bereits erfolgreiche Projekte führen. Im Falle von MTF sind dies: 121 • Ed Merks, Macromodeling Inc. Canada, Projekt EMF • Sven Efftinge, itemis AG, Deutschland, Projekt Xtext, MWE, Xtend Bereits das finden der Paten und überzeugen dieser von der Projektidee brachte insbesondere in den Aspekten der Abgrenzung anderer Lösungen und Integration weiterer vorhandener Projekte einen deutlichen Qualitätsvorteil und eine Schärfung des Projekproposals. Im Anschluss an die Findung der Paten wurde das Proposal als Entwurf innerhalb einer größeren Community vorgestellt 5.2.3 Interessenten Basierend auf diesem Entwurf des Proposals wurden nur in den vorhandenen englischsprachigen Kommunikationskanälen der Eclipse Foundation und auch innerhalb der vorhandenen Kundenkontakte der itemis AG potenzielle Interessenten gefunden. Das Proposal wurde als Entwurf auf an die Eclipse Foundation übermittelt14 und über die Newsgroup Eclipse.technologie.emft15 verbreitet. Daraufhin meldeten sich die folgenden Interessenten, die Interesse haben MTF zu nutzen oder gar in ihre Lösungen zu integrieren: • Achievo Deutschland AG, Sven Krause • CDO Model Repository, Eike Stepper (CDO project lead) • itemis AG, Sven Efftinge (TMF PMC) • Oracle Deutschland GmbH, Berthold Maier • Institut für Angewandte Informatik e.V. an der Universität Leipzig, Stefan Kühne • SOPERA GmbH, Zsolt Beothy-Elo • Abteilung Betriebliche Informationssysteme an der Universität Leipzig, Martin Gebauer • flowr.org, Helmar Behrends • Javier Muñoz, leader of the MOSKitt project • Raphael Faudou, Atos Origin and the MDT Papyrus project • Igor Burilo, Polarion Software (Subversive team) 14 15 122 http://www.Eclipse.org/proposals/mtf http://www.Eclipse.org/newsportal/thread.php?group=Eclipse.technology.emft 5.2.4 Proposal erstellen Mit den gefundenen Interessenten, den Projektpaten und den bereits erhaltenen Verbesserungsvorschlägen und Hinweisen aus der Community wurde das Proposal finalisiert und an das Managementboard der Eclipse Foundation gesendet. Aufgrund der guten Vorarbeiten wurde der itemis AG auch nach einigen Wochen die Erlaubnis erteilt, MTF als Projekt innerhalb der Eclipse Infrastruktur einzubringen. Notwendig dafür war allerdings noch, dass alle Entwickler am Projekt schriftlich bescheinigen müssen, bzw. von ihren Arbeitgebern bestätigen lassen müssen, dass sie in Zukunft genügend Freiraum haben, um das Projekt aktiv zu begleiten. Somit stellt die Eclipse Foundation nicht nur inhaltliche Qualität sicher, sondern auch die aktive Weiterentwicklung. Aktive Committer am Projekt sind: • Michael Willig, itemis AG • Sven Krause, Achievo AG • Steffen Dienst, Institut für Angewandte Informatik e.V. an der Universität Leipzig • Robert Wloch, itemis AG • Steffen Stundzig, itemis AG • Helmar Behrends, Achievo AG 5.2.5 Infrastruktur einrichten Nach der Freigabe als Eclipse Projekt wurde die zur Durchführung notwendige Infrastruktur aufgebaut. Zum Verfolgen von Fehlern, Aufgaben aber auch neuen Anforderungen wurde ein Bugzilla16 eingerichtet. Für die Kommunikation mit der Community wird die Newsgroup Eclipse.technology.emft genutzt. Das Verwalten der Quellcodes wird zentral im CVS-System der Eclipse Foundation ein entsprechendes Verzeichnis eingerichtet17 . Abschließend wurden für die automatische Build und Testumgebung entsprechende Jobs aufgebaut. Die Entwickler diskutieren über die Mailingliste mtf-dev18 . 5.2.6 Projektwebseite erstellen Alle Daten und Verweise zur Infrastruktur, als auch Proposal, Ziele und weitere Dokumentationen wurden in einer zentralen Webseite19 innerhalb der Eclipse Foundation zusammengefasst Das Projekt wurde als Incubation Projekt markiert, um allen Interessenten anzudeuten, dass das Projekt im Entstehen, bzw. in Entwicklung ist. Vom Designer der itemis AG wurde auch ein ansprechendes Logo für MTF entwickelt. 16 17 18 19 https://bugs.Eclipse.org/bugs/buglist.cgi?quicksearch=EMFT.MTF http://dev.Eclipse.org/viewcvs/viewvc.cgi/org.Eclipse.emf/org.Eclipse.emf.mtf/?root=Modeling_Project https://dev.Eclipse.org/mailman/listinfo/mtf-dev http://www.Eclipse.org/modeling/emft/mtf 123 Abbildung 4: Logo für das Eclipse Projekt MTF 5.2.7 Initialen Code einbringen Als initiale Quellcodebasis brachten die Entwickler der Achievo AG Quellcode aus dem OpenSource-Projekt flowr.org in das Projekt ein. Dieser Quellcode wurde von den anderen Committern refaktorisiert und entsprechend in das Layout vom MTF gebracht. Um den Quellcode überhaupt in das Projekt einbringen zu können, mussten die Entwickler für alle Dateien eindeutig schriftlich festhalten, dass die Quellen von ihnen selbst verfasst sind und keine anderen Kopierrechte oder andere Rechte von Dritten verletzt werden. Somit wurde rechtlich sichergestellt, dass die vorliegenden Basisquellcodes frei verwendet werden dürfen, was an einigen Stellen wieder zu einer weiteren Bereinigung und Qualitätsteigerung der Software führte. 5.2.8 Automatisierte Builds aufbauen Alle Projekte innerhalb der Eclipse Plattform werden zyklisch nach Änderungen bzw. zu festgelegten Zeitpunkten vollständig gebaut. Somit haben alle potenziellen Nutzer die Möglichkeit permanent die aktuellsten Versionen zu benutzen oder auch auf älteren Versionen, die entsprechend vorgehalten werden, zurückzugreifen. Für MTF wurden dafür 3 entsprechende Jobs eingerichtet die inhaltlich nach Funktion und Komponente strukturiert sind. 6 Weiteres Vorgehen Für die Weiterentwicklung das Projekts MTF und der entsprechenden Vorarbeiten im Eclipse Umfeld werden Sponsoren gesucht, die diese Entwicklung weiterfinanzieren möchten, um entsprechend die entstehende Lösung einsetzen zu können. Für die Arbeiten selbst wird wieder agil und iterativ vorgegangen. Ein grober Arbeitsplan für diese Weiterentwicklung wurde ebenfalls bereits entwickelt. Die Arbeitspakete werden für verschiedene Verfeinerungs- und Erweiterungsstufen durchgeführt. Die Interessenten werden aus dem vorhandenen Kundenkreis der itemis als auch über die Eclipse Foundation versucht zu finden. Das Projekt selbst wird, wenn möglich, mit Hilfe agiler Methoden, in dem Falle Scrum durchgeführt. Dabei entstehen innerhalb kurzer Sprintzyklen potenziell ausführbare Produktvarianten. 124 Abbildung 5: Scrum Prozess 6.1 Inhaltliche Schwerpunkte der Arbeitspakete AP1 „Anforderungsanalyse“ beschäftigt sich mit der Auswahl und Evaluation von Repositories und Werkzeugen aus dem Eclipse-Umfeld, die für eine Integration in MTF tatsächlich in Frage kommen. Daneben wird die auf Seite 5 beschriebene Gap-Analyse reevaluiert mit dem besonderen Fokus auf Schnittstellen und Interoperabilität. Als Grundlage für AP2 werden relevante Traceability-Metamodelle aus der Literatur auf ihre Eignung für den praktischen Einsatz in MTF hin untersucht. AP2 „DSL zur Deklaration von Abhängigkeiten“ beschäftigt sich aufbauend auf AP1 mit der Definition einer domänenspezifischen Sprache, die es einem Anwender erlaubt, Beziehungen und Beziehungstypen zwischen Artefakten zu definieren. Diese DSL wird später für die Konfiguration des Repositories eingesetzt werden. Aufbauend auf dieser deklarativen Sprache werden Mappings für verschiedene Eclipse-Modeling-Teilprojekte definiert, beispielsweise zwischen Modellen und graphischen Editoren auf GMF-Basis. Dieses Arbeitspaket bildet den wissenschaftlichen Kern des Projektes, die Leitung hierfür liegt deshalb beim InfAI. AP3 „Architektur“ legt die grundlegende Softwarearchitektur des Metarepositories fest. Es werden Schnittstellen für die Integration der einzelnen dedizierten Repositories geschaffen und Erweiterungspunkte, etwa für Hooks definiert. Es wird ein generisches Rechte- und Rollenkonzept entworfen sowie Anbindungen für Analysewerkzeuge, etwa für die Aufbereitung und Visualisierung von konsolidierten Sichten auf die Daten, die MTF auf dedizierte Repositories verteilt. AP4 „Implementierung“ stellt die eigentliche Umsetzung der Erkenntnisse aus AP1 und AP2 sowie der Architektur aus AP3 dar. MTF selbst wird modelgetrieben entwickelt, um eine einfachere Anpassbarkeit etwa für die Integration neuer Repository-Arten zu ermöglichen. Aufgrund ihrer technischen Kompetenz liegt die Verantwortung dieses Arbeitspaketes bei der itemis AG Im AP5 „Demonstratoren, Evaluation“ wird das MTF-Repository in prototypischen MDSD-Entwicklungen innerhalb der itemis AG sowie in praktischen Szenarien der assoziierten Partner angewendet und erprobt. Dabei werden Metriken zur Evaluation von Rationalisierungs- und Qualitätssteigerungseffekten definiert und ausgewertet. Die gewonnenen Erkenntnisse fließen in Form von ergänzenden Anforderungen in nachfolgende Projektiterationen ein. AP6 „Ergebnisverbreitung“ enthält sowohl die Veröffentlichung der gewonnenen Erkenntnisse auf wissenschaftlichen Konferenzen als auch die Präsentation der entstehenden Software auf 125 Messen und Unternehmenspräsentationen. Die praktischen Ergebnisse sollen frühzeitig der OpenSource-Community zur Verfügung gestellt werden, um noch zur Projektlaufzeit externes Feedback in die Entwicklung von MTF einbringen zu können. AP7 „Projektmanagement“ beinhaltet alle Aktivitäten, die dem Management und Controlling des Projekts dienen, d. h. Mitarbeiterführung, Organisation und Durchführung von Projekttreffen, Erstellung von Zwischenberichten und dem Abschlussbericht. Literatur [BLW05] Baker, Paul ; Loh, Shiou ; Weil, Frank: Model-Driven Engineering in a Large Industrial Context – Motorola Case Study. In: Briand, Lionel (Hrsg.) ; Williams, Clay (Hrsg.): Model Driven Engineering Languages and Systems Bd. 3713. Berlin, Heidelberg : Springer Berlin / Heidelberg, 2005. – ISBN 978–3–540–29010–0, Kapitel 36, S. 476–491 [Bro86] Brooks, Frederick P: No Silver Bullet – Essence and Accident in Software Engineering. In: Proceedings of the IFIP Tenth World Computing Conference, 1986, S. 1069–1076 [EMM+ 10] Eberle, Stephan ; Mandischer, Martin ; McClean, Toby ; Redding, Simon ; Selic, Bran: Gap Analysis of Eclipse Modeling Projects. http://wiki.Eclipse.org/images/4/4e/ MPIWG-GapAnalysis-Docs-20101001-final.zip. Version: 2010 [GF94] Gotel, Orlena C. Z. ; Finkelstein, Anthony C. W.: An Analysis of the Requirements Traceability Problem. In: Proceedings of the First International Conference on Requirements Engineering, 1994, S. 94–101 [GK10] Grammel, Birgit ; Kastenholz, Stefan: A generic traceability framework for facet-based traceability data extraction in model-driven software development. In: Proceedings of the 6th ECMFA Traceability Workshop. New York, NY, USA : ACM, 2010 (ECMFA-TW ’10). – ISBN 978–1– 60558–993–0, S. 7–14 [HK10] Hänsgen, Peter ; Kern, Heiko: Modellbasierte Schichtenarchitektur zur Komposition von Geschäftsanwendungen. In: Fähnrich, Klaus-Peter (Hrsg.) ; Franczyk, Bogdan (Hrsg.): GI Jahrestagung (1) Bd. 175, GI, 2010 (LNI). – ISBN 978–3–88579–269–7, 274-279 [KDZ10] Kirstan, Sascha ; Dr. Zimmermann, Jens: Evaluating costs and benefits of model-based development of embedded software systems in the car industry – Results of a qualitative Case Study. In: Modelling Foundations and Applications, 6th European Conference. Paris : Springer, 2010 [Loe09] Loeliger, Jon: Version control with Git: Powerful tools and techniques for collaborative software development. 1st. Beijing, 2009 (Safari Tech Books Online) [PCSF09] Pilato, C. Michael ; Collins-Sussman, Ben ; Fitzpatrick, Brian W.: Versionskontrolle mit Subversion: [Software-Projekte intelligent koordinieren]. 3. Aufl., komplett überarb. u. aktual. Köln u.a : O’Reilly, 2009. – ISBN 978–3–89721–897–0 [SBPM09] Steinberg, Dave ; Budinsky, Frank ; Paternostro, Marcelo ; Merks, Ed: EMF: Eclipse Modeling Framework. 2. Boston, MA : Addison-Wesley, 2009. – ISBN 978–0–321–33188–5 [WP10] 126 Winkler, Stefan ; Pilgrim, Jens: A survey of traceability in requirements engineering and model-driven development. In: Softw. Syst. Model. 9 (2010), September, S. 529–565. – ISSN 1619–1366 127 128 In der Reihe „Leipziger Beiträge zur Informatik“ sind bereits erschienen: Band I FÄHNRICH , K.-P.; H ERRE , H. (Hrsg.): Content- und Wissensmanagement. Arbeiten aus dem Forschungsvorhaben PreBIS und Beiträge auf den Leipziger Informatik-Tagen 2003. Leipziger Beiträge zur Informatik: Band I. Leipzig, 2003. – ISBN 3-934178-26X Band II FÄHNRICH , K.-P.; M EIREN , T. (Hrsg.): Computer Aided Engineering für IT-basierte Dienstleistungen. Arbeiten aus dem Forschungsvorhaben ServCase. Leipziger Beiträge zur Informatik: Band II. Leipzig, 2004. – ISBN 3-934178-39-1 Band III FÄHNRICH , K.-P.; T HRÄNERT, M.; W ETZEL , P. (Hrsg.): Umsetzung von kooperativen Geschäftsprozessen auf eine internetbasierte IT-Struktur. Arbeiten aus dem Forschungsvorhaben Integration Engineering. Leipziger Beiträge zur Informatik: Band III. Leipzig, 2005. – ISBN 3-934178-52-9 Band IV FÄHNRICH , K.-P.; K ÜHNE , S.; S PECK , A.; WAGNER , J. (Hrsg.): Integration betrieblicher Informationssysteme – Problemanalysen und Lösungsansätze des Model-Driven Integration Engineering. Leipziger Beiträge zur Informatik: Band IV. Leipzig, 2006. – ISBN: 978-3-934178-66-3 Band V FÄHNRICH , K.-P.; H ÄRTWIG , J.; K IEHNE , D.-O.; W EISBECKER , A. (Hrsg.): Technologien und Werkzeuge für ein rollen- und aufgabenbasiertes Wissensmanagement. Zusammenfassender Bericht aus dem Forschungsprojekt PreBIS. Leipziger Beiträge zur Informatik: Band V. Leipzig, 2007. – ISBN: 978-3-934178-76-2 Band VI FÄHNRICH , K.-P.; T HRÄNERT, M.; W ETZEL , P. (Hrsg.): Integration Engineering. Motivation – Begriffe – Methoden – Anwendungsfälle. Leipziger Beiträge zur Informatik: Band VI. Leipzig, 2007. – ISBN: 978-3-934178-78-6 Band VII AUER , S.: Towards Agile Knowledge Engineering: Methodology, Concepts and Applications. Dissertation an der Fakultät für Mathematik und Informatik der Universität Leipzig. Leipziger Beiträge zur Informatik: Band VII. Leipzig, 2007. – ISBN: 978-3934178-73-1 Band VIII FÄHNRICH , K.-P.; H EYER , G. (Hrsg.): Games Summer Camp 2007. Interdisziplinäres Blockseminar zum Thema Digitale Spiele. Eine Dokumentation. Leipziger Beiträge zur Informatik: Band VIII. Leipzig, 2007. – ISBN: 978-3-934178-77-9 Band IX A SLAM , M. A.: Towards Integration of Business Processes and Semantic Web Services. Leipziger Beiträge zur Informatik: Band IX. Leipzig, 2008. – ISBN: 978-3934178-89-2 Band X FÄHNRICH , K.-P.; M ÜLLER , R.; M EYER , K.; F REITAG , M. (Hrsg.): Entwicklung internationaler produktbezogener Dienstleistungen – Ein Handlungsleitfaden für kleine und mittlere Unternehmen. Leipziger Beiträge zur Informatik: Band X. Leipzig, 2008. – ISBN: 978-3-934178-98-4 129 Band XI FÄHNRICH , K.-P.; K ÜHNE , S.; T HRÄNERT, M. (Hrsg.): Model-Driven Integration Engineering. Modellierung, Validierung und Transformation zur Integration betrieblicher Anwendungssysteme. Leipziger Beiträge zur Informatik: Band XI. Leipzig, 2008. – ISBN: 978-3-941152-02-1 Band XII M AICHER , L.; G ARSHOL , L. M. (Hrsg.): Subject-centric Computing. Fourth International Conference on Topic Maps Research and Applications, TMRA 2008. Leipziger Beiträge zur Informatik: Band XII. Leipzig, 2008. – ISBN: 978-3-941152-05-2 Band XIII FÄHNRICH , K.-P.; S CHUMACHER , F. (Hrsg.): Digitale Spiele in Forschung und Lehre. Beiträge zum Games Summer Camp 2008. Leipziger Beiträge zur Informatik: Band XIII. Leipzig, 2009. – ISBN: 978-3-941608-00-9 Band XIV H EYER , G. (Ed.): Text Mining Services – Building and applying text mining based service infrastructures in research and industry. Proceedings of the conference on Text Mining Services – TMS 2009 at Leipzig University. Leipziger Beiträge zur Informatik: Band XIV. Leipzig, 2009. – ISBN: 978-3-941608-01-6 Band XV T HRÄNERT, M.: Integration-Engineering – Grundlagen, Vorgehen und Fallstudien. Leipziger Beiträge zur Informatik: Band XV. Leipzig, 2009. – ISBN: 978-3-94160802-3 Band XVI FÄHNRICH , K.-P.; A LT, R.; F RANCZYK , B. (Eds.): Practitioner Track – International Symposium on Services Science (ISSS’09). Leipziger Beiträge zur Informatik: Band XVI. Leipzig, 2009. – ISBN: 978-3-941608-03-0 Band XVII M EYER , K.: Software – Service – Co-Design: Eine Methodik für die Entwicklung komponentenorientierter IT-basierter Dienstleistungen. Leipziger Beiträge zur Informatik: Band XVII. Leipzig, 2009. – ISBN: 978-3-941608-04-7 Band XVIII AUER , S.; L AUENROTH , K.; L OHMANN , S.; R IECHERT, T. (Hrsg.): Agiles Requirements Engineering für Softwareprojekte mit einer großen Anzahl verteilter Stakeholder. Leipziger Beiträge zur Informatik: Band XVIII. Leipzig, 2009. – ISBN: 978-3-94160805-4 Band XIX M AICHER , L.; G ARSHOL , L. M. (Eds.): Linked Topic Maps. Fifth International Conference on Topic Maps Research and Applications, TMRA 2009. Leipziger Beiträge zur Informatik: Band XIX. Leipzig, 2009. – ISBN: 978-3-941608-06-1 Band XX H ÄRTWIG , J.: Konzept, Realisierung und Evaluation des semantischen Informationsraums. Dissertation. Leipziger Beiträge zur Informatik: Band XX. Leipzig, 2010. – ISBN: 978-3-941608-07-8 Band XXI M ORGENSTERN , U.; R IECHERT, T. (Hrsg.): Catalogus Professorum Lipsiensis. Konzeption, technische Umsetzung und Anwendungen für Professorenkataloge im Semantic Web. Leipziger Beiträge zur Informatik: Band XXI. Leipzig, 2010. – ISBN: 978-3941608-08-5 Band XXII L EHMANN , J.: Learning OWL Class Expressions. Leipziger Beiträge zur Informatik: Band XXII. Leipzig, 2010. – ISBN: 978-3-941608-09-2 130 Band XXIII M EYER , K.; T HIEME , M. (Hrsg.): Vom Bedarf zum Innovationserfolg – In 6 Schritten gemeinsam Potentiale aktivieren. Leipziger Beiträge zur Informatik: Band XXIII. Leipzig, 2010. – ISBN: 978-3-941608-10-8 Band XXIV M AICHER , L.; G ARSHOL , L. M. (Eds.): Information Wants to be a Topic Map. Sixth International Conference on Topic Maps Research and Applications, TMRA 2010. Leipziger Beiträge zur Informatik: Band XXIV. Leipzig, 2010. – ISBN: 978-3-94160811-5 Band XXV H EYER , G.; L UY, J.-F.; JAHN , A. (Hrsg.): Text- und Data Mining für die Qualitätsanalyse in der Automobilindustrie. Leipziger Beiträge zur Informatik: Band XXV. Leipzig, 2010. – ISBN: 978-3-941608-12-2 Band XXVI FÄHNRICH , K.-P.; S CHUMACHER , F.; T HIEME , M.; G ROSS , J. (Hrsg.): (Über)Leben in der Kreativwirtschaft – Beiträge zum Creative Summer Camp 2011. Leipziger Beiträge zur Informatik: Band XXVI. Leipzig, 2011. – ISBN: 978-3-941608-13-9 Band XXVII AUER , S.; R IECHERT, T.; S CHMIDT, J. (Hrsg.): Studentenkonferenz Informatik Leipzig 2011. Leipziger Beiträge zur Informatik: Band XXVII. Leipzig, 2011. – ISBN: 978-3-941608-14-6 Band XXVIII G EBAUER , M.; S TEFAN , F.: Systemintegration – Eine qualitative Erhebung aus der Sicht von Integrationsdienstleistern. Leipziger Beiträge zur Informatik: Band XXVIII. Leipzig, 2011. – ISBN: 978-3-941608-15-3 BAND XXIX M EYER , K.; B ÖTTCHER , M.: Entwicklungspfad Service Engineering 2.0 – Neue Perspektiven für die Dienstleistungsentwicklung. Leipziger Beiträge zur Informatik: Band XXIX. Leipzig, 2011. – ISBN: 978-3-941608-16-0 BAND XXX K ERN , H., K ÜHNE , S.: Integration betrieblicher Informationssysteme und modellgetriebene Entwicklung. Leipziger Beiträge zur Informatik: Band XXX. Leipzig, 2012. – ISBN: 978-3-941608-17-7 Weitere Informationen und Bestellungen über: liv@informatik.uni-leipzig.de 131