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 application, 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 diferent projects would be a highly beneficial feature for LCPs and their users.
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 [
LCPs leverage model-driven engineering techniques (MDE) so that models are the cornerstone
artifacts that drive the overall engineering process [
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). part of it (i.e., their elements) might be shared among diferent LCP systems. Thus, finding any solution on how to reuse these models, which may be of diferent languages like XML, JSON, etc., and diferent 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 diferent levels of models, we created two diferent 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 diferent 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 diferent zAppDev DM ( in XML) with a total of 27 diferent domain classes, and 47 diferent 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.
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 [
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 Mamba 3 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.
Invoice Form Date: Amount: Details:
Invoice number: Client: <<Select>>
Company: <<Select>>
Save Preview Delete Exit Invoice business model
Now the idea of a model slicer approach on an LCP as shown in Fig. 2 would be to provide to the approach only the C l i e n t BO class as input and it would be capable to compute and extract all the cross-related entities to the C l i e n t BO class and integrate those on an LCP. As shown on the right side of Fig. 2 the extracted model slice from the approach is itself a model which contains only the C l i e n t relevant entities across the LCP models.
Concluding, the model slicer tends to find connected entities to the BO input classes on cross-level and cross-language models and presents these as a model slice to the developers so everything that is connected within the entire production line on any LCP can be reused and integrated automatically on an LCP. Inspired by this running example, we have created a model slicing approach that will be explained in more detail in Section 3.
This section will be presenting in more detail how the model slicer extracts model slices from cross-level models. The overview of the model slicer is presented in Fig. 3.
The first step toward model slicing is persisting the models in a repository so they can be
reused for diferent business needs afterwards. Since all models in zAppDev are graph-based,
the repository of our approach is also graph-based. We selected the Resource Description
Framework (RDF) [
Since developing any software on an LCP ones needs to create its’ DM, its’ UI in a Form model, and the business logic which is persisted in any of these two (especially in zAppDev), we have created two diferent repositories for the model slicer, one which persists the knowledge graph for the DM, and another for the Form models. Thus, as explained in Fig. 3, step 1 of our approach is creating the repositories which persist the knowledge graph for the DM and Form models by converting them to RDF and merging them to their respective knowledge graphs.
Step 2 of our approach is getting the input class. The input class is the core entity of any model slice because any other entity of the model slice has to be related in a specific form to it. Hence, the input class defines the slicing criterion for our approach. After having the input class, the slice service - which is responsible for the business logic part of the model slicer - will query the repositories to find relevant connections between the existing entities within the repositories and the input class.
The first check the input class will go through is if it has any constraints class that has to be integrated with the input class. For instance, if the input class inherits a class within the BO classes, or has a composition class, then the base/composition class has to be integrated as well in the LCP in order to avoid model validation errors. Thus in step 3, our approach checks in the DT (BO) repository if there is any such constraints class related to the input class, and if any such class can be found it will be provided to the developers together with the input class. Since the input class and the constraint classes are on the same level (within the business object) we call this kind of relation as horizontal slicing. Since we are slicing only zAppDev models so far, the horizontal slice is defined only by checking if the input class has any base class within the BO repository.
Next, the model slicer service will check if there is any related entity within the Form KG to the input class. In step 4 the model slicer will return all the relevant information about the related entities to the input class. In our case, we query the information about UI components, i.e., the UI component name, the UI component data source - which shows to which specific UUIUII
Forms convert to
Step 1 convert to Knowledge graph of BOs
Repositories
Knowledge graph of Forms
Step 3 Query the BO KG for finding input class constraint classes
Step 4
Query the Forms KG for finding input class related UI components and
DSL code BO class input Step 2
Slice service combine results and generate the slice
Step 5
Model slice attribute of the input class the UI component is related, and the type of the UI component, e.g. TextBoxControll, CheckBox, etc. Although a lot of other relevant information can be retrieved e.g. the cascade style sheet (CSS) information about the UI components, UI components layout information, etc. Since in zAppDev the DSL functions a.k.a. Mamba functions are persisted within the Form models, in step 4 the model slicer also queries for related Mamba functions to the input class. Hence the UI components and DSL functions are not in the same model level as the input class, we call this relation of connected cross-level models a vertical slice.
Finally, the extracted horizontal and vertical slices will be merged as a single model slice and integrated into the LCP.
An example of model slicing is presented in Fig. 4. We see that the meta-class C l a s s 1 is connected to the UI components C o m p . 1 and C o m p . 2 and also to the DSL functions Func. 1 and Func. 2, thus the connection of all these entities would give a single slice (Slice 1). Further in Fig. 4, we can see that the meta-class C l a s s 3 has a constraint class C l a s s 2 within the BO, it is also related to the component C o m p 3 on the UI - Form model, and it has also a related DSL function Func. 3. The connection of these related entities to C l a s s 2 would produce another modeling slice (Slice 2).
This section demonstrates how the model slicer extracts model slices on real LCP models.
As a proof of concept, we got 5 diferent BOs and 47 diferent UI-Form models generated by these business objects. We have created two diferent knowledge graphs which contain all the information about the BOs and the Form models respectively. Then we selected each class iteratively from the BOs and gave this as an input class to the model slicer and checked the extracted model slices. In Fig. 5 we have presented the information that will be extracted by the model slicer. In this demo, the model slicer will try to extract a model slice related to the C l i e n t class.
Metamodel excerpt
a) Metaclas constraints - horizontal slice <Class ModelName="CoreBO" Name="Client" ShadowModel="" ShadowClass="" Description="" Stereotype="Class" PK="Id" ConcurencyControl="false" AutoAssignPrimaryKey="true" IdGeneratorType="HiLoGenerator" IsPersisted="true" IsStatic="false" BaseClass="" TableName="" BaseClasses="" BaseModel=""> <DiagramInfo IsExpanded="true" Width="220.16259765625" Height="310" Top="19.921142578125" Left="791.0921020507812" /> <Attributes> <Attribute Name="Company" IsValueClass="false" Description="" DataType="string" BaseInfo="" Length="100" Precision="8" Scale="2" InitValue="" IsRequired="false" IsInherited="false" Persisted="true" ColumnName="" IsEncrypted="false" IsStatic="false" ReadOnly="false" IsExternal="false" CustomValidation="" IsCreditCard="false" IsURL="false" IsEmail="false" MinLength="0" MaxLength="100" MinValue="" MaxValue="" Getter="" Setter="" /> .... </Class>
b) DSL functions c) UI components d) Data set Cross-model metaclass matching entities Horizontal slicing Vertical slicing
Form excerpts .... "Actions": [{ "Code": "function void Edit(int id) { \n Model.Client = Domain.Client.GetByKey(id);\n Model.Title = LocalResources.RES_PAGETITLE_Edit;\n}", "Name": "Edit", "Permissions": [], "AllowAnonymous": false, "AllowAllAuthenticatedUsers": true, "AccessLog": false, "IsEntryPoint": true, "IsDefault": false, "CausesValidation": false, "DontPostViewModel": false, "AllGroups": true, "Groups": [].... "Controls": [{ "$type": "CLMS.AppDev.DomainModel.Models.TextBoxControl, CLMS.AppDev.DomainModel", "ReadOnly": false, "Required": true, "ChangeWhileTyping": false, "ChangeDelay": 200, "MaxLength": 100, "Name": "txtCompany", "CssStyle": "", "CssClass": "", "Datasource": "Client.Company", "DoesNotMakeFormDirty": false, "FontSizeRole": 0, "ElementSizeRole": 3, "ColorRole": 0, "FilterOperator": 7, "RowOperator": 1, "Ovewrite": true, "ApplyOnBlur": true, "HiddenInMobileView": false, "Ignored": false, "Controls": [] }] "DataSets": [{ "Type": 1, "Name": "ClientDataSet", "Class": "Client", "Operation": "GetAll", "Filter": "function bool Filter(\n Domain.Client DataItem\n) {\n return true;\n}", "Sorting": [], "OvewriteDefaultSecurity": false, "AllowAnonymous": false, "AllowAllAuthenticatedUsers": false, "Permissions": [], "ManualOptions": [], "Arguments": [],
Initially, the model slicer will check within the BOs at the baseClass element to find any base class so it can create the horizontal slice ( a) ). This check is presented with the red dashed arrow. In this demo, the C l i e n t class hasn’t any base class, and since at the time of writing this paper this is the only checked constraint for BO classes, will the model slicer not define any horizontal slice. Next, the model slicer will check for extracting the relevant Mamba functions from the zAppDev Form models ( b) ). The model slicer will check within the Code notation to find any related function to the C l i e n t class. The found functions will be returned as part of the vertical slice.
In the end, all the information about the horizontal and vertical slices will be merged in a single JSON file and integrated into the zAppDev LCP. This model slice is extracted after selecting the C l i e n t BO class and clicking the ”Create forms from Slice” button located in the menu bar as shown in Fig. 6. The model slice is integrated on the zAppDev LCP as a UI-Form model including the extracted information for the C l i e n t BO class. A snapshot of the integrated model slice on zAppDev is depicted in Fig. 7.
In Table 1 we have outlined the results of how many model slices could be extracted from the zAppDev models. For the study, we have used 5 diferent business object models and 47 diferent UI-Form models. We listed all the BO classes from all the 5 BO models and counted 27 distinct classes. We iterated through each of these BO classes and set each of them successively as an input class to the Figure 7: Integration of the Client model slice model slicer. Of all these BO classes only one in zAppDev class had a base class (PMOUser had as base class ApplicationUser) i.e., a horizontal slice.
Also from the set of 27 distinct BO classes, the model slicer could extract 21 vertical slices which means that 21 BO classes have at least one related entity on the UI-Form models. From this amount of data we got from zAppDev, we could conclude that 77.78% of the BO classes are related at least to a base class or at least to one UI-Form model entity. This fact reveals the emerging need for a cross-language and cross-level model reuse approach on LCP that can be facilitated through the model slicer provided in this work.
The model slicer has been developed using Spring boot and is provided as a REST API for use in the zAppDev LCP. The source and the repositories containing the KG used for the evaluation are available on GitHub5
Although to the best of our knowledge this is the first approach towards model ruse through
slicing on cross-level and cross-language LCP models, inspired by program slicing approaches [
Salay et al. [
Taenzer et al. [
Compare to the approaches that enable model slicing for a specific model type [
In this work, we have presented an approach that enables the reuse of cross-related models on an LCP through model slicing. The model slicing approach gets as input a data model class and queries the data model for any constraint-related class, and also the Form model repositories to get UI components and DSL functions. The current approach enables model slicing of zAppDev models but conceptually it can be used for any LCP.
In future work, we plan to fine-grain the model slicer by proving UI component layout information, slicing the class attributes, etc. We also aim to integrate the model slicer on a model recommendation approach so that after selecting a suggested data model class, all its cross-related model entities will be integrated automatically.
This project has received funding from the EU Horizon 2020 research and innovation programme under the Marie Skłodowska Curie grant agreement No 813884. [13] A. Bergmayr, M. Wimmer, W. Retschitzegger, U. Zdun, Taking the pick out of the bunch type-safe shrinking of metamodels, in: S. Kowalewski, B. Rumpe (Eds.), Software Engineering 2013, Gesellschaft für Informatik e.V., Bonn, 2013, pp. 85–98. [14] H. Kagdi, J. I. Maletic, A. Sutton, Context-free slicing of uml class models, in: Proceedings of the 21st IEEE International Conference on Software Maintenance, ICSM ’05, IEEE Computer Society, USA, 2005, p. 635–638. URL: https://doi.org/10.1109/ICSM.2005.34. doi:1 0 . 1 1 0 9 / I C S M . 2 0 0 5 . 3 4 . [15] P. Kelsen, Q. Ma, C. Glodt, Models within models: Taming model complexity using the sub-model lattice, in: D. Giannakopoulou, F. Orejas (Eds.), Fundamental Approaches to Software Engineering, Springer Berlin Heidelberg, Berlin, Heidelberg, 2011, pp. 171–185. [16] A. Blouin, B. Combemale, B. Baudry, O. Beaudoux, Modeling model slicers, in: J. Whittle, T. Clark, T. Kühne (Eds.), Model Driven Engineering Languages and Systems, Springer Berlin Heidelberg, Berlin, Heidelberg, 2011, pp. 62–76.