A Graphical Workflow Editor for Tool Integration in the Design and Analysis of Gas Turbines
Jasvir Kaur Dhaliwal
A thesis submitted to McGill University in partial fulfillment of the requirements of the degree of
MASTER OF SCIENCE
The faculty of Electrical and Computer Engineering
McGill University Montreal
April 2020
c Jasvir Kaur Dhaliwal 2020 Abstract
The development of complex cyber-physical systems such as aeroderivative gas turbines (AGT) frequently involves running variety of multi-disciplinary design and analysis tools executed along hierarchical workflows in a collaborative environment. The efficient and accurate definition of tool integration workflows is a major challenge because the processing of data for each tool in the sequence is dependent upon the results generated by the other tool. In this thesis, I present a graphical workflow editor to provide an interactive, intuitive and user- friendly tool to define complex tool integration workflows. The workflow editor builds on several innovative ideas: (1) instead of a static palette, reusable workflow elements can be selected and instantiated from a dynamic library of model classes, which is continuously synchronized with a version control system, (2) workflow elements are placed on a grid layout similar to UML swimlanes but with dynamically expandable columns and rows, (3) auto-wiring is provided to draw connections between type compatible workflow elements. The workflow editor is developed using popular model-based tool development platforms such as Eclipse Modeling Framework (EMF) for the definition of concepts of the domain specific language, Graphical Modeling Framework (GMF) and Sirius for the development of graphical modeling work- bench. For the model-to-text transformation, VIATRA framework is used which provides a graph pattern based query language and an efficient incremental query engine. The performance and scalability of Graphical Workflow Editor is supported by early experi- mental results discussed in this thesis. The results indicate that the time taken for the workflow definition remains within acceptable limits even for the larger and complex workflow models. A user study is also included to provide a general feedback about the features of graphical workflow editor.
ii R´esum´e
Le d´eveloppement de syst`emes physico-num´eriquescomplexes tels que les turbines `agaz a´ero- d´eriv´ees(TGA) implique tr`essouvent l’utilisation d’une diversit´ed’outils multidisciplinaires pour la conception et l’analyse, ex´ecut´esau travers de flux de travaux hi´erarchis´esdans un environnement collaboratif. La d´efinitionde l’int´egrationdes outils dans les flux de travaux se doit d’ˆetreefficace et pr´ecise. Elle repr´esente un des enjeux majeurs car le traitement des donn´eesde chaque outil dans la s´equenceest d´ependant des r´esultatsg´en´er´espar les autres outils. Dans ce m´emoire,je pr´esente un ´editeur graphique de flux de travaux qui offre un outil interac- tif, intuitif et avec une interface conviviale permettant de d´efinirl’int´egrationdes flux de travaux d’outils complexes. L’´editeurde flux de travaux est construit sur plusieurs id´eesinnovantes : (1) plutˆotque d’utiliser une palette statique, des ´el´ements r´eutilisablesde flux de travaux peuvent ˆetre s´electionn´eset instanci´esdepuis une librairie dynamique de mod`elesde classes, qui est continuelle- ment synchronis´eeavec un syst`emede contrˆolede version, (2) les ´el´ements de flux de travaux sont plac´esdans une grille dont le nombre de colonnes et de lignes se modifie dynamiquement similaire aux couloirs UML, (3) l’´ecritureautomatique permet de dessiner les connexions entre les types d’´el´ements de flux de travaux compatibles. L’´editeurde flux de travail est d´evelopp´egrˆace`ades plateformes de d´eveloppement d’outils bas´essur les mod`elestels que Eclipse Modeling Framework (EMF) pour la d´efinitiondes concepts li´eesau langage sp´ecifiqueaux domaines, Graphical Modelling Framework (GMF) et Sirius pour le d´eveloppement de l’´etablide mod´elisationgraphique. Pour la transformation du mod`elevers le texte, la structure VIATRA est utilis´ee,ce qui procure un langage de requˆetebas´esur des mod`eles graphiques et un moteur incr´emental de requˆetesefficace. Les performances et la mise `al’´echelle de l’´editeurde flux de travaux est appuy´epar les r´esultatsexp´erimentaux pr´eliminairesdiscut´esdans ce m´emoire.Les r´esultatsprouvent que le temps moyen de d´efinitiond’un flux de travail reste dans les limites acceptables mˆemepour les mod`elesde flux de travaux plus grands et plus complexes. Une ´etudeaupr`esdes utilisateurs est ´egalement incluse afin de donner un retour sur les diff´erentes fonctionnalit´espropos´eespar l’´editeurgraphique de flux de travaux.
iii Table of Contents
Abstract ...... ii
R´esum´e ...... iii
Table of Contents ...... iv
List of Tables ...... vii
List of Figures ...... viii
Acknowledgements ...... x
1 Introduction ...... 1 1.1 Context and Motivation ...... 1 1.2 Contribution and Methodology ...... 2 1.3 Thesis Organization ...... 3
2 Industrial Background and Motivation ...... 4 2.1 Introduction to Gas Turbines ...... 4 2.2 Design and Analysis of Aeroderivative Gas Turbines ...... 6 2.2.1 High-Level Design Workflow ...... 6 2.2.2 Hierarchical Workflows for Tool Integration ...... 8 2.2.3 Low-level Workflows ...... 8 2.2.4 Workflow Definition Practice for AGT at Siemens ...... 10 2.3 Summary ...... 11
3 Overview of Technologies ...... 12 3.1 Domain-Specific Languages ...... 12 3.1.1 Models in Software and Systems Engineering ...... 12
iv Table of Contents
3.1.2 Foundations of Domain-Specific Languages ...... 13 3.1.3 Abstract Syntax ...... 14 3.1.4 Concrete Syntax ...... 19 3.1.5 Model representation formats ...... 21 3.2 Well-formedness Constraints and Model Transformations ...... 22 3.2.1 Constraint languages ...... 23 3.2.2 Model transformation techniques ...... 26 3.3 Version Control Systems ...... 30 3.3.1 Centralized Version Control Systems ...... 30 3.3.2 Distributed Version Control Systems (Git) ...... 32 3.4 Summary ...... 33
4 Graphical Editor for Tool Integration ...... 34 4.1 Architecture of Graphical Workflow Editor ...... 35 4.2 User-Friendly Dashboard ...... 36 4.3 Interactive Wizards for Workflow Configuration ...... 37 4.4 Dynamic Palette ...... 38 4.5 Dynamic Grid Layout ...... 39 4.6 Auto-wiring of Workflow Elements ...... 39 4.7 Dynamic Workflow Library for Re-usability ...... 42 4.7.1 Save workflow ...... 43 4.7.2 Reusable workflow ...... 44 4.8 Summary ...... 44
5 Feature Implementation for Graphical Editor ...... 45 5.1 Domain Specific Language ...... 45 5.1.1 Metamodel ...... 45 5.1.2 Java Code Generation ...... 47 5.1.3 Graphical Representation for DSL: Sirius ...... 47 5.2 Graphical Representation of Workflow Elements ...... 49 5.3 Setup of Dynamic Workflow Library for Reusability ...... 51 5.4 Setup of Dynamic Grid Layout ...... 52 5.5 Setup of Dynamic Palette ...... 54
v Table of Contents
5.6 Implementation of Auto-wiring ...... 54 5.7 Implementation of Workflow Definition File Generation ...... 57 5.7.1 Query Development Environment ...... 57 5.8 Summary ...... 59
6 Evaluation ...... 60 6.1 Performance Study ...... 60 6.1.1 Evaluation of RQ1 ...... 61 6.1.2 Evaluation of RQ2 ...... 63 6.2 Initial User Study ...... 64 6.3 Summary ...... 65
7 Related Work ...... 66 7.1 Business Process Modeling Workflows ...... 66 7.1.1 Business Process Model and Notation (BPMN) ...... 66 7.1.2 Java Business Process Model (jBPM) ...... 68 7.1.3 GWE vs BPMN and jBPM ...... 69 7.2 Workflows for Data Analytics ...... 69 7.2.1 Konstanz Information Miner (KNIME) ...... 69 7.2.2 RapidMiner ...... 70 7.2.3 GWE vs KNIME and RapidMiner ...... 71 7.3 Tool Integration Workflows for CPSs ...... 71 7.3.1 OpenMETA ...... 71 7.3.2 Advanced Data management tools for the engineering of CPS : AIDE . . . . 72 7.3.3 GWE vs OpenMeta and AIDE ...... 73 7.4 Summary ...... 73
8 Conclusion and Future Work ...... 74 8.1 Conclusions ...... 74 8.2 Future Work ...... 75
Bibliography ...... 76
vi List of Tables
6.1 Experiment results for creating 100 workflow elements (10 times): the total time taken for auto-wiring, overall I/O connection for these elements ...... 62 6.2 Experiment results for varying level of complexity and total time taken for auto-wiring 64 6.3 Aggregated results of user satisfaction survey for Graphical Workflow Editor (1: Strongly disagree, 2: disagree, 3: neutral, 4: agree, 5: strongly agree) ...... 65
vii List of Figures
2.1 Gas Turbine Engine [59] ...... 5 2.2 High-level Gas Turbine Design Workflow ...... 7 2.3 Low-level Gas Turbine Design Workflow Structure ...... 9 2.4 An overview of Performance Workflow at Siemens AGT ...... 9 2.5 An overview of SAS Analysis Workflow at Siemens AGT ...... 10
3.1 An overview of modeling language infrastructure ...... 16 3.2 Abstract syntax representation of modeling language ...... 17 3.3 EMF binds Java, XML and UML ...... 18 3.4 Abstract vs Concrete Syntax ...... 19 3.5 A sample Sirius diagram (created using the Graphical Workflow Editor) ...... 21 3.6 A sample of VIATRA query Pattern ...... 23 3.7 An example of VQL Constraint for validation ...... 24 3.8 Overview of runtime components of VIATRA Query [23] ...... 27 3.9 A sample of Java Transformation based on VIATRA Query API ...... 27 3.10 An overview of Acceleo transformation architecture [15] ...... 28 3.11 An overview of Centralized Version Control System [41] ...... 31 3.12 An overview of Distributed Version Control System [41] ...... 33
4.1 An overview of a Graphical Workflow Editor architecture ...... 35 4.2 Dashboard view of graphical workflow editor ...... 36 4.3 Create new workflow wizard: Page 1 and Page 2 ...... 37 4.4 Dynamic list of workflow elements from VCS ...... 38 4.5 Selection of workflow element for the placement on grid-layout ...... 38 4.6 An overview of two workflows on grid layout ...... 40 4.7 An overview of auto-wiring on grid layout ...... 41
viii List of Figures
4.8 An overview of algorithm for auto-wiring ...... 41 4.9 VCS preference dialog of Graphical Workflow Editor ...... 42 4.10 Save workflow on local drive ...... 43 4.11 Open an existing workflow on grid-layout ...... 44
5.1 Metamodel for the abstract syntax of Gas Turbine Workflows ...... 46 5.2 Metamodel for the concrete syntax of Gas Turbine Workflows (grid layout) . . . . . 46 5.3 Relationship between EMF and Sirius implementation for a graphical modeler . . . . 48 5.4 A snapshot of created Container Element (Activity Block) in VSM ...... 49 5.5 Graphical Element Mapping with Domain Model (Class) ...... 50 5.6 Style Specification for the Graphical Workflow Element ...... 50 5.7 Git cloning ...... 51 5.8 SSH setup for Distributed Version Control System ...... 52 5.9 Graphical configuration of grid layout in Sirius ...... 53 5.10 An excerpt of Sirius Service for the dynamic expansion of grid layout ...... 53 5.11 Setup of Dynamic Palette in Sirius ...... 54 5.12 An example of Auto-Wiring service setup in Sirius ...... 56 5.13 An example of auto-wiring implementation ...... 56 5.14 Structure of the query generated code with Match and Matcher classes ...... 58 5.15 Initialization of Query Engine ...... 58 5.16 Preparation of Query Engine with All Queries ...... 59
6.1 Dialog box for the scalability evaluation ...... 61 6.2 Scalability Implementation ...... 61 6.3 Total time taken for Auto-Wiring ...... 63 6.4 Total time taken for the extreme end I/O connections for overall workflow ...... 63
7.1 An overview of basic elements of BPMN (ICEDEG, 2014 [8]) ...... 67 7.2 An overview of components of jBPM [32] ...... 68 7.3 An overview of KNIME Workflow (KNIME Analytics Platform [35]) ...... 70 7.4 An overview of RapidMiner Workflow (CEUR Workshop, 2015 [66]) ...... 71 7.5 Design Flow in OpenMeta Tool Chain (International ModelicaConference, 2014 [38]) 72 7.6 Design Flow in AIDE Tool Chain [37] ...... 73
ix Acknowledgements
Foremost, I would like to express my sincere gratitude to my supervisor Prof. D´anielVarr´ofor the continuous support of my Master’s study and research, for his enthusiasm, motivation and immense knowledge. His valuable guidance helped me throughout research and writing of this thesis. I would like to extend appreciation to my manager Mr. Martin Staniszewski (at Siemens) for introducing me to the design and analysis process of aeroderivative and large gas turbine systems and also for the immense support, encouragement and insightful comments. My sincere thanks also goes to Mr. Jose Valenzuela Del Rio (at Siemens) for reviewing my work and for sharing his valuable feedback throughout the designing and implementation of the workflow editor. I would also like to thank my colleagues: M´artonB´urfor answering all my questions about the details of the VIATRA framework and VIATRA Query Language, and Maruthi Rangappa for the great support and stimulating discussions. I am thankful to the members of the research group (both at McGill University and Siemens) who provided numerous valuable observations and suggestions. I am also thankful to the colleagues at Siemens who participated in the user satisfaction survey and provided their valuable feedback about the presented tool. Last but not the least, I am very grateful to my family and friends for their continuous support.
x Chapter 1
Introduction
1.1 Context and Motivation
Designing of aero-derivative gas turbines (AGT) is a multidisciplinary process which involves active collaboration between distributed teams of heterogeneous stakeholders at the industrial partner (designer, analyst, advanced engineer, tool developer, software specialist, disciplinary expert etc.), with the ultimate goal of improving organizational efficiency, process transparency, responsiveness and profitability. Gas turbines as a critical cyber-physical system necessitate to use a multitude of different design, analysis and optimization tools to execute a complex sequence of steps coordinated by workflows in order to satisfy the product requirements and comply with a set of procedural rules and processes. To automate the definition and execution of such design and analysis processes, workflow management systems have become increasingly popular. In addition, workflows can also drive the integration of various design, analysis and optimization tools used during the engineering process [4, 42]. Since tool integration problems can easily lead to major defects in the product, the precise definition and execution of tool integration workflows is a major software engineering challenge. The general practice used at Siemens, which is the industrial partner for this research, for the definition of multidisciplinary workflow involves the manual editing of definition files (in JSON format), which are further used as input for the workflow execution framework. However, this approach requires extra caution during the definition of text-based workflow (1) to avoid any human errors, and (2) to keep the precise hierarchy of design and analysis process. The Erroneous definition files may affect the workflow execution process and require extra time for the debugging and fixing of errors. Hence, this text-based (in JSON format) workflow definition technique used to design an integrated workflow may effect (1) the overall time taken for the design and analysis process of gas turbines, (2) the efficiency of engineers (due to the time involved for the error debugging process). The graphical workflow editor aims to provide a solution for the highlighted
1 1.2. Contribution and Methodology problems by providing a simple graphical way to design and generate ready-to-execute workflow definition files.
1.2 Contribution and Methodology
In this thesis, I present the Graphical Workflow Editor (GWE), which is a modeling tool (not open- source) developed as part of a collaborative project with Siemens to provide a user-friendly way to define tool integration workflows. The main architecture of GWE was designed in collaboration with my supervisor (Prof. D´anielVarr´o)and the stakeholders from Siemens (Mr. Martin Staniszewski and Mr. Jose Valenzuela Del Rio). In particular, in this thesis, I present the following contributions where my own work was predominant.
• Integration with version control system: The graphical workflow editor is integrated with a version-controlled workflow element library used at the industrial partner for the design and analysis of aero-derivative and large gas turbines.
• Novel features in graphical editor: As conceptual contributions, the GWE (1) provides a dynamic palette of workflow elements with a version controlled library, (2) creates auto- wiring between type compatible workflow elements, (3) provides a dynamically expandable grid layout for the hierarchical composition of heterogeneous workflow components similar to UML swimlanes.
• Eclipse-based implementation As underlying technology for GWE, the Sirius framework is used to build a custom graphical modeling workbench on top of Eclipse Modeling Framework (EMF) [17] used for defining the concepts of the domain specific language. For the model- to-text transformation, the VIATRA framework [67] is used, which provides a graph pattern based query language and an efficient incremental query engine.
• Experimental evaluation A performance evaluation is carried out for GWE by conducting experiments such as (1) the measurement of execution time vs increasing workflow model size and (2) the measurement of execution time vs varying workflow model complexity. A usability study also gathers feedback from actual users at Siemens in the form of a survey.
The main added value of GWE is that it extends traditional workflow definition system with advanced graphical representation (e.g. graphical engineering workflow blocks, auto-wiring, an in-
2 1.3. Thesis Organization tuitive overview of workflow on grid layout), provides collaboration with version-controlled reposi- tories such as GitLab and generates ready-to-execute definition files for external workflow execution tools. The main target audience of GWE includes various engineers such as workflow designers, analysts, disciplinary experts, advanced engineer etc. The various stakeholders of multi-disciplinary teams can use this tool to define, analyse and execute the different components of design and anal- ysis process without the need of manually editing low-level text files. However, the tool can be easily adapted for specifying tool integration workflows in other domains.
1.3 Thesis Organization
The rest of this thesis is structured as follows:
• Chapter 2 provides an overview of the design process of aero-derivative gas turbines used at Siemens Canada, and highlights key analysis workflows used as an ongoing running example of the thesis.
• Chapter 3 discusses the underlying technologies used for the implementation of the graphical workflow editor and also compares other related technologies.
• Chapter 4 provides an overview of features of the graphical workflow editor and highlights user’s perspective of the available features.
• Chapter 5 provides an overview of the implementation steps used for the development of the graphical workflow editor. It includes technical concepts along with detailed reference of design steps for each feature.
• Chapter 6 provides detailed information about the evaluation experiments carried out related to the performance of the graphical workflow editor. It also covers the user based study per- formed within Siemens for the review of overall performance and appearance of the graphical workflow editor.
• Chapter 7 compares related graphical modeling tools available in the market. It also highlights the reasons due to which the graphical workflow editor differentiates from the other workflow modeling editors.
• Chapter 8 concludes the thesis by summarizing the major highlights of the graphical workflow editor and discussing future plans for the extension of this modeling tool.
3 Chapter 2
Industrial Background and Motivation
Gas turbines (GT) [63] are commonly used in many power generation applications because of their flexibility, wide output power range and also have evolved into very complex cyber-physical systems (CPS) [40]. The design of such complex gas turbines systems is very challenging and brings together the expertise from diverse disciplines to create and execute complex design workflows. A similar scenario exists at one of the leading organization (such as Siemens Canada) in the field of Power Generation, which produces aero-derivative gas turbines (AGT) [43] with output power ranging up to 65MW. Recent advancements in software and computer engineering can be leveraged to increase the efficiency of this design process by increasing collaboration and by integrating tools to create efficient and automated workflows. This chapter provides some background information to understand the challenges faced by Siemens AGT department in the design process and how efficient workflow design technologies can be applied to overcome these challenges.
2.1 Introduction to Gas Turbines
Gas turbines [59] are engines which convert the chemical energy of fuel either into mechanical energy (shaft power) or into kinetic energy. Gas turbines that produce shaft power are known as power generation gas turbines. Gas turbines that convert fuel energy into kinetic energy are used for generation of thrust to propel an aircraft. The conversion of fuel energy into shaft power requires interaction of several components of the engine (as shown in Figure 2.1) within each of them a chain of energy conversion takes place.
Compressor
The compressor, which is located near the inlet of the gas turbine, is used to increase the pressure of the air. The compression happens because the speed of the air is increased as it passes through the stator and rotor blades of the compressor, and more and more incoming air is pressed into the tiny gaps between the rotors and stators. This high pressure air is necessary for efficient combustion
4 2.1. Introduction to Gas Turbines
Figure 2.1: Gas Turbine Engine [59] of the fuel in the combustor of the gas turbine. A compressor in a turbine may have up to 3 sections such as Low-Pressure Compressor (LPC), Intermediate Pressure Compressor (IPC), and High-Pressure Compressor (HPC). These multiple sections of the compressors increase the pressure of air gradually to a very high point and are mixed with the fuel before entering into the combustion chamber. Each section of the compressor will typically have many stages (one set of rotor and stator blades in the compressors are referred to as a stage). The number of stages needed in the turbine is decided based on the size of the compressor and the air pressure and temperature needed at the output of the compressor.
Combustor
The mixture of highly compressed air and fuel is burnt inside the component of gas turbine called combustor to produce a jet of hot air at high velocity to move the turbine. The type of combustor used in a gas turbine depends on the type of fuel (natural gas, diesel, or kerosene) that the gas turbines burn. The most common types of combustors used in the gas turbine industry are Dry Low Emission (DLE) and Wet Low Emission (WLE) combustor. The efficiency of the gas turbine depends mostly on how well the fuel is burnt inside the combustor.
Turbine
The high-velocity hot air coming out of the combustor moves through the turbine sections, acting on the airfoil-shaped turbine blades on its way out of gas turbine engine. As a result of this movement, the rotation happens at the turbine mounted on a shaft (also connected to the shaft of a generator). Like the compressor, the turbine is also divided into multiple sections. The section of the turbine that is close to the combustor is called High-Pressure Turbine (HPT) and is always subjected to a range of high temperatures that are above the melting point of the material used to
5 2.2. Design and Analysis of Aeroderivative Gas Turbines build these turbine blades. These blades are cooled by applying cooling techniques to prevent them from melting down. To make the most use of the high velocity air available near the combustor, HPT blades are densely populated. A large portion of the gas turbine design efforts is concentrated around the design of the HPT turbine blades due to the complexity involved in designing the cooling passages. The HPT section is followed by an Intermediate Pressure Turbine (IPT) and Low-Pressure Turbines (LPT). Blades on these turbine sections are not cooled as they are subjected to reduced temperatures because the air loses heat as it passes through the HPT section. It is to be noted that while the compressors are upstream (low to high), turbines are downstream (high to low) and each compressor stage is driven by the corresponding turbine stage.
2.2 Design and Analysis of Aeroderivative Gas Turbines
A general gas turbine design process at Siemens, as shown in Figure 2.2, starts with a specification prepared by marketing experts based on facts (current and future trends) and requirements derived from the customer’s demands. After some preliminary studies about the required configuration, existing designs, and design feasibility, the specification is passed on for detailed design and analysis by specialized disciplines. Based on the type of the work and the domain expertise of the involved engineers, Siemens PG has identified the engagement of nine different disciplines in the AGT design process.
2.2.1 High-Level Design Workflow
Combustion: The combustion discipline is involved at the beginning of the design cycle in helping the performance discipline to create an initial performance model. Further, it is involved in the design and development of the combustion chamber for the gas turbine.
Design: This discipline involves the end-to-end designing of gas turbine components by the spe- cialized engineers.
Performance: The performance discipline plays a vital role in designing the performance model at the beginning of the design process. The performance model is a thermo-mechanical model providing pressures, temperatures, and mass flow at every section of the engine as well as shaft rotational speeds.
6 2.2. Design and Analysis of Aeroderivative Gas Turbines
Figure 2.2: High-level Gas Turbine Design Workflow
Aerothermal: Experts in this discipline provide aerodynamic and cooling design and analysis of compressors and turbines using state of the art tools and methods.
Seconday Air System (SAS): The SAS team runs the analysis to verify that the secondary air system can provide sufficient cooling air for the blades and vanes, and sealing to the turbine components at a given measurement point. Besides, SAS engineers perform load calculations to assess the integrity of bearings.
Thermo Mechanical: This discipline performs thermal analysis on the entire engine and pro- duces useful information for mechanical design and lifing disciplines to perform their analysis.
Mechanical Modelling: Mechanical modeling team performs the Finite Element Method (FEM) structural analysis on the static structural parts such as casings, bearing housings, and mounts to understand the critical engine operating speeds and loads.
Stress Analysis: The engineers of this discipline perform stress analysis on the various turbine components particularly turbine blades.
Lifing: The experts of this team perform different analyses to determine the life of gas turbine components for the given performance attributes.
7 2.2. Design and Analysis of Aeroderivative Gas Turbines
2.2.2 Hierarchical Workflows for Tool Integration
Based on the previous design process, it is evident that every analysis in the gas turbine design process greatly depends on the outputs of other disciplines. Hierarchical workflows are designed by the technical experts to streamline the execution of tasks involved in each design step. Engineers run these workflows and document the results for future reference by multiple disciplines. Figure 2.2 depicts a high-level workflow of gas turbine design used at Siemens for aero-derivative gas turbines (AGT) [43]. The workflow excludes the manufacturing and real engine testing because the design iterations triggered by these two design steps are minimal. The workflow focuses mainly on the design steps which are iterative and central to the workflow and also range from performance analysis to assessment of the life of critical components (lifing). The disciplines in the workflow are arranged in the order of their occurrence in the design process. The combustion discipline helps the performance team to design the performance model at the beginning of the workflow. Since the combustion chamber is a complex GT module, it is not modified frequently. Since it takes a long time to design a new combustion chamber, it is uncommon to see new combustion chambers for every version of GT. Consequently, the performance discipline is generally placed at the beginning of the workflow. The major section of the workflow has a modified waterfall structure. The output of one step is used as the input to the next step, and feedback is provided to the previous steps. The mechanical modeling discipline has involvement only with the stress discipline, and the design discipline is present throughout the workflow and supports all disciplines by providing mechanical designs.
2.2.3 Low-level Workflows
The high-level end-to-end design workflow is divided into multiple low-level workflows, also known as sub-workflows. The execution of a sub-workflow always involves running a design and analysis tool on a given set of inputs to produce a set of outputs. The sub-workflows capture tasks executed by disciplines in greater detail and can be executed independently of other sub-workflows provided all required inputs are available. A sub-workflow, which comes earlier, can execute a new analysis while another dependent sub-workflow which comes later is working on the previous versions of the data. At Siemens AGT, sub-workflows are executed on a proprietary workflow design and tool integration framework.
8 2.2. Design and Analysis of Aeroderivative Gas Turbines
Figure 2.3: Low-level Gas Turbine Design Workflow Structure
Performance Workflow The involvement of the performance discipline starts at the beginning of the high-level design workflow [13, 29]. It designs the performance model, which is a thermo- mechanical model providing measurements of pressure, temperature, and mass flow at every section of the gas turbine. The performance team is also responsible for specifying the shaft rotational speeds of the gas turbine in order to run experimental calculations on the performance model via the performance sub-workflow and to capture the measurements pressure, temperature, and mass flow for the desired engine specification. Running the performance workflow [9] involves defining a design envelope for desired ambient conditions, defining the flight cycle (GT cycle from startup to shutdown) data, running calculations on a performance model, and plotting the results for analysis. Engineers do this with the help of an in-house tool designed explicitly for this purpose using the workflow based tool integration framework. Figure 2.4 shows a generalized performance workflow at Siemens AGT. The names of inputs, outputs, and tools are generalized to respect the non-disclosure agreement with Siemens AGT department.
Figure 2.4: An overview of Performance Workflow at Siemens AGT
Secondary Air System Workflow A gas turbine experiences high pressures and high temper- atures, especially on the blades of the HPT and Nozzle Guide Vanes (NGV) located downstream of
9 2.2. Design and Analysis of Aeroderivative Gas Turbines the combustion chamber [54]. In order to maintain structural integrity and a competitive life-span, cooling of these blades is necessary. Gas turbine designers have incorporated a technique called film cooling into the blade design process to get the necessary cooling of the blades.
Figure 2.5: An overview of SAS Analysis Workflow at Siemens AGT
In film cooling, cool air is bled from the compressor stage, ducted to the internal chambers of the turbine blades, and discharged through small holes in the blade walls. This air provides a thin, cool, insulating blanket along the external surface of the turbine blade, thus prevents high pressure, high temperature air from directly acting on the turbine blades. The SAS discipline is responsible for analyzing the flow paths for the bleed air in the SAS network. The SAS network is composed of nodes that represent how flows are divided or merged in the SAS. As a result of this analysis, SAS shall provide an efficient SAS configuration for a given engine that will help (1) the mechanical design team to understand the component requirements to specify the component temperature and pressure, and (2) aerothermal and thermo-mechanical teams to give boundary conditions at engine interfaces to design auxiliary systems. Figure 2.5 shows SAS workflow administered at Siemens AGT. This workflow is further divided into three sub-workflows: pre-processing (which handles the configuration of the model), process (performs the execution of the model) and post-processing (performs the analysis of the results). The categories are defined to determine the correct flow of automation. Executing this workflow consists of running the solver on the SAS model with performance inputs and boundary conditions to produce a SAS configuration.
2.2.4 Workflow Definition Practice for AGT at Siemens
The AGT based workflows require highly involved collaboration between different stakeholders coming from diverse teams to exchange data produced by their disciplines. The engineers at Siemens use a traditional text based workflow definition technique to design a multidisciplinary
10 2.3. Summary workflow for the tool integration. A final workflow definition file is created based on the sequence of design and analysis steps for aero-derivative or large gas turbines, and the disciplines are inter- dependent on each other for the data to perform their analysis process. For instance, SAS analysis is highly dependent upon the outputs generated by the Performance discipline. Therefore, the results from each discipline get passed on to the next discipline in the workflow and a definition file needs to be updated each time for the final version. A definition file (in JSON format) is created by each discipline (such as Performance, Secondary Air System etc.), which describes the list of required inputs and the list of generated outputs. The workflows shown in Figure 2.4 and Figure 2.5 for Performance and SAS are created textually (in JSON format) by the engineers of each discipline and then the workflow execution system (WES) at Siemens visually represents these workflows at the time of execution as illustrated in these snapshots. If there is any fault or an error exists in text based definition files, it will only get noticed when WES will not be able to load these files due to the existing errors. Therefore, it is very late and exhausting to capture and debug the errors at the time of execution, because it delays the whole design and analysis process. Furthermore, this text based approach requires extra-caution during the definition of inter- disciplinary workflow (a) to avoid any mistakes done by engineers, and (b) to keep the right sequence of steps for the design and analysis process of gas turbine. It is very challenging for engineers to keep track of precise definition and execution of multi-disciplinary workflow. Therefore, the Graphical Workflow Editor presented in the Chapter 4 provides a user-friendly graphical way of designing workflows and avoids manually editing of low-level text files. This tool also helps to create instantaneous large workflow models without any errors, which helps to improve the overall work efficiency of engineers at work.
2.3 Summary
To conclude, this chapter provided a detailed information about the selected domain (such as complex cyber physical system: gas turbine) for the graphical workflow editor. It covered the important topics related to the design and analysis process for a gas turbine and also discussed about the approach adopted by Siemens engineers for the workflow definition. The following chapter will provide an overview of the technologies used for the development of the graphical workflow editor as well as the other related technologies.
11 Chapter 3
Overview of Technologies
3.1 Domain-Specific Languages
This chapter provides an overview of various modern technologies adopted by me for the develop- ment of the Graphical Workflow Editor (GWE) along with a brief comparison with other related technologies. I provide brief introduction of the underlying technologies for GWE (such as Eclipse Modeling Framework for the definition of concepts for domain-specific language, Sirius framework for the development of customized graphical editor, VIATRA framework for the model-to-text transformation, JSON format for the model representation and distributed version control system for the dynamic library) and the related technologies for each category.
3.1.1 Models in Software and Systems Engineering
Models play a significant role in Model Driven Engineering. The most general definition indicates that a model is a simplified representation of real life domain [62] or, more formally, “a model is a set of statements about the system” [61]. One can say that a model is a clear set of formal elements that describes something under development for a specific purpose, and that can be analyzed using various methods. In addition to what is specified by the definition of a model, an engineering model must possess, to a certain extent, the following five key characteristics [62]:
1. Abstraction: A model is an abstract description of the system in the sense that it does not cover all the aspects of the real-life system but precisely and concisely captures the essential properties of the system for a set of given concerns.
2. Understandable: It is not sufficient just to abstract out all details of the concerned system; we must also present it intuitively or adjusted to human needs and understanding.
3. Accurate: A model should provide a real life representation of the characteristics of a modelled system.
12 3.1. Domain-Specific Languages
4. Predictive: A model should capture the properties of the real-life system in such a way that one could predict those properties by executing the model on a computer or employing some formal analysis.
5. Inexpensive: A model should be notably cheaper to build and study than the modelled system.
3.1.2 Foundations of Domain-Specific Languages
A domain-specific language (DSL [28, 34]) is a software language dedicated to an application do- main. On the other hand, general-purpose language (GPL [56]) is broadly applicable across domains such as XML (markup language) [69], UML (modeling language) [10], Java (programming language) etc. There are various kinds of DSLs, ranging from languages for common domains, such as HTML [68] for web pages, to languages dedicated for a particular software technology, such as SQL [74] for relational databases. A few examples of industry standard DSLs are: AUTOSAR [12, 27] and MATLAB Simulink StateFlow [26] for automative, AADL [45] for aerospace, UML-MARTE [14] for railways, and SysML [46] for space applications. As a key principle, DSLs (1) must offer good abstraction, intuitiveness to the modeler, (2) must evolve based on the requirements, (3) must be supported by the methods and tools, (4) should be adaptable for extensions, but closed for alterations. The classification of DSLs [6] is usually done based on one or more of the following aspects:
Vertical vs. horizontal A vertical DSL defines language syntax and semantics for a particular industry or domain. Analysis languages used for the financial domain and languages used for configuration of automation systems are few examples of vertical DSLs. In contrast, a horizontal DSL defines the language syntax and semantics to capture concepts of a general concern having applicability in fields. The DSLs that cover a certain technology are good examples of horizontal DSLs (e.g., SQL [74], WebML [47]).
Declarative vs. imperative A declarative DSL provides specifications for describing a system or a process or a computation but does not provide execution constructs. Query definition languages such as SQL [74] and OCL [51] are good examples of declarative DSLs. In contrast, an imperative DSL provides control flow that should be followed to execute the algorithm defined using the DSL. The Programming languages like Java and C/C++ are good examples of imperative DSLs.
13 3.1. Domain-Specific Languages
Graphical vs. textual A graphical DSL uses visual models for development and graphical items such as blocks of different shapes (rectangle, diamond, square etc.), bordered ports, connecting edges, containers of various styles (list, gradient), symbols as development primitives. On the other hand, a textual DSL uses a regular text-based notation such as XML notations and structured text notations.
Internal vs. external An internal DSL is developed on top of an existing host language to provide extensions that offer abstractions to the host language constructs. In contrast, an external DSL has its customized syntax that includes a full parser, self-standing and independent models or programs.
Execution vs. code generation Execution in DSL involves the reading and execution of the DSL program at runtime, one statement at a time like programming language interpreters. In contrast, code generation in DSL refers to model-to-text (M2T) transformation to produce the executable program from the high-level model representation.
Irrespective of the type (general-purpose or domain-specific), the syntax and semantics are the building blocks of a language. A language has a) abstract syntax, b) concrete syntax, and c) seman- tics. Abstract syntax defines the taxonomy, relationships of model elements and well-formedness rules or constraints. In contrast, semantics defines the static or behavioural aspects, and last but not least, concrete syntax provides the textual or visual notation for the DSL.
3.1.3 Abstract Syntax
Means for defining abstract syntax A description of the abstract syntax is a formal expression of concepts and relationships that is amenable to processing by software. The abstract syntax defines the following key aspects:
1. language concepts and their attributes;
2. relationships between concepts;
3. constraints, well-formedness rules;
There are various methods to specify the abstract syntax of a DSL:
14 3.1. Domain-Specific Languages
1. Context-Free Grammar defines a set of production rules that describe all possible strings in a given formal language. It includes programming languages (such as Java, C, C++) and declarative languages (such as XML Schema [39], DTD [39], RDF [3]);
2. Attribute Grammar provides a formal way to define attributes for the productions of a formal grammar, associating these attributes with values. It includes complex structures like trees and graphs;
3. Graph Grammar provides a grammar where each side of a rule consists of a graph such as connected set of elements;
4. UML Profiles provide a generic extension mechanism for customizing UML models for par- ticular domains and platforms (such as MARTE [14]);
5. Metamodeling provides language design similar to UML language. The abstract syntax de- fined by the metamodel forms the basis for the new DSL.
Metamodels: The metamodel itself is a model and defines the abstract syntax for expressing a domain-specific language using modelling notations. In this definition of the metamodel, one should note the linguistic nature of the metamodel and how it can be used for defining other modeling languages. A commonly used definition of metamodels in MDE [61]: ”A metamodel is a specification model for a class of systems under research where each system is a valid model expressed in a certain modeling language.” Metamodels are used as abstract syntax for modeling languages, which means that metamodels specify rules for structuring sentences in modeling languages. Explicitly, a model defined using the new DSL conforms to the rules of the metamodel defining the abstract syntax as depicted in Figure 3.1.
Metadata Object Facility (MOF): Metadata Object Facility (MOF) offers below essential concepts for the definition of DSLs.
Class: A MOF class is a language construct that defines the structure as well as behavior of objects, which are instances of the defining class. A class describes the structure in terms of attributes (simple data like strings and numbers) and associations (links to and from other objects).
Attribute: An attribute describes the inherent characteristics of a class. It can have many properties and can be defaulted to a specific value.
15 3.1. Domain-Specific Languages
Figure 3.1: An overview of modeling language infrastructure
Association: An association defines a relationship from one class to another class. It represents links (such as references or pointers) that may exist at the run time between instances of the classes.
Composition: A composition is a sub-type of association, which defines a ”part-of” relationship of a class (child) with the other class (parent). A child cannot exist without parent, therefore their lifelines are linked.
Generalization: Generalization is the relationship that represents the class hierarchy between a specialized class called sub-class and a more general class called super-class. A sub-class adds new properties specific to the objects of sub-class in addition to the inherited properties of the super-class.
Example 3.1. Figure 3.2 gives an example of a metamodel (excerpt is shown) for part of a simple modeling language based on real-world systems such as design and analysis workflow for the critical cyber system (e.g., Gas Turbines). The metamodel describes the workflow for the design and analysis of an aero-derivative gas turbine. This metamodel diagram describes the key language concepts: ActivityBlock and Connector along with relationships between these concepts (e.g., reference-based). The well-formedness rules or constraints (e.g., OCL [51]) on the metamodel prevent the con- struction of ill-formed models. Some static semantic rules in metamodeling can be captured using metamodeling infrastructure, such as multiplicity constraints on references. In contrast, with tra- ditional context-free grammars, such rules are out of scope (and would be captured using attributes or other means). Further, this metamodel captures only the abstract syntax of the domain-specific
16 3.1. Domain-Specific Languages
Figure 3.2: Abstract syntax representation of modeling language language for defining workflows for gas turbine design and analysis and leaves out the details of the concrete syntax or the semantics used by the end-users to create the workflows.
Eclipse Modeling Framework
Eclipse Modeling Framework (EMF) [17] is an accessible technology used for building modeling tools and code generators (see Figure 3.3). EMF facilitates defining a metamodel in various formats (using, e.g. Java interfaces, UML diagram, or XML Schema). With the help of that metamodel, one can generate the corresponding implementation classes that systematically manage the underlying models of that domain. Following are the basic components of the EMF:
1. EMF Ecore Model: A metamodel called Ecore model is the component of EMF describing the model of the DSL language. The EMF bundles the change notification and persistence feature with the domain description and provides code generation feature to define Java classes for manipulating the DSL objects created from the metamodel.
2. EMF.Edit: The EMF.Edit component provides
• General Java classes required for the designing of EMF model editors.
17 3.1. Domain-Specific Languages
Figure 3.3: EMF binds Java, XML and UML
• Utility classes that are required for displaying the EMF models using UI viewers classes such as JFace [19].
• Command classes that are required to build editors having support for automatic undo and redo operations.
3. EMF.Codegen: The EMF.Codegen component provides a framework for generating Java classes for editing the model. Codegen is configurable using a GUI to specify options for code generation and uses JDT (Java Development Tooling) [1] of Eclipse.
EMF encapsulates a lot of information in the EMF models, which is useful for generating different type of artifacts. Typically this information can be used for
• Code generation: Java classes corresponding to the classes in the EMF model can be au- tomatically generated by using EMF code generation framework. This code can be manually extended to users requirement to implemented additional features.
• Document generation: Documents in the form of HTML pages can be generated using the EMF models.
• Transformations: Model-to-Model (M2M) and Model-to-Text (M2T) transformations use the information contained in the source EMF models to create new target models.
18 3.1. Domain-Specific Languages
Figure 3.4: Abstract vs Concrete Syntax
3.1.4 Concrete Syntax
Concrete syntax defines the textual or graphical representation of a modeling language. The struc- ture of the abstract syntax often drives the graphical concrete syntax by associating various graph- ical representations for classes and associations in the metamodel. For DSLs without a graphical syntax, a textual syntax can be described by a context-free grammar. Figure 3.4 shows abstract syntax and concrete syntax that defines the connection between two activity blocks in the context of workflow models. Frameworks described in the paragraphs below are used to create concrete syntax representa- tions in the workflow models.
Graphical Modeling Framework
The Graphical Modeling Framework (GMF) [60] is an Eclipse framework which is based on EMF and Graphical Editing Framework (GEF) [18] and provides platform for designing graphical editors for EMF models. GMF uses EMF for definition of abstract syntax of the domain-specific model and for generation of Java classes required for manipulating (create, read, update and delete) the model elements. GMF uses GEF to set concrete syntax of the graphical DSL defined for working on the EMF model.
Sirius
Sirius [21] is an open-source Eclipse project that is built on top of GMF [17, 65] and provides Eclipse plug-ins that facilitate easy creation of graphical DSLs. It uses an EMF metamodel of the
19 3.1. Domain-Specific Languages
DSL and provides the concrete syntax for operating on the metamodel. Usage of Sirius is most relevant when a graphical DSL is required over a textual DSL to allow easy drag and drop type of editors for model creation as in the case of workflow creation discussed in this thesis. Any modeling workbench developed using Sirius [44, 57] gives users the ability to visualize, create and edit models using graphical notations similar to other graphical design tools such as Powerpoint. Sirius offers three main types of editors: diagrams, tables and trees. The graphical workflow editor developed in this thesis is a diagram-based editor.
Sirius Diagram Representation The Sirius Diagram Representation is used to define the con- crete syntax for the abstract syntax contained in the metamodel of the language. The definition of the concrete syntax is done by specifying how a particular metamodel element (class or rela- tion) should be displayed on the graphical representation of the model created using the new DSL. Typical variables available for specifying the graphical representation for an object or relation are shape, label, font, color etc. Representations may involve placing one type of graphical element representing an instance of a metamodel class inside another graphical element representing an instance of another class in the metamodel (for example: placing an activity block inside a cell). This type of placement is called containment. To help with such complex placement requirements, Sirius provides many mechanisms in the Sirius specification project and few of them are listed below:
1. Conditional styles can modify the visual view of elements by applying conditions on style specifications. For instance, a defined condition can decide the color of a port depending upon whether it’s input or output (e.g., green for inputs and blue for outputs in GWE);
2. Layers and filters: can control the display of elements based on the conditional specifications;
3. Validation and quick-fixes can help end-users to find-out obvious errors in the defined model specifications. There is a validate option for viewpoint specification model (VSM) which lists down the captured problems in the Problems section and also suggests possible quick solutions for the listed problems;
The Sirius diagram representation allows the designer of the DSL to define tools to create new objects or relations. These tools are visible to the end users of the DSL on the palette of the editor. The designer can also specify behavior for actions such as drag and drop, right click on the graphical elements and special key press actions such as press of a delete key. Not all actions
20 3.1. Domain-Specific Languages performed by the end users are valid in the context of the design (e.g., user tries to create an activity block in a non-empty cell) and the DSL designer has to incorporate validation rules to check the correctness of such actions. The Sirius framework provides all the necessary features to implement such validation rules.
Example 3.2. The example shown in Figure 3.5 depicts a graphical workflow editor (developed using the Sirius framework) dedicated to the design process of an engineering workflow.
Figure 3.5: A sample Sirius diagram (created using the Graphical Workflow Editor)
The graphical workflow editor presents a grid layout, which allows users to place workflow elements (represented by rectangular boxes) in different cells, and auto-connections are drawn between elements using different colour codes (such as green, violet and blue) representing input, intermediate and output connections respectively.
3.1.5 Model representation formats
The graphical workflow editor (GWE) uses JSON representation format for the model-to-text transformation of designed workflow models. The below sections provide details about a few model representation formats.
XML Metadata Interchange (XMI)
XML Metadata Interchange (XMI)[70] is an object management group (OMG) standard that allows integration of the Unified Modeling Language (UML), MOF, and XML, and also enables developers of multiple systems to share object models and other metadata over the internet. XMI [49], together with MOF and UML, form the core of the OMG metadata repository architecture.
21 3.2. Well-formedness Constraints and Model Transformations
XMI provides a standard way through which UML tools could exchange UML models. XMI produced by one tool can generally be imported by another tool, which allows the exchange of models among tools by different vendors or the exchange of models with other types of tools upstream or downstream of the tool chain. As stated above, XMI is not limited to mapping UML to XML, but it provides rules to generate DTDs or XML schemas [39] and XML documents from any MOF-compliant language. Thus, a model that conforms to some MOF-compliant metamodel can be translated to an XML document that conforms to a schema generated according to the rules of the XMI standard [70]. EMF is an example which explains the practical usage of XMI because it records the details of a model using a persistence layer based on XMI.
JSON
JSON (JavaScript Object Notation) [5, 33] is a lightweight, easy to read and write data-interchange format, which reduces the complexity for machines to parse and generate. JSON uses human- readable text to send data objects that consist of pairs of attribute–value and array data types. It is a commonly used data format, with a diverse range of applications, such as serving as replacement for XML in AJAX [73] systems. It is a text-based format that is entirely language independent, and it has been actively used in the context of various languages including C, C++, C#, Java, JavaScript, Perl, Python etc. These features make JSON an ideal data-interchange language [33]. JSON is built on two structures:
1. A collection of name/value pairs, which is commonly known as an object, a record, struct, hash table, keyed list, dictionary or an associative array;
2. An ordered list of values such as an array, vector, list, or sequence;
These are universal data structures, and all modern programming languages support these data structures in some way. It is understandable that a data format that is interchangeable with programming languages should be based on these structures.
3.2 Well-formedness Constraints and Model Transformations
The Graphical Workflow Editor (GWE) uses VIATRA as a constraint language for the implementa- tion. The below sections briefly discuss a few related constraint languages and model-transformation techniques.
22 3.2. Well-formedness Constraints and Model Transformations
3.2.1 Constraint languages
VIATRA Query Language
VIATRA is an open-source framework for model transformation [23, 58, 67], with particular focus on evaluating the model queries in an efficient manner, and has support for different types of transformations. VIATRA offers a powerful editor for the development of model-queries, a code generator for easy integration of queries into Java based services or applications. It also provides a results view for the evaluation of queries and analysis of the query results.
VQL To execute model queries, VIATRA provides a dedicated query language based on the graph pattern formalism. The VIATRA Query Language (VQL) provides an efficient and simple method to write complex model queries by using graph pattern concepts. Useful features offered by VQL are a quick exploration of model, inverse, calculation and transitive closure. A VIATRA query consists of a graph pattern which defines a few variables referring to classes of the semantic model and the pattern body provides a list of constraints for the pattern matching process. The queries can be evaluated at runtime by calculating pattern matches. A pattern match binds all (output) variables to EObjects (or attribute values) in a way to ensure that the constraints of the pattern are satisfied. The set of matching pairs w.r.t a pattern includes the list of bindings where all the defined variables are matched with some value in the given instance model.
Example 3.3. Figure 3.6 shows an example of VIATRA query written to find matches (based on the described pattern) for a workflow element from the provided model. The illustrated pattern consists of a variable a mapped to an EObject ActivityBlock. The defined variable is matched with the list of values (e.g., the name of Activity Blocks) in the provided instance model.
Figure 3.6: A sample of VIATRA query Pattern
23 3.2. Well-formedness Constraints and Model Transformations
For the evaluation of results for the applied queries on a given instance model, a results view is offered by VIATRA which displays the set of matches found during the query execution. It also helps with analysis and troubleshooting of written query patterns.
Validation Another helpful feature provided by VIATRA framework is the definition of valida- tion constraints for the provided instance model. This feature helps to thoroughly validate the given model for the supplied validation constraints and highlights the violation of constraints using defined severity symbols. The defined pattern for the validation rules play a vital role to locate the problematic elements in the model and the supplied parameters (in the pattern body) guide the display of results for the end-user.
Example 3.4. The Figure 3.7 is an example for VIATRA validation constraint declaration. Here the constraint is added to highlight if there are duplicate elements detected for the given workflow model. Therefore, the graph pattern aims to detect instances of the erroneous case when two different ActivityBlocks share the same name and to display an information alert for the user. Here, the key-value lists the parameters which determine the objects (such as ActivityBlock) that need to be attached with the constraint violation. The message field is supplied with the information to display for the user when the breach of defined constraint is detected, and the severity field is used to notify whether it is a warning, error or info. The targetEditorID field is supplied with the ID of the concerned eclipse editor (such as ActivityEditorID as shown in the below figure)), where the validation configuration has been setup.
Figure 3.7: An example of VQL Constraint for validation
24 3.2. Well-formedness Constraints and Model Transformations
Object Constraint Language
The Object Constraint Language (OCL) [36, 51] is a declarative language that defines rules for various models such as UML and EMF. OCL is a text-based language that helps to define constraints or query expressions for the well-formedness in case of MOF or metamodels. The expressions or queries defined with the Object Constraint Language (OCL) [36, 51] prove helpful in finding out vital information which is not presented by the model itself (to avoid over- crowded data). The important characteristics of OCL are following:
• No side-effects: OCL is a specification only language and its expressions simply return the data represented in the latest state of model without any side-effects. Therefore, the eval- uation of an OCL query does not modify the state of a model. However, an OCL expression has a provision to specify a state change in post-condition expressions;
• Typed language: OCL is a strongly typed language (e.g., an integer value cannot be compared to a string value);
• Declarative language: OCL is a declarative language and hence does not specify control flows;
• Atomic: OCL expressions are also referred as atomic which means that the state of model does not change during the evaluation of OCL expression;
OCL expressions are written using constructs available in the language to specify the scope of an expression, pre-conditions and post-conditions applicable on OCL operations. OCL statements represents the following main concepts:
1. Context: The context of the OCL statement defines the class for which the following statements are valid;
2. Property: The property in an OCL expression represents a characteristics within the context (e.g., an attribute of the class is a property);
3. Operation: an operation is a construct that applies on the property (e.g., arithmetic operation, set-oriented);
4. Keywords: Keywords are OCL reserved words such as if, then, else, and, or, not, implies which are used to specify conditional expressions.
25 3.2. Well-formedness Constraints and Model Transformations
3.2.2 Model transformation techniques
The Graphical Workflow Editor (GWE) relies on the Java API provided by VIATRA Query frame- work [23, 67] to carry out model-to-text (M2T) transformations. Hereby, I give an overview of some popular model transformation technologies which could potentially be used for that purpose.
Native Java transformations
A model transformation refers to any program that can operate on a model to generate a mean- ingful artifact and can be implemented using any general-purpose programming language such as Java. The Java transformation offers a simple, native programming interface to define the trans- formation process with the Java programming language. Java transformation is used to quickly define simple or moderately complex transformation functionality without advanced knowledge of the Java programming language. A Java API is provided by VIATRA Query framework to carry out the model transformations by allowing an easy integration with any Java based service or application. The queries are executed on provided instance models using VIATRA transformation API which also notifies the changes in the matching results. The Query Engine is the vital component of VIATRA Transformation API, which is responsible for loading query specifications, evaluating and presenting the matching query results.
Native transformations with VIATRA API For the transformation process, VIATRA API requests for (1) an instance model which is referred by the scope, initialized by an instance of EMFScope, (2) a group of specified queries (in the form of generated query matcher classes by the VIATRA query project) to be run on the given model. Generally, the code files generated by the query project represents the specified query patterns which consists of the match and matcher classes for the defined constraints. As depicted in Figure 3.8, Query Engine is initialized by loading an EMFScope. The program- ming of the VIATRAQueryEngine.on method directs the creation of a query engine per scope. As discussed earlier, the next step is to prepare the query engine by loading all specified queries that will drive the transformation of model-to-text process by providing matching results. Furthermore, during the execution process, the query engine is requested for the matching results of supplied queries, with the help of a pattern matcher API. The pattern matcher API provides a method called getAllMatches() to find and return the set of match objects for the
26 3.2. Well-formedness Constraints and Model Transformations
Figure 3.8: Overview of runtime components of VIATRA Query [23] given parameters (as illustrated in below example).
Example 3.5. Figure 3.9 provides an example of Java transformation (Model to Text) based on VIATRA query API. The example shows that VIATRA query engine provides matches from the selected workflow model for the present workflow elements and using Java programming, the result is printed into a JSON file.
Figure 3.9: A sample of Java Transformation based on VIATRA Query API
Xtend
Xtend [24, 30] is a statically-typed programming language which translates to regular Java code. In contrast with other JVM languages, Xtend has zero interoperability issues with Java. Xtend is very concise, easily readable and very expressive. It has a small library that is just a thin layer to provide useful utilities as well as extensions on top of the Java Development Kit (JDK) [1]. Xtend methods can be called from Java in a completely transparent way. From the syntactic and semantic perspective, the basics of the Xtend language is Java but with enhancements on
27 3.2. Well-formedness Constraints and Model Transformations multiple features such as extension methods for the enhancement of closed types, powerful switch expressions, efficient white space handling in template expressions, type inference etc. Xtend provides a modern Eclipse-based IDE closely integrated with the Eclipse Java Develop- ment Tools, including features like call-hierarchies, rename refactoring, debugging and many more. Unlike ATL [30], Xtend has no particular language constructs for the writing of model transforma- tions. However, because of the wide variety of general programming language (GPL [56]) constructs, Xtend is an efficient language for the transformation of models. Xtend specifies the transformation rules as methods in the program. It defines the source as the input parameters for the method (containing transformation rules) and return value as the target for the transformation.
Acceleo
Acceleo [2, 15] is an open-source code generator from the Eclipse Foundation that promotes a model-driven approach to build applications. For the model-to-text transformation, Acceleo follows MOFM2T [50] standard. This code generation language uses a template-based approach where a (user-customizable) template is a text from an arbitrary target language (e.g., Java, C, Python) where certain parameters are substituted with elements accessed by navigating the inputs models (which is compatible with EMF). Acceleo implements OCL expressions for the navigation purpose. Acceleo provides tools for code generation from EMF-based models. It offers an incremental generation feature which allows generating and modifying a part of the program along with possibility to re-generate code keeping intact earlier changes.
Figure 3.10: An overview of Acceleo transformation architecture [15]
Acceleo contains a code generation module editor with syntax highlighting, completion, real- time error detection and refactoring. The Acceleo debugger enables to pause code generation with a break-point, and to check the state of the variables and then move step by step during a
28 3.2. Well-formedness Constraints and Model Transformations generation to identify problems. The profiler allows observing all the instructions executed during the generation, the number of times these instructions are already executed and the time taken by each of these instructions. The Acceleo engine is capable to compute traceability details of all the elements participated in the generation of a result file.
ATL
ATL (ATLAS Transformation Language) [16, 30] is a model transformation language and toolkit which is developed and maintained by OBEO and AtlanMod. In the scope of Model-Driven Engi- neering (MDE), ATL provides ways to produce a set of target models from a set of source models. It can be used to bridge between standards and tools, to refactor models, to refine conceptual models into a detailed view, and to verify consistency among rules. ATL is one of the widely used DSL for transformations of models. ATL is a declarative as well as imperative programming language. The declarative style lets the users specify transformations as mappings between elements of the source and target models. An ATL transformation program is a set of rules specifying how the source model should be navigated to match the model elements of interest, and create and initialize the target model ele- ments. The ATL language toolkit which integrates nicely into the Eclipse IDE, provides constructs to specify rules that navigate the source model and create target model elements. A module is the core construct of the ATL transformation program and has following sections:
1. Header: The header section defines attributes that are related to the transformation module;
2. Import: The optional import section allows inclusion of reusable modules (user defined or from ATL library);
3. Helpers: Helpers are similar to methods in Java programming language and are included in transformation expressions;
4. Rules: Rules are expressions that define the transformations from source model to target model;
29 3.3. Version Control Systems
3.3 Version Control Systems
GWE collaborates with Version control systems (VCS) [41] to implement a dynamic library of re- usable workflow elements. Version control systems are key components in most software engineering projects. A VCS keeps track of all the changes made in the code by a team of developers in a repository containing all project files and associated data. Few important benefits of version control systems are listed below:
• Change history: VCS keep track of all changes made in the source files. Change history helps to understand how the code has grown over time.
• Releases and tags: VCS has a concept of releases which helps teams to manage their code production workflows [31]. Tags in a VCS is an identifier applied on a baseline of code and makes maintaining releases easy.
• Work breakdown: VCS allows for structured breakdown of the development among the members of the team. Everyone works on a working copy of the code from the repository and merges their work when a significant progress is made.
The kinds of version control system that are widely used in software engineering community are a) Centralized version control system and b) Distributed version control system and discussed in detailed in the following sections.
3.3.1 Centralized Version Control Systems
In a centralized version control system, a central server has all the project files and data required to manage history. Developers make a copy of the files in the central server and work on them in isolation and merge their work back into the central server development when it is complete. Subversion (in short, SVN) [7] is the most popular centralized version control system and the key components of SVN are discussed below.
Repository A repository is the central part of a version control system (VCS). It is the common place where developers store all their work. Repository stores not only files but also history. It is accessed over a network, acting as a server and version control tool serving as a client. The clients download files from the repository, store their changes to the repository which can be retrieved by other clients. By saving the modifications, a client makes these adjustments available to the
30 3.3. Version Control Systems other members of a team, and by retrieving changes, a client takes other person’s developments as a working copy.
Branches The branching is used to create another line of development. It is beneficial when a person wants the development process to divide into two separate directions. For instance, when a version 5.0 is released, one might want to create a branch so that the development of 6.0 features can be kept separate from 5.0 bug-fixes.
Commit changes Commit is a process of storing changes from a private workplace to the primary server. After the completion of commit operation, the applied modifications become accessible to all the users. The users are able to retrieve these adjustments by their working copy. Commit operation need to be completely successful to be visible for the users.
Working copy It is a snapshot of the central repository. The central repository is accessed by all the team members, however nobody modifies it directly. In fact, each person accesses the working copy. It is also known as a personal or local repository where a user can implement things without affecting the other teammates.
Trunk The trunk is a folder dedicated to the central development performed by the team of developers for a common project.
Tags The tags directory is used to store named snapshots of the project. It provides informative names to a particular version of developed software available in the repository.
Figure 3.11: An overview of Centralized Version Control System [41]
Figure 3.11 illustrates a centralized version control system. The repository represents the storage system on the server (remote or local) which holds all the files of the project. Every developer in
31 3.3. Version Control Systems the team connects to the server and creates a copy of files, referred to as working copy, locally on his/her machine. Developer performs a commit operation to store changes on the server and other developers perform an update operation to get the changes to their working copies. A centralized version control system offers a simple architecture for change management with a centralized repository, but has following drawbacks
• Frequent connection to server: A developer using the centralized version control system need to be connected with the repository to store any changes. In an active development project, where large number of changes are made everyday, a continuous connection with the repository will be needed.
• Single point of failure: Single point of failure which is typical of any centralized system affects SVN as well. In event of a repository corruption, entire data of the project will be lost.
3.3.2 Distributed Version Control Systems (Git)
In contrast to centralized version control system, a distributed version control system has a lo- cal copy of the complete repository referred to as clone on every contributors machine [11, 48]. Figure 3.12 illustrates the repository distribution in a distribution version control system. The repository clone on the contributors computer has all the files and the associated metadata of the central repository and thus enables the contributor to work completely independent of the central repository. A contributor can store changes in the local repository by making commits. To update the local copy of a repository, one can do a pull from the main repository and to store the changes in the main repository one has to perform a push operation. Few popular distributed version control systems are git, GitLab, GitHub. Having clones of the entire main repository in the local drive has following advantages:
1. Fast performance: The contributor generally works with the local repository during a development day and pushes or pulls from the main repository only few times. The commit and update operations performed on the local repository are very fast.
2. Clean central repository: A contributor pushes changes to the main repository only after changes are successfully tested on the local repository. Contributors can share their repositories with others for review before affecting the main repository. Workflows defining
32 3.4. Summary
Figure 3.12: An overview of Distributed Version Control System [41]
a specific review and approval steps can be defined using tools providing these additional features.
3. Easy modification: Since every contributor has a full copy of the project repository, they can share changes if they want to get some feedback before affecting changes in the central repository.
4. Fail-safe: In contrast to the centralized version control system, a failure of the central repository can be recovered from one of the local repositories and results in very minimal or no data loss.
GWE uses GitLab repositories for dynamic workflow library which stores the reusable workflows designed using the workflow editor developed in this thesis.
3.4 Summary
To conclude, this chapter provided a brief introduction about the underlying technologies and concepts for the graphical workflow editor as well as the related technologies. The following chapter will give an overview of user-interface and features of the graphical workflow editor.
33 Chapter 4
Graphical Editor for Tool Integration
Critical cyber-physical systems like aero-derivative and large gas turbines use variety of design, analysis and optimization tools to run complex sequence of tasks as a workflow in order to meet the product specifications. The Graphical Workflow Editor (GWE) demonstrated here provides a graphical way to create tool integration workflows and then generate a definition file (in JSON for- mat). It also collaborates with version control system (VCS) to access a dynamic workflow element library (WEL) and to upload the output definition file to the workflow definition library (WDL). This chapter describes the overall architecture for GWE (Section 4.2) (designed in collaboration with my supervisor and Siemens) followed by a high-level descriptions of the key features of GWE:
1. user-friendly dashboard for the accessibility of all features (Section 4.2);
2. user-interactive wizards for the configuration of a new workflow (Section 4.3);
3.a dynamic palette for the live listing of workflow elements (Section 4.4);
4. an auto-expanding grid-layout for a compact overview of workflow (Section 4.5);
5. auto-connections between type-compatible workflow elements (Section 4.6);
6. integration with VCS by providing persistence of workflow elements and definition files stored in a version control system (Section 4.7);
7. persistence of the workflow definition files on the local drive for the offline review by different stakeholders from inter-disciplinary teams and on GitLab for the execution of workflow using Workflow Execution System (WES) (Section 4.7.1);
8. re-usability of existing workflow definition files (Section 4.7);
34 4.1. Architecture of Graphical Workflow Editor
4.1 Architecture of Graphical Workflow Editor
In the Graphical Workflow Editor architecture (Figure 4.1), the overall process of definition, persis- tence and execution of a workflow consists of three main functional steps such as: (1) design-time components provide graphical representation and definition of an inter-disciplinary workflow, (2) a version control repository serves as a persistence layer to provide storage and change management for workflow elements as well as workflow definition files, (3) run-time components support the execution of hierarchical workflows designed in Step (1).
Figure 4.1: An overview of a Graphical Workflow Editor architecture
Design-time During the design-time, GWE provides a user interface to define a tool integration workflow by using a dynamically populated palette and arranging elements in a hierarchical manner along a grid layout. The actual workflow elements of different engineering disciplines are stored (in a JSON format) in a version controlled Workflow Element Library (WEL). After a graphical workflow is defined, GWE provides an automated model-to-text transformation to generate a work- flow definition file (in JSON), which is committed and pushed to the Workflow Definition Library (WDL) in the version control system (VCS).
Version controlled repository Both workflow definition and execution subsystems are inte- grated with a version control system (VCS) such as GitLab. GWE mainly uses two libraries: (a) the Workflow Element Library which persists workflow elements defined by different disciplines, and (b) the Workflow Definition Library which persists the workflow definitions themselves gener- ated by GWE in a JSON format. The Workflow Execution System (WES) accesses and loads these definition files from corresponding library prior to execution.
35 4.2. User-Friendly Dashboard
Run-time The Workflow Execution Systems (WES) are hosted on local or remote machines run- ning various operating systems (e.g., Windows, Linux). During run-time, WES loads the workflow definition file from the version-controlled library (WDL) and executes the hierarchical workflow by supplying design data or simulation parameters as input for the design and analysis of gas turbines.
4.2 User-Friendly Dashboard
The dashboard (see Figure 4.2) of GWE provides an overview of the different features of the workflow creation process and enables a smooth integration with VCS.
Figure 4.2: Dashboard view of graphical workflow editor
As depicted above, the dashboard offers easy accessibility to the available features of GWE by providing user-interactive hovering icons along with self-explanatory text. The dashboard presents following key feature buttons:
1. Set GitLab Preferences for the integration with version control system (VCS) ;
2. Create New Workflow for the design of a new multidisciplinary workflow;
3. Save Workflow to Local-Drive for the persistence of workflow on the local system for the offline review;
4. Upload Workflow to GitLab for the persistence of workflow in the VCS and execution using Workflow Execution System (WES);
36 4.3. Interactive Wizards for Workflow Configuration
5. Open Existing Workflow for the re-usability of workflow available in the VCS or local-drive.
6. Open Sketch Area for manual accessibility of sketch window for the editing of currently started workflow (e.g., if user has closed the sketch window intentionally or unintentionally).
4.3 Interactive Wizards for Workflow Configuration
GWE offers interactive wizards (as captured in Figure 4.3) for the configuration of a new workflow for the design and analysis of gas turbines.
Figure 4.3: Create new workflow wizard: Page 1 and Page 2
After the setup of version control system (VCS) preferences (see detailed description in Sec- tion 4.7), GWE allows engineers to configure a new workflow for the design and analysis of gas turbines with the help of a wizard with multiple pages (see Figure 4.3) by clicking Create New Workflow button on dashboard. The first and second page of the wizard provide multiple fields to enter or select important information related to the workflow such as:
1.a display name for the overall workflow;
2.a description or rationale for workflow;
3.a design template to refer at the time of execution of the workflow for design and analysis;
4. a value for fidelity which defines the degree of accuracy to which final outcome of overall design and analysis workflow is expected;
37 4.4. Dynamic Palette
5.a version definition for the new workflow which helps to differentiate available workflows;
6.a discipline category to which this workflow refers (e.g., Performance, Turbine, Combustor, Compressor, Secondary Air System, Engine etc.);
7. a high-level Engine Design Structure (EDS) context which presents a common functional view of a particular gas turbine version to the engineer and also provides the top functional reference for a workflow in the Workflow Execution System (WES).
Once the basic information for the workflow is filled out and Finish button is clicked, GWE automatically opens a grid-layout window (a Sketch Area) with a dynamic palette for the graphical representation and design of the initiated workflow. At this step, the very first workflow setup may take some time due to the creation and initialization of Sirius based Modeling project at the back-end. Once the initialization and setup is done, the following workflow creations will be fast. After this step, user can start designing the desired workflow by selecting latest available workflow elements as detailed in the next section.
4.4 Dynamic Palette
GWE offers a dynamic palette (see Figure 4.4) which fetches latest workflow elements from Work- flow Element Library on VCS (e.g., GitLab).
Figure 4.4: Dynamic list of workflow elements Figure 4.5: Selection of workflow element for from VCS the placement on grid-layout
In contrast with traditional workflow modeling tools, GWE offers a dynamic palette which provides live listing of workflow elements from the Workflow Element Library (WEL) stored in
38 4.5. Dynamic Grid Layout the VCS using a secure channel provided by standard JGit module. Since the palette is continu- ously synchronized with the library elements stored on the VCS, engineers are ensured to create a workflow using latest available workflow elements. The palette of GWE contains tools such as (a) Add Activity Block (e.g., workflow element), and (b) Connector. When we drag and drop a workflow element from the palette onto the grid layout using the Add Activity Block tool, GWE opens a selection wizard as captured in Figure 4.4. The selection wizard consists of expandable multi-disciplinary groups (e.g., Performance, Compressor, Turbine, Casing etc.) and each group provides the live list of workflow element names available in the Workflow Element Library (WEL) on GitLab (see Figure 4.9). GWE also provides a search filter to look for a particular workflow element in order to avoid iterating over each list provided in a group. After the selection of the desired workflow element (as shown in Figure 4.5), GWE places it on the grid-layout.
4.5 Dynamic Grid Layout
The graphical workflow editor (GWE) presents a dynamically expandable grid-layout which pro- vides an easy to understand overview of overall workflow as illustrated in Figure 4.6. GWE provides dynamically expandable grid-layout, which adds new cells and columns as the workflow elements are added to the composition area (see Figure 4.6). GWE verifies if the new workflow element is added to the last column (or row) of grid layout, then it automatically adds a new column (or row). Therefore, the grid layout will be expanded depending on the number of workflow elements added to the workflow. GWE presents an initial grid layout with 3x3 matrix of rows and columns. As the workflow element is added to the last row or column of grid layout, then it automatically adds another row or column, respectively. Therefore, GWE allows the automated extension of the grid layout as the number of elements increases in a workflow. This dynamic behavior of grid-layout provides an intuitive and compact overview of the design and analysis workflow.
4.6 Auto-wiring of Workflow Elements
GWE establishes automatic connections between workflow elements as these are placed on the grid-layout.
39 4.6. Auto-wiring of Workflow Elements
Figure 4.6: An overview of two workflows on grid layout
Compared to traditional workflow definition systems, GWE facilitates automatic connections between workflow elements based on their type compatibility using a technique built on relation- based edge mappings provided by Sirius framework as an underlying technology. When a new workflow element is added to the grid layout, GWE compares properties of the selected element with those of the existing workflow elements and searches for a matching pair of I/O ports. If successful matches are found, then it automatically establishes connections for the newly added element with the other workflow elements. The outer most (left and right) borders of grid layout act as input and output lanes, respectively, for the overall workflow. Therefore, the ports which are not matched during the verification process are directly connected with either input or output lane depending on their type (input port or output port). Auto-wiring is illustrated in Figure 4.7a. One workflow element is already placed on the grid layout with one output port (Performance Data) connected to the output lane. When a new element (Secondary Air System, SAS) [54] is added to the workflow (see Figure 4.7b), the output port of Performance element is automatically re-connected to the input port of SAS element based on their
40 4.6. Auto-wiring of Workflow Elements
(a) Before step (b) After step
Figure 4.7: An overview of auto-wiring on grid layout type compatibility. Moreover, further input/output connections are also established automatically to complete the workflow.
Figure 4.8: An overview of algorithm for auto-wiring
Further, as illustrated in Section 4.5, the top workflow in Figure 4.6 (created by engineers of the industrial partner) contains two model elements, namely, Performance and Secondary Air System while all the connections are automatically established. Informally, Performance model element analyses the power curve based on the applied pressure and temperature (of air) and calculates the performance data across the compressor and turbine. It sends this data to Secondary Air System [54] as an input to compute the optimized cooling bleeds (air holes) for a gas turbine at varied temperature and pressure points. In the end of this analysis process, the Whole Engine Model receives the inputs from both Performance Model and Secondary Air System to perform the thermal analysis for the whole engine of gas turbine for better efficiency and performance. Hence, in order to complete the top workflow of Figure 4.6, a model element (Whole Engine) is added to the grid layout and GWE performs the auto-wiring algorithm (configured in Figure 4.8) which compares the properties of new element (target) with the already existing elements (source) on grid layout using the target finder expression and looks for matching pairs based on type com-
41 4.7. Dynamic Workflow Library for Re-usability patibility. In this case, GWE finds two matching pairs, therefore, it automatically connects the outputs of Performance and Secondary Air System with the inputs of Whole Engine Model (as shown in the bottom of Figure 4.6) and all other connections are also automatically completed. Furthermore, along with dynamic nature of connections, GWE also allows to alter the auto- matically created connections and draw manual connections between workflow elements using a Connector (tool) from the palette. Once all the connections are completed (automatically or man- ually), the workflow is saved by clicking on Save from File Menu or using shortcut (CTRL+S). After this step, the graphical representation of a multidisciplinary workflow is saved and it is ready for the generation of a workflow definition file (JSON format). The generated file can be further reviewed offline by the engineers of multidisciplinary teams or can be directly executed in the Work- flow Execution System (WES) by uploading the workflow definition to the version control system (VCS). The process of workflow definition file (JSON format) generation and upload to GitLab is illustrated in the Section 4.7.1.
4.7 Dynamic Workflow Library for Re-usability
The graphical workflow editor (GWE) is integrated with a version control system (e.g., GitLab) which adds dynamic characteristics to the tool.
Figure 4.9: VCS preference dialog of Graphical Workflow Editor
When Set GitLab Preferences button is clicked, GWE provides a preference dialog (see Fig- ure 4.9) for the user to setup (1) the preferred Workflow Element Library (WEL) URL persisted in the VCS which contains the workflow elements, (2) the preferred branch name for the cloning of data from WEL, (3) the local path for the cloning of workflow elements to a local drive, (4) the preferred branch name for the uploading of data on Workflow Definition Library (WDL) persisted
42 4.7. Dynamic Workflow Library for Re-usability in the VCS, (5) the SSH-RSA Private Key for the communication with VCS. Once all the required information is provided, Apply and Close button is clicked for the completion of VCS setup. The provided preferences w.r.t each field are cached until they are changed by the user at any point of time. This feature provides secure communication between GWE and the version control system (VCS) using SSH features of standard JGit module for Java. Therefore, it eliminates the require- ment to enter username and password while accessing VCS, instead, using SSH key pairs for the direct and secure connection with the help of JGit methods.
4.7.1 Save workflow
GWE provides two different ways for the storage of generated workflow definition file. It is possible to upload the workflow to the version control system (such as GitLab) as well as to save it on a local drive (see Figure 4.10).
Figure 4.10: Save workflow on local drive
GWE provides Upload Workflow to GitLab button on dashboard, to upload the final workflow to the Workflow Definition Library (in the VCS) which was set in the GitLab Preferences of the workflow editor (see Figure 4.9). Once user clicks on this button, GWE generates the workflow definition file (JSON format) using VIATRA queries and transformations, and pushes the generated file to the preferred version control system such as GitLab. Workflow Execution System (WES) is also integrated with GitLab, therefore, as soon as the workflow definition file is uploaded to GitLab, it becomes available for the execution. GWE provides Save Workflow to Local-Drive button on dashboard, to save the workflow def- inition file on a local drive. As user clicks on Save Workflow to Local-Drive button, GWE opens
43 4.8. Summary a wizard (see Figure 4.10 ) for the path selection on local machine. Once the local path is chosen and applied, a workflow definition file (JSON format) is generated at that path. The workflow definition file is used for offline review by engineers of interdisciplinary teams before executing it in Workflow Execution System (WES).
4.7.2 Reusable workflow
The graphical workflow editor also enables to open an existing workflow definition file (JSON format) and allows to edit this by the addition or removal of a workflow element (see Figure 4.11).
Figure 4.11: Open an existing workflow on grid-layout
As illustrated in above Figure 4.11, GWE opens a dialog box, upon clicking Open Existing Workflow button, to browse and open a desired workflow definition file which already exists on the user’s machine in the cloned repository. Once a file selection is made and Open button is clicked, a graphical representation of workflow is opened on the grid-layout. Therefore, it enables the user to edit this workflow by adding more workflow elements from the dynamic palette and to generate a new workflow definition file with the applied changes.
4.8 Summary
This chapter provided an overview of all features of GWE from the user perspective along with example snapshots from the actual tool. It provided a good insight of the appearance and features of tool. The details of implementation process of GWE will be covered in the next chapter.
44 Chapter 5
Feature Implementation for Graphical Editor
This chapter describes the implementation steps I performed for the development of the Graphical Workflow Editor (GWE) starting from the definition of DSL for the chosen domain, until the building of graphical editor based on the defined domain model. The below sections provide details about the (1) definition of the DSL for Gas Tubines, (2) graphical mapping of DSL classes (such as ActivityBlock) using Sirius, (3) setup of dynamic workflow library for re-usability, (4) setup of grid layout, (5) setup of dynamic palette, (6) implementation of auto-wiring, and (7) implementation of workflow definition file generation.
5.1 Domain Specific Language
GWE primarily aims to assist the work of mechanical engineers in designing aero-derivative gas turbines. The domain specific language for this editor defines the concepts of design and analysis process of gas turbines in the form of Ecore metamodels. This chapter provides the implementation details for the core features of GWE.
5.1.1 Metamodel
The domain model for the design of gas turbine workflow (shown in Figure 5.1) has been defined with the Ecore language. This EMF model defines Activities (also called workflows) that consist of various types of Activity Blocks (workflow elements) which are further composed of various Input and Output parameters. The design and analysis process of aero-derivative gas turbines includes a sequence of steps to be executed. These steps (termed as Activity Block in the engineering domain) are the actions performed by multi-disciplinary teams and their respective analysis tools. Each Activity Block
45 5.1. Domain Specific Language
Figure 5.1: Metamodel for the abstract syntax of Gas Turbine Workflows requires various inputs to perform the desired analysis and generates certain outputs after the successful completion of each analysis. These outputs are fed to the next Activity Block as inputs (as shown by the from/to relationships in the metamodel), and hence the process goes on until the design and analysis cycle is completed. A particular output of an Activity Block can be fed to multiple Activity Blocks as input if it matches their requirement to perform the analysis. The Input and Output classes have their predefined attributes such as (name, type, display-name, description, etc.), which play a vital role in deciding the relationships between workflow elements.
Figure 5.2: Metamodel for the concrete syntax of Gas Turbine Workflows (grid layout)
46 5.1. Domain Specific Language
The Figure 5.2 provides another excerpt of the metamodel, which defines the core structure of the grid layout. As illustrated in the metamodel for layout, it consists of a layout canvas that contains (0 or many) columns and cells. Each cell may contain (0 or 1) Activity Block, which helps to avoid overlap of elements in a cell.
5.1.2 Java Code Generation
Eclipse EMF [17] allows the creation of an editor for the domain model by generating the Java code for all respective classes and attributes. The Model Code, Edit Code and Editor Code can be generated from the Ecore diagram. Two Eclipse Plugin projects (with extensions .edit and .editor) are created once the generate code action is successfully completed. The generated code will contain three major components:
• workflowEditor.model provides the interfaces and the factory to create instances of classes in the metamodel. This central factory provides createObjectName() methods for the creation of objects. The interface also provides getter and setter methods for each attribute defined in the metamodel;
• workflowEditor.impl provides the concrete implementation for the EMF model defined inter- faces;
• workflowEditor.util provides the adapter factory for the model supporting adapter create method for the defined classes in the metamodel.
A @generated tag is by default attached with every generated method and any further modifi- cation for these auto-generated methods require this tag to be removed.
5.1.3 Graphical Representation for DSL: Sirius
On top of the domain model Figure 5.1, Sirius is used for the development of a graphical editor. Sirius [21] [22] allows specifying dedicated representations and associated tooling for the desired modeler. Figure 5.3 illustrates the relationship between EMF and Sirius modeling process. The implementation process (on Sirius end) involves the creation and configuration of a viewpoint specification model (VSM) that defines the structure, appearance and behaviour of the graphical modeler. A viewpoint specification model enables the specification for a group of viewpoints and
47 5.1. Domain Specific Language their representations (such as diagrams, trees, etc.). The resulting graphical editor enables the end-user to visualize, create and edit a workflow model.
Figure 5.3: Relationship between EMF and Sirius implementation for a graphical modeler
The important phases for creating VSM Configuration are the following ones:
Viewpoint A viewpoint consists of specifications configured for the representations and it is considered as one of the important components to be defined at the beginning of a Sirius project.
Representation A representation provides the visualization of the modeled data. It provides the definition of the structure, appearance and behaviour of the editor. By default, Sirius provides support for four kinds of representations, such as diagrams, tables, matrices and trees. GWE implements diagram style for the representation purpose.
Mapping A mapping defines the graphical representation for semantic model elements such as ActivityBlock, Layout, Cell, Column etc. Each representation type offers different kinds of mappings. For instance, diagrams offer container mappings (one of the offered mapping styles) for the graphical
48 5.2. Graphical Representation of Workflow Elements representation of semantic model elements.
Style Styles helps to define the look of the mapped elements in terms of the shape, size, colour, font for labels etc.
Tool Tools help to define behavior for the modeled elements on the diagram. The tools are generally accessed from the palette. Examples of tools are addition or deletion of an element, connectors etc.
5.2 Graphical Representation of Workflow Elements
There are various types of graphical elements supported by Sirius diagrams [22] such as Container, List, Region, Node, Bordered Node, Edge etc. These graphical elements are represented with the help of mappings (e.g., node mapping, container mapping, etc.). A mapping is specified in the viewpoint specification model that identifies a subset of the elements in the corresponding semantic model and associates a graphical representation to them, i.e., it provides a mapping of semantic elements onto some graphical representation.
Figure 5.4: A snapshot of created Container Element (Activity Block) in VSM
In order to represent workflow elements (called Activity Blocks at the industrial partner), the container mapping style is used by GWE (as shown in Figure 5.4). A container mapping specifies the representation of model elements graphically as containers and these containers can contain other nodes (even containers). A container can have bordered nodes which appear on the border of the container, for example, to represent the I/O ports. This container mapping style is well suited for the Activity Block (workflow element) design requirement because it consists of inputs and outputs along with their respective I/O ports. Therefore, Activity Block is a nested container: the outermost container for the workflow element itself, the innermost containers for inputs and outputs along with their bordered ports.
49 5.2. Graphical Representation of Workflow Elements
Figure 5.5: Graphical Element Mapping with Domain Model (Class)
Workflow Element Mapping The VSM’s container element (i.e., activity block) needs to be mapped with a semantic domain model element (for example, domain class ActivityBlock) in the Properties section (as shown in Figure 5.5). A semantic candidate’s expression may also be used for the mapping and it is evaluated at runtime to provide a set of elements in the semantic model. This list of elements is filtered using the domain class specified in the mapping. Moreover, a special “list mode” for the container is used by setting the children’s presentation attribute to List in the configuration. The List containers are visualized in a certain way: only the labels of the immediate sub-nodes are considered and presented in a vertical list.
Figure 5.6: Style Specification for the Graphical Workflow Element
Workflow Element Style For containers, there are three kinds of styles available for the graph- ical representation, such as gradient, parallelogram and custom image. The gradient style is used to represent an Activity Block, and all the style specifications are set in the Properties section such
50 5.3. Setup of Dynamic Workflow Library for Reusability as Label, Color, Border style etc. (see Figure 5.6) Similarly, the sub-containers (for input and output) are configured following the above steps, and their respective styles are set to differentiate between them. Bordered nodes are used to represent the I/O ports.
5.3 Setup of Dynamic Workflow Library for Reusability
GWE provides a dynamic workflow element library with the help of a version control system (such as GitLab). This feature enables the accessibility of the latest workflow elements present in the remote repository, as well as the reusability of previously created workflow models. It is important to establish safe communication between the GWE and remote repository to mitigate cyber threats. To access remote Git repository securely, a commonly available JGit [20] package has been used, which offers easy integration with GWE. Authentication in JGit [20] is mostly safe with native Git because of secure protocols like SSH and HTTP(S). JGit supports authentication methods like ”SSH with Public Key” and ”SSH with Password.” GWE applies the first method and authenticates itself using SSH keys in order to avoid requirement of password authentication, which could take a longer time in a practical scenario. To open a Git repository, cloneRepository() command is called as shown in Figure 5.7.
Figure 5.7: Git cloning
The implementation of the TransportConfigCallback method helps to setup the secure commu- nication to access the remote version control system (VCS), as shown in Figure 5.8. This method implements the configuration for SSH communication using standard Java library such as JGit and ignores the verification of host keys. By the default configuration, it retrieves the id RSA key file from the /.ssh folder on the home directory of user. Though, it is also possible to configure another location for the SSH key or setup of a password secured key. The implementation of the secure communication using public key authentication requires the configuration of a session factory for the executed command. In this case, JGit is responsbile for directing the start and closure of secure
51 5.4. Setup of Dynamic Grid Layout
(SSH) communication to the abstract SshSessionFactory. As illustrated in Figure 5.8, using the method setTransportConfigCallback(), an interface named TransportConfigCallback is specified to intercept the communication process. Further, the method configure() is invoked prior to the setup of the secure connection, and passed on a param- eter of type Transport that starts the transfer of data between the local and the remote repository. Moreover, the abstract JSchConfigSessionFactory implements the Java module such as JSch to setup SSH connections while its configure() method is overridden. The JSchConfigSessionFactory gen- erally works well with OpenSSH, which is used by Git for the SSH implementation. It fetches the list of known hosts and private keys from their default locations in the user’s .ssh directory (such as (identity, id RSA and id DSA)).
Figure 5.8: SSH setup for Distributed Version Control System
Once the secure connection is set up, GWE clones the data from a remote repository to a local repository or drive. GWE continuously pulls the latest data by using Git command (e.g., Pull) and also pushes the created workflow models using Push command.
5.4 Setup of Dynamic Grid Layout
Sirius provides various types of standard layouts. However, GWE uses a customized grid-layout to provide an intuitive and compact overview of an engineering workflow. As referred to the
52 5.4. Setup of Dynamic Grid Layout metamodel excerpt (Figure 5.2), the grid layout is composed of columns and cells. Figure 5.9 provides an example of graphical mapping of layout classes in the Sirius model for their respective style configuration. GWE adds a dynamic nature to grid-layout by controlling the expansion of columns and cells through customized services (in Sirius). Initially, GWE provides a 3x3 grid (i.e. three columns and three rows with a total of 9 cells) and it automatically adds a new cell or column if a workflow element is dropped to last column or cell of layout. The shrinking of grid-layout at the deletion of an element is not implemented, however, it can be included as future work.
Figure 5.9: Graphical configuration of grid layout in Sirius
Figure 5.10: An excerpt of Sirius Service for the dynamic expansion of grid layout
Example 5.1. As shown in Figure 5.10, the Sirius service is invoked to compare if the selected
53 5.5. Setup of Dynamic Palette column or cell for the drop of workflow element is the last one in the layout. In case the condition is satisfied, a new column or cell is added to the layout as required. As per the domain model reference, a column is composed of cells, therefore if a new column is added, then the number of cells also needs to be added (to maintain the symmetry of layout).
5.5 Setup of Dynamic Palette
By default, Sirius provides a palette with a static list of elements. However, GWE provides a novel feature of a palette with a varying list of workflow elements, which is enabled by the continuous interaction and integration of GWE’s palette with a version control system (such as GitLab).
Figure 5.11: Setup of Dynamic Palette in Sirius
Sirius allows the use of Tools Section to define the dynamic behaviour of features of the graphical editor and these tools appear in the diagram’s palette after setup. The tools can be configured (as shown in Figure 5.11) such as Add Activity Block tool. GWE uses this tool (from the palette) for the selection and creation of a new Activity Block. When the Add Activity Block tool is used, it invokes the service method ActivityBlockSelectionWizardWithExpandBar() (as shown in Figure 5.11). Therefore, upon processing the mentioned Java method, it opens a selection wizard (with multiple categories as shown in Figure 4.4 in Chapter 4), which provides the list of latest workflow elements fetched from the cloned local repository. Every time the tool is invoked, the list of workflow elements is refreshed. From this wizard, the user makes a selection of a workflow element and it is added to the grid layout after processing the rest of element creation steps defined in the invoked method.
5.6 Implementation of Auto-wiring
Sirius provides Edges for the mapping of links between diagram elements. Sirius offers two types of edges that are configured with a different style of mappings:
54 5.6. Implementation of Auto-wiring
Relation-based edges The relation-based edges visualize a relationship between elements. For example in UML, containment or reference relationship is represented using a relation-based edge.
Element-based edges The element-based edges are configured using the mapping of a semantic model element that is defined to visualize the relation . For example in UML, an association between two classes X and Y is not represented by a reference from X to Y, but by an Association class that connects X and Y. This kind of association is represented using element-based edge. GWE defines relation-based edges between workflow elements after the verification of a matching algorithm, which is defined as a service. From the Sirius perspective, the properties such as Source Mapping and Target Mapping must be defined to specify a relation-based edge in VSM. These properties indicate the source and target graphical elements of an edge. Both properties may contain multiple mappings, and a few mappings may appear as both source and target. It is also required to specify the TargetFinderExpression in the properties section (as illustrated in Figure 4.8). This expression evaluates the target semantic element of the defined source (in the Source mappings field) and returns the list of target semantic elements to make a connection with the source. This expression may also return 0 results to refer that no edge is started from the mentioned element. Therefore, in case of GWE as illustrated in Figure 4.8 of Chapter 4, an edge will be drawn between each pair of the graphical elements ActivityBlock(1) and ActivityBlock(2) on the diagram where: ActivityBlock(1)’s mappings are defined in the source mappings and ActivityBlock(2)’s map- pings are defined in the target mappings.
Edge Style Sirius provides same style specifications (along with conditional styles) for relation- based and element-based edges. Sirius enables to specify: (1) style for the edges such as (solid, dash, dot or dash-dot etc.), (2) colour, (3) width (with the help of size computation expression), and other end-point decorations like arrowheads. All of these configurations are made using Properties section for the defined edges in VSM. Furthermore, Sirius offers following routing styles for edges:
1. Straight: A straight line segment is used for the drawing of edge between the source and target elements, except for the case where the source and target refer to the same elements. GWE uses the Straight routing style for the connections between workflow elements;
55 5.6. Implementation of Auto-wiring
2. Manhattan: Manhattan style uses vertical and horizontal segments to draw edge between elements. Both type of segments (horizontal and vertical) follow Straight style;
3. Tree: It is also referred as a special style case of Manhattan. This style is used in case of multiple target elements need to be connected from a single source element.
Apart from the edge mapping and style configuration, Sirius also enables users to define some pre-conditions or algorithms using Java services, and to invoke these services before the drawing of edges between workflow elements. This conditional edge drawing functionality in Sirius allows GWE to implement auto-wiring as discussed in the following examples.
Example 5.2. As shown in Figure 5.12, Sirius allows to configure Java services in the Tools Section. Here, the service setConnections() is setup to be invoked after the service ActivityBlock- SelectionWizardWithExpandBar() is called, while the add Activity Block action is performed. This service runs the matching algorithm defined at the back-end Java method to draw relation based edges between workflow elements.
Figure 5.12: An example of Auto-Wiring service setup in Sirius
Figure 5.13: An example of auto-wiring implementation
56 5.7. Implementation of Workflow Definition File Generation
Example 5.3. As shown in Figure 5.13, when the Sirius service setConnections() is called while a new workflow element is being added, then the defined Java program compares and verifies the matching criterias such as (name, data-definition) for the selected workflow element with the rest of elements available on the grid layout. The setConnections() method verifies:
1. If the name of output and input (of workflow elements) match, then it moves on to verify the next defined criteria;
2. If the data-definition parameter of output and input (of workflow elements) match, then relation based edge is drawn (between source and target).
5.7 Implementation of Workflow Definition File Generation
Once the graphical model for the design and analysis workflow is ready in GWE, then this model is used as a reference in the definition file generation (model to text) feature. GWE uses VIATRA [23] as a model transformation framework that provides efficient evaluation of model queries and supports the transformation of workflow model to text format. The following steps describes the implementation of model-to-text transformation feature using VIATRA.
5.7.1 Query Development Environment
The VIATRA framework provides a graph pattern-based language (VQL) for the development of queries for the evaluation. A graph pattern constructs a query with some parameters and includes a list of constraints in the body of the query pattern. The match set (final result) of a graph pattern lists the matching elements where all the constraints are satisfied that are defined in the pattern bodies.
Definition and Evaluation of Query A VIATRA query project is created, in the Eclipse setup at the host machine, for the definition of queries. It is an Eclipse plug-in project with already setup VIATRA dependencies. Further, a VQL file is created inside this project, to write pattern-based queries (as shown in Figure 3.6). To execute queries and evaluate the results, VIATRA provides a results view section that enables the loading and execution of instance workflow models. After the execution of queries, the code is generated, in the VIATRA Query project, based on the query specification classes that represent the original VQL specifications for the runtime API (see Figure 5.14). ”Every specification of query includes (1) a Match and Matcher nested subclass
57 5.7. Implementation of Workflow Definition File Generation for each pattern definition, and (2) a group class for each file that can be used to initialize all queries together, using the same Java class name as the original vql file.” (as referred in [23]).
Figure 5.14: Structure of the query generated code with Match and Matcher classes
Generally, the evaluation of queries in the Query Results View section is a manual process. To automate the query execution and evaluation task for GWE, VIATRA Query API is used, which allows to run and evaluate query results with the help of Java methods.
VIATRA Query API VIATRA Query API [23] provides an interface to execute queries on multiple workflow models, along with support for regular listening to the changes in the query results. To use the VIATRA Query API, a headless Eclipse application is created, and it is executed over queries written in the VQL file. The primary element of the API is the Query Engine that loads query specifications, performs set-up of indexes and, finally, generates the match results for queries. ”VIATRA Query API requires (1) a scope which represents the workflow model and (2) a set of query specifications. Further, the scope is initialized by wrapping an EMF ResourceSet within a new EMFScope instance.” For the query specifications, the generated matcher classes can be used, as illustrated in Figure 5.14.
Figure 5.15: Initialization of Query Engine
58 5.8. Summary
Initializing Query Engine Firstly, the query engine is initialized by loading an EMF scope. This is done using the following code segment shown in Figure 5.15 (the instance model file is already copied into the root of the queries project): Next, the query engine is prepared with all the queries that can be used (see Figure 5.16). The corresponding prepareQueryEngine() method generates all the indexes required for the pattern matches for each query set.
Figure 5.16: Preparation of Query Engine with All Queries
After the preparation of the query engine, the pattern matcher API (as shown in Figure 3.9) is called to return the set of matches for all queries. The resulting matches are printed into a text file (in JSON format) in order to complete the generation of the workflow definition.
5.8 Summary
To conclude, this chapter provided the required information about the implementation steps related to each feature of GWE. It described the technical concepts used for the implementation along with code snapshots for a better understanding of the development steps. The performance evaluation as well as usability study for GWE will be discussed in the next chapter.
59 Chapter 6
Evaluation
This chapter presents the procedure and results of experimental evaluation I carried out for the measurement of scalability and execution time for GWE. It also provides an overview of usability feedback results (for GWE) recorded with the help of a satisfaction survey carried out at Siemens premises (the industrial partner).
6.1 Performance Study
I carried out an experimental evaluation of generating consistent workflow models to address the following research questions:
RQ1 How does GWE scale (in time) when creating workflow models of increasing size?
RQ2 What is the influence of the complexity of workflow elements (activity blocks) on the overall performance of GWE?
Benchmarking setup In order to answer the mentioned reasearch questions, a test scenario was created which included the implementation of dedicated Java services for the purpose of scalability evaluation including, e.g., (1) creation of certain configuration wizards or (2) the recording of time taken by the important background actions performed by GWE. Further details are provided separately for each research question.
Benchmark execution To measure scalability, a time-out of 2 minutes was set up for each workflow model creation run with increasing model size. For each measurement point, workflow model creation was executed 10 times and the median of the runs were taken. All measurements were executed on a computer with 32 GB RAM, 64-bit Windows Operating System and x64-based processor. GWE used Eclipse Modeling framework version — Photon (4.8.0), Java (1.8.0) and Sirius (6.2.1) as main underlying technologies.
60 6.1. Performance Study
Figure 6.1: Dialog box for the scalability evaluation
6.1.1 Evaluation of RQ1
Setup for RQ1 To address this research question, a test tool was created which invokes a Java service to carry out the requested scalability operation and captures the time taken by the vital methods such as setConnections() and setActivityIOconnections(). This tool can be accessed from the palette of GWE and it opens a dialog box (as shown in Figure 6.1) to enter the target number of Activity Blocks (workflow elements) to be added along with number of rows to be created on the layout. Once the desired information is provided, the background Java service is invoked upon user request (see Figure 6.2).
Figure 6.2: Scalability Implementation
This service takes a random list of workflow elements from the cloned repository and adds these on to the composition area. The extension of layout is also carried out based on the number of elements (the number of rows are kept constant as the value received from the dialog box and number of columns may vary depending upon the requirement). The Java service records the time taken for the actual auto-wiring phase (i.e., the above mentioned two methods) but it excludes preparatory steps like loading the palette elements from the version control system. The experiment results are recorded in a CSV file for each measurement run, which helps the post-processing of
61 6.1. Performance Study results.
Experiment Results For RQ1, the workflow model creation time (specifically for the auto- wiring and overall I/O connections for workflow) was evaluated by increasing the target model size from 10 to 200 elements. The tests were run for each measurement point for 10 times and median of these values was taken. Table 6.1 shows an example of 10 measurements taken for the addition of 100 workflow elements in GWE. It captures the total time taken for method processing such as setConnections() for auto-wiring of workflow elements and setActivityIOconnections() for the extreme end Input/Output connections of Workflow. Below examples illustrates the detailed analysis of run-time vs model size experiment.
Number of Elements Time taken for Auto-wiring (ms) Time taken for I/O connections of Workflow (ms)
100 1417 37.210 100 1009 39.818 100 0991 35.877 100 1058 38.428 100 1204 47.436 100 1118 35.002 100 0857 37.585 100 1094 32.585 100 1002 43.242 100 1237 39.054
Table 6.1: Experiment results for creating 100 workflow elements (10 times): the total time taken for auto-wiring, overall I/O connection for these elements
Example 6.1. The chart in Figure 6.3 illustrates the time taken for auto-wiring of workflow elements w.r.t the varying workflow model size. Further, the chart in Figure 6.4 illustrates the time taken for setting up of outer-most input and output connections for the overall workflow w.r.t the varying workflow model size.
Findings After careful observation of results achieved from the experiment conducted for RQ1, we figured out that the GWE takes less than a second to perform the auto-wiring (which is an important part for the workflow creation process) for the workflow model size such as (10, 50). As we keep on increasing the number of workflow elements up to 100, GWE takes nearly a second
62 6.1. Performance Study
Figure 6.3: Total time taken for Auto-Wiring
Figure 6.4: Total time taken for the extreme end I/O connections for overall workflow to perform the auto-wiring operation (which is quite fast and acceptable in the practical usability scenario). In case of 150 or 200 workflow elements, GWE takes approximate 2 and 5 seconds respectively for the auto-wiring. The observed graph pattern of GWE’s performance indicates that the execution time is quadratic to the input model size. Hence, the experimental evaluation for RQ1 shows that GWE provides a relatively fast performance with increasing workflow model size.
6.1.2 Evaluation of RQ2
For RQ2, the tests were run to create workflow models with varying complexity in terms of their number of input and output ports. We categorized the elements in to three categories (based on
63 6.2. Initial User Study level of complexity):
1. Simple: The set of workflow elements which require at most 2 inputs or outputs;
2. Intermediate: The set of workflow elements which require at least 2 and at most 10 inputs or outputs;
3. Complex: The set of workflow elements which require at least 10 or more inputs or outputs.
The measurements (time taken for auto-wiring of workflow elements) were taken for these three categories of workflow models. For each category, 10 measurement runs were performed and median of runs were taken. The median time taken (auto-wiring) for each category is as shown in Table 6.2.
Category Time taken for Auto-wiring (s)
Simple 0.006 Intermediate 0.010 Complex 0.017
Table 6.2: Experiment results for varying level of complexity and total time taken for auto-wiring
Findings When workflow elements of higher complexity are added to the workflow, we have observed an increased processing time for auto-wiring. However, even in the case of most complex workflow elements, auto-wiring took less than 0.01 seconds, which is not observable by the user. Therefore, the increased level of complexity of workflow elements does not have a major impact on the performance of GWE.
6.2 Initial User Study
An initial usability evaluation of GWE was carried out involving 10 Siemens engineers (Canada and USA) including tool developers, software engineers, mechanical engineers and workflow de- signers. Experienced engineers who have already created workflows for gas turbine design were asked to evaluate GWE while creating new (small and large) workflows of different complexity and integrating them back into the VCS with code generation support. The engineers could successfully complete their tasks using GWE in all cases. I also gave them a test scenario to construct a sample workflow model using GWE and to generate the workflow
64 6.3. Summary definition file following the tool demonstration script. I requested information from the participants of the survey about their overall experience of GWE, and asked specific questions about different features of the GWE. The survey was designed in such a way that it would take maximum 5 minutes to answer all the questions considering the busy schedule of all the engineers at workplace. A total of 7 questions were asked in the survey along with an open text section for the general feedback or suggestions about the tool. A few questions were about the different features of the tool and a couple of them were related to the outlook and overall performance of the tool. All the users actively recorded their feedback in the survey after they successfully tested and evaluated the tool in their daily work experience.
Questions 1 2 3 4 5
Dashboard provides an easy to understand functionality 00 00 00 49 51
New Activity Creation Wizard helps to easily configure a new Workflow 00 00 20 40 40
Add Activity Block Wizard helps me add the desired element easily 00 00 00 40 60
Auto-wiring of workflow elements works efficiently and intuitively 00 00 14 25 61
Grid Layout provides an easy to understand overview of the Analysis Workflow 00 00 12 46 42
Workflow Editor provides seamless interaction with WES and GitLab 00 00 20 40 40
Workflow Editor provides convincing look and feel for the user interface 00 00 22 38 40
Table 6.3: Aggregated results of user satisfaction survey for Graphical Workflow Editor (1: Strongly disagree, 2: disagree, 3: neutral, 4: agree, 5: strongly agree)
The key questions and the results of the survey are provided in Table 6.3. While getting feedback from the target user group is a major achievement in itself, GWE received a very positive feedback from all user groups: 80% of users agreed that the three key innovative features are beneficial.
6.3 Summary
To conclude this chapter, from the performance perspective, the time taken for auto-wiring by GWE was negligible even for complex and large workflows. Furthermore, the feedback received from the actual user group was very positive w.r.t the acceptance of this tool. The following chapter will discuss about the related tools and compare those with GWE.
65 Chapter 7
Related Work
This chapter provides an overview of various graphical, workflow-related modeling techniques and tools used in various domains with particular focus on (1) business process modeling, (2) data analytics, and (3) cyber-physical systems. We also highlight the novel features of GWE which differentiates GWE from these workflow modelers.
7.1 Business Process Modeling Workflows
7.1.1 Business Process Model and Notation (BPMN)
The Business Process Model and Notation (BPMN) [55] offers a graphical way for the specification of business processes in a Business Process Diagram. This notation is more like a flow chart that draws the business procedure from end-to-end. BPMN enables the business stakeholders to visualize their business processes and makes the communication between different process steps more transparent and understandable. At an abstract level, BPMN is mostly relevant for business organizations to provide them with graphical representation of their internal business procedures. At a ground level, BPMN also enables the users to implement a process by providing necessary information for the precise implementation. BPMN is a benchmark graphical notation for the users from various groups or domains such as business stakeholders, developers, business consultants, managers etc. In other words, this notation actually brings together the process description and implementation by accurately laying out the sequence of business steps along with clear implementation instructions. In general, the following BPMN [8] elements (shown in Figure 7.1) are generally used in the specification of business process diagrams:
1. Pools represent a business stakeholder or a participant or a company for the concerned process in a business diagram;
2. Lanes are sub-partition within a process, sometimes within a Pool, and extend the entire
66 7.1. Business Process Modeling Workflows
Figure 7.1: An overview of basic elements of BPMN (ICEDEG, 2014 [8])
length of the process (either vertically or horizontally). Lanes are used to organize and categorize activities;
3. Event provides a visual representation for some action which can occur. The main categories of an event are: (1) start event which represents the starting point for a process, (2) interme- diate event which represents an interruption while the process is executing such as time-out event or message arrival, and (3) end event which represents the termination point for a process. For the graphical representation of an event, circles are used in a BPMN digram;
4. Activity represents some task or sub-process which is executed to achieve a certain output. For the graphical representation of an activity, rectangles with rounded corners are used in a BPMN digram;
5. Gateway controls the flow of a business process by providing options and parallel execution of tasks. Exclusive and parallel are the most commonly used gatways for a business process diagram. An exclusive gateway provides different pathways or input options but a single output for a business process. Parallel gateway waits for all the inputs and starts output paths altogether in parallel. For the graphical representation of a gateway, diamonds are used in a BPMN digram;
6. Flows are connecting objects to represent the flow of a process: Sequence Flow (represents the order of activities to perform), Message Flow (exchanges message between participants) and Association (links information and Artifacts with BPMN graphical elements).
67 7.1. Business Process Modeling Workflows
7.1.2 Java Business Process Model (jBPM)
Java Business Process Model (jBPM) [53] is an open-source, light-weight, extensible workflow engine for the execution of business processes defined either in BPMN or jPDL. It is developed in native Java which makes it compatible with any application or service developed in a Java environment. A general BPM (Business Process Management) collaborates among various business stakehold- ers such as analysts, developers and end users, with the help of well-defined process management and supportive tools favorable for both end-users and developers. On the other hand, jBPM pro- vides support for adaptable and dynamic processes which require flexible environment to design complicated and real-world situations.
Figure 7.2: An overview of components of jBPM [32]
Figure 7.2 gives an overview of the different components of the jBPM project [32].
Modeling and Deployment Firstly, the process designer provides a web-based environment to the business participants for the design and simulation of business processes. Next, the data modeler provides the general users with the ability of viewing, modification and creation of data models. Next, the web-based form modeler provides the feasibility of creation, generation or editing of forms
68 7.2. Workflows for Data Analytics for the user-based actions such as initiating a process, finishing of a certain task etc. Lastly, the rules authoring enables the specification of multiple business-process based rules such as decision tables, guided rules etc.
Execution Core Engine is the main component of the jBPM project which provides flexible environment for the execution of business processes. It is a Java based component which makes possible an easy integration with any application or environment and reachability with the help of a web-based user-interface or remote application interfaces (such as REST, JMS). Further, a human task service, which is an optional core service, looks after the time-period of human-based activities in the business process. The persistence layer, an optional core service, keeps a record of the run-time status of all the processes and logs details of audit for run-time activities.
Run-time Management The participants can initiate new processes and verify running pro- cesses with the help of a web-based management console. It also helps the users to easily maintain their task list as well as do the business activity monitoring (BAM) and viewing of reports.
7.1.3 GWE vs BPMN and jBPM
BPMN and jBPM provide a standard graphical way to define business process related workflows, however most of the actions related to these workflow definition methods require manual interven- tion such as wiring of elements and addition of swim lanes/pools. Moreover, the palette provides a static list of elements in both the cases. In contrast, GWE provides a dynamic palette because of its collaboration with version control system (VCS), establishes automatic connections between workflow elements and offers a dynamically expandable grid-layout which provides a compact and interactive view of the overall workflow.
7.2 Workflows for Data Analytics
7.2.1 Konstanz Information Miner (KNIME)
The Konstanz Information Miner (KNIME) [25, 71] is an open-source framework for data analytics, integration of multiple projects or methods for machine learning and data mining, and reporting of analysis results. KNIME offers an interface for the graphical creation of workflows and enables the integration of nodes from multiple data sources for the analysis process (with the help of Java
69 7.2. Workflows for Data Analytics database connectivity (JDBC)).
Figure 7.3: An overview of KNIME Workflow (KNIME Analytics Platform [35])
KNIME [25, 35] allows the graphical creation and representation of data analysis workflows (see Figure 7.3), along with the possibility of selective execution of analysis processes and the visual reviewing of analysis results. KNIME is an Eclipse based product and primarily developed in Java, which makes it compatible for the extension and development of new features. It includes multiple database softwares for the integration of data such as SQLite, SQL Server, MySQL, PostgreSQL, Vertica etc. It is also possible to use KNIME workflows as data sets for the creation of report templates. Further, KNIME is capable of: (1) running analysis on large volumes of data such as 400 million addresses, (2) integrating methods for various domains of mining such as text and image mining and (3) performing analysis on time-series based data .
7.2.2 RapidMiner
RapidMiner [66] is a graphical workflow modeler by offering an integrated environment for the preparation of data, machine learning, deep learning, text mining, and predictive analytics. Rapid- Miner is very popular with commercial and business applications along with the fields of research & development, education etc. RapidMiner [72] helps with the preparation of data, graphical rep- resentation of outputs, validation and optimization of data models etc. RapidMiner operates on client-server based setup and availability of the server can be local or remote. RapidMiner helps with fast delivery of analytical results and reduces the occurrence of errors. It supports the different steps for the process of data mining and machine learning, which includes the loading, transfor-
70 7.3. Tool Integration Workflows for CPSs mation and preprocessing of data, graphical representation of results, predictive analysis of data etc.
Figure 7.4: An overview of RapidMiner Workflow (CEUR Workshop, 2015 [66])
RapidMiner is developed in the Java programming language. RapidMiner provides a graphical user interface (GUI) for the design and execution of analytical workflows. It refers to workflows (see Figure 7.4) as processes and these processes are made up of various operators [66]. The operator is responsible for the execution a task, and the final result generated by each operator is provided to the next operator as an input.
7.2.3 GWE vs KNIME and RapidMiner
Both KNIME and RapidMiner workflow designers provide integration of tool workflows and visual- ization of workflows. However, manual intervention is required when it comes to wiring of workflow elements and an interactive view of the overall workflow is missing since elements can be placed anywhere on the composition area. On the other hand, GWE provides auto-wiring of workflow elements as soon as these are placed on the layout and also provides an interactive view of the workflow with the help of dynamic grid-layout.
7.3 Tool Integration Workflows for CPSs
7.3.1 OpenMETA
The design process of complex cyber-physical systems involves multidisciplinary tools and methods. Recent major tool integration initiatives in cyber-physical systems include OpenMETA [52, 64], which is an automation tool suite for design and analysis of complex systems by bringing together modeling and execution frameworks for better visualization of system performance as well as trade- offs.
71 7.3. Tool Integration Workflows for CPSs
Figure 7.5: Design Flow in OpenMeta Tool Chain (International ModelicaConference, 2014 [38])
In other words, the OpenMETA [38, 64] tool chain offers an open source framework which com- prises of a model-based environment, execution platform, and a graphical interface for the results management. OpenMETA (see Figure 7.5) facilitates the involvement of a single model for the de- sign of a system using multiple domains which incorporates efficient cross-domain synchronization and communication. The common critical cyber-physical system domains involving OpenMETA tools are satellites, vehicular systems, and consumer electronics. The main characteristics which make OpenMETA tools powerful are: (1) the design of architec- ture and other components using unified design space modeling and exploration, (2) the consistent representation of system across all platforms by incorporating the integration of multi-models and component composition, and (3) the feasibility to automate multidisciplinary workflows. These properties of OpenMETA bring together the continuous integration, analysis and optimization of multidisciplinary workflows.
7.3.2 Advanced Data management tools for the engineering of CPS : AIDE
The development of cyber-physical systems (CPS) includes many experts from multidisciplinary teams. This whole process involves various steps which include the composition of requirements for the desired system, the detailed description of the expected software and hardware design followed by the creation of models, development of the software part and configuration. The information related to each phase of the development process is recorded and managed using variety of methods and database management systems. Hence, it is extremely critical to maintain the consistency of the data flow between inter-related steps of the development process.
72 7.4. Summary
Figure 7.6: Design Flow in AIDE Tool Chain [37]
The advanced data management tool suite (AIDE) [37] eases the transfer process of data between multidisciplinary software tools involved in the development process by reducing the unwanted delays with the help of graphical data management feature. Therefore, the AIDE platform brings efficiency to the end-user processes and speed-up of delivery by providing efficient utilization of resources along with maintaining better quality of end-product. This is achieved by providing support tools for creating tailored “tool-chains” and integration of data for the engineering of cyber-physical system. The underlying approach used for the AIDE tool chain follows data integration standards such as OASIS OSLC and Linked Data family. Figure 7.6 shows data integration for CPS engineering tools and repositories for the design, testing and deployment of cyber-physical systems. The highlighted red encirclement indicates the involvement of AIDE tool chain in this whole development process.
7.3.3 GWE vs OpenMeta and AIDE
Frameworks such as OpenMeta and AIDE help to visually design tool integration workflows for CPS and also provide analysis of results (such as performance for different design configurations). However, these frameworks lack the dynamic capability of core tool functionalities, which are offered by GWE such as dynamic palette, dynamic grid-layout and auto-wiring.
7.4 Summary
This chapter discussed about the related workflow editors as well as platforms and provided a brief comparison of these with GWE. The following chapter will provide conclusion of this research work and possible extensions to this tool in future.
73 Chapter 8
Conclusion and Future Work
This chapter summarizes the contributions presented in the thesis and also presents a list of possible continuations for the Graphical Workflow Editor (GWE).
8.1 Conclusions
In this thesis, I presented the Graphical Workflow Editor (GWE) which provides a user-friendly and efficient way to define tool integration workflows dedicated to the design of gas turbines. The novel features of this tool are dynamic palette, dynamic grid-layout and auto-wiring of workflow elements. The dynamic aspect of this tool is obtained due to the collaboration of GWE with version control system such as GitLab. Other features of this tool include an interactive user-interface (UI), instantaneous definition file generation (using model-to-text transformation), the re-usability of workflows (available in version control system). The thesis covers the required information related to the background, user and technical implementation perspective. GWE has been implemented using modern technologies frequently used for developing domain- specific modeling tools such as Eclipse Modeling Framework (for the definition of concepts of domain specific language), Sirius (for the development of custom graphical modeling workbench), VIATRA framework (for the model-to-text transformation) and Standard Widget Toolkit (SWT) for the development of UI. I conducted a performance evaluation on various test scenarios to assess the scalability of the tool, which included measurements of execution time with increasing number or increasing com- plexity of of workflow elements added to the workflow. The results indicate that GWE’s response time is acceptable in a practical scenario for both cases, i.e., for large (human-made) workflow models as well as complex workflow elements. Furthermore, I also conducted a small-scale user study with Siemens engineers to capture their feedback in a user satisfaction survey. The survey was prepared for the core users of this tool (at Siemens) to capture their opinion about: performance, general appearance of the tool, and
74 8.2. Future Work suggestions for further improvements in this tool. A positive feedback was received from the users about the overall performance of the tool and 80% of users found the novel features helpful in the designing of tool integration workflows.
8.2 Future Work
There are various possible continuations of the GWE project that could be addressed as future work.
1. Integration of GWE with the workflow execution system (WES): It would allow users to access both workflow creation/edit feature and initiation of workflow execution from the same tool;
2. Adaptation of GWE workflows to other domains: Currently, GWE is dedicated for the domain of aero-derivative gas turbines and large gas turbines. If the tool is made relevant for other domains as well, then it would widen the applicability area;
3. Conversion of GWE into web service application: A web service based architecture would allow users to easily access this tool from web browser and no installation would be needed for tool set-up;
4. Graphical design of workflow elements: Currently, GWE lists the already designed workflow elements in the palette at the time of workflow creation. It would be a great addition, if user can design the preferred workflow elements within the same editor, and create a new customized workflow.
5. Live monitoring of workflow execution: It would allow user to create a workflow, execute it and then monitor its completion status with the help of Restful APIs. In case of failure of a workflow, a user can re-initiate it without any further delay (due to the live monitoring of execution process).
75 Bibliography
[1] Oracle Corporation. Java development kit. URL: https://en.wikipedia.org/wiki/Java_ Development_Kit.
[2] Etienne´ Andr´e,Mohamed Mahdi Benmoussa, and Christine Choppy. Translating UML state machines to coloured Petri nets using Acceleo: A report. In Jun Pang and Yang Liu, edi- tors, Proceedings Third International Workshop on Engineering Safety and Security Systems, volume 150, pages 1–7, 2014.
[3] Chutiporn Anutariya, Vilas Wuwongse, Kiyoshi Akama, and Ekawit Nantajeewarawat. RDF declarative description (RDD): A language for metadata. J. Digit. Inf., 2(2), 2001.
[4] Andr´asBalogh, G´abor Bergmann, Gy¨orgyCsert´an,L´aszl´oG¨onczy, Akos´ Horv´ath,Istv´an Majzik, Andr´asPataricza, Bal´azsPolg´ar,Istv´anR´ath,D´aniel Varr´o,and Gergely Varr´o. Workflow-driven tool integration using model transformations. In Graph Transformations and Model-Driven Engineering, volume 5765 of LNCS, pages 224–248. Springer, 2010.
[5] Pierre Bourhis, Juan L. Reutter, and Domagoj Vrgoc. JSON: data model and query languages. Inf. Syst., 89:101478, 2020.
[6] Marco Brambilla, Jordi Cabot, and Manuel Wimmer. Chapter 6: Modeling languages at a glance. In ”Model-Driven Software Engineering in Practice”. Morgan & Claypool Publishers, 2012.
[7] Caius Brindescu, Mihai Codoban, Sergii Shmarkatiuk, and Danny Dig. How do centralized and distributed version control systems impact software changes? In Pankaj Jalote, Lionel C. Briand, and Andr´evan der Hoek, editors, 36th International Conference on Software Engi- neering, pages 322–333. ACM, 2014.
[8] Riccardo Cognini, Damiano Falcioni, Alberto Polzonetti, and Barbara Re. Egov: A solution for
76 Bibliography
public services execution. In 1st International Conference on eDemocracy and eGovernment, pages 59–64. ICEDEG, 2014.
[9] Samuel Cruz-Manzo, Sepehr Maleki, Yu Zhang, Vili Panov, and Anthony Latimer. Perfor- mance analysis of a twin shaft industrial gas turbine at fouling conditions. In International Conference on Prognostics and Health Management, pages 234–238. IEEE, 2017.
[10] Jo˜aoPablo S. da Silva, Miguel Ecar, Marcelo Soares Pimenta, Gilleanes T. A. Guedes, Luiz Paulo Franz, and Luciano Marchezan. A systematic literature review of UML-based domain-specific modeling languages for self-adaptive systems. In Jesper Andersson and Danny Weyns, editors, IEEE/ACM 13th International Symposium on Software Engineering for Adap- tive and Self-Managing Systems (SEAMS), pages 87–93. ACM, 2018.
[11] Brian de Alwis and Jonathan Sillito. Why are software projects moving from centralized to decentralized version control systems? In Proceedings of the 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering, CHASE 2009, Vancouver, BC, Canada, 17 May 2009, pages 36–39. IEEE Computer Society, 2009.
[12] Darko Durisic, Corrado Motta, Miroslaw Staron, and Matthias Tichy. Co-evolution of meta- modeling syntax and informal semantics in domain-specific modeling environments - A case study of AUTOSAR. In ACM/IEEE 20th International Conference on Model Driven Engi- neering Languages and Systems (MODELS), pages 189–198. IEEE Computer Society, 2017.
[13] Valceres Vieira Rocha e Silva, Wael Khatib, and Peter J. Fleming. Performance optimization of gas turbine engine. Eng. Appl. Artif. Intell., 18(5):575–583, 2005.
[14] Emad Samuel Malki Ebeid, Julio L. Medina, Davide Quaglia, and Franco Fummi. Extensions to the UML profile for MARTE for distributed embedded systems. In 2015 Forum on Specification and Design Languages FDL, pages 99–106. IEEE, 2015.
[15] Eclipse Foundation. Acceleo : A language for model to text transformation. URL: https: //www.eclipse.org/acceleo/.
[16] Eclipse Foundation. ATL - a model transformation technology. URL: https://www.eclipse. org/atl/.
[17] Eclipse Foundation. Eclipse modeling framework (EMF). URL: https://www.eclipse.org/ modeling/emf/.
77 Bibliography
[18] Eclipse Foundation. GEF: A graphical editing framework. URL: https://www.eclipse.org/ gef/.
[19] Eclipse Foundation. JFace: A UI toolkit with SWT based views. URL: https://wiki. eclipse.org/JFace.
[20] Eclipse Foundation. JGit: A java library implementing the Git version control system. URL: https://www.eclipse.org/jgit/.
[21] Eclipse Foundation. Sirius: A graphical modeling framework. URL: https://www.eclipse. org/community/eclipse_newsletter/2013/november/article1.php.
[22] Eclipse Foundation. Sirius: Specifying diagram editors. URL: https://www.eclipse.org/ sirius/doc/4.0.x/specifier/diagrams/Diagrams.html.
[23] Eclipse Foundation. VIATRA: Model transformation framework. URL: https://www. eclipse.org/viatra/documentation/tutorial.html.
[24] Eclipse Foundation. Xtend - a statically-typed programming language. URL: http://www. xtend-lang.org.
[25] Alexander Fillbrunn, Christian Dietz, Julianus Pfeuffer, Ren´eRahn, Gregory Landrum, and Michael Berthold. KNIME for reproducible cross-domain analysis of life science data. Journal of Biotechnology, 261, 07 2017.
[26] Mohammad Gholami, Mohammad Sharifkhani, and Saeed Saeedi. Modeling of DLL-based frequency multiplier in time and frequency domain with Matlab Simulink. In 2010 IEEE Asia Pacific Conference on Circuits and Systems, pages 1051–1054. IEEE, 2010.
[27] Andreas Graf and Markus V¨olter. A textual domain specific language for AUTOSAR. volume 2009-01, pages 165–170, 2009. URL: http://www.sse-tubs.de/mbees-dagstuhl/ MBEES2009_Proceedings_online_small.pdf.
[28] Richard C. Gronback. Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Pearson Education, 2009.
[29] Muhammad Baqir Hashmi, Tamiru Alemu Lemma, and Zainal Ambri Abdul Karim. Investi- gation of the combined effect of variable inlet guide vane drift, fouling, and inlet air cooling on gas turbine performance. Entropy, 21(12):1186, 2019.
78 Bibliography
[30] Regina Hebig, Christoph Seidl, Thorsten Berger, John Kook Pedersen, and Andrzej Wasowski. Model transformation languages under a magnifying glass: A controlled experiment with Xtend, ATL, and QVT. In Software Engineering and Software Management, SE/SWM 2019, Stuttgart, Germany, February 18-22, 2019, volume P-292 of LNI, pages 91–92. GI, 2019.
[31] Konrad Hinsen, Konstantin L¨aufer,and George K. Thiruvathukal. Essential tools: Version control systems. Computing in Science and Engineering, 11(6):84–91, 2009.
[32] jBPM Organization. jBPM - a workflow engine. URL: https://docs.jboss.org/jbpm/ release/7.36.0.Final/jbpm-docs/html_single/.
[33] JSON Foundation. JavaScript Object Notation (JSON). URL: https://www.json.org/.
[34] Anneke Kleppe. Software Language Engineering: Creating Domain-Specific Languages Using Metamodels. Pearson Education, 2008.
[35] KNIME Foundation. KNIME - a workflow designer for data science. URL: https://www. knime.com/knime-analytics-platform.
[36] Dimitrios S. Kolovos, Richard F. Paige, and Fiona A. C. Polack. On the evolution of OCL for capturing structural constraints in modelling languages. volume 5115 of Lecture Notes in Computer Science, pages 204–218. Springer, 2009.
[37] KTH. AIDE data management tools. URL: https://fed4sae.eu/advanced-platforms/ advanced-technologies/aide-kth/.
[38] Zsolt Lattmann, Adrian Pop, Johan Kleer, Peter Fritzson, Bill Janssen, Sandeep Neema, Ted Bapty, Xenofon Koutsoukos, Matthew Klenk, Daniel Bobrow, Bhaskar Saha, and Tolga Kur- toglu. Verification and design exploration through meta tool integration with OpenModelica. In Proceedings of the 10th International ModelicaConference, pages 353–362, 03 2014.
[39] Simon St. Laurent. Describing your data: DTDs and XML schemas. URL: https://www. xml.com/pub/a/1999/12/dtd/index.html.
[40] Jinzhi Lu, Martin T¨orngren,De-Jiu Chen, and Jian Wang. A tool integration language to formalize co-simulation tool-chains for cyber-physical system (CPS). In Software Engineering and Formal Methods, volume 10729 of Lecture Notes in Computer Science, pages 391–405. Springer, 2017.
79 Bibliography
[41] Mateusz Luba´nski.Centralized vs distributed version control systems. URL: https://medium. com/faun/centralized-vs-distributed-version-control-systems-a135091299f0.
[42] Levi Lucio, Sadaf Mustafiz, Joachim Denil, Hans Vangheluwe, and Maris Jukss. FTG+PM: an integrated framework for investigating model transformation chains. In SDL 2013: Model- Driven Dependability Engineering - 16th Int. SDL Forum, Montreal, Canada, June 26-28, 2013. Proc., volume 7916 of LNCS, pages 182–202. Springer, 2013.
[43] Raul Lugo-Leyte, Martin Salazar-Pereyra, Helen Denise Lugo-M´endez,I. Aguilar-Adaya, J. J. Ambriz-Garc´ıa,and J. G. V´azquezVargas. Parametric analysis of a two-shaft aeroderivate gas turbine of 11.86 MW. Entropy, 17(8):5829–5847, 2015.
[44] Fr´ed´ericMadiot and Marc Paganelli. Eclipse Sirius demonstration. volume 1554, pages 9– 11. CEUR-WS.org, 2015. URL: http://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_4. pdf.
[45] Ivano Malavolta, Henry Muccini, and Patrizio Pelliccione. Integrating AADL within a multi- domain modeling framework. In 2009 14th IEEE International Conference on Engineering of Complex Computer Systems, pages 341–346. IEEE Computer Society, 2009.
[46] Ralph Maschotta, Alexander Wichmann, Armin Zimmermann, and Kristina Gruber. Inte- grated automotive requirements engineering with a SysML-based domain-specific language. In 2019 IEEE International Conference on Mechatronics (ICM), pages 402–409. IEEE, 2019.
[47] Nathalie Moreno, Piero Fraternali, and Antonio Vallecillo. WebML modeling in UML. Soft- ware, IET, pages 1–5, 07 2007.
[48] Michael Murphy, John Markus Bjørndalen, and Otto J. Anshus. Scalability of distributed version control systems. Bibsys Open Journal Systems, Norway, 2017.
[49] Object Management Group. XML Metadata Interchange (XMI). URL: https://www.omg. org/spec/XMI/2.5.1/PDF.
[50] Object Management Group OMG. MOF: Model to text transformation language. URL: https://www.omg.org/spec/MOFM2T/About-MOFM2T.
[51] Object Management Group OMG. OCL: Object Constraint Language. URL: http://www. omg.org/spec/OCL/2.4.
80 Bibliography
[52] OpenMeta Foundation. OpenMeta - a visual automation tool suite for CPS. URL: https: //openmeta.metamorphsoftware.com/why-openmeta/.
[53] Hailan Pan, Wenrong Jiang, and Shiwei Lin. Research on collaboration software based on JBPM and lightweight J2EE framework. In The Int. Conf. on E-Business and E-Government, ICEE 2010, 7-9 May 2010, Guangzhou, China, Proc., pages 191–194, 2010.
[54] Timothe Peoch, Ahmed Bayoumy, Martin Staniszewski, Hany Moustapha, Michael Kokko- laras, and Fran¸coisGarnier. Integration of secondary air system for multidisciplinary de- sign optimization of gas turbines. CASI, 2019. URL: https://www.casi.ca/resources/ Documents/AERO/2019/.
[55] Gregor Polancic and Bostjan Orban. A BPMN-based language for modeling corporate com- munications. Computer Standards & Interfaces, 65:45–60, 2019.
[56] Alessandro Ricci and Andrea Santi. Designing a general-purpose programming language based on agent-oriented abstractions: the simpAL project. In Cristina Videira Lopes, editor, Con- ference on Systems, Programming, and Applications, pages 159–170. ACM, 2011.
[57] Juri Di Rocco, Davide Di Ruscio, Hrishikesh Narayanankutty, and Alfonso Pierantonio. Re- silience in Sirius editors: Understanding the impact of metamodel changes. volume 2245, pages 620–630. CEUR-WS.org, 2018. URL: http://ceur-ws.org/Vol-2245/me_paper_6.pdf.
[58] Alessio Di Sandro, Sahar Kokaly, Rick Salay, and Marsha Chechik. Querying automotive system models and safety artifacts with MMINT and VIATRA. In 22nd ACM/IEEE Inter- national Conference on Model Driven Engineering Languages and Systems, pages 2–11. IEEE, 2019.
[59] Meinhard T Schobeiri. Introduction, gas turbines, applications, types. In Gas Turbine Design, Components and System Design Integration, pages 1–29. Springer, 2018.
[60] Fredrik Seehusen and Ketil Stølen. An evaluation of the graphical modeling framework (GMF) based on the development of the CORAS tool. In Jordi Cabot and Eelco Visser, editors, Theory and Practice of Model Transformations, volume 6707 of LNCS, pages 152–166. Springer, 2011.
[61] Ed Seidewitz. What models mean. IEEE Software, 20:26–32, 10 2003.
81 Bibliography
[62] Bran Selic. The pragmatics of model-driven development. IEEE Software, 20(5):19 – 25, 10 2003.
[63] Claire Soares. Chapter 1 - gas turbines: An introduction and applications. In Claire Soares, editor, Gas Turbines (Second Edition), pages 1 – 40. Butterworth-Heinemann, Oxford, second edition edition, 2015.
[64] Janos Sztipanovits, Ted Bapty, Xenofon Koutsoukos, Zsolt Lattmann, Sandeep Neema, and Ethan Jackson. Model and tool integration platforms for cyber–physical system design. Pro- ceedings of the IEEE, 106(9):1501–1526, 2018.
[65] Muhammad Umer Tariq, Jacques Florence, and Marilyn Wolf. Design specification of cyber- physical systems: Towards a domain-specific modeling language based on simulink, eclipse modeling framework, and giotto. volume 1250, pages 6–15. CEUR-WS.org, 2014. URL: http: //ceur-ws.org/Vol-1250/paper2.pdf.
[66] Jan van Rijn and Joaquin Vanschoren. Sharing RapidMiner workflows and experiments with OpenML. CEUR Workshop Proceedings, 1455:93–103, 01 2015.
[67] D´anielVarr´o,G´abor Bergmann, Abel´ Heged¨us, Akos´ Horv´ath,Istv´anR´ath,and Zolt´anUjhe- lyi. Road to a reactive and incremental model transformation platform: three generations of the VIATRA framework. Software and Systems Modeling, 15(3):609–629, 2016.
[68] W3C Organization. HTML: Hyper text markup language. URL: https://www.w3.org/html/.
[69] W3C Organization. XML: Extensible markup language. URL: https://www.w3.org/XML/.
[70] Michael Weiss. XML Metadata Interchange, pages 3597–3597. Springer US, Boston, MA, 2009.
[71] Wikipedia. KNIME - a workflow designer for predictive analytics. URL: https://en. wikipedia.org/wiki/KNIME.
[72] Wikipedia. RapidMiner - a workflow designer for predictive analytics. URL: https://en. wikipedia.org/wiki/RapidMiner.
[73] Alex Wun. AJAX. In Ling Liu and M. Tamer Ozsu,¨ editors, Encyclopedia of Database Systems, Second Edition. Springer, 2018.
[74] Zainab Zolaktaf, Mostafa Milani, and Rachel Pottinger. Facilitating SQL query composition and analysis. CoRR, abs/2002.09091, 2020.
82