D4.5: Model & Traceability Management Methodology and … · 2020. 1. 30. · This deliverable D4.5...

D4.5: Model & Traceability Management Methodology and Guidelines

MILESTONE: 31/01/2020 (M34)

STATUS: FINAL

COORDINATOR: UOC

CONTRIBUTORS: SOFT, ARM, UAQ, UOC, INT, UCAN

REVIEWERS: SICS, ATOS

DISSEMINATION LEVEL: PUBLIC

HANDLE: HTTP://HDL.HANDLE.NET/20.500.12004/1/P/MMART2/D4.5

LAST EDITED: 30/01/2020

http://hdl.handle.net/20.500.12004/1/P/MMART2/D4.5








Executive summary

The overall objective of MegaM@Rt2 WP4 is to provide traceability and tool-supported techniques and methods for model management. To do so, WP4 partners have designed a generic Model & Traceability Management Methodology aiming to efficiently define forward and backward traceability support between design and runtime artifacts. This methodology supports model extraction from existing artifacts, model storage in efficient databases, as well as the definition of model views materializing traces between modeling layers.

This deliverable D4.5 specifies the final version of the MegaM@Rt2 Model & Traceability Management Methodology, and complements D4.4 by showing how the features of each solution from the WP4 toolset are articulated to contribute to the proposed methodology. This deliverable focuses on an end-user point of view, and thus details the process to follow to work with the different tools.

of 57

Table of Contents

Table of Contents 3

Acronyms 6

Introduction 8

Model & Traceability Management Methodology 9

Model & Traceability Management Toolset 11 NeoEMF 11

Process description 11

Usage guidelines 13

Creating a New EMF Project 13

Creating a Simple Ecore Model 14

Creating an Ecore File and an EMF Generator Model 14

Migrate the Generator Model 15

Generating the EMF Model Code 16

Creating a New NeoEMF resource 17

Populating the resource 18

Reading the resource 18

EMF Views 18


Usage guidelines 22

Creating a view manually 22

Creating a view with the ViewPoint Description Language (VPDL) 29

Creating a VPDL file in Eclipse 29

Using a VPDL file in Eclipse 30

Querying a view with OCL 31

Transforming a view (to produce another model or generate code) 32

Modelio 35


Usage guidelines 36

Volvo Use Case 37

SysML Modelling 37

Variability Design 37

Workbench/Expertise usage 38

Constellation 39


Usage guidelines 42

PADRE 43


of 57

Usage guidelines 45

JTL 48


Usage guidelines 50

JTL for bidirectional transformations 50

JTL for traceability 52

S3D 53

Process Description 53

Generic components 53

Library-based modeling 54

Hierarchy 54

Functional 54

Execution platform 55

Model of Computation flexibility 55

Usage guidelines 56

Conclusions 56

References 57

of 57

Acronyms

ADL Architecture Description Language AL Architectural Language API Application Programming Interface APL Apache Public License ATL Atlas Transformation Language BMM Business Motivation Model BPMN Business Process Model and Notation BVR Better Variability Result CBSE Component-Based Software Engineering CPS Cyber-physical Systems CSR Case Study Requirement CTS Conceptual Tool Set DDS Data Distribution Service DoDAF U.S. Department of Defense Architecture Framework

DSE Design Space Exploration

DSL Domain-Specific Language DSML Domain-Specific Modelling Language EMF Eclipse Modeling Framework EPL Eclipse Public License FOSS Free Open Source Software GPL GNU Public License GUI Graphical User Interface HPV Hypervisor HW Hardware IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers INCOSE International Council on Systems Engineering ISO International Organization for Standardisation LGPL Lesser GNU Public License M2C Model To Code M2M Model To Model M2T Model To Text MARTE Modeling and Analysis of Real-Time Embedded Systems MAST Modeling and Analysis Suite for Real-Time Applications MBD Model-Based Development MBSE Model-Based System Engineering MBT Model-Based Testing MDE Model Driven Engineering MDSD Model Driven Software Development MDT Eclipse Modeling Development Tools

of 57

MFR MMRT Framework Requirement ML Modelling Language MODAF British Ministry of Defence Architecture Framework NFP Non Functional Property OCL Object Constraint Language OCRA Othello Contracts Refinement Analysis OMG Object Management Group OS Operating System PDM Platform Description Model PIM Platform Independent Model PSM Platform Specific Model RTES Real-Time Embedded Systems S3D Single Source System Design SOA Service-Oriented Architecture SUT System Under Test SW Software SysML System Modelling Language TCP Tool Component Purpose TP Tool/Method Provider TS-MM MegaModelling Tool Set TS-RT RunTime Tool Set TS-SE System Engineering Tool Set TSC Tool Set Component UC Use Case UCP Use Case Provider UML Unified Modeling Language UTP UML Test Profile UPDM Unified Profile for DoDAF/MODAF V&V Verification and Validation W3C World Wide Web Consortium WCET Worst Case Execution Time XAL XtratuM Abstraction Layer XMI XML Metadata Interchange XML eXtensible Markup Language

of 57

1. Introduction

This deliverable covers the final version of the MegaM@Rt2 Model & Traceability Management Methodology. It complements the Model & Traceability Management toolset described in D4.4 by presenting the designed methodology to support global model and traceability management tasks in the context of the MegaM@Rt2 use cases.

The main challenge addressed by the proposed methodology is the definition of efficient

forward and backward traceability support between design time and runtime artifacts. The goal of this multi-level traceability support is to precisely match runtime behavior with the original system design, in order to better capture, analyze, and understand critical situations that may occur, as well as revealing potential failures in design. While methods and tools already exist to capture runtime behavior and measure execution performance, they typically do not support advanced traceability back to design models.

In the following, we present an overview of the MegaM@Rt2 Model & Traceability

Management Methodology (Section 2), and we detail how each tool contributes to this generic approach (Section 3). Section 4 concludes this document by summarizing the key points and drawing conclusions.

of 57

2. Model & Traceability Management Methodology

The MegaM@Rt2 project focuses on offering a scalable model-based framework incorporating methods and tools for the continuous design, development and runtime support of complex software-intensive Cyber Physical Systems. In particular, the project intends to provide a scalable (mega)modelling approach to manage all the involved artifacts, including the multitude of different types of models, corresponding modeling workflows and configurations (among others). In this context, an important challenge is to better tackle the large diversity of the involved models in terms of nature, number, size, and complexity.

WP4, and corresponding Model and Traceability Management (MTM) tool set, deals more specifically with the design and development of generic methods and tools for supporting global model and traceability management tasks in our context of complex Cyber Physical System engineering processes. To this end, a fundamental challenge notably resides in providing efficient forward and backward traceability support between the two main system levels: i.e. design time and runtime. Indeed, the system behavior at runtime has to be better matched with the original system design, in order to be able to understand critical situations that may occur, as well as corresponding potential failures in design. Methods and tools already exist (many of them not model-based) for monitoring system execution and performing measurements of runtime properties. However, they do not usually allow a relevant integration with (and/or traceability back to) design models.

Figure 2-1: A methodology for Runtime ↔ Design Time Model and Traceability Management in WP4.

Thus, in this document, the focus is set on creating and effectively supporting feedback loops between runtime and design time, which is the most suitable level for system engineers to analyze and take impactful decisions accordingly. To realize this, Figure 2-1 provides an overview of the general methodology that we developed and proposed in WP4. As the main role of Model & Traceability

of 57

Management (WP4) is to make the glue between design time and runtime, the activities in WP4 are naturally based on data resulting from system design (WP2) and runtime analysis (WP3).

● In case these WP2/WP3 artifacts are not directly available as models, a first Model Discovery step is required in order to inject the content of input system specifications, runtime logs, etc. into corresponding Design model(s) and runtime / Log model(s). This initial step can be simply ignored when the artifacts coming from WP2/WP3 are already exploitable models.

● Then, a second step consists in performing the Inter-model Traceability Computation between these different models. To this end, Traceability Rules must be manually specified first in order to express how the Design model(s) and runtime / Log model(s) can be interrelated accordingly. Then, the result of the actual application of these rules on the concerned models is contained in a Traceability model.

● After that second step, the Design model(s), runtime / Log model(s) and Traceability model are taken as inputs for Model View Building and Handling. This third step requires in addition a manually defined Viewpoint / View Specification describing how to appropriately combine the concerned metamodels / models inside a corresponding viewpoint / view (respectively).

● As a result of this third step, a Design-Runtime View is produced and provided to the target system engineer or architect for further View Navigation and Querying. It is on this resulting view (and based on the viewpoint it conforms to) that the engineer or architect will be able to reason on and analyse the gathered design time ↔ runtime traceability information.

● In parallel to the previously described items, it is important to notice that all the models involved at the different steps of the process can be both stored and retrieved in a scalable way thanks to the available Model Storage facilities. Depending on the actual needs (from the user and her/his use case), various Storage Strategies can be considered in order to customize the Model Repository and the way it is parameterized.

In the context of research efforts from MegaM@Rt2, we already worked on providing practical illustrations of this approach based on several tools from the Model & Traceability Management Toolset (cf. Section 3 for more details on each individual tool). Note that such an instantiation of our methodology has already been applied (at least partially) in two different scenarios from the MegaM@Rt2 project:

● A generic runtime-to-design time traceability scenario extracted from commonalities found in several use cases requirements coming from various use case providers [1].

● A more specific scenario coming from the CLEARSY use case and dealing with design-runtime interactions in the context of the development of a safety critical system for one of their customers [2].

In the general case, we can claim that all the steps of the process can be possibly covered by at least one tool from the Model & Traceability Management Toolset (cf. Section 3), and sometimes by multiple ones. In the Eclipse ecosystem, MegaM@Rt2 tools such as JTL and PADRE can be used to deal with Inter-model Traceability Computation while EMF Views can be used for Model View Handling. In parallel of these tools, NeoEMF can be used for supporting scalable Model Storage. In the Modelio ecosystem, Modelio itself can be considered to deal with both Inter-model Traceability Computation and Model View Handling while scalable Model Storage can be supported by Constellation.

of 57

3. Model & Traceability Management Toolset

3.1. NeoEMF

NeoEMF [3], as introduced in D4.1 [4], is a model persistence framework that aims to manage large models efficiently by using task-specific data-stores. The framework is designed to be transparent to client applications by providing a sound integration in the EMF environment, complemented by an advanced API allowing to benefit from the advanced capabilities of specific data-stores.

3.1.1. Process description

NeoEMF is based on the sound modeling ecosystem provided by the Eclipse Modeling Framework [5]. It reuses existing technologies and languages to define metamodels, generate code, access and manipulate models, while providing some scalability improvements transparently.

At design-time (see figure 3-1-1), modelers define their Ecore metamodels using an existing Ecore modeling tool (e.g. Emfatic , xcore , or the standard Ecore editor provided by EMF). They also define a 1 2

Generator model, that is used to specify how code should be generated from the Ecore metamodel. NeoEMF requires specific settings in this Generator model to work properly. These settings can be automatically set using the NeoEMF Generator Model Migrator (see next section for further details).

The produced NeoEMF Generator Model is then sent (along with the initial EMF Metamodel) to the standard EMF Code Generator, that takes care of producing the Java classes allowing to create, manipulate, and query the model at runtime.

Figure 3-1-1: Working with NeoEMF at design time

1 https://www.eclipse.org/emfatic/ 2 https://wiki.eclipse.org/Xcore

of 57

https://www.eclipse.org/emfatic/

https://wiki.eclipse.org/Xcore

Client application can use the generated code to manipulate their EMF resource and benefit from NeoEMF performances and scalability. Note that the produced Java code is fully compliant with the EMF API. This means that, from a client application point of view, the code used to access NeoEMF models is the same as the one used to access EMF resources. Making NeoEMF easily pluggable in existing software. Modeling activities covered by NeoEMF includes

- Creating model elements and storing them in NeoEMF. NeoEMF will transparently map model-level information into database records, allowing to build very large models with reasonable execution time.

- Loading an existing NeoEMF resource (i.e. database) and accessing it has a plain EMF model. NeoEMF automatically creates the appropriate wrappers to access the database as a model.

- Benefit from the NeoEMF advanced API to further enhance performances while manipulating 3

very large models. This API allows to finely customize NeoEMF internal caches, apply prefetching techniques [6], and translate model-level queries into native database queries.

These different processes are backed up by three different database implementations, each one optimized for a specific modeling scenario:

- NeoEMF/Map has been designed to provide fast access to atomic operations, such as accessing a single element/attribute and navigating a single reference. This implementation is optimized for EMF API-based accesses, which typically generate this kind of atomic and fragmented calls on the model. NEOEMF/MAP embeds a key-value store, which maintains a set of in-memory/on disk maps to speed up model element accesses. The benchmarks performed in previous work [7] shows that NEOEMF/MAP is the most suitable solution to improve performance and scalability of EMF API-based tools that need to access very large models on a single machine.

- NeoEMF/Graph persists models in an embedded graph database that represents model elements as vertices, attributes as vertex properties, and references as edges. Metamodel elements are also persisted as vertices in the graph, and are linked to their instances through the instance of relationship. Using graphs to store models allows NEOEMF to benefit from the rich traversal features that graph databases usually provide, such as fast shortest-path computation, or efficient processing of complex navigation paths. For instance, these advanced query capabilities have been used to develop the Mogwaï tool [8], that maps OCL expressions to graph navigation traversals.

- NeoEMF/Column has been designed to enable the development of distributed MDE-based applications by relying on a distributed column-based datastore. In contrast with Map and Graph implementations, NeoEMF/Column offers concurrent read/write capabilities and guarantees ACID properties at model element level [9]. It exploits the wide availability of distributed clusters in order to distribute intensive read/write workloads across datanodes.

3 Note that NeoEMF advanced API does not conform to the standard EMF API.

of 57

3.1.2. Usage guidelines

NeoEMF requires an Ecore metamodel and some configuration steps to enable scalable modeling and support for large EMF models. In the following, we illustrate how to create a persistent EMF resource using a Neo4j database as a backend . To do so, we define an Ecore metamodel, create instances of 4

this model and then store these instances in the persistent EMF resource.

In the following we assume that you have NeoEMF installed in your Eclipse environment. We also use Emfatic to create metamodels, but note that NeoEMF also supports the regular Ecore editor, as well as xcore.

Creating a New EMF Project

Now create a new EMF project by choosing File → New → Project… from the main menu. The dialog offers a couple of different project types. Select Empty EMF Project from the category Eclipse Modeling Framework and continue via Next.

Figure 3-1-2: Creating a EMF Project for NeoEMF

4 Here we illustrate how to create a NeoEMF model stored in Neo4j, see https://github.com/atlanmod/NeoEMF/wiki/Supported-Backends for more information on the other supported backends.

of 57

https://github.com/atlanmod/NeoEMF/wiki/Supported-Backends

Creating a Simple Ecore Model

To create and save an EMF resource, you first need an ECore Model. There are several ways to create an Ecore Model, here we use EMFatic, a textual syntax for ECore models.

From the main menu, choose File→ New → Other… and select Emfatic file from the category Example EMF Creation Wizard. Name your file "graph.emf".

Edit your file to create a simple model specifying a simple graph structure, containing Edges and Vertices, and described below:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

@namespace(uri=”http://atlanmod.neoemf.tutorial”, prefix=”graph”) package graph;

class Graph { val Vertice[*] vertices; val Edge[*] edges; } class Vertice { attr String label; } class Edge { ref Vertice from; ref Vertice to; }

Creating an Ecore File and an EMF Generator Model

Once the Emfatic file is ready, you need to generate a .ecore file. From the contextual menu (right-click on the graph.emf file), choose Generate Ecore Model.

Figure 3-1-3: Generate Ecore Model from Emfatic Definition

Now create a new EMF Generator Model by choosing File → New → Other… from the main menu. The dialog offers a couple of different wizards. Select EMF Generator Model from the category Eclipse Modeling Framework and continue via Next.

of 57

http://atlanmod.neoemf.tutorial/

Figure 3-1-4: Creating a Generator Model

Migrate the Generator Model After generating the graph.genmodel file, you need to migrate it to NeoEMF. From the contextual menu, choose NeoEMF → Migrate EMF Generator Model.

Figure 3-1-5: Migrating an EMF Generator Model to NeoEMF

of 57

The migration will modify several properties in the graph.genmodel file. Basically, it will set the root Class and the root Interface of EMF Classes and Interfaces to use the NeoEMF persistent implementations.

Figure 3-1-6: Summary of the migrated features in the NeoEMF generator model

Generating the EMF Model Code After generating the graph.genmodel file, you will be able to generate the Java underlying code for this model. Select Generate Model Code from the Project Explorer contextual menu (right-click the graph.genmodel file)

Figure 3-1-7: Generating code from NeoEMF Generator Model

of 57

The generation will add three new packages to your project. If you are familiar with the EMF generated code, you can browse the generated code to observe the differences between the default generated code and the NeoEMF one.

Figure 3-1-8: Structure of the Generated Artifacts

Creating a New NeoEMF resource Once the Ecore model is ready, we can create instances of this model and store them in a NeoEMF persistent resource. Creating a resource in NeoEMF is similar to standard EMF. Write down the following line to create a resource named "models/myGraph.graphdb" in your current Eclipse project.

Note: the following example concerns a Blueprints (graph-based) backend. Because all backends work in the same way, you can replace BlueprintsTinkerConfig and BlueprintsUri by the module-specific implementations of Config and UriBuilder related to the backend you want to use.

1 2 3 4 5 6 7

URI uri = new BlueprintsUriFactory().createLocalUri("models/myGraph.graphdb"); ResourceSet resourceSet = new ResourceSetImpl(); Resource resource = resourceSet .createResource(uri); ImmutableConfig config = new BlueprintsTinkerConfig();

of 57

Populating the resource

Now, write a simple code to create instances of the Graph model and to save the resource:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GraphFactory factory = GraphFactory.eINSTANCE; Graph graph = factory.createGraph(); for (int i = 0; i < 100; i++) { Vertice v1 = factory.createVertice(); v1.setLabel("Vertice " + i + "a"); Vertice v2 = factory.createVertice(); v2.setLabel("Vertice " + i + "b"); Edge e = factory.createEdge(); e.setFrom(v1); e.setTo(v2); graph.getEdges().add(e); graph.getVertices().add(v1); graph.getVertices().add(v2); } resource.getContents().add(graph); resource.save(config.asMap()); resource.unload();

Reading the resource

You can use the following code to load a resource and read its content:

1 2 3 4 5 6 7 8 9

resource.load(config.asMap()); Graph graph = (Graph) resource.getContents().get(0); for (Edge each : graph.getEdges()) { System.out.println(each.getFrom().getLabel() + "--->" + each.getTo().getLabel()); } resource.unload();

3.2. EMF Views EMF Views is an Eclipse/EMF-based framework that aims at facilitating the creation and handling of viewpoints / views on top of possibly heterogeneous metamodels / models (respectively). Thus, it directly addresses the activity Model View Building and Handling from the overall methodology

of 57

depicted in Section 2 / Figure 2-1. The EMF Views framework implements in the Eclipse ecosystem the generic model view approach that is described in what follows.


EMF Views is based on a model virtualization approach that is deployed similarly at both metamodel- and model-levels. Thus, views are actually virtual models that act transparently as regular models via proxies to these interrelated models, but do not duplicate any of the already available data. Each view conforms to a particular viewpoint, which has been previously specified from one or several corresponding metamodels (interconnected together) as a virtual metamodel. Interestingly, the fact that both viewpoints and views are actually virtual (meta)models behaving as normal (meta)models allows for easier viewpoint / view handling and reuse. An overview of the proposed approach is shown on Figure 3-2-1.

Figure 3-2-1: Overview of the EMF Views model view approach.

At design time, designers may specify a new viewpoint by choosing the concerned metamodel(s), listing the relations she/he wants to represent between them (as well as indicating how to eventually compute them at view-level, see hereafter), and identifying the concepts and properties to be selected. This required information is directly collected from the designer/architect, either manually or by using a DSL (cf. next Subsection 3.2.2 for a concrete example of that). This input data is stored in a weaving model that is then used by the virtualization mechanism to obtain the actual viewpoint. Therefore, the original metamodel(s) are not modified or polluted by the viewpoint definition. This results in a virtual metamodel, representing the viewpoint, that aggregates several different metamodels according to the given specification.

Similar to the select-project-join operations in relational algebra, the viewpoint definition mostly specifies what types/attributes from the contributing metamodels should be part of (or, conversely, filtered out from) the view (projection), what conditions model elements will need to satisfy in order to

of 57

appear as a result in the view query (selection) and how the elements from different models should be linked when computing the actual view (join).

Figure 3-2-2: Viewpoint creation at design time.

Figure 3-2-2 gives more insights on the inner behavior of EMF Views at the design-time level. As introduced earlier, the designer or architect can use one of the provided DSLs to specify the viewpoint. From the collected information, our approach can produce (by means of model-to-model or model-to-text transformations) three different artifacts:

● A Viewpoint file that lists general information about the viewpoint, i.e. contributing metamodel(s), weaving model, matching file.

● A Weaving model that contains the links between the connected elements from different metamodels, links to filtered elements, etc.

● A Matching file that expresses the matching rules to be applied at view-level in order to compute inter-model links

Both these Viewpoint file and Weaving model (in addition to the contributing metamodels, of course) are actually used as inputs for the virtualization mechanism to create the (virtual) metamodel representing the defined viewpoint.

At runtime (cf. Figure 3-2-3), once the viewpoint is specified, the user can work on querying and handling views that conform to it. To obtain such a view, she/he can choose the set of input models to be used as input data for the view (and that conform to their respective metamodels, themselves used to create the given viewpoint). With those models and the input viewpoint, the proposed approach can build up the corresponding view. As described before, the view is represented as a virtual model. In order to create the view, new links have to be established between the underlying models. These links are computed and initialized from the rules expressing the combination of the corresponding metamodels at the viewpoint-level (though a manual modification by the user is also possible when needed) by means of a matching engine (provided with the Epsilon Comparison Language in the current implementation of EMF Views). The links are stored in a separate weaving model associated with the view, without altering the original models.

of 57

Figure 3-2-3: View initialization at runtime.

Figure 3-2-3 gives more insights on the inner behavior of EMF Views at the runtime-level. As introduced earlier, the user or engineer has to list the contributing models to be used to produce the view according to the chosen viewpoint. These models have to conform to the contributing metamodels of the viewpoint. From this information, our approach can produce two different artifacts:

● A View file that lists general information about the view, i.e. contributing models, weaving model, viewpoint definition (i.e. Viewpoint file).

● A Weaving model that contains the actual links between the connected elements from different models, the links to filtered elements, etc.

The weaving model can be initialized automatically using a matching engine that reads the viewpoint definition and uses the content of the referenced Matching file to decide how to join the elements in the different models. In this case, it may exist only in memory and may not be serialized as an actual file. However, this weaving model may also be completed manually or via other tools if needed (e.g. from the execution of a model transformation). Both the View file and the Weaving model (in addition to the contributing models of course) are used as inputs for the virtualization mechanism to produce the resulting view as a virtual model.

An important aspect of our approach is that a common virtualization technique has been adapted to be used at both design time and runtime. Another fundamental aspect is the use of weaving models in order to create and store the viewpoint/view-specific information. Thus, our approach relies on a common and generic virtualization (weaving) metamodel we propose. Further details on these two aspects of our EMF Views framework and the underlying conceptual approach can be found in the Chapter 4 of a PhD thesis written and defended in the context of MegaM@Rt2 [10].

From a usability perspective, it is needed to provide proper interfaces for designers/users of our solution. As a consequence, we contribute in two DSLs covering two different applications of model views (as well as two corresponding subsets of our core virtualization metamodel). Concrete examples of the usage of one of these two DSLs are provided next Subsection 3.2.2.

Finally, from a scalability perspective, it is required to be able to load, store and access to all the involved metamodels and models (i.e. contributing ones, weaving ones) in an efficient way. As a result of a long-term research work performed in the context of MegaM@Rt2 [1], we propose to realize this

of 57

by integrating the use of existing model persistence solutions such as notably NeoEMF (as part of the same MegaM@Rt2 toolbox than EMF Views, and also described in this deliverable in Subsection 3.1).


Views and viewpoints can be created interactively inside the Eclipse workbench or can be created programmatically using the dedicated API provided by EMF Views. In the following paragraphs, we present how to create such views and viewpoints interactively using two different ways offered by EMF Views.

Creating a view manually

We will create a view linking two related models representing books. In order to create a view, you need the following:

1. Metamodels. These can be given as Ecore files, or through the namespace URI if the packages are loaded as plugins.

2. Models. These can be given in any serialization format supported by EMF (usually XMI). 3. A viewpoint. This defines the metamodel of the view. It is specified through an eviewpoint

file. 4. An eview file which describes the view.

First, unpack the emfviews-tutorial example. Here is what the file hierarchy should look like: 5

├── metamodels │ ├── Book.ecore │ └── Publication.ecore ├── models │ ├── book.xmi │ └── publication.xmi ├── viewpoints │ ├── publicationsAndBooks.eviewpoint │ └── publicationsAndBooks.xmi └── views ├── allChapters.ecl ├── allChapters.eview ├── firstChapter.ecl └── firstChapter.eview

This is one common way to organize views that are created using files, but it is not mandatory to follow this structure.

The metamodels folder contains the Ecore files for our two metamodels, Book and Publication.

5 You can download this example on https://github.com/atlanmod/emfviews/tree/master/examples/emfviews-tutorial

of 57

https://github.com/atlanmod/emfviews/tree/master/examples/emfviews-tutorial

Figure 3-2-4: Excerpt of the Ecore Metamodel

The Book metamodel has details about each chapter, while the Publication has more information about the publisher and publishing date. This is a simple example of two metamodels with overlapping and complementary information. The view we will create will bring all this information under a single (virtual) metamodel.

The models folder contains two serialized models in XMI format that conform to these metamodels. Here are the contents of book.xmi (left) and publication.xmi (right):

Figure 3-2-5: Excerpt of the Ecore Model

They both model the same book. In this example, there is only one element for simplicity. In realistic situation, each model may contain several books or publications. Our view will work the same with any number of elements.

To define the view, we must first define a viewpoint, which acts as a (virtual) metamodel for the view. Let us look at the file hierarchy again:

├── viewpoints │ ├── publicationsAndBooks.eviewpoint │ └── publicationsAndBooks.xmi

of 57

The viewpoints folder contains two files. Let us focus on the publicationsAndBooks.eviewpoint file which defines the viewpoint, and is defined as:

contributingMetamodels=publication::../metamodels/Publication.ecore,\ book::../metamodels/Book.ecore

weavingModel=publicationsAndBooks.xmi

The first two lines list the contributing metamodels. These are the two metamodels we are concerned with. In this case, we give relative URIs to the Ecore files in the metamodels folder. The paths are prefixed by an alias which will be used to match metamodels to models in the eview file. The third line specifies the weaving model. The weaving model describes how the viewpoint is constructed: it contains filters that select or exclude elements from the contributing metamodels, and it describes new elements that are to be added to the viewpoint. If you omit the weavingModel property, no elements are filtered or added.

Let’s try it now. Remove or comment (# begins a line comment) the weavingModel line, then save the file. You have to open the viewpoint in text mode (Right click → Open With → Text Editor). After you have made the change, you want to open the eviewpoint file in a model editor. The Sample Ecore Model Editor and the MoDisco Model Browser should both be able to do so. Right click → Open

With → Other..., and in the dialog select Sample Ecore Model Editor then click OK:

Figure 3-2-6: Opening an eviewpoint in the Sample Ecore Model Editor

of 57

https://www.atlanmod.org/emfviews/manual/user.html#weaving-models

https://help.eclipse.org/oxygen/topic/org.eclipse.modisco.infrastructure.doc/mediawiki/model_browser/user.html

Here is what you should see:

Figure 3-2-7: Opened viewpoint in the Sample Ecore Model Editor

This metamodel combines, under the same viewpoint package, our two metamodels Publication and Book. This metamodel is purely virtual: the packages Publication and Book, and all their elements, are proxies to the actual elements from the contributing metamodels. Note that the Publication package comes before Book because that is the order we specified in the contributingMetamodels line in the eviewpoint file.

Let us restore the weavingModel line. First, close the Sample Ecore Model Editor view of the eviewpoint. Then, restore or uncomment the weavingModel line in the eviewpoint by opening it with the Text Editor (or reuse the Text Editor tab if you had not closed it). Save the eviewpoint file, and open it up with the Sample Ecore Model Editor once more. Here is what you should get now:

Figure 3-2-8: Updated viewpoint in the Sample Ecore Model Editor

of 57

There are two differences with the previous viewpoint: there is a new bookChapters association in the Publication class, and the Chapter.nbPages attribute has been filtered out. The bookChapters association enhances the Publication metamodel by allowing us to navigate the chapters from a Publication instance. A Publication in this viewpoint would have all the information of the Book instance, and more.

Note that the Chapter class is part of the Book package (it comes from the Book metamodel), but it is the target class of an association of the Publication package. Combining both metamodels in the viewpoint allows us to create inter-metamodel associations, since they are now part of the same virtual metamodel.

If we open the weaving model publicationsAndBooks.xmi with the Sample Ecore Model Editor, we can see that it contains exactly these two changes. Here is the viewpoint on the left with the weaving model on the right. The changes made by the weaving model to the viewpoint are highlighted:

Figure 3-2-9: Opened viewpoint and weaving model

Now that we have a viewpoint, all that is left is the view itself. Let us take another look at the file hierarchy:

└── views ├── allChapters.ecl ├── allChapters.eview ├── firstChapter.ecl └── firstChapter.eview

In the views folder, two views are defined: allChapters and firstChapter. Let us focus on allChapters for now. If we look inside allChapters.eview:

1 2 3 4

contributingModels=publication::../models/publication.xmi,\ book::../models/book.xmi viewpoint=../viewpoints/publicationsAndBooks.eviewpoint matchingModel=allChapters.ecl

of 57

The contributingModels line point to the model resources which contribute to the view. Note that the order of the contributing models does not have to match the order of the contributingMetamodels line in the eviewpoint file. Metamodels from the eviewpoint file are matched to models using the prefix alias: pub is the alias for the Publication metamodel, and using the same alias indicates that the publication.xmi model conforms to it. The alias is also used by ECL files, as seen below. The viewpoint line is a relative path to the eviewpoint file. In order to define a view, we need to give it a metamodel, which is a viewpoint.

Finally, the matchingModel line is a path to an Epsilon Comparison file. The matching model contains rules that are used by EMF Views to construct a weaving model for the view. Let us look at this ECL file now:

1 2 3 4 5 6 7 8 9 10

rule bookChapters match p : publication!Publication with c : book!Chapter { compare { return p.title = c.eContainer().title and p.author = c.eContainer().authorName; } }

It describes a rule to populate the virtual association bookChapters. It considers each publication p from the (concrete) Publication metamodel against each chapter of the (concrete) Book metamodel; in other words, a Cartesian product Publication × Book. For each pair (p,c), if the predicate in compare is true, then the matching elements are part of the association bookChapters.

Here, if we have a book and a publication that refer to the same book, then we want to add all chapters of the book to the association. Thus, the predicate checks that the title of the publication is the same as the book’s title, and that they both have the same author, since that is all the common information between the two metamodels.

Note that for our two particular models which describe the same book, the predicate will always return true. Hence, we could have written the rule trivially:

1 2 3 4 5 6

... compare { return true; } }

But the former version will work with models containing more books and publications. When we open the allChapters.eview file with the MoDisco Model Browser (Right click → Open With → Other..., and select MoDisco Model Browser then click OK), we can see that the bookChapters associations allows us to navigate the chapters from the Book model:

of 57

Figure 3-2-10: Opened eview in the MoDisco Model Browser

We also can see that the nbPages attribute is absent from the chapters, because it has been filtered out from the metamodel.

Now, we have defined a view that combines the Book and Publication models. But we can define multiple views for the same viewpoint. Take a look at firstChapter.eview:

1 2 3 4

contributingModels=publication::../models/publication.xmi,\ book::../models/book.xmi

viewpoint=../viewpoints/publicationsAndBooks.eviewpoint matchingModel=firstChapter.ecl

The only difference with allChapters.eview is the matching model. For this view, we want only the first chapter of a matching book to be added to the new bookChapters association. Consequently, in firstChapter.ecl, the predicate is:

1 2

return p.title = c.eContainer().title and c = c.eContainer().eContents().first();

The right-hand part of the condition only matches if the chapter c is the first one of the book it is part of.

As a result, when we open firstChapter.eview with the MoDisco Model Browser, only one chapter is part of the bookChapters association:

Figure 3-2-11: Filtered eview in the MoDisco Model Browser

of 57

And that’s it! We have created one viewpoint combining two metamodels, then we created two views combining two models using this viewpoint. Note that while this method of creating views with eviewpoint and eview files is suitable for creating small-scale views interactively, EMF Views offers two other methods to create views: programmatically and using VPDL.

Creating a view with the ViewPoint Description Language (VPDL)

Creating a VPDL file in Eclipse

VPDL, standing for ViewPoint Description Language, is a domain-specific language for easing the specification of viewpoints and the creation of the corresponding views using EMF Views. The syntax of VPDL is inspired by SQL’s SELECT statement.

Instead of manually creating eviewpoint and eview files, you write a single vpdl file which describes the viewpoint and the view at the same time. Here is a VPDL file recreating the firstChapter view of the previous subsection:

1 2 3 4 5 6 7 8 9 10 11 12 13

create view publicationsAndBooks as

select publication.Publication.*, publication.Publication join book.Chapter as firstChapter, book.Book.*, book.Chapter.title,

from 'http://publication' as publication, 'http://book' as book,

where s.title = t.eContainer().title and t = t.eContainer().eContents().first() for firstChapter

The first line create view specifies the name of the viewpoint. This name is used for generating the eviewpoint, eview and xmi weaving model file.

With the select clause, you explicitly select the classes and features from the contributing metamodels that will appear in the viewpoint. The select clause essentially specifies the viewpoint’s weaving model, albeit in plain text. Here with publication.Publication.* we say that we want all the features of the publication.Publication class in the viewpoint, and by selecting only book.Chapter.title from book.Chapter, we exclude the nbPages attribute. The select clause is a whitelist, so if we don’t include the book.Book.* line for instance, the resulting viewpoint would not let us navigate Book instances, since there would be no visible features.

The line:

1 publication.Publication join book.Chapter as firstChapter,

of 57

tells EMF Views to create a virtual association from Publication to Chapter called firstChapter. This is the same as the bookChapter association of the previous section. The from clause simply maps the namespace URIs of the contributing metamodels to the aliases used in the select clause. Lastly, the where clause specifies, for each new association, how to match elements from the contributing models in the view. This is used to generate the matching model as an ECL file. Here, we use the same predicate as before, but this time s and t refer respectively to the source (Publication) and target (Chapter) of the association.

Using a VPDL file in Eclipse

To use a VPDL file, your project needs to be configured as an Xtext project in Eclipse. If you create a new project and add a vpdl file in it, Eclipse should prompt you to configure it as an Xtext project. Otherwise in the outline, Right click on the project → Configure → Convert to Xtext project.

Once the project is configured, whenever you save the vpdl file Xtext should generate three files: the eviewpoint, the xmi weaving model, and the ecl matching model. If you unpack the vpdl-tutorial example, here is how the file hierarchy looks like after we save the publicationAndBooks.vpdl file: 6

. ├── src │ └── publicationsAndBooks.vpdl ├── src-gen │ ├── publicationsAndBooks.ecl │ ├── publicationsAndBooks.eviewpoint │ └── publicationsAndBooks.xmi └── views └── firstChapter.eview

All the generated files are in the src-gen directory. To create the view, however, we still need an eview file. VPDL does not create one for a view. You just have to point to the generated files, and specify the contributing models you want to use. Here is the definition of firstChapter.eview:

1 2 3 4 5 6

viewpoint=../src-gen/publicationsAndBooks.eviewpoint contributingModels=\ publication::../../emfviews-tutorial/models/publication.xmi,\ book::../../emfviews-tutorial/models/book.xmi matchingModel=../src-gen/publicationsAndBooks.ecl weavingModel=publicationAndBooks.xmi

6 You can download this example on https://github.com/atlanmod/emfviews/tree/master/examples/vpdl-tutorial

of 57

https://www.atlanmod.org/emfviews/manual/user.html#org6da6005

https://github.com/atlanmod/emfviews/tree/master/examples/vpdl-tutorial

Opening firstChapter.eview using the MoDisco Model Browser, we get the same result as before, the difference being that this time the new association is more accurately called firstChapter:

Figure 3-2-12: Filtered eview in the MoDisco Model Browser with association firstChapter

Querying a view with OCL

To query a view interactively, you can use the standard OCL console. Refer to the OCL documentation on how to bring up the OCL console. Once you have a console open, you can query a 7

view using OCL expressions:

Figure 3-2-13: Example of OCL Query on a view

In this figure, we see the allChapters.eview view opened in the MoDisco Model Browser, with the Xtext OCL console on the lower half. When the [Publication] ATL in Depth object is selected in

7 https://help.eclipse.org/oxygen/topic/org.eclipse.ocl.doc/help/InteractiveOCL.html

of 57

https://help.eclipse.org/oxygen/topic/org.eclipse.ocl.doc/help/InteractiveOCL.html

MoDisco, it becomes the context object (self) for the OCL console, as indicated by the text Xtext

OCL for 'Publication…'.

In the console, we can see the results of executing the OCL query:

1 self.bookChapters->collect(c | c.title)

which collects the titles of all the chapters in this publication in a set, using the bookChapters virtual association.

Transforming a view (to produce another model or generate code)

To create an HTML report from a view, we will use in this example the Epsilon Generation Language . 8

Note that, as views appear as regular EMF models to EMF-compatible tools, you can use a view as a regular input to any model-to-model or model-to-text transformation.

In the view-to-html-tutorial , you can find the following files: 9

. ├── metamodels │ ├── Book.ecore │ └── Publication.ecore ├── models │ ├── book.xmi │ └── publication.xmi ├── templates │ ├── publicationsAndBooks.egl │ └── publicationsAndBooks.launch ├── viewpoints │ ├── publicationsAndBooks.eviewpoint │ └── publicationsAndBooks.xmi └── views ├── allChapters.ecl └── allChapters.eview

These are the same files from the emfviews-tutorial, except there’s a new templates folder that contains an EGL file and a launch configuration. The EGL file is rather straightforward:

1 2 3 4 5 6 7 8 9 10 11

[% for (p in Publication.allInstances()) { %] [%=p.title%], [%=p.author%], [%=p.publisher%] ([%=p.year%]) Contents: <ol> [% for (c in p.bookChapters) { %] <li>[%=c.title%]</li> [% } %] </ol> [% } %]

8 https://www.eclipse.org/epsilon/doc/egl/ 9 You can download this example on https://github.com/atlanmod/emfviews/tree/master/examples/view-to-html-tutorial

of 57

https://www.eclipse.org/epsilon/doc/egl/

https://www.eclipse.org/epsilon/doc/egl/

https://github.com/atlanmod/emfviews/tree/master/examples/view-to-html-tutorial

This example goes through all publications in the view, and for each it lists all its attribute and all its chapters. To execute this template, we need a launch configuration. One is provided in the templates folder; you should be able to import it. Otherwise, you can create a new EGL Generator launch configuration, and configure it as follows:

Figure 3-2-14: EGL Generator launch configuration (template view)

Figure 3-2-15: EGL Generator launch configuration (models view)

of 57

The important part is to use the eview file as Model file, and the eviewpoint file as Metamodels. The configurator may add the namespace URI of the viewpoint in the Metamodels list when you add the eview file. You should remove it, and point to the eviewpoint file instead. Before we can run this configuration, we need to make a minor change to the eviewpoint file. We add the saveInRegistry option:

1 2 3 4

contributingMetamodels=publication::../metamodels/Publication.ecore,\ book::../metamodels/Book.ecore

weavingModel=publicationsAndBooks.xmi saveInRegistry

The reason this is necessary is because EGL will load the eview and eviewpoint resources separately, and we need the view to find the created viewpoint at runtime. When opening views in model editors, this option is not necessary since the view will take care of instantiating the viewpoint directly.

Once this is taken care of, we can finally execute the EGL template on our view. After a few seconds, the console should output the line:

1 Output generated to /view-to-html-tutorial/templates/out.html

The generated HTML should look like this:

1 2 3 4 5 6 7 8 9 10

 ATL in Depth, A. Tlanmod, Willy (2022) Contents: <ol>arst <li>Introduction to ATL</li> <li>An Example Transformation</li> <li>A Couple of Compilers</li> <li>ATL Harder</li> </ol> 

And if we open that file in a web browser, here is the result:

Figure 3-2-16: Generated HTML from the view

of 57

Generating an HTML page from a model can make for more pleasant reports. With the right amount of CSS and JavaScript, you can even have built interactive visualizations from your views. See the traceability-demo in the examples folder for a more involved usage of templates. 10 11

3.3. Modelio Modelio is a multipurpose tool which supports several metamodels (UML, SysML, MARTE, etc.) and specifications. Modelio offers many features and therefore suits many projects in various business contexts.

In the WP4 methodology, Modelio role, as depicted in Figure 3-3-1, consist in managing models. More specifically Modelio is able to define Views and ViewPoints (respectively named expertise and workbench in Modelio context) which will guide the modeller by hiding unnecessary concepts. So Modelio provides a configuration mechanism at the metamodel level (Viewpoint /View Specification ) to allows its users to get only the commands and features (Model View Building and Handling) that suit their business and context (Model Storage).

Figure 3-3-1: Modelio Role in Megamart WP4


This mechanism is based on the concepts of expertise and workbenches.

An expertise defines what the user can see and/or do under Modelio. An expertise impacts the GUI, the commands, and the deployed extensions:

● At GUI level, an expertise: ○ filters the elements displayed in the model browser ○ filters the links displayed in the links editor ○ adjusts the audit rules ○ organizes the views (perspectives)

10 You can download this example on https://github.com/atlanmod/emfviews/tree/master/examples/traceability-demo 11 https://github.com/atlanmod/emfviews/tree/master/examples

of 57

https://github.com/atlanmod/emfviews/tree/master/examples/traceability-demo

https://github.com/atlanmod/emfviews/tree/master/examples

● At commands level, an expertise ○ filters the context menu commands ○ filters the diagrams which creation is possible via the fast creation bar

● At extensions level, an expertise ○ activates the business-related modules ○ deactivates the modules which are not related to the business

A workbench gathers several expertises by assembling the display configurations, and expertise commands it supports.

The mechanism which assembles expertises in a workbench takes account of the order in which the expertises are declared in the workbench. This order is used to solve the situations in which several supported expertises are in conflict over a configuration. In such cases, the first expertise prevails. The order of expertises in a workbench is important.

AS depicted in Figure 3-3-1, the user can create, delete, and activate Modelio workbenches. For each existing workbench, the user can add, remove and modify the order of composing expertises.

Figure 3-3-2: Modelio Workbench Configuration


On one hand, workbenches are managed directly via dedicated Modelio preferences windows. On the other hand, expertises are defined by Modelio itself or by a specific extension such as the SysML 12

and Variability Designer . In the following, we illustrate Modelio's usage guidelines to achieve the 13

Model View Building and Handling WP4 activity through the example of the Volvo use case defined in the context of MegaM@Rt2.

12 http://forge.modelio.org/projects/sysml 13 http://forge.modelio.org/projects/variabilitydesigner

of 57

http://forge.modelio.org/projects/sysml

http://forge.modelio.org/projects/variabilitydesigner

Volvo Use Case

The actual Volvo construction base engine is developed by a technology provider within Volvo. The base engine is a bare bones engine system together with the engine software. It is then equipped with auxiliary equipment for each application. Examples of the auxiliary equipment are external engine sensors, oil pans, fuel tanks, mounting brackets, engine turbochargers and so on. The auxiliary equipment is developed by the Engine Department at Volvo CE for each application. The software then needs to be configured and calibrated for each application. This process is very time consuming especially when considering that each application of the engine uses many features shared with other applications as well. Sometimes these common features (related to auxiliary equipment) are changed without knowing, or even being aware of the consequences for other variants. Moreover, many times the work is being re-done to implement the same feature several times between different applications.

SysML Modelling

To represent this base engine and the related auxiliary equipments, Volvo, in Megamart context, made some SysML modelling as depicted in the following Figure 3-3-2

Figure 3-3-3: SysML Modeling Example from the Volvo Use Case

Variability Design

Then to represent the possible variant, Variation point has been added to the SysML modelling.

of 57

Figure 3-3-4: Variation points in SysML Modeling

Workbench/Expertise usage

Once both SysML and Variability modelling are available, the user can switch from the SysML view (cf following figure 3-3-4) to dedicated Variability perspective where only SysML Elements with attached Variability information are shown (cf. following figure 3-3-5).

of 57

Figure 3-3-4: Complete SysML model

Figure 3-3-5: SysML model with related Bosh or Albonair Variant

3.4. Constellation Version 3 of Modelio introduced the concept of model fragments, and projects made up of these fragments. By composing the same set of model fragments in different ways, it became possible to

of 57

give each and every participant in the organization the exact project view which corresponds to his/her activities. The organization is highly decentralized, which allows the most open and agile cooperation modes.

When the number of fragments, users, roles, projects and their combinations increases, Constellation provides support for their daily management and more generally to their governance management. This is where the main Constellation functionality comes in: organizing and managing collaborative projects, both with regard to the content of these projects and to the management of the teams and individuals who work on them (rights, viewpoints on the project, and so on.) as depicted in the following figure.

Figure 3-4-1: Constellation role in Megamart WP4 methodology


A user is a person who will interact with a Constellation solution. However, this basic definition covers many different situations that will be made clearer below.

Figure 3-4-2: Overview of the Modelio/Constellation Ecosystem

of 57

Modelio users are users working with Modelio Modeler. From Modelio, they mainly open, modify and close projects. To become a Modelio user, a user must be enrolled in at least one project. The enrollment of people in a project grants them the right to join and work on the project.

Constellation administrators are users working with the Constellation administration tool, i.e. Constellation’s administration Web pages. These pages are used to configure projects, add users or fragments, and so on.

A Constellation administrator may have only limited access to the Constellation administration pages, depending on his/her attributed administration role.

For now, just remember that a user becomes a Constellation administrator by being assigned to an administration role, and that this role defines which administration operations he/she is allowed to carry out. Of course, a person can be a Modelio user or a Constellation administrator or both.

In Constellation, a user has to be enrolled in a project to be allowed to work on it. All users are not equal when working on a project, and what can be done by a given user on a given project is defined by the user’s rights on the project. Setting the individual rights of each user on a project can become tedious when there are a lot users on a project, especially when we consider that most of them will be granted the same rights. In fact, the rights of a user depend more on his/her function and responsibilities in the project than on the user himself/herself.

Constellation deals with these constraints by providing the concept of profile.

A profile:

● Defines which one of the project fragments will be visible to the users attached to the profile. This allows, for example, a “test model” fragment to be hidden from users who are not involved in development or testing.

● Defines a pattern for the values of the users' rights. This means that each user enrolled under this profile will have his/her rights set to those of the profile.

● Defines the FAS (Fragment Authentication Strategy) which is to be used for each visible fragment of the project.

Users enrolled in a project must always be attached to a profile. Therefore, when a project is created in Constellation, a special profile named default is automatically created and added to the project. Each user enrolled in the project will be attached to the default profile of the project (unless otherwise specified). Also note that a user can be attached to only one profile in a given project.

The following rules apply to the default profile:

● It cannot be deleted (however it can be edited) ● Each time a fragment is added to a project (and unless otherwise specified):

○ it is made visible in the default profile ○ it has read & write rights in the default profile ○ its FAS is set to Project Authentication Mode

It sets the users’ rights and fragment authentication strategy to predefined values. The predefined values of the ‘default’ profile are as follows:

of 57

● Users can see all project fragments ● The rights are read + write on each fragment (where relevant) ● The fragment authentication strategy is set to project authentication mode.


The following figure shows an example where profiles are used to organize the contributors to a project into several categories depending on their responsibilities in the project.

Figure 3-4-3: Example of Project Organization with Profiles and Responsibilities In the above figure, a project is made up of several model fragments.

Three profiles have been defined for the project: Analysts, Developers and Testers.

The project members (Modelio users) have been dispatched in the three profiles: one analyst, four developers and two testers.

The Requirements fragment is an analysis of the project’s requirements and goals. This fragment has been made visible to the three profiles, but only the Analyst profile grants modification (write) rights. This means that only the Analysts will be allowed to change the requirements of the project. However, the requirements are available to the Developers and Testers, in order that they may carry out their work according to the project requirements.

The Design and Implementation fragments are accessible by the Developers. The Analysts can still have a look at the design, probably for review purposes, but do not have the right to modify it.

of 57

The Tester fragment mainly holds testing material (examples, tools, programs, and so on). Only the users from the Testers profile can modify this fragment, in this example, it seems that the Analysts and Developers are not at all interested in tests, as this fragment has not been made visible to them…

This simple example shows that profiles greatly simplify the management of user rights, while keeping all the required refinements where needed.

3.5. PADRE PADRE is an Eclipse-based framework that enables, in a unique environment, the performance antipatterns detection on UML-MARTE software models (PADRE-010) [11] and the refactoring of the latter based on detection results. PADRE is applied in WP4 methodology as a transverse solution to assess the quality of the models extracted during the Model Discovery phase, and improve the performance of Model View creation and manipulation.


Figure 3-5-1 illustrates a typical Software Performance Engineering (SPE) process based on UML, in which we have plugged the Performance Antipattern Detection and Model Refactoring Framework (PADRE).

Figure 3-5-1: A typical Software Performance Engineering (SPE) process based on UML

Usually, a software model does not contain performance attributes and/or indices. However, consolidated techniques exist in the literature for transforming software models into performance models, estimating performance attributes like demand vectors and workload, and obtaining indices like throughput and response time from performance model solution. This is the goal of the Performance-oriented Model Integration component in Figure 3-5-1, namely to get performance indices and set the tagged values of the MARTE stereotypes that we assume as their containers in the UML model, thus obtaining a Performance-oriented Software Model. The latter is then given as input to our EPSILON-based Performance Antipattern Detection & Model Refactoring Framework, which includes three engines based on different EPSILON languages (i.e., EVL, EPL, and EWL) [12]. Each engine accomplishes the task of: (i) detecting bad design practices that degrade application performance (i.e. performance antipatterns), by verifying codified detection rules, and (ii) removing such bad design by applying codified refactoring actions. Although none of

of 57

EPSILON languages was conceived for addressing performance-driven model refactoring, we have identified different kinds of model refactoring support that they can provide due to their different execution semantics, as summarized in the following. Batch refactoring sessions: EPL allows to execute sequentially a set of antipattern detection rules and refactoring actions (see Figure 3-5-2). The process can be repeated once (i.e., standard mode) or until no more antipattern occurrences are found (i.e, iterative mode).

Figure 3-5-2: An information dialog in PADRE

User-driven multiple refactoring sessions: EVL allows to execute interactive antipattern detection and refactoring sessions (see Figure 3-5-3). In fact, after the list of detected antipattern occurrences in the performance-oriented software model is presented to the user, the EVL engine enables a number of available refactoring actions (i.e. fixes) as applicable. Each refactoring is applied to a current temporary version of the software model and, when the user stops the session, the current version is finalized and represents the session output.

Figure 3-5-3: A snapshot of the interactive antipattern detection and refactoring session

User-driven single refactoring sessions: Based on EWL, as an element is selected in the modeling environment, antipattern occurrences are immediately detected with respect to the selected element type (see Figure 3-5-3). Then, the EWL engine enables the antipattern solutions, among which the user can select the one to apply to the software model, thus producing a refactored model, which represents the session output. A subsequent element selection would trigger a new refactoring session. Due to the strong need for graphical support, these types of sessions are directly integrated with Eclipse-based Graphical Modeling Frameworks, e.g. Papyrus [14].

of 57

Figure 3-5-3: EWL output


PADRE’s architecture is illustrated in Figure 3-5-4, which basically shows the main actors that it involves, together with its workflow.

Figure 3-5-4: PADRE framework architecture

The framework is centered on three performance antipatterns detection and solution engines that provide different interactive support to the designer, and that are respectively based on EPL, EVL, and EWL. The designer selects the engine to use in order to perform refactoring sessions starting from an initial software model, i.e. M0, which conforms to UML+MARTE metamodel and is given as input to the

of 57

selected engine. During a refactoring session, a number of new refactored models, i.e., M1,..,Mn-1, can be created until a software model that satisfies the performance requirements is obtained, i.e. Mn. PADRE deals with UML models made out of the following diagrams: a Component Diagram that describes the software components and their Interfaces/Operations; a Deployment Diagram that describes the allocation of artifacts, corresponding to components, on platform nodes; a Use Case Diagram that describes the actors and the use cases that they can execute; a number of Sequence Diagrams, one for each use case, that describe the system behavior in terms of interactions among components. Hence, each model Mi in Figure 3-5-4 is required to be a UML model, as specified above, annotated with MARTE stereotypes and tags that represent the information needed to execute the Performance-oriented Model Integration, which is made up of: (i) the performance parameters required to generate and solve a performance model, and (ii) the performance indices required by the antipattern detection and refactoring, that are filled in with the outputs of the performance model solution. A performance expert has to build the basic knowledge KUML+MARTE, which is the UML+MARTE representation of performance antipatterns detection rules and refactoring actions that can be applied to remove them. Such knowledge is then used to produce detection and refactoring code in one of the considered EPSILON languages. A fragment of the UML software model is depicted in Figure 3-5-5, in which the Component Diagram depicts an excerpt of the static view of the application and their interconnections; the Deployment Diagram depicts the deployment view of the system, ie., the hardware nodes and how the application artifacts are allocated on them. Finally the Sequence Diagram depicts a considered scenario in the performance analysis. More detailed guidelines can be found in the PADRE github repository . 14

14 https://git.io/SeaLabAQ-padre

of 57

https://github.com/SEALABQualityGroup/padre/blob/master/README.md

Figure 3-5-5: A fragment of the UML software model

of 57

3.6. JTL JTL is an Eclipse EMF -based tool, realized to design and manipulate models, maintain consistency 15

and synchronize software artifacts, and keep traceability during design. Its constraint-based and relational model transformation engine is specifically tailored to support bidirectionality, change propagation and traceability. JTL is able to support languages based on EMF Ecore and it is integrated with other Eclipse-based modeling tools. This enables the tool to support both standard and domain specific modelling languages and profiles. The JTL bidirectional model transformation engine is able to guarantee compliance among the involved metamodels. Finally, the JTL bidirectional mechanism allows to provide the automatic generation of the performance analysis model from the UML/MARTE model and vice versa. The JTL framework has been implemented within the Eclipse EMF framework and has been realized as a set of plugins that constitute an Eclipse RCP. The role of JTL in the WP4 methodology is depicted in Figure 3-6-1. Specifically, the JTL traceability engine is able to relate design models with execution traces (Log model) by creating a traceability model by interpreting the Traceability Rules Specification. Such model contains links to elements in both design and log models.

Figure 3-6-1: Relation of JTL with the WP4 methodology The JTL traceability engine relies on the transformation mechanism for the generation of the traceability model. The JTL transformation mechanism provides relational semantics that relies on Answer Set Programming (ASP). Given a change to one source, JTL uses the DLV constraint solver 16

to find a consistent choice for the other source. JTL has been proposed for dealing with non-deterministic transformations, thus it allows to specify non-bijective correspondences between source and target models (both in terms of consistency relations and traceability links). Furthermore, more than one solution models can be generated as output of the bidirectional transformation according to the non-deterministic specification.

15 https://www.eclipse.org/modeling/emf/ 16 https://www.mat.unical.it/dlv-complex

of 57


The process underlying the generation of traceability information is outlined in Figure 3-6-2. Within JTL, the tracing information mechanism stores relevant details about the linkage between source and target model elements at execution-time (including the applied transformation rules). The traceability mechanism is an intrinsic characteristic of the ASP-based engine. Trace links are extrapolated during the transformation execution and made explicit by the framework. Thus, trace models are explicit and maintained as models that conform to the JTL Trace Metamodel, as defined in its Ecore format within EMF. Trace models can be stored, viewed and manipulated (if needed) from the designer. Within JTL, trace models are re-used during the transformation execution. In particular, trace model, can be given as input of the transformation in order to (re-) establish consistency, manage ambiguities and guarantee the correctness of the transformation.

Figure 3-6-2: Process underlying the generation of traceability information

When generating a traceability model, JTL requires as input:

● MMsource : a source metamodel in EMF format ● Msource : a source model in EMF format ● MMtarget : a target metamodel in EMF format ● Mtarget : a target model in EMF format ● Traceability Rules Specification: a specification of relations between metamodels, defined

using the JTL syntax within the JTL editor provided in Eclipse In this case, JTL will produce as a traceability model. The JTL traceability engine will generate a traceability model containing the links that relates the elements in Msource with the elements in Mtarget .

of 57


JTL for bidirectional transformations JTL can ben used to specify and execute bidirectional model transformations. These instructions are based on the Collapse/Expand State Diagrams benchmark . Starting from a hierarchical state 17

diagram (involving some one-level nesting), a flat view has to be provided. The hierarchical and non-hierarchical state machine metamodels (respectively 18

SimpleHierarchicalStateMachine and SimpleStateMachine) are given by means of their Ecore representation within the EMF-based framework. Starting from the definition of the involved metamodels, the JTL transformation is specified, as shown in Figure 3-6-3.

Figure 3-6-3: An example of JTL transformation defined between the SimpleHierarchicalStateMachine

and SimpleStateMachine metamodels The transformation can be easily executed from: Right-Click menu > Run as > Run Configurations. The user will be presented with the classic Run Configuration form, as shown in Figure 3-6-4.

17 http://bx-community.wikidot.com/examples:collapse-expandstatediagrams 18 https://github.com/MDEGroup/JTL/raw/master/downloads/StateMachineCaseStudy.zip

of 57

Figure 3-6-4: the JTL Run Configuration within Eclipse

The application of the transformation on HSM generates the corresponding SM model. Note that, by re-applying the transformation in the backward direction it is possible to obtain again the HSM source model. The missing sub-states and the transitions involving them are restored by means of trace information. Figure 3-6-5 shows both the HSM model and the SM model obtained from it by running the transformation in the forward direction.

of 57

Figure 3-6-5: the HSM (middle) and SM models (right)

JTL for traceability JTL has been successfully applied to the use case provided by ClearSy, concerning the log analysis of a safety-critical system. Specifically, JTL has been able to generate traceability information between logs models, B models (CSY_02 [14]), and design models (CSY_01 [14]). Such information has been represented as traceability models (in EMF) and provided to EMFViews to perform a log analysis (CSY_03 [14]). As an example of such application of JTL, Figure 3-6-6 shows models from the CSY use case: a log model on the left-hand side, a traceability model in the middle, and a model of a B specification on the right-hand side. The traceability model links elements from both sides using traceability links. Such links are generated by the JTL traceability engine using a correspondences specification.

of 57

Figure 3-6-6: A log model on the left-hand side, a traceability model in the middle, and a model of a B

specification on the right-hand side Examples, tutorials and further documentation can be found on the JTL website . 19

3.7. S3D S3D is a single-source modeling and design framework for Cyber-Physical System of Systems (CPSoS). As a consequence of the research and development activity of the University of Cantabria in T4.3, the scalability of the S3D modeling methodology has been significantly improved. In the next sections, the main improvements towards mega-modeling of complex, heterogeneous CPSoS are described. This piece of work is not directly related to the global model and traceability management addressed by WP4 as its main objective. Therefore, S3D has not any direct link to the conceptual framework in Figure 2-1, apart from the improvements in the scalability of models commented above. If S3D is included here is to describe the improvements achieved by UCAN in mega-modelling of complex, heterogeneous systems (of systems) addressed by task T4.3.

3.7.1. Process Description

3.7.1.1. Generic components

In order to improve reusability, S3D supports component-based modeling and design. Components are stored in libraries as generic components. Generic components are defined only by the services they provide and/or require. They lack ports, as they will be added when the Generic component is instantiated as an ‘Application Component’ inside a specific system, with the sole exception that a

19 http://jtl.univaq.it

of 57

component requires the same interface from N providers, where it is needed that these N ports are specified in the component. In MARTE, these elements are Structured Components. In their most abstract form, the only external information about such elements is the services (functions) they provide and/or require, as shown in Figure 3.7.1. Thus, the required interface of a structured component lists all the services that the component requires from other components or the environment. The provided interface lists all the services that the component offers to other components or the environment. The fact that the structured components do not specify which, and in what way the required/provided services are grouped in interfaces and exposed externally, maximizes the reusability of these components.

Figure 3-7-1 A generic, structured Component.

Each structured component will be linked to the file where its structured data and behavior is specified in the action language used, in our case, C++.

3.7.1.2. Library-based modeling

After generic components, a second step into facilitating reusability would be its integration in a reusable component library. A library is a UML model where generic, reusable components are defined. A component is modeled as a package. The package will contain all the relevant information about the component. The first element in the package is the component itself, stereotyped as a ‘RtUnit’ or a ‘PpUnit’. In addition, the minimum information to be provided is represented by the interface functions of the component and the data types used by them. In order to support simulation, performance analysis and synthesis, the files with the code in an appropriate action language are required. Component verification would require a specific package with the test cases in an appropriate language.

3.7.1.3. Hierarchy

Functional In order to approach a complex component, the main way to address its modeling is dividing it into smaller sub-components, which can be modeled independently. This procedure can be done recursively until the problem becomes simple enough to be afforded. Functional hierarchy is represented in S3D by hierarchical components, this is, subsystems. A subsystem is just a component. It includes other components inside and, therefore, a subsystem is a hierarchical component. In order to identify a component as a subsystem, the <<Subsystem>>

of 57

stereotype is used. A subsystem can be part of more complex subsystems. In this way, subsystems are essential to deal with the modeling of complex systems of systems (SoS). Nevertheless, independently of its internal architecture and functionality, a subsystem can be defined as a generic component without specific ports; just exhibiting the public required and provided services. In this way, again, the flexibility and thus, the reusability of the subsystem is maximized.

Execution platform Hardware hierarchy is supported in S3D in a similar approach as in Functional hierarchy, in a ‘top-down’ design from global network nodes to specific HW components. HW architecture of the system can be partitioned into Network Nodes (stereotyped as <<ComputingResource>>) which communicate between them via network links. Each node can contain other subnodes or directly its HW elements (processors, buses, memories…). Figure 3-7-2 shows two network nodes, and Figure 3-7-3 represents the internal HW architecture of the first node.

Figure 3-7-2 Network system diagram

Figure 3-7-3 HW description of a node

3.7.1.4. Model of Computation flexibility

Depending on the properties defining the services and the provided and the required ports, different programming models corresponding to different Models of Computation (MoC) can be supported.

● Function Call/RPC/RMI: Under the Function Call (FC) MoC, the calling thread is stopped until the required function call is attended and the output data read. Nevertheless, in order to avoid deadlocks, a timeout can be defined.

of 57

● Rendezvous (RV): This is the fundamental communication/synchronization pattern for the Communicating Sequential Processes (CSP) MoC. Rendezvous ensures that two active tasks synchronize and interchange data at the same time. After the rendezvous, both threads are free to continue execution.

● Data Flow (DF): In a DF system, components communicate through data. DF communication is asynchronous. Components may generate data and consume data at any time. This means that in the general case, a buffer is needed to store data when there are more data produced than consumed. When the buffers between components never gets full (infinite capacity), DF becomes a Khan Process Network (KPN). In real systems, buffers will have a finite size meaning that at certain points in time they may get full. In order to keep the properties of a KPN, the calling thread should stop.

● Discrete Event (DE), Time-Triggered (TT), Timed Data Flow (DTF): In DE systems, components react to events in their inputs. An event is an instantaneous indication to trigger a reaction. DE systems may be non-deterministic, producing different results depending on which component is executed first. In order to avoid non-determinism in DE systems, a global control component can be used.

In the TT MoC, the moment in which each component reads the inputs and the time in which it delivers the outputs are known in advance. In some cases, a clock is used in order to synchronize the input and output times of all the components.

Timed-Data Flow (DTF) MoC is basically a TT MoC in which the frequency of each component may by different depending on the input and output rates

● Synchronous Reactive (SR): In a SR system, the activity in the inputs, in our case, the calls for required functions, trigger the internal activity among components until the system reaches a stable state in which no further function calls are made.


S3D has been successfully applied to the Flight Management System (FMS) use case provided by Thales and a positioning system as an internal use-case. The modeling methodology and user’s guide are available at the S3D web page, ‘s3d.unican.es’.

Conclusions

In this deliverable, we presented the MegaM@Rt2 Model & Traceability Management Methodology, that aims to define efficient forward and backward traceability support between design time and runtime. We showed an overview of this methodology, and we detailed how the features of each contributing tool can be leveraged to contribute to it. Each of the presented tool include (1) a brief summary of the tool features as well as the problem(s) it aims to solve, (2) a process description emphasizing the internal logic of the tool to enable such features, and (3) usage guidelines detailing the necessary steps that need to be performed by a user to use the tool. This information complements the toolset description presented in previous deliverable with a user-oriented point of view that aims to ease and increase the adoption of MegaM@Rt2 technologies.

of 57

References

[1] Bruneliere, H., de Kerchove, F. M., Daniel, G., & Cabot, J. (2018, October). Towards Scalable Model Views on Heterogeneous Model Resources. In Proceedings of the 21th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (pp. 334-344). ACM.

[2] Eramo, R., de Kerchove, F. M., Colange, M., Tucci, M., Ouy, J., Bruneliere, H., & Ruscio, D. (2019). Model-driven design-runtime interaction in safety critical system development: an experience report.

[3] Daniel, G., Sunyé, G., Benelallam, A., Tisi, M., Vernageau, Y., Gómez, A., & Cabot, J. (2017). Neoemf: a multi-database model persistence framework for very large models. Science of Computer Programming, 149, 9-14.

[4] MEGAMART2-D4.1, MegaM@Rt2 project deliverable D4.1 - Foundation for Model Management and Traceability - Final Version. Published as a consortium internal document (2017)

[5] The Eclipse Foundation - The Eclipse Modeling Framework, online (https://www.eclipse.org/modeling/emf), accessed in 2020

[6] Daniel, G., Sunyé, G., & Cabot, J. (2016, October). Prefetchml: a framework for prefetching and caching models. In Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (pp. 318-328). ACM.

[7] Gómez, A., Tisi, M., Sunyé, G., & Cabot, J. (2015, April). Map-based transparent persistence for very large models. In International Conference on Fundamental Approaches to Software Engineering (pp. 19-34). Springer, Berlin, Heidelberg.

[8] Daniel, G., Sunyé, G., & Cabot, J. (2016, June). Mogwaï: a framework to handle complex queries on large models. In 2016 IEEE Tenth International Conference on Research Challenges in Information Science (RCIS) (pp. 1-12). IEEE.

[9] Gómez, A., Benelallam, A., & Tisi, M. (2015, July). Decentralized model persistence for distributed computing. In Proceedings of the BigMDE Workshop. CEUR

[10] Bruneliere, H. (2018). Generic Model-based Approaches for Software Reverse Engineering and Comprehension (Doctoral dissertation).

[11] MEGAMART2-D4.2, MegaM@Rt2 project deliverable D4.2 - Specification of the MegaM@Rt2 Model & Traceability Management Tool Set - Final Version. Published as a consortium internal document (2018)

[12] Epsilon Lab - Epsilon Object Language, online (https://www.eclipse.org/epsilon/doc/eol/), accessed in January 2020

[13] The Eclipse Foundation - Eclipse Papyrus, online (https://www.eclipse.org/papyrus), accessed in January 2020

[14] MEGAMART2-D4.1, MegaM@Rt2 project deliverable D4.1 - Industry requirements specification - Final Version. Published as a consortium internal document (2017)

of 57

https://www.eclipse.org/modeling/emf

https://www.eclipse.org/epsilon/doc/eol/

https://www.eclipse.org/papyrus/

D4.5: Model & Traceability Management Methodology and … · 2020. 1. 30. · This deliverable D4.5...

Documents

Transcript of D4.5: Model & Traceability Management Methodology and … · 2020. 1. 30. · This deliverable D4.5...