Table of Contents

This page lists the tools I developed and maintain.


Automata Violations Analyzer, AVA, is a technique to automatically produce candidate interpretations of software failures from anomalies identified by anomaly detection techniques. Interpretations capture the rationale of the differences between legal and failing executions with user understandable patterns that simplify identification of failure causes. Empirical validation conducted both with synthetic cases and third-party systems showed that AVA produces useful interpretations.

Click here for more information about AVA


BCT is a dynamic program analysis tool that can be used to debug software or to compare different program executions. BCT automatically identifies anomalous events that likely caused failures, filters the possible false positives, and presents the resulting data by building views that show chains of cause-effect relations, i.e., views that show when anomalous events are caused by other anomalous events. BCT comes with a library that provides its core functionality and an Eclipse plugin that provides management and visualization facilities.

Click here for more information about BCT


KLFA is a tool that automatically analyzes log files and retrieves important information to identify failure causes. KLFA automatically identifies dependencies between events and values in logs corresponding to legal executions, generates models of legal behaviors and compares log files collected during failing executions with the generated models to detect anomalous event sequences that are presented to users.

Click here for more information about KLFA


The majority of IDEs implement a concept of plug-in that nicely supports the integration of tools within the IDEs. Plug-ins dramatically simplify the structural integration of multiple tools, but provide little support to the design of the dynamic of the integration, which must be entirely coded by programmers from plug-ins’ API. Manually integrating plug-ins is costly, complex and requires a deep understanding of the underlying environment. The implementation of tools as plug-ins and the integration of the results produced by different plug-ins are still difficult, expensive and error-prone activities. In our vision, IDE users must be able to execute plug-ins and integrate their results by designing workflows that can be persisted, executed and re-used in other workflows. MASH is an Eclipse plug-in that enable users to compose the functionality provided by different plug-ins at runtime, by drawing a workflow in their workspace.

Click here for more information about MASH


RADAR (Regression Analysis with Diff And Recording) is a technique for debugging regression faults. RADAR combines monitoring, model inference and anomaly detection into a solution for the automatic identification of the anomalous behaviors that caused a regression failure. RADAR is implemented as an Eclipse plug-in and allows developers to analyze failures directly in the Eclipse IDE. In particular, RADAR can visualize the chain of anomalous behaviors that caused a failure, and provide developers a rich set of dynamic data that can be used to understand the context of the failure.

Future versions of RADAR will leverage Grammatech CodeSurfer static analysis capabilities to precisely pinpoint the code changes that lead to the regression.

Click here for more information about RADAR


Verification-Aided Regression Testing (VART) is a novel extension of regression testing that has a fault revealing capability that is significantly less sensitive to the completeness of the validation test suite due to the use of model checking.

The key idea in VART is to extend the use of test case executions from the conventional direct fault discovery to the generation of behavioral properties specific to the upgrade, by: (1) automatically producing properties that are proved to hold for the base version of a program; (2) automatically identifying and checking on the upgraded program only the properties that, according to the developers’ intention, must be preserved by the upgrade; (3) reporting the faults and the corresponding counter-examples that are not revealed by the regression tests.

Click here for more information about VART