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

A Rewriting Semantics for a Software Architecture Description Language

We present an architecture that includes two essential services to compose the supporting infrastructure required by context-aware applications: a Context Service, that provides access to context information, and a Discovery Service. A reference implementation, based on Web Services technology, was used to develop a remote assisted living application, which relies on ambient sensors, placed in each room, to capture context information and on a combo medical appliance to perform blood pressure measurements on the patient, according to a care plan prescribed by a doctor. The collected set of context data may be transmitted to a monitoring centre and also interpreted locally using medical knowledge; the identification of a patient's abnormal condition can activate local actions or send an emergency message to a monitoring centre. This infrastructure can help a doctor to monitor and assist the patient while he or she is performing daily activities and may also help improving the patient's treatment compliance and quality of life.

Applying context-aware techniques to design remote assisted living applications

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

Romulo Curty

Papers

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