
\documentstyle[art11,german,twocolumn]{article} %epsfig
%\input{trendsstyle_v2.tex}
\input{/home/pi/kelter/p/tex/a4.tex}
\input{/home/pi/kelter/p/tex/endversion.tex}

\newcommand{\yyyy}{\par}
\parskip1.8mm

%\textheight24cm
%\textwidth16.5cm
%\footheight0cm
%\setlength{\topmargin}{-2cm}
%\setlength{\oddsidemargin}{-0.5cm}
\author{\it Harry M. Sneed, Software-Engineering Service GmbH M"unchen, \\
 Rosenheimer Landstr. 37, 85521 Ottobrunn, Tel.: 089-6093193
\\ Email:
 100276.57@Compuserve.com}
\title{
  \begin{center}
  \large{\bf Metriken f"ur die Wiederverwendbarkeit
	bestehender Software-Systeme}
  \end{center} }
\date{}
%\setlength{\parindent}{0pt}
% \setlength{\parskip}{5pt plus 2pt minus 1pt}


\frenchspacing
\pagestyle{empty}
\sloppy

\begin{document}
\thispagestyle{empty}
\maketitle            
                                          
\section {Migrationsalternativen}
Immer mehr DV-Anwenderbetriebe stehen vor der Frage, ob sie ein bestimmtes 
Anwendungssystem neuentwickeln sollen oder ob sie das alte System 
zumindest teilweise weiterverwenden sollten. Auf der einen Seite haben 
sie die Gelegenheit, alles das nachzuholen, was 
sie bei der letzten Entwicklung vers"aumt haben. Auf der anderen Seite besteht 
die Gefahr, da"s das neue System zu teuer wird, zu sp"at oder "uberhaupt nicht 
fertig wird. Um die Kosten und Risiken einer Neuentwicklung zu beschr"anken, bietet sich die 
Wiederverwendung der bestehenden Software an. \yyyy
Dabei geht es um zwei alternative M"oglichkeiten der Wiederverwendung: 
\begin{center}
{\it Konversion und Kapselung}. \cite {Br95}
\end{center}
Bei der Konversionsalternative werden die alten Programme saniert und in 
die neue Umgebung migriert, z.B. von Assembler in eine h"ohere Programmsprache 
oder von einer prozeduralen Sprache in eine objektorientierte 
Sprache. \yyyy
Bei der Kapselungsalternative werden die alten Programme in 
einzelne Bausteine zerlegt und "uber eine Wrapper-Software neuen Systemen 
zug"anglich gemacht. Sie bleiben aber weiter in ihrer Umgebung. \yyyy
F"ur 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"swerten gef"allt werden. Ansonsten bleibt nur die 
Intuition. Man w"ahlt die Neuentwicklung, weil man die alte Umgebung nicht 
kennt und nicht bereit ist, sich mit dem alten Code auseinander zu setzen, 
oder man w"ahlt 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.     

\section {Metriken zur Soft\-ware-War\-tung und Wie\-der\-ver\-wen\-dung}
An Software-Metriken fehlt es nicht. Zuse \cite{Zu90}, Fenton \cite{Fe91}, Dumke \cite{Du96} und 
andere weisen auf mehr als 150 einzelne Metriken hin. \yyyy
Es gibt Ma"se f"ur die Software-Gr"o"se, wie Lines of Code, Anweisungen, Function-Points, Data-Points, 
Feature-Points und Object-Points \cite{Sn91}. Es gibt Ma"se f"ur die Software-Komplexit"at, 
z.B. Halstead's Sprachkomplexit"at \cite{Hal77}, McCabes 
Graphkomplexit"at \cite{Ca81}, Henry's Schnittstellenkomplexit"at \cite{He81} und Chapin's 
Datenkomplexit"at \cite{Chap77}. Schlie"slich gibt es Ma"se f"ur die Software-Qualit"at, wie 
Fehlerraten, M"angelraten, Verst"andlichkeit, Testbarkeit, Portierbarkeit und 
Modularit"at \cite{ISO}. Es sind auch Ma"se f"ur die Software-Wartung \cite{Sn95} sowie f"ur 
die Software-Wiederverwendbarkeit \cite{Scha94} vorgeschlagen worden. \yyyy
F"ur die Sch"atzung der Wartbarkeit ist der Code Maintainability Index von Welker, 
Oman und Atkinson besonders empfehlenswert \cite{Wel97}. F"ur die Bewertung der 
Wiederverwendbarkeit haben Cimitile, De Lucia und Minro wichtige Beitr"age 
geleistet \cite{Ci96}. \yyyy
Die empirische Untersuchung von Software-Reuse in der 
Wartung von Li hat gezeigt, wie man wiederverwendbare Funktionen erkennen 
kann \cite{Li97}. \yyyy
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 "uberhaupt wiederverwendet werden sollte bzw. 
kann. Wirtschaftsmanager brauchen einfache, leicht zu ermittelnde Me"swerte, 
die sich in eine Entscheidungsregel leicht einf"ugen lassen. Nur so k"onnen 
Software-Metriken zur groben Entscheidungsfindung beitragen. \yyyy
Au"serdem mu"s zwischen der Art der Wiederverwendung unterschieden werden. Es werden 
andere Me"swerte ben"otigt, je nach dem ob konvertiert oder gekapselt wird,
denn jede Migrationstechnik hat andere Voraussetzungen.
                                          
\section {Metriken f"ur die Konvertierung}  
Bei der Konvertierungstechnik kommt es darauf an, da"s die alte Struktur der 
Programme m"oglichst nahe an die geplante neue Struktur herankommt. Wenn 
also Assembler-Programme in COBOL zu transferieren sind, sollten die 
Assembler-Befehle m"oglichst 1:1 in entsprechende COBOL Anweisungen 
umsetzbar sein. \yyyy
Beispielhaft f"ur 1:1-Transformationen sind MVC-, CLC- und BAL- Befehle,
denn f"ur jeden dieser Befehle gibt es eine "aquivalente 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. \yyyy
Schlie"slich gibt es Assemblerkonstrukte, wie 
Adre"stabellen "uber die auf dynamische Speicherbereiche indirekt 
zugegriffen wird. Solche Assembler-Algorithmen bzw. Befehlsgruppen sind nur 
durch eine v"ollig 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:
\begin{itemize}
\item 1:1 umsetzbar,
\item 1:N umsetzbar,
\item M:N umsetzbar.
\end{itemize}
Die Klassifikationsregeln werden in Form eines Regelbaumes pro Quellsprache 
im Me"sprogramm gespeichert. Auf der ersten Stufe des Baumes werden die 1:1-Um"-setzungen 
erkannt. Sonst wird auf der n"achsten Stufe entschieden, ob es 
sich um eine 1:N-Um"-setzung handelt. Wenn auch dies ausscheidet, wird eine 
M:N-Umsetzung angenommen. \yyyy
Das Verfahren entspricht dem "ublichem Algorithmus 
f"ur regelbasierte Entscheidungsprozesse \cite{He84}. Um als Kandidat f"ur die 
Konvertierung in Frage zu kommen, m"ussen mindestens 60$\%$ der Quellcode-Befehle 
1:1 und mindestens 30$\%$ 1:N in Anweisungen der Zielsprache umsetzbar 
sein. Demnach d"urfen maximal 10$\%$ der Anweisungen manuell umgeschrieben 
werden. Der Rest mu"s per Werkzeug automatisch konvertiert werden \cite{Koz92}. Dies 
gilt sowohl f"ur Datendeklarationen als auch f"ur prozedurale Anweisungen. \yyyy
Wenn 1:1-Um"-setzungen mit 1,0, 1:N-Um"-setzungen mit 0,5 und M:N-Umsetzungen 
mit 0 gewichtet werden, entsteht eine Wiederverwendbarkeitsrate von 0,75. 
Dieses relationale Ma"s wird als Mindestgrenze f"ur Konvertierungsvorhaben 
angesehen \cite{Ba88}. Darunter ger"at der Aufwand einer Konvertierung in die N"ahe 
des Aufwandes f"ur eine Neuentwicklung.

\section {Metriken f"ur die Kapselung}
Bei der Kapselungstechnik werden andere Me"swerte ben"otigt als bei der 
Konvertierung einzelner Anweisungen. Hier geht es um den Anteil der 
Anweisungen, die von der neuen, externen Applikation genutzt werden, d.h. 
sie liegen auf Pfaden, die von au"sen steuerbar sind. Deren Erkennung ist 
das Ziel eines Verfahrens von Lanubile und Visaggio f"ur ablaufbasiertes 
Programm-Slicing \cite{Lan97}. \yyyy
Gekapselt werden Programme als Ganzes, Module und 
Abschnitte bzw. einzelne Prozeduren \cite{Sn96}. Innerhalb des gekapselten Codes 
k"onnen bestimmte Ablaufzweige im gekapseltem Zustand ausgeklammert werden, 
d.h. sie werden durch parametrisierte Bedingungen im Sinne von Dijkstra's 
"`guarded command"' Konzept gesch"utzt. Dies ist der Fall, wenn bestimmte 
Altfunktionen im neuen Gesch"aftsproze"s nicht mehr ben"otigt werden. Aus der 
Analyse des alten Systems mu"s hervorgehen, welche Code-Bausteine, 
Programme, Module, und Prozeduren "uberhaupt gekapselt werden und welche 
Anweisungen und Daten innerhalb der gew"ahlten Bausteine zu benutzen sind. \yyyy
Es kann sein, da"s nur wenige Pfade durch ein Modul f"ur 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"ahlen 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"ur die Ausf"uhrung in der alten 
Umgebung entspricht der 75$\%$-Rate bei der Konvertierung in eine neue 
Umgebung. Es ist immer noch m"oglich, 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. \yyyy
Wiederverwendbarkeit bezogen auf ein Software-Sy"-stem bedeutet, da"s 
mindestens die H"alfte wiederverwendet wird. Denn nur so k"onnen die Kosten 
der Wiederverwendung relativ zu den Kosten einer Neuentwicklung niedrig 
bleiben. \yyyy
Endres hat eine Formel f"ur die Kosten und Nutzen der 
Wiederverwendbarkeit relativ zur Neuentwicklung vorgeschlagen. Dabei kommt 
heraus, da"s die Wiederverwendungsrate mindestens 50$\%$ betragen mu"s \cite{En88}. Derselbe Autor hat auch darauf hingewiesen, da"s
 Reengineering-Kosten nicht 
mehr als 33$\%$ der Neuentwicklungskosten betragen d"urfen, ohne durch den 
Nutzen der Neuentwicklung ausgeglichen zu werden \cite{Sne91}. \yyyy
Es gibt somit zwei Grenzwerte die nicht zu unterschreiten sind:
\begin{itemize}
\item 0,75 bei der Konvertierung,
\item 0,50 bei der Kapselung.
\end{itemize}

\section {Ermittlung der Wiederverwendungsma"se}
Beide Ma"se
\begin{itemize}
\item das Konvertierbarkeitsma"s und
\item das Kapselungsma"s 
\end{itemize}
sind automatisch ermittelbar. Allerdings setzt die Kapselierbarkeitsmessung 
voraus, da"s die zu kapselierenden Ablaufpfade markiert sind. Daf"ur hat der 
Autor ein Tool entwickelt (SOFREDOC), welches dem Anwender erlaubt, sowohl 
datenflu"sbezogene als auch programmablaufbezogene "`Scheiben"' zu markieren, 
die in die neue Anwendung einzubinden sind. Bei dem datenflu"sbezogenen 
Ansatz wird von den erw"unschten Datenergebnissen ausgegangen, um den Weg 
durch das Programm vom Ausgang bis zum Eingang r"uckw"arts zu verfolgen. Beim 
programmablaufbezogenen Ansatz wird von den erw"unschten Einstiegsprodukten 
im Programm ausgegangen, um die Pfade durch das Programm vom Eingang bis 
zum Ausgang vorw"arts zu verfolgen. \yyyy
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"ahlt. \yyyy
Die Z"ahlung der 1:1, 1:N und M:N konvertierbaren Anweisungen wird vom Tool 
SOFAUDIT selbstst"andig durchgef"uhrt. Dies geschieht auf der Grundlage 
vordefinierter Konvertierbarkeitstabellen sowie auf den bereits 
geschilderten Regelb"aumen. Implementiert wurde dies f"ur Assembler-, PL/1- und 
COBOL-Programme.

\section {Zusammenfassung}
In diesem Beitrag wurden zwei Ma"se f"ur die Wiederverwendbarkeit bestehender 
DV-Applikationen vorgeschlagen. \yyyy
Im Falle der Konvertierung wird die 
Umsetzbarkeit des Quellcodes gemessen. Im Falle der Kapselung wird die 
Wiederverwendungsrate gemessen. In beiden F"allen wird eine 
Entscheidungshilfe f"ur die Frage geleistet, ob konvertiert, gekapselt oder 
neuentwickelt werden soll. \yyyy
Das Me"sverfahren 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.

\begin{thebibliography}{99}
\bibitem{Ba88} Bames, B.; Durek, T.; Gaffney, J.: {\it A Framework and Economic Foundation 
for Software Reuse}. in IEEE Tutorial Software Reuse Ed. W. Tracz, 
IEEE Press, L.A., 1988, p. 77
\bibitem{Br95} Brodie, M.; Stonebraker, M.: {\it Migrating Legacy Systems}. 
Morgan Kaufmann Pub., San Francisco, 1995
\bibitem{Chap77} Chapin, N.: {\it A Measure of Software Complexity}. in Proc. of NCC, 
Chicago, 1977, p. 995
\bibitem{Ci96} Cimitile, A.; De Lucia, A.; Minro, M.: {\it A Specification Driven 
Slicing Process for identifying Reusable Functions}. in Journal of 
Software Maintenance, Vol. 8, No. 3, May 1996, p. 145
\bibitem{Da72}Dahl, O.; Dijkstra, E.; Hoare, C.: {\it Structured Programming}. Academic 
Press, London, 1972, p. 63
\bibitem{Du96} Dumke, R.; Foltin, E.; Koeppe, R.; Winkler, A.: {\it Software Qualit"at 
durch Me"stools}. Vieweg Verlag, Braunschweig, 1996
\bibitem{En88} Endres, A.: {\it Software-Wiederverwendung - Ziele, Wege und Erfahrungen}. 
in Informatik Spektrum, Nov. 1988, p. 85
\bibitem{Fe91} Fenton, N.: {\it Software Metrics - A rigorous approach}.
Chapman \& Hall, London, 1991
\bibitem{Hal77} Halstead, M.: {\it Elements of Software Science}. Elvesier Pub., New York, 
1977, p. 79
\bibitem{He84} Hehner, E.: {\it Predicative Programming}. in Comm. of ACM, Vol. 27, No. 
2, Feb. 1984, p.134
\bibitem{He81} Henry, S.; Kafura, D.: {\it Software Structure Metrics based on 
Information Flow}. in IEEE Trans. on S.E. , Vol 7, No. 5, Sept. 1981
\bibitem{ISO} ISO/IEC: {\it Software Product Evaluation - Quality Characteristics and 
Guidelines for their use}. ISO/IEC Standard ISO-9126, 1991
\bibitem{Koz92} Kozacynski, W.; Niny, J.: {\it Program Concept Recognition and 
Transformation} in IEEE Trans. on S.E., Vol. 18, No.12, Dec. 1992, p. 
1065
\bibitem{Lan97} Lanubile, G.; Visaggio, G.: {\it Extracting Reusable Functions by Flow 
Graph-Based Program Slicing}. in IEEE Trans. on S.E., Vol. 23, No. 4, 
April 1997, p. 246
\bibitem{Li97} Li, W.: {\it An Empirical Study of Software Reuse in Reconstructive 
Maintenance}. in Journal of Software Maintenance, Vol. 9, No. 2, March 
1997, p. 69
\bibitem{Ca81} McCabe, T.: {\it A Complexity Measure}. in IEEE Trans. on S.E., Vol. 7, 
No. 5, Sept.1981
\bibitem{Scha94} Schach, S.: {\it Economic Impact of Software Reuse on Maintenance}. in 
Journal of Software Maintenance, Vol. 6, No. 4, July 1994, p. 185
\bibitem{Sne91} Sneed, H.: {\it Economics of Software Reengineering}. in Journal of 
Software Maintenance, Vol. 3, No. 3, Sept. 1991, p. 163
\bibitem{Sn91} Sneed, H.: {\it Software mu"s messbar werden}. in Information Management
4/91, Nov. 1991, p.56
\bibitem{Sn95} Sneed, H.: {\it Understanding Software through Numbers - A metric based 
Approach to Program Comprehension}. in Journal of Software 
Maintenance, Vol. 7, No. 6, Nov. 1995, p. 405
\bibitem{Sn96} Sneed, H.: {\it Encapsulating Legacy Software for Use in Client/Server 
Systems}. in Proc. of 3rd Conf. in Reverse Eng., IEEE Press, Monterey, 
Nov. 1996, p. 104
\bibitem{Wel97} Welker, K.; Oman, P.; Atkinson, G.: {\it Development and Applikation of an 
automated Source Code Maintainability Index}. in Journal of Software 
Maintenance, Vol. 9, No. 3, May 1997, p. 127
\bibitem{Zu90} Zuse, H.: {\it Software Complexity - Measures and Methods}. 
de Gruyter Verlag, Berlin, 1991
\end{thebibliography}

\end{document}

