Harry M. Sneed, Software-Engineering Service GmbH München,
Rosenheimer Landstr. 37, 85521 Ottobrunn, Tel.: 089-6093193
Email:
100276.57@Compuserve.com
Dabei geht es um zwei alternative Möglichkeiten der Wiederverwendung:
Bei der Konversionsalternative werden die alten Programme saniert und in die neue Umgebung migriert, z.B. von Assembler in eine höhere Programmsprache oder von einer prozeduralen Sprache in eine objektorientierte Sprache.Bei der Kapselungsalternative werden die alten Programme in einzelne Bausteine zerlegt und über eine Wrapper-Software neuen Systemen zugänglich gemacht. Sie bleiben aber weiter in ihrer Umgebung.
Für die Beanwortung der kritischen Frage nach dem richtigen Migrationsweg wird von der Wirtschaft dringend Entscheidungshilfe gebraucht. Die Entscheidung sollte auf der Basis einer Kosten/Nutzen-Analyse mit quantifizierbaren Meßwerten gefällt werden. Ansonsten bleibt nur die Intuition. Man wählt die Neuentwicklung, weil man die alte Umgebung nicht kennt und nicht bereit ist, sich mit dem alten Code auseinander zu setzen, oder man wählt die Wiederverwendung, weil man die neue Entwicklungstechnologie nicht beherrscht und nicht bereit ist, sich einzuarbeiten. Beide Entscheidungen sind irrational und zu vermeiden. Statt dessen sollte ein Abgleich quantitativer und qualitativer Kosten- und Nutzenfaktoren entscheidend sein. In diesem Beitrag stehen die Kosten der Wiederverwendung im Vordergrund.
Es gibt Maße für die Software-Größe, wie Lines of Code, Anweisungen, Function-Points, Data-Points, Feature-Points und Object-Points [19]. Es gibt Maße für die Software-Komplexität, z.B. Halstead's Sprachkomplexität [9], McCabes Graphkomplexität [16], Henry's Schnittstellenkomplexität [11] und Chapin's Datenkomplexität [3]. Schließlich gibt es Maße für die Software-Qualität, wie Fehlerraten, Mängelraten, Verständlichkeit, Testbarkeit, Portierbarkeit und Modularität [12]. Es sind auch Maße für die Software-Wartung [20] sowie für die Software-Wiederverwendbarkeit [17] vorgeschlagen worden.
Für die Schätzung der Wartbarkeit ist der Code Maintainability Index von Welker, Oman und Atkinson besonders empfehlenswert [22]. Für die Bewertung der Wiederverwendbarkeit haben Cimitile, De Lucia und Minro wichtige Beiträge geleistet [4].
Die empirische Untersuchung von Software-Reuse in der Wartung von Li hat gezeigt, wie man wiederverwendbare Funktionen erkennen kann [15].
Diese Metriken beziehen sich jedoch nur auf die Stufe der elementaren Bausteine, der Prozeduren. Hier leisten sie gute Hilfe bei der Detailauswahl wiederverwendabrer Code-Abschnitte, helfen aber wenig bei der Entscheidung, ob ein System überhaupt wiederverwendet werden sollte bzw. kann. Wirtschaftsmanager brauchen einfache, leicht zu ermittelnde Meßwerte, die sich in eine Entscheidungsregel leicht einfügen lassen. Nur so können Software-Metriken zur groben Entscheidungsfindung beitragen.
Außerdem muß zwischen der Art der Wiederverwendung unterschieden werden. Es werden andere Meßwerte benötigt, je nach dem ob konvertiert oder gekapselt wird, denn jede Migrationstechnik hat andere Voraussetzungen.
Beispielhaft für 1:1-Transformationen sind MVC-, CLC- und BAL- Befehle, denn für jeden dieser Befehle gibt es eine äquivalente COBOL-Anweisung: MOVE, IF und PERFORM. Andererseits gibt es Assembler-Befehle wie Shift Logical und Test under Mask, die nur durch mehrere COBOL-Anweisungen bzw. durch eine COBOL Subroutine abbildbar sind. Diese sind 1:N-Transformationen.
Schließlich gibt es Assemblerkonstrukte, wie Adreßtabellen über die auf dynamische Speicherbereiche indirekt zugegriffen wird. Solche Assembler-Algorithmen bzw. Befehlsgruppen sind nur durch eine völlig andere Gruppe von COBOL-Anweisungen abbildbar. Es handelt sich hierbei um eine M:N-Transformation, die in der Regel nur manuell zu bewerkstelligen ist. Somit lassen sich also die Anweisungen einer Quellsprache in drei Kategorien teilen:
Das Verfahren entspricht dem üblichem Algorithmus für regelbasierte Entscheidungsprozesse [10]. Um als Kandidat für die Konvertierung in Frage zu kommen, müssen mindestens 60 der Quellcode-Befehle 1:1 und mindestens 30 1:N in Anweisungen der Zielsprache umsetzbar sein. Demnach dürfen maximal 10 der Anweisungen manuell umgeschrieben werden. Der Rest muß per Werkzeug automatisch konvertiert werden [13]. Dies gilt sowohl für Datendeklarationen als auch für prozedurale Anweisungen.
Wenn 1:1-Umsetzungen mit 1,0, 1:N-Umsetzungen mit 0,5 und M:N-Umsetzungen mit 0 gewichtet werden, entsteht eine Wiederverwendbarkeitsrate von 0,75. Dieses relationale Maß wird als Mindestgrenze für Konvertierungsvorhaben angesehen [1]. Darunter gerät der Aufwand einer Konvertierung in die Nähe des Aufwandes für eine Neuentwicklung.
Gekapselt werden Programme als Ganzes, Module und Abschnitte bzw. einzelne Prozeduren [21]. Innerhalb des gekapselten Codes können bestimmte Ablaufzweige im gekapseltem Zustand ausgeklammert werden, d.h. sie werden durch parametrisierte Bedingungen im Sinne von Dijkstra's ,,guarded command`` Konzept geschützt. Dies ist der Fall, wenn bestimmte Altfunktionen im neuen Geschäftsprozeß nicht mehr benötigt werden. Aus der Analyse des alten Systems muß hervorgehen, welche Code-Bausteine, Programme, Module, und Prozeduren überhaupt gekapselt werden und welche Anweisungen und Daten innerhalb der gewählten Bausteine zu benutzen sind.
Es kann sein, daß nur wenige Pfade durch ein Modul für die neuen Anwendungen von Interesse sind. Die Anderen werden markiert. Bei der Messung der Systemverwendbarkeit kommt es darauf an, die zu nutzenden Daten und Anweisungen zu zählen und relativ zur Summe aller Daten und Anweisungen zu betrachten. Kommen sie nicht auf mindestens 50, so ist die Kapselung keine tragbare Alternative, weil das alte System in seiner Mehrheit ungenutzt bleibt. Diese Wiederverwendungsrate für die Ausführung in der alten Umgebung entspricht der 75-Rate bei der Konvertierung in eine neue Umgebung. Es ist immer noch möglich, einzelne Teile eines Altsystems heraus zu holen und in ein neues System zu verpflanzen. Hierbei handelt es sich jedoch in der Tat um eine Neuentwicklung unter Verwendung alter Bausteine. Von einer Wiederverwendung des alten Systems kann hier nicht die Rede sein.
Wiederverwendbarkeit bezogen auf ein Software-System bedeutet, daß mindestens die Hälfte wiederverwendet wird. Denn nur so können die Kosten der Wiederverwendung relativ zu den Kosten einer Neuentwicklung niedrig bleiben.
Endres hat eine Formel für die Kosten und Nutzen der Wiederverwendbarkeit relativ zur Neuentwicklung vorgeschlagen. Dabei kommt heraus, daß die Wiederverwendungsrate mindestens 50 betragen muß [7]. Derselbe Autor hat auch darauf hingewiesen, daß Reengineering-Kosten nicht mehr als 33 der Neuentwicklungskosten betragen dürfen, ohne durch den Nutzen der Neuentwicklung ausgeglichen zu werden [18].
Es gibt somit zwei Grenzwerte die nicht zu unterschreiten sind:
Nachdem die Pfade bzw. Programmscheiben markiert sind, werden die Anweisungen, die auf den markierten Pfaden liegen und die Daten, die von diesen Anweisungen verwendet werden, gezählt.
Die Zählung der 1:1, 1:N und M:N konvertierbaren Anweisungen wird vom Tool SOFAUDIT selbstständig durchgeführt. Dies geschieht auf der Grundlage vordefinierter Konvertierbarkeitstabellen sowie auf den bereits geschilderten Regelbäumen. Implementiert wurde dies für Assembler-, PL/1- und COBOL-Programme.
Im Falle der Konvertierung wird die Umsetzbarkeit des Quellcodes gemessen. Im Falle der Kapselung wird die Wiederverwendungsrate gemessen. In beiden Fällen wird eine Entscheidungshilfe für die Frage geleistet, ob konvertiert, gekapselt oder neuentwickelt werden soll.
Das Meßverfahren basiert auf der bisherigen Forschung in der statischen Code-Analyse und Wartungsmessung. Es wird noch verfeinert und mit Erfahrungswerten aus laufenden Migrationsprojekten kalibriert. Erste Erfahrungen sind bereits aus zwei Projekten vorhanden.