Modellbasierte Softwareentwicklung

Transkript

1 Universität Augsburg Institut für Informatik Programmierung verteilter Systeme Modellbasierte Softwareentwicklung WS 2008/2009 Seminarband Prof. Dr. Bernhard Bauer Dipl.-Inf. Benjamin Honke Dipl.-Inf. Stefan Fenn Dipl.-Inf. Raphael Romeikat Dipl.-Inf. Christian Saad

2 Vorwort Dieser Band enthält die studentischen Arbeiten des Seminars Modellbasierte Softwareentwicklung, das im Wintersemester 2008 / 2009 and der Universität Augsburg abgehalten wurde. In der ersten Arbeit wurde von Phillip Stadler auf die Grundlagen der modellbasierten Softwareentwicklung eingegangen. Neben den grundlegenden Techniken wie Metamodellierung wird dabei auch der konkrete Einsatz, z.b. im Gebiet Model-Driven Engineering, behandelt. Das zweite Thema, bearbeitet von Markus Bickelmaier, erörtert die Grundlagen modellbasierter Testfallgenerierung. Ziel ist es dabei Tests auf Modellebene durchzuführen um bereits auf diesem abstrakten Level das Verhalten zu untersuchen und potentielle Fehler feststellen zu können. Die Arbeit von Robert Freudenreich untersucht Entwicklungsprozesse im Kontext des Eclipse Process Framework (EPF). Dabei wird auf dessen Anwendungsbereiche anhand verschiedener Prozessmodelle eingegangen und die Erweiterbarkeit anhand einer Fallstudie illustriert. Panayot Radinski geht im nächsten Thema detailliert auf die Bindingtechnik JAXB ein die einen Datentransfer zwischen XML und Java ermöglicht. In der letzten Seminararbeit die von Matthias Drexl und Maximilian Koch gemeinsam erstellt wurde werden verschiedene Notationen für die Modellierung von Geschäftsregeln vorgestellt und evaluiert sowie im Rahmen einer Fallstudie näher beleuchtet. April 2009 Die Editoren

3 Inhaltsverzeichnis Einführung in die modellbasierte Softwareentwicklung Grundlagen der modellbasierten Testfallgenerierung Evaluierung der Potentiale des Eclipse Process Frameworks Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) Modellierung von Geschäftsregeln

4 IV

5 Einführung in die modellbasierte Softwareentwicklung Philipp Stadler Universität Augsburg Zusammenfassung Die Softwareentwicklung hat in den letzten Jahrzehnten immer mehr an Bedeutung gewonnen. Um im Gegenzug dazu die Komplexität, den Aufwand und die damit verbundenen Kosten in einem moderaten Bereich zu halten bedient man sich unter anderem dem Hilfsmittel der modellbasierten Softwareentwicklung. Im Rahmen dieser Arbeit soll nun eine Einführung in die modellbasierte Softwareentwicklung gegeben werden und auf die Modelle, die Metamodelle und Modellierung sowie auf Anwendungsszenarien eingegangen werden. 1 Einleitung und Motivation Frederick P. Brooks, einer der großen Informatik Pioniere, unter anderem Leiter der System/360 - Entwicklung und des OS/360 - Projektes von IBM, sowie ausgezeichnet mit dem Turing-Preis, schrieb 1986 in seinem Essay No Silver Bullet: Essence and Accidents of Software Engineering folgendes Paradigma: The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet something to make software costs drop as rapidly as computer hardware costs do. [1, S.1] Nach Brooks können Softwareprojekte also unberechenbare Monster sein, bei denen Zeit und Kostenplan vollkommen aus dem Ruder laufen können. Somit sucht man natürlich nach dem magischen Tool, also nach der Silver Bullet, mit der sich Kosten und Aufwand senken lassen könnten. Die Standish Group hat 1994 den ersten CHAOS-Bericht herausgebracht. Im Jahre 1994 haben sich, laut dem bereits genannten Bericht, 31,1 Prozent aller in diesem Jahr gestarteten IT-Projekte als komplette Fehlplanungen erwiesen. Während dieser Untersuchung wurden mehr als IT-Projekte in den USA untersucht. Diese Projekte wurden wiederum von der Standish Group in die Cluster successful, challenged sowie failed eingeteilt. [12] Welchen Zusammenhang haben nun die, vom CHAOS-Report herausgefundenen Verbesserungen, bezogen auf die Softwareentwicklung, mit der modellgetriebenen Softwareentwicklung?

6 2 P. Stadler Kategorie Veränderung successful 16% 34% Verdopplung challenged 53% 51% wenig failed 31% 15% Halbierung Tabelle 1. Ergebnisse des CHAOS - Reports Die modellgetriebene Softwareentwicklung, bzw. Model Driven Software Development, kurz MDSD, befasst sich mit der Automatisierung der Softwareherstellung. Mit Hilfe dieser werden Modelle nicht nur als Dokumente verwendet, sie können mit dem Code gleichgesetzt werden. Es wäre jetzt etwas übertrieben zu behaupten, dass man es allein den verschiedenen Forschungsgebieten innerhalb der Softwareentwicklung, zu dem auch die MDSD gehört, zu verdanken hätte, dass sich die Werte welche durch die Standish Group ermittelt wurden verbessert haben. Es wird sich aber zeigen, dass man durch den Ansatz der modellgetriebenen Softwareentwicklung Fehlerquellen schon von vornherein, also z.b. in der Analyse bzw. Planungs- und Simulationsphase, dezimieren kann. Dadurch, dass Fehler in den meisten Fällen mit einem Kostenaufwand verbunden sind kann auch davon ausgegangen werden, dass sich dieser wohl ebenso verringern lassen könnte. Das international tätige IT-Marktforschungs- und Beraterunternehmen IDC (International Data Corporation hat in ihrer Abschlussstudie 2008 für den deutschen IT-Markt eine etwas düstere Prognose für die ersten zwei Quartale 2009 herausgegeben. [4] Das IDC hat, in dem für diese Arbeit interessanten Bereich des IT-Marktes, nämlich den Softwarebereich, eine Wachstumsrate von fünf Prozent für den Zeitraum bis 2012 analysiert. Ob und inwieweit Softwareentwicklungsschmieden, welche sich mit der modellgetriebenen Softwareentwicklung beschäftigen, davon profitieren können lässt sich an dieser Stelle leider nicht fundiert feststellen. Frei nach der deutschen Redewendung Wer kein Ziel hat, kann auch keins erreichen stellt sich hier auch die Frage welche motivierenden Ziele die modellgetriebene Softwareentwicklung nun verfolgt [9, 6]. Erhöhung der Entwicklungsgeschwindigkeit: durch Automation kann aus formalen Modellen in einem oder mehreren Transformationsschritten lauffähiger Code generiert werden. Einsatz von Transformationen: Qualitätssteigerung in der Softwareentwicklung, die auch eine Steigerung der Softwarequalität zur Folge haben kann. Dealing with complexity: durch verschiedene Abstraktionsebenen kann und soll die Komplexität besser gehandhabt werden. Standardisierung: die Object Management Group strebt mit der MDA, der Modell Driven Architecture, eine Standardisierungsrichtung an mit der v.a. eine plattformunabhängige Herstellerunabhängigkeit erziehlt werden kann.

7 Einführung in die modellbasierte Softwareentwicklung 3 Mit diesen, mitunter allgemein gehaltenen, Fragen haben die Entwickler, Forscher und Wissenschaftler rund um das Gebiet der modellbasierten Softwareentwicklung das Rad natürlich nicht neu erfunden. Dies sind grundlegende Fragen und Ziele wie sie überall in der Informationstechnik zu finden sind. Daher stellt dies nur eine weiter Bestätigung derer dar. In dieser Arbeit sollen nun die Grundlagen über Modelle (Kap. 3.1) der modellbasierten Softwareentwicklung (Kap. 3.2) erläutert werden. Aufbauend auf diesen werden ausgewählte Details der modellbasierten Softwareentwicklung und der MDA (Kap. 3.3) herrausgearbeitet, Anwendungen erörtert (Kap. 4) und zuletzt ein Blick auf die gegenwärtige Nutzung und Forschung (Kap. 5) geworfen. 2 Metamodelle und Metamodellierung Metamodellierung ist eine Konkatenation aus den beiden Worten Modellierung und meta. Das griechische Wort meta bedeutet so viel wie zwischen, neben, über und nach. Also sind Metamodelle, schlicht gesagt, Modelle von Modellen, da Metamodelle Modelle sind, die etwas über Modellierung aussagen. Eine genauere Ausführung dieser Formulierung wäre [9, 91]: Ein Metamodell beschreibt die mögliche Struktur von Modellen - es definiert damit in abstrakter Weise die Konstrukte einer Modellierungssprache, ihre Beziehungen untereinander sowie Einschränkungen bzw. Modellierungsregeln, nicht jedoch die konkrete Syntax dieser Sprache. Man benötigt konsequenterweise eine (Meta-)Modellierungssprache, welche wiederum durch ein (Meta-)Modell beschrieben wird. Nach Stahl et. al. definiert ein Metamodell also die abstrakte Syntax, sowie die statische Semantik einer (Modellierungs-)Sprache. Syntax und Semantik von Metamodellen wird in Kapitel 2.1 näher beschrieben. Im Umkehrschluss hat jede formale Sprache (wie z.b. Java oder UML) auch ein Metamodell. Die folgende Abbildung, nach Völter und Stahl [9, 92], verdeutlicht diesen Sachverhalt: Abbildung 1. Beziehungen wirkliche Welt - Modell - Metamodell Metamodell und Modell stehen in einer Beziehung von einer Klasse zu einer Instanz. Dies bedeutet, dass jedes Modell die Instanz eines Metamodells ist. Eine Herausforderung bei den Metamodellen besteht darin eine Modellierungssprache für sie zu definieren.

8 4 P. Stadler Es ist prinzipiell möglich Modelle in einer beliebigen Modellierungssprache zu beschreiben. Der jeweilige Ausgangspunkt bei der Modellierung in der modellbasierten Softwareenwicklung ist die Domäne.[9] Dies ist, wie aus der IT bekannt, ein Gebiet, in Bezug auf die MDSD ist es ein, für die jeweilige Anforderung, begrenztes Wissensgebiet. Bei der Auswahl der Modellierungssprache ergibt sich daraus die Anforderung ob überhaupt genügend Werkzeuge, welche für die Modellierung der (Meta-)Sprache nötig sind, zur Verfügung stehen. Abbildung 2, welche offiziel von der OMG definiert wurde, zeigt die vier Metaschichten der OMG [9]: Abbildung 2. Die vier Metaschichten der OMG Eine Instanz während der Laufzeit der Klasse Person mit den dazugehörigen Attributen des Modells M1 ist in diesem Beispiel der Typ Person mit dem Namen Völter. Der Classifier des Metamodells-M2 bekommt den Namen des zu beschreibenden Modells, hier Name: Klasse von M1 (Typ). Die Schicht M3 ist die Abstraktionsschicht der MOF, welche dazu benötigt wird die Metamodelle zu beschreiben. Sie wurde von der Object Management Group innerhalb der Meta Object Facility Architectur definiert. Die Meta Object Facility verwendet einerseits eine Teilmenge der UML und

9 Einführung in die modellbasierte Softwareentwicklung 5 andererseits wird sie zum Entwurf von Metamodellen verwendet. Die offizielle Spezifikation der MOF, Schicht M3 in Abb. 2, beinhaltet eine abstrakte Sprachbeschreibung und ein Basisgerüst, das MOF - Modell. Mit diesem können plattformunabhängige Metamodelle erzeugt und spezifiziert werden. Um Metadaten innerhalb der MOF auszutauschen wurde von der OMG das XMI XML Metadata Interchange spezifiziert. Dieses Format erlaubt den Austausch von MOF-basierten Modellen und Metamodellen im XML-Format. [9] XML kann hier bei entscheidendte Vorteile zu anderen Formaten vorweisen: Ähnlichkeiten zu HTML, daher leichte Einarbeitung sehr strukturiert und dadurch leicht zu generieren und zu lesen plattformunabhänig und unterstützt Internationalisierung sowie Unicode modular sowie erweiterbar und enthält im Grunde die Obermenge für eine ganze Familie von Techniken Xlink (Überführung von Hyperlinks zu XML) XPointer (Syntax um auf Teile eines XML-Dokuments zu verweisen) CSS (Style-Sheet-Sprache; analog zu CSS in HTML) DOM (Document Object Model -Standardmenge an Funktionen) lizenzfrei und weit verbreitet Man kann die Meta Object Facility aus zwei verschiedenen Perspektiven betrachten. 1. die Modellierungsperspektive und 2. die Datenperspektive Bei der Modellierungsperspektive verläuft die Blickrichtung top-down entlang der Modellebenen. Hierbei kann die MOF entsprechende Informationsmodelle auf unterschiedlichen Ebenen für bestimmte Domänen definieren und diese anschließend durch Implementierungs- und Softwareentwurfstätigkeiten im Rahmen der Entwicklung nutzen. Die Datenperspektive legt ihren Fokus auf eine bestimmte Ebene eines gegebenen Modells. Dadurch können z.b. Strukturen im Rahmen der CORBA (Common Object Request Broker Architecture) Schnittstelle genutzt werden. Die CORBA - Schnittstelle wird auch von der OMG entwickelt und soll das Erstellen verteilter Anwendungen in einem homogenen Umfeld vereinfachen. Zusammenfassend muss man an dieser Stelle festhalten dass Metamodelle von essentieller Wichtigkeit für die Beschreibung von Modellen sind. Sie dienen infolgedessen auch zu einer besseren Verständlichkeit und der Vergleichbarkeit von Modellen, da man sich bei beiden unterschiedlichsten Arten von Modellen auf vergleichbare Eigenschaften etc. geeinigt hat, denn ohne eine vergleichbare Gesamtmenge könnte man grundlegend keine Vergleiche machen. 2.1 Syntax und Semantik der Metamodelle Die Syntax der Metamodelle befasst sich, wie auch in allgemein in Programmiersprachen, mit der grammatikalischen Struktur der Metamodelle. Eine Sprache

10 6 P. Stadler wird also durch ihre, nach ihren jeweils definierten Regeln, Konkatenation von Zeichen gebildet. Bei den Metamodellen wird zwischen konkreter und abstrakter Syntax unterschieden. Die konkrete Syntax ist der Bereich, der vom Anwender bzw. Modellierer direkt wahrgenommen und verarbeitet wird. Er stellt also eine spezifische Notation für die jeweilige Sprache bereit.[7] Die abstrakte Syntax ist die Realisierung zu einem Abstrakten System. Sie beinhaltet zwar das Vokabular sowie die Grammatik der Modellierungssprache aber sie definiert nicht wie die abstrakte Syntax dem Enandwender präsentiert wird. Die abstrakte Syntax definiert jedoch die Notationskonventionen und Schlüsselwörter, welche vom Compiler verwendet werden. Hierbei werden Strukturen und Konzepte definiert, die dem Programmierer, Anwender und Modellierer die Lesbarkeit vereinfachen. Die Schlüsselwörter, die der Endbenutzer nutzt sind jedoch aus abstrakter Sichtweise weniger relevant. Diese Aufgabe übernimmt die konkrete Syntax. Laut Stahl et. al könnte man sagen dass eine konkrete Syntax die Realisierung einer abstrakten Syntax ist. Hierbei ist die Tatsache besonders hervorzuheben, dass verschiedene konkrete Syntaxformen eine gemeinsame abstrakte Syntax haben können. Bei den Metamodellen unterscheidet man auch zwischen statischer und dynamischer Semantik. Die dynamische Semantik ist der Teil der Modellierungssprache der während der Programmausführung im Speicher existiert. So nimmt diese direkten Bezug auf die Lebensdauer ( Runtime ) bei der Ausführung von Programmabschnitten. Die statische Semantik setzt ihren Anspruch auf die Wohlgeformtheitsregeln der Sprache. Dies können auf der einen Seite Deklarationen von Variablen, Übergabeparameter oder aber auch Gültigkeitsbereiche, welche auf Gültigkeitsregeln beruhen, sein. [9] 2.2 Object Constraint Language and Domain Specific Language Um Modellierungsregeln für beispielsweise MOF-basierte Modellierungssprachen zu beschreiben, braucht man eine Sprache um diese Regeln oder Einschränkungen (bzw. Constraints) zu definieren. Diese Aufgabe übernimmt die Object Constraint Language. Die Object Constraint Language (OCL) ist eine Erweiterung der Unified Modeling Language (UML) und ihre Standard-Abfragesprache. Ursprünglich wurde sie als eigene Technik entwickelt und ist inzwischen Teil des Object Management Group bzw. OMG-Standards. Die Syntax der Object Constraint Language basiert teilweise auf der objektorientierten Programmiersprache Smalltalk-80 und hat neben dieser weitgehend intuitiven Syntax auch Bestandteile aus der Prädikatenlogik. Die OCL dient hauptsächlich der Beschreibung von Bedingungen für die UML Notationen, also Diagramme oder besser Klassendiagramme. Hier sind wiederum auch die Anteile der Prädikatenlogik ersichtlich, denn mit der OCL beschreibt

11 Einführung in die modellbasierte Softwareentwicklung 7 man Invarianten sowie Vor- und Nachbedingungen von Operationen und Methoden. Die Object Constraint Language kommt, verglichen mit der UML relativ wenig zum Einsatz. Der Grund hierfür liegt schätzungsweise darin, dass es vielen Anwendern schwerfällt eine texturelle Sprache innerhalb der visuellen Sprache UML zu verwenden. Die OCL ist, im Gegensatz zu Smalltalk-80, eine getypte Sprache.[7, 282] Neben den Standard- und Basistypen gibt es noch die Tupel und Containertypen. Zusammenfassend beschreibt die OCL 2.0 Spezifikation der Object Management Group die oft eingesetzten Datentypen wie String, Integer aber auch Aufzählungstypen. Sowie die jeweiligen Datentypen des zugrundeliegenden Modells. Dies bedeutet dass beispielsweise alle im UML-Modell definierten Typen auch in OCL bekannt sind. Jeder der aufgezählten Datentypen hat für ihn definierte Operationen. Die Aufzählung dieser würde den Umfang dieser Arbeit jedoch sprengen und sind außerdem in der Spezifikation für den OCL Standard für jeden frei verfügbar. Aus der theoretischen Informatik kennt man das Constraint-Satisfaction-Problem, welches sich zur Aufgabe gemacht hat die Belegungen zu finden welche alle Bedingungen, also Constraints, erfüllen. Ist dies der Fall spricht man, in der theoretischen Informatik, von einem Modell. Die Constraints, also Regeln und Einschränkungen zwischen verschiedenen Metaklassen machen neben den Metaattributen und Metaassoziationen einen großen Teil der Bedeutung des Metamodells aus. Dies ist auch der Grund warum man sich überhaupt für die Spezifizierung der OCL entschieden hat. Wie man aus der Beschreibung der statischen Semantik bereits weiß kann z.b. eine Modellierungssprache wie UML mit Hilfe der OCL formal definiert werden. OCL-Ausdrücke nehmen also, mit Hilfe der statischen Semantik Bezug auf die abstrakte Syntax (d.h. die Klassenstruktur des Profils) auf eine Sprache wie z.b. UML.[9, 68] Ein Teilgebiet der OMG ist die QVT, kurz Query View Transformation. Diese Spezifikation wird benötigt, da zwar mit MOF, UML und XMI die Standardisierung des Gebietes Modellierung relativ weit vorangeschritten ist, aber mit diesen noch keine Standards für Transformationen gegeben sind. Hier kommt die Query View Transformation zum Tragen.[6] Diese Transformationen zwischen Modellen ermöglichen beispielsweise eine Transformation von einem Klassenmodell zu einem ER-Modell. Die Object Management Group unterscheidet bei der Spezifizierung der QVT zwischen zwei Arten von Sprachen: deklarative und imperative Der deklarative Teil der Spezifikation wurde von der OMG wiederum in die Two Level Declarative Architekture unterteilt. Diese beiden Layers (Schichten) sind zum einen die benutzerfreundliche Relations-Schicht und zum anderen der QVT-Core, welcher für den Endanwender meist weniger von Bedeutung ist. Zusätzlich zu dem deklarativen Teil, welcher im Grunde die selben semantischen Inhalte nur auf unterschiedlichen Abstraktionsebenen darstellt, ist der imperative Teil dazu da imperative Implementierungen aus Transformationen des QVT-Cores

12 8 P. Stadler sowie der QVT-Relation Sprache zu vereinheitlichen. Dies geschieht über das Operational Mapping. Algorithmen die komplexer sind, bzw. nicht einheitlich standardisiert sind werden über die Black-Box geführt. Genauer gesagt für Black-box MOF Operation implemenations. Abbildung 3. Relationships between QVT metamodells Um die Kernaspekte einer Domäne, speziell ihre formalen Aspekte formal modellierbar zu machen greift man auf das Konzept der domänenspezifischen Sprache (DSL = Domain Specific Language) zurück. Diese DSL besitzt nun ein Metamodell, welches eine, wie in (Kap. 2.1) beschriebene, statische Semantik und eine dazugehörende konkrete Syntax hat. Der jeweiligen domänenspezifischen Sprache fehlt jedoch noch eine Semantik, welche den Konstrukten des Metamodells, eine für den Menschen sinnvolle Bedeutung geben. Genauer gesagt fehlt ihr eine dynamische Semantik, wie sie in (Kap. 2.1) beschrieben wurde. Ob man synonym zu der Domain Specific Language nun Modellierungssprache sagt hängt ganz davon ab wie stark man vom Kontext der jeweiligen Domäne abhängig ist.[9] 3 Grundlagen 3.1 Modelle Was ist unter Modellen und der dazugehörigen Modellierung überhaupt zu verstehen? An dieser Stelle soll nun Anspruch darauf gelegt werden einen formalen, wissenschaftlichen Ansatz zu beschreiben. Der deutsche Philosoph Klaus D. Wüsteneck definierte 1963 [11] den Begriff Modell folgendermaßen: Ein Modell ist ein System, das als Repräsentant eines komplizierten Originals auf Grund mit diesem gemeinsamer, für eine bestimmte Aufgabe

13 Einführung in die modellbasierte Softwareentwicklung 9 wesentlicher Eigenschaften von einem dritten System benutzt, ausgewählt oder geschaffen wird, um letzterem die Erfassung oder Beherrschung des Originals zu ermöglichen oder zu erleichtern, beziehungsweise um es zu ersetzen. So wird ersichtlich, dass Modelle dazu dienen sollen einerseits die Realität abzubilden und andererseits zwischen verschiedenen Wahrnehmungsdimensionen innerhalb eines bestimmten Abstraktionslevels zu vermitteln. Es ergibt sich also die Möglichkeit, mithilfe eines Modells, ein vereinfachtes Abbild der Realität bzw. eines Ausschnittes der Realität wiederzugeben. Des Weiteren eignen sich Modelle zur Beschreibung, Gestaltung und Erklärung der Realität. Nun kann man, nach Stachowiak [8], die grundsätzliche Definition der Modelle folgendermaßen klassifizieren: Abbildungsmerkmale, welche das Modell als Abbildung des Originalen kennzeichnen Verkürzungsmerkmale, die die meist aus subjektiver Sicht betrachteten, relevanten Merkmale eines realen Systems abbilden, um dem Modellierer ein leichter zu überblickendes Modellgerüst präsentieren pragmatische Merkmale beschreiben Modelle nach ihrem (Einsatz-)Zweck, also für was sie gebraucht werden, wo und warum. So entscheidet der Modellierer selbst auf pragmatische Weise welche Orientierung und Zielgebundenheit er, dem Modell bezogen auf das Original beimisst. In vielen Bereichen des alltäglichen Lebens ist man von Modellen umgeben ohne es überhaupt zu wissen. So ist z.b. eine Deutschlandkarte mit der dazugehörigen Agenda auch als ein Modell anzusehen, da die Karte innerhalb ihres Maßstabes beispielsweise die wichtigen Verkehrspunkte Deutschlands klar und übersichtlich darstellt. Neben der Anwendung von Modellen in der Softwareentwicklung findet sich diese Technik auch in der Wirtschaftsinformatik. Dazu gehören vor allem Geschäftsprozessmodellierung und die Entity-Relationship Modellierung. Die Geschäftsprozessmodellierung kann hier einen sehr interessanten Einblick in die Arbeitsweise und Struktur eines Unternehmens bringen. Unternehmen können die modellierten Geschäftsprozesse einerseits dafür nutzen die Wiederverwendbarkeit von Prozessen zu garantieren. Diese Wiederverwendbarkeit kann z.b. gefordert werden durch den Umzug eines Produktionsstandortes oder durch Abgang von Wissensträgern im Unternehmen. Andererseits dient die Geschäftsprozessmodellierung auch der Präsentation des Unternehmens nach außen, also der Öffentlichkeitsarbeit.[3] Im Unternehmen ist der Ausgangspunkt des Geschäftsprozesses in den meisten Fällen auch das Ziel. Dass das Ziel ungleich dem Ergebnis ist, kann durch einen Pfeil verdeutlicht werden der beim Ziel beginnt und über eine Prozesskette zum Ergebnis gelangt. Ziel Prozesskette Prozesskette... Prozesskette Ergebnis

14 10 P. Stadler In der Wirtschaftsinformatik sowie in der Softwareentwicklung ist das Wasserfallmodell und das Spiralmodell seit vielen Jahrzehnten ein Begriff.[2] Die folgende Abbildung verdeutlicht dies. Abbildung 4. Vorgehensweise der Softwareentwicklung: Wasserfall- und Spiralmodell Der durch die Abbildung schon ersichtliche Unterschied besteht darin, dass das Spiralmodell während des Entwicklungsprozesses Möglichkeiten zur Intervention bietet. Würde man sich allein nach dem Wasserfallmodell richten wäre es wohl schwer einen während der Implementation enteckten Designfehler auszubessern, vorausgesetzt man würde sich alleine an dieses recht starre und theoretische Modell halten. 3.2 Modellbasierte Softwareentwicklung Um das Gesamtkonzept der modellbasierten Softwareentwicklung zu verstehen sollte man sich vor Auge halten dass das Ziel der MDSD darin besteht durch eine oder mehrere Transformationen ein Software-Produkt ganz oder teilweise herzustellen. Bisher wurden Transformationen in Verbindung mit der Query View Transformation (QVT) in Verbindung mit dem Meta-Metamodell, M3 der Meta Object Facility (Abb. 2), gebracht. In der Informatik lassen sich in aller Regel folgende Phasen beim Software- Entwicklungsprozess unterscheiden:[10] Anforderungen - den Business-Kontext und die Softwareanforderungen ermitteln Analyse - die Anforderungen und Problemstellungen verstehen Design - die Lösung beschreiben Realisierung - die Anwendung erstellen Testen - die Erfüllung der Anforderungen, Fehlerfreiheit etc. überprüfen Installation und Betrieb - die Hardware und Software in Betrieb nehmen Wartung - die Anwendung pflegen, verbessern und anpassen

15 Einführung in die modellbasierte Softwareentwicklung 11 Abbildung 5. Phasen der konventionellen objektorientierten Softwareentwicklung Das folgende Schaubild verdeutlicht diesen Prozess: Wie wir in Kap. 1 vermutet haben erfindet die modellgetriebene Softwareentwicklung das Rad nicht neu, es stellt einen entscheidenen Anspruch darauf diese Phasenfolge teilweise zu automatisieren. Damit soll erreicht werden dass die Fehler welche, beim scheinbar erfolgversprechendem Roundtrip-Engineering - Änderungen am Quelltext werden hierbei ins Design-Modell übetragen, entstehen auszugleichen. Das große Problem beim Roundtrip-Engineering besteht, nach Trompeter et. al. [10], darin dass die Änderungen, also die Fehlerkorrektur, auf einem falschen Abstraktionsniveau liegen. So sind zum Beispiel Strukturen wie Vererbungshierarchien und Beziehungen zwischen Objekten im Quelltext nicht auf einen Blick erkennbar, während Klassendiagramme es erlauben, den Überblick zu behalten. Deshalb führt das ausschließliche Arbeiten im Quelltext schnell zu unübersichtlichen und damit schlecht wartbaren Lösungen. Diese Fehler gleicht nun die modellgetriebene Softwareentwicklung aus, indem Teile dieser Phasenfolge automatisiert, sowie Implementierungsschritte (Realisierung in Abb. 5) durch Transformationen aus dem Design-Modell generiert.[10] Dies verdeutlicht folgende Abbildung: Für die verschiedenen Vorgehensweisen welche in Kap. 4 beschrieben werden, gibt es im Grunde ein festes Schema welche viele gemeinsam haben. Bei der Implementierung eines modellgetriebenen Entwicklungsprojektes teilt sich diese Vorgehensweise in zwei Teilbereiche: [10] Genarator-Entwicklung: Definition der Software-Architektur und Entwicklung des Generators, der diese Architektur umsetzt und Anwendungs-Entwicklung: Entwicklung der Fachanwendung, basierend auf der definierten Architektur unter Nutzung des Generators

16 12 P. Stadler Abbildung 6. Phasen der objektorientierten und modellgetriebenen Softwareentwicklung Nach Trompeter et. al müssen in einem MDSD-Entwicklungsprojekt für beide Teilbereiche Lösungen erarbeitet werden. 3.3 Model Driven Architecture - der MDSD-Ansatz der OMG Die Object Management Group hat die Idee der MDSD aufgegriffen und daraus einen Standard für ein modellbasiertes Softwareentwicklungskonzept herausgearbeitet. Diesen Standard der OMG nennt man Model Driven Architecture, kurz MDA, dieser wurde im Jahr 2000 vorgestellt. MDA basiert auf den OMG - Basistechnologien UML, MOF, XMI, CWM (Common Warehouse Metamodel), sowie auf den OMG-Schnittstellendefinitionssprachen IDL (Interface Description Language) und CORBA (Common Object Request Broker Architecture)[5] Zeppenfeld et al [12] motivieren die Model Driven Architecture folgendermaßen: Ziel dieses Standards ist es, die Plattformunabhänigkeit und Interopabilität von Metamodellen herzustellen. Die Interopabilität wird insbesondere durch Modell-Transformationen erreicht, die es erlauben, ein Metamodell in ein anderes zu transformieren. Der Einsatz verschiedener Abstraktionsgrade, wie schon in der Einleitung 1 erklärt wurde, sowie die Entwicklung technologieneutraler Anwendungsmodelle ziehen innerhalb der MDA einige Vorteile nach sich [12]: Das in den Modellen enthaltene Fachwissen kann über lange Zeiträume festgehalten werden. Bei einem technologiebedingten Plattformwechsel kann immerwieder auf dasselbe fachliche Modell zurückgegriffen bzw. kann dasselbe Modell auf verschiedensten Plattformen umgesetzt werden. Bevor mit der Umsetzung eines Softwareprojektes unter Benutzung der MDA begonnen werden kann, muss an dieser Stelle noch geklärt werden was man unter

17 Einführung in die modellbasierte Softwareentwicklung 13 Plattformen und Modellen versteht. Man versteht unter einer Plattform innerhalb der MDA die Zusammenführung von (Sub-)Systemen oder Technologien, die ein gemeinsames Konstrukt von Funktionalität durch Schnittstellen und Anwendungsmuster darstellt. Es wird die für die Implementierung des Systems gewünschte Plattform ausgewählt und letztlich die allgemeine Systemspezifikation in eine für die entsprechende Plattform benötigte Spezifikation transformiert. Für diese Vorgehensweise definiert die MDA die folgenden aufeinander aufbauenden Modelle [12]: das Computation Independent Model CIM, das Platform Independent Model PIM, das Platform Specific Model PSM und das Implement Specific Model ISM. Wie schon genannt bauen die verschiedenen Modelle aufeinander auf. Das Computation Independent Model (CIM) beschreibt die Anforderungen des zu erstellenden Softwaresystems. Dieses Modell wird auch Domänenmodell oder Geschäftsmodell genannt. In diesem Modell ist typischerweise nicht ersichtlich wie die Software im Endresultat implementiert werden soll, das Modell zeigt eher die Umgebung in der das System später eingebettet werden soll und kann daher genau darstellen welche Aufgaben das zu entwerfende System zu erfüllen hat. Das Computation Independent Model besitzt nach Zeppenfeld et. al [12] eine vergleichsweise geringe Bedeutung und wird deshalb in dem offiziellen White Paper der OMG Developing in OMG s Model-Driven Architecture [5] nicht erwähnt. Es begründet seine Hauptaufgabe damit dem Systemanalytiker Klarheit für die weitere Umsetzung der MDA zu geben. Nun kann man sich laut Jon Siegel et. al. [5] an folgender Vorgehensweise orientieren: 1. Schritt 1: Erstellen eines PIM Alle MDA -Entwicklungsprojekte starten mit der Erstellung eines (PIM). Modelle auf dieser hohen Abstraktionsebene werden oft von Geschäftsexperten und nicht von den eigentlichen Systemprogrammierern erstellt. Dabei werden häufig Erweiterungen und Spezialisierungen von UML (UML -Profile) eingesetzt, um gewisse Details in den Modellen darzustellen. 2. Schritt 2: Erstellen eines (PSM) Hier wird das (PIM) durch ein Werkzeug in (PSM) übersetzt. Ein (PSM) ist an eine bestimmte Technologie (Betriebsysteme, Programmiersprache, Middleware, Applikationsserver etc.) adaptiert. Es beschreibt ihre Anwendung mit den Mitteln der konkreten Implementierungstechnologie. 3. Schritt 3: Generierung der Anwendung Schließlich wird das Plattform- und technologiespezifische (PSM) in Quellcode übersetzt. Weil ein (PSM) seine Basistechnologie kennt, ist diese relativ einfach.

18 14 P. Stadler Die in den Kapiteln 2.2 und 2.1 beschriebenen Metamodelle und MOF sowie OCL-Ausdrücke finden sich hier auch in der Abgrenzung der MDA von der MDSD wieder [9]: MDA ist bezüglich der Ontologie einer Spezialisierung von MDSD mit folgenden Eigenschaften: MDA verwendet MOF als das Metamodell (d.h. als Mittel, um Metamodelle zu definieren). MDA sieht vor, dass die DSL s auf Basis der MOF definiert werden. Es sind also beliebige Notationen und Metamodelle möglich, solange sie mit Hilfe des OMG-Metamodells definiert wurden. In der Praxis regt MDA die Verwendung von UML-Profilen als konkrete Syntax für eine DSL an. Damit ist die DSL im Kern dann auf UML festgelegt. Die statische Semantik wird dementsprechend mit OCL-Ausdrücken spezifiziert. Software-Systemfamilien und Produktlinien haben in der MDA- Terminologie keine direkte Entsprechung und stehen auch inhaltlich nicht im Fokus. Es werden verschiedene Sichtwinkel auf formale Modelle definiert: Ein fachliches Modell kann relativ zu einer Plattform spezifisch (PSM) oder unspezifisch (PIM) sein. Die MDA legt mehrschichtige Transformationen zwischen Modellen nah, verbietet aber auch eine direkte PIM-zu-Code-Transformation nicht. Um auch die letzte Transformation, also die zur Plattform hin, als Modell-zu-Modell-Transformation notieren zu können, muss auch die Plattform mittels eines Metamodells beschrieben werden. Dazu werden PDM s, die Plattform Description Models, verwendet. Es gibt noch keine standardisierte Transformationssprache, aber ein Request for Proposal für Query/Views/Transformations (QVT). Ziel ist es Transformationen zwischen Quell- und Ziel-Metamodell für Modell-zu-Modell-Transformationen zu beschreiben. So detailliert die MDA beschrieben werden kann, so problematisch ist aber im Gegenzug ihre (alleinige) Praxistauglichkeit. Die reine, vollständige Anwendung, ist laut Stahl et. al. [9] nicht ohne weiteres möglich. Sie postulieren den Vergleich dass man sich nur vor Augen führen muss wie lange es gedauert hat bis wirklich praxistaugliche UML-Tools auf dem Markt waren. Unter anderem gehen sie auch auf den Aspekt der Interopabilität ein, der die Fähigkeit zur Zusammenarbeit von verschiedenen Systemen beschreibt. Die modellgetriebene Softwareentwicklung (MDSD) an sich benötigt die Eigenschaft der Interopabilität nicht zwangsläuftig. Für MDA ist sie von zentraler Bedeutung, weil sonst viele ihrer Ziele nicht realisiert werden können.

19 Einführung in die modellbasierte Softwareentwicklung 15 4 Anwendung modellbasierte SE: MDSD - Abgrenzung und Möglichkeiten Es werden nun zwei Vorgehensmodelle für die modellbasierte Softwareentwicklung erörtert. Es wird sich aber zeigen das allein die Anwendung dieser Modelle keine Garantie bietet dass ein Softwareprojekt erfolgreich ist. Im folgenden sollen Anhand des V-Modell XT des BSI (Beauftragte der Bundesregierung für Informationstechnik) und des Rational Unified Process (RUP) der Firma Rational Abgrenzung und Möglichkeiten für die modellbasierten Softwareentwicklung aufgezeigt werden. Das V-Modell XT des Bundes ist ein generisches Vorgehensmodell zum Planen und Durchführen von Entwicklungsprojekten[10]. Dieses Vorgehensmodell soll dazu genutzt werden, dass die komplette Software-Entwicklung und das Software-Management abgedeckt werden können. Von ihm werden dafür die Aktivitäten und Ergebnisse, die während der Entwicklung von Systemen durchzuführen bzw. zu erstellen sind definiert. Bestimmte Aufgaben des Projektes, wie z.b. das Projektmanagement, werden durch verschiedene verpflichtende und optionale Vorgehensbausteine wie Aktivitäten, Produkte und Rollen vorgegeben. Eine zeitliche Ablaufreihenfolge wird erst durch Strategien für die Projektdurchführung vorgegeben. Laut Trompeter et. al. [10] kommen Petrasch und Fieber zu dem Ergebnis, dass sich die vorhandenen Durchführungsstrategien des V-Modells nicht ohne Änderungen für MDA-Projekte anwenden lassen, da entscheidende Meilensteine aus dem MDA Guide der OMG nicht als so genannte Entscheidungspunkte im V-Modell XT abgebildet sind. Um das V-Modell an eigene Bedürfnisse anzupassen wurde mit der Version XT im Jahr 2005 das so genannte Tailoring eingeführt. Dies rechtfertigt auch das Suffix XT = Extreme Tailoring. Zum Stand dieser Arbeit (April 2009) ist die Version 1.3 des V-Modell XT aktuell: Mit Hilfe der Möglichkeit des Tailoring kann man Anpassungen an den Vorgehensbausteinen und Durchführungsstrategien im V-Modell XT vornehmen. Trompeter et. al.[10] unterstellen dem V-Modell XT die Fähigkeit für ein modellgetriebenes Vorgehen geeignet zu sein, wenn an ihm Anpassungen bzw. Erweiterungen vorgenommen werden. Diese Änderungen sollen an bestimmten Entscheidungspunkten ansetzten. Kapitel 3.3 beschreibt die Platform Independent Models, und wie in der Vorgehensweise beschrieben wurde braucht das iterative Vorgehen des MDA- Ansatzes den Entscheidungspunkt PIM erstellt. Vollständigkeitshalber wird auch die positive Bestätigung dieses Vorganges PSM erstellt eingefügt. Damit wird deutlich dass das V-Modell XT grundsätzlich geeignet ist für die modellgetriebene Softwareentwicklung. Der Rational Unified Process (RUP) ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung. Der RUP wurde 1996 von der Firma Rational

20 16 P. Stadler Software, welche mittlerweile zu IBM gehört, vorgestellt. Die Vorgehensweise des RUP ist iterativ, architekturzentriert, klar definiert und strukturiert. Das zentrale Element der RUP ist die Unified Modelling Language. Laut Trompeter et. al. [10] ist der Rational Unified Process eine konkrete Implementierung des Unified Process; ein Metamodell für Vorgehensmodelle. Der praktische Einsatz des Rational Unified Process für die modellbasierte Softwareentwicklung lässt sich anhand einiger Gemeinsamkeiten ausmachen. Der Ansatz der modellbasierten Softwareentwicklung sowie der Model Driven Architecture zeigt durch seine Kompabilität zur Unified Modeling Language die Gemeinsamkeit zum Rational Unified Process, da dieser komplett darauf basiert. Dies verwundert nicht denn die Urväter der UML (G. Booch, I. Jacobson und J. Rumbaugh) entwickelten parallel zur UML den Unified Process. Das iterative Vorgehen des RUP zeigt ebenso die Verwendungsmöglichkeiten für die modellbasierte Softwareenwicklung die diese iterative Vorgehensweise auch voraussetzt, siehe Abb. 6. Der RUP bietet ebenso wie das V-Modell XT die Möglichkeit das Modell für eigene Bedürfnisse anzupassen. Dadurch kann, laut Trompeter et. al., für einen modellgetriebenen Ansatz die Elaborations-Phase, also die konkrete Umsetzung angepasst werden, um den Grundstein für die Systemarchitektur zu legen. 5 Kritische Würdigung und Fazit Die Recherche für diese Arbeit hat gezeigt das Modellierung mehr ist als UML. Die Unified Modelling Language ist zwar, bis jetzt, der erfolgreichste und am weitesten verbreiteste Ansatz für Modellierung aber es zeigt sich doch das der Wunsch besteht für jedes erdenkliche Anwendungsgebiet die optimale Modellierungssprache zu finden. Die modellgetriebene Softwareentwicklung ist ein vergleichsweise junger Entwicklungszweig der das Ziel verfolgt einen durchgängigen Entwicklungsprozess für eine möglichst weitgehende Automatisierung der Softwareherstellung zu erreichen. Im Kern von MDSD stehen formale, durch einen Generator auswertbare Modelle, aus denen weite Teile eines Softwaresystems automatisiert erzeugt werden. Die entscheidenden Vorteile der modellgetriebenen Softwareentwicklung sind Produktivitätssteigerungen und insbesondere Qualitätsverbesserungen für die langfristige Wartbarkeit der Softwaresysteme. In Kap. 4 wurde gezeigt das sich etablierte Vorgehensmodelle wie der Rational Unified Process für einen modellgetriebenen Entwicklungsansatz anpassen lassen können. Vergleichend lässt sich feststellen das der reine Ansatz der MDSD wohl mehr Potential hat sich in der Zukunft durchzusetzten da er Open-Source und flexibel ist. Die MDA ist sehr stark abhängig von den Richtlinien zur UML, OCL und der Meta Object Facility. Literatur [1] F. P. Brooks Jr.. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, 20(4):1 2, April 1986.

21 Einführung in die modellbasierte Softwareentwicklung 17 [2] N. de Lange. Grundlagen aus der Informatik. Springer, [3] G. Disterer, F. Fels, and A. Hausotter. Taschenbuch der Wirtschaftsinformatik. Hanser, [4] J. Hackmann. Der deutsche It-markt steht vor einer Rezession. Computerwoche/2008, December [5] Jon Siegel. Developing in Omg Model-Driven Architecture. Object Management Group White Paper, 2.6:12, [6] M. Kempa and Z. A. Mann. Modell Driven Architecture. Informatik Spektrum, 28(4): , August [7] J. Seemann and J. W. von Gudenberg. Software-Enwurf mit der UML2. Springer/Xpert.press, [8] H. Stachowiak. Allgemeine Modelltheorie. Spektrum, [9] T. Stahl and M. Völter. Modellgetriebene Softwareentwicklung: Techniken, Engineering, Management. Dpunkt, [10] J. Trompeter and G. Pietrek. Modellgetriebene Softwareentwicklung MDA und MDSD in der Praxis. Software & Support, [11] K. D. Wüsteneck. Zur philosophischen Verallgemeinerung und Bestimmung des Modellbegriffs. Deutsche Zeitschrift für Philosophie, 12(12):1504, [12] K. Zeppenfeld and R. Wolters. Generative Software-Entwicklung mit der MDA. Springer, 2005.

22 Grundlagen der modellbasierten Testfallgenerierung Markus Bickelmaier Universität Augsburg Zusammenfassung In dieser Seminararbeit werden Möglichkeiten zum automatisierten Erkennen von Softwarefehlern untersucht. Die Betrachtung führt hin zum Begriff des modellbasierten Testens. Neben einem Einblick in die Grundlagen dieser Testmöglichkeit werden aber auch andere Testansätze aufgegriffen. Stellvertretend für alternative Testansätze wird das sourcecodebasierte Testen am Beispiel eines JUnit Tests vorgestellt. Das Verfahren des modellbasierten Testens wird in seiner Grundidee und seiner darauf aufbauenden Struktur beschrieben. Dabei werden die Unterschiede und Vorteile des modellbasierten Testens gegenüber anderen Testverfahren diskutiert und untersucht. An praktischen Beispielen wird die Prüfung einer Software unter verschiedenen Aspekten vorgestellt. Die Generierung der Testfälle kann dabei sowohl aus statischen als auch dynamischen Modellen heraus erfolgen. Auf die Unterschiede und Möglichkeiten zwischen den aus statischen und dynamischen Modellen erzeugbaren Tests wird eingegangen. Abschließend werden (nicht-)kommerzielle Tools vorgestellt, die die Modellierung und die Generierung von modellbasierten Tests wesentlich unterstützen können. Anhand eines einfachen Beispiels wird die Anwendung verdeutlicht.

23 Grundlagen der modellbasierten Testfallgenerierung 19 1 Einführung Die Komplexität von Softwaresystemen steigt immer weiter. Softwarefehler die zu spät erkannt werden verursachen hohe, unnötige Kosten, sowie einen Mehraufwand zur Beseitung dieser. Entdeckt man diese Fehler jedoch frühzeitig, so ist die Beseitigung einfacher, die Wahrscheinlichkeit von Folgefehlern oder abgeleiteten Fehlern geringer und das Produkt wesentlich preiswerter. Ein Lösungsversuch Fehler bereits in der Modellierungsphase aufzuspüren ist das modellbasierte Testen. Modellbasierte Tests werden aus (bestehenden) Modellen eines SUT 1 gewonnen und testen vorrangig die Umsetzung der Spezifikation im Design. Als Ergebnis zeigen sich, abhängig von der Komplexität des zu entwicklenden Softwaresystems, geringere Kosten in der Entwicklung, weniger Fehler in der Implementierung und qualitativ bessere und verlässlichere Software. Zudem verfügen Entwickler mit modellbasierten Tests über ein starkes Zertifizierungswerkzeug. 2 Testen von Software 2.1 Sourcecodebasiertes Testen Was ist sourcecodebasiertes Testen? Sourcecodebasiertes Testen beschäftigt sich, wie der Name schon sagt, mit dem Testen eines SUT, wobei die verwendeten Tests direkt als Sourcecode vorliegen. Es müssen also keinerlei Modelle zu diesen Tests oder der Software an sich existieren. Ein sehr einfaches Beispiel für sourcecodebasiertes Testen ist das Hinzufügen einer main-methode in einer Java Klasse um die Funktionalität der Klasse mit simulierten Daten zu überprüfen. Dies ist natürlich eine stark vereinfachte Betrachtungsweise, denn korrekt durchgeführte, toolgestützte sourcecodebasierte Tests bieten eine solide Grundlage für stabile und fehlerfreie Software. Da bei sourcecodebasierten Tests vollständiges, oder nahezu vollständiges Wissen über die Funktionsweise des SUT angenommen werden eignen sich diese besonders für White-Box Tests 2, jedoch sind logischer Weise auch Black-Box Tests 3 möglich Beispiel: JUnit JUnit ist ein Test-Framework für die Programmiersprache Java. JUnit Tests sind Unit Tests, also Tests einzelner Units wie Methoden oder Klassen eines Softwareprojekts. Das Kernprinzip von JUnit Tests sind Zusicherungen, sogenannte Asserts, die entweder wahr oder falsch sein können [14]. Ein Beispiel hierfür wäre Assert.assertEquals( Test, 6, 3 * 2). Dies würde true liefern, falls die JVM 3*2 zu 6 berechnet und ansonsten false [3]. 1 System under Test; Das zu testende System 2 White-Box Tests sind Tests bei denen Informationen über innere Abläufe eines SUT vorliegen und diese somit in den Testablauf mit einbezogen werden können [1]. 3 Black-Box Tests sind Tests bei denen nur nach aussen sichtbare Schnittstellen bekannt sind, jedoch keinerlei Wissen über interne Abläufe eines SUT besteht [2].

24 20 M. Bickelmaier Die Idee hinter den JUnit Tests ist, dass nichts implementiert wird was nicht auch getestet wurde. Dies hat den Vorteil, dass ein Programmierer der neu zu einem bestehenden Softwareprojekt hinzukommt, oder einfach Änderungen an bestehender Software vornehmen möchte, zunächst alle JUnit Tests durchführt. Liefern alle Tests true zurück, so weiß der neue Programmierer, dass der Code zu Beginn seiner Arbeit, fehlerfrei war. Liefern einige Tests nach seinen Änderungen false zurück, so sind diese Fehler mit Sicherheit auf den von ihm geänderten Code zurückzuführen. Ein weiterer Vorteil ist in der Übersichtlichkeit der Überprüfung zu sehen. Strebt man eine möglichst geringe Größe der zu prüfenden Units an, so lassen sich eventuelle Fehler leichter lokalisieren. Liefert ein JUnit test false zurück, so liegt der Fehler mit hoher Wahrscheinlichkeit in dieser Unit [16]. import org.junit.*; public class MultiplicationTest { /** Test whether 3 * 2 = 6, according to the JVM. public void testmultiplication() { Assert.assertEquals("Multiplication", 6, 3 * 2); } } Abbildung 1. Beispiel eines JUnit Tests 2.2 Modellbasiertes Testen Was ist modellbasiertes Testen Modellbasiertes Testen beschreibt das Testen eines SUT, wobei die verwendeten Tests teilweise oder vollständig aus Modellen generiert werden (siehe Abbildung 2). Das Modell eines Tests beschreibt diesen abstrakt, ist also nicht lauffähig. Damit ein modellierter Test lauffähig wird muss er über Modelltransformationen in einen ausführbaren Test umgewandelt werden (z.b. das Erzeugen lauffähigen Codes aus UML-Diagrammen; siehe auch Abbildung 3) [4]. Da diese Tests auf der Grundlage von Modellen gewonnen werden und nicht aus dem eigentlichen Sourcecode des SUT, spricht man im Zusammenhang mit modellbasierten Tests oft auch von Black-Box Tests. Es können jedoch auch Aspekte des Testens auf Sourcecodeebene einbezogen werden, so dass hier eine Mischform von Black-Box und White-Box Testen entstehen kann (Gray-Box Testen) [12]. Man unterscheidet bei der Durchführung modellbasierter Test grundsätzlich zwischen Online und Offline Tests. Von einem Onlinetest spricht man, wenn sich das Test-Tool direkt zum SUT verbindet und dynamisch generierte Tests automatisch auf diesem durchführt. Dies ist vor allem für längere und größere Testreihen von Vorteil, da man diese ohne jegliche Betreuung längere Zeit,

25 Grundlagen der modellbasierten Testfallgenerierung 21 Abbildung 2. Testfallgenerierung aus Modellen [13] z.b. über Nacht, laufen lassen kann um am Ende die gesammelten Ergebnisse abzurufen. Von einem Offlinetest spricht man, wenn die Tests in einem maschinenlesbaren Format erzeugt und gespeichert werden. Dies hat den Vorteil dass man spezielle Tests gezielt durchführen kann wann immer diese benötigt werden. Es ist ebenfalls mögliche die generierten Tests automatisiert durchzuführen, um so längere Prüfläufe zu absolvieren [15] Unterschiede zum sourcecodebasierten Testen Zwar beanspruchen sowohl das sourcecodebasierte, als auch das modellbasierte Testen den Vorteil der Wiederverwendbarkeit, auch im laufenden Entwicklungsprozess, für sich, jedoch wird, betrachtet man die Grundlage auf der die beiden Arten von Tests aufgebaut sind, relativ schnell deutlich, dass man beim sourcecodebasierten Testen recht schnell in Gefahr läuft den Überblick zu verlieren. Tests werden einmal verfasst und zu größeren Testsuites zusammengefasst. Mit steigender Komplexität eines SUT erhöht sich die Anzahl der Testsuites. Es ist jedoch klar, dass sich das (manuelle) Anpassen jeder einzelnen Testsuite bedeutend aufwändiger gestaltet, als ein paar Modelle anzupassen und sich sämtliche Testsuites neu und zu dem aktuellen Stand der Software passend, generieren zu lassen. Dies wird deutlicher, je größer die Änderung am System ist. Da die Generierung und Durchführung der modellbasierten Tests automatisiert und ohne personelle Betreuung erfolgen kann, spart dies Kosten und Zeit. Ein weiterer Unterschied liegt aber auch in den Vorausetzungen zum Testen. Beim sourcecodebasierten Testen kann nur getestet werden was bereits programmiert wurde. Das bedeutet, dass je weiter der Softwareentwicklungsprozess

26 22 M. Bickelmaier voranschreitet, auch immer neue Tests entstehen. Man wird quasi zu einem parallelen Vorgehen gezwungen. Beim modellbasierten Testen stehen jedoch bereits von Anfang an alle Modelle, bevor auch nur eine Zeile Sourcecode programmiert wurde. Das heißt, dass bereits in einer sehr frühen Phase des Entwicklungsprozesses das SUT auf seine gewünschten Eigenschaften getestet werden kann. Auf diese Weise lässt sich ein Design frühzeitig gegen die vorgegebene Spezifikation verifizieren. Findet man in dieser Phase des Entwicklungsprozesses bereits Fehler, die sonst erst wesentlich später entdeckt worden wären, lassen sich diese bedeutend kosteneffizienter und einfacher beseitigen. Ein weiterer Vorteil des modellbasierten Testens liegt darin, dass gleichzeitig ein Modell des erwarteten Nutzerverhaltens entsteht (siehe auch Kapitel 2.5.2). Mit beiden Untersuchungsmethoden steht ein wertvolles Werkzeug zum Nachweis der Funktion, insbesondere gegenüber Dritten und Kunden zur Verfügung. Sourcecodebasierte Tests beschränken sich meist auf die fehlerfreie Funktion einer Software. Modellbasierte Tests jedoch können zudem zertifizieren dass gegebene Spezifikationen eingehalten wurden. Abbildung 3. Ablauf eines Tests [10] 2.3 Ableiten von Testfällen aus statischen Modellen Statische Modelle beschreiben den grundsätzlichen Aufbau des SUT, sagen allerdings nichts über das Verhalten des SUT aus. Die statischen Modelle eignen

27 Grundlagen der modellbasierten Testfallgenerierung 23 sich deshalb vorrangig dazu Schwächen und Fehler in der Struktur eines SUT aufzudecken. Hier kann man also überprüfen ob ein SUT prinzipiell dem ersten Anschein nach eine Spezifikation erfüllt, bzw überhaupt erfüllen kann Klassendiagramm Klassendiagramme eignen sich besonders gut, um die theoretische Korrektheit eines SUT zu testen, da in ihnen sämtliche strukturellen Informationen des SUT festgehalten sind. Zu diesen Informationen gehören Abhängigkeitsklauseln zwischen Klassen. Diese Klauseln wiederum ermöglichen Tests der Initialisierbarkeit dieser Klassen. Assoziationen geben Aufschluss über Beziehungen zwischen Klassen und deren Realisierbarkeit. Besonders spannend sind die Schnittstelleninformationen eines SUT. Diese lassen beispielsweise Tests auf Existenz einzelner Methoden (Method-Coverage) und ihrer Sichtbarkeit zu. Dazu wird einfach versucht alle Methoden der Reihe nach aufzurufen [11]. 2.4 Ableiten von Testfällen aus dynamischen Modellen Dynamische Modelle haben gegenüber statischen Modellen den Vorteil, dass in ihnen, wie der Name schon sagt, Informationen über das dynamische Verhalten eines SUT festgehalten sind. Dies bietet die Möglichkeit Benutzerinteraktionen mit dem SUT zu simulieren und zu testen. Auf diese Weise erhält man einerseits Tests die besonders für Code- / Method- und Action-Coverage geeignet sind. Andererseits wird während dem Testen bereits auch schon das erwartete Benutzerverhalten simuliert und es können Schwachstellen oder Abweichungen im gewünschten Verhalten des SUT entdeckt werden. Es werden nun einige Verfahren vorgestellt wie aus unterschiedlichen Vertretern von dynamischen Modellen Testfälle generiert werden können Finite-State-Machine (FSM) Hier gibt es mehrere Möglichkeiten Tests abzuleiten. Je nachdem welche Ziele verfolgt werden bieten sich unterschiedliche Algorithmen zur Testfallgenerierung an. Das Ableiten von Testfällen aus FSM wird anhand eines simplen Telefonsystem veranschaulicht. Beispielsweise besteht die Möglichkeit eine Testsequenz abzuleiten, welche jede verfügbare Aktion in jedem Zustand mindestens einmal ausführt (Action Coverage). Tabelle 1 zeigt eine mögliche solche Testsequenz.

28 24 M. Bickelmaier Abbildung 4. FSM eines einfachen Telefonsystems [7] Aktion Zustand Aktion Zustand - Bereit Wählen / Gegenüber bereit Klingeln Abheben Freizeichen Gegenüber hebt ab Sprechen Wählen / Gegenüber belegt Belegt Gegenüber legt auf Freizeichen Auflegen Bereit Auflegen Bereit Abheben Freizeichen Abheben Freizeichen Wählen / Gegenüber bereit Klingeln Wählen / Gegenüber bereit Klingeln Auflegen Bereit Gegenüber hebt ab Sprechen Abheben Freizeichen Auflegen Bereit Tabelle 1. Test Sequenz zum erreichen von Action-Coverage [7]

29 Grundlagen der modellbasierten Testfallgenerierung 25 Betrachtet man einen Test als eine zusammenhängende Sequenz von Aktionen die jeweils im Zustand Bereit beginnen und enden, so sind in obiger Tabelle also vier Testfälle enthalten. Es ist durchaus möglich dass eine, durch einen anderen Algorithmus, abgeleitete Testsequenz aus mehr oder weniger solcher Einzeltests bestehen kann [10]. Ein Testfall sollte erwartete Ausgabewerte angeben, ebenso wie die Sequenz der Eingaben. Ginge man davon aus, dass dieses Telefonsystem so konfiguriert wäre, dass es selbst seine Zustände ausgibt, so bräuchte man in diesem Fall kein seperates Testorakel, da diese Funktion bereits die FSM übernehmen würde. Action-Coverage ist das einfachste zu testende Kriterium einer FSM. Ein weiteres wichtiges Kriterium ist das Switch-Coverage Kriterium. Dieses ist erfüllt wenn jedes Tupel von Aktionen (Aktion in den Zustand, Aktion aus dem Zustand) durch die Testsequenz überprüft wird. Eines dieser Tupel wäre beispielsweise: (Gegenüber hängt auf, Wählen / Gegenüber bereit). Dieses Tupel ist nicht in Tabelle 1 enhalten. Mithilfe von Switch-Coverage kann man unter anderem zeigen, dass ein System Deadlock frei ist. Genau wie bei Action-Coverage sind auch hier Testfälle nicht eindeutig bestimmt, je nachdem welche Pfadfindungsalgorithmen man verwendet [7] Sequenzdiagramm Sequenzdiagramme haben den Vorteil, dass in ihnen nicht nur Informationen über Methodenaufrufe festgehalten sind, sondern auch Interaktionen mit anderen Objekten. Ausserdem sind Sequenzdiagramme über, in OCL definierte, Bedingungen dahingehend erweiterbar, dass Objektzustände während der Laufzeit überprüft werden können [13]. Testfälle die aus Sequenzdiagrammen generiert werden spielen Schritte der Sequenzdiagramme ab. Sie vergleichen erhaltene Ergebnisse mit den Ergebnisse die in Sequenzdiagrammen enthalten sind oder mittels Testorakel generiert wurden. Um einen Testfall aus einem Sequenzdiagramm zu generieren, interpretiert man die Nachrichten des Sequenzdiagramms. Dabei werden Systemfunktionen, also vom Akteuer zum System gehende Nachrichten, zu Testschritten des Testfalls. Systemreaktionen, also vom System zum Akteur gehende Nachrichten, dienen dem Ergebnisabgleich und der Verifikation. Die interne Interaktion zwischen Subsystemen kann, abhängig von der Testtiefe, auf die gleiche Weise mit einbezogen werden [8].

30 26 M. Bickelmaier Abbildung 5. Testfallgenerierung aus Sequenzdiagrammen Aktivitätsdiagramm Die Pfade durch den Graphen des Aktivitätsdiagramms sind die einzelnen Testfälle. Welche Pfade gewählt werden wird durch das zu bestimmende Überdeckungskriterium bestimmt. Will man Method- Coverage testen, so wird man Graphen wählen, welche alle Zustände enthalten. Für Transition-Coverage hingegen wird man Graphen wählen die alle Pfade / Transitionen im Graphen enthalten. Wie schon in der FSM, so gibt es auch hier, abhängig vom Pfadfindungsalgorithmus, wieder sehr viele, unterschiedliche Testfälle. Auch hier werden, wie bei Sequenzdiagrammen, die Systemfunktionen wieder zu Testschritten. Die Ergebnisse von Systemreaktionen werden wiederum mit den erwarteten Ergebnissen verglichen. Aktivitätsdiagramme weisen eine Ähnlichkeit zur mathematischen Grundlage von Petrinetzen auf. Es ist also relativ einfach mit formalen Methoden bestimmte Eigenschaften zu validieren. Zu diesen zählen unter anderem Deadlock- Situationen, Abhängigkeiten, Vollständigkeiten und Zyklen [8].

31 Grundlagen der modellbasierten Testfallgenerierung Toolgestützes modellbasiertes Testen Toolgestütztes modellbasiertes Testen bietet weitere Vorteile. Dazu gehören die Bereitstellung von Informationen über die durchgeführten Tests und deren Ergebnisse in aufbereiteter Form. Durch eine automatisierte Durchführung können ausserdem Personalkosten gespart werden. Sie können ohne Aufsicht über Nacht laufen, oder parallel zum Entwicklungsprozess durchgeführt werden. Dies hat wiederum eine Zeitersparnise zur Folge. Die Algorithmen zur Testfallgenerierung können des weiteren teilweise sehr komplex sein (siehe 2.4.1). Dies kann bei einer manuellen Durchführung zu einer erhöhten Fehleranfälligkeit führen. Tools hingegen führen solche Tätigkeiten verlässlich und vollautomatisch durch. Hierbei gibt es auch die Möglichkeit Prüfprotokolle erstellen zu lassen, welche als Nachweise gegenüber Dritten (dem Kunden) als Zertifizierungswerkzeug dienen können Conformiq Qtronic Conformiq Qtronic von der Firma Conformiq Software Ltd ( wird als Plugin für die Entwicklungsumgebung Eclipse vertrieben. Es unterstützt sowohl das Einbinden bestehender Modelle, beispielsweise mit Rhapsody erzeugte UML Diagramme, als auch die Erstellung eigener Prüfmodelle. Conformiq Qtronic unterstützt den modellbasierten Testvorgang auf Basis von UML Diagrammen [5] sowie der Java Action Language. Conformiq Software Ltd vertreibt sowohl eine Version für Windows als auch eine für Linux.

32 28 M. Bickelmaier Abbildung 6. Anlegen einer State Machine Abbildung 7. Festlegen der Testziele

33 Grundlagen der modellbasierten Testfallgenerierung 29 Abbildung 8. Durchführen der Tests und Ausgabe der Ergebnisse Conformiq Qtronic ist kostenpflichtig, jedoch gibt es die Möglichkeit eine vergünstigte akademische Lizenz für eine nicht-kommerziellen Nutzung zu erwerben. Unabhängig davon besteht die Möglichkeit eine kostenfreie Testversion zu erhalten [9] ModelJUnit ModelJUnit (czt.sourceforge.net/modeljunit/) ist ein Testframework mit dem Ziel die Ideen von JUnit Tests in den Bereich des modellbasierten Testens zu übertragen. In ModelJUnit werden FSM oder EFSM als Javaklassen geschrieben. Aus diesen Klassen werden anschließend Tests generiert. ModelJUnit ist derzeit sowohl als jar-datei als auch als Eclipse-Plugin verfügbar. ModelJUnit ist kostenfrei von der Homepage der Entwickler herunterladbar. ModelJUnit kann Überdeckungskriterien testen, sowie deren Ergebnisse in ausgewerteter und roher Form ausgeben. Ein weiteres Feature von ModelJUnit ist die Ausgabe von.dot Dateien, welche mit Visualisierungstools wie zum Beispiel Graphviz ( grafisch ausgewertet werden können (siehe Abbildung 9) [6]. Nachfolgend wird am Beispiel der Handlungsabläufe an einem Snack-Automaten der Ablauf eines ModelJUnit Tests veranschaulicht. Der Automat unterstützt das Einwerfen von 25 und 50 Cent. Für den Kauf sind 100 Cent erforderlich.

34 30 M. Bickelmaier Abbildung 9. Der von ModelJUnit während des Testens erzeugte Graph import net.sourceforge.czt.modeljunit.*; public class VendingMachineModel implements FsmModel { private int state = 0; // 0..2 public VendingMachineModel() { state = 0; } public String getstate() { return String.valueOf(state); } public void reset(boolean testing) { state = 0; } public boolean vendguard() { return state == 100; } void vend() { state = 0; } public boolean coin25guard() { return state <= 75; } void coin25() { state += 25; } } public boolean coin50guard() { return state <= 50; } void coin50() { state += 50; } Abbildung 10. Anlegen einer FSM in ModelJUnit

35 Grundlagen der modellbasierten Testfallgenerierung 31 public static void main(string[] args) { Tester tester = new RandomTester(new VendingMachineModel()); tester.buildgraph(); ArrayList<CoverageMetric> metric = new ArrayList<CoverageMetric>(); metric.add(new ActionCoverage()); metric.add(new StateCoverage()); metric.add(new TransitionCoverage()); metric.add(new TransitionPairCoverage()); for (CoverageMetric cm : metric) { tester.addcoveragemetric(cm); } tester.addlistener("verbose"); tester.generate(20); System.out.println("Metrics Summary:"); for (CoverageMetric cm : metric) { tester.getmodel().printmessage(cm.getname() + " was " + cm); } GraphListener graphlistener = tester.getmodel().getgraphlistener(); graphlistener.printgraphdot("vending.dot"); System.out.println("Graph contains " + graphlistener.getgraph().numvertices() + " states and " + graphlistener.getgraph().numedges() + " transitions."); } Abbildung 11. Testen einer FSM in ModelJUnit

36 32 M. Bickelmaier done (0, coin50, 50) done (50, coin25, 75) done (75, coin25, 100) done Random reset(true) done (0, coin50, 50) done (50, coin25, 75) done (75, coin25, 100) done (100, vend, 0) done (0, coin50, 50) done (50, coin50, 100) done (100, vend, 0) done (0, coin25, 25) done (25, coin25, 50) done Random reset(true) done (0, coin50, 50) done (50, coin25, 75) done (75, coin25, 100) done (100, vend, 0) done (0, coin50, 50) done (50, coin25, 75) ================================== Metrics Summary: action coverage was 3/3 state coverage was 5/5 transition coverage was 7/8 transition-pair coverage was 8/12 ================================== Graph contains 5 states and 8 transitions. Abbildung 12. Ergebnis des ModelJUnit Tests

37 Grundlagen der modellbasierten Testfallgenerierung 33 3 Ergebnisse In der Betrachtung zeigten sich wichtige Vorteile der Methode des modellbasierten Testens im Vergleich zur Alternative des sourcecodebasierten Testen. Bei der Erstellung komplexer Softwarelösungen ist es immer das Ziel etwaige Programmfehler in der neuen Software so früh wie möglich zu erkennen. Die Prüfung soll dabei durch übersichtliche und klar strukturierte Testmodelle vorgenommen werden und nach Möglichkeit bereits erste Nachweise für die Erfüllung der Spezifikation gegenüber dem Auftraggeber liefern. Hier zeigten sich die Stärken des modellbasierten Testens. Auf dem Markt befinden sich bereits geeignete Softwaretools, die das Erstellen von modellbasierten Tests unterstützen. Die Testsuites lassen sich damit relativ einfach aus den Designdiagrammen generieren. Das hat den Vorteil, dass man auch dem Auftraggeber gegenüber, relativ früh das spätere Funktionsverhalten modellieren und simulieren kann. Aus diesem Grund sollte das Verfahren des modellbasierten Testens in jedem umfangreicheren Softwareprojekt eingesetzt werden. Literatur [1] [2] [3] [4] [5] [6] marku/mbt/modeljunit/. [7] Software acquisition gold practice: Model-based testing. Software Acquisition Gold Practice, [8] T. Q. Benjamin Wilmes, Natalia Freijnik. Modellbasiertes testen (ableiten von tests aus anwendungsfällen, aktivitätsdiagrammen und statecharts), klassifikationsbaummethode, testwerkzeuge. Technical report, TU Berlin, [9] Conformiq Ltd. Conformiq Qtronic - Automate Test Design. [10] I. K. El-Far and J. A. Whittaker. Model-based software testing. Technical report, Florida Institute of Technology, [11] M. Köhler. Uml-basiertes testen. Technical report, Eberhard-Karls-Universität Tübingen, [12] S. Lawalata. Study literature of model-based testing for test integrity. Technical report, TU Hamburg Harburg, [13] B. Rumpe. Model-based testing of object-oriented systems. Technical report, IRISA-Université de Rennes, TU München. [14] J. Tulach. Practical API Design - Confessions of a Java Framework Architect. Apress, [15] M. Utting. Position paper: Model-based testing. Technical report, University of Waikato, [16] F. Westphal. Extreme programmer, unit tests mit junit. FrankWestphal.de,

38 Evaluierung der Potentiale des Eclipse Process Frameworks Robert Freudenreich Universität Augsburg Zusammenfassung Diese Seminararbeit evaluiert die Potentiale des Eclipse Process Framework. Es wird zunächst auf die Entwicklungsprozesse RUP, Scrum und OpenUP eingegangen sowie das Metamodell UMA und der EPF Composer thematisiert. Es folgt eine Erörterung der Anwendungsgebiete und Best Practices bevor mit einer prototypischen Implementierung die Erweiterbarkeit des EPF demonstriert wird. 1 Einleitung Als es noch keine Rechner gab, war auch das Programmieren noch kein Problem, als es dann ein paar leistungsschwache Rechner gab, war das Programmieren ein kleines Problem und nun, wo wir gigantische Rechner haben, ist auch das Programmieren zu einem gigantischen Problem geworden. Dieses Zitat von Edsger Dijkstra [1] beschreibt mit einfachen Worten die Explosion der Komplexität der Softwareentwicklung, der sich die Softwareindustrie durch die Dynamik der Hardware-Entwicklung, die zunehmende Zerstreuung der Entwicklungsteams sowie immer komplexeren und integrierteren Software- Systemen ausgesetzt ist. In [8] wird diese Explosion mit dem Faktor 50 innerhalb von 10 Jahren quantifiziert. Um diese Komplexität beherrschen zu können, werden Softwareentwicklungsprozesse eingesetzt. 2 Softwareentwicklungsprozesse Liggesmeyer beschreibt einen Softwareentwicklungsprozess in [11] als eine zielorientierte Aktivität zur Erzeugung eines Produktes oder zur Durchführung einer anderen Aufgabe im Rahmen der ingenieurmäßigen Softwareentwicklung. Die Grundlage für solche Prozesse sind Vorgehensmodelle, mit deren Entwicklung sich die Disziplin des Software-Engineering befasst. Dabei unterscheidet man klassische schwergewichtige und agile leichtgewichtige Vorgehensmodelle. Klassische Vorgehensmodelle eignen sich für große Entwicklungsprojekte und sind eher statisch und dokumentationslastig - Beispiele sind das Wasserfallmodell, V-Modell oder der Rational Unified Process. Agile Vorgehensmodelle eignen sich hingegen für kleinere und mittlere Entwicklungsprojekte und sind eher flexibel und anpassungsfähig - Beispiele sind Extreme Programming, Scrum und der Open Unified Process.

39 Evaluierung der Potentiale des EPF Rational Unified Process Der Rational Unified Process (RUP) ist ein iteratives und inkrementelles, aber dennoch klassisches Vorgehensmodell, das Anwendungsfall- und Architekturgetrieben ist. Es verwendet als Sprache die Unified Modeling Language (UML) und basiert auf diversen Erfahrungen der Softwareentwicklung, die sich in den folgenden sechs Software Best Practices wiederspiegeln: 1. Iterative Software-Entwicklung 2. Anforderungsmanagement 3. Verwendung komponentenbasierter Architekturen 4. Visuelle Software-Modellierung 5. Prüfung der Software-Qualität 6. Kontrolliertes Änderungsmanagement Der Lebenszyklus des RUP besteht aus vier Phasen 1, welche wiederum in Iterationen unterteilt sind und an deren Ende jeweils ein Meilenstein erreicht wird. Aufgaben innerhalb einer Iteration sind sechs Kern-Workflows 2 und drei unterstützenden Workflows 3 zugeordnet, die in jeder Iteration unterschiedlich intensiv angewandt werden. Abbildung 1 veranschaulicht diese Zusammenhänge. Abbildung 1. Workflows und Phasen des Rational Unified Process [10] 1 Inception, Elaboration, Construction und Transition 2 Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment 3 Configuration & Change Management, Project Management und Environment

40 36 R. Freudenreich 2.2 Scrum Scrum ist ein agiles Vorgehensmodell mit kurzen, iterativen Entwicklungszyklen, das von Ken Schwaber, Jeff Sutherland und Mike Beedle erfunden wurde. Die Grundlage für agile Vorgehensmodelle ist die Annahme, dass ein Softwareentwicklungsprozess zu komplex ist, als dass er sich weder im Voraus in unabhängige Stufen, noch in detaillierte Arbeitsschritte planen lässt. Agile Vorgehensmodelle sind daher sehr flexibel um gut auf Änderungen reagieren zu können. Scrum definiert nur wenige Rollen 4 und Artefakte. Das Product Backlog 5, wird zu Beginn des Prozesses initial gefüllt und vom Product Owner priorisiert. Für jeden Sprint 6 wird ein Sprint Backlog mit den Anforderungen erstellt, die dabei umgesetzt werden sollen. Das Team organisiert sich innerhalb des Sprints selbst und das Ergebnis soll ein lauffähiges Inkrement der Software sein. Abbildung 2 stellt diesen Prozess als Diagramm dar. Abbildung 2. Der Scrum Prozess 2.3 OpenUP A couple of years ago, several colleagues and I started to think about how you could create a stripped-down version of the Rational Unified Process reflecting an agile approach to using RUP, while at the same time leverage all the good things we liked in other agile processes, such as Scrum and XP. 4 Product Owner, Team und Scrum Master 5 Das Product Backlog enthält die Anforderungen an das Produkt 6 Bezeichnet eine Iteration mit einer Dauer von ca. 30 Tagen

41 Evaluierung der Potentiale des EPF 37 Diese Aussage von Per Kroll [9], Projektleiter des Eclipse Process Framework, beschreibt die Motivation hinter der Entwicklung des Open Unified Process (OpenUP). Es handelt sich dabei um ein agiles, iteratives Vorgehensmodell, das an den Rational Unified Process angelehnt ist und dessen grundlegende Charakteristika, u.a. Anwendungsfälle und ein architekturgetriebenes Vorgehen, einhält. Im Gegensatz zu diesem ist OpenUP aber ein minimaler Prozess, der nur grundlegende Inhalte enthält und auf viele weiterführende Themen verzichtet und sich daher vor allem für kleine Projekte eignet. OpenUP ist aber auch ein vollständiger und erweiterbarer Prozess, so dass er als Grundlage für andere Prozesse dienen kann, um ebenfalls höhere Anforderungen erfüllen zu können. OpenUP ist Open Source und basiert auf den folgenden Kernprinzipien, die sich am Agilen Manifest [18] orientieren: 1. Collaborate to align interests and share understanding 2. Balance competing priorities to maximize stakeholder value 3. Focus on the architecture early to minimize risks and organize development 4. Evolve to continuously obtain feedback and improve Abbildung 3. Ebenen des OpenUP [9]

42 38 R. Freudenreich OpenUP definiert sowohl Rollen, Aufgaben und Artefakte als auch Ebenen, die verschiedene Sichten mit einem unterschiedlichen Detailgrad auf das Projekt ermöglichen. Die Ebene des Projektlebenszyklus ähnelt dem Lebenszyklus des RUP und ermöglicht den Stakeholdern und Teammitgliedern einen effektiven Überblick über das Projekt. Er besteht aus den selben Phasen wie RUP, wird im Project Plan definiert und das Ergebnis ist eine freigabefähige Anwendung. Jede Phase besteht aus einer oder mehreren Iterationen, die ein funktionierendes Softwareinkrement hervorbringen und in der Ebene des Iterationslebenszyklus abgebildet sind. Das Team organisiert sich dabei selbst und verpflichtet sich auf den Iteration Plan, der festlegt, was in der Iteration geliefert werden soll. Die Ebene des Mikroinkrements befasst sich mit kleinen Arbeitseinheiten, die einen steten und messbaren Beitrag zum Projekterfolg leisten und typischerweise in einigen Stunden bis Tagen abgearbeitet werden können. Abbildung 3 veranschaulicht dies. 2.4 Vorteile Modellbasierter Unterstützung Lee Osterweil schrieb bereits im Jahr 1987: Software processes are software, too [16]. In der Tat ist ein Entwicklungsprozess im Grunde ein Programm, das von den Projektmitgliedern ausgeführt wird. Ein Prozess an sich ist abstrakt und schwer zu fassen. Durch das Erstellen eines Modells wird ein Prozess greifbar und dies ist Voraussetzung für das Verstehen, Analysieren, Ausführen und Lernen eines Prozesses. Die Formalisierung und Modellierung eines Entwicklungsprozesses bietet daher viele Vorteile. Henderson-Sellers führt in [5] u.a. an, dass dadurch ein konsistenter, reproduzierbarer Ansatz für die Entwicklung von Software sichergestellt wird und die Unzulänglichkeit und Unvollkommenheit eines Ad-hoc- Prozesses beseitigt wird. Desweiteren nennt er in diesem Zusammenhang, dass die Komplexität der heutigen Anforderungen verringert wird und die enorme Größe durch Dekomposition in handhabbare Teile gemeistert werden kann. Weitere Vorteile eines modellierten Entwicklungsprozesses sind verringerte Abhängigkeiten von Personen, Vergleichbarkeit mit anderen Entwicklungsprozessen, bessere Projektplanung und -controlling sowie einfachere Kommunikation der beteiligten Personen (intern und extern) untereinander, da eine gemeinsame Spache vorhanden ist. Trotz all dieser Vorteile, die mit Sicherheit überwiegen, gibt es in Verbindung mit der Prozessmodellierung auch einige wenige Nachteile. Dazu gehört, dass diese die Kreativität der Softwareentwicklung einschränken können und Neuerungen in der Softwareentwicklung langsamer übernommen werden können. Ein weiterer Punkt, dem Beachtung geschenkt werden muss, ist der Aufwand für die Erstellung und die Weiterentwicklung des Modells. 3 Eclipse Process Framework Projekte haben heute eine große Auswahl an unterschiedlichen Softwareentwicklungsprozessen. Am besten geeignet wäre jedoch oft eine Kombination ver-

43 Evaluierung der Potentiale des EPF 39 schiedener Prozesse oder eine angepasste Version eines bestehenden Prozesses. Durch die unterschiedlichen Metamodelle der verschiedenen Vorgehensmodelle ist dies allerdings nahezu unmöglich, bzw. mit einem sehr hohen Aufwand verbunden. Eine Lösung für dieses Problem ist das Eclipse Process Framework (EPF), ein erweiterbares Open Source Prozess-Framework unter dem Dach der Eclipse Foundation, dessen Ziel ein offenes und kollaboratives Ecosystem für die Entwicklung von Softwareentwicklungsprozessen ist. Dazu stellt des EPF mit UMA ein Metamodell, mit dem EPF-Composer ein Entwicklungswerkzeug und Entwicklungsprozesse wie OpenUP bereit. Abbildung 4 stellt dieses Ecosystem dar. Abbildung 4. Ecosystem des Eclipse Process Framework [3] 3.1 Unified Method Architecture Die Unified Method Architecture (UMA) ist eine Evolution des Software Process Engineering Metamodel (SPEM) 1.1, das von der Object Management Group (OMG) spezifiziert wurde um einen Metamodell-Standard für Vorhergehensmodelle in der Softwareentwicklung zu schaffen [13]. Im Mai 2005 reichte IBM zusammen mit anderen Firmen 7 bei der OMG einen Vorschlag auf Grundlage der UMA für den offiziellen Nachfolger der SPEM 1.1 ein [12]. Die aktuelle, noch in der Entwicklung befindliche Version von SPEM 2.0 basiert zum großen Teil 7 Adaptive Ltd., Fujitsu, Fundacion European Software Institue, Osellus Inc., Softeam

44 40 R. Freudenreich auf diesem Vorschlag und wird derzeit noch an die Bedürfnisse anderer OMG- Mitglieder angepasst [15]. Das Eclipse Process Framework unterstützt derzeit die UMA und erste Teile von SPEM 2.0, wobei die volle Unterstützung von SPEM 2.0 nach deren Verabschiedung als Standard geplant ist. Abbildung 5. Trennung von Method Content und Process Eine wesentliche konzeptionelle Eigenschaft der UMA ist die Trennung von Method Content (Methodeninhalt) und Process (Prozess), die in Abbildung 5 graphisch darstellt ist. Im Method Content werden wiederverwendbare Work Products (Arbeitsergebnisse), Tasks (Aufgaben), Roles (Rollen) und Guidances (Anleitungen) definiert, die beschreiben, wie gewisse Entwicklungsziele erreicht werden. Ein Prozess verwendet den Method Content in einer spezifischen Reihenfolge, so dass die speziellen Eigenheiten eines Projekts abgebildet werden. Diese Trennung ermöglicht eine hohe Wiederverwendbarkeit und Anpassbarkeit, da ein allgemeiner, prozessübergreifender Method Content definiert wird, der in verschiedenen Prozessen unterschiedlich verwendet werden kann. Um diese Eigenschaften auch für Bestandteile eines Prozesses zu erreichen, gibt es neben Delivery Processes (Bereitstellungsprozessen) sogenannte Capability Patterns (Prozessmuster), bei denen es sich um wiederverwendbare Prozessbausteine handelt. Beispiel Die Aufgabe Anforderungsanalyse wird im Method Content mit den beteiligten Rollen und Artefakten definiert. In einem agilen Prozess wird diese Aufgabe mehrmals in den einzelnen Iterationen durchgeführt, wohingegen ein anderer Prozess nach dem Wasserfallmodell diese Aufgabe nur genau einmal am Anfang spezifiziert. Neue Erkenntnisse zu dieser Aufgabe können zentral im Method Content ergänzt werden und die Prozesse werden automatisch aktualisiert. UMA definiert eine Method Library (Methodenbibliothek) als Container für Method Plug-Ins (Methoden-Plug-Ins), die den Method Content und die Prozesse

45 Evaluierung der Potentiale des EPF 41 enthalten. Ein Method Plug-In ist in Packages (Pakete) unterteilt und kann andere Method Plug-Ins referenzieren um deren Elemente verwenden zu können. Das Konzept der Variability (Variabilität) entspricht in ungefähr der objektorientierten Vererbung und ermöglicht die Erweiterung von Elementen. Auf dieses Konzept wird genauer im Kapitel Variability eingegangen. 3.2 EPF Composer Der Eclipse Process Framework Composer (EPF Composer) ist ein Open Source Autorenwerkzeug für das Erfassen und Veröffentlichen von Prozessen, das im Rahmen des EPF entwickelt wurde. Er implementiert in der aktuellen Version 1.5 als Metamodell sowohl die UMA als auch bereits erste Teile von SPEM 2.0. Abbildung 6. Benutzeroberfläche des EPF Composer Abbildung 6 zeigt die Benutzeroberfläche des EPF Composers in der ein Teil des OpenUP zu sehen ist. Die Benutzeroberfläche ist in die Bereiche Library (Bibliothek), Configuration (Konfiguration) und Editor unterteilt. Die Library enthält die Method Library mit den Method Plug-Ins und die Sicht entspricht deren physischen Struktur inklusive der Trennung zwischen Method Content und Process. Die aktuelle Konfiguration, die eine logische Teilmenge der Method Library ist und durch das Auswählen von Method Content Packages und Prozessen

46 42 R. Freudenreich entsteht, wird darunter angezeigt. Der Editor-Bereich dient dem Bearbeiten aller Elemente. Die Implementierung des EPF Composer ist Java-basiert und baut auf der Eclise Rich Client Plattform sowie den Projekten Graphical Editing Framework (GEF) 8, JTidy 9 und International Components for Unicode for Java (ICU4J) 10 auf. Eine weitere wichtige Komponente ist das Eclipse Modeling Framework (EMF) 11, das für die auf dem Metamodell basierende Generierung der entsprechenden Klassen und des zugehörigen Codes sowie für die Persistenz der Method Library in XMI Dateien benötigt wird. Abbildung 7 veranschaulicht diese Architektur. Abbildung 7. Architektur des EPF Composer [2] Für die Veröffentlichung der erstellten Inhalte generiert der EPF Composer eine Webseite nach dem DHTML-Standard, so dass ein einheitlicher Zugriff (z.b. über das Intranet) auf die Informationen von verschiedensten Endgeräten aus möglich ist. Zusätzlich ist ein Export nach XML und Microsoft Project möglich. 4 Anwendbarkeit des EPF Für die Aktzeptanz in der Industrie ist die Anwendbarkeit des EPF ein entscheidendes Kriterium. Interessante Fragestellungen dazu sind, in welchen Bereichen 8 Ein Framework für die Entwicklung von graphischen Editoren und Diagrammen 9 Ein Syntaxprüfer und Pretty Printer für HTML 10 Eine Java Bibliothek für Unicodeunterstützung 11 Ein Modellierungs- und Codeerzeugungsframework für strukturierte Datenmodelle

47 Evaluierung der Potentiale des EPF 43 das EPF eingesetzt werden kann, wie gut die Dokumentation für Anwender ist und welche Best Practices für den Umgang mit dem EPF Composer bekannt sind. 4.1 Anwendungsgebiete Das Ziel des EPF darin liegt ein erweiterbares Framework sowie exemplarische Werkzeuge und Inhalte für das Entwickeln von Softwareentwicklungsprozessen bereitzustellen. Daher liegt in der Domäne der Softwareentwicklung auch dessen Hauptanwendungsgebiet. Neben OpenUP wurden einige andere Entwicklungsprozesse bzw. -ansätze bereits prototypisch oder auch vollständig modelliert. Dazu zählen u.a. Scrum, Extreme Programming, Rational Unified Process, Microsoft Solution Framework und Model Driven Architecture. [14] Doch obwohl das EPF in der o.g. Domäne seine Wurzeln hat, ist sein Anwendungsgebiet nicht auf diese beschränkt. UMA bzw. SPEM 2.0 definieren lediglich ein grundlegendes und allgemeingültiges Gerüst für die Modellierung von Prozessen, z.b. dass diese durch Phasen und Aufgaben beschrieben werden, in denen Rollen Arbeitsergebnisse erstellen können. Theoretisch werden damit die unterschiedlichsten Domänen abgedeckt. In der Praxis wurde dies bereits durch einige Fallstudien bewiesen, in denen Prozesse mit dem EPF modelliert wurden, die mit der Softwareentwicklung nichts zu tun haben. Ein Beispiel für weitere Anwendungsgebiete des EPF sind Managementmethoden. Neben dem Tivoli Unified Process (ITIL) wurde in dieser Domäne u.a. auch die SOA Governance Lifecycle and Management Method, die IBM World Wide Project Management Method und die IBM Global Services Method erfolgreich modelliert. Beispiele für hardwarenahe Prozesse sind die Application Specific Integrated Circuits Method und der Ericsson s Product Lifecycle Management Process. Auch die Implementierung des Money-Lover-Prozesses für Investement Clubs zeigt, dass sich das EPF nicht auf einzelne Domänen beschränkt, sondern sich für die verschiedensten Bereiche und Branchen eignet. [14] 4.2 Anwenderdokumentation Eine gute Dokumentation für Anwender ist eine Bedingung, dass eine Software in Unternehmen eingesetzt wird und das EPF erfüllt diese Anforderung voll und ganz. Neben einem Wiki 12 bietet die EPF-Webseite eine Getting Started - Seite 13 auf der man anhand von Dokumenten, Tutorials, Präsentationen und auch Screencasts einen guten Überblick und viele Informationen über das EPF und den EPF Composer bekommt. Hervorzuheben ist vor allem die sehr gute integrierte Hilfe des EPF Composers. Neben einer detaillierten und ausführlichen Dokumentation des Programms enthält sie gut ausgearbeitete Tutorials mit

48 44 R. Freudenreich Schritt-für-Schritt-Anleitungen, die einen einfachen Einstieg in das Programm ermöglichen. Für den Fall dass die vorhandene Dokumentation für manche Probleme nicht ausreicht, gibt es eine Newsgroup 14, in der weiterführende Fragen u.a. direkt von den EPF-Verantwortlichen beantwortet werden. 4.3 Best Practices In diesem Kapitel werden zwei wesentliche Best Practices beschrieben, die die Potentiale des EPF Composer in der täglichen Arbeit ausnutzen können Synchronisation Aufgrund der Tatsache, dass der Method Content in Prozessen referenziert wird und um die Inhalte iterativ und von mehreren Personen entwickeln zu können, besitzt der EPF Composer einen Synchronisation- Mechanismus für Descriptoren. Descriptoren sind Referenzobjekte, die Elemente des Methode Content (z.b. einen Task) in einem Prozess referenzieren. Durch Drag-and-Drop eines Tasks kann dieser einem Prozess hinzugefügt werden. Anstatt dabei jedoch den Task zu kopieren, erstellt der EPF Composer einen Task Descriptor, der auf den Task im Method Content referenziert. Zusätzlich zur Referenz hat ein Descriptor eigene Beziehungs- und Dokumentationseigenschaften anhand derer das entsprechende Element an dieser speziellen Position im Prozess vom Original im Method Content abweichen kann. Abbildung 8. Task Descriptor Neben einer Standard-Synchronisation, die alle Eigenschaften eines Elementes angleicht, existiert eine benutzerdefinierte Synchronisation, in der die anzugleichenden Eigenschaften ausgewählt werden können. Die Synchronisationsrichtung 14 news://news.eclipse.org/eclipse.technology.epf epf

49 Evaluierung der Potentiale des EPF 45 erfolgt dabei immer vom Method Content zum Descriptor. Eine Synchronisierung in die andere Richtung existiert hingegen nicht, so dass Änderungen an Descriptoren nicht automatisch auf Elemente des Method Content übertragen werden können. Beim Authoring ist daher darauf zu achten, dass globale Änderungen am Method Content und nicht an den Descriptoren im Prozess vorgenommen werden. Eine Synchronisierungsmöglichkeit für Capability Patters und Delivery Processes ist nicht vorhanden. Für die Verwendung von Patterns in einen Delivery Process können diese entweder ohne Verbindung zum Original Pattern kopiert oder dynamisch eingebunden werden, so dass es das Original Pattern erweitert und Änderungen an diesem automatisch übernommen werden. Im Delivery Process kann das Pattern dann durch das Hinzufügen oder Unterdrücken von Elementen erweitert werden. Das Ändern von bestehenden Elementen des dynamisch eingebunden Patterns ist im Delivery Process nicht möglich Variability Ein wichtiges Konzept der Wiederverwendbarkeit und Anpassbarkeit ist die Method Content Variability (Variabilität). Diese ermöglicht die Erweiterung von Elementen und entspricht in ungefähr der objektorientierten Vererbung. D.h. ein Element kann ein anderes Element auf verschiedene Art und Weisen erweitern. Dabei wird das Original nicht verändert, sondern als Grundlage für neue Inhalte verwendet. Variability ermöglicht somit auch das Erstellen von Method Plug-Ins, die andere Method Plug-Ins erweitern. Eine Anwendungsmöglichkeit dieses Mechanismus liegt darin, eine vorhandene Basismethode (z.b. OpenUP) an die eigenen Bedürfnisse anzupassen ohne das Method Plug-In der Basismethode selbst zu verändern. Da die Änderungen lediglich im neuen Method Plug-In vorgenommen werden, kann die Basismethode mit wenig Aufwand und ohne den Verlust der eigenen Änderungen aktualisiert werden, sobald eine neue Version veröffentlicht wird. Es existieren die folgenden vier Arten der Method Content Variability um ein vorhandenes Element (Original) durch ein neues Element (Erweiterung) anzupassen: Contribute Die Inhalte der Erweiterung werden in das Original übernommen und an das Ende der dortigen Inhalte angehängt. Die veröffentlichte HTML- Webseite enthält nur das Original. Extend Die Erweiterung enthält die eigenen Inhalte und erbt alle Inhalte des Originals, die es nicht selbst definiert. Die HTML-Webseite enthält sowohl das Original als auch die Erweiterung. Replace Die Erweiterung ersetzt das Original. Alle anderen Elemente, die vorher das Original referenzierten, zeigen nun auf die Erweiterung. Die HTML-Webseite enthält nur die Erweiterung. Extend and Replace Die Erweiterung enthält die eigenen Inhalte und erbt alle Inhalte des Originals, die es nicht selbst definiert. Das Original wird von der Erweiterung ersetzt und die Referenzierungen auf die Erweiterung geändert. Die HTML-Webseite enthält nur die Erweiterung.

50 46 R. Freudenreich Abbildung 9. Variability eines Tasks Verwendung eines Versionsverwaltungssystems Der EPF Composer speichert alle Daten in XMI-Dateien, die auf dem XML-Format basieren, so dass bei der Entwicklung der Inhalte ein Versionskontrollsystem eingesetzt werden kann, dessen Vorteile in [19] beschrieben sind. Der EPF Composer unterstützt von Haus aus IBM Rational ClearCase und das Concurrent Versions System (CVS), aber auch andere Versionskontrollsysteme (z.b. Subversion) können verwendet werden. Dabei ist darauf zu achten, dass bereits relativ geringe Änderungen im EPF Composer mehrere Dateien betreffen können. Eine Datei sollte dabei aber nicht parallel bearbeitet werden, weil ein Merge der XMI Dateien möglichst zu vermeiden ist. Dateisperren (Locks) sind dafür gut geeignet und sollten verwendet werden. Da die Datei plugin.xmi eines Methoden Plug-Ins bei vielen Änderungen betroffen ist, empfiehlt es sich den Inhalt auf verschiedene Method Plug-Ins aufzuteilen. Pro Method Plug-In sollte eine Person die Rolle des Method Designer übernehmen und zu Beginn einen Method Sketch erstellen, um spätere strukturelle Veränderungen der XMI Dateien zu minimieren [17]. Beim Authoring ist häufiges Committen hilfreich um eine Korruption des Repositorys zu vermeiden. Treten dabei trotz Dateisperren Konflikte auf, sollte die Verantwortung für deren Beseitigung beim Method Designer liegen. Weitere hilfreiche Informationen enthält [7]. 5 Erweiterbarkeit des EPF Eine der wichtigsten Eigenschaften des EPF ist die Tatsache, dass es sich um ein Open Source Projekt handelt. Die zahlreichen Vorteile von Open Source gelten somit auch für das EPF. Einer der entscheidenden Vorteile ist dabei die freie

51 Evaluierung der Potentiale des EPF 47 Verfügbarkeit des Quelltextes des EPF Composer und die daraus resultierende Möglichkeit, dass jeder den EPF Composer weiterentwickeln und an die eigenen Bedürfnisse anpassen kann. Dies eröffnet vollkommen neue Möglichkeiten, die proprietären Alternativen vorenthalten sind. 5.1 Entwicklerdokumentation So gut die Dokumentation für Anwender ist, so schlecht ist die Dokumentation für Entwickler. Sie ist nur spärlich vorhanden, über verschiedenste Dokumente verteilt und teilweise nicht aktuell. Die zentrale Anlaufstelle bietet die Developers Resources Webseite 15, auf der u.a. die beiden wichtigsten Dokumente verlinkt sind. Diese sind der EPF Composer Architecture Overview 16 und der EPF Composer Development Guide 17. Der Development Guide enthält allerdings lediglich eine Anleitung wie die Eclipse IDE einzurichten ist, um mit dem Quelltext des EPF Composers zu arbeiten. Diese Anleitung ist dafür aber sehr gut und detailliert. Weiterführende Informationen (z.b. Tutorials, How-Tos, etc.) sind nicht vorhanden. Auch die Dokumentation des Quelltextes ist schlecht und nur in begrenztem Umfang umgesetzt. Das entsprechende Javadoc 18 ist daher nur schlecht zu gebrauchen. Die Hürde für die Einarbeitung in den Quelltext des EPF Composers ist dadurch hoch und erfordert eine Menge Geduld. Aufgrund dieses Umstands kann der EPF Composer einen seiner größten Trümpfe gegenüber propietären Konkurrenzprodukten leider nur begrenzt ausspielen - die freie Verfügbarkeit des Quelltextes und der damit einhergehenden Möglichkeit für Entwickler weltweit den EPF Composer an eigene Bedürfnisse anzupassen und weiterzuentwickeln. 5.2 Extension Point Mechanismus Der EPF Composer basiert auf der Eclipse Rich Client Plattform (RCP) mit seiner Plug-In Architektur, dessen Kern der Extension Point Mechanismus darstellt. Ein Extension Point stellt eine definierte Schnittstelle bereit, um ein Plug-In zu erweitern. Eine Extension kann an einem solchen Extension Point ansetzen um dem Plug-In zusätzliche Funktionalität bereitzustellen. Ein Beispiel für diesen Mechanismus ist ein -Programm das einen Extension Point für zusätzliche Spam-Filter definiert, die von Extensions bereitgestellt werden. Auch die Plug-Ins des EPF Composer bieten diverse Extension Points an. Eine Besonderheit ist die im Gegensatz zur objektorientierten Vererbung gegenläufige Nutzungs- und Abhängigkeitsrichtung. Ein Extension Point nutzt eine Extension, ist aber gemäß dem Hollywood-Prinzip We call you, don t call us nicht von dieser abhängig

52 48 R. Freudenreich Abbildung 10. Extension Point-Mechanismus 5.3 Fallbeispiel Prozess ausführen Im Rahmen dieser Arbeit sollte eine prototypische Erweiterung des EPF Composers als Fallbeispiel implementiert werden. Diese Erweiterung sollte untersuchen ob und wie es möglich ist, einen Prozess nicht nur als HTML-Webseite anschauen zu können, sondern diesen im weitesten Sinne ausführen zu können. D.h. dass ein Benutzer direkt aus der Prozessdokumentation heraus eine bestimmte Anwendung starten kann, um ein Artefakt zu erstellen, das in diesem Prozessschritt benötigt wird Möglichkeiten des EPF Der EPF Composer kann diese Anforderung bereits ohne Erweiterung mit gewissen Einschränkungen erfüllen. Es existiert der Guidance-Typ Template, in dem eine Vorlage für Work Products definiert werden kann. Ein Template kann beschreibenden Text und angefügte Dateien enthalten. Die Dateien werden in das Method Plug-In importiert und dort gespeichert. Beim Veröffentlichen der Methode werden die angefügten Dateien in die Dateistruktur der HTML-Webseite übernommen und können von der entsprechenden Template- Seite heruntergeladen werden. Moderne Browser bieten die Möglichkeit, Dateien direkt zu öffnen ohne diese explizit speichern zu müssen, so dass direkt die mit dem Dateityp assoziierte Anwendung startet und die Datei darin geöffnet wird. Abbildung 11 zeigt ein Artefakt mit zugehörigem Template. Diese Vorgehensweise hat mehrere Nachteile. Da die Anwendung durch das Öffnen einer Datei gestartet wird, muss eine Verknüpfung von Dateityp und Anwendung vorhanden sein. Dies kann zu Problemen führen, weil manche Anwendungen mit keinerlei Dateityp verknüpft sind oder ein Dateityp standardmäßig mit einer anderen Anwendung verknüpft ist Erweiterung des EPF Aufgrund der freien Verfügbarkeit des Quellcodes des EPF Composer kann die Erweiterung selbst implementiert werden. Ziel der Erweiterung ist ein neues Attribut für Artefakte, in dem der Pfad der Anwendung gespeichert wird. Für die Implementierung der Erweiterung sind die folgenden Schritte notwendig: Erweiterung des Metamodells, Programmierung des Authoring Plug-Ins und Änderung der XSL Dateien.

53 Evaluierung der Potentiale des EPF 49 Abbildung 11. Artefakt mit zugehörigem Template Erweiterung des Metamodells Grundlage für die Entwicklung der Erweiterung ist das UMA Metamodell und dessen Implementierung mit dem EMF. Da diese kein Attribut für den Anwendungspfad definiert, muss dieses in der Datei uma.ecore im Verzeichnis model/1.0.5 des Packets org.eclipse.epf.uma hinzugefügt werden. Dies geschieht über den Eintrag New Child EAttribute im Kontextmenü des ArtifactDescription-Elements, wobei die Eigenschaften des neuen Attributs noch bearbeitet werden müssen (EAttributeType soll vom Typ String und der Name soll apppath sein). Nach dem Speichern werden über das Kontextmenü der Datei uma.genmodel im selben Verzeichnis die Klassen und der dazugehörige Code generiert (Eintrag Generate Model Code). Programmierung des Authoring Plug-Ins Der nächste Schritt besteht nun darin einen neuen Bereich im Artefakt-Editor zu erstellen, damit beim Authoring der Anwendungspfad angegeben werden kann. Da der EPF Composer hierfür keinerlei Automatismus besitzt, muss der Quelltext selbst erstellt werden. Anstatt das Plug-In org.eclipse.epf.authoring.ui zu verändern, bietet es sich an, dessen Extension Point descriptionpagesectionprovider für ein eigenes Plug-In zu erweitern. Die Klasse DescriptionFormPageApplicationSection im neuen Plug-In de.uniaugsburg.epf.authoring.ui muss dafür das Interface ISectionProvider und im speziellen dessen Methode createsection() implementieren, wobei auf diverse Hilfsmethoden für das Erstellen von UI-Elementen zurückgegriffen werden kann. Das Erstellen der UI-Elemente wird in der Methode createapplicationsectioncontent() und das Laden der Daten in der Methode loadapplicationsectiondata() gekapselt. Listing 3.1. Ausschnitt der Datei DescriptionFormPageApplicationSection.java 1 public void createsection ( MethodElementEditor editor, 2 FormToolkit toolkit, Composite parent ) { this. editor = editor ; 4 // Get the element that is being edited 6 methodelement = editor. getmethodelement (); // Create this section only if editing an artifact

54 50 R. Freudenreich 8 if (!( methodelement instanceof Artifact )) { return ; } 10 // Get the description for the artifact artifactdescription = ( ArtifactDescription ) 12 (( ContentElement ) methodelement ). getpresentation (); 14 // Create the new section with appropriate name and description text applicationsection = createsection ( toolkit, parent, 16 APPLICATION_SECTION_NAME, APPLICATION_SECTION_DESC ); // Create composite for the new section 18 applicationcomposite = createcomposite ( toolkit, applicationsection ); // Set layout 20 (( GridLayout ) applicationcomposite. getlayout ()). numcolumns = 4; // Create content for the new section ( textboxes, etc.) 22 createapplicationsectioncontent ( toolkit ); 24 // Load data for the new section loadapplicationsectiondata (); 26 // Get the ActionManager actionmgr = editor. getactionmanager (); 28 // Add Listeners for new section ( Modify, Action, etc.) 30 addlisteners (); } 32 protected void createapplicationsectioncontent ( FormToolkit toolkit ) { 34 // Create the label and textbox for the application path ctrl_apppath = createtexteditwithlabel3 ( toolkit, 36 applicationcomposite, APPPATH_TEXT, SWT. DEFAULT, SWT. SINGLE ); // Set layout options 38 ctrl_apppath. setlayoutdata ( new GridData ( GridData. FILL_HORIZONTAL GridData. BEGINNING )); 40 // Create the button for the file choosing dialog ctrl_slot_button = toolkit. createbutton ( applicationcomposite, 42 AuthoringUIText. SELECT_BUTTON_TEXT, SWT. SIMPLE ); // Set layout data 44 ctrl_slot_button. setlayoutdata ( new GridData ( GridData. HORIZONTAL_ALIGN_END )); } 46 protected void loadapplicationsectiondata () { 48 // Get application path for the method element and set text String apppath = artifactdescription. getapppath (); 50 ctrl_apppath. settext ( apppath == null? "" : apppath ); } Änderung der XSL Dateien Als letzter Schritt muss die Generierung der HTML-Webseite angepasst werden. Die HTML-Webseite wird mit einer XSL Transformation der in XML gespeicherten Daten generiert, so dass das Erscheinungsbild der Webseiten durch einfaches Ändern der XSL Dateien bearbeitet werden kann. Diese Dateien befinden sich im Verzeichnis layout/xsl des Pakets org.eclipse.epf.library. Die Änderungen müssen direkt im jeweiligen XSL Template descriptionsection der Dateien artifact.xsl und artifact_descriptor.xsl vorgenommen werden, da es keinen entsprechenden Extension Point gibt. Listing 3.2. Ausschnitt des XSL Templates descriptionsection 1 <xsl : template name =" descriptionsection "> 2 <xsl : param name =" description "/ > {...} 4 <xsl : variable name =" apppath " select =" $description / attribute apppath ']"/ >

55 Evaluierung der Potentiale des EPF 51 6 <xsl : if test =" $briefoutline!= '' or {...} or $apppath!= ''"> <div class =" sectionheading "><xsl : value - of select =" $descriptiontext "/ ></ div > 8 <div class =" sectioncontent "> <table class =" sectiontable " border ="0" cellspacing ="0" cellpadding ="0" > 10 {...} <xsl : if test =" $apppath!= ''"> 12 <script type =" text / vbscript " for =" runapp " event =" onclick "> set oshell = CreateObject (" WScript. Shell ") 14 oshell. run """ < xsl : value -of select =" $apppath "/ >""",1 </ script > 16 <tr valign =" top "> <th class =" sectiontableheading " scope =" row ">Application </ th > 18 <td class =" sectiontablecell "> <img src ="{ $backpath }/ images / run. gif " name =" runapp " alt =" Run Application " 20 title =" Run Application " style =" vertical - align : middle ; cursor : pointer ;"/ > <xsl : value - of select =" concat (' ', $apppath )"/ > 22 </td > </tr > 24 </ xsl :if > </ table > 26 </div > </ xsl :if > 28 {...} </ xsl : template > Falls für ein Artefakt ein Anwendungspfad angegeben ist, enthält die entsprechende HTML-Seite einen neuen Eintrag mit einer kleinen Grafik und einem Text mit dem Anwendungspfad. Durch einen Klick auf die Grafik soll die Anwendung dann gestartet werden. Ein Problem ist dabei, dass es eine große Sicherheitslücke darstellen würde, wenn eine Webseite ohne weiteres ein Programm auf einem anderen Computer ausführen könnte. Aus diesem Grund erlauben dies gängige Webbrowser bis auf eine Ausnahme nicht. Beim Internet Explorer ist dies durch eine Kombination aus VBScript und ActiveX möglich. Diese Funktionalität erfordert beim Benutzer daher zwingend den Einsatz des Internet Explorers. Abbildung 12. Editor und Webseite mit Erweiterung Den EPF Composer selbst zu erweitern hat eindeutig den Vorteil, dass die Anforderungen sehr gut erfüllt werden können. Die Implementierung kommt den eigenen Wünschen sehr nahe (siehe Abbildung 12). Aber auch diese hat Nachteile. Die Änderung des Metamodells ist eine Verletzung des (zukünftigen) SPEM

56 52 R. Freudenreich 2.0 Standards und wegen fehlender Extension Points muss der Quelltext von zwei EPF Composer Plug-Ins geändert werden. Eine reibungslose Aktualisierung auf eine neue Version des EPF Composers ist dadurch nicht möglich, da diese Änderungen manuell übertragen werden müssen. 6 Alternativen Die Firma IBM ist nicht nur die treibende Kraft hinter dem EPF, sondern bietet außerdem mit dem Rational Method Composer (RMC) eine kommerzielle Alternative zu diesem an. Das EPF basiert entscheidend auf großen Teilen des RMC, die IBM als Spende in das Eclipse Projekt einbrachte, und bildet nun den Kern des RMC. Auf diesen Kern baut der RMC mit speziellen Features und zusätzlichen Inhalten auf. Hervorzuheben ist vor allem die Integration mit anderen Anwendungen von IBM Rational und der Rational Unified Process, der im RMC enthalten ist. [4] Eine weitere Alternative mit einem dem EPF ähnlichen Funktionsumfang ist der IRIS Process Author (IPA) der Firma Osellus. Der IPA ist eine Webanwendung und enthält diverse Entwicklungsprozesse (u.a. RUP, OpenUP) basierend auf dem SPEM 1.1 Metamodell. Die mit dem IPA erstellten Inhalte können als Webseite, Wiki oder als ausdruckbares Dokument veröffentlicht werden. Osellus bietet desweiteren mit dem IRIS Process Live ein Werkzeug an, um Prozesse in Verbindung mit dem Microsoft Visual Studio Team System auszuführen. Ein Blick über den Tellerrand liefert mit Anwendungen für domänenspezifische Sprachen (z.b. MetaEdit+) und für die Geschäftsprozessmodellierung im weitesten Sinne weitere Alternativen zum EPF. Die Unterschiede sind allerdings sehr groß. 7 Schluss Das EPF ist ein mächtiges Prozess-Framework, das aufgrund seiner Flexibilität in vielen Anwendungsgebieten eingesetzt werden kann und durch seinen Status als Open Source Projekt eine gute Erweiterbarkeit besitzt. [6] zeigt dass auch fortgeschrittenere Erweiterungen möglich sind. Es besteht allerdings Verbesserungsbedarf bei der Dokumentation für Entwickler. Das EPF ist eines der ersten Frameworks, das den zukünftigen SPEM 2.0 Standard unterstützen wird. Es ist daher gut für die Zukunft aufgestellt eine wichtige Rolle in der modellbasierten Softwareentwicklung zu spielen, denn eine Modellierung der Softwareentwicklungsprozesse ist für alle Entwicklungsprojekte sinnvoll. Vor allem mittlere und große Projekte profitieren davon. Literatur [1] E. Dijkstra. The Humble Programmer. Commun. ACM 15, 10: , 1972.

57 Evaluierung der Potentiale des EPF 53 [2] EPF. Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview. Abruf am [3] EPF. What is the Eclipse Process Framework. community/whats_epf.ppt, Abruf am [4] P. Haumer. IBM Rational Method Composer: Part 1: Key concepts, Dezember Abruf am [5] B. Henderson-Sellers, M. Serour, T. McBride, C. Gonzalez-Perez, and L. Dagher. Process Construction and Customization. Journal of Universal Computer Science, 10(4): , [6] M. Hermanns. Erweiterung der ViPER-Umgebung zur methodengestützten Entwicklung mit MeDUSA, Juli Hermanns_Intermediate_Talk.ppt, Abruf am [7] IBM. Using Eclipse Process Framework Composer with a Version Control System, docs/using%20epf%20with%20a%20version%20control%20system.rtf?root= Technology_Project&view=log, Abruf am [8] B. Kahlbrandt. Software-Engineering mit der Unified Modeling Language. Springer, [9] P. Kroll. OpenUP in a Nutshell, rational/library/sep07/kroll/index.html, Abruf am [10] P. Kruchten. Der Rational Unified Process. Addison-Wesley, [11] P. Liggesmeyer and D. Rombach. Software-Engineering eingebetteter Systeme: Grundlagen-Methodik-Anwendungen. Spektrum Akademischer Verlag, [12] OMG. Software Process Engineering Meta-Model 2.0 OMG Draft Adopted Specification. ad/ , Mai [13] OMG. Software Process Engineering Metamodel Specification Version 1.1. formal/ , January [14] OMG. Second Revised SPEM 2.0 Submission. ad/ , April [15] OMG. Software & Systems Process Engineering Meta-Model Specification. formal/ , April [16] L. Osterweil. Software processes are software too. In ICSE 87: Proceedings of the 9th international conference on Software Engineering, pages 2 13, Los Alamitos, CA, USA, IEEE Computer Society Press. [17] C. Péraire. A roadmap to method development, com/developerworks/rational/library/feb07/peraire/index.html, Abruf am [18] K. Schwaber et al. Manifesto for Agile Software Development, http: //agilemanifesto.org/, Abruf am [19] J. Vesperman. CVS. Versionskontrolle und Quellcode-Management. O Reilly, 2004.

58 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) Panayot Radinski Universität Augsburg Zusammenfassung Im Rahmen dieser Seminararbeit wird die modellbasierte Softwareentwicklung vorgestellt. Speziell wird die Bindung zwischen XML-Schema-Modellen und Java-Beans untersucht. Java Architecture for XML Binding (JAXB) ist eine der populärsten Techniken für die Modelltransformation bzw. Datentransfer zwischen Java und XML. Im Gegensatz zu anderen parser-basierten Ansätzen wie SAX oder DOM bietet JAXB eine höhere Flexibilität und einen vereinfachten Zugriff auf XML Dateien an, so dass Programmierer unkompliziert XML in ihren Java Anwendungen integrieren können. Wie genau JAXB diese Bindung zwischen Java und XML herstellt, wird anhand mehrerer Beispiele veranschaulicht. 1 Einleitung 1.1 Modellbasierte Softwareentwicklung Die heutigen Krisenzeiten, die vielfältigen Bedürfnisse der Kunden, der sich ständig ändernde Gesetzesrahmen erfordern von den IT-Unternehmen eine neue, flexiblere Art der Softwareentwicklung. Einen relativ neuen Ansatz stellt die Modellbasierte Softwareentwicklung, die sich gegenüber der klassischen Softwareentwicklung durch etliche Vorteile auszeichnet - mehr Effizienz, höhere Softwarequalität und bessere Wiederverwendbarkeit. Im Mittelpunkt der Modellbasierten Softwareentwicklung stehen formale Modelle, die die charakteristischen Domainbegriffe und die Beziehungen zwischen diesen Domainbegriffen, ohne Bezug auf die Softwaresysteme, beschreiben. Diese Modelle werden mit Hilfe von Werkzeugen für einen Anwendungsbereich spezifische, aber von den technologischen Details abstrahierte, plattformunabhängige Modelle transformiert. Anschließend werden automatisch aus den transformierten Modellen detailierte, plattformspezifische Modelle generiert, die möglichst große Teile der Implementierung beinhalten und manuell erweitert werden können. 1.2 Die Bindung zwischen Java und XML Java hat sich in den letzten Jahren zu einer der meist verbreiteten objektorientierten Programmiersprachen entwickelt. Plattformunabhängigkeit, Portierbarkeit,

59 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 55 Robustheit, Sicherheit, Modularität und viele mehr zählen zu den wichtigsten Eigenschaften, die diese Sprache so beliebt machen. Neben der Java Standard Edition (SE), die für die Implementierung von allgemeinen, portablen Anwendungen eingesetzt wird, gibt es die Java Micro Edition (ME) für Mobiltelefone oder PDAs und die Java Enterprise Edition (EE) für transaktionsbasierte Systeme. In der Spezifikation von Java wurden Softwarekomponenten und Dienste definiert, die die Grundbausteine für mehrschichtige, verteilte (Web)-Architekturen bereitstellen, um die stets steigende Komplexität zu beherrschen. Solche wiederverwendbaren Softwarekomponenten werden im Java Umfeld Beans genannt. Es gibt die Java Beans (JB) und die Enterprise Java Beans (EJB), die sich in der Aufgabe und im Einsatzgebiet unterscheiden. Die JBs werden als Container für die Datenübertragung verwendet und können überall ausgeführt werden, wo es eine Java Virtual Machine gibt. Dagegen bieten die EJBs in erster Linie Servermechanismen wie Persistenz, Load Balancing, Sicherheit, Transaktionsunterstützung und können ausschließlich in einem EJB-Container eines J2EE Application-Servers ablaufen (vgl. [3]). Im Allgemeinen bestehen beide Typen von Beans aus Java Klassen, die einem Java-Bean-Komponentenmodell entsprechen. Die Kommunikation zwischen den einzelnen Beans wird durch klar definierte Schnittstellen sichergestellt, die das Geheimnisprinzip wahren. Das bedeutet, dass die innere Anwendungslogik verborgen bleibt und die Kommunikation mit der Umwelt über eine äußere Hülle stattfindet, die mit öffentlichen getter- und setter-methoden ausgestattet ist. So können Komponenten unterschiedlicher Hersteller problemlos miteinander verknüpft werden, wenn sie sich an die Java- Bean-Spezifikation halten. XML stellt eine einfache Möglichkeit dar, Daten strukturiert auszutauschen. Da aber XML eine Metasprache ist, die die zu übertragenden Daten nur beschreibt, muss in einer Programmiersprache die notwendige Funktionalität implemeniert werden, um mit XML umgehen zu können. Es gibt verschiedene Techniken, wie DOM, SAX, Pull API, Data Binding usw., die auch in Java vorhanden sind und XML Dateien verarbeiten können. Die Parser-basierten DOM, SAX und Pull API sind aber nicht immer optimal. DOM verbraucht viel Speicher, SAX arbeitet sequentiell, Pull API ist sehr speichereffizient, hat aber auch eine sequentielle Arbeitsweise. Der wesentliche Nachteil der parser-basierten Ansätze ist, dass nicht alle Programmierer mit solchen komplizierten Techniken anvertraut sind. Data Binding benutzt einen eigenen XML-Parser und transformiert im Gegensatz zu diesen Verfahren die XML Daten in Java Objekte, die so für den direkten Programmzugriff bereitgestellt werden (vgl. [4]). Java Architecture for XML Binding (JAXB) ist ein Ansatz, der auf dem Data Binding Modell basiert. Im Rahmen dieser Arbeit wird nicht näher auf die Java Beans eingegangen, sondern man setzt sich mit der Bindung zwischen den beiden Technologien XML und Java auseinander. Im Nachfolgenden Kapitel wird genau erklärt, wie JAXB Java Datenmodelle in XML Schema, Java Objekte in XML Dateien und dann beides umgekehrt transformieren kann. Dafür ist es nicht notwendig, den genauen Aufbau der Beans zu kennen. Viel wichtiger ist es, wie diese äußere Bean-Hülle mit XML interagiert.

60 56 P. Radinski 2 Hauptteil 2.1 XML und XML-Schema XML (kurz gefasst) XML ist allgemein bekannt und wird hier nur kurz zur Wiederholung vorgestellt. Ein großer Vorteil von dieser erweiterbaren Auszeichnungssprache ist, dass sie, obwohl sie strengen Syntaxregeln unterliegt, für einen Menschen sehr einfach zu lesen ist. Um das Verarbeiten durch Parsern zu ermöglichen, wird XML als eine hierarchische Baumstruktur organisiert. Dies bringt aber den Nachteil mit sich, dass viele redundante Informationen gespeichert werden müssen. Der grundsätzliche Aufbau eines XML Dokuments wird anhand eines kurzen Beispiels veranschaulicht, in dem einem Einwohner eine Frau mit Name, Geburtsdatum und Bild zugeordnet wird. Listing 4.1. Das XML Dokument 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <Einwohner > <Frau Name =" Stephanie Müller "> 4 <Geburtsdatum > </ Geburtsdatum > <Visitenkarte Pfad =" D:\ stephie. doc " /> 6 <Haustier >Katze </ Haustier > </Frau > 8 <!-- Ein Kommentar --> </ Einwohner > Ein XML Dokument fängt immer mit einer Deklaration (Zeile 1) an, in der die XML Version und die Zeichenkodierung definiert werden. Mit standalone wird angegeben, ob ein externes XML Schema bzw. Document Type Definition (DTD) angebunden wird. Einwohner, Frau und Geburtsdatum sind XML-Elemente. Sie fangen immer mit einem in spitzen Klammern geschriebenen Start-Tag <name> an und werden mit einem Ende-Tag </name> abgeschlossen. Elemente haben gewöhnlich einen Inhalt (Zeile ) oder sie sind leer. Bild ist ein leeres Element und besteht aus einem Tag in der Form <elementname / >. XML-Attribute sind Zusatzinformationen über Elemente. Stephanie Müller ist der Inhalt des Attributs Name, das das Element Frau näher beschreibt. Wie ein Kommentar aufgebaut wird, ist in der Zeile 7 zu sehen. Damit XML Dateien auch richtig von Parsern gelesen werden können, müssen sie eine wohlgeformte Dokumentenstruktur haben. D.h. sie dürfen genau ein Wurzelelement besitzen (<Einwohner>), die Schachtelung und die Namen der Elemente müssen korrekt sein und die Attribute innerhalb eines Elementes dürfen nicht dieselbe Bezeichnung haben. In XML wird ausserdem zwischen Groß- und Kleinschreibung unterschieden. Wenn XML für den Datenaustausch eingesetzt wird, muss es sichergestellt werden, dass die Informationsquelle und der Datenempfänger dieselbe Sprache sprechen. Dafür muss die für die Kommunikation eingesetzte XML Datei wohlgeformt sein und nach den Vorgaben eines Schema-Modells aufgebaut sein. Die XML Datei muss also auf ihre Gültigkeit überprüft werden (vgl. [2]). Ein

61 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 57 Schema-Modell definiert, ob die prinzipielle Struktur eines XML Dokumentes und der Inhalt der darin verwendeten Tags valide sind. Unter der Benutzung von DTD oder XML-Schema können Modelle definiert werden, die die Gültigkeit von XML Dateien überprüfen. In dieser Arbeit wird beschrieben, wie XML-Schema-Modelle den Datentransfer zwischen Java Komponenten herstellen können XML-Schema Mit einem XML-Schema kann genau festgelegt werden, wie ein gültiges XML Dokument aussehen muss. Eine Menge Merkmale zeichnen das XML-Schema im Vergleich zu anderen Definitionssprachen aus (vgl. [1]): Die Syntax von XML wird in XML-Schema-Dateien benutzt, deshalb ist es nicht notwendig, eine neue Definitionssprache (wie z.b. DTD) zu erlernen. XML-Schema bietet eine Menge von einfachen und komplexen Datentypen. Die Kardinalität (Wertebereich) von Elementen kann genau angegeben werden. XML-Namensräume (namespaces) werden unterstützt. Damit können Elemente, die in verschiedenen XML-Schemata benutzt werden, eindeutig unterschieden werden. XML-Schema bietet ein besser ausgeprägtes Schlüsselkonzept, so dass Elemente eindeutig referenziert werden können. Inhaltsmodelle von Elementen lassen sich mit XML-Schema auch lokal definieren, typisieren und wiederverwenden - mehrfach verwendete Elemente werden nur einmal definiert. Aber: XML-Schema unterstützt so viele Möglichkeiten zur Definition von XML-Dokumenten, dass die XML-Schema-Dateien oft sehr groß, kompliziert und schwer zu lesen werden. In Listing 4.2 wird der Aufbau einer XML-Schema-Datei eingeführt, die die in Listing 4.1 dargestellte XML Datei auf ihre Gültigkeit überprüft. Listing 4.2. Das XML-Schema 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <xs : schema version ="1.0" xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> <xs : complextype name =" Frau "> 4 <xs : attribute name =" Name " type =" xs : string " use =" required "/ > <xs : sequence > 6 <xs : element name =" Geburtsdatum " type =" xs : string " minoccurs ="1" maxoccurs ="1"/ > 8 <xs : element name =" Visitenkarte " type =" xs : string "/ > <xs : element name =" Haustier " type =" xs : string " 10 default =" Hund "/ > </ xs : sequence > 12 </ xs : complextype > </ xs : schema > Die XML-Schema-Datei beginnt wie eine normale XML Datei mit einer XML-Deklaration und besitzt genau ein Wurzelelement - das ist immer der Tag <xs:schema>. Mit den Attributen version und xmlns wird angegeben, um welche XML-Schema-Version es sich handelt und welche XML-Namensräume benutzt werden. <xs:complextype> definiert die zusammenhängende Elementenstruktur Frau. Sie besteht aus dem Attribut (<xs:attribute>) Name und den

62 58 P. Radinski drei Elementen (<xs:element>) Geburtsdatum, Visitenkarte und Haustier. Mit der Angabe use= required muss der Name einer Frau stets vorhanden sein. <xs:sequence> bestimmt die Reihenfolge, in der die Elemente eines komplexen Datentyps vorkommen - Visitenkarte darf z.b. nicht vor Geburtsdatum auftreten. Ausserdem werden innerhalb des <xs:sequence> Tags die Wertebereiche der enthaltenen Elemente durch minoccurs= 1 und maxoccurs= 1 definiert. Im Beispiel bedeutet das, dass für eine Frau nur ein Geburtsdatum gespeichert wird. Falls keine occurs-attribute vorhanden sind, wird der Standardwert 1 benutzt. Mit der default Angabe in Zeile 10 wird ein Standardwert vorgegeben - falls in der XML Datei das Element Haustier keinen Inhalt hat, so wird die Belegung Hund verwendet. Ein XML-Schema kann abhängig von den Anforderungen die Struktur und den Inhalt einer XML Datei viel oder wenig einschränken. Im Listing 4.2 wird z.b. keine Vorgabe für das Attribut Pfad des Elementes Visitenkarte gemacht und auch die Anzahl der Haustiere wird nicht durch ein occur-attribut beschränkt. Einige von den wichtigen Eigenschaften und Funktionalitäten der XML- Schemata wurden bereits angesprochen. Diese Definitionssprache bietet aber viel mehr an (vgl. [2]). Für das Element Haustier kann eine Liste mit den zulässigen Werten für den Inhalt hinzugefügt werden. Ein neuer Datentyp <xs:simpletype> mit dem Namen allehaustiere sowie eine Liste dieses neuen Typs werden dem Element Haustier zugeordnet (siehe Listing 4.3). In der XML Datei wird dann der Inhalt von Haustier so aussehen: (Hund), (Katze), (Vogel), aber auch (Hund Katze Vogel) ist möglich - (Rex) ist dann eine falsche Eingabe. 1 <xs : simpletype name =" allehaustiere "> 2 <xs : restriction base =" xs : string "> <xs : enumeration value =" Katze "/ > 4 <xs : enumeration value =" Hund "/ > <xs : enumeration value =" Vogel "/ > 6 </ xs : restriction > </ xs : simpletype > 8 <xs : simpletype name =" Haustier "> <xs : list itemtype =" allehaustiere "/ > 10 </ xs : simpletype > Listing 4.3. XML-Schema Erweiterung 1 Für ein Haustier kann ein beliebiger Datentyp (xs:anytype) definiert werden, so dass als Elementinhalt die Anzahl der Haustiere, ihre Namen usw. zulässig sind (siehe Listing 4.4). Listing 4.4. XML-Schema Erweiterung 2 1 <xs : element name =" Haustier " type =" xs : anytype "/ > Der komplexe Datentyp Frau kann um das Element Ehemann erweitert werden (xs:extension) und so wird der neue Typ neuefrau entstehen (siehe Listing 4.5).

63 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 59 Listing 4.5. XML-Schema Erweiterung 3 1 <xs : complextype name =" neuefrau "> 2 <xs : complexcontent > <xs : extension base =" Frau "> 4 <xs : sequence > <xs : element name =" Ehemann " type =" xs : string "/ > 6 </ xs : sequence > </ xs : extension > 8 </ xs : complexcontent > </ xs : complextype > Das Format des Geburtsdatums lässt sich durch einen regulären Ausdruck ebenfalls einschränken (xs:restriction). So muss der Geburtstag immer die Form JJJJ.MM.TT haben (siehe Listing 4.6). Listing 4.6. XML-Schema Erweiterung 4 1 <xs : simpletype name =" Geburtsdatum "> 2 <xs : restriction base =" xs : string "> <xs : pattern value ="[0-9]{4}[.][0-9]{2}[.][0-9]{2}"/ > 4 </ xs : restriction > </ xs : simpletype > Anhand des XML-Schemas können eindeutige Schlüssel festgelegt werden. So kann für den komplexen Datentyp Frau definiert werden, dass alle darin enthaltenen Elemente eine eindeutige (unique) Kombination bilden müssen - eine Frau mit denselben Merkmalen darf nur einmal vorkommen. Zu dieser Elementenkombination kann dann ein Schlüssel (key) bereitgestellt werden, so dass von außen auf die Daten referenziert werden kann. Das XML Schema erlaubt sogar fremde Schemata wieder zu verwenden. Die Verknüpfung zwischen verschiedenen Schema Dateien wird von den include-, import- und redefine-klauseln gewährleistet. Der Typ Frau kann durch den Import einer anderen Frau-Definition so angepasst werden, dass von beiden Schemata kompatible XML Dateien abgeleitet werden können. Beispiele zu den Schlüssel- und Importeigenschaften des XML-Schemas wurden herausgelassen, da sie zu kompliziert und eigentlich für dieses Seminarthema nicht relevant sind. 2.2 JAXB Java Architecture for XML Binding (JAXB) stellt einen innovativen Ansatz dar, mit dem Entwickler XML als Schnittstelle zwischen Java Anwendungen einfach benutzen können. Es ist nicht notwendig, in Java die XML Dateien zu parsen bzw. zu validieren - diese Aufgabe übernimmt JAXB. In den früheren Versionen (1.x) von JAXB gab es aber mehrere Probleme beim Einsatz dieser Technologie. Laufzeitfehler auf den unterschiedlichen Java Virtual Machines haben die wesentlichen Vorteile von Java wie Plattformunabhängigkeit und Portabilität beeinträchtigt. Der Fokus bei der Entwicklung von JAXB lag nur auf der Transformation von XML-Schema zu Java Datenmodelle und nicht umgekehrt, was die Kommunikation zwischen Java Anwendungen sehr erschwerte (vgl. [5]). Mit der aktuellen JAXB Version 2.x wurden die meisten Probleme behoben und viele innovative Verbesserungen eingeführt (vgl. [6]):

64 60 P. Radinski Eine High-Level-XML-API erleichtert die Integration von XML, indem sie die Komplexität von XML Parsern von den Java Entwicklern fernhält und stattdessen eine allgemein bekannte und einfache Art für die Bindung von XML anbietet - nämlich die Java Beans (auch POJOs genannt - Plain Old Java Objects). Der jüngste Trend zu den POJOs basiert auf dem Streben nach mehr Einfachheit bei der Implementierung von Java Objekten und passt sehr gut in das Konzept von JAXB. Um die Transformation zwischen Java und XML speziell anpassen zu können, werden Java Annotationen eingesetzt, die erst mit der Java Standard Edition 5 eingeführt wurden. Die JAXB-charakteristischen Annotationen werden im Kapitel näher erläutert. Ein weiteres Ziel von JAXB ist es, das XML-Schema - wie von W3C definiert - möglichst vollständig zu unterstützen, um sich als Standard durchzusetzen. Mit der bidirektionalen Bindung zwischen Java und XML in JAXB 2.0 wurde ein sehr wichtiger Schritt gemacht, um die Verbindung von Java Anwendungen (auch Java Webservices) anhand XML zu ermöglichen. Das bedeutet, dass die Generierung einer XML Datei aus einem Java Objekt und die Transformation dieser XML Datei danach in einem zu dem ursprünglichen, äquivalenten Java Objekt unterstützt wird. Die Validierung von XML Dokumenten mit Hilfe des XML-Schemas ist auch ein Teil der Verbesserungen in JAXB. Bei der Kommunikation zwischen Java Programmen ist es sehr wichtig, dass gültige XML Daten ausgetauscht werden. Wie diese Verbesserungen eine korrekte, bidirektionale Bindung zwischen Java und XML ermöglichen, wird in den nächsten Kapiteln dieser Seminararbeit anhand ausführlicher Beispiele veranschaulicht, die auf Windows Vista mit der Entwicklungsumgebung Eclipse und der Java Version jdk1.6.0_07 erstellt wurden. Es gibt zwei Arten, wie JAXB auf einem Betriebssystem installiert werden kann. Einerseits ist JAXB ein Teil von Java geworden (die Klassen sind unter javax.xml.bind.* zu finden), andererseits kann die aktuelle JAXB Version von der Homepage ( heruntergeladen werden und in Eclipse entsprechend importiert werden (für die Beispiele wird hier die aktuellste Version von JAXB benutzt). Auf der Abbildung 1 sind die fünf grundlegenden Bausteine von JAXB dargestellt. Zu jedem wird jeweils ein Kapitel mit Beispielen gewidmet. Der vollständige Quellcode zu den Beispielen ist immer im Anhang zu finden. Deserialisieren (Unmarshalling) - Die Transformation von einer XML Datei in ein Java Objekt (automatische Validierung möglich). Serialisieren (Marshalling) - Die Transformation von einem Java Objekt in eine XML Datei (automatische Validierung möglich). Schemakompiler - Die Transformation von einem XML-Schema in ein Java Datenmodell. Schemagenerator - Die Transformation von einem Java Datenmodell in ein XML-Schema.

65 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 61 Annotationen - Mit den JAXB Annotationen werden alle vier oben aufgeführten Funktionen konfiguriert. Es gibt die Mapping-Annotationen, die in Java definiert werden und die Bindungskonfigurationen - die Annotationen - die im XML-Schema zum Einsatz kommen. Abbildung 1. JAXB Schema JAXB Java-Annotationen In diesem Kapitel liegt der Schwerpunkt auf den Mapping-Annotationen, da sie für einen Java Programmierer, der sich mit XML-Schema und XML Parsern nicht auskennt, von großer Bedeutung sind. Die Bindungskonfigurationen werden im Kapitel Schemakompiler näher erläutert. Um die volle Funktionalität von JAXB nutzen zu können, muss ein Programmierer die dafür spezifischen Java-Annotationen gut kennen. Sie steuern die korrekte Bindung zwischen Java und XML. Es sind insgesamt 29 Annotationen verfügbar, die auf verschiedenen Ebenen eingesetzt werden können. Es gibt die Package-, Class-, Enum type-, JavaBean Property/field- und Parameter- Ebenen. Die Annotationen werden vor dem Java Element deklariert, auf dem sie angewendet werden sollen (siehe Listing 4.7). Sie haben folgenden Standardaufbau (@Annotationsname(Parameter)) und die wichtigsten davon werden nun näher erläutert (vgl. [11]) // Annotation auf Class - 4 public class Frau { Listing 4.7. JAXB Annotationen Anwendung 6 // Annotation auf JavaBean Property / field - 8 public String Name ; 10 // Annoation auf JavaBean Property / field - Ebene

66 62 P. 12 public void setname ( String Name ){ this. Name = Name ; 14 } } XmlRootElement gibt an, dass die nachfolgende Java Klassendefinition einem XML Wurzelelement entspricht. Mit der XMLFrau ) wird vorgegeben, dass die Java Klasse Frau in XML den Namen XMLFrau hat. Diese Annotation kann auf Class- und Enum type-ebenen angewendet Mit XmlElement werden Java Attribute gekennzeichnet, die in XML als XML- Elemente dargestellt Hund ) definiert den Standardwert für ein Element. Andere wichtige Parameter, die diese Annotation spezifizieren können, sind name, namespace, nillable, required und type. XmlElement kann nur auf JavaBean Property/field-Ebene angewendet Die Annotation XmlAccessorType legt fest, welche Attribute einer Java Klasse in XML abgebildet werden sollen. Es gibt vier Parametererweiterungen, die abhängig von der Sichtbarkeit (public, private usw.) der Java Attribute ein entsprechendes Verhalten steuern. werden nur die Attribute serialisiert, die folgen. Mit XmlAccessType.PUBLIC_MEMBER werden alle public Attribute serialisiert. Mit XmlAccessType.PROPERTY werden nur Attribute abgebildet, die öffentliche getter- oder setter-methoden haben. XmlAccessType.FIELD sagt aus, dass alle Attribute, außer der statischen, serialisiert werden sollen. Diese Annotation kann auf Package- und Class-Ebenen angewendet XmlAccessorOrder erlaubt, die Reihenfolge der in XML abgebildeten Elemente zu ändern. Mit dem ALPHABETICAL) wird eine alphabetische Anordnung erzwungen, ansonsten erfolgt eine beliebige Sortierung. Diese Annotation kann auf Package- und Class- Ebenen angewendet Über die Annotation XmlTransient wird angegeben, dass ein Java Attribut nicht serialisiert werden darf. Diese Annotation kann auf JavaBean Property/field- Ebene angewendet Mit XmlAttribute werden die Attribute einer Java Klasse als XML Atrribute abgebildet. Diese Annotation kann auf JavaBean Property/field-Ebene angewendet Die Annotation XmlType wird benutzt, um komplexe bzw. einfache XML Datentypen (<xs:complextype>, <xs:simpletype>) zu definieren. Diese Annotation kann auf Class- und Enum-Ebenen angewendet

67 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 63 Mit der Annotation XmlValue wird ein Java Attribut in ein XML Wert transformiert (<xml>xmlwert</xml>). XmlValue und XmlElement können nicht gleichzeitig in derselben Klasse benutzt werden. Diese Annotation kann auf JavaBean Property/field-Ebene angewendet werden. Die bereits vorgestellten und die restlichen JAXB Annotationen erlauben eine präzise Bindung zwischen Java und XML. Sowohl als auch der Umgang mit verschiedenen Datentypen JavaTypeAdapter), Schlüsseleigenschaften und des XML-Schemas werden unterstützt. Damit schafft JAXB einen weiteren Schritt in Richtung seiner primären Ziele, nämlich das XML-Schema möglichst vollständig zu unterstützen Schemakompiler Beim Schemakompiler werden XML-Schemata in Java Datenmodelle umgewandelt. Für seine Anwendung ist also ein XML-Schema erforderlich. Dieses Schema kann dann über zwei verschiedenen Wege in ein fertiges Java Datenmodell transformiert werden - entweder die Kommandozeile oder viel bequemer, ein ANT-Skript in Eclipse (auch Build-Skript genannt), welches später im Abschnitt noch genauer erläutert wird. Beim Ausführen des ANT-Skripts werden mindestens zwei Java Klassen erstellt - mindestens eine Java Klasse zum XML-Schema und genau eine ObjectFactory.java Klasse. Im Beispiel mit der Frau wird nun das XML-Schema Frau.xsd aus Listing 4.2 benutzt, mit dem einzigen Unterschied, dass <xs:attribute name= Name > erst nach dem <xs:sequence> Attribut vorkommen darf (siehe Listing 4.27 im Anhang) - ansonsten meldet Eclipse einen Fehler, dass <xs:sequence> falsch aufgebaut wurde. Diese Frau.xsd wird im Projektordner schema abgelegt. Das ANT-Skript SchemaKompiler.xml wird im Projekt-Root-Ordner erstellt und wird über Run As -> Ant Build ausgeführt. Ein neuer Ordner generated wird automatisch angelegt und in diesem sind die fertigen Java Klassen Frau.java und ObjectFactory.java zu finden. Bevor aber gezeigt und erklärt wird, wie der Ablauf des Schemakompilers tatsächlich ist, müssen einige Begriffe und Zusammenhänge näher erläutert werden. Einige Grundbausteine sind beim Schemakompiler und beim Schemagenerator sehr ähnlich und werden nun hier vorgestellt. Folgende Transformationsregeln gelten in beiden Richtungen - also von XML-Schema zu Java Datenmodell (Schemakompiler) und umgekehrt (Schemagenerator) (vgl. [7]): XML Namespace <=> Java Paket. Ein <targetnamespace= wird zu einem package frau übersetzt und umgekehrt. XML komplexer Datentyp <=> Java Klasse. Ein <xs:complextype name= frau > wird zu einem public class Frau übersetzt und umgekehrt. XML einfacher Datentyp <=> Java Datentypen und Wrapper Klassen. Ein <xs:simpletype name= ehemann > wird z.b. zu einem protected String ehemann übersetzt und umgekehrt.

68 64 P. Radinski XML einfacher Datentyp mit Enumeration <=> Java Enumeration. Siehe 4.8. Listing 4.8. Enumeration 1 <xs : simpletype name =" Beziehung "> 2 <xs : restriction base =" xs : string "> <xs : enumeration value =" freund " /> 4 <xs : enumeration value =" ehemann " /> </ xs : restriction > 6 </ xs : simpletype > 8... in beiden Richtungen public enum Beziehung { FREUND, 12 EHEMANN ; } XML Element <=> Java Attribut. Ein <xs:element name= haustier type= xs:string > wird zu einem protected String Haustier übersetzt und umgekehrt. Ein ANT-Skript wird beim Schemakompiler und beim Schemagenerator eingesetzt und automatisiert die Umwandlungen in beiden Richtungen (Java nach XML bzw. XML nach Java). Er hat in beiden Fällen denselben Aufbau, aber verschiedene Parameter. ANT ist eine Java-basierte XML Sprache, mit der Build- Skripten erstellt werden, die verschiedene Aufgaben zusammenfassen (wie z.b. Kompilieren von Quellcode). Um nicht jedes Mal die JAXB Transformationsbefehle manuell anzustoßen, werden sie in Eclipse in einem ANT-Skript gepackt und ausgeführt. Dieses Skript besteht gewöhnlich aus folgenden Bereichen (vgl. [12]): Im Bereich <project> wird das Default Projekt definiert - zu jedem Projekt gehört genau eine Build Datei. Eine Beschreibung bzw. Kommentare können im <description> Tag angegeben werden. <property name= var...> wird angewendet, um Redundanz im Quellcode zu vermeiden. Die Variable var kann dann durch ${var} angesprochen werden. In <path> muss angegeben werden, wo sich das JDK und die JAXB Klassen befinden, da sie für die Transformation notwendig sind. Über <classpath> kann eine Funktion referenziert werden, die nicht in einer Datei mit einem existierenden Pfad auf dem System gespeichert ist. Ein Projekt besteht aus mindestens einem <target> Bereich. Die Targets sind sozusagen die Ablauflogik eines ANT-Skripts. Sie können sich untereinander aufrufen und stoßen verschieden Aufgaben an - beispielsweise die Kompilierung des Quellcodes, oder das Verpacken in einem JAR-Archiv usw. Funktionen werden in ANT mit dem <task> Tag bezeichnet. Es gibt vordefinierte Tasks (der Java-Compiler javac, ANT Tasks wie copy, delete, zip und mail) und benutzerdefinierte Tasks. xjc und schemagen sind JAXB spezifische Tasks, die in ANT als benutzerdefiniert mit dem Tag <taskdef > angegeben werden, da sie dem ANT Kompiler nicht direkt bekannt sind.

69 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 65 In Listing 4.9 wird das ANT-Skript vorgeführt, das die Transformation von XML-Schema (Frau.xsd) nach Java steuert. Die ANT Datei beginnt mit der Angabe der XML Version. Wenn kein Target spezifiziert sein sollte, wird im <project> Tag mit dem Attribut default den default-target definiert - xjc ist das JAXB-Task für die Schemakompilierung. Mit basedir wird das Hauptverzeichnis vorgegeben, wo sich alle Dateien zu dem gegebenen Projekt befinden. Ohne die Angabe der Ordner <path><fileset dir=...>, wo sich die JDK und JAXB Quelldaten auf dem System befinden, kann das ANT-Skript nicht funktionieren. Der <path> Tag besitzt außerdem das Attribut id= classpath, das später in der benutzerdefinierten Funktion <taskdef name= xjc...> referenziert wird. So wird dem ANT Compiler mitgeteilt, wo das xjc Task zu finden ist. Jetzt kann auch ein <target name=...> spezifiziert werden, das das xjc Task ausführt. Hier werden die Quell- und die Zielverzeichnisse angegeben - in welchem Ordner das Schema liegt (<schema dir= schema >), wie das Schema heisst (Frau.xsd) und wo sollen die neuen Java Datenmodelle (Klassen) erstellt werden (<xjc destdir=. >). Listing 4.9. ANT Skript - SchemaKompiler.xml 1 <? xml version ="1.0"? > 2 <project default =" xjc " basedir ="." > 4 <path id=" classpath "> <fileset dir =" C:\ Sun \ jaxb -ri \ lib " includes ="*. jar " /> 6 <fileset dir =" C:\ Program Files \ Java \ jdk1.6.0 _07 \ lib " includes ="*. jar " /> 8 </path > 10 <taskdef name =" xjc " classname =" com. sun. tools. xjc. XJCTask " classpathref =" classpath " /> 12 <target name =" xjc "> 14 <xjc destdir ="." > <schema dir =" schema "> 16 <include name =" Frau. xsd " /> </ schema > 18 </xjc > </ target > 20 </ project > Nach dem Ausführen von SchemaKompiler.xml entstehen die Frau.java (Listing 4.11) und ObjectFactory.java (Listing 4.10) Klassen. In der ObjectFactory werden create-methoden zu allen erzeugten Java Klassen gesammelt (vgl. [8]). Falls in einem XML-Schema zwei komplexe Datentypen definiert sind, werden bei der Transformation zwei Java Klassen erzeugt (z.b. Frau1.java und Frau2.java). In der ObjectFactory Klasse werden dann entsprechend zwei create-methoden createfrau1() und createfrau2() generiert. Diese Factory-Klasse ist eine Art zentrale Verwaltung. Dort können alle erzeugten Java Klassen instanziert werden. Sie wird durch die auf Class-Ebene gekennzeichnet und kann ebenso manuell erstellt und angepasst werden. Die zu Listing 4.10 vollständige Klasse ist im Anhang unter Listing 4.29 zu finden. Listing Automatisch generierte ObjectFactory.java (abgekürzt) 1 package generated ;

70 66 P. Radinski 2 import javax. xml. bind. annotation. XmlRegistry ; 6 public class ObjectFactory { 8 public ObjectFactory () { } 10 public Frau createfrau () { 12 return new Frau (); } 14 } Die Frau Klasse wird durch JAXB automatisch mit Java-Annotationen versehen, die die Struktur des XML-Schemas widerspiegeln. Alle Elemente <xs:element> aus dem komplexen Datentyp Frau sind erforderlich und zwar in der gegebenen Reihenfolge. Dies wird in Java auf Class-Ebene durch und auf JavaBean Property /field - Ebene durch die Angabe required = true definiert. Alle bezeichneten Java Attribute können über getter- und setter-methoden angesprochen werden. Die zu Listing 4.11 vollständige Klasse ist im Anhang unter Listing 4.28 zu finden. Listing Automatisch generierte Frau.java (abgekürzt) 1 package generated ; 2 import javax. xml. bind. annotation. XmlAccessType ; 4 import javax. xml. bind. annotation. XmlAccessorType ; import javax. xml. bind. annotation. XmlAttribute ; 6 import javax. xml. bind. annotation. XmlElement ; import javax. xml. bind. annotation. XmlType ; ( XmlAccessType. FIELD ) ( name = " Frau ", proporder = { " geburtsdatum ", 12 " visitenkarte ", " haustier " 14 }) public class Frau { ( name = " Geburtsdatum ", required = true ) 18 protected String geburtsdatum ;... ( name = " Name ", required = true ) protected String name ; 22 public String getgeburtsdatum () { 24 return geburtsdatum ; } 26 public void setgeburtsdatum ( String value ) { this. geburtsdatum = value ; 28 }... Die Transformation von XML-Schema nach Java kann auf zwei Arten beeinflusst werden - einerseits durch die XML-Schema-eigenen Sprachelemente, andererseits durch die JAXB Bindungskonfigurationen. An dieser Stelle werden einige interessante Transformationen vorgestellt, die teilweise auf den im Kapitel

71 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) gezeigten XML-Schema Erweiterungen basieren. Ein komplexer Datentyp im XML-Schema kann durch <xs:sequence>, <xs:all> oder <xs:choice> angepasst werden. <xs:sequence> bedeutet, dass alle Elemente in der gegebenen Reihenfolge auftreten müssen. Wie die Übersetzung in Java funktioniert, wurde in diesem Kapitel vorgestellt. <xs:all> bedeutet, dass alle Elemente ohne eine bestimmte Reihenfolge vorhanden sein müssen. Der einzige Unterschied zu der Abbildung von <xs:sequence> ist, dass das Attribut proporder leer ist. <xs:choice> bedeutet, dass nur ein Element und nicht mehrere vorkommen dürfen. Der einzige Unterschied zu der Abbildung von <xs:sequence> ist, dass das Attribut required = true fehlt. Die Angabe von Kardinalitäten durch die minoccur und maxoccur Attribute im XML Schema wird von Java in folgender Weise interpretiert. Falls maxoccur vorhanden ist, kann minoccur ausgelassen werden - der Wert wird per default auf 1 gesetzt: minoccur= 0 und maxoccur= 0 - das XML-Schema Element wird in Java überhaupt nicht abgebildet. minoccur= 1 und maxoccur= 1 - normale Abbildung wie in Listing minoccur= 0 und maxoccur= 2 - alle Schema-Elemente, die mit maxoccur größer 1 (auch maxoccur= unbounded ) markiert sind, werden als Java Listen interpretiert und nur mit getter- und ohne setter-methoden abgebildet. Die setter-methoden werden dann in einer anderen Weise implementiert (siehe Listing 4.12). Listing min- und maxoccurs Variationen /** * Gets the value of the geburtsdatum property. 4 * * <p> 6 * This accessor method returns a reference to the live list, * not a snapshot. Therefore any modification you make to the 8 * returned list will be present inside the JAXB object. * This is why there is not a <CODE >set </ CODE > method for the geburtsdatum property. 10 * * <p> 12 * For example, to add a new item, do as follows : * <pre > 14 * getgeburtsdatum (). add ( newitem ); * </pre > 16 * * 18 * <p> * Objects of the following type (s) are allowed in the list 20 * String } * 22 * */ 24 public List <String > getgeburtsdatum () {

72 68 P. Radinski if ( geburtsdatum == null ) { 26 geburtsdatum = new ArrayList < String >(); } 28 return this. geburtsdatum ; } Die Anpassungen durch XML-Sprachelemente sind ein spannender Aspekt von JAXB, werden aber hier nicht mehr behandelt. Der interessierte Leser kann sich jedoch unter [9] mit dem Thema auseinandersetzen. Hier sollen nun auch die Anpassungen durch Bindungskonfigurationen vorgestellt werden. Mit ihnen kann das Verhalten des Schemakompilers weiter verfeinert werden. Diese Arbeit zeigt jedoch nur Grundzüge der Möglichkeiten - für ein besseres Verständnis der Bindungskonfigurationen siehe [10]. Die JAXB-Bindungskonfigurationen können inline (direkt im XML-Schema) oder extern (in einer Datei) definiert werden. Inline ist es viel komfortabler, da die Bindungskonfigurationen immer in der Datei mitgenommen werden und das ANT-Skript auch nicht zusätzlich angepasst werden muss. Es wird anhand eines Beispiels (Listing 4.13) demonstriert, wie eine Bindungskonfiguration direkt im XML-Schema vom Listing 4.27 angebunden werden kann. Im Bereich <xs:annotation>...</xs:annotaion> eines XML-Schemas werden die Bindungskonfigurationen normalerweise definiert. Ganz wichtig ist die Zeile 3 im Beispiel - ohne die Angabe des Namespace können die Bindungskonfigurationen nicht aufgelöst werden. In Zeile 6 wird generateissetmethod=true benutzt, um in allen generierten Java Klassen (globalbindings) und für alle darin enthaltenen Attribute eine boolean isset-methode anzulegen. Sie überprüft, ob ein Attribut mit einem Wert belegt ist. Listing Bindungskonfigurationen im XML-Schema 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <xs : schema version ="1.0" xmlns : xs =" http :// www. w3. org /2001/ XMLSchema " xmlns : jaxb =" http :// java. sun. com / xml /ns/ jaxb " jaxb : version ="2.0" > 4 <xs : annotation > <xs : appinfo > 6 <jaxb : globalbindings generateissetmethod =" true " /> </ xs : appinfo > 8 </ xs : annotation > <xs : complextype name =" Frau "> Durch den Einsatz von jaxb:collectiontype (Listing 4.14) kann beispielsweise das in Listing 4.12 als List<String> interpretierte Geburtsdatum in einem java.util.vector transformiert werden (Listing 4.15). Mit der Angabe von global- Bindings wird diese Regel auf alle Attribute vom Typ List<String> angewendet. Listing jaxb:collectiontype Einsatz <jaxb : globalbindings collectiontype =" java. util. Vector " />...

73 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 69 Listing Automatisch generierte Frau.java 1... ( name = " Geburtsdatum ", required = true ) protected List <String > geburtsdatum = new Vector <String >(); 4... public List <String > getgeburtsdatum () { 6 if ( geburtsdatum == null ) { geburtsdatum = new Vector < String >(); 8 } return this. geburtsdatum ; 10 }... Diese und viele andere Anpassungen im XML-Schema sind möglich. Mit der Annotation jaxb:class kann z.b. der Name der zu generierenden Java Klasse unabhängig vom Namen des komplexen Datentyps im XML-Schema geändert werden. Mit jaxb:property können die Namen der zu generierenden Java Attribute angepasst werden Schemagenerator Der Schemagenerator transformiert Java Datenmodelle zu XML-Schemata. Er steht erst seit der JAXB Version 2.0 zur Verfügung. Dafür notwendig sind mit JAXB Annotationen versehene Java Datenmodelle und ein ANT Skript. Die Transformation kann ebenfalls wie beim Schemakompiler auf zwei verschiedenen Wegen stattfinden - über die Kommandozeile oder über ein ANT-Skript in Eclipse. In dieser Arbeit wird aus Platzgründen jedoch nur auf den bequemeren Weg in Eclipse eingegangen. Nach dem Ausführen des Skripts entsteht dann ein XML-Schema, das das Schema für alle Java Datenmodelle beinhaltet - also in einer Datei werden die Beschreibungen für alle Datenmodelle gesammelt. Im Beispiel wird die bereits im Schemakompiler generierte Frau.java Klasse (siehe 4.28) benutzt, um zu überprüfen, ob die Transformation rückwärts, also von der automatisch generierten Java Klasse nach XML-Schema dasselbe ergibt. Die im Schemakompiler erzeugte Klasse ObjectFactory.java kann mitgenommen werden, ist aber für die Schemagenerierung nicht unbedingt erforderlich. Falls die getter- und setter-methoden gleichzeitig fehlen, findet keine korrekte Umwandllung statt. Mindestens eine set- bzw. get-methode für jedes Java Attribut muss im Quelltext verfügbar sein. Eine Transformation ist sogar ohne JAXB-Annotationen möglich, nur die getter- oder setter-methoden müssen vorhanden sein, ansonsten wird dieses Attribut nicht in XML-Schema übersetzt. Das ANT-Skript (siehe 4.16) ist ähnlich wie beim Schemakompiler aufgebaut, hat aber natürlich andere Parameter. Im <taskdef > Tag wird ein benutzerdefiniertes Task angelegt, in dem das JAXB spezifische schemagen-task für die Umwandlung von Java Datenmodelle nach XML-Schema eingefügt wird. Zu beachten ist, dass schemagen klein geschrieben wird und nicht schemagen. Im Zielordner schemafolder wird das fertige XML-Schema ausgegeben. Listing ANT Skript SchemaGenerator.xml

74 70 P. Radinski 1 <? xml version ="1.0"? > 2 <project name =" Frau " default =" schemagen " basedir ="." > 4 <path id=" classpath "> <fileset dir =" C:\ Sun \ jaxb -ri \ lib " includes ="*. jar " /> 6 <fileset dir =" C:\ Program Files \ Java \ jdk1.6.0 _07 \ lib " includes ="*. jar " /> 8 </path > 10 <taskdef name =" schemagen " classname =" com. sun. tools. jxc. SchemaGenTask " 12 classpathref =" classpath "> </ taskdef > 14 <target name =" schemagen "> 16 <schemagen destdir =" schemafolder " srcdir =" src " classpathref =" classpath "> 18 </ schemagen > </ target > 20 </ project > Das Ergebnis der Transformation ist in Schema1.xsd (Listing 4.17) zu sehen. Es ist bemerkenswert, dass es zum größten Teil dem ursprünglichen Schema vom Schemakompiler (Listing 4.27) entspricht. Es fehlen nur die occur-attribute des Geburtsdatum-Elements. Sie sind aber eigentlich überflüssig, weil die Zusammensetzung minoccurs= 1 und maxoccurs= 1 nur besagt, dass das Geburtsdatum-Attribut vorhanden sein muss. Diese Anforderung ist durch die in der vorhandene Eigenschaft required= true gegeben. Die Übersetzung in XML-Schema erfordert dann keine Angabe von occur-attributen. Listing Automatisch generierte Schema1.xsd 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <xs : schema version ="1.0" xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> 4 <xs : complextype name =" Frau "> <xs : sequence > 6 <xs : element name =" Geburtsdatum " type =" xs : string "/ > <xs : element name =" Visitenkarte " type =" xs : string "/ > 8 <xs : element name =" Haustier " type =" xs : string " default =" Hund "/ > </ xs : sequence > 10 <xs : attribute name =" Name " type =" xs : string " use =" required "/ > </ xs : complextype > 12 </ xs : schema > Die Umwandlung von Java Datenmodell nach XML-Schema kann durch die bereits im Kapitel erwähnten Java-Annotationen weiter angepasst werden. Einige davon haben ihre äquivalenten XML-Schema Annotationen - d.h. sie sind bidirektional verknüpft. Aus der = Frau, proporder = X, Y ) entsteht immer ein komplexer Datentyp <xs:complextype name = Frau > und umgekehrt. Andere werden im XML-Schema nicht direkt gibt das Nichtvorhandensein eines Java Attributs vor. Das Beispiel in Listing 4.18 bedeutet, dass kein geburtsdatum-element im XML-Schema vorkommen soll. Listing Java-Annotation 1

75 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) ( name = " Frau ", proporder = { " visitenkarte ", 4 " haustier " }) 6 public class Frau { protected String geburtsdatum ; Wenn zwei oder mehr Java Klassen beim Schemagenerator transformiert werden, so entstehen im XML-Schema zwei oder mehr komplexe Datentypen. Dasselbe gilt auch umgekehrt - die Anzahl der Java Klassen ist abhängig von der Anzahl der komplexen Datentypen. Solche Abhängigkeiten wurden bereits im Kapitel Schemakompiler ausführlich beschrieben. Im selben Kapitel wurde auch angesprochen, dass eine manuelle Anpassung der ObjectFactory.java Klasse möglich ist. Bei der Validierung der XML-Daten durch das XML-Schema, was im nächsten Kapitel (Serialisieren) vorgestellt wird, ist es notwendig, dass zu dem komplexen Datentyp Frau eine <xs:element name= frau type= Frau / > Angabe im XML-Schema vorhanden ist. So ein Element wird von der Frau.java Klasse aus Listing 4.28 nicht automatisch erzeugt. Deshalb muss die ObjectFactory angepasst werden. Das funktioniert über die (siehe Listing 4.19). In diesem Fall muss die ObjectFactory.java Klasse zusammen mit der Frau.java Klasse durch den Schemagenerator transformiert werden. Listing ObjectFactory.java Anpassung 1... public class ObjectFactory { 4 private final static QName _Frau_QNAME = new QName ("", " frau "); 6 public ObjectFactory () { 8 } public Frau createfrau () { 10 return new Frau (); } 12 /** 14 * Create an instance of JAXBElement Frau >}} * 16 ( namespace = "", name = " frau ") 18 public JAXBElement <Frau > createfrau ( Frau value ) { return new JAXBElement <Frau >( _Frau_QNAME, Frau. class, null, value ); 20 } } Serialisieren Beim Serialisieren (Marshalling) werden Java Objekte in XML Dateien umgewandelt. Dabei können die XML Daten durch das XML Schema validiert werden (auf Gültigkeit überprüft werden). Eine so genannte Serialisierer Java Klasse und mindestens eine Java Klasse mit JAXB Annotationen sind notwendig für die Datenübertragung in XML. Die Java Klassen können

76 72 P. Radinski direkt oder über die ObjectFactory Klasse instanziert werden. Beim Serialisieren und Deserialisieren wird kein ANT Skript gebraucht, da keine Java Datenmodelle bzw. XML-Schema transformiert werden - in Java werden jeweils XML Daten eingelesen (Deserialisieren) oder ausgegeben (Serialisieren). Im Beispiel wird manuell die Serialisierer.java Klasse angelegt, welche dann die Frau.java Klasse aufruft. Um über die Seminararbeit hinweg konsistent zu bleiben, wird hier die bereits beim Schemakompiler generierte Frau.java (siehe Listing 4.28) benutzt. Da es sich um nur eine Java Klasse handelt, wird die ObjectFactory nicht verwendet, sondern die Objekte werden direkt erzeugt. In der Serialisierer Klasse (Listing 4.20) findet die Transformation des Java Objektes in eine XML Datei statt. Am Anfang muss immer ein JAXBContext Objekt erstellt werden - dort ist die Bindung zwischen Java Datenmodell und XML-Schema definiert. Dann wird ein Marshaller Objekt aufgerufen, das alle für die Transformation notwendigen Methoden beinhaltet. Die Angabe JAXB_FORMATTED_OUTPUT bedeutet, dass die auszugebende XML-Datei entsprechend formatiert sein muss. Mit der Initialisierung der Frau Klasse können ihre Attribute über die setter-methoden mit Werten belegt werden. Diese Werte werden durch die Angabe marshaller.marshal in eine XML-Datei (Listing 4.37) umgewandelt. Die zu Listing 4.20 vollständige Klasse ist unter Listing 4.34 zu finden. 1 import javax. xml. bind. JAXBContext ; 2 import javax. xml. bind. Marshaller ; 4 public class Serialisierer { Listing Serialisierer.java 6 public static void main ( String [] args ) { 8 try { JAXBContext context = JAXBContext. newinstance ( Frau. class ); 10 Marshaller marshaller = context. createmarshaller (); 12 marshaller. setproperty ( Marshaller. JAXB_FORMATTED_OUTPUT, true ); 14 Frau frau = new Frau (); frau. setgeburtsdatum (" "); marshaller. marshal (frau, System. out ); 18 } catch ( Exception e) { 20 e. printstacktrace (); } 22 } } Die in Schemakompiler automatisch erzeugte Frau.java Klasse (Listing 4.28) ist aber noch nicht für die Serialisierung vorbereitet und muss leicht angepasst werden. Eine Zeile muss noch eingefügt werden (siehe Listing 4.21) - die vollständige Klasse ist in Listing 4.35 zu finden. Ohne die Angabe Annotation kann das Serialisieren nicht funktionieren. Auch ohne Angabe von JAXB-Annotationen in der Frau Klasse kann die Serialisierung auskommen, nur die setter-methoden und Annotation müssen vorhanden

77 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 73 sein public class Frau { 4... } Listing Angepasste Frau.java Bei der Transformation können kein oder alle Java Attribute über die setter- Methoden mit Inhalten belegt werden - es wird immer eine XML-Datei erstellt. Wenn aber die XML-Datei auch validiert werden muss, dann müssen in Java die Wertebelegungen und die JAXB Annotationen entsprechend dem XML-Schema erfolgen. Im Beispiel hier müssen wegen <xs:sequence> alle im XML-Schema definierten Elemente und Attribute initialisiert werden. In der Serialisierer Klasse wird auch die Validierung der XML Datei implementiert (Listing 4.22). Die Validierung der XML Daten beim Seralisieren gleicht der Validierung beim Deserialisieren. In beiden Fällen wird eine XML-Datei durch ein XML-Schema auf Gültigkeit überprüft. Listing Für die Validierung angepasste Serialisierer.java import java. io. File ; import javax. xml. validation. Schema ; 4 import javax. xml. validation. SchemaFactory ;... 6 public class Serialisierer {... 8 SchemaFactory sf = SchemaFactory. newinstance ( javax. xml. XMLConstants. W3C_XML_SCHEMA_NS_URI ); 10 Schema schema = sf. newschema ( new File (" Frau. xsd ")); 12 marshaller. setschema ( schema ); // unmarshaller. setschema ( schema );// beim Deserialisierer Frau frau = new Frau (); 16 frau. sethaustier (" rexi "); frau. setgeburtsdatum (" "); 18 frau. setvisitenkarte (" D:\ visitenkarte. doc "); frau. setname (" Stephie Müller "); } Das hier benutzte XML-Schema aus Listing 4.27 ist aber für die Validierung noch nicht ausreichend. Eine Zeile mit der Angabe des komplexen Datentyps Frau als <xs:element> (siehe Listing 4.23) fehlt noch. Im Kapitel Schemagenerator wurde bereits gezeigt, wie diese Zeile durch Anpassung der ObjectFactory Klasse auch automatisch generiert werden kann. Listing Für die Validierung angepasste Frau.xsd <xs : schema version ="1.0" xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> <xs : element name =" frau " type =" Frau " /> 4 <xs : complextype name =" Frau ">...

78 74 P. Radinski Deserialisieren Beim Deserialisieren (Unmarshalling) werden XML Dateien in Java Objekte transformiert. Die XML Dateien können auf derselben Art wie in Kapitel Serialisieren auf Gültigkeit überprüft werden und ein ANT-Skript ist ebenfalls nicht notwendig. Die Java Klassen können direkt oder bei einer umfangreicheren Anwednung über die ObjectFactory Klasse instanziert werden. Für das Deserialisieren sind eine so genannte Deserialisierer Klasse, mindestens eine Java Klasse mit JAXB Annotationen und eine XML-Datei erforderlich. Die XML Daten werden dann nach der Deserialisierung als strukturierte Java Objekte bereitgestellt. Im Beispiel werden die in Kapitel als Ergebnis des Serialisierens erzeugte XML Datei (Listing 4.37) und die angepasste Frau.java (Listing 4.35) benutzt. Eine ObjectFactory Klasse wird nicht verwendet. Es wird überprüft, ob die Daten, die vorher in eine XML-Datei ausgegeben wurden, korrekt wieder in Java eingelesen werden können. Im Gegenteil zum Serialisieren werden hier alle JAXB-Annotationen in der Frau Klasse gebraucht, ansonsten werden die Java Attribute mit dem Wert null belegt. Hier sind nur die getter-methoden wichtig, die Anwendung kommt auch ohne die setter-methoden aus. Die Deserialisierer Klasse ist ähnlich wie die Serialisierer Klasse aufgebaut. Am Anfang wird durch ein JAXBContext ein Unmarshaller Objekt erzeugt, das die XML-Datei einliest. Über die getter-methoden der Frau Klasse werden die XML-Daten in Java angebunden. Listing Deserialisierer.java 1 import java. io. File ; 2 import javax. xml. bind. JAXBContext ; import javax. xml. bind. Unmarshaller ; 4 public class Deserialisierer { 6 public static void main ( String [] args ) { 8 try { 10 JAXBContext context = JAXBContext. newinstance ( Frau. class ); Unmarshaller unmarshaller = context. createunmarshaller (); 12 Frau frau = ( Frau ) unmarshaller. unmarshal ( new File ( 14 " frau. xml ")); 16 System. out. println (" Frau : " + frau. getname ()); 18 } catch ( Exception e) { e. printstacktrace (); 20 } } 22 } Die Validierung der XML-Datei wird in der Deserialisierer Klasse implementiert. Dabei muss das im Kapitel Serialisieren angepasste XML-Schema (Listing 4.23) benutzt werden - also mit der Angabe <xs:element> für den komplexen Datentyp Frau. Im Gegenteil zum Serialisieren müssen hier nicht unbedingt alle getter-methoden benutzt werden, weil sie keine Auswirkung auf die XML-Datei haben. Über die setter-methoden können die aus XML eingelese-

79 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 75 nen Daten überschrieben werden. In Listing 4.22 wurde bereits gezeigt, wie die Validierung funktioniert. Beim Deserialisieren wird nur Zeile 6 - wie im Listing angepasst. Listing Validierung beim Deserialisieren SchemaFactory sf = SchemaFactory. newinstance ( javax. xml. XMLConstants. W3C_XML_SCHEMA_NS_URI ); 4 Schema schema = sf. newschema ( new File (" Frau. xsd ")); 6 unmarshaller. setschema ( schema );... 8 // getter - Methoden JAXB Beispiel In diesem Kapitel wird anhand eines frei gewählten Modells veranschaulicht, wie der JAXB Ansatz sich in die Modellbasierte Softwareentwicklung integrieren lässt. Am Anfang dieser Seminararbeit wurde die Frage gestellt, wie JAXB die Bindung zwischen Java und XML herstellen kann - diese Frage wurde ausführlich in den vorausgegangenen Kapitel mit zahlreichen Beispielen beantwortet und das Ergebnis wird hier mit einem im Vergleich zu den vorherigen, komplizierteren Beispiel untermauert. Es wird nun eine Java Anwendung vorgestellt (siehe Abbildung 2), die Deterministische Endliche Automaten (DEAs) einliest, sie ausführt und das Ergebnis ausgibt. Die Definition eines DEAs ist wie folgt vorgegeben: ein DEA hat Zustände, Übergänge und eine Eingabe. Ein Zustand wird durch ein Zeichen repräsentiert und kann ein Startzustand, ein Endzustand oder ein sonstiger Zustand sein. Ein Übergang wird durch ein Tripel (Quelle-Zustand, Buchstabe aus Alphabet, Ziel-Zustand) dargestellt, wobei die Elemente des Tripels jeweils aus einzelnen Zeichen bestehen. Die Eingabe des DEAs ist eine beliebige Folge aus Buchstaben des Alphabets und wird entweder mitgeliefert oder in der Anwendung zur Laufzeit eingegeben. Die Grundregeln eines DEAs dürfen nicht verletzt werden. Das Alphabet darf keine Schnittmenge mit den Zuständen bilden und die Übergänge müssen eindeutig sein. Es wird von einem gültigen DEA ausgegangen, deshalb muss das Alphabet zur Überprüfung nicht mitgeliefert werden. Im Beispiel werden der tatsächliche DEA (sein Modell - siehe Abbildung 3) in einer XML Datei Dea.xml (Listing 4.44) und die Vorgaben für seine Gültigkeitsüberprüfung (sein MetaModell) in einem XML-Schema Dea.xsd (Listing 4.43) gespeichert. Beide Dateien stellen die Eingabe des Programms dar. Die Anwendung hier ist zum größten Teil auf der DEA-Definition in Dea.xsd aufgebaut. Es ist aber auch möglich, dass eine Schnittstelle definiert wird, so dass über vorgegebenen Methoden auf die Daten des DEAs zugegeriffen wird - so können auch unterschiedliche XML-Schemata eingelesen werden. Wenn hier ein XML- Schema geliefert wird, das denselben Aufbau wie in Dea.xsd hat, aber auch noch

80 76 P. Radinski Abbildung 2. DEA Beispiel Ablauf das Alphabet des DEAs beinhaltet, stellt das für die Anwendung kein Problem dar, denn die nötigen Daten können trotzdem eingelesen werden. Beim ersten Schritt wird dem SchemaKompiler.xml (Listing 4.42) die Dea.xsd übergeben. Bei der Modelltransformation entstehen folgende Klassen - Dea.java (Listing 4.46), Eingabe.java (Listing 4.47), ObjectFactory.java (Listing 4.48), Zustaende.java (Listing 4.51), Zustand.java (Listing 4.52), Uebergaenge.java (Listing 4.49) und Uebergang.java (Listing 4.50). Diese Klassen sind die äußere Bean-Hülle und werden dann für die Bindung der XML Daten verwendet. Im nächsten Schritt werden in der Deserialisierer.java (Listing 4.53) Klasse diese automatisch generierten Klassen über ein Unmarshaller-Objekt für das Einlesen der XML Daten benutzt. Außerdem findet in der Deserialisierer Klasse die Validierung der eingelesenen Dea.xml durch die Dea.xsd und die Anbindung der Anwendungslogik DEA_Engine.java (Listing 4.45) statt. Nach dem Ausführen des Programms (Deserialisierer.java) mit einer beliebigen Zeichenfolge als Eingabe, die in der Dea.xml mitgeliefert wird, wird entweder akzeptiert oder nicht akzeptiert

81 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 77 Abbildung 3. DEA Beispiel ausgegeben. Falls die Gültigkeitsüberprüfung der XML-Datei fehlschlägt, wird eine detaillierte Fehlermeldung angezeigt. 3 Schluss In dieser Seminararbeit wurde gezeigt, dass JAXB an sich sehr flexibel und vielseitig ist. Durch geringe Änderungen am Quellcode können verschiedene Erweiterungen eingefügt werden. Diese Erweiterungen wären bestimmt nicht notwendig, wenn die dargestellten Beispiele von Anfang an umfangreicher und komplizierter eingeplant wären. So wäre aber die Flexibilität von JAXB nicht eindeutig zum Vorschein gekommen und es hätte sich nicht gezeigt, wie einfach es ist, diese Erweiterungen einzubauen. Insgesamt erweist sich JAXB als eine sehr gute Alternative im Vergleich zu den parser-basierten Verfahren (SAX, DOM und Pull API), XML an Java anzubinden. Seit der Version 2.0 wurden erhebliche Verbesserungen erreicht, die einen großen Vorteil mit sich bringen, nämlich die bidirektionale Bindung zwischen den beiden Technologien Java und XML. Damit wurde der Weg freigemacht, XML als die Schnittstelle für Datentransfer zwischen Java Anwendungen einzusetzen. Im Sinne der Modellbasierten Softwareentwicklung ermöglicht JAXB eine vollständige und korrekte bidirektionale Modelltransformation zwischen Java und XML. Besonders bei den Service Orientierten Architekturen wird eine einfache und flexible Technologie gebraucht, um verschiedene Java Anwendungen bzw. Java Web Services anzubinden. JAXB ist diese Technologie. 4 Anhang 4.1 Schemakompiler 1 <? xml version ="1.0"? > 2 <project default =" xjc " basedir ="." > Listing SchemaKompiler.xml

82 78 P. Radinski Abbildung 4. Schemakompiler in Ecipse 4 <path id=" classpath "> <fileset dir =" C:\ Sun \ jaxb -ri \ lib " includes ="*. jar " /> 6 <fileset dir =" C:\ Program Files \ Java \ jdk1.6.0 _07 \ lib " includes ="*. jar " /> 8 </path > 10 <taskdef name =" xjc " classname =" com. sun. tools. xjc. XJCTask " classpathref =" classpath " /> 12 <target name =" xjc "> 14 <xjc destdir ="." > <schema dir =" schema "> 16 <include name =" Frau. xsd " /> </ schema > 18 </xjc > </ target > 20 </ project > Listing Frau.xsd 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <xs : schema version ="1.0" xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> <xs : complextype name =" Frau "> 4 <xs : sequence > <xs : element name =" Geburtsdatum " type =" xs : string " 6 minoccurs ="1" maxoccurs ="1" /> <xs : element name =" Visitenkarte " type =" xs : string " /> 8 <xs : element name =" Haustier " type =" xs : string " default =" Hund " /> </ xs : sequence > 10 <!-- interessant ist, dass attribut vor sequence verboten ist --> <xs : attribute name =" Name " type =" xs : string " use =" required "/ > 12 </ xs : complextype > </ xs : schema > Listing Frau.java

83 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 79 1 // 2 // This file was generated by the JavaTM Architecture for XML Binding ( JAXB ) Reference Implementation, vh // See <a href =" http :// java. sun. com / xml / jaxb "> http :// java. sun. com / xml /jaxb </a> 4 // Any modifications to this file will be lost upon recompilation of the source schema. // Generated on: at 05:10:57 PM CET 6 // 8 package generated ; 10 import javax. xml. bind. annotation. XmlAccessType ; 12 import javax. xml. bind. annotation. XmlAccessorType ; import javax. xml. bind. annotation. XmlAttribute ; 14 import javax. xml. bind. annotation. XmlElement ; import javax. xml. bind. annotation. XmlType ; /** * <p> Java class for Frau complex type. 20 * * <p>the following schema fragment specifies the expected content contained within this class. 22 * * <pre > 24 * & lt; complextype name =" Frau "> * & lt; complexcontent > 26 * & lt; restriction base ="{ http :// www. w3. org /2001/ XMLSchema } anytype "> * < sequence > 28 * < element name =" Geburtsdatum " type ="{ http :// /2001/ XMLSchema } string "/ > * < element name =" Visitenkarte " type ="{ http :// /2001/ XMLSchema } string "/ > 30 * < element name =" Haustier " type ="{ http :// /2001/ XMLSchema } string "/ > * &lt ;/ sequence > 32 * < attribute name =" Name " use =" required " type ="{ http :// /2001/ XMLSchema } string " /> * &lt ;/ restriction > 34 * & lt ;/ complexcontent > * &lt ;/ complextype > 36 * </pre > * 38 * */ ( XmlAccessType. FIELD ( name = " Frau ", proporder = { 42 " geburtsdatum ", " visitenkarte ", 44 " haustier " }) 46 public class Frau { ( name = " Geburtsdatum ", required = true ) protected String geburtsdatum ; ( name = " Visitenkarte ", required = true ) protected String visitenkarte ; ( name = " Haustier ", required = true, defaultvalue = " Hund ") protected String haustier ; ( name = " Name ", required = true ) protected String name ; 56 /** 58 * Gets the value of the geburtsdatum property. * 60 * possible object is 62 * String } * 64 */ public String getgeburtsdatum () { 66 return geburtsdatum ; } 68

84 80 P. Radinski /** 70 * Sets the value of the geburtsdatum property. * 72 value * allowed object is 74 * String } * 76 */ public void setgeburtsdatum ( String value ) { 78 this. geburtsdatum = value ; } 80 /** 82 * Gets the value of the visitenkarte property. * 84 * possible object is 86 * String } * 88 */ public String getvisitenkarte () { 90 return visitenkarte ; } 92 /** 94 * Sets the value of the visitenkarte property. * 96 value * allowed object is 98 * String } * 100 */ public void setvisitenkarte ( String value ) { 102 this. visitenkarte = value ; } 104 /** 106 * Gets the value of the haustier property. * 108 * possible object is 110 * String } * 112 */ public String gethaustier () { 114 return haustier ; } 116 /** 118 * Sets the value of the haustier property. * 120 value * allowed object is 122 * String } * 124 */ public void sethaustier ( String value ) { 126 this. haustier = value ; } 128 /** 130 * Gets the value of the name property. * 132 * possible object is 134 * String } * 136 */

85 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 81 public String getname () { 138 return name ; } 140 /** 142 * Sets the value of the name property. * 144 value * allowed object is 146 * String } * 148 */ public void setname ( String value ) { 150 this. name = value ; } 152 } Listing ObjectFactory.java 1 // 2 // This file was generated by the JavaTM Architecture for XML Binding ( JAXB ) Reference Implementation, vh // See <a href =" http :// java. sun. com / xml / jaxb "> http :// java. sun. com / xml /jaxb </a> 4 // Any modifications to this file will be lost upon recompilation of the source schema. // Generated on: at 05:10:57 PM CET 6 // package generated ; import javax. xml. bind. annotation. XmlRegistry ; 14 /** * This object contains factory methods for each 16 * Java content interface and Java element interface * generated in the generated package. 18 * <p>an ObjectFactory allows you to programatically * construct new instances of the Java representation 20 * for XML content. The Java representation of XML * content can consist of schema derived interfaces 22 * and classes representing the binding of schema * type definitions, element declarations and model 24 * groups. Factory methods for each of these are * provided in this class. 26 * */ public class ObjectFactory { /** * Create a new ObjectFactory that can be used to create new instances of schema derived classes for 34 * */ 36 public ObjectFactory () { } 38 /** 40 * Create an instance of Frau } * 42 */ public Frau createfrau () { 44 return new Frau (); } 46 }

86 82 P. Radinski 4.2 Schemagenerator Abbildung 5. Schemagenerator in Eclipse Listing SchemaGenerator.xml 1 <? xml version ="1.0"? > 2 <project name =" Frau " default =" schemagen " basedir ="." > 4 <path id=" classpath "> <fileset dir =" C:\ Sun \ jaxb -ri \ lib " includes ="*. jar " /> 6 <fileset dir =" C:\ Program Files \ Java \ jdk1.6.0 _07 \ lib " includes ="*. jar " /> 8 </path > 10 <taskdef name =" schemagen " classname =" com. sun. tools. jxc. SchemaGenTask " 12 classpathref =" classpath "> </ taskdef > 14 <target name =" schemagen "> 16 <schemagen destdir =" schemafolder " srcdir =" src " classpathref =" classpath "> 18 </ schemagen > </ target > 20 </ project > Listing Frau.java 1 Dieselbe Klasse wie in Schemakompiler! Listing ObjectFactory.java 1 Dieselbe Klasse wie in Schemakompiler!

87 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 83 Listing Schema1.xsd 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <xs : schema version ="1.0" xmlns : xs =" http :// www. w3. org /2001/ XMLSchema "> 4 <xs : complextype name =" Frau "> <xs : sequence > 6 <xs : element name =" Geburtsdatum " type =" xs : string "/ > <xs : element name =" Visitenkarte " type =" xs : string "/ > 8 <xs : element name =" Haustier " type =" xs : string " default =" Hund "/ > </ xs : sequence > 10 <xs : attribute name =" Name " type =" xs : string " use =" required "/ > </ xs : complextype > 12 </ xs : schema > 4.3 Serialisieren Abbildung 6. Serialisieren in Eclipse 1 import javax. xml. bind. JAXBContext ; 2 import javax. xml. bind. Marshaller ; 4 public class Serialisierer { Listing Serialisierer.java 6 public static void main ( String [] args ) { 8 try { JAXBContext context = JAXBContext. newinstance ( Frau. class ); 10 Marshaller marshaller = context. createmarshaller (); 12 marshaller. setproperty ( Marshaller. JAXB_FORMATTED_OUTPUT, true ); 14 Frau frau = new Frau (); 16 frau. setgeburtsdatum (" ");

88 84 P. Radinski 18 frau. sethaustier (" rexi "); frau. setname (" Stephie Müller "); 20 marshaller. marshal (frau, System. out ); 22 } catch ( Exception e) { 24 e. printstacktrace (); } 26 } } Listing Frau.java 1 // 2 // This file was generated by the JavaTM Architecture for XML Binding ( JAXB ) Reference Implementation, vh // See <a href =" http :// java. sun. com / xml / jaxb "> http :// java. sun. com / xml /jaxb </a> 4 // Any modifications to this file will be lost upon recompilation of the source schema. // Generated on: at 07:16:25 PM CET 6 // 8 10 import javax. xml. bind. annotation. XmlAccessType ; 12 import javax. xml. bind. annotation. XmlAccessorType ; import javax. xml. bind. annotation. XmlAttribute ; 14 import javax. xml. bind. annotation. XmlElement ; import javax. xml. bind. annotation. XmlRootElement ; 16 import javax. xml. bind. annotation. XmlType ; 18 /** 20 * <p> Java class for Frau complex type. * 22 * <p>the following schema fragment specifies the expected content contained within this class. * 24 * <pre > * & lt; complextype name =" Frau "> 26 * & lt; complexcontent > * < restriction base ="{ http :// /2001/ XMLSchema } anytype "> 28 * & lt; sequence > * < element name =" Geburtsdatum " type ="{ http :// /2001/ XMLSchema } string "/ > 30 * < element name =" Visitenkarte " type ="{ http :// /2001/ XMLSchema } string "/ > * < element name =" Haustier " type ="{ http :// /2001/ XMLSchema } string "/ > 32 * &lt ;/ sequence > * < attribute name =" Name " use =" required " type ="{ http :// /2001/ XMLSchema } string " /> 34 * &lt ;/ restriction > * & lt ;/ complexcontent > 36 * &lt ;/ complextype > * </pre > 38 * * 40 // Das muss manuell hinzugefügt werden, ansonsten wie in Schemakompiler! ( XmlAccessType. FIELD ) ( name = " Frau ", proporder = { " geburtsdatum ", 46 " visitenkarte ", " haustier " 48 }) 50 public class Frau { ( name = " Geburtsdatum ", required = true ) protected String geburtsdatum ; ( name = " Visitenkarte ", required = true )

89 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 85 protected String visitenkarte ; ( name = " Haustier ", required = true, defaultvalue = " Hund ") protected String haustier ; ( name = " Name ", required = true ) protected String name ; 60 /** 62 * Gets the value of the geburtsdatum property. * 64 * possible object is 66 * String } * 68 */ public String getgeburtsdatum () { 70 return geburtsdatum ; } 72 /** 74 * Sets the value of the geburtsdatum property. * 76 value * allowed object is 78 * String } * 80 */ public void setgeburtsdatum ( String value ) { 82 this. geburtsdatum = value ; } 84 /** 86 * Gets the value of the visitenkarte property. * 88 * possible object is 90 * String } * 92 */ public String getvisitenkarte () { 94 return visitenkarte ; } 96 /** 98 * Sets the value of the visitenkarte property. * 100 value * allowed object is 102 * String } * 104 */ public void setvisitenkarte ( String value ) { 106 this. visitenkarte = value ; } 108 /** 110 * Gets the value of the haustier property. * 112 * possible object is 114 * String } * 116 */ public String gethaustier () { 118 return haustier ; } 120 /** 122 * Sets the value of the haustier property.

90 86 P. Radinski * 124 value * allowed object is 126 * String } * 128 */ public void sethaustier ( String value ) { 130 this. haustier = value ; } 132 /** 134 * Gets the value of the name property. * 136 * possible object is 138 * String } * 140 */ public String getname () { 142 return name ; } 144 /** 146 * Sets the value of the name property. * 148 value * allowed object is 150 * String } * 152 */ public void setname ( String value ) { 154 this. name = value ; } 156 } Listing ObjectFactory.java 1 Dieselbe Klasse wie in Schemakompiler! Listing Ausgabe Serialisierer.java 1 <? xml version ="1.0" encoding =" UTF -8" standalone =" yes "? > 2 <frau Name =" Stephie Müller "> <Geburtsdatum > </ Geburtsdatum > 4 <Haustier >rexi </ Haustier > </frau > 4.4 Deserialisieren 1 import java. io. File ; 2 import javax. xml. bind. JAXBContext ; 4 import javax. xml. bind. Unmarshaller ; 6 public class Deserialisierer { Listing Deserialisierer.java 8 public static void main ( String [] args ) { 10 try {

91 Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 87 Abbildung 7. Deserialisieren in Eclipse JAXBContext context = JAXBContext. newinstance ( Frau. class ); 12 Unmarshaller unmarshaller = context. createunmarshaller (); 14 Frau frau = ( Frau ) unmarshaller. unmarshal ( new File ( 16 " frau. xml ")); 18 System. out. println (" Frau : " + frau. getname ()); System. out. println (" Geboren am: " + frau. getgeburtsdatum ()); 20 System. out. println (" Tier : " + frau. gethaustier ()); 22 } catch ( Exception e) { e. printstacktrace (); 24 } } 26 } Listing Frau.java 1 Dieselbe Klasse wie in Serialisieren! Listing ObjectFactory.java 1 Dieselbe Klasse wie in Schemakompiler! 1 Frau : Stephi Müller 2 Geboren am: Tier : rexi Listing Ausgabe Deserialisierer 4.5 JAXB Beispiel

92 88 P. Radinski Abbildung 8. JAXB Beispiel in Eclipse 1 <? xml version ="1.0"? > 2 <project default =" xjc " basedir ="." > Listing SchemaKompiler.xml 4 <path id=" classpath "> <fileset dir =" C:\ Sun \ jaxb -ri \ lib " includes ="*. jar " /> 6 <fileset dir =" C:\ Program Files \ Java \ jdk1.6.0 _07 \ lib " includes ="*. jar " /> 8 </path > 10 <taskdef name =" xjc " classname =" com. sun. tools. xjc. XJCTask " classpathref =" classpath " /> 12 <target name =" xjc "> 14 <xjc destdir ="." > <schema dir =" schema "> 16 <include name =" Dea. xsd " /> </ schema > 18 </xjc > </ target > 20 </ project >