Entwicklung einer Web-Applikation für IT-Dokumentationen im DocBook-Format Development of a Web application for ITDocumentations in the DocBook format

Transkript

1 Entwicklung einer Web-Applikation für IT-Dokumentationen im DocBook-Format Development of a Web application for ITDocumentations in the DocBook format Diplomarbeit zur Erlangung des Grades Diplom-Informatikerin an der Fakultät für Mathematik, Naturwissenschaften und Informatik der Brandenburgischen Technischen Universität Cottbus Diploma Thesis to graduate at the Faculty of Mathematics, Natural Sciences and Computing at Brandenburg University of Technology Cottbus Kerstin Buchholz Matrikel: Prof. Dr. Gerd Wagner Lehrstuhl Internet-Technologie Prof. Dr. Claus Lewerentz Lehrstuhl Software-Systemtechnik

2 Entwicklung einer Web-Applikation für IT-Dokumentationen im DocBook-Format: Diplomarbeit zur Erlangung des Grades DiplomInformatikerin an der Fakultät für Mathematik, Naturwissenschaften und Informatik der Brandenburgischen Technischen Universität Cottbus: Diploma Thesis to graduate at the Faculty of Mathematics, Natural Sciences and Computing at Brandenburg University of Technology Cottbus Development of a Web application for IT-Documentations in the DocBook format: Diplomarbeit zur Erlangung des Grades DiplomInformatikerin an der Fakultät für Mathematik, Naturwissenschaften und Informatik der Brandenburgischen Technischen Universität Cottbus: Diploma Thesis to graduate at the Faculty of Mathematics, Natural Sciences and Computing at Brandenburg University of Technology Cottbus Kerstin Buchholz Matrikel: Prof. Dr. Gerd Wagner Lehrstuhl Internet-Technologie Prof. Dr. Claus Lewerentz Lehrstuhl Software-Systemtechnik Zusammenfassung Die araneanet GmbH als Initiator und Betreuer der vorliegenden Arbeit betreut als mittelständisches Unternehmen öffentliche Auftraggeber und größere Unternehmen der freien Wirtschaft. Ein größerer Auftraggeber, der durch araneanet in einem umfangreichen Projekt dauerhaft betreut wird, hat um Unterstützung bei der Optimierung des Dokumentationsverfahrens für die vorhandenen IT-Systeme gebeten. Diese Art von Dokumentationen sind für die sichere Betriebsführung notwendig, gerade im Hinblick auf Wiederherstellungsmaßnahmen im Not- und/oder Fehlerfall. Aufgrund gesetzlicher Bestimmungen und in Bezug auf Revisionssicherheit, unterliegen die Unternehmen einer umfangreichen Dokumentationspflicht. Durch den Einsatz von DocBook, ein auf offenen und allgemein akzeptierten Standards basierendes Format für Dokumentationen, welches zudem plattformunabhängig einsetzbar ist und verschiedene Ausgabeoptionen realisiert, soll das Dokumentationsverfahren optimiert und vereinfacht werden. Weiterhin soll den autorisierten Mitarbeitern bzw. Nutzern eine Web-Applikation bereit gestellt werden, welche die Möglichkeit der zentralen Dateneingabe und -änderung, sowie bei Bedarf des gewünschten Ausgabeformat der Dokumentation per Mausklick erlaubt. Abstract The araneanet GmbH as initiator and carer of the present work cares for public clients and larger enterprises of the free economy as medium-sized company. A larger client, who is durably cared for through araneanet in an extensive project, asked for support during the optimization of the documentation procedure for the existing ITsystems. This kind of documentations straight are necessary regarding re-establishment measures in the emergency and/or case of an error for the safe management. Due to legal regulations and regarding revision security, the enterprises are subject to an extensive documentation obligation. By the use of DocBook, a format for documentations, based on open and generally accepted standards, which besides is platform-independently applicable and different output options realized, the documentation procedure should be optimized and simplified. Further a Web application should be delevoped for the authorized staff and/or users, which the possibility of the central data input and change, as well as the desired output format of the documentation by mouse-click permitted.

3

4

5 Inhaltsverzeichnis I. Hauptteil Einleitung Motivation Lösungsansatz Zusammenfassung Ausgangssituation und Vorgehensweise Dokumentenanalyse Model Driven Architecture (MDA) Nutzen der MDA Basistechnologien der MDA Entwurf nach der MDA am Beispiel Domänenmodell am Beispiel Informationsmodell Interaktionsmodell Konzeptuelles Verhaltensmodell Designmodell am Beispiel Implementationsmodell am Beispiel Anforderungsdefinition XML-Technologien XML - extensible Markup Language XML Schema XPath - XML Path Language XSL - extensible Markup Language XSLT - XSL Transformations XSL-FO - XSL Formating Objects Umsetzung des Projekts Anwendung von XML XML zur Aufnahme der Daten DocBook-XML Was ist DocBook? Warum DocBook? Ein DocBook-Dokument erstellen Verweise in DocBook-Dokumenten Das verwendete XML Schema Anwendung von XSL XSLT-Stylesheet für die Seiten der Webapplikation XSLT-Stylesheet zur Erstellung des DocBook-XML-Dokuments Das DocBook-XSL-Stylesheet Funktionen und Aufbau der Web-Applikation Zusammenspiel der eingesetzten Techniken Benutzerführung und Benutzeroberfläche der Web-Applikation Konzept der Benutzerführung Konzept der Benutzeroberflächen Versionierung Zusammenfassende und kritische Betrachtung der Umsetzung Dokumenten-Management v

6 9.1. Dokumenten-Management-Systeme Was ist ein Dokument? Einsatz von Dokumenten-Management-Systemen Verallgemeinerung des Problems Institutsberichte Ausgangssituation und Dokumentenanalyse Entwurf Informationsmodell im Domänenmodell Interaktionsmodell im Domänenmodell Verhaltensmodell im Domänenmodell Designmodell Umsetzung Fazit Zusammenfassung und Ausblick Vergleich der Ergebnisse mit der Aufgabenstellung Persönliche Betrachtungen Ausblick II. Anhänge A. Aufgabenstellung A.1. Einleitung/Motivation A.2. Zielbestimmungen A.3. Produktübersicht A.3.1. Weboberfläche A.3.2. Erstellen der Handbücher A.3.3. Editieren der Handbücher A.3.4. Darstellen der Handbücher A.3.5. Exportieren der Handbücher B. Pflichtenheft B.1. Zielbestimmungen B.1.1. Musskriterien B.1.2. Wunschkriterien B.1.3. Abgrenzungskriterien B.2. Produkteinsatz B.2.1. Anwendungsbereich B.2.2. Zielgruppen B.2.3. Betriebsbedingungen B.3. Produktübersicht B.4. Produktfunktionen B.5. Produktdaten B.6. Produktleistungen B.7. Qualitätsanforderungen B.8. Benutzeroberfläche B.9. Nichtfunktionale Anforderungen B.10. Technische Produktumgebung B Software B Hardware B Orgware B.11. Spezielle Anforderungen an die Entwicklungsumgebung B Software B Hardware B Orgware B.12. Ergänzungen vi

7 C. XML-Technologien C.1. XML - extensible Markup Language C.1.1. Hintergrund C.1.2. Was ist XML? C.1.3. Aufbau von XML C Wohlgeformtheit von XML-Dokumenten C Gültigkeit von XML-Dokumenten C Elementdeklaration C Attributdeklaration C.2. XML Schema C.2.1. Was ist XML Schema? C.2.2. Aufbau von XML Schema C Elemente und Attribute C Auswahl und Sequenzgruppen C Komplexe und einfache Typen C Komplexe Typen C Einfache Typen C Schlüsselbedingungen C.3. XPath - XML Path Language C.3.1. Aufbau von XPath C Datenmodell C Ausdruck C Lokalisierungspfade C Funktionen C.4. XSL - extensible Stylesheet Language C.4.1. XSLT - XSL Transformations C Transformation C XSLT-Elemente C Elemente oberster Ebene C Kombination von Stylesheets C Template-Regeln C Eingebaute Template-Regeln C Variablen und Parameter C Berechnungen mit xsl:value-of C Verzweiungselemente C Sortierung mit xsl:sort C Kopieren mit xsl:copy und xsl:copy-of C Meldungen mit xsl:message C Neue Elemente und Attribute C XSLT-Funktionen C XSLT-Prozessoren C xsltproc C Saxon C Xalan C.4.2. XSL-FO - XSL Formating Objects C Aufbau von XSL-FO C FO-Prozessoren C FOP C xfc D. XML Schema E. Abkürzungen F. Eidesstattliche Erklärung vii

8 Literatur viii

9 Abbildungsverzeichnis 4.1. Modellierungskonzept der MDA nach [03] Informationsmodell im Domänenmodell Interaktionsmodell im Domänenmodell Verhaltensmodell im Domänenmodell erster Teil des Klassendiagramms im Designmodell zweiter Teil des Klassendiagramms im Designmodell XML Schema: Übersicht Daten XML Schema: System XML Schema: Systemübersicht XML Schema: Beschreibung des Systems XML Schema: Abhängigkeiten XML Schema: Ansprechpartner XML Schema: SLA Kontext XML Schema: Administrationsrechte XML Schema: Zugriffskontrolle XML Schema: Kontenrichtlinien und Änderungshistory XML Schema: SLA Prioritäten, Ansprechpartner und Bereiche XML Schema: Schnittstellen XML Schema: Komponenten Webapplikation: Ablauf der Erstellung einer Dokumentation Webapplikation: Ablauf bei der Erstellung der Webseiten Webapplikation: Menüführung der Web-Applikation Web-Applikation: Startseite Web-Applikation: Startseite angemeldet Web-Applikation: Daten eingeben Web-Applikation: Daten bearbeiten - Auswahlliste Web-Applikation: Daten bearbeiten Web-Applikation: Ansprechpartner Web-Applikation: Handbuch erstellen Aufbau von Subversion nach [42] Dokument-Management als Bestandteil eines übergreifenden ECM allgemeines Modell (1) allgemeines Modell (2) Klassendiagramm für Institutsberichte Interaktionsmodell für Institutsberichte Verhaltensmodell für Institutsberichte Designmodell der Institutsberichte Applikationsmodell für Institutsberichte B.1. Anwendungsfalldiagramm B.2. Klassendiagramm C.1. Ablauf einer XSLT-Transformation nach [23] C.2. Ablauf der XSL-FO-Transformation nach [27] C.3. XSL-FO-Seitenmodell nach [28] ix

10 x

11 Tabellenverzeichnis B.1. Beschreibung der Anwendungsfälle xi

12 xii

13 Teil I. Hauptteil

14

15 Inhaltsverzeichnis 1. Einleitung Motivation Lösungsansatz Zusammenfassung Ausgangssituation und Vorgehensweise Dokumentenanalyse Model Driven Architecture (MDA) Nutzen der MDA Basistechnologien der MDA Entwurf nach der MDA am Beispiel Domänenmodell am Beispiel Informationsmodell Interaktionsmodell Konzeptuelles Verhaltensmodell Designmodell am Beispiel Implementationsmodell am Beispiel Anforderungsdefinition XML-Technologien XML - extensible Markup Language XML Schema XPath - XML Path Language XSL - extensible Markup Language XSLT - XSL Transformations XSL-FO - XSL Formating Objects Umsetzung des Projekts Anwendung von XML XML zur Aufnahme der Daten DocBook-XML Was ist DocBook? Warum DocBook? Ein DocBook-Dokument erstellen Verweise in DocBook-Dokumenten Das verwendete XML Schema Anwendung von XSL XSLT-Stylesheet für die Seiten der Webapplikation XSLT-Stylesheet zur Erstellung des DocBook-XML-Dokuments Das DocBook-XSL-Stylesheet Funktionen und Aufbau der Web-Applikation Zusammenspiel der eingesetzten Techniken Benutzerführung und Benutzeroberfläche der Web-Applikation Konzept der Benutzerführung Konzept der Benutzeroberflächen Versionierung Zusammenfassende und kritische Betrachtung der Umsetzung Dokumenten-Management Dokumenten-Management-Systeme Was ist ein Dokument?

16 9.3. Einsatz von Dokumenten-Management-Systemen Verallgemeinerung des Problems Institutsberichte Ausgangssituation und Dokumentenanalyse Entwurf Informationsmodell im Domänenmodell Interaktionsmodell im Domänenmodell Verhaltensmodell im Domänenmodell Designmodell Umsetzung Fazit Zusammenfassung und Ausblick Vergleich der Ergebnisse mit der Aufgabenstellung Persönliche Betrachtungen Ausblick

17 Kapitel 1. Einleitung 1.1. Motivation Die araneanet GmbH als Initiator und Betreuer der vorliegenden Arbeit betreut als mittelständisches Unternehmen öffentliche Auftraggeber und größere Unternehmen der freien Wirtschaft. Neben der umfassenden Betreuung von kompletten Netzwerken, gehört ebenfalls die Beratung hinsichtlich organisatorischer Fragen dazu. Ein größerer Auftraggeber, der durch araneanet in einem umfangreichen Projekt dauerhaft betreut wird, hat um Unterstützung bei der Optimierung des Dokumentationsverfahrens für die vorhandenen IT-Systeme gebeten. Diese Art von Dokumentationen sind für die sichere Betriebsführung notwendig, gerade im Hinblick auf Wiederherstellungsmaßnahmen im Notund/oder Fehlerfall. Aufgrund gesetzlicher Bestimmungen und in Bezug auf Revisionssicherheit, unterliegt der Auftraggeber einer umfangreichen Dokumentationspflicht. Bisher wurden die Dokumentationen der ca. 250 IT-Systeme manuell in Form von Microsoft Word-Dokumenten erstellt. Diese Art der Dokumentation bringt einen erheblichen Zeit- und Aktualisierungsaufwand mit sich, der reduziert werden soll. Der Auftraggeber fordert zukünftig eine teilautomatisierte und kostengünstige Erfassung und Pflege der relevanten Informationen. Dies bedeutet, dass die statischen Inhalte der Dokumentationen unveränderbar und die dynamischen, also neue bzw. sich ändernde, Informationen durch ein System mit geringem Aufwand verwaltbar sein sollen. Darüber hinaus wurde der Wunsch nach einer zentralen Plattform geäußert, die sich durch Benutzerfreundlichkeit sowie ständiger Verfügbarkeit und Lesbarkeit für autorisierte Mitarbeiter auszeichnet. Weiterhin sollen in die zu entwickelnde Lösung verschiedene Ausgabeoptionen integriert werden; sowohl für Printmedien also auch für die Ausgabe am Bildschirm Lösungsansatz Um den Anforderungen des Auftraggebers gerecht zu werden, muss eine Technolgie eingesetzt werden, die eine zentrale Datenhaltung und -pflege mit geringem Zeit- und Arbeitsaufwand sowie verschiedenen Ausgabeformen ermöglicht. Um Lizenzkosten zu vermeiden, lag der Fokus von vornherein auf einer Open-Source basierten Lösung, die individuell auf die definierten Bedürfnisse des Auftraggebers anpassbar ist. Ein Bestandteil des Dokumentationssystems ist DocBook, ein auf offenen und allgemein akzeptierten Standards basierendes Format für Dokumentationen, welches zudem plattformunabhängig einsetzbar ist und verschiedene Ausgabeoptionen realisiert. DocBook allein erfüllt jedoch nicht alle Kriterien. Zusätzlich muss eine einheitliche und feste Datenstruktur der abzubildenen Daten vorgegeben werden, sowie die Struktur des DocBook-Basisdokuments, um die relevanten Daten im Ausgabedokument an die richtige Position zu platzieren. Um das Verfahren der Erstellung und Pflege von Dokumentationen für IT-Systeme weiter zu vereinfachen und zu automatisieren, soll den autorisierten Mitarbeitern bzw. Nutzern eine Web-Applikation bereit gestellt werden, welche die Möglichkeit der zentralen Dateneingabe und -änderung, sowie bei Bedarf des gewünschten Ausgabeformat der Dokumentation per Mausklick erlaubt. 5

18 1.3. Zusammenfassung Die vorliegende Arbeit behandelt die Realisierung der Anforderungen des Auftraggebers von der Analyse über die Definition der konkreten Projektschritte bis hin zur Implementierung des entwickelten Dokumentationssystems. Dabei wird ausführlich auf die systematische Herangehensweise an die Aufgabenstellung sowie die technologischen Möglichkeiten und Verfahren, als auch auf Nutzen und Zweck im praktischen Einsatz eingegangen. 6

19 Kapitel 2. Ausgangssituation und Vorgehensweise Der durch die araneanet betreute Auftraggeber unterhält eine Vielzahl von IT-Systemen. Aufgrund gesetztlicher Bestimmungen und im Hinblick auf Wiederherstellungsmaßnahmen im Not- und/oder Fehlerfall, unterliegt der Auftraggeber einer umfangreichen Dokumentationspflicht. Derzeit werden die Dokumentationen manuell in Form von Microsoft Word-Dokumenten erstellt. Diese Art der Dokumentation bringt einen erheblichen Zeit- und Aktualisierungsaufwand mit sich. Bisweilen wird mit nicht einheitlich strukturierten und vom vorgegebenen Design abweichenden Dokumentationen gekämpft, in denen mitunter relevante Informationen fehlen. Weiterhin treten redundante Daten auf, die beim Einpflegen von Änderungen zu weiterem Zeitaufwand führen. Das Verfahren der Erstellung und Pflege von Dokumentationen für IT-Systeme soll vereinfacht und automatisiert werden. Dazu soll den autorisierten Mitarbeitern bzw. Nutzern eine Web-Applikation bereit gestellt werden, welche die Möglichkeit der zentralen Dateneingabe und -änderung, sowie bei Bedarf des gewünschten Ausgabeformat der Dokumentation per Mausklick erlaubt. Die relevanten Informationen der zu dokumentierenden IT-Systeme sollen zentral gehalten werden, um diese bei Bedarf in das gewünschte Ausgabeformat transformieren zu können. Auf Grundlage der bereits im Lastenheft beschriebenen konkreten Vorstellungen über die zu entwickelnde Web-Applikation und den bereit gestellten Dokumentationsvorlagen und beispielen mit enthaltenen Daten, soll der Entwurf nach der Strategie der Model Driven Architecture (MDA) der Object Management Group (OMG) erfolgen. [01] Bevor jedoch der Entwurf passieren kann, muss eine umfassende Analyse der vorhandenen Dokumentationen vorgenommen werden. Erst danach soll ein kurzer Überblick über die MDA geben werden, um im Anschluss die für dieses Projekt entworfenen Modelle beschreiben zu können. Die Anforderungsdefinition erfolgt in Form eines Pflichtenhefts, gefolgt von einer kurzen Einführung in die verwendeten Technologien, die die Grundlage für das weitere Vorgehen bilden. Im Anschluss daran, soll das Problem in einem allgemeinen Modell dargestellt und von den verwendeten Technologien soweit möglich abstrahiert werden. Im Weiteren soll gezeigt werden, dass der verwendete Ansatz ebenfalls auf weitere Arten von Dokumentationen anwendbar ist, speziell auf die Institutsberichte des Instituts für Informatik an der BTU Cottbus. 7

20 8

21 Kapitel 3. Dokumentenanalyse Bei der Dokumentenanalyse handelt es sich um eine Technik zur Erhebung von Daten, die ausschließlich in Dokumenten vorliegen. Dies ist bei diesem Projekt der Fall. Die zu verwaltenden Daten und deren Struktur liegen ausschließlich in bereits erstellten Dokumentationen vor. Zu den Vorteilen bei diesem Verfahren zählen u.a. der geringere Aufwand bei der Datenerhebung, da sämtliche Daten in einem Dokument vorhanden sind und die dadurch resultierenden geringen Betriebsstörungen, denn es müssen keine weiteren Mitarbeiter mit der Aufgabe der Zusammenstellung der Daten betraut werden. Nachteilig könnte sich auf das Ergebnis der Dokumentenanalyse auswirken, dass die vorhandenen Dokumente eventuell wenig aktuell sind, die daran enthaltenen Daten unvollständig und auch die uneinheitliche Struktur, in der die Daten eingeteilt sind. [vgl.[04]] Es existieren drei unterschiedliche Dokumentationen: Betriebshandbuch, Adminstrationskonzept und SOA-Handbuch. SOA steht für Sarbanes Oxley Act, was ein US-Gesetz zur Verbesserung der Unternehmensberichterstattung ist. [siehe [05]] Für jedes System kann eine oder alle der genannten Dokumentationen existieren. Bei der Analyse fällt auf, dass sich einige Sachverhalte in den unterschiedlichen Dokumentationen überschneiden, so z.b. die Kurzbeschreibung des Systems und die Systemübersicht oder -beschreibung in Form einer Tabelle. Die meisten zu erhebenen Daten unterscheiden sich jedoch voneinander. Während im Betriebshandbuch vor allen Dingen Informationen zu Schnittstellen und den Komponenten des Systems enthalten sind, behandelt das Administrationskonzept die Rechtevergabe sowie die Überwachung von Systemzugriffen. Das SOA-Handbuch enthält detailiertere Informationen und Beschreibungen des Systems selbst. Hier werden u.a. die Hard- und Softwarekomponenten client- und serverseitig beschrieben. Ein Bereich, der im Betriebshandbuch gar nicht beschrieben wird, sind im SOA-Handbuch Informationen zur Betriebsaufnahme, zur Überwachung des Betriebs und zur Unterbrechung und Beendigung des Betriebs. Das Ergebnis der Analyse ist das Informationsmodell im Domänenmodell der MDA. Die Daten werden in Form eines UML-Klassendiagrammes, jedoch noch ohne Kennungen, Datentypen oder abgeleitete Attribute dargestellt. Es zeigt die Zusammenhänge der in den Dokumentationen enthaltenen Daten und dient als Grundlage zur Erstellung eines konkreten Datenbankschemas und der Entwicklung der Web-Applikation. 9

22 10

23 Kapitel 4. Model Driven Architecture (MDA) Die Model Driven Architecture (MDA) ist eine Strategie der OMG zur modellgetriebenen Softwareentwicklung. Dabei erfolgt eine Trennung von plattformunabhängigen Modellen (PIM, engl. platform independent model) und plattformspezifischen Modellen (PSM, engl. platform specifc model), so dass beide unabhängig voneinander wieder verwendet werden können. Abbildung 4.1. Modellierungskonzept der MDA nach [03] Im Domänenmodell (CIM) wird die Geschäftssicht der zu entwickelnden Softwareapplikation modelliert. Es stellt die höchste Abstraktionsebene dar und ist unabhängig in Bezug auf die technische Implementierung. Hier wird weder die interne Struktur noch das innere Verhalten der Software beschrieben. Das CIM bildet die Basis für die weiteren Modelle. Das Designmodell (PIM) spezifiziert die Struktur und das Verhalten der zu entwickelnden Softwareapplikation unabhängig von der technischen Implementierung. Dies soll die Transformation des Designmodells in ein spezifiziertes Implementationsmodell ermöglichen. Das Implementationsmodell (PSM) enthält plattformabhängige Informationen, die für die Implementation der Softwareapplikation in der jeweiligen spezifischen Plattform notwendig sind. Es soll automatisch aus dem Designmodell mit Hilfe von Mappings (Abbildungen) erzeugt werden können. [vgl. [02]] 4.1. Nutzen der MDA Bei der Entwicklung von Software ändert sich die eigentliche Intention Was soll entwickelt werden? nur wenig. Algorithmen bleiben über Jahre gleich. Allerdings ändert sich kontinuierlich das Wie soll etwas entwickelt werden?. 11

24 Bisher setzen ein oder mehrere Entwickler manuell einen Entwurf mit den geforderten Funktionalitäten in Java, C# oder C++ um. Dies birgt jedoch Schwächen und Risiken in sich, wenn die Software z.b. auf eine neue Technologie portiert werden soll. Der Entwurf muss erneut erstellt werden und erhöht die Kosten und den Aufwand der Portierung. Durch die Definition eines plattformunabhängigen Modells der MDA wird die Implementierung auf unterschiedlichen Plattformen ermöglicht. Dies erhöht die Portabilität und Langlebigkeit der Software. Der Prozess der Softwareentwicklung wird dadurch schneller, effizienter und kostengünstiger. [vgl. [02]] 4.2. Basistechnologien der MDA In der MDA vereinigen sich eine Vielzahl von standardisierten Technologien der OMG. Die Umsetzung der MDA kann nur mit Hilfe dieser Technologien erfolgen. Die Unified Modeling Language (UML), aktuell in Version 2.0 verfügbar, ist fester Bestandteil der MDA. Sie dient der grafischen Beschreibung der Struktur- und Verhaltensmodelle und definiert Begriffe und Beziehungen, die für die Modellierung wichtig sind. Mit UML-Profilen wird der Sprachumfang der UML erweitert, um diese an spezifische Einsatzbedingungen anzupassen, d.h. sie bilden die Grundlage für die Transformation des plattformunabhängigen Modells in das plattformabhängige Modell. Analog zur Grammatik einer Programmiersprache, definiert ein UML-Profil die Syntax und statische Semantik der Modellsprache. Zur Definition von Meta-Modell-Sprachen dient die Meta Object Facility (MOF). Sie beschreibt eine abstrakte Sprache für plattformunabhängige Metamodelle. Zu diesen Metamodellen gehören u.a. die UML und das Common Warehouse Metamodel (CWM). Das Common Warehouse Metamodel (CWM) soll den Metadatenaustausch zwischen verschiedenen Softwarekomponenten und Werkzeugen verschiedener Hersteller erleichtern. CWM-konforme Metadaten können u.a. dateibasiert über XML-Dokumente ausgetauscht werden. Eine weitere Basistechnologie ist XMI (engl. extensible Markup Language Metadata Interchange). Sie ist ein auf XML (engl. extensible Markup Language) basiertes Austauschformat für UML Modelle. Dies ermöglicht den Austausch von Modellen zwischen UMLWerkzeugen verschiedener Hersteller. Die Modelle werden dabei durch XML dargestellt. Eine XML-Datei besteht aus einer Dokumenttypdefinition, die die Struktur des folgenden eigentlichen Inhalts darstellt. Einen ausführlicheren Überblick über XML gibt das Kapitel XML-Technologien. [vgl. [02]] 12

25 Kapitel 5. Entwurf nach der MDA am Beispiel Im Folgenden werden die für das umzusetzende Projekt entworfenen Modelle in der MDA beschrieben Domänenmodell am Beispiel Das Domänenmodell für das umzusetzende Projekt ist ein IT-unabhängiges Modell, auf deren Grundlage letztendlich das Projekt umgesetzt wird ohne jedoch technische Aspekte der Implementierung einfließen zu lassen, wie es die MDA vorschreibt. Im Folgenden wird ein Informations-, Interaktions- und Verhaltensmodell im Domänenmodell aufgestellt. Dabei wird auf designspezifische Angaben wie Kennungen, Datentypen für Attribute, abgeleitete Attribute und Aufzählungsdatentypen verzichtet [vgl. [03]] Informationsmodell Zur Darstellung von Informationen in einem Modell, wird in der UML das Klassendiagramm verwendet. Dieses stellt graphisch die Struktur und das Verhalten gleichartiger Objekte des Systems dar. Eine Klasse dient dazu die konkreten Objekte zu erzeugen. Abbildung 5.1 zeigt das Informationsmodells. Zentraler Mittelpunkt ist die Klasse System, welche den Namen (name) und eine kurze Beschreibung (description) des zu dokumentierenden IT-Systems als Attribute besitzt. Abbildung 5.1. Informationsmodell im Domänenmodell 13

26 Ihr angeschlossen sind die Klassen für die Beschreibung des Systems (SystemDescription), für Schnittstellen (Interface), für den SLA Kontext (SlaContext) und dessen Priorität (SlaPriority), für Kontaktpersonen (Contact), für Komponenten (Component), für Abhängig14

27 keiten zu anderen Systemen (Dependences), für die Zugriffskontrolle (AccessControl), für Administrationsrechte (AdministrationRight), für Kontenrichtlinien (AccountDirective), sowie Klassen für den Datenfluss (SystemDataFlow) und die Übersicht (SystemSummary) des Systems und für einen Verweis auf eine oder mehrere Installationsanweisungen (InstalllationReference) falls vorhanden. Letztere setzen sich aus der Angabe einer externen Datei (ExternalFile) zusammen. Weiterhin existieren zu jedem System mehrere Änderungsinformationen (RevisionHistory). Diese Klasse enthält den Autor (author), das Datum (date) sowie die Nummer der aktuellen Version der Dokumentation (number) und die Beschreibung (description) dessen, was geändert wurde. Bis auf Komponenten (Component), Kontaktpersonen (Contact) und Schnittstellen (Interfaces) sind dies alles existenzabhängige Assoziationen (Kompositionen), da durch Löschen eines Systems alle anderen Informationen ebenfalls nicht mehr benötigt werden und somit gelöscht werden können. Schnittstellen (Interface) können weitere Informationen besitzen. Es können zur Schnittstelle mehrere oder auch keine Funktion/en (IntefaceFunction) angegeben werden. Jede Funktion besitzt Parameter (InterfaceFunctionParameter) oder auch nicht. Weiterhin besitzt eine Schnittstelle eine Anzahl von Daten (InterfaceData), die von einem bestimmten Typ (InterfaceDataType) sein müssen. Hinzu kommen Informationen zur Archivierung (InterfaceDataArchive) der Schnittstellendaten. Ein weiterer großer Bereich sind die Komponenten (Component). Jede Komponente ist von einem bestimmten Typ (ComponentType) und besitzt eine Vielzahl weiterer Informationen. Dazu zählen Informationen zur Installation der Komponente (ComInstallation), zu betriebsrelevanten Parametern (ComParameter), zu bekannten Fehlern (ComKnownErrors), zum Backup (ComBackup), zu Recovery Szenarien (ComRecovery) und Abhängigkeiten zu anderen Systemen und Kompenenten (ComRecDepSystem und ComRecDepComponent), sowie Informationen zu Betriebsarbeiten (ComOperationWork), zu Referenzen zur Software-Verteilung (ComScript), zu Lizenzen (ComLicence), zu Berechtigungen (ComAuthorizations) und zum Wartungsvertrag (ComMaintenanceContract). Für den Wartungsvertrag der Komponente werden ein Ansprechpartner und ein Abrufberechtigter angegeben. Die Informationen dieser beiden Personen sind kongruent mit denen der Kontaktpersonen (Contact), so dass dort ebenfalls zwei Assoziationen vorhanden sind. Für das Backup der Komponente werden weitere Informationen benötigt; die Angabe, welche Pfade (ComBackupPath) gesichert werden sollen und vor allem mit welchem Client (ComBackupClient) die Sicherung erfolgen soll. Ein Pfad hat ebenfalls einen Typ (ComBackupType). Die in den Referenzen zur Softwareverteilung enthaltenen Skripte können verschiedene Installationstypen (ComScriptInstallationType) haben. Auch die Betriebsarbeiten der Komponenten werden in Typen (ComOperationWorkType) eingeteilt. Eine weitere wichtige Klasse, ist die Klasse Introduction. Sie stellt die Informationen für das erste Kapitel, die Einleitung, der Dokumentationen dar. Insgesamt sind drei verschiedene Dokumentationen für ein System möglich: das Betriebshandbuch, das Administrationskonzept und das SOA-Handbuch. Um das Einleitungskapitel zum jeweiligen Handbuch zuzuordnen, existiert eine weitere Klasse ManualType. Sie nimmt als Kürzel die drei verschiedenen Dokumentationsarten auf, so dass auch weitere Arten hinzugefügt werden können. Diese Klasse ist ebenso mit den Änderungsinformationen (RevisionHistory) assoziiert. Denn hier 15