Vorlage Schnittstellendokumenation
Diese Seite ist ein Teil der IsyFact-Standards. Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt. Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
Dieser Lizenztext bezieht sich auf die Vorlage. In Dokumenten, die auf der Vorlage basieren, ist dieser Text zu löschen.
Allgemeine Hinweise zur Dokumentvorlage
Diese Dokumentvorlage enthält die Gliederung für eine V-Modell-konforme Schnittstellendokumentation eines Softwaresystems (Software-Entwicklungsprojekt) mitsamt Ausfüllhinweisen und Beispielen in den jeweiligen Kapiteln. Die Hinweise und Beispiele (auch dieser Abschnitt) sind in der Schnittstellendokumentation später zu entfernen. Sie dienen nur als Hilfestellung für die Erstellung des Dokuments.
Das Dokument enthält eine fachliche Beschreibung der angebotenen Nachbarsystemschnittstellen und richtet sich somit an Fachanwender, Softwareentwickler und Softwarearchitekten, die die beschriebenen Schnittstellen nutzen möchten. Dieses Dokument enthält keine Dokumentation der technischen Details der Nachbarsystemschnittstellen, wie z.B. Schnittstellentechnologie, Aufrufpfade oder Implementierungshinweise.
Bei Änderungen des Softwaresystems, die die Schnittstellen betreffen, ist dieses Dokument anzupassen und auf die Änderungen in der Historie hinzuweisen.
Dieses Dokument orientiert sich am Aufbau der V-Modell XT Vorlage „Externes-SW-Modul-Spezifikation“, da die Nachbarsystemschnittstelle ein externes Software-Modul darstellt. Da es sich bei diesem Dokument um eine rein fachliche Dokumentation und keine Spezifikation handelt, wird der Umfang und die Gliederung der Vorlage angepasst. Zudem ist die Sichtweise eine andere. In der Spezifikation werden Anforderungen an etwas Neues gestellt, in der Dokumentation wird etwas bereits Umgesetztes beschrieben. Das Mapping der Gliederung mit der Dokumentvorlage des V-Modells XT zeigt die nachfolgende Abbildung.
Für die Bezeichnung von Elementen der Schnittstellendokumentation wird folgende Konvention verwendet, um den Typ des Elements kenntlich zu machen:
<Elementtypkürzel><Name_des_Elements>_
Der Typ des Elements wird in gekürzter Form dem Elementnamen vorangestellt. Der Elementname wird mit Unterstrichen statt mit Leerzeichen notiert (z.B. NSE_Meldung_Person). Durch diese Schreibweise wird die spätere Durchsuchbarkeit und eindeutige Identifikation der Elemente gewährleistet.
Jedes Element wird im Dokument in einem Kapitel mit einer Überschrift im folgenden Format notiert:
<Elementtyp> <Elementtypkürzel><Name_des_Elements>_
Zum Beispiel „Angebotene Nachbarsystemschnittstelle NST_Daten_lesen“.
Die Gliederung der Überschriften soll dem Muster aus diesem Dokument entsprechen. Die Inhalte der jeweiligen Kapitel werden nachfolgend beschrieben.
1. Allgemeines
1.1. Zusammenfassung (Management-Summary)
Unter diesem Kapitel soll eine Zusammenfassung des Dokuments auf wenigen Seiten erfolgen.
Beispiel: Dieses Dokument enthält Ausfüllhinweise für die Erarbeitung von Schnittstellendokumentationen nach dem V-Modell XT in einer für den Kunden angepassten Fassung. Es handelt sich um Empfehlungen, die im Einzelfall in Absprache mit dem Kunden abgewandelt werden können. Abweichungen, insbesondere in der Dokumentstruktur sind jedoch in Kapitel 1.2 anzugeben und mit einer Begründung zu versehen.
1.2. Leseanleitung
Die Leseanleitung enthält Hilfen für den Leserkreis. Inhalte sind zum Beispiel
-
Aufbau der Dokumentation (Aufteilung in Dokumente, interne Struktur)
-
Beschreibung der verwendeten Methodik
-
Empfehlungen für verschiedene Lesergruppen
-
Leseanleitung zu verwendeten Notationen (zum Beispiel UML 2.0)
-
Im Folgenden sind einige Beispielkapitel vorhanden, die genutzt, erweitert oder auch gelöscht werden können.
-
1.2.1. Verwendete Notation und Präfixe
In diesem Kapitel wird kurz auf die verwendete Notation und verwendeter Präfixe für die Bezeichnung von Elementen eingegangen. Im Folgenden befindet sich eine Beispielbeschreibung, die je nach Bedarf und Lesergruppe angepasst werden kann.
Beispiel: Für die Beschreibung der Nachbarsystemschnittstellen wird eine angepasste Form der Notation UML 2.0 verwendet. Die in dieser Notation dargestellten Diagramme bestehen aus Elementen und ihren Beziehungen untereinander. Die Beziehungen werden je nach Art der Beziehung durch unterschiedliche Verbinder dargestellt. Zur Erläuterung werden in den folgenden Abschnitten die verwendeten Elemente und Verbinder genauer erklärt.
Zu jeder Schnittstelle werden die Eingabeparameter links und die Ausgabeparameter rechts neben dem Schnittstellensymbol aufgeführt.
Die Parameter können komplex sein. Um die Übersichtlichkeit zu erhöhen, ist ihre Struktur nicht direkt im Schnittstellendiagramm, sondern in separaten Kapiteln Aufrufparameter und Ausgabeparameter im Detail beschrieben. Die Spezifikation der Nachbarsystemschnittstellen umfasst grafische, tabellarische und textliche Beschreibungen.
Die Tabelle 1 enthält im Dokument verwendete Präfixe mit den zugehörigen Elementen.
Präfix | Element |
---|---|
DTY_ |
Datentyp |
NSA_ |
Nachbarschnittstellen-Attribut |
NSE_ |
Nachbarsystemschnittstellen-Entitätstyp |
NST_ |
Nachbarsystemschnittstelle |
1.2.2. Regeln für den Aufbau von Nachrichten
Dieses Kapitel gibt eine kurze Einführung in die Validierungsregeln von Nachrichten. Falls keine Validierung von Nachrichten benötigt wird, kann dieses Kapitel entfernt werden. Im Folgenden befindet sich eine Beispielbeschreibung, die genutzt werden kann.
Beispiel: Die Nachrichten werden vom Service-Gateway gegen Regeln validiert. Dabei wird u.a. geprüft,
-
ob die anfragende Behörde berechtigt ist
-
ob alle Pflichtattribute gesetzt sind
-
ob der Wertebereich der Attribute eingehalten wurde
-
ob die Nachricht mit dem Bestand kompatibel ist
-
etc.
Schlägt die Prüfung fehl, gibt das Service-Gateway eine Fehlernachricht mit Fehlercodes und Fehlertext an den Aufrufer zurück.
Bei jeder Schnittstelle sind die Regeln beschrieben, die beim Aufbau der Nachricht eingehalten werden müssen.
Zu jeder Regel ist angegeben, welcher Fehlercode bei einer Regelverletzung in der Fehlermeldung zurückgegeben wird. Die zugehörigen Fehlertexte können im Anhang nachgelesen werden.
1.2.3. Beispiel zum Verwenden dieser Spezifikation
Im Folgenden wird beschrieben, wie diese Dokumentation verwendet werden kann, um eine Nachricht für eine Nachbarsystemschnittstelle zu erstellen. Der Aufbau ist exemplarisch und kann bei Bedarf angepasst werden. Da dieses Dokument in der Regel mehrere Nachbarsystemschnittstellen dokumentiert, sollte die Beschreibung der Verwendung möglichst allgemeingültig verfasst werden, sodass sie auf alle Nachbarsystemschnittstellen zutrifft.
Beispiel: Hier wird beschrieben, wie der Anwender mithilfe dieser Spezifikation eine Nachricht aufbauen kann.
-
Die benötigte Schnittstelle ist NST_<Nachbarsystemschnittstelle>.
-
In Kapitel <Kapitel der NST> ist diese Schnittstelle beschrieben.
-
Es muss eine NSE_<Schnittstellenentität der Anfrage> aufgebaut werden; der Aufbau ist in Abbildung xyz dargestellt. Hier sieht man, welche Entitäten enthalten sein müssen und welche Entitäten enthalten sein können (Kardinalitäten an den Verbindern).
-
Für jede NSE sind die Attribute im Kapitel Eingabeparameter beschrieben.
-
Für jedes Attribut ist der Datentyp im Kapitel Datentypen beschrieben.
-
Durch die Regeln für den Aufbau der Nachricht werden die Wertebereiche der Attribute genauer bestimmt (zum Beispiel kann auch ‚+‘ für unbekannt in Namensattributen angegeben werden, aber es muss mindestens Vorname oder Nachname bekannt sein).
-
Durch die Regeln werden die Attribute miteinander in Beziehung gesetzt, zum Beispiel muss sich ein gemeldeter „Anderer Name“ von den Grundpersonalien unterscheiden, und eine Organisation darf nur bei bestimmten Sachverhalten und Sachverhaltskennungen gemeldet werden.
-
Unter Berücksichtigung dieser Informationen, kann die NSE_<Schnittstellenentität der Anfrage> korrekt aufgebaut werden.
2. Fachlicher Überblick
2.1. Ziele und Rahmenbedingungen
Die zentralen Ziele und Rahmenbedingungen bilden das einleitende Kapitel einer Schnittstellendokumentation. Damit wird ein inhaltlicher Einstieg in die Schnittstellendokumentation gegeben. Es werden die folgenden Themen behandelt:
-
Zweck und Ziele des Systems bzw. des Projektes
-
Ausgrenzungen bezüglich des Projektumfangs
-
Projektbeteiligte und Nutzer des Systems
-
Vorgaben und Rahmenbedingungen des Projektes (fachlich, technologisch, organisatorisch, politisch, gesetzlich, etc.)
2.2. Architekturüberblick
Der Architekturüberblick beschreibt die angebotenen Schnittstellen und identifiziert Nachbarsysteme. Die Darstellung erfolgt rein aus fachlicher Sicht und differenziert nicht zwischen Schnittstellentechnologien. Jede angebotene Schnittstelle wird in Kapitel 3 detailliert beschrieben. Dieses Kapitel bietet somit einen fachlichen Gesamtüberblick über alle Schnittstellen. Je nach Komplexität kann das Diagramm auf Anwendungsebene oder auf Komponentenebene erstellt werden. Im Folgenden wird die Sicht auf die Aufwendungsebene beschrieben.
Der Architekturüberblick sollte knapp und klar gestaltet werden. Ein gutes Übersichtsbild listet Schnittstellen und externe Nachbarsysteme auf.
Neben dem Übersichtsbild werden die angebotenen Schnittstellen tabellarisch aufgelistet und kurz fachlich beschrieben.
Schnittstelle | Typ | Beschreibung |
---|---|---|
NST<Bezeichnung der Schnittstelle>_ |
Falls es eine fachliche Unterscheidung gibt (z.B. Meldung, Auskunft, etc.) |
Kurze Beschreibung der Schnittstelle |
Weitere Schnittstelle |
Weiterer Typ |
Weitere Beschreibung |
Weitere Schnittstelle |
Weiterer Typ |
Weitere Beschreibung |
3. Nachbarsystemschnittstellen
Ein UML-Komponentendiagramm gibt einen Überblick über die von der Anwendung angebotenen Schnittstellen.
3.1. Angebotene Nachbarsystemschnittstelle NST_<Bezeichnung der Schnittstelle>
3.1.1. Kommunikationsablauf NST_<Bezeichnung der Schnittstelle>
In diesem Kapitel wird der Kommunikationsablauf zwischen einem anderen System und der angebotenen Nachbarsystemschnittstelle beschrieben.
Der Kommunikationsablauf wird in einem Sequenzdiagramm dargestellt. Das Sequenzdiagramm enthält die beteiligten Akteure und die Eingabe- und Ausgabeparameter. Im Anschluss an das Sequenzdiagramm wird dieses erläutert.
3.1.2. Aufbau NST_<Bezeichnung der Schnittstelle>
Die Nachbarsystemschnittstelle wird in einem oder mehreren Diagrammen grafisch dargestellt. Dabei werden die Parameter und Rückgabewerte als Nachbarschnittstellenentitäten dargestellt. Diese beschreiben den Aufbau der Schnittstelle. Der Aufbau der Schnittstellenentitäten kann dem Aufbau eines Datenmodells ähneln. Meist ergeben sich aber doch Abweichungen, zum Beispiel, weil Attribute erst vom aufgerufenen Anwendungsfall berechnet und gespeichert werden.
Für die Beschreibung der Nachbarsystemschnittstellen wird eine angepasste Form der Notation UML 2.0 verwendet. Die in dieser Notation dargestellten Diagramme bestehen aus Elementen und ihren Beziehungen untereinander. Die Beziehungen werden je nach Art der Beziehung durch unterschiedliche Verbinder dargestellt. Zur Erläuterung werden in den folgenden Abschnitten die verwendeten Elemente und Verbinder genauer erklärt.
Zu jeder Schnittstelle werden die Eingabeparameter (Eingabeparameter) links und die Ausgabeparameter (Ausgabeparameter) rechts neben dem Schnittstellensymbol aufgeführt. Die Parameter können komplex sein. Um die Übersichtlichkeit zu erhöhen, ist ihre Struktur nicht direkt im Schnittstellendiagramm, sondern in separaten Kapiteln Aufrufparameter und Ausgabeparameter im Detail beschrieben.
Nachbarschnittstellenentitäten können über mehrere Schnittstellen hinweg wiederverwendet werden.
Wenn das Diagramm der Schnittstelle zu umfangreich wird, kann es auf mehrere Diagramme aufgeteilt werden.
Kurzbeschreibung |
Welche fachlichen Dienste werden durch die Schnittstelle bereitgestellt? Welchen fachlichen Hintergrund haben die ausgetauschten Daten? |
Synchron/Asynchron |
Bei synchronen Schnittstellen blockiert der aufrufende Bearbeitungsablauf so lange, bis die aufgerufene Anwendung eine Antwort zurückgesendet hat (enge Kopplung). Bei asynchronen Schnittstellen fährt der aufrufende Bearbeitungsablauf sofort mit weiteren, lokalen Schritten fort (lose Kopplung). Falls eine Reaktion von der aufgerufenen Anwendung erwartet wird, so muss sie über einen asynchronen Mechanismus wie z.B. ein Aufgabensystem in den Bearbeitungsprozess wieder eingegliedert werden. |
Verwendete |
Liste der Schnittstellenentitätstypen, die Parameter beim Aufruf der Schnittstelle durch ein Nachbarsystem sind. Durch das Schnittstellendiagramm ist diese Information bereits dargestellt, daher ist die Auflistung optional. |
Verwendete |
Liste der Schnittstellenentitätstypen, die von der Schnittstelle zurückgeliefert werden. Durch das Schnittstellendiagramm ist diese Information bereits dargestellt, daher ist die Auflistung optional. |
3.1.2.1. Eingabeparameter
Die Eingabeparameter der Nachbarsystemschnittstelle werden beschrieben. Wenn es viele Überschneidungen zwischen den Eingabeparametern der verschiedenen angebotenen Nachbarsystemschnittstellen gibt, kann dieser Abschnitt auch einmalig nach den Nachbarsystemschnittstellen beschrieben werden.
3.1.2.1.1. Schnittstellenentitätstyp NSE_Meldung_Person
Namen von Schnittstellenentitätstypen beginnen mit dem Präfix „NSE“ gefolgt von einem Substantiv, z.B. „NSE_Person“. Falls nötig, kann noch ein Adjektiv vor das Substantiv gestellt werden. Es hat sich als sinnvoll erwiesen, zusätzlich eine Kurzfassung des Namens der Schnittstelle in den Namen der Entität aufzunehmen, z.B. „NSE_Meldung_Person“. Wenn die Schnittstellenentität einem Entitätstyp im Datenmodell der Systemspezifikation entspricht, sollte sie auch analog heißen._
Falls der Schnittstellenentitätstyp aus mehreren Entitäten zusammensetzt ist, kann dieser (nach einer kurzen Gesamtübersicht) in die einzelnen Entitäten zerlegt und diese anschließend ausführlich beschrieben werden. Dieses Vorgehen wird exemplarisch in diesem Dokument gezeigt.
3.1.2.1.2. Schnittstellenentitätstyp NSE_<Name des Schnittstellenentitätstyps>
Kurzbeschreibung |
Die Beschreibung des Schnittstellenentitätstyps ermöglicht dem Leser, den Namen der Entität zu verstehen. Für die Begriffserklärung können Synonyme oder Oberbegriffe benutzt werden (Beispiel: „Ein Mitarbeiter ist eine natürliche Person“…"). Anschließend wird der Begriff inhaltlich und zeitlich abgegrenzt, d.h. es wird erläutert, unter welchen Bedingungen eine Ausprägung zu diesem Entitätstyp gehört. Die Beschreibung kann Beispiele, weitere Erläuterungen und Anmerkungen enthalten. |
Attribut | Datentyp | Bedeutung | Pflicht |
---|---|---|---|
Name des Nachbarschnittstellenattributs beginnend mit dem Präfix „NSA_“. |
Verweis auf den fachlichen Datentyp (siehe Kapitel „3. 3 Datentypen“) oder auf einen einfachen Datentyp („Zeichenkette“, „Ganzzahl“, „Fließkommazahl“ etc.). |
Die Beschreibung des Attributes sollte einen inhaltlichen Mehrwert bringen (also Beschreibungen wie „Datum ist das Datum der Buchung“ vermeiden). Folgende Fragestellungen können bei der Beschreibung helfen:
|
Gibt an, ob es sich um ein Pflichtfeld handelt (J/N). Weitere Details sind in den entsprechenden Kapiteln zu den Befüllungsregeln der Nachrichten beschrieben. Bei einem Pflichtfeld muss ein Wert gesetzt sein. Bei einigen Attributen sind auch unscharfe Angaben erlaubt (z.B. NSA_Geburtsdatum und NSA_Vorname). Bei einem Datum erkennt man das am Datentyp (DTY_unsicheres_Datum), bei einem Textattribut erkennt man es bei den Regeln für den Aufbau der Nachrichten (z.B. beim NSA_Vorname ist die Angabe ‚+‘ erlaubt, das steht für einen unbekannten Wert). Bei Ausgabeparametern bedeutet die Pflichtangabe, ob das Attribut in der Rückgabe immer gesetzt ist. |
Weitere Nachbarschnittstellenattribute in nachfolgenden Zeilen |
Weitere Datentypen |
Weitere Beschreibungen |
3.1.2.2. Ausgabeparameter
Die Ausgabeparameter der Nachbarsystemschnittstelle werden analog zu den Eingabeparametern beschrieben. Wenn es viele Überschneidungen zwischen den Ausgabeparametern der verschiedenen angebotenen Nachbarsystemschnittstellen gibt, kann dieser Abschnitt auch einmalig nach den Nachbarsystemschnittstellen beschrieben werden. Zurückgegebene Fehlermeldungen (z.B. NSE_Fehler) werden in Kapitel 4 beschrieben. Diese sollen an dieser Stelle nicht beschrieben werden.
3.1.2.2.1. Schnittstellenentitätstyp NSE_<Name des Schnittstellenentitätstyps>
Kurzbeschreibung |
Die Beschreibung des Schnittstellenentitätstyps ermöglicht dem Leser, den Namen der Entität zu verstehen. Für die Begriffserklärung können Synonyme oder Oberbegriffe benutzt werden (Beispiel: „Ein Mitarbeiter ist eine natürliche Person“…"). Anschließend wird der Begriff inhaltlich und zeitlich abgegrenzt, d.h. es wird erläutert, unter welchen Bedingungen eine Ausprägung zu diesem Entitätstyp gehört. Die Beschreibung kann Beispiele, weitere Erläuterungen und Anmerkungen enthalten. |
Attribut | Datentyp | Bedeutung | Mindestangabe |
---|---|---|---|
Name des Nachbarschnittstellenattributs beginnend mit dem Präfix „NSA_“. |
Verweis auf den fachlichen Datentyp (siehe Kapitel „3.3 Datentypen“) oder auf einen einfachen Datentyp („Zeichenkette“, „Ganzzahl“, „Fließkommazahl“ etc.). |
Die Beschreibung des Attributes sollte einen inhaltlichen Mehrwert bringen (also Beschreibungen wie „Datum ist das Datum der Buchung“ vermeiden). Folgende Fragestellungen können bei der Beschreibung helfen:
|
|
Weitere Nachbarschnittstellenattribute in nachfolgenden Zeilen |
Weitere Datentypen |
Weitere Beschreibungen |
3.1.3. Regeln für den Aufbau der Anfragenachricht
In diesem Kapitel wird beschrieben, welche Regeln beim Aufbau der Anfragenachrichten eingehalten werden müssen. Diese Regeln werden vom System geprüft. Ist die Regel nicht erfüllt, erzeugt das System in der Regel eine Fehlernachricht mit dem angegebenen Fehlercode und einem Fehlertext.
Geprüft werden kann zum Beispiel,
• ob der Anfragende berechtigt ist
• ob alle Pflichtattribute gesetzt sind
• ob der Wertebereich der Attribute eingehalten wurde
• etc.
Zu jeder Regel muss angegeben werden, welcher Fehlercode bei einer Regelverletzung in der Fehlermeldung zurückgegeben wird. Die zugehörigen Fehlertexte werden im Anhang verfasst.
Die Art und der Umfang der Regeln bestimmen die Kapitelstruktur. Die folgenden Kapitel stellen keine abschließende Auflistung von Regeltypen dar. Die Beschreibung der Regeln erfolgt auf Schnittstellenentitäts- und Attributsebene. Die Regeln sind tabellarisch zu beschreiben und mit dem Fehlercode zu versehen, der bei einem Regelbruch zurückgeliefert wird. Beispielhaft kann folgende Struktur als Grundlage gewählt werden:
3.1.3.1. Regeln der Schnittstellenentitäten
Hier werden Regeln definiert, die für eine komplette Schnittstellenentität gelten. Dies kann zum Beispiel die Prüfung auf Vollständigkeit sein.
3.1.3.2. Regeln für Wertebereich der Schnittstellenentitätsattribute
Hier werden Regeln für die Wertebereiche der einzelnen Schnittstellenentitätsattribute definiert. Auf eine Gruppierung nach Schnittstellenentität in Form von Unterkapiteln kann bei Bedarf verzichtet werden, da typischerweise gleiche Attribute über mehrere Schnittstellenentitäten hinweg verwendet werden und der Übersicht halber nur einmal beschrieben werden sollen.
Typische Regeln:
-
Max. Länge des anzunehmenden Wertes
-
erlaubte Zeichen
-
Format ggfs. mit regulären Ausdrücken
-
Verwendung von Wildcards
Attribut | Wertebereich | Max. Länge | Fehlercode |
---|---|---|---|
NSA_Datum |
|
10 |
ABCXY4567 |
Weiteres Attribut |
Weiterer Wertebereich |
||
3.1.3.3. Regeln für Zusammensetzung einer Anfrage
Oft sind weitere Regeln notwendig, um die korrekte Zusammensetzung einer Anfrage aus mehreren Schnittstellenentitäten oder Schnittstellenentitätsattributen zu gewährleisten.
Typische Regeln
-
Einhaltung der Kardinalität
-
Einhaltung von logischen Verknüpfungen
-
Einhaltung von WENN-DANN Beziehungen (z.B. wenn NSA_Alter < 18, dann muss NSE_Erziehungsberechtigter in der Nachricht enthalten sein.)
Regel | Fehlercode |
---|---|
Bei einer Anfrage muss entweder NSE_Organisation oder NSE_Person befüllt sein. |
ABCXY789 |
3.2. Angebotene Nachbarsystemschnittstelle NST_<Bezeichnung der Schnittstelle>
Dieser Abschnitt ist ein Platzhalter, um zu verdeutlichen, dass ab hier weitere angebotene Schnittstellen mit ihren Ein- und Ausgabeparametern zu beschreiben sind.
3.3. Datentypen
Fachliche Datentypen gruppieren Typen und Wertebereichsangaben von Attributen. Die Datentypen werden in einem Datentypverzeichnis verwaltet. Beispiele: ISBN, Fahrgestellnummer, Aufzählungstypen.
Im Fall von trivialer Fachlichkeit (z.B. Beschreibungstexte, einfache Nummern) verzichten wir auf fachliche Datentypen und verwenden direkt die technischen Basistypen Zeichenkette, Ganzzahl, Kommazahl etc. Eigenschaften des Attributes und der Datentyp sollten voneinander getrennt werden.
Typischerweise verwenden verschiedene Anwendungen ähnliche Datentypen. Innerhalb einer Anwendungslandschaft müssen gleich benannte Datentypen auch den gleichen Inhalt haben. Ähnliche, aber inhaltlich unterschiedliche Datentypen sollten auch über die Anwendungen der Anwendungslandschaft explizit unterschiedlich benannt werden, um hier Verwirrung zu vermeiden.
Datentyp | Basistyp | Bedeutung | Wertebereich |
---|---|---|---|
Name des Datentyps beginnend mit dem Präfix „DTY_“. |
Technischer Basistyp wie „String“, „Integer, „Float“, „Alphanum“ oder ähnliche. |
Fachliche Bedeutung des Datentyps. Hier sollen auch Plausibilisierungen und Prüfungen beschrieben werden. |
Mögliche Ausprägungen des Datentyps. |
4. Fehlerbehandlung
In diesem Kapitel wird die Fehlerbehandlung der angebotenen Schnittstellen beschrieben. Neben der Beschreibung von Validierungs- und Verarbeitungsfehlern, können der Beschreibung auch weitere Fehlerarten hinzugefügt werden.
4.1. Validierungsfehler
Validierungsfehler werden durch fehlerhafte fachliche Bedingungen beim Eingang von Nachrichten ausgelöst. Zu einer Nachricht werden alle Validierungsfehler gesammelt und an den Aufrufer übermittelt. Die möglichen Validierungsfehler sind bei den Aufbauregeln der einzelnen Anfragenachrichten beschrieben. In diesem Kapitel sollen mindestens folgende Aspekte beschrieben werden:
-
Validierungsarten (Format, Fachliche Anforderungen, etc.)
-
Behandlung der Validierungsfehler (Organisationssicht)
4.2. Verarbeitungsfehler
Verarbeitungsfehler sind technische Ausnahmefehler, die zum Beispiel bei technischen Verarbeitungsproblemen oder einer nicht Schemakonformen-Nachricht auftreten können.
In diesem Kapitel sollen mindestens folgende Aspekte beschrieben werden:
-
Behandlung der Verarbeitungsfehler (Organisationssicht)
4.3. Aufbau der Fehlernachricht NSE_<Bezeichnung der Schnittstellenentität>
In diesem Kapitel wird der Aufbau der Fehlernachricht beschrieben, die bei einem Validierungs- oder Verarbeitungsfehler an den Aufrufer zurückgegeben wird. Die Fehlernachricht ist als Schnittstellenentität ein Teil der Schnittstellenbeschreibung in Kapitel 3. Da in vielen Fällen die gleiche Schnittstellentität als Fehlernachricht für mehrere Schnittstellen verwendet wird, wird die Fehlernachricht zentral in diesem Kapitel beschrieben.
Kurzbeschreibung |
Die Fehlernachricht enthält alle Entitäten um die fachlichen Fehler bei einem Schnittstellenaufruf zurückzuliefern. |
4.3.1. Schnittstellenentitätstyp NSE_Fehler
Kurzbeschreibung |
Enthält die Beschreibung des aufgetretenen Fehlers. |
Attribut | Datentyp | Bedeutung |
---|---|---|
Name des Nachbarschnittstellenattributs beginnend mit dem Präfix „NSA_“. |
Verweis auf den fachlichen Datentyp (siehe Kapitel „3.3 Datenmodell) oder auf einen einfachen Datentyp („Zeichenkette“, „Ganzzahl“, „Fließkomma-zahl“ etc.). |
Kurze Beschreibung des Attributs. |
NSA_Fehlertext |
DTY_Zeichenkette |
Textuelle Kurzbeschreibung des fachlichen Fehlers. |
5. Schnittstellenverhalten
In diesem Kapitel soll das Verhalten der Schnittstellen beschrieben werden. Als Grundlage dient hierfür die Umsetzung der nicht-funktionalen Anforderungen aus der Systemspezifikation. Im Fokus steht vor allem das Performanzverhalten und mögliche Einschränkungen im Mengengerüst von Anfragen.
5.1. Performanz und Antwortzeitverhalten
Das Antwortzeitverhalten von Nachbarsystemschnittstellen ist ein wichtiger Bestandteil der Schnittstellendokumentation, da es darüber Auskunft gibt, wie lange ein externes System in der Regel auf eine Antwort wartet. Oft erhält man hier Angaben wie "Antwortzeit beträgt max. 10 Sekunden". Falls das Performanz- und Antwortverhalten je Nachbarsystemschnittstelle differenziert, sollten die Angaben je Nachbarsystemschnittstelle dokumentiert werden. Die Angaben können je nach Umfang in Text- oder Tabellenform erfolgen.
5.2. Lastverhalten und Mengengerüst
Mengengerüste können sich auf Aspekte wie Benutzungshäufigkeit, zeitliche Verteilung der Benutzung, der Menge fachlicher Objekte und Datenvolumen beziehen. Zusammen mit dem Performanzverhalten stellt das Mengengerüst einen wichtigen Faktor in Leistung einer Schnittstelle dar. Zum Beispiel ist das Performanzverhalten nur dann aussagekräftig, wenn sie sich als Voraussetzung und Annahme auf ein konkretes Mengengerüst beziehen. Das Mengengerüst selbst ist auch ein wichtiger Aspekt, der für die Nutzung der Schnittstelle eine große Bedeutung besitzt.
5.3. Verfügbarkeit
In diesem Kapitel werden besondere Aspekte der Verfügbarkeit dokumentiert. Die Verfügbarkeit wird über einen Prozentwert gemessen, der unter Berücksichtigung von definierten Betriebs- und Wartungsfenstern angibt, wie ausfallsicher eine Anwendung sein sollte und tatsächlich ist. Dokumentiert wird die geplante Betriebszeit. Zum Beispiel wird hier angegeben, dass die Schnittstelle jeweils Montag bis Freitag von 07:00 bis 19:00 Uhr zur Verfügung steht. Alternativ wird auch einfach nur ein Prozentwert angegeben, zum Beispiel 99 %.
6. Offene Punkte
Die zur Abnahme des Dokuments noch zu klärenden offenen Punkte in Listenform.
Nummer | Beschreibung |
---|---|
1 |
Ein offener Punkt |
7. Anhang
7.1. Glossar
Das Glossar definiert die wichtigen fachlichen und technischen Begriffe und Abkürzungen des Projekts. Zudem werden häufig verwendete fremdsprachige Begriffe übersetzt und erläutert. Das Glossar klärt somit Begriffsbedeutungen und beugt Missverständnissen vor. Es erleichtert das gemeinsame Verständnis von Fachlichkeit und Technik, sowie die Einarbeitung der Projektbeteiligten. Schließlich etabliert das Glossar eine gemeinsame Sprache aller Projektbeteiligten, sowohl im Entwicklungsprojekt wie auch auf Kundenseite.
Beispielhaft ein Glossar zu den in diesem Dokument verwendeten Begriffen:
Begriff | Kategorie | Erläuterung | Synonym(e) oder Übersetzung(en) |
---|---|---|---|
Anwendungskomponente |
Architektur |
Eine Anwendungskomponente beschreibt eine Menge funktional zusammenhängender Anwendungsfälle. |
|
Anwendungslandschaft |
Architektur |
Die Anwendungslandschaft einer Organisation ist bestimmt durch die Menge der von der Organisationseinheit betriebenen Anwendungen. |
|
Anwendung |
Architektur |
Eine Anwendung ist eine zusammengehörende, logische Einheit aus Funktionen, Daten und Schnittstellen. Sie besteht aus Anwendungskomponenten. Eine Anwendung unterstützt Geschäftsprozesse. Sie beschreibt die gesamten hierfür notwendigen Funktionen, von den Schnittstellen (zu Anwendern oder anderen Anwendungen) über die Geschäftslogik, die Prozesse bis hin zur Datenhaltung. Dabei kann sie Services von anderen Anwendungen nutzen. Eine Anwendung ist Bestandteil der A-Architektur. Die software-technische Umsetzung einer Anwendung besteht in der Regel aus mehreren IT-Systemen. |
|
Attribut |
Daten |
Als „Attribut“ versteht man eine dem Entitätstyp zugeordnete Information. |
|
Entität |
Daten |
Als Entität wird ein eindeutig zu bestimmendes Objekt bezeichnet, dem Informationen zugeordnet werden. Die Objekte können materiell oder immateriell sein. |
Informationsobjekt, Objekt |
Entitätstyp |
Daten |
Jede Entität (das einzelne Objekt) wird einem Entitätstyp zugeordnet. Entitäten sind konkrete Ausprägungen eines Entitätstyps. |
Klasse |
Fachlicher Datentyp |
Daten |
Ein fachlicher Datentyp beschreibt das Format und den Wertebereich eines Nachbarsystemschnittstellen-Attributs. Die Namen der fachlichen Datentypen beginnen mit dem Präfix „DTY_“. Datentypen, die eine Liste von Schlüsselwertpaaren repräsentieren, heißen Aufzählungstypen. Namen von Aufzählungstypen beginnen mit dem Präfix „DTY_“ und enden mit dem Suffix „Code“. |
Datentyp |
Nachbarsystem |
Architektur |
Ein externes System, mit dem über eine Schnittstelle kommuniziert wird. |
|
Nachbarsystemschnittstelle |
Architektur |
Die Nachbarsystemschnittstelle eines Systems ermöglicht es anderen Systemen, Daten mit diesem zu einem bestimmten fachlichen Zweck auszutauschen. Die Namen von Nachbarsystemschnittstellen sind in der fachlichen Schnittstellenbeschreibung durch den Präfix "NST_" gekennzeichnet. |
Schnittstellen |
Nachbarsystemschnittstellen-Attribut |
Daten |
Ein Nachbarsystemschnittstellen-Attribut entspricht einer einzelnen fachlichen Information, die über die Nachbarsystemschnittstelle ausgetauscht wird. Die Namen der Nachbarsystemschnittstellen-Attribute beginnen mit dem Präfix „NSA_“. Zum Beispiel enthält das Attribut NSA_Staat der Entität NSE_Geburtsort den Staat des Geburtsorts. |
|
Nachbarsystemschnittstellen-Entitätstyp |
Daten |
Nachbarsystemschnittstellen-Entitätstypen gruppieren einzelne, fachliche Attribute der Nachbarsystem-schnittstelle. Nachbarsystemschnittstellen-Entitäten sind konkrete Ausprägungen eines Entitätstyps. Die Namen der Nachbarsystemschnittstellen-Entitätstypen beginnen mit dem Präfix "NSE_“. |
|
Projekt |
Vorgehen |
Ein Projekt ist ein Vorhaben, bei dem innerhalb einer definierten Zeitspanne ein definiertes Ziel erreicht werden soll, und das sich dadurch auszeichnet, dass es im Wesentlichen ein einmaliges Vorhaben ist. |
IT-Projekt |
Protokollierung |
Nichtfunktionale Anforderungen |
Die Protokollierung erfasst Informationen zu fachlichen Abläufen, um diese zu einem späteren Zeitpunkt nachvollziehbar zu machen. Es handelt sich nicht um Logging! |
|
UML-Klassendiagramm |
Methodik |
Ein Klassendiagramm ist in der Informatik eine grafische Darstellung von Entitätstypen sowie der Assoziationen zwischen diesen Entitätstypen. |
|
UML-Komponentendiagramm |
Methodik |
Das Komponentendiagramm ist ein Strukturdiagramm. Es zeigt eine bestimmte Sicht auf die Struktur der modellierten Anwendung. |
|
Unified Modelling Language (UML)_ |
Methodik |
Die Unified Modeling Language (UML) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Anwendungen. |
7.2. Fehlercodes und Fehlertexte
In diesem Kapitel werden alle Fehlercodes und dazugehörige Fehlertexte aufgelistet, die die Schnittstellen zurückliefern können.
In der folgenden Tabelle sind alle Fehlercodes mit den zugehörigen Fehlertexten als Nachschlagewerk aufgelistet.
Fehlercode | Fehlertext |
---|---|
ABCXY0123 |
Die Anfrage konnte nicht verarbeitet werden, da die Anfragenachricht nicht vollständig ist. Es fehlt: Organisation. |