Combining Rigorous Requirements Specifications with Low-Code Platforms to Rapid Development Software Business Applications

Abstract

Low-code development platforms have gained popularity as an effective solution to address urgent market demands for software applications. These platforms have often overcome challenges faced by traditional software development processes, including requirements engineering processes, as they tend to incorporate the requirements in their prototyping phase. However, low-code platforms have followed different approaches with proprietary languages, which is a problem when customers need to move to other technologies or intend to define the specification of their applications in a readable and platform-independent way. To mitigate these challenges, this article discusses a model-driven approach that semi-automatically produces software business applications by combining rigorous requirement specifications (defined with the ITLingo ASL language) with a concrete low-code platform (Quidgest Genio). First, we analyse the common concepts in both ITLingo ASL and Genio languages. Then, we discuss model-to-model transformations that allow converting ASL specifications into Genio low-code projects. Finally, the code generation capabilities of the Genio low-code platform are employed to generate the source code of the target software applications. To evaluate the consistency of the proposed approach, we use and discuss a simple and representative case study based on a fictitious system, the Invoice Management System (IMS), whose requirements are similar to those found in many business applications.

1. Introduction

The development of modern software applications is a complex process requiring a multidisciplinary team. The diversity of backgrounds among the members of such teams causes communication barriers and difficulties in sharing a common vision of the systems to be developed [1]. Requirements engineering (RE) practices help mitigate these barriers’ impacts and increase software development teams’ productivity [2]. RE has proven to be a crucial collaboration facilitator [3], as business requirements specifications are defined in natural languages (or controlled natural languages) that are easier to understand than programming languages.

Low-code development platforms (or just “low-code platforms” for brevity) started to grow as the need to create applications that quickly adapt to urgent market demands increased [4,5,6]. Low-code platforms intend to reduce the development and maintenance effort required to deliver and operate some application classes and enable digital-savvy citizen developers (who lack or have limited programming experience) to contribute directly to the software development process [7]. Considering a spectrum where controlled natural languages and programming languages are opposite ends, low-code platform languages stand somewhere in the middle; most of them allow for specifying business requirements more comprehensively than programming languages do. However, they are not as abstract as platform-independent specification languages. Low-code platforms such as Quidgest Genio [8], OutSystems [9], or Mendix [10] can be particularly beneficial at the prototyping stages of the development process, as experienced users of these tools can create simple yet fully functional systems in a matter of days or weeks. Currently, most large cloud providers offer low-code platforms within their cloud-based solutions. For instance, Microsoft released its Power Apps framework [11] in November 2016; Google acquired the provider AppSheet [12] and made it its primary low-code solution in January 2020; and Amazon released Honeycode [13], a low-code platform for web and mobile application development, in June 2020.

On the other hand, model-driven engineering (MDE) is an approach that considers models not just as documentation artefacts but also as first-class citizens, where models might be used throughout all engineering disciplines and in any application domain [14]. As MDE has similar goals to low-code development, there is an open debate on how low-code development differs from MDE and to what extent work carried out in the field of MDE can be directly transferable to low-code platforms [15]. For instance, Di Ruscio et al. discuss the commonalities and differences between both approaches, concluding that not all model-driven techniques aim at reducing the amount of code needed to implement software solutions, and not all low-code approaches are model-driven [7].

In the scope of this debate, our research intends to show and discuss the combination of a platform-independent language for the specification of software applications, ITLingo ASL [3], with a concrete low-code software development platform, Quidgest Genio [8]. First, we discuss how ASL compares to the Genio language to evaluate the possibility of automatically developing mechanisms to transform ASL specifications into Genio projects. Then, we take the findings of this analysis and design the proposed transformation, represented by the ASL2LC task in Figure 1. It is out of the scope of this paper to discuss the second transformation illustrated in Figure 1 as the LC2Code (code generation) task. Indeed, this transformation has been extensively implemented and evaluated in hundreds of applications of the Genio framework [16].

ITLingo is a research initiative that has proposed new languages, tools, and techniques to support users in improving their practices mainly related to project management, requirements engineering, and system design. This initiative has since expanded to include both concluded and ongoing research projects to address challenges like poor productivity and low-quality technical documentation [17].

In this scope, ASL (“Application Specification Language”) is research that explores specification languages for the IT domain, mainly targeting the design of software applications [3]. Besides continuously improving as a platform-independent specification language, recent work surrounding ASL has explored model-to-model and model-to-code transformations, respectively, from ASL into ASL specifications and from ASL specifications into Django artefacts [3].

The main contribution of this paper is the proposal and discussion of a functional approach that combines model-driven techniques with low-code platforms. This approach allows developers to quickly write software application specifications in a platform-independent language mainly focused on these applications’ data, user interface, and business aspects. ASL specifications can later be automatically converted to concrete low-code platform specifications to take advantage of the numerous features offered by these platforms. Our work differs from the work developed by Gamito and Silva [3] because, in their approach, they discuss model-to-code transformations, i.e., directly from ASL specifications into Django/Python code. In contrast, our approach is based on the combination of model-to-model and model-to-code transformations, as suggested in Figure 1. Moreover, this paper presents and compares the metamodels underlying both ASL and Genio languages and proposes ASL extensions (developed during this research) to better support the alignment and transformation between ASL and Genio specifications or models.

The rest of this article is organised as follows: Section 2 provides the background on domain-specific languages for the specification of software applications and low-code platforms. Section 3 compares the common concepts of ITLingo ASL and Quidgest Genio languages. Section 4 presents the extensions we propose to ASL based on the previous analysis and comparison findings. Section 5 overviews the ASL2Genio transformation mechanism. Section 6 illustrates how the evaluation and testing of this research were conducted based on a simple yet representative business application. Section 7 identifies and discusses the related work. Finally, Section 8 presents the conclusion, discusses the advantages and limitations of the proposed approach, and identifies future research goals.

2. Background

This section introduces the main concepts and technologies underlying this research. Namely, it introduces ITLingo ASL, a platform-independent language for the specification of software applications, and Quidgest Genio, a low-code platform for developing business software applications.

2.1. Domain-Specific Languages for Business Apps

Domain-specific languages (DSLs) are visual or textual languages specialised in solving problems for specific domains, as opposed to general-purpose languages (GPLs), which provide mechanisms to solve problems in any domain [18]. It is important to note that a higher degree of specialisation means that new DSLs can be created to solve specific problems, and DSLs can solve problems related to their domain faster than GPLs can [19]. Popular examples of DSLs are HTML (Hypertext Markup Language) [20] and CSS (Cascading Style Sheets) [21] (for web pages), or LaTeX (for technical documentation) [22].

In this study, we focus on DSLs for the specification of business applications. A problem faced by development teams in the IT industry is the language barrier between software developers (responsible for building such applications) and business analysts or domain experts (responsible for specifying the business and user requirements). These DSLs can contribute [18,23] to (1) increasing the developer’s productivity because they are simpler to understand and write, (2) reducing the language barrier between different stakeholders, and (3) increasing the overall productivity of the development team.

2.2. Low-Code Development Platforms

Low-code development platforms started to grow as the need to create applications that quickly adapt to urgent market demands increased [4,5,6,7,24]. These platforms produce applications whose source code is mostly automatically generated rather than being hand-coded as it occurred traditionally. Based on code generation features, this approach aims to reduce delivery times and the size of the teams required to build them. On average, low-code platforms can decrease the time to produce a fully functional system from months to days, or from years to weeks, depending on the complexity of the needs of their customers [25].

The reduced need for manual code allows professionals without an IT background to design and build complex systems using their domain expertise to define application specifications, which may be used to automatically generate fully functional software products. For instance, a study conducted by Gartner in June 2021 predicts that non-IT professionals will build around 80% of technology products and services by 2024 [26]. This trend is fuelled by the growth of low-code software development platforms and the use of artificial intelligence applied to the automatic generation of code [27].

Moreover, the “low-code” trend is not exclusive to the industry. Some academic research has been conducted towards analysing the evolution of low-code platforms, focusing on their promises and limitations. For example, Frank et al. [5] perform an exploratory study in the market of low-code platforms to determine whether and to what extent the promises and prospects of low-code platforms are appropriate. Their study did not find evidence that low-code platforms go beyond the state of the art in the research. However, the authors acknowledge that the “low-code” trend raises awareness of the importance of researching alternative representations to code. Overeem [6] discusses the evolution of low-code platforms and how they can support the new generation of digital companies. For instance, the author discusses how software applications generated by low-code platforms must include features of modern software systems, such as event sourcing [28], API management [29], and evolution supporting architecture [30], in order to be an effective tool to support the development of complex software systems. Bock et al. [4] provide a balanced account of the current trend of low-code platforms. The authors discuss how low-code platforms compare with the current status of research, and what opportunities for future research arise from the present attention to low-code platforms. Similarly, their analysis did not provide evidence that the individual components of low-code platforms are radical innovations but that the momentum generated by the “low-code” trend gives rise to other significant research opportunities.

2.3. ITLingo ASL

ITLingo ASL (or just ASL for brevity) [3] is a specification language to define software business applications and is part of the ITLingo Initiative [17]. ASL combines some concepts from ITLingo RSL and OMG IFML languages. ITLingo RSL is a requirement and test specification language [31,32,33,34]. OMG IFML language is a modelling language to describe the user interface aspects of an application front-end [35].

The fundamental concepts (relevant for this paper) provided by ASL are (1) data entities and enumerations, which represent domain-specific concepts; (2) UI elements, such as UI containers, components, and parts; (3) actors, who represent roles played by users or other systems; and (4) use cases, which represent interactions between the actor(s) and the system under consideration. These concepts are organised in the following key architectural views: data view and use case view (also based on the RSL language) and user interface view (inspired by the IFML language).

To assist the writing of *SL specifications (namely, ASL specifications), some software tools have been offered within the context of the ITLingo Initiative. Currently, authoring ASL specifications is best supported by ITLingo-Studio, a specialised tool for rigorously writing *SL specifications [17]. However, a web version of ITLingo-Studio is being developed, named ITLingo-Cloud. This platform aims to bring multi-organisation and multi-project collaboration features to the ITLingo ecosystem. Figure 2 shows some of the features provided by ITLingo-Studio to aid the specification process, such as syntax highlighting and error checking.

2.4. Quidgest Genio

Quidgest Genio (or just Genio for brevity) is a low-code software development platform developed by Quidgest, a multinational technology company based in Portugal [36]. Genio is defined as an extreme low-code platform (rather than simply a low-code platform) since, according to Quidgest, solutions generated by Genio are composed of, on average, only 2% of manual code [8]. Since most of the source code is automatically generated, the resulting systems are easily maintainable and adaptable to new market demands.

Developing software systems in Genio follows a model-driven engineering approach; most of the effort is put into creating models that can be used by any business process, rather than following a process-driven approach by specifying distinct business processes.

Genio acts as an IDE that supports editing data entities, business rules, forms, and menus of software applications rather than source code. Genio’s user interface is shown in Figure 3, including a menu with the main concepts that can be defined.

3. Comparison of ASL and Genio Languages

This section compares and discusses ASL and Genio based on their language metamodels to draw initial conclusions about their closeness and alignments. This comparison aims to identify: (1) concepts that are defined in both ASL and Genio so that the ASL2Genio generator can transform them directly; and (2) concepts that are defined in Genio but not in ASL, so we can design extensions to ASL and later update the generator accordingly.

This analysis focuses on the following groups of concepts usually found in the specification of business applications: data entities, user interface (UI), actors, use cases, and related concepts.

A fictitious “Invoice Management System” (IMS) supports our analysis and discussion. The following text presents a summary description of the IMS informal requirements, which are further detailed in [32,34]:

“The Invoice Management System (IMS) is a system that allows users to manage customers, products, and invoices. An IMS user has a user account and is assigned to user roles, such as operator, manager, and customer. For each customer, the system shall maintain the following information: name, fiscal id, logo image, address, bank details, and additional information such as basic personal contact information. Each product must have only one VAT category and maintain the respective current VAT value. Additionally, the system should maximise the productivity of its users by using computed fields, so the users only need to focus on what is strictly necessary. [...]”

3.1. Data Entities

The elicitation and representation of data entities are usually defined as the first steps of the development process of model-driven business applications (in parallel with use cases or scenarios specification). Data entities denote the key concepts used in domain modelling, data modelling, or data specification [32,37].

Figure 4 shows a fragment of ASL metamodel focused on data specification, which includes DataEntity, DataAttribute, and Constraints concepts. A DataEntity denotes a data element defined by several DataEntityConstraints and DataAttributes. A DataAttribute represents a data value of a particular type (e.g., Integer or String) and is characterised by several DataAttributeConstraints. A DataAttributeConstraint can be used to mark a DataAttribute as a primary key of a DataEntity, to reference other DataAttributes denoting foreign keys, etc.

Spec. 1 shows a partial ASL specification of data entities that support the IMS system, considering some of the usual properties an invoice (and invoice lines) shall include.

• Spec. 1. ASL specification of the “Invoice” and “InvoiceLine” data entities (IMS example).

On the other hand, Figure 5 shows a fragment of Genio’s metamodel focusing on data entities and related constructs based on Genio’s terminology. A Table aggregates a set of TableFields and WriteConditions. TableFields are similar to ASL’s DataAttributes, representing a data value with a particular data type. However, Genio supports the specification of different types of formulas, which allow these values to be automatically computed. TableFields can also reference Enumerations, which aggregate a set of Enumeration elements uniquely identified by their id and include a user-friendly description. Finally, WriteConditions are logical expressions that can be defined to enforce business rules at the Table level. For instance, considering the data attribute “Value Without VAT” of the data entity “Invoice”, a WriteCondition can be employed to validate if this value is greater than or equal to zero. If the condition is not met, the record cannot be updated.

By examining how common concepts are expressed in both languages, we can conclude the similarity between these two metamodels. For instance, some aspects, such as identifiers, titles, or constraints, are described similarly in both languages. However, concepts like a field’s type are not directly translatable, requiring additional mapping between the representations in both languages. Finally, some minor aspects (such as the plural form of a field’s title) can be defined in Genio but not in ASL, and there are some limitations in Genio specifications when compared to ASL, such as the character limit imposed on the definition of data entity and data attribute identifiers.

Still, performing an in-depth analysis focused on data attributes reveals key differences between them that our solution shall take into consideration:

Primary keys. In ASL, the concept of a primary key is defined as a constraint of the data attribute, whereas Genio implements it as a data attribute type. In ASL, it is possible to specify different data entities that use distinct data attribute types for their primary key data attributes, while Genio enforces that the same data attribute type is used for all primary keys. This is a limitation in Genio, as the optimal data attribute type to be used as a data entity’s primary key depends on its most common use cases. For instance, using integer primary keys reduces the size of the database, while using GUID primary keys improves the generation of random new keys.

Data enumerations. Regarding the definition of data enumerations, ASL can be improved since it allows only the text values to be specified, while Genio data enumerations have keys associated with the values. For example, the value “Invoice” of data enumeration “Document type” could have an additional key such as “I”. These keys could be used for internal use only (never exposed to the application users), such as to reduce the size of the data stored in the database or to uniquely identify the selected value when using multi-language systems.

Formulas. ASL supports the definition of whether a data attribute’s value is derived but offers no practical way of specifying how to compute it. In Genio, a field is implicitly derived when its value is computed using a formula. Formulas are expressions (written using Genio’s general purpose expression language) evaluated at different moments of the application runtime. Commonly used types of formulas are arithmetic formulas, which can evaluate logical expressions to compute a field value.

Write conditions. As discussed, Genio supports the specification of write conditions, which are business rules written in the form of logical expressions (using Genio’s general purpose expression language) that must be enforced when modifying the value of a given record. These expressions are commonly present in Genio data models. ASL, on the other hand, currently does not support the definition of such conditions.

Human-readable keys. Genio uses a property called “human key” to mark a field of a given table as one of the most suitable to represent the record on the user interface (there may be multiple fields marked as human keys). For instance, a primary key is an adequate field to uniquely identify a record during internal operations. Still, it does not provide much information to the application users when displayed on the screen. For that purpose, Genio uses fields that are marked as human keys. For example, the fields “Name” or “Fiscal ID” are potential candidates to be marked as a human key for the table “Person”. In ASL, this type of specification is not yet possible.

3.2. UI Elements

Business software applications depend on user input to support data management tasks that build most of the knowledge of these systems. UI elements, such as menus and forms, are commonly defined to support CRUD (i.e., short for “create, read, update, and delete”) and other related operations [38,39].

For the specification of UI elements, ASL follows the IFML terminology, in which the UI structure is defined with UI containers, UI components, and UI parts. The rules for expressing such elements are based on the IFML (Interaction Flow Modeling Language) [34]. UI components supported by ASL include lists, details, forms, dialogues, and menus [3,35]. Figure 6 shows a fragment of ASL’s metamodel with a focus on UI components and other constructs directly related to them. A UIContainer aggregates a set of UIComponents, and a UIComponent is bound to a given DataEntity and aggregates UIComponentParts. A UIComponentPart is bound to a given DataAttribute and can be defined as a field (i.e., a part that is visible to the user, may trigger events, and may receive values through parameter passing) or a slot (i.e., a value placeholder that is not visible to the user).

As suggested by the UIComponentType enumeration, a UIComponent can be used to specify diverse types of UI elements, such as Forms or Lists, which are both directly offered by Genio. Spec. 2 shows an example specification of a Form and a List bound to the “Invoice” DataEntity.

3.2.1. UI Forms

Information systems often use forms to support CRUD operations on data entities. Figure 7 shows a fragment of Genio’s metamodel focused on forms and other related constructs. For instance, it shows that Forms shall be bound to a given Table and aggregate a set of Form fields, each bound to a given Table field. In Genio, as suggested in Figure 7, a Form supports the definition of the minimum access level (MAL) required to read and update the record. This means that when a user attempts to open a form to perform a certain action (for example, to update a record), the system verifies if the user’s access level is greater or equal to the minimum access level allowed for the corresponding task (in this case, to update the record).

Regarding Genio Forms, we can create a direct mapping to ASL. In particular, ASL’s UIComponent may be directly used to represent a Genio form’s key concepts without requiring any expansion. For example, the form itself may be defined as a UIComponent, and its fields each as a UIComponentPart.

• Spec. 2. ASL specification of a Form and a List for the “Invoice” data entity (IMS example).

3.2.2. UI Lists

Like Forms, Lists are UI components commonly found in information systems optimised for data reading, searching, and filtering purposes. Lists usually show data in tabular views and help users deal with large amounts of data.

In Genio, lists are implemented as a type of menu entry. Additionally, Genio supports the definition of lists as form fields, allowing them to be rendered inside forms, which helps list-related records. Figure 8 shows a fragment of Genio’s metamodel focusing on menu pages and other related constructs.

In Genio, a support form is a form that is used to perform CRUD operations of a given table in the context of a specific list. As shown in Figure 8, Genio’s user interface makes it easy to specify which form should be used for this purpose. This is possible since, during code generation, Genio automatically creates the appropriate buttons in the user interface to support this behaviour. We can specify the necessary buttons and their proper actions to achieve similar ASL results.

3.3. Actors and Use Cases

ASL supports the specification of actors and use cases. Actors represent the entities that interact with the system, namely user roles and external systems [31,34]. Use cases represent a sequence of actions performed by the system’s actors, such as CRUD operations, as well as other specific actions (e.g., approve, export) [31,34]. Figure 9 shows a fragment of ASL’s metamodel with a focus on actors and use cases. For instance, it shows that: (1) UseCase aggregates a set of UCActions, operates around a given DataEntity, and has a primary Actor; (2) the primary Actor of the UseCase can either be a user of the system or an external system; (3) a UseCase can be classified as a certain UseCaseType and each UCAction as an ActionType.

Spec. 3 shows a partial ASL specification of actors (e.g., aU_Operator and aU_Customer) and use cases (e.g., uc_CreateInvoice and uc_PrintInvoice). For instance, the use case uc_CreateInvoice defines the actor aU_Operator, who initiates it, and the involved data entity e_Invoice.

• Spec. 3. Example specification of actors and use cases in ASL.

As defined in ASL, the concept of actor partially exists in Genio, but only the equivalent of ASL’s actors of type “User” can be defined. The concept of use case is supported in ASL but not in Genio. Instead, Genio supports the definition of access levels and access rights. Access levels can be assigned to the end-users (e.g., “Manager”, “Customer”), while access rights define types of CRUD operations on data entities. For example, users with the access level “Customer” may read or consult invoices, and only users with the access level “Manager” may update invoices. Use cases are not explicitly supported in Genio but are an implicit aspect resulting from the combination of access levels with access rights, as shown in Figure 7.

4. ASL Extensions

This research identified concepts supported by ASL and Genio languages, which our transformation tool can convert directly. However, the study also identified some concepts that ASL did not include at the beginning of this work. This section presents the extensions added to ASL to improve its alignment with Genio’s metamodel and its flexibility as a platform-independent specification language. Figure 10 shows the extended ASL metamodel focusing on the proposed changes.

4.1. Data Attribute’s Formulas

The first extension added to ASL was the support for specifying formulas defined at the data attribute level. Formulas are expressions that are evaluated at different moments of the application’s runtime (e.g., when a record is saved in the database) to compute a value of a corresponding data attribute (or field) based on the value(s) of other data attribute(s).

As shown in Figure 4, Genio supports the specification of different types of formulas. Upon analysis, we proposed two types of formulas: arithmetic and details formulas.

Arithmetic formula. An arithmetic formula supports the specification of basic arithmetic operations (e.g., addition, subtraction, multiplication, or division) to compute the value of its associated data attribute. For instance, considering a data attribute “Value With VAT” of the data entity “InvoiceLine”, an arithmetic formula defined by “formula arithmetic (e_InvoiceLine.valueWithoutVAT * e_Product.VATValue)” can be used to calculate the value (including VAT) of the invoice line.

Details formula. A details formula allows the specification of operations on related data entities of a given data entity. For example, considering a data attribute “Total lines” of the data entity “Invoice”, a details formula defined by “formula details: count (e_InvoiceLine)” can be used to calculate the total number of lines of an invoice.

To implement the rigorous definition of such formulas, we add a simple yet flexible expression language [19]. The syntax of this language is similar to other expression languages, such as the one in Microsoft Excel [40]. Spec. 4 shows an example usage of this expression language to specify both arithmetic and details formulas in an improved specification of the “Invoice” data entity.

• Spec. 4. Example usage of formulas for the ASL specification of the “Invoice” data entity.

4.2. UI Elements’ Expressions

Using the same general purpose expression language initially added to ASL to support the specification of formulas at the data attribute level, it is possible to define other types of expressions, such as conditions that can help shape the user interface. To this end, we propose two additional usages of expressions at the UIComponentPart level: ShowIf and BlockIf conditions.

ShowIf condition. A ShowIf condition is an expression associated with a UIComponentPart that determines whether it should be displayed in the user interface or not. For instance, considering a Form field “Customer Name” with the ShowIf condition defined by “showIf (e_Invoice.customerID !=““)”, the ShowIf condition specifies that the field shall be hidden if the value of the data attribute e_Invoice.customerID is empty.

BlockIf condition. A BlockIf condition is similar to a ShowIf condition as both are expressions specified at the UIComponentPart level to manipulate the user interface. Unlike a ShowIf condition, a BlockIf condition determines whether the part should be visible but blocked from accepting user input rather than being completely removed from the user interface. For example, considering a Form field “Customer Name” with the BlockIf condition defined by “blockIf (e_Invoice.customerID !=““)”, the BlockIf condition specifies that the field shall be blocked if the value of the data attribute e_Invoice.customerID is empty.

4.3. Extended Data Enumerations

Another extension added to ASL is the support of key/value pairs of strings to define data enumerations. Previously, ASL only supported the specification of data enumerations with values (without an associated unique identifier). As discussed in Section 3.1, using this unique identifier for the data enumeration element brings some advantages. For example, it makes it possible to uniquely identify an element in multi-language systems where the associated value is translated according to the user’s preferred language. Additionally, it contributes to keeping the size of databases as low as possible since the keys are potentially significantly smaller than their associated values.

Spec. 5 shows an example specification of the data enumeration “Document Type”, using the newly added unique identifiers.

• Spec. 5. Example specification of the data enumeration “Document Type”.

5. ASL2Genio Transformation

The ASL2Genio transformation is another extension to ASL (namely, to ASL’s code generator), which makes it available in any software tool offered within the ITLingo ecosystem that supports ASL specifications. For Eclipse-based development environments (ITLingo-Studio) [41], the artefacts are continuously generated as the user changes the source specification file. These artefacts are available locally in the user’s Eclipse workspace. Complementary and for Web/Cloud-based editors (ITLingo-Cloud), the user may click a generation button to start this task when needed. In that case, the server generates the artefacts and packages them as a zip file so the user can download and use them later in the scope of the “Import Genio Project” task.

Since Genio’s import and export mechanism is designed to represent Genio projects in XML format and with a specific directory structure, the proposed generator must meet these requirements. For instance, some concepts, such as data enumerations, must be generated within the same XML file, while others, such as data entities, are expected to be placed in separate files (one file per data entity).

Table 1. Overview of the structure of Genio XML files.

ASL Element	Genio Element	Folder	File Name (.xml)
DataEntities	Tables	GENTABEL	{Data entity name}
UIComponent	Forms	GENFORMS	{Form name}
UIComponent	Menus	GENMENUS	{Menu name}
-	Modules	GENMODUL	{Module name}
DataEnumerations	Enumerations	-	GENARRS
Actors + UseCases	Access levels	-	GENNIVAC

overviews the expected file and folder structure of the generated artefacts.

As mentioned above, the ASL2Genio transformation extends to ASL’s code generator. This code generator is built using the Xtend framework [42] and handles the initial parsing of an ASL specification file. Then, based on the requested target platform (currently, the Genio platform), the generator instantiates the appropriate extension.

Figure 11 shows the involved tasks to transform an ASL specification into a Genio project, including the ASL2Genio transformation and the creation of the Genio project using the generated XML files.

As discussed in Section 1, this research focuses on designing and implementing the ASL2Genio transformation. Spec. 6 shows the pseudo-code of the generate method of ASL’s Genio extension, which was implemented based on the aspects discussed in Section 3 and according to the structure outlined in Table 1.

• Spec. 6. Pseudo-code of the generate method of ASL’s Genio extension.

6. Case Study: Invoice Management System

This section presents a case study based on the fictitious “Invoice Management System” (IMS). A summary of the informal requirements of IMS is introduced in Section 3. This case study refers to the specification and development of the IMS application based on the proposed approach.

6.1. ASL Specification

The process of transforming rigorous requirements into a software business application starts with their specification. The entire ASL specification of the Invoice Management System can be consulted in [43]. However, Appendix A presents key aspects that define the IMS application based on the following views: data (data entities and enumerations), user interface (UI elements), and use case view (actors and use cases elements).

6.2. Genio Model

Taking the ASL specification as input, we use the ASL2Genio generator to create the Genio model in XML. Then, we use Genio to import the XML files and create a new project. Figure 12 shows the table “Invoice” definition, initially specified in ASL. Similarly, the transformation engine converted any other ASL concepts mapped to Genio, such as data enumerations, forms, menus, and roles.

The correctness of the transformation rules can be extensively checked by the vast number of validations that Genio performs on project definitions. These validations check the specifications for inconsistencies, such as invalid relationships between tables, helping to reveal any problems in the ASL2Genio transformation. However, defining a set of unit tests in ASL could provide more assurance of the reliability of these transformations.

6.3. Software Business Application

To conclude the process of transforming a rigorous requirements specification into a software business application, we use Genio’s code generation capabilities. Genio supports source code generation to different target platforms and technologies, such as Backoffice C++, ASP.NET MVC, or REST Webservices [8]. Genio’s default generation target for Web Applications is ASP.NET MVC [44]. Figure 13 illustrates the process of generating the source code for the project.

Once the code generation task is finished, the steps to compile and deploy the application are the same as if the code had been written manually, i.e., as in traditional approaches. Figure 14 shows a menu page of the Invoice Management System—the list of registered products.

The user may also perform CRUD operations on the invoices, supported by the “Invoice” form, as shown in Figure 15.

7. Related Work

The recent interest in using low-code platforms to develop software applications has attracted attention from both the industry and the scientific community. Some studies have been conducted to work out common limitations expressed by customers of almost every low-code platform and opportunities for combining model-driven with low-code development approaches. This section presents the related work involving the following aspects: languages and architectural views, model-driven tool interoperability, and low-code platforms’ interoperability.

7.1. Languages and Architectural Views

IT organisations have used system and software architecture descriptions to improve communication among stakeholders and enable them to work more comprehensively and consistently [45,46]. The ISO/IEC/IEEE 42010:2011 standard defines software engineering architecture description based on the following concepts [47]: the “architecture” encompasses key ideas or characteristics of a system included in its parts, relationships, and principles of its design and development; the “architecture view” shows the architecture of a system from a specific perspective; and the “architecture description” is a work product used to express an architecture.

In the scope of software development, Kruchten discusses software architecture blueprints based on the “4+1 view model” that encompasses the following architectural views based on the UML usage: scenarios (or use case), logical, development, process, and physical views [48]. More recently, Górski proposes the “1+5 architectural views model” (also based on UML and UML extensions) for the design of cooperating information systems and especially blockchain solutions [49].

However, based on the ASL and Genio languages, the architectural views discussed in our paper are just focused on data, user interface, and use case views. The “data view” and “use case view” are relatively aligned with, respectively, the “logical view” and the “scenarios view” as proposed by the “4+1 view model” and “1+5 view model”. On the other hand, these architecture models (as well as modelling languages like UML or SysML) do not include the “user interface view” as discussed in this paper, as well as found in languages and MDE tools like WebRatio [50], XIS-Mobile [51], XIS-Web [52], Enterprise WAE [53], or Kroki [54].

The design of ASL language was strongly influenced by the architecture of modelling languages like XIS-Mobile and XIS-Web (despite being defined as UML profiles while ASL is a textual controlled-natural language). However, none of these approaches has proposed to combine its MDE features with low-code platforms as proposed and discussed in this research.

7.2. Model-Driven Tool Interoperability

Several pieces of research have addressed interoperability in software engineering since the 1980s [55]. Depending on the problem addressed, different approaches have been proposed, operating at distinct levels that achieve different degrees of interoperability. We analyse existing research on how tool interoperability can be achieved using model-driven approaches [14].

Bézivin et al. discuss how model-driven engineering approaches can be employed to solve practical engineering problems [56]. Much like ours, their approach to this challenge is to use small DSLs with well-focused metamodels, rather than large, generic modelling languages like UML 2.0. In their work, the authors propose a tool that makes it possible to perform model transformations to convert the specifications of one tool to another. Additionally, they identify a series of necessary steps to develop such a tool. This information, along with the general lessons and conclusions outlined towards the end of the paper, is valuable to our work.

Markus Voelter and Eelco Visser investigate using domain-specific languages to represent variability [57]. The authors believe that DSLs can be used to bridge the gap observed between current and future models and programming languages. A very similar problem is observed between different low-code platforms, which represents the primary motivation of our work. Similarly, we employ a DSL to address this problem.

Brunelière et al. discuss that approaches that operate at the API level are often too limited to achieve real data interoperability [58]. This issue is the primary motivation for their work, which proposes the construction of a metamodel-level bridge, similar to the one we suggest, to achieve interoperability between tools with variable metamodels. The authors identify a series of four main steps involved in the creation of such a bridge between distinct metamodels: (1) transcription, (2) syntactic translation, (3) semantic alignment, and (4) data interchange.

7.3. Low-Code Platforms’ Interoperability

The industry and scientific community’s interest in using low-code platforms to develop software applications has attracted attention. Consequently, several studies have been conducted to identify or solve common limitations expressed by customers and practitioners.

To our knowledge, no studies have addressed low-code platforms’ interoperability with concrete solutions. However, we identified some studies that use DSL approaches to address certain limitations of low-code platforms.

Bragança et al. discuss how SPL engineering can be supported in low-code platforms using a DSL approach [59]. The proposed solution involves a model-to-model transformation, which takes as input a representation of the low-code model, such as a JSON file, and generates its corresponding low-code metamodel. However, the authors classify this task as semi-automatic; an expert on the low-code platform verifies the generated metamodel. In our work, the low-code metamodel is not automatically generated. We propose a tool that has prior knowledge of the low-code platforms’ metamodels that it supports. Naturally, this approach requires active maintenance to support the latest versions of each low-code platform, but it allows the transformation process to be completely automatic.

8. Conclusions

This article proposes an end-to-end model-driven approach that aims to accelerate the development of software business applications by combining rigorous specifications with common features provided by emerging low-code platforms. In particular, this paper discusses a concrete application of this approach based on the ASL language and the Genio platform. Moreover, it discusses the model-to-model transformation, i.e., from ASL specifications into Genio projects (the ASL2Genio transformation). It then leverages the code generation capabilities of Genio to generate source code for concrete software applications (the Genio2Code transformation).

The experience of applying this approach (with the supported tools) to write and transform the Invoice Management System’s ASL specification into a Genio project allowed us to identify some benefits and limitations. A key benefit of this approach is that it allows developers to write rigorous specifications in a platform-independent language without sacrificing the code generation capabilities of low-code platforms. As the tool gains support for more low-code platforms, developers can test their code generation capabilities without necessarily learning them first. Additionally, because ASL specifications are platform-independent, this could promote interoperability between low-code applications.

On the other hand, a limitation of this approach could be the difficulty of maintaining the solution. Currently, the transformation mechanism only supports the transformation of ASL specifications into Genio projects, which could be challenging to maintain. As other low-code platforms would be supported, this could become complex to manage. Despite this issue, the proposed approach can also increase the quality of requirements specifications and accelerate the development of business applications by digital-savvy citizen developers.

For future work, we aim to explore the combination of ASL with other low-code platforms and research their reverse transformations (in this case, from Genio projects into ASL specifications). If paired, these two developments could represent a promising step towards achieving interoperability between low-code platforms and, consequently, a higher level of independence from vendor-specific solutions. Following the work developed recently [32,37,60], we also intend to research linguistics patterns and practical guidelines to better specify business applications, in particular, those most related to the user interface aspects. Furthermore, we plan to research intra- and inter-dependencies between ASL constructs and related languages [61,62], considering the minimisation of their combinatorial effects [63]. Finally, we intend to explore additional concepts and transformations to increase the overall quality and productivity of the proposed approach, for instance, considering emerging areas of blockchain and smart contracts [49,64], robotic process automation [62,65,66], and hyperautomation applications [67].