1 Einleitung

Neben der Entwicklung von Software spielt auch die Wartung der Software im Softwarelebenszyklus eine entscheidende Rolle. Die Kosten für die Wartung übersteigen sogar die Kosten für die Entwicklung der Software. So beträgt im Durchschnitt der Anteil der Wartung an den gesamten Kosten 67%, während für die Entwicklung nur 33% veranschlagt werden [Pagel & Six, 1994].
Bei der Wartung von Software können unterschiedliche Ziele verfolgt werden:

• Verbesserung,
• Portierung und
• Fehlerkorrektur.

Wie man sieht, ist die Arbeit mit der Software nach der Installation noch nicht beendet. Gerade bei guter Software, die häufig benutzt wird, wünschen sich die Benutzer immer neue Funktionen, die dann hinzuzufügen sind. Oder aber die Software wird über 10 Jahre eingesetzt, so daß eine Anpassung an neue Computertypen und/oder Betriebssysteme erforderlich wird. Ein momentan großes Problem der Informatikbranche ist auch aus diesem Grund entstanden. Die Programmierer haben in den 60/70 Jahren nie gedacht, daß ihre Programme noch im Jahre 2000 betrieben werden. So haben sie nur 2-stellige Jahreszahlen benutzt. Aufgrund der fehlenden Dokumentation ist es nun sehr schwierig die Programme anzupassen und nun auf 4-stellige Jahreszahlen umzustellen, so daß die Programme auch nach dem Jahr 2000 noch funktionsfähig sind.
Da viel Zeit zwischen der Entwicklung und den Wartungsaktivitäten vergeht, muß der Softwareentwickler, der die Anpassung vornimmt, den Entwurf der Software erneut verstehen. Insbesondere können durch Veränderungen in der Firma Softwareentwickler mit der Wartung beschäftigt sein, die nicht an der Entwicklung der Software beteiligt waren. In diesem Fall muß der Entwickler schnell ein Verständnis für die Struktur erlangen. Ein einfaches Lesen des Quellcodes reicht fast nie aus. Allenfalls für kleine Fehlerkorrekturen ist dieser Weg eventuell machbar, aber selbst bei nur kleinen Änderungen können durch Nebenwirkungen schnell große Probleme entstehen.
Für die Analyse des Quellcodes stehen auch Reverse Engineering Tools zur Verfügung. Diese lesen den Quellcode und generieren daraus die Klassendiagramme mit allen Klassen und den Beziehungen zwischen den Klassen. Jedoch sind diese Ergebnisse auch nicht sehr hilfreich, da diese Diagramme keine informative Struktur besitzen, siehe Abbildung 1.
So hilft für das Verständnis des kompletten Entwurfs der Software nur das Wissen aus der Entwurfsphase. Damit dieses Wissen während der Wartung der Software verfügbar ist, muß dieses Wissen in einer Dokumentation zusammengefaßt und sinnvoll strukturiert werden. Diese Dokumentation wird in einigen Firmen jedoch nur unzureichend erstellt. Denn meist stehen die Entwickler bei dem Entwurf unter Zeitdruck und sind froh, daß die Software rechtzeitig fertig ist. Anschließend steht meist schon das nächste Projekt an, so daß keine Zeit vorhanden ist, um die Dokumentation zu erstellen.
Mit der Unterstützung von Werkzeugen kann die Dokumentation schnell und gleichzeitig gut strukturiert erstellt werden. Diese Diplomarbeit beschreibt eine mögliche Form der Werkzeugumgebung. Dazu zeige ich in Kapitel 2 die verbreiteten Techniken, die für eine Dokumentation eingesetzt werden. Danach schließt sich mit Kapitel 3 eine Beschreibung der Werkzeugumgebung an, die ich während der Diplomarbeit realisiert habe. Mit der Nachdokumentation von dem Framework OSEFA ("offenen objekt-orientierten Steuerungsbaukasten für Fertigungsanlagen") der FH-Konstanz habe ich diese Werkzeugumgebung eingesetzt und validiert. Zum Schluß folgt das Kapitel 4, das die bei der Entwicklung der Werkzeugumgebung noch nicht gelösten Probleme mit entsprechenden Lösungsansätzen aufführt.

Abbildung 1: Klassendiagramm nach Reverse Engineering von OSEFA (Ausschnitt)