Use-case-bezogenes reverse-engineering von entscheidungstabellen

(1)

Use-Case-bezogenes Reverse-Engineering von Entscheidungstabellen

Rainer Schmidberger

Institut für Softwaretechnologie, Abteilung Software Engineering Universität Stuttgart

Universitätsstr. 38 70569 Stuttgart

rainer.schmidberger@informatik.uni-stuttgart.de

Abstract: Obwohl Entscheidungstabellen zur Spezifikation von Programmablauf- logik bereits seit über vier Jahrzehnten etabliert sind, finden sie in den Veröffentli- chungen der letzten Jahre kaum mehr Beachtung. Dabei sind Entscheidungstabel- len 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 Le- gacy-Programmcode, nach Use Cases getrennt, wieder Entscheidungstabellen ab- geleitet werden.

1 Einleitung

Betriebswirtschaftliche Software-Systeme bilden einen bedeutenden Anteil des heutigen Software-Bestandes. Verwaltungen und Finanzdienstleister, also Banken und Versiche- rer, 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 Be- nutzungsschnittstellen 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

(2)

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

• Der ursprünglichen Entwicklung lagen Entscheidungstabellen als Implementie- rungsvorgabe zu Grunde, die Tabellen sind nur nicht mehr verfügbar.

• Der Implementierung lagen andere Spezifikationsformen wie z. B. Textdokumen- te 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 „Reverse- Engineering von Entscheidungstabellen“ nicht ganz korrekt, da ja nie explizit Entschei- dungstabellen in den Code eingeflossen waren. Trotzdem ist gerade in diesem Fall eine Darstellung der Ablauflogik als Entscheidungstabelle besonders interessant. Der Analy- tiker erhält damit (erstmals) eine vollständige, präzise und kompakte Übersicht der imp- lementierten Sonderfälle. Um Entscheidungstabellen oder Sonderfälle aus Programmco- de 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 Programmco- de des betrachteten Prozesses und anderem Programmcode vorzunehmen.

• Der Programmcode ist oft in einem schlechten Zustand. Größere Bereiche des Pro- grammcodes sind nicht erreichbar (toter Code). Viele Fallunterscheidungen enthal- ten 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äfts- prozess (oder auch Use Case) die Programmabläufe mit den relevanten Bedingungster- men der Sonderfälle und Entscheidungstabellen auswertet. Die folgenden zwei Informa- tionsquellen werden dabei verwendet:

1. der Programmcode der untersuchten Software und hier speziell die Verzwei- gungen und deren Bedingungsterme

2. 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

(3)

2 Verwandte Arbeiten

Eisenbarth, Koschke und Simon beschreiben in [Ei03] ein Verfahren der Feature- Lokalisierung, 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 Betrach- tung 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 Behand- lung von Fallunterscheidungen und Schleifen. Cavouras sieht den Nutzen seines Verfah- rens 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 existie- ren Werkzeuge, die aus den Entscheidungstabellen direkt Programmcode generieren.

Der besondere Vorteil von Entscheidungstabellen gegenüber anderen Spezifikations- formen 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 über- sichtlich 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

(4)

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.

F F

T -

Bedingung 2

Regeln (condition entry)

Aktionen (action stub)

Regel k

… Regel 3

Regel 2 Regel 1

Bedingungen (condition stub)

x Aktion j

x x

Aktion 2

x x

x Aktion 1

- -

- F

Bedingung i

F T

Bedingung 1

F F

T -

Bedingung 2

Regeln (condition entry)

Aktionen (action stub)

Regel k

… Regel 3

Regel 2 Regel 1

Bedingungen (condition stub)

x Aktion j

x x

Aktion 2

x x

x Aktion 1

- -

- F

Bedingung i

F T

Bedingung 1

Don‘t careDon‘t Beding- care

ungen ver- wenden Eingabe- daten

Aktionen erzeugen Ausgabe- daten 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 Akti- onen sind als sortierte Liste zu betrachten und müssen in der genau spezifizierten Rei- henfolge 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 Entscheidungs- tabellen 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 CASE- Anweisungen (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 Entscheidungstabel- len nachgebildet werden. Art Lew [Le82] zeigt, dass eine Entscheidungstabelle als wie- derholbares CASE-Statement betrachtet werden kann. Enthält eine Programmsequenz eine eingebettete Schleife, wird diese wie eine Aktion in der Entscheidungstabelle be- handelt. 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

(5)

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 Äqui- valenzklassen 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 Se- quenz von Entscheidungen, die an den Verzweigungen getroffen werden. Ein Entschei- dungskriterium 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 IF A >= 5 AND <=9 0020 STATEMENT1 0030 ELSE 0040 STATEMENT2 0050 END-IF

Wenn A den Wert 2 hat, liefert uns die Ausführung des Programms einen Pfad (0010, 0040), die Sequenz von Termen, die den Pfad bestimmen, und außerdem den Hinweis, dass es zu diesem Term mindestens einen weiteren Pfad für den Fall gibt, dass die auf A angewendeten Terme ein anderes Resultat liefern. Da wir zunächst nicht wissen, wie viele Pfade sich hier verbergen, sprechen wir unbestimmt von einem „dunklen Pfad“.

Zwei schwach äquivalente Eingabedatensätze di und dj sind stark äquivalent, wenn alle angewendeten Terme das gleiche Resultat ergeben, wenn also die annotierten, d.h. um die ausgewerteten Terme erweiterten Pfade, gleich sind. Im Beispiel oben wäre ein Da- tensatz dem ersten stark äquivalent, wenn A = 4 enthielte, denn der annotierte Pfad ist in beiden Fällen 0010 (A ≥ 5 → FALSE, A ≤ 9 → TRUE), 0040. Dagegen wäre A = 10 nur schwach äquivalent, der annotierte Pfad ist 0010 (A ≥ 5 → TRUE, A ≤ 9 → FALSE), 0040.

Nun erfolgt die Betrachtung der zuvor ersetzten Schleifen. Für jede der durch ein SEi ersetzten Si werden die dort im Schleifenkörper enthaltenen Schleifen Sij wieder durch eine Schleifenersetzung SEij ersetzt. Für den so entstandenen schleifenlosen Schleifen- körper wird in gleicher Weise wie für das Programm P’ verfahren. Alle dunklen Pfade sowie schwache und starke Äquivalenzen werden festgestellt. Je Schleifenkörper entstehen so eigene, untergeordnete Äquivalenzklassen.

76

(6)

4 Bildung von Entscheidungstabellen

4.1 Grundsätzliches Vorgehen

Die These dieser Arbeit ist, dass stark äquivalente Eingabeklassen jeweils einem Fall in einer Entscheidungstabelle entsprechen. Darum werden viele, womöglich alle verfügba- ren Eingabedatensätze verarbeitet und die annotierten Pfade verglichen. Wenn ein neuer annotierter Pfad entdeckt wird, kann er als neuer Fall gespeichert werden.

Wenn noch kein einziger Datensatz angewendet wurde, stellt das gesamte Programm einen dunklen Pfad dar. Jede Ausführung (d.h. jeder Programmlauf mit einem weiteren Datensatz) erweist sich entweder als stark äquivalent zu einer früheren Ausführung oder beseitigt einen dunklen Pfad, indem sie einen neuen annotierten Pfad und in der Regel auch neue dunkle Pfade liefert.

In der Praxis ist natürlich nicht damit zu rechnen, dass am Ende alle dunklen Pfade beseitigt sind. Für die verbliebenen dunklen Pfade können unterschiedliche Ursachen vor- liegen:

• Der gefundene dunkle Pfad ist fachlich durchaus sinnvoll und gewollt. Es war nur kein entsprechender Eingabedatensatz angewendet worden. Programmcode zur Fehlerbehandlung zählt oft zu dieser Gruppe. In diesem Fall sollte ein entsprechender Eingabedatensatz erzeugt und in einem folgenden Programmablauf angewendet werden.

• Der gefundene dunkle Pfad ist bedeutungslos geworden, weil er eine Ausnahmebehandlung für Eingabedatensätze darstellt, die so nicht mehr exist- ieren (weil es diese Eingabedatensätze z. B. nur zeitlich befristet gab).

• Es handelt sich bei dem dunklen Pfad um Programmcode, der für sinnvolle Ein- gabedaten nicht erreichbar und damit unsinnig ist.

Welche dieser Ursachen vorliegt, kann nicht automatisch erkannt werden. Hierzu sind schließlich Programmdurchsichten der entsprechenden Programmcode-Bereiche erfor- derlich.

4.2 Technische Umsetzung

Die technische Umsetzung wurde bislang u. a. für die Programmiersprache VS COBOL II vorgenommen. Der gesamte Ablauf gliedert sich in drei Abschnitte:

1. Parsen, Analysieren und Instrumentieren des Programmcodes

2. Ausführen des instrumentierten Programmcodes mit den Eingabedaten. Protokol- lieren der Pfade und Bedingungsterme in einer relationalen Datenbank

3. Ermitteln und Konsolidieren der Entscheidungstabellen durch Datenbank- Auswertung

77

(7)

Abbildung 2: Technische Umsetzung

Der Parser sowie die Instrumentierung sind programmiersprachenabhängig, die grund- sätzliche Vorgehensweise ist aber ansonsten für die verschiedenen Programmierspra- chen die gleiche.

Ein wichtiger Aspekt ist die Use-Case-bezogene Vorgehensweise. Der Anwender (oder auch Analytiker) wird die Eingabedatensätze derart wählen, dass nur ein zuvor festge- legter Use Case abgearbeitet wird. Die entstehenden Entscheidungstabellen werden dann auch nur die Einträge aufweisen, die zum Kontext des ausgewählten Use Case gehören.

Parsen, Analysieren und Instrumentieren

Die Instrumentierung soll dem Programmcode Code-Zeilen hinzufügen, die während des Programmablaufs die bearbeiteten Anweisungs-Blöcke und die Resultate der Bedingungsterme protokollieren. Hierzu müssen die Anweisungen, die den Kontrollfluss beeinflussen, erkannt und die (in der Regel logischen) Ausdrücke der IF- und CASE-Anweisungen ausgewertet werden.

Programmcode (IBM VS-COBOL)

Parsen mitjavaccund

Java Tree-Builder COBOL Grammatik

Instrumentierter COBOL Code

Parsen und Instrumentieren

Reguläre Daten für einen ausge- wählten Use Case

Programmausführung Repository

Verdichten und Konsolidieren

Entscheidungstabellen

Programmausführung

Auswertung

78

(8)

Als Werkzeug zum Parsen von Programmcode bieten sich Compiler-Frontends an, die heute für viele Programmiersprachen auch frei verfügbar sind. In der hier vorgenommenen Implementierung wurde eine COBOL-Grammatik (siehe [La01]) für den Java-Compiler-Compiler (javacc) verwendet.

Jeder Term sowie jeder Anweisungs-Block erhält eine eindeutige Nummer. Für geschachtelte Entscheidungstabellen, wie sie beispielsweise bei Schleifen entstehen, sind diese Nummern wichtig, damit bei mehrfachem Durchlaufen des Programms eindeutige Zuordnungen einer Code-Sequenz zu einer Entscheidungstabelle möglich sind. Instrumentiert sei nun das bereits gezeigte Beispielprogramm (der Original-Code ist fett gedruckt):

0040 IF A>=5

0050 MOVE 47 TO SEQUENCE-ID

0060 MOVE 'IF SUBTERM' TO SEQUENCE-TYPE 0070 MOVE 1 TO SUBTERM

0080 PERFORM PROTOCOL-STATEMENT 0090 ELSE

0110 MOVE 'ELSE SUBTERM' TO SEQUENCE-TYPE 0120 MOVE 1 TO SUBTERM

0130 PERFORM PROTOCOL-STATEMENT 0140 END-IF

0150 IF A<=9

0160 MOVE 47 TO ACT-BLOCK-ID

0170 MOVE 'IF SUBTERM' TO SEQUENCE-TYPE 0180 MOVE 2 TO SUBTERM

0190 PERFORM PROTOCOL-STATEMENT 0200 ELSE

0220 MOVE 'ELSE SUBTERM' TO SEQUENCE-TYPE 0230 MOVE 2 TO SUBTERM

0240 PERFORM PROTOCOL-STATEMENT 0250 END-IF

0260 IF A >= 5 AND <=9

0270 MOVE 47 TO SEQUENCE-ID 0280 MOVE 'IF' TO SEQUENCE-TYPE 0290 MOVE 0 TO SUBTERM

0300 PERFORM PROTOCOL-STATEMENT 0310 STATEMENT1

0320 ELSE

0330 MOVE 47 TO SEQUENCE-ID 0340 MOVE 'ELSE' TO SEQUENCE-TYPE 0350 MOVE 0 TO SUBTERM

0360 PERFORM PROTOCOL-STATEMENT 0370 STATEMENT2

0380 END-IF

Die eindeutigen Nummern für Bedingungen und Code-Sequenzen (im Beispiel die 47) werden bei der Instrumentierung fortlaufend vergeben. Mit derselben Nummer wird der Term sowie die Original-Programmzeilen-Nummer im Repository protokolliert. Im

79

(9)

Beispiel erkennt man an den Zeilen bis 250 die Auswertung der einzelnen Bedingungs- terme, die als Subterm bezeichnet werden.

Weitere Sequenz-Typen gibt es für Prozedurbeginn, Fallunterscheidung sowie den Se- quenz-Typ „LOOP“ und „LOOP-END“, der den Ein- und Ausstieg eines Schleifen- Körpers signalisiert.

Allen, die COBOL nicht kennen, wird das Code-Beispiel umständlich implementiert vorkommen. Natürlich wären Funktionsaufrufe mit den Übergabeparametern kompakter als die Befüllung globaler Variablen mit anschließendem Prozeduraufruf. Die Program- miersprache COBOL kennt aber keine Parameterübergabe.

Durchführen der Programmabläufe

Mit dem nun instrumentierten Programmcode wird das Programm in seiner normalen Testumgebung, also mit der üblichen Infrastruktur wie Datenbank, Middleware usw.

betrieben. Der Betrieb erfolgt mit den Eingabedatensätzen des regulären Betriebs. Der Programmcode ist aber nun um die instrumentierten Code-Zeilen erweitert und wird etwas langsamer ablaufen.

Die Auswahl der Eingabedatensätze wird typischerweise auf einzelne Use Cases einge- schränkt. Beim Betrieb einer Personal-Gehalts-Software wird so z. B. zunächst nur eine Monatsabrechnung (durchaus für verschiedene Monate) abgearbeitet. Die Protokollie- rung, die dann zu den Entscheidungstabellen führt, enthält dann nur Aktionen, die zu diesem Use Case gehören. Die Entscheidungstabellen bleiben darurch übersichtlicher.

Auswertungen

Als Resultat einer Use-Case-Abarbeitung liegt eine (durchaus sehr lange) Pfad-Sequenz der abgearbeiteten Anweisungen - dem annotierten Pfad - in der Datenbank vor. Die Auswertung des annotierten Pfades erfolgt nun derart, dass zunächst zyklische Pfad- Sequenzen entfernt und durch einen Schleifenersetzer ersetzt werden. Der Schleifener- setzer verweist dann auf die herausgeschälten Pfad-Sequenzen, zu denen später eine eigene Entscheidungstabelle erzeugt wird. Sei beispielsweise der folgende annotierte Pfad gespeichert:

Line Sequence-ID Sequence-

Type Condition

1 1 FUNCTION

2 2 LOOP

3 47 CONDITION A>5 → TRUE, A<=9 → TRUE

4 23 IF

5 2 LOOP

6 47 CONDITION A>5 → TRUE, A<=9 → FALSE

7 24 ELSE

8 2 LOOP

10 23 IF

11 2 LOOP

80

(10)

12 47 CONDITION A>5 → FALSE, A<=9 → FALSE

13 24 ELSE

14 2 LOOP-END

Zyklen werden nun derart erkannt, dass im Pfad von vorne beginnend der erste

„LOOP“-Eintrag verwendet wird. Die Sequenz-ID dieses Eintrags sei c, die Zeile n. Es wird nun der nächste folgende Eintrag mit Sequence-ID=c und Line>n gesucht. Ange- nommen, 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 Sequence-

ID Sequence-

Type Condition 1 1 FUNCTION 2 Schleifen-

ersetzung 2

Als einzelne Pfad-Zyklen ergeben sich:

Schleife 2 / 1. Durchlauf Zeile Sequence-

ID Sequence-

Type Condition 2 2 LOOP

4 23 IF

ID Sequence-

6 47 CONDITION A>5 → TRUE, A<=9 → FALSE

7 24 ELSE

ID Sequence-

9 47 CONDITION A>5 → TRUE, A<=9 → TRUE 10 23 IF

ID Sequence-

81

(11)

12 47 CONDITION A>5 → FALSE, A<=9 → FALSE 13 24 ELSE

Aus den so gewonnenen schleifenfreien Pfad-Sequenzen wird nun eine Entscheidungs- tabelle erzeugt, indem alle enthaltenen Bedingungen in den Bedingungsteil der Ent- scheidungstabelle gestellt werden. Die jeweiligen Resultate werden in den Regel-Teil eingetragen, die ausgeführten Aktionen werden im Aktionen-Teil markiert. Tritt in einer Pfad-Sequenz eine Bedingung der Entscheidungstabelle nicht auf, wird im Regel-Teil ein „Don’t care“ markiert.

So entsteht die nicht-konsolidierte Entscheidungstabelle, die so viele Regeln enthält, wie Schleifendurchläufe vorlagen.

Regel 1 Regel 2 Regel 3 Regel 4 A>5 TRUE TRUE TRUE FALSE A<=9 TRUE FALSE TRUE FALSE

2 LOOP x x x x

23 IF x x

24 ELSE x x

Nun erfolgt die Konsolidierung der Entscheidungstabelle. Diese wird in den folgenden Schritten durchgeführt:

• Zuerst wird nachgesehen, ob es Regeln mit gleichen Aktionen gibt.

• Wenn ja, dann werden jeweils zwei dieser Regeln paarweise betrachtet.

• Sind die Bedingungsresultate der zwei betrachteten Regeln gleich, liegt starke Äquivalenz vor. Eine der beiden Regeln wird gestrichen. Im Beispiel sind das Regel 1 und Regel 3.

• Wenn sich die Bedingungsresultate der zwei betrachteten Regeln in nur einer Zeile unterscheiden, dann werden die beiden Regeln zu einer Regel zusammenge- fasst und die beiden unterschiedlichen Bedingungsresultate werden durch „Don’t care“ ersetzt. Im Beispiel könnten so Regel 2 und Regel 4 konsolidiert werden.

Für die Bedingung A>5 würde ein „Don’t care“ eingetragen [Ba00].

5 Zusammenfassung der Ergebnisse und Aussichten

Es wurde ein Verfahren vorgestellt, das Entscheidungstabellen aus bestehendem Pro- grammcode wiedergewinnen kann. Das Verfahren basiert auf durchgeführten Pro- grammablä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

(12)

Enthält ein untersuchter Programmcode sehr viele Programmschleifen, werden entspre- chend viele Entscheidungstabellen erzeugt. Der gewünschte Nutzen, das Programmver- stä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 Java- Version, 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 Akademi- scher 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 grammar Version 1.0.4.

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