Projektmanagement und SiSy

Berufsakademie Sachsen
Laser & Co. Solutions GmbH
Staatliche Studienakademie Bautzen
Promenadenring 8
Studienrichtung Wirtschaftsinformatik
02702 Löbau
Entwicklung einer prototypischen Schnittstelle zwischen dem
SiSy-Repository und externen Datenformaten
Diplomarbeit zur Erlangung
des Grades Diplom-Wirtschaftsinformatiker
der Studienrichtung Wirtschaftsinformatik
eingereicht von
Renè Platzk
Seminargruppe BW 00 WI
Studien-Nr. 00WI26
am 08.08.2003
Prüfer und Gutachter:
Herr Prof. Dr. rer. nat. Ralph Großmann, Staatliche Studienakademie Bautzen
Herr Dipl.-Ing. Päd Alexander Huwaldt, Laser & Co. Solutions GmbH
2
3
Thesen
Platzk, René: Entwicklung einer prototypischen Schnittstelle zwischen dem
SiSy-Repository und externen Datenformaten, Berufsakademie Sachsen,
Staatliche Studienakademie Bautzen, Studienrichtung Wirtschaftsinformatik,
Diplomarbeit, 2003. - 73 Seiten, 19 Literaturquellen, 9 Onlinequellen, 1
Softwareprodukt, 7 Anlagen.
-
Eine Schnittstelle des Softwareprodukts SiSy zu externen Datenformaten
erweitert dessen Kompatibilität.
-
Als Exportformate wurden CSV, XML und MySQL gewählt, da diese
moderne Techniken darstellen und von SiSy-Nutzern als Exportformate
gefordert werden.
-
In SiSy existieren bereits einige Schnittstellen, durch die ein Datenexport
in andere Systeme realisiert wurde.
-
Für den Entwurf der Schnittstelle in SiSy, ist der Entwurf weiterer
SiSyBasic-Klassen mit Funktionen notwendig.
-
Die SiSyBasic-Klassen werden in der Programmiersprache C++ realisiert
und durch die „Assi.exe“ bereitgestellt.
-
Beim Datenexport in die Formate CSV und XML werden jeweils Dateien
mit konformem Inhalt erzeugt.
-
Die Schnittstelle zur MySQL-Datenbank wird über eine ODBCSchnittstelle in Visual C++ realisiert.
-
Für die Verwendung der Schnittstelle sollte das Augenmerk auf die
Verwendung der Daten gelegt werden.
4
Autorenreferat
Platzk, René: Entwicklung einer prototypischen Schnittstelle zwischen dem
SiSy-Repository und externen Datenformaten, Berufsakademie Sachsen,
Staatliche Studienakademie Bautzen, Studienrichtung Wirtschaftsinformatik,
Diplomarbeit, 2003. - 73 Seiten, 19 Literaturquellen, 9 Onlinequellen, 1
Softwareprodukt, 7 Anlagen.
Die Schnittstellen zwischen verschiedenen Softwareprodukten gewinnen für
Unternehmen immer mehr an Bedeutung, um die Kompatibilität ihres
Programms zu Standardsoftware und somit zu Standards der Industrie zu
erweitern. Diese Arbeit soll die Entwicklung einer Schnittstelle zwischen dem
Softwareprodukt SiSy und externen Datenformaten CSV, XML und MySQL
darlegen.
In einem einleitenden Kapitel wird das Ziel dieser Arbeit spezifiziert und die
Firma Laser & Co. Solutions GmbH mit Ihrem Produkt SiSy vorgestellt.
Danach folgt Vorbetrachtung der thematischen Grundlagen. Hierbei wird u.a.
auf Datenbanken und deren Modelle eingegangen, und die Exportformate
CSV, XML und MySQL näher erläutert.
Anschließend erfolgt die Analyse des Softwareprodukts SiSy und dessen
Schnittstellen. Danach wird auf die Entwicklung der Schnittstelle einer
ODBC-Schnittstelle unter Visual C++ analysiert.
Aus Anforderungen der Analyse wird im darauf folgenden Kapitel ein Entwurf
für die Schnittstelle abgeleitet und die Realisierung kurz erläutert.
In einem abschließenden Kapitel wird der Entwicklungsstand der
Schnittstelle bewertet und ein Ausblick auf weitere, daraus folgende
Entwicklungen gegeben.
5
Inhalt
Abkürzungsverzeichnis .......................................................................................6
1
Einleitung ................................................................................................7
1.1
Ziel ..........................................................................................................7
1.2
Die Laser & Co. Solutions GmbH und SiSy®..........................................8
1.3
Vorgehen ................................................................................................9
2
Theoretische Vorbetrachtung ................................................................11
2.1
Begriffe..................................................................................................11
2.2
Datenbanktheoretische Grundlagen......................................................14
2.3
MySQL ..................................................................................................18
2.4
XML.......................................................................................................21
2.5
CSV.......................................................................................................27
3
Analyse .................................................................................................30
3.1
Simple Systems®..................................................................................30
3.2
Beispiel der Organisationssicht in SiSy® ..............................................37
3.3
ODBC unter Visual C++ ........................................................................39
3.4
Anforderungen ......................................................................................45
4
Entwurf und Realisierung der Schnittstelle............................................48
4.1
Die Skript-Ebene ...................................................................................51
4.2
Die Dialog-Ebene ..................................................................................54
4.3
Die Klassen-Ebene ...............................................................................59
4.4
Realisierung ..........................................................................................62
5
Schlussbetrachtungen...........................................................................64
5.1
Ergebnisse ............................................................................................64
5.2
Ausblick.................................................................................................65
Literaturverzeichnis...........................................................................................67
Onlinequellen ....................................................................................................69
Softwareprodukte..............................................................................................69
Abbildungsverzeichnis ......................................................................................70
Tabellenverzeichnis ..........................................................................................71
Anlagenverzeichnis...........................................................................................72
6
Abkürzungsverzeichnis
ANSI
American National Standards Institute
CASE
Computer Aided Software Engineering
CSV
Comma Separated Values
DB
Database
DBMS
Datenbankmanagementsystem
DCL
Data Controll Language
DDE
Dynamic Data Exchange
DDL
Data Definition Language
DIN
Deutsche Industrie Norm
DML
Data Manipulation Language
DTD
Dokumententyp-Definition
DV
Datenverarbeitung
EDV
Elektronische Datenverarbeitung
ERD
Entity-Relationship-Diagram
GPL
General Public Licence
GUI
Graphical User Interface
ISO
International Standard Organisation
HTML
Hypertext Markup Language
MS
Microsoft
ODBC
Open Database Connectivity
SiSy
Simple System
SQL
Structured Query Language
UML
Unified Modelling Language
URL
Uniform Resource Locator
URR
User Requirements Review
XML
Extensible Markup Language
7
1 Einleitung
Bis vor einigen Jahren zeichneten sich Software-Lösungen durch ihre
Eigenständigkeit und Inkompatibilität aus, um jegliche direkte Konkurrenz zu
vermeiden. Mittlerweile hat man erkannt, dass diese Inkompatibilität der ITBranche schadet. So wurde die Forderung nach offenen Systemen und
herstellerunabhängigen Standards immer größer. Dabei ist wichtig, dass eine
Anwendung auf Daten in einem Netzwerk auf beliebige Rechner zugreifen und
sogar Daten transferieren kann. Um dies umzusetzen, sind standardisierte
Schnittstellen zwischen Anwendungen und Daten von immenser Bedeutung.
1.1 Ziel
Die Firma Laser & Co. Solutions GmbH hat die Bedeutung von Schnittstellen zu
anderen Systemen erkannt und ist zu dem Schluss gekommen ihr SoftwareProgramm SiSy® flexibler zu gestalten. Das Unternehmen möchte nun
Schnittstellen zum Export von Daten in andere Systeme zur Verfügung stellen.
Speziell soll eine Schnittstelle entwickelt werden, mit dessen Hilfe modellierte
Daten, aus SiSy®, in externe Datenformate exportiert werden können, wie das
Komponentendiagramm in der Abbildung 1 verdeutlicht.
Das Komponentendiagramm ist ein Diagramm der Unified Modelling Language,
kurz UML. Es verwendet verschiedene Objekte und ist in Anlage 1 genauer
erklärt. Die Würfel stellen Systeme dar, in denen sich verschiedene
Komponenten befinden.
Nutzer
externe
Datenformat
SiSy
Schnittstelle
Abbildung 1 Grobentwurf der Schnittstelle
8
Diese Arbeit soll die Entwicklung der Schnittstellen zwischen dem SoftwareSystem SiSy® und externen Datenformaten darlegen. Die dabei in Betracht
gezogenen Datenformate sind XML, MySQL und CSV. Diese Formate wurden
gewählt, da sie den Fortschritt verschiedener Techniken repräsentieren und
somit einerseits eine Umstellung auf diese Techniken in SiSy® notwendig
machen, andererseits die Verarbeitung bzw. die Bereitstellung dieser Formate
von Nutzern gefordert wird.
1.2 Die Laser & Co. Solutions GmbH und SiSy®
Die Firma Laser & Co. Solutions GmbH, in welcher der Autor seine
Praxissemester absolvierte, kann auf mehr als zehn Jahre erfolgreiches Wirken
in der IT-Branche zurückblicken. Sie beschäftigt ca. sieben Mitarbeiter und
zusätzlich eine differierende Anzahl von Studenten und Praktikanten.
Die Leistungserstellungsprozesse der Laser & Co. Solutions GmbH reichen von
der Entwicklung des Software-Produktes SiSy®, über die Realisierung von
Individuallösungen bis hin zur Schulung. Im Bereich der Entwicklung wird mit
dem Qualitätsmanagementsystem nach ISO 9001:2000 gearbeitet, das mit Hilfe
des eigenen Software-Produktes SiSy® erarbeitet wurde.
Das Software-System SiSy® ist ein universelles Modellierungstool, mit dessen
Hilfe es möglich ist nicht nur ein Qualitätsmanagementsystem nach ISO
9001:2000 zu erstellen, sondern kann es auch unterstützend bei der
Strukturierten und der Objektorientierten Systementwicklung verwendet werden.
Die strukturierte Vorgehensweise der Systementwicklung unterstützt SiSy® u.a.
mit der Strukturierten Analyse, dem Strukturierten Design, dem ERD und mit
dem Struktogramm. Durch die Diagramme der UML, die in SiSy® realisiert
wurden, ist es möglich mit SiSy® die Objektorientierte Systementwicklung
durchzuführen.
Ebenfalls bietet SiSy® die Möglichkeit Netzwerke zu modellieren und zu planen
mit dem Vorgehensmodell zum Netzwerkentwurf.
9
1.3 Vorgehen
Das Vorgehen in dieser Arbeit selbst richtet sich am Wasserfallmodell von
Boehm1) aus. Es ist ein klassisches Vorgehensmodell des SoftwareEngineerings. Das Wasserfallmodell beschreibt den organisatorischen Ablauf
der Entwicklung eines Systems durch die Einteilung in verschiedene und
aufeinander aufbauende Phasen, wie z.B. Analyse-, Entwurfs- und
Realisierungsphase, anhand eines Wasserfalls Die Abbildung 2 zeigt das
klassische Wasserfallmodell.
Analyse
Entwurf
Realisierung
Test
Einführung
Abbildung 2 Das Wasserfallmodell
Bei diesem Modell wird in jeder Phase ein Teilergebnis erarbeitet, welches der
sich anschließenden Phase übergeben wird. Es wird also jede Phase
sequentiell nacheinander abgearbeitet. Dies ist aber für die Praxis unrealistisch,
und so wurden dem Wasserfallmodell Rücksprünge von einer Phase auf die
vorangegangene hinzugefügt, wie ebenfalls in der Abbildung 2 zu sehen ist. In
der Arbeit wurde der Schwerpunkt auf die Phasen der Analyse, des Entwurfs
und der Realisierung gesetzt.
Nachdem nun einleitende Worte gesagt sind, wird im Folgenden eine
theoretische Vorbetrachtung stattfinden, um thematische Grundlagen für das zu
bearbeitende Thema zu schaffen. Hierbei sollen zunächst Begriffe erläutert und
1)
Vgl. [3]
10
der Aufbau von Schnittstellen kurz dargestellt werden. Weiterhin werden die
ausgewählten Datenformate betrachtet.
Danach folgt eine Analyse des Softwaresystems SiSy® und der darin
vorhandenen Schnittstellen. Dabei wird auf den Aufbau dieser Schnittstellen
näher eingegangen.
Nachdem das System SiSy® mit seinen Schnittstellen analysiert wurde, erfolgt
der Entwurf der Schnittstelle zu den externen Datenformaten XML, MySQL und
CSV.
Anschließend wird auf die Realisierung der Schnittstelle gemäß dem
Wasserfallmodell eingegangen. Zum Schluss erfolgt die Schlussbetrachtung
Auswertung der Arbeitsergebnisse. Die Perspektiven und
Verbesserungsvorschläge bezüglich der prototypischen Schnittstelle werden
ebenfalls aufgezeigt
11
2 Theoretische Vorbetrachtung
Dieses Kapitel dient dazu Grundbegriffe im zu betrachtenden Themengebiet zu
klären und die einzelnen Datenformate näher zu erläutern. Dabei wird zunächst
auf den Begriff „Schnittstelle“ näher eingegangen und Datenbanktheoretische
Grundlagen erläutert.
2.1 Begriffe
2.1.1 Schnittstelle
Schnittstellen werden in der EDV oft eng mit den Begriffen Integration,
Vereinheitlichung, Kompatibilität, Nutzung von Standards oder Interoperabilität
verknüpft. Diese Stichworte geben eine Zielrichtung der Verwendung von
Schnittstellen an, definieren den Begriff einer Schnittstelle, engl. Interface, aber
nicht:
„Nach DIN 44300, Teil 1, versteht man generell unter einer Schnittstelle
den Übergang an der Grenze zwischen zwei gleichartigen Einheiten mit
vereinbarten Regeln für die Übergabe von Daten und Signalen“, „zitiert
nach 2)“
Die Abbildung 3 zeigt und verdeutlicht das Prinzip einer Schnittstelle.
Einheit
Schnittstelle
Einheit
Abbildung 3 Prinzip einer Schnittstelle
Die Einheiten können alle verschiedenen Ebenen einer DV-Anwendung sein,
beispielsweise die Benutzeroberfläche oder Daten bzw. Datenbank.
Da diese Arbeit sich mit Schnittstellen der Ebene der Datenbank beschäftigt soll
im folgenden Kapitel nun auf die Datenbankschnittstellen näher eingegangen
werden.
2)
Vgl. [7] S. 6
12
2.1.2 Datenbankschnittstelle
Bei einer Spezifikation einer Schnittstelle für den Datenaustausch zwischen
zwei Systemen oder Anwendungen ist die Vereinbarung der Modalitäten der
Datenübergabe ein grundlegender Aspekt. Dabei soll die Anwendung sich auf
die auszutauschenden Daten beschränken.
Datenbankschnittstellen haben die Aufgabe Informationen bzw. Daten zu
transportieren, sie gegebenenfalls zu transformieren und zu kontrollieren3).
Die Betrachtungsweise der Schnittstellen für den Datenaustausch kann sowohl
aus physischer als auch aus logischer Sicht erfolgen. Die physische
Schnittstelle definiert die programmtechnischen Möglichkeiten bzw.
Einschränkungen für den Datenaustausch, d.h. dass man die Semantik und die
Syntax der kommunizierenden Anwendungen exakt bestimmen kann. Damit
sich die Komplexität, die zwischen den Anwendungen herrscht, verringert
wurde eine Schicht entworfen, die Middleware. Sie liegt zwischen Basissystem
und Anwendung, wie in Abbildung 4 Einordnung der Middleware verdeutlicht ist.
Gleichzeitig wird durch die Middleware die Flexibilität der Anwendung
vergrößert.
Netzwerk mit
Standardprotkoll
Anwendung
Middleware
Middleware
Betriebssystem
Datenbank
Abbildung 4 Einordnung der Middleware
Der Datenaustausch zwischen den funktionellen Teilsystemen wird durch die
logische Sicht einer Schnittstelle beschrieben. Sie sichert die Integrität der
Anwendung und beschreibt die Anforderungen an den Datenaustausch.
3)
Vgl. [15]
13
Dieser ist heutzutage auf verschiedenste Weise möglich. Zu nennen wäre dabei
der Datenaustausch über DDE(Dynamic Data Exchange), OLE (Object Linking
Embedding), der Datenaustausch über EDI (Electronic Data Interchange) und
über ODBC. Auf den Standard ODBC soll in weiteren Ausführungen nun näher
eingegangen werden.
2.1.3 ODBC
Die Open Database Connectivity (ODBC) ist eine Standardschnittstelle für den
Datenzugriff unterschiedlicher Datenquellen. Sie beruht auf dem Client-ServerModell und ist eine typische Middleware-Komponente.
ODBC macht es möglich die gewünschte Datenquelle zu lokalisieren, in einem
Netzwerk die Verbindung zu einem Datenbanksystem aufzubauen, spezielle
Zugriffsbefehle überflüssig zu machen und Abfragen im SQL-Format
abzusetzen.
Die Architektur von ODBC besteht aus mehreren Ebenen, damit die DBMSUnabhängigkeit gewährleistet wird. Dabei sind vier Komponenten besonders zu
nennen:
-
Anwendung
-
Treiber-Manager
-
Treiber
-
Datenquellen.
Die einzelnen Komponenten sollen an dieser Stelle nicht näher erläutert
werden. Der Autor verweist hier auf seine Studienarbeit4), in der das Thema
konkretisiert wurde.
4)
Vgl. [12]
14
2.2 Datenbanktheoretische Grundlagen
Nach der Definition des Begriffes Datenbank sollen in diesem Kapitel
Grundlagen über verschiedene Modelle des Datenbankentwurfes erläutert und
auf die Datenbanksprache SQL näher eingegangen werden.
2.2.1 Datenbank-Definition
Eine Datenbank (engl. data base) ist ein System von strukturiert gespeicherten
Daten. Zwischen diesen Daten besteht eine Vielzahl von Beziehungen5).
Die Motivation der Organisation in Datenbanken besteht darin Daten konsistent
und redundanzfrei zu speichern, so dass ein Vielfachzugriff durch
unterschiedliche Benutzer und Programme möglich ist. Dadurch wird die flexible
Auswertungs- und Verarbeitungsmöglichkeit der Daten bei kürzeren
Zugriffzeiten für die Benutzer bzw. kürzere Verarbeitungszeiten für die
Programme ermöglicht.
Um die Daten einer Datenbank zu verwalten, ist ein
Datenbankmanagementsystem, kurz DBMS, nötig. Es kontrolliert die
Datenbank auf Konsistenz und ist für die Modifikation der Daten zuständig.
Die Datenbank und das Datenbankmanagementsystem bilden zusammen das
Datenbanksystem.
Um nun Daten zu modellieren bzw. zu beschreiben, wurde 1975 durch die
ANSI-Gruppe ein Architekturmodell eingeführt. Dabei wird die Vorgehensweise
bei der Beschreibung der Daten in drei Sichten6) unterteilt:
-
externe (Daten-)Sicht
-
konzeptionelle (Daten-)Sicht
-
interne (Daten-)Sicht
Die externe Sicht ist die Sicht des Nutzers, auch oft Benutzersicht genannt. Sie
beschreibt die Sicht, aus der jeder einzelne Nutzer die Datenbank sieht. Die
externe Sicht beschäftigt sich mit der Frage, auf welche Weise die Nutzer auf
die von ihnen benötigten Daten zugreifen und diese logisch verknüpfen können.
5)
Vgl. [On4]
6)
Vgl. [6]
15
Die konzeptionelle Sicht beschreibt die logische Struktur der Daten, die in der
Datenbank gespeichert sind, und zwar unabhängig von der tatsächlichen
physischen Speicherung und der einzelnen Anwendungen aus Benutzersicht.
Die logische Struktur der Daten wird im sogenannten semantischen Modell
beschrieben. Das entworfene Modell wird je nach DBMS in verschiedene
Datenbankmodelle überführt. Die Sicht, die sich mit der physischen
Speicherung der Daten aus dem logischen Datenmodell beschäftigt, ist die
interne Sicht. Die physische Speicherung wird dabei vom DBMS
übernommen7).
2.2.2 Datenbankmodelle
Ein Modell ist ein Ausschnitt der Realität. Dabei werden Objekte der realen Welt
abstrahiert.
Die verschiedene Modelle der Datenmodellierung werden klassifiziert in
klassische und semantische Datenmodelle.
Zu den klassischen Datenmodellen gehören:
•
das hierarchische Datenmodell
•
das Netzwerkdatenmodell und
•
das relationale Datenmodell.
Semantische Datenbankmodelle wurden mit dem Ziel entwickelt, den
interessierenden Informations- bzw. Datenausschnitt noch genauer als in den
klassischen Modellen abzubilden. Dabei sollte der Verlust der Semantik bzw.
Bedeutung der Daten so gering wie möglich sein. Zu den Semantischen
Modellen gehören:
•
das Entity-Relationship-Modell
•
semantische Netze und
•
das Object-Role-Modell.
Das Entity-Relationship-Modell ist dabei das wichtigste und bedeutendste
Modell8).
Beim Datenbankentwurf wird oft aufgrund von aufwandtechnischen Gründen
zuerst das Entity-Relationship-Diagramm entwickelt, und danach wird aus
7)
Vgl. [6]
8)
Vgl. [17]
16
diesem das relationale Datenmodell abgeleitet, bzw. das Entity-RelationshipModell wird in das relationale Datenmodell überführt. Deshalb soll auf das
Entity-Relationship-Modell und das relationale Modell in den folgenden Kapiteln
näher eingegangen werden.
2.2.2.1
ERM
Das Entity-Relationship-Modell, kurz ERM, wurde 1976 von P.P. Chen
entwickelt. Es wird hauptsächlich zum Datenbankentwurf als Analysemethode
verwendet, da hier nur ein semantisches Datenmodell festgelegt und visualisiert
wird. Es ist also nur eine Entwurfs- bzw. Modellierungshilfe9).
Das ERM wird im Entity-Relationship-Diagramm visualisiert. Im ERM werden
dabei die Elemente „Entity“, „Relationship“ und „Kardinalität“ verwendet. Die
Enities stellen die abstrahierten Objekte der realen Welt dar und werden als
Rechtecke abgebildet. Ihnen sind Attribute bzw. Eigenschaften zuzuordnen. Die
Relationships sind die Beziehungen zwischen den Entities. Sie werden als
Rauten dargestellt. Die Beziehungen besitzen bestimmte Ausprägungen, die
Kardinalität. Sie sind Mengenbeziehungen, die auf bzw. an der Kante im ERD
Abteilung
1
gehört zu
n
Person
Abbildung 5 Beispiel eines ERM
abgebildet werden. Die Abbildung 5 zeigt ein ERM in Chen-Notation.
2.2.2.2
Relationales Datenbankmodell
Das relationale Modell, oder auch Relationenmodell, wurde 1970 von E.F.
CODD veröffentlicht. Eine zweite Version wurde 1990 veröffentlicht, wobei darin
die wichtigsten Veröffentlichungen aus diesem Gebiet zusammengefasst sind
und ergänzt wurden10)11).
9)
Vgl. [9]
10)
Vgl. [18]
11)
Vgl. [8]
17
Im Gegensatz zu anderen Modellen wird auf die grafische Darstellung
verzichtet. Es werden, vereinfacht gesagt, alle Daten in zweidimensionalen
Tabellen dargestellt, die aus einer festen Anzahl von Spalten und einer beliebig
großen Anzahl von Zeilen bzw. Tupeln bestehen. Der Hauptbegriff des
relationalen Modells ist die Relation. Sie wird als Teilmenge (=Tabelle) eines
kartesischen Produkts von vorgegebenen Wertebereichen definiert.
Das relationale Modell besteht aus der Definition von Objekten, Operationen
und Regeln. Die Objekte des relationalen Modells werden im Folgenden
beschrieben und den Begriffen des Entity-Relationship-Modells
gegenübergestellt:
Die Relation ist eine zweidimensionale Tabelle und beschreibt im ERM einen
Entitätstyp12). Die Entität aus dem ERM wird durch ein Tupel im relationalen
Modell beschrieben. Das Tupel entspricht der Zeile in der zweidimensionalen
Tabelle. Weiterhin entsprechen die Spalten im relationalen Modell den
Attributen im ERM. Die Entitäten werden durch die Ausprägung der Attribute
beschrieben. Die Anzahl der Attribute wird Grad der Relation genannt. Die
Zusammenfassung aller möglichen Attributwerte eines Attributs wird als
Domäne bezeichnet.
2.2.3 Die Datenbanksprache SQL
Das relationale Modell findet sich in einem sprachlichen Rahmen wieder, der
Datenbanksprache SQL (engl. Structured Query Language, strukturierte
Abfragesprache)13). Sie ist das sprachliche Mittel für die Definition, die
Manipulation und die Kontrolle von Relationen.
SQL ist eine mengenorientierte Sprache, d. h. es wird angegeben, welche
Datenmenge gebraucht wird, jedoch nicht wie die Daten ermittelt werden.
Erstmals wurde SQL 1986 von der ANSI genormt. Seitdem wurden mehrere
SQL-Standards festgelegt, die neueste Version ist SQL-99. Er ist gleichzeitig
Standard für objektrelationale Datenbanken. Trotz Standardisierung durch ANSI
und ISO existieren verschiedene SQL-Dialekte, die sich z. T. erheblich von den
12)
Vgl. [17]
13)
Vgl. [9]
18
aktuellen Normen unterscheiden. Hier ist vor allem MySQL zu nennen, das
einen weit verbreiteten SQL-Dialekt darstellt.
Mit Hilfe von SQL kann der Anwender Befehle formulieren, die danach durch
ein DBMS verarbeitet werden. Dabei übernimmt das DBMS das Eingeben,
Speichern, Ausgeben und Löschen der Daten. Betrachtet man die SQL-Befehle
genauer, so kann man sie in folgende Klassifizierung einteilen14):
•
Datendefinitionsanweisungen (DDL)
•
Datenmanipulationsanweisungen (DML) und
•
Datenkontrollanweisungen (DCL).
Die DDL übernimmt das Erstellen bzw. Definieren von Objekten der Datenbank,
wie z.B. Tabellen und Spalten. Hier finden wir Befehle wie „CREATE“, „ALTER“
und „DROP“.
Das Verändern und Manipulieren der Daten einer Datenbank kann mit Hilfe der
DML vorgenommen werden. DML-Anweisungen sind „SELECT“-, „INSERT“-,
„UPDATE“- und „DELETE“-Befehle.
Mit Hilfe der DCL können die Rechte, ob ein Nutzer bestimmte Befehle
ausführen kann und darf, vergeben werden. Der „GRANT“- und der „REVOKE“Befehl sind solche Anweisungen.
2.3 MySQL
MySQL ist ein relationales Datenbankmanagementsystem, das im Jahr 1995
von Michael Widenius entwickelt wurde. Aus wirtschaftlichen Gründen heraus
entstand die Idee eine Middleware für mittlere und kleine Unternehmen, sowie
für kleinere Anwendungen zu entwickeln. Da MySQL frei und kostenlos
erhältlich ist, ist es eine Alternative zu den bekannten Datenbanksystemen, wie
Oracle, Microsoft SQL Server oder DB2. MySQL ist ein Open Source Produkt
und besitzt eine GPL (General Public Licence). D. h. der Einsatz einer MySQLDB ist unter bestimmten Vorrausetzungen ohne eine Lizenz möglich. Dazu
muss man nur seine Entwicklung mit der MySQL-DB der Öffentlichkeit
zugänglich machen.
14)
Vgl. [1]
19
MySQL unterstützt die Datenbanksprache SQL nach dem ANSI-SQL/92Standard jedoch mit gewissen Einschränkungen. So kennt MySQL bestimmte
SQL-Befehle nicht oder sind nur zum Teil möglich. MySQL bietet aber auch
eine Reihe von anderen Datentypen an. Durch den geringeren Befehlsumfang
kann es eine hohe Performance bieten. Da MySQL eine Client/Server
Anwendung ist, können die Anfragen bzw. Zugriffe mehrerer Anwendungen,
z.B. per Internet, bearbeitet werden, das bedeutet es ist Multi Thread fähig.
Somit ist MySQL eine sichere, robuste Anwendung, die eine hohe Performance
liefert15).
Ein weiterer großer Vorteil von MySQL ist die Plattformunabhängigkeit, das
bedeutet es gibt nahezu zu jedem Betriebssystem Distributionen von MySQL,
z.B. Windows, MAC oder OS/2. Bekannt wurde MySQL durch die Integration in
das Betriebsystem Linux.
MySQL-Anwendungen bzw. Client-Programme können in vielen verschiedenen
Programmiersprachen entwickelt werden, so z.B. unter C, C++ oder PHP, da
viele API`s, Application Programming Interfaces, für MySQL existieren.
Zusätzlich bietet MySQL eine ODBC-Schnittstelle für Windows übliche
Programmiersprachen (Delphi, Visual Basic, usw.) an. Diese Schnittstelle heißt
MyODBC und existiert in der Version 3.5.
2.3.1 Geschichte
Die Geschichte von MySQL beginnt mit der Doktorarbeit von David Hughes, die
er an der Bond Universität in Australien schrieb. Eine Schlüsselkomponente
davon war ein DBMS zur Speicherung von Informationen. Da eine kommerzielle
Datenbank zu teuer war, nutzte Hughes die damals freie Datenbank Postgres,
mit der Abfragesprache PostQUEL. Da zur damaligen Zeit SQL verbreiteter war
als PostQUEL, entwickelte Hughes mSQL, einen Übersetzer, der SQL in
PostQUEL übersetzte. Jedoch wurde die Arbeit mit der Datenbank immer
langsamer, je größer sie wurde.
15)
Vgl. [13]
20
Zur gleichen Zeit entwickelte die Firma TCX eine webbasierende Anwendung
zur Verwaltung von Datenbanken mit dem Namen UNIREG. Aufgrund der o.g.
Probleme mit mSQL entwickelte Michael Widenius im Jahr 1994 eine eigene
Middleware Datenbank auf der Basis von mSQL und UNIREG. Die erste
Version von MySQL war 1995 fertig, nannte sich MySQL 1.0 und wurde als
Open Source veröffentlicht.
Da MySQL für viele Betriebssysteme verfügbar und Open Source war, also frei
erhältlich, wuchsen die Marktanteile bis zum Jahr 2000 von MySQL, und immer
mehr Nutzer wendeten MySQL an. Ebenfalls zur Verbreitung von MySQL trägt
der Boom von Linux bei, da MySQL ein Bestandteil von Linux-Distributionen ist.
So wird geschätzt, dass es ca. 4 Millionen Installationen weltweit gibt und mehr
als 25.000-mal heruntergeladen wird16).
Die aktuellste Version von MySQL ist MySQL 4.1 alpha. Die Version MySQL
5.0 ist mit einigen Erweiterungen geplant17).
2.3.2 Einschränkungen von SQL unter MySQL
Wie bereits erwähnt, benutzt MySQL in der Version 4.0 den ANSI-SQL/92Standard, aber mit Einschränkungen. Auf diese soll im Folgenden näher
eingegangen werden.
MySQL ist nicht in der Lage SubSelects in der Form des folgenden Beispiels
durchzuführen:
SELECT * FROM Tabelle1 WHERE x IN (SELECT y FROM Tabelle2)
Dies kann durch das anlegen einer temporären Datei oder durch zusätzlichen
Code in einer externen Programmiersprache umgangen werden.
Ein großes Problem ist, dass MySQL nicht die referentielle Integrität umsetzen
kann. MySQL kennt zwar Fremdschlüssel, welche die Verbindung zweier
Tabellen möglich machen, ist aber nicht in der Lage dadurch die referentielle
16)
Vgl. [On8]
17)
Vgl. [On2]
21
Integrität zu sichern. Wenn eine Tabelle gelöscht wird und ein Fremdschlüssel
dieser Tabelle noch in einer anderen existiert, kümmert sich MySQL nicht
darum und lässt den Verweis auf die gelöschte Tabelle stehen, wie ein Link
dessen Quelle nicht mehr existiert. Das ist ein Problem bei Abfragen, die über
diesen Fremdschlüssel gemacht werden. Da die Tabelle des Fremdschlüssels
nicht mehr existiert, kann es dabei zu erheblichen Problemen kommen. Hierbei
muss der Programmierer beim Anwenden von Änderungs- und Löschbefehlen
die Integrität der Daten sicherstellen und ggf. solche Beziehungen zwischen
einzelnen Tabellen prüfen.
Weiterhin unterstützt MySQL keine Views, Stored Procedures, Trigger, und es
sind keine Transaktionen in MySQL möglich, diese Begriffe sollen aber an
dieser Stelle nicht näher erläutert werden.
2.4 XML
Kein anderes Stichwort wurde in den letzten Jahren häufiger in der IT-Branche
genannt wie XML, die Extensible Markup Language („erweiterte
Auszeichnungssprache“). XML gehört zu den Auszeichnungssprachen. Diese
definieren und beschreiben die Struktur von Text bzw. Daten mit Hilfe von sog.
Tags, nicht aber dessen Formatierung. Dabei zeichnet sich XML durch seine
Erweiterbarkeit aus, was bedeutet, dass es in XML möglich ist eine eigene
Struktur von Daten durch Definition von Tags festzulegen.
Dabei ist die wichtigste Anwendung von XML die Speicherung von
strukturierten Daten.
2.4.1 Geschichte
Die Idee der Auszeichnungssprachen stammt aus dem Druck- und
Verlagswesen. Sie existiert bereits seit etwa 50 Jahren. Damals wurden
Textpassagen zur Layoutbeschreibung ausgezeichnet. In den sechziger Jahren
wurde an einer Sprache zur Beschreibung der Struktur und des Inhaltes von
Dokumenten gearbeitet. Es entstand die SGML („Standard Generalized Markup
Language“). 1986 wurde eine Version des entwickelten Standards von der ISO
übernommen. Jedoch stand einem breiten Einsatz von SGML die hohe
Komplexität und der Mangel an entsprechenden Editoren entgegen.
22
Erst mit der Entwicklung des WorldWideWeb und HTML („Hyper Text Markup
Language“) als Anwendung von SGML wurde ein Meilenstein in der
Entwicklung der Auszeichnungssprachen geschaffen. HTML war zwar leicht zu
handhaben, jedoch konnten die Daten nicht von der Formatierung getrennt
werden. Eine Alternative war die Entwicklung von XML18) 19).
2.4.2 Aufbau und Struktur
XML zeichnet durch die Schaffung einer eigenen Struktur in einem Dokument
aus. Jedes XML-Dokument besitzt eine logische und eine physische Struktur.
Die logische Struktur definiert die einzelnen Elemente eines Dokuments und in
welcher Reihenfolge sie vorkommen sollen. Hingegen beinhaltet die physische
Struktur die Daten, die verwendet werden sollen.
Die logische Struktur eines XML-Dokumentes drückt sich also in dem Aufbau
des Dokuments aus. Das erste Element in einem XML-Dokument ist ein
Dokumentenkopf, der zwei optionale Elemente enthält, die XML-Deklaration
und die Dokumententyp-Deklaration. Die XML-Deklaration identifiziert die
Version der XML-Spezifikation, die in dem Dokument benutzt wird. Diese Zeile
muss klein geschrieben werden, wie im folgenden Beispiel zu sehen ist:
<?xml version="1.0"?>
Nach der XML-Deklaration folgt die Dokumenttyp-Deklaration. Sie definiert die
grammatischen Regeln bzw. die Document Type Definition (DTD) des
Dokuments. Die Definition der Regeln einer DTD soll an späterer Stelle erläutert
werden. Die Dokumententyp-Deklaration kann auch auf eine externe Datei
verweisen, wie das folgende Beispiel zeigt:
<!DOCTYPE Musik Katalog "Musik.dtd">
Die Dokumententyp-Deklaration muss immer nach der XML-Deklaration und vor
dem Dokument-Element stehen. Das Dokument-Element, auch Root-Tag oder
Wurzelelement genannt, kann in weitere Unterelemente zergliedert werden. Es
18)
Vgl. [2]
19)
Vgl. [11]
23
verhält sich wie bei einem Buch, welches in Komponenten, wie z.B. Kapitel
zergliedert, werden kann. Diese Komponenten können wiederum weiter in
Überschriften, Absätze oder Abbildungen zerlegt werden. So entsteht eine
Baumstruktur des Dokuments. Die Elemente in der Baumstruktur können noch
zusätzliche Attribute besitzen, die spezielle Eigenschaften bezeichnen.
<SONGLIST KATEGORIE=”Pop”>
<SONG>
<TITLE>Hot Cop</TITLE>
<COMPOSER>Jacques Morali</COMPOSER>
<COMPOSER>Henri Belolo</COMPOSER>
<COMPOSER>Victor Willis</COMPOSER>
<PUBLISHER>PolyGram Records</PUBLISHER>
<LENGTH>6:20</LENGTH>
<YEAR>1978</YEAR>
<ARTIST>Village People</ARTIST>
</SONG>
<SONG>
...
</SONG>
...
</SONGLIST>
Diese Baumstruktur wird in der XML-Syntax durch das Prinzip der
Verschachtelung realisiert. Die Verschachtelung ist die Einbettung eines
Objekts in ein anderes. Beispielsweise kann ein Wurzelelement weitere
Elemente bzw. Dokumente enthalten. Diese Dokumente können wiederum
weitere Elemente besitzen, usw. So wird durch die Verschachtelung eine
Erbschaftsbeziehung hergestellt20).
Die physikalische Struktur definiert den gesamten Inhalt eines Dokuments.
Dabei werden kleine Speichereinheiten definiert, die Entities. Sie werden durch
einen eindeutigen Name identifiziert und enthalten ihren Wert. In der logischen
Struktur werden die Entities in der Dokumententyp-Definition, kurz der DTD,
deklariert und werden dann im Wurzelelement referenziert. Dabei wird dem
XML-Prozessor durch die Entitydeklaration mitgeteilt, mit welcher Art von Inhalt
das Entity gefüllt werden soll. Das Definieren einer Entitydeklaration wird im
Kapitel 2.4.3 Dokumententyp-Definition erläutert. Das Abrufen und das
20)
Vgl. [11]
24
Verwenden des Inhalts des Entities wird dem Prozessor durch die
Entityreferenzierung mitgeteilt.
Eine Entityreferenzierung besteht aus einem kaufmännischem Und („ & “), dem
Namen des Entities und abschließendend aus einem Semikolon („ ; “), so dass
im folgenden Bespiel ein Entity mit dem Namen „Compbest“ referenziert wird:
<BESTCOMP>Der beste Komponist ist &Compbest;</ BESTCOMP>
Bestimmte Zeichen (<,>, &, “, /) werden in XML für die Markierung des
Dokumentes benötigt und können nicht für den Inhalt verwendet werden. Für
die Nutzung dieser Zeichen als Inhalt sind speziell vordefinierte Entities
vorhanden. So ist für eine öffnende spitze Klammer die Zeichenkette &lt; als
Entityreferenzierung definiert. Weitere vordefinierte Entities befinden sich in der
Tabelle 1 Vordefinierte Entities.
Tabelle 1 Vordefinierte Entities
2.4.2.1
Markup
Bisher wurde auf die logische und physische Struktur eines XML-Dokumentes
eingegangen. Es wurde aber noch nicht erläutert wie die logische und
physische Struktur zusammengeführt werden. Dies soll nun erklärt werden.
Die in der DTD deklarierten Elemente werden in der Struktur von XML in so
genannte Tags eingeschlossen. Tags beinhalten also den Elementennamen
und werden durch spitze Klammern begrenzt. Zu jedem Element gehören ein
Start- und ein End-Tag. Dabei wird im End-Tag dem Elementennamen ein
Slash („/“) vorangestellt. Ein Elementenname muss mit einem Buchstaben
beginnen, und danach kann jedes beliebige Zeichen folgen. Dabei ist aber die
Groß- und Kleinschreibung zu beachten, da die XML-Prozessoren diese
unterscheiden. Zwischen den Tags der logischen Struktur wird dann der Inhalt
der physischen Struktur eingefügt. Dies geschieht durch vordefinierte Entities
25
oder durch Entityreferenzierung, wie bereits oben erwähnt wurde. Das folgende
Beispiel zeigt ein Element mit Inhalt, Start- und End-Tag:
<COMPOSER>Jacques Morali</COMPOSER>
Start-Tag
Inhalt
End-Tag
Eine besondere Form des Tags in XML nimmt das Empty-Element-Tag an.
Dieses Tag fasst Start- und Eng-Tag zusammen und es enthält keinen Inhalt.
Das Empty-Element besteht nur aus einem Tag, bei dem auf den Tagnamen
ein Slash („/“)folgt, so dass sich folgendes allgemeines Beispiel ergibt:
<Elementname/>
XML erlaubt zusätzlich das Definieren von Attributen zu einem Element. Sie
stellen eine Verknüpfung mit einem Element dar. Ein Attribut wird im Start-Tag
eines Elementes definiert. Dabei folgt auf den Attributsnamen ein
Gleichheitszeichen („=“). Anschließend steht der Attributswert, der in
Hochkommas eingeschlossen wird. Im Folgenden wird ein allgemeines Beispiel
eines Elementes und eines Empty-Elementes mit einem Attribut dargestellt:
<Elementname Attribut=”Attributswert”>Elementeninhalt</Elementname>
<Elementname Attribut=”Attributswert”/>
In XML sind auch Kommentare erlaubt. Diese werden nicht als Inhalt erkannt.
Sie werden aber zum Markup dazugezählt. Ein Kommentar wird wie folgt
dargestellt:
<!-- Kommentare -->
Die so entstandene Abbildung der logischen Struktur und dessen entstandene
Verbindung mit der physischen Struktur nennt man Markup. Es ist die
Gesamtheit aller Tags. Wenn die Tags die Beschreibung für den Inhalt liefern,
so spricht man von deskriptivem Markup (deskriptiv=beschreiben).
26
2.4.2.2
Wohlgeformtheit und Gültigkeit
Jede Sprache hat Regeln, nach der sie aufgebaut ist, und aus der sich eine
Grammatik bildet. Ein Dokument, das ein verständliches Markup besitzt, nennt
man ein wohlgeformtes Dokument. Dabei unterstützt die Wohlgeformtheit ein
Prinzip von XML: das einfache Erzeugen von XML, da hier keine Definition
einer DTD notwendig ist. Die Wohlgeformtheit zielt vor allem auf die logische
Struktur ab. Dabei wird auf das Prinzip der Verschachtelung zurückgegangen,
wobei jedes Dokument ein Wurzelelement besitzt, in dem alle anderen
Elemente verschachtelt sind. Bei der Verschachtelung im Wurzelelement muss
beachtet werden, dass ein Element einer Ebene zunächst durch ein End-Tag
geschlossen wird, bevor eine anderes Element der gleichen Ebene geöffnet
wird. So ergibt sich, dass jedes Element genau ein Elternelement besitzt, und
dass jedes Element kein, ein oder mehrere Unterelemente haben kann.
Ein Dokument besitzt dann Gültigkeit, wenn es wohlgeformt ist und eine
Markup-Deklaration, für das Dokument, in einer DTD vorliegt.
Dabei wird von einem gültigen XML-Dokument die Deklaration in der DTD
streng beachtet, das bedeutet ein Dokument, das als gültig bezeichnet wird,
nach einer DTD validiert sein muss. Die Validisierung wird durch einen XMLProzessor vorgenommen. Auf die Definition einer DTD soll im folgenden Kapitel
näher eingegangen werden.
Der XML-Prozessor, auch Parser genannt, ist eine Application, welche die
Hauptaufgabe hat XML-Dokumente zu parsen und zu validieren, wie bereits
erläutert. Der XML-Prozessor kann auch den Inhalt von Dokumenten in ein
Format bringen, das von Anwendungen verwendet werden kann. Somit fungiert
der XML-Prozessor als eine Art Vermittlungsschicht zwischen den Daten und
der GUI21) 22).
2.4.3 Dokumententyp-Definition
Die DTD ist eine Art Regelwerk. Sie definiert Elementtypen, Attribute, Entities
und Notationen. Dabei deklariert sie, welche von diesen Komponenten
21)
Vgl. [5]
22)
Vgl. [11]
27
innerhalb eines Dokumentes und an welchen Stellen diese zur Verfügung
stehen bzw. vorkommen dürfen.
Eine DTD ist für eine organisatorische Standardisierung für ein Dokument von
großer Bedeutung, da sie eine zuverlässige Verarbeitung eines Dokumentes
gewährleistet. Sie kann direkt in dem XML-Dokument oder in einer externen
Datei, einer *.dtd-Datei, definiert werden.
Wie die einzelnen Komponenten eines Dokumentes in einer DTD deklariert
werden, soll an dieser Stelle nicht näher erläutert werden. Stattdessen wird auf
die Anlage 2 verwiesen.
2.5 CSV
CSV ist die Abkürzung für „comma separated values“, das heißt soviel wie
„durch Komma unterteilte Werte“. Das CSV-Format ist ein einfaches TextFormat für den Austausch von Daten zwischen verschiedenen Systemen, wie
z.B. Datenbanken u.ä. Dabei ist kein Datenbanksystem nötig, um dieses
Format einzuhalten, und um Daten aus diesem Format zu lesen und zu
schreiben. Das CSV-Format kann also für den Export und Import von Daten
zwischen verschiedenen Systemen genutzt werden23)24).
Die Speicherung der Daten in einer CSV-Datei erfolgt zeilenweise. In der ersten
Zeile sind die Spaltennamen zu finden, danach folgen zeilenweise die einzelnen
Datensätze. Die Daten sind dabei durch Seperatoren (=Trennzeichen) getrennt.
Gültige Seperatoren sind in der folgenden Tabelle 2 aufgeführt:
Tabelle 2 CSV-Seperatoren
23)
Vgl. [On3]
24)
Vgl. [On4]
Name
Beschreibung
Tab
Tabulatorsprung nach jedem Dateninhalt
Komma (,)
Komma zwischen den Daten
Semikolon (;)
Semikolon zwischen den Daten
Leerzeichen
Leerzeichen zwischen den Daten
28
Da die Daten Leerzeichen oder auch Kommas enthalten können, wird oft das
Semikolon als Seperator eingesetzt. Zusätzlich können die Daten mit Hilfe von
Textbegrenzungszeichen gekennzeichnet werden, sodass folgende Semantik
entsteht, wie in Tabelle 3 zu sehen ist.
Tabelle 3 Beispiele für Textbegrenzungszeichen
Textbegrenzungszeichen Beispiel
Anführungszeichen
"Datenfeld 1";"Datenfeld 2"; … ;"Datenfeld n"
Apostroph
`Datenfeld 1';'Datenfeld 2'; … ;'Datenfeld n'
{kein}
Datenfeld 1;Datenfeld 2; … ;Datenfeld n
Eine CSV-Datei kann man selbstständig erstellen oder aus einer MicrosoftExcel-Tabelle exportieren. Da das CSV-Format leicht zu lesen ist, es
weitestgehend standardisiert wurde und somit viele Anwendungen dieses
Format unterstützen, ist es möglich die Daten aus den verschiedensten
Datenbank-Systemen in eine CSV-Datei zu exportieren und Daten einer CSVDatei in andere Systeme, wie z.B. in eine MySQL-Datenbank oder in XMLDokumente, zu importieren.
Ein weiterer Vorteil ist, dass eine CSV-Datei einem Entity aus dem ERD
entspricht. Somit wird das Exportieren und das Importieren der Daten
vereinfacht.
Dem stehen einige Nachteile entgegen:
•
Es ist nur ein exklusiver Zugriff auf die Daten möglich, das bedeutet, man
hat beim Schreiben und Lesen Zugriff auf alle Daten und nicht nur auf
bestimmte Datenmengen.
•
Weiterhin ist ein großes Problem, dass beim Erstellen einer CSV-Datei
redundante Daten entstehen können, und so die Konsistenz der Daten nicht
mehr gegeben ist.
•
Für CSV-Dateien werden auch keine Funktionen bereitgestellt, sodass z.B.
keine Suche von Daten in der CSV-Datei durchgeführt werden kann.
•
Ebenfalls ist kein Datenschutz vor unberechtigtem Zugriff auf die Daten
einer CSV-Datei vorhanden.
29
•
Da die Daten zeilenweise durch Seperatoren getrennt sind, ist der Umgang
mit einer CSV-Datei teilweise umständlicher als mit einem DatenbankManagementsystem.
•
Durch die Speicherung in einem Text-Format erfolgt keine Komprimierung
der Daten bei der Speicherung.
30
3 Analyse
In diesem Kapitel erfolgt die Analyse des Softwaresystems SiSy® und dessen
vorhandenen Schnittstellen zu anderen Systemen. Weiterhin soll die
Entwicklung einer ODBC-Schnittstelle unter Visual C++ analysiert werden.
Abschließend werden Anforderungen aus den vorangegangenen
Betrachtungen abgeleitet und definiert.
3.1 Simple Systems®
Simple Systems, kurz SiSy®, wurde durch die Firma Laser & Co. Solutions
GmbH entwickelt. Es handelt sich dabei um ein CASE-Tool. CASE bedeutet
Computer Aided Software Engineering, d.h. es unterstützt die
Softwareentwicklung. Es bietet verschiedene Möglichkeiten der Anwendung. So
beinhaltet SiSy® u. a. die Strukturierte Analyse, Struktogrammtechnik und die
Modellierung mit Hilfe der UML. Neben der Unterstützung der
Softwareentwicklung kann SiSy® zur Modellierung von Geschäftsprozessen,
zur Dokumenterstellung nach DIN ISO 9000ff und zur Darstellung von
Aufbauorganisationen genutzt werden.
Diese vielfältigen Möglichkeiten der Modellierung verschiedener Modelle
werden in diversen Vorgehensmodellen zur Verfügung gestellt. So gibt es u. a.
die Vorgehensmodelle der UML, der Strukturierten Techniken, der
Programmierung, des Projektmanagement, des Qualitätsmanagements und das
Vorgehensmodell der Geschäftsprozessmodellierung. Ein Vorgehensmodell der
Geschäftsprozessmodellierung, die „Strategiepyramide“, ist in Abbildung 6
Simple System25) aufgeführt. Hier ist auch der grundsätzlichen Aufbau des
Softwaresystems SiSy® zu sehen. Am oberen Rand befindet sich die
Menüleiste, die verschiedene Funktionen bereitstellt, z. B. das Öffnen des
Navigators oder des Assistenten. Der Navigator, auf der linken Seite, ist eine
Art Explorer. Er zeigt die Projektstruktur in einem Ordnerbaum. Darunter
befindet sich der Assistent. Er ist eine statische Hilfe, die Tipps und Vorlagen
zur jeweiligen Sicht in SiSy® anbietet. Das Diagrammfenster ist hier das größte
25)
Vgl. [So1]
31
Fenster. In diesem kann der Nutzer Objekte anlegen, die in der Objektbibliothek
auswählbar sind. Zu jedem Objekt kann eine Beschreibung hinzugefügt werden,
die beim Anklicken des Objekts im Beschreibungsfenster angezeigt wird.
Abbildung 6 Simple System
Zur Erweiterung des Tools SiSy® können zusätzlich Add-Ons erworben
werden, die spezielle Funktionen für SiSy® anbieten, so z.B. den HTML-Export.
Es sind bereits Schnittstellen vorhanden, um Daten aus SiSy® in andere
Systeme zu transferieren, wie z.B. zu MS Word 2000, MS Project 2000 und in
die Sprache HTML. Um eine eindeutige Identifizierung eines Add-Ons zu
ermöglichen, wurde durch die Laser & Co. Solutions GmbH eine
Namenskonvention eingeführt. Es wurde festgelegt, dass sich die Namen der
Dateien eines Add-Ons aus zwei Teilen zusammensetzen, dem Add-On-Namen
und dem Sichtnamen. Der Add-On-Name bezieht sich meist auf das
Vorgehensmodell, in dem die Funktionalität des Add-Ons installiert wird. So
wurde beispielsweise für das Add-On „Projektmanagement“ das Kürzel „pm“
und für die Sicht des „Netzplanes“ das Kürzel „npt“ eingeführt, so dass sich für
die Dateien der Sicht „Netzplan“ im Vorgehensmodell „Projektmanagement“ der
Dateiname „pm_npt.*“ ergibt.
32
3.1.1 Repository von SiSy®
Ein Repository ist eine spezielle Datenbank für Modellierungs- bzw. CASETools, dessen Hauptaufgabe es ist die Modellinformationen und
Entwicklungsdaten zu speichern. Das Repository von SiSy® besitzt
objektorientierte Merkmale; d.h. die strukturierte Speicherung der Objekte wird
besser unterstützt als in relationalen Datenbanken. Die Speicherung der
Objekte erfolgt in einem Objektkern. Dieser Kern enthält Informationen über
Nummer, Typ und Subtyp des Objekts, Name, Beschreibung und Datum der
Erstellung, verschiedene Flags, Links auf Vorgänger- Nachfolger-Strukturen
(VG/NF-Strukturen) und Links auf objektspezifische Daten. Dabei ist im
Repository auch die Bildung von Referenzen der Objekte möglich, wobei die
Referenzen existentiell vom Original abhängig sind. In einem Objekt werden
auch diagrammspezifische Daten abgelegt, da es in mehreren Diagrammen
auftreten kann. Diese Daten werden strukturiert abgespeichert. In den VG/NFStrukturen werden Informationen zu Beziehungen zwischen den Objekten
gespeichert. Diese Beziehungen umfassen z.B. die Hierarchisierung von
Diagrammen oder die Verbindung von Objekten durch Kanten. Die Abbildung 7
zeigt eine Grobstruktur des Repository von SiSy®.
Auf die Objekte und deren Daten im Repository kann mit Hilfe der internen
Sprache SiSyBasic und den SiSy-Basic-Klassen zugegriffen werden.
Objektreferenzen
Strukturierte
Objektdaten
VG/NF-Strukturen
Abbildung 7 Grobstruktur des Repository von SiSy®
Objektdaten
33
3.1.2 SiSyBasic
SiSyBasic ist die interne Programmiersprache für SiSy®. Sie ist anwenderorientiert, das bedeutet, dass SiSyBasic so konzipiert wurde, dass Anwender,
z.B. die Kompetenzpartner der Laser & Co. Solutions GmbH, mit Hilfe von
SiSyBasic schnell und einfach eigene Add-Ons für SiSy® realisieren können.
SiSyBasic wird durch SiSyBasic-Klassen interpretiert, die durch die Datei
“Assi.exe“ bereitgestellt werden. Diese Klassen stellen eine Art Interpreter dar,
der die Struktur des SiSyBasic verarbeitet, ohne es vorher in
Maschinensprache umzuwandeln. Die SiSyBasic-Klassen wurden in der
Sprache C++ entwickelt. Sie enthalten auch Funktionen zur Verarbeitung der,
im Repository (siehe Kapitel 3.1.1) gespeicherten Daten. Die SiSyBasic-Skripte
werden in FLD- und in FLQ-Dateien hinterlegt. Die in SiSyBasic entwickelten
Funktionen können durch den Dialog eines Objekts in SiSy® angesprochen
werden bzw. unterstützen die Funktionalität des Dialoges.
3.1.3 Schnittstellen in SiSy®
In das Softwaresystem SiSy® sind bereits einige Schnittstellen integriert. So
gibt es Schnittstellen zum Softwareprodukt MS-Word, zu diversen Compilern
und eine Schnittstelle zu DBMS die SQL-Statements umsetzen können.
Ausgewählte Schnittstellen sollen im Folgenden näher analysiert werden.
3.1.3.1
Schnittstelle zu SQL-Standard konformen DBMS
Die Schnittstelle zu Datenbankmanagementsystemen, die SQL-Statements
verarbeiten können, wurde mit Hilfe der ODBC-Schnittstelle von Windows in der
Sprache C realisiert. Dabei modelliert der SiSy®-Nutzer zunächst ein
Datenmodell im ERD in SiSy®, wie ein Beispiel in Abbildung 8 zeigt.
34
Computer
Computer
Abteilung
n
wird
zugeordnet
1
Abteilung
Abbildung 8 Beispiel Entity-Relationship-Diagramm
Bevor durch den Nutzer die Datenbank generiert wird und der SiSy-ODBCDialog geöffnet wird, wird eine Prüfung des erstellten Entity-RelationshipDiagrammes vorgenommen. Bei einem Fehler oder semantisch unkorrekter
Modellierung erscheint eine Meldung. Danach wird automatisch der SiSyODBC-Dialog geöffnet. Im SiSy-ODBC-Dialog kann man die Datenquelle, in die
das ERD überführt werden soll, auswählen. Die Auswahl der Datenquelle bzw.
des Datenbankformates wird über den Dialog der ODBC-Schnittstelle von
Windows vorgenommen. Weiterhin können im SiSy-ODBC-Dialog Tabellen-,
Feldnamen und die zugehörigen Typen, die in der zu erzeugenden Datenbank
verwendet werden sollen, über jeweilige Schalter festgelegt werden. Die
Abbildung 9 26) zeigt den SiSy-ODBC-Dialog analog zum genannten Bespiel.
Abbildung 9 Der SiSy-ODBC-Dialog
26)
Vgl. [So1]
35
Nachdem die Datenquelle ausgewählt und die Bezeichner und Typen festgelegt
wurden, können die SQL-Statements mit Datendefinition- und
Datenmanipulationsanweisungen generiert werden. Die Anweisungen
erscheinen dann in einem editierbaren Dialogfeld, so dass die Statements
durch den Nutzer an dieser Stelle noch einmal bearbeitet werden können.
Zuletzt kann man die Statements ausführen und somit eine Datenbank erstellen
bzw. verändern.
Bei dieser Schnittstelle werden aber nur SQL-Statements nach dem ANSISQL/92-Standard erzeugt, so dass auch nur Systeme bearbeitet werden
können, die SQL-Statements verstehen. Wenn man eine Datenquelle, z.B.
CSV-Dateien, auswählt die keine SQL-Statements verarbeiten können, so
können diese auch nicht erstellt werden.
3.1.3.2
Schnittstelle zum Compiler „DJGPP“
SiSy® ermöglicht es kleine bis mittelgroße Programme in den Sprachen C,
C++, C#, Java, Pascal und Assembler zu erstellen. Diese Programme können
mit Hilfe von Compilern kompiliert und gelinkt werden. Für die Sprache C und
C++ wird in SiSy® der Compiler „DJGPP“ verwendet.
Das Programmieren ist im Struktogrammeditor und im Vorgehensmodell
„Programmierung“ möglich. Im Vorgehensmodell „Programmierung“ kann man
für jedes einzelne Programm ein Objekt erstellen. Auf diesem Objekt hinterlegt
man den Quelltext zu dem Programm, in der jeweiligen Sprache.
36
Im Dialog des Objekts kann dessen Name festgelegt und die gewünschte
Sprache ausgewählt werden. Daraus werden mit Hilfe von SiSyBasicSkripten
Dateiname, Programmname und Speicherort generiert.
Abbildung 10 Dialog zum Programmieren
Über die Schalter im Dialog jedes Objekts kann man eine Datei mit dem
angegebenen Quellcode erzeugen, kompilieren und gegebenenfalls mit
anderen Dateien zu einem ausführbaren Programm linken, wie man in der
Abbildung 10 sehen kann. Die in diesem Dialog benutzten Dialogelemente
werden für den Dialog des Datenexport in Betracht gezogen, da u.a. die
Auswahl der Sprache durch SiSyBasic-Skript aus einer INI-Datei generiert wird.
3.1.3.3
Das Objekt „Aufzählung“
Mit Hilfe des Objekts „Aufzählung“ kann man Informationen von Objekten,
welche in SiSy® modelliert sind, u.a. in Form von Tabellen in das Programm
MS Word überführen. Dieses Objekt befindet sich unter dem Objekt
„Dokumenteninhalt“ in SiSy®. Dort können Dokumente modelliert und in MS
Word generiert werden. Dazu zieht man ein Objekt, unter dem sich die
aufzuzählenden Daten befinden, als „Aufzählung“ in das Diagrammfenster. Im
Dialog dieses „Aufzählen“-Objekts kann man festlegen nach welchen
Objekttypen bzw. in welchen Objekttypen gesucht werden soll. Dieser Dialog ist
ein Wizard-Dialog, in dem der Nutzer sequentiell alle Informationen eingeben
37
muss. Hier kann auch bestimmt werden, welche Eigenschaften der Objekttypen
in den Tabellen gespeichert werden sollen. Dazu wird im Dialog der
„Aufzählung“ die in der Abbildung 11 dargestellte Dialogseite verwendet.
Abbildung 11 Dialogseite des "Aufzählen" Objektes
Beim Generieren des Dokuments aus SiSy® heraus werden, mit Hilfe eines
SiSyBasic-Skripts und unter Verwendung von SiSyBasic-Klassen, die
Informationen aus den Objekten gelesen und dann in die festgelegte Struktur
einer Tabelle gespeichert. Hier sei besonders die Funktion „ScanTree“ der
Klasse „Repo“ erwähnt. Diese Methode sucht nach den gewünschten
Objekttypen, die dann aufgelistet werden.
3.2 Beispiel der Organisationssicht in SiSy®
In diesem Kapitel soll kurz der Aufbau der Sichten und deren Objekte am
Beispiel der Organisationssicht gezeigt werden, und dargelegt werden wie ein
Export von Stellen mit deren Eigenschaften durchgeführt werden könnte.
Die Organisationssicht befindet sich im Vorgehensmodell der
Geschäftsprozessmodellierung. Zur Modellierung der Organisation eines
Unternehmens kann das Objekt „Organisationssicht“ benutzt werden. Dieses
38
Objekt kann man durch ein Organigramm verfeinern. Dort kann man die
Organisation einer Unternehmung modellieren, in dem man
Organisationseinheiten, Stellen, interne und externe Personen und Rollen
anlegt, wie ein Beispiel in Abbildung 12 Beispiel der Organisationssicht27) zeigt.
Abbildung 12 Beispiel der Organisationssicht
Beim Anlegen der einzelnen Objekte, wie „Stelle“, „Organisationseinheit“ u.s.w.,
ist es möglich Daten zu speichern. So kann man beispielsweise in einer Stelle
neben dem Namen, einer Abkürzung und der Beschreibung, auch
Telefonnummer u.s.w. im Dialog des Objektes hinterlegen. Den Dialog mit den
verschiedenen Eigenschaften des Objektes „Stelle“, welche möglich zu
definieren sind, sehen Sie in der Abbildung 13.
27)
Vgl. [So1]
39
Abbildung 13 Dialogseite "zusätzliche Informationen" der
Stelle
Diese Informationen können durch SiSyBasic-Skript, z.B. durch das
„Aufzählen“-Objekt, aus den Objekten ausgelesen und bearbeitet bzw.
verarbeitet werden.
Bei einem Export von Stellen und deren Eigenschaften müsste man zuerst ein
Objekt festgelegt werden auf dem die Suche nach Stellen begonnen werden
soll. Das wäre in diesem Bespiel das Objekt der „Organisationssicht“. Hier kann
man in das Organigrammen „Abtauchen“ und nach dem Objekttyp „Stelle“
suchen. Wenn man alle Objekte des Typs „Stelle“ gefunden hat, könnten die
Eigenschaften dieser exportiert und gespeichert werden.
3.3 ODBC unter Visual C++
Da durch SiSyBasic-Skript keine Verbindung zu eine Datenquelle hergestellt
werden kann bzw. es nicht durch SiSyBasic-Funktionen möglich ist Daten direkt
in eine Datenbank zu generieren muss diese Funktionalität durch eine
SiSyBasic-Klasse bereitgestellt werden. Diese Klasse muss in C++ entwickelt
werden.
Dieses Kapitel soll kurz die Möglichkeiten des Einsatzes von ODBC unter
Visual C++ darlegen. Der Programmierer hat grundsätzlich zwei Möglichkeiten
mit Hilfe der Bibliothek „ODBC32.LIB“ oder den MFC-ODBC-Klassen.
40
3.3.1 Die Bibliothek „ODBC32.LIB“
In der Bibliothek „ODBC32.LIB“ wird über drei verschiedene Handles mit der
Verbindung zu ODBC gearbeitet. Ein Handle ist eine Anwendungsvariable in
der das System Informationen über eine Anwendung oder ein Objekt ablegen
kann. Die Bibliothek „ODBC32.LIB“ verwendet Umgebungshandles,
Verbindungshandles und Anweisungshandles, die hierarchisch angeordnet
sind, wie in Abbildung 14 zu sehen ist.
Umgebungshandle
Verbindungshandle
Verbindungshandle
Anweisungs-
Anweisungs-
Anweisungs-
Anweisungs-
handle
handle
handle
handle
Abbildung 14 Die Hierarchie der Handles
ODBC verwendet das Handle-Konzept, um eine widerstandsfähige
Fehlerbehandlung sicherzustellen. Dabei haben die einzelnen Handles folgende
Funktionen28):
1. Umgebungshandle (henv – Handle to Enviroment):
Dies ist ein globales Kontext-Handle und muss als erstes allokiert werden.
Am Ende der Verbindung wird das Handle wieder freigegeben. Es stellt
einen globalen Platzhalter für alle anderen Handles dar und besitzt darüber
hinaus folgende Funktionalität:
28)
-
übergibt alle Felder in der Umgebung an die Funktion „SQLError()“
-
Kontext-Handle für die Methode „SQLDataSources()“
-
Kontext-Handle für die Methode „SQLDrivers()“
-
verwaltet die Transaktionen
[4]
41
2. Verbindungshandle (hdbc – Handle to Database Connection):
Dieses Handle verwaltet alle Informationen über eine Verbindung. Dabei
wird mit Hilfe der Funktion „SQLAllocConnect( henv, &hdbc )“ ein
Verbindungshandle einem Umgebungshandle zugeordnet und mit
„SQLFreeConnect()“ wieder freigegeben. Weiterhin wird dieses Handle
benötigt für:
-
das Einrichten einer Verbindung durch „SqlConnect()“ und
„SQLBrowseConnect()“
-
den Abbau der Verbindung durch „SQLDisconnect()“
-
die Übergabe aller aufgetretenen Fehler an „SQLError()“
-
das Setzen der Verbindungsoptionen mit der Funktion
„SQLSetConnectOption()“
-
die Verwaltung der Transaktionen und
-
als Argument für die Informationsfunktion „SQLGetInfo()“ und
„SqlGetFunctions()“
3. Anweisungshandle (hstmt – Handle to Statement):
Das Anweisungshandle ist für die Verarbeitung der SQL-Anweisungen und
Katalogfunktionen zuständig. Es wird durch die Methode „SQLAllocStmt()“
erzeugt und durch „SQLFreeStmt()“ wieder freigegeben. Jedes
Anweisungshandle ist hierarchisch unter dem Verbindungshandle
angeordnet und wie deshalb nur einem Verbindungshandle zugeordnet. Es
wird u.a. dazu verwendet um Statusinformationen zu verwalten.
Aus dieser Arbeit und der Hierarchisierung der Handles folgt ein grundsätzlicher
Ablauf zum Verbindungsaufbau zu einer Datenquelle in einer Anwendung, der
in der Abbildung 15 verdeutlicht ist:
42
Anwendung
Allokation der
Umgebungs- und
Verbindungshandles
Aufruf einer
Verbindungsfunktion
Aufruf der
Treiberfuntionen
zur Allokation der
Handles
Laden des Treibers
Einrichten der
Verbindung zum
Server
Ausführung der
SQL-Anweisung
Freigabe der
Handles
Abbildung 15 Ablauf eines Verbindungsaufbaus
Zuerst werden das Umgebungshandle und das Verbindungshandle durch die
Funktionen „SQLAllocEnv()“ und „SQLAllocConnect()“ allokiert. Dies ist nur eine
Interaktion zwischen der Anwendung und dem Treibermanager.
Die Entwicklung von ODBC sah eine maximale Flexibilität vor. Deshalb macht
ODBC es möglich die Verbindungsoptionen in einem separaten
Konfigurationsprozess oder dynamisch zur Laufzeit zu bestimmen. Dazu
werden drei verschiedene Methoden zum Aufbau einer Verbindung angeboten:
die Funktionen „SQLConnect()“, „SQLDriverConnect()“ und
„SQLBrowseConnect()“.
Die Funktion „SQLConnect()“ verlangt als Inputparameter den Namen der
Datenquelle, einen User-ID und ein Passwort. Daraus folgt, das man in der
Anwendung Sicherheitsinformationen abfragt bzw. müssten diese in der
Anwendung kodiert sein. Diese Funktion wird für den Aufbau einer direkten
43
Verbindung von einem PS zu einem DBMS genutzt und ist die einzige Funktion,
die im Call Level Interface des ISO-Standards enthalten ist.
„SQLDriverConnect()“ ist die gebräuchlichste Art des Verbindungsaufbaus.
Diese Funktion übernimmt den gesamten Verbindungsprozess und fragt alle
nötigen Informationen vom Benutzer mit Hilfe eines Dialoges ab. Hier steht dem
Entwickler frei, wie viele Informationen kodiert werden, denn die fehlenden
Informationen werden vom Benutzer abgefragt.
Die Funktion „SQLBrowseConnect()“ stellt dieselben Möglichkeiten zur
Verfügung wie „SQLDriverConnect()“. Zusätzlich kann mit dieser Funktion das
visuelle Erscheinungsbild während der Interaktion mit dem Nutzer beeinflusst
werden. Dabei kann die Anwendung Ihr eigenes Dialogfeld benutzen und die
von „SQLBrowseConnect()“ spezifizierten Informationen benutzen. Diese
werden als Attribut-Wert-Paar zurückgeliefert. Wenn die Anwendung alle
Informationen ermittelt hat, kann „SQLBrowseConnect()“ mit diesen erneut
aufgerufen und die Verbindung aufgebaut werden.
Das Ausführen der SQL-Befehle bietet ebenfalls drei verschiedene
Möglichkeiten:
1. ExecDirect:
Das Modell „ExecDirect“ fasst alle Schritte in einem einzigen
Funktionsaufruf von SQLExecDirect zusammen. Dabei werden die SQLAnweisungen spezifiziert, an den Server gesendet und danach ausgeführt.
Es ist deshalb besonders gut für solche Anweisungen, die nur einmal
ausgeführt werden, geeignet. Nach der Ausführung der SQL-Anweisung
werden die verwendeten Optimierungsinformationen vom DBMS
verworfen.
2. Prepare/Execute- Vorbereiten/Ausführen-Modell:
Dieses Modell unterteilt die Schritte in zwei Teile. Im ersten Teil wird die
SQL-Anweisung vorbereitet; das bedeutet, sie wird an den Server
geschickt, geparst und optimiert (SQLPrepare). Zeitlich unabhängig kann
dann in einem zweiten Schritt die so vorbereitete Anweisung ausgeführt
werden (SQLExecute). Dabei wird nicht die eigentliche SQL-Anweisung an
den Server gesendet, sondern ein Verweis der Anweisung, so dass der
44
vorhandene Zugriffsplan unmittelbar ausgeführt werden kann. Erst wenn
die Anwendung beendet wurde, wird der Zugriffsplan im DBMS gelöscht.
Dieses Modell findet Anwendung bei Anweisungen, die mehrmals
ausgeführt werden oder wenn diese dynamisch zur Laufzeit generiert
werden.
3. Gespeicherte Prozeduren:
Diese Modell ist dem Prepare/Execute-Modell sehr ähnlich. Hier kann
jedoch der Vorbereitungsschritt abgekoppelt von der Anwendung erfolgen
und die gespeicherte Prozedur über die Laufzeit der Anwendung erhalten
bleiben. Zugriffsberechtigungen erfolgen in diesem Modell nur anhand der
User-ID, im Gegensatz zu statischem SQL, wo dies auch
anwendungsabhängig möglich ist.
Bei der Ausführung der Anweisungen unterscheidet man noch in zwei
verschiedene Modi, in die asynchrone und die synchrone Ausführung. Bei der
synchronen Ausführung, die standardmäßig eingestellt ist, wird die Steuerung
erst nach dem Beenden der Funktion an die Anwendung zurückgegeben. Die
asynchrone Ausführung gibt der Anwendung vor der Ausführung der Funktion
die Steuerung zurück, und diese muss dann in gewissen Zeitabständen prüfen,
ob die Funktion bereits beendet ist. Der Modus kann mittels der Funktion
SQLSetConnectOption oder SQLSetStmtOption durch das Setzen des Flags
SQL_ASYNC_ENABLE erfolgen.
3.3.2 MFC-ODBC-Klassen
Die MFC-ODBC-Klassen bieten ebenfalls die Möglichkeit der ODBCProgrammierung. Dabei wird die Funktionalität von ODBC in Klassen
„CDatabase“ und „CRecordset“ gekapselt29).
Durch die Klasse „CDatabase“ kann die Verbindung zu einer Datenbank über
die Funktion „Open()“ hergestellt und mit der Funktion „Close()“ beendet
werden. Dabei nimmt das Attribut „m_hdbc“ das ODBC-Verbindungshandle auf.
Zusätzlich enthält die Klasse „CDatabase“ Operationen zur
Verbindungseinstellung. Dazu verwendet die Klasse einen asynchronen Modus.
29)
Vgl. [On9]
45
Mit Hilfe der Methode „Cancel()“ kann die laufende Abarbeitung unterbrochen
werden. Ebenfalls enthält die Klasse „CDatabase“ Funktionen zur
Transaktionsbearbeitung, wie z.B. die Funktionen „BeginTrans()“ und
„CommitTrans()“. Durch die Operation „ExecuteSQL()“ können SQLAnweisungen abgesetzt werden.
Die Klasse „CRecordSet“ wird durch die Funktion „Open()“ mit einem SQLStatement verbunden und repräsentiert somit diese Anweisung. Die Attribute
dieser Klasse kapseln das Anweisungshandle. Sie enthalten u.a. die Nummern
der Felder und die Parameter im Datensatz. Die Memberfunktion „Open()“, der
Klasse „CRecordSet“, öffnet einen Datensatz. Dabei stehen zwei
Datensatztypen zur Verfügung, Dynasets und Snapshots:
•
Snapshots: Dies ist eine statische Ansicht der Daten. Sie werden in der
Form zum Zeitpunkt ihrer Erstellung dargestellt. Dabei werden
zwischenzeitliche Änderungen nicht berücksichtigt.
•
Dynasets: Dynasets sind die dynamische Ansicht der Daten. Hierbei
werden alle Änderungen von Anwendern berücksichtigt.
Die Methode „Close()“ schließt den Datensatz und somit das
Anweisungshandle. Ebenso stehen in der Klasse „CRecordSet“ zur Ermittlung
der Parameter des Datensatzes weitere Funktionen zur Verfügung, u.a.
„GetStatus()“ und „GetTableName()“. Durch die Operationen „Move()“,
„MoveNext()“, „MoveLast()“ und „MovePrev()“ kann man die einzelnen
Datensätze selektieren. Das Löschen, Bearbeiten, Aktualisieren und
Hinzufügen von Datensätzen kann mit Hilfe der Funktionen „Delete()“, „Edit()“,
„Update()“ und „AddNew()“ durchgeführt werden.
3.4 Anforderungen
In diesem Kapitel wird aus der Analyse des Softwaresystems SiSy® und
dessen Schnittstellen heraus die Funktionalität und die Anforderungen an die
Schnittstelle zu den externen Datenformaten beschrieben.
Die Schnittstelle soll modellierte Daten aus einem oder mehreren Modellen, die
in SiSy® bereitgestellt werden, in ein externes Datenformat überführen. Kurz
gesagt, mit Hilfe der Schnittstelle soll ein Datenexport durchgeführt werden
können.
46
Die Funktionalität der Schnittstelle soll in SiSy® integriert werden und als AddOn in SiSy® installierbar sein. Beim erstellen des Add-Ons müssen auf die
Namens- und Dateikonventionen in SiSy® geachtet werden. Die Anlage 3
enthält diese Dateikonventionen.
Um dem Nutzer die Schnittstelle zugänglich zu machen, muss eine
Benutzeroberfläche bereitgestellt werden. Dazu sollen SiSy-Basic-Dialoge
entworfen werden, die sich an bestehenden Dialogoberflächen und der
Nutzerführung in SiSy® orientieren. Dieser Dialog muss an zentraler Stelle in
SiSy® aufrufbar sein. Er soll die Möglichkeit zur Auswahl des Exportformats
haben. Hier muss auch das Exportverzeichnis bzw. die Exportdatei durch den
Nutzer festgelegt werden können. Des weiteren muss der Dialog eine Liste
bereitstellen in der die zu exportierenden Objekttypen und die Objekttypen, in
welchen nach den zu exportierenden Objekttypen gesucht werden soll,
ausgewählt werden können. Zusätzlich muss der Nutzer in den Dialogen
bestimmen können welche Eigenschaften der Objekte exportiert werden sollen.
Zu den Eigenschaften muss ebenfalls der jeweilige Datentyp durch den Nutzer
bestimmt werden. Um die Handhabung für den Nutzer zu vereinfachen, soll im
Dialog ein Möglichkeit zur Auswahl einer Vorlage gegeben werden. Durch eine
solche Vorlage sollen alle Angaben, wie zu exportierende Objekttypen und zu
exportierende Eigenschaften, bereits voreingestellt sein. Die Einstellungen,
welche der Nutzer vornimmt, sollen auch als Vorlage gespeichert werden
können.
Um die Daten im Dialog einzustellen und zu verarbeiten, muss ein SiSyBasicSkript bereitgestellt werden, welches die Funktionalität des Dialoges
unterstützen muss. Die Funktionen des Skripts müssen die Daten, welche
durch den Nutzer im Dialog festgelegt wurden, in einem geeigneten Format wie
XML, CSV oder MySQL zur Weiterverarbeitung speichern. Hier ist eine
eindeutige Definition der Daten erforderlich.
Um den Export möglich zu machen, müssen Klassen erstellt werden, welche
die zu exportierenden Daten zusammenstellen und sie in das gewählte
Exportformat formatieren und speichern. Die Klassen müssen in der Sprache
47
C++ erstellt werden. Für den Export sollen die Klassen die Daten aus dem
SiSy-Repository auslesen und zwischenspeichern. Die Daten sollen auch durch
diese Klassen in das durch den Nutzer gewählte Format formatiert und
gespeichert werden. Dabei sollen jeweils für die Formate CSV und XML eine
Datei erzeugt werden. Die XML-Dokumente sollen wohlgeformt und gültig
generiert werden, dazu soll zu jedem Dokument eine DTD erstellt werden. Um
Daten in einer MySQL-Datenbank zu speichern soll zusätzlich eine ODBCSchnittstelle genutzt werden. Dazu sollen die durch die MFC bereitgestellten
Klassen genutzt werden. Durch diese ODBC-Schnittstelle soll eine Datenbank
und deren Spalten erzeugt werden und die Daten des Exportes in dieser
gespeichert werden. Dabei sollen konforme Dateien bzw. Statements erzeugt
werden.
So ergeben sich aus den Anforderungen für die Schnittstelle die in der Tabelle
4 folgenden Qualitätsanforderungen.
Tabelle 4 Qualitätsanforderungen
Produktqualität
sehr gut
gut
Funktionalität
x
Zuverlässigkeit
x
befriedigend nicht relevant
Benutzbarkeit
x
Effizienz
x
Änderbarkeit
x
Übertragbarkeit
x
48
4 Entwurf und Realisierung der Schnittstelle
In diesem Kapitel wird der Entwurf der Schnittstelle zwischen dem SiSyRepository und externen Datenformaten aus den Anforderungen der Analyse
abgeleitet und erläutert. Dabei wird zunächst auf die Architektur der
Schnittstelle eingegangen und anschließend die einzelnen Komponenten, wie
z.B. der Dialog, näher betrachtet.
Die Schnittstelle soll als ein Add-On in SiSy® installierbar sein. Da durch die
Schnittstelle ein Datenexport durchgeführt werden soll, wird anhand der SiSyNamenskonvention der Dateiname „Dat_exp.*“ festgelegt. Dabei steht das
Kürzel „Dat“ für Daten und das Kürzel „exp“ für Export, „Datenexport“. Somit ist
eine eindeutige Identifizierung der zugehörigen Dateien zum Add-On
gewährleistet.
Bei dem groben Entwurf der Schnittstelle wurde darauf geachtet, dass die
Schnittstelle leicht zu pflegen und anzupassen ist. So wurde eine Drei-EbenenArchitektur gewählt, welche aus der Betrachtung der Umgebung in SiSy®
hervorgegangen ist. Sie ist in Abbildung 16 sehen.
SiSyBasic-Klassen-Ebene
Assi.exe
SiSyBasic-Dialog-Ebene
Dat_exp.flq
und
Dat_exp.fld
SiSyBasic-Skript-Ebene
Abbildung 16 Die Schichtenarchitektur der Schnittstelle
Die erste Ebene ist die SiSyBasic-Skript-Ebene. Sie erzeugt die Dialog-Ebene
und stellt ihr Funktionen bereit, welche im bzw. durch den Dialog aufgerufen
werden und somit die Funktionalität des Dialoges unterstützen. Die SiSyBasicDialog-Ebene beschränkt sich auf die Schnittstelle zum SiSy®-Nutzer in Form
von den SiSy®-Dialogen. Die Skript-Ebene ist eine Art Schnittstelle zwischen
49
der Dialog-Ebene und der SiSyBasic-Klassen-Ebene. Die Klassen-Ebene
besitzt SiSyBasic-Klassen mit Funktionen, welche die Verarbeitung der
Exportdaten aus dem Repository von SiSy® übernehmen. Dazu werden in der
Klassen-Ebene mehrere Klassen zur Verfügung gestellt, welche den Export der
Daten durchführen. Die wichtigsten Klassen sind dabei die Klasse
„CImportExportDat“ und die Klasse „CTableObj“. Sie werden in der „Assi.exe“
bereitgestellt und benutzen u.a. andere Klassen, die bereits in die „Assi.exe“
implementiert wurden.
Zur besseren Veranschaulichung des Zusammenwirkens der einzelnen
Komponenten wurde das Problem der Schnittstelle zwischen dem SiSy®Repository und ausgewählten externen Datenformaten in einem
Komponentendiagramm, der UML, visualisiert. Der Entwurf der
Komponentenarchitektur der Schnittstelle sehen Sie in der Abbildung 17 Der
Entwurf der Schnittstelle.
SiSy
SiSyBasic-Skript
benutzt
SiSyBasic-Klassen
ruft auf
benutzt
TableObj
benutzt
ImportExportDat
Dialog
liest in
SiSy-Repository
Schnittstelle_1
Schnittstelle_2
externe Datenformate
Nutzer
Schnittstelle_1
XML
Schnittstelle_2
CSV
Schnittstelle_2
SQL
Schnittstelle_2
Abbildung 17 Der Entwurf der Schnittstelle
Hier sehen Sie die Komponente SiSy®, die Komponente der externen
Datenformate und den Nutzer, der hier als Knoten dargestellt wurde. Die
Komponenten besitzen weitere Unterkomponenten, die wichtig für den Entwurf
50
der Schnittstelle sind. Der Nutzer besitzt die „Schnittstelle 1“, die zur
Komponente „Nutzer-Dialog„ führt. Der Nutzerdialog der SiSyBasic-DialogEbene benutzt das SiSyBasic-Skript und dessen Funktionen. Die SiSyBasicKlassen werden durch das SiSyBasic-Skript angesprochen. Sie benutzen sich
gegenseitig und stehen somit auch in Beziehung zueinander. Mit Hilfe der
Komponente „Klasse ImportExportDat“ wird die Schnittstelle zu den externen
Datenformaten, wie XML, CSV und MySQL, hergestellt. Die Klassen-Ebene
wird in Kapitel 4.3 erläutert.
Die Schnittstelle soll über den „Definieren Dialog“ des Projektes aufgerufen
werden können. Dazu wird die Dialogseite „Datenexport“ diesem Dialog beim
installieren des Add-Ons hinzugefügt. Auf dieser Seite befindet sich ein Schalter
über den der „Datenexport“ aufgerufen werden kann. Die Abbildung 18 zeigt
diesen Dialog.
Abbildung 18 Die Dialogseite Datenexport
Durch den Schalter „Datenexport starten“ wird die Skript-Ebene der
Schnittstelle aufgerufen. Diese soll im folgenden Kapitel erläutert werden.
51
4.1 Die Skript-Ebene
Die Skript-Ebene wird durch die Funktion „Dlg_DatExportWizard()“ in der Datei
„dat_exp.flq“ angesprochen. Diese Funktion erzeugt den Dialog und somit die
Schnittstelle des Datenexports zum Nutzer. Die Abbildung 19 zeigt den Ablauf
SiSyBasic
WizardDialog
SiSyPfad holen
Dialog erzeugen
INI-Datei
initialiseren
Dialog aus
INI-Datei holen
Ablauf
Wizard-Dialog
Prüfen ob Export
durchgeführt wurde
[Export durchgeführt]
[Export abgebrochen]
Meldung
erfolgreiche
Durchführung
Meldung Export
abgebrochen
Abbildung 19 Der Ablauf des SiSyBasic-Skripts
dieser Funktion in einem Aktivitätsdiagramm. Durch die Aktion „Ablauf des
Wizard-Dialoges“ wird der Ablauf des Dialoges symbolisiert. Die Dialog-Ebene
und dessen Ablauf wird im Kapitel 4.2 erläutert.
Nachdem der Dialog erzeugt wurde, wird durch die Skript-Ebene eine Instanz
der SiSyBasic-Klasse „ImportExportDat“ erzeugt, die durch die Klassen-Ebene
bereitgestellt wird. Damit kann die Skript-Ebene während der Laufzeit des
Dialoges auf Funktionen der Klassen-Ebene zugreifen. So können alle
Exporteinstellungen des Dialoges, parallel zu dessen Laufzeit, durch Methoden
der Klasse „ImportExportDat“ in der Klassen-Ebene gespeichert werden.
52
Nachdem alle Exportinformationen im Dialog festgelegt wurden und dieser
durch den Schalter „Export starten“ beendet wird, ruft die SiSyBasic-SkriptEbene die Funktion „startExport()“ der SiSyBasic-Klasse „ImportExportDat“ auf
und startet somit den eigentlichen Datenexport. Die Abbildung 20 soll die
Interaktion der Skript-Ebene bei diesem Aufruf deutlich machen.
WizardDialog
Schalter "Export
starten" betätigt
SiSyBasic
Prüfen ob der
Export gestartet
werden soll
ImportExportDat
[Export starten]
Variablen
aufbereiten
setTabellenName
setExportFormat
Prüfen ob
Eigenschaft zum
Exportieren
vorhanden
setExportZiel
[Eigenschaft vorhanden]
Daten einer
Spalte aufbereiten
addSpalte
[keine weitere
Eigenschaft vorhanden]
Prüfen ob weitere
Eigenschaft
vorhanden
Repo.ScanTree
[Export nicht starten]
Prüfen ob Objekte
gefunden
Dialog beenden
[keine Objekte gefunden]
[Objekte gefunden]
Export starten
startExport
Abbildung 20 Der Ablauf der Skript-Ebene beim Starten des Exports
Zunächst werden die Exportdaten wie der Tabellenname, das Exportformat und
das Exportziel in der Klasse „ImportExportDat“ gespeichert. Anschließend
werden die Daten der Exportspalten, wie z.B. Spaltenname, Datentyp und
Primärschlüsseleigenschaft, aufbereitet. Die Spalten mit diesen Daten werden
dann mit Hilfe der Aktion „addSpalte“ einer Tabelle hinzugefügt, dies soll in
Kapitel 4.3 näher erläutert werden.
53
Durch die Aktion „Repo.Scantree“ wird das SiSy®-Repository nach dem zu
exportierenden Objekttyp durchsucht, den der Nutzer im Dialog definiert. Dabei
werden alle Nummern der Objekte dieses Objekttyps in einem Feld gespeichert.
Dieses Feld wird beim Starten des Exports an die Methode „startExport()“ der
Klasse „ImportExportdat“ übergeben.
Die Aktion „startExport“ in der Klasse „ImportExportDat“ repräsentiert den
Ablauf, durch den der Export unter Verwendung weiterer Klassen, der KlassenEbene, durchgeführt wird. Die Klassen-Ebene soll in Kapitel 4.3 näher erläutert
werden.
Desweiteren unterstützt die Skript-Ebene den Dialog u.a. mit Funktionen die
ListBoxen generiert. Dazu soll eine INI-Datei definiert werden. INI-Dateien
können zur Speicherung von systemweiten Daten genutzt werden. Sie
bestehen aus Sektionen und Einträgen in den Sektionen. Die Sektionsnamen
sind in eckige Klammern eingeschlossen. Darunter stehen die zu Sektion
gehörigen Einträge, denen durch ein Gleichheitszeichen ein Wert zugewiesen
wird. Um die Skript-Ebene zu unterstützen und um einfacher diesen
Datenexport um neue, weitere Formate zu erweitern, sollen Format-bezogene
Daten in der „Dat_exp.ini“ gehalten werden. In dieser Datei stehen die
auszuwählenden Formate in einer Sektion „[Formate]“. In einer Sektion
„[DatTyp]“ sollen die auszuwählenden Datentypen der jeweiligen Formate
hinterlegt werden. Dabei werden die Eintrage nummeriert. Die Nummern der
Datentypen entsprechen den Nummern der zugehörigen Formate. Diese
Informationen werden dann zur Laufzeit des Dialoges auf den jeweiligen Seiten
durch Funktionen der Skript-Ebene in den Dialog ausgelesen und dort zur
Auswahl in einer ListBox angeboten. Somit sollen auch neue Formate besser
und einfacher in das Modul eingepflegt werden können.
Weiterhin soll die Skript-Ebene das Laden und Speichern von Vorlagen im
Dialog ermöglichen. Dazu werden *.FLK-Dateien im INI-Format angelegt, wie
es in SiSy® bereits angewendet wird. Diese besitzen die Sektionen „[Setup]“
und „[Werte]“. Die Sektion „[Setup]“ enthält alle allgemeinen Informationen zur
Vorlage, wie z.B. den Vorlagentyp, den Titel der Vorlage und eine Beschreibung
der Einstellungen. In der Sektion „[Werte]“ werden alle Daten bzw.
54
Einstellungen zum Export abgelegt, u.a. Exportobjekttyp und zu exportierende
Eigenschaften mit Datentypen.
Der Dialog, der durch diese Funktionalitäten unterstützt wird, und dessen
Aufbau soll im folgenden Kapitel erläutert werden.
4.2 Die Dialog-Ebene
Beim Entwurf des Dialoges wurde darauf geachtet, dass sich dieser, an der
Nutzerführung und dem Dialogaufbau anderer SiSy®-Komponenten orientiert.
Hier fand vor allem der Dialog des Objekts „Aufzählen“ in SiSy® Beachtung.
Beim Export von Daten aus SiSy® herausmüssen viele Daten erfasst und
aufbereitet werden. Neben dem Festlegen eines Exportformates muss der
Nutzer auch die zu exportierenden Objekte, deren Eigenschaften usw.
bestimmen. Die Tätigkeiten, die der Anwender bzw. Nutzer durchführen muss,
wurden in einem Anwendungsfalldiagramm, das in der Abbildung 21 zu sehen
ist, dargestellt.
Schnittstelle Datenexport
Exportformat
festlegen
Speicherort und
-name festlegen
ODBC-Datenquelle
bestimmen
StartObjekt
festlegen
"Abtauch"-Objekttypen
festlegen
Export-Objekttyp
festlegen
Nutzer
zu exportierende
Eigenschaften der
Objekte festlegen
Export-Eigenschaften
festlegen
Auswahl Vorlage
Vorlage speichern
Export starten
Abbildung 21 Anwendungsfalldiagramm der Schnittstelle
55
Bei dem Entwurf eines Prototypen der Schnittstelle zwischen dem SiSy®Repository und externen Datenformaten wurde festgelegt, dass nur ein
Objekttyp mit dessen Eigenschaften exportiert werden kann. So kann auf der
Seite der Auswahl der zu exportierenden Objekte in der prototypischen
Umsetzung nur ein Objekttyp ausgewählt werden.
Damit der Nutzer alle nötigen Daten richtig und vollständig eingibt, und dazu
eine einfache Nutzerführung bereitgestellt bekommt, wurde ein Wizard-Dialog
für die Schnittstelle gewählt. Der Wizard-Dialog, in SiSy®, ist ein Dialog mit
einer beliebigen Anzahl von Dialogseiten, die durch den Nutzer sequentiell
nacheinander abgearbeitet werden müssen. Beim Entwerfen des Dialoges
wurden weitere ergonomische Aspekte, wie der übersichtliche Aufbau und
Erläuterung der Dialoge, beachtet. Auf jeder Seite des Dialoges können
verschiedene Daten, die für den Export nötig sind, festgelegt werden. Die Daten
jeder einzelnen Seite werden beim Verlassen der Seite durch Funktionen des
SiSyBasic-Skripts auf Korrektheit und Vollständigkeit geprüft. Falls durch den
Nutzer inkonsistente Daten eingegeben werden, erscheint beim Versuch des
Verlassen der Dialogseite eine Meldung, dass die Daten nicht korrekt oder
unvollständig eingegeben wurden. Der Nutzer bleibt dann auf der aktuellen
Dialogseite und kann erst nach korrekter Eingabe der Daten auf der nächsten
Seite mit der Eingabe fortfahren.
Alle Dialogseiten sind in der Anlage 4 zu finden und sind dort komplett
dargestellt. Der Ablauf des Dialoges ist in der Abbildung 22 zusehen. Diese
Abbildung zeigt die Abfolge der Dialogseiten in einem Aktivitätsdiagramm und
verdeutlicht den Ablauf der Eingabe der Exporteinstellungen im Dialog.
56
WizardDialog
Dialog-Seite Tipp
Dialog-Seite
Ausgabeform
[Format MySQL]
Dialog-Seite
ODBCVerbindung
[Format XML oder CSV]
Dialog-Seite Start
Dialog-Seite
Startobjekt
[Vorlage auswählen]
Dialog-Seite
Vorlagenauswahl
[Manuell einstellen]
Dialog-Seite
Abtauchen
Dialog-Seite
Manuell
Dialog-Seite
Exportieren
Dialog-Seiten
Spalten
Dialog-Seite
Speichern als
Vorlage
Dialog-Seite
Übersicht
Abbildung 22 Der Ablauf des Dialoges
Auf der Seite „Tipp“ erhält der Nutzer eine kurze Erläuterung zur Durchführung
des Datenexports. Bei der sequentiellen Abarbeitung des Wizard-Dialoges kann
der Nutzer mit Hilfe de Schalter „Weiter“ und „Zurück“ zwischen den einzelnen
Dialogseiten vor und zurück wechseln. So kommt er zur nächsten Dialogseite
mit dem Schalter „Weiter“. Hier kann der Nutzer das gewünschte Exportformat
und einen Namen für den Export wählen. Dieser Dialog ist in Abbildung 23 zu
sehen. Anhand dieses Dialoges sollen die ergonomischen Aspekte deutlich
gemacht werden. Der Dialog ist einfach und leicht überschaubar aufgebaut.
Der Nutzer arbeitet den Dialog von oben nach unten ab, so wie die bevorzugte
Leserichtung eines Menschen ist. Zuerst wählt der Nutzer das Exportformat aus
57
einer Listbox aus und vergibt anschließend einen Namen für den Export. Aus
diesen Daten werden Dateiname und das Verzeichnis des Exportes generiert.
Durch den Schalter „Verzeichnis wählen“ kann der Nutzer das Verzeichnis
manuell festlegen.
Abbildung 23 Die Dialogseite-"Ausgabeform"
Wenn der Nutzer das Exportformat „MySQL“ gewählt hat, kommt er durch den
Schalter „Weiter“ zur Seite „ODBCVerbindung“. Dort kann die Datenquelle
ausgewählt werden. Bei der Auswahl eines anderen Formats gelangt der
Nutzer sofort zur Seite „Startobjekt“.
Auf dieser Seite muss ein Startobjekt festgelegt werden, auf dem die Suche
nach dem zuexportierenden Objekttyp begonnen werden soll.. Hierzu wird eine
Listbox mit der Auswahl des Objekttyps erzeugt. Bei dieser Auswahl aus einer
generierten Listbox werden alle Objekte in einer weiteren Listbox zur Auswahl
des Startobjektes gegeben.
Danach hat der Nutzer die Möglichkeit eine Vorlage zu laden oder selbst die
weiteren Einstellungen zu bestimmen. Auf der Seite der „Vorlagenauswahl“
können Vorlagen aus einer Liste geladen werden, durch die alle weiteren
Festlegungen der Exportdaten in den folgenden Dialogen voreingestellt sind. Zu
den einzelnen Vorlagen kann der Nutzer auch Informationen und
Beschreibungen aus dem Dialog heraus aufrufen und abfragen.
58
Von der Dialogseite der Vorlagenauswahl kommt der Nutzer zur Seite
„Manuell“, in der man durch Schalter zu Dialogseiten „Abtauchen“ und
„Exportieren“ gelangt. Auf der Seite „Exportieren“ kann der zu exportierende
Objekttyp bestimmt werden. Auf der Seite „Abtauchen“ kann der Nutzer
festlegen in welchen Objekttypen nach den zu exportierenden Objekttypen
gesucht werden soll.
Nachdem durch den Nutzer die jeweiligen Objekttypen definiert wurden, legt er
die Eigenschaften mit zugehörigen Datentypen fest die beim Export den
Tabellen entsprechen.. Hier wird auch namentlich festgelegt wie Spalten bzw.
Eigenschaften des Exports benannt werden sollen. Die Eigenschaftsnamen
bzw. Spaltennamen in der Exportdatei sollen in einem Editfeld angegeben
werden. Die zu exportierenden Eigenschaften der Objekte stehen in einer
Listbox zur Auswahl. Hier sollen Eigenschaften, welche jedes Objekt besitzt, zu
wählen sein. Die Auswahl der Datentypen wird über eine Listbox realisiert.
Dazu sollen die Datentypen von MySQL und die Elementtypen von XML
genutzt werden. Für das Format CSV werden Datentypen von MS Excel
genutzt, wie z.B. Text, Zahl oder Datum. Zusätzlich sollen bei Auswahl des
Formates „MySQL“ festgelegt werden welche Eigenschaft als Primärschlüssel
dienen soll. Dazu wird eine CheckBox zu jeder Eigenschaft im Dialog erzeugt.
Die Einstellungen dieser Dialogseite werden ebenfalls durch eine Funktion auf
Konsistenz und Integrität der Daten überprüft. So wird gewährleistet, dass der
Nutzer stets konsistente Daten exportiert.
Zum Schluss erscheint eine Übersicht der Einstellungen, in der alle festgelegten
Daten noch einmal anführt werden. Hier hat der Nutzer die Möglichkeit die
Einstellungen in einer Vorlage zu speichern.
59
4.3 Die Klassen-Ebene
Die Klassen-Ebene soll die durch den Nutzer gewählten Daten aus dem SiSy®Repository in eine virtuelle Tabelle importieren und anschließend diese
Informationen in das gewünschte Format exportieren.
Dazu wurde die SiSyBasic-Klasse „ImportExportDat“ entworfen, die dem
SiSyBasic-Skript Funktionen bereitstellt, mit denen der Export der Daten
durchgeführt werden kann. Der Funktionsumfang dieser Klasse beschränkt sich
u.a. auf das Festlegen des Exportformats, das Hinzufügen von Spalten einer
Tabelle der Klasse „CTableObj“ und das Starten des Exports. Die SiSyBasicKlasse „ImportExportDat“ wird durch die Interpreterklasse
„CInterp_ImportExportDat“ interpretiert. Das bedeutet, die Funktion „WorkMember()“ dieser Klasse prüft, welche Funktion in der SiSyBasic-Klasse
angesprochen wurde und startet die entsprechende Funktionen der Klasse
„CImportExportDat“. Somit erzeugt die Interpreterklasse
„CInterp_ImportExportdat“ die C-Klasse „CImportExportDat“. Dieser
Sachverhalt soll kurz an einem Beispiel verdeutlicht werden:
In SiSyBasic wird die Funktion „startExport()“ der SiSyBasic-Klasse
„ImportExportDat“ aufgerufen. Der SiSy® -Interpreter prüft durch die
Interpreterklasse „CInterp_ImportExportDat“, ob diese Funktion vorhanden ist,
und ruft die Methode „startExport()“ der C-Klasse „CImportExportDat“ auf.
Die Klasse „CImportExportDat“ ist die eigentliche Export-Klasse. Sie wurde
„CImportExportDat“ genannt, da mit Hilfe dieses Entwurfs eventuell ein Import
von Daten in SiSy® realisiert werden soll. Der Entwurf des Klassendiagramms,
der in der Abbildung 24 zu sehen ist, soll sich jedoch auf den Export von Daten
aus SiSy® beschränken.
60
CImportExportDat
SiSyBasic::ImportExportDat
# m_akt_db : CDatabase
# tabName : CString
# exportFormat : CString
# exportZiel : CString
# tabObj : CTableObj
# interp : CInterp_ImportExportDat
+ startExport(CString objNrArray) : void
+ setTabellenName(String tabName) : void
+ setExportZiel(String exportZiel) : void
+ addSpalte(String exportQuelle_Eigensc...) : void
+ setExportFormat(String exportFormat) : void
+ setAllParameter(String allParameter) : void
+ getAllParameter() : String
+ getTabName() : String
+ getExportFormat() : CString
+ getExportVerzeichnis() : String
+ firstConnect() : void
1
1
interpretiert durch
1
benutzt
+ startExport(CString objNrArray) : int
+ setTabname(CString tabName) : void
+ setAllParameter(CString allParameter) : void
+ getAllParameter() : CString
+ setExportFormat(CString exportFormat) : void
+ setExportVerzeichnis(CString exportVerzeichnis) : void
+ getTabName() : CString
+ getExportFormat() : CString
+ getExportVerzeichnis() : CString
1
1
CDatabase
benutzt
1
1
# akt_dsn : CString
+ firstConnect() : BOOL
+ changeODBCConnect() : BOOL
+ executeSQL() : void
+ getConnect() : CString
erzeugt
erzeugt
1
1
CInterp_ImportExportDat
CStmtDialog
1
# impExpDat : CImportExportDat
# stmts : CString
CTableObj
+ Work_Member(CString para1, CString para...) : void
# rows : CPtrArray
# header : CTableObj_Header
+ addRowsFromRepo(CDWordArray* objnrlist) : int
+ getContentCSV() : CString
+ getContentSQL(CString exportName, CString...) : CString
+ getContentXML(CString exportName, CString...) : CString
1
besitzt
CSOVObjekt
1
besitzt
1
1
1
n
CTableObj_Header
CTableObj_Row
# headerFelder : CPtrArray
+ addColumnFeld(CString spaltenQuelle, CStr...) : int
+ getFirstHeaderFeld() : CTableObj_HeaderFeld*
+ getNextHeaderFeld() : CTableObj_HeaderFeld*
kennt
1
1
# sov : CSOVObjekt
# rowFelder : CPtrArray
# header : CTableObj_Header*
+ initFromRepo(Long objNr, CTableObj_Heade...) : int
+ getContentRowCSV() : CString
+ getContentRowSQL(CString tabName) : CString
+ getContentRowXML(CString tabName) : CString
1
besitzt
1
besitzt
n
CTableObj_HeaderFeld
n
# spalte : CString
# datentyp : CString
# primarykey : BOOL
# spaltenQuelle : CString
+ setSpalte(CString spaltenname) : void
+ setDattyp(CString dattyp) : void
+ getSpalte() : CString
+ getDattyp() : CString
+ setPrimarykey(BOOL primarykey) : void
+ getPrimarykey() : BOOL
+ setSpaltenQuelle(CString spaltenQuelle) : void
+ getSpaltenQuelle() : CString
CTableObj_RowFeld
kennt
1
1
# feldInhalt : CString
# hFeld : CTableObj_HeaderFeld*
+ initFromRepo(CSOVObjekt* sovObj, CTableO...) : void
+ getContentFeldCSV() : CString
+ getContentFeldSQL() : CString
+ getContentFeldXML() : CString
Abbildung 24 Entwurf des Klassendiagramms
Die Klasse „CImportExportDat“ erzeugt die Klasse „CTableObj“. Mit Hilfe dieser
Klasse wird eine virtuelle Tabelle mit einem Tabellenkopf, dem „Header“, und
mit mehreren Reihen, den „Rows“, erzeugt. Bevor der Datenexport gestartet
wird, müssen die Spalten der Tabelle durch die Funktion „addSpalte()“ der
SiSyBasic-Klasse erzeugt werden. Durch den Aufruf dieser Funktion wird die
Funktion „addColumnFeld()“ der Klasse „CTableObj_Header“ aufgerufen und
eine Spalte mit Namen, Datentyp, Primärschlüsseleigenschaft und der
Quelleigenschaft erzeugt.
Nachdem alle Spalten der Tabelle generiert wurden, kann der Export gestartet
werden. Der Ablauf der Funktion „startExport()“ ist in Abbildung 25 zu sehen.
Dabei ruft die Funktion „startExport()“ die Methode „initFromRepo()“ der Klasse
61
„CTableObj“ auf. Der Operation „initFromRepo()“ wird als Parameter eine Liste
aller zu exportierenden Objekte übergeben.
ImportExportDat
CTableObj
export==OK
CTableObj_Row
initFromRepo
initFromRepo
CTableObj_RowFeld
initFromRepo
Prüfung ob
Tabelle gefüllt
[Tabelle gefüllt]
Prüfung des
Formats ob
"MySQL"
CODBC
[Format ist MySQL]
Aufbau einer
ODBC-Verbindung
getContentSQL
CODBCDialog
Prüfen ob Format
XML
erzeuge
ODBC-Dialog mit
generierten
Statements
[Format XML]
[Format CSV]
getContentXML
getContenCSV
SQL-Statements
absenden
Abbau der
ODBC-Verbindung
speichern in Datei
Abbildung 25 Der Ablauf des Exports in der Klassen-Ebene
Diese Methode wiederum erzeugt für jedes Objekt eine Instanz der Klasse
„CTableObj_Row“. Im Konstruktor dieser Klasse wird die Methode
„initFromRepo()“ aufgerufen und eine Objektnummer und ein Pointer auf die
Klasse „CTableObj_Header“ als Parameter übergeben. Die Operation
„initFromRepo()“ der Klasse „CTableObj_Row“ initialisiert das „CSOVObjekt“
mit der Objektnummer und ruft für jedes „HeaderFeld“ eine Instanz der Klasse
„CTableObj_RowFeld“ auf. Somit wird für jede vorhandene Spalte bzw.
„HeaderFeld“ ein Zeilenfeld bzw. „RowFeld“ erzeugt.
62
Der Konstruktor der Klasse „CTableObj_RowFeld“ ruft wiederum dessen
Funktion „initFromRepo()“. Diese bekommt als Parameter jeweils einen Pointer
auf das „CSOVObjekt“ und auf ein Objekt der Klasse „CTableObj_HeaderFeld“.
Sie holt sich aus dem „HeaderFeld“ die zu exportierende Eigenschaft mit der
Methode „getSpaltenQuelle()“ und exportiert diese aus dem „CSOVObjekt“ in
den Feldinhalt der Tabelle.
Wenn die Tabelle komplett mit allen zu exportierenden Daten gefüllt ist, wird
das Format geprüft und die entsprechende „getContent()“-Methode der Klasse
„CTableObj“ aufgerufen. Diese ruft dann die „getContent()“-Methode der Klasse
„CTableObj_Row“ usw. Durch jene Funktionen werden die Daten der virtuellen
Tabelle in das jeweilige Exportformat generiert werden. Beim Export in die
Formate CSV und XML werden gültige und konforme CSV- bzw. XMLDokumente erzeugt. Beispiele solcher Dokumente werden in Anlage 5 und
Anlage 6 gezeigt. Beim Format MySQL werden gültige SQL-Statements nach
dem ANSI-SQL/92-Standard generiert. Diese Dokumente bzw. Statements
werden anschließend gespeichert.
Bei den Formaten CSV und XML erfolgt das Speichern jeweils in einer Datei.
Anders beim Format MySQL, hier sollen die Informationen über eine ODBCVerbindung in eine Datenbank gespeichert werden. Dabei soll zuerst eine
ODBC-Verbindung hergestellt und ein Dialog mit den generierten SQLStatements erzeugt werden. Darin soll der Nutzer die Möglichkeit haben die
SQL-Statements zu bearbeiten und anschließend über einen Schalter
absenden zu können. Abschließend wird die ODBC-Verbindung abgebaut. Für
die Funktionalität dieser ODBC-Schnittstelle sollen Methoden der MFC-Klasse
„CDatabase“ genutzt werden.
4.4 Realisierung
Das Kapitel der Realisierung soll einen Überblick über Implementierung des
Entwurfs der Schnittstelle geben.
Die Skript- und die Dialog-Ebene wurden in SiSyBasic-Skript realisiert. Dazu
wurden die beschriebenen Dialoge und Aktivitätsdiagramme des Entwurfs der
63
Schnittstelle verwendet und realisiert. Für die Entwicklung der beiden Ebenen
wurden Editoren wie das Notepad und HTML-Editoren verwendet, da für die
Entwicklung von SiSyBasic-Skript keine Entwicklungsumgebung existiert, und
die Arbeit mit den Editoren ausreichend ist. Der vollständige Quellcode der
Dialog-Ebene und dessen SiSyBasic-Funktionen befinden sich in der Datei
„dat_exp.fld“, die auf dem Datenträger in Anlage 7 hinterlegt ist. Dort ist auch
die Datei „dat_exp.flq“ zu finden, in welcher der Quelltext der Skript-Ebene zu
finden ist.
Die entworfenen Klassen der SiSyBasic-Klassen-Ebene wurden mit Hilfe des
MS-Visual Studios 6.0 in der Sprache C++ entwickelt. Dabei wurde das
Klassendiagramm des Entwurfs umgesetzt.
Zur Realisierung wurde das Softwareprodukt SiSy® dokumentierend eingesetzt.
Hierbei wurde im Vorgehensmodell der UML in SiSy® das grobe
Fachklassenkonzept modelliert und daraus auch generiert. Die so erzeugten
Quellcode- und Headerdateien wurden anschließend in das MS Visual Studio
eingebunden. Die einzelnen Methoden der verschiedenen Klassen wurden
dann nur noch im Visual Studio um die eigentliche Fachlogik erweitert.
Der vollständige Quellcode der realisierten Klassen befindet sich auf dem
Datenträger der Anlage 7.
Zusätzlich wurde zum Add-On ein HTML-Seite, die „dat_exp.htm“, entwickelt.
Sie öffnet sich nach dem installieren des Add-Ons und gibt dem Nutzer
Informationen zum Aufruf und der Handhabung des Datenexportes. Diese
HTML-Seite ist ebenfalls auf dem Datenträger in der Anlage 7 zu finden.
64
5 Schlussbetrachtungen
Dieses Kapitel fasst die Ergebnisse zusammen und gibt einen Ausblick über die
mögliche Erweiterung des entwickelten Prototyps der Schnittstelle.
5.1 Ergebnisse
Anhand dieser Arbeit wurde gezeigt wie eine Schnittstelle zwischen dem
SiSy®-Repository und den externen Datenformaten CSV, XML und MySQL
umgesetzt wurde. Beim Betrachten des vorliegenden Prototyps dieser
Schnittstelle wird deutlich, dass die im Kapitel 3.4 gestellten Anforderungen an
das Modul zum größten Teil umgesetzt wurden. Somit wurde die
Vorraussetzungen für die Weiterentwicklung dieses Prototyps geschaffen.
Die entwickelte Schnittstelle wurde als installierbares Add-On realisiert und liegt
auf dem Datenträger in Anlage 7 zur Installation in SiSy® vor. Hierbei wurden
Namens- und Dateikonventionen von SiSy® beachtet und dem Add-On der
Name „Dat_Exp“ gegeben.
Bei dem vorliegenden Prototyp wird durch das SiSyBasic-Skript das Repository
nach dem zu exportierenden Objekttyp durchsucht bzw. gescannt. Diese
Funktionalität könnte man in die Klassen-Ebene mit aufnehmen. Da sich aber
dadurch keine wesentliche Verbesserung der Performance ergeben würde, hat
sich der Autor dazu entschieden das „Durchsuchen“ nach dem Objekttyp in die
Skript-Ebene zu verlagern.
Die realisierte Schnittstelle lässt sich ebenfalls leicht pflegen. So muss ein
neues Format nur in der Konfigurationsdatei „dat_exp.ini“ hinzugefügt und
Funktionen in der Klassen-Ebene zum Zusammenstellen der Daten in dem
Format entwickelt werden. Die Anpassung der Klassen-Ebene an neue Formate
kann nur der Entwickler des Produkts SiSy® durchführen, nicht der Benutzer
selbst.
Beim Entwurf der Schnittstelle wurde ein ergonomischer Dialog entwickelt, der
sich an der bestehenden Nutzerführung in SiSy® orientiert. Dazu wurde ein
65
SiSyBasic-Skipt geschaffen, welches den Dialog unterstützt und die
Schnittstelle zur SiSyBasic-Klassen-Ebene herstellt. Die Klassen-Ebene wurde
in der Sprache C++ realisiert und exportiert die Daten aus dem SiSy®Repository in ein gewähltes Datenformat. Dabei werden gültige und konforme
Dokumente in den Formaten CSV und XML erzeugt. Die Schnittstelle zu einer
MySQL-Datenbank wurde in Ansätzen über eine ODBC-Schnittstelle realisiert,
jedoch konnte diese zum Zeitpunkt der Abgabe nicht fertiggestellt werden.
Damit ist mit dem Prototyp dieser Schnittstelle auf dem Datenträger in der
Anlage 7 nur ein Export in die Formate CSV und XML möglich.
Der Wizard-Dialog wurde gewählt, da dieser bereits im Objekt der „Aufzählung“
umgesetzt wurde und sich somit an der bestehenden Nutzerführung in SiSy
orientiert. Beim Abarbeiten dieses Dialogs muss der Nutzer nacheinander alle
nötigen Exportdaten festlegen, da die Einstellungen beim Verlassen auf
Vollständigkeit geprüft werden. So konnten Fehler bei der Eingabe durch den
Nutzer minimiert werden.
Der Prototyp der Schnittstelle bringt eine Einschränkunge mit sich:
Er kann zunächst nur einen Objekttyp exportieren, da dadurch die Realisierung
des Prototypen vereinfacht werden sollte. Bei einer Weiterentwicklung muss an
dieser Stelle zuerst angesetzt werden, da ein Export von verknüpften Daten
bzw. Objekttypen für den Nutzer weitaus interessanter ist und für die
Entwicklungsabteilung der Laser & Co. Solutions GmbH erstrebenswert sein
sollte.
Der entwickelte Prototyp stammt aus der Phase der Realisierung und muss
einer Testphase unterzogen werden. Dazu müssen Testchecklisten entworfen
werden, dessen Entwicklung im Rahmen dieser Arbeit sich zu umfangreich
gestalten würde.
5.2 Ausblick
Wie in Kapitel 5.1 bereits erwähnt, sollte bei der Erweiterung der entwickelten
Schnittstelle zunächst der Export von Daten mehrerer verschiedener
Objekttypen und eventuell dessen Verknüpfung entwickelt werden. Dazu
könnten mehrere virtuelle Tabellen erzeugt und exportiert werden.
66
Dieser Datenexport könnte für die Überführung kompletter SiSy®-Projekte in
verschiedene Datenformate genutzt werden. Somit besteht die Möglichkeit ein
Archiv anzulegen und dadurch den Export kompletter Projektdaten in ein
Exportformat, wie z.B. XML, zu realisieren.
Weiterhin könnten mit Hilfe dieses Datenexports komplette Webapplikationen
erstellt werden, ähnlich wie es im Add-On „HTML-Export“ umgesetzt wurde.
Folglich würden Daten durch den Export in ein Datenformat, wie z.B. MySQL,
transferiert und durch eine aus SiSy® erzeugte Applikation genutzt. Auf diese
Weise kann man z.B. Intranet-Plattformen für Firmen realisieren, wobei diese
zunächst ihre Unternehmung z.B. aufbau- und ablauforganisatorisch abbilden
und anschließend beispielsweise einen Intranetbereich mit sämtlichen
Prozessen des Unternehmens und dessen Verantwortlichen erzeugen können.
Neben dem Export von Daten aus SiSy® in verschiedene Datenformate soll der
Entwurf dieser Schnittstelle auch Daten verschiedener Formate in SiSy®
importieren, wie in Kapitel 4.3 bereits erwähnt. Dazu muss die Funktionalität
eines Import von Daten implementiert werden. Dies sollte als weiterer Schritt
der Entwicklung dieser Schnittstelle aufgenommen werden.
Somit könnten beispielsweise Projektdaten, die mit Hilfe der Schnittstelle
exportiert wurden, wieder in SiSy® importiert werden. So könnte u.a. das
Einlesen von Archiven in SiSy® realisiert werden.
67
Literaturverzeichnis
[1]
ACHILLES, Dr. Albrecht: SQL: Standardisierte Datenbanksprache vom
PC bis zum Mainframe.- 5., durchges. Auflage.- München; Wien:
Oldenbourg, 1995
[2]
ARCHINIEGAS, Fabio: XML Developer’s Guide: Erstellen effizienter
XML-Anwendungen – Aktuelle Standards – Mobiles XML – Web
Publishing – Ergänzende Technologien. Poing: Franzis Verlag GmbH,
2001
[3]
BÖHM, Rolf; Wenger, Sven: Methoden und Techniken der SystemEntwicklung, 2. überarb. Und erweiterte Auflage – Zürich: vdf
Hochschulverlag AG, 1996
[4]
GEIGER, Kyle: Inside ODBC: Der Entwicklerleitfaden zum
Industriestandard für Datenbank-Schnittstellen – Unterschleißheim:
Microsoft Press Deutschland, 1995
[5]
GOLDFARB, Charles F.; Prescod, Paul: Das XML-Handbuch:
Anwendungen, Produkte, Technologien, 2. aktualisierte und erweiterte
Auflage. – München: Addison-Wesley, 2000
[6]
GROSSMANN, Ralph: Aufzeichnungen aus einer Vorlesungen über
Datenbanksysteme, 2001
[7]
GRÄFE, Gunter: Studienheft BSI 5 – Datenaustausch über
Schnittstellen. Darmstadt: Private Fern Fachhochschule Darmstadt
[8]
HEUER, Andreas: Datenbanken: Konzepte und Sprachen / Andreas
Heuer; Gunter Saake, 2. aktualisierte und erweiterte Auflage. – Bonn:
mitp-Verlag, 2000
[9]
MOOS, Alfred; Daues, Gerhard: Datenbank-Engineering: Analyse,
Entwurf und Implementierung relationaler Datenbanken mit SQL, 2.
überarbeitete Auflage. – Braunschweig; Wiesbaden: Vieweg, 1997
[10]
MÜLLER, Christian: persönliche Gespräche: Löbau, 2003
[11]
PARDI, William J.: XML in Action: Dynamische und datengestützte
Webseiten mit der neuesten Web-Technologie -Redmond, Washington:
Microsoft Press, 2000
[12]
PLATZK, René: Studienarbeit: Analyse und Entwurf einer Schnittstelle
zwischen dem SiSy-Repository und einer MySQL-Datenbank.- Bautzen:
2003
68
[13]
RAYMANS, Heinz-Gerd: MySQL im Einsatz – Mit ODBC, JDBC, PHP
und Perl. – München: Addison-Wesley, 2001
[14]
RIEDEL, Toralf: persönliche Gespräche: Löbau, 2003
[15]
RUF, Walter: Ein Software-Entwicklungs-System auf der Basis des
Schnittstellen-Management-Ansatzes – Für Klein- und Mittelbetriebe.
Berlin: Springer-Verlag, 1988
[16]
SCHUBERT, Daniel: Diplomarbeit – Realisierung eines SQL-Generators
mit ODBC-Schnittstelle für universaleditorbasierende Entity-RelationshipDiagramme im Softwaresystem SiSy.- Bautzen: 2001
[17]
STAHLKNECHT, Peter: Einführung in die Wirtschaftsinformatik / Peter
Stahlknecht; Ulrich Hasenkamp. 9., vollständig überarbeitete Auflage;
Berlin: Springer, 1999
[18]
TRAUTLOFT, Rainer: Datenbanken: Entwurf und Anwendung. – Berlin:
Verlag Technik, 1990
[19]
Firmeninterne Dokumente der Laser & Co. Solutions GmbH, Löbau:
2003
69
Onlinequellen
[On1] World Wide Web Consortium: XML (16.01.2003) [Online],
http://www.w3.org
[On2] MySQL: Produkte (16.01.2003) [Online], http://www.mysql.de
[On3] VIP7: CSV-Format (Infoblatt) (07.05.2003) [Online],
http://www.vip7.de/info/develop/csv-format.htm
[On4] PCtip: Helpdesk (07.05.2003) [Online]
http://www.pctip.ch/helpdesk/kummerkasten/archiv/office/23651.asp
[On5] Tformer:Aufbau einer CSV-Datei (07.05.2003) [Online],
http://www.tformer.com/HelpDE/Dokumentation/Externe_Daten/ExtDaten
_CSVImport.htm
[On6] Galileobusiness: Glossar – Datenbank (18.06.2003) [Online],
http://www.galileobusiness.de/glossar/gp/anzeige-50
[On7] Universität Magdeburg: UML – Unified Modelling Language (24.06.2003)
[Online], http://ivs.cs.uni-magdeburg.de/sweng/us/CAME/tools/UML/Komponentendiagramm.htm
[On8] LinuxDay: MySQL (02.07.2003) [Online],
http://www.linuxday.at/upload/MySQL_Kompaktseminar_200211.pdf
[On9] IT-Academy: ODBC-Programmierung (01.08.2003) [Online],
http://www.it-academy.cc/content/article_browse.php?ID=271
Softwareprodukte
[So1] Laser & Co. Solutions GmbH : Softwaresystem SiSy® – Simple Sytem
Version PFFH 2.16d. Löbau, 2003
70
Abbildungsverzeichnis
Abbildung 1 Grobentwurf der Schnittstelle ..........................................................7
Abbildung 2 Das Wasserfallmodell .....................................................................9
Abbildung 3 Prinzip einer Schnittstelle..............................................................11
Abbildung 4 Einordnung der Middleware ..........................................................12
Abbildung 5 Beispiel eines ERM .......................................................................16
Abbildung 6 Simple System ..............................................................................31
Abbildung 7 Grobstruktur des Repository von SiSy®........................................32
Abbildung 8 Beispiel Entity-Relationship-Diagramm .........................................34
Abbildung 9 Der SiSy-ODBC-Dialog .................................................................34
Abbildung 10 Dialog zum Programmieren ........................................................36
Abbildung 11 Dialogseite des "Aufzählen" -Objektes........................................37
Abbildung 12 Beispiel der Organisationssicht ...................................................38
Abbildung 13 Dialogseite "zusätzliche Informationen" der Stelle ......................39
Abbildung 14 Die Hierarchie der Handles .........................................................40
Abbildung 15 Ablauf eines Verbindungsaufbaus...............................................42
Abbildung 16 Die Schichtenarchitektur der Schnittstelle...................................48
Abbildung 17 Der Entwurf der Schnittstelle.......................................................49
Abbildung 18 Die Dialogseite Datenexport .......................................................50
Abbildung 19 Der Ablauf des SiSyBasic-Skripts ...............................................51
Abbildung 20 Der Ablauf der Skript-Ebene beim Starten des Exports ..............52
Abbildung 21 Anwendungsfalldiagramm der Schnittstelle ................................54
Abbildung 22 Der Ablauf des Dialoges .............................................................56
Abbildung 23 Die Dialogseite-"Ausgabeform" ...................................................57
Abbildung 24 Entwurf des Klassendiagramms..................................................60
Abbildung 25 Der Ablauf des Exports in der Klassen-Ebene ............................61
71
Tabellenverzeichnis
Tabelle 1 Vordefinierte Entities .........................................................................24
Tabelle 2 CSV-Seperatoren ..............................................................................27
Tabelle 3 Beispiele für Textbegrenzungszeichen..............................................28
Tabelle 4 Qualitätsanforderungen.....................................................................47
72
Anlagenverzeichnis
Anlage 1:
Das Komponentendiagramm
Anlage 2:
Die Dokumententyp-Definition
Anlage 3:
Dateikonventionen in SiSy
Anlage 4:
Die Dialoge der Schnittstelle
Anlage 5:
Das erzeugte CSV-Dokument
Anlage 6:
Das erzeugte XML-Dokument
Anlage 7:
Die Arbeitsergebnisse auf Datenträger
73
Eidesstattliche Erklärung
Ich erkläre an Eides Statt, dass ich die vorliegende Arbeit selbstständig und nur
unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe.
Die Zustimmung der Firma zur Verwendung betrieblicher Unterlagen habe ich
eingeholt. Die Arbeit wurde bisher in gleicher oder ähnlicher Form weder
veröffentlicht noch einer anderen Prüfungsbehörde vorgelegt.
Bautzen, den 08.08.2003
Unterschrift des Verfassers
74
Anlage 1
Das Komponentendiagramm
Das Komponentendiagramm, engl. component diagramm, ist ein Diagramm der
UML. Es stellt die Zusammenhänge einzelner Komponenten von
Softwaresystemen her, unabhängig von Compiler- und Laufzeitumgebung.
Die Komponente ist ein physisches Stück Programmcode, welches ein Stück
Quellcode, Binärcode oder ein Teil eines Softwaresystems sein kann. Sie
werden als Rechteck dargestellt und enthalten Namen und den Typ der
Komponente. Am linken Rand des Rechtecks befinden sich eine Ellipse und
zwei kleinere Rechecke. Eine Komponente kann wiederum Objekte und
Komponenten enthalten und Schnittstellen besitzen.
Schnittstellen werden als Kreise dargestellt und enthalten eine eindeutige
Bezeichnung30).
Die Komponenten können zusätzlich auf (Hardware-)Knoten abgebildet werden.
Knoten werden als dreidimensionale Rechtecke(Würfel) dargestellt, und sind
die Hardware auf denen sich die Komponenten befinden. Die folgende
Abbildung zeigt ein Beispiel eines Komponentendiagramms.
KomponenteA:KompTypA
KomponenteB
Schnittstelle
:KompTypA
Schnittstelle
Schnittstelle
Abbildung 26 Beispiel eines Komponentendiagramms
30)
[On9]
:KompTypB
75
Anlage 2
Blatt 1
Die Dokumententyp-Definition
Die DTD ist eine Art Regelwerk. Sie definiert Elementtypen, Attribute, Entities
und Notationen. Dabei deklariert sie, welche von diesem Komponenten
innerhalb eines Dokumentes und an welchen Stellen diese zur Verfügung
stehen bzw. vorkommen dürfen.
Eine DTD ist für eine organisatorische Standardisierung für ein Dokument von
großer Bedeutung, da sie eine zuverlässige Verarbeitung eines Dokumentes
gewährleistet. Sie kann direkt in dem XML-Dokument oder in einer externen
Datei, einer *.dtd-Datei, definiert werden.
Wie werden nun die einzelnen Komponenten eines Dokumentes in einer DTD
deklariert? Wie bereits oben genannt können in einer DTD Elementtypen,
Attribute, Entities und Notation deklariert werden.
Alle Komponenten werden in Tags mit spitzen Klammern dargestellt. Der
öffnenden Klammer folgt ein Ausrufezeichen.
Die Deklaration eines Elementtyps enthält das Wort ELEMENT, welches das
Tag als Elementtyp-Deklaration kennzeichnet, den Elementnamen und die Art
der Daten, die das Element enthält. Der Name des Elements muss ein gültiger
XML-Name sein, das bedeutet dass der Name mit einem Buchstaben, einem
Semikolon oder einem Unterstrich, gefolgt von einer beliebigen
Namenszeichen, beginnen muss. Die Art der Daten kann aus einen der
folgenden Typen bestehen:
•
Dem Schlüsselwort EMPTY – Durch dieses Schlüsselwort wird das
Element als leer deklariert, es sind keine Inhalte für dieses Element
erlaubt. Das folgende Beispiel zeigt eine Deklaration eines leeren
Elementes:
<!ELEMENT Test EMPTY>
•
Dem Schlüsselwort ANY – Durch dieses Schlüsselwort kann das
Element jedes beliebige Element oder Zeichendaten in jeder beliebigen
Reihenfolge enthalten. Ein folgendes Beispiel zeigt ein solches Element:
<!ELEMENT TITLE ANY>
76
Anlage 2
Blatt 2
•
Dem Schlüsselwort (#PCDATA) – PCDATA ist das Kürzel für Parsed
Character DATA. Für die Elemente mit diesem Schlüsselwort sind nur
Zeichendaten zulässig. Das folgende Beispiel zeigt eine Deklaration
eines Element mit Zeichendaten als zulässigem Inhalt:
<!ELEMENT COMPOSER (#PCDATA)>
•
Einer Liste von untergeordneten Elementen – Die Deklaration eines
Elementes mit untergeordneten Elementen, darf nur dem Element
untergeordnete, deklarierte Elemente besitzen. Dabei kann eine
bestimmte Spezifikation durch Struktursymbole vorgenommen werden,
diese sind in der xxx erläutert. Das Beispiel zeigt eine ElementtypDefinition mit einer Liste von untergeordneten Elementen:
<!ELEMENT SONG (TITLE?,COMPOSER+,ARTIST+)>
•
Aus gemischten Inhalt – In dieser Deklaration dürfen jede Art von
Daten verwendet werden: Zeichendaten oder untergeordnete Elemente.
Hier werden zur Spezifikation der Daten ebenfalls Struktursymbole und
Modifizierer verwendet.
Das folgende Beispiel ist eine Deklaration mit gemischten Daten. Das
Element SONG muss als Daten Zeichendaten und die Elemente TITLE,
COMPOSER, ARTIST in verschiedenen Ausprägungen genau in dieser
Reihenfolge besitzen:
<!ELEMENT SONG (#PCDATA,TITLE?,COMPOSER+,ARTIST+)>
Es wurde bereits erwähnt das XML eine Spezifikation der Struktur der Daten,
durch einen Satz von Symbolen, verwendet. Sie haben in einigen Beispielen,
solche Symbole gesehen. Die Struktursymbole, die in XML verwendet werden
sehen sie in Tabelle 5 Die Struktursymbole:
77
Anlage 2
Blatt 3
Tabelle 5 Die Struktursymbole
Die Deklaration von Attributen enthält das Schlüsselwort ATTLIST, den
Elementnamen zu dem das Attribut gehört, den Attributsnamen, den
Attributstyp und eine Vorgabe für das Attribut. Eine allgemeine
Attributsdeklaration sehen Sie im folgenden Beispiel:
<!ATTLIST Elementname Attributsname Attributstyp Vorgabe>
Die Attributstypen die in einer DTD verwendet werden können sehen Sie in der
folgenden Tabelle:
Tabelle 6 Die Attributstypen der DTD
Attributtyp
CDATA
ENTITY
ENTITIES
ID
IDREF
IDREFS
NMTOKEN
NMTOKENS
NOTATION
Aufzählung
Bedeutung
In dem Attribut können nur Zeichenkettendaten
verwendet werden.
Die Attributswerte müssen sich auf ein externes, binäres
Entity beziehen, das in der DTD deklariert wurde.
Beispiel
<!ATTLIST SONG Quality CDATA #IMPLIED>
Wie Entity, jedoch sind mehrere, durch Leerzeichen
getrennte Werte möglich.
Der Attributwert muss ein eineindeutiger Identifier sein.
Der Wert muss ein Verweis/ Referenz auf eine anderswo
deklarierte ID sein.
Wie IDREF, hier sind jedoch mehrere, durch Leerzeichen
getrennte, Werte erlaubt.
Der Attributswert ist jede belibiege Zusammenstellung
aus Namenstokenzeichen, die Buchstaben, Ziffern,
Punkte, Bindestriche, Semikolons oder Unterstriche sein
müssen.
Wie NMTOKEN, jedoch sind mehrere, durch Leerzeichen
getrennte, Werte erlaubt.
Der Attributswert muss auf eine Notation verweisen, die
an einer anderen Stelle in der DTD deklariert ist.
Der Attributwert mus mit einer der aufgeführten Werte
übereinstimmen.
<!ATTLIST SONG Quality ENTITIES #IMPLIED>
<!ATTLIST SONG Quality ENTITY #IMPLIED>
<!ATTLIST SONG Quality ID #IMPLIED>
<!ATTLIST SONG Quality IDREF #IMPLIED>
<!ATTLIST SONG Quality IDREFS #IMPLIED>
<!ATTLIST SONG Quality NMTOKEN #IMPLIED>
<!ATTLIST SONG Quality NMTOKENS #IMPLIED>
<!ATTLIST SONG Quality NOTATION #IMPLIED>
<!ATTLIST SONG Quality (good | bad) #IMPLIED>
78
Anlage 2
Blatt 4
Die Vorgaben für Attribute, auch Attributsvorgaben genannt, ist die letzte
Eigenschaft der Attributdeklaration. Die Formen dieser Deklaration sind
folgende Schlüsselwörter:
•
#REQUIRED – Das Attribut ist vorgeschrieben, es wird benötigt. Jede
Instanz des einschließenden Elements muss dieses Attribut besitzen. Im
Folgenden sehen Sie ein solches Bespiel:
<!ATTLIST SONG SongID ID #REQUIRED>
•
#IMPLIED – Das Attribut ist für das benannte Element nicht nötig. Es
kann weggelassen werden. Das folgendes Beispiel zeigt ein Attribut das
nicht unbedingt benötigt wird:
<!ATTLIST SONG Quality #IMPLIED>
•
#FIXED Wert – Wenn dieses Schlüsselwort angegeben wird, muss das
Attribut den Wert besitzen, der auf das Schlüsselwort folgt. Das folgende
Beispiel zeigt ein Attribut mit einem festen Wert:
<!ATTLIST SONG ImArchiv #FIXED “yes“>
•
Vorgabe – Mit Hilfe einer Vorgabe, kann man einen Standardwert für ein
Attribut definieren. Wenn das Element nicht dieses Attribut besitzt, wird
der XML-Prozessor diesen Standardwert des Attributs nehmen. Im
folgenden sehen Sie ein solches Beispiel:
<!ATTLIST SONG (Pop|Rock|Hip Hop|Techno) “Pop“>
Die Attributsdeklaration mit einer Vorgabe von Werten für ein Attribut ist ein
Aufzählungstyp. Aufzählungstypen legen die möglichen Werte, die ein Attribut
annehmen kann, explizit fest. Eine weitere Form von Aufzählungstypen ist der
Deklarationstyp NOTATION. Dabei beschreiben Notationen die Dateninhalte für
andere Deklarationen, die dann beispielsweise in einer Attributsdeklaration als
Aufzählungstyp verwendet werden können.
79
Anlage 2
Blatt 5
Notationen werden in XML zur Definition von XML-fremden Formaten benutzt.
Dabei wird der XML-Prozessor über ein bestimmten Datentyp aufgeklärt und
gesagt wie damit mit einer Hilfsapplikation umzugehen ist. Beispielsweise wird
der XML-fremde Datentyp einer GIF-Notation definiert und die Verarbeitung
durch die Anwendung „MS InternetExplorer“ deklariert, wie in dem folgenden
Beispiel erkennen kann:
<!NOTATION GIF SYSTEM “Iexplore.exe“>
Die Deklaration einer Notation wird durch das Schlüsselwort NOTATION
eingeleitet. Darauf folgen der Notationsname, der Bezeichner und in
Hochkommatas die Hilfsapplikation. Der Bezeichner bezieht sich auf eine
externe Information. Es gibt zwei Typen von Bezeichner: Systembezeichner
und öffentliche Bezeichner. Der Systembezeichner benutzt das Schlüsselwort
SYSTEM, wie im oben gezeigt Beispiel. Er verwendet eine URL, um auf die
Position eines Objektes zu verweisen.
Der öffentliche Bezeichner kann, neben der URL, zusätzlich auch über einen
Namen auf eine DTD-Komponente oder ein externes Entity verweisen, die als
eine Art Standardbibliothek zu sehen ist. Hierbei wird das Schlüsselwort
PUBLIC verwendet, gefolgt von einer DTD-Komponente bzw. einem externen
Entity und anschließend der URL. Ein folgendes Beispiel zeigt ein Deklaration
mit einem öffentlichen Bezeichner:
<!NOTATION SONG PUBLIC “-//SOURCE//EN“
“http://www.xmlsources.com/dtd/song.dtd“>
Die Angabe der URL bezieht sich immer auf relative Pfade des Speicherorts der
Ressource. Notationen können in Attributs- und Entitydeklarationen verwendet
werden.
Entities werden in der DTD definiert und im XML-Dokument referenziert, wie
bereits erläutert wurde. Sie können verschiedene Arten von Daten bzw. Inhalten
aufnehmen. Dabei werden sie in verschiedene Arten unterschieden. Nach Art
und Weise der Verarbeitung durch den XML-Prozessor werden Entities in
geparste und ungeparste unterteilt.
80
Anlage 2
Blatt 6
Weiterhin kann man Entities nach ihrer Funktion unterscheiden, in
Parameterentities und allgemeine Entities. Darüber hinaus können die
allgemeinen Entities, die innerhalb eines Dokumentes benutzt werden, in
interne und externe Entitäten unterteilt werden. Die Abbildung 272) zeigt die
Klassifizierung der Entitätstypen.
Entitäten
Ungeparst
Geparst
Parameter
Intern
Allgemein
Extern
Abbildung 27 Die Entitätstypen
Die Deklaration eines Entities wird immer durch das Wort ENTITY eingeleitet,
gefolgt vom Namen des Entities. Danach folgen Schlüsselwörter, Inhalte und
Referenzzierungen auf Notationen, die bei den verschiedenen Entity-Typen
verwendet werden.
Ungeparste Entities werden oft auch als binäres Entity bezeichnet, da deren
Inhalt in einer Binärdatei vorliegt, die vom XML-Prozessor nicht direkt geprüft
und interpretiert wird. Ein ungeparstes Entity benötigt eine Notation, da diese
Entities andere Informationen als geparste Entities benötigen. Das folgende
Beispiel zeigt ein ungeparstes Entity mit der zugehörigen Notation:
<!ENTITY Booklet SYSTEM “Image001.gif“ NDATA GIF>
<!NOTATION GIF SYSTEM “Iexplore.exe”>
2)
ARCHINIEGAS, Fabio: XML Developer’s Guide: Erstellen effizienter XML-Anwendungen –
Aktuelle Standards – Mobiles XML – Web Publishing – Ergänzende Technologien. Poing:
Franzis Verlag GmbH, 2001
81
Anlage 2
Blatt 7
Geparste Entities können durch den XML-Prozessor interpretiert werden. Dabei
wird der Inhalt des Entities aus der DTD herausgezogen und erscheint als Teil
des Dokumentes am Ort der Entityreferenzierung. Die internen geparsten
allgemeinen Entities sind die einfachsten Entity-Typen. Dieser Entity-Typ wird
auch Textentity genannt, da dieser Typ Textdaten enthält. Sie werden Teil des
Dokumentes sobald Sie verarbeitet sind. Das Textentity wird durch den Namen,
gefolgt vom Inhalt, der in Hochkommata steht, spezifiziert. Textentity mit dem
Namen “KAT“ und dem Inhalt “Kategorie: Pop“ könnte z.B. wie folgt dargestellt
werden:
<!ENTITY KAT “Kategorie: Pop“>
Die externen geparsten allgemeinen Entities enthalten ebenfalls Textdaten, die
aber in einer externen Datei, im System, vorliegen, z.B. in einer Textdatei oder
einer HTML-Datei. Ein externes allgemeines Entity kann auf folgende Weise
deklariert werden:
<!ENTITY entityname SYSTEM “SystemID“>
<!ENTITY entityname PUBLIC “PublicID“ “SystemID“>
Der “SystemID” verweist auf die URL oder den Namen der externen Datei. Der
“PublicID“, wie bereits erläutert, verweist auf eine Standardbibliothek, die
verwendet werden kann. Ein Beispiel mit einem “SystemID“ stellt sich wie folgt
dar:
<!ENTITY SONG SYSTEM “song.txt“>
Ein weiteres allgemeines Entity ist das Parameterentity. Sie sind für gute
Lesbarkeit und der Wiederverwendung in einer DTD verantwortlich.
Parameterentities benennen Textabschnitte die in der DTD verwendet werden,
nicht aber im Dokument. Damit machen sie das Benennen von XML-Typen und
die
82
Anlage 2
Blatt 8
Wiederverwendung von Teilen von Inhaltsmodellen bzw. Deklarationen
möglich, laut Quelle 3). Die Deklaration von Parameterentity hat folgenden
Syntax:
<!ENTITY % Entityname “Ersetzungstext“>
Bei der Deklaration ist zu beachten das vor dem Entitynamen ein
Prozentzeichen („%“) voransteht. Parameterentities können nur innerhalb einer
DTD verwendet bzw. referenziert werden. Die Referenzzierung eines
Parameterentities wird durch ein Prozentzeichen eingeleitet und ein Semikolon
abgeschlossen, dazwischen steht der Entityname der referenziert wird. Ein
Beispiel einer Deklaration eines Parameterentities und deren Referenzzierung
stellt sich wie folgt dar:
<!ENTITY % auswahlkategorie “(Pop|Rock|Hip Hop|Techno)“>
<!ATTLIST Kategorie %auswahlkategorie; “Pop“>
3)
ARCHINIEGAS, Fabio: XML Developer’s Guide: Erstellen effizienter XML-Anwendungen –
Aktuelle Standards – Mobiles XML – Web Publishing – Ergänzende Technologien. Poing:
Franzis Verlag GmbH, 2001
83
Anlage 3
Dateikonventionen in SiSy
Dateierweiterung Beschreibung
Beispiele aus
Add-On PM
VG*
Sicht-Steuerungsdateien für
Vorgehensmodelle (VGM =
Eintrittsebene)
*.vgm, *.vgd,,
*.vgi, *.vgt, *.vgx
FL*
Sicht-Steuerungsdateien für
Diagramme (außer VGM)
*.flc, *.fld, *.flt
VGM, FLC
Logik und Objektlayout der Sicht
pm_vgm.vgm;
pm_mindm.flc;
pm_npt.flc
VGD, FLD
Defnieren-Dialoge für die Objekte der
Sicht
pm_vgm.vgd;
pm_mindm.fld;
pm_npt.fld
VGT, FLT
Tipps zu den Objekten der Sicht
pm_vgm.vgt;
pm_mindm.flt;
pm_npt.flt
VGX, FLX
temporäre Übersetzung der VGM/FLC Addon.vgx
VGI, FLI
Standard-Inhalt der Objekte der Sicht
pm_vgm.vgi
VGQ, FLQ
SiSy-Basic-Quelltexte
pm_npt.flq
EMF
Sichtvorschau für das VGM bei
Anlegen eines neuen Projektes
pm_vgm.emf
TXT
First Aid = Erste Hilfe zur Sicht
(wird angezeigt, wenn die Sicht noch
leer ist)
pm_vgm.txt;
pm_mindm.txt;
pm_npt.txt
ASI
Assistentendateien
pm_vgm.asi;
pm_mindm.asi;
pm_npt. asi
CHM, HTML, GIF
Hilfedateien mit Quellen
pm_vgm.chm;
pm_npt.vgm;
org_hpt.htm;
org_hpt1.gif
EXP
Add-On Datei, die zur Installation des
Add-On’s benötigt wird
pm.exp
FLK
Vorlagendatei für das Objekt
„Aufzählung”
(Dokumentengenerierung)
pm_npt1.flk
SEX
Vorlagendatei für Sichten, bei der
Objekte geladen werden
pm_vgm.sex;
pm_mindm.sex;
pm_npt1.sex
84
Anlage 4
Blatt 1
Die Dialoge der Schnittstelle
Abbildung 28 Die Dialogseite "Tipp"
Abbildung 29 Die Dialogseite
"Ausgabeform"
Abbildung 30 Die Dialogseite
"ODBCVerbindung"
Abbildung 6 Die Dialogseite "StartObjekt"
85
Anlage 4
Blatt 2
Abbildung 7 Die Dialogseite "Start"
Abbildung 8 Die Dialogseite „Vorlage“
Abbildung 9 Die Dialogseite "Manuell"
Abbildung 10 Die Dialogseite "Abtauchen"
86
Anlage 4
Blatt 3
Abbildung 11 Die Dialogseite "Exportieren"
Abbildung 12 Die Dialogseite "Spalten"
Abbildung 13 Die Dialogseite
Abbildung 14 Die Dialogseite "Übersicht"
"Einstellungen für Vorlage"
87
Anlage 5
Das erzeugte CSV-Dokument
Stellnr;Stellenname;Telnr1;Telnr2;Faxnr
int;string;string;string;string
TRUE;FALSE;FALSE;FALSE;FALSE
1;QM-Beauftragter;0190123456;0190654321;01901234567
2;Projektleiter;0190147258;0190258147;01901234567
3;Sekretärin;0190666666;0190111111;01901234567
88
Anlage 6
Das erzeugte XML-Dokument
<?xml version="1.0"?>
<!DOCTYPE test [
<!ELEMENT Stelle ( Stellennr, Stellennmae, Telnr1, Telnr2,
Faxnr )>
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
]>
Stellennr (ID) >
Stellennmae (#PCDATA) >
Telnr1 (#PCDATA) >
Telnr2 (#PCDATA) >
Faxnr (#PCDATA) >
<test>
<Stelle>
<Stellennr>1</Stellennr>
<Stellennmae>QM-Beauftragter</Stellennmae>
<Telnr1>0190123456</Telnr1>
<Telnr2>0190654321</Telnr2>
<Faxnr>01901234567</Faxnr>
</Stelle>
<Stelle>
<Stellennr>2</Stellennr>
<Stellennmae>Projektleiter</Stellennmae>
<Telnr1>0190147258</Telnr1>
<Telnr2>0190258147</Telnr2>
<Faxnr>01901234567</Faxnr>
</Stelle>
<Stelle>
<Stellennr>3</Stellennr>
<Stellennmae>Sekretaerin</Stellennmae>
<Telnr1>0190666666</Telnr1>
<Telnr2>0190111111</Telnr2>
<Faxnr>01901234567</Faxnr>
</Stelle>
</test>
89
Anlage 7
Die Arbeitsergebnisse auf Datenträger
Der vorliegende Datenträger enthält den kompletten Quelltext der in der Arbeit
beschriebenen Schnittstelle in Form C++ - Quellcode- und Headerdateien.
Weiterhin liegt das installationsfähige Add-On „Dat_Exp“ auf dem Datenträger
vor. Dieses Add-On kann über den Menüpunkt „Einstellungen/Add-On
hinzufügen...“ installiert werden.
Zum Datenexport durch das Add-on „Dat_Exp“ muss die im SiSy-Ordner
befindliche „Assi.exe“ mit der bereitgestellte „Assi.exe“ auf dem Datenträger
ersetzt werden.
Die vollständige Installationsanweisung ist auf dem Datenträger in der Datei
„readme.txt“ zu finden.
Link zur CD