Anforderungsdefinition Integration - diko-project.de

Anforderungsdefinition Integration
Tim Brüggemann, Helge Saathoff, Ralph Stuber, Guido Zendel
15. Mai 2003
1

Inhaltsverzeichnis
1 Ausgangssituation und Zielsetzung 3
2 Systemeinsatz und Systemumgebung 3
3 Funktionale Anforderungen 3
4 Nichtfunktionale Anforderungen 4
5 Benutzerschnittstellen 4
6 Dokumentationsanforderungen 4
7 Abnahmekriterien 5
8 Anhang 5

1 Ausgangssituation und Zielsetzung
Ziel der Integration ist es, die Daten aus verschiedenen Händlerdatenbanken in eine Kartenanbieterdatenbank
zu importieren. Als Arbeitsgrundlage hierfür dienen die bereits
angelegten Datenbanken der zwei Händler und die des Kartenanbieters, die im Rahmen
des ersten Teilprojektes entstanden sind. Für jede der beiden Händlerdatenbanken ist
ein separater Loader zu implementieren.
Die Überlegung, ein zusätzliches Datenbankschema zu erstellen, welches als Zwischendatenbank
zwischen den Händler- und Kartenanbieterdatenbanken fungieren soll, wird
aufgrund des zusätzlichen, hohen Arbeitsaufwands nicht implementiert. Ein Vorteil einer
solchen Zwischendatenbank wäre die einfachere Erweiterbarkeit des Szenarios bzgl.
mehrerer Kartenanbieter. Mit existierender Zwischendatenbank müßte für einen zusätzlichen
Kartenanbieter lediglich ein Loader zur Zwischendatenbank implementiert werden
und nicht ein Loader pro existierendem Händler. Nachteil einer Zwischendatenbank ist,
daß im Falle nur eines Kartenanbieters ein zusätzlicher Loader von der Zwischendatenbank
zum Kartenanbieter geschrieben werden müßte, was eine erhebliche Steigerung
des Arbeitsaufwandes darstellt. Zudem entstünden erhöhte Kosten durch redundante
Datenhaltung und zusätzlichen administrativen Aufwand. Es stellte sich die Frage, ob
einer der Händler oder der Kartenanbieter für die Verwaltung der Zwischendatenbank
verantwortlich ist.
2 Systemeinsatz und Systemumgebung
Als DB dient eine Oracle-Datenbank, die unter Solaris läuft. Die Loader werden in Java
implementiert, woraus eine Plattformunabhängigkeit resultiert, da das Ausführen auf
geeigneten Systemen mit einer Java-Laufzeitumgebung gewährleistet wird.
3 Funktionale Anforderungen
Es werden alle Daten aus den beiden Händlerdatenbanken ausgelesen, um sie anschließend
in die Datenbank des Kartenanbieters einzufügen. Es besteht die Möglichkeit per
Kommandozeilenparameter Einfluss auf die Integration zu nehmen. Dabei können die
Namen der Quell- und Zieldatenbank, die erforderlichen Zugangsdaten zu den Datenbanken,
der Treiber der zum Zugriff auf die Datenbank nötig ist sowie der Name des
Rechensystems auf dem die Datenbank läuft übergeben werden. Eine genauere Schnittstellendefinition
erfolgt im Gliederungspunkt Benutzerschnittstellen.// Das Programm
besteht aus insgesamt vier Klassen, wobei eine Klasse für die Datenbankverbindung,
eine Klasse zur Steuerung des Programmablaufs und jeweils eine Klasse für den Import
der Daten eines Händlers zuständig ist. Das Schema für die Datenübertragung zwischen
Händlerdatenbanken und Kartenanbieterdatenbank wird in Tabellenform im Angang
dargestellt.

4 Nichtfunktionale Anforderungen
Nichtfunktionale Anforderungen für das System sind
Portabilität (Plattformunabhängigkeit)
Stabilität (leichtes Abfangen von Fehlern)
Benutzerfreundlichkeit (Übergabe von Steuerungsparametern)
Wart- und Erweiterbarkeit (Übersichtliche Programmstruktur + Dokumentation)
Sicherheit (Zugriff auf die Datenabnken nur für berechtigte Nutzer)
Großer Wert wird zudem auf eine umfassende Dokumentation des Systems gelegt.
5 Benutzerschnittstellen
Das Programm läßt sich aus einer Kommandozeile mit Kommandozeilenparametern starten.
So können die folgenden acht Parameter int sourceDB, int targetDB, String hostNameSDB,
String driverSDB, String userSDB, String passwdSDB, String hostNameTDB,
String driverTDB, String userTDB und String passwdTDB optional übergeben werden.
In diesem Falle werden diese Parameter für die Integration genutzt. Weiterhin existiert
die Möglichkeit, nur die sechs Kommandozeilenparameter int sourceDB, int targetDB,
String usersSDB, String passwdSDB, String userTDB und String passwdTDB zu übergeben.
Bei dieser Lösung werden die Werte für hostNameSDB, hostNameTDB sowie
driverSDB und driverTDB fest im Programm codiert. Schließlich kann bei initialem
Import auch der Kommandozeilenparamter init aufgerufen werden, um die Kartenanbieterdatenbank
auf die Importe der Daten aus den Händlerdatenbanken vorzubereiten
(Anlegen von Werten für LOV-Tabellen usw.). Auf das Auftreten von Fehlern soll das
Programm mit Programmabbruch und Ausgabe eines Fehlertextes reagieren. Folgende
Fehler können auftreten:
1. Fehlerhafte Zugangsdaten. Verhalten: kein Verbindungsaufbau.
2. Fehler in der Datenbank (z.B. Attributname geändert). Verhalten: Angabe der
Fehlerquelle.
3. Verbindungsabbruch. Verhalten: Fehlermeldung
6 Dokumentationsanforderungen
Die Dokumentation des Programms umfaßt folgende Punkte:
Anforderungsdefinition (dieses Dokument)
Entwurf

Dokumentierter Sourcecode
System-Dokumentation bestehend aus Benutzer- und Developer-Handbuch
Die Dokumentation soll in elektronischer Form erfolgen.
7 Abnahmekriterien
Die funktionalen Anforderungen sollen erfüllt werden, nichtfunktionale Anforderungen
sollen möglichst vollständig implementiert werden. Sämtliche für den Kartenanbieter relevanten
Daten aus den Händlerdatenbanken sollen von dem Programm in die Kartenanbieter-
Datenbank übernommen werden. Der Kartenanbieter hat dabei keine Möglichkiet auf
die Auswahl der Daten Einfluss zu nehmen, da die Auswahl der Daten fest in den Methoden
der Importklassen codiert sind. Somit ist auch keine Metadatensteuerung, die
prinzipiell möglich wäre, vorgesehen.
8 Anhang
Die im Anhang enthaltenen Tabellen dienten als Ausgangslage für die Arbeit der Integration.
Sie beinhalten alle Attribute und Wertebereiche der beiden Händlerdatenbanken.
Diese werden nun den entsprechenden Attributen der Kartenanbieterdatenbank
gegenübergestellt, wobei einzelne Attribute im Kartenanbieterschema erst noch generiert
werden mussten (generieren).

Abbildung 1: Relation kunde mit karte

Abbildung 2: Relation kunde ohne karte
Abbildung 3: Relation Filiale
Abbildung 4: Relation Kategorie
Abbildung 5: Relation Preis

Abbildung 6: Relation Artikel
Abbildung 7: Relation Position
Abbildung 8: Relation Bon

Abbildung 9: Relation Kunde
Abbildung 10: Relation Adresse

Abbildung 11: Relation Profil
Abbildung 12: Relation Produkt

Abbildung 13: Relation Kategorie
Abbildung 14: Relation Hersteller

Abbildung 15: Relation Produkt Warenkorb
Abbildung 16: Relation Warenkorb

Abbildung 17: Relation Attribut
Abbildung 18: Relation Text Attribut