Project-Team-Triskell:Contract-based and Aspect Oriented Design

Project-Team : triskell

Section: New Results

Contract-based and Aspect Oriented Design

Model Driven Engineering for Distributed Real Time Embedded Systems

Participants: Jean-Marc Jézéquel, Pierre-Alain Muller, Christophe Métayer.

In domains such as automotive or avionics, real-time and embedded systems are getting ever more software intensive. The software cannot any longer be produced as a single chunk, and engineers are contemplating the possibility of componentizing it along the lines presented in Section 3.2. In this vision, any composite application is viewed as a particular configuration of components, selected at build-time and configured or re-configured at run-time. A software component only exhibits its provided or required interfaces. This defines basic contracts between components allowing one to properly wire them.

In real-time and embedded systems however, we have to take into account many extra-functional aspects, such as timeliness, memory consumption, power dissipation, reliability, performances, and generally speaking Quality of Service (QoS). These aspects can also be seen as contracts between the system, its environment and its users. These contracts must obviously be propagated down to the component level. One of the key desiderata in component-based development for embedded systems is thus the ability to capture both functional and extra-functional properties in component contracts, and to verify and predict corresponding system properties.

A contract is in practice taken to be a constraint on a given aspect of the interaction between a component that supplies a service, and a component that consumes this service. Component contracts differ from object contracts in the sense that to supply a service, a component often explicitly requires some other service, with its own contract, from another component. So the expression of a contract on a component-provided interface might depend on another contract from one of the component-required interfaces. For instance, the throughput of a component A doing some kind of computation on a data stream provided by component B clearly depends on the throughput of B.

It is then natural that people resort to modelling to try to master this complexity [32]. Since models of software have the same nature as the thing they models, this opens the possibility to automatically derive software from its model. This was recently be made quite popular with an OMG initiative called the Model Driven Architecture (MDA). The aim of this work is to show how MDA can be used in relation with real-time and embedded component based software engineering [18]. Building on Model Driven Engineering techniques, we show how the very same contracts expressed in a UML model can be exploited for (1) validation of individual components, by automatically weaving contract monitoring code into the components; and (2) validation of a component assembly, including getting end-to-end QoS information inferred from individual component contracts, by automatic translation to a Constraint Logic Programming language.

In [32] we report on our experience with a model-driven architecture for distributed and embedded process-control based on the assembly of pre-defined components implemented for low-cost micro-controlers.

Model Composition and Weaving

Participants: Benoit Baudry, Franck Fleurey.

The aspect oriented modeling (AOM) approach provides mechanisms for separating crosscutting functionality from core functionality in design models. Crosscutting functionality is described by aspect models and the core application functionality is described by a primary model. The integrated system view is obtained by composing the primary and aspect models. In [39], we present a model composition technique that relies on signature matching: A model element is merged with another if their signatures match. A signature consists of some or all properties of an element as defined in the UML metamodel. The technique proposed in this paper is capable of detecting some conflicts that can arise during composition.

To implement the composition algorithm we have chosen to use our Kermeta language [34]. First, the language allows implementing composition by adding the algorithm in the body of the operations defined in the composition metamodel. Second, KerMeta tools are compatible with the Eclipse Modeling Framework (EMF) which allows us to use Eclipse tools to edit, store, and visualize models.

The apparent similarities between model composition and model transformations often lead to the following question: Is model composition a special type of model transformation? Answering this question can lead to useful insights that can be used to develop technologies that leverage the relationship between composition and transformation. In [25] we show that there are a number of ways to implement composition as transformations. We give an overview of these approaches in terms of their generality, ease of use, and ease of implementation. The insights gained from our initial analysis suggest that one can implement model composition as model transformations. This is important in that it indicates that research on model composition can leverage research on model transformations.

This work is done in collaboration with Robert France, Sudipto Ghosh and Raghu Reddy from Colorado State University (CSU). It was ignitiated during a visit from Benoit Baudry and Franck Fleurey to CSU. This visit was supported by INRIA and by the ARTIST network of excellence.

Weaving Behavioural Models

Participants: Jacques Klein, Jean-Marc Jézéquel, Noel Plouzeau.

Languages for aspect-oriented programming (AOP), such as AspectJ, are now popular, and the concepts used by the AOP community such as join points, pointcuts and advice are well-known. At the same time, in recent years, the aspect oriented software development (AOSD) approach has been developing itself beyond the programming activity. More particularly, the Early Aspects Initiative advocates the management of crosscutting properties, i.e. aspects, at the early development stages of requirements engineering and architecture design to identify the impact of aspects as soon as possible. Some composition operators of aspects exist for these development stages, but they do not closely match standard AOP concepts (pointcuts, advice...). In [29], we propose an automatic way for weaving behavioural aspects given as scenarios. With these kinds of behavioural modelling languages, aspect weaving cannot always be performed at the abstract syntax level. In [28], we present the problems relating to the design of a semantic based aspect weaver for Hierarchical Message Sequence Charts (HMSCs).

Timed-based contracts for components

Participants: Pierre-Alain Muller, Noël Plouzeau, Sébastien Saudrais.

In many application domains, contract-based specification for software components need to take time properties as well as other so called extra-functional properties (e.g. throughput, bandwidth consumption, etc).

[38] is a rigorous and automated approach for the behavioral validation of control software systems, based on metamodeling, model-transformations and process algebra. The work combines semi-formal object-oriented models with formal validation.

Triskell has also designed in the past three years a language for specifiying extra-functional properties on software components. This language allows the definition of extra-functional dependencies between required services and provided services.

Since the beginning of 2005, our team is working on a formal definition of this language. This formalization effort aims at supporting extra-functional property specification and verification through a complete chain of model transformation and validation that implements model driven engineering processes. The major difficulty to be tackled is the correct transformation of formal properties bound to the successive software models generated during the model transformation. The target platforms are real-time runtimes and frameworks such as the Giotto runtime model. The work also aims at maximing the compatibility with existing tool chain items from external partners.

This work is done in cooperation with the Jacquard project team at LIFL and with partners of the Artist2 network of excellence.