Fernando Castor Filho

Evolving software product lines with aspects: an empirical study on design stability

Software product lines (SPLs) enable modular, large-scale reuse through a software architecture addressing multiple core and varying features. To reap the benefits of SPLs, their designs need to be stable. Design stability encompasses the sustenance of the product lines modularity properties in the presence of changes to both the core and varying features. It is usually assumed that aspect-oriented programming promotes better modularity and changeability of product lines than conventional variability mechanisms, such as conditional compilation. However, there is no empirical evidence on its efficacy to prolong design stability of SPLs through realistic development scenarios. This paper reports a quantitative study that evolves two SPLs to assess various design stability facets of their aspect-oriented implementations. Our investigation focused upon a multi-perspective analysis of the evolving product lines in terms of modularity, change propagation, and feature dependency. We have identified a number of scenarios which positively or negatively affect the architecture stability of aspectual SPLs.

Exceptions and aspects: the devil is in the details

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.

Extracting Error Handling to Aspects: A Cookbook

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.

Error handling as an aspect

One of the fundamental motivations for employing exception handling in the development of robust applications is to lexically separate error handling code from the normal code so that they can be independently modified. However, experience has shown that exception handling mechanisms of mainstream programming languages fail to achieve this goal. In most systems, exception handling code is interwined with the normal code, hindering maintenance and reuse. Moreover, because of limitations in the exception handling mechanisms of most mainstream programming languages, error handling code is often duplicated across several different places within a system. In this paper we present a pattern, Error Handling Aspect, which leverages aspect-oriented programming in order to enhance the separation between error handling code and normal code. The basic idea of the pattern is to use advice to implement exception handlers and pointcuts to associate advice to different parts of the normal code in order to improve the maintainability of the normal code and promote reuse of error handling code.

A method for modeling and testing exceptions in component-based software development

The design, implementation and testing of the exceptional activity of a software system are complex tasks that usually do not receive the necessary attention from existing development methodologies. This work presents a systematic way to deal with exception handling, from the requirement specification phase to the implementation and testing phases, in component-based software development. Testing activities are performed since the early stages of development, promoting an increase in the quality of the produced system. Our solution refines the Methodology for the Definition of Exception Behavior, MDCE, in the architectural design, implementation, and testing phases. Moreover, the proposed method was adapted to the UML Components process.

Application execution management on the InteGrade opportunistic grid middleware

The InteGrade project is a multi-university effort to build a novel grid computing middleware based on the opportunistic use of resources belonging to user workstations. The InteGrade middleware currently enables the execution of sequential, bag-of-tasks, and parallel applications that follow the BSP or the MPI programming models. This article presents the lessons learned over the last five years of the InteGrade development and describes the solutions achieved concerning the support for robust application execution. The contributions cover the related fields of application scheduling, execution management, and fault tolerance. We present our solutions, describing their implementation principles and evaluation through the analysis of several experimental results.

Specification of exception flow in software architectures

Abstract In recent years, various approaches combining software architectures and exception handling have been proposed for increasing the dependability of software systems. This conforms with the idea supported by some authors that addressing exception handling-related issues since early phases of software development may improve the overall dependability of a system. By systematically designing the mechanism responsible for rendering a system reliable, developers increase the probability of the system being able to avoid catastrophic failures at runtime. This paper addresses the problem of describing how exceptions flow amongst architectural elements. In critical systems where rollback-based mechanisms might not be available, such as systems that interact with mechanical devices, exception handling is an important means for recovering from errors in a forward-based manner. We present a framework, named Aereal, that supports the description and analysis of exceptions that flow between architectural components. Since different architectural styles have different policies for exception flow, Aereal makes it possible to specify rules on how exceptions flow in a given style and to check for violations of these rules. We use a financial application and a control system as case studies to validate the proposed approach.

A systematic approach for structuring exception handling in robust component-based software

Component-based development (CBD) is recognized today as the standard paradigm for structuring large software systems. However, the most popular component models and component-based development processes provide little guidance on how to systematically incorporate exception handling into component-based systems. The problem of how to employ language-level exception handling mechanisms to introduce redundancy in componentbased systems is recognized by CBD practitioners as very difficult and often not adequately solved. As a consequence, the implementation of the redundant exceptional behaviour causes a negative impact, instead of a positive one, on system and maintainability. In this paper, we propose an approach for the construction of dependable component-based systems that integrates two complementary strategies: (i) a global exception handling strategy for inter-component composition and (ii) a local exception handling strategy for dealing with errors in reusable components. A case study illustrates the application of our approach to a real software system.

An Architectural-Level Exception-Handling System for Component-Based Applications

Component-based software systems built out of reusable software components are being used in a wide range of applications which have high dependability requirements. In order to accomplish the required levels of dependability, it is necessary to incorporate into these complex systems means for to cope with software faults. Exception handling is a well-known technique for adding forward error recovery to software systems supported by various mainstream programming languages. However, exception handling for component-based applications at the architectural level introduces new challenges which are not addressed by traditional exception handling systems, such as unavailability of source code, specially when off-the-shelf components are employed. In this paper, we present an exception handling system which adds fault tolerance to component-based systems at the architectural level. Our solution considers issues which are specific to component-based applications, such as unavailability of source code. We also present a framework which implements the proposed exception handling system for applications built using the C2 architectural style.

A framework for analyzing exception flow in software architectures

We present Aereal, a framework for analyzing exception flow in architecture descriptions. Aereal works as a customizable architectural-level exception handling system that can be further constrained or have some of its rules relaxed. Since different architectural styles have different policies for exception flow, Aereal makes it possible to specify rules on how exceptions flow in a given style and to check for violations of these rules. As enabling technologies. Aereal uses Alloy, a first-order relational language, ACME, an interchange language for architecture description, and their associated tool sets.