XGenerator 2.0. Anwenderhandbuch Version 1.4

Transkript

1 XGenerator 2.0 Anwenderhandbuch Version 1.4 Februar 2008

2 Änderungsübersicht Version Datum Bearbeiter Beschreibung April 2007 Alina Stosiek (]init[ AG) Fabian Büttner (TZI) Mai 2007 Alina Stosiek (]init[ AG) Fabian Büttner (TZI) Ergänzung in Anhang B Hinzufügen des Anhang A und Abschnitt Juli 2007 Boris Neutzler (CSC) Überarbeitung Kap Januar 2008 Boris Neutzler (CSC) Überarbeitung Kap Februar 2009 Christian Senf Anpassung an XBeispiel Basisdokumente

3 Dokument Datei Beschreibung Bericht zum XÖV-UML- Profil Version 1.1 Technische Dokumentation zum XGenerator _UML-Profil für XÖV.pdf XGenerator_Technische_Dok umentation.odt Beschreibung eines generischen UML- Profils für XÖV-Projekte vom August 2006 Technische Dokumentation zur Architektur und Systemsicht des XGenerators 2.0

4 Inhaltsverzeichnis 1 Einleitung und Hintergrund Kontext Der XGenerator Inbetriebnahme Technische Voraussetzungen Installation des Tools Input-Verzeichnisstruktur Vorbereiten eines Projektes Verzeichnis model Verzeichnis templates Internationalisierung Anwendung des Tools mit Benutzeroberfläche Starten des Tools Projekte verwalten Projekt erstellen Projekt öffnen und wechseln Projekt löschen Arbeiten mit dem Tool Einlesen und Profil-Validierung des Modells Generierung und Validierung der XML-Schemata Generierung der DocBook-Dateien Darstellung von Schema-Elementen als SVG-Grafik Validierung der DocBook-Dateien Pfadangaben für die DocBook-Validierung Protokollierung Fehlermeldungen Seite 4

5 4 Fehlerbehandlung Input-Dateien Sessionhandling...27 Anhang A Aufbau der Eingabedateien.invariants,.operations, Codelisten..29 A.1 Die.invariants-Dateien...29 A.2 Die.operations-Dateien...31 A.3 Die Codelisten...33 Anhang B Hinweise zur Template-Entwicklung Fehler! Textmarke nicht definiert. B.1 Der Aufbau von XGenerator-Templates... Fehler! Textmarke nicht definiert. B.2 Verwendung von OCL, um das UML-Modell abzufragenfehler! Textmarke nicht definiert. B.3 Verwendung von Hilfsoperationen in den OCL-AnfragenFehler! Textmarke nicht definiert. Anhang C Glossar und Abkürzungsverzeichnis...38 Seite 5

6 Abbildungsverzeichnis Abbildung 1: Modelle, Profile, XÖV-Standards und der XGenerator... 9 Abbildung 2: Der XGenerator im Kontext Abbildung 3: Verzeichnisstruktur für Input Abbildung 6: Verzeichnis "templates" Abbildung 7: Benutzeroberfläche Seite 6

7 1 Einleitung und Hintergrund Die Umsetzung durchgängig elektronisch unterstützter und medienbruchfreier Prozesse über die Verwaltungsgrenzen hinweg ist ein wesentliches Ziel der Initiative Deutschland-Online (DOL). Das im Aktionsplan von den Regierungschefs des Bundes und der Länder im Juni 2006 festgeschriebene Deutschland-Online- Vorhaben Standardisierung soll hierbei die Entwicklung und Bereitstellung von fachlichen Standards für den elektronischen Datenaustausch mit und innerhalb der Öffentlichen Verwaltung unterstützen und fördern ( XÖV-Standards ). Hierzu werden insbesondere auch eine technische Infrastruktur und Werkzeuge für die Entwicklung angeboten, um einerseits eine Beschleunigung der Spezifizierung von Standards zu fördern, aber auch um eine einheitliche Vorgehensweise zu ermöglichen und vergleichbare Qualitätsaspekte sicherzustellen. Der XGenerator 2.0 ist zur Unterstützung der Öffentlichen Verwaltung beim Spezifizieren eines XML-basierten Datenaustausches konzipiert worden. Eine solche Spezifikation definiert eine Reihe von maschinenlesbaren XML-Schema-Dateien, die im wesentlichen die fachlichen Datenbeschreibungen beinhalten, und einer konsistenten Dokumentation für die Verfahrensentwickler. Es hat sich gezeigt, dass eine manuelle Pflege der Schemata und der Dokumentation schwierig und mit einem hohen Aufwand behaftet ist; eine Gefahr liegt in einer nicht-konsistenten Aktualität zwischen XML-Schemata und der Dokumentation. An dieser Stelle setzt der XGenerator 2.0 an: Die zu erstellenden o.g. Projektergebnisse werden aus einem vorab erstellten Fachmodell abgeleitet. Somit können Änderungen am Fachmodell durch den Einsatz des XGenerators in die XML-Schemata bzw. Dokumentation konsistent und ohne größeren Anpassungsaufwand übernommen werden. Dieses Dokument soll den Benutzer des Werkzeuges XGenerator 2.0 bei der Inbetriebnahme und Anwendung des Tools unterstützen. In diesem Kapitel wird der XGenerator 2.0 in seinem Kontext und mit seiner Funktionsweise beschrieben. Das 2. Kapitel erläutert, wie das Tool in Betrieb genommen werden kann. Im darauffolgenden Kapitel wird die Benutzung der Clientanwendung XGenerator mittels Benutzeroberfläche beschrieben. Dabei wird bereits auf Fehlerquellen und meldungen eingegangen, die im 4. Kapitel kurz zusammengefasst werden. Im abschließenden 5. Kapitel gibt es Hinweise für die Template-Entwicklung. 1.1 Kontext Ein XÖV-Standard beschreibt für jeweils einen Bereich der öffentlichen Verwaltung, welche Informationen wann in welchen Vorgängen zwischen und mit Behörden ausgetauscht werden können. Verfahrenshersteller können, ausgehend von einem solchen XÖV-Standard, Lösungen für die öffentliche Verwaltung anbieten und implementieren, die ein öffentlich zugängliches und für den gesamten Verwaltungsbereich gültiges und aktuelles Datenschema verwenden und integrieren. Dies vermeidet redundante Mehrfachentwicklungen und versetzt die einzelnen Seite 7

8 Verfahren in die Lage, semantisch miteinander kommunizieren zu können. Sollen beispielsweise Fachverfahren aufgrund einer gesetzlichen Änderung ab einem bestimmten Datum miteinander Daten austauschen können wie beim Meldewesen, so ist ein XÖV-Standard Voraussetzung für eine funktionierende, schnelle und kostenminimale Implementierung der Daten-Schnittstellen. Ein XÖV-Standard beinhaltet grundsätzlich neben einer textuellen Beschreibung (z.b. in Form eines PDF-Dokuments) eine Reihe von XML-Schema-Dateien, welche die zu übertragenden Daten auf XML-Basis beschreiben. Die Grundidee des XGenerators liegt in dem Ansatz, dass die Entwicklung eines Standards in und an einem Fachmodell erfolgt, also auf einer fachlichen Ebene. Die Übersetzung in die XML-Schemadateien und Dokumentationen erfolgt dann durch den XGenerator. Beispiele für XÖV-Standards sind für das Meldewesen, XBau für das Bauwesen, XJustiz für den elektronischen Rechtsverkehr oder XDomea für die Vorgangsbearbeitung von Dokumenten und Akten in der Öffentlichen Verwaltung. Diese Standards werden in Projekten entwickelt, die sich mit der Deutschland-Online-Initiative abstimmen ( XÖV- Projekte ). Mit dem XGenerator 2.0 ist ein Werkzeug entwickelt worden, mit dessen Hilfe XÖV- Projekte beim Erstellen von XÖV-Standards in der beschriebenen Weise an zwei Stellen unterstützt werden können. o Das Werkzeug validiert Fachmodelle gegen angewandte Profile. In diesen werden Regeln hinterlegt, die bei der Erstellung von XML-Schema-Dateien zu beachten sind oder Vorgaben, wie zum Beispiel gesetzte Datenelemente die sogenannten Kernkomponenten - zu verwenden sind. o Das Werkzeug generiert die XML-Schema- und die Dokumentationsdateien aus dem Fachmodell automatisch und wiederholbar. Die Ergebnisse werden qualitätsgesichert bereitgestellt. Folgende Abbildung 1 illustriert diesen Zusammenhang: Seite 8

9 Abbildung 1: Modelle, Profile, XÖV-Standards und der XGenerator Das Werkzeug soll damit ein möglichst einheitliches Vorgehen in den verschiedenen XÖV-Projekten fördern. 1.2 Voraussetzungen zur Verwendung des XGenerators Voraussetzung für den Einsatz des XGenerators 2.0 ist die Erstellung eines Fachmodells in UML 2. Dies geschieht unter der Nutzung eines UML-CASE-Tools. Der Import des Modells in den XGenerator geschieht gegenwärtig über XMI, ausdrücklich unterstützt wird das Tool MagicDraw UML, Version Um den XGenerator zu verwenden, sollte ein Anwender fundierte Kenntnisse in der UML-Modellierung mittels eines UML-CASE-Tools haben. Neben dem Fachmodell werden Dateien benötigt, die folgendes bereitstellen: XÖV-UML-Profil, welches u. a. Stereotypen beinhaltet, die beschreiben, wie aus dem UML-Fachmodell die Dokumentation und die XML-Schemata abzuleiten sind, CoreComponents-Profil, welches beschreibt, wie konkrete Fachkomponenten aus allgemeinen Kernkomponenten abzuleiten sind, Template, welches die XML-Schema- und Dokumentationsgenerierung steuert. Diese Dateien werden mit dem XGenerator mitgeliefert. Kenntnisse über die beiden Profile sind notwendig und bei der UML-Modellierung zu berücksichtigen. Seite 9

10 1.3 Der XGenerator Die XÖV-Spezifikation lässt sich im Wesentlichen aus dem Fachmodell ableiten. Dies wird vom XGenerator 2.0 unterstützt: er generiert aus dem UML Fachmodell die Schema-Dateien und Teile der Dokumentation in Form von DocBook-Dateien und SVG-Dateien für die grafische Dokumentation von Schema-Elementen. Aus DocBook und SVG kann dann bspw. mit Hilfe des Werkzeugs Adobe FrameMaker ein PDF erzeugt werden. Um im Fachmodell die notwendigen Zusatzinformationen zur Datenübertragung mit XML abzulegen, wird das Fachmodell mit dem XÖV-UML-Profil profiliert. Diese Zusatzinformationen, im Fachmodell dargestellt durch Stereotypen, sind technische Details für die Erzeugung von Schemata bzw. Dokumentation, die vom XGenerator ausgelesen und in die Generierung einbezogen werden. Die Generierung der XÖV-Spezifikation kann in jedem XÖV-Projekt ein wenig anders aussehen (z.b. andere Konventionen in den XML-Schema-Dateien, anderer Aufbau der Dokumentation). Der XGenerator unterstützt diese Anforderung, indem die Generierung durch Transformations-Templates gesteuert wird, die je nach Projekt variiert werden können. Das XÖV-Profil definiert darüber hinaus bestimmte Regeln, die festlegen, wie die Stereotypen aus dem Profil anzuwenden sind. Der XGenerator validiert das Fachmodell gegen diese Regeln. Bei einem Verstoß wird keine Generierung durchgeführt. Stattdessen wird der Modellierer darüber informiert, welche Teile des Fachmodells gegen welche Regeln aus dem UML-Profil verstoßen. Im Allgemeinen können mit dem Tool beliebige Profile verwendet werden, denn das XÖV-UML-Profil ist nicht fest im XGenerator verortet. Die folgende Abbildung illustriert den XGenerator im beschriebenen Kontext. Abbildung 2: Der XGenerator im Kontext Seite 10

11 2 Inbetriebnahme 2.1 Technische Voraussetzungen Die technischen Voraussetzungen zur Inbetriebnahme des XGenerators beschränken sich auf die in der unten stehenden Tabelle angegebenen Inhalte. Voraussetzung bzgl. Betriebssystem Weitere Software Hardware Windows, Linux Java ab Version 1.5 (Java 5) muss installiert sein Arbeitsplatzrechner, 1 GB RAM, keine Netzwerkverbindung notwendig 2.2 Installation des Tools Der XGenerator 2.0 wird als Produkt für die Betriebssysteme Windows bzw. Linux aus der Eclipse-Entwicklungsumgebung heraus als jeweils eigenes Produktverzeichnis erstellt (Details siehe Technische Dokumentation). Dieses Verzeichnis wird für die Inbetriebnahme des Tools von einer Installations-CD bzw. von einer Website auf die lokale Festplatte übertragen. Betriebssystem Produktverzeichnis xgenerator-verzeichnis Linux Rootverzeichnis: linux.gtk.x86 Startroutine im Verzeichnis: eclipse Windows Rootverzeichnis: win32.win32.x86 Startroutine im Verzeichnis eclipse: eclipse.exe Mit der Ausführung der Startroutine xgenerator.exe bzw. xgenerator aus dem gleichnamigen Verzeichnis kann der XGenerator mit Benutzeroberfläche gestartet werden. 2.3 Input-Verzeichnisstruktur Vorbereiten eines Projektes Bevor ein Projekt mit dem XGenerator 2.0 geöffnet bzw. bearbeitet werden kann, muss ein Projektverzeichnis (z. B. XBeispiel ) angelegt sein, welches mindestens die beiden Unterverzeichnisse templates und model enthält. Die Namen dieser Seite 11

12 beiden Unterverzeichnisse werden genau so vom XGenerator benötigt, sind also fix. Wo das Projektverzeichnis angelegt wird, ist für ein neues Projekt beliebig. Abbildung 3: Verzeichnisstruktur für Input Zusätzlich können auch weitere Unterverzeichnisse angelegt werden, die für das Projekt, aber nicht für die Anwendung des XGenerators von Bedeutung sind. Sollen mehrere Projekte mit dem XGenerator bearbeitet werden können, so muss für jedes Projekt ein separates Projektverzeichnis angelegt werden, mit jeweils einem eigenen model- und templates-ordner, auch wenn es ggf. projektübergreifend in diesen Unterverzeichnissen redundante Dateien gibt Verzeichnis model Das model-verzeichnis enthält alle Inputfiles für den XGenerator. Das sind einerseits die Dateien, die unmittelbar mit dem UML-Fachmodell und den angewandten UML- Profilen zusammenhängen (aus dem UML-Case-Tool exportiert), und andererseits die im XGenerator benötigten Dateien zur Profilvalidierung bzw. Templateauswertung des Modells. Darüber hinaus können in diesem Verzeichnis auch für Schemata bzw. DocBook benötigte Codelisten in einem separaten Unterverzeichnis codelists abgelegt. Die folgenden Tabellen und Beschreibungen erläutern detailliert, welche Dateien für ein XÖV-Projekt vom XGenerator benötigt und eingelesen werden. UML-Fachmodell und Profile im Format EMF-XMI Datei- bzw. Verzeichnisname Inhalt und Verwendung Quelle XBeispiel.uml2 *.profile.uml2 UML_Standard_Profile.MagicDraw_ Profile.profile.uml2 UML_Standard_Profile.UML_Standa rd_profile.profile.uml2 UML-Fachmodell hier von XBeispiel Im XBespiel genutzte weitere Profile UML-Standardprofil vom CASE-Tool MagicDraw (wird beim Export mit generiert, aber nicht für XÖV benötigt) UML-Standard-Profil (wird beim Export mit generiert, aber nicht für XÖV benötigt) Alle Dateien (Modell und angewandte Profile) werden zusammen bei einem EMF-XMI-Export von MagicDraw 12.5 erzeugt Der XGenerator 2.0 kann UML2.0-Modelle und -Profile einlesen, die das Format EMF-XMI (XMI 2.0) haben. Diese werden vom dem Case-Tool MagicDraw in der Version 11.5,12.1 und 12.5 erzeugt. Es ist darauf zu achten, dass der model-ordner nur ein Fachmodell mit zugehörigen Profilen enthält. Bei einem erneuten Export eines UML-Modells aus MagicDraw muss dieses gemeinsam mit den beim Export aktuell generierten Profilen in den model- Seite 12

13 Ordner eingestellt werden und alte Modell- bzw. Profildateien sollten gelöscht bzw. überschrieben werden. Bereits enthaltene Profile von einem früheren Export können für ein neu exportiertes Modell nicht genutzt werden, da MagicDraw interne Referenzen zwischen Modell und Profilen erzeugt, die sich bei jedem Export ändern. Alte Profile führen zu Fehlermeldungen im XGenerator Neben den hier genannten Profilen kann der XGenerator auch Modelle mit anderen Profilen einlesen, z.b. das Profil für Kernkomponenten der UN/CEFACT, wie es von der AG Datenkonferenz genutzt wird. (Hinweis: Besteht Bedarf neue Profile zu verwenden, so ist bei der Nutzung von MagicDraw darauf zu achten, dass diese nicht versehentlich als Modell oder Paket angelegt werden. Bei letzteren führt das zu Problemen beim Einlesen der Modelle.) Datei- bzw. Verzeichnisname für XÖV-Profil und Templateverabeitung templates.operations cc.profile.invariants xoev_cc.invariants XOEV-Profil-V1.1.invariants cc.profile.operations xoev_cc.operations XOEV-Profil-V1.1.operations Inhalt und Verwendung Operations (OCL-Aufrufe) die in den Velocity Templates verwendet werden, zur Wiederverwendung für weitere Templates gedacht Profilinvariante zur Profilvalidierung des Modells im XGenerator als Teil des CC Profils Profilinvariante zur Profilvalidierung des Modells im XGenerator, welches Regeln enthält, die aus dem Zusammenspiel von XÖV und CC Profil notwendig werden Profilinvariante zur Profilvalidierung des Modells im XGenerator als Teil des XÖV Profils Hilfsunktionen, bezogen auf das CC Profil Hilfsunktionen, bezogen auf das XÖV und CC Profil Hilfsunktionen, bezogen auf das XÖV Profil Diese Tabelle verweist auf die für die Profilvalidierung benötigten Invarianten (Constraints) und Dateien mit OCL-Befehlen, wie sie für die Definition der Invarianten bzw. für die Templates verwendet werden. Verzeichnis Datei- bzw.verzeichnisname Inhalt und Verwendung Quelle codelists Verzeichnis enthält projektrelevante Codelisten / Schlüsseltabellen in Form vom XML-Schema, die für die Einbindung in Schemata bzw. DocBook genutzt werden können Manuell bzw. mittels Datenbank erzeugte Dateien Alle diese Dateien (*.operations, *.invariants und Codelisten) müssen einem Schema genügen. Durch die Eintragung des namespaces in diese Dateien erkennt der XGenerator die Schemata, auch ohne eine online-verbindung, da diese Seite 13

14 Schemata zusätzlich in das Tool integriert wurden. Detaillierte Informationen zu Inhalt und Struktur dieser Dateien finden sich in Anhang A Verzeichnis templates Bei der Erzeugung von XML-Schemata, DocBook-Dateien oder ggf. auch anderen Output-Dateien arbeitet der XGenerator 2.0 mit Template-Dateien. Die Templates sind in der Sprache Velocity (Dateiendung *.vm) erstellt und enthalten OCL-Aufrufe, wie sie in der Datei templates.operations bzw. auch XOEV- Profil.profile.operations aus dem model-verzeichnis definiert wurden, zur Navigation und Auswertung der Modelle. Die benötigten Templates zur XML-Schema- bzw. DocBook-Generierung müssen vor der Bearbeitung eines Projektes erstellt sein und sind in den Unterverzeichnissen xsd bzw. docbook abzulegen. Abbildung 4: Verzeichnis "templates" Die Auslieferung des XGenerators 2.0 erfolgte mit einem Satz Velocity-Templates für die Erzeugung von XML-Schemata und DocBook für das Beispielmodell XBeispiel. Diese Templates werden zusammen mit dem Tool zur Verfügung gestellt und können als Vorlage für die eigene projektspezifische Template-Entwicklung genutzt werden. Die Templates zur Schema-Generierung sind bereits sehr generisch und können in der bestehenden Form genutzt werden. 2.4 Internationalisierung Die Oberfläche des XGenerators kann sowohl in englischer als auch deutscher Sprache genutzt werden. Die Spracheinstellung ist an die Spracheinstellung des Betriebssystems gebunden. Seite 14

15 3 Anwendung des Tools mit Benutzeroberfläche Nach der Inbetriebnahme des XGenerators und den Vorbereitungen für ein Projekt (Fachmodell), wie im obigen Kapitel beschrieben, kann die Bearbeitung eines Projektes beginnen. 3.1 Starten des Tools Wie bereits in Abschnitt 2.2 beschrieben, wird das Tool mit dem Aufruf der xgenerator-datei (xgenerator.exe bzw. xgenerator) gestartet. Nach dem Splashscreen öffnet sich direkt die Benutzeroberfläche des Tools. Abbildung 5: Benutzeroberfläche 3.2 Projekte verwalten Unter dem Menüpunkt Verwalten im Menü Projekt öffnet sich ein Dialog Seite 15

16 mit dem Projekte o erstellt, o geöffnet, o gewechselt oder o gelöscht werden können. Hinweis: Die Meta-Informationen, welche Projekte wie geöffnet bzw. bearbeitet wurden, werden in einem neu generierten Unterverzeichnis des Produktverzeichnisses (siehe Abschnitt 2.2) gespeichert. Kommentar [bn1]: Gibt es da eine Namenskonvention? Wie heisst das Unterverzeichnis? Im Fall einer Fehlermeldung bzgl. hier enthaltener Dateien, kann das Workspace- Verzeichnis gelöscht werden. Die Projekte müssen danach nur erneut im XGenerator, wie im folgenden Abschnitt beschrieben, erstellt werden. Änderungen bzgl. der Generierung von Dateien gehen nicht verloren und werden beim Öffnen des Projektes wie zuvor angezeigt. Kommentar [C. S.2]: Sollte in einen extra Absatz verschoben werden Projekt erstellen Ein neues Projekt kann erstellt werden, wenn es zuvor wie in Abschnitt 2.3 beschrieben vorbereitet wurde. Bei Klick auf den Button Erstellen öffnet sich ein weiterer Dialog. Seite 16

17 Unter Projektname kann ein frei wählbarer Name (z. B. XBeispiel ) eingetragen werden, der dann in der Oberfläche angezeigt wird. Als Projektverzeichnis wird das wie in 2.3 eingerichtete Projektverzeichnis ausgewählt. Ein Projektverzeichnis kann nur für ein Projekt verwendet werden. Nach Auswahl des Projektverzeichnisses werden unter Modell die XMI-Dateien (*.uml) des model-ordners angezeigt. Diese beziehen sich, wie in Abschnitt erläutert, auf das UML-Modell und die Profile. Existiert in dem ausgewählten Projektverzeichnis kein Unterordner model, so bleibt die Auswahl unter Modell inaktiv. Seite 17

18 Aus den unter Modell angezeigten Dateien wird das eigentliche Fachmodell ausgewählt. Nach Betätigen des Buttons Fertig stellen ist das Projekt erstellt und kann mit OK geöffnet werden. Seite 18

19 In der Oberfläche des XGenerators wird das vorbereitete Projekt mit Namen und als Dateibaum mit allen vorbereiteten Unterverzeichnissen des Projektordners angezeigt. In diesem Dateibaum kann navigiert und die ausgewählten Dateien mit ihren Programmen-zugeordneten Endungen geöffnet werden Projekt öffnen und wechseln Bereits einmal erstellte Projekte können über den Dialog unter dem Menüpunkt Verwalten direkt wieder geöffnet bzw. auch gewechselt werden, wenn bereits mehrere Projekte eingerichtet wurden. Nach Klick auf OK öffnet sich das ausgewählte Projekt im XGenerator Projekt löschen Über denselben Verwaltungsdialog können ausgewählte Projekt mit einem Klick auf Löschen entfernt werden. Seite 19

20 Ein Projekt zu löschen bedeutet, es aus dem Workspace, d.h. aus der Anzeige des XGenerators zu löschen. Physisch bleiben die Dateien im Dateisystem erhalten. 3.3 Arbeiten mit dem Tool Nachdem ein Projekt im XGenerator geöffnet wurde, kann das UML-Modell gegen das angewandte Profil validiert werden bzw. können die Schema- bzw. DocBook-Dateien generiert werden. Welche dieser Arbeitsschritte vom Tool ausgeführt werden sollen, wird über eine Auswahlbox gesteuert. Nach Auswahl eines Modus, z.b. Validation & XSD, wird nach Klick auf den Button Aktualisieren der Validierungs- und Generierungsprozess angestoßen. Der Prozess wird sequentiell gemäß der Vorgabe in der Auswahlbox abgearbeitet. Seite 20

21 Der angestoßene Prozess kann über Abbrechen auf dem Prozessfortschrittsbalken beendet werden. Der Abbruch der laufenden Operation kann jedoch einige Zeit dauern, da das Tool Aufgaben in größeren Blöcken abarbeitet und nur vor Beginn der nächsten Teilaufgabe die Benutzereingaben auswertet um gegebenenfalls abzubrechen. Wenn der Unterordner build nicht manuell angelegt wurde, wird dieser beim ersten Bearbeiten eines Projektes (gestartet mit dem Button Aktualisieren ) im Projektverzeichnis erzeugt. Die vom Tool generierten Schema- bzw. DocBook- Dateien werden hier in entsprechende Unterordner xsd bzw. docbook geschrieben. Zusätzlich wird ein aktuelles Protokoll generierung.log in den Build-Ordner geschrieben (Details siehe Abschnitt 3.3.5). Mit dem Button Bereinigen werden die erzeugten XML-Schemata und DocBook- Dateien auch physisch aus dem Dateisystem entfernt. Im angezeigten Dateibaum kann navigiert und die Dateien wie Templates, Schemata usw. können aus dem Dateibaum des XGenerators heraus mit dem, der jeweiligen Dateiendung zugeordneten Programm geöffnet und bearbeitet werden. Die im XGenerator ablaufenden Prozessschritte sind bereits im Abschnitt 1.2 dargestellt. An dieser Stelle sei noch auf einige Details verwiesen. Seite 21

22 3.3.1 Einlesen und Profil-Validierung des Modells Neben dem eigentlichen UML-Modell und dem angewandten Profil werden auch die weiteren, im Verzeichnis model enthaltenen Dateien (siehe Abschnitt 2.3.1) vom XGenerator eingelesen. Nach dem Einlesen der Dateien erfolgt die Validierung des UML-Modells auf die korrekte Anwendung des Profils. Hierzu werden u. a. auch die zuvor aus model eingelesenen Dateien XOEV-Profil.profile.invariants und XOEV- Profil.profile.operations benötigt. Fehler bei der Anwendung des Profils auf das UML-Modell werden durch die Validierung aufgedeckt und vom XGenerator in textueller Form gemeldet (dazu siehe auch 3.3.6). Sie sollen den Anwender befähigen, die Fehler aufzufinden und zu korregieren Generierung und Validierung der XML-Schemata Auf Basis einer erfolgreichen Validierung gegen ein Profil, kann die von den Schema- Templates gesteuerte Generierung der XML-Schemata (*.xsd) erfolgen. Die Schema- und auch die DocBook-Templates arbeiten mit den OCL-Ausdrücken der ebenfalls aus dem Model-Ordner eingelesenen operations-dateien (siehe Abschnitt 2.3.1). Die Ergebnisse werden in das Projektverzeichnis XBeispiel\build\xds geschrieben. Nach der Schema-Generierung wird geprüft, ob die erzeugten Schemata valide sind. Die Prüfung erfolgt auf Basis einer EMF(Eclipse Modelling Framework)-internen Schema-Validierung. Fehler, die bei der Generierung bzw. Validierung festgestellt werden, meldet das Tool ebenfalls Generierung der DocBook-Dateien Nach erfolgreicher Schema-Generierung und -Validierung können, gesteuert über die DocBook-Templates, DocBook-Dateien (*.xml) erzeugt werden. Die vom XGenerator erzeugten DocBook-Fragmente sind xml-dateien, die die zuvor erzeugten Schemata auf Basis des UML-Modells als auch auf Basis der Schemata selbst dokumentieren. Die Ergebnisse werden in das Projektverzeichnis XBeispiel\build\docbook geschrieben. Die Struktur des docbook -Verzeichnisses mit seinen Unterverzeichnissen ergibt sich aus den Festlegungen in den DocBook-Templates. Die erzeugten DocBook-Dateien sind Teil einer Spezifikation, die in der Regel aus weiteren, auf anderen Wegen, z.b. manuell erstellten DocBook-Dateien besteht. Bei der Generierung auftretende Fehler, z.b. durch unkorrekte Anweisungen in den Templates, werden vom XGenerator angezeigt. In diesem Arbeitsschritt der DocBook-Generierung werden auch SVG-Grafiken (*.svg) zur grafischen Dokumentation von Schema-Elementen erzeugt, die auf die bereits zuvor generierten XML-Schemata zugreifen. Seite 22

23 Darstellung von Schema-Elementen als SVG-Grafik Die SVG-Grafiken werden durch einen eigenen Prozessor generiert, der durch die DocBook-Templates angestoßen wird, und haben ein fest vorgegebenes Layout. Die im Folgenden aufgeführten Erläuterungen zu den verwendeten Icons bzw. Beispielen von Grafiken sollen helfen, die allgemeine Darstellung der Schema-Grafiken eindeutig zu interpretieren. Icon Bedeutung XSDAttribute: zeigt an, dass eine Attributdefinition vorliegt (ohne Icon sind Elementdefinitionen dargestellt) XSDSimpleType: zeigt an, dass das Element einen XSD-Basistypen als Datentyp besitzt XSDComplexType: zeigt an, dass der Typ ein komplexer Typ ist XSDSequence: zeigt an, dass eine Sequenz von Elementen und Typen definiert ist Beispiele für SVG-Grafiken Bedeutung Darstellung eines benannten complextype Hier wird deutlich, dass frist ein simpletype und Grund vom Typ Schlüsseltabelle ist. Darstellung einer Extension Das Beispiel zeigt, dass type.meldebehoerde eine Extension von type.behoerde ist. Darstellung einer Restriction Das Beispiel zeigt, dass type.bzst.auskunftssperre eine Restriktion von type.auskunftssperre ist und nur aus dem Element grund besteht Seite 23

24 Beispiele für SVG-Grafiken Bedeutung An dieser Grafik wird die Darstellung der Kardinalität von Elementen deutlich. Elemente ohne Angaben haben genau die Kardinalität 1. Eine abweichende Kardinalität wird separat angegeben, z.b. 1..*, 0..1 oder 0..*. Darstellung eines anonymen Typen Ein anonymer complextype wird aufgeklappt dargestellt, damit seine Elemente erkennbar sind Validierung der DocBook-Dateien Nach der DocBook-Erzeugung findet eine DocBook-Validierung statt. Diese inkludiert auch manuell erzeugte DocBook-Dateien. Die Validierung erfolgt über die Root- DocBook-Datei Spezifikation.xml, die auch den Verweis auf die der Validierung zugrundeliegende DocBook-DTD enthält. Mit der DocBook-Validierung über alle Dateien wird z.b. sichergestellt, dass sämtliche Referenzen über Pfadangaben innerhalb der Dateien korrekt sind. Auftretende Fehler werden auch in diesem Fall vom XGenerator angezeigt. Nach erfolgreicher Validierung können diese DocBook-Dateien in einem, der Verwendung des XGenerators nachgeordneten Prozess für die Erstellung einer Spezifikation z.b. in Form von HTML oder PDF genutzt werden Pfadangaben für die DocBook-Validierung Zur DocBook-Validierung der Spezifikation sind die Originalpfade notwendig. Da in den DocBook-Dateien absolute Pfade verwendet werden, deren Richtigkeit für die Seite 24

25 Validierung entscheidend ist, müssen diese in der Datei global_variables.vm vor der Verwendung des XGenerators eingetragen werden Protokollierung Neben der Anzeige eines Prozessfortschrittsbalkens wird der gesamte Prozessverlauf der Validierung und Generierung vom XGenerator in der Datei build/generierung.log protokolliert und kann (z.b. über Öffnen mit TextPad) synchron verfolgt werden. Bei einem erneuten Prozessdurchlauf wird der bestehende Inhalt der Log-Datei mit den aktuellen Ergebnissen überschrieben, d.h. nur der jeweils letzte Lauf eines Projektes ist hier protokolliert. Die Log-Datei hat einen dem Prozess entsprechenden Aufbau mit folgendem Inhalt: Generiere Projekt 'XBeispiel' Projektordner: C:\...\xbeispiel Startzeit: Name des Projektes Pfadangabe des Projektordners Datum und Startzeit der Validierung und Generierung Teilaufgabe 'model' Angaben zur UML-Profilvalidierung des Modells Teilaufgabe 'xsdgenerator' Teilaufgabe 'xsd' Teilaufgabe 'docbookgenerator' Teilaufgabe 'xml' Endzeit: Auflistung der Namen der generierten XML-Schemata Angaben zur Schema-Validierung Auflistung der Namen der generierten DocBook-Dateien Angaben zur DocBook-Validierung Datum und Endzeit der Validierung und Generierung Treten im Verlauf des Prozesses Fehler auf, wird im entsprechenden Teilprozess (Teilaufgabe) und am Ende des Protokolls allgemein darauf hingewiesen. Im Verzeichnis./xgenerator des Produktverzeichnisses (Windows- oder Linux- Version) gibt es eine Datei xgenerator0.log, die technisch detaillierter auflistet, welche Tasks/Teilaufgaben bei einem Durchlauf des XGenerators abgearbeitet wurden bzw. welche Fehler aufgetreten sind. Diese Datei wird fortlaufend weitergeschrieben und kann für Zwecke der Fehleranalyse genutzt werden. Im Falle, Seite 25

26 dass diese Datei zu viel Speicherplatz beansprucht, kann sie problemlos manuell gelöscht werden. Bei einem weiteren Durchlauf wird diese Datei neu generiert Fehlermeldungen Detaillierte Fehlermeldungen werden wie oben bereits erwähnt vom XGenerator selbst angezeigt. Kommt es im Prozess des Einlesens, Validierens oder Generierens zu Fehlern, wird der Prozess an dieser Stelle abgebrochen und detaillierte textuelle Fehlermeldungen mit Angaben zur Datei, in der der Fehler auftritt, werden in dem separaten Problemfenster des XGenerators ausgegeben. Nach dem Korrigieren der Fehler, z.b. durch Bereitstellen eines korregierten Modells oder Änderungen an Templates, kann mit dem Button Aktualisieren der Prozess fortgesetzt bzw. neu gestartet werden. Seite 26

27 4 Fehlerbehandlung Im Dokument gibt es in den einzelnen Abschnitten bereits Hinweise zu vermeidbaren Fehlerursachen, wie z.b. beim Anlegen eines Projektes (siehe Abschnitt 2.3) bzw. bei Fehlern in den Input-Dateien (model und profiles) selbst. Diese Fehler werden vom XGenerator gemeldet. Im Abschnitt ist beschrieben, wo und wie solche Fehler vom Tool selbst ausgegeben werden. In diesem Abschnitt soll noch einmal kurz zusammenfassend auf evtl. Fehlerquellen hingewiesen werden, die vor allem bei der Bereitstellung der einzulesenden Dateien auftreten können. Außerdem ist danach ein kurzer Abschnitt bzgl. evtl. Fehlermeldungen, die dass Tool selbst betreffen, eingefügt. 4.1 Input-Dateien Besteht Bedarf neue Profile zu verwenden, so ist bei der Nutzung von MagicDraw darauf zu achten, dass diese Profile auch als Profile angelegt werden und nicht versehentlich als Modell oder Paket. Bei den beiden letzteren führt das zu Problemen beim Einlesen der Modelle und der verwendeten Profile in den XGenerator. Es ist darauf zu achten, dass der model-ordner nur ein Fachmodell mit zugehörigen Profilen enthält. Bei einem erneuten Export eines UML-Modells aus MagicDraw muss dieses gemeinsam mit den beim Export aktuell generierten Profilen in den model- Ordner eingestellt werden und alte Modell- bzw. Profildateien sollten gelöscht werden. Bereits enthaltene Profile von einem früheren Export können für ein neu exportiertes Modell nicht genutzt werden, da MagicDraw interne Referenzen zwischen Modell und Profilen erzeugt, die sich bei jedem Export ändern. Alte Profile werden also nicht eingelesen und führen zu Fehlermeldungen im XGenerator. Alle diese Dateien (*.operations, *.invariants und Codelisten) müssen einem Schema genügen. Durch die Eintragung des namespaces in diese Dateien erkennt der XGenerator die Schemata, auch ohne eine online-verbindung, da diese Schemata zusätzlich in das Tool integriert wurden. Bevor ein Projekt vollständig mit dem XGenerator bearbeitet werden kann, muss sichergestellt sein, dass die Entwicklung der Template-Dateien beendet ist, als auch die Definitionen in den *.opertions und *.invariants Dateien fehlerfrei sind. Fehler in diesen Dateien werden bei einem Prozessdurchlauf aber ebenfalls von XGenerator gemeldet. 4.2 Sessionhandling Fehlermeldungen, die über die Ausführungen in Abschnitt hinausgehen und sich auf eine konkrete Session mit dem XGenerator beziehen, finden sich in detaillierter Form in dem fortgeschriebenen Logfile.log im Unterverzeichnis \workspace\.metadata des Produktverzeichnisses des XGenerators. Seite 27

28 Im Fall einer Fehlermeldung bzgl. hier enthaltener Dateien kann das Workspace- Verzeichnis auch gelöscht werden. Die Projekte müssen danach zwar erneut im XGenerator, wie in Abschnitt beschrieben, erstellt werden. Änderungen bzgl. der Generierung von Dateien bleiben jedoch im Dateisystem erhalten und werden beim Öffnen des Projektes wie zuvor angezeigt. Seite 28

29 Anhang A Aufbau der Eingabedateien.invariants,.operations, Codelisten Damit die im Folgenden beschriebenen Eingabedateien vom XGenerator als valide Dateien interpretiert werden, werden sie beim Einlesen jeweils gegen ein Schema geprüft, dass selbst Bestandteil des XGenerators ist. Über den angegebenen namespace in den Dateien kennt der XGenerator beim Einlesen die zugehörige schema location und findet das zugehörige Schema. Auf diese Weise kann der XGenerator auch offline genutzt werden. Mit der Angabe von namespace und schema location in den Dateien selbst können theoretisch auch lokale oder weitere online verfügbare Schemata genutzt werden. Hierfür besteht aber keine Notwendigkeit. A.1 Die.invariants-Dateien Diese Dateien enthalten die OCL-Well-formedness Rules (=Invarianten) für das/die anzuwendende(n) Profile(e). Alle.invariants-Dateien, die sich im model-verzeichnis des XGenerator-Projekts befinden, werden automatisch mit geladen. Jede invariants-datei besteht zwingend aus einem <invariants>-wurzelelement: <?xml version='1.0' encoding='iso '?> <invariants xmlns=" </invariants> Der Namespace ist dabei relevant und wie oben zu setzen. In dem Wurzelelement können beliebig viele <invariant>-elemente enthalten sein. Jedes <invariant>- Element definiert genau eine Well-formedness Rule. Dabei sind die XML-Attribute 'context' (die Metaklasse, auf die sich diese Regel bezieht) und 'name' (der Name dieser Regel) zwingend anzugeben. Als Unterelemente von <invariant> sind ein <body>-element (die OCL-Definition der Invariante) und ein optionales <documentation>-element anzugeben. Die Dokumentation wird, falls vorhanden, im XGenerator mit angezeigt. Der OCL- Ausdruck im <body>-element muss ein boolscher Ausdruck sein. Beispiel für eine Invariante: <invariant context='property' name='elementsmusthaveseqno'> <body> self.extension_xsdelement.isdefined implies Seite 29

30 self.extension_xsdelement.seqno.isdefined </body> <documentation> Eigenschaften, die als «xsdelement» stereotypisiert sind, müssen einen seqno-wert besitzen. </documentation> </invariant> Die folgende XML-Schema-Datei invariants.xsd für.invariants-dateien ist Bestandteil des XGenerators und wird von ihm zur Validierung der Dateien genutzt. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" <xs:element name="invariants"> <xs:complextype> <xs:sequence> <xs:element maxoccurs="unbounded" minoccurs="0" name="invariant"> <xs:complextype> <xs:sequence> <xs:element maxoccurs="1" minoccurs="1" name="body"/> <xs:element maxoccurs="1" minoccurs="0" name="documentation"/> </xs:sequence> <xs:attribute name="context" type="xs:string" use="required"/> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Seite 30

31 A.2 Die.operations-Dateien Diese Dateien enthalten die Zusatzinformationen, die im Rahmen der angewandten Profile für die UML-Metaklassen und die Stereotypklassen definiert werden sollen. Diese Hilfsoperationen sind damit an allen Stellen, an denen OCL ausgewertet wird, verfügbar. Alle.operations-Dateien, die sich im model-verzeichnis des XGenerator- Projekts befinden, werden automatisch mit geladen. Jede operations-datei besteht zwingend aus einem <additionaloperations>- Wurzelelement: <?xml version="1.0" encoding="iso "?> <additionaloperations xmlns=" Der Namespace ist dabei relevant und wie oben zu setzen. In dem Wurzelelement können beliebig viele <additionaloperation>-elemente enthalten sein. Jedes <additionaloperation>-element definiert eine Operation. Dabei sind die XML- Attribute 'context' (die Metaklasse, für die die Operation definiert werden soll) und 'name' (der Name der Operation) zwingend anzugeben. Als Unterelemente sind ein <result>-element mit dem OCL-Rückgabetyp der Operation ('type'-attribut) und, wie bei den Invarianten, ein <body>-element und ein optionales <documentation>- Element anzugeben. <operation context='element' name='hlpowningpackage'> <result type='package'/> <body> if self.owner.oclistypeof(class) then self.owner.hlpowningpackage() else self.owner.oclastype(package) endif </body> <documentation> Das Paket, in welchem dieses Element enthalten ist. Bei Elementen in inneren Klassen wird aufsteigend nach einem Paket gesucht. Seite 31

32 </documentation> </operation> Die folgende XML-Schema-Datei operations.xsd für.operations-dateien ist Bestandteil des XGenerators und wird von ihm zur Validierung der Dateien genutzt. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" <xs:element name="additionaloperations"> <xs:complextype> <xs:sequence> <xs:element maxoccurs="unbounded" minoccurs="0" name="operation"> <xs:complextype> <xs:sequence> <xs:element maxoccurs="1" minoccurs="1" name="result"> <xs:complextype> <xs:attribute name="type" type="xs:string"/> </xs:complextype> </xs:element> <xs:element maxoccurs="1" minoccurs="0" name="param"/> <xs:element maxoccurs="1" minoccurs="1" name="body"/> <xs:element maxoccurs="1" minoccurs="0" name="documentation"/> </xs:sequence> <xs:attribute name="context" type="xs:string" use="required"/> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Seite 32

33 A.3 Die Codelisten Die Code-List-Dateien befinden sich in model/codelists. Jede Code-List-Datei definiert die Menge der Codes für genau eine Code-List-Klasse. Die Codes aus jeder Datei stehen in der OCL-Auswertung als Objekte der Klasse Code zur Verfügung und können über Code.allInstances iteriert werden. Die Struktur der Code-List-Dateien wurde von der OSCI-Leitstelle vorgeschlagen und ist konform zum gleichnamigen UN/CEFACT-CoreComponents-Konzept. Jede Code-List-Datei besteht aus genau einem <codelist>-element, welches für den XGenerator zwingend den CodeListUniformResourceIdentifier enthält. Dieser Identifier stellt die Verbindung zwischen der Klasse im UML-Modell und den Codes in dieser Datei her. Optional können die weiteren Attribute der UN/CEFACT- Code-Klasse noch einmal wiederholt werden. Die genaue Beschreibung der einzelnen Attribute findet sich in der XML-Schema-Datei für die Code-Listen. Innerhalb des <codelist>-element befinden sich beliebig viele <entry>-elemente, die die möglichen Ausprägungen dieses Code-Typs definieren. Pro <entry> sind die Attribute 'content' und 'codename' (optional) anzugeben. Diese Werte sind über OCL aus den Instanzen der Code-Klasse abzufragen. Insgesamt sind damit auf OCL-Ebene die Attribute Code.Content, Code.CodeName und Code.CodeListUniformResourceIdentifier definiert. Letzter kann benutzt werden, um alle Codes einer Liste abzufragen. Die folgende XML-Schema-Datei codelist.xsd für die Code-Listen-Dateien ist Bestandteil des XGenerators und wird von ihm zur Validierung der Dateien genutzt. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:codelist=" xmlns:xs=" attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" version=" "> <!--Datentypen und Elemente zur Definition von Codelisten (Schlüsseltabellen) analog UN/CEFACT (C) OSCI Leitstelle Bremen, > <xs:attributegroup name="codelistattributegroup"> <xs:annotation> <xs:documentation>die Liste der Attribute, die den Codes gemeinsam ist, die der gleichen Codeliste zugehören</xs:documentation> </xs:annotation> <xs:attribute name="codelistidentifier" type="xs:nmtoken" use="required"> <xs:annotation> Seite 33

34 <xs:documentation>kann den Namen der Code-Liste beinhalten, über den diese im Bereich der herausgebenden Agentur eindeutig identifiziert wird (z.b. ISO )</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="codelistagencyname" type="xs:normalizedstring" use="optional"> <xs:annotation> <xs:documentation>kann den Namen der Agentur beihalten, die die Code-Liste herausgibt und pflegt (z.b. "International Organization for Standardization")</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="codelistversionidentifier" type="xs:nmtoken" use="optional"> <xs:annotation> <xs:documentation>kann die benutzte Version der Code-Liste beinhalten (z.b. "1997")</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="codelistname" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>kann den Namen der Code-Liste beihalten (z.b. ISO Country Code)</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="codelistuniformresourceidentifier" type="xs:normalizedstring" use="optional"> <xs:annotation> <xs:documentation>kann die URL der eigentlichen Code-Liste beihalten (z.b. </xs:annotation> </xs:attribute> Seite 34

35 <xs:attribute name="codelistschemeuniformresourceidentifier" type="xs:normalizedstring" use="optional"> <xs:annotation> <xs:documentation>kann die URL des Schemas der Code-Liste beinhalten (z.b. </xs:annotation> </xs:attribute> <xs:attribute name="codelistagencyidentifier" type="xs:name" use="optional"> <xs:annotation> <xs:documentation>kann einen eindeutigen Identifizierer der herausgebenden Agentur auf Basis der UN/CEFACT Code-Liste 3055 (Code-Liste für Herausgeber von Code-Listen) beinhalten (z.b. 5 = ISO (International Organization for Standardization))</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="languageidentifier" type="xs:name" use="optional"> <xs:annotation> <xs:documentation>kann einen eindeutigen Identifizierer der für den Code verwendeten Sprache auf Basis von ISO 639:1998 (Code-Liste für Sprachen) beinhalten.</xs:documentation> </xs:annotation> </xs:attribute> </xs:attributegroup> <xs:attributegroup name="codeattributegroup"> <xs:annotation> <xs:documentation>die Liste der Attribute, die pro Element einer Codeliste spezifisch sind</xs:documentation> </xs:annotation> <xs:attribute name="content" type="xs:string" use="required"> <xs:annotation> <xs:documentation>der eigentliche Code (der Schlüssel) in einer Schlüsseltabelle, also z. B. der Wert 'w' in der Schlüsseltabelle der Geschlechter.</xs:documentation> Seite 35

36 </xs:annotation> </xs:attribute> <xs:attribute name="codename" type="xs:normalizedstring" use="optional"> <xs:annotation> <xs:documentation>der zu einem Code gehörige Wert (die Semantik des Schlüssels), also z. B. 'weiblich' als Semantik des Schlüssels 'w' in der Schlüsseltabelle der Geschlechter.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="sorter" type="xs:nmtoken" use="optional"> <xs:annotation> <xs:documentation>dieses Attribut kann genutzt werden, um Tabelleneinträge innerhalbder Tabelle in einer gewünschten Reihenfolge zu sortieren.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="remark" type="xs:normalizedstring" use="optional"> <xs:annotation> <xs:documentation>eine beliebige Bemerkung zu diesem Schlüssel.</xs:documentation> </xs:annotation> </xs:attribute> </xs:attributegroup> <xs:complextype name="tcode"> <xs:annotation> <xs:documentation>der Datentyp für Tabelleneinträge (Schlüssel, Wert, ggfs. Hinweis)</xs:documentation> </xs:annotation> <xs:attributegroup ref="codelist:codeattributegroup"/> </xs:complextype> <xs:complextype name="tcodelist"> <xs:annotation> Seite 36

37 <xs:documentation>der Datentyp für eine Codeliste (Schlüsseltabelle)</xs:documentation> </xs:annotation> <xs:sequence> <xs:element maxoccurs="unbounded" minoccurs="0" name="entry" type="codelist:tcode"> <xs:annotation> <xs:documentation>die für diese Tabelle definierten Werte</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:attributegroup ref="codelist:codelistattributegroup"/> <xs:attribute name="remark" type="xs:normalizedstring" use="optional"/> </xs:complextype> <xs:complextype name="tcodelistset"> <xs:annotation> <xs:documentation>der Datentyp für eine Menge von Codelisten (Schlüsseltabellen)</xs:documentation> </xs:annotation> <xs:sequence> <xs:element maxoccurs="unbounded" minoccurs="0" name="codelist" type="codelist:tcodelist"/> </xs:sequence> </xs:complextype> <xs:element name="codelist" type="codelist:tcodelist"> <xs:annotation> <xs:documentation>ein globales Element vom Typ Codelist</xs:documentation> </xs:annotation> </xs:element> </xs:schema> Seite 37

38 Anhang B Glossar und Abkürzungsverzeichnis API DocBook DOL EMF EPL GEF GUI JavaDoc MOF OCL OMG RCP SVG TZI UML Velocity XÖV XSD Application Programming Interface OASIS-Standard für ein XML-basiertes Dokumentenaustauschformat Deutschland Online Eclipse Modelling Framework; Open-Source Java-Framework zur automatisierten Erzeugung von Quelltext anhand von strukturierten Modellen Eclipse Public License Grafisches Editor Framework Graphical User Interface (Grafische Benutzeroberfläche) Software-Dokumentationswerkzeug, das aus Java-Quelltexten automatisch HTML-Dokumentationsdateien erstellt. Meta Object Facility; spezielle Metadaten-Architektur der OMG Object Constraint Language; ein Bestandteil von UML Object Management Group Rich Client Platform, ein Framework des Eclipse-Projektes zur Entwicklung von Java Anwendungen Scalable Vector Graphics Standard zur XML konformen Beschreibung zweidimensionaler Vektorgrafiken Technologie Zentrum Informatik; Einrichtung an der Universität Bremen Unified Modeling Language; Von der OMG entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen. Open-Source Template Prozessor der Apache Software Foundation XML-basierte fachliche Standards in der öffentlichen Verwaltung ; ein Überbegriff für die Standardisierung von Kommunikationsschnittstellen der deutschen Verwaltung XML Schema Definition; W3C Standard zum Validieren von XML Dateien Seite 38