Model Slicing on Low-code Platforms Ilirian Ibrahimi1,2,∗ , Dimitris Moudilos2 1 Johannes Kepler University, Institute of Software Engineering, Altenberger Straße 69, Linz, Austria 2 CLMS UK. Battle House,1 East Barnet Road,New Barnet, Herts EN4 8RR, UK, and Andrea Papandreo 19, Athens, Greece Abstract Low-code platforms (LCP) use models as the main artifact during the software development process. Typically, the modeling activity concerns both structural and behavioral aspects of the generated appli- cation, like the underlying data model (DM), User Interface (UI), and business logic (BL), resulting in a collection of interconnected models. Thus, reusing model fragments across different projects would be a highly beneficial feature for LCPs and their users. This paper presents a model slicing approach for LCP models that combines DM, UI, and BL modeling concerns. A model slice consists of a DM class which serves as an input for the approach, its DM constraint-related classes e.g., base classes, and its related UI entities as well as BL functions. The model slicer operates on separated model repositories which will be queried to find related entities to the DM input class and integrate them automatically into the LCP. We conducted an experimental evaluation with zAppDev models and concluded that 77.78% of the DM classes are cross-connected to any entity among the zAppDev models. Hence all these connected entities can be extracted as model slices and reused automatically. Keywords MDE, Low-code platfroms, Model slicing, Model reuse, Knowledge graphs 1. Introduction Low-code platforms (LCP) are cloud-based applications that serve for building full-stack software applications without necessarily requesting coding knowledge. One of the main capabilities of an LCP is modeling the software application by designing its data models (DM), the user interface - Form models, and business logic model(s) (BL), writing as less as possible domain-specific code for implementing and deploying a complete software application. Typical software engineering activities like coding in a general-purpose language, code formatting, modularization, database configuration, deployment, etc, are automated [1, 2]. By giving priority to modeling rather than coding, LCP enables so-called citizen developers, i.e., stakeholders with very limited or even no coding experience, the opportunity to create full- stack software applications which makes the LCPs more popular and useful in the software development industry [3]. LCPs leverage model-driven engineering techniques (MDE) so that models are the cornerstone artifacts that drive the overall engineering process [4, 5]. Some of these models as a whole or Staf 2022 Workshop - 2nd International Workshop on Foundations and Practice of Visual Modeling (FVPM) ∗ Corresponding author. Envelope-Open ibrahimi.ilirian@gmail.com (I. Ibrahimi); d.moudilos@clmsuk.com (D. Moudilos) GLOBE https://github.com/iliriani (I. Ibrahimi); https://clmsuk.com/ (D. Moudilos) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) part of it (i.e., their elements) might be shared among different LCP systems. Thus, finding any solution on how to reuse these models, which may be of different languages like XML, JSON, etc., and different levels like DM, UI models, etc., and providing all this information automatically to the user in the domain modeling stage would be a novel and highly on-demand task. Hence, this paper presents an approach for model reuse through model slicing on LCP. To get the information on heterogeneous models, our approach converts all the heterogeneous models to a homogeneous graph which will serve as a knowledge graph (KG). And to cope with the different levels of models, we created two different repositories, one for the DM, and another for the Form models. The two repositories persist the KG for the DM and the Forms respectively. The model slicing approach gets as input a DM class and queries both repositories in order to get related entities to it. The required entities within the DM repository like base class, composition, etc. will constitute the horizontal slice since they belong to the same model level (i.e., DM) as the input class. And the related entities from the Form repository will constitute the vertical slice since they belong to a different level than the input class. Both slices will be merged as a single model slice and provided to the developer1 in a JSON format. As a proof of concept, we have tested our approach on the zAppDev2 LCP by using 5 different zAppDev DM ( in XML) with a total of 27 different domain classes, and 47 different Form models related to these domain models. The evaluation revealed that 77.78% of the given DM classes had any kind of cross-model relation i.e. we could extract successfully 21 distinct cross-language and cross-level model slices from these zAppDev models. The approach has been developed on Spring boot and is provided as a REST API. In the rest of this paper, we present in Section 2 a running example in order to better understand the aim of the model slicing approach. In Section 3 we outline and explain how the model slicing approach works. In Section 4 we present an experimental evaluation of our approach. Afterward, in Section 5 we present some related work to model slicing, and finally, in Section 6 we provide the conclusion and the tentative future work. 2. Running Example To clarify the concepts used throughout this paper, we will initially provide some background information. 2.1. Background Information about the zAppDev LCP zAppDev is a web-based, model-driven development environment, allowing developers of any technology and proficiency level to easily create, edit and reuse models of software artifacts (e.g. database models, business logic models, user interface models, and more), covering the complete application development lifecycle while having total control of the process. As explained in [1] an LCP typically consists of 4 different layers which are included as well on zAppDev and are comprised of 1. The application layer is represented by the Form models, 2. The service 1 For the sake of brevity, in this paper we will use the terms developer interchangeably for citizen developer 2 https://zappdev.io/ integration layer by API adapters, 3. The data integration layer is represented by data models, the service models, API Adapters, and finally 4. The deployment layer is represented by the Cloud. The layers of interest for us are the appli- zAppDev cation and data integration layers and their L3 metalanguage (C#) corresponding models since these are the only models the developers have direct contact conforms to conforms to with. Concretely, in this work, we will work with zAppDev data models a.k.a business ob- Business Object Web Form UI ject models (BOs), and Form models a.k.a L2 metamodel metamodel UI-Form models. The BO and UI-Form mod- els belong to the zAppDev L1 level of the 3- conforms to conforms to level meta-modeling architecture as depicted in Fig. 1. Both, the BOs and the UI-Form mod- ... ... L1 n m els are instances of the Business Object meta- BO Model UI Form Model model and Web Form UI metamodel respec- tively (L2 level). Whereas both metamodels conform to the zAppDev metalanguage writ- Figure 1: Metamodeling layers on the zAppDev ten in the c# programming language (L3 level). LCP The metamodels and the metalanguage are embedded on zAppDev and the developers have no access to them, they start the work directly by creating BO models as instances of the BO metamodel and auto-generate the UI-Form models from the BO models or they can initially design the UI-Form model and connect it afterwards to the relevant BO model. Lastly, the developers define the business logic of any UI component within the UI-Form model by using the Mamba language. Now, by explaining a running example we will be trying to clarify how this approach will extract model slices from LCP models. 2.2. Running example Assume that in an LCP there is an I n v o i c e software containing a BO, a UI-Form model named ”Invoice Form” auto-generated from the BO classes or manually constructed by the developer, and the business logic functions related to the BO classes. The architecture of the I n v o i c e software is depicted in Fig. 2. In the zAppDev LCP, the BOs are presented in XML format, the UI-Forms as JSON files, and the DSL functions are written in the Mamba3 language. As we can see in Fig. 2 on the left part, the BO is constructed from the classes I n v o i c e , C l i e n t , and C o m p a n y . We aim to get only the related cross-level and cross-language artifacts to the C l i e n t BO class. As depicted in Fig. 2, the C l i e n t BO class is related to the Invoice Form with a label with the text C l i e n t on it and a combo box. Further, we can see that the C l i e n t class has an Edit function related to it. To emphasize the connection of all the C l i e n t related cross-level and cross-language entities we rounded and connected them with a blue cycle and blue lines. 3 https://docs.zappdev.com/MambaLanguage/About/ Repository Invoice Form Invoice Date: number: Client: <> Save Preview Delete Exit Model slice Generates UI-Form controlls Invoice business model Client: <