Use-Case-bezogenes Reverse-Engineering von Entscheidungstabellen Rainer Schmidberger Institut für Softwaretechnologie, Abteilung Software Engineering Universität Stuttgart Universitätsstr. 38 70569 Stuttgart [email protected] Abstract: Obwohl Entscheidungstabellen zur Spezifikation von Programmablauflogik bereits seit über vier Jahrzehnten etabliert sind, finden sie in den Veröffentlichungen der letzten Jahre kaum mehr Beachtung. Dabei sind Entscheidungstabellen gut geeignet, Kundenanforderungen der Form „wenn ... dann ...“ präzise und übersichtlich zu spezifizieren, und das, ohne einer Realisierungsform vorzugreifen. Viele Veröffentlichungen in den Jahren 1965 bis 1975 hatten die Umsetzung von Entscheidungstabellen in Programmcode zum Inhalt. Dieser Artikel beschreibt genau die umgekehrte Umsetzung: Zum Zweck der besseren Wartung sollen aus Legacy-Programmcode, nach Use Cases getrennt, wieder Entscheidungstabellen abgeleitet werden.

1 Einleitung Betriebswirtschaftliche Software-Systeme bilden einen bedeutenden Anteil des heutigen Software-Bestandes. Verwaltungen und Finanzdienstleister, also Banken und Versicherer, gehören zu den Betreibern dieser Verwaltungs-Software. Der technische Gegenstand von Verwaltungs-Software ist typischerweise einfach: Einlesen von Eingabedaten, einfache Berechnungen (also einfache Arithmetik, keine Differenzialgleichungen o. ä.), Abarbeiten von Entscheidungstabellen und Speicherung von Ausgabedaten. Über Benutzungsschnittstellen werden die Eingabedaten erfasst und die Ausgabedaten angezeigt. Die Komplexität von Verwaltungs-Software liegt nicht in komplizierten Details wie z. B. Algorithmen, sondern in ihrer Größe, dem durch die Entscheidungstabellen bedingt komplizierten Kontrollfluss und den vielen Schnittstellen und Abhängigkeiten. Die in Verwaltungs-Software enthaltenen Entscheidungstabellen sind durch eine direkte Auswertung von Eingabedaten geprägt. Es werden also, gesteuert von Merkmalen der Eingabedaten, Aktionen ausgeführt. Diese Merkmale sind typischerweise invariant, d. h. sie steuern zwar den Programmablauf, gehen aber selbst unverändert aus dem Vorgang hervor. Auch Sonderfälle oder Ausnahmen bilden in der genannten Programmgruppe einen wichtigen Anteil der Programmlogik. Die Behandlung von Sonderfällen erfolgt üblicherweise als „wenn ... dann ...“-Konstrukte, wobei auch hier die „wenn“-

72

Bedingung Merkmale der Eingabedaten prüft. Für das Auffinden von Entscheidungstabellen aus bestehendem Legacy-Programmcode gibt es somit zwei unterschiedliche Ausgangssituationen: • •

Der ursprünglichen Entwicklung lagen Entscheidungstabellen als Implementierungsvorgabe zu Grunde, die Tabellen sind nur nicht mehr verfügbar. Der Implementierung lagen andere Spezifikationsformen wie z. B. Textdokumente der Form „wenn ... dann ... sonst ...“ zu Grunde. Zudem wurden im Laufe der (langen) Zeit Sonderfälle oder Ausnahmen hinzugefügt oder verändert.

Für die zuletzt geschilderte Ausgangssituation ist die Formulierung „ReverseEngineering von Entscheidungstabellen“ nicht ganz korrekt, da ja nie explizit Entscheidungstabellen in den Code eingeflossen waren. Trotzdem ist gerade in diesem Fall eine Darstellung der Ablauflogik als Entscheidungstabelle besonders interessant. Der Analytiker erhält damit (erstmals) eine vollständige, präzise und kompakte Übersicht der implementierten Sonderfälle. Um Entscheidungstabellen oder Sonderfälle aus Programmcode zu gewinnen, wird in der Praxis meist ohne technische Hilfen analysiert. Das ist aber einerseits aufwändig, andererseits fehlerträchtig: • •

Viele Geschäftsprozesse sind in einem monolithischen Programmcode implementiert. Dies macht es schwierig, die genaue Abgrenzung zwischen dem Programmcode des betrachteten Prozesses und anderem Programmcode vorzunehmen. Der Programmcode ist oft in einem schlechten Zustand. Größere Bereiche des Programmcodes sind nicht erreichbar (toter Code). Viele Fallunterscheidungen enthalten Fälle, die keine Rolle mehr spielen.

Aus diesen Gründen ist es nicht wirtschaftlich, ohne technische Hilfen Programmcode zu analysieren. In diesem Artikel wird ein werkzeuggestütztes Verfahren beschrieben, das für tatsächlich sinnvolle Eingabedaten für (genau) einen ausgewählten Geschäftsprozess (oder auch Use Case) die Programmabläufe mit den relevanten Bedingungstermen der Sonderfälle und Entscheidungstabellen auswertet. Die folgenden zwei Informationsquellen werden dabei verwendet: 1. 2.

der Programmcode der untersuchten Software und hier speziell die Verzweigungen und deren Bedingungsterme die existierenden Eingabedaten des regulären Betriebs

Offensichtlich stellen die existierenden Eingabedaten des regulären Betriebs nur einen Bruchteil der möglichen Eingabedatenmenge dar; innerhalb der Menge der fachlich sinnvollen Eingabedaten ist ihr Anteil aber typischerweise relativ hoch. Der Nutzen der wiedergewonnenen Entscheidungstabellen liegt in der verbesserten Wartung oder der Dokumentation zur Neuimplementierung der Systeme.

73

2 Verwandte Arbeiten Eisenbarth, Koschke und Simon beschreiben in [Ei03] ein Verfahren der FeatureLokalisierung, das auf Programmabläufen und statischer Analyse des Programmcodes basiert. Für ein aufgerufenes Feature werden die Programmcode-Funktionen gesammelt, die beim Ausführen aufgerufen werden. Aus dem Funktions-Aufruf wird, nach Betrachtung mehrerer Features und Anwendung der formalen Begriffsanalyse, auf den Beitrag einer Funktion zur Implementierung des Features geschlossen. Der Kontrollfluss wird nicht detailliert betrachtet. Cavouras beschreibt in [Ca74] ein Verfahren zur Konvertierung von Programmcode in Entscheidungstabellen. Er betrachtet den Programmcode aber nur statisch, worin der Hauptunterschied zum hier vorgestellten Verfahren besteht. Es fehlen auch die Behandlung von Fallunterscheidungen und Schleifen. Cavouras sieht den Nutzen seines Verfahrens in der Fehlersuche und Optimierung der Programme.

3 Grundlagen 3.1 Entscheidungstabellen Entscheidungstabellen als Darstellungsform von Programmlogik gibt es schon sehr lange [Pr65]. Für die Programmiersprache COBOL gibt es auch für das Einbeziehen von Entscheidungstabellen in den Entwicklungsprozess eine längere Tradition. Hier existieren Werkzeuge, die aus den Entscheidungstabellen direkt Programmcode generieren. Der besondere Vorteil von Entscheidungstabellen gegenüber anderen Spezifikationsformen besteht darin, dass sie • • •

für Fachexperten oder Analytiker leicht lesbar und leicht darstellbar, für Implementierer präzise und in der Darstellung recht kompakt sind.

Innerhalb moderner Darstellungsformen wären am ehesten die Aktivitätendiagramme der UML [UML98] mit Entscheidungstabellen vergleichbar. Die Entscheidungstabellen sind dabei aber deutlich kompakter und leichter darstellbar. Mit Hilfe von Entscheidungstabellen können Entscheidungsprozesse kompakt und übersichtlich spezifiziert werden. Im Prinzip ist eine Entscheidungstabelle nichts anderes als eine übersichtliche Darstellung des Sachwissens in der Form „wenn ... dann ...“ [Ba00]. Eine Entscheidungstabelle bildet Eingaben über Bedingungen auf Ausgaben (Aktionen) ab. Die Darstellung - siehe Abbildung 1 - erfolgt in einer Tabelle mit vier Quadranten: oben links stehen die Bedingungsdefinitionen (condition stub), oben rechts die Regeln in Form kombiniert erfüllter oder nicht erfüllter Bedingungen (condition entry), links unten

74

stehen die Aktionsdefinitionen (action stub) und rechts unten sind die für eine Regel auszuführenden Aktionen selektiert (action entry). Eine Kombination von Bedingungen, die zu einer speziellen Aktionssequenz führt, wird als Regel bezeichnet. Regeln (condition entry) Bedingungen (condition stub)

Regel 1

Regel 2

Regel 3

…

Regel k

Bedingung 1

T

F

T

F

Bedingung 2

-

T

F

Bedingung i

F

-

-

Bedingungen verwenden Eingabedaten

Aktionen erzeugen Ausgabedaten

x

Don‘t care

F -

Aktionen (action stub) x

Aktion 1 Aktion 2

x

Aktion j

x

x x

Aktion wird ausgeführt

Abbildung 1: Entscheidungstabelle Eine Tabelle ist dann eindeutig, wenn je Eingabedatensatz nur eine Regel anwendbar ist und die Reihenfolge, in der die Bedingungen geprüft werden, ohne Belang ist. Die Aktionen sind als sortierte Liste zu betrachten und müssen in der genau spezifizierten Reihenfolge abgearbeitet werden. Entscheidungstabellen spezifizieren in der Regel nicht die Entscheidungsprozesse eines Gesamtsystems, sondern eher eines Teilprozesses. Im Kontext der UML würde man einen Use Case durch eine oder mehrere Entscheidungstabellen weiter spezifizieren. Wie aber schon angedeutet, sieht die UML dies nicht mittels Entscheidungstabellen, sondern mittels Aktivitätendiagrammen vor. Auch wenn Entscheidungstabellen üblicherweise für Sequenzen von IF- oder CASEAnweisungen (oder andere nicht-wiederholende Konstrukte) verwendet werden, können Programmschleifen durch wiederholte Bearbeitung einer Tabelle nachgebildet werden. Eine Entscheidungstabelle bildet dann eine Schleife, wenn mindestens eine Regel zur erneuten Anwendung dieser Entscheidungstabelle führt. Konkret können alle durch Programmablaufgraphen darstellbaren Programme über wiederholte Entscheidungstabellen nachgebildet werden. Art Lew [Le82] zeigt, dass eine Entscheidungstabelle als wiederholbares CASE-Statement betrachtet werden kann. Enthält eine Programmsequenz eine eingebettete Schleife, wird diese wie eine Aktion in der Entscheidungstabelle behandelt. Für die Schleife selbst wird eine eigene Entscheidungstabelle erstellt. 3.2 Definitionen Sei P ein prozedurales Programm. Wir bilden das schleifenfreie Programm P’ aus P, indem jede in P enthaltene Schleife Si (Schleifenbedingung und Schleifenkörper) durch

75

eine neu hinzugefügte Anweisung SEi, die Schleifenersetzung, ersetzt wird. Die nun folgende Betrachtung gilt für dieses schleifenfreie Programm P’. Sei di ein vollständiger Eingabedatensatz für das Programm P. Mit dem Datensatz di durchläuft P’ deterministisch einen ganz bestimmten Programmpfad, den Pfad pi. Der Pfad ist die vollständige Sequenz der ausgeführten Anweisungen. Wir bilden nun Äquivalenzklassen von Eingabedatensätzen. Zwei Eingabedatensätze di und dj sind schwach äquivalent, wenn die beiden zugeordneten Pfade pi und pj gleich sind. Jeder Pfad ist bestimmt durch den Eintrittspunkt in das Programm und durch die Sequenz von Entscheidungen, die an den Verzweigungen getroffen werden. Ein Entscheidungskriterium an einer Programmverzweigung besteht, wie von Frühauf, Ludewig und Sandmayr beschrieben, aus einem oder mehreren Termen [Fr97]. Sei beispielsweise ein kurzes Programm (COBOL-Syntax) 0010 0020 0030 0040 0050

IF A >= 5 AND =5 MOVE 47 TO SEQUENCE-ID MOVE 'IF SUBTERM' TO SEQUENCE-TYPE MOVE 1 TO SUBTERM PERFORM PROTOCOL-STATEMENT ELSE MOVE 47 TO SEQUENCE-ID MOVE 'ELSE SUBTERM' TO SEQUENCE-TYPE MOVE 1 TO SUBTERM PERFORM PROTOCOL-STATEMENT END-IF IF A= 5 AND 5 → TRUE, A5 → TRUE, A5 → TRUE, A5 → FALSE, An gesucht. Angenommen, dieser Eintrag wird gefunden und die Zeile sei m. Dann erstreckt sich der erste wiederholte Bereich von Zeile n bis m-1. Dieser Vorgang mit Sequence-ID=c wird so lange fortgesetzt, bis der Sequenz-Typ „LOOP-END“ erreicht ist. Statt der Schleife wird der Schleifenersetzer in den annotierten Pfad eingesetzt und ersetzt damit alle Zeilen von Zeile n bis zum „LOOP-END“. Danach wird der nächste „LOOP“-Eintrag gesucht, der ebenso abgearbeitet wird. Für die einzelnen Schleifenköper wird in gleicher Weise verfahren. Für das oben angeführte Beispiel ergibt sich als nicht-zyklischer Rest: Zeile 1 2

SequenceID 1

SequenceType FUNCTION Schleifenersetzung 2

Condition

Als einzelne Pfad-Zyklen ergeben sich: Zeile 2 3 4

Zeile 5 6 7

Zeile 8 9 10

Zeile 11

SequenceID 2 47 23

Schleife 2 / 1. Durchlauf SequenceCondition Type LOOP CONDITION A>5 → TRUE, A5 → TRUE, A5 → TRUE, A5 → FALSE, A5 A5 würde ein „Don’t care“ eingetragen [Ba00].

5 Zusammenfassung der Ergebnisse und Aussichten Es wurde ein Verfahren vorgestellt, das Entscheidungstabellen aus bestehendem Programmcode wiedergewinnen kann. Das Verfahren basiert auf durchgeführten Programmabläufen und kann somit für einzelne Use Cases relevante Kontrollstrukturen erkennen und Entscheidungstabellen erzeugen. Damit hat dieses Verfahren Vorteile gegenüber manueller Code-Durchsicht oder auch anderen auf statischer Code-Analyse basierenden Verfahren.

82

Enthält ein untersuchter Programmcode sehr viele Programmschleifen, werden entsprechend viele Entscheidungstabellen erzeugt. Der gewünschte Nutzen, das Programmverständnis zu verbessern, würde dann nur bedingt erzielt. Das Verfahren hat auch Schwächen, wenn Aussprünge aus einer Schleife (z. B. mittels GOTO oder auch Exceptions) vorgenommen werden. Hieran wird weiter gearbeitet. Ebenso entsteht derzeit eine JavaVersion, die, bedingt durch das objektorientierte Paradigma, die Polymorphie speziell lösen muss. Für COBOL-Programme wurde eine exemplarische Umsetzung erfolgreich implementiert. Der Einsatz in einem konkreten Projekt mit etwa 40 KLOC läuft derzeit.

Literaturverzeichnis [Ba00]

Helmut Balzert,: Lehrbuch der Software-Technik, 2. Auflage. Spektrum Akademischer Verlag, Heidelberg, Berlin, 2000

[Ca74]

John C.Cavouras: On the Conversation of Programs to Decision Tables: Method and Objectives. Comm. ACM 17, 8 (August 1974), 456-462

[Ei03]

Eisenbarth T., Koschke R., Simon D.: Locating Features in Source Code. IEEE Transactions on Software-Engineering (März 2003), 210-224

[Fr97]

Frühauf K., Ludewig J., Sandmayr H.,: Software-Prüfung. vdf Hochschulverlag AG, Zürich, 1997

[La03]

Ralf Lämmel: VS COBOL II http://www.cs.vu.nl/grammars/vs-cobol-ii/

[Le82]

Art Lew: On the Emulation of Flowcharts by Decision Tables. Comm. ACM 25, 12 (Dezember 1982), 895-905

[Pr65]

Laurence I. Press: Conversation of Decision Tables to Computer programs, Comm. ACM 8, 6 (Juni 1965), 385-390

[UML98]

I. Jacobson, G. Booch, J.Rumbaugh: The Unified Software Development Process. Addison-Weseley, 1998

83

grammar

Version

1.0.4.