Program slicing is a software analysis technique conceived of and developed in the late 70s and early 80s by the late Mark Weiser to remove code from a program that does not affect a given computation. A program slice is any selection of program statements that maintains the same behavior as the original program at a specific point while considering a particular set of variables, known as the slicing criterion. This technique permits a software engineer to focus on an immediate computation and safely ignore statements and variables that do not contribute to that focus. We will briefly review the basics of program slicing and some of the myriad of related techniques and applications that developed over the years to tackle the problems that software engineers confront while sitting at their workstations.

This paper outlines the content and techniques used to teach software maintenance to American university sophomores (second year students) who have had 3 semesters of programming. The course uses an introductory text that is geared to the maturity of the audience. By turning the project of the introductory course into a large software evolution exercise, the major topics of software engineering can still be easily introduced and examined. We present the course organization, evaluation rubrics, and student and instructor experiences from six offerings of the course to demonstrate that treating the project in an introductory course as a software evolution exercise on a large, mature system is a viable alternative to the usual (greenfield) approaches. As an added benefit, meaningful contributions to the open source community can be made.

Comprehension of computer programs is daunting, due in part to clutter in the software developer's visual environment and the need for frequent visual context changes. Previous research has shown that nonspeech sound can be useful in understanding the runtime behavior of a program. We explore the viability and advantages of using nonspeech sound in an ecological framework to help understand the static structure of software. We describe a novel concept for auditory display of program elements in which sounds indicate characteristics and relationships among a Java program's classes, interfaces, and methods. An empirical study employing this concept was used to evaluate 24 sighted software professionals and students performing maintenance-oriented tasks using a 2×2 crossover. Viability is strong for differentiation and characterization of software entities, less so for identification. The results suggest that sonification can be advantageous under certain conditions, though they do not indicate the overall advantage of using sound in terms of task duration at a 5% level of significance. The results uncover other findings such as differences in comprehension strategy based on the available tool environment. The participants reported enthusiasm for the idea of software sonification, mitigated by lack of familiarity with the concept and the brittleness of the tool. Limitations of the present research include restriction to particular types of comprehension tasks, a single sound mapping, a single programming language, and limited training time, but the use of sound in program comprehension shows sufficient promise for continued research.

There has been considerable interest in improving the capability to identify communities within large collections of social networking data. However, many of the existing algorithms will compartment an actor (node) into a single group, ignoring the fact that in real-world situations people tend to belong concurrently to multiple groups. Our work focuses on the ability to find overlapping communities by aggregating the community perspectives of friendship groups, derived from egonets. We will demonstrate that our algorithm not only finds overlapping communities, but additionally helps identify key members, which bind communities together. Additionally, we will highlight the parallel feature of the algorithm as a means of improving runtime performance.

Robustness of a program is the degree of system correctness of all parts. Measuring robustness is a goal for many researchers. In this paper, program slicing is used to build a robustness hierarchy, where this hierarchy will be used to test, and build a robust program.

A dependence cluster is a set of program statements, all of which are mutually inter-dependent. This article reports a large scale empirical study of dependence clusters in C program source code. The study reveals that large dependence clusters are surprisingly commonplace. Most of the 45 programs studied have clusters of dependence that consume more than 10% of the whole program. Some even have clusters consuming 80% or more. The widespread existence of clusters has implications for source code analyses such as program comprehension, software maintenance, software testing, reverse engineering, reuse, and parallelization.

In order to characterize and improve software architecture visualization practice, the paper derives and constructs a qualitative framework, with seven key areas and 31 features, for the assessment of software architecture visualization tools. The framework is derived by the application of the Goal Question Metric paradigm to information obtained from a literature survey and addresses a number of stakeholder issues. The evaluation is performed from multiple stakeholder perspectives and in various architectural contexts. Stakeholders can apply the framework to determine if a particular software architecture visualization tool is appropriate to a given task. The framework is applied in the evaluation of a collection of six software architecture visualization tools. The framework may also be used as a design template for a comprehensive software architecture visualization tool.

Operational software is constantly evolving. Regression testing is used to identify the unintended consequences of evolutionary changes. As most changes affect only a small proportion of the system, the challenge is to ensure that the regression test set is both safe (all relevant tests are used) and inclusive (only relevant tests are used). Previous approaches to reducing test sets struggle to find safe and inclusive tests by looking only at the changed code. We use decomposition program slicing to safely reduce the size of regression test sets by identifying those parts of a system that could not have been affected by a change; this information will then direct the selection of regression tests by eliminating tests that are not relevant to the change. The technique properly accounts for additions and deletions of code. We extend and use Rothermel and Harrold's framework for measuring the safety of regression test sets and introduce new safety and precision measures that do not require a priori knowledge of the exact number of modification-revealing tests. We then analytically evaluate and compare our techniques for producing reduced regression test sets.

Program comprehension of unfamiliar software is a daunting task and existing comprehension environments, although helping significantly, do not fully alleviate the information overload involved. The visual medium has been well-explored in aiding software engineers understanding of source code and other artifacts concerned with maintaining existing software systems, but the use of non-visual representations, e.g. sound, has not gone far beyond simple noises to indicate error conditions or attract attention in a running program. This paper aims to explore the program comprehension problems that could usefully be addressed using sound. There are many dimensions to this problem and this paper addresses a new area open program comprehension research, defining the problem space and beginning to populate it with possible solutions. We expect the primary focus of this session to be on software comprehension and sound although many disciplines are likely to become involved in the research that flows from it

Abstract The attempt to design and integrate consistent changes to an existing system is the essence of software maintenance. Software developers also confront similar problems: there are changes during testing and the release of new system builds. Whether in development or maintenance, changes to evolving systems must be made consistently; that is, without damaging correct computations. It is difficult for the programmer to ascertain the complete effect of a code change; the programmer may make a change to a program that is syntactically and semantically legal, but which has ripples into the parts of the program that were intended to remain unchanged. Using the standard denotational semantics for procedural programming languages, this paper formalizes decomposition slicing, which identifies interferences between software components and isolates the components to be changed. We enumerate the conditions for changing one component in ways that will guarantee that changes to it will not interact inconsistently and prove that changes made under these conditions are sound. Thus, the programmer can then execute changes secure in the knowledge that the semantics of the new system are guaranteed to be consistent with the projection of the semantics of the original for which it behaved correctly. Validating that the changes do not interfere not only guarantees consistency with respect to previous unchanging behaviors, but can also be achieved with a complexity proportional to the size of the change to be made. Copyright © 2003 John Wiley & Sons, Ltd.

Visual impact analysis is a software visualisation technique that lets software maintainers judge the impact of proposed changes and plan maintenance accordingly. An existing CASE tool uses a directed acyclic graph display derived from decomposition slicing of a program for visual impact analysis. In this paper, we analyse the graph display and show that it is semantically ambiguous and fails to show important information. We propose requirements for an improved display based on a definition of "interference" between variables in a maintenance context. The design for a new display is presented with a series of examples to illustrate its effectiveness. The display is focused on providing a straightforward method to analyse the impact of changes.

The Surgeon's Assistant is a CASE tool for software maintainers and developers of ANSI C programs. It is based on the premises that maintainers need to be able to limit the scope of changes and that (most) development starts from some existing, similar system. The Decomposition Slice Display System (DSDS-XVCG), a component of the Surgeon's Assistant, automates and visualizes impact analysis by displaying the relationships among a program's decomposition slices. It allows the software maintainer to visually comprehend the relationships between the decomposition slices. The DSDS-XVCG uses the interface of a tool for Visualizing Compiler Graphs, VCG, to present the lattice of the decomposition slices for the user's perusal. It allows the user to manipulate the graph by deleting and coloring nodes, and by collapsing regions. The software maintainer is provided with a visualization of the impact of proposed changes and can plan maintenance accordingly.

The author reports on an empirical evaluation of decomposition slicing as a maintenance method as implemented in the Surgeon's Assistant. The improvement-oriented software maintenance model presented by H. D. Rombach and B.T. Ulery (1988) is used as the foundation. A reprise of software process modeling, a short introduction to software maintenance process modeling, and the definition of the evaluation model are presented. Decomposition slicing induces changes in the standard maintenance model; the evaluation attempts to measure the effectiveness of the induced model as compared with the standard one. The evaluation is a pilot study. A preliminary comparison is made using certain defined metrics. This yields some insights into the strengths and weaknesses of the tool and its applicability in certain scenarios.>

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

The authors use data-flow techniques to form a notion of direct sum decomposition for programs. The decomposition yields a method and guidelines for software maintainers to use so that changes can be assured to be completely contained in the modules under consideration and that there are no undetected linkages between the modified and unmodified code. Thus, the impact of small changes can be gauged. The decomposition can also be used to limit the amount of testing required to assure that the change is correct; under suitable conditions, modification testing will be required only for the changed code. Moreover, if these hypotheses are violated, the modifier can be virtually assured that proposed changes will have a wider impact than that which is contemplated.>