James R. Lyle

Using program slicing in software maintenance

Program slicing is applied to the software maintenance problem by extending the notion of a program slice (that originally required both a variable and line number) to a decomposition slice, one that captures all computation on a given variable, i.e., is independent of line numbers. Using the lattice of single variable decomposition slices ordered by set inclusion, it is shown how a slice-based decomposition for programs can be formed. One can then delineate the effects of a proposed change by isolating those effects in a single component of the decomposition. This gives maintainers a straightforward technique for determining those statements and variables which may be modified in a component and those which may not. Using the decomposition, a set of principles to prohibit changes which will interfere with unmodified components is provided. These semantically consistent changes can then be merged back into the original program in linear time. >

A Two-Person Inspection Method to Improve Prog ramming Productivity

A6xfmct-Thls paper reviews current research and investigates the effect of n two-person Inspeetion method on programmer productivity. This method is similar to tbe current larger team method in stressing f d t detection, but doCS not use a moderator. The experiment used a Pretest-Posttest Control Group design. An experimental and control group of novices each completed two programming assignments. The amount of time taken to complete each program. (Timel, Timel) was recorded for each subject. The subjects or the experlmental group did either a design inspection, a code inspection, o r both during the development of the second program. An analysis of variance was performed nnd the relationship between Timel and Time2 was modeled for both groups. A comparison of the models revealed (he experimental group improved significantly in programming speed as a result of using tbe two-person inspection. I t also a p peared as though this method was more elkctive at improving the performance of the slower programmers. This two-person method could have its application in those envimnmeats wbcre access to larger team resourcm Is nol available. If further researeta establishes consistency with this method then it might be useful IS a transition to the larger team method.

Application of the pointer state subgraph to static program slicing

A new technique for performing static analysis of programs that contain unconstrained pointers is presented. The technique is based on the pointer state subgraph: a reduced control flow graph that takes advantage of the fact that in any program there exists a smaller program that computes only the values of pointer variables. The pointer state subgraph is useful in building static analysis tools. As an example, the application of the pointer state subgraph to program slicing is considered. Finally, some experimental results, obtained using the ANSI-C slicer Unravel, are reported. These results show a clear reduction in the time taken to compute data-flow information from programs that contain pointers. They also show a substantial reduction in the space needed to store this information.

Software safety and program slicing

Describes a novel application of program slicing to two issues of software safety: functional diversity and the validation and verification of safety-critical components. Software quality assurance auditors are faced with a myriad of difficulties, ranging from inadequate time to inadequate CASE tools. One particular problem is the localization of safety-critical code that may be interleaved throughout the entire system. Once this code is located, its effects throughout the system are difficult to ascertain. A method is presented that uses program slicing to mitigate these difficulties in two ways. First, it is shown that program slicing can be used to locate all code that contributes to the value of variables that might be part of a safety-critical component. Second, it is shown that slicing-based techniques can be used to validate functional diversity, i.e. that there are no interactions of one critical component with another critical component and that there are no interactions of noncritical components with the safety-critical components.<<ETX>>