FESAS Design Tool

Besides implementing the functional logics of the MAPE components, the SAS has to be designed. The FESAS Design Tool supports the system designers who specify which (sub)systems host which parts of the managed resources and/or the adaptation logic. Additionally, the system designer specifies the functional logic that the components load. Further, the system designer uses the FESAS De- sign Tool to describe the connections between the components, such as which sensor retrieves data from which managed resources or from which monitor an analyzer receives information. This allows the implementation of distribution patterns, such as the ones from [401].

7.1. Implementation of the FESAS IDE

The FESAS Design Tool is an Eclipse plug-in that supports model-driven development for designing the system. It provides a graphical editor in which the system designer specifies the configuration of the adaptation logic. Further, the plug-in is complemented with a generator for JSON files representing the information specified in the editor. These files are used in the system deployment process to configure the SAS. The FESAS Design Tool is based on the Eclipse Modeling Framework (EMF)6_{, the Graphical Modeling Framework (GMF)}7_{, and}

the Acceleo8 _{code generator. Figure 7.4 depicts the creation of configuration files}

using the FESAS Design Tool. Next, this section presents the implementation of the editor using EMF and GMF and the JSON file generation with Acceleo.

Acceleo

Metamodel / PIM

System Model / PSM

JSON Files

EMF/

GMF

Figure 7.4.: Process of JSON configuration file generation with EMF / GMF and Acceleo.

EMF and GMF are Eclipse plug-ins. As other model-driven development

approaches, EMF specifies a Platform Independent Model (PIM) and a Platform Specific Model (PSM). The PIM represents the metamodel and is implemented as an Ecore model with EMF. It is based on the FESAS Adaptation Logic Template presented in Section 6.1.1. Elements of the metamodel represent the MAPE components with their properties, including the contracts for functional logics

that have to be loaded at runtime. The meta elements of the PIM are the

elements that describe the SAS, i.e., the MAPE components. The EMF generator model generates code based on the PIM and, hence, act as Decorator [137].

The PIM’s elements are the base for the implementation of PSMs. A PSM

specifies the components of a specific adaptation logic, its configuration, and the connections between the components. For each SAS, a PSM is generated using the Ecore model. Having the EMF files only, a developer would have to write the

6 _{EMF’s website: https://eclipse.org/modeling/emf/} 7 _{GMF’s website: http://www.eclipse.org/modeling/gmp/} 8 _{Acceleo’s website: http://www.acceleo.org/pages/welcome/en}

7.1. Implementation of the FESAS IDE

PSMs manually by writing XML files complying to the EMF syntax. For a more convenient use of the plug-in, we implemented a GMF-based graphical editor.

GMF supports the development of graphical editors for all types of models and purposes. The GMF runtime engine combines different components: Graphical Definition, Tooling Definition, Mapping Definition, and GenModel. The GMF Graphical Definition describes the different elements, the editor should be able to draw (e.g., a box for representing a monitor component). Further, it describes their lookalike on the diagram canvas. The GMF Tooling Definition defines the tools, e.g., for each component that the user should create on the diagram canvas, a tool has to be specified. The tools are shown in the so called palette. The GMF Mapping Definition maps the tools and their graphical definition with the EMF Ecore model. This enables an automatic creation of an element in the PSM, once an element is added to the diagram canvas. Further, the system designer can only use the elements of the palette. The structural correctness of the model is guar- anteed as EMF/GMF permits to use the elements of the palette only as specified in the metamodel, e.g., it prohibits to connect a monitor directly to a planner component. The GMF GenModel combines all these information in a definition of the editor and generates an Eclipse plug-in that represents the editor’s function- ality. GMF offers functionalities to generate all of the required components out of an Ecore model. Accordingly, for implementation of the FESAS Design Tool, we first needed to define the PIM as Ecore model. With GMF we than automat- ically generated all components for the editor and adjusted them slightly, e.g., delete elements that should not be drawable or change the colors and symbols for elements in the editor. The logic of the editor and storing of the content of the diagram canvas to the model file is offered by GMF out of the box.

System designers can drag and drop elements from the palette into the can- vas (e.g., an analyzer component), specify the functional logic of these elements, and add connections (e.g., to a planner or another analyzer). Connections be- tween components are represented by arrows in the canvas and by elements in the palette. Further, arrows between device and managed element as well as adaptation logic groups indicate which physical device deploys which adapta- tion logic elements and which parts of the managed resources. Figure 7.5 shows the diagram canvas with a subset of the SmartHighway system. The system fol- lows the fully decentralized pattern as each section is managed by a dedicated

7.1. Implementation of the FESAS IDE

Figure 7.5.: Diagram canvas with an exemplified SAS. The left side shows the ed- itor. There, a subset of the SmartHighway system showing elements of one section is specified. The right side shows the palette with the available elements for system design.

part of the adaptation logic with full MAPE functionality. Further, the designer defines the connection between managed resources – e.g., traffic cameras and traffic signs – and the adaptation logic using the plug-in.

For further convenience, it is possible to choose a distribution pattern. The plug-in offers a fully centralized pattern, a fully decentralized pattern – i.e., the adaptation logic is separated into several subsystems that all have full MAPE functionality, however, no connection between each other –, and the decentral- ization patterns from [401]. This functionality is a custom implementation and does not extend the EMF/GMF functionalities. As a first experiment for the vision of having a self-* IDE, we implemented a mechanism that can choose a suitable pattern depending on system properties, such as scalability, responsive- ness, and local vs. global optimization. We added this mechanism as additional functionality of the FESAS Design Tool. However, as this is in preliminary stage, that function is excluded from further investigation in this thesis.

7.1. Implementation of the FESAS IDE

1 [template public generateComm(aDiagram :DiagramElement)]

2 [file ((’config_Comm.json’), false, ’UTF-8’)]

3 {

4 "COMM_ADAPTATIONLOGIC": [’[’/]

5 [for (anAdaptationLogic:AdaptationLogicElement | aDiagram. diagramAdaptationLogicConn)]

6 [for (sensor: SensorElement | anAdaptationLogic.sensorALConn)] 7 [for (sen_mon: SensorMonitorComm | sensor.mon_sen)]

8 [for (aLogic: ALLogicElement | sensor.AL_LOGIC)]

9 { 10 "COMM_ELEMENT": { 11 "COMM_TYPE": "[sen_mon.COMM_TYPE/]", 12 "COMM_RECEIVER": "[sen_mon.RECEIVER.AL_ID/]", 13 "COMM_SENDER": "[sen_mon.SENDER.AL_ID/]", 14 "COMM_INFO_TYPE": "[sen_mon.COMM_INFO_TYPE/]", 15 "COMM_INFO_CATEGORY": "[sen_mon.COMM_INFO_CATEGORY/]" 16 } 17 }, 18 [/for] 19 [/for] 20 [/for] 21 ... // code removed 22 } 23 [/file] 24 25 [/template]

Listing 7.2: Excerpt of an Acceleo template showing the template that is filled with the data collected in the editor for the connections between the MAPE components.

Once the system is designed in the editor, the next step is the creation of configuration files. For that, the plug-in uses the functionality of the open source code generator Acceleo. Acceleo enables the transformation of EMF models to various formats, such as HTML, XML, or JSON. Acceleo uses the EMF-based PSM and templates of the JSON files as input for the configuration file genera- tion. The templates are composed of static JSON data and wildcards. During file generation, the Acceleo generator replaces the wildcards with the values of the PSM represented by the model specified in the editor. Listing 7.2 shows an excerpt of such an Acceleo template. For each device, Acceleo creates one JSON

7.1. Implementation of the FESAS IDE

file with the information about the components as well as one file with the in- formation regarding connections. The FESAS Middleware uses these files during the deployment of a SAS as specified in Section 6.1.2. Acceleo offers reference implementations in Java based on EMF models. We extended and customized these implementations. 1 { 2 "DEVICE_PROPERTIES": [ 3 { 4 "TYPE": "device_id", 5 "VALUE": "fesasID-123_0_000" 6 },... // code removed], 7 8 "AL_ADAPTATIONLOGIC": [{ 9 "AL_TYPE": "MONITOR", 10 "AL_ID": "fesasID-123_1_001", 11 "AL_NAME": "Device_km1_monitor",

12 "AL_LOGIC": [

13 {

14 "SUPPORTED_INFORMATION_TYPES":[ 15 "Context_CAMERA_DATA"],

16 ... // code removed],

17 "AL_PROPERTIES" :[... // code removed

18 ],

19

20 "MANAGEDRESOURCES": [{

21 "MR_RESOURCE": {... // code removed}},

22 ]

23 }

Listing 7.3: Excerpt of a generated JSON file for showing its structure with some data from the SmartHighway system.

Listing 7.3 shows the structure of a resulting configuration JSON file. As a lightweight and language-independent representation, JSON suits this use case. The file for a device has a JSON element for the device as root element. This ele- ment contains the device’s properties as JSON attributes and JSON elements for the adaptation logic, managed resources, and the communication. Each JSON element represents an array with the adaptation logic components and/or the probes and actuators of the managed resources. The communication links be-