Reengineering und Datenmigration einer Rückwaren-Datenbank in eine neue Systemumgebung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Motivation
1.2 Problemstellung und Praxisphase
1.3 Aufbau der Arbeit

2 Grundlagen des Reengineering
2.1 Definitionen
2.2 Einführung in das Reengineering
2.2.1 Technisches Reengineering
2.2.2 Reengineering aus Projektmanagement Sicht
2.2.3 Risiken des Reengineering
2.3 Best Practices und Strategien des Reengineering
2.4 Migration

3 Konzept des Reengineerings
3.1 Das Ausgangssystem
3.2 Gründe und Strategien für ein Reengineering
3.3 Bestimmung des Zielsystem

4 Durchführung des Reengineering
4.1 Vorgehensweise
4.2 Entwurf der neuen Datenbank
4.3 Implementierung der Zieldatenbank
4.4 Migration der Daten
4.5 Reengineering der Programmlogik und der Benutzeroberfläche
4.6 Problematiken
4.7 Alternative Lösungsansätze

5 Fazit und Ausblick
5.1 Zusammenfassung
5.2 Fazit
5.3 Ausblick

Literaturverzeichnis

Zusammenfassung

Kaum ein Industriezweig entwickelt sich so schnell wie die IT-Branche. Die Rechnerkapazitäten und deren Leistungen steigen immer weiter, sodass ebenso die Anforderungen an die Software zunehmen. Anwender, welche die damit verbundenen Möglichkeiten für sich nutzen wollen, sind folglich gezwungen, sich diesem Prozess anzupassen.

Ziel dieser Bachelorarbeit ist es, eine Rückwaren-Datenbank, die Mitte der Neunzigerjahre mit der mittlerweile veralteten Software Microsoft Access 97 entwickelt und mit der bis dato gearbeitet wurde, in eine zeitgemäße Systemumgebung zu übertragen.

Die Hauptaufgabe besteht darin, eine Datenbank, zu der es keine Dokumentation gibt, zu analysieren sowie das sogenannte Reengineering durchzuführen. Damit gilt es, ein Konzept zu entwickeln, mit dem man das neue Datenbanksystem projektieren kann. Zusätzlich steht im Fokus dieser Bachelorarbeit die Migration von Datensätzen aus der Struktur der ursprünglichen Rückwaren-Datenbank in die neue Systemumgebung.

Diese Arbeit dient nicht dem Zweck, neue Strategien in diesem Bereich zu entwickeln. Sie gibt vielmehr einen Überblick über den aktuellen Stand der Wissenschaft, verdeutlicht anhand des Fallbeispiels konkrete Problemstellungen und zeigt Lösungswege auf. Im Fokus steht hier insbesondere die Migration der Daten, welche aufgrund der unkonventionellen Ablage im Ausgangssystem eine besondere Herausforderung darstellt.

Der Verfasser dieser Bachelorarbeit hat bereits neben dem Studium als Werkstudent bei einer Migration von einem Unternehmen zu einem anderen mitgewirkt. Bei solchen Großprojekten bleibt oftmals keine Zeit, sich um die „kleinen Projekte“ zu kümmern, weshalb sich die Datenbanken häufig unverändert jahrzehntelang im Einsatz befinden. Aus diesem Grund besteht das Interesse daran, diesen Sachverhalt näher zu beleuchten.

Abbildungsverzeichnis

2.1 Zusammenhänge der einzelnen Begriffe nach Chikofsky und Cross [CI90]

2.2 Migrationsarten nach Sneed [SWH10]

2.3 Hierarchische Graphen

2.4 Beispiel einer Portfolio-Analyse nach Sneed [Sne95]

2.5 Projektrisiken nach Sneed [Sne99]

2.6 Ausschnitt möglicher Reengineering Patterns nach Nierstrasz, Ducasse, und Demeyer [NDD09]

3.1 Legacy-System der Rückwaren-Datenbank. Überblick der Befund Erfassung. . .

3.2 Legacy-System der Rückwaren-Datenbank. Überblick der Auflistung der Befunde

4.1 Entity-Relationship-Modell des Ausgangssystem

4.2 Vergrößerter Ausschnitt des Entity-Relationship-Modell aus Abbildung 4.1

4.3 Sitemap mit Lupe

4.4 Vergrößerter Ausschnitt der Sitemap aus Abbildung 4.3

4.5 Datenbankentwurf als Entity Relationship Modell. Physical Data Model

4.6 Vergrößerter Ausschnitt der zentralen Entität OrderDevice und der Nachbarn links davon

4.7 Vergrößerter Ausschnitt der zentralen Entität OrderDevice und der Nachbarn rechts davon

4.8 Vergrößerter Ausschnitt der zentralen Entität OrderDevice und der Entität oberhalb

4.9 Vergrößerter Ausschnitt der zentralen Entität OrderDevice und der Nachbarn unterhalb

4.10 Vergrößerter Ausschnitt der zentralen Entität OrderDevice und der M:N Beziehung

4.11 Einen Ausschnitt der aufbereiteten Daten für die Entität OrderDevice

4.12 Sequenzdiagramm der durchgeführten Datenmigration

4.13 Tabelle Picture mit dem Attribut Photo in der das Bild als Binärdaten abgelegt wird

4.14 Testapplikation um das abgespeicherte Bild auszulesen

4.15 Rückwaren-Erfassung im Ausgangssystem

4.16 Rückwaren-Erfassung nach dem Reengineering

Tabellenverzeichnis

2.1 Wartungsaktivitäten nach der Studie von Fjeldstad und Hamlen [FH83]

Listingverzeichnis

2.1 Ein unbekanntes Programm

4.1 Auszug aus dem fehlerhaften SQL-Server 2012 Skript

4.2 Auszug aus dem funktionierenden SQL-Server 2008 Skript

Kapitel 1 Einleitung

Grundlage für die vorliegende Arbeit stellt die absolvierte Praxisphase des Autors bei einer führenden Firma im Energiemanagementbereich in Süddeutschland dar. Im Bereich der Motivation gelangt das Interesse an diesem Thema zur Erläuterung und näher zur Vorstellung.

Das Unterkapitel 1.2 „Problemstellung und Praxisphase“ gibt einen kurzen Einblick in das Thema und deren Problematik.

Zum Schluss dieses Kapitels folgen im Unterkapitel 1.3 detaillierte Angaben zur Struktur dieser Arbeit.

1.1 Motivation

Heutzutage schreitet die Entwicklung in der IT-Branche so schnell voran, dass Unternehmen oftmals ihre Systeme und Anwendungen nicht innerhalb angemessener Zeit an die neuen Gegebenheiten anpassen können.

Es wird zum Beispiel ein neues Betriebssystem oder eine Anwendung von den Herstellern auf den Markt gebracht. Dadurch geraten Unternehmen normalerweise in Zugzwang, ein Upgra- de der Systeme und Anwendungen durchzuführen, um „up to date“ zu bleiben. Die großen Softwarehersteller wie Microsoft unterstützen die Vorgängerversionen noch für einen gewissen Zeitraum, ehe sie die Dienste dafür einstellen. Dies kann zur Folge haben, dass die eigenen IT- Sicherheitsvorkehrungen als Vorgaben im Unternehmen die Funktionalität von Anwendungen weiter einschränken. Somit werden Netzwerkanbindungen von alten Systemen getrennt, obwohl die Software noch aktiv ist. Eine Migration solch einer Anwendung zu einem aktuellen System gestaltet sich sehr langwierig und bedeutet ohne Dokumentation ein größeres Unterfangen.

Am Beispiel einer Rückwaren-Datenbank findet das Reengineering in genau solch einem Beispiel statt. Dazu aber später in Kapitel 3 „Konzept des Reengineerings“ und in Kapitel 4 „Durchführung des Reengineering“ mehr.

Die Rückwaren-Datenbank war eine Eigenentwicklung des Unternehmens, die bei einer Firmen- übernahme weitergenutzt wurde. Große Systeme wie das Warenwirtschaftssystem SAP wurden dabei erfolgreich zum neuen Unternehmen migriert, aber vergleichsweise kleine Anwendungen,wie die Rückwaren-Datenbank, der Qualitätssicherungsabteilung, wurden isoliert auf einem lokalen Client PC ohne Netzwerkanbindung lauffähig gehalten. Datenbanken sind aus dem ITUmfeld so gut wie nicht mehr wegzudenken. Ebenso ist diese Rückwaren-Datenbank aus dem Unternehmen nicht mehr wegzudenken, weshalb es Zeit wurde, ein Reengineering sowie eine Migration der Daten auf eine neue Plattform durchzuführen. Bei der Firmenübernahme konnte der Autor dieser Arbeit bereits Erfahrungen mit Migrationen sammeln.

„Datenbanken gehören neben Tabellenkalkulationen und Textverarbeitung zu den allerersten Rechneranwendungen.“ [Dae13]

„Datenbanksysteme ermöglichen die integrierte Speicherung von großen Daten- beständen, auf die mehrere Anwendungen gleichzeitig zugreifen können.“ [SSH11]

1.2 Problemstellung und Praxisphase

Aufgrund des Fortschritts der technischen Entwicklungen und von verschiedenen Sicherheits- richtlinien des Unternehmens wird die aktuelle Rückwaren-Datenbank, die 1998 als Microsoft Access 97 Datenbank eingeführt wurde, nur noch als lokale Client Installation betrieben.

Das Projektziel, während der Praxisphase im Rahmen des Bachelorstudiengangs Informatik, bestand darin, die Datenbank in der Rückwarenabteilung zu analysieren sowie ein zukunftsfähi- ges Konzept mit Mehrbenutzerzugriff im Netzwerk zu entwickeln. Zusätzlich sollten die 15.000 Datensätze, die sich in der zu analysierenden Datenbank befinden, in die neue Datenbank mi- griert werden.

1.3 Aufbau der Arbeit

Kapitel 2 enthält die Grundlagen und eine Einführung in das Reengineering, überdies verschiedene Konzepte, Best Practice und Strategien des Reengineering. Außerdem werden zwei Vorgehensmodelle der Migration vorgestellt.

In Kapitel 3 wird das Ausgangssystem des Fallbeispiels, Gründe und Strategien des Reen- gineerings bezogen auf die Rückwaren-Datenbank erläutert sowie das Zielsystem bestimmt.

In Kapitel 4 geht es um die konkrete Durchführung des Reengineering am Beispiel der RückwarenDatenbank. Außerdem wird noch auf Problematiken während des Projekts eingegangen.

Kapitel 5 inkludiert eine Zusammenfassung des Projekts, das Fazit und einen Ausblick.

2.Grundlagen des Reengineering

In diesem Kapitel werden der Begriff und die Bedeutung des Reengineering näher beleuchtet und vorgestellt. Ebenso werden die Zusammenhänge der Begriffe Reengineering, Forward Engineering, Reverse Engineering, Redocumentation, Design Recovery und Software-Wartung erörtert und aufgezeigt.

Es folgt ein Einblick in das Thema Migration bzw. Datenmigration und der Unterschied zu Software Reengineering wird verdeutlicht.

2.1 Definitionen

Für die Bezeichnung Reengineering gibt es mehrere Definitionen. Dieser Abschnitt geht auf drei verschiedene Begriffsdefinitionen ein und gibt diese wieder. Da wäre zum einen die Beschreibung durch Arnold [Arn93], die Definition von McClure [McC92] sowie abschließend die Bezeichnung von Chikofsky und Cross [CI90].

Reengineering: „Unter Reengineering werden alle Aktivitäten nach Inbetriebnahme eines Programmsystems zusammengefasst, die das Verständnis von Software erhöhen oder die Wartbarkeit, Wiederverwendbarkeit oder Weiterentwickelbarkeit von Software verbessern oder erst ermöglichen.“ [Arn93]

Zu einer Software gehören nicht nur die Anwendung bzw. das Programm, sondern sämtliche Dokumente. Demnach zählen neben dem Quelltext zum Beispiel auch Spezifikationen, DesignEntwürfe oder Dokumentationen zu einer Software.

McClure [McC92] definiert das Reengineering folgendermaßen:

Reengineering: „Unter Reengineering versteht man den Prozess der Untersuchung und/oder Modifikation eines Software-Systems mit der Hilfe automatisierter Werkzeuge. Ziel ist die Verbesserung der Wartbarkeit und der verwendeten Technologie, die Erhöhung der Lebenserwartung und die maschinelle Verwaltung der Systemkomponenten zur Unterstützung von CASE-Tools.“ [McC92]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Zusammenhänge der einzelnen Begriffe nach Chikofsky und Cross [CI90]

Gemäß der folgenden Definition von Chikofsky und Cross [CI90] wurde in den beiden Kapiteln 3 und 4 dieser Arbeit vorgegangen.

Reengineering: „Die Untersuchung und Modifikation eines Programmsystems, um es in einer neuen Form wiederherzustellen und diese Form nachfolgend zu implementieren.“ [CI90]

Als Modell werden in Abbildung 2.1 die von Chikofsky und Cross beschriebenen Zusammenhänge der einzelnen Begriffe originalgetreu wiedergeben.

Forward Engineering ist die Bezeichnung für das Standard Entwicklungsverfahren von Soft- ware. Ein Auftraggeber äußert seine Anforderungen an die fertige Software. Der Softwareent- wickler abstrahiert die Anforderungen und setzt diese in lauffähige Codes um. Reverse Engi- neering beschreibt den entgegengesetzten Verlauf, wie in Abbildung 2.1 gut zu erkennen ist.

Forward Engineering: „Forward Engineering ist der Transformationsprozeß einer Spezifikation von einem höheren in ein niedrigeres Abstraktionsniveau.“ [Mü13]

So kann eine höhere Abstraktionsebene z.B. die natürliche Sprache darstellen und das Ziel der niedrigeren Abstraktionsebene ist die Programmiersprachen Syntax, etwa in C++ oder Java. Etwas anders formuliert beschreibt es die Neuentwicklung eines Systems nach vorgegebenen Spezifikationen.

Reverse Engineering: „ Unter Reverse Engineering versteht man die Extrakti- on und Repräsentation von Informationen aus einem Softwaresystem (Spezifikation) in einer anderen Form oder auf einem höheren Abstraktionsniveau.“ [Mü13]

Dadurch erhält man etwa aus dem Quellcode einer Anwendung verschiedene Spezifikationen oder Diagramme, wie das Klassen- oder Sequenzdiagramm, um ein besseres Verständnis dafür zu erhalten.

Redokumentation: Unter Redokumentation versteht man die Erstellung von Dokumentationen auf Basis der bestehenden Software. Als Ergebnis ist z.B. die Darstellung in Datenflussdiagramme.

Die Redokumentation findet statt, um vorhandene Dokumentationen nach dem Reengineering an das überarbeitete System anzupassen und zu aktualisieren. Dies gewährleistet, dass sich die Unterlagen danach auf dem gleichen Stand befinden und nicht noch das Ausgangssystem abbilden. Es ist jedoch durchaus möglich, dass Dokumentationen neu erstellt werden müssen, weil für das Ausgangssystem bislang keine Unterlagen vorhanden waren.

Design Recovery: „Im Design Recovery erstellt man ein Modell des betrachte- ten Systems (Programm). Dieses Modell besitzt ein höheres Abstraktionsniveau und kann nicht ausschließlich aus dem System (Programm) erzeugt werden. Zusätzliche Informationsquellen sind z.B. eventuell vorhandene Dokumentationen, allgemeines Wissen über den Problembereich und die Anwendung, persönliche Erfahrungen und andere.“ [Mü13]

Für das spätere Fallbeispiel der „Rückwaren-Datenbank“ wird ebenfalls ein Design Recovery durchgeführt, weshalb die Definition hier wiedergeben wird.

Software-Wartung: „Befinden sich die Programme in Betrieb, so werden an Ihnen oft Veränderungen und Erweiterungen vorgenommen. Mögliche Wartungs- arbeiten sind der Austausch von bestimmten Algorithmen durch leistungsfähigere (z.B. schnellere) oder der Einbau zusätzlicher Benutzerfunktionen. In der Regel er- hält das Programm noch Fehler, die sich erst im laufenden Betrieb herausstellen und im Rahmen der Wartung korrigiert werden. Viele Programme hängen auch von gesetzlichen Bestimmungen oder Tarifvereinbarungen ab und müssen regelmäßig aktualisiert werden.“ [CS03]

Im Verlauf dieser Arbeit findet der Begriff „Wartung“ mehrfach Erwähnung, weshalb diese Definition für das Verstehen nützlich ist.

Zu besseren Abgrenzung der Begriffe Softwaremigration und Software Reengineering wird die Beschreibung durch Sneed aufgezeigt.

Softwaremigration: „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]

„Softwaremigration und Software Reengineering unterscheiden sich anhand ihrer Ziele. Die Maßnahmen des Software Reengineering verfolgen im strengen Sinne das Ziel, die Qualität einer Software zu steigern. Im Gegensatz dazu zielen Migrations- maßnahmen darauf ab, dass die Erhaltung eines Softwaresystems in einer neuen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Migrationsarten nach Sneed [SWH10]

Zielumgebung gegeben ist. Die Softwaremigration, kurz Migration, findet in unse- rem Fall nur auf der Datenebene statt. Bei der Datenmigration werden Daten von einem vorhergehenden System in ein anderes oder neues System migriert. Meist finden Datenmigrationen ohne Verlust in der Datenqualität statt.“ [SWH10]

Die verschiedenen Migrationsarten nach Sneed [SWH10] sind in der Abbildung 2.2 ersichtlich. Auf dieser Grafik ist auch im unteren Bereich die angesprochene Datenmigration dargestellt.

Datenmigration: „Bei der reinen Datenmigration bleiben die Programme in ihrer Form bestehen und es werden nur die Daten migriert. Die Daten können in ein anderes Datenhaltungs- bzw. Datenbankmanagementsystem überführt werden. Es versteht sich, dass eine Datenmigration von einer hierarchischen oder netzarti- gen Datenbank in eine relationale Datenbank eine aufwendige und anspruchsvolle Aufgabe ist. Das gleiche gilt in etwas geringerem Umfang für die Migration von Flat- Files in relationale Datenbanken. Es ist nicht so sehr die Konvertierung der Daten selbst, die eine Migration erschwert, sondern die Konvertierung der Programme, die die Dateien verarbeiten.“ [SWH10]

Das Thema Migration gelangt im späteren Unterkapitel 2.4 „Migration“ kurz zur Erörte- rung. Auf die Datenmigration wird bei unserem praktischen Beispiel in Kapitel 4 „Durchfüh- rung des Reengineering“ genauer eingehen, genauer eingegangen, denn dort erfolgt eine Da- tenmigration. Solche Datenmigrationen sind bei einer relationalen Datenbank zu einer anderen Datenbank weniger problematisch und können teilweise vollautomatisiert erledigt werden. Dennoch kommt es vor, dass Datenmigrationen sich doch nicht ganz so einfach gestaltet. Sie wird schwieriger, wenn das Ausgangssystem veraltet ist und in dieser Form nicht oder nur teilweise übernommen wird. Die enthaltenen Daten werden in dem neuen System neuen Strukturen zu- geordnet. Die eigentlichen Werte der Daten bleiben aber trotzdem enthalten. Dazu aber später in Kapitel 4 mehr.

Ein Hauptproblem des Reengineering stellt die fehlende Vertrautheit des Programmierers mit der Software dar. Den Großteil der Arbeitszeit für die Software Erweiterung, Wartung oder Analyse verbringt der Software-Entwickler mit dem Verstehen der Anwendung sowie der Arbeitsweise der Anwendung.

Zum Verstehen der Anwendung zählen das Erkennen der Systemstrukturen und -eigenschaften und die technische Arbeitsweise der Software. Charakterisierende Fragen sind zum Beispiel:

-Welche Datenbank, Dateien etc. gehören zu einer Anwendung?
-Welche Daten oder Dateien werden erzeugt?
-Welche Abhängigkeiten bestehen zwischen den Bestandteilen der Anwendung?
-Welche Funktion ruft welche Funktion auf?
-Wo wird Variable 1 geschrieben und wo gelesen?
-Welche Änderungen ziehen welche Auswirkungen mit sich?

2.2 Einführung in das Reengineering

Software Reengineering ist die Analyse bestehender Softwaresystemen und die darauffolgende umfangreiche Überarbeitung der Anwendung, um deren Qualität und Leistung deutlich zu optimieren. Wie beim Software-Engineering erfolgen auch beim Software Reengineering die Analyse und die Überarbeitung ingenieurmäßig unter Anwendung geeigneter Vorgehensweisen, Methoden und Werkzeuge.

Wie im vorherigen Kapitel definiert versteht man unter Software-Wartung das Ändern von Software. In einem Lebenszyklus von Anwendungen ist es logisch, dass die Software-Wartung ein unverzichtbarer Bestandteil in diesem Prozess darstellt. Es wird durch äußerliche Einflüsse immer wieder Anforderungen an eine Software geben, die nicht vorhersehbar sind. Von der Entfernung der Programmfehler (Bugs) ganz zu schweigen.

Die Frage darf also nicht sein, ob es Wartung geben soll oder muss, sondern wie hoch der Aufwand für die Softwarewartung und dessen Kosten sein darf. Eine pauschale Antwort auf diese Frage existiert nicht. Dies muss jedes Unternehmen für sich selbst entscheiden.

2.2.1 Technisches Reengineering

Hauptsächlich interessieren wir uns für die Aktivität in der Wartungsphase, welche in der englischen Sprache typischerweise durch die Vorsilbe Re- gekennzeichnet wird: Reengineering. Ein essenzieller Punkt der Software-Wartung und des Reengineerings ist das Verstehen der Software. Oftmals müssen Jahre nach der Entwicklung der Software Änderungen daran vorgenommen werden oder ein Entwickler, der mit dieser Software absolut nicht vertraut ist, soll daran Modifikationen durchführen, Erweiterungen vornehmen oder schlichtweg nur einen Fehler beheben. Deshalb ist das Programmverstehen eine unabdingbare Voraussetzung der Wartung und gleichzeitig ebenfalls der größte Zeitfresser.

Eine Studie von Fjeldstad und Hamlen ist zwar schon etwas älter, aber hat dennoch einen aussagekräftigen Charakter. Sie untersucht die einzelnen Aktivitäten der Wartung von Software. Diese Einzelpunkte und der entsprechende Aufwand führt Tabelle 2.1 auf. [FH83]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Wartungsaktivitäten nach der Studie von Fjeldstad und Hamlen [FH83]

Wenn man sich die Tabelle 2.1 nun genauer betrachtet, stellt man fest, dass die Aktivitäten des Programmverstehens beinahe die Hälfte des kompletten Wartungsaufwands an Ressourcen benötigen. Das Verstehen der Anfrage, das Verstehen der Dokumentation und das Verstehen des Programmcodes nehmen ganze 47 % der Aktivitäten ein.

Vom eigentlichen Aufwand, um Änderungen an der Software vorzunehmen, werden mit der Im- plementierung und der Dokumentation nur 25 % und das Testen 28 % in Anspruch genommen. Es zeigt sich also, dass das Verstehen des Programms den größten Abschnitt in der Softwa-rewartung einnimmt und die Wartung selbst aber den größten Teil des Softwarelebenszyklus ausmacht. Es lohnt sich folglich, Zeit in das Verstehen des Programms zu investieren. Inwieweit sich die Zahlen aus der Tabelle 2.1 belegen lassen, zeigt ein typisches Wartungsszenario, wie man auch später in den beiden Kapiteln 3 und 4 des Fallbeispiels sehen kann. Um eine Änderung am Programm vornehmen zu können, muss ein Programmierer die typischen Analyse und Programmieraufgaben durchführen. Im Rahmen dessen wird davon ausgegangen, dass der Programmierer, der die Änderungen durchführen soll, das Programm nicht selbst entwickelt hat und es ihm demnach fremd ist. Er muss sich zuerst einen Überblick über die Software verschaffen. Dabei muss er:

-die Systemspezifikationen analysieren,
-das Design analysieren,
-Anwender der entsprechenden Software befragen,
-Programme durcharbeiten,
-sich im besten Fall in vorhandene Dokumentationen einlesen, sofern es welche gibt,
-die Quelle eines Softwarefehlers (Bug) verfolgen,
-die Programmänderung designen,
-das Programm modifizieren,
-das Programm validieren und testen sowie
-letztendlich die Dokumentation aktualisieren und anpassen.

Erschwerend ist meistens, dass dem Programmierer keine oder eine völlig veraltete Dokumentation vorliegt und ihm dadurch ausschließlich der Programm-Quellcode als Quelle dient. Spezifikationen und Design sind ebenso meist überholt oder nicht vorhanden.

Das Erkennen von Konzepten und Zusammenhängen sowie seine Abstraktionen von pro- grammspezifischer in domänenspezifische Ausdrucksweise wird in der Literatur als Concept Assignment Problem [ES93] bezeichnet. Ein kleines Programmbeispiel wird in Listing 2.1 dar- gestellt.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.1: Ein unbekanntes Programm

Die Erklärung für dieses kleine Beispielprogramm sollte mit qualitativ anderen Bezeichnungen und Beschreibungen stattfinden, um den Abstraktionsvorgang - oder auch Erkenntnisvorgang genannt - des Programmverstehens zu belegen. Für das Beispiel aus Listing 2.1 würde es in etwa so aussehen:

Das Programm sortiert eine Liste in aufsteigender Reihenfolge.

Die Implementierungsdetails, wie die Sortierung erfolgt (Bubble-Sort), wird dabei abstrahiert.

Der Verstehensprozess wird in drei verschiedenen Theorien differenziert und als plausibel betrachtet. Es gibt die Buttom-Up, die Top-Down und eine verbindende Theorie. In Müller [Mü13] werden diese wie folgt definiert:

Bottom-Up Verstehen: „Beim Bottom-Up-Verstehen bildet der Programmierer ausgehend vom Quell-Code Abstraktionen auf höherem Niveau, z.B. Sortieren in vorigem Beispiel. Auf diese Weise wird das interessierende Programmstück in mehrere Segmente geteilt, für die mentale Abstraktionen gebildet werden. Durch einen sukzessiven Prozess werden diese Konzepte auf einer höheren Abstraktionsebene wieder mit einem Konzept versehen. So wird über mehrere Abstraktionsstufen schließlich dem zu untersuchenden Modul ein domänenspezifisches Konzept unabhängig von der realen Implementierung zugeordnet.“ [Mü13]

Top-Down Verstehen: „Beim Top-Down verstehen geht der Programmierer mit einer gewissen Erwartungshaltung, die auf seiner Erfahrung beruht, in die Analyse. Bei einer Anwendung Gehaltsabrechnung werden z.B. Datenfelder wie Name, Personalnummer und Gehalt erwartet; ebenso Prozeduren für reguläre Gehaltsabrechnung aber auch für Sonderfälle wie Krankheit und Urlaub. Nach diesen Strukturen wird gesucht und bei deren Erkennen nach einer Art Puzzle-Spiel nach und nach das Programm rekonstruiert.“ [Mü13]

Opportunistisches Verstehen: „Das opportunistische Verstehen verbindet den top-down und den bottom-up Ansatz. Sowohl das Domänenwissen als auch das Algorithmen- und Codierungswissen werden genutzt um ein mentales Modell des aktuellen Programmverständnisses aufzubauen. Dieses Modell wird dann sowohl durch den top-down Ansatz (Bildung von Hypothesen, welche Programmfunktiona- lität vorhanden sein muss um deren Bestätigung oder Verwerfung) als auch durch den bottom-up Ansatz (Analyse von Programm-Code und anschließend Konzept- bildung) ständig erweitert. Das Verfahren heißt opportunistisch, weil der mensch- liche Programmversteher wie ein opportunistischer Prozessor die Möglichkeit hat, zwischen den beiden Verfahren das angemessenere und erfolgversprechendere zu wählen.“ [Mü13]

Ein weiterer Schritt zum besseren Programmverstehen besteht darin, einen Systemüberblick zu bekommen und gegebenenfalls zu visualisieren. Bei einzelnen Anwendungen ist dieser Schritt schon sinnvoll, um einen besseren Überblick zu erhalten. Unabdingbar wird es bei komplexen Softwaresystemen, die im Allgemeinen aus mehreren Programm-Modulen, Dateien, Datenban- ken und Ähnlichem bestehen. Um das System als Ganzes darzustellen, müssen die Teilsysteme und deren Verbindungen zueinander dargestellt werden. Diese Informationen werden meistens als hierarchische Graphen visuell aufgezeigt. Ebenso wichtig bezüglich des Gesamtüberblicks

Abbildung in dieser Leseprobe nicht enthalten

(a) Ein einfacher Aufrufgraph. (b) Ein einfacher Kontrollflussgraph

Abbildung 2.3: Hierarchische Graphen

der Anwendung ist die Aufrufhierarchie der Funktionen und Prozeduren. Stellt man die Funk- tionen und Prozeduren als Knoten und die Verbindungen zueinander als Kanten dar, dann er- hält man einen Graphen der Aufrufhierarchie. Analog dazu kann man diese Vorgehensweise für Formulare, Module usw. übernehmen. Einen einfachen Aufrufgraph zeigt Abbildung 2.3 (a).

Eine andere Form der Visualisierung stellt der Kontrollflussgraph dar. Kontrollflussgraphen verdeutlichen die interne Struktur von Prozeduren, Komponenten oder Ähnlichem. Knoten stellen (Blöcke von) Anweisungen dar, Kanten zeigen den möglichen Kontrollfluss durch die Komponente. Ein einfacher Kontrollflussgraph ist in Abbildung 2.3 (b) ersichtlich.

Das Thema Wiederverwendung spielt im Software-Engineering eine bedeutende Rolle. Bei Neuentwicklungen kommen des Öfteren vorgefertigte oder von anderen entwickelte Pro- grammbauteile zum Einsatz. Im Bereich des Reengineering spielt nicht selten die Wiederver- wendung von Programmteilen eine ebenso zentrale Rolle. Durch die Wartung oder Modifikation einer Anwendung wird der Großteil der Software leicht modifiziert oder komplett wiederver- wendet.

So auch in unserem späteren Beispiel aus der Praxis in Kapitel 4. Dies führt innerhalb des Software-Engineering bzw. Reengineering zur maßgeblichen Produktivitätssteigerung und bei qualitativ hochwertigen Softwarebausteinen zu einer Qualitätssteigerung, da häufig verwendeter Code meist fehlerfrei ist. Dadurch lassen sich Kosten sparen und das Kosten-/Nutzen-Verhältnis verbessert sich.

Verschiedene Faktoren sind beispielsweise folgende:

Minimierung von Routinearbeiten: Häufig genutzte Prozeduren und Funk- tionen liegen dem Entwickler in unterschiedlichen Bibliotheken vor und können wie- derverwendet werden. Dies entlastet den Programmierer bei den Implementierungen und es müssen nicht häufig genutzte Funktionen bei jeder Neuentwicklung neu pro- grammiert werden.

mit den benötigten Programmierbausteinen kann man bei der Wiederverwendung die Entwicklungszeit des gesamten Softwarepakets erheblich verkürzen. Dadurch sinken die Kosten.

Höhere Software-Qualität: Die fertigen Programmierbausteine und Biblio- theken sind meistens fehlerfrei, da sie durch die Wiederverwendung oftmals getestet wurden und sich in einigen Produktivsystemen bereits im Einsatz befinden. Die höhere Qualität und demnach die geringeren Anwendungsfehler steigern die Kun- denzufriedenheit.

Reduzierung des Wartungsaufwands: Da der Quellcode der Programmierbausteine zentral in Bibliotheken verwaltet wird, ist es auch einfacher, diesen Code zentral zu warten. Modifikationen wie Updates oder Erweiterungen erfolgen demnach direkt in der Bibliothek und finden dadurch indirekt den Weg in das Produktivsystem, weil die Bibliotheken dort eingebunden sind. Durch standardisierte Softwarebausteinen führt dies zu einem gewissen Softwarestandard und damit zu einem leichter verständlichen und wartbaren Programm.

Probleme der Wiederverwendbarkeit können zum einen sein, dass dafür Investitionen getä- tigt werden müssen, um das organisatorische Umfeld für die Wiederverwendbarkeit aufzubauen. Darunter fallen unter anderem die Werkzeuge sowie die Struktur für den Aufbau und die Verwal- tung von den Bibliotheken und Programmbausteinen. Zusätzlich muss die Software allgemeiner entworfen, entwickelt und implementiert werden, damit die Bibliotheken eingebunden werden können.

Als weiteres Problemfeld stellt sich die Wiederverwendung von gekaufter Software oder Quellcode dar. Bei gekaufter Fremdsoftware steht zunächst stets das Urheberrecht im Raum und muss geklärt werden. Danach entscheidet sich, ob der gekaufte Quellcode oder die Bausteine in einer eigenen Anwendung genutzt und weiterverkauft werden können.

Mit der Zeit sammelt sich eine große Anzahl von Bausteinen, die der Wiederverwendbarkeit dienen, an. Demzufolge müssen die Aktualität und das Qualitätsniveau gewährleistet sein. Die Bausteine sollten bezüglich der Qualität folgende Kriterien erfüllen:

-Korrektheit
-Robustheit und Fehlertoleranz
-Effizient
-Modular
-Portabel
-Gut dokumentiert.

[...]