Institut für Parallele und Verteilte Systeme
Universität Stuttgart
Universitätsstraße 38
D–70569 Stuttgart
Bachelorarbeit Nr. 299
Eine Methodik zur Migration von
Microsoft-Access-Anwendungen
Manuel Lorenz
Studiengang: Softwaretechnik
Prüfer/in: Prof. Dr.-Ing. habil. Bernhard Mitschang
Betreuer/in: Dipl.-Inf. Frank Steimle
Beginn am: 15. Januar 2016
Beendet am: 15. Juli 2016
CR-Nummer: H.2.4


Kurzfassung
Migrationen und insbesondere Datenmigrationen stellen ein erhebliches Aufgabe dar. Durch
geeignete Methodiken lassen sich diese Aufgaben systematisch angehen. Wiederkehrende
Erkenntnisse bei der Migration können in diese Methodiken festgehalten werden und verhindern
so die Wiederholung der gleichen Problem. Für viele Migrationen existieren bereits ausgereifte
Methodiken. Für eine Migration vom Microsoft Access Anwendungen fehlt eine solche Methodik.
Mit dieser Bachelorarbeit soll der Grundstein für eine solche Methodik erstellt werden. Dazu
wird eine Migration einer Microsoft Access Anwendung exemplarisch durchgeführt und dabei
die besonderen Merkmale einer solchen Migration festgehalten. Diese Merkmale können dann
genutzt werden um eine geeignete Methodik zur Migration vom Microsoft-Access-Anwendungen
zu erstellen.
3

Inhaltsverzeichnis
1 Einleitung 9
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Anforderungskatalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Rollen und Rechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Möglicher Zugriff von mehreren Benutzern . . . . . . . . . . . . . . . . . 11
1.3 Zieldefinition der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Migration 13
2.1 Definition und Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Gründe für Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Migrationarten und Migrationsstrategien . . . . . . . . . . . . . . . . . . . . . . 17
3 Migrationsmodelle 23
3.1 Cold-Turkey-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Chicken-Little-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Butterfly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Analyse des bestehenden Systems 31
4.1 Beschreibung Legacy-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 Oberfläche Legacy-System . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Microsoft Access als Legacy-System . . . . . . . . . . . . . . . . . . . . 33
4.2 Auswertung der Legacy-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Gründe für die Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Migrationsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Migration Altsystem 39
5.0.1 Zieldefinition des Migrationsprojektes . . . . . . . . . . . . . . . . . . . 39
5.1 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Technologiestack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1.2 Entwurf der Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.3 Entwurf des Neusystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Implementierung der Datenbankanbindung . . . . . . . . . . . . . . . . 44
5.2.2 Implementierung der Benutzeroberflächen . . . . . . . . . . . . . . . . . 46
5.3 Export des Datenbestands aus Altsystem . . . . . . . . . . . . . . . . . . . . . 46
5.4 Import und Evaluierung des Datenbestands . . . . . . . . . . . . . . . . . . . . 47
5
6 Zusammenfassung und Ausblick 49
Literaturverzeichnis 51
6
Abbildungsverzeichnis
2.1 Begriffliche Einordnung der Softwaremigration [SWH10] . . . . . . . . . . . . . 16
2.2 Übersicht der Migrationsarten [SWH10] . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Übersicht der Migrationsstrategien [Sne99] . . . . . . . . . . . . . . . . . . . . . 21
3.1 Nicht-zerlegbare Architektur [Sne99] . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Zerlegbare Architektur [Sne99] . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Oberfläche zum Erstellen von Studentischen Arbeiten . . . . . . . . . . . . . . 32
4.2 Oberfläche zum Erstellen vom Prüfungsausschussanträgen . . . . . . . . . . . . 33
4.3 ER Diagramm der Tabelle für Studentische Arbeiten . . . . . . . . . . . . . . . 35
4.4 ER Diagramm der Prüfungsausschusstabelle . . . . . . . . . . . . . . . . . . . . 36
5.1 Technologiestack für die Reimplementierung des Legacy-Systems . . . . . . . . 40
5.2 Entwurf der Studenten Ansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Entwurf der Ansicht für Studentische Arbeiten . . . . . . . . . . . . . . . . . . 44
7

1 Einleitung
Die Softwaretechnik beschäftigt sich neben der Neuentwicklung von Software auch mit deren
Wartung und Erweiterung. Ein Teilgebiet dieser Wartung ist die Migration von Software.
Diese wird immer dann notwendig, wenn sich durch veraltete Technologien und geänderte
Anforderungen das bestehende System nur noch mit großen Aufwand betreiben lässt. Der Anteil,
den Wartung und Migration in modernen Systemen einnimmt, wächst stetig. Technologien
veralten mit zunehmender Geschwindigkeit, was zu einer immer kürzeren Lebenspanne von
Software führt. Noch in den 90er Jahren wurde die Lebensspanne von Software mit etwa
10 Jahren angegeben. Dadurch bedingt hat sich eine Halbwertszeit für Anwendersoftware
von maximal 5 Jahren herauskristallisiert. Aus der immer leistungsfähigeren Hardware mit
einem beispielsweise größeren Cache werden effizientere Algorithmen ermöglicht und erzeugen
eine bessere User Experience. Das bedingt auch die stetige Neuentwicklung von Software.
Dieser immer kürzer werdende Entwicklungszyklus zwingt die Softwareingenieure daz,u sich
Gedanken über neue Prozesse zu machen. Vor allem der Bereich der Informationssysteme
ist hiervon betroffen. Solche Systeme bestehen nicht nur aus der sich ständig anredenden
Hardware, sondern auch aus einer Datenbank, einer Anwendungen und einer Laufzeitumgebung.
Solche Systeme haben aber oft nur einen kleinen Anwenderkreis und unterliegen somit nur
einer geringen Wartung und werden meist direkt vom Anwender gepflegt, erweitert oder
angepasst. Die geringe Wartung für solche Systeme hat ihren Ursprung darin, days Wartung
stets ein teurer Aspekt des Lebenszyklus ist. Für viele Wartungsarbeiten muss das System
außer Betrieb genommen oder entsprechend aufwendigere Strategien genutzt werden, um eine
Wartung im Betrieb zu ermöglichen. Somit stellt die Wartung für ein kleines Team oder ein
kleinen Anwenderkreis eine besondere Herausforderung dar. Eine übliche Software für diese
System ist Microsoft Access. Es stellt fast alle benötigten Werkzeuge bereit und lässt sich
auch durch einen Anwender mit wenig Erfahrung erweitern. Doch leider führt das auch zu
einem unkontrollierten Wachsen des Systems. Im weiteren Sinne ist das Wachsen des Systems
auch in die Wartung verflochten. Schnelle Änderungen vom Anwender selbst führen dazu, dass
kein einheitlicher Wartungsplan eingehalten wird. Der Anwender implementiert nur die von
ihm aktuell benötigten Erweiterungen, ebenso wie er nur die aus seiner Sicht notwendigen
Wartungen durchführt. Die Dokumentation und die Wartbarkeit nehmen zunehmend mit dem
Alter des Systems ab.
1.1 Problemstellung
Die gewählte Problemstellung für diese Arbeit liegt in einer Microsoft Access Anwendung.
Dadurch, dass das bestehende System fest an Versionen und ein Betriebssystem gebunden
9
1 Einleitung
ist, erfüllt es nicht mehr die Anforderungen für die neue Umgebung. Die Informationen dieses
Systems waren bisher nur wenigen Anwendern zugänglich. Der Zugriff auf das System ist
nur unter Windows mit einer Microsoft Access Version 2006 möglich. Das Migrationsprojekt
soll dazu führen, dass aus dem umgebungsgebundenen System eine plattformunabhängige
Webanwendung entsteht, und somit alle aktuellen, sowie kommenden Anforderungen an die
Umgebung der Anwender sichergestellt ist. Auch wenn sich die neuen Anforderungen an
die Funktionalität geändert haben, wären diese weiterhin in Microsoft Access umsetzbar.
Gegen das Verwenden von Microsoft Access sprich jedoch die Plattformunabhängigkeit. Der
Einsatz von Microsoft Access ist nicht auf allen Systemen gewährleistet. Als unabdingbares
Akzeptanzkriterium muss gewährleistet werden, dass der gesamte Datenbestand unverändert
übernommen wird. Da die Überführung einer Access Datenbank nicht ohne weiteres möglich
ist, muss zunächst die entsprechende Migrationsstrategie gefunden und auf das Problem
angewendet werden. Später sollen alle weiteren neuen Funktionalitäten integriert werden. Die
genauen Anforderungen an das neue System sind in einem Anforderungskatalog 1.2 zusammen
gefasst und weiter ausgeführt.
1.2 Anforderungskatalog
Das nachfolgende Dokument beschreibt alle an das Migrationsprojekt geforderten technischen
sowie fachlichen Funktionalitäten.
• Anforderungen an die Umgebung
– Plattformen: Windows, Linux, Mac OS X
– Tomcat Webserver
– Java 1.8
• Technische Anforderungen
– CRUD Funktionalität für Studenten
– CRUD Funktionalität für Mitarbeiter
– CRUD Funktionalität für Studentische Arbeiten
– CRUD Funktionalität für Prüfungsausschussanträge
• Fachliche Anforderungen
– Rollen und Rechte für Benutzer
– Möglicher Zugriff von mehreren Benutzern
10
1.3 Zieldefinition der Arbeit
1.2.1 Rollen und Rechte
Die Rollen und Rechte sollen den Zugriff auf Funktionalitäten der Anwendung für die Benutzer
freigeben oder einschränken. Alle Funktionalitäten sollen mit einem jeweils eigenen Recht
versehen werden. Rollen müssen beliebig viele Rechte zugewiesen werden können.
1.2.2 Möglicher Zugriff von mehreren Benutzern
Das System soll beliebige multiple Zugriffe auf das System ermöglichen. Beim gleichzeitigen
Zugriff auf die Anwendung muss sicher gestellte werden, dass Objekte, die in Bearbeitung sind,
nicht von einem Zweiten Benutzer bearbeitet werden können.
1.3 Zieldefinition der Arbeit
Im Fokus dieser Arbeit liegt die Entwicklung einer Methodik, um Microsoft Access Anwendun-
gen zu migrieren. Als Resultat dieser Arbeit soll ein auf alle Microsoft Access Anwendungen
anwenderbares Vorgehen erarbeitet werden. Dieses Vorgehen soll als Leitfaden für die Migration
vom Microsoft Access Anwendungen nach MySQL mit entsprechender Oberfläche einsetzbar
sein.
1.4 Aufbau der Arbeit
Dies Arbeit legt ihren Fokus auf die Migration von solchen Microsoft Access Informationssys-
tem und neuen plattformunabhängigen Technologien. Der Fokus wird in der Theorie daher
hauptsächlich auf dem Hintergrund der Migration liegen. Die weiteren Kapitel beschäftigen sich
mit der Auswertung des bestehenden Systems und der möglichen Neuimplementierung in einem
neuen Technologiestack. Der praktische Teil dieser Arbeit führt gezielt ein Informationssystem
in eine neue Umgebung über und zeigt die Schwierigkeiten eines solchen Unterfangens auf.
Ebenso soll der praktische Teil als Leitfaden für ein Migrationsprojekt Microsoft Access nach
Spring Data darstellen.
11

2 Migration
Diese Kapitel soll den Begriff der Migration definieren und die möglichen Gründe für ein
Migrationsprojekt aufzeigen. Desweiteren beschäftigt sich dieses Kapitel mit den existieren-
den Migrationsarten und -strategien. Es werden die Migrationsarten System-, Daten- und
Programmmigration behandelt sowie die Migrationsstrategien Neuentwicklung/Reimplemen-
tierung, Konversion und Kapselung besprochen.
2.1 Definition und Abgrenzung
Bezogen auf die Informatik bezeichner der Begriff Migration den Prozess der Überführung
einer bisherigen Umgebung in eine technologisch neue Umgebung. Die Migration kann hierbei
entweder als Prozess der Überführung des gesamten Systems gesehen werden oder aber auch
nur auf Teilgebiete des Systems wie Daten, Programme oder Schnittstellen. Bei einer Migration
wird in der Regel ein Legacy-System, auch Altsystem genannt, als Ausgangssystem betrachtet.
Ein Legacy-System ist nach Brodie und Stonebraker wie folgt definiert: „A legacy information
system is any information system that siginificantly resists modification and evolution to meet
new and constantly changing business requierments.“[BS95] Desweiteren haben die beiden
Autoren Charakteristika aufgestellt die auf ein solches Legacy-System zutreffen:
• Basiert entweder auf veralteten Datenbankmanagementsystemen(DBMS) oder auf über-
haupt keinem DBMS, sondern auf einer File-Datenbank (zum Beispiel ISAM oder
VSAM).
• Geschrieben in veralteten Programmiersprachen wie zu Beispiel COBOL
• Großes System mit mehreren Millionen Zeilen Code
• Applikationen sind unabhängig, ohne Schnittstellen zu anderen Applikationen.
Auf Brodie und Stonebacker geht auch die Schätzung des typischen Alters eines Legacy-Systems
zurück. 1995 gaben sie das typische Alter eines Legacy-System mit 10 Jahren an. Heute jedoch
muss diese Schätzung aufgrund der sich immer schneller entwickelnden Technologien auf 5
Jahre angepasst werden. Der Umgang mit referentieller Integrität stellt ein Problem für Legacy-
System da. Oft werden sie vollständig ignoriert oder nur auf Applikationsebene behandelt. Bei
DBMS kam es häufig zu Problemen mit referentieller Integrität. Diese stellte das Hauptproblem
in der Anfangszeit der DBMS dar. Neuere Versionen stellen die referentielle Integrität jedoch
selbst sicher. Somit kann es nicht vorkommen, dass auf Applikationsebene Fremdschlüssel
nicht deklariert werden.
13
2 Migration
Ein weiteres entscheidendes Problem bei Legacy-Systemen ist, dass sie oft nur unzureichend
dokumentiert sind und der Quellcode nur schlecht zugänglich ist. Sie sind daher nur mit großem
Aufwand wartbar. Selbst wenn das System über eine Dokumentation verfügt, wird diese oft
veraltet sein und ist nicht mit dem Legacy-System gewachsen, da das System über die Jahre
viele Änderungen und Anpassungen erlebt hat.[HC96] Bei der Bewertung eines Legacy-Systems
sind diese Faktoren jedoch nicht fest gewichtet - so kann auch eine System, das jünger als 5
Jahre ist oder gerade erst entwickelt wurde ein Legacy-System sein. Tritt der Fall ein, dass ein
System als Legacy-System bewertet wird, hat der Anwender zwei Möglichkeiten: Entweder er
entscheidet sich weiterhin dafür, mit dem veralteten System zu arbeiten und geht damit das
Risiko ein, den Support zu verlieren. Entscheidet er sich für die zweite Möglichkeitm sich den
Anforderungen neuer Technologien zu stellen, eröffnen sich ihm weitere zwei Möglichkeiten.
Er kann auf eine vollständige Neuentwicklung setzten oder aber auf die Migration. Hierbei
ist es nicht ausschlaggebend, ob er lediglich nur Teile des Legacy-Systems migrieren will oder
aber das komplette System. Eine vollständige Neuentwicklung führt jedoch zum Verlust aller
Informationen des Legacy-Systems. Wie später im Kapitel 2.3 ausgeführt wird gibt es jedoch
auch geeignete Strategien, eine Neuentwicklung mit einer Migration zu kombinieren.
Jedoch lässt sich an der Möglichkeit der Kombination feststellen, dass eine Trennung wie sie in
der Theorie versucht wird nicht gänzlich möglich sein. Es kann immer zu Überschneidungen
der beiden Arten kommen. Sneed et al. betonen die Beibehaltung der Funktionen[SWH10]. Sie
definieren Migration im Rahmen der Überführung von Systemen wie folgt: „Softwaremigration
bezeichnet die Überführung eines Softwaresystems in eine andere Zielumgebung oder in eine
sonstige andere Form, wobei die fachliche Funktionalität unverändert bleibt.“[SWH10] Ihre
Definition geht sogar noch weiter als die Definition von Brodie und Stonebaker. Sie haben
Migration wie folgt definiert: „Legacy IS migration begins with a legacy IS and ends with a
comparable target IS. This target IS is significantly different from the original, but it contains
substantial functionality and data from the legacy IS.“[BS95] Sie sagen anders als Sneed et al.,
dass sich der grundlegende Code des Legacy-Systems ändern darf, aber die Funktionen und
die Daten des zugrunde liegenden Legacy-Systems weitgehend unverändert bleiben.
Hier zeigt sich nun, dass alle Autoren die Migration klar von der Neuentwicklung abgrenzen: „Die
Neuentwicklung bestehender Legacy-Systeme ist keine Migration, allenfalls eine Entwicklung
unter Wiederverwendung von Teilen des alten Systems.““
Nun ist zunächst ungewöhnlich, dass bei einer Migration der Wunsch nach neuen Funktionen
nicht umgesetzt werden sollte. Durch neue Technologien bieten auch gänzlich andere Möglich-
keiten, und stellt somit oft auch eines der Hauptmerkmale für den Systemwechsel dar. Sneed et
al. bewerten dieses Motiv jedoch als falschen Grund für eine Migration. Die Autoren betonen
ausdrücklich, wie wichtig es ist, diese Trennung vorzunehmen und dass die unveränderte
Funktionalität bei einer Migration Voraussetzung für die gleichbleibende Testbasis ist. Die
gleichbleibende Testbasis ist ein entscheidender Vorteil der Migration. Die Testbasis stellt für
das Legacy-System die notwendigen Akzeptanztests bereit, die erfolgreich durchgeführt werden
müssen. Führt man die selbige Testbasis auf dem migrierten System au,s muss diese ebenfalls
erfolgreich durchlaufen werden. Fügt man bei einer Migration weitere Funktionalität hinzu,
ändert sich auch die Testbasis. Daher sollte man weitere Funktionen erst nach Abschluss der
Migration durchführen.
14
2.2 Gründe für Migration
Betrachtet man eine komplette Neuentwicklung, lässt diese sich im Softwareengineering in den
Bereich Softwareentwicklung eingliedern. Die Migration wird jedoch als Teil der Softwareer-
haltung gesehen. Softwareerhaltung wird von der IEEE wie folgt definiert: „Modification of a
software product performed after delivery to correct faults, to improve performance or other
attributes, or to adapt the product to a modified environment.““ [72098] Der Standart für
Software Maintenance der IEEE unterscheidet drei große Bereiche, denen allesamt gemeinsam
ist, dass sie dafür sorgen das ein System am Leben bleibt: Korrigierende Erhaltung („corrective
maintenance“), verbessernde Erhaltung („perfective maintenance“) und anpassende Erhaltung
(„adaptive maintenance“). Den Zusammenhang der einzelnen Teilbereiche wird in 2.1 ersichtlich.
Die Abbildung ordnet die Bereiche Softwareentwicklung und Software Maintenance (auch:
Softwareerhaltung) dem Software Engineering zu. Weiter lässt sich die Softwareerhaltung in die
Teilbereiche Softwarewartung, Softwareevolution, Softwaresanierung und Softwaremigration
unterteilen. Somit lässt sich nach dieser Aufschlüsselung Migration in die Softwareerhaltung,
und dort in die Softwaresanierung eingliedern, wie aus Abbildung 2.1 hervorgeht, da Migration
das System in eine neue Umgebung überführt, aber gleichzeitig am Leben erhält.
Es gibt noch weitere Bereiche der Softwareerhaltung, die jedoch von der Softwaremigra-
tion abgegrenzt werden müssen. Diese Teilbereiche sind Softwareevolution, -Wartung und
-Sanierung.
Sanierung kann auch als Re-Engineering bezeichnet werden und hat die Absicht, die Qualität
des bestehenden Systems weiter zu verbessern. Ähnlich zur Migration bleiben Funktionalitäten
unangetastet. Der Unterschied zur Migration besteht darin, dass die Sanierung keine Änderun-
gen an der Sprache oder der Umgebung vornimmt, sie verbessert lediglich die Qualität des
bestehenden Codes oder der bestehenden Architektur.
Sanierungen können jedoch sowohl vor, als auch nach einer Migration genutzt werden. Vor der
Migration können sie diese wesentlich vereinfachen. Nach der Migration kann eine Sanierung
genutzt werden, um die Qualität der Migration zu verbessern. Wartung beinhaltet nur die
Korrektur von Fehlern im bestehenden System, maximal jedoch kleine Änderungen, die jedoch
nicht als Weiterentwicklung bezeichnet werden können. Die Softwareevolution bezieht sich auf
inkrementelle Veränderungen des bestehenden Systems . Sie findet immer dann Anwendung,
wenn die bestehende Systemarchitektur den veränderten Anforderungen nicht mehr gerecht
werden kann. Die Softwareevolution zieht also immer eine Anpassung des Codes nach sich.
Bei einer Anpassung von weniger als 20 Prozent des Codes spricht man von Evolution. Ist der
Anteil höher spricht man von Neuentwicklung. Somit bildet die Evolution eine Vorstufe zur
Neuentwicklung, und unterscheidet sich somit auch von der Migration, da sie eine veränderte
Funktionalität des Systems mit sich bringt.
2.2 Gründe für Migration
Gründe für einen Anwender, sich der Migration anzunähern, sind sehr vielfältig. Diese entstehen
dadurch, dass sich die Anforderungen an Soft- und Hardware geändert haben und das System
dafür nicht mehr ausreichend ist.
15
2 Migration
Abbildung 2.1: Begriffliche Einordnung der Softwaremigration [SWH10]
Betrachtet man die Entwicklung von IT-Technologien, fällt einem sofort auf, dass der Zusam-
menhang von abgelösten Technologien mit der Ablöse und dem Anwendersystem einhergeht.
Jedoch muss nicht jeder Technologiewechsel sofort mit einer Migration gekontert werden.
Neben der kompletten Neuentwicklung stehen dem Anwender auch noch die Beibehaltung des
Systems zur Verfügung. Dies ist solange eine gute Alternative, wie der Anwender seine Aufgabe
mit dem System noch vertretbar durchführen kann. Ein zu langes Warten führt jedoch schnell
zu einer viel größeren Aufgabe und eine Neuentwicklung wird oft unumgänglich.
Vor allem große Unternehmen oder Behörden setzten sehr lange auf ein Anwendersystem.
Dieses System und deren Technologien sind meist über 20 Jahre alt. Daher finden sich dort
noch oft Anwendungen, die in Assembler oder COBOL geschrieben sind. Solche Systeme
zu warten oder gar zu erweitern ist nur mit großem Aufwand möglich. Oft beherrschen nur
noch wenige Experten diese Sprachen und es wird zunehmend unmöglich, Spezialisten für
diese Aufgabe zu finden.[Sne99] In vielen Fällen werden innerhalb eines Unternehmens aber
auch unabhängig voneinander entwickelte Applikationen verwendet, die zudem nicht selten
aus unterschiedlichen Generationen stammen.[Glö07] Hinzu kommt, dass die Daten nicht
in relationale Datenbanksysteme abgelegt sind. Solche Strukturen sind hoch komplex und
bringen einen enormen Aufwand mit sich, wenn es um die Lebenserhaltung geht.[SWH10] Eine
16
2.3 Migrationarten und Migrationsstrategien
Schätzung geht davon aus, dass ein Unternehmen, welches ein System nutzt das älter als zehn
Jahre ist, bereits 60 Prozent seines IT-Bugets für die Erhaltung dieser Systeme aufbringen
muss. Neben dem Budgetaufwand sind diese Unternehmen auch nicht mehr gut aufgestellt für
neue Herausforderungen des Marktes. Denn nur neue Systeme können neue Geschäftsprozesse
unterstützen. Diese Unternehmen laufen daher auch Gefahr, Chancen und Möglichkeiten zu
verpassen. Die Migration stellt hiermit die beste Strategie dar um rechtzeitig diesen Kurs zu
verhindern. Ein weiterer Grund für die Migration von Systemen ist, dass sich die IT-Landschaft
drastisch ändert und geändert hat.
So hat man noch vor 10 Jahren die Systeme maßgeblich als Client/Server-Architektur entworfen.
Es hat ein schneller Wandel zur serviceorientierten Architektur stattgefunden und wandelt
sich heute immer mehr hin zur eine Cloud-Architektur.
Das angestrebte Ziel diesen Wandels ist es, eine möglichst hohe Flexibilität und Effektivität zu
erreichen. Jedoch finden solche Wechsel oft nicht in der gesamten IT-Landschaft statt. Somit
existieren Anwendungen aus unterschiedlichen Generationen. Hier können Migrationsprojekte
helfen, die abschließende Integration alles Prozesse zu ermöglichen.
Hierzu muss die Migration neue Schnittstellen implementieren und Daten migrieren. Bisherige
Migrationsprojekte haben oft nur die Hard- oder Software betroffen. Moderne Migrationsprojek-
te führen jedoch auch zu einer Umstellung der Geschäftsprozesse. Fortan könnten beispielsweise
die Fachabteilungen für die Modellierung zuständig sein und die IT-Abteilung übernimmt nur
noch die Datenhaltung, Datenaustausch und die Datenverarbeitung.
2.3 Migrationarten und Migrationsstrategien
Bevor man sich für eine Migrationsstrategie entscheiden kann, muss man zunächst die ver-
schiedenen Migrationsarten überdenken.
Migrationsarten
Die komplexeste Art der Migration, die Systemmigration, umfasst das gesamte System. Dennoch
ist es möglich nur einzelne Teile zu migrieren, je nach Anforderung des Migrationsprojekts.
Somit ergibt sich noch die feinere Einteilung in: Daten-, Programm-, Oberflächen-, oder
Schnittstellenmigration.[SWH10] Abbildung 2.2 zeigt die einzelnen Migrationsarten in einer
Übersicht. Bei der Programmmigration verbleiben alle Daten in ihrer alten Umgebung und
lediglich die Anwendungslogik wird neu implementiert. Hierbei existieren drei Varianten: Ein
Wechsel der Programmiersprache bei gleichbleibender Umgebung, ein Wechsel der Umgebung
bei gleichbleibender Sprache, oder die Migration von sowohl Sprache als auch Umgebung.
Eine reine Oberflächenmigration belässt die Anwendungslogik und die Daten in ihrer alten
Umgebung. Lediglich die Benutzerschnittstellen werden migriert. Hierfür muss jedoch die
Oberfläche von der Programmlogik getrennt sein. Sollte das für ein Legacy-System nicht der
Fall sein, kann die Trennung durch eine Sanierungsmaßnahme vorgenommen werden.
Es können jedoch auch die Programmlogik und die Oberflächen gleichzeitig migriert werden.
Bei einer Schnittstellenmigration werden die Systemschnittstellen migriert, die das System
17
2 Migration
zu anderen Systemen anbinden. Diese Art von Migration muss immer dann durchgeführt
werden, wenn sich die Fremdsysteme ändern, mit denen das System Daten austauscht. Auf
welche Art sich das Fremdsystem ändert ist dabei unwichtig, sei es durch eine Migration oder
eine Neuentwicklung mit neuen Schnittstellenprotokollen. Sofern das Altsystem über einen
Datenaustausch mit sequenziellen Exportdateien gesetzt hat, ist die Migration aufwendiger,
als wenn sie bereits moderne XML-Dateien oder SOAP-Nachrichten zum Datenaustausch
gesetzt hat. Das passiert dadurch, dass bei einem Datenaustausch über sequenzielle Dateien der
Eingriff in den Programmcode wesentlich aufwendiger ist, anstatt lediglich den bestehenden
Code an die neue Schnittstelle anzubinden.
Bei der Datenmigration werden ausschließlich die Daten des Altsystems übertragen, die
Programme an sich bleiben dabei ohne Veränderung bestehen. Sofern das System auf eine
relationale Datenbank gesetzt hat, ist der Wechsel relativ problemlos möglich und oft auch
voll automatisierbar. Hierbei muss jedoch die Evaluation der Daten genauer betrachtet werden
um sicher zu stellen, dass alle Daten korrekt übertragen wurden. Kompliziert ist die Migration
von relationalen Strukturen in eine objektorientierte Struktur. Diese lässt sich nur bedingt
automatisieren, jedoch können hier durch geeignete Modellierung viele Probleme vermieden
werden. Der schwerste Fall einer Datenmigration stellt die Migration von Daten dar, die auf
einer nicht relationalen, veralteten Datenbank beruhen. Nur die Daten zu migrieren wird in
diesen Fällen selten gelingen, denn sowohl die Struktur als auch die Zugriffslogik der neuen
Datenbank unterscheiden sich grundlegend von der alten Datenbank.
Diese Art der Datenmigration stellt somit auch die komplexeste Migration dar und kann zu
einer echten Herausforderung für den Entwickler werden.
Migrationsstrategien
In der Theorie haben sich drei unterschiedliche Migrationsstrategien entwickelt: Man unterschei-
det zwischen Konversion, Kapselung und Reimplementierung. Letztere wird in der Literatur
auch als Neuentwicklung bezeichnet. An diesen Begriffen sieht man schnell die von Sneed
et al. propagierte Schwierigkeit in der Trennung von Migration und Neuentwicklung. Sneed
selbst nutzt diesen Begriff[Sne99] Diesen Begriff ändert Sneed et al. in Reimplementierung
ab. Hiermit wird versucht, den Begriff schärfer abzugrenzen. [SWH10]. Dass es notwendig ist
die Grenze schärfer zu ziehen wird klar, wenn man betrachtet was eine Neuentwicklung im
Sinne der Migration meint. Die Neuentwicklung bei einer Migration steht nicht von Grund auf
im Zusammenhang mit der Neuentwicklung. Sneed unterscheidet hierbei zwischen Daten und
Programmen.
Daten können vollkommen neuen Strukturen zugewiesen werden, was dazu führen kann,
dass völlig neue Schlüssel bestimmt werden. Somit bleibt bei dieser Strategie lediglich die
semantische Bedeutung der Daten gleich, damit bleibt auch der Inhalt der Daten gleich,
nicht aber ihre Ausprägung oder ihre Formatierung. Bei Programmen geht Sneed sogar noch
einen Schritt weiter und erlaubt sogar Veränderungen bei den Zugriffen auf die Datenbank,
oder gar, dass neue Funktionen definiert werden. Neben diesen Änderungen, die im Zuge der
Neuentwicklung möglich sind, kann es auch noch zum Austausch der Programmiersprache
kommen, auch kann das Kommunikationssystem abgeändert werden. Daraus entsteht bei der
18
2.3 Migrationarten und Migrationsstrategien
Abbildung 2.2: Übersicht der Migrationsarten [SWH10]
Neuentwicklung ein System, dass kaum noch mit dem alten vergleichbar ist.[SWH10] Sneed
sagt dazu „Die Entwickler werden lediglich durch die Semantik der alten Daten gehemmt. Auf
der funktionalen Seite steht ihnen alles offen.“[SWH10]
Die Reimplementierung kann als freie Übersetzung des Systems bezeichnet werden, bei wel-
cher lediglich einzelne Bausteine migriert werden. Diese Bausteine müssen jedoch nach der
Neuentwicklung vergleichbar mit dem Alt-System sein. Sollten sie nicht mehr vergleichbar
sein, kann nicht von einer Migration gesprochen werden.[SWH10] Somit fasst der Begriff der
Reimplementierung die Strategie enger, da hierbei die Bausteine vergleichbar sein müssen.
Neben der Neuentwicklung beziehungsweise die Reimplementierung stehen dem Entwickler
auch noch die Konversion als Strategie zur Verfügung.
Bei derKonversion werden Programme und Daten meist automatisiert übertragen. Somit ändert
sich nur die Form der Umgebung, dennoch bleiben Daten und Programme unverändert.[SWH10]
Bei der Konversion handelt es sich nicht, wie bei der Reimplementierung, um eine freie
Übersetzung. Die Konversion entspricht einer genauen Übersetzung, die jeden Datentyp des
alten Systems in den entsprechenden Datentypen des neuen Systems übersetzt. Desweiteren
19
2 Migration
müssen Anweisungen und deren Abfolge zur Laufzeit der gleichen Reihenfolge entsprechen wie
im Ursprungsprogramm.[SWH10]
Die Konversion setzt eine sehr aufwändige und genaue Ist-Analyse des Legacy-Systems voraus.
Diese Ist-Analyse kann mit der Systemdokumentation erfolgen. Ist die Dokumentation nicht
hinreichend, können die ursprünglichen Entwickler zur Hilfe gezogen werden. Sind auch diese
nicht verfügbar, bleibt dem Entwickler nur die Möglichkeit des Reverse-Engineering um das
System nachzudokumentieren. Hierbei muss der Entwickler alle notwendigen und verfügbaren
Informationen aus dem Quellcode des Legacy-Systems extrahieren. Er muss alle Informationen
heranziehen und eine abstrakte Beschreibung des Systems zu erhalten, die als Grundlage für
das neue System dienen können.[HC96] Hat der Entwickler es mit einer Datenbankkonversion
zu tun, muss er zwischen einer unteren und einer oberen Ebene unterscheiden. Auf der oberen
Ebene muss er die Datenbankstruktur konvertieren. Auf der unteren Ebene muss er die
Datentypen konvertieren. Liegt dem Legacy-System eine relationale Datenbank zu Grunde
und soll das neue System ebenfalls eine relationale Datenbank nutzen, muss lediglich die
untere Ebene konvertiert werden. Wobei nur die Datentypen konvertiert werden müssen, die
nicht kompatibel sind. Die obere Ebene muss in diesem Szenario nicht konvertiert werden,
da sich die Struktur nicht ändert. Liegt einem der beiden Systeme aber eine nicht-relationale
Datenbank zu Grunde, ist zusätzlich die obere Ebene zu konvertieren. Eine Normalisierung
der Ausgangsdatenbank hat zur Folge, dass bestimmte Attribute in neue Tabellen verlagert
werden müssen.[SWH10] Wendet man die Konversion auf eine hierarchische Struktur an
und möchte eine objektorientierte Struktur erzeugen, bietet sich ein Zwischenschritt für die
Daten an. In diesem Zwischenschritt werden die Daten zunächst in eine relationale Struktur
überführt. Aus dieser Struktur lassen sich Objekte einfacher bilden. Aus Prozeduren der
alten Programme müssen Methoden gebildet werden. Die Komplexität hängt maßgeblich von
der Ausgangssprache ab. Sofern eine Sprache wie C oder COBOL, die eine objektorientierte
Erweiterung bieten, genutzt wurde, lassen sich die Prozeduren in Methoden überführen ohne
die Einzelanweisung zu ändern. Bei Sprachen, die keine solche Erweiterung bieten oder die
Programmlogik anderweitig herstellen, ist dies nicht möglich und die Konversion muss manuell
durchgeführt werden. Der Aufwand für die Konversion eines solchen Systems ist erheblich
größer und kann als Ausschlusskriterium für die Konversion gesehen werden.[Sne99]
Die dritte Möglichkeit ist die Kombination beider Strategien zur Kapselung. Gleichzeitig ist die
Kapselung auch die aktuellste der Strategien. Sie wurde Ende der 90er entwickelt, um auf die
Herausforderung der aufkommenden objektorientierten Programmierung zu reagieren.[SWH10]
Das Ziel der Kapselung besteht weder darin, Daten und Programme zu konvertieren noch zu
reimplementieren, sondern sie in der alten Umgebung zu halten. Sie werden einfach in ihrer
alten Umgebung in ein sogenannten Wrapper oder eine Softwareschale gehüllt.
Dieser Wrapper stellt die Schnittstelle zwischen dem alten und dem neuen System sicher. Er
ist dabei maßgeblich für die Übersetzung der unterschiedlichen Sprachen verantwortlich. Im
neuen System werden Benutzeroberflächen und die lokale Verarbeitungslogik reimplementiert.
So kann der Wrapper dafür Sorge tragen, dass das neue System beispielsweise das Frontend in
Java dennoch mit dem Backend aus COBOL-Programmen vom alten System kommunizieren
kann.[Sne99][SWH10]
Eine weitere Aufgabe die der Wrapper bei der Kapselung wahrnimmt ist die Sicherstellung der
Konsistenz der Daten. Er muss dafür Sorge tragen, dass sowohl die Applikation des gekapselten
20
2.3 Migrationarten und Migrationsstrategien
Abbildung 2.3: Übersicht der Migrationsstrategien [Sne99]
Legacy-Systems, als auch die neue Applikation Änderungen an den Daten vornehmen können,
ohne die Datenintegrität zu verletzten.[THHB06]
Für welche der drei Strategien man sich entscheidet, ist immer vom zu migrierenden Legacy-
System und dessen Bewertung abhängig. Konversion und Kapselung sind grundsätzlich immer
möglich, können jedoch im Einzelfall kompliziert umzusetzen sein. Schwierig sind diese Fälle
meist dann, wenn die Daten in einer veralteten Struktur oder in einer ungewöhnlichen Form
vorliegen.
Die Ist-Analyse kann zu einem Ergebnis kommen, die die Konversion ausschließt, da die
Analyse die Programmstruktur als zu groß und komplex eingestuft hat. Daher würde eine
Konversion einen zu aufwendigen Restrukturierensprozess nach sich ziehen. Eine Konversion
kann auch aus dem gegenteiligen Ergebnis ausgeschlossen werden. Wenn die Qualität des
Programms zu niedrig ist, kann die Konversion Sanierungsmaßnahmen voraussetzen, die sich
aus Kostengründen nicht rechtfertigen lassen.[Sne99] Eine optimale Strategiewahl wäre dann
gewährleistet, wenn jede Komponente des Legacy-Systems einzeln analysiert wird und die
von den drei am meisten geeignete Strategie für jede Komponente gewählt wird. Die Praxis
zeigt jedoch, dass aus Kostengründen meiste nur eine Strategie für alle Komponenten gewählt
wird.[SWH10] Ungeachtet der Strategie die man nutzt, überführt man immer ein ehemaliges
System in ein neues System. Abbildung 2.3 zeigt eine Übersicht der Strategien, ebenso wie die
Überführung der ursprünglichen Eigenschaften eines Legacy-System in ein neues System.
21

3 Migrationsmodelle
Im Laufe der Zeit haben sich neben verschiedenen Migrationsarten und Migrationsstrategien
auch unterschiedliche Migrationsmodelle entwickelt. Dieses Kapitel soll einen Überblick über
die gängigen Migrationsmodelle verschaffen und sie einzeln bewerten. Für jedes Modell soll
eine kurze Auflistung der Vor- und Nachteile erfolgen. Neben dem ältesten Modell, dem
Cold-Turkey-Ansatz, wurde der Chicken-Little-Ansatz entwickelt. Weitere Vorgehensschemen
die in diesem Kapitel betrachtet werden sind, der Butterfly-Ansatz, der Renaissance-Ansatz
und die Migrationsfabrik.
3.1 Cold-Turkey-Ansatz
Beim Cold-Turkey-Ansatz, oder auch die Bigbang-Migration genannt [BLWG99], handelt es
sich um eine vollständige Neuentwicklung mit modernen Entwicklungsmethoden. Während das
Legacy-System weiterhin betrieben wird, wird parallel dazu das neue System entwickelt und
getestet. Nachdem das neue System vollständig entwickelt wurde und alle Tests bestanden hat,
wird es im finalen Schritt im sogenannten „Big Bang“ ausgerollt. Dabei wird das Legacy-System
vollständig abgeschaltet und das neue System übernimmt alle Aufgaben. Durch den finalen
Schritt ergibt sich eine hohes Risiko für dieses Migrationsmodell, wenn es funktionieren soll.
Bevor der finale Schritt jedoch durchgeführt werden kann, durchläuft die Entwicklung beim
Cold-Turkey-Ansatz - verkürzt dargestellt - folgende Phasen [BS95]:
• Analyse des Legacy-Systems
• Entwicklung des neuen Systems
• Test des neuen Systems
• Migration der Daten des Legacy-Systems
• Deaktivierung des Legacy-Systems
• Ausrollen des neuen Systems
Nach [BS95] ergeben sich aus diesem Ablauf besondere Probleme beim Cold-Turkey-Ansatz.
23
3 Migrationsmodelle
Fehlende Spezifikation
Wie bereits erläutert unterliegt die Migration von Legacy-Systemen oft einer fehlenden oder
unzureichenden Dokumentation oder Spezifikation. Für alte Systeme existiert meist nur der
Quellcode als Dokumentation. Das ist eine besonders schwere Hürde für den Cold-Turkey-
Ansatz, da er eine Analyse des Legacy-Systems zwingend voraussetzt. Diese jedoch nur aus
dem Quellcode zu gewinnen ist komplex und teuer.
Undokumentierte Abhängigkeiten
Da Legacy-Systeme oftmals im Laufe ihres Lebenszyklen erweitert werden, kommt es vor, dass
sie an Fremdsystem angeschlossen werden, ohne dies zu dokumentieren. Bei der darauffolgenden
Migration müssen diese Abhängigkeiten trotzdem entdeckt und umgesetzt werden. Ohne die
notwendige Dokumentation ist auch dieser Schritt kompliziert und teuer in der Umsetzung.
Altsysteme können zu groß sein
Meist sind Legacy-Systeme dort im Einsatz, wo eine fast 100% Verfügbarkeit vorausgesetzt
wird. Durch die Migration kann es bei sehr großen Systemen zu einem Ausfall von Tagen
oder Wochen kommen. Zum Einen dann, wenn sehr große Datenmengen migriert werden
müssen oder aber dann, wenn die Datenaufbereitung für das neue System viel Zeit in Anspruch
nimmt.
Schwierigkeiten große Projekte zu managen
Legacy-Systeme sind nicht selten sehr große Systeme. Die Entwicklung eines entsprechend neuen
Systems kann lange dauern und nur mit einer großen Anzahl an Entwicklern in vertretbarer
Zeit gelingen. Dennoch sind große Projekte schwerer zu managen und können daher schneller
scheitern als kleinere Projekte.
Analysis-Paralyse
Ein Migrationsprojekt nach dem Cold-Turkey-Ansatz kann erst dann beginnen, wenn das
Legacy-System vollständig analysiert wurde. Da jedoch das Legacy-System aufwendig zu
analysieren und meist sehr komplex ist, wird weiter analysiert. Da die Analyse nie abgeschlossen
ist, kann ein erfolgreicher Start der Migration nie beginnen.
Insgesamt wird der Cold-Turkey-Ansatz als sehr starr im Bezug auf die Anforderungen an das
neue System gesehen. Zudem ist er mit einem hohen Risiko behaftet.[BS95] Als Alternative
dazu würde wie bereits in der Einleitung erwähnt der „ -Little-Ansatz“ entwickelt, welcher im
nächsten Abschnitt behandelt wird.
24
3.2 Chicken-Little-Ansatz
3.2 Chicken-Little-Ansatz
Beim „Chicken-Little-Ansatz“ wird ein iteratives Vorgehen genutzt, der die Risiken, die
beim „Cold-Turkey-Ansatz“ vorhanden sind, zu minimieren. Das Legacy-System bleibt dabei
im Einsatz und wird nach und nach durch Bestandteile des neuen Systems ersetzt. Im
Gegensatz zu einem großen Problem wie „Cold-Turkey-Ansatz“ wird das Problem in viele kleine
überschaubare Teilprobleme aufgespaltet, welche nun einfacher einzeln gelöst werden können.
[BS95] Kent Beck argumentiert in [Bec00] ähnlich wie Brodie, dass bei einem fehlgeschlagenen
Schritt der Migration nur dieser eine Teilschritt wiederholt werden muss. Ein fehlgeschlagener
Teilschritt führt nicht zum Scheitern des ganzen Migrationsprojektes. Anzuführen ist das der
„Chicken-Litte-Ansatz“ die Probleme nicht verschwinden lässt, sondern sie lediglich in Risiken
einteilt, die für das Migrationsprojekt überschaubarer sind.
Für eine erfolgreiche Migration nach dem „Chicken-Litte-Ansatz“ muss im Vorfeld eine Analyse
durchgeführt werden. Diese Analyse dient dazu, zu identifizieren wie sehr die einzelnen Kompo-
nenten miteinander verflochten sind. Brodie und Stonebraker unterscheiden dabei zwischen drei
Systemarchitekturen: Zerlegbare, semi-zerlegbare und nicht-zerlegbare Architekturen: [BS95]
Dahingegen veranschaulicht Abbildung 3.1 eine nicht-zerlegbare Architektur. Liegt einem
System eine solche Architektur zu Grunde, nennt man dieses System auch BlackBox. Bei einem
Blackbox System ist die innere Funktionsweise nicht ersichtlich.[BS95]
Abbildung 3.2 zeigt eine zerlegbare Architektur, bei der mehrere voneinander unabhängige
Teilmodule zu erkennen sind. Die Teilmodule verfügen über eigene Schnittstellen zu einer
Datenbank, sowie Benutzer- und Systemschnittstellen.
Die dritte Variante die Brodie und Stonebraker anführen, ist die semi-zerlegbare Architektur.
Sie ist eine Mischung aus beiden genannten Architekturen. Bei der semi-zerlegbaren Architektur
können Benutzer- und Systemschnittstellen getrennt voneinander betrachtet werden. Jedoch
sind die Applikationen und Datenbankschnittstellen so miteinander verflochten, dass eine
Trennung nicht möglich ist. [BS95]
Gateways
Um den iterativen Vorgehen Genüge zu tun benötigt dieses Migrationsmodell Gateways, sie
sollen das iterative Vorgehen ermöglichen. Bei einem Gateway handelt es sich um Software,
das die Anfragen eines Benutzers an das Altsystem auf das Neue System umleitet.[BS95]
Um Gateways überhaupt nutzten zu können, wird das Legacy-System durch dieses Migrations-
modell in drei Schichten eingeteilt:
• Schnittstellenschicht
• Anwendungsschicht
• Datenbankschicht
25
3 Migrationsmodelle
Abbildung 3.1: Nicht-zerlegbare Architektur [Sne99]
Gateways können hierbei zwischen Benutzer/Fremdsystem und dem Legacy-System liegen,
aber auch zwischen zwei Schichten des Legacy-Systems. Der Einsatz von Gateways hängt
maßgeblich von der Modularisierbarkeit des Legacy-Systems ab.[BS95]
Schritte des Chicken-Little-Ansatzes
Der „Chicken-Little-Ansatz“ hat 11 Schritte, in denen die Migration durchgeführt wird.
Diese Schritte sind weitesgehend unabhängig voneinander und können parallelisiert werden.
Diese Schritte werden in jedem Inkrement durchgeführt. Es können jedoch einzelne Schritte
ausgelassen werden. [BS95]
1. Das Legacy-System inkrementell analysieren Der erste Schritt ist zwingend und gleich
zum „Cold-Turkey-Ansatz“. Das Legacy-System muss analysiert werden um eine Spezifikation
für das neue System zu erstellen.
26
3.2 Chicken-Little-Ansatz
Abbildung 3.2: Zerlegbare Architektur [Sne99]
2.Das Altsystem inkrementell zerlegen In diesem Schritt soll das Legacy-System in einzelne
Module zerlegt werden. Dazu kann eine Refaktorisierung notwendig werden. Das Ziel, welches
mit diesem Schritt erreicht werden soll, ist eine schwache Kopplung der Module, sodass einzelne
Module durch das neue System ersetzt werden können.
3. Inkrementell die Zielschnittstellen entwerfen Als dritter Schritt müssen die benötigten
Schnittstellen entworfen werden. Gleichzeitig muss für jeden Schnittstelle entschieden werden,
ob ein Gateway benötigt wird.
4. Inkrementell das Zielsystem entwerfen In Schritt 4 können nun die einzelne Module für
das neue System entworfen werden. Somit wird das Legacy-System beziehungsweise dessen
Geschäftprozesse nachgebaut.
5. Inkrementell die Zieldatenbank entwerfen Dieser Schritt dient der Nachbildung der
Legacy-Datenbank. Hierbei wird lediglich eine neue Datenbank entworfen.
27
3 Migrationsmodelle
6. Die Zielumgebung inkrementell Installieren Die vom neuen System benötigte Hard- und
Software muss installiert und in Betrieb genommen werden.
7. Benötigte Gateways inkrementell erzeugen und installieren Die vorher festgelegten und
benötigten Gateways müssen beschafft oder implementiert werden.
8. Die Datenbank des Altsystems inkrementell migrieren Sofern der Datenbestand des
Legacy-Systems übernommen werden soll, kann dies über ein entsprechendes Gateway inkre-
mentell passieren. Dabei müssen die Daten aus der Legacy-Datenbank geladen werden, danach
gesäubert, konvertiert und neu gespeichert werden.
9. Das Altsystem inkrementell migrieren Entsprechend der Anforderungen an das neue
System, werden nun einzelne Module migriert. Folgende Kriterien können dabei entscheidend
sein:
• Einfache Migrierbarkeit
• Verursachte Kosten
• Bedeutung der Module für die Anwender
10. Die Benutzungsschnittstellen des Altsystems inkrementell migrieren Die Benutzer-
schnittstelle wird vom Legacy-System auf das Neu-System umgestellt. Damit die Benutzer
nicht zwischen der neuen und der alten Benutzerschnittstelle wechseln müssen, kann ein
Gateway eingesetzt werden.
11. Inkrementell auf das Zielsystem umsteigen Das neue System hat alle Module migriert
und alle Systemtests bestanden. Benutzer können nun nach und nach Umsteigen, um das
neue System im Arbeitsumfeld zu testen. Nachdem das System erfolgreich von einigen Nutzer
getestet wurde, können alle Benutzer auf das neue System umsteigen. Im gleichen Zug werden
die Reste des Legacy-Systems abgeschaltet.
3.3 Butterfly
Bisbal stellt in [BLWG99] einen weiteren Ansatz vor. Der „Butterfly-Ansatz“ wurde im Zug
dessen entwickelt, da man die Benutzung von Gateways bei einer inkrementellen Migration
kritisierte. Dieses Vorgehen wird zwar unter Betrachtung des Risikogesichtspunktes befürwortet,
allerdings erhöhen Gateways drastisch die Komplexität der Migration und steigern somit das
Risiko, dass das Migrationsprojekt scheitert.
Weiterhin werden an Gateways kritisiert:
28
3.3 Butterfly
• es werden keine Transaktionsmanager unterstützt. Daher kann die Konsistenz der Daten
zwischen Legacy- und Neu-System nicht sichergestellt werden
• es kann nicht zwischen Unterschieden in der Struktur und Repräsentation der beiden
Datenbanken vermittelt werden
• schwer zu implementieren und zu betreiben
Insbesondere wurden im Zusammenhang mit dem „Chicken-Little-Ansatz“ die Datenbank-
Gateways kritisiert.[BLWG99]
Ein Datenbank-Gateway muss bei jedem einzelnen Zugriff zwischen Legacy-System, Neu-System
oder beiden unterscheiden. Sofern auf beide System geschrieben werden soll, muss dies durch ein
2-Phasen-Commit-Protokoll geschehen. Die Konsistenz der Daten beim Schreiben zu garantieren
ist ein komplexes Problem und daher nur mit viel Aufwand realisierbar.[BS95] Der von Bisbal
in [BLWG99] vorgestellte „Butterfly-Ansatz“ beschreibt das die Interaktionen zwischen Legacy-
System und Neu-System nicht notwendig sind. Daher besteht keine Notwendigkeit für die
zusätzliche Komplexität durch Gateways.[BLWG99] Der „Butterfly-Ansatz“ legt als Grundlage
für eine erfolgreiche Migration die Migration der Daten fest. Er teilt die Migration in nur zwei
Teile auf:
• Das Kopieren der Daten aus dem Legacy-System
• Das Erstellen des Neu-Systems
Im ersten Schritt werden somit die Daten aus dem Legacy-System gesperrt. Daraufhin wird der
Datenbestand exportiert. Da jedoch die weitere Nutzung des Legacy-Systems nicht beeinträch-
tigt werden darf, werden hierbei sogenannte „TempStores“ angelegt. Sie halten alle Änderungen
am Datenbestand vor und geben diese auf Anfrage des Legacy-Systems heraus.[BLWG99]
Sobald die Daten aus dem Legacy-System vollständig gesichert sind, werden die Daten aus
dem ersten „TempStore“ kopiert. Hierbei kommt ein zweiter „TempStore“ zum Einsatz. Die-
ser Vorgang wird solange wiederholt, bis die voraussichtliche Zeit, die für das Sichern eines
„TempStores“ benötigt wird ausreichend klein ist. Nun kann das Legacy-System abgeschaltet
werden und auf das Neu-System umgeschaltet werden.
Im Vergleich zum „Cold-Turkey-Ansatz“ ergibt sich der Vorteil, dass das Legacy-System
nur sehr kurz abgeschaltet werden muss. Es fällt nur für die Zeit aus, die benötigt wird,
um die „TempStores“ anzulegen. Gegenüber dem „Chicken-Litte-Ansatz“ hat er den Vorteil,
dass die Migration jederzeit gestoppt werden kann, bevor das Legacy-System abgeschaltet
wird.[BLWG99] Der „Chicken-Litte-Ansatz“ bietet diesen Vorteil nicht, dass Teile des Daten-
bestandes nur in einem der System verfügbar ist, solange die Migration nicht abgeschlossen ist.
Für einen Stopp müsste erst die bisherige Migration rückgängig gemacht werden.
29

4 Analyse des bestehenden Systems
Dieses Kapitel stellt eine grundlegende Beschreibung und Auswertung des Legacy-Systems
dar. In den nachfolgenden Abschnitten werden zuerst das Altsystem und dessen Komponenten
beschrieben. Danach wird das Datenbanksystem des Legacy-Systems einer Ist-Analyse unter-
zogen und ausgewertet. Im Anschluss soll der geeignete Migrationsansatz sowie die Gründe für
die Wahl dieses Ansatzes erläutert werden.
4.1 Beschreibung Legacy-System
Das in diesem Fallbeispiel genutzte Legacy-System bildet den Verwaltungsprozess von Stu-
dierenden ab. In diesem System werden alle Studierenden einer Fakultät erfasst sowie ihrer
Studentischen Arbeiten und Anträge an den Prüfungsausschuss verwaltet. Das Legacy-System
setzt auf Microsoft Access auf und bildet die durch das ER-Diagramm gegebene Datenbank
ab. Zu den Kernfunktionen zählen:
• Anlegen und Verwalten eines neuen Studenten
• Anlegen und Verwalten einer neuen Studentischen Arbeit
• Arten von Studentischen Arbeiten:
– Abschlussarbeiten
∗ Diplomarbeit
∗ Masterarbeit
∗ Bachelorarbeit
– Studienleistungen
∗ Fachstudie
∗ Seminararbeit
• Anlegen und Verwalten eines neuen Antrags an den Prüfungsausschuss
• Antragsarten:
– Annullierung
– BAFöG-Antrag
– Einstufung
31
4 Analyse des bestehenden Systems
– Fristverlängerung
– Nebenfach
– Prüfungsrücktritt
– Studienleistung
– Zulassung
– Diverses
• Anlegen und Verwalten eines neuen Mitarbeiters
• Erzeugen eines Berichtes/Briefes für einen Studenten
Bei den zu erzeugenden Berichten/Briefen handelt es sich um Antwortbriefe auf gestellte
Anträge. Aber auch um Einladungen für mündliche Prüfungen.
4.1.1 Oberfläche Legacy-System
Die bisherige Oberfläche ist vollständig in Access angelegt. Abbildung 4.1 zeigt die
Oberfläche, die für das Erstellen von Studentischen Arbeiten genutzt wird. Nicht angezeigt
wird der Header der Oberfläche, in dem die Metadaten des Studenten angezeigt werden.
Die Oberfläche, die in Abbildung 4.2 zu sehen ist, ist die bisherige Ansicht zum Erstellen
von Prüfungsausschussanträgen.
Abbildung 4.1: Oberfläche zum Erstellen von Studentischen Arbeiten
32
4.1 Beschreibung Legacy-System
Abbildung 4.2: Oberfläche zum Erstellen vom Prüfungsausschussanträgen
4.1.2 Microsoft Access als Legacy-System
Microsoft Access stellt bei Migrationsprojekten einen größeren Aufwand als andere Legacy-
Systeme für die Reimplementierung dar. Access ist ein Vertreter der sogenannten Relational
Database Management Systems (kurz :RDBMS). Access bietet nicht nur die Funktionalität
eines RDBMS, sondern auch die Möglichkeit Oberflächen für den Zugriff auf den Datenbestand
zu erstellen. Desweitern ist es möglich mit Access auch Berichte anzulegen die als Vorlage für
automatisch generierte Drucke dienen. Somit bietet Access mehr als andere RDBMS und stellt
gleich alle Bestandteile des Legacy-Systems dar.
• Das Database Managament System (DBMS) um die Datenbestände auf dem Speicher zu
sichern.
• Die Benutzeroberflächen als Schnittstelle zwischen Anwender und DBMS
• Die Programmiersprache Visual Basic for Applications (VBA) um Anwendungen und
Benutzeroberflächen zu entwickeln.
In diesem Migrationsprojekt kann der letzte Punkt vernachlässigt werden. Dennoch stellen die
ersten beiden Punkte eine besondere Herausforderung für die Reimplementierung dar. Sofern
als Legacy-System Access im Einsatz ist, verschwimmt die Grenze zwischen Reimplementierung
und Neuentwicklung der Oberflächen noch weiter als bei einer herkömmlichen Migration, da
33
4 Analyse des bestehenden Systems
nicht der gesamte Umfang von Access reimplementiert wird. Es wird nur ein Teil reimplementiert
was zunächst mehr den Anschein einer Neuentwicklung hat, als den einer Reimplementierung.
4.2 Auswertung der Legacy-Datenbank
Da Microsoft Access bereits eine relationale Datenbank bereitstellt, können wir zur Ist-Analyse
das von Access exportierte ER-Diagramme 4.3 und 4.4 heranziehen. In den beiden Abbildungen
4.3 und 4.4 werden die Rot eingerahmten Tabellen für die bessere Darstellung in verkürzter
Variante abgebildet. Die für das Migrationsprojekt maßgebliche Tabellen sind zur Übersicht
im Anhang, ohne Relationen, dargestellt. Die Auswertung der Relationen ergeben folgende
kritische Relationen für die neue Datenbank:
• Für die Tabelle „Vorlesungen“ werden die Tabelle „tbl_IvIMit_1“, „tbl_IvIMit_2“,
„tbl_IvIMit_3“ verknüpft, jedoch nicht „tbl_IvIMit“.
• Unzutreffende Benennung folgender Tabellen:
– „tbl_FachSemester“
– „tbl_FachSemester1“
– „tbl_PruefungsAusschuss“
34
4.2 Auswertung der Legacy-Datenbank
A
bb
ild
un
g
4.
3:
ER
D
ia
gr
am
m
de
r
Ta
be
lle
fü
r
St
ud
en
tis
ch
e
A
rb
ei
te
n
35
4 Analyse des bestehenden Systems
A
bbildung
4.4:ER
D
iagram
m
der
Prüfungsausschusstabelle
36
4.3 Gründe für die Migration
4.3 Gründe für die Migration
Die Gründe für diese Migrationsprojekt ergeben sich aus drei Teilgebieten. Zum Einen er-
geben sich Gründe aus der Ist-Analyse der Legacy-Datenbank, welche bereits im Abschnitt
„Auswertung Legacy-Datenbank“ beschrieben wurden. Des weiteren ergeben sich Gründe aus
der Besonderheit mit Access als Legacy-System und aus den geänderten Anforderungen an
das System selbst. Die Hauptgründe die sich aus den geänderten Anforderungen ergeben sind
folgende:
• Plattformunabhängiges System
• Verbesserte Unterstützung von parallelem Arbeiten
• Ergänzen von Sicherheitsfunktionen
• Einführen von Rollen und Rechten
• Einschränken von Funktionalitäten für bestimmte Nutzergruppen
Die Gründe, die sich aus Microsoft Access als Legacy-System ergeben, sind, das zum einen die
Erneuerung der Lizenzen, sowie die eventuelle Inkompatibilität zu neuen Versionen vermieden
wird.
4.4 Migrationsansatz
Aus Microsoft Access als Legacy-System ergeben sich folgende Gründe: Zum Einen die Erneue-
rung der Lizenzen und zum Anderen die Vermeidung eventueller Inkompatibilität zu neuen
Versionen. Als Migrationsstrategie kommt der Cold-Turkey-Ansatz zum Tragen.
Ziel des Migrationsprojektes war ein neues System, welches alle funktionalen Anforderungen
erfüllt, die auch das Legacy-System erfüllt hatte. Als Folge des Migrationsprojektes sollte
der Anwender über ein System verfügen, das plattformunabhängig losgelöst von Microsoft
Access ist. Für das neue System wurden zusätzliche Anforderungen geschaffen, die im Zuge
der Migration eingefügt werden sollten. Die Schnittstellen zur Datenbank werden mit dem
Architekturmuster REST aufbereitet, sodass eine einfache Kommunikation über den Austausch
von JSON ermöglicht wird.
Desweiteren sollte das neue System über einen WebClient mit Multiuserunterstützung ver-
fügen. Im Zuge der Umstellung auf einen Web basierenden Client wurden auch moderne
Security-Features wie eine Authentifizierung des Nutzer sowie ein Rollen- und Rechtesystem
integriert. Da die Programmlogik des Ausgangssystems sich auf eine reine Verwaltungsaufgabe
beschränkt, ist eine weitere Analyse der Programmlogik nicht notwendig. Somit entfällt für
dieses Migrationsprojekt auch der Schritt der Reverse-Engineering-Maßnahme.
Der Fokus dieses Migrationsprojektes liegt jedoch nicht in der Reimplementierung der Benut-
zeroberflächen oder der Sanierungsmaßnahme, sondern in der Datenmigration. Sie stellt somit
den Hauptarbeitsbereich in diesem Projekt dar. Durch die bereits in Abschnitt „Auswertung
Legacy-Datenbank“ dargelegten Eigenschaften der Datenbank bedarf es bei der Datenmigration
37
4 Analyse des bestehenden Systems
eine Konversion nur auf der unteren Ebene. Auf der unteren Ebene wurden alle Datentypen
gegen die entsprechenden Datentypen einer MySQL-Datenbank definiert.
Auf der oberen Ebene wurden keine direkten Änderungen vorgenommen, lediglich die durch
die neu eingesetzten Technologien veränderten Beziehungen wurden angepasst. Somit findet
auf Programm und Oberflächenebene eine Reimplementierung statt, wobei bei der Migration
der Daten eine Konversion stattfindet.
Das Migrationsprojekt unterscheidet sich von einer Neuimplementierung. In diesem Projekt
müssen sich die Reimplementierungen der Programmlogik und Oberflächen an die durch die
Daten vorgebene Struktur halten. Da als Modell der Cold-Turkey-Ansatz gewählt wurde und
das Legacy-System bis zur Umstellung weiter genutzt wird, ist das Risiko eines Scheiterns
der Migration erhöht. Das Risiko erhöht sich maßgeblich dadurch, dass das laufende System
weiteren Änderungen unterliegt. Solche Änderungen können nur kurzfristig und schwer in
das Migrationsprojekt integriert werden. Sie stellen einen uneinsehbaren Mehraufwand für
das Projekt dar. Dennoch ist dieser Ansatz für ein Migrationsprojekt dieser Ordnung der
einzig sinnvolle. Eine schrittweise durchgeführte Migration wäre nur mit erheblichem Aufwand
möglich. Bei der schrittweisen Migration wäre neben der Entwicklung des Projektes auch
noch ein erheblicher Anteil der Arbeitszeit dafür benötigt worden, das Legacy-System neben
dem neuen System zu pflegen, sowie die Integrität der Daten zu gewährleisten. Ebenso wäre
aufgrund dass sich eine Microsoft Access Anwendung als eine nicht-zerlegbare Architektur
aufweist eine schrittweise Migration sehr schwierig. Dieses Migrationsprojekt zeigt daher
sehr gut, welche Risiken auftreten können und welche Herausforderungen an Migrationen im
Unternehmensumfeld gestellt werden.
38
5 Migration Altsystem
5.0.1 Zieldefinition des Migrationsprojektes
Für diese Arbeit ist als Ziel definiert, die bisherige Funktionalität des Informationssystems
neu abzubilden und den Datenbestand zu migrieren. Die Zieldefinition gilt als erfüllt, wenn
folgende Punkte erarbeitet wurden:
• Übernahme des gesamten Datenbestands
• Bereitstellen der bisherigen Funktionalität
• Ausführliche Dokumentation des Migrationsvorgangs
• Neuimplementierung der Programmlogik
• Dokumentation der Implementierung
• Anfertigung eines Handbuchs
• Durchführung des Export sowie des Imports des Datenbestandes
Zum Erreichen dieses Ziels haben wir zunächst einen Prototyp entwickelt, der die Machbarkeit
des Vorhabens prüfen soll. Ausgehend von diesen Ergebnissen wird das neue Informationssystem
entwickelt und in Betrieb genommen. Nach erfolgreichem Betriebstest werden die Daten
exportiert und in das neue System importiert. Anschließend werden weitere Funktionen und
Anforderungen implementiert. Der Entwicklungsprozess steht in ständigem Feedback zum
Anwender und wird als Individuallösung durchgeführt.
5.1 Entwurf
Beim Entwurf des Zielsystems mussten alle Anforderungen berücksichtigt werden. Jedoch
kam zusätzlich noch hinzu, dass die verwendeten Technologien frei zugänglich waren und
über eine sehr gute Dokumentation für spätere Erweiterungen des Systems boten. Zu Beginn
der Planung musste ein Technologie Stack erarbeitet werden, mit dem alle Anforderungen
abgedeckt werden konnten.
Der grundlegende Gedanke der Architektur ist eine Anwendung mit einer klassischen rela-
tionalen Datenbank und einer auf Spring basierenden Webanwendung, die Daten per REST-
Schnittstelle und einer Zugriffskontrolle nach außen freigibt. Ein authentifizierter Client kann
den Server via HTTP-Methoden wie GET, POST oder DELETE ansprechen und die Daten
bearbeiten.
39
5 Migration Altsystem
Abbildung 5.1: Technologiestack für die Reimplementierung des Legacy-Systems
5.1.1 Technologiestack
Abbildung 5.1 zeigt die Technologien, die bei der Reimplementierung des Legacy-Systems zum
Einsatz kommen. Aus dem Aufbau kann man von unten nach oben die Abhängigkeiten der
einzelnen Technologien ablesen. Alle Technologien werden in der zum 15.01.2016 aktuellsten
Version verwendet.
Programmiersprache Für die Sprache des neuen Systems wurde Java in der Version 1.8
gewählt, somit setzten alle andern Technologien abgesehen von der des Datenbankmanage-
mentsystem auf Java 1.8 auf.
Backend Für die Datenbasis wird eine MySQL-DB eingesetzt. MySQL ist eine weitverbreite-
tes und beliebtes Open-Source Datenbankmanagementsystem das neben einer guten Doku-
mentation auch ein breites Spektrum an Werkzeugen mit sich bringt. Für das ObjektRelation-
Mapping findet Hibernate Verwendung.
40
5.1 Entwurf
Spring Boot Spring ist ein Framework, das die Entwicklung von J2EE-Anwendungen erleich-
tern soll. Dabei setzt es auf Dependency Injection und Aspekt-Orienterte Programmierung
([EFB01, vgl.]). Außerdem bietet es eine Alternative zu EJB, indem es Transaktionen mit PO-
JOs (die nicht den gleichen Einschränkungen wie EJBs unterliegen) unterstützt [Joh05, vgl.]).
Mit Spring Boot sind die Entwickler von Pivotal einen Schritt weiter gegangen. Hiermit lässt
sich eine Webanwendung mit wenig Konfiguration einrichten, welche in einem eingebetteten
Tomcat direkt gestartet werden kann. Die Handhabung von Spring Boot ist so konzipiert, dass
die meisten Standardeinstellungen für gängige Webanwendungen verwendbar sind und keine
langen XML-Dateien angelegt werden müssen. Dies ist beim “großen Bruder” von Spring Boot,
dem Spring Framework, ein häufig kritisierter Punkt.
Spring Data JPA / REST Um die Anforderung abdecken zu können, wird Spring Data JPA
und Spring Data REST verwendet. Hiermit wird sowohl die Datenschicht als auch die Export-
Schnittstelle via REST weitestgehend automatisch von Spring bereitgestellt. Lediglich die
JPA-Entitäten werden manuell definiert.
Frontend Zur Reimplementierung der Oberflächen wurde Thymeleaf als TemplateEngine
eingesetzt. Durch die sehr gute Unterstützung von Spring lässt sich Thymeleaf schnell und
einfach den nötigen Umständen anpassen. Um interaktive Oberflächen zu erstellen wird die
JavaScript Bibliothek jquery eingesetzt.
Bootstrap Für das grundlegende Styling kommt die beliebte Bibliothek Bootstrap zum
Einsatz. Neben einem Responsive Design bietet Bootstrap auch Optionen für Navigationsmenüs
und Dropdownmenüs.
Spring Security Durch die neuen Anforderungen an die Sicherheit einer Web Applikation
findet in dieser Reimplementierung Spring Security Anwendung. Spring Security stellt neben
der Sicherung der einzelnen Seiten der Webanwendung auch den Login von Nutzern und das
Rechte und Rollen System bereit. Desweiteren sichert Spring Security gegen Standart Angriffe
wie „Session Fixation“, „Clickjacking“ oder „Cross-Site-Request-Forgery“. Damit muss man
für den Entwurf keine weiteren Sicherheitsaspekte beachten.
Liquibase Liquibase ist ein sogenanntes „Database Refactoring Tool“. Mit der Hilfe von
Liquibase können wir Unterschiede zwischen zwei Datenbanken ausfindig machen. Die gefunde-
nen Unterschiede lassen sich direkt durch Liquibase in sogenannten „changeLogs“ erfassen.
Desweiteren ist Liquibase in der Lage die so erzeugten „changeLogs“ auf die Überführungsda-
tenbank anzuwenden und diese an die Zieldatenbank anzupassen. Aus den „changeLogs“ kann
Liquibase direkt SQL-Scripte erzeugen zur manuellen Anwendung.
Außerdem ist Liquibase in der Lage Unterschiede im Datenbestand zu erkennen. Da dieses
Feature jedoch nicht für den Einsatz für initiale Migration geeignet ist, findet es in diesem
Projekt keine Anwendung. Durch die Unterstützung von vielen Datenbanken durch Liquibase
41
5 Migration Altsystem
lässt sich dieses Werkzeug für die meisten Migrationsprojekte einsetzen die eine Anpassung
der Datenstruktur benötigen.
Liquibase fließt hier als einzige Technologie nicht direkt in das neue System ein. Liquibase
wird lediglich als Werkzeug für die Unterstützung zur Datenbankmigration genutzt.
5.1.2 Entwurf der Datenbank
Migration der Access Entitäten zur JPA Entitäten
Für den Entwurf der Datenbank war es unerlässlich die Access Entitäten zunächst in geeigente
JPA Entitäten wandeln zu können. Nach [PRL07, vgl.] können folgenden Schritte ausgeführt
werden, um eine JPA-Entität zu erhalten:
• 1. Entfernen aller Interfaces (Bei Access nicht weiter notwendig)
• 2. Den Primärschlüssel in der neuen JPA-Entität mit @Id annotieren
• 3. Die Annotations @Table und @Column entsprechend der Access Struktur umsetzen
• 4. Die Annotations @ManyToOne, @OneToOne und @OneToMany entsprechend der
Access Struktur umsetzen
• 5. Transaktions- und Sicherheitseinstellungen in Repositories und Service Klassen verla-
gern
• 6. Datenmodell durch Controller Klasse für Client bereitstellen
ER-Diagramm der neuen Datenbank
Da keine strukturellen Änderungen am Datenbankschema vorgenommen wurden, werden die
gleichen ER-Diagramme des Legacy-Systems, in Kapitel 4.2, zur Erstellung der Datenbank
genutzt.
5.1.3 Entwurf des Neusystems
Migration der Geschäftslogik und Oberflächen
Für die gewählte Migrationsstrategie ist die Migration von Geschäftslogik und Oberflächen
nicht notwendig. Die Oberflächen wie auch die Geschäftslogik werden reimplementiert und den
bestehenden Gegenstücken des Legacy-Systems nachempfunden. Um jedoch eine möglichst
hohe User Experience zu erhalten, wurden die Oberflächen sowie die Geschäftsprozesse dem
Legacy-System nachempfunden. Die Oberflächen wurden um neue Komfort-Features ergänzt,
die das Legacy-System bisher nicht bot.
42
5.1 Entwurf
Abbildung 5.2: Entwurf der Studenten Ansicht
Im Allgemeinen ist bei einer Reimplementierung jedoch der Entwurf von Oberflächen und
Geschäftslogik losgelöst. Somit hat der Anwender beim Entwerfen großen Einfluss auf das
spätere Look and Feel des neuen Systems.
Oberflächen Durch das Lösen der Oberflächen von der Datenbank selbst, ergibt sich ein
sehr großer Freiheitsgrad für die Entwicklung der Oberflächen. Um die Migration und den
Umstieg möglichst einfach zu gestalten, orientieren sich die neuen Oberflächen an den bisherigen
Formen des Legacy-Systems. Durch direkte Validierung der benötigten Daten und Rechte,
reagieren die Oberflächen entsprechend ihrer Aufgabe bereits clientseitig auf den Anwender.
Im Gegensatz zu den starren Konstrukten der Legacy Formen wird die Usability des Tools
drastisch gesteigert. Zudem erhält der Anwender eine aufgefrischte und moderne Oberfläche.
Gleichzeitig wurden die Oberflächen an den Workflow angepasst. Die beiden Abbildungen 5.2
zeigen den Entwurf für die Studentendetailansicht und Abbildung 5.3 zeigt den Entwurf für die
Seite zum Anlegen von neuen Studentischen Arbeiten. Alle anderen Oberflächen orientieren
sich an diesen Entwürfen.
Rollen und Rechte Die Funktionalität für Rollen und Rechte wird mit Hilfe von Spring
Security entwickelt. Dazu wird das Datenmodell um zwei weitere Tabellen ergänzt. Zum Einen
um eine Nutzertabelle und zum Anderen eine Rechtetabelle. Dabei kann ein Nutzer beliebig viele
Rechte besitzen. Die Nutzer des Systems werden entsprechend in der Nutzertabelle angelegt.
Alle durchführbaren Operationen werden mit einem eigenen Recht in der Rechtetabelle angelegt.
Die Abbildung 5.1 zeigt die notwendige Annotation um eine Funktionalität an ein Recht zu
binden. Spring Security verfügt über dem im Beispiel verwendeten „@PreAuthorize“ auch
43
5 Migration Altsystem
Abbildung 5.3: Entwurf der Ansicht für Studentische Arbeiten
über „@PostAuthorize“. Wie durch die Benennung angedeutet, findet bei „@PreAuthorize“
eine Validierung der benötigten Rechte vor dem Durchführen und bei „@PostAuthorize“ nach
der Ausführung der Methode statt. Alle Methoden die Datenbankzugriffe erfordern, sollten
stets mit „@PreAuthorize“ annotiert werden.
Listing 5.1: Spring Security Annotation
@RequestMapping(value = "/edit", method = RequestMethod.GET)
@PreAuthorize("hasRole(’show_students’)")
\\@PostAuthorize("hasRole(’show_students’)")
public String showStudent(@RequestParam(value = "id", required = true) Integer id,
Model model, RedirectAttributes redirectAttrs) {
.
.
.
}
5.2 Implementierung
5.2.1 Implementierung der Datenbankanbindung
Die Datenbankanbindung wird im neuen System vollständig durch Spring Data realisiert.
Die genutzte Datenbank wird nur durch wenige Parameter in den Spring Konfigurationen
definiert. Durch die gegebenen Anforderungen an die Verfügbarkeit des Systems ist ein hotswap
der Datenbank nicht möglich. Durch die einfache Konfiguration durch eine Anpassung der
Parameter sowieso durch einen Neustart der Anwendung kann man dies jedoch erreichen. Die
drei gesetzten Parameter sind in 5.2 ersichtlich. Der erste Parameter stellt sicher, dass Hibernate
die Datenbank nicht bei jedem Neustart löscht und neu erstellt, sondern alle Daten beibehält
und die Änderungen am Schema in das bisherige integriert. Der zweite Parameter bestimmt
den genutzten SQL Dialekt, welcher hier dem MySQL Dialekt entspricht. Der letzte Parameter
gibt den Pfad zum Datenbankserver an. Spring setzt als Persistenslayer standardmäßig auf
44
5.2 Implementierung
Hibernate. Im Migrationsprojekt werden keine weiteren Einstellungen an Spring Data oder
Hibernate vorgenommen. Für komplexere Migrationsprojekte sollten hier die Konfigurationen
angepasst werden.
Listing 5.2: Spring Konfigration
spring.jpa.hibernate.ddl-auto=create-drop
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.MySQL5Dialect
spring.datasource.url=
Für die Anbindung an das Frontend benötigt Spring Data Entitäten. Durch die einfache
Annotation werden Entitäten in Java Code geschrieben und mit „@Entity“ annotiert. Spring
Data findet annotierte Entitäten selbstständig und erzeugt die notwendigen Datenbanktabellen
automatisch. 5.3 zeigt zum Einen die Standard Annotierung für Entitäten in Spring, sowie auch
die Annotierungen für die Indentifier. @Id legt die Variable als PrimaryKey fest, @Generated-
Value sorgt dafür, dass diese Variable automatisch inkrementiert wird. Durch @Column lassen
sich weitere Parameter für die Spalte übergeben. Der hier im Beispiel genutzte Parameter legt
den Namen der Spalte fest. Die Annotierung @Table nimmt, genau wie @Column, Parameter
entgegen, hier im Beispiel den Tabellennamen. Die so durchgeführte Benamung der Tabellen
und Spalten wird auch als explizites OR-Mapping bezeichnet. Im Migrationsprojekt wurde
bewusst auf explizites OR-Mapping gesetzt, um den Legacy-Datenbestand mit möglichst
geringer Anpassung übernehmen zu können.
Listing 5.3: Beispiel einer annotierten Java Entität
@Entity
@Table(name="tbl_StADAs")
public class Stada {
@Id
@GeneratedValue
@Column(name = "id")
@Getter
@Setter
private int id;
}
Desweiteren wurden im Projekt @ManyToOne und @OneToOne für die Verknüpfung von
Entitäten genutzt. Spring Data übernimmt in diesem Fall die korrekte Zuordnung automatisch.
Durch weitere Annotierung lässt sich die Methode für das Mapping selbst bestimmen. So kann
zwischen verknüpften Tabellen oder Spalten unterschieden werden.
Listing 5.4: Beispiel einer Annotierten für Joins
@Setter
@Getter
@ManyToOne
@JoinTable(name = "student_stadas")
private Student student;
@OneToOne
@Getter
@Setter
private Institut institut;
45
5 Migration Altsystem
Um die erzeugten Datenbank Entitäten nach außen zugänglich zu machen und sie letztendlich
mit dem Frontend zu konsumieren, benötigen wir noch sogenannte „Repositories“. Auch hier
unterstützt Spring Data massiv mit Annotationen und vorgegebenen Repositories. Somit muss
für eine voll funktionsfähige Schnittstelle lediglich das notwendige Repository angelegt werden;
Durch Spring gelingt das wie in 5.5. Die einzige Annotierung @Repository und eine Zeile Code
genügen, um hier die Standard Funktionalitäten zu realisieren. Vor ein solches Repository lässt
sich ein Service schalten, wodurch beliebige Anpassungen an die Funktionalität des Repositories
durchgeführt werden könnten. Dieses Migrationsprojekt benötigt jedoch keine weiteren als die
bereits durch das Standard Repository bereitgestellten Funktionen.
Listing 5.5: Beispiel einer Annotation für Repositories
@Repository
public interface StadaRepository extends JpaRepository<Stada, Integer> {
List<Stada> findAllByStudent(Student student);
}
Neben den genannten Annotationen wurden im Migrationsprojekt keine weiteren genutzt,
dennoch verfügt Spring Data über weitere Annotierungen und Einstellmöglichkeiten. Sie
ermöglichen die Anpassungen an unterschiedlichste Einsatzmöglichkeiten. Dadurch wird es
möglich mit Spring Data jede Legacy SQL Datenbank nach Spring Data zu migrieren. Die
weiteren Ausführungen und Erläuterungen von Spring Data sind nicht Bestandteil dieser Arbeit
und können in der Dokumentation eingesehen werden 1 .
5.2.2 Implementierung der Benutzeroberflächen
Wie in 5.1.3 beschrieben orientieren sich die Oberflächen an denen des Legacy-Systems. Für
die Darstellung wird die im Technologiestack angebene TemplateEngin Thymeleaf genutzt.
5.3 Export des Datenbestands aus Altsystem
Die bestehenden Daten werden direkt von Microsoft Access aus mit Hilfe des Exportools und
„ODBC Databases“ in die MySQL Datenbank exportiert. Durch die zuhilfename des Microsoft
Access-eigenen Tools sind für den Export und Import in die Überführungsdatenbank keine
weiteren Schritte notwendig. Ebenso stellt das Tool sicher, dass alle Daten korrekt in die neue
Umgebung übertragen werden.
1http://docs.spring.io/spring-data/rest/docs/2.5.2.RELEASE/reference/html/
46
5.4 Import und Evaluierung des Datenbestands
5.4 Import und Evaluierung des Datenbestands
Aufgrund der Datenbank Anpassungen für das neue System sind Änderungen am bestehen
Datenbankschema der Überführungsdatenbank notwendig. Um die Änderungen nicht manuell
und eventuell mit Fehlern zu überführen, nutzen wir Liquibase.
Liquibase erzeugt mit dem Befehl „diffChangeLog“ bei der Angabe von Überführungs- und
Zieldatenbank die benötigten „changeLogs“.
Listing 5.6: Beispiel für ein Liguibase diffChangLog
liquibase.sh --driver=com.mysql.jdbc.Driver \
--url=jdbc:mysql_leagcy \
--username=bob \
--password=bob \
diffChangeLog \
--referenceUrl=jdbc:mysql_new \
--referenceUsername=bob \
--referencePassword=bob
Durch die Ausführung von Liquibase werden beide Datenbanken aneinander angepasst. Somit
hat die Überführungsdatenbank nun dieselbe Schemastruktur wie die Zieldatenbank. Nun kann
die Überführungsdatenbank als Produktivdatenbank für das System verwendet werden.
Um die Migration abzuschließen und die Integrität der Daten sicherzustellen werden in dieses
Migrationsprojekt alle überführten Daten nochmals gegen die ursprüngliche Microsoft Access
Datenbank getestet. Der dazu entwickelte Datentester nutzt die Schnittstelle zur Access
Datenbank und jUnit als Testumgebung. Der Datentester wird in dieser Arbeit nicht weiter
beschrieben, da er lediglich die manuelle Überprüfung automatisiert.
Eine Überprüfung der Daten sollte bei jedem Migrationsprojekt Bestandteil des Verfahren
sein.
47

6 Zusammenfassung und Ausblick
Zu Beginn dieser Arbeit haben wir eine Problemstellung in Form eines reellen Migrationspro-
jektes definiert. Die zu migrierende Anwendung des Prüfungsausschusses als Microsoft Access
Anwendung sollte auf eine neue Umgebung migriert werden. Die Migration war notwendig,
da die Anwendung nicht plattformunabhängig war. Für die neuen Anforderungen war eine
plattformunabhängige Anwendung jedoch verpflichtend. Weitere Gründe für die Migration
waren die Ergänzung von Multinutzerzugriff sowie ein feingranulares Rollen- und Rechtesystem
der Nutzer. Im Anschluss an die Problemstellung wurden mögliche Migrationsmodelle und
Migrationsstrategien evaluiert und ihre Vor- und Nachteile betrachtet. Darauffolgend wur-
de das Altsystem analysiert. Hierbei wurden die wichtigsten Funktionalitäten des Systems
identifiziert und der dafür notwendige Datenbestand betrachtet. Anhand der Analyse sowie
der Evaluierung der Migrationstrategien wurde das Rahmenwerk für das Migrationprojekt
festgelegt. Dabei wurde ein neues Zielsystem entworfen, welche alle vorherigen Anforderungen
realisiert. Neben der Migration des Altsystems wurde das Zielsystem um das Rollen- und
Rechtesystem erweitert. Im letzten Kapitel haben wir die einzelnen Migrationsschritte für das
Zielsystem durchgearbeitet. Gestartet von den Datenbankanpassungen bis hin zum Export des
Datenbestands, dem Import und der anschließenden Evaluierung. Durch die Evaluierung und
die Inbetriebnahme des Systems haben wir das Migrationsprojekt erfolgreich abgeschlossen.
Wir haben somit anhand einer Beispiel-Migration die notwendigen Schritte für eine Migration
von Microsoft Access nach MySQl identifiziert. Diese Methodik lässt sich angepasst an die
jeweiligen Umstände auf jedes Microsoft Access Migrationsprojekt anwenden.
49
tbl_StADAstbl_Studenten tbl_PruefungsAusschusstbl_IvIMit
StADA_ID
StADA_STUD_ID
StADA_PB_ID
StADA_ABT_ID
StADA_Note
StADA_IvIMit1_ID
StADA_IvIMit2_ID
StADA_FA_ID
StADA_DO_ID
StADA_STAAT_ID
StADA_Beginn
StADA_Ende
StADA_Abgabe
StADA_Pause
StADA_Sperre
StADA_PA
StADA_NB
StADA_NrSTADA
StADA_Titel
StADA_Notiz
StADA_public
StADA_Freigabe
StADA_Abbruch
StADA_Versuch
StADA_USL
STUD_ID
STUD_MtrNr
STUD_MtrNr1
STUD_Name
STUD_Vorname
STUD_GebName
STUD_Geschlecht
STUD_Mail
STUD_FSUpdDatum
STUD_blnInaktiv
STUD_blnArchiv
STUD_ArchivJahr
STUD_Adresse
STUD_GebDat
STUD_Telefon
STUD_Mobil
STUD_Familienstand
STUD_SV_Nr
STUD_FS
STUD_STG_ID
STUD_STG1_ID
STUD_STG2_ID
STUD_PLZ_ID
STUD_STAAT_ID
STUD_STAAT1_ID
STUD_ASA_ID
STUD_DO_ID
STUD_BD_ID
STUD_KtoNr
STUD_KK_ID
STUD_privatversichert
STUD_KKOrt_ID
STUD_AG_ID
STUD_VDPrfgsAusschuss
STUD_VDPraedikat
STUD_VDNote
STUD_VDDatum
STUD_FS1_ID
STUD_HDNote
STUD_HDPraedikat
STUD_HDDatum
STUD_FS2_ID
STUD_Preistraeger
STUD_STAAT2_ID
STUD_J_ID
STUD_Urkunde
STUD_UrkundeVersand
STUD_UrkundeAbsender
STUD_Zeugnis
STUD_ZeugnisVersand
STUD_ZeugnisAbsender
STUD_AbschlussfeierDatum
STUD_AbschlussfeierTeilnahm
STUD_FS3_ID
STUD_FS4_ID
STUD_Notiz
STUD_ZweitWdh
STUD_Mint
STUD_EN
PA_ID
PA_STUD_ID
PA_AK_ID
PA_AFL_ID
PA_STD_ID
PA_PB_ID
PA_FS1_ID
PA_FS2_ID
PA_MD_ID
PA_PN_ID
PA_PrfgTeil
PA_VLSG1_ID
PA_VLSG2_ID
PA_PRFG_NE
PA_LVA_ID
PA_SEM_ID
PA_FU_ID
PA_DO_ID
PA_STAAT_ID
PA_FUP_ID
PA_anlegeDat
PA_betrDat
PA_divDat
PA_Notiz
PA_RuecktrittFrist
PA_Grund
PA_BewStatus
PA_VersuchPrfg
PA_nachholenNF
PA_nachholenPIA
PA_nachholenPIB
PA_nachholenThIA
PA_nachholenThIB
PA_Note
PA_Schein
PA_IvIMit_ID
PA_WiederVorlage
PA_AktenNotiz
PA_BafoeGLP
IvIMit_ID
IvIMit_Name
IvIMit_Vorname
IvIMit_Geschlecht
IvIMit_AG_ID
IvIMit_Institut_ID
IvIMit_AStat_ID
IvIMit_PAV
IvIMit_LVVO_ID
IvIMit_PB
IvIMit_PLZ_ID
IvIMit_Adresse
IvIMit_Abt_ID
IvIMit_Telefon
IvIMit_Durchwahl
IvIMit_Fax
IvIMit_GebDat
IvIMit_PrivTel
IvIMit_Mobil
IvIMit_PrivFax
IvIMit_Notiz
IvIMit_PrivMail
IvIMit_IvIMail
IvIMit_Homepage
IvIMit_Buero
Literaturverzeichnis
[72098] IEEE Standard for Software Maintenance. IEEE Std 1219-1998, S. i–, 1998.
doi:10.1109/IEEESTD.1998.88278. (Zitiert auf Seite 15)
[Bec00] K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 2000. (Zitiert auf Seite 25)
[BLWG99] J. Bisbal, D. Lawless, B. Wu, J. Grimson. Legacy Information Systems: Issues and
Directions. IEEE Software, 16(5):103–111, 1999. doi:http://doi.ieeecomputersociety.
org/10.1109/52.795108. (Zitiert auf den Seiten 23, 28 und 29)
[BS95] M. L. Brodie, M. Stonebraker. Legacy Information Systems Migration: Gateways,
Interfaces, and the Incremental Approach. Morgan Kaufmann Publishers Inc., San
Francisco, CA, USA, 1995. (Zitiert auf den Seiten 13, 14, 23, 24, 25, 26 und 29)
[EFB01] T. Elrad, R. E. Filman, A. Bader. Aspect-oriented Programming: Introduction.
Commun. ACM, 44(10):29–32, 2001. doi:10.1145/383845.383853. URL http:
//doi.acm.org/10.1145/383845.383853. (Zitiert auf Seite 41)
[Glö07] H. Glöckle. IT-Integration und Migration —Konzepte und Vorgehensweisen. HMD
Praxis der Wirtschaftsinformatik, 44(5):7–19, 2007. doi:10.1007/BF03341120. URL
http://dx.doi.org/10.1007/BF03341120. (Zitiert auf Seite 16)
[HC96] M. A. Hoffman, D. L. Carver. Reverse engineering data requirements. In Aerospace
Applications Conference, 1996. Proceedings., 1996 IEEE, Band 2, S. 269–277 vol.2.
1996. doi:10.1109/AERO.1996.495931. (Zitiert auf den Seiten 14 und 20)
[Joh05] R. Johnson. J2EE development frameworks. Computer, 38(1):107–110, 2005.
doi:10.1109/MC.2005.22. (Zitiert auf Seite 41)
[PRL07] D. PANDA, R. Rahman, D. Lane. EJB 3 in Action. Manning Publications Co.,
1.Grennwich, CT, USA, 2007. (Zitiert auf Seite 42)
[Sne99] H. M. Sneed. Objektorientierte Softwaremigration. Addison-Wesley, 1999. (Zitiert
auf den Seiten 7, 16, 18, 20, 21, 26 und 27)
[SWH10] H. Sneed, E. Wolf, H. Heilmann. Softwaremigration in der Praxis: Übertragung
alter Softwaresysteme in eine moderne Umgebung. dpunkt-Verlag, 2010. URL
https://books.google.de/books?id=t6YXPQAACAAJ. (Zitiert auf den Seiten 7, 14,
16, 17, 18, 19, 20 und 21)
51
Literaturverzeichnis
[THHB06] P. Thiran, J.-L. Hainaut, G.-J. Houben, D. Benslimane. Wrapper-based evolution
of legacy information systems. ACM Transactions on Software Engineering and
Methodology (TOSEM), 15(4):329–359, 2006. (Zitiert auf Seite 21)
Alle URLs wurden zuletzt am 10. 07. 2016 geprüft.
52
Erklärung
Ich versichere, diese Arbeit selbstständig verfasst zu haben.
Ich habe keine anderen als die angegebenen Quellen be-
nutzt und alle wörtlich oder sinngemäß aus anderen Werken
übernommene Aussagen als solche gekennzeichnet. Weder
diese Arbeit noch wesentliche Teile daraus waren bisher Ge-
genstand eines anderen Prüfungsverfahrens. Ich habe diese
Arbeit bisher weder teilweise noch vollständig veröffentlicht.
Das elektronische Exemplar stimmt mit allen eingereichten
Exemplaren überein.
Ort, Datum, Unterschrift