4,888 research outputs found
Symbolic Quantitative Information Flow
acmid: 2382791 issue_date: November 2012 keywords: algorithms, security, verification numpages: 5acmid: 2382791 issue_date: November 2012 keywords: algorithms, security, verification numpages: 5acmid: 2382791 issue_date: November 2012 keywords: algorithms, security, verification numpages: 5acmid: 2382791 issue_date: November 2012 keywords: algorithms, security, verification numpages: 5acmid: 2382791 issue_date: November 2012 keywords: algorithms, security, verification numpages:
Inferring Concise Specifications of APIs
Modern software relies on libraries and uses them via application programming
interfaces (APIs). Correct API usage as well as many software engineering tasks
are enabled when APIs have formal specifications. In this work, we analyze the
implementation of each method in an API to infer a formal postcondition.
Conventional wisdom is that, if one has preconditions, then one can use the
strongest postcondition predicate transformer (SP) to infer postconditions.
However, SP yields postconditions that are exponentially large, which makes
them difficult to use, either by humans or by tools. Our key idea is an
algorithm that converts such exponentially large specifications into a form
that is more concise and thus more usable. This is done by leveraging the
structure of the specifications that result from the use of SP. We applied our
technique to infer postconditions for over 2,300 methods in seven popular Java
libraries. Our technique was able to infer specifications for 75.7% of these
methods, each of which was verified using an Extended Static Checker. We also
found that 84.6% of resulting specifications were less than 1/4 page (20 lines)
in length. Our technique was able to reduce the length of SMT proofs needed for
verifying implementations by 76.7% and reduced prover execution time by 26.7%
Automatically Discovering, Reporting and Reproducing Android Application Crashes
Mobile developers face unique challenges when detecting and reporting crashes
in apps due to their prevailing GUI event-driven nature and additional sources
of inputs (e.g., sensor readings). To support developers in these tasks, we
introduce a novel, automated approach called CRASHSCOPE. This tool explores a
given Android app using systematic input generation, according to several
strategies informed by static and dynamic analyses, with the intrinsic goal of
triggering crashes. When a crash is detected, CRASHSCOPE generates an augmented
crash report containing screenshots, detailed crash reproduction steps, the
captured exception stack trace, and a fully replayable script that
automatically reproduces the crash on a target device(s). We evaluated
CRASHSCOPE's effectiveness in discovering crashes as compared to five
state-of-the-art Android input generation tools on 61 applications. The results
demonstrate that CRASHSCOPE performs about as well as current tools for
detecting crashes and provides more detailed fault information. Additionally,
in a study analyzing eight real-world Android app crashes, we found that
CRASHSCOPE's reports are easily readable and allow for reliable reproduction of
crashes by presenting more explicit information than human written reports.Comment: 12 pages, in Proceedings of 9th IEEE International Conference on
Software Testing, Verification and Validation (ICST'16), Chicago, IL, April
10-15, 2016, pp. 33-4
Issues of Architectural Description Languages for Handling Dynamic Reconfiguration
Dynamic reconfiguration is the action of modifying a software system at
runtime. Several works have been using architectural specification as the basis
for dynamic reconfiguration. Indeed ADLs (architecture description languages)
let architects describe the elements that could be reconfigured as well as the
set of constraints to which the system must conform during reconfiguration. In
this work, we investigate the ADL literature in order to illustrate how
reconfiguration is supported in four well-known ADLs: pi-ADL, ACME, C2SADL and
Dynamic Wright. From this review, we conclude that none of these ADLs: (i)
addresses the issue of consistently reconfiguring both instances and types;
(ii) takes into account the behaviour of architectural elements during
reconfiguration; and (iii) provides support for assessing reconfiguration,
e.g., verifying the transition against properties.Comment: 6\`eme Conf\'erence francophone sur les architectures logicielles
(CAL'2012), Montpellier : France (2012
A Historical Perspective on Runtime Assertion Checking in Software Development
This report presents initial results in the area of software testing and analysis produced as part of the Software Engineering Impact Project. The report describes the historical development of runtime assertion checking, including a description of the origins of and significant features associated with assertion checking mechanisms, and initial findings about current industrial use. A future report will provide a more comprehensive assessment of development practice, for which we invite readers of this report to contribute information
- …