Modelling frameworks

MDE frameworks historically emerged from computer-aided software engineering (CASE) tools developed in the 80s. Since then, they evolved into full MDE ecosystems. This section gives an overview about two concrete open source modelling frameworks, 1) the Eclipse Modeling Framework (EMF) and 2) the Kevoree Modeling Framework (KMF). EMF is presented, since it is considered as the de facto standard for mod- elling frameworks. On the other hand, KMF is discussed because it was specifically developed to support the [email protected] paradigm. For this reason, the concepts presented in this dissertation have been implemented and integrated into KMF.

2.2.5.1 The Eclipse Modeling Framework

The Eclipse Modeling Framework (EMF) [294] is a de facto modelling standard and part of the Eclipse ecosystem [29]. On its project website1 _{it is described as “a mod-}

elling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XML meta- data interchange (XMI), EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.” EMF allows different ways to define models, e.g., annotated Java, UML, XML, or graphical/textual modelling tools. The specified models can then be imported into EMF. It provides the foundations for interoperability with other EMF-based applications and tools of the Eclipse ecosystem. EMF consists of three main building blocks:

• EMF.Core: The framework core contains the meta model (Ecore) for describing models. The core also includes runtime support for models (change notifications, persistence support with XMI serialisation) and a reflective application program- ming interface (API) for manipulating EMF objects.

• EMF.Edit: The EMF.Edit framework contains reusable classes (e.g., content and label provider classes, a command framework) for building editors for EMF models.

• EMF.Codgen: The code generation facility provides support to build a com- plete editor for EMF models. It also contains a UI to specify generation op- tions and which generators should be invoked. EMF.Codgen supports three level of code generation: model (Java interfaces and implementation classes for the model classes, factory and package implementation class), adapters (implementa- tion classes that adapt the model classes for editing and displaying), and editors (a basic generated editor, which can be further customised).

Ecore is the meta model at the base of EMF. It enables to define domain models. Ecore is its own meta model, i.e., it is defined with itself. Despite some differences, EMOF and Ecore concepts are very similar. EMF can be considered as a “tuned Java

implementation” of most of EMOF. Over the years, EMF has been used to implement a large number of tools and evolved into a widely used modelling framework.

However, EMF has been mainly developed with design time models in mind and less with runtime models. This leads to some significant shortcomings and limitations when used in the context of [email protected]. Therefore, with the Kevoree Model- ing Framework, an alternative to EMF has been developed, specifically to meet the [email protected] requirements.

2.2.5.2 The Kevoree Modeling Framework

The Kevoree Modeling Framework (KMF) [147], [151] is an alternative to EMF. Like EMF, KMF is a modelling framework and code generation toolset for building object- oriented applications based on structured data models. However, while EMF was primarily designed to support design-time models, KMF is specifically designed to support the [email protected] paradigm and targets runtime models. While the basic concepts remain similar, runtime models—especially runtime models of complex cyber- physical systems—usually have higher requirements regarding memory usage, runtime performance, and thread safety. Therefore, EMF faces some limitations in supporting the [email protected] paradigm, which KMF tries to address [147]. More specifically, Fouquet [147] et al., state the following requirements of [email protected], which have initially lead to the development of KMF:

• Reduced memory footprint: the more efficient a modelling framework (its runtime) is, the more devices are capable of running it. This is especially impor- tant for [email protected], which for example are used in the context of CPSs and must run on comparatively limited devices.

• Dependencies: the size of needed dependencies should be fairly small, since all dependencies need to be deployed on every device using [email protected]. The tight coupling and integration of EMF into the Eclipse IDE comes with the price of comparable large dependencies.

• Thread safety: [email protected] are often used in distributed and concurrent environments. This can lead to concurrent modifications of runtime models and must be efficiently supported by a [email protected] runtime.

• Efficient model (un)marshalling and cloning: For verification or reasoning purposes, runtime models need to be cloned locally on a device in order to reason on an independent representation. In addition, runtime models often need to be communicated to other computational nodes (in distributed systems, like smart grids), thus an efficient [email protected] infrastructure must provide efficient model cloning and (un)marshalling.

• Connecting [email protected] to classical design tools: an efficient run- time model infrastructure should provide transparent compatibility with design environments. Therefore, the Kevoree Modeling framework comes with plugins for intelliJ for a seamless integration into an integrated development environment (IDE).

KMF promotes the use of models not only for code generation or architectural man- agement but also during runtime as a central artefact. Therefore, KMF was from the ground up developed with strict performance and memory requirements in mind. It provides its own (textual) modelling language. The semantic of this language is close to Ecore, however it is not compatible. We use KMF to integrate the concepts intro- duced in this dissertation. Besides the fact that KMF has been designed specifically for [email protected], we decided to use KMF as base for our approach rather than, for example, EMF for several additional reasons. First, we found that KMF is a more lightweight framework, making fundamental changes on the core, e.g., to implement asynchronous calls for read and write operations, easier. Secondly, KMF is more suit- able to process large datasets, i.e., has lower memory requirements [147]. Thirdly, KMF can be easily extended with different storage concepts, e.g., key-value stores. This is especially important for our approach, since the large amount of data, which needs to be analysed in the context of CPSs and IoT, usually does not fit completely in memory. Instead, data must be efficiently loaded from external storage to memory and vice versa. Last but not least, KMF is the main modelling framework inside our research group at the SnT.