Universität Augsburg Institut für Informatik Programmierung … › lehrstuehle › swt › ... · 2017-01-10 · Universität Augsburg Institut für Informatik Programmierung verteilter

Universität AugsburgInstitut für InformatikProgrammierung verteilter Systeme

Modellbasierte SoftwareentwicklungWS 2008/2009

SeminarbandProf. Dr. Bernhard BauerDipl.-Inf. Benjamin HonkeDipl.-Inf. Stefan FennDipl.-Inf. Raphael RomeikatDipl.-Inf. Christian Saad

Vorwort

Dieser Band enthält die studentischen Arbeiten des Seminars ’ModellbasierteSoftwareentwicklung’, das im Wintersemester 2008 / 2009 and der UniversitätAugsburg abgehalten wurde.In der ersten Arbeit wurde von Phillip Stadler auf die Grundlagen der modellba-sierten Softwareentwicklung eingegangen. Neben den grundlegenden Technikenwie Metamodellierung wird dabei auch der konkrete Einsatz, z.B. im GebietModel-Driven Engineering, behandelt.Das zweite Thema, bearbeitet von Markus Bickelmaier, erörtert die Grundlagenmodellbasierter Testfallgenerierung. Ziel ist es dabei Tests auf Modellebene durch-zuführen um bereits auf diesem abstrakten Level das Verhalten zu untersuchenund potentielle Fehler feststellen zu können.Die Arbeit von Robert Freudenreich untersucht Entwicklungsprozesse im Kontextdes Eclipse Process Framework (EPF). Dabei wird auf dessen Anwendungsberei-che anhand verschiedener Prozessmodelle eingegangen und die Erweiterbarkeitanhand einer Fallstudie illustriert.Panayot Radinski geht im nächsten Thema detailliert auf die BindingtechnikJAXB ein die einen Datentransfer zwischen XML und Java ermöglicht.In der letzten Seminararbeit die von Matthias Drexl und Maximilian Koch ge-meinsam erstellt wurde werden verschiedene Notationen für die Modellierungvon Geschäftsregeln vorgestellt und evaluiert sowie im Rahmen einer Fallstudienäher beleuchtet.

April 2009 Die Editoren

Inhaltsverzeichnis

Einführung in die modellbasierte Softwareentwicklung . . . . . . . . . . . . . . . . . 1

Grundlagen der modellbasierten Testfallgenerierung . . . . . . . . . . . . . . . . . . . 18

Evaluierung der Potentiale des Eclipse Process Frameworks . . . . . . . . . . . . 34

Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) . . . . . . 54

Modellierung von Geschäftsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

IV

Einführung in die modellbasierteSoftwareentwicklung

Philipp Stadler

Universität [email protected]

Zusammenfassung Die Softwareentwicklung hat in den letzten Jahr-zehnten immer mehr an Bedeutung gewonnen. Um im Gegenzug dazudie Komplexität, den Aufwand und die damit verbundenen Kosten ineinem moderaten Bereich zu halten bedient man sich unter anderem demHilfsmittel der modellbasierten Softwareentwicklung. Im Rahmen dieserArbeit soll nun eine Einführung in die modellbasierte Softwareentwicklunggegeben werden und auf die Modelle, die Metamodelle und Modellierungsowie auf Anwendungsszenarien eingegangen werden.

1 Einleitung und Motivation

Frederick P. Brooks, einer der großen Informatik Pioniere, unter anderem Leiterder System/360 - Entwicklung und des OS/360 - Projektes von IBM, sowieausgezeichnet mit dem Turing-Preis, schrieb 1986 in seinem Essay No SilverBullet: 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 straightfor-ward, but is capable of becoming a monster of missed schedules, blownbudgets, and flawed products. So we hear desperate cries for a silverbullet–something to make software costs drop as rapidly as computerhardware costs do. [1, S.1]

Nach Brooks können Softwareprojekte also unberechenbare Monster sein, beidenen Zeit und Kostenplan vollkommen aus dem Ruder laufen können. Somitsucht man natürlich nach dem magischen Tool, also nach der Silver Bullet, mitder sich Kosten und Aufwand senken lassen könnten. Die Standish Group hat1994 den ersten CHAOS-Bericht herausgebracht.Im Jahre 1994 haben sich, laut dem bereits genannten Bericht, 31,1 Prozent allerin diesem Jahr gestarteten IT-Projekte als komplette Fehlplanungen erwiesen.Während dieser Untersuchung wurden mehr als 100.000 IT-Projekte in den USAuntersucht.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 herausgefunde-nen Verbesserungen, bezogen auf die Softwareentwicklung, mit der modellgetrie-benen Softwareentwicklung?

2 P. Stadler

Kategorie 1994 2004 Veränderungsuccessful 16% 34% Verdopplungchallenged 53% 51% wenigfailed 31% 15% Halbierung

Tabelle 1. Ergebnisse des CHAOS - Reports

Die modellgetriebene Softwareentwicklung, bzw. Model Driven Software Develop-ment, kurz MDSD, befasst sich mit der Automatisierung der Softwareherstellung.Mit Hilfe dieser werden Modelle nicht nur als Dokumente verwendet, sie könnenmit dem Code gleichgesetzt werden.Es wäre jetzt etwas übertrieben zu behaupten, dass man es allein den verschie-denen Forschungsgebieten innerhalb der Softwareentwicklung, zu dem auch dieMDSD gehört, zu verdanken hätte, dass sich die Werte welche durch die StandishGroup ermittelt wurden verbessert haben.Es wird sich aber zeigen, dass man durch den Ansatz der modellgetriebenenSoftwareentwicklung Fehlerquellen schon von vornherein, also z.B. in der Analysebzw. Planungs- und Simulationsphase, dezimieren kann. Dadurch, dass Fehler inden meisten Fällen mit einem Kostenaufwand verbunden sind kann auch davonausgegangen werden, dass sich dieser wohl ebenso verringern lassen könnte.Das international tätige IT-Marktforschungs- und Beraterunternehmen IDC (In-ternational Data Corporation www.idc.com) hat in ihrer Abschlussstudie 2008für den deutschen IT-Markt eine etwas düstere Prognose für die ersten zweiQuartale 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 denZeitraum bis 2012 analysiert. Ob und inwieweit Softwareentwicklungsschmieden,welche sich mit der modellgetriebenen Softwareentwicklung beschäftigen, davonprofitieren können lässt sich an dieser Stelle leider nicht fundiert feststellen.Frei nach der deutschen Redewendung Wer kein Ziel hat, kann auch keinserreichen stellt sich hier auch die Frage welche motivierenden Ziele die modellge-triebene Softwareentwicklung nun verfolgt [9, 6].

Erhöhung der Entwicklungsgeschwindigkeit: durch Automation kann ausformalen Modellen in einem oder mehreren Transformationsschritten lauffä-higer Code generiert werden.

Einsatz von Transformationen: Qualitätssteigerung in der Softwareentwick-lung, die auch eine Steigerung der Softwarequalität zur Folge haben kann.

Dealing with complexity: durch verschiedene Abstraktionsebenen kann undsoll die Komplexität besser gehandhabt werden.

Standardisierung: die Object Management Group strebt mit der MDA, derModell Driven Architecture, eine Standardisierungsrichtung an mit der v.a.eine plattformunabhängige Herstellerunabhängigkeit erziehlt werden kann.

Einführung in die modellbasierte Softwareentwicklung 3

Mit diesen, mitunter allgemein gehaltenen, Fragen haben die Entwickler, Forscherund Wissenschaftler rund um das Gebiet der modellbasierten Softwareentwick-lung das Rad natürlich nicht neu erfunden. Dies sind grundlegende Fragen undZiele wie sie überall in der Informationstechnik zu finden sind. Daher stellt diesnur eine weiter Bestätigung derer dar.In dieser Arbeit sollen nun die Grundlagen über Modelle (Kap. 3.1) der modell-basierten Softwareentwicklung (Kap. 3.2) erläutert werden. Aufbauend auf diesenwerden ausgewählte Details der modellbasierten Softwareentwicklung und derMDA (Kap. 3.3) herrausgearbeitet, Anwendungen erörtert (Kap. 4) und zuletztein Blick auf die gegenwärtige Nutzung und Forschung (Kap. 5) geworfen.

2 Metamodelle und Metamodellierung

Metamodellierung ist eine Konkatenation aus den beiden Worten Modellierungund meta. Das griechische Wort meta bedeutet so viel wie zwischen, neben, überund nach. Also sind Metamodelle, schlicht gesagt, Modelle von Modellen, daMetamodelle 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 - esdefiniert damit in abstrakter Weise die Konstrukte einer Modellierungs-sprache, ihre Beziehungen untereinander sowie Einschränkungen bzw.Modellierungsregeln, nicht jedoch die konkrete Syntax dieser Sprache.

Man benötigt konsequenterweise eine (Meta-)Modellierungssprache, welche wie-derum durch ein (Meta-)Modell beschrieben wird. Nach Stahl et. al. definiertein Metamodell also die abstrakte Syntax, sowie die statische Semantik einer(Modellierungs-)Sprache. Syntax und Semantik von Metamodellen wird in Kapitel2.1 näher beschrieben. Im Umkehrschluss hat jede formale Sprache (wie z.B. Javaoder 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 einerInstanz. Dies bedeutet, dass jedes Modell die Instanz eines Metamodells ist. EineHerausforderung bei den Metamodellen besteht darin eine Modellierungssprachefür sie zu definieren.

4 P. Stadler

Es ist prinzipiell möglich Modelle in einer beliebigen Modellierungssprache zubeschreiben. Der jeweilige Ausgangspunkt bei der Modellierung in der modellba-sierten 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-)Sprachenötig sind, zur Verfügung stehen.Abbildung 2, welche offiziel von der OMG definiert wurde, zeigt die vier Meta-schichten der OMG [9]:

Abbildung 2. Die vier Metaschichten der OMG

Eine Instanz während der Laufzeit der Klasse Person mit den dazugehörigenAttributen des Modells M1 ist in diesem Beispiel der Typ Person mit dem NamenVölter.Der Classifier des Metamodells-M2 bekommt den Namen des zu beschreibendenModells, hier Name: Klasse von M1 (Typ).Die Schicht M3 ist die Abstraktionsschicht der MOF, welche dazu benötigt wirddie Metamodelle zu beschreiben. Sie wurde von der Object Management Groupinnerhalb der Meta Object Facility Architectur definiert.Die Meta Object Facility verwendet einerseits eine Teilmenge der UML und


andererseits wird sie zum Entwurf von Metamodellen verwendet.Die offizielle Spezifikation der MOF, Schicht M3 in Abb. 2, beinhaltet eineabstrakte Sprachbeschreibung und ein Basisgerüst, das MOF - Modell. Mit diesemkönnen plattformunabhängige Metamodelle erzeugt und spezifiziert werden.Um Metadaten innerhalb der MOF auszutauschen wurde von der OMG das XMIXML Metadata Interchange spezifiziert. Dieses Format erlaubt den Austauschvon 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 eineganze 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 betrach-ten.

1. die Modellierungsperspektive und2. die Datenperspektive

Bei der Modellierungsperspektive verläuft die Blickrichtung top-down entlangder Modellebenen. Hierbei kann die MOF entsprechende Informationsmodelleauf unterschiedlichen Ebenen für bestimmte Domänen definieren und diese an-schließend durch Implementierungs- und Softwareentwurfstätigkeiten im Rahmender Entwicklung nutzen.Die Datenperspektive legt ihren Fokus auf eine bestimmte Ebene eines gegebenenModells. Dadurch können z.B. Strukturen im Rahmen der CORBA (CommonObject Request Broker Architecture) Schnittstelle genutzt werden. Die CORBA -Schnittstelle wird auch von der OMG entwickelt und soll das Erstellen verteilterAnwendungen in einem homogenen Umfeld vereinfachen.Zusammenfassend muss man an dieser Stelle festhalten dass Metamodelle vonessentieller Wichtigkeit für die Beschreibung von Modellen sind.Sie dienen infolgedessen auch zu einer besseren Verständlichkeit und der Ver-gleichbarkeit von Modellen, da man sich bei beiden unterschiedlichsten Artenvon Modellen auf vergleichbare Eigenschaften etc. geeinigt hat, denn ohne einevergleichbare 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 Programmier-sprachen, mit der grammatikalischen Struktur der Metamodelle. Eine Sprache

6 P. Stadler

wird also durch ihre, nach ihren jeweils definierten Regeln, Konkatenation vonZeichen gebildet.Bei den Metamodellen wird zwischen konkreter und abstrakter Syntax unterschie-den. Die konkrete Syntax ist der Bereich, der vom Anwender bzw. Modelliererdirekt wahrgenommen und verarbeitet wird. Er stellt also eine spezifische Notati-on 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 Modellierungsspracheaber sie definiert nicht wie die abstrakte Syntax dem Enandwender präsentiertwird. Die abstrakte Syntax definiert jedoch die Notationskonventionen und Schlüs-selwö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, dieder 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 Realisierungeiner abstrakten Syntax ist. Hierbei ist die Tatsache besonders hervorzuheben,dass verschiedene konkrete Syntaxformen eine gemeinsame abstrakte Syntaxhaben können.Bei den Metamodellen unterscheidet man auch zwischen statischer und dynami-scher Semantik.Die dynamische Semantik ist der Teil der Modellierungssprache der während derProgrammausführung im Speicher existiert. So nimmt diese direkten Bezug aufdie Lebensdauer („Runtime“) bei der Ausführung von Programmabschnitten.Die statische Semantik setzt ihren Anspruch auf die Wohlgeformtheitsregeln derSprache.Dies können auf der einen Seite Deklarationen von Variablen, Übergabeparameteroder 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 Modellierungssprachenzu beschreiben, braucht man eine Sprache um diese Regeln oder Einschränkungen(bzw. Constraints) zu definieren. Diese Aufgabe übernimmt die Object ConstraintLanguage.Die Object Constraint Language (OCL) ist eine Erweiterung der Unified ModelingLanguage (UML) und ihre Standard-Abfragesprache. Ursprünglich wurde sie alseigene Technik entwickelt und ist inzwischen Teil des Object Management Groupbzw. OMG-Standards. Die Syntax der Object Constraint Language basiert teil-weise auf der objektorientierten Programmiersprache Smalltalk-80 und hat nebendieser weitgehend intuitiven Syntax auch Bestandteile aus der Prädikatenlogik.Die OCL dient hauptsächlich der Beschreibung von Bedingungen für die UMLNotationen, also Diagramme oder besser Klassendiagramme. Hier sind wiederumauch die Anteile der Prädikatenlogik ersichtlich, denn mit der OCL beschreibt


man Invarianten sowie Vor- und Nachbedingungen von Operationen und Metho-den. Die Object Constraint Language kommt, verglichen mit der UML relativwenig zum Einsatz. Der Grund hierfür liegt schätzungsweise darin, dass es vielenAnwendern schwerfällt eine texturelle Sprache innerhalb der visuellen SpracheUML zu verwenden.Die OCL ist, im Gegensatz zu Smalltalk-80, eine getypte Sprache.[7, 282] Nebenden Standard- und Basistypen gibt es noch die Tupel und Containertypen. Zusam-menfassend beschreibt die OCL 2.0 Spezifikation der Object Management Groupdie oft eingesetzten Datentypen wie String, Integer aber auch Aufzählungstypen.Sowie die jeweiligen Datentypen des zugrundeliegenden Modells. Dies bedeutetdass beispielsweise alle im UML-Modell definierten Typen auch in OCL bekanntsind.Jeder der aufgezählten Datentypen hat für ihn definierte Operationen.Die Aufzählung dieser würde den Umfang dieser Arbeit jedoch sprengen und sindauß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 alleBedingungen, also Constraints, erfüllen. Ist dies der Fall spricht man, in dertheoretischen Informatik, von einem Modell. Die Constraints, also Regeln undEinschränkungen zwischen verschiedenen Metaklassen machen neben den Metaat-tributen und Metaassoziationen einen großen Teil der Bedeutung des Metamodellsaus. Dies ist auch der Grund warum man sich überhaupt für die Spezifizierungder 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 dieabstrakte 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. DieseSpezifikation wird benötigt, da zwar mit MOF, UML und XMI die Standardi-sierung des Gebietes Modellierung relativ weit vorangeschritten ist, aber mitdiesen noch keine Standards für Transformationen gegeben sind. Hier kommt dieQuery View Transformation zum Tragen.[6] Diese Transformationen zwischenModellen ermöglichen beispielsweise eine Transformation von einem Klassenmo-dell zu einem ER-Modell. Die Object Management Group unterscheidet bei derSpezifizierung der QVT zwischen zwei Arten von Sprachen:

. deklarative und

. imperative

Der deklarative Teil der Spezifikation wurde von der OMG wiederum in dieTwo Level Declarative Architekture unterteilt. Diese beiden Layers (Schichten)sind zum einen die benutzerfreundliche Relations-Schicht und zum anderen derQVT-Core, welcher für den Endanwender meist weniger von Bedeutung ist.Zusätzlich zu dem deklarativen Teil, welcher im Grunde die selben semantischenInhalte nur auf unterschiedlichen Abstraktionsebenen darstellt, ist der imperativeTeil dazu da imperative Implementierungen aus Transformationen des QVT-Cores

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.http://www.omg.org/docs/formal/08-04-03.pdf

Abbildung 3. Relationships between QVT metamodells

Um die Kernaspekte einer Domäne, speziell ihre formalen Aspekte formalmodellierbar zu machen greift man auf das Konzept der domänenspezifischenSprache (DSL = Domain Specific Language) zurück. Diese DSL besitzt nun einMetamodell, welches eine, wie in (Kap. 2.1) beschriebene, statische Semantikund 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 Be-deutung geben.Genauer gesagt fehlt ihr eine dynamische Semantik, wie sie in (Kap. 2.1) be-schrieben wurde.Ob man synonym zu der Domain Specific Language nun Modellierungssprachesagt hängt ganz davon ab wie stark man vom Kontext der jeweiligen Domäneabhängig ist.[9]

3 Grundlagen

3.1 Modelle

Was ist unter Modellen und der dazugehörigen Modellierung überhaupt zu ver-stehen?An dieser Stelle soll nun Anspruch darauf gelegt werden einen formalen, wissen-schaftlichen Ansatz zu beschreiben.Der deutsche Philosoph Klaus D. Wüsteneck definierte 1963 [11] den BegriffModell folgendermaßen:

Ein Modell ist ein System, das als Repräsentant eines kompliziertenOriginals auf Grund mit diesem gemeinsamer, für eine bestimmte Aufgabe


wesentlicher Eigenschaften von einem dritten System benutzt, ausgewähltoder geschaffen wird, um letzterem die Erfassung oder Beherrschung desOriginals zu ermöglichen oder zu erleichtern, beziehungsweise um es zuersetzen.

So wird ersichtlich, dass Modelle dazu dienen sollen einerseits die Realität ab-zubilden und andererseits zwischen verschiedenen Wahrnehmungsdimensioneninnerhalb eines bestimmten Abstraktionslevels zu vermitteln. Es ergibt sich alsodie 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ärungder Realität.Nun kann man, nach Stachowiak [8], die grundsätzliche Definition der Modellefolgendermaßen klassifizieren:

. Abbildungsmerkmale, welche das Modell als Abbildung des Originalen kenn-zeichnen

. Verkürzungsmerkmale, die die meist aus subjektiver Sicht betrachteten, re-levanten Merkmale eines realen Systems abbilden, um dem Modellierer einleichter 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 Modellie-rer selbst auf pragmatische Weise welche Orientierung und Zielgebundenheiter, dem Modell bezogen auf das Original beimisst.

In vielen Bereichen des alltäglichen Lebens ist man von Modellen umgeben ohnees überhaupt zu wissen. So ist z.B. eine Deutschlandkarte mit der dazugehörigenAgenda auch als ein Modell anzusehen, da die Karte innerhalb ihres Maßstabesbeispielsweise die wichtigen Verkehrspunkte Deutschlands klar und übersichtlichdarstellt.Neben der Anwendung von Modellen in der Softwareentwicklung findet sich dieseTechnik auch in der Wirtschaftsinformatik. Dazu gehören vor allem Geschäftspro-zessmodellierung und die Entity-Relationship Modellierung.Die Geschäftsprozessmodellierung kann hier einen sehr interessanten Einblickin die Arbeitsweise und Struktur eines Unternehmens bringen. Unternehmenkönnen die modellierten Geschäftsprozesse einerseits dafür nutzen die Wieder-verwendbarkeit von Prozessen zu garantieren. Diese Wiederverwendbarkeit kannz.B. gefordert werden durch den Umzug eines Produktionsstandortes oder durchAbgang von Wissensträgern im Unternehmen.Andererseits dient die Geschäftsprozessmodellierung auch der Präsentation desUnternehmens nach außen, also der Öffentlichkeitsarbeit.[3] Im Unternehmenist der Ausgangspunkt des Geschäftsprozesses in den meisten Fällen auch dasZiel. Dass das Ziel ungleich dem Ergebnis ist, kann durch einen Pfeil verdeutlichtwerden der beim Ziel beginnt und über eine Prozesskette zum Ergebnis gelangt.

Ziel → Prozesskette → Prozesskette → ..... → Prozesskette → Ergebnis

10 P. Stadler

In der Wirtschaftsinformatik sowie in der Softwareentwicklung ist das Was-serfallmodell und das Spiralmodell seit vielen Jahrzehnten ein Begriff.[2] Diefolgende Abbildung verdeutlicht dies.

Abbildung 4. Vorgehensweise der Softwareentwicklung: Wasserfall- und Spiralm-odell

Der durch die Abbildung schon ersichtliche Unterschied besteht darin, dass dasSpiralmodell während des Entwicklungsprozesses Möglichkeiten zur Interventionbietet. Würde man sich allein nach dem Wasserfallmodell richten wäre es wohlschwer einen während der Implementation enteckten Designfehler auszubessern,vorausgesetzt man würde sich alleine an dieses recht starre und theoretischeModell halten.

3.2 Modellbasierte Softwareentwicklung

Um das Gesamtkonzept der modellbasierten Softwareentwicklung zu verstehensollte man sich vor Auge halten dass das Ziel der MDSD darin besteht durcheine oder mehrere Transformationen ein Software-Produkt ganz oder teilweiseherzustellen.Bisher wurden Transformationen in Verbindung mit der Query View Transfor-mation (QVT) in Verbindung mit dem Meta-Metamodell, M3 der Meta ObjectFacility (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 ermit-teln

. 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


Abbildung 5. Phasen der konventionellen objektorientierten Softwareentwick-lung

Das folgende Schaubild verdeutlicht diesen Prozess:Wie wir in Kap. 1 vermutet haben erfindet die modellgetriebene Softwareent-

wicklung das Rad nicht neu, es stellt einen entscheidenen Anspruch darauf diesePhasenfolge teilweise zu automatisieren.Damit soll erreicht werden dass die Fehler welche, beim scheinbar erfolgverspre-chendem Roundtrip-Engineering - Änderungen am Quelltext werden hierbei insDesign-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 falschenAbstraktionsniveau liegen.

So sind zum Beispiel Strukturen wie Vererbungshierarchien und Bezie-hungen 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, indemTeile dieser Phasenfolge automatisiert, sowie Implementierungsschritte (Realisie-rung 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 teiltsich diese Vorgehensweise in zwei Teilbereiche: [10]

. Genarator-Entwicklung: Definition der Software-Architektur und Entwicklungdes Generators, der diese Architektur umsetzt und

. Anwendungs-Entwicklung: Entwicklung der Fachanwendung, basierend aufder definierten Architektur unter Nutzung des Generators

12 P. Stadler

Abbildung 6. Phasen der objektorientierten und modellgetriebenen Software-entwicklung

Nach Trompeter et. al müssen in einem MDSD-Entwicklungsprojekt für beideTeilbereiche 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 darauseinen Standard für ein modellbasiertes Softwareentwicklungskonzept herausgear-beitet.Diesen Standard der OMG nennt man Model Driven Architecture, kurz MDA,dieser wurde im Jahr 2000 vorgestellt. MDA basiert auf den OMG - Basistechno-logien UML, MOF, XMI, CWM (Common Warehouse Metamodel), sowie aufden OMG-Schnittstellendefinitionssprachen IDL (Interface Description Langua-ge) 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 Interopabili-tät von Metamodellen herzustellen. Die Interopabilität wird insbesonderedurch Modell-Transformationen erreicht, die es erlauben, ein Metamodellin ein anderes zu transformieren.

Der Einsatz verschiedener Abstraktionsgrade, wie schon in der Einleitung 1erklärt wurde, sowie die Entwicklung technologieneutraler Anwendungsmodelleziehen innerhalb der MDA einige Vorteile nach sich [12]:

. Das in den Modellen enthaltene Fachwissen kann über lange Zeiträumefestgehalten werden.

. Bei einem technologiebedingten Plattformwechsel kann immerwieder aufdasselbe fachliche Modell zurückgegriffen bzw. kann dasselbe Modell aufverschiedensten Plattformen umgesetzt werden.

Bevor mit der Umsetzung eines Softwareprojektes unter Benutzung der MDAbegonnen werden kann, muss an dieser Stelle noch geklärt werden was man unter


Plattformen und Modellen versteht.Man versteht unter einer Plattform innerhalb der MDA die Zusammenführungvon (Sub-)Systemen oder Technologien, die ein gemeinsames Konstrukt vonFunktionalität durch Schnittstellen und Anwendungsmuster darstellt. Es wirddie für die Implementierung des Systems gewünschte Plattform ausgewählt undletztlich die allgemeine Systemspezifikation in eine für die entsprechende Platt-form benötigte Spezifikation transformiert.Für diese Vorgehensweise definiert die MDA die folgenden aufeinander aufbauen-den 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. DasComputation Independent Model (CIM) beschreibt die Anforderungen des zuerstellenden Softwaresystems. Dieses Modell wird auch Domänenmodell oderGeschäftsmodell genannt. In diesem Modell ist typischerweise nicht ersichtlichwie die Software im Endresultat implementiert werden soll, das Modell zeigt eherdie Umgebung in der das System später eingebettet werden soll und kann dahergenau darstellen welche Aufgaben das zu entwerfende System zu erfüllen hat.Das Computation Independent Model besitzt nach Zeppenfeld et. al [12] eine ver-gleichsweise geringe Bedeutung und wird deshalb in dem offiziellen White Paperder OMG Developing in OMG´s Model-Driven Architecture [5] nicht erwähnt.Es begründet seine Hauptaufgabe damit dem Systemanalytiker Klarheit für dieweitere Umsetzung der MDA zu geben.

Nun kann man sich laut Jon Siegel et. al. [5] an folgender Vorgehensweiseorientieren:

1. Schritt 1: Erstellen eines PIMAlle MDA -Entwicklungsprojekte starten mit der Erstellung eines (PIM).Modelle auf dieser hohen Abstraktionsebene werden oft von Geschäftsexper-ten und nicht von den eigentlichen Systemprogrammierern erstellt. Dabeiwerden 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 Anwendungmit den Mitteln der konkreten Implementierungstechnologie.

3. Schritt 3: Generierung der AnwendungSchließlich wird das Plattform- und technologiespezifische (PSM) in Quellcodeübersetzt. Weil ein (PSM) seine Basistechnologie kennt, ist diese relativeinfach.

14 P. Stadler

Die in den Kapiteln 2.2 und 2.1 beschriebenen Metamodelle und MOF sowieOCL-Ausdrücke finden sich hier auch in der Abgrenzung der MDA von der MDSDwieder [9]:

MDA ist bezüglich der Ontologie einer Spezialisierung von MDSD mitfolgenden Eigenschaften:

. MDA verwendet MOF als das Metamodell (d.h. als Mittel, um Meta-modelle zu definieren).

. MDA sieht vor, dass die DSL´s auf Basis der MOF definiert werden.Es sind also beliebige Notationen und Metamodelle möglich, solangesie mit Hilfe des OMG-Metamodells definiert wurden. In der Praxisregt MDA die Verwendung von UML-Profilen als konkrete Syntax füreine DSL an. Damit ist die DSL im Kern dann auf UML festgelegt.Die statische Semantik wird dementsprechend mit OCL-Ausdrückenspezifiziert.

. Software-Systemfamilien und Produktlinien haben in der MDA- Ter-minologie keine direkte Entsprechung und stehen auch inhaltlich nichtim Fokus.

. Es werden verschiedene Sichtwinkel auf formale Modelle definiert: Einfachliches Modell kann relativ zu einer Plattform spezifisch (PSM)oder unspezifisch (PIM) sein. Die MDA legt mehrschichtige Transfor-mationen zwischen Modellen nah, verbietet aber auch eine direktePIM-zu-Code-Transformation nicht.

. Um auch die letzte Transformation, also die zur Plattform hin, alsModell-zu-Modell-Transformation notieren zu können, muss auchdie Plattform mittels eines Metamodells beschrieben werden. Dazuwerden PDM´s, die Plattform Description Models, verwendet.

. Es gibt noch keine standardisierte Transformationssprache, aber einRequest for Proposal für Query/Views/Transformations (QVT). Zielist es Transformationen zwischen Quell- und Ziel-Metamodell fürModell-zu-Modell-Transformationen zu beschreiben.

So detailliert die MDA beschrieben werden kann, so problematisch ist aber imGegenzug ihre (alleinige) Praxistauglichkeit. Die reine, vollständige Anwendung,ist laut Stahl et. al. [9] nicht ohne weiteres möglich. Sie postulieren den Vergleichdass man sich nur vor Augen führen muss wie lange es gedauert hat bis wirklichpraxistaugliche UML-Tools auf dem Markt waren. Unter anderem gehen sie auchauf den Aspekt der Interopabilität ein, der die Fähigkeit zur Zusammenarbeit vonverschiedenen 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 nichtrealisiert werden können.


4 Anwendung modellbasierte SE: MDSD - Abgrenzungund Möglichkeiten

Es werden nun zwei Vorgehensmodelle für die modellbasierte Softwareentwicklungerörtert. Es wird sich aber zeigen das allein die Anwendung dieser Modelle keineGarantie bietet dass ein Softwareprojekt erfolgreich ist.Im folgenden sollen Anhand des

. V-Modell XT des BSI (Beauftragte der Bundesregierung für Informations-technik) und des

. Rational Unified Process (RUP) der Firma Rational

Abgrenzung und Möglichkeiten für die modellbasierten Softwareentwicklung auf-gezeigt werden.Das V-Modell XT des Bundes ist ein generisches Vorgehensmodell zum Pla-nen und Durchführen von Entwicklungsprojekten[10]. Dieses Vorgehensmodellsoll dazu genutzt werden, dass die komplette Software-Entwicklung und dasSoftware-Management abgedeckt werden können. Von ihm werden dafür dieAktivitäten und Ergebnisse, die während der Entwicklung von Systemen durch-zuführen bzw. zu erstellen sind definiert. Bestimmte Aufgaben des Projektes,wie z.b. das Projektmanagement, werden durch verschiedene verpflichtende undoptionale Vorgehensbausteine wie Aktivitäten, Produkte und Rollen vorgegeben.Eine zeitliche Ablaufreihenfolge wird erst durch Strategien für die Projektdurch-führung vorgegeben. Laut Trompeter et. al. [10] kommen Petrasch und Fieber zudem Ergebnis, dass sich die vorhandenen Durchführungsstrategien des V-Modellsnicht ohne Änderungen für MDA-Projekte anwenden lassen, da entscheidendeMeilensteine aus dem MDA Guide der OMG nicht als so genannte Entscheidungs-punkte im V-Modell XT abgebildet sind. Um das V-Modell an eigene Bedürfnisseanzupassen wurde mit der Version XT im Jahr 2005 das so genannte Tailoringeingeführt. Dies rechtfertigt auch das Suffix XT = Extreme Tailoring. Zum Standdieser Arbeit (April 2009) ist die Version 1.3 des V-Modell XT aktuell: http://v-modell.iabg.de/dmdocuments/V-Modell-XT-Gesamt-Deutsch-V1.3.pdf. Mit Hilfeder Möglichkeit des Tailoring kann man Anpassungen an den Vorgehensbaustei-nen und Durchführungsstrategien im V-Modell XT vornehmen. Trompeter et.al.[10] unterstellen dem V-Modell XT die Fähigkeit für ein modellgetriebenesVorgehen geeignet zu sein, wenn an ihm Anpassungen bzw. Erweiterungen vorge-nommen werden. Diese Änderungen sollen an bestimmten Entscheidungspunktenansetzten. Kapitel 3.3 beschreibt die Platform Independent Models, und wie inder Vorgehensweise beschrieben wurde braucht das iterative Vorgehen des MDA-Ansatzes den Entscheidungspunkt PIM erstellt. Vollständigkeitshalber wird auchdie positive Bestätigung dieses Vorganges PSM erstellt eingefügt. Damit wirddeutlich dass das V-Modell XT grundsätzlich geeignet ist für die modellgetriebeneSoftwareentwicklung.

Der Rational Unified Process (RUP) ist ein objektorientiertes Vorgehens-modell zur Softwareentwicklung. Der RUP wurde 1996 von der Firma Rational

16 P. Stadler

Software, welche mittlerweile zu IBM gehört, vorgestellt.Die Vorgehensweise des RUP ist iterativ, architekturzentriert, klar definiert undstrukturiert. Das zentrale Element der RUP ist die Unified Modelling Language.Laut Trompeter et. al. [10] ist der Rational Unified Process eine konkrete Imple-mentierung des Unified Process; ein Metamodell für Vorgehensmodelle.Der praktische Einsatz des Rational Unified Process für die modellbasierte Soft-wareentwicklung lässt sich anhand einiger Gemeinsamkeiten ausmachen. DerAnsatz der modellbasierten Softwareentwicklung sowie der Model Driven Ar-chitecture zeigt durch seine Kompabilität zur Unified Modeling Language dieGemeinsamkeit 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 iterativeVorgehen des RUP zeigt ebenso die Verwendungsmöglichkeiten für die modellba-sierte Softwareenwicklung die diese iterative Vorgehensweise auch voraussetzt,siehe Abb. 6. Der RUP bietet ebenso wie das V-Modell XT die Möglichkeit dasModell für eigene Bedürfnisse anzupassen. Dadurch kann, laut Trompeter et. al.,für einen modellgetriebenen Ansatz die Elaborations-Phase, also die konkrete Um-setzung angepasst werden, um den Grundstein für die Systemarchitektur zu legen.

5 Kritische Würdigung und FazitDie Recherche für diese Arbeit hat gezeigt das Modellierung mehr ist als UML.Die Unified Modelling Language ist zwar, bis jetzt, der erfolgreichste und amweitesten verbreiteste Ansatz für Modellierung aber es zeigt sich doch das derWunsch besteht für jedes erdenkliche Anwendungsgebiet die optimale Model-lierungssprache zu finden. Die modellgetriebene Softwareentwicklung ist einvergleichsweise junger Entwicklungszweig der das Ziel verfolgt einen durchgän-gigen Entwicklungsprozess für eine möglichst weitgehende Automatisierung derSoftwareherstellung zu erreichen. Im Kern von MDSD stehen formale, durch einenGenerator auswertbare Modelle, aus denen weite Teile eines Softwaresystemsautomatisiert erzeugt werden. Die entscheidenden Vorteile der modellgetriebenenSoftwareentwicklung sind Produktivitätssteigerungen und insbesondere Quali-tätsverbesserungen für die langfristige Wartbarkeit der Softwaresysteme. In Kap.4 wurde gezeigt das sich etablierte Vorgehensmodelle wie der Rational UnifiedProcess für einen modellgetriebenen Entwicklungsansatz anpassen lassen können.Vergleichend lässt sich feststellen das der reine Ansatz der MDSD wohl mehrPotential hat sich in der Zukunft durchzusetzten da er Open-Source und flexibelist. Die MDA ist sehr stark abhängig von den Richtlinien zur UML, OCL undder 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.


[2] N. de Lange. Grundlagen aus der Informatik. Springer, 2005.[3] G. Disterer, F. Fels, and A. Hausotter. Taschenbuch der Wirtschaftsinformatik.

Hanser, 2002.[4] J. Hackmann. Der deutsche It-markt steht vor einer Rezession. Computerwo-

che/2008, December 2008.[5] Jon Siegel. Developing in Omg Model-Driven Architecture. Object Management

Group White Paper, 2.6:12, 2001.[6] M. Kempa and Z. A. Mann. Modell Driven Architecture. Informatik Spektrum,

28(4):298–302, August 2005.[7] J. Seemann and J. W. von Gudenberg. Software-Enwurf mit der UML2. Sprin-

ger/Xpert.press, 2006.[8] H. Stachowiak. Allgemeine Modelltheorie. Spektrum, 1973.[9] T. Stahl and M. Völter. Modellgetriebene Softwareentwicklung: Techniken, Engi-

neering, Management. Dpunkt, 2005.[10] J. Trompeter and G. Pietrek. Modellgetriebene Softwareentwicklung MDA und

MDSD in der Praxis. Software & Support, 2007.[11] K. D. Wüsteneck. Zur philosophischen Verallgemeinerung und Bestimmung des

Modellbegriffs. Deutsche Zeitschrift für Philosophie, 12(12):1504, 1963.[12] K. Zeppenfeld and R. Wolters. Generative Software-Entwicklung mit der MDA.

Springer, 2005.

Grundlagen der modellbasiertenTestfallgenerierung

Markus Bickelmaier

Universität Augsburg

Zusammenfassung In dieser Seminararbeit werden Möglichkeiten zumautomatisierten Erkennen von Softwarefehlern untersucht. Die Betrach-tung führt hin zum Begriff des modellbasierten Testens. Neben einemEinblick in die Grundlagen dieser Testmöglichkeit werden aber auchandere Testansätze aufgegriffen. Stellvertretend für alternative Testan-sätze wird das sourcecodebasierte Testen am Beispiel eines JUnit Testsvorgestellt.Das Verfahren des modellbasierten Testens wird in seiner Grundideeund seiner darauf aufbauenden Struktur beschrieben. Dabei werden dieUnterschiede und Vorteile des modellbasierten Testens gegenüber anderenTestverfahren diskutiert und untersucht.An praktischen Beispielen wird die Prüfung einer Software unter verschie-denen Aspekten vorgestellt. Die Generierung der Testfälle kann dabeisowohl aus statischen als auch dynamischen Modellen heraus erfolgen.Auf die Unterschiede und Möglichkeiten zwischen den aus statischen unddynamischen Modellen erzeugbaren Tests wird eingegangen.Abschließend werden (nicht-)kommerzielle Tools vorgestellt, die die Mo-dellierung und die Generierung von modellbasierten Tests wesentlichunterstützen können. Anhand eines einfachen Beispiels wird die Anwen-dung verdeutlicht.

Grundlagen der modellbasierten Testfallgenerierung 19

1 Einführung

Die Komplexität von Softwaresystemen steigt immer weiter. Softwarefehler diezu spät erkannt werden verursachen hohe, unnötige Kosten, sowie einen Mehrauf-wand zur Beseitung dieser. Entdeckt man diese Fehler jedoch frühzeitig, so ist dieBeseitigung einfacher, die Wahrscheinlichkeit von Folgefehlern oder abgeleitetenFehlern geringer und das Produkt wesentlich preiswerter.

Ein Lösungsversuch Fehler bereits in der Modellierungsphase aufzuspürenist das modellbasierte Testen. Modellbasierte Tests werden aus (bestehenden)Modellen eines SUT1 gewonnen und testen vorrangig die Umsetzung der Spe-zifikation im Design. Als Ergebnis zeigen sich, abhängig von der Komplexitätdes zu entwicklenden Softwaresystems, geringere Kosten in der Entwicklung,weniger Fehler in der Implementierung und qualitativ bessere und verlässlichereSoftware. Zudem verfügen Entwickler mit modellbasierten Tests über ein starkesZertifizierungswerkzeug.

2 Testen von Software

2.1 Sourcecodebasiertes Testen

2.1.1 Was ist sourcecodebasiertes Testen? Sourcecodebasiertes Testenbeschäftigt sich, wie der Name schon sagt, mit dem Testen eines SUT, wobeidie verwendeten Tests direkt als Sourcecode vorliegen. Es müssen also keinerleiModelle zu diesen Tests oder der Software an sich existieren. Ein sehr einfachesBeispiel für sourcecodebasiertes Testen ist das Hinzufügen einer main-Methodein einer Java Klasse um die Funktionalität der Klasse mit simulierten Daten zuüberprüfen. Dies ist natürlich eine stark vereinfachte Betrachtungsweise, dennkorrekt durchgeführte, toolgestützte sourcecodebasierte Tests bieten eine solideGrundlage für stabile und fehlerfreie Software. Da bei sourcecodebasierten Testsvollständiges, oder nahezu vollständiges Wissen über die Funktionsweise des SUTangenommen werden eignen sich diese besonders für White-Box Tests2, jedochsind logischer Weise auch Black-Box Tests3 möglich.

2.1.2 Beispiel: JUnit JUnit ist ein Test-Framework für die Programmierspra-che Java. JUnit Tests sind Unit Tests, also Tests einzelner Units wie Methodenoder Klassen eines Softwareprojekts. Das Kernprinzip von JUnit Tests sindZusicherungen, 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ürdetrue liefern, falls die JVM 3*2 zu 6 berechnet und ansonsten false [3].1 System under Test; Das zu testende System2 White-Box Tests sind Tests bei denen Informationen über innere Abläufe eines SUTvorliegen 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 bekanntsind, jedoch keinerlei Wissen über interne Abläufe eines SUT besteht [2].

20 M. Bickelmaier

Die Idee hinter den JUnit Tests ist, dass nichts implementiert wird was nichtauch getestet wurde. Dies hat den Vorteil, dass ein Programmierer der neu zueinem bestehenden Softwareprojekt hinzukommt, oder einfach Änderungen anbestehender 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 zuBeginn seiner Arbeit, fehlerfrei war. Liefern einige Tests nach seinen Änderungenfalse zurück, so sind diese Fehler mit Sicherheit auf den von ihm geänderten Codezurückzuführen. Ein weiterer Vorteil ist in der Übersichtlichkeit der Überprüfungzu 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 falsezurü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. */@Testpublic void testMultiplication() {

Assert.assertEquals("Multiplication", 6, 3 * 2);}

}

Abbildung 1. Beispiel eines JUnit Tests

2.2 Modellbasiertes Testen

2.2.1 Was ist modellbasiertes Testen Modellbasiertes Testen beschreibtdas Testen eines SUT, wobei die verwendeten Tests teilweise oder vollständig ausModellen generiert werden (siehe Abbildung 2). Das Modell eines Tests beschreibtdiesen abstrakt, ist also nicht lauffähig. Damit ein modellierter Test lauffähig wirdmuss er über Modelltransformationen in einen ausführbaren Test umgewandeltwerden (z.B. das Erzeugen lauffähigen Codes aus UML-Diagrammen; siehe auchAbbildung 3) [4]. Da diese Tests auf der Grundlage von Modellen gewonnenwerden und nicht aus dem eigentlichen Sourcecode des SUT, spricht man imZusammenhang mit modellbasierten Tests oft auch von Black-Box Tests. Eskönnen jedoch auch Aspekte des Testens auf Sourcecodeebene einbezogen werden,so dass hier eine Mischform von Black-Box und White-Box Testen entstehenkann (Gray-Box Testen) [12].

Man unterscheidet bei der Durchführung modellbasierter Test grundsätzlichzwischen Online und Offline Tests. Von einem Onlinetest spricht man, wennsich das Test-Tool direkt zum SUT verbindet und dynamisch generierte Testsautomatisch auf diesem durchführt. Dies ist vor allem für längere und größe-re Testreihen von Vorteil, da man diese ohne jegliche Betreuung längere Zeit,


Abbildung 2. Testfallgenerierung aus Modellen [13]

z.B. über Nacht, laufen lassen kann um am Ende die gesammelten Ergebnisseabzurufen. Von einem Offlinetest spricht man, wenn die Tests in einem maschi-nenlesbaren Format erzeugt und gespeichert werden. Dies hat den Vorteil dassman spezielle Tests gezielt durchführen kann wann immer diese benötigt werden.Es ist ebenfalls mögliche die generierten Tests automatisiert durchzuführen, umso längere Prüfläufe zu absolvieren [15].

2.2.2 Unterschiede zum sourcecodebasierten Testen Zwar beanspru-chen sowohl das sourcecodebasierte, als auch das modellbasierte Testen denVorteil der Wiederverwendbarkeit, auch im laufenden Entwicklungsprozess, fürsich, jedoch wird, betrachtet man die Grundlage auf der die beiden Arten vonTests aufgebaut sind, relativ schnell deutlich, dass man beim sourcecodebasiertenTesten recht schnell in Gefahr läuft den Überblick zu verlieren. Tests werdeneinmal verfasst und zu größeren Testsuites zusammengefasst. Mit steigenderKomplexität eines SUT erhöht sich die Anzahl der Testsuites. Es ist jedoch klar,dass sich das (manuelle) Anpassen jeder einzelnen Testsuite bedeutend aufwän-diger gestaltet, als ein paar Modelle anzupassen und sich sämtliche Testsuitesneu und zu dem aktuellen Stand der Software passend, generieren zu lassen.Dies wird deutlicher, je größer die Änderung am System ist. Da die Generierungund Durchführung der modellbasierten Tests automatisiert und ohne personelleBetreuung 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 pro-grammiert wurde. Das bedeutet, dass je weiter der Softwareentwicklungsprozess

22 M. Bickelmaier

voranschreitet, auch immer neue Tests entstehen. Man wird quasi zu einem par-allelen Vorgehen gezwungen. Beim modellbasierten Testen stehen jedoch bereitsvon Anfang an alle Modelle, bevor auch nur eine Zeile Sourcecode programmiertwurde. Das heißt, dass bereits in einer sehr frühen Phase des Entwicklungspro-zesses das SUT auf seine gewünschten Eigenschaften getestet werden kann. Aufdiese Weise lässt sich ein Design frühzeitig gegen die vorgegebene Spezifikati-on verifizieren. Findet man in dieser Phase des Entwicklungsprozesses bereitsFehler, die sonst erst wesentlich später entdeckt worden wären, lassen sich diesebedeutend kosteneffizienter und einfacher beseitigen.

Ein weiterer Vorteil des modellbasierten Testens liegt darin, dass gleichzeitigein Modell des erwarteten Nutzerverhaltens entsteht (siehe auch Kapitel 2.5.2).

Mit beiden Untersuchungsmethoden steht ein wertvolles Werkzeug zum Nach-weis der Funktion, insbesondere gegenüber Dritten und Kunden zur Verfügung.Sourcecodebasierte Tests beschränken sich meist auf die fehlerfreie Funktion einerSoftware. Modellbasierte Tests jedoch können zudem zertifizieren dass gegebeneSpezifikationen 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, sagenallerdings nichts über das Verhalten des SUT aus. Die statischen Modelle eignen


sich deshalb vorrangig dazu Schwächen und Fehler in der Struktur eines SUTaufzudecken. Hier kann man also überprüfen ob ein SUT prinzipiell „dem erstenAnschein“ nach eine Spezifikation erfüllt, bzw überhaupt erfüllen kann.

2.3.1 Klassendiagramm Klassendiagramme eignen sich besonders gut, umdie theoretische Korrektheit eines SUT zu testen, da in ihnen sämtliche struktu-rellen Informationen des SUT festgehalten sind. Zu diesen Informationen gehörenAbhängigkeitsklauseln zwischen Klassen. Diese Klauseln wiederum ermöglichenTests der Initialisierbarkeit dieser Klassen. Assoziationen geben Aufschluss überBeziehungen zwischen Klassen und deren Realisierbarkeit. Besonders spannendsind die Schnittstelleninformationen eines SUT. Diese lassen beispielsweise Testsauf 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 inihnen, wie der Name schon sagt, Informationen über das dynamische Verhalteneines SUT festgehalten sind. Dies bietet die Möglichkeit Benutzerinteraktionenmit dem SUT zu simulieren und zu testen. Auf diese Weise erhält man einer-seits Tests die besonders für Code- / Method- und Action-Coverage geeignetsind. Andererseits wird während dem Testen bereits auch schon das erwarteteBenutzerverhalten simuliert und es können Schwachstellen oder Abweichungenim gewünschten Verhalten des SUT entdeckt werden.

Es werden nun einige Verfahren vorgestellt wie aus unterschiedlichen Vertre-tern von dynamischen Modellen Testfälle generiert werden können.

2.4.1 Finite-State-Machine (FSM) Hier gibt es mehrere MöglichkeitenTests abzuleiten. Je nachdem welche Ziele verfolgt werden bieten sich unterschied-liche Algorithmen zur Testfallgenerierung an. Das Ableiten von Testfällen ausFSM wird anhand eines simplen Telefonsystem veranschaulicht.

Beispielsweise besteht die Möglichkeit eine Testsequenz abzuleiten, welchejede verfügbare Aktion in jedem Zustand mindestens einmal ausführt (ActionCoverage). Tabelle 1 zeigt eine mögliche solche Testsequenz.

24 M. Bickelmaier

Abbildung 4. FSM eines einfachen Telefonsystems [7]

Aktion Zustand Aktion Zustand- Bereit Wählen / Gegenüber bereit KlingelnAbheben Freizeichen Gegenüber hebt ab SprechenWählen / Gegenüber belegt Belegt Gegenüber legt auf FreizeichenAuflegen Bereit Auflegen BereitAbheben Freizeichen Abheben FreizeichenWählen / Gegenüber bereit Klingeln Wählen / Gegenüber bereit KlingelnAuflegen Bereit Gegenüber hebt ab SprechenAbheben Freizeichen Auflegen Bereit

Tabelle 1. Test Sequenz zum erreichen von Action-Coverage [7]


Betrachtet man einen Test als eine zusammenhängende Sequenz von Aktionendie jeweils im Zustand „Bereit“ beginnen und enden, so sind in obiger Tabelle alsovier Testfälle enthalten. Es ist durchaus möglich dass eine, durch einen anderenAlgorithmus, abgeleitete Testsequenz aus mehr oder weniger solcher Einzeltestsbestehen kann [10].

Ein Testfall sollte erwartete Ausgabewerte angeben, ebenso wie die Sequenzder Eingaben. Ginge man davon aus, dass dieses Telefonsystem so konfiguriertwäre, dass es selbst seine Zustände ausgibt, so bräuchte man in diesem Fall keinseperates Testorakel, da diese Funktion bereits die FSM übernehmen würde.

Action-Coverage ist das einfachste zu testende Kriterium einer FSM. Einweiteres wichtiges Kriterium ist das Switch-Coverage Kriterium. Dieses ist erfülltwenn 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 inTabelle 1 enhalten. Mithilfe von Switch-Coverage kann man unter anderem zeigen,dass ein System Deadlock frei ist. Genau wie bei Action-Coverage sind auch hierTestfälle nicht eindeutig bestimmt, je nachdem welche Pfadfindungsalgorithmenman verwendet [7].

2.4.2 Sequenzdiagramm Sequenzdiagramme haben den Vorteil, dass in ih-nen nicht nur Informationen über Methodenaufrufe festgehalten sind, sondernauch Interaktionen mit anderen Objekten. Ausserdem sind Sequenzdiagrammeüber, in OCL definierte, Bedingungen dahingehend erweiterbar, dass Objektzu-stände während der Laufzeit überprüft werden können [13].

Testfälle die aus Sequenzdiagrammen generiert werden spielen Schritte derSequenzdiagramme ab. Sie vergleichen erhaltene Ergebnisse mit den Ergebnissedie in Sequenzdiagrammen enthalten sind oder mittels Testorakel generiertwurden.

Um einen Testfall aus einem Sequenzdiagramm zu generieren, interpretiertman 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, dienendem Ergebnisabgleich und der Verifikation. Die interne Interaktion zwischen Sub-systemen kann, abhängig von der Testtiefe, auf die gleiche Weise mit einbezogenwerden [8].

26 M. Bickelmaier

Abbildung 5. Testfallgenerierung aus Sequenzdiagrammen

2.4.3 Aktivitätsdiagramm Die Pfade durch den Graphen des Aktivitäts-diagramms sind die einzelnen Testfälle. Welche Pfade gewählt werden wirddurch 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 auchhier, abhängig vom Pfadfindungsalgorithmus, wieder sehr viele, unterschiedlicheTestfälle.

Auch hier werden, wie bei Sequenzdiagrammen, die Systemfunktionen wiederzu Testschritten. Die Ergebnisse von Systemreaktionen werden wiederum mitden erwarteten Ergebnissen verglichen.

Aktivitätsdiagramme weisen eine Ähnlichkeit zur mathematischen Grund-lage von Petrinetzen auf. Es ist also relativ einfach mit formalen Methodenbestimmte Eigenschaften zu validieren. Zu diesen zählen unter anderem Deadlock-Situationen, Abhängigkeiten, Vollständigkeiten und Zyklen [8].


2.5 Toolgestützes modellbasiertes Testen

Toolgestütztes modellbasiertes Testen bietet weitere Vorteile. Dazu gehörendie Bereitstellung von Informationen über die durchgeführten Tests und derenErgebnisse in aufbereiteter Form. Durch eine automatisierte Durchführung könnenausserdem Personalkosten gespart werden. Sie können ohne Aufsicht über Nachtlaufen, oder parallel zum Entwicklungsprozess durchgeführt werden. Dies hatwiederum eine Zeitersparnise zur Folge.

Die Algorithmen zur Testfallgenerierung können des weiteren teilweise sehrkomplex sein (siehe 2.4.1). Dies kann bei einer manuellen Durchführung zu einererhöhten Fehleranfälligkeit führen. Tools hingegen führen solche Tätigkeitenverlässlich und vollautomatisch durch. Hierbei gibt es auch die MöglichkeitPrüfprotokolle erstellen zu lassen, welche als Nachweise gegenüber Dritten (demKunden) als Zertifizierungswerkzeug dienen können.

2.5.1 Conformiq Qtronic Conformiq Qtronic von der Firma Conformiq Soft-ware Ltd (www.conformiq.com) wird als Plugin für die EntwicklungsumgebungEclipse vertrieben. Es unterstützt sowohl das Einbinden bestehender Modelle,beispielsweise mit Rhapsody erzeugte UML Diagramme, als auch die Erstellungeigener Prüfmodelle. Conformiq Qtronic unterstützt den modellbasierten Test-vorgang auf Basis von UML Diagrammen [5] sowie der Java Action Language.Conformiq Software Ltd vertreibt sowohl eine Version für Windows als auch einefür Linux.

28 M. Bickelmaier

Abbildung 6. Anlegen einer State Machine

Abbildung 7. Festlegen der Testziele


Abbildung 8. Durchführen der Tests und Ausgabe der Ergebnisse

Conformiq Qtronic ist kostenpflichtig, jedoch gibt es die Möglichkeit einevergünstigte akademische Lizenz für eine nicht-kommerziellen Nutzung zu erwer-ben. Unabhängig davon besteht die Möglichkeit eine kostenfreie Testversion zuerhalten [9].

2.5.2 ModelJUnit ModelJUnit (czt.sourceforge.net/modeljunit/) ist ein Test-framework mit dem Ziel die Ideen von JUnit Tests in den Bereich des modell-basierten Testens zu übertragen. In ModelJUnit werden FSM oder EFSM alsJavaklassen 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 aus-gewerteter und „roher“ Form ausgeben. Ein weiteres Feature von ModelJUnitist die Ausgabe von .dot Dateien, welche mit Visualisierungstools wie zum Bei-spiel Graphviz (www.graphviz.org) grafisch ausgewertet werden können (sieheAbbildung 9) [6].

Nachfolgend wird am Beispiel der Handlungsabläufe an einem Snack-Automatender Ablauf eines ModelJUnit Tests veranschaulicht. Der Automat unterstütztdas Einwerfen von 25 und 50 Cent. Für den Kauf sind 100 Cent erforderlich.

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; }public @Action void vend() { state = 0; }

public boolean coin25Guard() { return state <= 75; }public @Action void coin25() { state += 25; }

public boolean coin50Guard() { return state <= 50; }public @Action void coin50() { state += 50; }

}

Abbildung 10. Anlegen einer FSM in ModelJUnit


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

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/3state coverage was 5/5transition coverage was 7/8transition-pair coverage was 8/12==================================Graph contains 5 states and 8 transitions.

Abbildung 12. Ergebnis des ModelJUnit Tests


3 Ergebnisse

In der Betrachtung zeigten sich wichtige Vorteile der Methode des modellba-sierten Testens im Vergleich zur Alternative des sourcecodebasierten Testen.Bei der Erstellung komplexer Softwarelösungen ist es immer das Ziel etwaigeProgrammfehler in der neuen Software so früh wie möglich zu erkennen. DiePrüfung soll dabei durch übersichtliche und klar strukturierte Testmodelle vorge-nommen werden und nach Möglichkeit bereits erste Nachweise für die Erfüllungder Spezifikation gegenüber dem Auftraggeber liefern.

Hier zeigten sich die Stärken des modellbasierten Testens. Auf dem Marktbefinden sich bereits geeignete Softwaretools, die das Erstellen von modellba-sierten Tests unterstützen. Die Testsuites lassen sich damit relativ einfach ausden Designdiagrammen generieren. Das hat den Vorteil, dass man auch demAuftraggeber gegenüber, relativ früh das spätere Funktionsverhalten modellierenund simulieren kann.

Aus diesem Grund sollte das Verfahren des modellbasierten Testens in jedemumfangreicheren Softwareprojekt eingesetzt werden.

Literatur

[1] http://en.wikipedia.org/wiki/White_box_testing.[2] http://en.wikipedia.org/wiki/Black_box_testing.[3] http://en.wikipedia.org/wiki/Junit.[4] http://en.wikipedia.org/wiki/Model-based_testing.[5] http://en.wikipedia.org/wiki/Model-based_testing_tools.[6] http://www.cs.waikato.ac.nz/ marku/mbt/modeljunit/.[7] Software acquisition gold practice: Model-based testing. Software Acquisition Gold

Practice, 2004. http://www.goldpractices.com/practices/mbt/.[8] T. Q. Benjamin Wilmes, Natalia Freijnik. Modellbasiertes testen (ableiten von

tests aus anwendungsfällen, aktivitätsdiagrammen und statecharts), klassifikati-onsbaummethode, testwerkzeuge. Technical report, TU Berlin, 2008.

[9] Conformiq Ltd. Conformiq Qtronic - Automate Test Design.http://www.conformiq.com/qtronic.php.

[10] I. K. El-Far and J. A. Whittaker. Model-based software testing. Technical report,Florida Institute of Technology, 2001.

[11] M. Köhler. Uml-basiertes testen. Technical report, Eberhard-Karls-UniversitätTübingen, 2006.

[12] S. Lawalata. Study literature of model-based testing for test integrity. Technicalreport, TU Hamburg Harburg, 2006.

[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, 2008.

[15] M. Utting. Position paper: Model-based testing. Technical report, University ofWaikato, 2005.

[16] F. Westphal. Extreme programmer, unit tests mit junit. FrankWestphal.de, 2001.http://www.frankwestphal.de/UnitTestingmitJUnit.html.

Evaluierung der Potentiale des Eclipse ProcessFrameworks

Robert Freudenreich


Zusammenfassung Diese Seminararbeit evaluiert die Potentiale desEclipse Process Framework. Es wird zunächst auf die Entwicklungs-prozesse RUP, Scrum und OpenUP eingegangen sowie das MetamodellUMA und der EPF Composer thematisiert. Es folgt eine Erörterung derAnwendungsgebiete und Best Practices bevor mit einer prototypischenImplementierung die Erweiterbarkeit des EPF demonstriert wird.

1 EinleitungAls es noch keine Rechner gab, war auch das Programmieren noch keinProblem, als es dann ein paar leistungsschwache Rechner gab, war dasProgrammieren ein kleines Problem und nun, wo wir gigantische Rechnerhaben, ist auch das Programmieren zu einem gigantischen Problemgeworden.

Dieses Zitat von Edsger Dijkstra [1] beschreibt mit einfachen Worten dieExplosion der Komplexität der Softwareentwicklung, der sich die Softwareindustriedurch die Dynamik der Hardware-Entwicklung, die zunehmende Zerstreuungder Entwicklungsteams sowie immer komplexeren und integrierteren Software-Systemen ausgesetzt ist. In [8] wird diese Explosion mit dem Faktor 50 innerhalbvon 10 Jahren quantifiziert. Um diese Komplexität beherrschen zu können, werdenSoftwareentwicklungsprozesse eingesetzt.

2 SoftwareentwicklungsprozesseLiggesmeyer beschreibt einen Softwareentwicklungsprozess in [11] als „eine ziel-orientierte Aktivität zur Erzeugung eines Produktes oder zur Durchführung eineranderen Aufgabe im Rahmen der ingenieurmäßigen Softwareentwicklung“. DieGrundlage für solche Prozesse sind Vorgehensmodelle, mit deren Entwicklungsich die Disziplin des Software-Engineering befasst. Dabei unterscheidet manklassische schwergewichtige und agile leichtgewichtige Vorgehensmodelle. Klas-sische Vorgehensmodelle eignen sich für große Entwicklungsprojekte und sindeher statisch und dokumentationslastig - Beispiele sind das Wasserfallmodell,V-Modell oder der Rational Unified Process. Agile Vorgehensmodelle eignen sichhingegen für kleinere und mittlere Entwicklungsprojekte und sind eher flexibelund anpassungsfähig - Beispiele sind Extreme Programming, Scrum und derOpen Unified Process.

Evaluierung der Potentiale des EPF 35

2.1 Rational Unified Process

Der Rational Unified Process (RUP) ist ein iteratives und inkrementelles, aberdennoch klassisches Vorgehensmodell, das Anwendungsfall- und Architekturge-trieben ist. Es verwendet als Sprache die Unified Modeling Language (UML)und basiert auf diversen Erfahrungen der Softwareentwicklung, die sich in denfolgenden sechs Software Best Practices wiederspiegeln:

1. Iterative Software-Entwicklung2. Anforderungsmanagement3. Verwendung komponentenbasierter Architekturen4. Visuelle Software-Modellierung5. Prüfung der Software-Qualität6. Kontrolliertes Änderungsmanagement

Der Lebenszyklus des RUP besteht aus vier Phasen1, welche wiederum inIterationen unterteilt sind und an deren Ende jeweils ein Meilenstein erreichtwird. Aufgaben innerhalb einer Iteration sind sechs Kern-Workflows2 und dreiunterstützenden Workflows3 zugeordnet, die in jeder Iteration unterschiedlichintensiv angewandt werden. Abbildung 1 veranschaulicht diese Zusammenhänge.

Abbildung 1. Workflows und Phasen des Rational Unified Process [10]

1 Inception, Elaboration, Construction und Transition2 Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deploy-ment

3 Configuration & Change Management, Project Management und Environment

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. DieGrundlage für agile Vorgehensmodelle ist die Annahme, dass ein Softwareent-wicklungsprozess zu komplex ist, als dass er sich weder im Voraus in unabhängigeStufen, noch in detaillierte Arbeitsschritte planen lässt. Agile Vorgehensmodellesind daher sehr flexibel um gut auf Änderungen reagieren zu können.

Scrum definiert nur wenige Rollen4 und Artefakte. Das Product Backlog5, wirdzu Beginn des Prozesses initial gefüllt und vom Product Owner priorisiert. Fürjeden Sprint6 wird ein Sprint Backlog mit den Anforderungen erstellt, die dabeiumgesetzt werden sollen. Das Team organisiert sich innerhalb des Sprints selbstund das Ergebnis soll ein lauffähiges Inkrement der Software sein. Abbildung 2stellt 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 abouthow you could create a stripped-down version of the Rational UnifiedProcess reflecting an agile approach to using RUP, while at the sametime leverage all the good things we liked in other agile processes, suchas Scrum and XP.

4 Product Owner, Team und Scrum Master5 Das Product Backlog enthält die Anforderungen an das Produkt6 Bezeichnet eine Iteration mit einer Dauer von ca. 30 Tagen


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 grundlegendeCharakteristika, u.a. Anwendungsfälle und ein architekturgetriebenes Vorgehen,einhält. Im Gegensatz zu diesem ist OpenUP aber ein minimaler Prozess, dernur grundlegende Inhalte enthält und auf viele weiterführende Themen verzichtetund sich daher vor allem für kleine Projekte eignet. OpenUP ist aber auch einvollständiger und erweiterbarer Prozess, so dass er als Grundlage für andereProzesse dienen kann, um ebenfalls höhere Anforderungen erfüllen zu können.

OpenUP ist Open Source und basiert auf den folgenden Kernprinzipien, die sicham Agilen Manifest [18] orientieren:

1. Collaborate to align interests and share understanding2. Balance competing priorities to maximize stakeholder value3. Focus on the architecture early to minimize risks and organize development4. Evolve to continuously obtain feedback and improve

Abbildung 3. Ebenen des OpenUP [9]

38 R. Freudenreich

OpenUP definiert sowohl Rollen, Aufgaben und Artefakte als auch Ebenen,die verschiedene Sichten mit einem unterschiedlichen Detailgrad auf das Projektermöglichen. Die Ebene des Projektlebenszyklus ähnelt dem Lebenszyklus desRUP und ermöglicht den Stakeholdern und Teammitgliedern einen effektivenÜberblick über das Projekt. Er besteht aus den selben Phasen wie RUP, wirdim Project Plan definiert und das Ergebnis ist eine freigabefähige Anwendung.Jede Phase besteht aus einer oder mehreren Iterationen, die ein funktionierendesSoftwareinkrement hervorbringen und in der Ebene des Iterationslebenszyklus ab-gebildet sind. Das Team organisiert sich dabei selbst und verpflichtet sich auf denIteration Plan, der festlegt, was in der Iteration geliefert werden soll. Die Ebenedes Mikroinkrements befasst sich mit kleinen Arbeitseinheiten, die einen stetenund messbaren Beitrag zum Projekterfolg leisten und typischerweise in einigenStunden bis Tagen abgearbeitet werden können. Abbildung 3 veranschaulichtdies.

2.4 Vorteile Modellbasierter UnterstützungLee Osterweil schrieb bereits im Jahr 1987: „Software processes are software, too“[16]. In der Tat ist ein Entwicklungsprozess im Grunde ein Programm, das von denProjektmitgliedern ausgeführt wird. Ein Prozess an sich ist abstrakt und schwerzu fassen. Durch das Erstellen eines Modells wird ein Prozess greifbar und diesist Voraussetzung für das Verstehen, Analysieren, Ausführen und Lernen einesProzesses. Die Formalisierung und Modellierung eines Entwicklungsprozessesbietet daher viele Vorteile. Henderson-Sellers führt in [5] u.a. an, dass dadurchein konsistenter, reproduzierbarer Ansatz für die Entwicklung von Softwaresichergestellt wird und die Unzulänglichkeit und Unvollkommenheit eines Ad-hoc-Prozesses beseitigt wird. Desweiteren nennt er in diesem Zusammenhang, dassdie Komplexität der heutigen Anforderungen verringert wird und die enormeGröße durch Dekomposition in handhabbare Teile gemeistert werden kann.

Weitere Vorteile eines modellierten Entwicklungsprozesses sind verringerte Ab-hängigkeiten von Personen, Vergleichbarkeit mit anderen Entwicklungsprozessen,bessere Projektplanung und -controlling sowie einfachere Kommunikation derbeteiligten Personen (intern und extern) untereinander, da eine gemeinsameSpache vorhanden ist.

Trotz all dieser Vorteile, die mit Sicherheit überwiegen, gibt es in Verbindung mitder Prozessmodellierung auch einige wenige Nachteile. Dazu gehört, dass diese dieKreativität der Softwareentwicklung einschränken können und Neuerungen in derSoftwareentwicklung langsamer übernommen werden können. Ein weiterer Punkt,dem Beachtung geschenkt werden muss, ist der Aufwand für die Erstellung unddie Weiterentwicklung des Modells.

3 Eclipse Process FrameworkProjekte haben heute eine große Auswahl an unterschiedlichen Softwareent-wicklungsprozessen. Am besten geeignet wäre jedoch oft eine Kombination ver-


schiedener Prozesse oder eine angepasste Version eines bestehenden Prozesses.Durch die unterschiedlichen Metamodelle der verschiedenen Vorgehensmodel-le ist dies allerdings nahezu unmöglich, bzw. mit einem sehr hohen Aufwandverbunden. Eine Lösung für dieses Problem ist das Eclipse Process Framework(EPF), ein erweiterbares Open Source Prozess-Framework unter dem Dach derEclipse Foundation, dessen Ziel ein offenes und kollaboratives Ecosystem für dieEntwicklung von Softwareentwicklungsprozessen ist. Dazu stellt des EPF mitUMA ein Metamodell, mit dem EPF-Composer ein Entwicklungswerkzeug undEntwicklungsprozesse wie OpenUP bereit. Abbildung 4 stellt dieses Ecosystemdar.

Abbildung 4. Ecosystem des Eclipse Process Framework [3]

3.1 Unified Method Architecture

Die Unified Method Architecture (UMA) ist eine Evolution des Software ProcessEngineering Metamodel (SPEM) 1.1, das von der Object Management Group(OMG) spezifiziert wurde um einen Metamodell-Standard für Vorhergehensmo-delle in der Softwareentwicklung zu schaffen [13]. Im Mai 2005 reichte IBMzusammen mit anderen Firmen7 bei der OMG einen Vorschlag auf Grundlageder UMA für den offiziellen Nachfolger der SPEM 1.1 ein [12]. Die aktuelle, nochin der Entwicklung befindliche Version von SPEM 2.0 basiert zum großen Teil

7 Adaptive Ltd., Fujitsu, Fundacion European Software Institue, Osellus Inc., Softeam

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 dieUMA und erste Teile von SPEM 2.0, wobei die volle Unterstützung von SPEM2.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 vonMethod Content (Methodeninhalt) und Process (Prozess), die in Abbildung 5graphisch darstellt ist. Im Method Content werden wiederverwendbare WorkProducts (Arbeitsergebnisse), Tasks (Aufgaben), Roles (Rollen) und Guidances(Anleitungen) definiert, die beschreiben, wie gewisse Entwicklungsziele erreichtwerden. Ein Prozess verwendet den Method Content in einer spezifischen Reihen-folge, so dass die speziellen Eigenheiten eines Projekts abgebildet werden. DieseTrennung ermöglicht eine hohe Wiederverwendbarkeit und Anpassbarkeit, da einallgemeiner, prozessübergreifender Method Content definiert wird, der in verschie-denen Prozessen unterschiedlich verwendet werden kann. Um diese Eigenschaftenauch für Bestandteile eines Prozesses zu erreichen, gibt es neben Delivery Proces-ses (Bereitstellungsprozessen) sogenannte Capability Patterns (Prozessmuster),bei denen es sich um wiederverwendbare Prozessbausteine handelt.

Beispiel Die Aufgabe „Anforderungsanalyse“ wird im Method Content mit denbeteiligten Rollen und Artefakten definiert. In einem agilen Prozess wird dieseAufgabe mehrmals in den einzelnen Iterationen durchgeführt, wohingegen einanderer Prozess nach dem Wasserfallmodell diese Aufgabe nur genau einmal amAnfang spezifiziert. Neue Erkenntnisse zu dieser Aufgabe können zentral im Me-thod Content ergänzt werden und die Prozesse werden automatisch aktualisiert.

UMA definiert eine Method Library (Methodenbibliothek) als Container fürMethod Plug-Ins (Methoden-Plug-Ins), die den Method Content und die Prozesse


enthalten. Ein Method Plug-In ist in Packages (Pakete) unterteilt und kann andereMethod Plug-Ins referenzieren um deren Elemente verwenden zu können. DasKonzept der Variability (Variabilität) entspricht in ungefähr der objektorientiertenVererbung und ermöglicht die Erweiterung von Elementen. Auf dieses Konzeptwird genauer im Kapitel 4.3.2 Variability eingegangen.

3.2 EPF Composer

Der Eclipse Process Framework Composer (EPF Composer) ist ein Open SourceAutorenwerkzeug für das Erfassen und Veröffentlichen von Prozessen, das imRahmen des EPF entwickelt wurde. Er implementiert in der aktuellen Version1.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 Teildes OpenUP zu sehen ist. Die Benutzeroberfläche ist in die Bereiche Library(Bibliothek), Configuration (Konfiguration) und Editor unterteilt. Die Libraryenthält die Method Library mit den Method Plug-Ins und die Sicht entsprichtderen physischen Struktur inklusive der Trennung zwischen Method Contentund Process. Die aktuelle Konfiguration, die eine logische Teilmenge der MethodLibrary ist und durch das Auswählen von Method Content Packages und Prozessen

42 R. Freudenreich

entsteht, wird darunter angezeigt. Der Editor-Bereich dient dem Bearbeiten allerElemente.

Die Implementierung des EPF Composer ist Java-basiert und baut auf der EcliseRich Client Plattform sowie den Projekten Graphical Editing Framework (GEF)8,JTidy9 und International Components for Unicode for Java (ICU4J)10 auf. Eineweitere wichtige Komponente ist das Eclipse Modeling Framework (EMF)11, dasfür die auf dem Metamodell basierende Generierung der entsprechenden Klassenund des zugehörigen Codes sowie für die Persistenz der Method Library in XMIDateien 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 Composereine Webseite nach dem DHTML-Standard, so dass ein einheitlicher Zugriff (z.B.über das Intranet) auf die Informationen von verschiedensten Endgeräten ausmö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 entschei-dendes Kriterium. Interessante Fragestellungen dazu sind, in welchen Bereichen8 Ein Framework für die Entwicklung von graphischen Editoren und Diagrammen9 Ein Syntaxprüfer und Pretty Printer für HTML

10 Eine Java Bibliothek für Unicodeunterstützung11 Ein Modellierungs- und Codeerzeugungsframework für strukturierte Datenmodelle


das EPF eingesetzt werden kann, wie gut die Dokumentation für Anwender istund welche Best Practices für den Umgang mit dem EPF Composer bekanntsind.

4.1 Anwendungsgebiete

Das Ziel des EPF darin liegt ein erweiterbares Framework sowie exemplarischeWerkzeuge und Inhalte für das Entwickeln von Softwareentwicklungsprozessenbereitzustellen. Daher liegt in der Domäne der Softwareentwicklung auch dessenHauptanwendungsgebiet. Neben OpenUP wurden einige andere Entwicklungspro-zesse bzw. -ansätze bereits prototypisch oder auch vollständig modelliert. Dazuzählen u.a. Scrum, Extreme Programming, Rational Unified Process, MicrosoftSolution Framework und Model Driven Architecture. [14]

Doch obwohl das EPF in der o.g. Domäne seine Wurzeln hat, ist sein An-wendungsgebiet nicht auf diese beschränkt. UMA bzw. SPEM 2.0 definierenlediglich ein grundlegendes und allgemeingültiges Gerüst für die Modellierungvon Prozessen, z.B. dass diese durch Phasen und Aufgaben beschrieben werden,in denen Rollen Arbeitsergebnisse erstellen können. Theoretisch werden damitdie unterschiedlichsten Domänen abgedeckt. In der Praxis wurde dies bereitsdurch einige Fallstudien bewiesen, in denen Prozesse mit dem EPF modelliertwurden, 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. auchdie SOA Governance Lifecycle and Management Method, die IBM World WideProject Management Method und die IBM Global Services Method erfolgreichmodelliert. Beispiele für hardwarenahe Prozesse sind die Application SpecificIntegrated Circuits Method und der Ericsson’s Product Lifecycle ManagementProcess. Auch die Implementierung des Money-Lover-Prozesses für InvestementClubs zeigt, dass sich das EPF nicht auf einzelne Domänen beschränkt, sondernsich für die verschiedensten Bereiche und Branchen eignet. [14]

4.2 Anwenderdokumentation

Eine gute Dokumentation für Anwender ist eine Bedingung, dass eine Softwarein Unternehmen eingesetzt wird und das EPF erfüllt diese Anforderung vollund ganz. Neben einem Wiki12 bietet die EPF-Webseite eine „Getting Started“-Seite13 auf der man anhand von Dokumenten, Tutorials, Präsentationen undauch Screencasts einen guten Überblick und viele Informationen über das EPFund den EPF Composer bekommt. Hervorzuheben ist vor allem die sehr guteintegrierte Hilfe des EPF Composers. Neben einer detaillierten und ausführlichenDokumentation des Programms enthält sie gut ausgearbeitete Tutorials mit12 http://epf.eclipse.org13 http://www.eclipse.org/epf/general/getting_started.php

http://epf.eclipse.org

http://www.eclipse.org/epf/general/getting_started.php

44 R. Freudenreich

Schritt-für-Schritt-Anleitungen, die einen einfachen Einstieg in das Programmermöglichen. Für den Fall dass die vorhandene Dokumentation für mancheProbleme nicht ausreicht, gibt es eine Newsgroup14, in der weiterführende Fragenu.a. direkt von den EPF-Verantwortlichen beantwortet werden.

4.3 Best Practices

In diesem Kapitel werden zwei wesentliche Best Practices beschrieben, die diePotentiale des EPF Composer in der täglichen Arbeit ausnutzen können.

4.3.1 Synchronisation Aufgrund der Tatsache, dass der Method Contentin Prozessen referenziert wird und um die Inhalte iterativ und von mehrerenPersonen entwickeln zu können, besitzt der EPF Composer einen Synchronisation-Mechanismus für Descriptoren. Descriptoren sind Referenzobjekte, die Elementedes Methode Content (z.B. einen Task) in einem Prozess referenzieren. DurchDrag-and-Drop eines Tasks kann dieser einem Prozess hinzugefügt werden. An-statt dabei jedoch den Task zu kopieren, erstellt der EPF Composer einen TaskDescriptor, der auf den Task im Method Content referenziert. Zusätzlich zurReferenz hat ein Descriptor eigene Beziehungs- und Dokumentationseigenschaftenanhand derer das entsprechende Element an dieser speziellen Position im Prozessvom Original im Method Content abweichen kann.

Abbildung 8. Task Descriptor

Neben einer Standard-Synchronisation, die alle Eigenschaften eines Elementesangleicht, existiert eine benutzerdefinierte Synchronisation, in der die anzuglei-chenden Eigenschaften ausgewählt werden können. Die Synchronisationsrichtung14 news://news.eclipse.org/eclipse.technology.epf

http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.epf

news://news.eclipse.org/eclipse.technology.epf




erfolgt dabei immer vom Method Content zum Descriptor. Eine Synchronisierungin die andere Richtung existiert hingegen nicht, so dass Änderungen an Descrip-toren nicht automatisch auf Elemente des Method Content übertragen werdenkönnen. Beim Authoring ist daher darauf zu achten, dass globale Änderungenam Method Content und nicht an den Descriptoren im Prozess vorgenommenwerden.

Eine Synchronisierungsmöglichkeit für Capability Patters und Delivery Processesist nicht vorhanden. Für die Verwendung von Patterns in einen Delivery Pro-cess können diese entweder ohne Verbindung zum Original Pattern kopiert oderdynamisch eingebunden werden, so dass es das Original Pattern erweitert undÄnderungen an diesem automatisch übernommen werden. Im Delivery Processkann das Pattern dann durch das Hinzufügen oder Unterdrücken von Elemen-ten erweitert werden. Das Ändern von bestehenden Elementen des dynamischeingebunden Patterns ist im Delivery Process nicht möglich.

4.3.2 Variability Ein wichtiges Konzept der Wiederverwendbarkeit und An-passbarkeit ist die Method Content Variability (Variabilität). Diese ermöglichtdie Erweiterung von Elementen und entspricht in ungefähr der objektorientiertenVererbung. D.h. ein Element kann ein anderes Element auf verschiedene Art undWeisen erweitern. Dabei wird das Original nicht verändert, sondern als Grundlagefür neue Inhalte verwendet. Variability ermöglicht somit auch das Erstellen vonMethod Plug-Ins, die andere Method Plug-Ins erweitern. Eine Anwendungsmög-lichkeit dieses Mechanismus liegt darin, eine vorhandene Basismethode (z.B.OpenUP) an die eigenen Bedürfnisse anzupassen ohne das Method Plug-In derBasismethode selbst zu verändern. Da die Änderungen lediglich im neuen MethodPlug-In vorgenommen werden, kann die Basismethode mit wenig Aufwand undohne den Verlust der eigenen Änderungen aktualisiert werden, sobald eine neueVersion veröffentlicht wird.

Es existieren die folgenden vier Arten der Method Content Variability umein 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 desOriginals, die es nicht selbst definiert. Die HTML-Webseite enthält sowohldas Original als auch die Erweiterung.

Replace Die Erweiterung ersetzt das Original. Alle anderen Elemente, dievorher das Original referenzierten, zeigen nun auf die Erweiterung. DieHTML-Webseite enthält nur die Erweiterung.

Extend and Replace Die Erweiterung enthält die eigenen Inhalte und erbtalle Inhalte des Originals, die es nicht selbst definiert. Das Original wirdvon der Erweiterung ersetzt und die Referenzierungen auf die Erweiterunggeändert. Die HTML-Webseite enthält nur die Erweiterung.

46 R. Freudenreich

Abbildung 9. Variability eines Tasks

4.3.3 Verwendung eines Versionsverwaltungssystems Der EPF Compo-ser speichert alle Daten in XMI-Dateien, die auf dem XML-Format basieren,so dass bei der Entwicklung der Inhalte ein Versionskontrollsystem eingesetztwerden kann, dessen Vorteile in [19] beschrieben sind. Der EPF Composer un-terstützt von Haus aus IBM Rational ClearCase und das Concurrent VersionsSystem (CVS), aber auch andere Versionskontrollsysteme (z.B. Subversion) kön-nen verwendet werden. Dabei ist darauf zu achten, dass bereits relativ geringeÄnderungen im EPF Composer mehrere Dateien betreffen können. Eine Dateisollte dabei aber nicht parallel bearbeitet werden, weil ein Merge der XMI Dateienmöglichst zu vermeiden ist. Dateisperren (Locks) sind dafür gut geeignet undsollten verwendet werden. Da die Datei plugin.xmi eines Methoden Plug-Insbei vielen Änderungen betroffen ist, empfiehlt es sich den Inhalt auf verschie-dene Method Plug-Ins aufzuteilen. Pro Method Plug-In sollte eine Person dieRolle des Method Designer übernehmen und zu Beginn einen Method Sketcherstellen, um spätere strukturelle Veränderungen der XMI Dateien zu minimieren[17]. Beim Authoring ist häufiges Committen hilfreich um eine Korruption desRepositorys zu vermeiden. Treten dabei trotz Dateisperren Konflikte auf, solltedie Verantwortung für deren Beseitigung beim Method Designer liegen. Weiterehilfreiche Informationen enthält [7].

5 Erweiterbarkeit des EPF

Eine der wichtigsten Eigenschaften des EPF ist die Tatsache, dass es sich um einOpen Source Projekt handelt. Die zahlreichen Vorteile von Open Source geltensomit auch für das EPF. Einer der entscheidenden Vorteile ist dabei die freie


Verfügbarkeit des Quelltextes des EPF Composer und die daraus resultierendeMöglichkeit, dass jeder den EPF Composer weiterentwickeln und an die eigenenBedürfnisse anpassen kann. Dies eröffnet vollkommen neue Möglichkeiten, dieproprietären Alternativen vorenthalten sind.

5.1 Entwicklerdokumentation

So gut die Dokumentation für Anwender ist, so schlecht ist die Dokumentationfür Entwickler. Sie ist nur spärlich vorhanden, über verschiedenste Dokumenteverteilt und teilweise nicht aktuell. Die zentrale Anlaufstelle bietet die DevelopersResources Webseite15, auf der u.a. die beiden wichtigsten Dokumente verlinktsind. Diese sind der EPF Composer Architecture Overview16 und der EPFComposer Development Guide17. Der Development Guide enthält allerdingslediglich eine Anleitung wie die Eclipse IDE einzurichten ist, um mit dem Quelltextdes EPF Composers zu arbeiten. Diese Anleitung ist dafür aber sehr gut unddetailliert. Weiterführende Informationen (z.B. Tutorials, How-Tos, etc.) sindnicht vorhanden.

Auch die Dokumentation des Quelltextes ist schlecht und nur in begrenztemUmfang umgesetzt. Das entsprechende Javadoc18 ist daher nur schlecht zugebrauchen. Die Hürde für die Einarbeitung in den Quelltext des EPF Composersist dadurch hoch und erfordert eine Menge Geduld. Aufgrund dieses Umstandskann der EPF Composer einen seiner größten Trümpfe gegenüber propietärenKonkurrenzprodukten leider nur begrenzt ausspielen - die freie Verfügbarkeit desQuelltextes und der damit einhergehenden Möglichkeit für Entwickler weltweitden 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 seinerPlug-In Architektur, dessen Kern der Extension Point Mechanismus darstellt.Ein Extension Point stellt eine definierte Schnittstelle bereit, um ein Plug-In zuerweitern. Eine Extension kann an einem solchen Extension Point ansetzen umdem Plug-In zusätzliche Funktionalität bereitzustellen. Ein Beispiel für diesenMechanismus ist ein E-Mail-Programm das einen Extension Point für zusätzlicheSpam-Filter definiert, die von Extensions bereitgestellt werden. Auch die Plug-Insdes EPF Composer bieten diverse Extension Points an.

Eine Besonderheit ist die im Gegensatz zur objektorientierten Vererbung gegen-läufige Nutzungs- und Abhängigkeitsrichtung. Ein Extension Point nutzt eineExtension, ist aber gemäß dem Hollywood-Prinzip „We call you, don’t call us“nicht von dieser abhängig.15 http://www.eclipse.org/epf/general/developers_documentation.php16 http://www.eclipse.org/epf/composer_architecture/17 http://www.eclipse.org/epf/composer_dev_guide/18 http://www.eclipse.org/epf/composer_javadoc/epf1.5javadoc.zip

http://www.eclipse.org/epf/general/developers_documentation.php

http://www.eclipse.org/epf/composer_architecture/

http://www.eclipse.org/epf/composer_dev_guide/

http://www.eclipse.org/epf/composer_javadoc/epf1.5javadoc.zip

48 R. Freudenreich

Abbildung 10. Extension Point-Mechanismus

5.3 Fallbeispiel Prozess ausführen

Im Rahmen dieser Arbeit sollte eine prototypische Erweiterung des EPF Compo-sers als Fallbeispiel implementiert werden. Diese Erweiterung sollte untersuchenob und wie es möglich ist, einen Prozess nicht nur als HTML-Webseite anschauenzu können, sondern diesen im weitesten Sinne „ausführen“ zu können. D.h. dassein Benutzer direkt aus der Prozessdokumentation heraus eine bestimmte An-wendung starten kann, um ein Artefakt zu erstellen, das in diesem Prozessschrittbenötigt wird.

5.3.1 Möglichkeiten des EPF Der EPF Composer kann diese Anforderungbereits ohne Erweiterung mit gewissen Einschränkungen erfüllen. Es existiert derGuidance-Typ Template, in dem eine Vorlage für Work Products definiert werdenkann. Ein Template kann beschreibenden Text und angefügte Dateien enthalten.Die Dateien werden in das Method Plug-In importiert und dort gespeichert. BeimVeröffentlichen der Methode werden die angefügten Dateien in die Dateistrukturder HTML-Webseite übernommen und können von der entsprechenden Template-Seite heruntergeladen werden. Moderne Browser bieten die Möglichkeit, Dateiendirekt zu öffnen ohne diese explizit speichern zu müssen, so dass direkt die mitdem 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 undAnwendung vorhanden sein. Dies kann zu Problemen führen, weil manche Anwen-dungen mit keinerlei Dateityp verknüpft sind oder ein Dateityp standardmäßigmit einer anderen Anwendung verknüpft ist.

5.3.2 Erweiterung des EPF Aufgrund der freien Verfügbarkeit des Quell-codes des EPF Composer kann die Erweiterung selbst implementiert werden.Ziel der Erweiterung ist ein neues Attribut für Artefakte, in dem der Pfad derAnwendung gespeichert wird. Für die Implementierung der Erweiterung sind diefolgenden Schritte notwendig: Erweiterung des Metamodells, Programmierungdes Authoring Plug-Ins und Änderung der XSL Dateien.


Abbildung 11. Artefakt mit zugehörigem Template

Erweiterung des Metamodells Grundlage für die Entwicklung der Erweite-rung ist das UMA Metamodell und dessen Implementierung mit dem EMF. Dadiese kein Attribut für den Anwendungspfad definiert, muss dieses in der Dateiuma.ecore im Verzeichnis model/1.0.5 des Packets org.eclipse.epf.uma hin-zugefügt werden. Dies geschieht über den Eintrag New Child → EAttribute imKontextmenü des ArtifactDescription-Elements, wobei die Eigenschaften desneuen Attributs noch bearbeitet werden müssen (EAttributeType soll vom TypString und der Name soll appPath sein). Nach dem Speichern werden über dasKontextmenü der Datei uma.genmodel im selben Verzeichnis die Klassen undder dazugehörige Code generiert (Eintrag Generate Model Code).

Programmierung des Authoring Plug-Ins Der nächste Schritt besteht nundarin einen neuen Bereich im Artefakt-Editor zu erstellen, damit beim Authoringder Anwendungspfad angegeben werden kann. Da der EPF Composer hierfürkeinerlei Automatismus besitzt, muss der Quelltext selbst erstellt werden. An-statt das Plug-In org.eclipse.epf.authoring.ui zu verändern, bietet es sichan, dessen Extension Point descriptionPageSectionProvider für ein eigenesPlug-In zu erweitern. Die Klasse DescriptionFormPageApplicationSectionim neuen Plug-In de.uniaugsburg.epf.authoring.ui muss dafür das InterfaceISectionProvider und im speziellen dessen Methode createSection() imple-mentieren, wobei auf diverse Hilfsmethoden für das Erstellen von UI-Elementenzurückgegriffen werden kann. Das Erstellen der UI-Elemente wird in der Me-thode createApplicationSectionContent() und das Laden der Daten in derMethode loadApplicationSectionData() gekapselt.

Listing 3.1. Ausschnitt der Datei DescriptionFormPageApplicationSection.java1 public void createSection ( MethodElementEditor editor ,2 FormToolkit toolkit , Composite parent ) {

this. editor = editor ;4

// Get the element that is being edited6 methodElement = editor . getMethodElement ();

// Create this section only if editing an artifact

50 R. Freudenreich

8 if (!( methodElement instanceof Artifact )) { return ; }

10 // Get the description for the artifactartifactDescription = ( ArtifactDescription )

12 (( ContentElement ) methodElement ). getPresentation ();

14 // Create the new section with appropriate name and description textapplicationSection = 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 sectionloadApplicationSectionData ();

26 // Get the ActionManageractionMgr = editor . getActionManager ();

28// Add Listeners for new section (Modify , Action , etc .)

30 addListeners ();}

32protected void createApplicationSectionContent ( FormToolkit toolkit ) {

34 // Create the label and textbox for the application pathctrl_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 dialogctrl_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 ));}

46protected void loadApplicationSectionData () {

48 // Get application path for the method element and set textString appPath = artifactDescription . getAppPath ();

50 ctrl_appPath . setText ( appPath == null ? "" : appPath );}

Änderung der XSL Dateien Als letzter Schritt muss die Generierung derHTML-Webseite angepasst werden. Die HTML-Webseite wird mit einer XSLTransformation der in XML gespeicherten Daten generiert, so dass das Er-scheinungsbild der Webseiten durch einfaches Ändern der XSL Dateien bear-beitet werden kann. Diese Dateien befinden sich im Verzeichnis layout/xsldes Pakets org.eclipse.epf.library. Die Änderungen müssen direkt im je-weiligen XSL Template descriptionSection der Dateien artifact.xsl undartifact_descriptor.xsl vorgenommen werden, da es keinen entsprechendenExtension Point gibt.

Listing 3.2. Ausschnitt des XSL Templates descriptionSection1 <xsl: template name =" descriptionSection ">2 <xsl: param name =" description "/>

{...}4 <xsl: variable name =" appPath "

select =" $description / attribute [ @name ='appPath ']"/ >


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 entspre-chende HTML-Seite einen neuen Eintrag mit einer kleinen Grafik und einem Textmit dem Anwendungspfad. Durch einen Klick auf die Grafik soll die Anwendungdann gestartet werden. Ein Problem ist dabei, dass es eine große Sicherheitslückedarstellen würde, wenn eine Webseite ohne weiteres ein Programm auf einemanderen Computer ausführen könnte. Aus diesem Grund erlauben dies gängi-ge Webbrowser bis auf eine Ausnahme nicht. Beim Internet Explorer ist diesdurch eine Kombination aus VBScript und ActiveX möglich. Diese Funktionalitäterfordert 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 dieAnforderungen sehr gut erfüllt werden können. Die Implementierung kommt deneigenen Wünschen sehr nahe (siehe Abbildung 12). Aber auch diese hat Nachteile.Die Änderung des Metamodells ist eine Verletzung des (zukünftigen) SPEM

52 R. Freudenreich

2.0 Standards und wegen fehlender Extension Points muss der Quelltext vonzwei EPF Composer Plug-Ins geändert werden. Eine reibungslose Aktualisierungauf 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, sondernbietet außerdem mit dem Rational Method Composer (RMC) eine kommerzielleAlternative zu diesem an. Das EPF basiert entscheidend auf großen Teilen desRMC, die IBM als Spende in das Eclipse Projekt einbrachte, und bildet nunden Kern des RMC. Auf diesen Kern baut der RMC mit speziellen Featuresund zusätzlichen Inhalten auf. Hervorzuheben ist vor allem die Integration mitanderen Anwendungen von IBM Rational und der Rational Unified Process, derim RMC enthalten ist. [4]

Eine weitere Alternative mit einem dem EPF ähnlichen Funktionsumfang ist derIRIS Process Author (IPA) der Firma Osellus. Der IPA ist eine Webanwendungund enthält diverse Entwicklungsprozesse (u.a. RUP, OpenUP) basierend aufdem SPEM 1.1 Metamodell. Die mit dem IPA erstellten Inhalte können alsWebseite, Wiki oder als ausdruckbares Dokument veröffentlicht werden. Osellusbietet desweiteren mit dem IRIS Process Live ein Werkzeug an, um Prozesse inVerbindung mit dem Microsoft Visual Studio Team System auszuführen.

Ein Blick über den Tellerrand liefert mit Anwendungen für domänenspezifischeSprachen (z.B. MetaEdit+) und für die Geschäftsprozessmodellierung im weites-ten Sinne weitere Alternativen zum EPF. Die Unterschiede sind allerdings sehrgroß.

7 Schluss

Das EPF ist ein mächtiges Prozess-Framework, das aufgrund seiner Flexibilitätin vielen Anwendungsgebieten eingesetzt werden kann und durch seinen Statusals Open Source Projekt eine gute Erweiterbarkeit besitzt. [6] zeigt dass auchfortgeschrittenere Erweiterungen möglich sind. Es besteht allerdings Verbesse-rungsbedarf bei der Dokumentation für Entwickler. Das EPF ist eines der erstenFrameworks, das den zukünftigen SPEM 2.0 Standard unterstützen wird. Es istdaher gut für die Zukunft aufgestellt eine wichtige Rolle in der modellbasiertenSoftwareentwicklung zu spielen, denn eine Modellierung der Softwareentwick-lungsprozesse ist für alle Entwicklungsprojekte sinnvoll. Vor allem mittlere undgroße Projekte profitieren davon.

Literatur

[1] E. Dijkstra. The Humble Programmer. Commun. ACM 15, 10:859–866, 1972.


[2] EPF. Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview.http://www.eclipse.org/epf/composer_architecture/, Abruf am 24.03.2009.

[3] EPF. What is the Eclipse Process Framework. http://www.eclipse.org/epf/community/Whats_EPF.ppt, Abruf am 18.03.2009.

[4] P. Haumer. IBM Rational Method Composer: Part 1: Key concepts, Dezember2005. http://www.ibm.com/developerworks/rational/library/dec05/haumer/,Abruf am 24.03.2009.

[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):326–358, 2004.

[6] M. Hermanns. Erweiterung der ViPER-Umgebung zur methodengestützten Ent-wicklung mit MeDUSA, Juli 2007. http://www.viper.sc/images/c/c8/Marcel_Hermanns_Intermediate_Talk.ppt, Abruf am 26.03.2009.

[7] IBM. Using Eclipse Process Framework Composer with a Version ControlSystem, 2006. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.epf/docs/Using%20EPF%20with%20a%20Version%20Control%20System.rtf?root=Technology_Project&view=log, Abruf am 08.04.2009.

[8] B. Kahlbrandt. Software-Engineering mit der Unified Modeling Language. Springer,2001.

[9] P. Kroll. OpenUP in a Nutshell, 2007. http://www.ibm.com/developerworks/rational/library/sep07/kroll/index.html, Abruf am 26.03.2009.

[10] P. Kruchten. Der Rational Unified Process. Addison-Wesley, 1999.[11] P. Liggesmeyer and D. Rombach. Software-Engineering eingebetteter Systeme:

Grundlagen-Methodik-Anwendungen. Spektrum Akademischer Verlag, 2005.[12] OMG. Software Process Engineering Meta-Model 2.0 OMG Draft Adopted Speci-

fication. ad/05-05-06, Mai 2005.[13] OMG. Software Process Engineering Metamodel Specification Version 1.1.

formal/05-01-06, January 2005.[14] OMG. Second Revised SPEM 2.0 Submission. ad/06-04-12, April 2006.[15] OMG. Software & Systems Process Engineering Meta-Model Specification.

formal/08-04-01, April 2008.[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, 1987. IEEE Computer Society Press.

[17] C. Péraire. A roadmap to method development, 2007. http://www.ibm.com/developerworks/rational/library/feb07/peraire/index.html, Abruf am09.04.2009.

[18] K. Schwaber et al. Manifesto for Agile Software Development, 2001. http://agilemanifesto.org/, Abruf am 15.03.2009.

[19] J. Vesperman. CVS. Versionskontrolle und Quellcode-Management. O’Reilly, 2004.

http://www.eclipse.org/epf/composer_architecture/

http://www.eclipse.org/epf/community/Whats_EPF.ppt

http://www.eclipse.org/epf/community/Whats_EPF.ppt

http://www.ibm.com/developerworks/rational/library/dec05/haumer/

http://www.viper.sc/images/c/c8/Marcel_Hermanns_Intermediate_Talk.ppt

http://www.viper.sc/images/c/c8/Marcel_Hermanns_Intermediate_Talk.ppt

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.epf/docs/Using%20EPF%20with%20a%20Version%20Control%20System.rtf?root=Technology_Project&view=log



http://www.ibm.com/developerworks/rational/library/sep07/kroll/index.html

http://www.ibm.com/developerworks/rational/library/sep07/kroll/index.html

http://www.ibm.com/developerworks/rational/library/feb07/peraire/index.html

http://www.ibm.com/developerworks/rational/library/feb07/peraire/index.html

http://agilemanifesto.org/

http://agilemanifesto.org/

Binding zwischen XML-Schema-Modellen undJava-Beans (JAXB)

Panayot Radinski


Zusammenfassung Im Rahmen dieser Seminararbeit wird die modell-basierte Softwareentwicklung vorgestellt. Speziell wird die Bindung zwi-schen XML-Schema-Modellen und Java-Beans untersucht. Java Architec-ture for XML Binding (JAXB) ist eine der populärsten Techniken fürdie Modelltransformation bzw. Datentransfer zwischen Java und XML.Im Gegensatz zu anderen parser-basierten Ansätzen wie SAX oder DOMbietet JAXB eine höhere Flexibilität und einen vereinfachten Zugriffauf XML Dateien an, so dass Programmierer unkompliziert XML inihren Java Anwendungen integrieren können. Wie genau JAXB diese Bin-dung zwischen Java und XML herstellt, wird anhand mehrerer Beispieleveranschaulicht.

1 Einleitung

1.1 Modellbasierte Softwareentwicklung

Die heutigen Krisenzeiten, die vielfältigen Bedürfnisse der Kunden, der sichständig ändernde Gesetzesrahmen erfordern von den IT-Unternehmen eine neue,flexiblere Art der Softwareentwicklung. Einen relativ neuen Ansatz stellt dieModellbasierte Softwareentwicklung, die sich gegenüber der klassischen Soft-wareentwicklung durch etliche Vorteile auszeichnet - mehr Effizienz, höhereSoftwarequalität und bessere Wiederverwendbarkeit.

Im Mittelpunkt der Modellbasierten Softwareentwicklung stehen formale Mo-delle, die die charakteristischen Domainbegriffe und die Beziehungen zwischendiesen Domainbegriffen, ohne Bezug auf die Softwaresysteme, beschreiben. DieseModelle werden mit Hilfe von Werkzeugen für einen Anwendungsbereich spezifi-sche, aber von den technologischen Details abstrahierte, plattformunabhängigeModelle transformiert. Anschließend werden automatisch aus den transformiertenModellen detailierte, plattformspezifische Modelle generiert, die möglichst großeTeile 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 objektorientier-ten Programmiersprachen entwickelt. Plattformunabhängigkeit, Portierbarkeit,

Binding zwischen XML-Schema-Modellen und Java-Beans (JAXB) 55

Robustheit, Sicherheit, Modularität und viele mehr zählen zu den wichtigstenEigenschaften, die diese Sprache so beliebt machen. Neben der Java StandardEdition (SE), die für die Implementierung von allgemeinen, portablen Anwendun-gen eingesetzt wird, gibt es die Java Micro Edition (ME) für Mobiltelefone oderPDAs und die Java Enterprise Edition (EE) für transaktionsbasierte Systeme.In der Spezifikation von Java wurden Softwarekomponenten und Dienste defi-niert, die die Grundbausteine für mehrschichtige, verteilte (Web)-Architekturenbereitstellen, um die stets steigende Komplexität zu beherrschen. Solche wie-derverwendbaren Softwarekomponenten werden im Java Umfeld Beans genannt.Es gibt die Java Beans (JB) und die Enterprise Java Beans (EJB), die sich inder Aufgabe und im Einsatzgebiet unterscheiden. Die JBs werden als Containerfü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 LinieServermechanismen wie Persistenz, Load Balancing, Sicherheit, Transaktions-unterstützung und können ausschließlich in einem EJB-Container eines J2EEApplication-Servers ablaufen (vgl. [3]). Im Allgemeinen bestehen beide Typen vonBeans aus Java Klassen, die einem Java-Bean-Komponentenmodell entsprechen.

Die Kommunikation zwischen den einzelnen Beans wird durch klar definierteSchnittstellen sichergestellt, die das Geheimnisprinzip wahren. Das bedeutet,dass die innere Anwendungslogik verborgen bleibt und die Kommunikation mitder Umwelt über eine äußere Hülle stattfindet, die mit öffentlichen getter- undsetter-Methoden ausgestattet ist. So können Komponenten unterschiedlicherHersteller 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 implemeniertwerden, um mit XML umgehen zu können. Es gibt verschiedene Techniken, wieDOM, SAX, Pull API, Data Binding usw., die auch in Java vorhanden sind undXML Dateien verarbeiten können. Die Parser-basierten DOM, SAX und PullAPI sind aber nicht immer optimal. DOM verbraucht viel Speicher, SAX arbeitetsequentiell, Pull API ist sehr speichereffizient, hat aber auch eine sequentielleArbeitsweise. Der wesentliche Nachteil der parser-basierten Ansätze ist, dassnicht alle Programmierer mit solchen komplizierten Techniken anvertraut sind.Data Binding benutzt einen eigenen XML-Parser und transformiert im Gegensatzzu diesen Verfahren die XML Daten in Java Objekte, die so für den direktenProgrammzugriff bereitgestellt werden (vgl. [4]). Java Architecture for XMLBinding (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 XMLund Java auseinander. Im Nachfolgenden Kapitel wird genau erklärt, wie JAXBJava Datenmodelle in XML Schema, Java Objekte in XML Dateien und dannbeides umgekehrt transformieren kann. Dafür ist es nicht notwendig, den genauenAufbau der Beans zu kennen. Viel wichtiger ist es, wie diese äußere Bean-Hüllemit XML interagiert.

56 P. Radinski

2 Hauptteil

2.1 XML und XML-Schema

2.1.1 XML (kurz gefasst) XML ist allgemein bekannt und wird hier nurkurz zur Wiederholung vorgestellt. Ein großer Vorteil von dieser erweiterbarenAuszeichnungssprache ist, dass sie, obwohl sie strengen Syntaxregeln unterliegt,für einen Menschen sehr einfach zu lesen ist. Um das Verarbeiten durch Parsernzu ermöglichen, wird XML als eine hierarchische Baumstruktur organisiert. Diesbringt aber den Nachteil mit sich, dass viele redundante Informationen gespeichertwerden müssen. Der grundsätzliche Aufbau eines XML Dokuments wird anhandeines kurzen Beispiels veranschaulicht, in dem einem Einwohner eine Frau mitName, Geburtsdatum und Bild zugeordnet wird.

Listing 4.1. Das XML Dokument1 <?xml version ="1.0" encoding ="UTF -8" standalone =" yes "?>2 <Einwohner >

<Frau Name =" Stephanie Müller ">4 <Geburtsdatum >15.11.1980 </ Geburtsdatum >

<Visitenkarte Pfad ="D:\ stephie .doc" />6 <Haustier >Katze </ Haustier >

</Frau >8 

</Einwohner >

Ein XML Dokument fängt immer mit einer Deklaration (Zeile 1) an, in derdie XML Version und die Zeichenkodierung definiert werden. Mit standalone wirdangegeben, ob ein externes XML Schema bzw. Document Type Definition (DTD)angebunden wird. Einwohner, Frau und Geburtsdatum sind XML-Elemente. Siefangen immer mit einem in spitzen Klammern geschriebenen Start-Tag <na-me> an und werden mit einem Ende-Tag </name> abgeschlossen. Elementehaben gewöhnlich einen Inhalt (Zeile 4 - 15.11.1980 ) oder sie sind leer. Bild istein leeres Element und besteht aus einem Tag in der Form <elementname />.XML-Attribute sind Zusatzinformationen über Elemente. Stephanie Müller istder Inhalt des Attributs Name, das das Element Frau näher beschreibt. Wie einKommentar aufgebaut wird, ist in der Zeile 7 zu sehen.

Damit XML Dateien auch richtig von Parsern gelesen werden können, müssensie eine wohlgeformte Dokumentenstruktur haben. D.h. sie dürfen genau einWurzelelement besitzen (<Einwohner>), die Schachtelung und die Namen derElemente müssen korrekt sein und die Attribute innerhalb eines Elementes dürfennicht dieselbe Bezeichnung haben. In XML wird ausserdem zwischen Groß- undKleinschreibung unterschieden.

Wenn XML für den Datenaustausch eingesetzt wird, muss es sichergestelltwerden, dass die Informationsquelle und der Datenempfänger „dieselbe Spra-che sprechen“. Dafür muss die für die Kommunikation eingesetzte XML Dateiwohlgeformt 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


Schema-Modell definiert, ob die prinzipielle Struktur eines XML Dokumentes undder Inhalt der darin verwendeten Tags valide sind. Unter der Benutzung von DTDoder XML-Schema können Modelle definiert werden, die die Gültigkeit von XMLDateien überprüfen. In dieser Arbeit wird beschrieben, wie XML-Schema-Modelleden Datentransfer zwischen Java Komponenten herstellen können.

2.1.2 XML-Schema Mit einem XML-Schema kann genau festgelegt werden,wie ein gültiges XML Dokument aussehen muss. Eine Menge Merkmale zeichnendas XML-Schema im Vergleich zu anderen Definitionssprachen aus (vgl. [1]):

. Die Syntax von XML wird in XML-Schema-Dateien benutzt, deshalb ist esnicht 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 wer-den.

. XML-Namensräume (namespaces) werden unterstützt. Damit können Ele-mente, die in verschiedenen XML-Schemata benutzt werden, eindeutig unter-schieden werden.

. XML-Schema bietet ein besser ausgeprägtes Schlüsselkonzept, so dass Ele-mente eindeutig referenziert werden können.

. Inhaltsmodelle von Elementen lassen sich mit XML-Schema auch lokal de-finieren, typisieren und wiederverwenden - mehrfach verwendete Elementewerden nur einmal definiert.

. Aber: XML-Schema unterstützt so viele Möglichkeiten zur Definition vonXML-Dokumenten, dass die XML-Schema-Dateien oft sehr groß, kompliziertund schwer zu lesen werden.

In Listing 4.2 wird der Aufbau einer XML-Schema-Datei eingeführt, die die inListing 4.1 dargestellte XML Datei auf ihre Gültigkeit überprüft.

Listing 4.2. Das XML-Schema1 <?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 einerXML-Deklaration und besitzt genau ein Wurzelelement - das ist immer derTag <xs:schema>. Mit den Attributen version und xmlns wird angegeben, umwelche XML-Schema-Version es sich handelt und welche XML-Namensräumebenutzt werden. <xs:complexType> definiert die zusammenhängende Elemen-tenstruktur Frau. Sie besteht aus dem Attribut (<xs:attribute>) Name und den

58 P. Radinski

drei Elementen (<xs:element>) Geburtsdatum, Visitenkarte und Haustier. Mitder Angabe use=“required“ muss der Name einer Frau stets vorhanden sein.<xs:sequence> bestimmt die Reihenfolge, in der die Elemente eines komplexenDatentyps vorkommen - Visitenkarte darf z.B. nicht vor Geburtsdatum auftreten.Ausserdem werden innerhalb des <xs:sequence> Tags die Wertebereiche derenthaltenen Elemente durch minOccurs=“1“ und maxOccurs=“1“ definiert. ImBeispiel 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 inder 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 undden Inhalt einer XML Datei viel oder wenig einschränken. Im Listing 4.2 wirdz.B. keine Vorgabe für das Attribut Pfad des Elementes Visitenkarte gemachtund 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 vielmehr an (vgl. [2]). Für das Element Haustier kann eine Liste mit den zulässigenWerten für den Inhalt hinzugefügt werden. Ein neuer Datentyp <xs:simpleType>mit dem Namen alleHaustiere sowie eine Liste dieses neuen Typs werden demElement Haustier zugeordnet (siehe Listing 4.3). In der XML Datei wird dannder Inhalt von Haustier so aussehen: (Hund), (Katze), (Vogel) , aber auch (HundKatze Vogel) ist möglich - (Rex) ist dann eine falsche Eingabe.

Listing 4.3. XML-Schema Erweiterung 11 <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 >

Für ein Haustier kann ein beliebiger Datentyp (xs:anyType) definiert werden,so dass als Elementinhalt die Anzahl der Haustiere, ihre Namen usw. zulässigsind (siehe Listing 4.4).

Listing 4.4. XML-Schema Erweiterung 21 <xs: element name =" Haustier " type =" xs: anyType "/>

Der komplexe Datentyp Frau kann um das Element Ehemann erweitert wer-den (xs:extension) und so wird der neue Typ neueFrau entstehen (siehe Listing4.5).


Listing 4.5. XML-Schema Erweiterung 31 <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 Ausdruckebenfalls einschränken (xs:restriction). So muss der Geburtstag immer die FormJJJJ.MM.TT haben (siehe Listing 4.6).

Listing 4.6. XML-Schema Erweiterung 41 <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 darinenthaltenen Elemente eine eindeutige (unique) Kombination bilden müssen - eineFrau mit denselben Merkmalen darf nur einmal vorkommen. Zu dieser Elemen-tenkombination kann dann ein Schlüssel (key) bereitgestellt werden, so dass vonaußen auf die Daten referenziert werden kann. Das XML Schema erlaubt sogarfremde Schemata wieder zu verwenden. Die Verknüpfung zwischen verschiedenenSchema Dateien wird von den include-, import- und redefine-Klauseln gewähr-leistet. Der Typ Frau kann durch den Import einer anderen Frau-Definition soangepasst werden, dass von beiden Schemata kompatible XML Dateien abge-leitet werden können. Beispiele zu den Schlüssel- und Importeigenschaften desXML-Schemas wurden herausgelassen, da sie zu kompliziert und eigentlich fürdieses 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 einfachbenutzen können. Es ist nicht notwendig, in Java die XML Dateien zu parsenbzw. zu validieren - diese Aufgabe übernimmt JAXB. In den früheren Versionen(1.x) von JAXB gab es aber mehrere Probleme beim Einsatz dieser Technolo-gie. Laufzeitfehler auf den unterschiedlichen Java Virtual Machines haben diewesentlichen Vorteile von Java wie Plattformunabhängigkeit und Portabilitätbeeinträchtigt. Der Fokus bei der Entwicklung von JAXB lag nur auf der Trans-formation von XML-Schema zu Java Datenmodelle und nicht umgekehrt, wasdie Kommunikation zwischen Java Anwendungen sehr erschwerte (vgl. [5]).

Mit der aktuellen JAXB Version 2.x wurden die meisten Probleme behobenund viele innovative Verbesserungen eingeführt (vgl. [6]):

60 P. Radinski

. Eine High-Level-XML-API erleichtert die Integration von XML, indem siedie Komplexität von XML Parsern von den Java Entwicklern fernhält undstattdessen eine allgemein bekannte und einfache Art für die Bindung vonXML anbietet - nämlich die Java Beans (auch POJOs genannt - Plain OldJava Objects). Der jüngste Trend zu den POJOs basiert auf dem Strebennach mehr Einfachheit bei der Implementierung von Java Objekten und passtsehr 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 Edition5 eingeführt wurden. Die JAXB-charakteristischen Annotationen werden imKapitel 2.2.1 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 wurdeein sehr wichtiger Schritt gemacht, um die Verbindung von Java Anwendungen(auch Java Webservices) anhand XML zu ermöglichen. Das bedeutet, dass dieGenerierung einer XML Datei aus einem Java Objekt und die Transformationdieser XML Datei danach in einem zu dem ursprünglichen, äquivalenten JavaObjekt unterstützt wird.

. Die Validierung von XML Dokumenten mit Hilfe des XML-Schemas ist auchein Teil der Verbesserungen in JAXB. Bei der Kommunikation zwischenJava Programmen ist es sehr wichtig, dass gültige XML Daten ausgetauschtwerden.

Wie diese Verbesserungen eine korrekte, bidirektionale Bindung zwischenJava und XML ermöglichen, wird in den nächsten Kapiteln dieser Seminararbeitanhand ausführlicher Beispiele veranschaulicht, die auf Windows Vista mit derEntwicklungsumgebung Eclipse 3.3.2 und der Java Version jdk1.6.0_07 erstelltwurden. Es gibt zwei Arten, wie JAXB auf einem Betriebssystem installiertwerden kann. Einerseits ist JAXB ein Teil von Java geworden (die Klassen sindunter javax.xml.bind.* zu finden), andererseits kann die aktuelle JAXB Versionvon der Homepage (https://jaxb.dev.java.net/) heruntergeladen werden und inEclipse entsprechend importiert werden (für die Beispiele wird hier die aktuellste2.1.10 Version von JAXB benutzt).

Auf der Abbildung 1 sind die fünf grundlegenden Bausteine von JAXBdargestellt. Zu jedem wird jeweils ein Kapitel mit Beispielen gewidmet. Dervollständige Quellcode zu den Beispielen ist immer im Anhang zu finden.

. Deserialisieren (Unmarshalling) - Die Transformation von einer XMLDatei in ein Java Objekt (automatische Validierung möglich).

. Serialisieren (Marshalling) - Die Transformation von einem Java Objektin eine XML Datei (automatische Validierung möglich).

. Schemakompiler - Die Transformation von einem XML-Schema in ein JavaDatenmodell.

. Schemagenerator - Die Transformation von einem Java Datenmodell inein XML-Schema.


. Annotationen - Mit den JAXB Annotationen werden alle vier oben aufge-führten Funktionen konfiguriert. Es gibt die Mapping-Annotationen, die inJava definiert werden und die Bindungskonfigurationen - die Annotationen -die im XML-Schema zum Einsatz kommen.

Abbildung 1. JAXB Schema

2.2.1 JAXB Java-Annotationen In diesem Kapitel liegt der Schwerpunktauf den Mapping-Annotationen, da sie für einen Java Programmierer, der sichmit XML-Schema und XML Parsern nicht auskennt, von großer Bedeutungsind. Die Bindungskonfigurationen werden im Kapitel Schemakompiler nähererläutert. Um die volle Funktionalität von JAXB nutzen zu können, muss einProgrammierer die dafür spezifischen Java-Annotationen gut kennen. Sie steuerndie korrekte Bindung zwischen Java und XML. Es sind insgesamt 29 Annotationenverfügbar, die auf verschiedenen Ebenen eingesetzt werden können. Es gibtdie Package-, Class-, Enum type-, JavaBean Property/field- und Parameter-Ebenen. Die Annotationen werden vor dem Java Element deklariert, auf dem sieangewendet werden sollen (siehe Listing 4.7). Sie haben folgenden Standardaufbau(@Annotationsname(Parameter)) und die wichtigsten davon werden nun nähererläutert (vgl. [11]).

Listing 4.7. JAXB Annotationen Anwendung1 ...2 // Annotation auf Class - Ebene

@XmlRootElement4 public class Frau {

6 // Annotation auf JavaBean Property /field - Ebene@XmlElement

8 public String Name;

10 // Annoation auf JavaBean Property /field - Ebene

62 P. Radinski

@XmlTransient12 public void setName ( String Name ){

this.Name = Name;14 }

}16 ...

@XmlRootElement:XmlRootElement gibt an, dass die nachfolgende Java Klassendefinition einem

XMLWurzelelement entspricht. Mit der Angabe@XmlRootElement(name=“XMLFrau“)wird vorgegeben, dass die Java Klasse Frau in XML den Namen XMLFrau hat.Diese Annotation kann auf Class- und Enum type-Ebenen angewendet werden.@XmlElement:

Mit XmlElement werden Java Attribute gekennzeichnet, die in XML als XML-Elemente dargestellt werden. @XmlElement(defaultValue=“Hund“) definiert denStandardwert für ein Element. Andere wichtige Parameter, die diese Annotationspezifizieren können, sind name, namespace, nillable, required und type. XmlEle-ment kann nur auf JavaBean Property/field-Ebene angewendet werden.@XmlAccessorType:

Die Annotation XmlAccessorType legt fest, welche Attribute einer Java Klassein XML abgebildet werden sollen. Es gibt vier Parametererweiterungen, dieabhängig von der Sichtbarkeit (public, private usw.) der Java Attribute ein ent-sprechendes Verhalten steuern. Mit @XmlAccessorType(XmlAccessType.NONE)werden nur die Attribute serialisiert, die auf @XmlElement und @XmlAttributefolgen. Mit XmlAccessType.PUBLIC_MEMBER werden alle public Attributeserialisiert. Mit XmlAccessType.PROPERTY werden nur Attribute abgebildet,die öffentliche getter- oder setter-Methoden haben. XmlAccessType.FIELD sagtaus, dass alle Attribute, außer der statischen, serialisiert werden sollen. DieseAnnotation kann auf Package- und Class-Ebenen angewendet werden.@XmlAccessorOrder:

XmlAccessorOrder erlaubt, die Reihenfolge der in XML abgebildeten Ele-mente zu ändern. Mit dem Parameter @XmlAccessorOrder(XmlAccessOrder.ALPHABETICAL) wird eine alphabetische Anordnung erzwungen, ansonstenerfolgt eine beliebige Sortierung. Diese Annotation kann auf Package- und Class-Ebenen angewendet werden.@XmlTransient:

Über die Annotation XmlTransient wird angegeben, dass ein Java Attributnicht serialisiert werden darf. Diese Annotation kann auf JavaBean Property/field-Ebene angewendet werden.@XmlAttribute:

Mit XmlAttribute werden die Attribute einer Java Klasse als XML Atrributeabgebildet. Diese Annotation kann auf JavaBean Property/field-Ebene angewen-det werden.@XmlType:

Die Annotation XmlType wird benutzt, um komplexe bzw. einfache XML Da-tentypen (<xs:complexType>, <xs:simpleType>) zu definieren. Diese Annotationkann auf Class- und Enum-Ebenen angewendet werden.@XmlValue:


Mit der Annotation XmlValue wird ein Java Attribut in ein XML Werttransformiert (<xml>XMLWert</xml>). XmlValue und XmlElement könnennicht gleichzeitig in derselben Klasse benutzt werden. Diese Annotation kann aufJavaBean Property/field-Ebene angewendet werden.

Die bereits vorgestellten und die restlichen JAXB Annotationen erlauben einepräzise Bindung zwischen Java und XML. Sowohl Listen (@XmlElementWrapper,@XmlElements), als auch der Umgang mit verschiedenen Datentypen (@Xml-JavaTypeAdapter), Schlüsseleigenschaften (@XmlID) und Importeigenschaften(@XmlAttachmentRef, @XmlNs) des XML-Schemas werden unterstützt. Damitschafft JAXB einen weiteren Schritt in Richtung seiner primären Ziele, nämlichdas XML-Schema möglichst vollständig zu unterstützen.

2.2.2 Schemakompiler Beim Schemakompiler werden XML-Schemata in Ja-va Datenmodelle umgewandelt. Für seine Anwendung ist also ein XML-Schemaerforderlich. Dieses Schema kann dann über zwei verschiedenen Wege in einfertiges Java Datenmodell transformiert werden - entweder die Kommandozeileoder viel bequemer, ein ANT-Skript in Eclipse (auch Build-Skript genannt),welches später im Abschnitt noch genauer erläutert wird. Beim Ausführen desANT-Skripts werden mindestens zwei Java Klassen erstellt - mindestens eineJava Klasse zum XML-Schema und genau eine ObjectFactory.java Klasse.

Im Beispiel mit der Frau wird nun das XML-Schema Frau.xsd aus Listing4.2 benutzt, mit dem einzigen Unterschied, dass <xs:attribute name=“Name“>erst nach dem <xs:sequence> Attribut vorkommen darf (siehe Listing 4.27 imAnhang) - ansonsten meldet Eclipse einen Fehler, dass <xs:sequence> falschaufgebaut wurde. Diese Frau.xsd wird im Projektordner schema abgelegt. DasANT-Skript SchemaKompiler.xml wird im Projekt-Root-Ordner erstellt undwird über Run As -> Ant Build ausgeführt. Ein neuer Ordner generated wirdautomatisch angelegt und in diesem sind die fertigen Java Klassen Frau.java undObjectFactory.java zu finden.

Bevor aber gezeigt und erklärt wird, wie der Ablauf des Schemakompilerstatsächlich ist, müssen einige Begriffe und Zusammenhänge näher erläutert werden.Einige Grundbausteine sind beim Schemakompiler und beim Schemageneratorsehr ähnlich und werden nun hier vorgestellt. Folgende Transformationsregelngelten in beiden Richtungen - also von XML-Schema zu Java Datenmodell(Schemakompiler) und umgekehrt (Schemagenerator) (vgl. [7]):

. XML Namespace <=> Java Paket. Ein <targetNamespace=http://frau>wird zu einem package frau übersetzt und umgekehrt.

. XML komplexer Datentyp <=> Java Klasse. Ein <xs:complexType na-me=“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 Stringehemann übersetzt und umgekehrt.

64 P. Radinski

. XML einfacher Datentyp mit Enumeration <=> Java Enumeration. Siehe4.8.

Listing 4.8. Enumeration1 <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 ...

10 public enum Beziehung {FREUND ,

12 EHEMANN ;}

. XML Element <=> Java Attribut. Ein <xs:element name=“haustier“ ty-pe=“xs:string“> wird zu einem protected String Haustier übersetzt undumgekehrt.

Ein ANT-Skript wird beim Schemakompiler und beim Schemagenerator ein-gesetzt und automatisiert die Umwandlungen in beiden Richtungen (Java nachXML bzw. XML nach Java). Er hat in beiden Fällen denselben Aufbau, aberverschiedene 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 Transformationsbe-fehle manuell anzustoßen, werden sie in Eclipse in einem ANT-Skript gepacktund ausgeführt. Dieses Skript besteht gewöhnlich aus folgenden Bereichen (vgl.[12]):

. Im Bereich <project> wird das Default Projekt definiert - zu jedem Projektgehört genau eine Build Datei.

. Eine Beschreibung bzw. Kommentare können im <description> Tag angege-ben werden.

. <property name=“var“...> wird angewendet, um Redundanz im Quellcode zuvermeiden. Die Variable var kann dann durch ${var} angesprochen werden.

. In <path> muss angegeben werden, wo sich das JDK und die JAXB Klassenbefinden, da sie für die Transformation notwendig sind. Über <classpath>kann eine Funktion referenziert werden, die nicht in einer Datei mit einemexistierenden Pfad auf dem System gespeichert ist.

. Ein Projekt besteht aus mindestens einem <target> Bereich. Die Targetssind sozusagen die Ablauflogik eines ANT-Skripts. Sie können sich unter-einander aufrufen und stoßen verschieden Aufgaben an - beispielsweise dieKompilierung des Quellcodes, oder das Verpacken in einem JAR-Archiv usw.

. Funktionen werden in ANT mit dem <task> Tag bezeichnet. Es gibt vor-definierte Tasks (der Java-Compiler javac, ANT Tasks wie copy, delete, zipund mail) und benutzerdefinierte Tasks. xjc und schemaGen sind JAXBspezifische Tasks, die in ANT als “benutzerdefiniert“ mit dem Tag <taskdef>angegeben werden, da sie dem ANT Kompiler nicht direkt bekannt sind.


In Listing 4.9 wird das ANT-Skript vorgeführt, das die Transformation vonXML-Schema (Frau.xsd) nach Java steuert. Die ANT Datei beginnt mit derAngabe der XML Version. Wenn kein Target spezifiziert sein sollte, wird im<project> Tag mit dem Attribut default den default-Target definiert - xjc ist dasJAXB-Task für die Schemakompilierung. Mit basedir wird das Hauptverzeichnisvorgegeben, wo sich alle Dateien zu dem gegebenen Projekt befinden. Ohnedie Angabe der Ordner <path><fileset dir=...>, wo sich die JDK und JAXBQuelldaten auf dem System befinden, kann das ANT-Skript nicht funktionieren.Der <path> Tag besitzt außerdem das Attribut id=“classpath“, das später in derbenutzerdefinierten Funktion <taskdef name=“xjc“...> referenziert wird. So wirddem 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 werdendie Quell- und die Zielverzeichnisse angegeben - in welchem Ordner das Schemaliegt (<schema dir=“schema“>), wie das Schema heisst (Frau.xsd) und wo sollendie neuen Java Datenmodelle (Klassen) erstellt werden (<xjc destdir=“.“>).

Listing 4.9. ANT Skript - SchemaKompiler.xml1 <?xml version ="1.0"? >2 <project default =" xjc" basedir ="." >

4 <path id =" classpath "><fileset dir ="C:\ Sun\jaxb -ri -20090206\ 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 (Lis-ting 4.11) und ObjectFactory.java (Listing 4.10) Klassen. In der ObjectFactorywerden create-Methoden zu allen erzeugten Java Klassen gesammelt (vgl. [8]).Falls in einem XML-Schema zwei komplexe Datentypen definiert sind, werden beider Transformation zwei Java Klassen erzeugt (z.B. Frau1.java und Frau2.java).In der ObjectFactory Klasse werden dann entsprechend zwei create-MethodencreateFrau1() und createFrau2() generiert. Diese Factory-Klasse ist eine Artzentrale Verwaltung. Dort können alle erzeugten Java Klassen instanziert werden.Sie wird durch die Annotation @XmlRegistry auf Class-Ebene gekennzeichnetund kann ebenso manuell erstellt und angepasst werden. Die zu Listing 4.10vollständige Klasse ist im Anhang unter Listing 4.29 zu finden.

Listing 4.10. Automatisch generierte ObjectFactory.java (abgekürzt)1 package generated ;

66 P. Radinski

2import javax .xml.bind. annotation . XmlRegistry ;

4 ...@XmlRegistry

6 public class ObjectFactory {

8 public ObjectFactory () {}

10public Frau createFrau () {

12 return new Frau ();}

14 }

Die Frau Klasse wird durch JAXB automatisch mit Java-Annotationenversehen, die die Struktur des XML-Schemas widerspiegeln. Alle Elemente<xs:element> aus dem komplexen Datentyp Frau sind erforderlich und zwar inder gegebenen Reihenfolge. Dies wird in Java auf Class-Ebene durch die Annota-tionen @XmlAccessorType, @XmlType und auf JavaBean Property /field - Ebenedurch die Angabe required = true definiert. Alle mit @XmlElement und @Xm-lAttribute bezeichneten Java Attribute können über getter- und setter-Methodenangesprochen werden. Die zu Listing 4.11 vollständige Klasse ist im Anhangunter Listing 4.28 zu finden.

Listing 4.11. 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 ;8 ...

@XmlAccessorType ( XmlAccessType . FIELD )10 @XmlType (name = "Frau", propOrder = {

" geburtsdatum ",12 " visitenkarte ",

" haustier "14 })

public class Frau {16

@XmlElement (name = " Geburtsdatum ", required = true)18 protected String geburtsdatum ;

...20 @XmlAttribute (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 be-einflusst werden - einerseits durch die XML-Schema-eigenen Sprachelemente,andererseits durch die JAXB Bindungskonfigurationen. An dieser Stelle werdeneinige interessante Transformationen vorgestellt, die teilweise auf den im Kapitel


2.1.2 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 Reihenfolgeauftreten müssen. Wie die Übersetzung in Java funktioniert, wurde in diesemKapitel vorgestellt.

. <xs:all> bedeutet, dass alle Elemente ohne eine bestimmte Reihenfolgevorhanden sein müssen. Der einzige Unterschied zu der Abbildung von<xs:sequence> ist, dass das Attribut propOrder von @XmlType leer ist.

. <xs:choice> bedeutet, dass nur ein Element und nicht mehrere vorkommendürfen. Der einzige Unterschied zu der Abbildung von <xs:sequence> ist,dass das Attribut required = true von @XmlType fehlt.

Die Angabe von Kardinalitäten durch die minOccur und maxOccur Attributeim XML Schema wird von Java in folgender Weise interpretiert. Falls maxOccurvorhanden ist, kann minOccur ausgelassen werden - der Wert wird per defaultauf 1 gesetzt:

. minOccur=“0“ und maxOccur=“0“ - das XML-Schema Element wird inJava überhaupt nicht abgebildet.

. minOccur=“1“ und maxOccur=“1“ - normale Abbildung wie in Listing 4.28.

. minOccur=“0“ und maxOccur=“2“ - alle Schema-Elemente, die mit maxOc-cur größer 1 (auch maxOccur=“unbounded“) markiert sind, werden als JavaListen 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 4.12. min- und maxOccurs Variationen1 ...2 /**

* 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 the8 * 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 list20 * { @link String }

*22 *

*/24 public List <String > getGeburtsdatum () {

68 P. Radinski

if ( geburtsdatum == null) {26 geburtsdatum = new ArrayList <String >();

}28 return this. geburtsdatum ;

}30 ...

Die Anpassungen durch XML-Sprachelemente sind ein spannender Aspektvon JAXB, werden aber hier nicht mehr behandelt. Der interessierte Leser kannsich jedoch unter [9] mit dem Thema auseinandersetzen. Hier sollen nun auchdie Anpassungen durch Bindungskonfigurationen vorgestellt werden. Mit ihnenkann das Verhalten des Schemakompilers weiter verfeinert werden. Diese Arbeitzeigt jedoch nur Grundzüge der Möglichkeiten - für ein besseres Verständnis derBindungskonfigurationen 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“ werdenund das ANT-Skript auch nicht zusätzlich angepasst werden muss. Es wirdanhand eines Beispiels (Listing 4.13) demonstriert, wie eine Bindungskonfigu-ration direkt im XML-Schema vom Listing 4.27 angebunden werden kann. ImBereich <xs:annotation>...</xs:annotaion> eines XML-Schemas werden dieBindungskonfigurationen normalerweise definiert. Ganz wichtig ist die Zeile 3 imBeispiel - ohne die Angabe des Namespace können die Bindungskonfigurationennicht aufgelöst werden. In Zeile 6 wird generateIsSetMethod=true benutzt, um inallen generierten Java Klassen (globalBindings) und für alle darin enthaltenenAttribute eine boolean isSet-Methode anzulegen. Sie überprüft, ob ein Attributmit einem Wert belegt ist.

Listing 4.13. Bindungskonfigurationen im XML-Schema1 <?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">10 ...

Durch den Einsatz von jaxb:collectionType (Listing 4.14) kann beispielswei-se das in Listing 4.12 als List<String> interpretierte Geburtsdatum in einemjava.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 4.14. jaxb:collectionType Einsatz1 ...2 <jaxb: globalBindings collectionType =" java.util. Vector " />

...


Listing 4.15. Automatisch generierte Frau.java1 ...2 @XmlElement (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 derAnnotation jaxb:class kann z.B. der Name der zu generierenden Java Klasseunabhängig vom Namen des komplexen Datentyps im XML-Schema geändertwerden. Mit jaxb:property können die Namen der zu generierenden Java Attributeangepasst werden.

2.2.3 Schemagenerator Der Schemagenerator transformiert Java Datenmo-delle 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 undein ANT Skript. Die Transformation kann ebenfalls wie beim Schemakompilerauf zwei verschiedenen Wegen stattfinden - über die Kommandozeile oder überein ANT-Skript in Eclipse. In dieser Arbeit wird aus Platzgründen jedoch nur aufden “bequemeren“ Weg in Eclipse eingegangen. Nach dem Ausführen des Skriptsentsteht dann ein XML-Schema, das das Schema für alle Java Datenmodellebeinhaltet - also in einer Datei werden die Beschreibungen für alle Datenmodellegesammelt.

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“, alsovon 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 diegetter- und setter-Methoden gleichzeitig fehlen, findet keine korrekte Umwandl-lung statt. Mindestens eine set- bzw. get-Methode für jedes Java Attribut muss imQuelltext verfügbar sein. Eine Transformation ist sogar ohne JAXB-Annotationenmöglich, nur die getter- oder setter-Methoden müssen vorhanden sein, ansonstenwird dieses Attribut nicht in XML-Schema übersetzt. Das ANT-Skript (siehe4.16) ist ähnlich wie beim Schemakompiler aufgebaut, hat aber natürlich andereParameter. Im <taskdef> Tag wird ein benutzerdefiniertes Task angelegt, indem das JAXB spezifische schemagen-Task für die Umwandlung von Java Da-tenmodelle nach XML-Schema eingefügt wird. Zu beachten ist, dass schemagenklein geschrieben wird und nicht schemaGen. Im Zielordner schemafolder wirddas fertige XML-Schema ausgegeben.

Listing 4.16. ANT Skript SchemaGenerator.xml

70 P. Radinski

1 <?xml version ="1.0"? >2 <project name =" Frau" default =" schemagen " basedir ="." >



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 Schemavom Schemakompiler (Listing 4.27) entspricht. Es fehlen nur die occur-Attributedes Geburtsdatum-Elements. Sie sind aber eigentlich überflüssig, weil die Zu-sammensetzung minOccurs=“1“ und maxOccurs=“1“ nur besagt, dass das Ge-burtsdatum-Attribut vorhanden sein muss. Diese Anforderung ist durch diein der Java-Annotation @XmlElement vorhandene Eigenschaft required=“true“gegeben. Die Übersetzung in XML-Schema erfordert dann keine Angabe vonoccur-Attributen.

Listing 4.17. Automatisch generierte Schema1.xsd1 <?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 diebereits im Kapitel 2.2.1 erwähnten Java-Annotationen weiter angepasst werden.Einige davon haben ihre äquivalenten XML-Schema Annotationen - d.h. siesind bidirektional verknüpft. Aus der Annotation @XmlType(name = “Frau“,propOrder = “X“, “Y“) entsteht immer ein komplexer Datentyp <xs:complexTypename = “Frau“> und umgekehrt. Andere werden im XML-Schema nicht direktabgebildet. @XmlTransient gibt das Nichtvorhandensein eines Java Attributsvor. Das Beispiel in Listing 4.18 bedeutet, dass kein geburtsdatum-Element imXML-Schema vorkommen soll.

Listing 4.18. Java-Annotation 1


1 ...2 @XmlType (name = "Frau", propOrder = {

" visitenkarte ",4 " haustier "

})6 public class Frau {

8 @XmlTransientprotected String geburtsdatum ;

10 ...

Wenn zwei oder mehr Java Klassen beim Schemagenerator transformiertwerden, so entstehen im XML-Schema zwei oder mehr komplexe Datentypen.Dasselbe gilt auch umgekehrt - die Anzahl der Java Klassen ist abhängig von derAnzahl der komplexen Datentypen. Solche Abhängigkeiten wurden bereits imKapitel 2.2.2 Schemakompiler ausführlich beschrieben. Im selben Kapitel wurdeauch angesprochen, dass eine manuelle Anpassung der ObjectFactory.java Klassemöglich ist. Bei der Validierung der XML-Daten durch das XML-Schema, wasim nächsten Kapitel (Serialisieren) vorgestellt wird, ist es notwendig, dass zudem komplexen Datentyp Frau eine <xs:element name=“frau“ type=“Frau“/>Angabe im XML-Schema vorhanden ist. So ein Element wird von der Frau.javaKlasse aus Listing 4.28 nicht automatisch erzeugt. Deshalb muss die ObjectFac-tory angepasst werden. Das funktioniert über die Annotation @XmlElementDecl(siehe Listing 4.19). In diesem Fall muss die ObjectFactory.java Klasse zusammenmit der Frau.java Klasse durch den Schemagenerator transformiert werden.

Listing 4.19. ObjectFactory.java Anpassung1 ...2 @XmlRegistry

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 { @link JAXBElement }{ @code <}{ @link Frau }{ @code >}}

*16 */

@XmlElementDecl ( namespace = "", name = "frau ")18 public JAXBElement <Frau > createFrau (Frau value ) {

return new JAXBElement <Frau >( _Frau_QNAME , Frau.class , null , value );20 }

}

2.2.4 Serialisieren Beim Serialisieren (Marshalling) werden Java Objektein XML Dateien umgewandelt. Dabei können die XML Daten durch das XMLSchema validiert werden (auf Gültigkeit überprüft werden). Eine so genannteSerialisierer Java Klasse und mindestens eine Java Klasse mit JAXB Annotatio-nen sind notwendig für die Datenübertragung in XML. Die Java Klassen können

72 P. Radinski

direkt oder über die ObjectFactory Klasse instanziert werden. Beim Serialisierenund Deserialisieren wird kein ANT Skript gebraucht, da keine Java Datenmodellebzw. XML-Schema transformiert werden - in Java werden jeweils XML Dateneingelesen (Deserialisieren) oder ausgegeben (Serialisieren).

Im Beispiel wird manuell die Serialisierer.java Klasse angelegt, welche dann dieFrau.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 nichtverwendet, sondern die Objekte werden direkt erzeugt. In der Serialisierer Klasse(Listing 4.20) findet die Transformation des Java Objektes in eine XML Dateistatt. Am Anfang muss immer ein JAXBContext Objekt erstellt werden - dort istdie Bindung zwischen Java Datenmodell und XML-Schema definiert. Dann wirdein Marshaller Objekt aufgerufen, das alle für die Transformation notwendigenMethoden beinhaltet. Die Angabe JAXB_FORMATTED_OUTPUT bedeutet,dass die auszugebende XML-Datei entsprechend formatiert sein muss. Mit derInitialisierung der Frau Klasse können ihre Attribute über die setter-Methoden mitWerten belegt werden. Diese Werte werden durch die Angabe marshaller.marshalin eine XML-Datei (Listing 4.37) umgewandelt. Die zu Listing 4.20 vollständigeKlasse ist unter Listing 4.34 zu finden.

Listing 4.20. Serialisierer.java1 import javax .xml.bind. JAXBContext ;2 import javax .xml.bind. Marshaller ;

4 public class Serialisierer {

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 ("11.11.1111");

16 ...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 angepasstwerden. Eine Zeile muss noch eingefügt werden (siehe Listing 4.21) - die vollstän-dige Klasse ist in Listing 4.35 zu finden. Ohne die Angabe der @XmlRootElementAnnotation kann das Serialisieren nicht funktionieren. Auch ohne Angabe vonJAXB-Annotationen in der Frau Klasse kann die Serialisierung auskommen, nurdie setter-Methoden und die @XmlRootElement Annotation müssen vorhanden


sein.

Listing 4.21. Angepasste Frau.java1 ...2 @XmlRootElement

public class Frau {4 ...

}

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 dieWertebelegungen und die JAXB Annotationen entsprechend dem XML-Schemaerfolgen. Im Beispiel hier müssen wegen <xs:sequence> alle im XML-Schemadefinierten Elemente und Attribute initialisiert werden. In der Serialisierer Klassewird auch die Validierung der XML Datei implementiert (Listing 4.22). DieValidierung der XML Daten beim Seralisieren gleicht der Validierung beimDeserialisieren. In beiden Fällen wird eine XML-Datei durch ein XML-Schemaauf Gültigkeit überprüft.

Listing 4.22. Für die Validierung angepasste Serialisierer.java1 ...2 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 Deserialisierer14 ...

Frau frau = new Frau ();16 frau. setHaustier (" rexi ");

frau. setGeburtsdatum ("11.11.1111");18 frau. setVisitenkarte ("D:\ visitenkarte .doc ");

frau. setName (" Stephie Müller ");20 ...

}

Das hier benutzte XML-Schema aus Listing 4.27 ist aber für die Validierungnoch nicht ausreichend. Eine Zeile mit der Angabe des komplexen Datentyps Frauals <xs:element> (siehe Listing 4.23) fehlt noch. Im Kapitel Schemageneratorwurde bereits gezeigt, wie diese Zeile durch Anpassung der ObjectFactory Klasseauch automatisch generiert werden kann.

Listing 4.23. Für die Validierung angepasste Frau.xsd1 ...2 <xs: schema version ="1.0" xmlns :xs =" http :// www.w3.org /2001/ XMLSchema ">

<xs: element name =" frau" type =" Frau" />4 <xs: complexType name =" Frau">

...

74 P. Radinski

2.2.5 Deserialisieren Beim Deserialisieren (Unmarshalling) werden XMLDateien in Java Objekte transformiert. Die XML Dateien können auf derselbenArt wie in Kapitel Serialisieren 2.2.4 auf Gültigkeit überprüft werden und einANT-Skript ist ebenfalls nicht notwendig. Die Java Klassen können direkt oderbei einer umfangreicheren Anwednung über die ObjectFactory Klasse instanziertwerden. Für das Deserialisieren sind eine so genannte Deserialisierer Klasse,mindestens eine Java Klasse mit JAXB Annotationen und eine XML-Datei erfor-derlich. Die XML Daten werden dann nach der Deserialisierung als strukturierteJava Objekte bereitgestellt.

Im Beispiel werden die in Kapitel 2.2.4 als Ergebnis des Serialisierens er-zeugte XML Datei (Listing 4.37) und die angepasste Frau.java (Listing 4.35)benutzt. Eine ObjectFactory Klasse wird nicht verwendet. Es wird überprüft, obdie Daten, die vorher in eine XML-Datei ausgegeben wurden, korrekt wieder inJava eingelesen werden können. Im Gegenteil zum Serialisieren werden hier alleJAXB-Annotationen in der Frau Klasse gebraucht, ansonsten werden die Java At-tribute mit dem Wert null belegt. Hier sind nur die getter-Methoden wichtig, dieAnwendung kommt auch ohne die setter-Methoden aus. Die Deserialisierer Klasseist ähnlich wie die Serialisierer Klasse aufgebaut. Am Anfang wird durch einJAXBContext ein Unmarshaller Objekt erzeugt, das die XML-Datei einliest. Überdie getter-Methoden der Frau Klasse werden die XML-Daten in Java angebunden.

Listing 4.24. Deserialisierer.java1 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 implemen-tiert. Dabei muss das im Kapitel Serialisieren 2.2.4 angepasste XML-Schema(Listing 4.23) benutzt werden - also mit der Angabe <xs:element> für denkomplexen Datentyp Frau. Im Gegenteil zum Serialisieren müssen hier nichtunbedingt alle getter-Methoden benutzt werden, weil sie keine Auswirkung aufdie XML-Datei haben. Über die setter-Methoden können die aus XML eingelese-


nen Daten überschrieben werden. In Listing 4.22 wurde bereits gezeigt, wie dieValidierung funktioniert. Beim Deserialisieren wird nur Zeile 6 - wie im Listing4.25 - angepasst.

Listing 4.25. Validierung beim Deserialisieren1 ...2 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

...

2.3 JAXB Beispiel

In diesem Kapitel wird anhand eines frei gewählten Modells veranschaulicht, wieder JAXB Ansatz sich in die Modellbasierte Softwareentwicklung integrierenlässt. Am Anfang dieser Seminararbeit wurde die Frage gestellt, wie JAXB dieBindung zwischen Java und XML herstellen kann - diese Frage wurde ausführlichin den vorausgegangenen Kapitel mit zahlreichen Beispielen beantwortet und dasErgebnis wird hier mit einem im Vergleich zu den vorherigen, komplizierterenBeispiel untermauert.

Es wird nun eine Java Anwendung vorgestellt (siehe Abbildung 2), die Deter-ministische Endliche Automaten (DEAs) einliest, sie ausführt und das Ergebnisausgibt. 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äsentiertund 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 einzelnenZeichen bestehen. Die Eingabe des DEAs ist eine beliebige Folge aus Buchstabendes Alphabets und wird entweder mitgeliefert oder in der Anwendung zur Lauf-zeit eingegeben. Die Grundregeln eines DEAs dürfen nicht verletzt werden. DasAlphabet darf keine Schnittmenge mit den Zuständen bilden und die Übergängemüssen eindeutig sein. Es wird von einem gültigen DEA ausgegangen, deshalbmuss 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ültig-keitsüberprüfung (sein MetaModell) in einem XML-Schema Dea.xsd (Listing4.43) gespeichert. Beide Dateien stellen die Eingabe des Programms dar. DieAnwendung hier ist zum größten Teil auf der DEA-Definition in Dea.xsd aufge-baut. Es ist aber auch möglich, dass eine Schnittstelle definiert wird, so dass übervorgegebenen Methoden auf die Daten des DEAs zugegeriffen wird - so könnenauch unterschiedliche XML-Schemata eingelesen werden. Wenn hier ein XML-Schema geliefert wird, das denselben Aufbau wie in Dea.xsd hat, aber auch noch

76 P. Radinski

Abbildung 2. DEA Beispiel Ablauf

das Alphabet des DEAs beinhaltet, stellt das für die Anwendung kein Problemdar, denn die nötigen Daten können trotzdem eingelesen werden. Beim erstenSchritt wird dem SchemaKompiler.xml (Listing 4.42) die Dea.xsd übergeben. Beider 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) undUebergang.java (Listing 4.50). Diese Klassen sind die äußere Bean-Hülle undwerden dann für die Bindung der XML Daten verwendet. Im nächsten Schrittwerden in der Deserialisierer.java (Listing 4.53) Klasse diese automatisch gene-rierten Klassen über ein Unmarshaller-Objekt für das Einlesen der XML Datenbenutzt. Außerdem findet in der Deserialisierer Klasse die Validierung der ein-gelesenen Dea.xml durch die Dea.xsd und die Anbindung der AnwendungslogikDEA_Engine.java (Listing 4.45) statt. Nach dem Ausführen des Programms(Deserialisierer.java) mit einer beliebigen Zeichenfolge als Eingabe, die in derDea.xml mitgeliefert wird, wird entweder “akzeptiert“ oder “nicht akzeptiert“


Abbildung 3. DEA Beispiel

ausgegeben. Falls die Gültigkeitsüberprüfung der XML-Datei fehlschlägt, wirdeine detaillierte Fehlermeldung angezeigt.

3 Schluss

In dieser Seminararbeit wurde gezeigt, dass JAXB an sich sehr flexibel undvielseitig ist. Durch geringe Änderungen am Quellcode können verschiedeneErweiterungen eingefügt werden. Diese Erweiterungen wären bestimmt nichtnotwendig, wenn die dargestellten Beispiele von Anfang an umfangreicher undkomplizierter eingeplant wären. So wäre aber die Flexibilität von JAXB nichteindeutig zum Vorschein gekommen und es hätte sich nicht gezeigt, wie einfaches ist, diese Erweiterungen einzubauen.

Insgesamt erweist sich JAXB als eine sehr gute Alternative im Vergleich zuden parser-basierten Verfahren (SAX, DOM und Pull API), XML an Java anzu-binden. Seit der Version 2.0 wurden erhebliche Verbesserungen erreicht, die einengroßen Vorteil mit sich bringen, nämlich die bidirektionale Bindung zwischen denbeiden Technologien Java und XML. Damit wurde der Weg freigemacht, XMLals die Schnittstelle für Datentransfer zwischen Java Anwendungen einzusetzen.Im Sinne der Modellbasierten Softwareentwicklung ermöglicht JAXB eine voll-ständige und korrekte bidirektionale Modelltransformation zwischen Java undXML. Besonders bei den Service Orientierten Architekturen wird eine einfacheund flexible Technologie gebraucht, um verschiedene Java Anwendungen bzw.Java Web Services anzubinden. JAXB ist diese Technologie.

4 Anhang

4.1 Schemakompiler

Listing 4.26. SchemaKompiler.xml1 <?xml version ="1.0"? >2 <project default =" xjc" basedir ="." >

78 P. Radinski

Abbildung 4. Schemakompiler in Ecipse



8 </path >




16 <include name =" Frau.xsd" /></schema >


20</project >

Listing 4.27. Frau.xsd1 <?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 

<xs: attribute name =" Name" type =" xs: string " use =" required "/>12 </xs: complexType >

</xs:schema >

Listing 4.28. Frau.java


1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792

// 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: 2009.03.20 at 05:10:57 PM CET6 //

8package generated ;

10import 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 ;

16

18 /*** <p>Java class for Frau complex type.

20 ** <p>The following schema fragment specifies the expected content contained within this class .

22 ** <pre >

24 * < complexType name =" Frau">* < complexContent >

26 * < restriction base ="{ http :// www.w3.org /2001/ XMLSchema } anyType ">* <sequence >

28 * < element name =" Geburtsdatum " type ="{ http :// www.w3.org /2001/ XMLSchema } string "/>* < element name =" Visitenkarte " type ="{ http :// www.w3.org /2001/ XMLSchema } string "/>

30 * < element name =" Haustier " type ="{ http :// www.w3.org /2001/ XMLSchema } string "/>* &lt ;/ sequence >

32 * < attribute name =" Name" use =" required " type ="{ http :// www.w3.org /2001/ XMLSchema } string " />* &lt ;/ restriction >

34 * &lt ;/ complexContent >* &lt ;/ complexType >

36 * </pre >*

38 **/

40 @XmlAccessorType ( XmlAccessType . FIELD )@XmlType (name = "Frau", propOrder = {

42 " geburtsdatum "," visitenkarte ",

44 " haustier "})

46 public class Frau {

48 @XmlElement (name = " Geburtsdatum ", required = true)protected String geburtsdatum ;

50 @XmlElement (name = " Visitenkarte ", required = true)protected String visitenkarte ;

52 @XmlElement (name = " Haustier ", required = true , defaultValue = "Hund ")protected String haustier ;

54 @XmlAttribute (name = "Name", required = true)protected String name;

56/**

58 * Gets the value of the geburtsdatum property .*

60 * @return* possible object is

62 * { @link String }*

64 */public String getGeburtsdatum () {

66 return geburtsdatum ;}

68

80 P. Radinski

/**70 * Sets the value of the geburtsdatum property .

*72 * @param value

* allowed object is74 * { @link String }

*76 */

public void setGeburtsdatum ( String value ) {78 this. geburtsdatum = value ;

}80

/**82 * Gets the value of the visitenkarte property .

*84 * @return

* possible object is86 * { @link String }

*88 */

public String getVisitenkarte () {90 return visitenkarte ;

}92

/**94 * Sets the value of the visitenkarte property .

*96 * @param value


*100 */

public void setVisitenkarte ( String value ) {102 this. visitenkarte = value ;

}104

/**106 * Gets the value of the haustier property .

*108 * @return


*112 */

public String getHaustier () {114 return haustier ;

}116

/**118 * Sets the value of the haustier property .

*120 * @param value


*124 */

public void setHaustier ( String value ) {126 this. haustier = value ;

}128

/**130 * Gets the value of the name property .

*132 * @return


*136 */


public String getName () {138 return name;

}140

/**142 * Sets the value of the name property .

*144 * @param value


*148 */

public void setName ( String value ) {150 this.name = value ;

}152

}

Listing 4.29. ObjectFactory.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8package generated ;

10import javax .xml.bind. annotation . XmlRegistry ;

12

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 **/

28 @XmlRegistrypublic class ObjectFactory {

30

32 /*** Create a new ObjectFactory that can be used to create new instances of schema derived classes for package : generated

34 **/

36 public ObjectFactory () {}

38/**

40 * Create an instance of { @link Frau }*

42 */public Frau createFrau () {

44 return new Frau ();}

46}

82 P. Radinski

4.2 Schemagenerator

Abbildung 5. Schemagenerator in Eclipse

Listing 4.30. SchemaGenerator.xml1 <?xml version ="1.0"? >2 <project name =" Frau" default =" schemagen " basedir ="." >



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 4.31. Frau.java1 Dieselbe Klasse wie in Schemakompiler !

Listing 4.32. ObjectFactory.java1 Dieselbe Klasse wie in Schemakompiler !


Listing 4.33. Schema1.xsd1 <?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

Listing 4.34. Serialisierer.java1 import javax .xml.bind. JAXBContext ;2 import javax .xml.bind. Marshaller ;

4 public class Serialisierer {


8 try {JAXBContext context = JAXBContext . newInstance (Frau. class );

10Marshaller marshaller = context . createMarshaller ();

12marshaller . setProperty ( Marshaller . JAXB_FORMATTED_OUTPUT , true );

14Frau frau = new Frau ();

16 frau. setGeburtsdatum ("11.11.1111");

84 P. Radinski

18 frau. setHaustier (" rexi ");frau. setName (" Stephie Müller ");

20marshaller . marshal (frau , System .out );

22} catch ( Exception e) {

24 e. printStackTrace ();}

26 }}

Listing 4.35. Frau.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8

10import 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 >* < complexType name =" Frau">

26 * < complexContent >* < restriction base ="{ http :// www.w3.org /2001/ XMLSchema } anyType ">

28 * <sequence >* < element name =" Geburtsdatum " type ="{ http :// www.w3.org /2001/ XMLSchema } string "/>

30 * < element name =" Visitenkarte " type ="{ http :// www.w3.org /2001/ XMLSchema } string "/>* < element name =" Haustier " type ="{ http :// www.w3.org /2001/ XMLSchema } string "/>

32 * &lt ;/ sequence >* < attribute name =" Name" use =" required " type ="{ http :// www.w3.org /2001/ XMLSchema } string " />

34 * &lt ;/ restriction >* &lt ;/ complexContent >

36 * &lt ;/ complexType >* </pre >

38 **

40 */@XmlRootElement // Das muss manuell hinzugefügt werden , ansonsten wie in Schemakompiler !

42@XmlAccessorType ( XmlAccessType . FIELD )

44 @XmlType (name = "Frau", propOrder = {" geburtsdatum ",

46 " visitenkarte "," haustier "

48 })

50 public class Frau {

52 @XmlElement (name = " Geburtsdatum ", required = true)protected String geburtsdatum ;

54 @XmlElement (name = " Visitenkarte ", required = true)


protected String visitenkarte ;56 @XmlElement (name = " Haustier ", required = true , defaultValue = "Hund ")

protected String haustier ;58 @XmlAttribute (name = "Name", required = true)

protected String name;60

/**62 * Gets the value of the geburtsdatum property .

*64 * @return


*68 */

public String getGeburtsdatum () {70 return geburtsdatum ;

}72

/**74 * Sets the value of the geburtsdatum property .

*76 * @param value


*80 */

public void setGeburtsdatum ( String value ) {82 this. geburtsdatum = value ;

}84

/**86 * Gets the value of the visitenkarte property .

*88 * @return


*92 */

public String getVisitenkarte () {94 return visitenkarte ;

}96

/**98 * Sets the value of the visitenkarte property .

*100 * @param value


*104 */

public void setVisitenkarte ( String value ) {106 this. visitenkarte = value ;

}108

/**110 * Gets the value of the haustier property .

*112 * @return


*116 */

public String getHaustier () {118 return haustier ;

}120

/**122 * Sets the value of the haustier property .

86 P. Radinski

*124 * @param value


*128 */

public void setHaustier ( String value ) {130 this. haustier = value ;

}132

/**134 * Gets the value of the name property .

*136 * @return


*140 */

public String getName () {142 return name;

}144

/**146 * Sets the value of the name property .

*148 * @param value


*152 */

public void setName ( String value ) {154 this.name = value ;

}156

}


Listing 4.37. Ausgabe Serialisierer.java1 <?xml version ="1.0" encoding ="UTF -8" standalone =" yes "?>2 <frau Name =" Stephie MÃ¼ller ">

<Geburtsdatum >11.11.1111 </ Geburtsdatum >4 <Haustier >rexi </ Haustier >

</frau >

4.4 Deserialisieren

Listing 4.38. Deserialisierer.java1 import java.io.File;2

import javax .xml.bind. JAXBContext ;4 import javax .xml.bind. Unmarshaller ;

6 public class Deserialisierer {


10 try {


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 ());


24 }}

26 }

Listing 4.39. Frau.java1 Dieselbe Klasse wie in Serialisieren !


Listing 4.41. Ausgabe Deserialisierer1 Frau: Stephi Müller2 Geboren am: 11.11.1111

Tier: rexi

4.5 JAXB Beispiel

88 P. Radinski

Abbildung 8. JAXB Beispiel in Eclipse

Listing 4.42. SchemaKompiler.xml1 <?xml version ="1.0"? >2 <project default =" xjc" basedir ="." >



8 </path >




16 <include name =" Dea.xsd" /></schema >


20</project >


Listing 4.43. Dea.xsd1 <?xml version ="1.0" encoding ="UTF -8" ?>2 <xs: schema xmlns :xs =" http :// www.w3.org /2001/ XMLSchema ">

<xs: element name =" dea">4 <xs: complexType >

<xs: sequence >6 <xs: element ref =" eingabe " />

<xs: element ref =" zustaende " />8 <xs: element ref =" uebergaenge " />


</xs: element >12 <xs: element name =" eingabe ">

<xs: complexType mixed =" true" />14 </xs: element >

<xs: element name =" uebergaenge ">16 <xs: complexType >

<xs: sequence >18 <xs: element ref =" uebergang " maxOccurs =" unbounded " />


</xs: element >22 <xs: element name =" uebergang ">

<xs: complexType mixed =" true">24 <xs: attribute name =" ziel" type =" xs: string " use =" required " />

<xs: attribute name =" quelle " type =" xs: string "26 use =" required " />

</xs: complexType >28 </xs: element >

<xs: element name =" zustaende ">30 <xs: complexType >

<xs: sequence >32 <xs: element ref =" zustand " maxOccurs =" unbounded " />


</xs: element >36 <xs: element name =" zustand ">

<xs: complexType mixed =" true">38 <xs: attribute name =" isStart " type =" xs: boolean "

use =" required " />40 <xs: attribute name =" isEnd " type =" xs: boolean " use =" required " />

</xs: complexType >42 </xs: element >

</xs:schema >

Listing 4.44. Dea.xml1 <?xml version ="1.0" encoding ="UTF -8"? >2 <dea >

<eingabe >010 </ eingabe >4 <zustaende >

<zustand isStart =" true" isEnd =" false ">A </ zustand >6 <zustand isStart =" false " isEnd =" false ">B </ zustand >

<zustand isStart =" false " isEnd =" false ">C </ zustand >8 <zustand isStart =" false " isEnd =" true">D </ zustand >

<zustand isStart =" false " isEnd =" true">E </ zustand >10 </zustaende >

<uebergaenge >12 <uebergang quelle ="A" ziel ="B">0</ uebergang >

<uebergang quelle ="A" ziel ="C">1</ uebergang >14 <uebergang quelle ="B" ziel ="D">1</ uebergang >

<uebergang quelle ="C" ziel ="E">0</ uebergang >16 <uebergang quelle ="D" ziel ="B">1</ uebergang >

<uebergang quelle ="D" ziel ="E">0</ uebergang >18 </ uebergaenge >

</dea >

90 P. Radinski

Listing 4.45. DEA-Engine.java

1 import java.util. Vector ;2

public class DEA_Engine {4

public DEA_Engine (Dea dea) {6 int i = 0;

int j = 0;8 String tempEingabe = "";

String tempUebergang = "";10

String eingabe = dea. getEingabe (). getContent ();12 String [] uebergangsRelationen = new String [dea. getUebergaenge ()

. getUebergang (). size ()];14 Vector <String > endZustaende = new Vector <String >();

String tempZustand = "";16

// Daten einlesen18 for (int a = 0; a < dea. getZustaende (). getZustand (). size (); a++) {

if (dea. getZustaende (). getZustand (). get(a). isIsEnd () == false20 && dea. getZustaende (). getZustand (). get(a). isIsStart () == true) {

tempZustand = dea. getZustaende (). getZustand (). get(a). content ;22 }

if (dea. getZustaende (). getZustand (). get(a). isIsEnd () == true24 && dea. getZustaende (). getZustand (). get(a). isIsStart () == false ) {

endZustaende26 .add(dea. getZustaende (). getZustand (). get(a). content );

}28 }

30 for (int b = 0; b < dea. getUebergaenge (). getUebergang (). size (); b++) {uebergangsRelationen [b] = dea. getUebergaenge (). getUebergang ()

32 .get(b). getQuelle ()+ dea. getUebergaenge (). getUebergang (). get(b). content

34 + dea. getUebergaenge (). getUebergang (). get(b). getZiel ();}

36boolean endzustand = false ;

38 boolean durchlauf = true;

40 // Wenn endzustand und durchlauf true , dann akzeptiere !!!// Dea ausführen

42 for (i = 0; i < eingabe . length (); i++) {j = i + 1;

44 tempEingabe = eingabe . substring (i, j);tempUebergang = tempZustand + tempEingabe ;

46 tempZustand = neachsterZustand ( tempUebergang , uebergangsRelationen );if ( tempZustand . equals (" kein ")) {

48 i = eingabe . length ();durchlauf = false ;

50 }endzustand = istEndZustand ( tempZustand , endZustaende );

52 }if ( endzustand && durchlauf ) {

54 System .out. println (" akzeptiert ");} else {

56 System .out. println (" nicht akzeptiert ");}

58 }

60 public String neachsterZustand ( String tempUebergang ,String [] uebergangsRelationen ) {

62for (int i = 0; i < uebergangsRelationen . length ; i++) {

64 if ( uebergangsRelationen [i]. indexOf ( tempUebergang ) == 0) {return uebergangsRelationen [i]. substring (2, 3);

66 }


}68 return "kein ";

}70

public boolean istEndZustand ( String tempZustand , Vector <String > endZustaende ) {72

for (int i = 0; i < endZustaende .size (); i++) {74 if ( tempZustand . equals ( endZustaende . elementAt (i). toString ())) {

return true;76 }

}78 return false ;

}80 }

Listing 4.46. Dea.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792


// Generated on: 2009.04.09 at 02:25:50 PM CEST6 //

8

10 import javax .xml.bind. annotation . XmlAccessType ;import javax .xml.bind. annotation . XmlAccessorType ;



16/**

18 * <p>Java class for anonymous complex type.*


22 * <pre >* < complexType >


26 * <sequence >* < element ref ="{} eingabe "/>

28 * < element ref ="{} zustaende "/>* < element ref ="{} uebergaenge "/>

30 * &lt ;/ sequence >* &lt ;/ restriction >


34 * </pre >*

36 **/

38 @XmlAccessorType ( XmlAccessType . FIELD )@XmlType (name = "", propOrder = {

40 " eingabe "," zustaende ",

42 " uebergaenge "})

44 @XmlRootElement (name = "dea ")public class Dea {

46@XmlElement ( required = true)

48 protected Eingabe eingabe ;@XmlElement ( required = true)

50 protected Zustaende zustaende ;

92 P. Radinski

@XmlElement ( required = true)52 protected Uebergaenge uebergaenge ;

54 /*** Gets the value of the eingabe property .

56 ** @return

58 * possible object is* { @link Eingabe }

60 **/

62 public Eingabe getEingabe () {return eingabe ;

64 }

66 /*** Sets the value of the eingabe property .

68 ** @param value

70 * allowed object is* { @link Eingabe }

72 **/

74 public void setEingabe ( Eingabe value ) {this. eingabe = value ;

76 }

78 /*** Gets the value of the zustaende property .

80 ** @return

82 * possible object is* { @link Zustaende }

84 **/

86 public Zustaende getZustaende () {return zustaende ;

88 }

90 /*** Sets the value of the zustaende property .

92 ** @param value

94 * allowed object is* { @link Zustaende }

96 **/

98 public void setZustaende ( Zustaende value ) {this. zustaende = value ;

100 }

102 /*** Gets the value of the uebergaenge property .

104 ** @return

106 * possible object is* { @link Uebergaenge }

108 **/

110 public Uebergaenge getUebergaenge () {return uebergaenge ;

112 }

114 /*** Sets the value of the uebergaenge property .

116 ** @param value

118 * allowed object is


* { @link Uebergaenge }120 *

*/122 public void setUebergaenge ( Uebergaenge value ) {

this. uebergaenge = value ;124 }

126 }

Listing 4.47. Eingabe.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8


12 import javax .xml.bind. annotation . XmlRootElement ;import javax .xml.bind. annotation . XmlType ;

14 import javax .xml.bind. annotation . XmlValue ;

16/**





26 * &lt ;/ restriction >* &lt ;/ complexContent >

28 * &lt ;/ complexType >* </pre >

30 **

32 */@XmlAccessorType ( XmlAccessType . FIELD )

34 @XmlType (name = "", propOrder = {" content "

36 })@XmlRootElement (name = " eingabe ")

38 public class Eingabe {

40 @XmlValueprotected String content ;

42/**

44 * Gets the value of the content property .*

46 * @return* possible object is

48 * { @link String }*

50 */public String getContent () {

52 return content ;}

54/**

56 * Sets the value of the content property .

94 P. Radinski

*58 * @param value


*62 */

public void setContent ( String value ) {64 this. content = value ;

}66

}

Listing 4.48. ObjectFactory.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8

10 import javax .xml.bind. annotation . XmlRegistry ;

12/**

14 * This object contains factory methods for each* Java content interface and Java element interface

16 * generated in the generated package .* <p>An ObjectFactory allows you to programatically

18 * construct new instances of the Java representation* for XML content . The Java representation of XML

20 * content can consist of schema derived interfaces* and classes representing the binding of schema

22 * type definitions , element declarations and model* groups . Factory methods for each of these are

24 * provided in this class .*

26 */@XmlRegistry

28 public class ObjectFactory {

30/**

32 * Create a new ObjectFactory that can be used to create new instances of schema derived classes for package : generated*

34 */public ObjectFactory () {

36 }

38 /*** Create an instance of { @link Uebergang }

40 **/

42 public Uebergang createUebergang () {return new Uebergang ();

44 }

46 /*** Create an instance of { @link Zustaende }

48 **/

50 public Zustaende createZustaende () {return new Zustaende ();

52 }


54 /*** Create an instance of { @link Uebergaenge }

56 **/

58 public Uebergaenge createUebergaenge () {return new Uebergaenge ();

60 }

62 /*** Create an instance of { @link Eingabe }

64 **/

66 public Eingabe createEingabe () {return new Eingabe ();

68 }

70 /*** Create an instance of { @link Zustand }

72 **/

74 public Zustand createZustand () {return new Zustand ();

76 }

78 /*** Create an instance of { @link Dea }

80 **/

82 public Dea createDea () {return new Dea ();

84 }

86 }

Listing 4.49. Uebergaenge.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8

10 import java.util. ArrayList ;import java.util.List;




18/**





28 * <sequence >* < element ref ="{} uebergang " maxOccurs =" unbounded "/>

30 * &lt ;/ sequence >* &lt ;/ restriction >

96 P. Radinski


34 * </pre >*

36 **/


40 " uebergang "})

42 @XmlRootElement (name = " uebergaenge ")public class Uebergaenge {

44@XmlElement ( required = true)

46 protected List <Uebergang > uebergang ;

48 /*** Gets the value of the uebergang property .

50 ** <p>

52 * This accessor method returns a reference to the live list ,* not a snapshot . Therefore any modification you make to the

54 * returned list will be present inside the JAXB object .* This is why there is not a <CODE >set </ CODE > method for the uebergang property .

56 ** <p>

58 * For example , to add a new item , do as follows :* <pre >

60 * getUebergang (). add( newItem );* </pre >

62 **

64 * <p>* Objects of the following type(s) are allowed in the list

66 * { @link Uebergang }*

68 **/

70 public List <Uebergang > getUebergang () {if ( uebergang == null) {

72 uebergang = new ArrayList <Uebergang >();}

74 return this. uebergang ;}

76}

Listing 4.50. Uebergang.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8


12 import javax .xml.bind. annotation . XmlAttribute ;import javax .xml.bind. annotation . XmlRootElement ;

14 import javax .xml.bind. annotation . XmlType ;import javax .xml.bind. annotation . XmlValue ;

16

18 /**


* <p>Java class for anonymous complex type.20 *

* <p>The following schema fragment specifies the expected content contained within this class .22 *

* <pre >24 * < complexType >

* < complexContent >26 * < restriction base ="{ http :// www.w3.org /2001/ XMLSchema } anyType ">

* < attribute name =" ziel" use =" required " type ="{ http :// www.w3.org /2001/ XMLSchema } string " />28 * < attribute name =" quelle " use =" required " type ="{ http :// www.w3.org /2001/ XMLSchema } string " />

* &lt ;/ restriction >30 * &lt ;/ complexContent >

* &lt ;/ complexType >32 * </pre >

*34 *

*/36 @XmlAccessorType ( XmlAccessType . FIELD )

@XmlType (name = "", propOrder = {38 " content "

})40 @XmlRootElement (name = " uebergang ")

public class Uebergang {42

@XmlValue44 protected String content ;

@XmlAttribute ( required = true)46 protected String ziel;

@XmlAttribute ( required = true)48 protected String quelle ;

50 /*** Gets the value of the content property .

52 ** @return

54 * possible object is* { @link String }

56 **/

58 public String getContent () {return content ;

60 }

62 /*** Sets the value of the content property .

64 ** @param value

66 * allowed object is* { @link String }

68 **/

70 public void setContent ( String value ) {this. content = value ;

72 }

74 /*** Gets the value of the ziel property .

76 ** @return


80 **/

82 public String getZiel () {return ziel;

84 }

86 /**

98 P. Radinski

* Sets the value of the ziel property .88 *

* @param value90 * allowed object is

* { @link String }92 *

*/94 public void setZiel ( String value ) {

this.ziel = value ;96 }

98 /*** Gets the value of the quelle property .

100 ** @return


104 **/

106 public String getQuelle () {return quelle ;

108 }

110 /*** Sets the value of the quelle property .

112 ** @param value


116 **/

118 public void setQuelle ( String value ) {this. quelle = value ;

120 }

122 }

Listing 4.51. Zustaende.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8import java.util. ArrayList ;

10 import java.util.List;import javax .xml.bind. annotation . XmlAccessType ;

12 import javax .xml.bind. annotation . XmlAccessorType ;import javax .xml.bind. annotation . XmlElement ;

14 import javax .xml.bind. annotation . XmlRootElement ;import javax .xml.bind. annotation . XmlType ;

16

18 /*** <p>Java class for anonymous complex type.


22 ** <pre >

24 * < complexType >* < complexContent >

26 * < restriction base ="{ http :// www.w3.org /2001/ XMLSchema } anyType ">* <sequence >

28 * < element ref ="{} zustand " maxOccurs =" unbounded "/>


* &lt ;/ sequence >30 * &lt ;/ restriction >

* &lt ;/ complexContent >32 * &lt ;/ complexType >

* </pre >34 *

*36 */

@XmlAccessorType ( XmlAccessType . FIELD )38 @XmlType (name = "", propOrder = {

" zustand "40 })

@XmlRootElement (name = " zustaende ")42 public class Zustaende {

44 @XmlElement ( required = true)protected List <Zustand > zustand ;

46/**

48 * Gets the value of the zustand property .*

50 * <p>* This accessor method returns a reference to the live list ,

52 * not a snapshot . Therefore any modification you make to the* returned list will be present inside the JAXB object .

54 * This is why there is not a <CODE >set </ CODE > method for the zustand property .*

56 * <p>* For example , to add a new item , do as follows :

58 * <pre >* getZustand (). add( newItem );

60 * </pre >*

62 ** <p>

64 * Objects of the following type(s) are allowed in the list* { @link Zustand }

66 **

68 */public List <Zustand > getZustand () {

70 if ( zustand == null) {zustand = new ArrayList <Zustand >();

72 }return this. zustand ;

74 }

76 }

Listing 4.52. Zustand.java1 //2 // This file was generated by the JavaTM Architecture for XML Binding (JAXB) Reference Implementation , vhudson -jaxb -ri -2.1 -792



8


12 import javax .xml.bind. annotation . XmlAttribute ;import javax .xml.bind. annotation . XmlRootElement ;

14 import javax .xml.bind. annotation . XmlType ;import javax .xml.bind. annotation . XmlValue ;

16

100 P. Radinski

18 /*** <p>Java class for anonymous complex type.


22 ** <pre >

24 * < complexType >* < complexContent >

26 * < restriction base ="{ http :// www.w3.org /2001/ XMLSchema } anyType ">* < attribute name =" isStart " use =" required " type ="{ http :// www.w3.org /2001/ XMLSchema } boolean " />

28 * < attribute name =" isEnd " use =" required " type ="{ http :// www.w3.org /2001/ XMLSchema } boolean " />* &lt ;/ restriction >


32 * </pre >*

34 **/


38 " content "})

40 @XmlRootElement (name = " zustand ")public class Zustand {

42@XmlValue

44 protected String content ;@XmlAttribute ( required = true)

46 protected boolean isStart ;@XmlAttribute ( required = true)

48 protected boolean isEnd ;

50 /*** Gets the value of the content property .

52 ** @return


56 **/

58 public String getContent () {return content ;

60 }

62 /*** Sets the value of the content property .

64 ** @param value


68 **/

70 public void setContent ( String value ) {this. content = value ;

72 }

74 /*** Gets the value of the isStart property .

76 **/

78 public boolean isIsStart () {return isStart ;

80 }

82 /*** Sets the value of the isStart property .

84 *


*/86 public void setIsStart ( boolean value ) {

this. isStart = value ;88 }

90 /*** Gets the value of the isEnd property .

92 **/

94 public boolean isIsEnd () {return isEnd ;

96 }

98 /*** Sets the value of the isEnd property .

100 **/

102 public void setIsEnd ( boolean value ) {this. isEnd = value ;

104 }

106 }

Listing 4.53. Deserialisierer.java1 import java.io.File;2

import javax .xml.bind. JAXBContext ;4 import javax .xml.bind. Unmarshaller ;

import javax .xml. validation . Schema ;6 import javax .xml. validation . SchemaFactory ;

8public class Deserialisierer {

10public static void main( String [] args) {

12try {

14 JAXBContext context = JAXBContext . newInstance (Dea. class );

16 Unmarshaller unmarshaller = context . createUnmarshaller ();

18 // ValidierenSchemaFactory sf = SchemaFactory

20 . newInstance ( javax .xml. XMLConstants . W3C_XML_SCHEMA_NS_URI );

22 Schema schema = sf. newSchema (new File (" schema /Dea.xsd "));unmarshaller . setSchema ( schema );

24Dea dea = new Dea ();

26try {

28 dea = (Dea) unmarshaller . unmarshal (new File (" Dea.xml "));

30 new DEA_Engine (dea );

32 } catch ( javax .xml.bind. UnmarshalException e) {System .out. println (" Fehler : " + e. toString ());

34 }


38 }}

40 }

102 P. Radinski

Literatur

[1] X. Clearinghouse. Xml-schema.[2] u. Henry S. Thompson, David Beech. Xml schema teil 1: Strukturen.[3] S. Kersken. It-handbuch für fachinformatiker.[4] D. Matuszek. Jaxb.[5] S. Michaelis and W. Schmiesing. Jaxb 2.0. In Ein Programmiertutorial für die

Java Architecture for XML Binding, pages XI–XII. Hanser, 2007.[6] S. Michaelis and W. Schmiesing. Jaxb 2.0. In Ein Programmiertutorial für die

Java Architecture for XML Binding, pages 1–3, 14–16. Hanser, 2007.[7] S. Michaelis and W. Schmiesing. Jaxb 2.0. In Ein Programmiertutorial für die

Java Architecture for XML Binding, page 9. Hanser, 2007.[8] S. Michaelis and W. Schmiesing. Jaxb 2.0. In Ein Programmiertutorial für die

Java Architecture for XML Binding, pages 295–297. Hanser, 2007.[9] S. Michaelis and W. Schmiesing. Jaxb 2.0. In Ein Programmiertutorial für die

Java Architecture for XML Binding, pages 17–53. Hanser, 2007.[10] S. Michaelis and W. Schmiesing. Jaxb 2.0. In Ein Programmiertutorial für die

Java Architecture for XML Binding, pages 125–192. Hanser, 2007.[11] S. Microsystems. Package javax.xml.bind.annotation.[12] u. Stephane Bailliez, Nicola Ken Barozzi. Apache ant 1.7.1 manual.

Modellierung von Geschäftsregeln

Matthias Nicolas DrexlMaximilian Koch


[email protected]

Zusammenfassung Bei der Geschäftsprozessmodellierung spielen Ge-schäftsregeln eine entscheidende Rolle, da sie zwischen Domänenexpertenund Softwareingenieuren eine entscheidende Verbesserung, im Bezugauf Kommunikation und Verständnis ermöglichen. Diese Seminararbeitbeschreibt die vier verschiedenen grafischen Notationen ROSS Notation,ORM (Object Rule Modeling), AORML (Agent Oriented Rule ModelingLanguage), und URML (UML-Based Rule Modeling Language) für dieModellierung von Geschäftsregeln. Basierend auf diesen Notationen wirdim folgenden jeweils ein Überblick über die theoretischen Grundlagen, derUmsetzung, und der praktischer Anwendung vermittelt. Anhand einerFallstudie werden Zusammenhänge und Unterschiede der Notationendetailliert erläutert. Abschließend werden die verschiedenen Ansätzemiteinander verglichen und Vor- und Nachteile präsentiert.

1 Motivation

Die Softwareentwicklung ist einem stetigen und agilen Wandel unterzogen. Klas-sische Methoden der Softwareentwicklung bestehend aus Analyse, Design, Imple-mentierung und Test sind aufgrund immer komplexer werdender Anforderungennicht mehr zeitgemäß. Einer IDC-Studie (International Data Corporation - An-bieter in den Bereichen Marktbeobachtung und Beratung der IT- und Telekom-munikationsindustrie) zufolge ändern sich ca. 45% der Regeln, innerhalb einesangenommenen Softwarerelease-Zyklus von mindestens einem Monat [1].

Um eine höhere Flexibilität in Unternehmensprozessen zu gewährleisten, wirdstatt eines traditionellen Softwarerelease-Verfahrens ein dynamisches, kontinuier-liches Lebenszyklusmanagement von Geschäftsregeln, verwendet - die grafischeModellierung von Geschäftsregeln.

Die meist von Domänenexperten, in natürlicher Sprache formulierten Ge-schäftsregeln werden von Softwareentwicklern in eine formale, technische Spracheübersetzt, um damit automatisiert ablaufende Prozesse zu gestalten. Die gra-fische Notation von Geschäftsregeln bildet eine gemeinsame Ebene, welche dieKommunikationslücke zwischen den Domänen- und IT-Experten überbrückt.Verschiedene Regelmodellierungsmethoden dienen dabei beiden Seiten zu einembesseren Verständnis von Geschäftsregeln. Durch den grafischen, modularenAnsatz lassen sich Geschäftsregeln kurzfristig ergänzen und modifizieren, wo-durch eine höhere Flexibilität in der konzeptionellen Phase erreicht wird, dass

104 M. Drexl und M. Koch

sowohl Kosten- als auch Zeitersparnis zur Folge hat. Zusätzlich stellt die grafischeNotation eine technische Dokumentation von Geschäftregeln dar.

2 Grundlagen - State of the art

Bevor detailliert verschiedene Ansätze der Regelmodellierung diskutiert werden,gibt der folgende Abschnitt einen Überblick über die verschiedenen Abstraktions-level von Geschäftsregeln. Die damit verbundenen Definitionen und Fachterminitragen zum besseren Verständnis von Syntax und Semantik, der Regelmodellie-rung, bei.

2.1 Definitionen

Geschäftsprozesse

Unter einem Geschäftsprozess versteht man die Zusammenführung von fachlichzusammenhängenden Geschäftsaktivitäten, die schrittweise ausgeführt werden.Geschäftsprozesse können modular aus anderen Prozessen aufgebaut werden,oder selbst wieder Teil eines anderen Geschäftsprozesses sein. So werden bei-spielsweise Aktivitäten eines Unternehmens wie bestimmte Arbeitsabläufe alsGeschäftsprozesse beschrieben.

Genauer soll ein Geschäftsprozess ein Unternehmen unterstützen, Geschäfts-objekte so zu bearbeiten, dass Unternehmensziele vollständig erreicht werden.Dabei sind sowohl die Anzahl der am Prozess beteiligten Aktionen, als auchderen Ablauf von Bedeutung. Des Weiteren benötigt ein Prozess ein auslösendesEreignis, das zur Ausführung von Aktivitäten führt. Ein Ereignis kann sowohlinternen, als auch externen Quellen (Input) zugeordnet werden. Lediglich bedeu-tend ist das Ergebnis, das eine Ausgabe (Output) einer Aktivität beinhaltet, diewiederum für weitere Aktivitäten zur Verfügung steht[6].

Beispiele:

. Ein Kunde möchte ein Auto bei einer Autovermietung reservieren.

. Die Autovermietung kontrolliert den PKW vor der Rückgabe auf einen vollenTank.

. Ein Kunde möchte diese Auto mit der Kreditkarte bezahlen.

Geschäftsprozesse können durch unterschiedliche Modellierungssprachen, wiePetrinetze, Aktivitätsdiagramme oder ereignisgesteuerte Prozessketten (EPKs),dargestellt werden.

Geschäftsregeln

Eine Geschäftsregel legt den genauen Ablauf von Geschäftsprozessen fest. Siedefiniert präzise die geschäftsprozessspezifische Logik z.B. den elementaren techni-schen Ablauf von Prozessaktivitäten, Exception Handling und die Art und Weise

Modellierung von Geschäftsregeln 105

der Abwicklung von Geschäftsprozessen. Zusätzlich wird die Entscheidungslogikvon prozessübergreifenden Regelwerken beschrieben.

Regeln sollten wegen der Widerverwendbarkeit modular und allgemeingültigdefiniert sein. Sie können analog zu den Prozessen wiederum Teil anderer Regelnsein oder bereits definierte Regeln enthalten. Eine einzelne Regel enthält auf deruntersten Modellierungsebene als atomare Regel keine weiteren Regeln.

Außerdem verwenden Geschäftsprozesse typischerweise mehrere Geschäftsre-geln (1..n). Eine Regel kann komplementär in mehreren verschiedenen Prozessenvorkommen (1..m). Somit stehen Prozesse und Regeln im Verhältnis n:m zuein-ander.

Laut der Business Rules Group (BRG) können Geschäftsregeln im Kontextder Prozessmodellierung zum einen aus der Sicht des Unternehmens (Betriebs-wirtschaftliche Sicht) und zum anderen aus der Sicht der IT (Technische Sicht)definiert werden.[8]

Die Betriebswirtschaftliche Sicht beschreibt eine Direktive, „die das Verhaltendes Unternehmens in eine bestimmte Richtung steuern und dabei die Einhaltungder Unternehmenspolitik unterstützen soll.“ Dabei beschreiben Geschäftsregelndie Organisationsstruktur von Unternehmen und deren Abläufe. Sie könnenwie oben definiert deren Geschäftslogik enthalten und sind somit Teil von Ge-schäftsprozessen und deren effizienter Durchführung.

Die Technische Sicht beschreibt Geschäftsregeln als „Eine Aussage, die Ver-haltensweisen oder Vorgänge innerhalb des Unternehmens einschränkt. Sie hataus dieser Sicht die Aufgabe die Unternehmung zu strukturieren bzw. zu kontrol-lieren.“

Aus diesen beiden verschiedenen Sichtweisen entsteht das Problem einesgemeinsamen Dialogs von Domänenexperten auf der einen und Technikern aufder anderen Seite. Die visuelle Repräsentation von Regeln soll hierbei Abhilfeschaffen und dabei helfen Regeln aus der natürlichen Sprache zu erfassen und indie technische Domäne zu überführen.

Beispiele:. Nur Kunden älter als 24 Jahre mit gültigem Führerschein können einen PKW

mieten.. Der Kunde wird auf eine schwarze Liste gesetzt, falls der Tankinhalt bei der

Rückgabe eines Mietwagens unter 50% liegt.. Bezahlt der Kunde mit einer Kreditkarte, erhält er 10% Rabatt auf einen

Mietwagen.

Geschäftsregeln können durch unterschiedliche Notationen, grafisch dargestelltwerden, die grundlegend in Kapitel 2.3 definiert werden. Spezifische Modellie-rungssprachen werden anschließend detailliert in den Kapiteln 3 bis 6 vorgestellt.

2.2 Abgrenzung von Geschäftsregeln

Die Abgrenzung von Geschäftsregeln basiert auf dem Ansatz der MDA (ModelDriven Architecture) welcher als Strategie von der OMG (Object Management


Group) definiert wurde. Das Konzept der Model Driven Architecture geht davonaus, dass für die Konstruktion eines Softwaresystems ein einziges Gesamtmodellzu ungenau und unübersichtlich ist. Bei den meisten Modellen sind geschäftsre-levante mit technischen Informationen vermischt. Deshalb unterteilt die MDAdas ursprüngliche Gesamtmodell in drei verschiedene Modellierungsebenen[13]dieauch in Abbildung [1] dargestellt sind:

Abbildung 1. Abgrenzung von Geschäftsregeln im Bezug auf die Modellierungs-ebenen CIM, PIM und PSM

. CIM (Computation-Independent-Model) für die umgangssprachliche Beschrei-bung.

. PIM (Platform-independent-Model) für die Modellierung und Verfeinerungvon Geschäftsprozessen, bzw. -regeln.

. PSM (Platform-Specific-Model) für Architektur und Services.

CIM ist eine semi-formale Modellierungsebene. Hierbei beschreiben Geschäfts-regeln Aussagen, über das Regelwerk von im Unternehmen auftretender Ak-tivitäten. Diese werden in einer deklarativen Art und Weise dargestellt, dieeinerseits der natürlichen Sprache und andererseits einer visuellen Repräsentationentsprechen.

PIM ist eine formale Modellierungsebene. Fachliche Spezifikationen werdenin pattformunabhängigen Modellen durch eine formal eindeutige Modellierungs-sprache definiert.

PSM ist eine formale Modellierungsebene die plattformabhängig ist. Geschäfts-regeln sind hier als Aussagen in einer spezifischen ausführbaren Sprache, wie MSOutlook 6 Rule oder Oracle 10g SQL View, beschrieben. Der Zusammenhangder verschiedenen Abstraktionsebenen ist in Abbildung [2] definiert. Eine um-gangssprachlich formulierte Geschäftsregel auf CIM Ebene kann beispielsweisedurch eine ECAA Regel auf PIM Ebene visualisiert werden. Dieses Modell kannwiederum durch Modelltransformation in ein spezifisches Modell, auf PSM Ebene,übersetzt werden. Die höchste Abstraktionsstufe wäre nun die automatisierteSourcecodegenerierung aus dem plattformspezifischen Modell, was in dieser Arbeitjedoch nicht vertieft erläutert wird.


Abbildung 2. Zusammenhang der Modellierungsebenen

Regeln werden in folgende fünf verschiedene Arten kategorisiert:

1. Integrity Rules oder auch Constraints für Bedingungs- oder Einschränkungs-regeln

2. Derivation Rules für Ableitungsregeln3. Reaction Rules für Prozess- oder Verhaltensregeln4. Production Rules für Produktionsregeln5. Transformation Rules für Transformationsregeln

Der Fokus dieser Arbeit liegt bei den ersten drei Regelarten, die im Folgen-den detailliert anhand grafischer Notationen erklärt werden. Einschränkungs-,Ableitungs-, und Prozessregeln können sowohl textuell als auch visuell auf derPIM Ebene formuliert werden. Tabelle [1] zeigt Beispiele von der möglichenÜberführung von Geschäftsregeln aus der CIM in die PIM Ebene

Konzepzt ImplementierungConstraints If-Then-Statements in Programmiersprachen, DO-

MAIN,CHECK und CONSTRAIN Klauseln in SQLTable Definitionen, CREATE, ASSERTION Statementsin SQL Datenbank Schema Definitionen

Derivation Rules Deduktive Datenbank Statements (oder Prolog) Regeln,SQL CREATE VIEW Statements

Reaction Rules If-Then-Statements in Programmiersprachen, CREA-TE,TRIGGER Statements in SQL, Produktionsregelnin ’Experten Systemen’Tabelle 1. Beispiele - CIM zu PIM


2.2.1 Bedingungs- / Einschränkungsregeln (Integrity Rules / Cons-traints) Einschränkungsregeln beschreiben allgemeingültige Aussagen und Be-hauptungen, die immer wahr sind und somit uneingeschränkt gelten. Sie könnenauch als Verbote oder Gebote definiert werden. Analog zu den in 2.1 bereitsdefinierten Beispielen kann folgende Regel als Einschränkungsregel eingeordnetwerden.

Beispiel: Nur Kunden älter als 24 Jahre mit gültigem Führerschein könneneinen PKW mieten

Diese Regel beinhalten Statements über die Bedingungen, unter denen ineinem Geschäftsprozess eine bestimmte Aktion ausgeführt wird (z.B.: PKW darfgemietet werden). Diese können nur ausgeführt werden, wenn sie danach in einemgültigen Zustand enden.

2.2.2 Ableitungsregeln (Derivation Rules): Unter Ableitungsregeln ver-steht man Regeln, bei denen neue Information aus bereits bestehenden Informa-tionen abgeleitet werden.

Beispiel: Der Kunde wird auf eine schwarze Liste gesetzt, falls der Tankinhaltbei der Rückgabe eines Mietwagens unter 90% liegt.

2.2.3 Prozess- oder Verhaltensregeln (Reaction Rules): Prozessregelnsind Anweisungen, die Aktionen anstoßen, verhindern oder erlauben. Gleichzeitigwird überprüft, ob diese Aktionen ausgeführt werden dürfen, müssen oder ebennicht ausgeführt werden. Darüber hinaus beschreiben Verhaltensregeln Statementsüber dynamische Aspekte in einem Unternehmen. Diese charakterisieren, inwiefernder Prozessstatus von einer Aktion beeinflusst wird.

Beispiel: Bezahlt der Kunde mit einer Kreditkarte, erhält er bei positiverBonität, 10% Rabatt auf einen Mietwagen

2.3 Existierende Modellierungsansätze von Geschäftsregeln:

Wie oben bereits mehrfach erwähnt, gibt es für die Darstellung von Geschäfts-regeln unterschiedliche Möglichkeiten. Im Folgenden werden vier verschiedenAnsätze dargestellt. Eine erste Formulierung der Geschäftsregeln kann in einernatürlichen Sprache erfolgen, was durch das Regelbasierte System repräsentiertwird. Eine formalere Darstellung kann anhand des JBOSS-Rules Regelsystemsdurchgeführt werden. Eine Visualisierung der Geschäftsregeln kann entsprechenddes E(vent)C(onditon)A(ction)A(ction)-Konzepts bzw. der EreignisgesteuerteProzessketten (EPK) vorgenommen werden. Die angesprochenen Konzepte wer-den im Folgenden detailliert erklärt.


2.3.1 Regelbasiertes System

Grundlagen: Geschäftsregeln können durch das regelbasierte System dargestelltwerden, das aus den folgenden drei Bereichen besteht:

. Faktenbasis: Datenbank an Fakten (Extraktion von Fakten aus Geschäftspro-zessen)

. Regelbasis: Menge an Regeln (Regeldatenbank)

. Business-Rule-Engine: Kontrollsystem mit Regelinterpreter

Die Business-Rule-Engine identifiziert Regeln in einem Geschäftsprozess derFaktenbasis und aktualisiert die angelegte Regeldatenbank mit neu angelegtenRegeln. Des Weiteren wird von der Engine die als nächstes anzuwendende Regelausgewählt.

Formale Darstellung: Regeln werden durch Domänenexperten in natürlicherSprache ausgedrückt und liegen in Form von: WENN DANN SONST (IF THENELSE) Abfragen vor. Dadurch wird eine bestimmte Regel (= EVENT) zerlegtund dargestellt. Dabei bildet der WENN Teil als Prämisse die Annahme einerbestimmten Voraussetzung für die Konklusion (= DANN) durch eine bestimmteAktion. Eine weitere Abzweigung durch weitere Konklusionen (= SONST) alsAlternative anderer Aktionen ist möglich.

EVENTWENN ( Prämisse / Voraussetzung )...

DANN ( Konklusion durch eine Aktion )...SONST ( Konklusion durch eine anderer Aktion ) ...

Listing 5.1. Allgemeines Schema eines Regelsystems

Listing 5.2 zeigt wie man die bereits definierten Beispiele in ein regelbasiertesSystem überführen kann.

PKW Miete :WENN Kunde älter als 24 Jahre ist UND einen gültigen Führerschein besitzt ,

DANN wird der Mietwagen reserviert ,SONST wird die Anfrage zurückgewiesen

PKW Rückgabe :WENN der Tankinhalt bei der PKW Rückgabe unter 90 Prozent liegt ,

DANN wird der Kunde in die schwarze Liste eingetragen UND der PKWwird aufgetankt

SONST wird der PKW gereinigt

PKW Bezahlung :WENN ein Kunde mit der Kreditkarte bezahlt ,

DANN werden 10 Prozent auf den Mietwagenpreis gutgeschriebenSONST zahlt der Kunde 100 Prozent des Mietwagenpreises

Listing 5.2. Beispiel von Regeln innerhalb einer Autovermietung als Regelsystem


2.3.2 JBOSS-Rules Um die Softwarequalität hinsichtlich Flexibilität, Wart-barkeit, Kosten und Stabilität zu verbessern, erfolgt bei JBOSS eine Unterteilungin ein prozessorientiertes System, welches aus Geschäftsprozessen, Geschäftsregelnund der Basisfunktionalität besteht.

Bei den Regeln handelt es sich um ein Java basiertes Regelsystem, dessenSyntax sich eng an der formalen Darstellung des bereits vorgestellten regel-basierten Systems anlehnt. Die Trennung von Software in Basisfunktionalität,Geschäftsprozesse und Regeln erhöht die Flexibilität, indem Änderungen anGeschäftsprozessen und Regeln im laufenden Betrieb möglich und durch diejeweilige Fachabteilung mit wenig Hilfe von IT Spezialisten durchführbar sind.Basisfunktionalität, Geschäftsprozesse und Regeln sind unabhängig testbar unddurch deren klare und strukturierte Definition ist neben dem geringen War-tungsaufwand gleichzeitig eine übersichtliche Dokumentation verfügbar. Dadurchwird auch die Stabilität des Regelsystems erhöht, da bereits getestete Methodenwiederverwendet werden.rule 'PKW_Miete '

when$c: Customer ( alterKunde >= 24, DrivingLicence == TRUE );

thenSystem .out. println ('Der PKW 'BMW Isetta ' wurde reserviert ');Car. reserve ($c. getCarRequest ());

end

rule 'PKW_Rückgabe 'when

$p: Car ( gasoline . Value <= 50);then

System .out. println ('Der Kunde Fritz wurde auf die Blacklist gesetzt ');Customer . addStatus (' Blacklisted ');

end

rule 'PKW_Bezahlung 'when

$c: Customer ( carPayment == 'CreditCard ');then

Car. setPrice ( Price . getDiscount (10));end

Listing 5.3. Beispiel von Regeln innerhalb einer Autovermietung, definiert alsJBOSS-Rule

2.3.3 ECAA-Regeln und EPK Die ECAA-Regeln zur Modellierung vonGeschäftsregeln wurde im regelbasierten Modellierungsansatz aufgegriffen underweitert. Sie stellt die Grundlage für eine strukturierte Modellierung von Ge-schäftsregeln dar. Die explizite Modellierung einer Bedingungskomponente ermög-licht eine praxisnähere Modellierung von Geschäftsregeln, als es beispielsweisemit ereignisgesteuerten Prozessketten (EPK) möglich ist und bietet zusätzlicheMöglichkeiten für eine Modellierung der Ablaufsteuerung. Der Grundaufbau derECAA-Regel mit deren Hilfe Constraints und Reaction Rules formuliert werdenkönnen ist in Abbildung [3] dargestellt. Ein weiteres komplexeres Beispiel füreinen regelbasierten modellierten Prozess wird in Abbildung [4] dargestellt. Hier-bei stellt ein Kunde eine Anfrage an eine Autovermietung, einen PKW zu mieten.


Abbildung 3. Grundaufbau einer ECAA Regel

Dabei wird ersichtlich, dass eine Geschäftsregel nicht immer für sich alleine, alsatomare Regel steht, sondern eng mit anderen Geschäftsregeln verknüpft sowiein den gesamten Prozessverlauf integriert ist. Eine Geschäftsregel die mit der

Abbildung 4. Erweiterte ECAA Regel

ECAA-Regel modelliert wurde und deren Überführung in ihre entsprechendeEPK (Ereignisgesteuerte Prozesskette) ist in Abbildung [5] dargestellt. Will einKunde einen PKW mieten und ist Neukunde, muss dieser erst erfasst werden,ansonsten wird der Auftrag sofort erstellt. Der WENN/DANN/SONST Zweigder ECAA Regel wird in der EPK durch eine XOR Operator exemplarischmodelliert. Nachdem nun im letzten Kapitel Grundlegende Definitionen undDarstellungsweisen von Regeln vorgestellt wurden, kommen wir nun zu konkretenModellierungsnotationen, die jeweils für spezifische Regelarten, wie Constraints,Derivation- oder Reaction Rules, entwickelt wurden. Zu Beginn werden die beiden


Abbildung 5. Exemplarische Darstellung einer ECAA-Regel und deren Model-lierung als EPK

Notationen R-Notation und ORM vorgestellt, die haupsächlich für Constraintsund Derivation Rules verwendet werden. Danach werden die Agent-Oriented-Modeling-Language und die UML-Based-Rule-Modeling-Language präsentiert,die in der Praxis vor allem bei der Modellierung von Reaction Rules eingesetztwerden[13].

3 Ross-Notation

3.1 Definition

Die von Ronald G. Ross entwickelte R-Notation definiert Regeln als Konstruktedie aus Termen und Fakten bestehen. Als Grundlage für die präzise und formaleKlassifikation von Geschäftsregeln dient das von Ross entwickelte Business RulesManifesto, das folgende wichtige Aspekte für Regeln beinhaltet:

. Regeln sind essentiell für die Modellierung von Anforderungen innerhalbvon Geschäftsmodellen, Systemmodellen und Implementierungsmodellen imUnternehmensumfeld.

. Regeln sind weder Prozesse noch Prozeduren sondern stoßen diese an.

. Regeln sind auf Fakten aufgebaut, die auf Geschäftskonzepten basieren, diewiederum aus Termen bestehen.

. Eine Regel muss immer eindeutig definiert, und in natürlichen Sprache ausge-drückt werden (CIM-Ebene), und hat den Anspruch, allgemein verständlichzu sein.

. Regeln sind Bedingungen (Constraint) für Verhalten.


. Das Verhältnis zwischen Ereignissen (Event) und Regeln ist im allgemeinem:n.

. Bei Regelverletzungen, muss eine alternative Aktivität (Activity) zur Verfü-gung stehen.

. Regelausnahmen und Verfeinerungen werden wiederum durch andere Regelnmodular ausgedrückt.

. Regel sollen von Domänenexperten mittels eines Modellierungstools auf derPIM-Ebene entwickelt werden, damit die Geschäftsregeln flexibel auf andereSoftware- und Hardwareplattformen übertragen werden können.

Die Eckpfeiler des soeben beschriebenen Manifest bilden die Grundlage für dentextuellen und grafischen Modellierungsansatz der R-Notation.

3.2 Einsatz in der Praxis

In der Praxis dient die R-Notation der formalen Beschreibung von Geschäftsregeln.Aufgrund fehlender Modellierungstools wird die Ross Notation vorwiegend alsGrundlage für weitere Regelmodellierungssprachen, die ihren Schwerpunkt in derFormulierung von Constraints setzen, verwendet. Dazu gehört die im nächstenKapitel beschriebene Object-Rule-Modeling-Language. Darüber hinaus bildet dieR-Notation einen guten Einblick in die Komplexität von Geschäftsregeln undstellt diese auf verständliche aber bereits formal definierte Weise dar.

Die formale Definition einer Regel der R-Notation basiert auf der Beschrei-bung des Regelbasierten Systems und wird ebenfalls durch eine Implikationausgedrückt[7]:

IF p THEN q

. p und q entsprechende Boolschen Ausdrücken.

. p nennt man Antecedent (vorangehend) bzw. Prämisse (Voraussetzung).

. q nennt man Consequent (folgend) bzw. conclusion (Folgerung).

. p impliziert q (p → q) ist ebenfalls ein gültiger Ausdruck für diese Beispiel

. Die Sprache enthält weitere logische Operatoren wie AND, OR, NOT etc.und logische Quantifikatoren wie EXISTS, FORALL etc., um komplexereRegeln auszudrücken.

. (OR(NOT p)), q ist ebenfalls ein gültiger Ausdruck für obiges Beispiel.

Die Implikation beschreibt einen logischen Ausdruck, der auf einen Wahrheitswertabgebildet wird (TRUE, FALSE). Um im Speziellen auszudrücken, dass es sich beider Regel um einen Constraint handelt, erhällt der Antecedent einen Rule TypeIndicator. Dieser wird durch eine hochgestelltes T für True beim Antecedentenhinzugefügt.

MT → A AND F

(PKW Mieten)T → Älter als 24 AND Führerschein ist vorhanden Falls dielogische Implikation statt einem Constraint eine Abfrage formuliert, wird dashochgestellte T durch ein hochgestelltes Fragezeichen ersetzt.


M? → A AND F(PKW Mieten)? → Älter als 24 AND Führerschein ist vorhanden Frage: Impliziertdas Mieten eines PKWs, dass der Kunde älter als 24 ist und einen gültigenFührerschein hat? Damit Regeln untereinander eindeutig referenziert werdenkönnen, wird vor den logischen Ausdruck der Name der Regel geschrieben.

R1: MT → A AND FRegel-für-Miete-PKW: (PKW Mieten)T → Älter als 24 AND Führerschein istvorhanden

3.3 Konkrete Syntax und SemantikEine Entity entspricht einem Objekt im Regeldiagramm, das einen Namen undAttribute besitzt und mit anderen Entitäten über Assoziationen verbunden ist.Die oben beschriebenen Constraints bestehen hierbei aus zwei Varianten, denIntegrity Constraints und den Conditions[4]. Die beiden Constraintarten könnendurch 42 Regeltypen repräsentiert werden. Dazu gehören z.B. RESTRICTED,EQUALITY und EXISTS, das im folgenden Beispiel verwendet wird. Ein IntegrityConstraint ist eine Bedingung, die im Bezug auf eine Assoziation zwischen zweiEntitäten oder eines Attributes, nach Definition immer wahr sein muss. EineCondition ist ebenfalls eine Bedingung, die wahr oder falsch sein kann. Je nachdemkönnen, abhängig vom Ergebnis, andere Constraints oder Aktionen aufgerufenwerden. Sowohl Integrity Constraints als auch Conditions besitzen jeweils eineeingehende Kante, die vom Antecedent ausgeht. Die Integrity Constraints besitzenmehrere ausgehende Kanten, die zum Consequent führt. Conditions könnenauch mehrere ausgehende Kanten besitzen, um auf den Consequent und andereConstraints zu referenzieren. Folgendes Beispiel verdeutlicht die Visualisierungvon Geschäftsregeln innerhalb der R-Notation. Die Integrity Rule mit dem

Abbildung 6. Modellierungsbeispiel der Ross-Notation

logischen Quantifikator EXISTS sagt aus, dass die Zweigstelle (Entity) einerAutovermietung eine Adresse (Attribut) besitzen muss.


Formal ausgedrückt:

Regel1: ZweigstelleT → Adresse

Die Condition mit dem logischen Quantifikator EXISTS sagt aus, dass eineZweigstelle (Entity) einer Autovermietung die eine Adresse (Attribut) besitzt aufdas Constraint Regel2 verweist.

Formal ausgedrückt:

Regel1: ZweigstelleT → Adresse → Regel2

Durch den Gebrauch von 42 Regelarten kann durch die R-Notation jeglicherFall von möglichen Contraints als Geschäftsregel abgedeckt werden, was bei derModellierung das Problem der Komplexität erhöht. Im nächsten Kapitel solldeshalb die übersichtlichere ORM Notation vorgestellt werden, welche ebenfallsdie Möglichkeit der Contraintmodellierung bietet.

4 ORM - Objekt Role Modeling Language

4.1 Definition

ORM (Objekt Role Modeling Language) visualisiert reale Anwendungsfälle alseine Reihe von Objekten (Entities) die Rollen übernehmen und damit mitein-ander in Beziehung stehen (Relationship). Diese Objekte und Rollen werdenentweder in natürlicher Sprache und in intuitiven Diagrammen beschrieben. ORMwird darüber hinaus auch als faktenbasierte Modellierungstechnik bezeichnet[2],da Daten als atomaren Fakten formuliert werden und diese ohne Verlust vonInformation nicht weiter zerlegt werden können.


ORM dient in der Praxis als Sprache um die Komplexität von Betrieben zuerfassen. Auf Grund einer klaren und detaillierten Formulierung ist ORM alsModellierungstechnik sehr anpassungsfähig, um schnell auf Änderungen in Un-ternehmensprozessen und -Strukturen reagieren zu können. ORM basiert auf derIdee der ER-Modellierung und ist eine Methode, für die konzeptionelle Erstellungvon Datenbanken, die im Rahmen der Datenmodellierung einen Ausschnitt derrealen Welt beschreibt. Somit dient zum einen das ORM-Modell in der Implemen-tierungsphase als Grundlage für das Design der Datenbank, zum anderen in derkonzeptionellen Phase der Anwendungsentwicklung zur Verständigung zwischenAnwendern und Entwicklern. Hierbei wird ausschließlich die Sachlogik, und nichtdie Technik, dargestellt.


Abbildung 7. Konkreter Syntax von ORM

4.3 ORM - Modellierung

4.3.1 Konkrete Syntax und Semantik - Grundelemente Im folgendenKapitel werden alle relevanten Grundelemente definiert, welche für die Model-lierung von Geschäftsregeln unter ORM nötig sind. Nach Abbildung [7] sinddies: Um den genauen Zusammenhang der Objekte zu verstehen werden dieGrundelemente und ihre Funktionsweise definiert und in Abbildung [8] derenZusammenhang präsentiert.

Objekte sind allgemein formulierte Entitäten, die sich aus der zugrundeliegendenDatentabelle (Faktenbasis) erschließen. Diese Tabelle enthält Daten über Objektedes realen Lebens, wie Fahrzeugklassen oder Kunden, bezogen auf das Beispielder Autovermietung. Um den Objekttypen genau zu identifizieren, werden denObjekten spezifische Datentypen (Schemes) zugewiesen. So wird der ObjekttypFahrzeugklasse beispielsweise anhand des Typs PKW-Klasse und der Kundeanhand seines Namens identifiziert. Objekte werden über Kanten mit Faktenverbunden, wodurch eine spezifische Rolle entsteht. ORM erlaubt Verbindungenmit einer Rolle (unär), oder auch mehreren Rollen (binär, ternär) wobei aufgrundder atomaren Definition von Fakten in der Praxis nicht mehr als vier Rollen mitObjekten verbunden sind.

Rollen stellen, anhand ihrer Beschriftung und Bedingungen (Constraints), diegenaue Beziehung zwischen Objekttypen dar und sind mittels Kanten mit min-destens einem Objekttyp verbunden. Für jede Rolle existiert eine entsprechendeFaktentabelle. Eine Rolle kann auch als Faktentyp bezeichnet werden.


Verbindungen sind Kanten zwischen Rollen und Objekten. Sie können zusätz-lich durch deren Semantik Contsraints definieren. Die genaue Funktionsweisewird jedoch der Übersicht halber in Kapitel 4.3.2 erklärt.

Faktentabellen enthalten Objekte, von Objekttypen, die mit der zugehörigenRolle über Kanten verbunden sind. Der Aufbau der Faktentabellen orientiertsich an der tabellarische Darstellung der Datentabelle. Abbildung [8] präsentiertein ORM-Diagramm mit den Objekttypen Kunde und PKW, die zum einenanhand ihres Namens und zum anderen anhand der KFZ-Klasse identifiziertwerden. Dabei sind die beiden Obekttypen mittels Kanten mit dem binärenFaktentypen (zwei Rollen) „mieten“ verbunden. So wird exemplarisch von Person1eine Mittelklassewagen und ein Kleinwagen von Person2 gemietet.

Abbildung 8. Beispiel - Zusammenhang der Grundelemente

4.3.2 Konkrete Syntax und Semantik - Constraints Aufbauend auf denORM-Grundelementen wird in diesem Kapitel nun die Regelmodellierung mitConstraints innerhalb von ORM beschrieben. Dafür wird die Syntax um folgendeElemente erweitert:

Um den Gesamtzusammenhang der Constraints innerhalb der ORM-Modellierungzu verstehen, wird im Folgenden der erweiterte Syntax präzise definiert und er-neut in zwei weiteren Beispielen (Abbildung [10] und [11]) diskutiert. FolgendeConstrainttypen können in ORM modelliert werden:

Mandatory Role Constraint Jeder Objekttyp ist bezüglich seiner Rolle miteinem anderen Objekttypen verbunden d.h. jedes Objekt ist in der Faktentabelleimmer mit einem anderen Objekt verknüpft. Leere Einträge in der Faktentabellesind hier nicht erlaubt.

Uniqueness Constraint (1:1) Jedes Objekt in der Faktentabelle ist eindeutigeinem anderen Objekt zugeordnet und umgekehrt analog.


Abbildung 9. Erweiterte Syntaxelemente für die Constraints


Uniqueness Constraint (n:1) Jedes Objekt in der Faktentabelle ist eindeutigeinem anderen Objekt zugeordnet, umgekehrt jedoch können auch mehrereObjekte zugeordnet werden.

Uniqueness Constraint (m:n) Jedem Objekt können in der Faktentabellemehrere andere Objekt zugeordnet werden und umgekehrt analog.

Pair-Exclusion Constraint Zwischen unterschiedlichen Rollen sind gleichePaare von Objekten aus den jeweiligen unterschiedlichen Faktentabellen verboten.

Asymmetric Constraint Assymetrische Verbindungen von Objekten unterein-ander sind verboten. z.B. Es gilt nicht: x → a AND a → x ⇒ x → x

External-Uniqueness Constraint Innerhalb unterschiedlicher Faktentabellesind Dublikate von Objekten verboten und somit eindeutig.

Pair-Subset Constraint Pair-Subset Constraints definieren Subtypen zwischenRollen bzw. Objekttypen.

Beispiel: Jeder Angestellte hat genau einen Namen. Außerdem besitz der Auf-trag genau einen Mitarbeiter, der diesen bearbeitet. Jeder Mitarbeiter berichtetgenau einem Vorgesetzen (Uniqueness Constraint n:1). Es besteht die Möglichkeit,dass mehrere Angestellte mehr als einen Auftrag prüfen und Aufträge von mehrals einem Mitarbeiter geprüft werden (Uniqueness Constraint m:n). Jeder Mitar-beiter besitzt immer einen Namen und Aufträge werden immer von Mitarbeiternausgeführt (Mandatory-Role Constraint).

Kein Mitarbeiter prüft und führt Aufträge gleichzeitig aus (Pair-ExklusionConstraint). Wenn ein Mitarbeiter den anderen überwacht, ist das Gegenteil nichtmöglich (Asymmetric Constraint). Weitere Constraints werden in Abbildung [11]dargestellt. Innerhalb einer Abteilung sind Namen eindeutig vergeben (External-Uniqueness Constraint). Jeder Manager, der eine Abteilung leitet arbeitet auch fürdiese und ist somit auch ein ein Mitarbeiter (Pair-Subset Constraint). DerivationRules besitzen innerhalb der ORM Modellierung keinen konkreten Syntax sondernmüssen logisch aus den ORM Diagrammen abgeleitet werden. Die Tatsache, dassein Manager seine Mitarbeiter leitet, muss aus dem Umstand abgeleitet werden,dass ein Manager eine Abteilung leitet, die Mitarbeiter beschäftigt (DerivationRule). Um aus einer Datentabelle die oben beschriebenen ORM-Diagramme zumodellieren, führen Entwickler bzw. Anwender, folgenden Algorithmus in siebenSchritten aus[3].

1. Wandle bekannte Informationen in elementare Fakten um und mache einenQualitäts Check.

2. Zeichne das ORM-Diagramm und überprüfe die Modellierung mit Beispielenaus der Faktentabelle.


Abbildung 10. Exemplarische Darstellung verschiedener Constraintformen 1/2

Abbildung 11. Exemplarische Darstellung verschiedener Constraintformen 2/2


3. Teste, ob Objekt Typen zusammengefasst werden sollten und kennzeichnealle Typen, die aus den Bestehenden generiert werden können.

4. Füge Uniqueness Constraints hinzu, und teste diese.5. Füge Mandatory-Role Constraints hinzu und teste ob etwas logisch ableitbar

ist.6. Füge einschränkende Constraints, Pair-Constraints und Subset-Constraints

ein.7. Füge restliche Bedingungen ein und führe letzten Check durch.

Anschließend kann der Entwickler bzw. der Anwender auf Basis des erstelltenORM-Diagramms (CIM) mittels des Frameworks automatisch Code für beispiels-weise relationale Datenbankmanagementsysteme (PSM) generieren lassen. Dasfolgende Beispiel zeigt die automatisierte Codegnerierung in SQL-92 aus Abbil-dung [10]. Hier werden zur Vereinfachung Exclusion Constraints und AsymmetricConstraints als Zusicherungen (Assertions) implementiert.create assertion 'berichten istassymetrisch 'check ( not exists ( select *from Mitarbeiter X, Mitarbeiter Ywhere X. angestelltennr = Y. vorgesetzterand X. vorgesetzter = Y. angestelltennr ))

Listing 5.4. Beispielcode nach automatisierter Codegenerierung (PSM)

5 AORML - Agent Object Relationship ModelingLanguage

5.1 Definition

AORML (Agent-Object-Relationship Modeling Language) ist ein agentenbasierterModellierungsansatz, der auf Basis von AOR (Agent Object Relationship Mode-ling) die bereits existierenden Modellierungsansätze wie ER (Entity RelationshipModeling) und UML (Unified Modeling Language), erweitert[12]. Im Mittelpunktstehen Konzepte, welche auf die Bedürfnisse von Unternehmenskommunikati-on zwischen der beteiligten Kommunikationspartnern zugeschnitten sind. Diesewerden im Folgenden als Agenten bezeichnet. Kommunikation und Interaktionkönnen dadurch besser dargestellt werden.


AORML dient den Anwendungsentwicklern in der konzeptionellen Phase zurModellierung von Geschäftsprozessen bzw. von Geschäftsregeln.

Die Agenten-Orientierung wird als neues Paradigma im Software und In-formationsengineering angesehen. Sie bietet dabei höchstes Abstaktionsniveau,das die Konzepte von Kommunikation und Interaktion in bereits bestehede In-formationssysteme ermöglicht. Da Geschäftsprozesse meist auf Agenten (oderauch Akteure) ausgerichtet sind, ist der agentenorientierte Ansatz hier aufgrund


der physikalischen und sozialen Interaktion der verschiedenen Individuen oderInstitutionen sehr bedeutend. Es können Modelle für den externen und für deninternen Betrachter existieren[5]. In der Analysephase werden in einem externenModell die Hauptakteue modelliert. In der Designphase wird für jeden dieserHaupagenten ein internes AOR Modell erstellt. Abschließend werden die internenAOR-Modelle in die plattformabhängige Zielsprache wie Java oder SQL übersetzt(PSM).

5.3 AORML - Modellierung

5.3.1 Grundelemente Basierend auf 19 Onthologieprinzipien, sowie einerzugehörige Diagrammsprache wurde ein Framework für die Modellierung entwi-ckelt. Die Onthologieprinzipien erweitern die Entity-Relationship Prinzipien umwichtige Aspekte der agentenbasierten Kommunikation in Unternehmen. Dazugehören die aus entities abgeleiteten Kategorien der Agenten (agents), Ereignisse(events), Aktionen (actions), Rechte (claims), Verbindlichkeiten (commitments)und gewöhnliche Objekte (ordinary objects). Der genaue Zusammenhang wird inAbbildung [12] als Metamodell dargestellt.

Abbildung 12. Metamodell Entity - AORML Grundelemente

. Entity (Entität) ist ein bekanntes Prinzip aus der ER Modellierung undbeschreibt innerhalb eines Softwaresystems, abstrakte oder materielle Objekteder Wirklichkeit. Sie werden in die oben beschriebene Kategorien eingeteilt,die im Folgenden detailliert definiert werden.

. Commitment (Verbindlichkeit)/Claim (Recht) sind immer mit einemActionEvent gekoppelt und sind fundamentale Komponenten im sozialen In-teraktionsprozess, um präzises Verhalten vorherzusagen und zu gewährleisten.Beispiel Commitment:Der Kunde hat die Verbindlichkeit den PKW bei der


Autovermietung zurückzugeben. Beispiel Claim: Die Autovermietung hat dasRecht, das Auto vom Kunden zurück zu fordern.

. Ein Event beschreibt ein Ereignis, dass während eines Prozessworkflowsauftreten kann. Hierbei wird zwischen dem ActionEvent und dem Non-ActionEvent unterschieden, wobei ActionEvents von Aktionen ausgelöstwerden. ActionEvents können mit Commitments und Claims wie bereitsbeschrieben gekoppelt werden. Non-ActionEvents finden unabhängig vonAktionen statt. Außerdem können ActionEvents in Communicative- und Non-Communicative-ActionEvent unterschieden werden. Beispiel Non-ActionEvents:Die Tempertaur steigt über 30 Grad Celsius (⇒ Alle Klimaanlagen der Miet-wagen checken. Beispiel Non-Communicative-ActionEvent: Die Autovermie-tung stellt dem Kunden einen PKW zur Verfügung. Beispiel Communicative-ActionEvent: Der Kunde stellt eine Reservierungsanfrage an eine Autover-mietung.

. Actions stoßen Events an, die ActionEvents genannt werden.

. Objekte entsprechen den Entity-Typen im ER-Diagramm bzw. den Objekt-Klassen im UML-Klassendiagramm. Sie stehen mit anderen Agenten oderObjekten in Verbindung.

. Agenten lassen sich in Artificial-, Institutional- und BiologicalAgents un-tergliedern. ArtificialAgents sind Kommunikationsagenten die auf einemSoftwaresystem basieren. Dazu zählen Roboter, Softwareagenten und ein-gebettete Systeme. InstituationalAgents sind soziale Konstrukte wie Orga-nisationen und Organisationseinheiten. Zu den BiologicalAgents gehörennur menschliche Akteure. Beispiel ArtificalAgents: Buchungssystem. BeispielInstitutionalAgents: Autovermietung. Beispiel BiologicalAgents: Kunde.Zusätzlich werden bei Organisationen zwischen internen- und externen Agen-ten unterschieden, wobei eine Organisationseinheit immer aus mehrereninternen Agenten besteht und gleichzeitig mit mehreren externen Agentenin Beziehung treten kann. Beispiel: Aus der Sicht der „Autovermietung“(Organisation) steht diese mit dem externen Agenten „Kunde“ in Beziehung.Außerdem besteht die Organisation aus mehrere internen Agenten (Organi-sationseinheiten wie z.B. Zweigstellen) die wiederum aus weiteren internenAgenten besteht (z.B. Mitarbeiter als HumanAgent)


Abbildung 13. Metamodell Agent - AORML Grundelemente

5.3.2 Konkrete Syntax und Semantik - Grundelemente Agenten kön-nen im Gegensatz zu Objekten Events erkennen, Nachrichten (MessageTypes)senden und empfangen, Non-CommunicativeActionsEvents ausführen und Rechte(Claims) bzw. Verbindlichkeiten (Commitments) einfordern. Der konkrete Syntaxund die jeweiligen Relation der beschriebenen Grundelemente sind in Abbildung[14] dargestellt.

Abbildung 14. Konkreter Syntax - Grundelemente

5.3.3 Konkrete Syntax und Semantik - Reaction Rules Nachdem derZusammenhang der verschiedenen Grundelemente erläutert wurde, wird nundetailliert auf die visuelle Darstellung von Geschäftsregeln eingegangen, dieallerdings sehr eng mit dem Aufbau der AOR Grundelemente in Verbindungsteht. Regeln werden als ReactionRule durch einen Kreis mit folgenden ein- undausgehenden Kannten beschrieben, welche die Funktionsweise, das Verhalten unddie Semantik der Regel erst abstrakt definieren.


Abbildung 15. Konkreter Syntax einer Regel

. Triggering Event (eingehende Kante die immer vorkommt): Bedingung,die ein Ereignis auslöst und die Reaction Rule instanziiert

. State Condition (eingehende Kante): Kante gibt Bezug zu anderen dazu-gehörigen Entity Typen an

. Outgoing Message (ausgehende Kante): Mentale Auswirkung (Belief/Com-mitment)

. Action (ausgehende Kante): Ausführen einer Aktion

. State Change (ausgehende Kante): Mentale Auswirkung (Belief/Commit-ment)

Abbildung 16. Beispiel - Regelemodellierung innerhalb einer Autovermietung

Events können von Akteuren, als MessageTypes, an andere Akteure oderauch Regeln übergeben werden. Folgender Messagetype beschreibt eine Über-prüfung, ob eine Kunde bereits auf einer schwarzen Liste steht und somit einen


PKW überhaupt mieten darf. Der Messagetype löst als triggering event ei-ne Regel aus und ist dadurch eine Vorbedingung für die Regel. Beispiel: as-kIf(blacklisted(?Customer))

Zusätzlich zur visuellen Darstellung von Reaction Rules, können diese auchin eine textuelle Form übertragen werden.

R1:1: ON RECEIVE requestReservation (? CarGrp , ? Period ) FROM ? Customer2: IF ? CarGrp . hasCapacity (? Period )3: THEN4: SEND askIf ( blacklisted (? Customer )) TO headquarter

Listing 5.5. Beispiel für eine Reaction Rule - Reservierung in einer Autovermie-tung

Die Syntax einer Reaction Rule lehnt sich am Syntax der EACC Regel an.Der in der erste Zeile beschriebene Event Messagetype ist Triggering Event fürdas schalten der Regel R1. Die zweite Zeile überprüft den aktuellen Status einerBedingung, der für die Statusänderung in Zeile 4 Voraussetzung ist. Erst wennder Status erfüllt ist, kann eine Aktion ausgeführt werden oder sich ein Statusändern. Die Statusänderung dient darüber hinaus noch als Triggering Event fürdas schalten von Regel R2. Um die Ablaufsteuerung einer Reaction Rule präzisezu gestalten sind erweiterte Boolsche Operatoren nötig, die folgendermaßenmodelliert werden:

AND-Split: Die Regel R1 führt einen AND-Split aus indem sie ausgehend vonActionEvent1 sowohl eine neue Message, als auch einen neuen ActionEvent2gleichzeitig schaltet.

Abbildung 17. Modellierung eines AND-Split in AORML

AND-Join: Die Regel R1 führt einen AND-Join aus indem sie ausgehend vonden eingehenden Nachrichten Message1 und Message2 eine neue Message3 sendet,falls die eingehenden Kannten gleichzeitig gelten.

OR-Split: Die Regel R1 führt einen OR-Split aus indem sie ausgehend von Ac-tionEvent1 entweder eine neue Message, oder einen neuen ActionEvent2 schaltet.


Abbildung 18. Modellierung eines AND-Join in AORML

Abbildung 19. Modellierung eines OR-Split in AORML

OR-Join: Die Regel R1 führt einen OR-Join aus indem sie ausgehend von deneingehenden Nachrichten Message1 und Message2 eine neue Message3 sendet,falls mindestens eine der eingehenden Kannten gilt.

Abbildung 20. Modellierung eines OR-Join in AORML

ELSE: Wenn eine Bedingung (Condition) war ist, sendet die Regel R1 dieNachricht Message1, ansonsten wird das ActionEvent2 geschalten.

NOT: Wenn eine Bedingung (Condition) falsch ist, sendet die Regel R1 dieNachricht Message1, ansonsten wird das ActionEvent2 geschalten.

6 URML - UML-Based Rule Modeling Language

6.1 Definition

MOF/UML Klassendiagramme sind Schlüsseltechnologien für die visuelle Reprä-sentation von Domänenkonzepten. Das klassische UML Metamodell wurde umneue Regelkonzepte erweitert um neben den Geschäftsprozessen auch detailliertGeschäftsregeln darzustellen. Diese Erweiterung wird in der Fachliteratur alsURML-Standard (UML-Based-Rule-Modeling-Language) bezeichnet[10]. URMLwurde, wie die bereits vorgestellten Modellierungssprachen entwickelt, um dieKommunikation zwischen Domänen- und Softwareexperten zu verbessern. Hierbeisteht wiederum eine natürliche, (semi-)visuelle Darstellung von Regeln im Vorder-grund. Neben der Analyse erfüllt URML auch den Zweck der Dokumentation der


Abbildung 21. Modellierung von ELSE in AORML

Abbildung 22. Modellierung von NOT in AORML

Systemanforderungen innerhalb von Unternehmen. Bei der Regeldarstellung liegtder Fokus auf der Modellierung von Derivation-Rules. Aber auch Production- undIntegrity-Rules können visualisiert werden. Außerdem wird darüber nachgedacht,Reaction-Rules in den URML Standard zu integrieren.


Die Industrie fordert aufgrund von fehlender Erfahrung bei der visuelle Dar-stellung von Geschäftsregeln und Onthologien für das semantische Web, Mo-dellierungstools, die auf der bereits bekannten und umfangreich eingesetztenUnified Modeling Language (UML) basieren. Zu diesem Zweck wurde das StrelkaPlugin für das JAVA Modellierungstool Fujaba entwickelt (PIM-Ebene)[9]. DiesesModellierungstool arbeitet auf der Grundlage von URML und erweitert somitwie oben beschrieben UML-Modellierung um Regelkonzepte, die im Folgendendargestellt werden. Darüber hinaus bietet Strelka die Möglichkeit aus Regelm-odellen automatisiert Code auf Plattformen wie beispielsweise JBOSS-Rules zugenerieren (PSM-Ebene).

6.3 URML - Modellierung

Da URML das umfangreiche Metamodell von UML erweitert, und dieses alsbekannt vorausgesetzt wird, soll im Folgenden nur auf das erweiterte Konzeptbetrachtet werden.

6.3.1 Grundlagen Innerhalb von UML werden die URML Regeln als Erweite-rung eines, im UML Metamodell definierten, TypedElement mit einem Namespace


integriert. Somit repräsentieren Regeln, Elemente mit einem bestimmten Typenund werden durch ihren Namen identifiziert. Nach Abbildung 23 werden Regeln in

Abbildung 23. Metamodell der Ruleinterpretation in

folgende drei bekannten Typen unterschieden, die im Modell folgende Funktionenbeinhalten:

Derivation Rules: Ableitungsregeln besitzen mindestens eine Vorbedingung(RuleCondition) und genau eine Folgerung (RuleConclusion). Diese Regel definiert,in wieweit bestimmte Modellelemente aus der Regel abgeleitet werden können.

Production Rule: Produktionsregeln besitzen wie Derivation Rules mindestenseine Vorbedingung (RuleCondition), genau eine resultierende Aktion (RuleAction)sowie optionale Nachbedingung (PostCondition).

Reaction Rule: Prozess- / Verhaltensregeln können mehrere Vorbedingungen(RuleConditions) enthalten und besitzen wie die ProductionRules genau eineresultierende Aktion (RuleAction) sowie optionale Nachbedingung (PostCon-dition). Außerdem benötigt diese Regel ein auslösendes Element (RuleEvent).ReactionRules repräsentieren somit eine ECAA Struktur.

6.3.2 Konkrete Syntax und Semantik In folgendem Abschnitt werden allerelevanten URML Regelelemente, deren Zusammenhang untereinander, sowie die


Abbildung 24. Konkreter Syntax einer Regel in URML

Integration in das UML Prozessmodell erläutert. Nach Abbildung [24] sind dies:Regeln werden durch Kreise mit ihrem zugehörigen Namen und einer eindeutigenID modelliert. Zusätzlich besitzen sie ein- und ausgehende Kanten. EingehendeKanten (ConditionArrow) repräsentieren Vorbedingungen (RuleCondition) unddefinieren die Beziehung zwischen Modellelementen und der Regel. Darüberhinaus können die eingehende Kanten negiert werden (NegatedConditionArrow)um eine Negation der Vorbedingung zu überprüfen. Einschränkungen einer Vor-bedingung werden durch textuelle Ausdrücke (FilterExpression) auf den Kantenvorgenommen. Ausgehende Kanten (ConclusionArrow) repräsentieren die Fol-gerung (RuleConclusion) und definieren die Beziehung zwischen der Regel unddem Modellelement. Auf ein- und ausgehenden Kanten werden für die Parame-terübergabe, an die Conditions bzw. Conclusions, Variablen verwendet. Für dasbessere Verständnis dient folgendes Beispiel [25] bei dem eine Derivation Rulemodelliert wurde. Hierbei überprüft die Regel DR mit der ID 8 ob ein Mietwagenvollgetankt (Filter Expression) bei einer bestimmten Zweigstelle untergebracht ist(Condition Arrow) und ob der Mietwagen momentan nicht anderweitig zugeteiltwurde (NegatedConditionArrow). Aus diesen Überprüfungen, leitet die DerivationRule ab, das der PKW zum Verleih zur Verfügung (ConclusionArrow) steht. Ein-und ausgehende Kanten sind zudem mit Variablen belegt, die hier zum besserenVerständnis der Derivation Rule, in folgender logischen Formulierung verwendetwerden.

. istVerfügbarBei(mw, zs) ← istUntergebrachtBei(mw, zs) AND tankInhalt(mw)≥90 AND ¬∃ma(istZugeteiltZu(mw, ma))


Abbildung 25. Modellierung einer Derivation Rule über URML

7 Gegenüberstellung und Vergleich der Regel-Modellierungsmethoden

In diesem Abschnitt werden die vorgestellten Regelmodellierungsmethoden be-wertet. Dafür müssen zunächst eine Reihe von geeigneten Bewertungskriterienausgearbeitet werden. Als Vorlage dient die DIN-ISO-Norm 9126, die zur Unter-suchung der Softwarequalität herangezogen wird. Softwarequalität wird dabei indieser Norm folgendermaßen abgegrenzt: „Software-Qualität ist die Gesamtheitder Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessenEignung beziehen, festgelegte Erfordernisse zu erfüllen“. Nach dieser Definitiongibt es nicht nur ein einziges Merkmal, an dem die Qualität festgemacht wer-den kann. Nicht alle Merkmale eignen sich dabei auch für die Evaluierung vonRegel-Modellierungsmethoden. Es wird daher zunächst eine Auswahl aus denvorhandenen Merkmalen getroffen bevor deren Begriffsbestimmungen an die spezi-fischen Erfordernisse der Qualitätsbeurteilung von Regel-Modellierungsmethodenangepasst wird.

Zu den geeigneten Merkmalen zählen Funktionalität, Benutzbarkeit undÄnderbarkeit. Zunächst muss der Begriff der Funktionalität definiert wer-den. Bei einer Software versteht man hierunter die Frage, inwieweit diese einenspezifizierten Funktionsumfang erfüllt und was damit umgesetzt werden kann.Übertragen auf Regelmodellierungsmethoden sind hier die Ausdrucksstärke, diePraxisnähe und eventuelle Alleinstellungsmerkmale eines Modells sinnvolle Be-wertungskriterien. Benutzbarkeit hingegen wird bei Software als Summe „alle[r]Eigenschaften eines Systems, die sich mit der Mensch-Maschine-Schnittstelle und


damit in direkter Weise mit der Benutzerinteraktion befassen“, festgelegt. Bei denRegelmodellierungsmethoden ist dabei die Sicht des Benutzers, der das Modellspäter betrachtet gemeint. Hierbei wird nach Erlernbarkeit der Syntax sowie derVerständlichkeit des gesamten Modells differenziert. Als letztes Merkmal wirddie Änderbarkeit herangezogen. Sie soll die Sichtweise des Modellierers darstel-len. Interessante Teilbereiche sind hierbei der Modellierungsaufwand sowie dieMöglichkeit, ein bestehendes Modell nach der Umstellung einer Regeländerunganzupassen und dessen anschließende Stabilität zu beurteilen. Diese an die Er-fordernisse der Beurteilung von Regelmodellen adaptierten Bewertungskriterienbilden nunmehr die Basis für die Evaluierung der vorgestellten Modellierungs-sprachen.

FunktionalitätZuerst soll die Ausdrucksstärke einer jeden Sprache miteinander verglichen werden.Im Bezug auf die Ausdrucksstärke unterstütz URML die meisten Regelarten.Darunter befinden sich Constraints und Derivation Rules, die ebenfalls mit derRoss Notation und ORMmodelliert werden können. Außerdem können ProductionRules dargestellt werden und die Integration von Reaction Rules befindet sichin Planung. Bisher ist AORML im Vergleich die einzige Modellierungssprache,mit der Reaction Rules überhaupt dargestellt werden können, was somit auch alsAlleinstellungsmerkmal angesehen werden kann. Tabelle [2] zeigt die verwendetenRegeltypen der jeweiligen Modellierungssprachen noch einmal im übersichtlichenVergleich.

Regelmodellierungssprache Verwendete RegeltypenRoss Notation Constraints, Derivation RulesORM Constraints, Derivation RulesAORML Reaction RulesURML Constraints, Derivation Rules, Production Rules

Tabelle 2. Regeltypen der jeweiligen Modellierungssprache

Zur Praxisnähe ist zu sagen, das sich ORM im Bereich der Regelmodellierungfür Datenbanken etabliert hat und somit einen Vorteil im Vergleich zu den anderenSprachen hat[11]. Der umfangreiche Toolsupport von ORM (NORMA: Pluginfür Visual Studio) und URML (Fujaba: Rule Plugin) unterstreicht den intuitivenEinsatz in der Praxis. Für AORML ist ebenfalls ein Plugin für MS Visio verfügbar,dass aber aufgrund der Modellierungsmöglichkeit von nur einer Regelart wenigerRelevanz als die bereit erwähnten Sprachen hat. Für die Ross-Notation existiertkein bekannter Toolsupport.

BenutzbarkeitFür den Benutzer, der das Modell am Ende verstehen und anwenden soll, istzum einen die Verständlichkeit ein wichtiges Kriterium. Dabei stellt sich die


Frage, ob das Regelmodell übersichtlich und der Ablauf der modellierten Regeleinfach nachzuvollziehen ist. Die Praxis zeigt, dass ORM und AORML durch dieintuitive Darstellung von Regeln, in natürlicher Sprache kombiniert mit sinnvollverwendeten grafischen Elementen, einfach zu verstehen und zu erlernen ist. DaURML eine Erweiterung von UML ist, ist es leichter als ORM und AORMLzu erlernen, durch die technische Sicht jedoch schwieriger zu verstehen. DieRoss-Notation die weniger eine einfache grafische Notation besitzt, sondern ehereine aus logischen Ausdrücken bestehende formale Sprache darstellt, ist somitschwierig zu erlernen. Dazu kommt, dass 42 verschiedene Regeltypen existieren.

Änderbarkeit

Schließlich wird noch die Sicht des Modellierers betrachtet. Wie bereits erwähnt,soll dabei auf die Änderbarkeit eines Regelmodells eingegangen werden. KomplexeModelle sind selbstverständlich aufwendiger zu konstruieren und schwerer zuverstehen. ORM ist die stabilste Sprache, da sie im Gegensatz zu den anderenNotation nicht zwischen Klassen und Attributen unterscheidet, sondern sie alsunabhängige Konzepte betrachtet. Somit ist die Änderbarkeit bei ORM sehrhoch und weniger mit Seiteneffekten behaftet.

Vergleichstabelle

Die Ergebnisse der vorangegangenen Abschnitte werden zum Abschluss nocheinmal übersichtlich in Vergleichstabelle [3] dargestellt. Dabei stellt ein „+“ einestarke Ausprägung dar und ist als positiv anzusehen. Die „0“ steht für eineneutrale Ausprägung, während das „-“ eine schwache Ausprägung ist und eineSchwäche der Sprache im jeweiligen Bereich darstellt.

Beurteilungskriterium/Notation Ross-Notation ORM AORML URMLAusdrucksstärke 0 0 0 +Praxisnähe - + 0 +Alleinstellunsgmerkmale 0 0 + 0Verständlichkeit 0 + + 0Erlernbarkeit - 0 0 +Änderbarkeit 0 + 0 0

Tabelle 3. Übersicht Vergleichskriterien

8 Fazit

Zusammenfassend lässt sich feststellen, dass bei der Modellierung von Ge-schäftsprozessen die zusätzlich integrierte Geschäftsregelmodellierung essenziellfür die umfassende Darstellung, und Anpassung von Prozessabläufen ist und


somit die Flexibilität und Konkurenzfähigkeit von Unternehmen im Alltag stei-gert. Der Kerngedanke der Regelmodellierung besteht in der Verbesserung derKommunikation zwischen Domänen- und IT-Experten. Dafür verwenden alle viervorgestellten Sprachen eine relativ sachliche Darstellungsweise, wobei im Detailfolgende Unterschiede anzumerken sind. Alle betrachteten Methoden weisenSpezialisierungen im Bezug auf verwendete Regeltypen auf, wobei URML dienötige Integration mehrerer Regelarten erkennen lässt. Hierbei ist jedoch daraufzu achten, dass durch den universellen Ansatz nicht die Erlernbarkeit darunterleidet. ORM und URML sind darüber hinaus am weitesten verbreitet und bietendeshalb den besten Toolsupport. Zu AORML ist zu sagen, dass die Sprache zwareinen sehr guten Ansatz hinsichtlich der Verständlichkeit aufweist, allerdingsdurch die Spezialisierung auf einen Regeltypen nur bedingt für den umfassen-den, betrieblichen Einsatz geeignet ist. Die Ross-Notation ist in ihrer gesamtenKomplexität, durch ihr formales Gerüst, nur schwer für den Regelmodellierer zuerlernen und damit bedingt praxisnah.

Wünschenswert für die Zukunft wäre natürlich die Möglichkeit, verschiedeneModellierungssprachen für unterschiedliche Regelarten in einem Unternehmen,abhängig von den darzustellenden Regeltypen und der Präferenz des Modellierers,zu verwenden.

Literatur[1] T. C. u. L. W. Dr. Wolfgang Martin. Das Ende des Software-Release-Zyklus? -

Business Rules Management. JAXenter, Januar 2008.[2] T. Halpin. Business Rules and Object Role Modeling. Database Programming and

Design, Oktober 1996.[3] T. Halpin. Object-Role Modeling: an overview. Microsoft Corporation, 2001.[4] D. C. Hay. The Business Constraint Model. TDAN.com, Juli 2004.[5] G. W. Kular Taveter. Agent-Oriented Enterprise Modeling Based on Business

Rules. 2001.[6] J. Müller. Workflow-based Integration Grundlagen, Technologien, Management.

Springer, Berlin, 2005.[7] R. G. Ross. Principles of the Business Rule Approach. Addison-Wesley, 2003.[8] R. G. Ross. Business Rules and Events: The Crux of the Matter. Business Rules

Solutions - LLC, Mai 2005.[9] G. W. Sergey Lukichev. UML-Based Rule Modeling with Fujaba. Institute of

Informatics, Brandenburg University of Technology at Cottbus, Deutschland, 2006.[10] G. W. Sergey Lukichev. Visual Rules Modeling. Institute of Informatics, Bran-

denburg University of Technology at Cottbus, Deutschland, 2006.[11] M. J. Sergey Lukichev. Graphical Notations for Rule Modeling - Handbook of

Research on Emerging Rule-Based Languages and Technologies. Idea Group Inc.,2009.

[12] G. Wagner. The Agent-Object-Relationship Metamodel: Towards a Unified View ofState and Behavior. Eindhoven University of Technology, In Information Systems28:5, 2003.

[13] G. Wagner. The Abstract Syntax of RuleML: Towards a General Web Rule Lan-guage Framework. Proceedings of the IEEE,WIC,ACM International Conferenceon Web Intelligence, 2004.

Documents

Universität Augsburg Institut für Informatik Programmierung … › lehrstuehle › swt › ... · 2017-01-10 · Universität Augsburg Institut für Informatik Programmierung verteilter