Herzlich willkommen zum Vorlesungsteil über Migration, Software-Migration ist ein wichtiger Teil von Software-Re-Engineering.
Wir haben uns mit zentral mit dem Staged Model beschäftigt und dabei gesehen,
es gibt Wechsel, es gibt Teile,
die abgelöst werden müssen, Teile,
die einen schlechten Zustand sind.
Es gibt das Closed Down, wo man dann Teile vielleicht abschaltet.
All diese Sachen führen zu Veränderungen, die in irgendeiner Form
Wechselaustausch oder sowas benötigen.
Und das ist darum geht es bei Migration
Wir haben hier erst mal ein paar Fragen,
auf die werden wir dann jeweils wieder eingehen.
Ich starte mal damit, den Begriff zu erläutern. Ja,
diese Begriffe, diese Definition ist eine sehr einfache Definition.
Es geht eigentlich nur um die Umgebung.
Und zwar Überführung eines Softwaresystems in eine andere Zielumgebung.
Hier steht jetzt schon mal Zieleumgebung, wir werden gleich sehen,
dass das verschiedene Ziele sind. Ganz häufig ist es so,
dass es eigentlich gar nicht um funktionale Weiterentwicklung geht,
sondern es geht um andere Anforderungen,
die sich geändert werden
Die sich ändern müssen, nicht funktionale Anforderungen. Solche Anforderungen können
zum Beispiel sein, dass das Zeitverhalten nicht den heutigen Anforderungen entspricht.
Zum Beispiel, wir brauchen einen schnelleren, eine schnellere Verarbeitung.
Es kommt zu, wir haben heute viel mehr Anfragen. Das passiert oder wir wollen mit anderen Systemen zusammenarbeiten,
zum Beispiel, wir haben ein Warnwirtschaftssystem,
was neu in die Firma eingeführt wird und was mit dem alten System nicht mehr zusammenarbeitet,
manchmal aber auch, und das würde ich jetzt mal hier so ergänzen,
manchmal gibt es auch solche Punkte wie Kosten, zum Beispiel, dass wir oder Verfügbarkeit von Entwicklern.
Und dabei geht es nicht um die Personen,
sondern vor allen Dingen um das Know-how, zum Beispiel,
wir haben ein großes System mit Cobol und es gibt immer weniger Entwickler,
die Cobol hinreichend gut beherrschen,
dass wir sie da einsetzen können oder was die Kosten betrifft,
wir haben ein System, was plötzlich viel mehr Lizenzkosten kostet als früher,
vielleicht weil die Firma gekauft worden ist,
der neue Besitzer möchte mehr Geld verdienen,
er ändert kurzerhand mal das Lizenzmodell und dann sagen wir,
oh, da können das nicht mehr wirtschaftlich betreiben,
wir wollen jetzt irgendeiner Form eine Veränderung vornehmen.
In jedem Fall geht es um rein technische Transformationen,
also Transformationen im Sinne von Umformungen, ja,
es gibt im Normalfall keine fachlichen Änderungen.
Die fachlichen Änderungen wären zum Beispiel, wir wollen neue Geschäftsprozesse,
wir wollen geänderte Datenfelder, wir wollen andere Regeln.
Sowas gibt es meistens nicht, wenn wir für immer Migration reden. Das heißt,
die Systemfunktionalität bleibt unverändert und das bietet uns den Vorteil,
dass wir zur Absicherung des Migrationsvorgangs können wir testen, durchführen.
Alle Tests, die wir haben, die verwendbar sind,
sollten durchlaufen, auch nach der Migration.
Hier unten steht eine Quelle angegeben mit dem Link.
Diesen Link finden Sie auch im Model. Ich möchte Sie einladen,
das alles hier nachzulesen, was ich hier sage.
Es gibt natürlich, ich gehe ein bisschen über hinaus,
was hier ist, was hier diese Arbeit,
die sich hier lesen können, ist nicht so sehr lang.
Sie ist das Ergebnis eines Workshops der Gesellschaft für Informatik.
Das ist für mich die Gelegenheit, sie dazu einzuladen.
Als Informatiker sollte man seine Berufsgenossenschaft, seine Berufsprofession Gemeinschaft kennen, unterstützen.
Ich bin seit vielen Jahren Mitglied der Informatik der Gesellschaft für Informatik und kann nur sagen,
dass ich sehr davon profitiert habe, dort Kollegen zu treffen.
Dieser Workshop-Software-Engineering, der findet jährlich in Bad Thonev statt.
Dort werden bestimmte Themen verarbeitet. Hier eben das Thema 2005
wurde mal Migration bearbeitet, wenn jemand von Ihnen da Interesse hat,
kann man sich da ganz einfach anmelden.
Das finden Sie alles im Netz. Ja, wie gesagt,
der Stoff dieser Vorlesung steht zum großen Teil,
habe ich im großen Teil in Andehnung an die Ergebnisse dieses
Workshops strukturiert und Sie können dort einiges nachlesen
Hier gleich noch die Frage hier für Frage 1 Beispiele für geänderte Anforderungen. Ja,
da hatten wir jetzt hier gerade Performance in der Operabilität,
gestiegene Kosten, dass das für ein Know-how nicht mehr verfügbar ist.
Es könnte aber auch sein, dass die Geräte nicht mehr verfügbar sind.
Vielleicht haben sie gehört, vor einigen Jahren,
als dann die NASA neue Raketen einsetzen musste,
weil die Bordcomputer und die Chips der Bordcomputer nicht mehr verfügbar waren.
Also da auch solche Sachen Verfügbarkeit von Ersatzteilen kann dazu führen,
dass wir hier einen Austausch vornehmen müssen.
Okay, es gibt verschiedene Arten von Änderungen,
die damit zusammenhängen und die möchte ich kurz mit Ihnen durchgehen.
Das erste ist, es könnte sein, dass die Hardware sich ändert.
Dass wir also eine Migration haben von der Hardware-Plattform.
Das könnte zum Beispiel sein Mainframe von Mainframe weg zu einem kleinen Serversystem oder so etwas,
wird zu einem GC Oder Service, basierte Lösung.
Es könnte genauso gut sein, dass wir etwas bisher,
was auf einem Großrechner lief,
dass wir das jetzt auf ein Tablet bringen wollen oder so etwas.
Das wäre ein Beispiel. Wenn wir, häufig sind diese Dinge,
die vier Boxen, die ich hier angegeben habe,
das ist häufig nicht miteinander zu trennen.
Also wenn wir hier diesen Mainframe verlassen, den Großcomputer,
der sehr leistungsfähig ist, aber der hat eine spezielle Architektur.
Und wenn wir den verändern wollen, müssen wir natürlich auch die Architektur verändern.
Doch wenn wir, die sind ein bisschen danach gegliedert,
diese vier Boxen, was steht denn im Vordergrund?
Manchmal steht die Migration der Architektur im Vordergrund. Und da könnte es sein,
dass wir weg von einem Modulit wollen, monolithischer Turm Lässt Architektur.
Ja, also zum Beispiel zu einem serviceorientierten System,
was ja flexibel erweitern können, das wäre,
oder dass wir zu einer Mehrschichtenarchitektur wechseln wollen.
Doch diese ermärchlichen Architektur macht man nicht als Selbstzweck,
sondern man macht sie zum Beispiel,
weil wir eine komplette Schicht durch etwas anderes ersetzen,
ausbauen oder sowas. Manchmal gibt es auch einen Wechsel,
der sich vorrangig oder vor allem entzündet dran, an der Entwicklungsumgebung.
Zum Beispiel, wenn wir die Programmiersprache wechseln.
Zum Beispiel weg von Cobol zu etwas anderen.
Sie schabt oder Java oder so etwas. Oder von,
es gibt Anwendungen, die über die Jahre gewachsen sind,
in den 90ern mit Visual Basic
Und man möchte die zu einer Java-Applikation wechseln.
Auch das wäre denkbar. Dann ist es natürlich auch so,
dass ich die anderen Aspekte, ja, die Architektur wird
sich ändern oder das geht einher mit einer Änderung der Hardware.
Das wird sich auch, das würde auch sein.
Als dritten, vierten Block habe ich hier Systemsoftware-Migrationen angegeben.
Damit ist gemeint oder ein Beispiel dafür ist,
der wechselt des Datenbanksystems
Oder wir wollen eine Mittelwehr einführen, die transparente Bedienung,
transparente Verteilung ermöglicht.
So etwas wäre hier denkbar bei der letzten Kategorie.
In diesem Fall auch würden wir
jeweils die Architektur mit verändern
Diese Veränderungen können, wir Teile des Systems stattfinden, eben für die Teile,
wo es nicht mehr weitergeht. Zum Beispiel, wir wollen,
wir wollen durchaus ein paar Sachen auf dem PC,
hatten wir vorher schon auf dem PC gehabt,
aber es bleiben ein paar Sachen auf dem Mainframe,
aber die Sachen, die häufiger häufigeren Änderungen unterworfen sind,
werden hier abgelöst.
Oder es bleibt ein Teil in Cobol,
aber nur ein Teil wird in eine objektorientierte Programmiersprache überführt.
Auch das wäre denkbar. Zu diesen Teilen, zu diesem Projekt,
Brücken zwischen alt und neu werden wir im letzten Abschnitt kommen,
wenn wir über Rapper und Adapter sprechen.
Es gibt verschiedene Aspekte, die zu beachten sind,
wenn wir benutzerischen, wenn wir,
jetzt bin ich schon beim ersten Blump hier, wenn wir Migration durchführen.
Und zwar müssen wir einerseits auch daran denken,
dass die Daten zu migrieren sind. Bei den Daten,
da geht es nicht nur darum, dass wir die Daten mitnehmen.
Natürlich ist das ganze Voraussetzung, ja, wir können nicht,
sie können nicht einfach bei einer Bank das auf das System
wechseln und die Leute haben alle einen Kontostand null oder
der Kredit ist plötzlich weg.
Das geht natürlich nicht,
sondern wir müssen die Daten mitnehmen
Und dazu gehört natürlich der Datenbestand, der ebenfalls mitzunehmen ist,
das bedeutet auch zu transformieren, umzuwandeln,
andere Dateiformate oder einfach nur auf eine andere Maschine kopieren,
dann auch die Datenstrukturen.
Ja, vielleicht gibt es für Long oder Intager
oder auch für Charakter oder Arace oder Listen andere Datenformate,
die müssen dann entsprechend umgeformt werden
Und manchmal, gerade für relationale Datenbanken, müssen Schemata auch verändert werden.
Diese Migration der Daten ist eine große Herausforderung für sich selbst,
weil wir ganz häufig damit zu tun haben,
wir können nicht einfach die Daten, wir formulieren ein paar Konversionsregeln,
Transformationsregeln und lassen das Ganze laufen.
Wir werden dabei eine ganze große Menge Fehlermeldungen bekommen,
wo eben in einem Feld für eine Postleitzahl eben nicht eine Tostleitzahl steht,
weil es hier Datenprobleme mit der Datenqualität gibt,
da müssen die Daten erstmal verbessert werden.
Wir müssen uns um Fehler kümmern
Wir müssen händisch nacharbeiten. Alles das passiert hier bei
der Datenmigration auch mit. Da gehen wir jetzt nicht weiter
drauf ein. Wer damit mal zu tun hat,
wird dann nachlesen müssen, wird sich weiter informieren müssen.
Was gibt es da für Möglichkeiten? Was kann man da tun?
Was helfen Werkzeuge? Wie geht man vor mit Vorring,
um das Risiko zu verringern? Wenn wir sagen, ja,
wir wollen migrieren, dann meinen wir eigentlich meist das Programm.
Das heißt, bei den Programmen geht es natürlich um die Programmlogik.
Aber es sind auch Schnittstellen und Protokolle
Anzupassen. Protokolle hatten wir schon im Zusammenhang mit Zustandsdiagrammen,
wo wir den Protokollzustandsautomaten zum Beispiel gezeigt haben.
Ja, also ein Programmsystem hat verschiedene Zustände und diese Zustände
werden durch ihre Ereignisse getriggert. Also was passiert ja an
den Schnittstellen. So etwas müssen wir da auch ändern.
Ja, Benutzungsschnittstelle, die wird häufig auch migriert.
Manchmal ist das auch der primäre Anlass,
weil wir die gleiche Funktionalität aber jetzt mit einem anderen Look
and Feel
haben wollen
Oder auf einer anderen, mit anderer Betriebssystem-Software. Also wir haben durchaus
hier Systemsoftware, was hier den untersten Punkt haben hier.
Da gibt es durchaus auch, dass das der Grund ist,
der Auslöser ist, weil wir die grafischen Benutzeroberfläche verändern wollen oder verändern müssen.
Ja, und diese grafische Benutzeroberfläche sind nicht nur die Gui-Elemente,
sondern auch, dass wir die Anordnung, die Gliederung verändern.
Also, das Layout und die Gliederung der Ui, muss da häufig,
ist da häufig betroffen und sie können sich vorstellen, wenn wir,
dass wir die Nutzer, die Benutzer da irgendwie mitnehmen müssen.
Soweit zu den Aspekten, die wir hier sehen,
ich schaue nochmal auf die Fragen zurück, welche Fragen wir dabei haben,
also hier war das Wort gegen die Frage 3,
oh, das sollte nicht schreiben hier,
das sollte man geringer geben, einen Leuchtpunkt,
also einzelne Arten von Migrationen hängen hier so zusammen,
dass das eine immer das andere bedingt.
So, wir haben die Frage zwei übergangen, Qualitätsmerkmale nach ISO,
die durch Migration betroffen sind, die Migration erleichtern.
Dazu müssen Sie nochmal zurückschauen, ich mache das jetzt mal
nicht, um Sie nicht beim Zuschauen zu irritieren.
Schauen Sie zurück zu den Qualitätsmerkmalen nach ISO.
Was sind da die wesentlichen, die wir zu betreffen?
Die wird anzuschauen haben und das würde ich gern mit Ihnen
offen lassen für den interaktiven Teil.
Das würde ich gerne mit Ihnen in der Fragerunde diskutieren.
Ansonsten können Sie es durch pures Lesen auch feststellen,
welche der Qualitätsmerkmale primär betroffen sind,
aber es gibt noch ein paar,
die auch mit dazu im Zusammenhang stehen