1,284 research outputs found
On Verifying Resource Contracts using Code Contracts
In this paper we present an approach to check resource consumption contracts
using an off-the-shelf static analyzer.
We propose a set of annotations to support resource usage specifications, in
particular, dynamic memory consumption constraints. Since dynamic memory may be
recycled by a memory manager, the consumption of this resource is not monotone.
The specification language can express both memory consumption and lifetime
properties in a modular fashion.
We develop a proof-of-concept implementation by extending Code Contracts'
specification language. To verify the correctness of these annotations we rely
on the Code Contracts static verifier and a points-to analysis. We also briefly
discuss possible extensions of our approach to deal with non-linear
expressions.Comment: In Proceedings LAFM 2013, arXiv:1401.056
Automatic Test Generation for Space
The European Space Agency (ESA) uses an engine to perform tests in the Ground
Segment infrastructure, specially the Operational Simulator. This engine uses
many different tools to ensure the development of regression testing
infrastructure and these tests perform black-box testing to the C++ simulator
implementation. VST (VisionSpace Technologies) is one of the companies that
provides these services to ESA and they need a tool to infer automatically
tests from the existing C++ code, instead of writing manually scripts to
perform tests. With this motivation in mind, this paper explores automatic
testing approaches and tools in order to propose a system that satisfies VST
needs
A heuristic-based approach to code-smell detection
Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache
Formal Reasoning Using an Iterative Approach with an Integrated Web IDE
This paper summarizes our experience in communicating the elements of
reasoning about correctness, and the central role of formal specifications in
reasoning about modular, component-based software using a language and an
integrated Web IDE designed for the purpose. Our experience in using such an
IDE, supported by a 'push-button' verifying compiler in a classroom setting,
reveals the highly iterative process learners use to arrive at suitably
specified, automatically provable code. We explain how the IDE facilitates
reasoning at each step of this process by providing human readable verification
conditions (VCs) and feedback from an integrated prover that clearly indicates
unprovable VCs to help identify obstacles to completing proofs. The paper
discusses the IDE's usage in verified software development using several
examples drawn from actual classroom lectures and student assignments to
illustrate principles of design-by-contract and the iterative process of
creating and subsequently refining assertions, such as loop invariants in
object-based code.Comment: In Proceedings F-IDE 2015, arXiv:1508.0338
The Oracle Problem in Software Testing: A Survey
Testing involves examining the behaviour of a system in order to discover potential faults. Given an input for a system, the challenge of distinguishing the corresponding desired, correct behaviour from potentially incorrect behavior is called the “test oracle problem”. Test oracle automation is important to remove a current bottleneck that inhibits greater overall test automation. Without test oracle automation, the human has to determine whether observed behaviour is correct. The literature on test oracles has introduced techniques for oracle automation, including modelling, specifications, contract-driven development and metamorphic testing. When none of these is completely adequate, the final source of test oracle information remains the human, who may be aware of informal specifications, expectations, norms and domain specific information that provide informal oracle guidance. All forms of test oracles, even the humble human, involve challenges of reducing cost and increasing benefit. This paper provides a comprehensive survey of current approaches to the test oracle problem and an analysis of trends in this important area of software testing research and practice
ArĂs 2.1: Adapting ArĂs for Object Oriented Language
In the software development area, software verification is important such that it can guarantee the software
fulfills its requirements. Despite its importance, verifying software is difficult to achieve. Additional
knowledge and effort are needed to write specification especially if the software is complex and big in
size. Nevertheless, there are some software that already have verified specifications. This project will
focus on extending ArĂs (Analogical Reasoning for reuse of Implementation & Specification) which has
been developed to increase verified software by reusing and transferring the specification from a similar
implementation to a target code. The extension is done to facilitate specification transferring to program
written in language other than C#, in this case Java. This extension will add functions to existing ArĂs
that will receive Conceptual Graphs representation of a program and write the specification to a file.
Another companion system is also built from Java to generate the Conceptual Graphs in Conceptual
Graph Interchange Format (CGIF) and transform the Spec# specification to JML. Finally, this new
system is evaluated by running some testing. From the result that we have, we can conclude that the
building of conceptual graph and the specification transformation is the most difficult part in our system
ArĂs 2.1: Adapting ArĂs for Object Oriented Language
In the software development area, software verification is important such that it can guarantee the software
fulfills its requirements. Despite its importance, verifying software is difficult to achieve. Additional
knowledge and effort are needed to write specification especially if the software is complex and big in
size. Nevertheless, there are some software that already have verified specifications. This project will
focus on extending ArĂs (Analogical Reasoning for reuse of Implementation & Specification) which has
been developed to increase verified software by reusing and transferring the specification from a similar
implementation to a target code. The extension is done to facilitate specification transferring to program
written in language other than C#, in this case Java. This extension will add functions to existing ArĂs
that will receive Conceptual Graphs representation of a program and write the specification to a file.
Another companion system is also built from Java to generate the Conceptual Graphs in Conceptual
Graph Interchange Format (CGIF) and transform the Spec# specification to JML. Finally, this new
system is evaluated by running some testing. From the result that we have, we can conclude that the
building of conceptual graph and the specification transformation is the most difficult part in our system
Contracts in Practice
Contracts are a form of lightweight formal specification embedded in the
program text. Being executable parts of the code, they encourage programmers to
devote proper attention to specifications, and help maintain consistency
between specification and implementation as the program evolves. The present
study investigates how contracts are used in the practice of software
development. Based on an extensive empirical analysis of 21 contract-equipped
Eiffel, C#, and Java projects totaling more than 260 million lines of code over
7700 revisions, it explores, among other questions: 1) which kinds of contract
elements (preconditions, postconditions, class invariants) are used more often;
2) how contracts evolve over time; 3) the relationship between implementation
changes and contract changes; and 4) the role of inheritance in the process. It
has found, among other results, that: the percentage of program elements that
include contracts is above 33% for most projects and tends to be stable over
time; there is no strong preference for a certain type of contract element;
contracts are quite stable compared to implementations; and inheritance does
not significantly affect qualitative trends of contract usage
Perfect is the enemy of test oracle
Automation of test oracles is one of the most challenging facets of software
testing, but remains comparatively less addressed compared to automated test
input generation. Test oracles rely on a ground-truth that can distinguish
between the correct and buggy behavior to determine whether a test fails
(detects a bug) or passes. What makes the oracle problem challenging and
undecidable is the assumption that the ground-truth should know the exact
expected, correct, or buggy behavior. However, we argue that one can still
build an accurate oracle without knowing the exact correct or buggy behavior,
but how these two might differ. This paper presents SEER, a learning-based
approach that in the absence of test assertions or other types of oracle, can
determine whether a unit test passes or fails on a given method under test
(MUT). To build the ground-truth, SEER jointly embeds unit tests and the
implementation of MUTs into a unified vector space, in such a way that the
neural representation of tests are similar to that of MUTs they pass on them,
but dissimilar to MUTs they fail on them. The classifier built on top of this
vector representation serves as the oracle to generate "fail" labels, when test
inputs detect a bug in MUT or "pass" labels, otherwise. Our extensive
experiments on applying SEER to more than 5K unit tests from a diverse set of
open-source Java projects show that the produced oracle is (1) effective in
predicting the fail or pass labels, achieving an overall accuracy, precision,
recall, and F1 measure of 93%, 86%, 94%, and 90%, (2) generalizable, predicting
the labels for the unit test of projects that were not in training or
validation set with negligible performance drop, and (3) efficient, detecting
the existence of bugs in only 6.5 milliseconds on average.Comment: Published in ESEC/FSE 202
- …