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.

/pdf/on-the-modularization-and-reuse-of-exception-handling-with-43fyu2mc8e.pdf

On the modularization and reuse of exception handling with aspects

Architectural languages (ALs) have attracted much attention as the modeling notations for specifying and reasoning about important design decisions. In this study, 124 different existing ALs have been analyzed for a set of requirements that are crucial for practitioners. These requirements are concerned with language definition, language features, and tool support. Some of the important findings obtained from the analysis are as follows: (1) performance is the top popular nonfunctional requirement supported by ALs; (2) no ALs offer both textual and visual notation sets, one of which could be used independently; (3) process algebras are the top preferred formal method by formal ALs; (4) the physical, deployment, and operational viewpoints are rarely supported by ALs; (5) the top preferred extension mechanism of the extensible ALs is XML for syntax extension; (6) Java is the top preferred programming language in generating software code; (7) the exhaustive model checking is the top preferred automated analysis method; (8) the logic‐based formal techniques are so popular in specifying system requirements; (9) among the analysis properties considered, consistency is the top supported property for the automated checking; and (10) most ALs do not provide any discussion platform (eg, forums). Hence, these findings can be used by the new AL developers in addressing the needs of practitioners and bridging the gaps in the field. Practitioners can also use the findings to find out about the existing ALs and compare them to choose the one(s) that suits their needs best.

The analysis of architectural languages for the needs of practitioners

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.

Architecting fault tolerance with exception handling: verification and validation

This paper presents a comprehensive approach to describe, deploy and adapt component-based applications having dynamic non-functional requirements. The approach is centered on high-level contracts associated to architectural descriptions, which allow the non-functional requirements to be handled separately during the system, design process. This helps to achieve separation of concerns facilitating the reuse of modules that implement the application in other systems. Besides specifying non-functional requirements, contracts are used at runtime to guide configuration adaptations required to enforce these requirements. The infrastructure required to manage the contracts follows an architectural pattern, which can be directly mapped to specific components included in a supporting reflective middleware. This allows designers to write a contract and to follow standard recipes to insert the extra code required to its enforcement in the supporting middleware.

/pdf/a-contract-based-approach-to-describe-and-deploy-non-3rxxbic8wj.pdf

A contract-based approach to describe and deploy non-functional adaptations in software architectures

A Rewriting Semantics for a Software Architecture Description Language

This paper presents an approach to describe, deploy and manage component-based applications having dynamic functional and non-functional requirements, which include different types of QoS. The approach is centered on an ADL that allows functional and non-functional requirements to be described by high-level textual contracts. The meta information extracted from the software architecture description is used to guide configuration adaptations required to enforce the ruling contract. The infrastructure required to automatically manage these contracts follows a standard architectural pattern, which can be directly mapped to specific components included in a supporting middleware. This allows designers to write a contract and to follow a standard recipe to insert the extra code required to its enforcement in the supporting middleware. Also, the component configuration capability provided by the middleware helps to put in practice adaptations defined by a contract. Examples demonstrate how the approach and the associated middleware can be used to configure and to support applications with adaptive QoS requirements.

/pdf/deploying-non-functional-aspects-by-contract-5ajdux1zwc.pdf

Deploying Non-Functional Aspects by Contract.

This paper presents an approach to describe, deploy and manage software architectures having dynamic functional and non-functional requirements. The approach is centered on an ADL extended with high-level contracts, which are used to specify the non-functional requirements associated to the architecture of a given application. These contracts are also used to configure the infrastructure required to enforce the non-functional requirements and, during the running time, can be used to guide architecture adaptations, in order to keep them valid in face of changes in the supporting environment. The infrastructure required to manage the contracts follows an architectural pattern, which can be directly mapped to specific components included in a supporting reflective middleware. This allows designers to write a contract and to follow standard recipes to insert the extra code required to its enforcement in the supporting middleware.

/pdf/deploying-qos-contracts-in-the-architectural-level-3ra1k9hk17.pdf

Sidney Ansaloni

Papers

A contract-based approach to describe and deploy non-functional adaptations in software architectures

Deploying Non-Functional Aspects by Contract.

Deploying QoS Contracts in the Architectural Level