Final Report Summary - COMING (Component-based design meets model-driven engineering methodologies: improving the development of embedded systems)
The COMING project proposal aimed at the improvement of current component-based software engineering (CBSE) techniques by exploiting model-driven engineering (MDE) methodologies. CBSE is a software development technique largely used in relevant industrial applicative domains, notably aerospace, automotive, control, railway, and telecommunication. It promotes the reuse of existing (and already verified and validated) software units to enhance quality attributes of the final system while at the same time reducing the development time. However, reuse of software components is not always straightforward, since both functionalities and quality attributes of their composition could be very difficult to predict, especially when they would be provided by third parties or inherited by other projects without a thorough documentation of component properties.
The COMING project proposal defined three main goals:
1. definition of appropriate languages for a multiview approach to component-based software modelling for embedded systems;
2. specification of model transformations for translating component models toward appropriate domains to enable corresponding analysis;
3. realisation of adequate model-driven mechanisms supporting embedded systems evolution.
The definition of the languages in task 1 is based on the concept of component model, that is the means to describe reusable units on which, by embracing a CBSE approach, the software development is based. A component model should provide enough information for evaluating reuse opportunities of a certain software component in a system development scenario, both in terms of functionalities and quality attributes. On the other hand, it should not be too domain-specific, otherwise the set of assumptions on which the component relies can prevent its suitability evaluation in other contexts. In COMING it is adopted a cross-domain component model based on a structural definition and the notions of container and connector. In particular, the structural characteristic of the component is purely functional, and hence can be considered as generic (or domain-independent); then, in order to allow domain-specific evaluations / exploitations of the component, especially in terms of quality attributes, a container and connectors are specified. The former acts as a wrapper for the component and takes in charge the satisfaction of properties the component has to satisfy. Practically, it exposes a component's required and provided interfaces by mediating the access to / from other components as well as the platform. Connectors are devoted to the interaction between components and enable the separation of functional characteristics pertaining to single components from the attributes related to their composition.
A proof of concept of such solution has been implemented in close collaboration with a European project (the CHESS project, ARTEMIS JU Grant Agreement No. 216682). In that project one of the main goals was to develop a cross-domain language to design component-based industrial-sized embedded systems. The solution demonstrated its efficacy, enabling a shared modelling approach for both aerospace, automotive, railway, and telecommunications domain. Moreover, model-to-text transformations generate implementation code for a selected target platform. In the context of COMING, a generator has been realised able to produce 100 % implementation code for the telecommunication domain. It is important to stress the fact that in order to fully profit of embracing an MDE approach it is critical to consider the generated code as read only and never fine-tuned by hand. Such statement justifies part of the work presented later on in this report.
One of the main purposes of the language in task 1 is to provide enough details to be used for analysis of particular system properties, notably performances, dependability, security, and so forth (goal 2)). The adopted component model lends itself to annotation mechanisms that is functional definition, container, and connectors can be decorated with tags enabling the input of additional information related to quality attributes. Subsequently, starting from an annotated model it is possible to extrapolate the information pertaining to a certain property analysis approach, give it as input to a selected analysis method, and hence get outcomes on the current properties the system under development enjoys. In some design contexts, the explicit modelling of multiple quality attributes and their interactions can be also exploited to derive trade-offs between the properties owned by the resulting system. Notably, performances have to be mediated with energy consumptions as well as memory budgets have to be balanced against security needs. In COMING, it is proposed a modelling approach to explicitly define the interplay between disparate quality attributes of the system, their priority levels with respect to the purpose of the system, and also a formula to calculate the 'level of satisfaction' provided with the current overall property values.
Goal 3 resulted in the investigation of system evolution from different perspectives, as the management of changing deployment contexts and impacts on existing system properties, and the monitoring activities on the running system to survey its behaviour characteristics and report resulting data back to the modelling level (as corresponding language annotations). At this point, it is of paramount importance to notice that analysis feedbacks (as the ones calculated in goal 2)) can be automatically annotated back to the models, otherwise they would have to be manually updated by developers, resulting in a time-consuming and error-prone task. Such issue becomes even more relevant when getting feedbacks from monitoring of system executions. In fact, some quality attributes cannot be predicted in a sharp way until the system is deployed and executed on a particular platform, hence execution monitors are exploited to record those property measures at runtime. As a consequence, it emerges the need to trace back execution values at design level, and it would be hard (if not impossible) to do that without any automated aid. In this respect, by adhering to a proper MDE approach, extrapolation of annotation information to be inputted to analysis tools and the subsequent mapping of resulting feedbacks back to the models can be taken in charge by model transformations. In a similar way, monitoring results can be traced back to the appropriate design entities. Such a task is called back-propagation and is exploited to map back results coming from both static analyses and monitoring measurements. Thanks to the adopted component model and to traceability features provided by model transformations, the back-propagation is simplified through the shift of the focus only on the particular aspect taken into consideration, hence dependability, or performance (just to mention a few).
To summarise the results of the project, COMING demonstrates that by adopting a rigorous MDE approach it is possible to transfer several benefits of such vision, notably reduction of complexity through abstraction and early system analysis, in the development of embedded systems by means of CBSE techniques. Moreover, MDE methods aid developers in evolutionary contexts. A very interesting follow-up of COMING would be to investigate the reverse direction that is trying to integrate CBSE methodologies into the MDE vision. Such trial would trigger a reflection upon the abstract concept of component from a modelling point of view, as well as the concept of reusable unit, and therefore bring in the MDE field novel research topics.
COMING proposal not only has drawn goals from a technical perspective, but also a path for the personal career development of the participant. In this respect, the researcher has been involved as main lecturer in both an advanced course on MDE, delivered to Doctor of Philosophy (PhD) students, and in a Master level course. Moreover, he is assistant supervisor of three PhD students and drives several Master's thesis on related subjects. Transfers of knowledge and integration activities manifested in multiple project proposals, both for European and national funding. In particular, the researcher has been involved in multidisciplinary scenarios as energy awareness, outsourcing of components, and distributed databases. By the end of the project, the researcher became a senior lecturer at the host institution.
The COMING project proposal defined three main goals:
1. definition of appropriate languages for a multiview approach to component-based software modelling for embedded systems;
2. specification of model transformations for translating component models toward appropriate domains to enable corresponding analysis;
3. realisation of adequate model-driven mechanisms supporting embedded systems evolution.
The definition of the languages in task 1 is based on the concept of component model, that is the means to describe reusable units on which, by embracing a CBSE approach, the software development is based. A component model should provide enough information for evaluating reuse opportunities of a certain software component in a system development scenario, both in terms of functionalities and quality attributes. On the other hand, it should not be too domain-specific, otherwise the set of assumptions on which the component relies can prevent its suitability evaluation in other contexts. In COMING it is adopted a cross-domain component model based on a structural definition and the notions of container and connector. In particular, the structural characteristic of the component is purely functional, and hence can be considered as generic (or domain-independent); then, in order to allow domain-specific evaluations / exploitations of the component, especially in terms of quality attributes, a container and connectors are specified. The former acts as a wrapper for the component and takes in charge the satisfaction of properties the component has to satisfy. Practically, it exposes a component's required and provided interfaces by mediating the access to / from other components as well as the platform. Connectors are devoted to the interaction between components and enable the separation of functional characteristics pertaining to single components from the attributes related to their composition.
A proof of concept of such solution has been implemented in close collaboration with a European project (the CHESS project, ARTEMIS JU Grant Agreement No. 216682). In that project one of the main goals was to develop a cross-domain language to design component-based industrial-sized embedded systems. The solution demonstrated its efficacy, enabling a shared modelling approach for both aerospace, automotive, railway, and telecommunications domain. Moreover, model-to-text transformations generate implementation code for a selected target platform. In the context of COMING, a generator has been realised able to produce 100 % implementation code for the telecommunication domain. It is important to stress the fact that in order to fully profit of embracing an MDE approach it is critical to consider the generated code as read only and never fine-tuned by hand. Such statement justifies part of the work presented later on in this report.
One of the main purposes of the language in task 1 is to provide enough details to be used for analysis of particular system properties, notably performances, dependability, security, and so forth (goal 2)). The adopted component model lends itself to annotation mechanisms that is functional definition, container, and connectors can be decorated with tags enabling the input of additional information related to quality attributes. Subsequently, starting from an annotated model it is possible to extrapolate the information pertaining to a certain property analysis approach, give it as input to a selected analysis method, and hence get outcomes on the current properties the system under development enjoys. In some design contexts, the explicit modelling of multiple quality attributes and their interactions can be also exploited to derive trade-offs between the properties owned by the resulting system. Notably, performances have to be mediated with energy consumptions as well as memory budgets have to be balanced against security needs. In COMING, it is proposed a modelling approach to explicitly define the interplay between disparate quality attributes of the system, their priority levels with respect to the purpose of the system, and also a formula to calculate the 'level of satisfaction' provided with the current overall property values.
Goal 3 resulted in the investigation of system evolution from different perspectives, as the management of changing deployment contexts and impacts on existing system properties, and the monitoring activities on the running system to survey its behaviour characteristics and report resulting data back to the modelling level (as corresponding language annotations). At this point, it is of paramount importance to notice that analysis feedbacks (as the ones calculated in goal 2)) can be automatically annotated back to the models, otherwise they would have to be manually updated by developers, resulting in a time-consuming and error-prone task. Such issue becomes even more relevant when getting feedbacks from monitoring of system executions. In fact, some quality attributes cannot be predicted in a sharp way until the system is deployed and executed on a particular platform, hence execution monitors are exploited to record those property measures at runtime. As a consequence, it emerges the need to trace back execution values at design level, and it would be hard (if not impossible) to do that without any automated aid. In this respect, by adhering to a proper MDE approach, extrapolation of annotation information to be inputted to analysis tools and the subsequent mapping of resulting feedbacks back to the models can be taken in charge by model transformations. In a similar way, monitoring results can be traced back to the appropriate design entities. Such a task is called back-propagation and is exploited to map back results coming from both static analyses and monitoring measurements. Thanks to the adopted component model and to traceability features provided by model transformations, the back-propagation is simplified through the shift of the focus only on the particular aspect taken into consideration, hence dependability, or performance (just to mention a few).
To summarise the results of the project, COMING demonstrates that by adopting a rigorous MDE approach it is possible to transfer several benefits of such vision, notably reduction of complexity through abstraction and early system analysis, in the development of embedded systems by means of CBSE techniques. Moreover, MDE methods aid developers in evolutionary contexts. A very interesting follow-up of COMING would be to investigate the reverse direction that is trying to integrate CBSE methodologies into the MDE vision. Such trial would trigger a reflection upon the abstract concept of component from a modelling point of view, as well as the concept of reusable unit, and therefore bring in the MDE field novel research topics.
COMING proposal not only has drawn goals from a technical perspective, but also a path for the personal career development of the participant. In this respect, the researcher has been involved as main lecturer in both an advanced course on MDE, delivered to Doctor of Philosophy (PhD) students, and in a Master level course. Moreover, he is assistant supervisor of three PhD students and drives several Master's thesis on related subjects. Transfers of knowledge and integration activities manifested in multiple project proposals, both for European and national funding. In particular, the researcher has been involved in multidisciplinary scenarios as energy awareness, outsourcing of components, and distributed databases. By the end of the project, the researcher became a senior lecturer at the host institution.