Abstract 1
The Structural Complexity of Software: An Experimental Test
David P. Darcy, Chris F. Kemerer, Sandra A. Slaughter, James E. Tomayko
1This
Purpose
Approach
Results
Conclusions
research examines the structural complexity of software and,
specifically, the potential interaction of the two dominant dimensions of
structural complexity, coupling and cohesion.
2Analysis based on an information processing view of developer cognition
results in a theoretically driven model with cohesion as a moderator for a main
effect of coupling on effort. 3An empirical test of the model was devised in a
software maintenance context utilizing both procedural and object-oriented
tasks, with professional software engineers as participants.
4aThe results support the model 4bin that there was a significant interaction
effect between coupling and cohesion on effort, 4ceven though there was no
main effect for either coupling or cohesion.
5aThe implication of this result is that, 5bwhen designing, implementing, and
maintaining software to control complexity, 5aboth coupling and cohesion
should be considered jointly, instead of independently. 6aBy providing
guidance on structuring software for software professionals and researchers,
6bthese results enable software to continue as the solution of choice for a wider
range of richer, more complex problems.
Abstract 2
Design and Implementation of a Fine-Grained Software Inspection Tool
Paul Anderson, T. Reps, and T. Teitelbaum
Background
(Problem)
Purpose
Approach
Results
Conclusions
1aAlthough
software inspection has led to improvements in software
quality,
1bmany software systems continue to be deployed with unacceptable
numbers of errors, 1ceven when software inspection is part of the
development process. 2The difficulty of manually verifying that the
software under inspection conforms to the rules is partly to blame.
3We describe the design and implementation of a tool designed to help
alleviate this problem.
4aThe tool provides mechanisms for fine-grained inspection of
software 4bby exposing the results of sophisticated whole-program
static analysis to the inspector. 5The tool computes many staticsemantic representations of the program, including an accurate call
graph and dependence graph. 6aWhole-program pointer analysis is
used 6bto make sure 6cthat the representation is precise with respect to
aliases induced by pointer usage. 7Views on the dependence graph and
related representations are supported. 8aQueries on the dependence
graph allow 8ban inspector to answer detailed questions about the
semantics of the program. 9aFacilities for openness and extensibility
permit 9bthe tool to be integrated with many software-development
processes.
10The
main challenge of the approach is to provide facilities to
navigate and manage the enormous complexity of the dependence
graph.
1
Abstract 3
Software assurance by bounded exhaustive testing
David Coppit, Jinlin Yang, S. Khurshid, Wei Le, and K. Sullivan
Background
(Problem)
Purpose
Approach 1
Results 1
Approach 2
Results 2
Conclusions
1Bounded
exhaustive testing (BET) is a verification technique in which
software is automatically tested for all valid inputs up to specified size
bounds. 2A particularly interesting case of BET arises in the context of
systems that take structurally complex inputs. 3aEarly research suggests
3bthat the BET approach can reveal faults in small systems with inputs of
low structural complexity,
3cbut its potential utility for larger systems with more complex input
structures remains unclear.
4We set out to test its utility on one such system.
5aWe used Alloy and TestEra 5bto generate inputs to test the Galileo dynamic
fault tree analysis tool, for which we already had both a formal specification
of the input space and a test oracle.
6An initial attempt to generate inputs using a straightforward translation of
our specification to Alloy did not work well. 7The generator failed to
generate inputs to meaningful bounds.
8We developed an approach in which we factored the specification, used
TestEra to generate abstract inputs based on one factor, and passed the
results through a postprocessor that reincorporated information from the
second factor.
9aUsing this technique, 9bwe were able to generate test inputs to meaningful
bounds, 9cand the inputs revealed nontrivial faults in the Galileo
implementation, our specification, and our oracle.
10aOur results suggest 10bthat BET, combined with specification abstraction
and factoring techniques, could become a valuable addition to our
verification toolkit 10cand that further investigation is warranted.
2