Regina Lúcia de Oliveira Moraes

Injection of faults at component interfaces and inside the component code: are they equivalent?

The injection of interface faults through API parameter corruption is a technique commonly used in experimental dependability evaluation. Although the interface faults injected by this approach can be considered as a possible consequence of actual software faults in real applications, the question of whether the typical exceptional inputs and invalid parameters used in these techniques do represent the consequences of software bugs is largely an open issue. This question may not be an issue in the context of robustness testing aimed at the identification of weaknesses in software components. However, the use of interface faults by API parameter corruption as a general approach for dependability evaluation in component-based systems requires an in depth study of interface faults and a close observation of the way internal component faults propagate to the component interfaces. In this paper we present the results of experimental evaluation of realistic component-based applications developed in Java and C using the injection of interface faults by API parameter corruption and the injection of software faults inside the components by modification of the target code. The faults injected inside software components emulate typical programming errors and are based on an extensive field data study previously published. The results show the consequences of internal component faults in several operational scenarios and provide empirical evidences that interface faults and software component faults cause different impact in the system

Experimental Risk Assessment and Comparison Using Software Fault Injection

One important question in component-based software development is how to estimate the risk of using COTS components, as the components may have hidden faults and no source code available. This question is particularly relevant in scenarios where it is necessary to choose the most reliable COTS when several alternative components of equivalent functionality are available. This paper proposes a practical approach to assess the risk of using a given software component (COTS or non-COTS). Although we focus on comparing components, the methodology can be useful to assess the risk in individual modules. The proposed approach uses the injection of realistic software faults to assess the impact of possible component failures and uses software complexity metrics to estimate the probability of residual defects in software components. The proposed approach is demonstrated and evaluated in a comparison scenario using two real off-the-shelf components (the RTEMS and the RTLinux real-time operating system) in a realistic application of a satellite data handling application used by the European Space Agency.

Fault injection approach based on dependence analysis

Fault injection is used to validate a system in the presence of faults. Jaca, a software injection tool developed in previous work, is used to inject faults at interfaces between classes of a system written in Java. We present a strategy for fault injection validation based on dependence analysis. The dependence analysis approach is used to help in reducing the number of experiments necessary to cover the systems interfaces. For the experiments we used a system that consists of two integrated components, an ODBMS performance test benchmark, Wisconsin 007 and an ODBMS, Ozone. The results of some experiments and their analysis are presented.

Requirements, design and evaluation of a privacy reference architecture for web applications and services

Organizational Information Systems (IS) collect, store, and manage personal and business information through web applications and services. Due to regulation laws and to protect the privacy of users, clients, and business partners, such information must be kept private. This paper proposes a privacy reference architecture that can serve as foundation for the analysis, design and development of web applications with privacy concerns. Using the proposed reference architecture, these applications can manage personal information in a more secure manner, protecting such information from different sources of privacy violation. Also, it can be used as a standardization model that facilitates system integration and communication. The architecture was evaluated regarding four key quality attributes: completeness, applicability, usability and feasibility. Results show that it brings values for the stakeholders and is an important tool in the analysis and implementation of applications with privacy protection.

Collecting, Analyzing and Archiving Results from Fault Injection Experiments

This paper addresses the issue of the identification of the suitable level of observation (readouts and measurements) to characterize fault injection experiments. In practice, several outcomes can be observed in an experiment, but it is not rare for experimenters to consider only one viewpoint or to rely on the first event observed, in order to diagnose the experiment. In addition, there is not always a single way to assert the faulty behaviors as distinct viewpoints might be considered. Accordingly, an elaborate reflection on the types of readouts and measurements to be collected and recorded is an essential dimension for analyzing the faulty behavior of a target system. Another key aspect concerns the need for archiving the experimental data in a suitable way (featuring sufficient details, still in an exploitable format), so that they can be also useful for extended or alternative analyses. With that in mind, the paper sketches some simple guidelines towards the sharing of experimental results via an open data repository.

A Strategy for Validating an ODBMS Component Using a High-Level Software Fault Injection Tool

We present a strategy for the validation of an Object Oriented Database Management System (ODBMS), an off-the-shelf component software, when we deliberately introduced faults and observe its behavior in the presence of these faults. A tool designed for the injection of faults in OO applications, specially Java language systems, was used. This Software Fault Injection tool, Jaca, was developed at UNICAMP and has the ability to inject faults in objects’ attributes and methods. For the experiments we used an ODBMS performance test benchmark, Wisconsin OO7. The experiments were aimed at validating the robustness of the ODBMS component in the presence of errors originated at the application. For that purpose a fault injection strategy was proposed to help answer the questions: Where to inject? What error model to use? This strategy was applied, so some results and their analysis are presented. Improvement for Jaca were addressed as a experiments’ result.

Development of a serious game for children with hemophilia

This work describes the development process of the interface of an educational game that is aimed at children with hemophilia. The development and evaluation process used the dynamic Braindraw, Participatory Heuristic Evaluation and Beta Test and involved the end users of the game: children with hemophilia. The hypothesis is that children learn more about the disease through the game, which motivates them in an interactive practice. The experiments performed confirmed that the children with hemophilia learned more about the disease with the game.

Component-based software certification based on experimental risk assessment

Third-party software certification should attest that the software product satisfies the required confidence level according to certification standards such as ISO/IEC 9126, ISO/IEC 14598 or ISO/IEC 25051. In many application areas, especially in mission-critical applications, certification is essential or even mandatory. However, the certification of software products using common off-the-shelf (COTS) components is difficult to attain, as detailed information about COTS is seldom available. Nevertheless, software products are increasingly being based on COTS components, which mean that traditional certification processes should be enhanced to take COTS into account in an effective way. This paper proposes a mean to help in the certification of component-based systems through an experimental risk assessment methodology based on fault injection and statistical analysis. Using the proposed methodology the certification authority or the system integrator can compare among components available the one that best fit for the system that is assembling a component that provides a specific functionality. Based on the results it is also possible to decide whether a software product may be considered certified or not in what concerns the risk of using a COTS into the system. The proposed approach is demonstrated and evaluated using a space application running on top of two alternative COTS real-time operating systems: RTEMS and RTLinux.

Challenges on Anonymity, Privacy, and Big Data

This paper provides an overview of the tools and methodologies for data privacy protection that can cope with the challenges raised by the Big Data storage and analytics processing, with focus on anonymity. Preserving individual privacy is one of the major issues in the context of Big Data, as while handling huge volumes of data, it is possible that sensitive or personally identifiable information ends up disclosed. In fact, even when dealing with anonymized raw data, sensitive information may be extracted through analytics. Preserving anonymity is particularly difficult because it should be done while allowing the analytics to produce useful insight about the data. We further discuss these challenges and future research directions in order to perform big data analytics in a privacy-compliant way.

Fault injection approach based on architectural dependencies

In a previous paper we described a fault injection strategy that applies risk-based analysis to select the system’s riskiest components for testing. Among other criteria, this analysis considers the number of upstream and downstream dependencies of a component in a system. In order to obtain this number, we propose the use of architectural-level dependency analysis. One advantage of an analysis at architectural level is that systems may often contain COTS components from which no source code is available. The approach is illustrated with a case study, and the preliminary experimental results are also discussed.