Fadi Wedyan

The Effectiveness of Automated Static Analysis Tools for Fault Detection and Refactoring Prediction

Many automated static analysis (ASA) tools have been developed in recent years for detecting software anomalies. The aim of these tools is to help developers to eliminate software defects at early stages and produce more reliable software at a lower cost. Determining the effectiveness of ASA tools requires empirical evaluation. This study evaluates coding concerns reported by three ASA tools on two open source software (OSS) projects with respect to two types of modifications performed in the studied software CVS repositories: corrections of faults that caused failures, and refactoring modifications. The results show that fewer than 3% of the detected faults correspond to the coding concerns reported by the ASA tools. ASA tools were more effective in identifying refactoring modifications and corresponded to about 71% of them. More than 96% of the coding concerns were false positives that do not relate to any fault or refactoring modification.

Cell Phone-Based System (Chaak) for Surveillance of Immatures of Dengue Virus Mosquito Vectors

ABSTRACT Capture of surveillance data on mobile devices and rapid transfer of such data from these devices into an electronic database or data management and decision support systems promote timely data analyses and public health response during disease outbreaks. Mobile data capture is used increasingly for malaria surveillance and holds great promise for surveillance of other neglected tropical diseases. We focused on mosquito-borne dengue, with the primary aims of: 1) developing and field-testing a cell phone-based system (called Chaak) for capture of data relating to the surveillance of the mosquito immature stages, and 2) assessing, in the dengue endemic setting of Mérida, México, the cost-effectiveness of this new technology versus paper-based data collection. Chaak includes a desktop component, where a manager selects premises to be surveyed for mosquito immatures, and a cell phone component, where the surveyor receives the assigned tasks and captures the data. Data collected on the cell phone can be transferred to a central database through different modes of transmission, including near-real time where data are transferred immediately (e.g., over the Internet) or by first storing data on the cell phone for future transmission. Spatial data are handled in a novel, semantically driven, geographic information system. Compared with a pen-and-paper-based method, use of Chaak improved the accuracy and increased the speed of data transcription into an electronic database. The cost-effectiveness of using the Chaak system will depend largely on the up-front cost of purchasing cell phones and the recurring cost of data transfer over a cellular network.

On generating mutants for AspectJ programs

Context: Mutation analysis has been widely used in research studies to evaluate the effectiveness of test suites and testing techniques. Faulty versions (i.e., mutants) of a program are generated such that each mutant contains one seeded fault. The mutation score provides a measure of effectiveness. Objective: We study three problems with the use of mutation analysis for testing AspectJ programs:*The manual identification and removal of equivalent mutants is difficult and time consuming. We calculate the percentage of equivalent mutants generated for benchmark AspectJ programs using available mutation tools. *The generated mutants need to cover the various fault types described in the literature on fault models for AspectJ programs. We measure the distribution of the mutants generated using available mutation tools with respect to the AspectJ fault types. *We measure the difficulty of killing the generated mutants. We propose the use of simple analysis of the subject programs to prevent the generation of some equivalent mutants. Method: We revised existing AspectJ fault models and presented a fault model that removes the problems in existing fault models, such as overlapping between fault types and missing fault types. We also defined three new fault types that occur due to incorrect data-flow interactions occurring in AspectJ programs. We used three mutation tools: AjMutator, Proteum/AJ, and MuJava on three AspectJ programs. To measure the difficulty of killing the mutants created using a mutation operator, we compared the average number of the mutants killed by 10 test suites that satisfy block coverage criterion. Results: A high percentage of the mutants are equivalent. The mutation tools do not cover all the fault types. Only 4 out of 27 operators generated mutants that were easy to kill. Conclusions: Our analysis approach removed about 80% of the equivalent mutants. Higher order mutation is needed to cover all the fault types.

A Dataflow Testing Approach for Aspect-Oriented Programs

Dataflow testing of programs ensures the execution of data dependencies between locations in the code (1) where variables are assigned values, and (2) where these definitions are used. Such data dependencies are called Def-Use Associations (DUAs). In an aspect-oriented (AO) program, aspects and classes interact in several ways, such as (1) through parameters passed from advised methods in a class to advices in the aspect, or (2) by the reading or writing of class state variables in an advice. In this paper, we present a dataflow testing approach for AO programs that is based on class state variables. We identify various types of DUAs for such variables and propose a set of dataflow test criteria that require executing these DUAs. Our approach is implemented by a tool called DCT-AJ, which identifies the DUAs in an AspectJ program and computes the coverage obtained from a test suite. Preliminary results indicate that the test suites satisfying the proposed dataflow criteria are more effective in detecting faults than the test suites that satisfy block coverage criteria.

An approach and tool for measurement of state variable based data-flow test coverage for aspect-oriented programs

ContextData-flow testing approaches have been used for procedural and object-oriented programs, and shown to be effective in detecting faults. However, few such approaches have been evaluated for aspect-oriented programs. In such programs, data-flow interactions can occur between base classes and aspects, which can affect the behavior of both. Faults resulting from such interactions are hard to detect unless the interactions are specifically targeted during testing. ObjectiveThis paper presents an approach and tool implementation for measuring data-flow coverage based on state variables defined in base classes or aspects in AspectJ programs. The paper also reports on an empirical study that compares the cost and effectiveness of data-flow test criteria that are based on state variables with two control-flow criteria. MethodEffectiveness of the criteria was evaluated for various fault types. Cost-effectiveness of test suites that cover all state variable definition-use associations (DUAs) was evaluated for three coverage levels: 100%, 90%, and 80%. ResultsThe effort needed to obtain a test case that achieves data-flow coverage is higher than the effort needed to obtain a test case that covers a block or a branch in an advised class. Covering certain data flow associations requires more effort than for other types of data flow associations. The data-flow test criteria based on state variables of a base-class are in general more effective than control-flow criteria. ConclusionsOverall, it is cost-effective to obtain test suites at the 90% coverage level of data-flow criteria.

A Joinpoint Coverage Measurement Tool for Evaluating the Effectiveness of Test Inputs for AspectJ Programs

Testing aspect-oriented programs is challenging in part because of the interactions between the aspects and the base classes with which the aspects are woven. Coverage metrics, such as joinpoint coverage, address faults resulting from the changes in base class control flow that may be introduced by the woven advices. Definitions of joinpoint coverage in the literature typically require counting the execution of aspects at each joinpoint. We present a tool for measuring joinpoint coverage from two perspectives: per advice, which measures the execution of the advice at each joinpoint it is woven into, and per class, which measures the execution of all the advices in each joinpoint in the class. This gives a more detailed measurement of joinpoint coverage and helps in identifying what more needs to be tested in both the base class and the aspect. The tool is based on AspectJ and Java bytecode, and thus, does not require any source code. We demonstrate the use of our tool to measure the joinpoint coverage of test inputs generated by Xie and Zhaos Aspectra framework.

CodeRoid: a Framework for Generating Java Sourcecode Using Tablets and Smartphones

Smartphones and tablets are gaining more popularity due to their increasing capabilities and affordable prices. While most of the applications built for these devices are business, social, or entertainment oriented, few applications provide tools for developers. This is because of the limited screen size and the virtual keyboards that do not provide a comfortable programming environment. In this paper, we propose a framework, called CodeRoid, for developing Java programs that can be used on tablets and smartphones. Using CodeRoid, developers visually interact with the device to specify the specifications of the required code and CodeRoid automatically generates the required Java source files. CodeDroid provides the building programming blocks which the developer can choose and customize. CodeRoid checks the syntax of the produced Java files. In order to minimize the memory and computational requirements. Java source files can be sent to a server to produce the bytecode. Therefore, a complier and a JVM are not required. CodeRoid is developed with Android and set to run on smartphones and tablets with different screen sizes, computational and memory capabilities. The current version of the framework generates Java sourcecode, however, it can be extended to support other object-oriented programming languages (e.g., C++).