Software Product Lines (SPLs) are techniques where several artefacts are reused (domain), and some are customised (variation points). An SPL can bind variation points statically (compilation time) or dynamically (runtime). Dynamic Software Product Lines (DSPLs) use dynamic binding to adapt to the environment or requirements changes. DSPLs are commonly used to build dependable systems, defined as systems with the ability to avoid more frequent or severe service failures than the acceptable. The main dependability attributes are availability, confidentiality, integrity, reliability, maintainability, and safety. To better understand this context, a Systematic Mapping Study (SMS) was applied searching proposals that include dependability attributes in DSPLs. Our results suggest that few solutions handle dependability in DSPL context. We selected nine primary studies in this regard. We performed a comparative study of the results, analysing other dimensions, and facets, aiming for a better understanding of this research area.

Context: Over recent years, software developers have been evaluating the benefits of both Service-Oriented Architecture and software fault tolerance techniques based on design diversity by creating fault-tolerant composite services that leverage functionally equivalent services, or variant services. Three major design issues need to be considered while building software fault-tolerant architectures based on design diversity namely, selection and execution of variants and selection of an adjudication algorithm to determine the correct or adjudicated result from the variants. Each design issue, in turn, can be realized by a set of alternative design solutions, which present different degrees of quality requirements (e.g. memory consumption and reliability). Objective: To investigate whether existing approaches for fault-tolerant composite services support the above mentioned design issues and to provide a detailed classification of the analysed approaches. Method: A systematic literature review of diversity-based approaches for fault-tolerant composite services, which compose our primary studies. Results: We found 17 primary studies providing direct evidence about the research question. Our findings reveal that the primary studies support a wide variety of design decisions. For example, (i) variant services may be chosen at different points during the software lifecycle; (ii) both parallel and sequential execution schemes have been addressed; and (iii) a variety of adjudication mechanisms were found amongst the target papers. Conclusion: We build up a broad picture of what design issues have been addressed by existing diversity-based approaches for fault-tolerant composite services. Finally, practical issues and difficulties are summarized and directions for future work are suggested.

A number of approaches based on design diversity moderate the communication between clients and functionally equivalent services, i.e., variant services, to tolerate software faults in service-oriented applications. Nevertheless, it is unclear whether variant services are actually diverse and fail on disjoint subsets of the input space. In a previous work, we proposed an experimental setup to assess design diversity of variant services that realize a requirements specification. In this work, we utilize the proposed experimental setup to assess the design diversity of a number of third-party Web services adhering to seven different requirements specifications. In this paper, we describe in detail the main findings and lessons learnt from this empirical study. Firstly, we investigate whether variant services are in fact diverse. Secondly, we investigate the effectiveness of service diversity for tolerating faults. The results suggest that there is diversity in the implementation of variant services. However, in some cases, this diversity might not be sufficient to improve system reliability. Our findings provide an important knowledge basis for engineering effective fault-tolerant service applications.

Background: A number of approaches leverage design diversity to tolerate software design faults in service-oriented applications. The use of design diversity depends on the assumption that functionally equivalent services, i.e., variant services, rarely fail on the same input case. However, there are no directives to assess whether variant services are actually diverse and fail on disjoint subsets of the input space. Aim: To provide proper assessment of service diversity in order to achieve a high level of reliability by employing either a diversity-based solution with the variant services or a single service that exhibits higher reliability than would be the case if design diversity was adopted. Method: We propose an experimental setup that encompasses (i) a set of directives to organize the preparation and execution of the experiment to investigate service diversity; (ii) investigation of whether variant services are actually diverse by using statistical tests; and (iii) an analysis of if and by how much the reliability of a diversity-based solution that leverages voters is an improvement over one that uses a single service. We evaluated the applicability and usefulness of the proposed experimental setup by employing it to assess diversity of variant services adhering to four different requirements specifications. For each specification, we analysed three different services. Results: We found that the proposed directives were effective for the purposes of this assessment. Assessment results demonstrated that services implementing the four requirements specifications are actually diverse at a 0.05 significance level. For two of the specifications, coincident failures of two or more services are infrequent enough to promote gains in overall system reliability. Conclusions: Our findings reveal threats to the effectiveness of service-oriented applications that relies on design diversity to tolerate faults. This in turn reinforces the usefulness of our experimental setup, which supports researchers' decision making when selecting variants for building fault-tolerant service applications.

Abstract This paper presents an in‐depth study of the adequacy of the AspectJ language for modularizing and reusing exception‐handling code. The study consisted of refactoring existing applications so that the code responsible for implementing error‐handling strategies was moved to newly created exception handler aspects. We have performed quantitative assessments of five systems—four object‐oriented and one aspect‐oriented—based on four key quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi‐perspective analysis of the refactored systems, including (i) the extent to which error‐handling aspects can be reused, (ii) the beneficial and harmful aspectization scenarios for exception handling, and (iii) the scalability of AOP to support the modularization of exception handling in the presence of other aspects. Copyright © 2009 John Wiley & Sons, Ltd.

It is usually assumed that exception handling code can be better modularized by the use of aspect-oriented programming (AOP) techniques. However, recent studies argue that the ad hoc use of AOP can be detrimental to the quality of a system. When refactoring exception handling code to aspects, developers and maintainers need to follow clear and simple principles to obtain a well-structured system design. Otherwise, typical problems that stem from poorly designed/implemented error handling code will arise, e.g. resource leaking and swallowed exceptions. In this paper, we propose a classification for error handling code based on the factors that we found out have more influence on its aspectization. Moreover, we present a scenario catalog comprising combinations of these factors and analyze how these scenarios positively or negatively affect the task of aspectizing exception handling. We evaluated the proposed catalog through a case study where we used it to guide the aspectization of exception handling in two real systems.

It is usually assumed that the implementation of exception handling can be better modularized by the use of aspect-oriented programming (AOP). However, the trade-offs involved in using AOP with this goal are not well-understood. This paper presents an in-depth study of the adequacy of the AspectJ language for modularizing exception handling code. The study consisted in refactoring existing applications so that the code responsible for implementing heterogeneous error handling strategies was moved to separate aspects. We have performed quantitative assessments of four systems - three object-oriented and one aspect-oriented - based on four quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi-perspective analysis of the refactored systems, including (i) the reusability of the aspectized error handling code, (ii) the beneficial and harmful aspectization scenarios, and (iii) the scalability of AOP to aspectize exception handling in the presence of other crosscutting concerns.

Exception handling is a structuring technique that facilitates the design of software systems by encapsulating the process of error recovery. In this paper, we present a systematic approach for incorporating exceptional behaviour in the development of component-based software. The premise of our approach is that components alone do not provide the appropriate means to deal with exceptional behaviour in an effective manner, hence the need to consider the notion of collaborations for capturing the interactive behaviour between components when error recovery involves more than one component. The feasibility of the approach is demonstrated in terms of the mining control system case study. Copyright © 2004 John Wiley & Sons, Ltd.

This paper presents a component model for designing and implementing flexible software components in Java. Our model defines a mapping of how the fundamental concepts of component-based development (CBD) should be implemented using the object-oriented (OO) constructs, available in the Java programming language. The benefit of this mapping is to shorten the distance between component-based software architecture and its implementation, enhancing the reusability, adaptability and maintainability of component-based software systems.

This paper considers the problem of integrating Commercial offthe-shelf (COTS) components into systems with high dependability requirements. Such components are built to be reused as black boxes that cannot be modified. The system architect has to rely on techniques that are external to the component for resolving mismatches between the services required and provided that might arise in the interaction of the component and its environment. The paper puts forward an approach that employs the layer-based C2 architectural style for structuring error detection and recovery mechanisms to be added to the component during system integration.

Jaca is a software fault injection tool that validates OO applications written in Java. Jaca's major goal is to inject faults using high-level programming features during runtime by corrupting attribute values, methods parameters or return values. Jaca's design was based on a set of patterns-the fault injection pattern system. This pattern describes a generic architecture defined from recurrent design aspects present in most fault injection tools. The objective was to reduce tool development time while enhancing qualities such as portability, extensibility, reusability, efficiency and robustness. The paper presents the pattern set and its use in Jaca's development. An extension of Jaca to consider injection at the assembly level is also presented to show how easy it is to add new features to the tool.

Modern concurrent and distributed applications are becoming increasingly complex; so, in order to provide fault tolerance, special structuring mechanisms are required to help reduce this complexity. Unfortunately, such structuring techniques are mostly introduced as design and implementation features, which complicates their employment. The approach we propose relies on introducing the appropriate software structuring together with associated fault tolerance measures at the earlier phases of software development and on supporting it with special software architectures and design patterns.

Dependable object-oriented software systems are inherently complex and have to cope with an increasing number of exceptional conditions in order to meet system dependability requirements. This work proposes a software architecture which integrates uniformly both concurrent and sequential exception handling. The exception handling architecture is independent of programming language or exception handling mechanism, and its use can minimize the complexity caused by the handling of abnormal behavior. Our architecture provides, during the architectural design stage, the context in which more detailed design decisions related to exception handling are made in later development stages. This work also presents a set of design patterns which describes the static and dynamic aspects of the components of our software architecture. The patterns allow a clear separation of concerns between the system's functionality and the exception handling facilities, applying the computational reflection technique.

The current lack of effective error-handling techniques for developing dependable object-oriented software produces software components which are usually difficult to understand, to change and to maintain in the presence of faults. Ideally, such components should incorporate their exceptional activity in a structured and transparent manner so that the abnormal code would not be amalgamated into the normal code. In this context, we propose the design and implementation of an object-oriented exception handling mechanism based on a meta-level approach. The goal of our work is twofold: (i) to define an exception handling model which supports a clear and transparent separation of the normal activity of a component from its exceptional activity, and (ii) to provide a meta-level architecture which implements such mechanism. This mechanism does not require any special language support and was implemented within the Java programming language without any changes to the language itself by means of a meta-object protocol.