A Component-Based and Aspect-Oriented Model for Software Evolution

International audienceComponent-Based Software Development (CBSD) and Aspect-Oriented Software Development (AOSD) are solutions to support software evolution by decomposing a software system into concerns. In this article, we propose Fractal Aspect Component (FAC), a general and symmetrical model for components and aspects. FAC decomposes a software system into regular components and aspect components which embody crosscutting concerns. We reify the relationship between an aspect component and a component, called an aspect binding, as a first-class runtime entity. The evolution of the system can be expressed by adding or removing components (aspect or regular) and by setting bindings (regular or crosscutting)

A concern-oriented approach to software architecture

A major cause of many complications in the field of software architectures is the lack of appropriate abstractions for separating, combining and encapsulating concerns of various kinds in architectural descriptions. Architectures of most complex software-intensive systems involve concerns that inherently crosscut the natural boundaries of the elements composing the architecture descriptions. Crosscutting concerns intersect the common modularity of systems as prescribed by their architecture descriptions, by traversing both the components and connectors, i.e., the relationships among the components. Crosscutting concerns are critical aspects of many architectural problems. However, architectural descriptions written in special-purpose languages (ADLs) like Wright, Darwin, Rapide and Acme should support descriptions of multiple structures, which include diagrams, models and views, that intentionally address different kinds of concerns. ADLs should show how various concerns affect each other in architectural designs; they should also allow one to identify, analyze and elaborate architectural concerns that cut across several software components, such as transactions, security, load balancing, synchronization, reuse, customization, scalability, etc.; they should, but they do not. This dissertation presents a new approach to software architecture that is suitable for supporting concern-oriented development and documentation of architectures for software-intensive systems. This approach allows for creating and documenting a multidimensional software structure that is referred to as concern-oriented software architecture; it provides new mechanisms for encapsulating individual concerns into independent architectural constructs. The ultimate goal of this new approach is to provide support for achieving design by concerns all through the development and description of software architectures. Moving towards this goal, we present a particular concern-oriented architectural framework called Perspectival Concern-Spaces (PCS). The PCS Framework offers a flexible and extensible means a) for supporting advanced separation of concerns in architectural design, and in the construction and evolution of software-intensive systems; and b) for filling the gap between architectural descriptions and modern software development artifacts. To show the feasibility of the proposed approach, we provide new modeling techniques that are used to describe and apply an aspect-oriented architectural pattern, called the On-demand Remodularization pattern. We give several examples of how the PCS Framework can be used to integrate concern-oriented architectural documentations with mainstream software development artifacts

Exception handling in the development of fault-tolerant component-based systems

Orientador: Cecilia Mary Fischer RubiraTese (doutorado) - Universidade Estadual de Campinas, Instituto de ComputaçãoResumo: Mecanismos de tratamento de exceções foram concebidos com o intuito de facilitar o gerenciamento da complexidade de sistemas de software tolerantes a falhas. Eles promovem uma separação textual explícita entre o código normal e o código que lida com situações anormais, afim de dar suporte a construção de programas que são mais concisos fáceis de evoluir e confáveis. Diversas linguagens de programação modernas e a maioria dos modelos de componentes implementam mecanismos de tratamento de exceções. Apesar de seus muitos benefícios, tratamento de exceções pode ser a fonte de diversas falhas de projeto se usado de maneira indisciplinada. Estudos recentes mostram que desenvolvedores de sistemas de grande escala baseados em infra-estruturas de componentes têm hábitos, no tocante ao uso de tratamento de exceções, que tornam suas aplicações vulneráveis a falhas e difíceis de se manter. Componentes de software criam novos desafios com os quais mecanismos de tratamento de exceções tradicionais não lidam, o que aumenta a probabilidade de que problemas ocorram. Alguns exemplos são indisponibilidade de código fonte e incompatibilidades arquiteturais. Neste trabalho propomos duas técnicas complementares centradas em tratamento de exceções para a construção de sistemas tolerantes a falhas baseados em componentes. Ambas têm ênfase na estrutura do sistema como um meio para se reduzir o impacto de mecanismos de tolerância a falhas em sua complexidade total e o número de falhas de projeto decorrentes dessa complexidade. A primeira é uma abordagem para o projeto arquitetural dos mecanismos de recuperação de erros de um sistema. Ela trata do problema de verificar se uma arquitetura de software satisfaz certas propriedades relativas ao fluxo de exceções entre componentes arquiteturais, por exemplo, se todas as exceções lançadas no nível arquitetural são tratadas. A abordagem proposta lança de diversas ferramentas existentes para automatizar ao máximo esse processo. A segunda consiste em aplicar programação orientada a aspectos (AOP) afim de melhorar a modularização de código de tratamento de exceções. Conduzimos um estudo aprofundado com o objetivo de melhorar o entendimento geral sobre o efeitos de AOP no código de tratamento de exceções e identificar as situações onde seu uso é vantajoso e onde não éAbstract: Exception handling mechanisms were conceived as a means to help managing the complexity of fault-tolerant software. They promote an explicit textual separation between normal code and the code that deals with abnormal situations, in order to support the construction of programs that are more concise, evolvable, and reliable. Several mainstream programming languages and most of the existing component models implement exception handling mechanisms. In spite of its many bene?ts, exception handling can be a source of many design faults if used in an ad hoc fashion. Recent studies show that developers of large-scale software systems based on component infrastructures have habits concerning the use of exception handling that make applications vulnerable to faults and hard to maintain. Software components introduce new challenges which are not addressed by traditional exception handling mechanisms and increase the chances of problems occurring. Examples include unavailability of source code and architectural mismatches. In this work, we propose two complementary techniques centered on exception handling for the construction of fault-tolerant component-based systems. Both of them emphasize system structure as a means to reduce the impactof fault tolerance mechanisms on the overall complexity of a software system and the number of design faults that stem from complexity. The ?rst one is an approach for the architectural design of a system?s error handling capabilities. It addresses the problem of verifying whether a software architecture satis?es certain properties of interest pertaining the ?ow of exceptions between architectural components, e.g., if all the exceptions signaled at the architectural level are eventually handled. The proposed approach is based on a set of existing tools that automate this process as much as possible. The second one consists in applying aspect-oriented programming (AOP) to better modularize exception handling code. We have conducted a through study aimed at improving our understanding of the efects of AOP on exception handling code and identifying the situations where its use is advantageous and the ones where it is notDoutoradoDoutor em Ciência da Computaçã

Feature interaction in composed systems. Proceedings. ECOOP 2001 Workshop #08 in association with the 15th European Conference on Object-Oriented Programming, Budapest, Hungary, June 18-22, 2001

Feature interaction is nothing new and not limited to computer science. The problem of undesirable feature interaction (feature interaction problem) has already been investigated in the telecommunication domain. Our goal is the investigation of feature interaction in componet-based systems beyond telecommunication. This Technical Report embraces all position papers accepted at the ECOOP 2001 workshop no. 08 on "Feature Interaction in Composed Systems". The workshop was held on June 18, 2001 at Budapest, Hungary

Advances in component-oriented programming

WCOP 2006 is the eleventh event in a series of highly successful workshops, which took place in conjunction with every ECOOP since 1996. Component oriented programming (COP) has been described as the natural extension of object-oriented programming to the realm of independently extensible systems. Several important approaches have emerged over the recent years, including component technology standards, such as CORBA/CCM, COM/COM+, J2EE/EJB, and .NET, but also the increasing appreciation of software architecture for component-based systems, and the consequent effects on organizational processes and structures as well as the software development business as a whole. COP aims at producing software components for a component market and for late composition. Composers are third parties, possibly the end users, who are not able or willing to change components. This requires standards to allow independently created components to interoperate, and specifications that put the composer into the position to decide what can be composed under which conditions. On these grounds, WCOP\u2796 led to the following definition: "A component is a unit of composition with contractually specified interfaces and explicit context dependencies only. Components can be deployed independently and are subject to composition by third parties." After WCOP\u2796 focused on the fundamental terminology of COP, the subsequent workshops expanded into the many related facets of component software. WCOP 2006 emphasizes reasons for using components beyond reuse. While considering software components as a technical means to increase software reuse, other reasons for investing into component technology tend to be overseen. For example, components play an important role in frameworks and product-lines to enable configurability (even if no component is reused). Another role of components beyond reuse is to increase the predictability of the properties of a system. The use of components as contractually specified building blocks restricts the degrees of freedom during software development compared to classic line-by-line programming. This restriction is beneficial for the predictability of system properties. For an engineering approach to software design, it is important to understand the implications of design decisions on a system\u27s properties. Therefore, approaches to evaluate and predict properties of systems by analyzing its components and its architecture are of high interest. To strengthen the relation between architectural descriptions of systems and components, a comprehensible mapping to component-oriented middleware platforms is important. Model-driven development with its use of generators can provide a suitable link between architectural views and technical component execution platforms. WCOP 2006 accepted 13 papers, which are organised according to the program below. The organisers are looking forward to an inspiring and thought provoking workshop. The organisers thank Jens Happe and Michael Kuperberg for preparing the proceedings volume

An orthogonal framework for fault tolerance composition in software systems

Building reliable systems is one of the major challenges faced by software developers as society is becoming more dependent on software systems. The failure of any system can lead to a serious loss, for example serious injury or death in case of safety critical systems and significant financial loss in the case of business-critical systems. As a consequence, fault tolerance is considered as a solution to provide reliability, but the fault tolerance capability is associated with many challenges, such as the right development phase where it needs to be introduced, how it can be composed with the software, and the issues that arise from this composition such as complexity and potential undesirable feature interactions. This thesis presents an orthogonal fault tolerance framework for the composition of design diversity fault tolerance mechanism with the base system. It further ensures the separation of concerns between the ‘base’ system and the fault tolerance mechanisms that are composed with the base system. The composition in this framework is based on operational semantics that describe the behaviour of the underlying components when composed with the fault tolerance mechanisms. A custom-built pre-processor is based on these composition rules, and is used to automatically compose the system component and the fault tolerance mechanisms. The very introduction of different fault tolerance mechanisms to the system may cause interactions with other fault tolerance features or with system components. Logic properties written in CTL and LTL are used in NuSMV to analyse undesirable interactions. To illustrate its applicability, the framework has been applied to the Home Automation and Therac-25 software