AK VRZ

Verkehrsrechnerzentralen

SW-Architektur

Segment Parametrierung und Konfiguration (PuK)

SW-Einheit Konfiguration

Ersteller:
Autor:	Dipl.-Inform. R. Schmitz
Version:	1.0
Stand:	05.04.2005
Status:	akzeptiert
PID:	SE-02.08.01.00.00-SwArc-0.1
Submodell:	Systementwicklung
Projekt ID AG:	AK VRZ
Projekt ID AN:	BAST.06.006/BAST.07.007

Kappich+Kniß Systemberatung Verkehr und Technik

Im Auftrag der Bundesanstalt für Straßenwesen BASt

1  Allgemeines

Verteilerliste

Entfällt. Dokumentverteilung entsprechend aktuellem Projektverteiler.

Versionsübersicht

Tabelle 1-1: Versionsübersicht

Änderungsübersicht

Tabelle 1-2: Änderungsübersicht

Kurzbeschreibung

In diesem Produkt wird die SW-Architektur der SW-Einheit Konfiguration beschrieben.

Inhaltsverzeichnis

1 Allgemeines

2 SW-Einheit Konfiguration

2.1 Lösungsvorschläge

2.2 Modularisierung/Datenbankentwurf

2.2.1 Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken

2.2.2 Einzelbeschreibungen

2.2.2.1 Modul Verwaltung

2.2.2.2 Modul Konfigurationseditor

2.2.2.3 Modul Versorgungsdateizugriff

2.2.2.4 Modul Konfigurationsdateizugriff

2.2.2.5 Modul Datenrepräsentation

2.2.3 Dynamisches Ablaufmodell

2.2.4 Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

2.2.5 Sonstige Entwurfsentscheidungen

2.3 Schnittstellen

2.3.1 Externe Schnittstellen der SW-Einheit

2.3.2 Interne Schnittstellen der SW-Einheit

2.4 Anforderungszuordnung

3 SW-Einheit Parametrierung

3.1 Lösungsvorschläge

3.1.1 Kriterien zur Zerlegung der SW-Einheit

3.1.2 Skizzierung der gewählten Lösung

3.2 Modularisierung/Datenbankentwurf

3.2.1 Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken

3.2.2 Einzelbeschreibungen

3.2.2.1 Modul Methodenbibliothek

3.2.2.2 Modul Kern

3.2.3 Dynamisches Ablaufmodell

3.2.4 Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

3.2.5 Sonstige Entwurfsentscheidungen

3.3 Schnittstellen

3.3.1 Externe Schnittstellen der SW-Einheit

3.3.2 Interne Schnittstellen der SW-Einheit

3.4 Anforderungszuordnung

Abkürzungen

(siehe Abkürzungsverzeichnis AK VRZ)

Definitionen

(siehe Glossar AK VRZ)

Verzeichnis der Tabellen

Tabelle 1-1: Versionsübersicht

Tabelle 1-2: Änderungsübersicht

Tabelle 2-1: Identifizierung der SW-Komponenten und Module

Tabelle 2-2: Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

Tabelle 2-3: Übersicht der externen Schnittstellen der SW-Einheit Konfiguration

Tabelle 2-4: Übersicht der internen Schnittstellen der SW-Einheit Konfiguration

Tabelle 2-5: Anforderungszuordnung

Tabelle 3-1: Identifizierung der SW-Komponenten und Module

Tabelle 3-2: Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

Tabelle 3-3: Übersicht der externen Schnittstellen der SW-Einheit Parametrierung

Tabelle 3-4: Übersicht der internen Schnittstellen der SW-Einheit Parametrierung

Tabelle 3-5: Anforderungszuordnung

Verzeichnis der Abbildungen

Abbildung 2-1:  Strukturierung der SW-Einheit Konfiguration

Abbildung 2-2: Schnittstellen der SW-Module

Abbildung 2-3: Arbeitsmodi der Konfiguration

Abbildung 3-1:  Strukturierung der SW-Einheit Parametrierung

Referenzierte Dokumente

2  SW-Einheit Konfiguration

2.1  Lösungsvorschläge

Hauptkriterien für die Zerlegung der SW-Einheit in Module sind:

• Wiederverwendbarkeit von Modulen

  Wenn absehbar ist, das bestimmte Funktionen der SW-Einheit auch an anderen Stellen im System benötigt werden, dann führt eine entsprechende Modularisierung dazu, dass die jeweiligen Funktionen einfach durch Wiederverwendung der entsprechenden Module in andere SW-Einheiten übernommen werden können.

  Andererseits wird die Architektur natürlich durch die Wiederverwendung von Modulen aus anderen Stellen des Systems oder durch die Verwendung von verfügbaren kommerziellen oder Open-Source basierten Fremdmodulen beeinflusst.

• Austauschbarkeit von Modulen

  Die Austauschbarkeit von Modulen innerhalb einer SW-Einheit ist wichtig, um eine Flexibilität bezüglich der Implementierung bestimmter Funktionen zu erreichen.

  Mit dem Austausch eines Moduls durch eine anderes Modul mit gleichen Schnittstellen kann zum einen bei gleicher Funktion des Moduls die Art der Implementierung einfach verändert werden und zum anderen die Funktion des Moduls flexibel verändert werden.

  Die Flexibilität kann so weit gehen, dass erst zur Laufzeit der Applikation mit Hilfe von Konfigurationsdaten, Aufrufargumenten oder Parametern entschieden wird, welche Module zum Einsatz kommen.

• Erweiterbarkeit der SW-Einheit durch weitere Module mit gleicher Schnittstelle

  Die Erweiterbarkeit einer SW-Einheit um weitere Modulen kann ähnlich wie bei der Austauschbarkeit von Modulen über eine entsprechende Schnittstelle vorgesehen werden. Damit erhält die SW-Einheit die notwendige Flexibilität, um zu späteren Zeitpunkten durch weitere Module mit anderen Funktionen ergänzt zu werden.

• Geringe Schnittstellenkomplexität

  Eine geringe Komplexität der Schnittstellen zwischen den Modulen ist erforderlich, um die Wiederverwendung zu fördern und die Wartbarkeit und Nutzbarkeit der jeweiligen Schnittstellen zu erhöhen.

  Folgende Ziele, die zu einer geringen Schnittstellenkomplexität beitragen, sind wesentliche Kriterien für die Modularisierung:

  • Hoher Grad an Abgeschlossenheit der Module
  • Schwache Kopplung der Module untereinander
  • Enge Bindung innerhalb eines Moduls

Wenn mehrere Module gemeinsam einen Funktionskreis implementieren, werden sie zu Komponenten zusammengefasst.

Die sich aus dieser Vorgehensweise herauskristallisierte Modularisierung wird in den folgenden Kapiteln dargestellt.

2.2  Modularisierung/Datenbankentwurf

2.2.1  Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken

Die SW-Einheit Konfiguration setzt sich aus den folgenden Modulen zusammen:

• Modul Verwaltung
• Modul Konfigurationseditor
• Modul Versorgungsdateizugriff
• Modul Konfigurationsdateizugriff
• Modul Datenrepräsentation

Eine weitere Strukturierung in Komponenten ist nicht erforderlich:

Abbildung 2-1: Strukturierung der SW-Einheit Konfiguration

In der folgenden Tabelle sind die Komponenten und Module mit ihren eindeutigen Identifikatoren dargestellt:

Tabelle 2-1: Identifizierung der SW-Komponenten und Module

2.2.2  Einzelbeschreibungen

Die folgende Abbildung zeigt die SW-Module und SW-Komponenten sowie die interne Kommunikationsstruktur der SW-Einheit:

Abbildung 2-2: Schnittstellen der SW-Module

2.2.2.1  Modul Verwaltung

Das Modul "Verwaltung" übernimmt wesentliche Verwaltungsaufgaben der Konfiguration und die Koordination der weiteren Module der SW-Einheit.

• Interpretation der Aufrufparameter und Steuerung des Arbeitsmodus (siehe Kapitel 2.2.3 Dynamisches Ablaufmodell).
• Zugriff auf die Verwaltungsdaten der Konfiguration.
• Steuerung von Persistenz, Übernahme, Import und Export von Konfigurationsdaten.
• Bereitstellung und Änderung von Konfigurationsdaten für Applikation.
• Unterstützung der Simulation.
• Authentifizierung von Benutzern und Zugang zu den Authentifizierungsdaten.
• Konsistenzprüfung von Konfigurationsdaten
• Koordination der Module innerhalb der SW-Einheit

Über das Modul Konfigurationseditor wird eine Nutzerschnittstelle zur interaktiven Versorgung angebunden und über das Modul Versorgungsdateizugriff wird der Import und Export von Versorgungsdaten ermöglicht. Die Verwaltung stellt für diese Module eine Verbindung zu den Konfigurationsdaten entweder direkt über das Modul Konfigurationsdateizugriff oder indirekt über Datenverteilerkommunikation zu einer anderen Instanz der SW-Einheit her.

2.2.2.2  Modul Konfigurationseditor

Das Modul Konfigurationseditor implementiert sämtliche Funktionen der Nutzerschnittstelle zur interaktiven Versorgung des Systems auf Basis des Datenmodells. Dazu gehören insbesondere die generische Visualisierung und Änderung von Konfigurationsdaten über entsprechende Dialoge und ein Zugang zur Steuerung von Konsistenzprüfung, Aktivierung und Freigabe von Konfigurationsdaten über entsprechende Interaktionen.

Die Entkopplung der Nutzerschnittstelle von den restlichen Funktionen der Konfiguration war wesentliches Kriterium für die gewählte Zerlegung durch die aber auch die Austauschbarkeit und Erweiterbarkeit mit der Nutzerschnittstelle ermöglicht wird.

2.2.2.3  Modul Versorgungsdateizugriff

Das Modul "Versorgungsdateizugriff" realisiert den lesenden und schreibenden Zugriff auf Versorgungsdatein für die Zwecke des Imports und Exports von Konfigurationsdaten und definiert das XML-basierte Format der exportierten bzw. zu importierenden Daten in Versorgungsdateien.

Das Modul verkapselt alle spezifischen Funktionen zum Umgang mit Versorgungsdateien und entkoppelt so die formatabhängigen Funktionen des Konfigurationsdatenimports und -exports von den formatunabhängigen Funktionen. Die Austauschbarkeit des Dateiformats und die Erweiterbarkeit durch andere Dateiformate wird ermöglicht.

2.2.2.4  Modul Konfigurationsdateizugriff

Das Modul "Konfigurationsdateizugriff" realisiert den lesenden und schreibenden Zugriff auf Konfigurationsdateien in einem plattformneutralen Format. In einer Konfigurationsdatei werden sämtliche Konfigurationsdaten eines Konfigurationsbereichs gespeichert.

Die Schnittstelle zum Zugriff auf die Konfigurationsdaten, die vom Modul Verwaltung genutzt wird, stimmt weitestgehend mit demjenigen Teil der Datenverteiler-Applikationsfunktionen überein, über den "normale" Applikationen auf die Konfigurationsdaten zugreifen.

Damit wird z.B. ermöglicht, dass die Zugriffe auf Konfigurationsdaten im Arbeitsmodus "Konfigurationseditor" (siehe Kapitel 2.2.3 Dynamisches Ablaufmodell) vom Modul Verwaltung transparent für das Modul Konfigurationseditor entweder

• direkt über das Modul Konfigurationsdateizugriff aus den lokalen Konfigurationsdateien oder
• indirekt über die Datenverteilerkommunikation von einer anderen Instanz der SW-Einheit Konfiguration

befriedigt werden.

Wesentlicher Aspekt für die gewählte Zerlegung ist die Schnittstelle zur Verwaltung, die auch einen indirekten Zugriff über die Datenverteilerkommunikation ermöglicht.

2.2.2.5  Modul Datenrepräsentation

Das Modul Datenrepräsentation realisiert die eindeutige plattformneutrale Abbildung der in Konfigurationsanfragen und -antworten übertragenen Konfigurationsdaten auf einen Bytestrom Dieses Modul wurde bereits in [SwArcDaVDAF] identifiziert und beschrieben. Es wird in die SW-Einheit Konfiguration übernommen und damit wiederverwendet.

2.2.3  Dynamisches Ablaufmodell

Die Konfiguration kann in folgenden verschiedenen Arbeitsmodi parallel gestartet werden:

• Import von Versorgungsdateien
• Export von Versorgungsdateien
• Konfigurationseditor zur interaktiven Versorgung
• Konfiguration als dienstleistender Hintergrundprozeß für andere Applikationen des Systems

Über Aufrufparameter beim Start der Applikation wird gesteuert, in welchem der verschiedenen Arbeitsmodi die SW-Einheit arbeiten soll.

Die drei gelben Kreise in der folgenden Abbildung stellen eigenständige Prozesse als unterschiedlich parametrierte Instanzen der gleichen Softwareeinheit dar.

Abbildung 2-3: Arbeitsmodi der Konfiguration

Im Arbeitsmodus "Konfiguration", d.h. als dienstleistender Hintergrundprozeß wird die Konfiguration üblicherweise für jeden organisatorischen Bereich im Sinne der Anwenderforderungen [Afo] genau einmal gestartet. Dieser Prozeß stellt den Applikationen des organisatorischen Bereichs über die Datenverteilerkommunikation einen Zugang zu den Konfigurationsdaten zur Verfügung.

In den Arbeitsmodi "Import", "Export" und "Konfigurationseditor" wird die Konfiguration je nach Bedarf des Anwenders gestartet. Dieser Prozeß nimmt dann über die Datenverteilerkommunikation Verbindung mit der Instanz der Konfiguration auf, die im Arbeitsmodus "Konfiguration" die Konfigurationsdaten verwaltet.

Um auch während der Aufbauphase eines Systems die Konfiguration in den Arbeitsmodi "Import", "Export" und "Konfigurationseditor" nutzen zu können ist es auch möglich, dass diese Prozesse direkt auf die Verwaltungsdaten und Konfigurationsdaten der Konfiguration zugreifen.

2.2.4  Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

Die Kritikalität der einzelnen SW-Komponenten und Module ist in der folgenden Tabelle aufgeführt:

Tabelle 2-2: Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

2.2.5  Sonstige Entwurfsentscheidungen

Es wurden keine sonstigen Entwurfsentscheidungen getroffen.

2.3  Schnittstellen

2.3.1  Externe Schnittstellen der SW-Einheit

Tabelle 2-3 Übersicht der externen Schnittstellen der SW-Einheit Konfiguration folgende Tabelle gibt eine Übersicht der externen Schnittstellen der SW-Einheit Konfiguration. Dabei sind pro Schnittstelle die beiden Kommunikationspartner und eine Kurzbeschreibung zum Zweck der Schnittstelle angegeben.

Die detaillierte Beschreibung der Schnittstellen erfolgt in [SSB].

Tabelle 2-3: Übersicht der externen Schnittstellen der SW-Einheit Konfiguration

2.3.2  Interne Schnittstellen der SW-Einheit

Tabelle 2-4 Übersicht der internen Schnittstellen der SW-Einheit Konfiguration zeigt die internen Schnittstellen der SW-Einheit Konfiguration. Dabei wird jede Schnittstelle namentlich aufgeführt und es wird durch Markierungen im rechten Teil der Tabelle gekennzeichnet, zwischen welchen Modulen die Schnittstelle angesiedelt ist. Die Beschreibung der Schnittstellen erfolgt in [SSB].

Tabelle 2-4: Übersicht der internen Schnittstellen der SW-Einheit Konfiguration

2.4  Anforderungszuordnung

In der folgenden Tabelle ist die Zuordnung der Anforderungen aus den technischen Anforderungen [TAnfPuK] auf die SW-Einheit, Komponenten, Subkomponenten bzw. Module angegeben:

Tabelle 2-5: Anforderungszuordnung

3  SW-Einheit Parametrierung

3.1  Lösungsvorschläge

3.1.1  Kriterien zur Zerlegung der SW-Einheit

Die Kriterien zur Zerlegung der SW-Einheit sind in Kapitel 2.1 Lösungsvorschläge aufgeführt.

Die sich aus dieser Vorgehensweise herauskristallisierte Modularisierung wird in den folgenden Kapiteln dargestellt.

3.1.2  Skizzierung der gewählten Lösung

Abbildung 3-1 Strukturierung der SW-Einheit Parametrierung zeigt die Zerlegung der SW-Einheit in SW-Komponenten und SW-Module sowie die interne Kommunikationsstruktur der SW-Einheit, die sich unter Berücksichtigung der oben erläuterten Kriterien ergibt:

Abbildung 3-1: Strukturierung der SW-Einheit Parametrierung

3.2  Modularisierung/Datenbankentwurf

3.2.1  Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken

Die SW-Einheit Parametrierung setzt sich aus den folgenden Modulen zusammen:

• Modul Methodenbibliothek
• Modul Kern

In der folgenden Tabelle sind die Komponenten und Module mit ihren eindeutigen Identifikatoren dargestellt:

Tabelle 3-1: Identifizierung der SW-Komponenten und Module

3.2.2  Einzelbeschreibungen

3.2.2.1  Modul Methodenbibliothek

Im Modul Methodenbibliothek werden Methoden zur Verfügung gestellt, die von Applikationen zum Informationsaustausch mit dem Modul Kern der Parametrierung verwendet werden.

3.2.2.2  Modul Kern

Im Modul Kern findet die eigentliche Verwaltung und Bereitstellung der Parameter und deren persistente Speicherung statt. Dort werden Objekthierarchien ausgewertet und bearbeitet und die Verteilung von globalen Parametern vorgenommen.

3.2.3  Dynamisches Ablaufmodell

Bei dieser SW-Einheit sind keine Vorgaben zum dynamischen Ablaufmodell notwendig.

3.2.4  Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

Die Kritikalität der einzelnen SW-Komponenten und Module ist in der folgenden Tabelle aufgeführt:

Tabelle 3-2: Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

3.2.5  Sonstige Entwurfsentscheidungen

Es wurden keine sonstigen Entwurfsentscheidungen getroffen.

3.3  Schnittstellen

3.3.1  Externe Schnittstellen der SW-Einheit

Tabelle 3-3 Übersicht der externen Schnittstellen der SW-Einheit Parametrierung gibt eine Übersicht der externen Schnittstellen der SW-Einheit Parametrierung. Dabei sind pro Schnittstelle die beiden Kommunikationspartner und eine Kurzbeschreibung zum Zweck der Schnittstelle angegeben.

Die detaillierte Beschreibung der Schnittstellen erfolgt in [SSB].

Tabelle 3-3: Übersicht der externen Schnittstellen der SW-Einheit Parametrierung

3.3.2  Interne Schnittstellen der SW-Einheit

Tabelle 3-4 Übersicht der internen Schnittstellen der SW-Einheit Parametrierung zeigt die internen Schnittstellen der SW-Einheit Parametrierung. Dabei wird jede Schnittstelle namentlich aufgeführt, und es wird durch Markierungen im rechten Teil der Tabelle gekennzeichnet, zwischen welchen Modulen die Schnittstelle angesiedelt ist. Die Beschreibung der Schnittstellen erfolgt in [SSB].

Tabelle 3-4: Übersicht der internen Schnittstellen der SW-Einheit Parametrierung

3.4  Anforderungszuordnung

In der folgenden Tabelle ist die Zuordnung der Anforderungen aus den technischen Anforderungen [TAnfPuK] auf die SW-Einheit, Komponenten, Subkomponenten bzw. Module angegeben:

Tabelle 3-5: Anforderungszuordnung