Understanding the role of Model Transformation Compositions in Low-Code Development Platforms

Low-code development platforms (LCDPs) permit developers that do not have strong programming experience to produce complex software systems. Visual environments permit to specify work-flows consisting of sequential or parallel executions of services that are directly available in the considered LCDP or are provided by external entities. Specifying workflows involving different LCDPs and services can be a difficult task. In this paper, we propose the adoption of concepts and tools related to the composition of model transformations to support the specification of complex workflows in LCDPs. We elaborate on how LCDPs services can be considered as model transformations and thus, workflows of services can be considered as model transformation compositions. The architecture of the environment supporting the proposed solution is presented.


INTRODUCTION
Low-Code Development Platforms (LCDPs) 1 are visual environments that are being increasingly promoted by major IT players for supporting citizen developers to create software systems even if they lack programming background and knowledge [16]. One of the most prominent application domain for LCDPs is process Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. automation [10]: citizen developers are provided with visual environments to specify workflows orchestrating sequential or even parallel consumptions of services, each typically provided by external providers, which the used LCDP is able to connect. Thus, developers can specify processes e.g., to retrieve data from external data sources (e.g., calendar, sensors, and files stored in cloud services), to manipulate retrieved data. It can be achieved by means of the provided facilities or even by using external services, and to perform some aggregation and analysis according to rules defined with the languages provided by the platform. However, when complex workflows have to be specified, developers have to be aware of the possible service providers that the used LCDP is able to interact with, and the manipulation means that might be exploited to finally develop the desired process.
In this paper, we focus on the low-code development of complex workflows involving the interoperability of different services. In such a setting, we aim at providing citizen developers with the means to declaratively specify the goals of the desired processes and to get back the services, and the corresponding interactions. Such interactions might be potentially employed to develop the process previously specified in a declarative manner at a higher level of abstraction. To this end, we investigate the possibility of relying on the results developed by the Model Driven Engineering (MDE) [11] research community about the topic of model transformation composition [2]. The envisioned idea is considering workflows as corresponding model transformation chains, and the services to be consumed in the workflows as model transformations that have to be properly composed. Thus, many smaller and simpler model transformations are composed together to realize complex workflows to be executed in the considered LCDP. The contribution of the paper is to propose a research direction to support several specifications of services to define and execute their complex workflows in LCDPs.
The paper is structured as follows: Section 2 introduces the problem we want to cope in this paper. Section 3 presents an overview of existing approaches for composing model transformations. Section 4 proposes their adoption to support the definition of complex workflows in LCDPs. Section 5 concludes the paper and presents our future plans.

PROBLEM STATEMENT
LCDPs are visual environments that permit mainly in a declarative manner to develop complex applications even for developers that do not have strong programming experience. Systems like IFTTT 2 , and zapier 3 provide users with easy to use tools for developing workflows consisting of sequential or even parallel execution of services. By means of such tools, users can specify workflows that can be triggered e.g., when a new email arrives and a corresponding spreadsheet is updated in order to keep track of emails that have been sent from specific addresses. Even in Internet of Things (IoT) scenarios, LCDPs can play a key role e.g., when devices from different brands and ecosystems need to be integrated in a same physical environment.
Workflows that users might have the need to specify can be complex and involve different platforms and services. An explanatory scenario is shown in Figure 1 that considers two LCDPs named as LCDP1 and LCDP2. In LCDP1, there are two applications shown as circles called App11 and App12. Inside App11, there are two services shown as squares named as x1 and x2. Inside App12, there are also two services shown in squares named m1 and m2. Likewise, in LCDP2, there are two applications shown as circles called App21 and App22. Inside App21, there are three services show in squares called as y1, y2 and y3. Similarly in App22, there are also three services shown in squares called as z1, z2 and z3. According to the depicted arrows in Figure 1, different kinds of interactions (i.e., service invocations and application interfaces) can occur in workflows like the one previously described in the example involving Mendix and Appian. In the following points, we distinguish two kinds of interactions, i.e., Inter LCDPs and Intra LCDPs: • Inter LCDP: This kind of interactions occurs when data from services and applications produced in one LCDP are manipulated or consumed by services and applications provided by another LCDP. Such manipulations or consumption are shown in arrows y1 to x1, z1 to App12, App12 to App21 and App12 to z2. • Intra LCDP: This kind of interactions occurs when data from services or applications are manipulated or consumed by services or applications within the same low-code platform. Such interactions can be further detailed as: -Inter applications: Data from one application are manipulated or consumed by different applications within the same LCDP. Such manipulations are shown in arrows y2 to z3, y3 to App22, App11 to App12 and App12 to x2. -Intra application: Data from services in one application within the same LCDP are manipulated by another services offered by the same application. For instance, data produced by pre-built forms, reports, etc., are used and manipulated by the same application to provide different view such as grid view, Kanban view, etc. Such manipulation is shown in m1 to m2. To make a concrete example with respect to Figure 1, let us suppose to work with the Mendix and Appian low-code development platforms as shown in Figure 2. In Mendix, there are two developed applications called Attendance Management System and Autonomous Vacation Management System. Attendance Managment System determines the attendance of each employee on a given month and it provides a service named as Enrollment System, which is reused by the application known as Enrollment Management System built in the Appian low-code platform. Also, Autonomous Vacation Management System built in Mendix uses an application known as Vacation Management System built in Appian. Autonomous Vacation Management System interacts with an external service provided by IFTTT 4 to build an automatic allocation of the vacation if the employee asked for it. This example deals with different services and applications that interact across different LCDPs.
The data from Autonomous Vacation Management System application is used in Attendance Management System in Mendix to automate the absence of an employee due to the allotment of vacation. Also, suppose there is a service named as Salary Section in the application Vacation Management System which is determined by another service of another application Enrollment Management System known as Grading System within the same low-code platform Appian. Such interactions within the same LCDPs can also be executed within applications or across different applications of that LCDP. Specifying workflows involving different LCDPs and services can be a difficult task. To support their specifications, we investigate the possibility of relying on techniques and tools developed in the MDE field for chaining model transformations. In particular, if services are seen as model transformations, specifying workflows consisting of orchestrations of different services can be seen as the problem of properly chaining different model transformations. To this end, next section makes an overview of existing approaches for model transformation compositions. Afterwards, we propose to employ them to support the development of complex workflows in LCDPs.

MODEL TRANSFORMATION COMPOSITION APPROACHES
Composing model transformations is a way to develop complex model management operations by composing smaller ones. There are two main ways to compose model transformations i.e., internal and external. In internal composition, two model transformation definitions give place to a new transformation. In external composition, two different transformations are chained together and the output models of the first transformation are given as input to the second one. Over the last years, several approaches have been proposed to compose model transformations and relevant works in such a context are overviewed in Section 3.1. The problem statement discussed in Section 2 indicates a clear need to research and develop tools to implement those workflows in concern with LCDPs. An explanatory example showing the usage of model transformation compositions is given in Section 3.2

Overview
Basciani et al. (2018a, 2018b) [2,3] propose an approach for the external composition of model transformations. In particular, given as input the source model, and the wanted target metamodel, the system is able to find out a ranked list of transformation chains with respect to a notion of information loss implemented in a customized Dijkstra algorithm. Etien et al. (2015) [7] propose an approach to transform very large models by decomposing them based on a separation of concern technique and then use localized transformations to check the desired outcomes according to the objectives of the application. Thus the proposed technique consists of building localized transformations and combine them with the help of a composition language.
Aranega et al. (2012) [1] make use of feature models to automate a consistent set of model transformations and generate an executable chain implementing the desired objectives.
In [5], authors propose an approach to determine which chaining of available model transformations gives the desired result with respect to pre-conditions, post-conditions, and behavioural aspects of individual rules. Thus, commutativity of the chaining of model transformations is also used to detect identical results by using both sides of the transformation. Similarly, in [4] authors present an approach to find out the best transformation chain (that satisfies given chaining constraints) by statically analyzing single transformations.
In [6] authors propose a technique to combine independent model transformations that do not handle compatible source and target metamodels, and that might jointly work to achieve the wanted objective. The approach relies on the composition language for independent model transformations with incompatible metamodels. Wagelaar et al. (2010Wagelaar et al. ( , 2008 [14,15] propose an internal composition technique named model superimposition that allows for extending and overriding rules in different transformation modules. [13] present a language to specify transformation chains. The language is based on UML activity diagrams and it is independent from the languages used to develop the transformations being chained. Similarly, Rivera et al. (2009) [9] propose a graphical language for orchestrating ATL transformations. The language provides users with modeling constructs to specify conditional, parallel, and looping execution of different ATL model transformations.

Explanatory example
We have mentioned external (chaining) as well as internal composition of model transformations for transforming and composing different services. According to paper [12], it is easier to build and test the smaller model transformations separately and then merge them together to form the whole complex transformation.   Also, from Figure 3, the total number of model transformations can be calculated as follows. If 2 models are available to be transformed, then only 1 model transformation is possible. Similarly, for 3, 4 and 5 models to be transformed, the total number of model transformations possible are 3, 6 and 10 respectively. Therefore, we can generalize this trend. The trend shows for n models (where n >2) to be transformed, there will be n(n-1)/2 model transformations possible. Therefore, the total number of model transformations possible within a system of n models are n(n-1)/2. This explains the possible number of model transformations in specifying complex workflows available in a software and gives us the ability to find out the optimal composition of model transformations by estimating the optimal paths [3].
The paper aims at composing different model transformations (either, internally or externally) to have an optimal path to achieve the target workflows. Therefore, a transformation path is aimed with minimal cost and time. This would require all the possible number of model transformations available to obtain a specific workflow with different combinations of model transformation compositions. Such model transformation compositions are more reusable if the overlapping of their combination is maximum. This gives an efficient and simpler solution to define all the workflows because most of the compositions are pre-built and therefore it can be easily reused for a new workflow with minimum changes on the newer transformations. This maximum overlapping of model transformation compositions utilizes the use of pre-built compositions developed from previous workflows to deliver a new workflow.

PROPOSED APPROACH
In this section, we elaborate on how model transformation composition techniques can be used to support the specification of complex workflows in LCDPs. In particular, we see the possible interactions occurring intra and inter LCDPs presented in Section 2 as proper orchestrations of different services. Then, if we can manage such services as model transformations, then we can reuse the theories underpinning existing composition approaches for model transformations. In this respect, Figure 4 depicts the main components of the envisioned approach, which is detailed in the following.
Goal specification metamodel: We plan to employ a similar technique as proposed in [2] to chain model transformations. In that case, the goal specified by the user consists of the target metamodel that the desired model should conform. By considering the given goal and the input model, the approach is able to identify possible transformation chains, if any. In a similar manner, we aim at providing users of LCDPs with the means to specify the characteristics of the desired workflows at a high-level of abstraction. The tools and languages shall permit to specify constraints, functional, and non-functional requirements that the final workflow should satisfy. An example of goal is that the user wants to take some input model and visualize it by means of two target views, i.e., grid view and Kanban view. To enable the adoption of the metamodel, it is necessary to define a modeling language providing users with all the modeling constructs formalized in the metamodel.
LCDP metamodels: We plan to define metamodels for specifying characteristics of the supported LCDPs. The idea is to be able to specify workflow models that can be executed by the corresponding LCDP. The specification of such metamodels require the analysis of different platforms with the aim of identifying the peculiar characteristics with respect to the provided mechanisms for specifying and executing workflows [10]. The metamodels can be mainly classified as follows. The main data metamodel of the whole LCDP is mapped to view-specific metamodels. They are essentially a design-time view and a run-time view, which correspond to the static analysis of the data model before the deployment, and to run-time analysis of the data model after its deployment, respectively. Such views store only those data that are relevant to its specific view [8]. The citizen developers should only see these view models individually and not the whole of LCDP's data model. These separations of views allow the citizen developer to focus on either of the views without much worrying about the overall expressiveness and flexibility of the data model of a particular LCDP.
LCDPs connectors: They are the software components that permit the system to connect to the different low-code development platforms by relying on provided APIs.
Composition Reasoner: Such a component checks the feasibility of the input goal with respect to the available services provided by the LCDPs which the system is able to connect. The list of such services is retrieved and kept updated by relying on the available LCDPs connectors. For instance, by considering simple goal specification previously given, the composition reasoner would check if the available LCDPs can manage services' view types like grid and Kanban views.
Goal2Workflow transformation: By relying on the outcome of the Composition Reasoner and by considering the available LCDPs connectors, this component generate possible workflows that are compatible with the specified goals. Similarly to what happens in model transformation compositions, different solutions can be possible and the system will provide the user with a ranked list. By considering the previous example, the component would show all the possible workflows that permit to generate grid and Kanban views out of a source model. In case there are more than one services (even provided by different LCDPs) are able to manage grid and Kanban view, the component would produce all the possible compositions.
Workflow engine: It is the software component able to execute models generated by the Goal2Workflow transformation. The engine interacts with the LCDPs that enable the execution of workflows via some exposed APIs.

CONCLUSION AND FUTURE WORKS
The paper gives preliminary study on the usage of model transformation compositions in the domain of low-code development platforms. The problem that we want to address in the medium term is about the specification of complex workflows in LCDPs. The goal is to support citizen developers by providing them with modeling constructs that permit to specify the goal of the desired workflows at a high-level of abstraction. By relying on the techniques and tools developed for composing model transformations, the idea is to generate possible workflows that satisfy the initial goal. The architecture of the planned solution has been overviewed and we plan to work on it by first focusing on the needed modeling languages, i.e., the goal and workflow specification languages. They have to be defined in an iterative manner by specifying real situations and refine the available constructs in case of errors or to cover unforeseen requirements. As a next step, we will focus on the development of the workflow engine and all the dependent components including the reasoner, and the goal to workflow transformation. We plan to apply the proposed approach in different application domains including the development of IoT systems and the specification of complex workflows involving different model managements operations.