SOEN 6431 Winter 2011 - Program Slicing Updated

SOEN 6431 SOFTWARE MAINTENANCE AND EVOLUTION

Dr. Juergen Rilling

Notes:#7 Program Slicing

Program comprehensionProgram comprehension is the study of how software engineers understand programs. Program comprehension is needed for:

Debugging Code inspection Test case design Re-documentation Design recovery Code revisions

2

Program comprehension process Involves the use of existing knowledge to acquire new knowledge about a program. Existing knowledge:

Programming languages Computing environment Programming principles Architectural models Possible algorithms and solution approaches Domain-specific information Any previous knowledge about the code Code functionality Architecture Algorithm implementation details Control flow Data flow

New knowledge:

3

Comprehension techniques Reading by step-wise abstraction

Determine the function of critical subroutines, work through the program hierarchy until the function of the program is determined.

Checklist-based reading

Readers are given a checklist to focus their attention on particular issues within the document. Different readers were given different checklists, therefore each reader would concentrate on different aspects of the document.Defects are categorized and characterized (e.g., data type inconsistency, incorrect functionality, missing functionality, etc.) A set of steps (a scenario) is then developed for each defect class to guide the reader to find those defects. Similar to defect-based reading, but instead of different defect classes, readers have different roles (tester, designer and user) to guide them in reading.

Defect-based reading

Perspective-based reading

4

Sources of variationAside from the issue of how comprehension occurs, comprehension performance and effectiveness are affected by many factors:

Maintainer characteristics Program characteristics Task characteristics

Program

8

Maintainer characteristicsFamiliarity with code base Application domain knowledge Programming language knowledge Programming expertise Tool expertise Individual differences

Program

9

Program characteristicsApplication domain Programming domain Quality of problem to be understood Program size and complexity Availability and accuracy of documentation

10

Task characteristicsTask type

Experimental: recall, modification Perfective, corrective, adaptive, reuse, extension.

Task size and complexity Time constraints Environmental factors

11

ModelsMental models

Internal working representation of the software under consideration.

Cognitive models

Theories of the processes by which software engineers arrive at a mental model.

Program

CognitiveMod el

Mental Model

12

Mental modelsStatic elements

Text structure knowledge Microstructure Chunks (macrostructure) Plans (objects) Hypotheses

Dynamic elements

Strategies (chunking and cross-referencing)Beacons Rules of discourse

Supporting elements

13

Text structureThe program text and its structure

Control structure: iterations, sequences, conditional constructs Variable definitions Calling hierarchies Parameter definitions

Microstructure actual program statements and their relationships.

14

ChunksContain various levels of text structure abstractions. Also called macrostructure. Can be identified by a descriptive label. Can be composed into higher level chunks.

15

Plans (objects) Knowledge elements for developing and validating expectations, interpretations, and inferences. Include causal knowledge about information flow and relationships between parts of a program. Programming plans

Based on programming concepts. Low level: iteration and conditional code segments. Intermediate level: searching, sorting, summing algorithms; linked lists and trees. High level All knowledge about the problem area. Examples: problem domain objects, system environment, domainspecific solutions and architectures.

Domain plans

16

Hypotheses Conjectures that are results of comprehension activities that can take seconds or minutes to occur. Three types:

Why hypothesize the purpose/rationale of a function of design choice. How hypothesize the method for accomplishing a certain goal. What hypothesize classification.

Hypotheses are drivers of cognition. They help to define the direction of further investigation. Code cognition formulates hypotheses, checks them whether they are true or false, and revises them when necessary. Hypotheses fail for several reasons:

Cant find code to support a hypothesis. Confusion due to one piece of code satisfying different hypothesis. Code cannot be explained.

17

Supporting elementsBeacons

Cues that index into existing knowledge. A swap routine can be a beacon for a sorting function. Experienced programmers recognize beacons much faster than novice programmers. Used commonly in top-down comprehension.

Rules of discourse

Rules that specify programming conventions. Examples: coding standards, algorithm implementations, expected use of data structures.

18

Mental models dynamic elementsStrategies

Sequences of actions that lead to a particular goal.

Actions

Classify programmer activities implcitly and explicitly during a maintenance task.

Episodes

Sequences of actions.

Processes

Aggregations of episodes.

19

StrategiesGuide the sequence of actions while following a plan to reach a goal. Match programming plans to code.

Shallow reasoning do not perform in-depth analysis; stop upon recognition of familiar idioms and programming plans. Deep reasoning perform detailed analysis.

Mechanisms for understanding

Chunking Cross-referencing

20

ChunkingCreates new, higher-level abstraction structures Labels replace the detail of the lower level chunks.

21

Cross-referencingMap program parts to functional descriptions

temp = a; a = b; b = temp;

swap

for (i=0; i a[i] then begin min := a[i]; s := min; end; output (s); i := i +2; end; output (max) ; output (min);

Data Dependence:Represents a data flow (definition-use chain).=> Data dependence between 2 and 7 but not between 2 and 8.

Control Dependence:The execution of a node depends on the outcome of a predicate node. => Control dependence between node 6 and 8, but not between 6 and 15.

13 1415 16

48

Program Dependence Graph (PDG)A Program dependence graph is formed by combining data and control dependencies 49 between nodes. 1 input (n,a); 2 max := a[1]; 3 min := a[1]; 4 i := 2; 5 s:= 0; 6 while i n do begin 7 if max < a[i] then begin 8 max := a[i]; 9 s := max; end; 10 if min > a[i] then begin 11 min := a[i]; 16 12 s := min; end;

1314

i := i +2; end; 15 output (max); 16 output (min);

output (s);

Data Dependency Control Dependency49

Any problems within this PDG?

Slicing Example50

1 main( ) 2{ 3 int i, sum; 4 sum = 0; 5 i = 1; 6 while(i a[i]; output(s); i := i +2; in output (max); output (min);

13111412 613 1514 1615

69

Dynamic Dependency Graph

Execution trace based AlgorithmsBackward Algorithm Original dynamic slicing algorithm presented by Korel and Laski in 1988. Based on a recorded execution trace for an input x.

Traces the execution trace backwards to derive dynamic data and control dependencies. Create individual node in the PDG for each executed statement.

70

Backward AlgorithmProgram Execution for n=2, a[1,2] at statement 15

71

16

15

Static and Dynamic slice for variable sStatic Slice: 1 2 3 4 5 6 7 8 9 10 input (n,a); max := a[1]; min := a[1]; i := 2; s:= 0; while i n do begin if max < a[i] then begin max := a[i]; s := max; end; if min > a[i] then begin min := a[i]; s := min; end; output (s); i := i +2; end; Dynamic Slice: 1 2 4 5 6 input (n,a); max := a[1]; i := 2; s:= 0; while i n do begin 7 if max < a[i] then begin 8 max := a[i]; 9 s := max; end; 13 output (s); 14 i := i +2; end;

72

11 1213 14

Dynamic slice for variable s on input n=2, a[1,2];

73

new

Another Dynamic Slice Example

74

new c

Another Dynamic Slice Example

75

new

Static vs. Dynamic Slice

76

new

Any problems?Q: How many nodes do we have in a Dynamic Dependency Graph? A: ???Q: How many dynamic slices can we compute? A: ???

Q: Any suggestion on how to reduce the complexity? A: ???

77

Dynamic Forward Slicing

78

Algorithm based on removable blocks Presented by Korel in 1994 and extended later on. Execution trace based. Overcomes limitations of dependency based algorithms with respect to unstructured programs. Uses data dependency. Uses removable blocks instead of control dependencies. All Blocks are initially marked as removable => identify the blocks which are not removable.

79

Challenge: Complexity of Dynamic Slicing

B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B13 B14 B15

11 22 33 44 55 66 77 88 99 1010 1311 1412 613 1514

input (n,a); max := a[1]; min := a[1]; i := 2; s := 0; i< n max < a[i]; max := a[i]; s := max; min > a[i]; output(s); i := i + 2; i < n output (max];

A removable block is informally:The smallest part of program text that can be removed during a slice computation without violating the syntactical correctness o