Model-driven Development of Front-Ends for CRUD Applications

worked on by: Alexander Korzec

Introduction

Virtually every company manages some kind of customer and employee information, e.g., contact adresses, telephone numbers, contractual data, and updates them on a regular basis. The forms used to manage these information are similar regardless of the problem domain the business is dealing with. Therefore, it can be beneficial to utilize model-driven development and use a form designer rather than implementing forms from scratch. There are two approaches to create forms with the help of another program or framework. Forms can either be generated as a code artifact before runtime [1, 2] or shown dynamically at runtime [3-5]. Overeem and Jansen call the former approach generative and the latter approach interpretive [6]. In both cases the forms are created from a set of models [1, 2, 4, 5] or with the help of a graphical menu [3].

Modern web architectures often use microservices that expose APIs for accessing and manipulating resources and are structured according to a REST pattern [7], with messages produced by microservices and consumed by UIs. These components are often developed by independent teams that must agree on APIs. One can specify a model and formalize request-response schemas to document APIs and generate code to access them using additional tools (Swagger [8], OpenAPI [9], JSON:API [10]). The input of a form designer is similar in the sense that it is described using an appropriate set of domain-specific languages. Examples of DSLs include UML, XML, and SQL, which can be extended by domain-specific abstractions [11]. Ideally, the content, behavior and appearence of the created forms is fully determined by prescribed models.

There are several possible requirements towards form designers. First, the forms themself should be user-friendly and responsive. Second, the form designer should seperate solution space from problem space. For example, input models should contain only as many implementation-specific abstractions as necessary and these should be independent of the technology used by the form. Moreover, it may be desirable to switch the technology, which the form uses, i.e., the form designer may support different templates. For example, a form designer may support the creation of not only React [12] forms, but also Angular [13] forms. This may require an intermediate product in the form of an abstract GUI. Third, the validation of the form input and the description of rules for validating the input must also be handled by the form designer. The complexity of validation rules can range from simple data type validation to some arbirarily complex function. These validation rules must be appropriately distributed among server and client, e.g., validation rules can be kept only on the server-side or in addition as a static asset on the client-side. Depending on the chosen solution, security and performance issues may arise. The form may also need to manage its state for validating user input, which increases the complexity of the form designer even further.

Outline of Contribution

This thesis is written in coorperation with t2Informatik GmbH [14] as industrial partner and takes the perspective of a UI development team. It will be shown that models can be used not only to generate code for accessing APIs, but can also be used to construct complex forms. For the functional part of the form, i.e., the access and manipulation of resources at the backend, a relationship between resources provided by REST producers, e.g., microservices, and a corresponding part of the domain model must be defined. This information has to be supplemented by additional information about the layout and design of the form. Furthermore, requirements resulting from topics such as localization, validation, and complex interrelationships and dependencies within a form are considered. The conditions under which it is possible to develop APIs and forms independently in a model-driven approach are also discussed.

A case study is conducted in which t2Informatik GmbH defines the requirements for a form designer and the utility of already existing form designers is assessed. The focus is on form designers that interpret the input models at runtime. The implementation work in this thesis depends on the existence of a form designer that fulfills all given requirements. Most likely, a custom form generator will be implemented based on existing projects, focusing especially on input validation. Moreover, design patterns commonly used by form designers are explored and used to develop the custom form designer [15-19]. Finally, the limitations of MDD of forms and the shortcomings of modern MDD software are evaluated using the case study as an example.

Technologies used in web development are subject to rapid development and change. As a consequence, a form designer should be as independent as possible of a specific technology and instead allow for the integration of various interchangeable technologies and tools. Open standards, modeling languages and their tool support play a crucial role here. Thus, it will be investigated which standards and tools can be integrated into the outlined UI development process in order to, e.g., obtain the highest degree of freedom with respect to tool support. However, the focus of this thesis is not on the creation of the models themselves, but on the integration and evaluation of the models, data and required information on client-side in order to be able to display a functioning form at runtime.

Related Work

The articles [11] and [20] serve as a foundation for the theory used in this thesis and give a general introduction into MDD theory and terminology. Omari et al. [1] outline a workflow on how to generate an Angular front-end from an UML diagram, but their case study discusses only the transformation of a single class with one attribute and method, i.e., [1] seems to be useful in context of this thesis, but the proposed workflow is only tested on a toy example. Nascimento [2] explores the generation of front-ends for multiple platforms from database schemas and uses a self-defined extension of SQL as DSL. Both AJSF [5] and JSONForms [4] create forms at runtime based on JSON inputs for the data schema and form layout. Another interesting aspect of MDD software worth noting is the usability of the generating software itself. Weber et al. evaluated that the usability of CASE and MDD software is rather mixed, which may have implications for the use of MDD in practice [21]. Overeem et al. [6, 22] conducted a literature review and summerize the benefits and drawbacks of generative MDD and model interpretaton. Voelter describes best practices for DSLs and MDD, which may be of particular interest to this thesis if the development of a custom form designer becomes necessary [15, 16]. A recent systematic review done by Alzahrani [23] concluded that 4GL code generation is not sufficiently investigated over the past 20 years. The focus of this thesis is not on code generation, but a consideration of the use of 4GLs in MDD might provide a more complete picture of the problems addressed.

Thesis Requirements

formulate requirements here (together with your adviser)

Milestones and Planning

A milestone is a scheduled event signifying the completion of a major deliverable or a set of related deliverables. A milestone has zero duration and no effort -- there is no work associated with a milestone. It is a flag in the workplan to signify some other work has completed. Usually a milestone is used as a project checkpoint to validate how the project is progressing and revalidate work. (Source: http://www.mariosalexandrou.com/definition/milestone.asp)

Milestone no.	Past		CW	Goals	accomplished
1		1	CWXX	Goals	accomplished

…

Weekly Status

Week 1 (CW XX)

Activities

• been there, done that
• …

Results

• achieved XYZ

Next Steps

• planning …

Problems

• …

References

[1] M. EL Omari, M. Erramdani, and A. Rhouati, “A Model Driven Approach for Generating Angular 7 Applications,” International journal of recent contributions from engineering, science & IT, vol. 8, no. 2, pp. 36–45, 2020.
[2] E. Nascimento, “A Model-Driven Approach to the Generation of Front-Ends,” https://web.fe.up.pt/∼jacome/downloads/thesis/evertonnascimento.pdf, 2018, accessed: 2022-03-26.
[3] “EMF Forms / EMF Client Platform,” https://www.eclipse.org/ecp/emfforms/, accessed: 2022-04-18.
[4] “JSONForms,” https://jsonforms.io/, accessed: 2022-04-18.
[5] “Angular JSON Schema Form,” https://github.com/hamzahamidi/ajsf, accessed: 2022-04-18.
[6] M. Overeem and S. Jansen, “An exploration of the’it’in’it depends’: Generative versus interpretive model-driven development.” in MODELSWARD, 2017, pp. 100–111.
[7] R. T. Fielding, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, 2000.
[8] “Swagger,” https://swagger.io/, accessed: 2022-04-20.
[9] “OpenAPI,” https://www.openapis.org/, accessed: 2022-04-20.
[10] “JSON:API,” https://jsonapi.org/, accessed: 2022-04-20.
[11] K. Czarnecki, “Overview of Generative Software Development,” in Unconventional Programming Paradigms, ser. Lecture Notes in Computer Science, J.-P. Banˆatre, P. Fradet, J.-L. Giavitto, and O. Michel, Eds. Springer, 2005, pp. 326–341.
[12] “React,” https://reactjs.org/, accessed: 2022-03-26.
[13] “Angular,” https://angular.io/, accessed: 2022-03-26.
[14] “t2Informatik GmbH,” https://t2informatik.de/, accessed: 2022-03-26.
[15] M. Voelter and J. Bettin, “Patterns for model-driven software-development,” in EuroPLoP, 2004, pp. 525–560.
[16] M. Voelter, “Best practices for dsls and model-driven development,” Journal of Object Technology, vol. 8, no. 6, pp. 79–102, 2009.
[17] C. Preschern, N. Kajtazovic, and C. Kreiner, “Applying patterns to model-driven development of automation systems: An industrial case study,” in Proceedings of the 17th European Conference on Pattern Languages of Programs, ser. EuroPLoP ’12. New York, NY, USA: Association for Computing Machinery, Jul. 2012, pp. 1–10.
[18] G. Macher and C. Kreiner, “Model transformation and synchronization process patterns,” in Proceedings of the 20th European Conference on Pattern Languages of Programs, ser. EuroPLoP ’15. New York, NY, USA: Association for Computing Machinery, Jul. 2015, pp. 1–11.
[19] P. Bachmann, “Static and metaprogramming patterns and static frameworks: A catalog. an application,” in Proceedings of the 2006 Conference on Pattern Languages of Programs, ser. PLoP ’06. New York, NY, USA: Association for Computing Machinery, Oct. 2006, pp. 1–33.
[20] R. France and B. Rumpe, “Model-driven Development of Complex Software: A Research Roadmap,” in Future of Software Engineering (FOSE ’07). IEEE, 2007, pp. 37–54.
[21] T. Weber, A. Zoitl, and H. Hußmann, “Usability of Development Tools: A CASE-Study,” in 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), Sep. 2019, pp. 228–235.
[22] M. Overeem, S. Jansen, and S. Fortuin, “Generative versus interpretive model-driven development: Moving past ‘it depends’,” in International Conference on Model-Driven Engineering and Software Development. Springer, 2017, pp. 222–246.
[23] A. A. H. Alzahrani, “4GL Code Generation: A Systematic Review,” International Journal of Advanced Computer Science and Applications (IJACSA), vol. 11, no. 6, 2020/58/30.
[24] F. P. Basso, R. M. Pillat, T. C. Oliveira, F. Roos-Frantz, and R. Z. Frantz, “Automated design of multi-layered web information systems,” Journal of systems and software, vol. 117, pp. 612–637, 2016.
[25] N. Mellegard, A. Ferwerda, K. Lind, R. Heldal, and M. R. Chaudron, “Impact of introducing domain-specific modelling in software maintenance: An industrial case study,” IEEE Transactions on software Engineering, vol. 42, no. 3, pp. 245–260, 2015.
[26] S. Jörges, Construction and Evolution of Code Generators: A Model-Driven and Service-Oriented Approach. Springer, Jan. 2013.