FAQ

Im Rahmen der Produktionsphase wird das XÖV-Fachmodell im Austauschformat XMI an das Werkzeug XGenerator übergeben. Obgleich XMI ein anbieter- und werkzeugneutraler Standard sein sollte, sind große Unterschiede bei den einzelnen Werkzeugen feststellbar. In diesem Zusammenhang empfiehlt die KoSIT die Modellierungswerkzeuge MagicDraw und Papyrus zur Erstellung und Pflege eines XÖV-Fachmodells.

Für das Modellierungswerkzeug MagicDraw wird die Nutzung der Version 2021x Refresh1 empfohlen. Diese Version (sowie die ältere Version 19.0 SP4) ist mit den Produkten des XÖV-Rahmenwerks auf Kompatibilität und Fehlerfreiheit getestet. Zudem bietet der Hersteller unterschiedliche Editionen (Standard, Enterprise etc.) des Werkzeugs an. Die Standard-Edition ist für die Entwicklung eines XÖV-Standards ausreichend.

Das Open-Source-Modellierungswerkzeugs Papyrus wird in den aktuellen Versionen unterstützt. Getestet wurde mit der Version 2022-03 (4.23) / Release 6.1.0.

Sprechen Sie uns gerne an, wenn Sie Fragen zur Auswahl oder zur Beschaffung des Werkzeugs haben, wir beraten Sie gerne.

Datentypen und globale Elemente werden im XÖV-Fachmodell mittels UML-Klassen spezifiziert. Klasseneigenschaften, die Kindelemente der Datentypen bzw. globalen Elemente repräsentieren, werden mit dem Stereotyp “xsdElement” annotiert. Zur Bestimmung der Reihenfolge der Kindelemente in der resultierenden XML Schema-Definition erhält jedes Kindelement eine entsprechende Positionsangabe (position).

(Beispiel: Im Falle eines Datentyps “Person” mit den Kindelementen “name” (position = 1) und “geburtsdatum” (position = 2) erscheint das Element “name” in der XML Schema-Definition vor dem Element “geburtsdatum”.)

Bei XML Schema-Erweiterungen leitet ein Datentyp bzw. ein globales Element von einem Basistyp ab und erbt damit unter anderem dessen Kindelemente. Stehen in diesem Fall die Positionsangaben im ableitenden Typ bzw. globalen Element in einer Beziehung mit den Positionsangaben im Basistyp?

Lösung: Die Positionsangaben gelten lokal für jede UML-Klasse. Somit werden bei einer XML Schema-Erweiterung die Positionen der Kindelemente im Kontext des Basistyps und im Kontext des ableitenden Typs bzw. globalen Elements unabhängig voneinander vergeben.

(Beispiel: Leitet der Datentyp “PersonMitAnschrift” mit dem Kindelement “anschrift” (position = 1) von dem oben genannten Datentyp “Person” per XML Schema-Erweiterung ab, sind in einer XML-Instanz des Datentyps “PersonMitAnschrift” die Elemente in der folgenden Reihenfolge zu befüllen: “name”, “geburtsdatum”, “anschrift”. Für das Kindelement “anschrift” muss somit nicht die Position 3 vergeben werden, auch wenn es im diesem Beispiel zum selben Ergebnis führte.)

Dieses Vorgehen folgt aus der Tatsache, dass in XML-Instanzdokumenten die Gruppe der Kindelemente eines Basistyps immer vor der Gruppe der Kindelemente des ableitenden Typs bzw. globalen Elements auftreten.

Das XÖV-Profil bietet die Möglichkeit, Geschäftsregeln im XÖV-Fachmodell eines Standards zu spezifizieren und diese mittels XGenerator automatisiert in Schematron-Regeln zu überführen. Diese können als Grundlage für die Validierung von Nachrichteninstanzen des Standards genutzt werden. Detaillierte Ausführungen anhand von Beispielen finden Sie auf dieser Seite: XÖV-Methodik zur Spezifikation von Geschäftsregeln

Diese Seite liefert Beispiele und Ausführungen zum Thema: Default- und Fixed-Werte

Codelisten, die über das XRepository bereitgestellt werden, können problemlos in das XÖV-Fachmodell eingebunden werden. Verwenden Sie hierzu den Download der Codeliste im mdxml-Format. Eine detaillierte Beschreibung der Einbindung der mdxml-Datei finden Sie auf der Seite Nutzung einer Codeliste aus dem XRepository im XÖV-Fachmodell.

In verschiedenen XÖV-Standards besteht der Bedarf im Modell eines Standards Inhalte zu pflegen, die nicht originär Teil eines XÖV-Fachmodells sind. Beispielsweise werden in Aktivitäts- oder Sequenzdiagrammen UML-Elemente eingesetzt, die ebenfalls im Kontext von Klassendiagrammen zur Beschreibung von Nachrichten und Datentypen genutzt werden (z. B. UML-Klassen und deren Eigenschaften).

Es kann vorkommen, dass der XGenerator derartige Inhalte im XÖV-Fachmodell vorfindet und versucht diese zu interpretieren und bspw. in XML Schema abzubilden. Hierbei handelt es sich jedoch um eine Fehlinterpretation, die zu Fehlern führt.

Zur Gewährleistung einer klaren Trennung von Inhalten des XÖV-Fachmodells, die vom XGenerator entsprechend verarbeitet werden, und darüber hinausgehenden Inhalten, die vom XGenerator ignoriert werden sollen, sind letztere Inhalte außerhalb des mit dem Stereotyp xoevStandard gekennzeichneten Modellpakets des Standards anzuordnen.

Der XGenerator ist ein Werkzeug, das sowohl die automatisierte Prüfung des XÖV-Fachmodells als auch die Erzeugung der Bestandteile des Standards ermöglicht. Ausgangspunkt ist dabei das XÖV-Fachmodell im XMI-Format (XML Metadata Interchange), das mittels Exportfunktion aus dem Modellierungswerkzeug heraus erzeugt wird.

Neben der von mir genutzten Version des XGenerators sind eine Reihe weiterer Versionen veröffentlicht. Welche davon soll ich für die Produktion meines Standards nutzen?

Lösung: Mit dem XGenerator in der Version 3.1.0 können Standards in allen gültigen XÖV-Konfigurationen verarbeitet werden.

Mein Modellierungswerkzeug bietet unter der Exportfunktion eine Reihe von Exportformaten zur Nutzung an. Welches dieser Formate und zugehöriger Versionen wird aktuell zur Produktion eines XÖV-Standards empfohlen?

Lösung: Die aktuellen Versionen des XGenerators (3.n) sind mit der XMI-Version „Eclipse UML2 v5.x“ getestet und konform.

Im Kontext eines XÖV-Standards kann entschieden werden, bestimmte XÖV-Empfehlungen und/oder SOLL-Regeln dauerhaft nicht einzuhalten. In diesem Fall können diese deaktiviert werden, sodass der XGenerator hierzu bei Verletzung keine Meldung mehr macht. Auf diese Weise wird erreicht, dass nur noch die für den Standard relevanten Warnungen und Hinweise ausgegeben werden.

Eine XÖV-Prüfanweisung kann dauerhaft deaktiviert werden, indem sie innerhalb des XGenerator-Projektes, d. h. der XML-Datei mit der Endung .xgen-project, als disabled-rule gekennzeichnet wird.

Hierfür wird zunächst die ID der jeweiligen Prüfanweisung ermittelt. Der XGenerator zeigt die ID einer verletzten Prüfanweisung im oberen rechten Bereich an. Sie kann durch Markieren und Kopieren (Strg+C) übernommen werden. Alternativ kann die ID einer Prüfanweisung der generierten Log-Datei (build/xgenerator-log.xml) entnommen werden (XML-Attribut id innerhalb des Elements svrl:failed-assert).

Die ID der zu deaktivierenden Prüfanweisung wird daraufhin innerhalb der XGenerator-Projektdatei als Wert des XML-Elements prj:disabled-rule in das bestehende Element

eingetragen.

Das Folgende Beispiel zeigt die Deaktivierung der Prüfanweisung mit der ID NachrichtenOderFachmodulePaketDefiniert:

Achtung: XÖV-Prüfanweisungen, die MUSS-Regeln entsprechen, dürfen nicht deaktiviert werden.

In diesem FAQ-Eintrag wird die Umstellung auf das zum XÖV-Release 2.4 (vom 15.12.2021) gehörende XÖV-Profil 2.0.0 beschrieben.

Hinweis: Die folgende Anleitung gilt für die Umstellung von XÖV-Standards, die derzeit das XÖV-Profil in der Version 1.7.0, 1.7.1 oder 1.7.2 einsetzen und somit die Regelungen des XÖV-Handbuchs 2.3.0 bzw. 2.3.1 umsetzen. Für die Umstellung von XÖV-Standards, die ältere Versionen des Profils einsetzen, sind bspw. aufgrund der zu XÖV 2.3 aktualisierten Methodik zur Modellierung und Nutzung von Codelisten weitere Umstellungsschritte erforderlich. In diesem Fall wird eine Kontaktaufnahme mit der KoSIT empfohlen.

Mit der Version 1.2 des Codelistenhandbuchs wurden Möglichkeiten geschaffen s.g. mehrsprachige Codelisten abzubilden. Darin können die Metadaten der Codelisten in mehreren Sprachen verfasst und die Daten sprachlich ausgezeichnet werden.

Nein, es können weiterhin Codelisten produziert und veröffentlicht werden ohne eine sprachliche Auszeichnung.

Wenn sie die Codeliste im Codelisten-Editor bearbeiten, wird diese automatisch auf die neuste Version migriert.

Nein, der Genericoder unterstüzt die Codelistenmethodik nur bis zur Version 1.1. Wie bereits Mitte des Jahres 2021 angekündigt, wird der Genericoder zum Ende November 2022 abgeschaltet. Als vollwertige Alternative steht der Codelisten-Editor im XRepository bereit.

Eine Codelistenversion umfasst gemäß dem Codelisten-Handbuch eine “Liste von Codes und zugehöriger Beschreibung(en)”, das heißt eine Liste von Einträgen. Die Einträge einer Codelistenversion, die im XÖV-Fachmodell eines Standards entwickelt und/oder genutzt wird, liegen als Menge ohne bestimmte Sortierung vor.

Bei der Abbildung von Codelistenversionen in XML Schema und Genericode sortiert der XGenerator die Codelisteneinträge anhand der Codes in der zu nutzenden Code-Spalte (siehe Abschnitt “Bestimmung der zu nutzenden Code-Spalte” des XÖV-Handbuchs) alphabetisch um den Einträgen eine geregelte Ordnung zu geben (gemäß den Regeln beschrieben in https://www.w3.org/TR/xslt20/#sorting für String-Werte) und damit deterministisch zu arbeiten. So soll insbesondere gewährleistet werden, dass die generierten Bestandteile eines Standards technisch vergleichbar bleiben und keine Änderungen erfahren, die nicht durch inhaltliche Änderungen des XÖV-Fachmodells begründet sind.

Für die Verarbeitung einer Codelistenversion darf die Reihenfolge ihrer Einträge in Genericode oder XML Schema keine Bedeutung haben, da keine bestimmte Reihenfolge der Codelisteneinträge angenommen werden kann.

Dieselbe Codelistenversion, kann bspw. in einer konkreten Abbildung folgende Einträge besitzen:

In einer anderen konkreten (äquivalenten!) Abbildung kann sie dagegen folgende Einträge besitzen:

Im Umkehrschluss bedeutet dies, dass die Reihenfolge im verarbeitenden System den jeweiligen Anforderungen entsprechend gewählt werden kann ohne die inhaltliche Aussage zu verändern.

Als beispielhafter Kontext kann die Darstellung einer Codelistenversion im Spezifikationsdokument betrachtet werden. Für menschliche Leser:innen ist bei numerischen Codes häufig eine numerische Sortierung leichter zu erfassen als eine alphabetische.

Eine alphabetische Sortierung würde im vorherigen Beispiel zu folgender, ggf. unerwarteten, Abbildung im Spezifikationsdokument führen:

Aus diesem Grund steht für die DocBook-Generierung im XÖV-Fachmodell der Stereotyp docNumerischeSortierung zur Verfügung. Wenn eine Codelistenversion mit diesem Stereotyp annotiert wird, erfolgt eine numerische Sortierung.

Das XÖV-Starterpaket bringt eine beispielhafte Funktionalität zur automatisierten Generierung eines Spezifikationsdokuments (PDF) mit sich, d. h. Übersetzungsanweisungen zur Überführung der Inhalte des XÖV-Fachmodells in DocBook und Übersetzungsanweisungen und Tools (so genanntes DocBook-Zubehör) zur Übersetzung des DocBook-Gesamtdokuments in ein PDF.

Das PDF-Dokument besitzt Dokumenteneigenschaften, u. a. zur Angabe eines Titels, eines Verfassers oder der Anwendung, mit der das PDF erzeugt wurde.

Das DocBook-Zubehör entfernt aus Datenschutzgründen automatisiert die Angaben zur Anwendung und setzt die Metadaten zum Titel und Verfasser (genutzter Beispielwert "Koordinierungsstelle für IT-Standards (KoSIT)").

Sie können die Angaben zum Verfasser individuell Anpassen, indem Sie in der Datei "docbookzubehoer\stylesheets\kosit\kosit_docbook.changes.xsl" den Wert im Element "dc:creator" aktualisieren.