Software Maintenance. Program Slicing im Software Maintenance. Fehlerlokalisierung UNIV.-PROF. DIPL.-ING. DR. FRANZ WOTAWA

Transkript

1 Software Maintenance UNIV.-PROF. DIPL.-ING. DR. FRANZ WOTAWA Technische Universität Graz, Institut für Softwaretechnologie Program Slicing im Software Maintenance Program Slicing kann im Bereich der Wartung von Software zur Unterstützung mehrere Aufgaben verwendet werden. In diesem Kapitel widmen wir uns der Fehlersuche in Programmen bzw. der Verwendung von Slices zur Abschätzung von Auswirkungen bei Änderungen im Programmcode. Fehlerlokalisierung Bei der Fehlerlokalisierung geht es darum, die Ursachen für ein Fehlverhalten des Programms zu ermitteln. Das heißt, dass zumindest ein Testfall zur Verfügung stehen muss, bei dem sich das Programm fehlerhaft verhält. Ein Fehlverhalten kann sich hierbei auf unterschiedliche Arten äußern. Ein Programm kann auf eine unbestimmte bzw. unerwartete Art beendet werden, z.b. durch einen Core Dump oder eine Exception. Ein Programm kann zwar korrekt beendet werden aber ein falsches Ergebnis liefern, oder ein Programm befindet sich in einer Endlosschleife und wird nie beendet. Für unsere weiteren Betrachtungen nehmen wir an, dass das Programm korrekt beendet wird aber ein falsches Resultat für eine oder mehrere Variablen liefert. In diesem Fall kann Slicing sicherlich verwendet werden, um die Fehlerlokalisierung zu unterstützen. Da alle Statements eines Slices einen Einfluss auf die Variablen haben, die im Slicing-Kriterium angegeben sind, muss man nur einen Slice für die fehlerhaften Variablen berechnen. Beispiel: Wir werden uns diese Idee für die Fehlerlokalisierung anhand eines einfachen Beispiels ansehen. Gegeben sei folgendes Programm: 1. sum =0; 2. i =0;

2 3. while (i<=n) do 4. sum=sum+i; 5. i=i+1; end while; 6. Angenommen wir erwarten nun für n = 2 den Wert 2 für i an der Stelle 6. Als Anmerkung sei erwähnt, dass in diesem Testfall der Wert von sum nicht spezifiziert ist. Führt man das Programm aus, erhält man für i den Wert 3 und wir erhalten einen Widerspruch zum Testfall. Um das Programm nun für die Fehlersuche einzuschränken, können wir einen Slice für die Variable i an der Stelle 6 berechnen. Wie einfach nachzuprüfen ist, erhalten wir folgendes Programm für das Slicing-Kriterium (6,{i}): i =0; 3. while (i<=n) do i=i+1; end while; 6. Da das Programm in diesem Fall kleiner als das Originalprogramm ist, hilft es bei der Fokussierung auf die relevanten Statements. Wir können die Idee zur Fehlerlokalisierung mit Hilfe von Slicing als Algorithmus formalisiert darstellen: Algorithm ComputeCauses Input: Program Π and test-case T where T specifies variable values before the first and at the last statement n of program Π which has to be the empty statement. Output: Program Π Π that explains differences in program execution 1. Let the program Π run and compute a set CV comprising all variables where their values are in contradiction with the specified values in T.

3 2. Let Π be the slice computed for the slicing criterion (n,cv) where n is the last statement in Π 3. Return Π Die Einschränkung, dass nur Variablenwerte am Ende eines Programms spezifiziert werden können, kann durch entsprechende Adaptionen behoben werden. Der angeführte Algorithmus implementiert die zu Grunde liegende Idee direkt und reicht für unsere Betrachtungen vollkommen aus. Solange das Input-Programm terminiert, terminiert auch ComputeCauses. Die Frage ist nun, ob der Algorithmus hinsichtlich der Angaben minimale Erklärungen produziert. Wir werden sehen, dass die nicht der Fall ist. Betrachten wir hierzu folgendes Beispiel: Beispiel: Gegeben ist folgendes einfaches Programm, das den Umfang und die Fläche eines Kreises berechnet. 1. r = d/1; 2. c = 2*r*3.14; 3. a = r*r*3.14; 4. Das Programm ist offensichtlich falsch, da in der ersten Zeile das Statement r=d/2 stehen sollte. Dieser Fehler bzw. das Fehlverhalten wird auch durch folgenden Testfall gefunden: d=2, c=6.28, a= 3.14 In diesem Fall berechnet das Programm für c und für a den Wert Somit entsprechen die Werte für die beiden Variablen c und a nicht den spezifizierten Werten. Das Programm ComputeCauses liefert als Resultat den Slice für (4,{c,a}), das ist das ganze Programm, zurück. Die Frage ist nun, ob wir für das obige Beispiel ein besseres Resultat berechnen können. Dies ist insofern wichtig, da das Beispiel folgende Schlussfolgerung zulässt. Hat ein Fehler Auswirkungen auf mehrere Variable, dann enthält der Slice alle Statements, die einen Einfluss auf diese Variablen haben, und wird somit relativ groß. Unter diesem Gesichtspunkt ist es besser, für jede Variable, die im Widerspruch zum Testfall steht, einen Slice zu berechnen und die Slices entsprechend zu kombinieren.

4 Für das Beispiel erhalten wir auf diese Weise 2 Slices: (4,{c}) = {1,2} (4,{a}) = {1,3} Wie einfach zu sehen ist kommt nur das Statement 1 in beiden Slices vor. Dieses Statement ist somit eine minimale Erklärung für das Fehlverhalten von 2 Variablen. Definition (Conflict): Ein Konflikt/Conflict für ein gegebenes Programm und einen Testfall ist ein Slice (n,{x}) für genau eine Variable x, deren berechneter Wert im Widerspruch zum spezifizierten Wert im Testfall steht. Für einen Testfall können wir die Menge aller Konflikte CO mit Hilfe von Slicing einfach bestimmen. Wir benötigen dazu nur die Menge aller Variablen CV, die im Widerspruch zum Testfall stehen. CO = {(n,{x}) x CV }. Jedes Element in CO beinhaltet alle Statements, die zu einem falsch berechneten Wert führen. Um nun eine minimale Erklärung für alle falsch berechneten Variablen zu bekommen, muss man nach Statements suchen, die in allen bzw. möglichst vielen Konflikten vorkommen. Solche Statements können einfach mit Hilfe einer so genannten Hitting-Set-Berechnung geliefert werden. Ein Hitting-Set ist dabei eine Menge, die von jedem Konflikt zumindest ein Element enthält. Im generellen sind Hitting-Sets für allgemeine Mengen von Mengen wie folgt definiert. Definition (Hitting-Set): Gegeben sei eine Menge F von Mengen. Hitting-Set h für F ist eine Teilmenge von x F x, die geschnitten mit jeder Menge f F ungleich der leeren Menge ist, d.h. f h {}. Wir sagen, dass ein Hitting-Set h minimal ist, wenn es keine Menge h h gibt, die ebenfalls ein Hitting-Set ist. Betrachten wir unser einfaches Kreis-Beispiel von vorher. Die Menge CO = {{1,2},{1,3}} (Anmerkung: Wie bereits gesagt, verwenden wir das letzte Statement hier nicht mehr) enthält alle Konflikte. Wir erhalten folgende minimalen Hitting-Sets: {1} {2,3}

5 Beide Hitting-Sets sind mögliche Erklärungen für das Fehlverhalten. Im ersten Hitting-Set wird das 1. Statement als mögliche Ursache herangezogen. Im zweiten Hitting-Set geht man von einem Mehrfachfehler aus. Auch diese Erklärung ist nicht unbedingt falsch. Man kann das Programm auch korrigieren, indem man bei beiden Statements entsprechende Änderungen vornimmt. Allerdings wird man in der Praxis möglichst kleine Hitting-Sets bevorzugen, da man den Änderungsaufwand so minimiert. Der folgende Algorithmus liefert minimale Erklärungen für Konflikte: Algorithm ComputeMinimalCauses Input: Program Π and test-case T where T specifies variable values before the first and at the last statement n of program Π which has to be the empty statement. Output: A set of hitting-sets for all conflicts. 1. Let the program Π run and compute a set CV comprising all variables where their values are in contradiction with the specified values in T. 2. Let CO be the set of all conflicts, i.e., CO = {(n,{x}) x CV }, where all empty statements are removed from the elements of CO. 3. Sort CO wrt. the cardinality of its elements and remove all supersets of sets occurring in CO. We assume the left-most element has the lowest cardinality. 4. Return all minimal hitting-sets of CO. Als Anmerkung sei erwähnt, dass die Hitting-Sets der Konflikte keine ausführbaren Programme mehr sind. Welchen Typ des Slicings (statisch vs. dynamisch) man für die Konfliktberechnung verwendet, hat keinen Einfluss auf die Berechnung der Hitting-Sets aus den Konflikten. D.h. man kann durchaus auch dynamisches Slicing passierend auf mehreren Testfällen für die Berechnung der Konfliktmengen verwenden und aus diesen dann die Hitting-Sets berechnen. Was noch fehlt um das Kapitel abzuschließen, ist ein Algorithmus zur Berechnung aller (minimalen) Hitting-Sets. Bevor wir den Algorithmus formal behandeln, werden wir die grundlegenden Ideen anhand unseres Beispiels diskutieren. Die Menge der Hitting-Sets CO war für das Kreis-Beispiel {{1,2},{1,3}}. Wir wissen darüber hinaus aus der Definition von Hitting-Sets, das diese Elemente aus allen Mengen von CO enthalten müssen. Somit können

6 wir einen gerichteten Graphen aufbauen, der mögliche Hitting-Sets beinhaltet. Wir gehen dabei wie folgt vor. Wir erzeugen einen Wurzelknoten. Danach wählen wir das am weitest Links stehende Element (in unserem Fall {1,2}. Für jedes Element aus dieser Menge generieren wir einen neun Knoten und verbinden diesen mit den Wurzelknoten. Diese Kante enthält als Label (Markierung) das entsprechende Element. Für unser Beispiel erzeugen wir im ersten Schritt folgenden Graphen: 1 2 Danach bearbeiten wir jeden neuen Knoten n. Zuerst berechnen wir die Menge h(n), die alle Element der Kantenmarkierung vom Wurzelknoten zu n enthält. Danach suchen wir ein Element x aus CO, wo h(n) x gleich der leeren Menge ist. In diesem Fall haben wir noch nicht alle Elemente im Hitting-Set. Haben wir ein solches x gefunden, dann erzeugen wir wieder neue Knoten und Kanten wie bereits beschrieben. Gibt es ein solches x nicht, haben wir ein Hitting-Set gefunden und wir markieren diesen Knoten mit. In diesem Fall ist h(n) ein Hitting-Set. Dieser Prozess wird erst beendet, wenn keine neuen Knoten und Kanten mehr erzeugt werden können. In unserem Fall erhalten wir folgenden Graphen als Resultat: Der Algorithmus berechnet in der oben beschriebenen Form noch keine minimalen Hitting- Sets. Der linke untere Knoten ist mit markiert. Das Hitting-Set h von diesen Knoten ist

7 jedoch {1,2}. Dieses Hitting-Set ist nicht minimal, da bereits {1} minimal ist. Wir können den Algorithmus jedoch einfach erweitern um dieses Problem auszuschalten. Wir fügen bei der Behandlung eines Knotens n nur folgende Regel ein. Gibt es bereits einen Knoten m, der mit markiert ist und wo h(m) h(n) ist, dann markieren n mit und bearbeiten n nicht mehr. Verwendet man diese Regel erhält man folgenden gerichteten Graphen, der nur mehr minimal Hitting-Sets für Knoten, die mit markiert sind, enthält Algorithm HittingSets Input: Set of sets F. Output: A directed graph representing all minimal hitting-sets for F. 1. Create the root vertex of the graph and let V be the set with the root vertex as the only element. 2. Let V be the empty set. 3. Unless V is not empty do the following: a. Select a vertex n from V and compute h(n), i.e., the set of all arc labels from the root vertex to n. b. From left to right choose the first element x of F where the intersection from h(n) and x is empty. c. If there is such an element, do the following: i. For each element i of x generate a new vertex m and an edge which is marked by i. Add the new vertex m to V if and only if there is no previously generated m which is labelled with and where h(m ) h(m). Otherwise mark m with. d. Otherwise, mark n with.

8 e. If V is empty, then return the directed graph. Otherwise, let V be V and go to 2. In der Literatur werden noch andere Algorithmen zur Berechnung von Hitting-Sets beschrieben. HittingSets selber ist eine modifizierte Version eines Algorithmus, der von Ray Reiter [2] beschrieben und von Greiner et al. [3] verbessert wurde. Mehr Informationen über den Zusammenhang zwischen Slicing und Hitting-Sets bzw. der darunter liegenden Diagnosetheorie findet man in [4]. Abschätzung von Auswirkungen bei Programmänderungen Eine wichtige Aufgabe im Software Maintenance ist es die Auswirkung von Änderungen abschätzen zu können. Hier interessiert zum Beispiel eine Antwort auf die Frage, ob eine Änderung eines Statements einen Einfluss auf den Wert einer Variablen an einer beliebigen Stelle im Code haben kann. Diese und ähnliche Problemstellungen können mit Hilfe von Slicing beantwortet werden. Angenommen wir haben ein Programm Π wo wir das Statement S durch das Statement S ersetzen wollen. Die Frage ist nun, ob diese Änderung eine Auswirkung auf eine Variable x an der Stelle n haben kann. Zur Beantwortung dieser Frage berechnen wir einen Slice (n,{x}) für das geänderte Programm Π. Ist nun S im Slice enthalten, dann wissen wir, dass es einen möglichen Einfluss gibt. Im anderen Fall hat S keinen Einfluss auf x an der Stelle n. Interessant ist nun die Frage ob diese Änderung sich auch auf das Verhalten auswirken kann. Angenommen S war im Slice (n,{x}) für Π enthalten und S ist nicht mehr im selben Slice für Π. In diesem Fall wissen wir, dass es zumindest eine Änderung in den Abhängigkeiten gibt. Diese sollte entsprechend durch Testfälle abgefragt werden. Wir können natürlich auch alle Variablen finden, auf die eine Änderung Einfluss hat. Zu diesem Zweck müssen wir nur für alle Variablen an einer Stelle getrennt einen Slice berechnen und überprüfen ob die Änderung im Slice ist. Ist dies der Fall, dann hat die Änderung eine Auswirkung auf die Variable. Diese Art der Berechnung ist nicht sehr effizient. Dies gilt vor allem für große Programme mit vielen Variablen. Der Grund dafür ist,

9 dass wir zur Beantwortung der Frage eigentlich eine Berechnung in Vorwärtsrichtung, d.h. vom Statement zur Variablenposition, brauchen. Die Berechnung von Slices erfolgt jedoch Rückwärts, d.h. von der Position der Variablen zum Programmanfang hin. Eine Reduktion beim Berechnungsaufwand kann somit nur erfolgen, wenn Slices in Vortwärtsrichtung (Forward Slices) berechnet werden. In diesem Fall erhält man alle Statements, die von einem früheren Statement beeinflusst werden können. Natürlich können Forward Slices nicht durch Backward Slices simuliert werden. Forward Slices beschreiben hier mögliche Auswirkungen eines Statements auf den Rest eines Programms während die Backward Slices alle Statements berechnet, die einen Einfluss auf eine bestimmte Variable an einer Stelle haben. Allerdings führt die Diskussion der Anwendung von Backward Slices direkt zu Forward Slices und deren Anwendung. Wir werden nun die Berechnung von Forward Slices vorstellen, wobei wir auf einen Algorithmus zur Berechnung von Flüssen in gerichteten Graphen zurückgreifen werden. In unserem Fall ist der Graph ein Control Flow Graph (CFG). Wir berechnen mit Hilfe des Algorithmus die relevanten Variablen und in einem zweiten Schritt die Statement, die im Slice vorhanden sein müssen. Infolge werden wir den Algorithmus auch für anderen Aufgaben einsetzten (siehe auch [5]). Der Algorithmus verwendet die Mengen gen und kill, die für Knoten definierte sind um von Eingangswerten (in) auf Ausgangswerte (out) zu schließen. Dabei werden alle Elemente aus kill von in entfernt und alle Elemente aus gen hinzugefügt um out zu berechnen. Die Menge in wird mit Hilfe der Ausgangswerte der Vorgängerknoten (pred; predecessors) berechnet. Algorithm FlowPropagation Input: Directed Graph G Output: Computed out values for each vertex 1. For each vertex n of G do: a. Let in(n) = {} and out(n) = gen(n) (in(n) \ kill(n)) 2. While any in(n) or out(n) changes do: a. For each vertex n of G do: i. Let in(n) = p pred(n) out(p) ii. Let out(n) = gen(n) (in(n) \ kill(n))

10 3. Return G Um diesen Algorithmus für die Berechnung der Forward Slices zu verwenden, müssen wir zuerst gen und kill definieren. Zusätzlich führen wir ein Prädikat inslice für Knoten ein, das dann und nur dann wahr ist, wenn der Knoten des CFG im Forward Slice enthalten ist. Die Mengen in und out sollen nun die relevanten Variablen enthalten, die im CFG propagiert werden sollen. Die Funktionen gen und kill können mit Hilfe der definierten Variablen (def) und referenzierten Variablen (ref) eines Statements wie folgt berechnet werden: gen( n) = { x x def ( n) ( ref ( n) in( n) {} inslice( n) )} kill( n) = {} Eine Variable wird neu hinzugefügt, wenn sie im Statement n definiert wird und das Statement entweder bereits im Forward Slice enthalten ist oder eine relevante Variable eines Vorgängerknotens referenziert wird. Am Beginn der Berechnung ist der Wahrheitswert von inslice(n) für alle Knoten False, außer für den Knoten, für den der Forward Slice berechnet werden soll. Danach erfolgt die Berechnung der relevanten Variablen mit Hilfe von FlowPropagation. Für alle Knoten, wo ref(n) out(n) {} gilt, wird der Wahrheitswert von inslice auf True geändert. Gilt inslice(n) für einen Testknoten n eines CFG, dann wird inslice von allen Knoten, die im Wirkungsbereich von n sind (INFL(n)), ebenfalls auf True gesetzt. Der Algorithmus FlowPropagation wird wiederum ausgeführt. Dieser Prozess geschieht so lange, bis keine weitere Änderung von inslice erfolgt. Algorithm forwardslice Input: CFG G and a selected vertex v. Output: G where inslice is true for elements of the forward slice 1. Let inslice(v) be true. For all other vertices, let inslice(n) be false. 2. Use FlowPropagation to compute relevant variables. 3. For all vertices where ref(n) out(n) {} set inslice(n) to true. 4. If inslice(n) is true for a test vertex n, set inslice(m) to true for all m INFL(n). 5. If inslice is changed from false to true for at least one vertex, go to Otherwise, return G.

11 Der Algorithmus funktioniert ähnlich dem Algorithmus für Statische (Backward) Slices. Es werden die relevanten Variablen in mehreren Iterationen berechnet. Ein Unterschied besteht in der Angabe des Slicing-Kriteriums und in der Berechnungsrichtung. Ein ähnlicher Algorithmus kann auch für Backward Slices angegeben werden. Zu diesem Zweck muss jedoch FlowPropagation leicht modifiziert werden (siehe auch [5]). Beispiel: Zur Illustration des Algorithmus werden wir den Forward Slice für Statement 2 im folgenden Programm berechnen. 1. r =0; 2. i =0; 3. while (i<x) do 4. r=r+y; 5. i=i+1; end while; 6. Zu diesem Zweck erstellen wir zuerst den CFG: Entry r=0 i=0 while (i<x) Exit r=r+y i=i+1 Nach dem ersten Durchgang des Algorithmus FlowPropagation haben wir folgende Situation:

12 Entry inslice=f, out={} r=0 inslice=f, out={} i=0 while (i<x) r=r+y inslice=t, out={i} inslice=f, out={i} inslice=f, out={i} Exit inslice=f, out={i} i=i+1 inslice=f, out={i} Vor dem zweiten Durchgang wird inslice neu berechnet und wir erhalten: Entry inslice=f, out={} r=0 inslice=f, out={} i=0 while (i<x) r=r+y inslice=t, out={i} inslice=t, out={i} inslice=t, out={i} Exit inslice=f, out={i} i=i+1 inslice=t, out={i} Da es Änderungen in inslice gegeben hat, erfolgt ein nochmaliger Aufruf von FlowPropagation, der die out-mengen verändert aber sonst zu keinen neuen Veränderungen führt. Somit erhalten wir als Lösung folgenden CFG.

13 Entry inslice=f, out={} r=0 inslice=f, out={} i=0 while (i<x) r=r+y inslice=t, out={i} inslice=t, out={i,r} inslice=t, out={i,r} Exit inslice=f, out={i,r} i=i+1 inslice=t, out={i,r} Die Berechnung des Forward Slice für das Statement 2 führt zum Programm: i =0; 3. while (i<x) do 4. r=r+y; 5. i=i+1; end while; 6. Wobei nur das erste Statement nicht relevant ist. Dieses Ergebnis ist jedoch keineswegs überraschend, da das Statement 2 sicherlich einen Einfluss auf den Rest des Programms hat. Das Ergebnis für den Forward Slice für Statement 1 sieht jedoch anders aus. Wir erhalten folgendes Programm als Resultat: 1. r = 0; r=r+y; Auch hier entspricht das Ergebnis den Erwartungen. Das Statement 1 hat nur einen Einfluss auf das Statement 4. D.h. der Initialwert der Variable r beeinflusst das Ergebnis von r nach der Programmausführung.

14 Literatur [1] Frank Tip. A survey on program slicing techniques. Journal of programming languages, 3(3), September citeseer.ist.psu.edu/tip95survey.html [2] R. Reiter, A theory of diagnosis from first principles, Artificial Intelligence 32(1):57-95, [3] R. Greiner, B.A. Smith, R.W. Wilkerson. A correction to the algorithm in Reiter s theory of diagnosis, Artificial Intelligence 41(1):79-88, [4] F. Wotawa, On the relationship between model-based debugging and program slicing, Artificial Intelligence 135: , [5] P. Tonella and A. Potrich, Reverse Engineering of Object-Oriented Code, Springer, 2005.