Sie sind hier:
  • XÖV
  • FAQ zum XÖV-Rahmenwerk

FAQ - Häufig gestellte Fragen

Inhalt

Modellierung: Welches Modellierungwerkzeug soll ich verwenden?

Modellierung: Wie wird im XÖV-Fachmodell bei XML Schema-Erweiterungen die Reihenfolge der XML-Elemente gesteuert?

Modellierung: Wie können Geschäftsregeln in einem Standard modelliert werden?

Modellierung: Wie ist mit Default- und Fixed-Werten in XML Schema-Defintionen umzugehen?

Modellierung: Kann eine über das XRepository bereitgestellt Codeliste in mein XÖV-Fachmodell importiert werden?

Modellierung: Wie ist mit Modellinhalten umzugehen, die vom XGenerator nicht verarbeitet werden sollen?

XGenerator: Wozu brauche ich den XGenerator?

XGenerator: Welche Version des XGenerators soll ich verwenden?

XGenerator: Welche XMI-Version benötigt der XGenerator?

XGenerator: Deaktivierung von XÖV-Prüfanweisungen

XÖV-Profil: Welche Schritte sind für die Umstellung auf das XÖV-Profil 2.0.0 zu unternehmen?

Übernahme der neuen Produkte in das Projektverzeichnis des Standards

Erforderliche Einstellungen nach Übernahme der neuen Produkte

Codelisten: Mehrsprachigkeit

Codelisten: Ist eine Nutzung der Mehrsprachigkeits-Funktionalität notwendig um die Version 1.2 zu nutzen?

Codelisten: Wie kann ich eine neue Version meiner bestehenden Codeliste bereitstellen, die konform zu den neuen Regelungen ist?

Codelisten: Kann ich weiterhin den Genericoder verwenden?

Codelisten: Reihenfolge von Codelisteneinträgen


Modellierung: Welches Modellierungwerkzeug soll ich verwenden?

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.

Zurück zur Übersicht


Modellierung: Wie wird im XÖV-Fachmodell bei XML Schema-Erweiterungen die Reihenfolge der XML-Elemente gesteuert?

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.

Zurück zur Übersicht


Modellierung: Wie können Geschäftsregeln in einem Standard modelliert werden?

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

Zurück zur Übersicht


Modellierung: Wie ist mit Default- und Fixed-Werten in XML Schema-Defintionen umzugehen?

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

Zurück zur Übersicht


Modellierung: Kann eine über das XRepository bereitgestellt Codeliste in mein XÖV-Fachmodell importiert werden?

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".


Modellierung: Wie ist mit Modellinhalten umzugehen, die vom XGenerator nicht verarbeitet werden sollen?

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.

Zurück zur Übersicht


XGenerator: Wozu brauche ich den XGenerator?

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.

Zurück zur Übersicht


XGenerator: Welche Version des XGenerators soll ich verwenden?

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.

Zurück zur Übersicht


XGenerator: Welche XMI-Version benötigt der XGenerator?

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.

Zurück zur Übersicht


XGenerator: Deaktivierung von XÖV-Prüfanweisungen

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.

Zurück zur Übersicht


XÖV-Profil: Welche Schritte sind für die Umstellung auf das XÖV-Profil 2.0.0 zu unternehmen?

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.

Übernahme der neuen Produkte in das Projektverzeichnis des Standards

Das XÖV-Profil 2.0.0 wird als ZIP-Archiv bereitgestellt. Dieses wird im Projektverzeichnis des Standards entpackt (d. h. in dem Verzeichnis, in dem sich u. a. das "model"-Verzeichnis befindet). Dabei werden die bestehenden Inhalte zum XÖV-Profil automatisch ersetzt.

Mit dem XÖV-Profil 2.0.0 ist die Nutzung der XÖV-Bibliothek in der Fassung vom 2021-12-15 zwingend erforderlich. Die Modelldatei der neuen Fassung der XÖV-Bibliothek wird hierfür im "model"-Verzeichnis des Standards abgelegt. Damit wird die bisherige Datei überschrieben.

Sofern für die Dokumentationsgenerierung die mit dem Starterpaket bereitgestellten DocBook-Übersetzungsanweisungen genutzt werden, kann deren aktueller Stand dem XÖV-Starterpaket 2.4.0 entnommen werden.

Erforderliche Einstellungen nach Übernahme der neuen Produkte

Nach der Übernahme des XÖV-Profils 2.0.0 stehen im Kontext des Stereotyps xsdXModel neue Stereotypeigenschaften zur Verfügung, die in bestehenden Standards folgende Werte erhalten müssen:

Tabelle
StereotypeigenschaftWertHinweis
"xsdXModel/automatischeImportErmittlung"false
"xsdXModel/automatischeIncludeErmittlung"false
"xsdXModel/ermittlungElementreihenfolge"Stereotyp
"xsdXModel/standardeinstellungEigenschaften"keine
"xsdXModel/xsdNamedTypeNameSuffix"'' (leerer String)Ggf. ist diese Einstellung ebenso in den genutzten externen Modellen vorzunehmen, wenn diese noch nicht auf XÖV 2.4 umgestellt wurden.

Umsetzung der Einstellungen in einem Beispiel-Standard:

Achtung! Die Standardwerte der aufgeführten Einstellungen sind auf neue XÖV-Vorhaben ausgerichtet. Für bestehende Standards wird dringend empfohlen, die Einstellungen wie zuvor beschrieben vorzunehmen um inhaltliche und strukturelle Änderungen in den Schemas des Standards zu vermeiden. Sofern Anpassungen an den Einstellungen gewünscht sind, wird eine Kontaktaufnahme mit der KoSIT empfohlen.

Zurück zur Übersicht


Codelisten: Mehrsprachigkeit

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.

Codelisten: Ist eine Nutzung der Mehrsprachigkeits-Funktionalität notwendig um die Version 1.2 zu nutzen?

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

Codelisten: Wie kann ich eine neue Version meiner bestehenden Codeliste bereitstellen, die konform zu den neuen Regelungen ist?

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

Codelisten: Kann ich weiterhin den Genericoder verwenden?

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.


Codelisten: Reihenfolge von Codelisteneinträgen

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:

Tabelle
CodeBeschreibung
1rot
2gelb
11grün

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

Tabelle
CodeBeschreibung
2gelb
11grün
1rot

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:

Tabelle
CodeBeschreibung
1rot
11grün
2gelb

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.

Zurück zur Übersicht