Section: New Results
Aspect-oriented Design of Dynamic Components Assemblies
Formal models and approaches
With new component platforms, architects create distributed applications by assembling components. For all these platforms, a software architecture defines the application organization as a collection of components plus a set of constraints on the interactions between components. To face the difficulties for building correct software architecture, abstract software architecture models were defined. They are powerful methods in the specification and analysis of high-level designs. Lots of architecture description models have been defined to describe, design, check, and implement software architectures. Many of these models support sophisticated analysis and reasoning or support architecture-centric development.
Nevertheless, these models are often static or work only on the components composition. In these conditions, it is difficult to build large software architecture or to integrate new components in an existing software architecture or to add a forgotten concern such as security or persistency. Thus, we propose SafArchie, an abstract component model for designing software architectures  . With SafArchie, we based our approach on architecture types that are points of reference at each step of our reasoning  ,  . We develop SafArchie Studio   ,  , an architecture centric tool based on three-view perspective and driven by the component life cycle.
Still related to the domain of static validation of component-based architectures, we have also worked in validating architectures composed by the means of aspects. CompAr (Composing Around advice) is a language that has been created to automatically detect and solve Aspect-Composition Issues (ACIs) of around advice. When doing AOP or any related programming technique using around advising, such as interception-based approaches, an ACI can arise when several around pieces of advice apply to the same advised element (it is then an advice chain). Indeed, each around advice code holds some implicit execution contraints; when they are composed together in a chain, they can conflict in such a way that the global system does not fulfill some of the implicit contraints anymore. With CompAr, one can specify the execution constraints of the advice as well as an abstract representation of its code. For a given advice chain order, the CompAr compiler checks that all the execution contraints are fullfilled by evaluating the abstract specification for all the possible contexts. In the case an execution constraint is not fulfilled, the compiler reports an error and some indications to the user so that s/he can solve the ACI, either by reordering the chain, or by changing the abstract specification of some advice. CompAr and some examples of conflict resolving have been published in  .
Aspects and Components for Software Architectures
This action is concerned with the definition and the implementation of a programming environment for complex applications in the domains of middleware, embedded systems and ubiquitous computing. This environment investigates the use of two software engineering techniques: component-based software engineering (CBSE) and aspect-oriented software development (AOSD).
In a post-object world (object in the sense of object-oriented programming languages), both techniques are recognized as being solutions to manage the complexity of software. Far from being redundant or conflicting, they are complementary in the sense that CBSE is a solution for defining the functional part of a software architecture, whereas AOSD allows modularizing the crosscutting, non functional, part of this software.
Two new results have been achieved in 2005 around this action:
The definition of a general framework  for integrating AOSD and CBSE. We showed that both concepts can be integrated at various level of granularity: the level of the software architecture, the level of the individual building blocks of this architecture, and the level of the implementation of these building blocks. These three levels have different purposes, and are jointly needed when considering applications with components and aspects. This result is part of the ongoing work of Nicolas Pessemier's PhD thesis.
Component frameworks (e.g. EJB, CCM, .Net/COM+) provide an infrastructure for hosting component-based applications. Various services are provided to manage components. The granularity and the features included in these services vary because each component model addresses needs that may be different. However, so far, component models are mostly closed, black boxes, in which services are hardcoded and can not be changed. We showed that the engineering of these services could be opened with components. We have thus proposed a two-dimension component model where the business dimension is concerned, just like in the other component models, with the functional part of the application, whereas the control dimension is concerned with the services provided by the framework to host and manage the components of the business dimension. Through this approach, we propose a high-level solution for engineering the control part of software components. Several domains may benefit from this approach, such as the domains of self-healing, self-testable or proof-carrying software components. The proposed model and its implementation are called AOKell  . It conforms to the Fractal Specifications.
These two results are part of the ongoing grant with France Telecom R&D.
Transformation Languages and Tools
Building a software architecture with all the needed concerns at once is a complex task. Consequently, an incremental approach where each concern is successively integrated into the architecture will be preferred. Unfortunately, the existing architecture description languages, which enable an architect to create an architecture by constructing and combining increasingly complex elements, are not suitable to cleanly structure concerns that crosscut the software architecture, such as security. To address this issue we have proposed TranSAT, which is a framework to specify incremental software architecture transformations  ,  ,  . TranSAT isolates the description of each concern in a separate architecture construct, the pattern , that is automatically integrated with an existing software architecture by a weaver . Analogous to an aspect, a pattern consists of the new architecture fragment to be integrated, a description of where it can be applied, and a specification of the transformations that should be performed to connect it to the existing architecture. As a pattern can specify updates to multiple elements in an existing architecture, it is suitable for expressing crosscutting concerns. We have designed the language for specifying patterns in order to enable verifications that ensure that the concern is safely integrated into the existing architecture. The verification comprises static verifications that check coherence properties once the pattern has been defined, and dynamic verifications that focus on the parts of the architecture that are affected by the pattern. This work has been done in the context of the PhD of Olivier Barais  ,  .
In order to support analysis and design-level validation in an efficient way, we are also currently working at building language-level transformation tools. For this, we have developped Spoon, which is an annotation-driven program transformation tool. In 2004, SUN released Java 5, which includes "generics" and "annotations". With annotations, the Java 5 programmers can define and attach metadata on the program elements. These metadata allow for declarative configuration of the programs to define non-functional properties. In many cases, annotation-based configuration is preferred over typical XML-based one, because it is more integrated into Java, much safer (type-safety), and it avoids information redundancy. However, current tools to deal with annotations are currently limited to large-grained annotation-based program validation and documentation generation. Spoon's goal is to answer the needs of the industry and of the Java community in general for a tool that fully supports generics and annotations and that allows for fined-grained and type-safe program validation and transformations. Spoon has applications in several domains. Spoon can be used in component containers (to implement annotation-driven deployment), for general software engineering (in particular AOSD can benefit from the use of annotation to parameterize the pointcuts), ubiquitous computing (annotations would help the programs to target the right environment), real-time systems (programmers would then define time constraints annotations directly in the Java code), etc. Spoon and its application to AOSD has been published in  .