=Paper=
{{Paper
|id=Vol-3250/fpvmpaper3
|storemode=property
|title=Model Slicing on Low-code Platforms
|pdfUrl=https://ceur-ws.org/Vol-3250/fpvmpaper3.pdf
|volume=Vol-3250
|authors=Ilirian Ibrahimi,Dimitris Moudilos
|dblpUrl=https://dblp.org/rec/conf/staf/IbrahimiM22
}}
==Model Slicing on Low-code Platforms==
https://ceur-ws.org/Vol-3250/fpvmpaper3.pdf
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: <