Sie sind auf Seite 1von 51

FACHHOCHSCHULE DES BFI WIEN

BACHELORSTUDIENGANG
Projektmanagement und Informationstechnik

LEHRVERANSTALTUNG: SEMINAR IT

BACHELORARBEIT
Releasespezifisches Verwalten von betreiberInnenspezifschen
Steuerungsdaten auf Basis von Klartext-Datenspeichern

Fachbereich:

Informationstechnologie

Eingereicht von:

Sebastian Kopf

Personenkennzeichen:

1110387012

Anschrift:

Rabensburgerstrasse 17/3, 1020 Wien

Betreuer:

Dipl. Ing. Thomas Havelka

Erhalter:

Fachhochschule des BFI Wien GmbH


Wohlmutstrae 22
1020 Wien

Wien, 29.06.2014

1110387012 Sebastian Kopf

Eidesstattliche Erklrung
Ich versichere,
dass ich die Regeln des wissenschaftlichen Arbeitens eingehalten habe, insbesondere, dass ich die Diplomarbeit selbstndig verfasst und mich anderer als der
im beigefgten Literaturverzeichnis angegebenen Quellen nicht bedient habe. Alle
Stellen, die wrtlich oder sinngem aus Verffentlichungen entnommen wurden,
sind als solche kenntlich gemacht. Ich versichere weiters, dass ich diese Diplomarbeit bisher weder im Inland noch im Ausland in irgendeiner Form als Prfungsarbeit vorgelegt habe.
Mir ist bewusst, dass auch nach positiver Beurteilung der Diplomarbeit die Aufdeckung eines Verstoes gegen die Regeln des wissenschaftlichen Arbeitens (insbesondere bei Vorliegen eines Plagiats) die Einleitung eines Verfahrens zur Nichtigerklrung der Beurteilung sowie des akademischen Grades zur Folge hat.

________________
Datum

___________________
Unterschrift

1110387012 Sebastian Kopf

Einverstndniserklrung

Mit meiner Unterschrift rume ich der FH des bfi Wien GmbH das weltweite, zeitlich
und rtlich unbegrenzte Nutzungsrecht ein, meine Bachelor-/Diplomarbeit auf einer
Internetplattform zur Verfgung zu stellen (iSd 18a UrhG) und fr Lehrzwecke zu
vervielfltigen.
Ich bin weiters damit einverstanden, dass meine Bachelor-/Diplomarbeit von der FH
des bfi Wien GmbH bei Prmierungsveranstaltungen bzw. bewerben (wie z.B.
Best-paper-Award) nach Rcksprache mit dem Autor/der Autorin bzw. den
AutorInnen eingereicht wird.


_____________________________
Unterschrift des/der Autors/in



Wien, _________________

II

1110387012 Sebastian Kopf

Inhaltsverzeichnis
1 Einleitung.............................................................................................................. 1
1.1 Relevanz der Themenstellung......................................................................... 1
1.2 Forschungsfrage ............................................................................................. 4
1.3 Stand und kritische Reflexion der Literatur ..................................................... 4
1.4 Methodische Vorgangsweise .......................................................................... 5
1.5 Aufbau der Arbeit ............................................................................................ 5
1.6 Definitionen ..................................................................................................... 5
2 Konfigurationsmanagement ............................................................................... 8
2.1 Grundlagen von Konfigurationsmanagement .................................................. 8
2.2 Artefakte der Softwareentwicklung unter Konfigurationsmanagement ........... 9
2.3 Grnde fr den Einsatz von Konfigurationsmanagement ............................. 10
2.4 Ttigkeiten im Konfigurationsmanagement ................................................... 12
2.4.1 Baselines etablieren ............................................................................... 12
2.4.2 nderungen verfolgen und lenken .......................................................... 14
2.4.3 Integritt etablieren ................................................................................. 14
2.5 Herausforderungen im Einsatz von Konfigurationsmanagement .................. 15
3 Versionsverwaltungssysteme .......................................................................... 17
4 Datenbankbasierte Verwaltung von BetreiberInnen-spezifischen
Steuerungsdaten .............................................................................................. 21
4.1 Grundlagen Datenbanken ............................................................................. 21
4.2 Funktionsweise von Datenbanken ................................................................ 22
4.3 Konventionelle Datenbanken ........................................................................ 23
4.4 Temporale Datenbanken ............................................................................... 23
4.5 Anforderungen des Konfigurationsmanagements von
betreiberInnenspezifischer Software an datenbankbasierte Verwaltungen von
Steuerungsdaten.................................................................................................... 24
4.6 Erfllung der Anforderungen des Konfigurationsmanagements von
Steuerungsdaten in datenbankbasierten Applikationen ........................................ 26
5 Alternative Verwaltungsmglichkeiten von betreiberInnen-spezifischen
Steuerungsdaten .............................................................................................. 27
5.1 Auszeichnungssprache Extensible Markup Language (XML) ....................... 27
5.1.1 Grundlagen von XML .............................................................................. 27
5.1.2 Aufbau von XML ..................................................................................... 28
5.1.3 XML Dokumenttyp Definition und XML-Schema .................................... 29
5.1.4 XML-Daten ............................................................................................. 30
5.1.5 Anwendungsgebiete von XML ................................................................ 31
5.1.6 Erfllung der Konfigurationsmanagement-Anforderungen von
Steuerungsdaten in datenbankbasierten Applikationen verwaltet in XML ......... 32
5.2 Domain Specific Language ........................................................................... 33
5.2.1 Grundlagen von DSL .............................................................................. 33
III

1110387012 Sebastian Kopf

5.2.2 Anwendungsgebiete von DSL ................................................................ 35


5.2.3 Erfllung der Konfigurationsmanagement-Anforderungen von
Steuerungsdaten in datenbankbasierten Applikationen verwaltet in DSL .......... 36
5.3 Vergleich von DSL und XML als Grundlage fr die Verwaltung von
Steuerungsdaten.................................................................................................... 36
6 Conclusio............................................................................................................ 38
7 Literaturverzeichnis ........................................................................................... 40

IV

1110387012 Sebastian Kopf

Darstellungsverzeichnis
Nr.

Bezeichnung

Seite

Darstellung 1: Durch Konfigurationsmanagement verwaltete Softwarebestandteile


................................................................................................................................. 2
Darstellung 2: Versions/Release-Entwicklung SoftwareherstellerIn versus
BetreiberIn ............................................................................................................... 3
Darstellung 3: berblick Aktivitten des Konfigurationsmanagements ................. 9
Darstellung 4: Einfache Darstellung einer versionierten Datei ............................ 17
Darstellung 5: Vereinfachter nderungsworkflow von Steuerungsdaten mit Git . 20
Darstellung 6: Applikationsarchitektur einer datenbankbasierten Software ........ 25
Darstellung 7: Beispiel eines XML ....................................................................... 28
Darstellung 8: Beispiel eines DTD von Projektdaten ........................................... 29
Darstellung 9: XML-Schema der Projektdaten .................................................... 30
Darstellung 10: Baumstruktur eines XML-Kontaktdokuments ............................. 31

1110387012 Sebastian Kopf

Tabellenverzeichnis
Nr.

Bezeichnung

Seite

Tabelle 1: Operationen von Versionsverwaltungssystemen ................................. 19

VI

1110387012 Sebastian Kopf

Abkrzungsverzeichnis
CMMI
DBMS
HTML
IEC
ISO
ITIL
SACM
SGML
SPICE
SQL
UML
XHTML
XML

Capability Maturity Model Integration


Datenbankmanagementsystem
Hypertext Markup Language
International Electrotechnical Commission
International Organization for Standardization
Information Technology Infrastructure Library
Service Asset and Configuration Management
Standard Generalized Markup Language
Software Process Improvement and Capability Determination
Structured Query Language
Unified Modeling Language
Extensible HyperText Markup Language
Extensible Markup Language

VII

1110387012 Sebastian Kopf

Abstract
Configuration Management is the discipline to manage and control assets needed to deliver software or services. Configuration data, which changes the runtime behaviour of an
application during its operation, is part of the assets controlled via configuration management. Changing the runtime behaviour in a running application is risky because of possible unwanted effects. It is therefore necessary to reduce the risk of such effects happening in a production environment. Configuration data in database-based applications is
difficult to manage in respect to the requirements of formal configuration management.
Without various processes to support the management of configuration data, instead of
just changing it, these applications are not capable to properly administer changing configuration data. This thesis analysis the effects of database managed configuration data in
respect to the requirements of configuration management. In addition it investigates textbased alternatives to manage the configuration data in collaboration with version control
software. The research is done in published literature, different papers and various web
based sources. Results show that XML-based management of configuration data with
support of version control software is able to fulfil the requirements of formal configuration
management. Database managed configuration data is either flawed or requires additional
effort to implement the necessary features. These outcomes can be used to study the
needs for an integrated software solution which supports the management of configuration
data for external database based applications.

VIII

1110387012 Sebastian Kopf

Einleitung

1.1

Relevanz der Themenstellung

In den letzten Jahren haben sich die Mglichkeiten und die Innovationsfhigkeiten
der Softwaretechnologie schneller entwickelt als die Fhigkeiten von Softwareentwicklungsfirmen, die Komplexitt der Probleme in der Entwicklung und im Betrieb
zu managen. Dadurch wird ihr Vermgen, zuverlssige und verwendbare Software
innerhalb des vorgegebenen Budgets und den vorgegebenen Termin zu entwickeln, weiter beeintrchtigt. 1
Hinzu kommt die Schwierigkeit, komplexe Software auf die unterschiedlichen Bedrfnisse eines/einer BetreiberIn zuzuschneiden. Anstatt die Software je nach BetreiberIn mit unterschiedlichen Funktionen im Quellcode auszustatten, wird die
gleiche Funktionalitt an alle BetreiberInnen ausgeliefert. Die unterschiedlichen
Bedrfnisse werden mittels vom/von der BetreiberIn setzbaren Steuerungsdaten
(in einer Datenbank gespeichert) zufriedengestellt. Diese Steuerungsdaten ndern
das Verhalten der Applikation whrend der Laufzeit entsprechend den Bedrfnissen des/der BetreiberIn.
Durch diese Variabilitt der Applikation treten verschiedene Schwierigkeiten auf.
Zum einen sind nderungen an den Steuerungsdaten einer Software whrend des
Betriebes ein groes Risiko. Dabei muss sichergestellt werden, dass nur qualifiziertes und autorisiertes Personal in der Lage ist, solche nderungen durchzufhren. Zum anderen besteht die Notwendigkeit, die Vernderungen dieser Steuerungsdaten zu dokumentieren, um im Falle von Softwarefehlern oder anderen Anlssen (z.B. risikoreiche Konfigurationsnderungen) die Nachvollziehbarkeit zu
gewhrleisten.
In Darstellung 1 wird ein schematischer berblick eines Softwareprodukts abgebildet. Dabei unterteilt sich die Software auf oberster Ebene in die unterschiedlichen
Module sowie den Datenspeicher fr Steuerungsdaten.

Vgl. Keyes (2004) o.S.

1110387012 Sebastian Kopf

Darstellung 1: Durch Konfigurationsmanagement verwaltete Softwarebestandteile

Innerhalb der Module wird in unterschiedliche Code-Arten weiter unterteilt. Diese


sind:

Quell-Code,

kompilierter Code (Resultat der bersetzung aus dem Quell-Code in ein


maschinenlesbares Ergebnis)3 und

ausfhrbarer Datei (durch Verlinken der kompilierten Module erzeugte ausfhrbare Datei) 4

Weiters werden die Abhngigkeiten zwischen den Modulen und die Verwendung
von Steuerungsdaten in den Modulen dargestellt. Im Rahmen des Lebenszyklus
einer Software sind alle diese Bestandteile einer fortlaufenden Vernderung unterzogen. Mit Ausnahme der Steuerungsdaten sind alle diese Bestandteile dem
Softwareentwicklungsprozess unterworfen. Die durch die KundInnen vernderbaren Daten sind vom regulren Entwicklungsvorgehen und dessen Verwaltung

Eigene Darstellung nach Quelle: Conrardi/Westfechtel (1998) S. 237.

WhatIs (2014) online.

Allain (2014) online.

1110387012 Sebastian Kopf

ausgenommen, da das Laufzeitverhalten der Software im Rahmen des Betriebes


angepasst und verndert werden kann.
Um diese Problemstellung/Thematik besser zu illustrieren, ist in Fehler! Verweisquelle konnte nicht gefunden werden. ein beispielhaftes Versions- bzw. Releasediagramm abgebildet. Im Rahmen des Entwicklungsprozesses wird angenommen, dass der/die HerstellerIn verschiedene Versionen der Software und des
Quellcode-Standes hlt. Das konkrete Beispiel zeigt, dass von der HerstellerInnen-Version 2.1.0 die Baseline (Ausgangsversion) der Betriebsinstallation erstellt
wird. Diese Version beinhaltet einen vom/von der HerstellerIn definierten Zustand
der Steuerungsdaten. Vernderungen in der Betriebsinstallation (z.B. Version 3.0
der BetreiberIn) werden durch Anpassungen in den Steuerungsdaten hervorgerufen.

Darstellung 2: Versions/Release-Entwicklung SoftwareherstellerIn versus BetreiberIn

Eigene Darstellung

1110387012 Sebastian Kopf

Als weiteren Anwendungsfall kann das Auftreten eines Fehlers im Test der Betriebsinstallation Version 3.0 dargestellt werden. Damit der/die HerstellerIn den
konkreten Zustand der Software beim Auftreten des Fehlers beurteilen kann, werden die Steuerungsdaten an den/die Hersteller bermittelt. Durch diesen Informationstransfer ist es dem/der HerstellerIn mglich, eine betriebsspezifische Version
2.1.0.K in der eigenen Versions/Release-Verwaltung zu erstellen.
Die Verwaltung dieser Art von kritischen Daten ist Aufgabe des Konfigurationsmanagements. Konfigurationsmanagement definiert die Aufgaben und Anforderungen, die an die Administration solcher Daten gestellt werden.
Diese Arbeit untersucht die Anforderungen die Konfigurationsmanagement an die
Verwaltung der Steuerungsdaten von datenbankbasierten Applikationen hat und
versucht Lsungsmodelle aufzuzeigen, um diese Anforderungen zu erfllen.

1.2

Forschungsfrage

Die in der Einleitung beschriebenen Problemstellungen konnte der Autor in der


Praxis hufig beobachten. Der Wunsch, dieses Problem besser zu strukturieren
sowie das Bedrfnis zu einer Besserung beizutragen, haben zu den folgenden
Forschungsfragen gefhrt:
Forschungsfrage 1:
Wie kann eine releasespezifische Verwaltung datenbankbasierter Steuerungsdaten durch den Einsatz eines Klartext-Datenspeichers im Hinblick auf die Anforderungen aus Software-Konfigurationsmanagement abgelst werden?
Unterfrage 1:
Welche Probleme treten im Zusammenhang mit dem releasespezifischen Verwalten von datenbankbasierten Steuerungsdaten auf?

1.3

Stand und kritische Reflexion der Literatur

Konfigurationsmanagement als Methode wird in verschiedenen Management


Standards und Reife-Grad Modellen beschrieben. Im Hinblick auf Konfigurationsmanagement weichen die Standards nur sehr gering von einander ab.

1110387012 Sebastian Kopf

1.4

Methodische Vorgangsweise

Die Auswahl der Literatur erfolgt nach Relevanz im Bezug auf die gestellten Forschungsfragen. Die Relevanz wird anhand des Abstracts oder der Volltexte beurteilt. Verwendet werden Artikel aus verschiedenen Publikation und Werken zu den
Themen Domain Specific Language, Configuration Management und Software
Configuration Management.
Um die Forschungsfragen zu klren, wird eine qualitative Inhaltsanalyse der ausgewhlten Literatur durchgefhrt. Dabei wird nur Primrliteratur verwendet.
Die Literaturrecherche wird sowohl online als auch in Bibliotheken durchgefhrt.
Die Onlinerecherche wird fr die Erhebung aller Artikel und Webseiten durchgefhrt. Hierfr werden die Suchmaschinen von Google Scholar, Emerald, ScienceDirect, Wiley Online Libary sowie Google verwendet. Die Recherche der weiteren
Werke erfolgt in den Bibliotheken der Wirtschaftsuniversitt Wien, der Fachhochschule des bfi Wien und der technischen Universitt Wien.

1.5

Aufbau der Arbeit

Nach der Einleitung und den allgemeinen Definitionen in Kapitel 1 werden in dieser Arbeit in Kapitel 2 zuerst die Grundlagen und Anforderungen von Konfigurationsmanagement dargelegt. Im Anschluss wird in Kapitel 3 die Funktionalitt und
Funktionsweise von Versionsverwaltungssoftware erlutert und den Bezug zu
Konfigurationsmanagement hergestellt. Das Kapitel 4 erlutert die Ausgangslage
der datenbankbasierten Verwaltung von Steuerungsdaten. In Kapitel 5 wird auf
die alternativen Verwaltungsmglichkeiten von Steuerungsdaten eingegangen und
auf ihre Eignung im Hinblick auf die Anforderungen aus Konfigurationsmanagement untersucht. Die Conclusio erfolgt abschlieend in Kapitel 6.

1.6

Definitionen

Konfigurationsmanagement:
Fr Konfigurationsmanagement gibt es viele Definitionen in Managementstandards oder Reifegrad-Modellen. In dieser Arbeit werden aufgrund des Software
Fokus die weit verbreiteten Reifegrad-Modelle Capability Maturity Model Integration (CMMI) und Software Process Improvement and Capability Determination
(SPICE) verwendet. Fr den Betrieb wird teilweise noch das Service-Framework
der Information Technology Infrastructure Library (ITIL) verwendet.
CMMI definiert Software Konfigurationsmanagement wie folgt:
5

1110387012 Sebastian Kopf

Disziplin der technischen und administrativen Leitung und Aufsicht


fr (1) Identifikation und Dokumentation der funktionalen und physikalischen Eigenschaften von Konfigurationseinheiten, (2) Steuerung
der nderungen dieser Eigenschaften, (3) Aufzeichnung und Berichterstattung zur nderungsbearbeitung und des Umsetzungsstatus und (4) Verifizierung der Erfllung der festgelegten Anforderungen.6
Nach SPICE ist Konfigurationsmanagement definiert:
The purpose of the Configuration management process is to establish and maintain the integrity of all the work products of a process or
project and make them available to concerned parties.7
Die Information Technology Infrastructure Library definiert Konfigurationsmanagement folgendermaen:
The purpose of the SACM process is to ensure that the assets required to deliver services are properly controlled, and that accurate
and reliable information about those assets is available when and
where it is needed. This information includes details of how the assets have been configured and the relationships between assets.8
Steuerungsdaten:
Daten, die das [..] System bentigt, um die verschiedenen Verarbeitungen entsprechend den Anforderungen des Anwenders [sic!] durchfhren zu knnen.9
Software Process Improvement and Capability Determination (SPICE):
SPICE ist ein Reifegrad-Modell des Verbands der Automobilindustrie zur Bewertung von Softwarezulieferern. Das Modell basiert auf dem ISO-Standard ISO/IEC
15504-2. 10
Capability Maturity Model Integration (CMMI):
CMMI ist ein Reifegrad-Modell des Software Engineering Institute zur Bewertung
von Softwareentwicklungsorganisationen.
Das Software Engineering Institute definiert CMMI wie folgt:
CMMI fr Entwicklung umfasst gute Praktiken fr die Entwicklung
und Pflege von Produkten und Dienstleistungen sowie Praktiken, die
den gesamten Lebenszyklus eines Produkts von der Konzeption
ber die Lieferung bis hin zur Pflege abdecken. Dabei liegt der

Software Engineering Institute (2010) S. 454.

Verband der Automobilindustrie (2007) S. 62.

Cabinet Office (2011) S. 89 f.

SAP Knowledge Warehouse (2014) online.

10

Vgl. Verband der Automobilindustrie (2010) S. 8.

1110387012 Sebastian Kopf

Schwerpunkt auf der Arbeit, die in die Entwicklung und Instandhaltung des Endprodukts fliet.11
Versionsverwaltung:
Versionsverwaltung ist ein System, das nderungen an einer Datei oder einem
Satz von Dateien im Zeitablauf aufzeichnet, um spter auf spezifische Version der
Datei(en) zugreifen zu knnen.12
Baseline:
Baselines stellen eine stabile Basis fr die kontinuierliche Weiterentwicklung von
Konfigurationseinheiten dar.13

11

Software Engineering Institute (2010) S. 15.

12

Vgl. Chacon (2009) S. 1.

13

Software Engineering Institute (2010) S. 151.

1110387012 Sebastian Kopf

Konfigurationsmanagement

In diesem Kapitel werden die Grundlagen des Konfigurationsmanagements ausgefhrt und die Anforderungen in Bezug auf die Verwaltung von Arbeitsergebnissen
der Softwareentwicklung und dem Betrieb von Software aufgezeigt.

2.1

Grundlagen von Konfigurationsmanagement

Konfigurationsmanagement betrachtet die einzelnen Teile des Systems sowie das


System als Ganzes. Es wird sichergestellt, dass alle Informationen ber eine
Software in Teilen oder als Ganzes vollstndig, korrekt und zuverlssig sind. Weiters wird die Verfgbarkeit dieser Informationen gewhrleistet. Die Informationen
beschreiben die Details der Teile und des Ganzen sowie deren Konfigurationsstand und deren Beziehungen untereinander.14 Das Konfigurationsmanagement
dient dadurch der Etablierung der Integritt von Arbeitsergebnissen.15
Die Bestandteile von Konfigurationsmanagement sind in der betrachteten Literatur
zu groen Teilen bereinstimmend. Sie werden in unterschiedlichen Detailierungsgraden ausgefhrt. Die Hauptbestandteile sind jedoch bergreifend einheitlich. In den Reifegrad-Modellen Capability Maturity Model Integration (CMMI) und
Software Process Improvement and Capability Determination (SPICE) werden die
folgenden Bestandteile aufgelistet:16

Definition der Konfiguration ausgewhlter Arbeitsergebnisse zur Erstellung


der Baselines zu definierten Zeitpunkten.

Steuerung von Anpassungen an Konfigurationseinheiten

Bereitstellung von Spezifikationen zur Erstellung von Arbeitsergebnissen


aus dem Konfigurationsmanagementsystem

Erhaltung der Baslineintegritt

Statusreporting der Konfigurationsdaten fr bestimmte Abnehmer wie EntwicklerInnen, EndanwenderInnen und KundInnen.

Darstellung 3 zeigt einen berblick ber die Aktivitten des Konfigurationsmanagements und seine Zusammenhnge:
14

Vgl. Cabinet Office (2011) S. 89 f.; anders Software Engineering Institute (2010) S. 150; anders
Hass (2003) o.S.

15

Vgl. Software Engineering Institute (2010) S. 150; anders Cabinet Office (2011) S. 90

16

Vgl. Software Engineering Institute (2010) S. 151; bereinstimmend Verband der Automobilindustrie (2010) S. 63 f.

Configuration management is unique identification, controlled storage, change control, and status reporting
of selected intermediate work products, product components, and products during the life of a system.
Figure 1-1 shows the
activity areas
included in the definition of configuration management used in this book. It also shows their
1110387012
Sebastian
Kopf
relations to each other, to common data, and to elements outside the configuration management process area.

Figure 1-1. Overview of Configuration Management Activities

17

Darstellung
3: berblick Aktivitten des Konfigurationsmanagements
When you work professionally with configuration management (as with anything else) it's important to have the fundamental
concepts in place. If all else fails, you can go back and seek a solution there.

2.2

Artefakte der Softwareentwicklung unter Konfigurationsmanagement

Im Rahmen des Konfigurationsmanagements knnen verschiedene Konfigurationselemente unter die Verwaltung gestellt werden.
Ein Konfigurationselement ist jeder mgliche Bestandteil der Entwicklung oder
Lieferung eines Systems oder Produkts, fr den es notwendig ist, ihn zu identifizieren, herzustellen, zu speichern, zu verwenden und individuell zu ndern.18
Ein Software Objekt als Element von Konfigurationsmanagement enthlt das Resultat einer Entwicklungs- oder Wartungsaktivitt.19 Dabei wird aber nicht nur der
17

Hass (2003) o.S.

18

Vgl. Hass (2003) o.S.

1110387012 Sebastian Kopf

Programm-Quellcode als relevant betrachtet.20 Die Arten von Software Objekten


unter Konfigurationsmanagement beinhalten auch unter anderem: 21

die Anforderungs-Spezifikation

Designs

Dokumentation

Programm-Quellcode

Testplne

Testflle

Benutzerhandbcher

Projektplne

Steuerungsdaten22

Es werden aber nicht nur diese Elemente berwacht, sondern auch deren Beziehungen zueinander.23

2.3

Grnde fr den Einsatz von Konfigurationsmanagement

Konfigurationsmanagement kann existenziell im Softwareentwicklungsprozess


eingesetzt werden.24 Das Reifegrad-Modell CMMI fhrt hierzu an:
Konfigurationsmanagement ist auf die rigorose Lenkung von betrieblichen und technischen Aspekten von Arbeitsergebnissen, einschlielich des gelieferten Produkts oder der Dienstleistung, gerichtet.25
Damit sich MitarbeiterInnen speziell in agilen Umgebungen nicht festfahren, entsteht die Anforderung hufiger nderungen und Produktionslufe, sowie verschiede Baselines und vielfltige Arbeitsrume (z.B. fr Einzelpersonen oder Teams)
untersttzen zu knnen.26 Agile Umgebungen bezieht sich auf die Projektabwicklung beim Softwareerstellungsprozess und legen den Schwerpunkt auf kurze Ent-

19

Vgl. Conrardi/Westfechtel (1998) S. 235.

20

Vgl. Hass (2003) o.S.

21

Vgl. Conrardi/Westfechtel (1998) S. 235; anders Verband der Automobilindustrie (2010) S. 63.

22

Vgl. Verband der Automobilindustrie (2010): S. 63.

23

Vgl. Conrardi/Westfechtel (1998) S. 236.

24

Vgl. Hass (2003) o.S.

25

Software Engineering Institute (2010) S. 152.

26

Vgl. Software Engineering Institute (2010) S. 152.

10

1110387012 Sebastian Kopf

wicklungszyklen und die inkrementelle Lieferung der Ergebnisse, basierend auf


vernderbare Anforderungen der KundInnen. 27
Konfigurationsmanagement beantwortet somit folgende Fragen fr individuelle
Komponenten oder ganze Produkte:28

Wer bin ich?

Warum bin ich hier?

Warum bin ich, wer ich bin?

Wo gehre ich dazu?

Die Mglichkeit, diese Fragen ber den gesamten Lebenszyklus eines Softwareproduktes zu beantworten, erhht die Qualitt des Produktes.29
A. M. J. Hass fasst konkret die folgenden Vorteile aus dem Einsatz von Konfigurationsmanagement zusammen:30

Ermglicht die Behebung des gleichen Fehlers an mehreren Stellen

Keine Entwicklung auf Basis einer falschen Grundlage durchfhren (z.B.


veraltete Anforderungen)

Kein Wiederauftreten bereits behobene Fehler

Keine Einfhrung unerwnschter Funktionalitt

Ausschlieen von Unwissen ber die an KundInnen verteilte Produktversion

Keine unerwnschten Kosten bei der Aktualisierung aufgrund von Inkompatibilitten mit alter Infrastruktur

Keine Redundanzen bei der Programmierung

Keine Probleme beim Wissenstransfer zu neuen MitarbeiterInnen

J. Keyes ergnzt diese Vorteile noch um die folgenden Punkte:31

Nachvollziehbarkeit der Anforderungen bis zum Produkt

Beschrnkung der Haftbarkeit durch die Aufzeichnung aller Daten

27

Vgl. eHow (2014) online.

28

Vgl. Hass (2003) o.S.

29

Vgl. Hass (2003) o.S.

30

Vgl. Hass (2003) o.S.

31

Vgl. Keyes (2004) o.S.

11

1110387012 Sebastian Kopf

Hilft bei der Reduktion der Lebenszyklus Kosten der Softwarewartung

Erlaubt Verantwortlichkeiten zur Quellen zurckzuverfolgen

Bietet einen konstante bereinstimmung mit den Anforderungen von KundInnen

Bietet eine stabile Umgebung, um den Softwareentwicklungsprozess zu definieren, zu wiederholen und zu verbessern

Erweitert die Einhaltung von angewendeten Standards

Bietet eine Umgebung, in der sinnvolle Messungen durchgefhrt und verwendet werden knnen

Erweitert die Mglichkeiten der Statusauswertung

Bietet einfache Mglichkeiten zur Berichtsgenerierung

Erlaubt ein schnelles und einfaches Auditing

Schafft die Mglichkeit, die Umstnde zu reproduzieren, unter welchen ein


Produkt erstellt wurde

Frdert die Fhigkeit zur Verbesserung ohne Schuldzuweisungen

Bietet die Fhigkeit festzustellen, wann ein Produkt fertig zum Release ist.

2.4

Ttigkeiten im Konfigurationsmanagement

In diesem Kapitel werden die einzelnen Ttigkeiten des Konfigurationsmanagements nach CMMI und SPICE behandelt.

2.4.1 Baselines etablieren


Im Rahmen der Etablierung der Baseline werden die Ttigkeiten nderungen
verfolgen und lenken und Integritt etablieren durchgefhrt. nderungen
verfolgen und lenken (Kapitel 2.4.2) dient dazu, die Baseline an nderungen anzupassen. Integritt etablieren (Kapitel 2.4.3) dient dazu, die Integritt der Baseline zu dokumentieren und auditieren.32
Das Einfgen der Baselines in das Konfigurationsmanagementsystem erfolgt entsprechend dem Entwicklungsfortschritt. Vernderungen an Baselines und das erstellen von Auswertung werden systematisch gelenkt und berwacht. Beispiele fr

32

Vgl. Software Engineering Institute (2010) S. 153.

12

1110387012 Sebastian Kopf

eine Baseline sind Nachverfolgbarkeitsmatrizen von Arbeitsergebnissen, widerspruchsfreie Anforderungen oder auch AnwenderInnendokumentationen. 33
Im Zuge der Ttigkeit Baselines etablieren fallen folgende Aufgaben an:

Konfigurationseinheiten festlegen
Bei der Etablierung der Baseline mssen die Konfigurationseinheiten festgelegt werden. Dies zielt darauf ab, die Bestandteile und zugehrigen Arbeitsergebnisse festzusetzen, die unter Konfigurationsmanagement gestellt
werden sollen.34
Ergnzend zu dem unter Kapitel 2.2 aufgefhrten Punkte werden noch weiters ausgewhlt und spezifiziert:35
- die ausgelieferten Produkte
- ausgewiesene interne Arbeitsergebnisse
- zugekaufte Produkte
- Werkzeuge und Investitionsgter der Projektarbeitsumgebung
- Andere Gegenstnde, die zur Erzeugung und Dokumentation der Arbeitsergebnisse verwendet werden.

Konfigurationsmanagementsysteme etablieren
Im Zuge der Festlegung von Konfigurationseinheiten ist es auch notwendig
ein System zu definieren, in dem die Artefakte verwaltet werden. Hier werden sowohl die Speichermedien als auch die Verfahren und Werkzeuge fr
den Zugriff definiert.36

Baselines erstellen und freigeben


Die Baseline wird durch die Vergabe eines eindeutigen Bezeichners (an
einzelne Konfigurationseinheiten oder an eine Gruppe) zu einem definierten
Zeitpunkt dargestellt.37 Die erstellten Baselines knnen sowohl intern verwendet werden, als auch an den KundInnen ausgeliefert werden.38

33

Vgl. Software Engineering Institute (2010) S. 151.

34

Vgl. Software Engineering Institute (2010) S. 153; anders Verband der Automobilindustrie (2010)
S. 63.

35

Vgl. Software Engineering Institute (2010) S. 153 f.; anders Verband der Automobilindustrie
(2010) S. 63.

36

Vgl. Vgl. Software Engineering Institute (2010) S. 155; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

37

Vgl. Software Engineering Institute (2010) S. 156.

38

Vgl. Software Engineering Institute (2010) S. 156; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

13

1110387012 Sebastian Kopf

2.4.2 nderungen verfolgen und lenken


Die hier durchgefhrten Ttigkeiten verfolgen und lenken die Arbeitsergebnisse
unter Konfigurationsmanagement.39 Es werden hier die folgenden Aufgaben wahrgenommen:

nderungsantrge verfolgen
Bei der Verfolgung von nderungsantrgen werden nicht nur neue oder angepasste Anforderungen bercksichtigt, sondern auch Fehler in Arbeitsergebnissen. Die nderungsantrge werden beurteilt, um Folgen der nderung auf die Ergebnisse, das Budget und den Projektplan zu ermitteln.40

nderungsantrge lenken
Die Lenkung der nderungsantrge bezieht sich auf die dauerhafte Verfolgung der Konfigurationen sowie allenfalls der Freigabe einer neuen Version
und damit die Aktualisierung der Baseline.41

2.4.3 Integritt etablieren


Bei der Etablierung der Integritt der Baseline wird sichergestellt, dass die Integritt der Baseline auch durch die in Kapitel 2.4.1 und 2.4.2 angefhrten Ttigkeiten
erhalten bleibt.42 Hierfr fallen folgende Schritte an:

Aufzeichnungen zum Konfigurationsmanagement etablieren


Hierbei wird sichergestellt, dass die durchgefhrten nderungen auch dokumentiert und verfgbar sind.43

Konfigurations-Audits durchfhren
Konfigurations-Audits belegen die Einhaltung von spezifizierten Standards
oder Anforderungen, der Baselines und deren Dokumentation.44 Es ber-

39

Vgl. Software Engineering Institute (2010) S. 157.

40

Vgl. Software Engineering Institute (2010) S. 157; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

41

Vgl. Software Engineering Institute (2010) S. 158; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

42

Vgl. Software Engineering Institute (2010) S. 159; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

43

Vgl. Software Engineering Institute (2010) S. 159; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

44

Vgl. Software Engineering Institute (2010) S. 159; bereinstimmend Verband der Automobilindustrie (2010) S. 64.

14

1110387012 Sebastian Kopf

prft, ob die Baseline und die Dokumentation den Anforderungen entsprechen oder einen definierten Standard einhalten.45

2.5

Herausforderungen im Einsatz von Konfigurationsmanagement

Wenn sich eine Organisation dazu entscheidet Konfigurationsmanagement einzusetzen, entstehen hierbei eine Reihe von Herausforderungen. Hufig wird davon
ausgegangen, dass Konfigurationsmanagement sowohl alle Ressourcen verbraucht als auch die Kreativitt der MitarbeiterInnen unterdrckt. Es ist somit bei
jedem Einsatz von Konfigurationsmanagement die Angemessenheit zu prfen.46
Im Speziellen sind folgende Punkte bei der Definition des Umfangs von Konfigurationsmanagement zu beachten:47

Granularitt
Bei der Granularitt gilt es zu beachten, auf welcher Ebene nderungen an
den Artefakten erfolgen. Ein Beispiel hierfr wre die Granularitt von Anforderungen. Wird eine Anforderungsspezifikation verfasst, so ist es nicht
sinnvoll, das gesamte Dokument als einzelnes Konfigurationselement zu
definieren, wenn sich einzelne Anforderungen unabhngig von einander
ndern knnen. Ein weiteres Beispiel ist das Unterstellen eines gesamten
Subsystems als einzelnes Konfigurationselement, obwohl die zugehrigen
Quellcode-Module einzeln gendert werden knnen.

Grenzen
Das Festlegen der Konfigurationseinheiten sollte mittels einer bewusst erstellen Liste erfolgen. Damit wird das Problem umgangen, dass z.B. smtliche Erzeugnisse der Arbeitsablufe (wie Emails, Protokolle,...) oder auch
gar keine Artefakte unter Konfigurationsmanagement gesetzt werden.

Zeitpunkt
Es ist wichtig, den richtigen Zeitpunkt auszuwhlen, um ein Artefakt unter
Konfigurationsmanagement zu stellen. Ab dem Zeitpunkt, an dem ein Artefakt unter Konfigurationsmanagement steht, mssen smtliche nderungen
durch die Ttigkeiten des Konfigurationsmanagements (siehe Kapitel 2.4)

45

Vgl. Software Engineering Institute (2010) S. 159.

46

Vgl. Hass (2003) o.S.

47

Vgl. Hass (2003) o.S.

15

1110387012 Sebastian Kopf

berwacht werden. Aufgrund dessen sollten die Bedrfnisse nach Sicherheit und Information, welche durch Konfigurationsmanagement gestillt werden, gegen den Aufwand abgewogen werden.
Bei der Beurteilung der Aufwnde und auch der Vorteile sollte bercksichtigt werden, dass diese hufig ungleich verteilt sind. Die Vorteile treten oft an anderen
Stellen zu Tage, als an denen, wo die Aufwnde anfallen.48
Insgesamt kann gesagt werden, dass eine angemessene Implementierung von
Konfigurationsmanagement, in einem sinnvollen Umfang, Aufgaben fr alle Beteiligten erleichtert.49

48

Vgl. Hass (2003) o.S.

49

Vgl. Hass (2003) o.S.

16

1110387012 Sebastian Kopf

3
2

Versionsverwaltungssysteme
C H A P T E R 1 N G E T T I N G S T A R T E D

Wie in Kapitel 1.6 erwhnt, behandelt die Versionsverwaltung das Verwalten aller
Versionen der im Versionsverwaltungssystem abgelegten Artefakte (z.B. Dateien).

Local Version Control Systems

Versionsverwaltungssysteme sind meist darauf ausgelegt, Klartext-Dateien zu


Many peoples version-control method of choice is to copy files into another directory (per-

haps a time-stamped
directory,in
if theyre
approach is very commonZeilen
becausehinzugefgt
its
verarbeiten.
Dabei werden
jeder clever).
neuenThis
Klartext-Dateiversion
so simple, but its also incredibly error prone. Its easy to forget which directory youre in and

oder
entfernt.write
Binre
haben
keine
Klartext-Zeilen,
diese Art der
accidentally
to the Dateien
wrong file or
copy over
files when
you dont meanwodurch
to.
To deal with this issue, programmers long ago developed local VCSs that had a simple

Verarbeitung
nicht mglich ist. Werden binre Dateien mit Klartext basierten Verdatabase that kept all the changes to files under revision control (see Figure 1-1).
One of the more popular
VCS toolsso
waswird
a system
which
is still distributed
with
sionsverwaltungstools
verwaltet,
fr called
jede rcs,
neue
Version
die komplette
Datei
many computers today. Even the popular Mac OS X operating system includes the n_o com-

neumand
gespeichert.
Auch
viele
Funktionalitten
eines
when you install the
Developer
Tools. andere
This tool basically
works by keeping patch
sets Klartext(that is, the differences between files) from one change to another in a special format on disk;

50
Versionsverwaltungssystems
sind fr
Dateien
verfgbar.
it can then re-create what any file looked
like Binre
at any point
in time nicht
by adding
up all the patches.

Figure 1-1. Local version control diagram


Darstellung
4: Einfache Darstellung einer versionierten Datei

51

Darstellung 4 zeigt eine einfache Abbildung einer versionierten Datei. Hierbei


wird die Versionsdatenbank gezeigt, in welcher alle bisherigen Versionen der Datei gespeichert sind. Der Checkout bezeichnet die auerhalb der Versionsdatenbank vorhandene Datei. Diese lokale Datei kann, im Gegensatz zu den verschiedenen Versionen in der Versionsdatenbank, beliebig editiert werden.

50

Vgl. Berlin/Rooney (2006) S. 15.

51

Chacon (2009) S. 2.

17

1110387012 Sebastian Kopf

Funktionalitt von Versionsverwaltungssystemen


Ein Versionsverwaltungssystem verwaltet alle darin gespeicherten Artefakte (z.B.
Dateien) und ermglicht es, auf alle verfgbaren Versionen zuzugreifen. Diese
zentrale Verwaltung, in der die Originalkopie aller Versionen abgelegt ist, wird
auch Repository genannt.52 Im Speziellen sind folgende Operationen mglich:
Operation

Beschreibung

Sicherung und Wiederherstellung

Dateien werden zu einem bestimmten


Zeitpunkt gespeichert und es ist mglich, zu jedem gespeicherten Zeitpunkt
zurck zu gehen.

Synchronisation

AnwenderInnen knnen Dateien gemeinsam benutzen und dabei auf dem


aktuellsten Stand bleiben.

Kurzfristiges Rcksetzen

Wurde eine Datei beispielsweise gelscht oder fehlerhaft verndert, kann


mittels Versionsverwaltung auf die letztbekannte korrekte Version zurckgestiegen werden.

Langfristiges Rcksetzen

Im Falle eines lnger zurckliegenden


Fehlers kann mittels Versionsverwaltung die alte Version wieder hergestellt
und gleichzeitig berprft werden, welche nderungen zum damaligen Zeitpunkt erfolgten.

nderungen nachverfolgen

Alle nderungen an Dateien knnen mit


einer

nderungsmeldung

versehen

werden. Diese Meldung wird im Versionsverwaltungssystem abgelegt. Damit


wird es mglich, die Entwicklung der
Datei zu berprfen.

52

Vgl. Mason (2006) S. 9.

18

1110387012 Sebastian Kopf

Operation

Beschreibung

EigentmerInnenschaft festhalten

Jede durchgefhrte nderung wird mit


der durchfhrenden Person verknpft.
Dabei ist auch eine Zugriffskontrolle fr
die BenutzerInnensteuerung mglich.

Selbstversicherung

Im Falle von greren Anpassungen an


Dateien knnen vorlufige nderungen
in einer isolierten Umgebung durchgefhrt werden. Erst nach berprfung
der Richtigkeit werden die nderungen
mit dem zentralen Repository zusammengefhrt.

Versionsvergleich

Durch Vergleich knnen die Unterschiede zwischen zwei Versionen (Datei, Verzeichnis) gefunden und angezeigt werden.

Konfliktanzeige

Wird ein Artefakt von verschiedenen


BenutzerInnen

gleichzeitig

gendert,

knnen bei der Zusammenfhrung Konflikte auftreten. Dabei wird angezeigt,


falls an der selben Stelle nicht deckungsgleiche nderung durchgefhrt
werden.
Sperre

Um Konflikte zu vermeiden oder nur


bestimmten Personen Zugriff zu gewhren, knnen Artefakte gesperrt (und
entsperrt) werden.

Tabelle 1: Operationen von Versionsverwaltungssystemen

53

In Fehler! Verweisquelle konnte nicht gefunden werden. wird beispielhaft ein vereinfachter nderungsworkflow des Versionsmanagementtools Git gezeigt. Dabei
53

Vgl. Azad (2007) online.

19

1110387012 Sebastian Kopf

wird durch den/die VerwalterIn der Steuerungsdaten eine nderungen im lokalen


Repository vorgenommen. Diese nderung wird zum Review an eine Genehmigungsstelle gesendet. Wird die nderung akzeptiert, erfolgt eine bernahme in
das zentrale Repository. Wird die nderung abgelehnt, wird dies an die anfordernde Stelle zurckgesendet.

Darstellung 5: Vereinfachter nderungsworkflow von Steuerungsdaten mit Git

54

Im Kontext des Konfigurationsmanagements ist ein Versionsverwaltungssystem


damit dazu in der Lage, die Anforderungen bezglich der nderungsverfolgung
abzudecken.

54

Eigene Darstellung nach Quelle: Chacon (2009) S. 108.

20

1110387012 Sebastian Kopf

Datenbankbasierte Verwaltung von BetreiberInnenspezifischen Steuerungsdaten

Dieses Kapitel gibt einen berblick ber die Ausgangssituation bezglich der Verwaltung von Steuerungsdaten innerhalb einer Datenbank. Es werden die Grundlagen von Datenbanken erklrt und in Folge dargelegt, wie die datenbankbasierte
Verwaltung von Steuerungsdaten die Anforderungen des Konfigurationsmanagements erfllt.

4.1

Grundlagen Datenbanken

R. A. Elmasri und S. B. Navathe definieren eine Datenbank als:


[...] eine Sammlung von Daten, die einen Ausschnitt der realen Welt
beschreiben. Unter Daten verstehen wir bekannte Tatsachen, die
aufgezeichnet werden knnen und eine implizite Bedeutung haben.55
Dabei beschreibt eine Datenbank einen definierten Ausschnitt der realen Welt. Auf
diese Daten zugreifen bzw. sie zu verndern ist fr einen bestimmten Personenkreis von Interesse.56
Werden diese Datenbanken computergesttzt verwaltet, so spricht man von einem
Datenbankmanagementsystem (DBMS). In diesem DBMS werden die Datentypen,
die Struktur und Einschrnkungen der Daten definiert. Ein DBMS bietet weiters die
Mglichkeit der Manipulation und Abfrage dieser Daten. 57
Das Resultat dieser Definitionen ist ein Datenmodell.58 Bei der Art von Datenmodellen gibt es folgende Unterscheidungen:59

Ein Relationales Datenmodell reprsentiert das Modell als Sammlung von


Relationen zwischen den Daten.60

Satzbasiertes Datenmodelle stellen ausschlielich Datenstrukturen dar

Ein Objektdatenmodell bietet Eigenschaften wie Objektidentitten, benutzerdefinierte Datentypen, Vererbung, Klassen und komplexe Objekte.61

55

Elmasri/Navathe (2009) S. 18.

56

Vgl. Elmasri/Navathe (2009) S. 18.

57

Vgl. Elmasri/Navathe (2009) S. 19.

58

Vgl. Elmasri/Navathe (2009) S. 41.

59

Vgl. Elmasri/Navathe (2009) S. 41.

60

Vgl. Elmasri/Navathe (2009) S. 134.

21

1110387012 Sebastian Kopf

Weiters gibt es in lteren Systemen noch Netzwerk- und hierarchische Datenmodelle. 62

4.2

Funktionsweise von Datenbanken

Eine Datenbank kann eine Reihe von Operation ausfhren. In der Folge werden
einige Operationen erklrt, um die Begriffe Commit und Transaktion erlutern zu
knnen:

Die Select-Operation ist die Operation, mit der eine Teilmenge der in der
Datenbank verwalteten Daten ausgewhlt werden.63

Eine Insert-Operation erzeugt einen neuen Datensatz in den angegeben


Datenbanktabellen.64

Update-Operationen dienen der Vernderung von bereits bestehenden Daten.65

Eine Delete-Operation fhrt die Lschung von verwalteten Daten durch.66

Die aufgelisteten Operationen fhren nderungen auf der Datenbank durch. Zur
Sichtbarmachung dieser nderungen ist es notwendig, ein DBMS explizit dazu
aufzufordern. Dies bedeutet, dass die nderungen in der Datenbank persistent
festgeschrieben werden. Diese Operation wird als Commit bezeichnet.67
Im Rahmen eines Commits gibt es bei DBMS ein sogenanntes TransaktionsKonzept. Als Transaktion werden eine Sammlung von Anweisungen (z.B. ein Insert und ein Update) bezeichnet, die gemeinsam durchgefhrt werden.68 Diese
Transaktionen erfllen die folgenden Eigenschaften: 69

Atomaritt: Es wird sichergestellt, dass alle Anweisungen innerhalb einer


Transaktion erfolgreich ausgefhrt werden. Schlgt dies fehl, so wird die
Transaktion abgebrochen. Alle bis zu diesem Zeitpunkt durchgefhrten nderungen werden wieder in ihren Ursprungszustand (vor dem Beginn der

61

Vgl. Gnther (1998) S. 111.

62

Vgl. Elmasri/Navathe (2009) S. 41.

63

Vgl. Elmasri/Navathe (2009) S. 150.

64

Vgl. Elmasri/Navathe (2009) S. 212.

65

Vgl. Elmasri/Navathe (2009) S. 214.

66

Vgl. Elmasri/Navathe (2009) S. 214.

67

Vgl. tutorialpoint (2014) online.

68

Vgl. tutorialpoint (2014) online.

69

Vgl. tutorialpoint (2014) online.

22

1110387012 Sebastian Kopf

Transaktion) zurckgesetzt. Dieser Rcksetzungsvorgang wird auch Rollback genannt.

Konsistenz: Es wird sichergestellt, dass die innerhalb der Datenbank definierten Regeln bzw. Relationen nach einem Commit erhalten bleiben.

Isolation: Ist die Fhigkeit, dass Transaktionen unabhngig und transparent


von einander durchgefhrt werden knnen.

Dauerhaftigkeit: Stellt sicher, dass die Ergebnisse der Transaktion die


commitiert wurde, auch persistent bleiben.

4.3

Konventionelle Datenbanken

Eine konventionelle Datenbank (im Unterschied zu temporalen Datenbanken, siehe Kapitel 4.4) bieten keinen natrlichen Mechanismus, um die darin gespeicherten Daten zu versionieren. Die Datenbank verndert sich durch eine Transaktion
von einem konsistenten Zustand zum nchsten, whrend der bisherige Zustand,
nach dem Commit der Transaktion, verworfen wird.70
Es ist jedoch auch in einer konventionellen Datenbank mglich, eine zeitsensitive
Darstellung der Daten durchzufhren. Um dies umzusetzen ist es notwendig, im
Design und der Umsetzung sowohl in der Applikation, welche die Datenbank verwendet, als auch der Zugriffsschicht, welche die Daten zur Verfgung stellt (siehe
Fehler! Verweisquelle konnte nicht gefunden werden.), die Versionierung von
Steuerungsdaten zu bercksichtigen. Eine solche Implementierung von zeitsensitiven Daten fhrt, aufgrund der speziellen Designs und Umsetzungen im Rahmen
der Entwicklung, zu erhhten Aufwnden.

4.4

Temporale Datenbanken

Temporale Datenbanken sind Datenbanken, die in der Lage sind, zeitvernderliche Daten zu verwalten.71 Hierbei gibt es zwei unterschiedliche Interpretationen
von Zeit:72

Valid Time ist jene Zeitperiode, innerhalb derer die gespeicherten Fakten
im Bezug auf die echte Welt gltig sind.

70

Vgl. Salzberg/Tsotras (1999) S. 158.

71

Vgl. Salzberg/Tsotras (1999) S. 159.

72

Vgl. TimeConsult (2005) online.

23

1110387012 Sebastian Kopf

Transaktionszeit ist jene Zeitperiode, innerhalb derer die Fakten in der Datenbank gespeichert werden.

Aus diesen Sichtweisen auf Zeit ergeben sich unterschiedliche Formen von temporalen Datenbanken:73

Historische Datenbanken speichern Daten im Hinblick auf die echte Durchfhrungszeit.

Eine Rollback-Datenbank speichert die Daten im Hinblick auf die Transaktionszeit (der Datenbank).

Eine bitemporale Datenbank bercksichtigt bei der Verarbeitung der Daten


sowohl die Transaktionszeit als auch die echte Durchfhrungszeit.

Um diese zeitsensitiven Datenstze abzufragen, sind spezielle Mechanismen notwendig, die auch in den SQL-Standard 2011 Eingang gefunden haben.74
Wie bereits bei konventionellen relationalen Datenbanken ist es auch bei temporalen Datenbanken notwendig, spezielle Implementierungen in der Zugriffsschicht
und den Applikationen durchzufhren, um diese zeitsensitiven Daten abzufragen.
Durch die in Bordmittel vorhandenen Mglichkeiten der Bercksichtigung von zeitsensitiven Daten ist der Aufwand bei temporalen Datenbanken im Vergleich zu
konventionellen relationalen Datenbanken geringer.

4.5

Anforderungen des Konfigurationsmanagements von betreiberInnenspezifischer Software an datenbankbasierte


Verwaltungen von Steuerungsdaten

BetreiberInnenspezifische Steuerungsdaten sind Daten, die das Verhalten einer


Software steuern und verndern. Sie knnen in einer BetreiberInnen-Installation
der Software von einem/einer AnwenderIn verndert werden. Bei datenbankbasierter Software (oder Datenbanksystemen) werden die Daten ber die Funktionen
der Applikation in einer Datenbank gespeichert (siehe Fehler! Verweisquelle konnte nicht gefunden werden.).75

73

Vgl. TimeConsult (2005) online.

74

Vgl. Kulkarni/Michels (2012) S. 34

75

Vgl. Elmasri/Navathe (2009) S. 20.

24

1110387012 Sebastian Kopf

Darstellung 6: Applikationsarchitektur einer datenbankbasierten Software

76

Vernderungen dieser Steuerungsdaten verndern das Verhalten der Software


und damit auch die darin ablaufenden Prozesse. Sind diese Prozesse von hoher
Relevanz fr das Geschft, ist auch das Risiko solcher nderungen gro.
Das Konfigurationsmanagement stellt nun verschiedene Anforderungen an den
nderungsprozess von Steuerungsdaten. Wie bereits in Kapitel 2.3 erwhnt, ist
Konfigurationsmanagement notwendig, um unter anderem:

Die Nachvollziehbarkeit der nderung zu gewhrleisten

Verantwortlichkeiten zur Quellen zurckzuverfolgen

Keine unerwnschte nderungen durchzufhren und

ein schnelles und einfaches Auditing zu haben.

ITIL Service Transition 2011 fhrt dazu noch weitere Anforderungen an:77

Die Sicherstellung des kontrollierten Einsatzes whrend des gesamten Lebenszyklus

Belegen, managen und beschtzen der nderungselemente whrend des


gesamten Lebenszyklus durch das Arbeiten mit nderungsmanagement,

76

Datadisk (2014) online.

77

Vgl. Cabinet Office (2011) S. 90.

25

1110387012 Sebastian Kopf

sodass nur autorisierte Elemente durch autorisierte Anpassungen erfolgen


knnen.

4.6

Erfllung der Anforderungen des Konfigurationsmanagements von Steuerungsdaten in datenbankbasierten Applikationen

Wie bereits in den Kapitel 4.3 und 4.4 beschrieben, ist fr die zeitsensitive Verwaltung von Daten zustzlicher Implementierungsaufwand innerhalb der verwendeten Applikation notwendig. Ohne diese Aufwnde kann den Anforderungen des
Konfigurationsmanagements bezglich des kontrollierten Einsatzes ber den gesamten Lebenszyklus nicht entsprochen werden (siehe Kapitel 4).
Den weiteren Anforderungen bezglich belegen, managen und beschtzen der
nderungselemente whrend des gesamten Lebenszyklus kann aber ohne weitere Funktionalitten innerhalb der Applikation nicht entsprochen werden. Eine rein
datenbankbasierte Protokollierung wie beispielsweise durch automatisches Auslsen der Speicherung von nderungsdatenstzen ist nicht ausreichend, da diese
einem/einer AnwenderIn nicht in der Benutzeroberflche der Applikation dargestellt werden.
Um einen kontrollierten und nachvollziehbaren Zugriff im Sinne eines nderungsmanagement zu ermglichen, wrden beispielsweise Zugriffskontrollen und Protokollierungen notwendig sein sowie eine Mglichkeit, einen nderungsworkflow
(z.B. Anfordern, genehmigen und durchfhren) darzustellen.
Damit ist es nicht mglich, Steuerungsdaten einer datenbankbasierten Applikation
entsprechend den Anforderungen von Konfigurationsmanagement zu verwalten.

26

1110387012 Sebastian Kopf

Alternative Verwaltungsmglichkeiten von betreiberInnen-spezifischen Steuerungsdaten

Als Alternative zur datenbankbasierten Speicherung (siehe Kapitel 4) besteht die


Mglichkeit, diese Daten in Klartext-Dateien (siehe Kapitel 3) abzulegen. In diesem Kapitel werden die verschiedenen Mglichkeiten zur Verwaltung von Steuerungsdaten erlutert und auf den Erfllungsgrad der Anforderungen von Konfigurationsmanagement untersucht.

5.1

Auszeichnungssprache Extensible Markup Language (XML)

XML ist eine Meta-Auszeichnungssprache fr Textdokumente. Dabei werden Daten als Zeichenketten festgehalten und mit beschreibenden Textauszeichnungen
umgeben.78 Als Textdokument sind XML-Dokumente dazu geeignet, in Versionsverwaltungssoftware (siehe Kapitel 3) verwaltet zu werden.

5.1.1 Grundlagen von XML


XML entwickelte sich aus im Jahre 1969 entwickelten Standard Generalized
Markup Language (SGML) und aus Hypertext Markup Language (HTML). SGML
wurde entwickelt, um Dokumentenstrukturen zu beschreiben. HTML wurde entwickelt als Beschreibungssprache von webbasierten Dokumenten zur Darstellung
von Bildern, Texten und Links auf Webseiten.79
Da bei HTML die mglichen Elemente fix vorgegeben sind, war dies fr eine weitere Entwicklung des Webs zu unflexibel. Auch der Informationsverlust (z.B. gehen
Attributsbeschreibungen von Daten verloren) bei Datendarstellungen in HTML aus
einer z.B. Datenbanktabelle ist als groer Nachteil zu sehen.80
Aus diesen Grnden wurde XML als flexible Beschreibungssprache entwickelt. Sie
ermglicht eine individuelle Definition der Elemente und Struktur. Dateninhalte
knnen wie in Datenbanktabellen ber ein beschreibendes Element definiert werden.81 In Fehler! Verweisquelle konnte nicht gefunden werden. ist ein Beispiel einer XML-Datei aus der Fehlerverwaltungs-Software Mantis-Bugtracker abgebildet.

78

Vgl. Harold/Means (2004) S. 3.

79

Vgl. Vonhoegen (2007) S. 28.

80

Vgl. Vonhoegen (2007) S. 29.

81

Vgl. Vonhoegen (2007) S. 28.

27

1110387012 Sebastian Kopf

Darstellung 7: Beispiel eines XML

82

5.1.2 Aufbau von XML


Trotz der flexiblen Definitionsmglichkeiten der Struktur gibt es zwei vorgegebene
Elemente in der Grundstruktur:

Prolog: Im Prolog werden optional Basisdaten ber das XML festgehalten.


Es wird definiert, welche Version der XML-Sprache und nach welcher Zeichensatzkodierung das Dokument erstellt wird.83 Eine Zeichensatzkodierung definiert die mglichen maschinenlesbaren Zeichenkombinationen.84
Weiters besteht die Mglichkeit, eine Definition des Dokumententyps

82

XML-Export aus der Fehlerverwaltungssoftware Mantis Bug-Tracker

83

Vgl. Fawcett u.a. (2012) S. 29.

84

Vgl. Techterms (2010) online.

28

Die blo formale Prfung auf Wohlgeformtheit kann noch ergnzt werden durch
eine Prfung auf Gltigkeit. Dabei geht es um die Frage, ob das Dokument auch
1110387012
SebastianInformationen
Kopf
alle geforderten
enthlt, und zwar in der richtigen Reihenfolge.
Ein Projekt in unserem Beispiel kann zwar mehr als einen Autor haben, aber kein
(Document
Type Autor
Definition,
oder
eines XML
Projekt
kommt ohne
aus. DTD)
Um die
Elemente
und Schemas
Attributevorzunehund ihre Reihen85
folge men.
fr ein
Dokument genau festzulegen, kann dem XML-Dokument ein entsprechendes
Datenmodell
zugeordnetistwerden,
dem der
seine
Gltigkeit dann
Wurzelelement:
Das Wurzelelement
das erstean
Element
Datenstrukgemessen werden kann.
86
tur. Es schliet alle anderen mglichen Elemente in sich ein.

Mit dem Werkzeug, das wir im Verlauf dieses Buchs noch hufiger verwenden
5.1.3 XML Dokumenttyp Definition und XML-Schema
werden XMLSpy kann ein solches Datenmodell auch nachtrglich aus einem
Eine
DTD
und ein XML-Schema
sind in einer
formalen
Syntax
geschrieben
und
schon
vorliegenden
XML-Dokument
erzeugt
werden.
Dabei
gibt es hauptschlich
beschreiben,
welche Elemente
in demeine
XMLDTD
vorkommen
knnen und welche Inhal- oder
zwei Mglichkeiten.
Sie knnen
eine Dokumenttyp-Definition
87
te
und
Attribute
dieses
Element haben
kann.dieser
ein
XML
Schema
erzeugen.
Die Rolle
beiden Datenmodelle wird ausfhrlichBasis
in Kapitel
Dokumenttypen
und Validierung,
DTD fr unser
Auf
eines 3,
DTD
oder eines XML-Schemas
knnen behandelt.
Programme Eine
automatisch
Beispiel sieht
zum
so aus:
berprfen,
ob das
zuBeispiel
verarbeitende
XML den Vorgaben des Modelles entspricht.

88

Darstellung
Beispiel
von Projektdaten
Abbildung8:1.4
Eineeines
DTDDTD
fr die
Projektdaten

Das gleiche Datenmodell in Form eines XML Schemas zeigt die nchste Abbildung.

Fehler! Verweisquelle konnte nicht gefunden werden. zeigt ein Beispiel eines
DTD von Projektdaten. Die gleichen Inhalte sind in Fehler! Verweisquelle konnte
nicht gefunden werden. in Form eines XML-Schemas abgebildet.

24

85

Vgl. Vonhoegen (2007) S. 53.

86

Vgl. Vonhoegen (2007) S. 54.

87

Vgl. Harold/Means (2004) S. 28.

88

Vonhoegen (2007) S. 24.

29

aus. Der Modelldesigner kann sein Modell auch gleich in dieser grafischen Form
entwerfen. Das erleichtert es, den berblick ber die Hierarchie der Informati1110387012 Sebastian Kopf
onseinheiten zu behalten, die er konstruiert.

Darstellung
9: 1.5
XML-Schema
derSchema,
Projektdaten
Abbildung
Das XML
das der DTD entspricht
89

5.1.4 XML-Daten
Die XML-Daten enthalten alle Elemente, Attribute und deren Ausprgungen. Das
Wurzelelement folgt auf den Prolog (siehe Kapitel 5.1.2). Innerhalb des Wurzelelements sind alle Daten des XML in Baumform (siehe Darstellung 10) enthalten.90

Abbildung 1.6

Das XML Schema als Diagramm in XMLSpy

Die Gltigkeit eines Dokuments kann in XMLSpy immer sofort geprft werden,
weil ein validierender Parser integriert ist. Der Internet Explorer ignoriert dagegen normalerweise die Frage der Gltigkeit, zeigt also auch ungltige Dokumente
solange an, als sie wohlgeformt sind.
89
Vonhoegen (2007) S. 25.

90

Vgl. Vonhoegen (2007) S. 54.

30

25

Auer fr das Wurzelelement gibt es folglich fr jedes andere Element genau ein
Elternelement, whrend das Wurzelelement und jedes seiner Kindelemente wie1110387012
Sebastian Kopf
der weitere Kindelemente
zum Inhalt haben knnen. Es sind beliebig tiefe Verschachtelungen erlaubt.
kontakte

kontakt

name

ort

Abbildung 2.2

kontakt

mail

name

Baumstruktur eines Dokuments

mail

ort

Darstellung 10: Baumstruktur eines XML-Kontaktdokuments

91

Diese hierarchische Baumstruktur kann durch einen Graphen dargestellt werden,


Der
hier gezeigte Baum kann auch ein relationales Datenmodell darstellen.92 Sodessen Knoten durch gerichtete Kanten verbunden sind und dessen Wurzelkno-

mit
istkeine
es dieser
auch Kanten
mglich,
Daten einer
relationalen
Datenbank
ten fr
der Endknoten
ist. Dieser
Graph enthlt
folglich auch in einem XML zu
keine Zyklen.

speichern.

Der Baum ist durch die sequenzielle Abfolge der Elemente im XML-Dokument
implizit Anwendungsgebiete
geordnet. Natrlich kann auchvon
eine ganz
flache Struktur wie eine relati5.1.5
XML
onale Datenbanktabelle in XML ausgedrckt werden, aber die besonderen Strken des
Modells
kommen
dann zur Geltung,
es um tiefgestaffelte
DatenXML
findet
hufig
Anwendung
in der wenn
Darstellung
und Speicherung
strukturen geht.

von Daten.93 In

der Folge werden diese Anwendungsgebiete aufgelistet:


2.1.8

Dokumenten-zentriertes
Start-Tags und End-Tags XML: Wird verwendet, um eine grobe Struktur der

Jedes Element
jeweils
durch ein
und einanzureichern.
End-Tag begrenzt.Weiters
Das
Inhaltewird
(z.B.
Kapitel)
mitStart-Tag
Metadaten
wird es dazu
XML-Dokument vermischt also die darin enthaltenen Inhalte mit Informationen
verwendet,
um
mehrere
zu bedienen
ber diese
Inhalte, oder
man
kann auchPublikationskanle
sagen, es mischt Informationen
und und die Inhalte

dabei wiederzuverwenden.94
54

Konfigurations-Dateien: Zur Speicherung von Konfigurationsdaten verwenden aufgrund der einfachen Analysemglichkeiten fast alle modernen Systeme XML.95

Webservices: Ein Webservice ist ein Dienst, der im Web von beliebigen
Anwendungen benutzbar ist.96 Im Rahmen der Kommunikation von Webservices wird XML als einfacher Weg zur plattformbergreifenden Serialisierung von Objekten verwendet.97

91

Vonhoegen (2007) S. 54.

92

Vgl. Vonhoegen (2007) S. 54.

93

Vgl. Fawcett u.a. (2012) S. 14.

94

Vgl. Fawcett u.a. (2012) S. 13 f.

95

Vgl. Fawcett u.a. (2012) S. 14.

96

Vgl. IT Wissen (2014) online.

97

Vgl. Fawcett u.a. (2012) S. 14.

31

1110387012 Sebastian Kopf

Web Inhalte: XHTML (eine XML Version von HTML) ist eine Variante, Webinhalte wiederverwendbar zu machen und auch eine Mglichkeit zur Reduktion der verwendeten Bandbreite und Speicher.98

Dokumentenmanagement: Hier wird XML zur Verwaltung der Metadaten


(z.B. AutorIn, Erstellungsdatum oder nderungen) von Dokumenten verwendet.

Interoperabilitt im Geschftsverkehr: Das Definieren und Abstimmen eines


XMLs zum Austausch von Daten zwischen verschiedenen Applikationen, ist
einfacher als die Verarbeitung eines applikationsspezifischen Formates.99

5.1.6 Erfllung der Konfigurationsmanagement-Anforderungen von


Steuerungsdaten in datenbankbasierten Applikationen verwaltet in
XML
XML bietet sowohl die Mglichkeit zur Abbildung von relationalen (siehe Kapitel
5.1.4), als auch von objektorientierten Datenstrukturen.100
Werden nun die Steuerungsdaten zum Zeitpunkt Null (z.B. Inbetriebnahme) mittels
einer Exportschnittstelle in ein XML-Datei geschrieben, ist das Ergebnis ein Textdokument. Auch ein Import dieser XML ist wieder mittels Schnittstelle mglich.
Dieses Textdokument kann ber die in Kapitel 3 beschriebene Versionsverwaltungssoftware verwaltet werden.
Durch die Versionsverwaltungssoftware wird prinzipiell die Fhigkeit geschaffen:

Zugriffskontrollen durchzufhren

nderungen nachverfolgen

Historien aller Mutationen zu fhren

nderungsworkflows zu schaffen

Dadurch kann den Anforderungen des Konfigurationsmanagements bezglich des


kontrollierten Einsatzes ber den gesamten Lebenszyklus sowie dem Belegen,
Managen und Beschtzen der nderungselemente whrend des gesamten Lebenszyklus entsprochen werden.

98

Vgl. Fawcett u.a. (2012) S. 15.

99

Vgl. Fawcett u.a. (2012) S. 12.

100

Vgl. Fawcett u.a. (2012) S. 14.

32

1110387012 Sebastian Kopf

5.2

Domain Specific Language

Eine Domain Specific Language (DSL) ist im Gegensatz zu einer General Purpose
Language eine Programmiersprache mit limitierten Ausdrucksmglichkeiten, die
auf eine bestimmte Domain (Problemgebiet) fokussiert ist.101 Eine General Purpose Language ist eine Programmiersprache mit der es mglich ist, alle Arten von
Problemstellungen zu lsen.102
M. Fowler definiert die Domain Specific Language wie folgt:
A domain-specific language (DSL) is a programming language or
executable specification language that offers, through appropriate
notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.103
Eine DSL hat vier Kernelemente:104

Es ist eine Sprache, die von Menschen benutzet wird, um einen Computer
zu instruieren, etwas zu tun.

Die Sprache sollte flssig sein, damit die Ausdrucksstrke nicht nur von
einzelnen Ausdrcken, sondern vom gesamten Aufbau der Konstrukte
kommt.

Die DSL soll im Gegensatz zu General Purpose Languages, nur jenes Minimum an Features haben, das bentigt wird, um die definierte Domain abzubilden.

Eine beschrnkte Sprache ist nur dann ntzlich, wenn sie einen klaren Fokus auf eine beschrnkte Domain hat.

Die Domain Specific Language wird durch einen speziellen Compiler bei der Ausfhrung durch Funktionen einer General Purpose Language interpretiert und ausgefhrt.105

5.2.1 Grundlagen von DSL


Bei DSL wird zwischen internen und externen DSL unterschieden.

101

Vgl. Fowler (2010) o.S.

102

Vgl. PCmag (2014) online.

103

Van Deursen u.a. (2000) o.S.

104

Vgl. Fowler (2010) o.S.

105

Vgl. Fowler (2010) o.S.

33

1110387012 Sebastian Kopf

Interne DSL:
Eine interne DSL ist durch die Syntax einer General-Purpose Language reprsentiert. Es wird dabei eine Teilmenge der General-Purpose Language verwendet, um
einen kleinen Bestandteil des Gesamtsystems abzubilden. Eine interne DSL muss
im Gegensatz zu einer externen DSL nicht von einem speziellen Compiler
bersetzt werden, um ausfhrbar zu sein.106
Sie ist aufgrund dessen, dass sie eine General Purpose Language als Basis verwendet, ohne weitere Kompilierung direkt in der Ausfhrungsumgebung (z.B. Java
Virtual Machine) dieser Sprache einsetzbar.
Das Resultat der Definition einer internen DSL ist eine mageschneiderte Sprache. Ein Beispiel hierfr ist das Entwicklungsframework Ruby on Rails, das die
General Purpose Language Ruby als Grundlage verwendet. 107
Externe DSL:
Eine externe DSL ist eine Domain Specific Language, die eine von der General
Purpose Language mit der sie zusammenarbeitet (Basissprache) unabhngige
Syntax hat. Es wird also eine eigene Syntax verwendet, die nur spezifisch fr die
definierte Domain verwendet wird.108

Ein Beispiel fr eine externe DSL im Kontext des Wertpapierhandels:109


buy 500.shares.of("SUNW").at(10.14)
sell 350.shares.of(AAPL").at(179.30)
show_transactions "AAPL"
print_portfolio_value

In diesem Beispiel ist die Syntax im Zusammenhang mit dem Fachgebiet verstndlich. Die Anweisungen, die in der externen DSL verfasst werden, mssen
durch einen Prozess in die Basissprache bersetzt werden, der einer Kompilie-

106

Vgl. Fowler (2010) o.S.

107

Vgl. Fowler (2010) o.S.

108

Vgl. Fowler (2010) o.S.

109

Spradlin (2008) online.

34

1110387012 Sebastian Kopf

rung gleicht. Dieses Zwischenergebnis kann im Anschluss in der Ausfhrungsumgebung der Basissprache ausgefhrt werden. 110

5.2.2 Anwendungsgebiete von DSL


Domain Specific Language bietet verschiedene Anwendungsmglichkeiten innerhalb des Softwarelebenszyklus.
In der Folge werden diese Anwendungsgebiete kurz erlutert:

Applikations Domain DSL: Es handelt sich um eine DSL, die das Kerngeschft der Businesslogik (u.a. Steuerungsdaten) der Applikation beschreibt.
Diese Art von DSL ist dafr vorgesehen, von Domain Experten (z.B. AnwendernInnen) eingesetzt zu werden. Die Anforderung an die SprachNotation sind dadurch strenger (z.B. Einfachheit der Bedienung und Werkzeug-Untersttzung). Applikations Domain DSL bentigen auch im Vergleich zu anderen DSL mehr Aufwand, da die Domain zuerst verstanden,
strukturiert und von den Domain ExpertInnen wieder erlernt werden
muss.111

Anforderungsanalyse DSL: Diese DSL fokussiert nicht auf automatische


Quellcode-Generierung, sondern auf eine przise, komplette und prfbare
Beschreibung der Anforderungen. Die Nachvollziehbarkeit zwischen den
Artefakten ist wichtig. 112

DSL fr Analysen wird zur Prfung und Analyse von Belegen verwendet.
Die Formalismen der DSL ermglichen eine formale Prfung von z.B. komplexen technischen Systemen.113

DSL als Hilfsmittel: Hier werden DSL als Hilfsmittel fr EntwicklerInnen


eingesetzt. Es wird damit ein kleiner Teil des Softwareentwicklungsprozesses automatisiert. Ein Beispiel hierfr ist die Generierung von Datenbanktabellen auf Basis von Klassendiagrammen wie in Ruby on Rails.114 Klas-

110

Vgl. Voelter (2013) S. 51

111

Vgl. Voelter (2013) S. 49.

112

Vgl. Voelter (2013) S. 49.

113

Vgl. Voelter (2013) S. 49 f.

114

Vgl. Voelter (2013) S. 47.

35

1110387012 Sebastian Kopf

sendiagramme beschreiben die Objekte und die Struktur der Information


die von der Applikation verwendet werden.115

Architektur DSL: Ein groes Anwendungsgebiet von DSL ist die Beschreibung von Architekturelementen (z.B. Komponenten, Schnittstellen oder
Nachrichten) mithilfe von DSL.116

5.2.3 Erfllung der Konfigurationsmanagement-Anforderungen von


Steuerungsdaten in datenbankbasierten Applikationen verwaltet in
DSL
DSL bietet hnlich wie XML (siehe Kapitel 5.1.6) die Mglichkeit, Steuerungsdaten in Form von Klartext, im Fall von DSL eine Art von Quellcode darzustellen.
AnwenderInnen (=Domain ExpertInnen) sind dadurch in der Lage, die Pflege der
Steuerungsdaten vorzunehmen. Diese Form von DSL wird auch als von Fachleuten lesbarer Code bezeichnet.117 Der dadurch erzeugte DSL-Code wird hnlich
der datenbankbasierten Verwaltung von Steuerungsdaten (siehe Kapitel 4.6) in
der Datenbank abgelegt und kann von dort mit dem gleichen Verfahren wie fr
XML (siehe Kapitel 5.1.6), exportiert und von einer Versionsverwaltungssoftware
verwaltet werden.
Damit sind dieselben Mglichkeiten bezglich KonfigurationsmanagementAnforderungen gegeben wie bei XML:

Zugriffskontrollen durchzufhren

nderungen nachzuverfolgen

Historien aller Mutationen fhren

nderungsworkflows schaffen

Es ist somit auch mittels DSL mglich, ber den gesamten Lebenszyklus nderungselemente zu belegen, zu managen und zu beschtzen.

5.3

Vergleich von DSL und XML als Grundlage fr die Verwaltung von Steuerungsdaten

In den Kapiteln 4.6, 5.1.6 sowie 5.2.3 wurde die Eignung der Methoden im Hinblick auf die Abdeckung der Anforderungen aus Konfigurationsmanagement fr
Steuerungsdaten untersucht. Sowohl DSL als auch XML sind in der Lage, aus
115

Vgl. Microsoft (2014) online.

116

Vgl. Voelter (2013) S. 47 f.

117

Vgl. Fowler (2010) o.S.

36

1110387012 Sebastian Kopf

Sicht von Konfigurationsmanagement diese Anforderungen abzudecken. Bei der


datenbankbasierten Speicherung ist die Anforderung nicht ohne zustzliche Implementierungen innerhalb der verwalteten Applikation zur Abdeckung der Anforderungen bezglich Verwaltung mglich.
Auch bei den Varianten XML und DSL sind zustzliche Implementierungen notwendig. Dabei handelt es sich jedoch um reine Import/Export Schnittstellen, wobei
die Datenbankvariante auch Prozesslogik zur Verwaltung (z.B. AnwenderInnenautorisierung oder Freigabeprozess) bentigt.
Die Varianten XML und DSL unterscheiden sich nicht, was die Verwaltbarkeit im
Konfigurationsmanagement betrifft. Hier bleibt als Differenzierungsmerkmal nur
der Aufwand, die jeweilige Methode aufzubauen.
Bei XML beluft sich dieser Aufwand auf die Definition der XML-Struktur. Diese
Definition kann ber eine Ableitung des Datenmodells erfolgen (siehe Kapitel
5.1.6).
Bei DSL ist der Aufwand abhngig von der Komplexitt der abzubildenden Domaine und der notwendigen Kompilierung. Es ist jedoch ein Aufwand, der zustzlich
zu der Analyse des Datenmodelles anfllt. Somit ist die Variante mit dem geringsten Aufwand, welche die Anforderungen des Konfigurationsmanagements erfllen
kann, eine Speicherung der Steuerungsdaten in XML.

37

1110387012 Sebastian Kopf

Conclusio

Die Ergebnisse der Recherche zeigen die Probleme bei der Verwaltung von betreiberInnenspezifischen Steuerungsdaten bei der alleinigen Verwendung von Datenbanken im Hinblick auf die Anforderungen des Konfigurationsmanagements. Es
ist ohne Funktionalittserweiterung innerhalb der betriebenen Applikation nicht
mglich, Zugriffskontrollen und Protokollierungen durchzufhren oder einen nderungsworkflow abzubilden.
Die alternativen Verwaltungsmglichkeiten basierend auf XML und DSL mit Untersttzung von Versionsverwaltungssoftware ermglichen hingegen eine vollstndige Abdeckung der Anforderungen. Durch den Einsatz von Versionsverwaltungssoftware ist die Nachvollziehbarkeit gewhrleistet (inklusive Verantwortlichkeiten) und die Auditierung wird untersttzt. Weiters sind alle Vernderungen der
Elemente dokumentiert und jederzeit wieder herstellbar. Der zustzliche Aufwand
beschrnkt sich bei dieser Methode auf die Notwendigkeit, den Export und Import
der Daten aus und in die Datenbank zu ermglichen.
Bei der Variante der Verwaltung der Daten durch XML gibt es Vorteile im Vergleich zum Einsatz von DSL. Der Einsatz von DSL bentigt im Vergleich zu XML
jedoch hhere Aufwnde, da hierbei nicht nur die Steuerungsdaten modelliert
werden mssen, sondern auch die Notwendigkeit besteht, die Domain zu analysieren. Weiters muss eine Kompilierung durchgefhrt werden.
Durch den Einsatz von XML und einer Versionsverwaltungssoftware wird das
Problem, dass sich jene Daten, die innerhalb der Applikation einen Bezug zu den
Steuerungsdaten herstellen, bei der Vernderung der Steuerungsdaten mglicherweise auf die ursprnglichen Steuerungsdaten zeigen mssen, nicht gelst. Ein
Beispiel hierfr knnen Umsatzdaten einer Kontoapplikation sein, die auf eine Berechnungsmethode des aktuellen Steuerjahres zeigen. Berechnungsmethoden
sind im diesem Fall die Steuerungsdaten. Durch eine nderung in den Steuergesetzen muss eine neue Berechnungsmethode konfiguriert werden. Damit die Umsatzdaten die mit der ursprnglichen Berechnungsmethode erzeugt wurden, auch
nach der Konfigurationsnderung noch bei einer Anzeige oder einem Storno mit
diesen Daten in der Applikation verarbeitet werden knnen, ist es notwendig innerhalb der Software diese Historie zu erhalten. Dieser historische Bezug ist durch
die in dieser Arbeit aufgezeigten Verwaltungsmglichkeiten nicht mglich.
38

1110387012 Sebastian Kopf

Die Erkenntnisse aus dieser Arbeit werden im Rahmen eines betrieblichen Evaluierungsprojektes Anwendung finden.

Weitere Forschungen zu diesem Thema sollten die Frage untersuchen, inwieweit


die hier dargestellten Vorgehensweisen in einer Steuerungsdatenverwaltungsapplikation integriert werden knnen, um Steuerungsdaten von beliebigen datenbankbasierten Applikationen ohne Zusatzaufwnde zu verwalten.

39

1110387012 Sebastian Kopf

Literaturverzeichnis

Allain,

A.
(2014):
Compiling
and
Linking,
bezogen
http://www.cprogramming.com/compilingandlinking.html,
Zugriff
25.06.2014

Azad,

K (2007): A Visual Guide to Version Control, bezogen unter:


http://betterexplained.com/articles/a-visual-guide-to-version-control/, Zugriff
am: 11.05.2014

unter:
am:

Berlin, D. / Rooney, G.(2006): Practical Subversion, 2. Aufl., New York: SpringerVerlag New York
Cabinet Office (2011): ITIL Service Transition, 2. Aufl., Norwich: The Stationery
Office
Chacon, S. (2009): Pro Git, 1. Aufl., New York: Springer-Verlag New York
Conrardi, R. / Westfechtel B. (1998): Version Models for Software Configuration
Management, in: ACM Computing Surveys, 30/2, S. 232-282, bezogen unter: http://dx.doi.org/10.1145/280277.280280, Zugriff am 27.04.2014
Datadisk
(2014):
Applikationarchitektur,
bezogen
http://www.datadisk.co.uk/images/sap/basis/intro4.jpg,
Zugriff
01.06.2014

unter:
am:

Ehow

unter:

(2014): Definition of Agile Project Management, bezogen


http://www.ehow.com/facts_6801409_definition-agile-projectmanagement.html, Zugriff am: 10.06.2014

Elmasri, R. A. / Navathe, S. B. (2009): Grundlagen von Datenbanksystemen, 3.


Aufl., Mnchen: Pearson Education Deutschland GmbH,
Fawcett, J. / Quin, L. R.E. / Ayers, D. (2012): Beginning XML, 5. Aufl., Indianapolis: John Wiley & Sons
Fowler, M. (2010): Domain Specific Languages, 1. Aufl., Boston: Addison-Wesley
Professional
Gnther, O. (1998): Environmental Information Systems, 1. Aufl., Berlin: SpringerVerlag
Harold, E. R. / Means, W. S. (2004): XML in a Nutshell, 3. Aufl., Sebastopol:
OReilly Media
Hass, A. M. J. (2003): Configuration Management Principles and Practice, Boston:
Pearson
Education
Inc.,
bezogen
unter:
http://my.safaribooksonline.com/book/management/0321117662,
Zugriff
am: 01.06.2014
ITWissen
(2014):
Webservice,
bezogen
http://www.itwissen.info/definition/lexikon/Webservice-WS-webservices.html, Zugriff am 10.06.2014

unter:

Keyes, J. (2004): Software Configuration Management, 1. Aufl., Boca Raton: Auerbach Publications, bezogen unter: http://www.amazon.com/SoftwareConfiguration-Management-Jessica-Keyesebook/dp/B000Q36ELA/ref=tmm_kin_title_0, Zugriff am: 14.04.2014

40

1110387012 Sebastian Kopf

Kulkarni, K. / Michels, J. (2012): Temporal features in SQL:2011, in: SIGMOD Record,


41/3,
S.
34-43,
bezogen
unter:
http://dl.acm.org/citation.cfm?id=2380786, Zugriff am: 01.06.2014
Microsoft (2014): UML Class Diagrams: Reference,
http://msdn.microsoft.com/en-us/library/dd409437.aspx,
13.06.2014

bezogen
Zugriff

unter:
am

PCmag (2014): Definition of: general-purpose language, bezogen unter:


http://www.pcmag.com/encyclopedia/term/43726/general-purposelanguage, Zugriff am 10.06.2014
Salzberg, B. / Tsotras, V. J. (1999): Comparison of Access Methods for TimeEvolving Data, in: ACM Computing Surveys, 31/2, S. 158-221, bezogen unter:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.9679&rep=re
p1&type=pdf, Zugriff am: 01.06.2014
SAP

Knowledge Warehouse (2014): Steuerungsdaten, bezogen unter:


http://www.urz.uniheidelberg.de/saphelp/helpdata/DE/35/28ea57e8aa5570e10000009b38f983/cont
ent.htm, Zugriff am: 01.06.2014

Software Engineering Institute (2010): CMMI fr Entwicklung, Version 1.3, Prozessverbesserung fr die Entwicklung besserer Produkte und Dienstleistungens, Pittsburgh: Software Engineering Institute, bezogen unter:
http://www.sei.cmu.edu/library/assets/whitepapers/10tr033de_v11.pdf, Zugriff am 01.06.2014
Spradlin, J. (2008): Groovy Domain Specific Language Tutorial, bezogen unter:
http://www.justinspradlin.com/programming/groovy-domain-specificlanguage-tutorial/, Zugriff am 02.06.2014
Techterms
(2010):
Character
encoding,
bezogen
http://www.techterms.com/definition/characterencoding,
Zugriff
10.06.2014

unter:
am:

TimeConsult (2005): What are Temporal Databases?, bezogen unter:


http://www.timeconsult.com/TemporalData/TemporalDB.html, Zugriff am:
01.06.2014
Tutorialspoint
(2014):
SQL
Transactions
http://www.tutorialspoint.com/sql/sql-transactions.htm,
10.06.2014

,bezogen
Zugriff

unter:
am

Van Deursen, A. / Klint, P./ Visser, J. (2000): Domain-Specific Languages:


An Annotated Bibliography, in: Sigplan Notices, 35/6, S. 26-36, bezogen unter: http://dx.doi.org/10.1145/352029.352035, Zugriff am
26.04.2014
Verband der Automobilindustrie (2010): Automotive Spice Process Assessment
Model,
Version
2.5,
bezogen
unter:
http://www.automotivespice.com/fileadmin/softwaredownload/automotiveSIG_PAM_v25.pdf, Zugriff am 01.06.2014
Voelter, M. (2013): DSL Engineering: Designing, Implementing and Using DomainSpecific Languages, 1. Aufl., CreateSpace Independent Publishing Platform
41

1110387012 Sebastian Kopf

Vonhoegen, H. (2011): Einstieg in XML, 6. Aufl., Bonn: Galileo Press GmbH


WhatIs
(2014):
Definition
compiler,
bezogen
unter:
http://whatis.techtarget.com/definition/compiler, Zugriff am: 12.06.2014

42