Staatliche Studienakademie Bautzen Promenadenring 8

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 ODBC- Schnittstelle 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 CASE CSV DB DBMS DCL DDE DDL DIN DML DTD DV EDV ERD GPL GUI ISO HTML MS ODBC SiSy SQL UML URL URR XML American National Standards Institute Computer Aided Software Engineering Comma Separated Values Database Datenbankmanagementsystem Data Controll Language Dynamic Data Exchange Data Definition Language Deutsche Industrie Norm Data Manipulation Language Dokumententyp-Definition Datenverarbeitung Elektronische Datenverarbeitung Entity-Relationship-Diagram General Public Licence Graphical User Interface International Standard Organisation Hypertext Markup Language Microsoft Open Database Connectivity Simple System Structured Query Language Unified Modelling Language Uniform Resource Locator User Requirements Review 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 IT- Branche 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 Software- Programm 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 SiSy externe Datenformat S chnittstelle Abbildung 1 Grobentwurf der Schnittstelle

8 Diese Arbeit soll die Entwicklung der Schnittstellen zwischen dem Software- System 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 Boehm 1) aus. Es ist ein klassisches Vorgehensmodell des Software- Engineerings. 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 kontrollieren 3). 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 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-Server- Modell 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 DBMS- Unabhä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 Studienarbeit 4), 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 Beziehungen 5). 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 Sichten 6) 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 übernommen 7). 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 Modell 8). 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-Relationship- Modell 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. Modellierungshilfe 9). 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 1 n Abteilung gehört zu 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 wurden 10)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ätstyp 12). 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 einteilen 14) : 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 MySQL- DB 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/92- Standard 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 liefert 15). 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 wird 16). Die aktuellste Version von MySQL ist MySQL 4.1 alpha. Die Version MySQL 5.0 ist mit einigen Erweiterungen geplant 17). 2.3.2 Einschränkungen von SQL unter MySQL Wie bereits erwähnt, benutzt MySQL in der Version 4.0 den ANSI-SQL/92- Standard, 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 XML 18) 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 hergestellt 20). 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 < 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 XML- Prozessor 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 GUI 21) 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 Text- Format 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 werden 23)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 Name Tab Komma (,) Semikolon (;) Leerzeichen Beschreibung Tabulatorsprung nach jedem Dateninhalt Komma zwischen den Daten Semikolon zwischen den Daten Leerzeichen zwischen den Daten 23) Vgl. [On3] 24) Vgl. [On4]

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 Microsoft- Excel-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 CSV- Datei in andere Systeme, wie z.b. in eine MySQL-Datenbank oder in XML- Dokumente, 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 Datenbank- Managementsystem. 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 System 25) 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. CASE- Tools, 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/NF- Strukturen 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 Objektdaten S trukturierte Objektdaten VG/NF-Strukturen Abbildung 7 Grobstruktur des Repository von SiSy

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 Abteilung Computer n wird 1 zugeordnet Abteilung Abbildung 8 Beispiel Entity-Relationship-Diagramm Bevor durch den Nutzer die Datenbank generiert wird und der SiSy-ODBC- Dialog geöffnet wird, wird eine Prüfung des erstellten Entity-Relationship- Diagrammes vorgenommen. Bei einem Fehler oder semantisch unkorrekter Modellierung erscheint eine Meldung. Danach wird automatisch der SiSy- ODBC-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 ANSI- SQL/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