Patrick H. S. Brito

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.

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.

Architecting fault tolerance with exception handling: verification and validation

When building dependable systems by integrating untrusted software components that were not originally designed to interact with each other, it is likely the occurrence of architectural mismatches related to assumptions in their failure behaviour. These mismatches, if not prevented during system design, have to be tolerated during runtime. This paper presents an architectural abstraction based on exception handling for structuring fault-tolerant software systems. This abstraction comprises several components and connectors that promote an existing untrusted software element into an idealised fault-tolerant architectural element. Moreover, it is considered in the context of a rigorous software development approach based on formal methods for representing the structure and behaviour of the software architecture. The proposed approach relies on a formal specification and verification for analysing exception propagation, and verifying important dependability properties, such as deadlock freedom, and scenarios of architectural reconfiguration. The formal models are automatically generated using model transformation from UML diagrams: component diagram representing the system structure, and sequence diagrams representing the system behaviour. Finally, the formal models are also used for generating unit and integration test cases that are used for assessing the correctness of the source code. The feasibility of the proposed architectural approach was evaluated on an embedded critical case study.

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.

Explicit exception handling variability in component-based product line architectures

Separation of concerns is one of the overarching goals of exception handling in order to keep separate normal and exceptional behaviour of a software system. In the context of a software product line (SPL), this separation of concerns is also important for designing software variabilities related to different exception handling strategies, such as the choice of different handlers depending on the set of selected features. This paper presents a method for refactoring object-oriented product line architecture in order to separate explicitly their normal and exceptional behaviour into different software components. The new component-based software architecture includes variation points related to different choices of exception handlers that can be selected during product instantiations, thus facilitating the evolution of the exceptional behaviour. The feasibility of the proposed approach is assessed through a SPL of mobile applications.

Verifying architectural variabilities in software fault tolerance techniques

This paper considers the representation of different software fault tolerance techniques as a product line architecture (PLA) for promoting the reuse of software artifact. The proposed PLA enables to specify a series of closely related architectural applications, which is obtained by identifying variation points associated with design decisions regarding software fault tolerance. These decisions are used to choose the appropriate technique depending on the features selected, e.g, the number of redundant resources, or the type of adjudicator. The proposed approach also comprises the formalisation of the PLA, using B-Method and CSP, for systematising the verification of fault-tolerant software systems at the architectural level. The properties verified cover two complementary contexts: the selection of the correct architectural variabilities for instantiating the PLA, and also the properties of the chosen fault tolerance techniques.

Architecture-centric fault tolerance with exception handling

When building dependable systems by integrating untrusted software components that were not originally designed to interact with each other, it is inevitable the occurrence of architectural mismatches related to assumptions in the failure behaviours. These mismatches if not prevented during system design have to be tolerated during run-time. This paper presents an architectural abstraction based on exception handling for structuring fault-tolerant software systems. This abstraction comprises several components and connectors that transform an existing untrusted software element into an idealised fault-tolerant architectural element. The proposed rigorous approach relies on a formal representation for analysing exception propagation, and verifying important dependability properties. Beyond this, the formal models are also used for generating unit and integration test cases that would be used for validating the final software product. The feasibility of the proposed approach was evaluated on an embedded critical case study.

Verification of Exception Control Flows and Handlers Based on Architectural Scenarios

The use of exception handling mechanisms to develop robust software systems in a non-systematic manner can be a source of many design faults. This paper presents a rigorous development approach based on formal methods, which allows to systematise the verification of the systems abnormal behaviour at the architectural level. Our solution is based on the specification and verification of architectural scenarios, which describe both exception control flows and exception handlers involving architectural elements (components and connectors). We also adopt an architectural abstraction for guiding the internal structure of the architectural elements. The verification process is conducted using the ProB model checker, which combines the use of set-theory (B-Method) and a process algebra (CSP). The feasibility of our approach was evaluated by a case study from the financial domain.

Development of Fault-Tolerant Software Systems Based on Architectural Abstractions

The incorporation of fault tolerance into systems normally increases their complexity, which consequently makes their analysis more difficult. This paper discusses how architectural abstractions can be effective in developing fault-tolerant software systems. Depending on the fault model and the resources available, different abstractions can be employed for representing issues that are related to fault tolerance, such as error detection, and error and fault handling. These architectural abstractions, and their internal views, can be instantiated into concrete components and connectors for designing fault-tolerant software architectures. Since structural and behavioural properties associated with these abstractions are formally specified, the process of verifying and validating software architectures can be automated. In this paper, we show how appropriate architectural abstractions and a recursive process can facilitate the architectural modelling and analysis of fault-tolerant software systems. The feasibility of the proposed approach is demonstrated in the context of a critical real-time application.

Designing fault-tolerant SOA based on design diversity

BackgroundOver recent years, software developers have been evaluating the benefits of both Service-Oriented Architecture (SOA) and software fault tolerance techniques based on design diversity. This is achieved by creating fault-tolerant composite services that leverage functionally-equivalent services. Three major design issues need to be considered while building software fault-tolerant architectures based on design diversity: (i) selection of variants; (ii) selection of an adjudication algorithm to choose one of the results; and (iii) execution of variants. In addition, applications based on SOA need to function effectively in a dynamic environment where it is necessary to postpone decisions until runtime. In this scenario, control is highly distributed and involves conflicting user requirements. We aim to support the software architect in the design of fault-tolerant compositions.MethodsLeveraging a taxonomy for fault-tolerant systems, this paper proposes guidelines to aid software architects in making key design decisions. The taxonomy is used as the basis for defining a set of guidelines to support the architect in making decisions related to fault tolerance in SOA. The same taxonomy is used in a systematic literature review of solutions for fault-tolerant composite services.The review investigates how existing approaches for fault-tolerant composite services address design diversity issues and also specific issues related to SOA.ResultsThe contribution of this work is twofold: (i) a set of guidelines for supporting the design of fault-tolerant SOA, based on a taxonomy for fault tolerance techniques; and (ii) a systematic literature review of existing solutions for designing fault-tolerant compositions using design diversity.ConclusionAlthough existing solutions have made significant contributions to the development of fault-tolerant SOAs, there is a lack of approaches for fault-tolerant service composition that support strategies with diverse quality requirements and encompassing sophisticated context-aware capabilities. This paper discusses which 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.