Automatic Code Generation of MVC Web Applications

: As Web applications become more and more complex, the development costs are increasing as well. A Model Driven Architecture (MDA) approach is proposed in this paper since it simpliﬁes modeling, design, implementation, and integration of applications by deﬁning software mainly at the model level. We adopt the The Uniﬁed Modeling Language (UML), as modeling language. UML provides a set of diagrams to model structural and behavioral aspects of the Web applications. Automatic translation of UML diagrams to the Object-Oriented code is highly desirable because it eliminates the chances of introducing human errors. Moreover, automatic code generation helps the software designers delivering of the software on time. In our approach, the automatic transformations across the MDA’s levels are based on meta-models for two of the most important constructs of UML, namely Use Cases and classes. A proprietary tool (called xGenerator ) performs the transformations up to the Java source code. The architecture of the generated Web applications respects a variant of the well-known Model-View-Controller


Introduction
Enterprise Web applications are an essential part of the computer-based information system of most organizations. They provide business-oriented tools such as online payment processing and automated billing systems. The main goal of enterprise Web applications is to improve company productivity and efficiency through business logic support functionality. Those applications perform business functions including order processing, accounting and customer relationship management.
The development of Web applications is a challenging goal [1]. For an IT project to be successful, it must reproduce, as much as possible, the business context, in such a way corporate employees can recognize in the software their daily modus operandi-each "actor" plays a set of "use cases" within an organization regardless of automation.
In general terms, a Use Case (UC) is a sequence of interactions between systems and users in a particular environment to achieve a specific goal. A UC may have multiple "paths" that can be taken at any one time. A UC scenario is a single path through an UC. In the Unified Modeling Language (UML), "UCs are a means to capture the requirements of systems, that is, what systems are supposed to do. [. . . ] A UC is a specification of a behavior." [2], p. 639.
The biggest innovation brought by the UC construct is that it exists in the business context independently from the automation process-the software designer only needs to discover UCs in the enterprise system and then reproduce them in the software application. In 2008, Paolone et al. [3] approach, analysts and designers are charged with the construction of models at CIM, while PIM, PSM and the Code are automatically generated. The transformations across levels of MDA are based on meta-models for two of the most important constructs of UML-UCs and classes. The adopted meta-models and the transformation algorithms are embedded inside xGenerator and analysts and designers do not need to care about. The architecture of the generated source code, of the enterprise Web application, respects a variant of the MVC pattern.
The paper is structured as follows. Section 2 introduces notions and terms used throughout the paper. Section 3 presents the proposed methodological process. A case study is given in Section 4 to illustrate the approach. Section 5 is about the comparison with the related work, while Section 6 concludes the paper with a look to the future work. An Appendix completes the paper.

Background
This section collects notions and concepts used in the paper. A model is a simplified abstract view of a complex reality. It may focus on particular views, enforcing the divide and conquer principle for a compound problem. In the business domain, a model represents how the business functions. In other words, we can say that a business model is "the how" of the business. It is a high level description of factors like how to add value, target customers, partners, costs, and so forth. So, an (enterprise) business model is a model of its business. Last but not least, a model must have a purpose. For a business, the purpose may be understanding its structure or its behavior. The term system model denotes a software system that (in some way) automates the business.
A meta-model is a model of a model. It defines the modeling language, that is, the constructs that can be used to express models. It defines (a) the object types that can be used to represent a model; (b) the relations between object types; (c) the attributes of the object types; (d) the rules to combine object types and relations. The meta-model is the abstract syntax, the modeling language is the concrete syntax.
Modeling s aim is representing all relevant aspects of a domain in a defined language. The result of modeling is a model. A modeling language specifies the building blocks (elements) from which a model can be made. The meta-modeling is the process of generating meta-models. A meta-meta-model defines the language in which a meta-model can be expressed.
The Unified Modeling Language (UML) Standardized by the Object Management Group (OMG) in 1997, UML is both a de facto and a de jure standard in industrial development of software systems, as reiterated in recent publications (e.g., References [5,18]).
UML diagrams provide a visual representation of an aspect of a system. They illustrate the quantifiable aspects of a software system that can be described visually, such as behavior, structure, relationships, and functionality. The visual representation of a software system that UML diagrams provide can offer both low-level and high-level insight into the concept and design of an application. In UML 2.5 diagrams are grouped in three categories [2]: UML models represent software systems at different levels of detail. UML models contain model elements (such as actors, use cases and classes) and one or more diagrams that show a specific perspective of a system. A model can also contain other, more detailed models. A typical UML model can consist of many different types of diagrams, with each diagram presenting a different view of the software system under modeling. UML models are abstract representations of a software system. A Process is a logical sequence of tasks performed to achieve a particular objective. A process defines what is to be done, without specifying how each task is performed. A software development process is composed of a sequence of tasks devoted to develop a software system.
The Model-View-Controller (MVC) Figure 1 shows the MVC pattern applied to an enterprise Web application. The rectangles with rounded corners are part of the standard MVC pattern [19]. Each layer is composed of classes. The latter implement the interactions among the three layers. The Controller interacts with the Model in order to retrieve the needed data and generates the View. The View is responsible of the management of the graphical user interface; this layer controls the way data is displayed and how the user interacts with it. It also provides ways for data gathering from the users. The Model layer implements the business logic of the application. It encapsulates methods to access data into the databases. The Browser displays the HTML produced by the View classes and sends requests to the Controller. The Unified Process is an iterative and incremental process for the development of general purpose software. The best-known refinement of the Unified Process is the Rational Unified Process. The latter is divided into disciplines: Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment, Configuration and Change Management, Project Management, and Environment [20]. In the present work, the first four disciplines of the Rational Unified Process are used.
Model Driven Architecture (MDA) provides guidelines for structuring software specifications that are expressed as models. In Reference [21], the term application is used to refer to a software functionality being developed. OMG MDA defines a platform as "a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented".
The MDA is structured in terms of the three models recalled below: • Computation Independent Model (CIM) -It ignores details of the structure of the software system. A CIM is sometimes called a domain model.

•
Platform Independent Model (PIM) -It exhibits a certain degree of platform independence so as to be suitable for use with a number of different platforms of similar type.

•
Platform Specific Model (PSM) -It combines the specifications in the PIM with the details that specify how the software system uses a particular type of platform.
The transition between the CIM, PIM and PSM models and finally the Code is possible through the execution of model transformations. A transformation converts models from one level of abstraction to another, usually from a more abstract to less abstract view, by adding more detail supplied by the transformation rules. Transformations can be Model to Model (it concerns the transition from CIM to PIM or from PIM to PSM) and Model to Text (it concerns the generation of the code from the PSM to a specific programming language as a target). Reference [18] reports about the state-of-the-art of code generation using MDA research in software engineering.
The following sentences about code generators and generation techniques are borrowed from Section 2.4 of the book by Sven Jörges [8].
Code generators automatically derive an implementation from the model, so they allow real model-driven software development. Code generators relate to models as compilers relate to high-level programming languages. As compilers, code generators support a specific source language, translate it into a target language and are implemented in a specific language. The available approaches to code generation are classified in different ways. In Reference [22], pp. 151-156, for instance, Kleppe distinguishes model transformation rules from hard-coded transformation. In the first case, the code generator is described by means of rules. These rules are processed by a tool which performs the translation from the source language to the target, and which therefore realizes a large part of the generation logic via the transformation engine. In the second case, the transformation is implemented by means of a general-purpose programming language. Code generators can output the full code or generate skeletons to be completed by programmers. In the latter case, code and models are both editable artefacts, therefore the problem is to keep them consistent. Performing this task manually increases the workload and it is error-prone. Round-trip engineering [23] is a technique aiming at automating the synchronization between code and models. The two directions of the synchronization are called forward engineering (from higher level model to lower level model or code) and reverse engineering (the other way around). Round-trip engineering poses many problems. For instance, the forward engineering task has to ensure that the code can be regenerated safely when the model has been modified. This task is not trivial, especially when the code also has been modified. MDA is an example of an approach that is frequently realized on the basis of round-trip engineering. Many code generators for UML, mainly produce skeletons that have to be completed manually. The so-called generation gap pattern [24] is a generation code technique that solves the latter problem. The strategy separates the generated code from the non-generated code by inheritance-the "hand-written" classes extend the generated ones ( Figure 2). On regeneration, the code generator can safely overwrite the superclasses, while the manually written subclasses are not affected.

The Proposed Software Development Process
This section presents a pragmatic approach aimed at the automatic development of enterprise Web applications. The proposed Software Development Process is UML-based, implements the MDA (Section 2) and makes use of a proprietary code generator.

Overview of the Proposal
With the economy at a minimum point in time, companies and projects are resetting their goals. Long term projects are cancelled, in favor of projects with feasible goals, lower costs and short time-to-market. Well-known ways of generating code from a model make use of: • Domain Specific Languages. DSLs allow textual or graphical representations of custom domains. DSLs promise high productivity, provided that the target environment can be clearly defined.

•
UML. UML provides standard techniques (e.g., use cases, class diagrams, sequence diagrams, etc.) for modeling behavior and structure of the applications. Generating code from a UML model is possible, provided that the target environment is well defined.
• Database. Many tools generate (parts of) applications from the database structure. This approach have important limitations. The generated application instead of providing support for the work processes to be automated, will mimic the database and thus will be data-centric. Besides that, in the context of service orientation and cloud computing, many applications do not even have their own database.
In the proposed Software Development Process, analysts and designers are charged with the construction of CIM, while PIM, PSM and the Code are generated by xGenerator. This tool implements the so-called generation gap pattern (Section 2), that allows updating the model without losing the hand-written code (if any).
The transition from one level to another of the MDA is achieved by applying transformations to the elements of the source level, to generate the target elements. Each transformation adds the information necessary to generate the final code, in addition to ensuring the traceability link between the models, thus guaranteeing the quality of the software generated, its adherence to the project requirements as well as the chosen architecture. In our case, the latter is a slight variant (see Appendix A) of the MVC pattern (Section 2). In this article, we present our approach to model transformation, including the transformations that lead to the generation of the application source code.
According to the OMG, the CIM level requires that both structural and behavioral aspects of the company business are modeled, as well as the relationships between them. This step is carried out through the disciplines of Business Modeling and Requirements of the Rational Unified Process (Section 2). The transformation of models used in this article focuses on the Use Case (UC) and Class constructs which, together, cover both the behavioral and the structural aspects. In our Software Development Process, the UC "enters the scene" at the CIM level to model the business and becomes a Java class in the code of the Web Application. Figure 3 shows the different levels of abstractions played by the UCs, their name, as well as the relationships among them across the layers. At the CIM, the UCs are called Business UC Realization (BUCR), while at the PIM they are called System UC Realization (SUCR); according to the Rational Unified Process. The UC construct is also present on the third layer, where it maps the PSM to (Java) code through code generation. In this paper, the terms UC, BUCR, and SUCR are used with the following meaning. UC denotes the use case construct in general; Business UC Realization describes a behavior from the user's perspective; System UC Realization describes the behavior from the machine's perspective.

Computational Indepedent Model (CIM)
At the CIM level are discovered and modeled Business Actors, Business UC Realizations, Business Objects and Business Scenarios, according to the Rational Unified Process. A Business UC Realization is a sequence of actions defining the interactions between a Business Object and a (software) system to achieve a goal. Business Objects represent real world business entities at a higher level of abstraction than software objects. Business Objects model organizational concepts, such as resources and Business Actors. Each Business Actor performs a set of Business UC Realizations in the enterprise context. Each Business UC Realization captures an elementary aspect of the system. For every Business UC Realization the main scenario is described; all deviations to such a scenario are described as alternative scenarios. Next to the Business UC Realizations, that capture the desired behavior, the Business Objects model provides a structural view of the software system. Business scenarios model the interaction between the behavioral and the structural aspects: each scenario is modeled with Sequence diagrams that contain the Business Actors, the Boundary classes and the Business Objects.
The description of the Requirements completes the CIM. They concern the structural and behavioral Business Rules. The former rules are represented in the Business Object diagram, through the attributes of each Business Object and the relationships between them. The behavioral business rules are represented, in part, in the Business Object diagram and, in part, in the sequence diagrams of the business scenarios. Figure 4 depicts the elements of the business domain that play a relevant role at the CIM level.
The CIM's artefacts to be produced are: the Business UC Realization Diagram, the Business Object Diagrams, and the Sequence Diagrams of the Business scenarios.

Platform Independent Model (PIM)
At this level, the CIM models and the relationships among them are to be transformed into system models by applying meta-models. A simplified version of the meta-models of Business Objects, UCs and Boundary classes is given in the next sub-section. The automatic transformation takes place as follows: 1. analysis of the Business Actors, Business Objects and Business UC Realizations that participate in the automation process (they are the only ones having a Boolean tag set to True), so they have to be included in the system model; 2. trans f ormation of the Business Objects into Domain Classes; 3. trans f ormation of the Business Actors into System Actors; 4. trans f ormation of the Business UC Realizations whose tag is true, in as many System UC Realizations; 5. trans f ormation of the business scenario (modeled as Sequence diagrams) into a system scenario (modeled as Sequence diagrams): the Boundary classes (of the CIM) become View classes (at PIM).
The System UC Realization constitutes the basic element for the construction of the Web Application. System UC Realizations handle a set of Business Objects for implementing operations such as: search, display, insert, edit, and so forth. The sequence diagram relates the structural aspect to the behavioral one through the use of View and Domain classes, in the system perspective exactly as happens in the business perspective. In addition to the mentioned transformations, in accordance with the recommendations of MDA, at the PIM level it is necessary to add software system classes for the automation, maintaining independence from the platform that will be chosen. In particular, this occurs for the management of the classes of Actors implemented in an additional component of xGenerator (the Login Component). Figure 5 depicts the elements of the system domain that play a relevant role at the PIM level.
The PIM's artefacts to be produced are: the System UC Realization Diagram, the Domain Class Diagrams, and the Sequence Diagrams.

The Platform Specific Model (PSM)
The same scenarios part of the PIM are still present at this level, but the Sequence Diagrams that model them are more detailed, in fact, they contain the classes of all the architectural layers of the extended MVC pattern (see Appendix A). xGenerator transforms the analysis model of the PIM into a design model using the meta-models illustrated in the next sub-section. The classes of each layer of the MVC pattern inherit from the corresponding classes of the meta-model. The automatic PIM to PSM transformation occurs as follows: • about the structural aspect:

The Code Model (PSM to Code)
Once the design of the PSM artefacts is completed, xGenerator generates the source code of the Web Application and the deployment unit. It is possible to request either the generation of the code of a Java project in the Eclipse environment or to invoke the generation of the code and the deployable unit on the cloud. As mentioned, the code is generated according to the specifications of the extended MVC software architecture (Appendix A). In accordance with what is proposed in Reference [24], the classes are generated at two different levels of abstraction ( Figure 7): for each class of the PSM, the superclass and the subclass are generated.
The output of the Code model are the artefacts: (a) one Java class for each class of the PSM at each architectural layer; (b) a Java superclass for each class of the PSM at each architectural layer and a subclass that inherits from the superclass.

Our Meta-Models
To link the business perspective to the system perspective, we have defined meta-models for the UML constructs class and UC. Figure 9 shows the main elements of the UML meta-model of the diagram of the Business Objects. Moving from the business perspective (CIM) to that of the software system, each Business Object becomes a Java Bean class that inherits from AbstractBusinessObject all the attributes and methods necessary to implement the standard behavior of a Business Object, including the management of its persistence in the database.  Figure 10 shows a simplified version of the meta-model of the UC construct. Moving from the business perspective to the software system perspective, the UC becomes a Java class that inherits from the AbstractUseCase class all the attributes and methods necessary to implement the standard behavior of the UC. At a business level, the UC manipulates Boundary classes and Business Objects. At the system level (PIM), the UC manipulates, respectively, Bean classes ( Figure 11a) and Graphical User Interfaces (Figure 11b). In the context of the Web Applications, we use Panels as Graphical User Interfaces. Moving from the business perspective to the software system perspective, Boundary becomes a Panel class that inherits the attributes and methods necessary to implement the standard behavior of a Graphical User Interface from AbstractUseCasePanel. AbstractUseCase uses the AbstractBusinessObject and the AbstractUseCasePanel to redirect the HTML pages to the browser and implement the expected UC behavior.

Discussion
Model-driven code generation could be done given some minimal settings. First, you have to know how to model; which modeling techniques to use, and how to use them. Our Software Development Process, uses UML and combines UCs and Class diagrams. Second, it is necessary to set a reference software architecture in order to generate a good and maintainable software. We adopt a variant of the MVC pattern. Third, to speed up the development further, it is recommended to use standard tools. We adopt xGenerator which incorporates Vaadin and Hibernate.
The automatic translation of UML diagrams to object oriented code is highly desirable because it eliminates human errors in the translation process. As further merits of code generators, it is worth recalling that they increase productivity, assure uniform code quality and respect of coding conventions for all the generated classes making part of a project, unlike handwritten code where the outcome is not always predictable since it is programmer dependent. Code generators assume the role of writing huge volume of repetitive code, which would take much longer if coded manually, leaving to programmers more time to concentrate on the writing of specific portions of the whole application.

Case Study: The Automated Teller Machine (ATM) Project
This section applies the approach of Section 3 for developing a Web application named ATMProject that adheres to the extended MVC pattern of Appendix A. The application automates the banking subsystem for the management of withdrawals from an account, carried out through an ATM. A similar example is taken into account in References [2,25,26]. The application implements the following operations: (a) withdrawal of a sum of money; (b) display of the balance; (c) display of the transaction list.
The Web application has a single user profile (Customer) with specific privileges. Customer is a person who owns a bank account. He is authorized to use the services provided by the bank through an ATM card and a PIN. For the sake of simplicity, the management of the information about the ATMs and the Customers' account are kept out of the case study. The business vocabulary (i.e., the general concepts) in our example is composed of: Customer, Bank Account, Transaction, Currency, and ATM; while the business rules to be implemented are the following: (a) a customer can activate N bank accounts; (b) an account is owned by 1 customer; (c) N transactions can be made on an account; (d) a transaction takes place at an ATM; (e) a transaction has 1 currency.
The UML modeling of the ATM Project has been carried out with StarUML (http://staruml.io/). Following the best practices of the Rational Unified Process, the modeling file is organized in four views ( Figure 12). The Use Case View is split in two packages: the Business Use-Case Model and the System Use-Case Model (Figure 12b). The Logical View is split in two packages: the Business Object Model and the Design Model (Figure 12b). The Component View and the Deployment View will not be used in the StarUML project file, because the code will be generated by xGenerator; the latter imports the XMI file from the UML model of the ATM Project.  Figure 13 shows the Withdraw Business UC Realization diagram. In it, Customer is a Business Object, but in the ATM subsystem it is also a Business Actor because it plays an active role. Therefore, Customer takes the stereotype «Business Worker».

PIM
The artefacts generated by xGenerator to map CIM to PIM are described below. They implement the Steps 1-5 of the PIM (Section 3.2). The Business Actors, Business Objects and the Business UC Realization of the CIM must be automated (Tag=True) (Step 1). Generation of the Domain classes from the Business Objects ( Figure 21) (Step 2). In each Domain class are present all the attributes of the corresponding Business Object besides the IDentifier field.  In accordance with what was said in Section 3, the System UC Realization maintain the same characteristics as the Business UC Realization: this ensures that the UC construct preserves its semantics in the transition from CIM to PIM.
Transformation of the business scenarios into the system scenarios for the Withdraw System UC Realization (Step 5) inside of the Use-Case Realizations package contained, in turn, in the Design Model package (Figure 23).  The name of each View class is a string composed as follows: UseCasePanel+SUCRName+BoundaryClassName; when BoundaryClassName is identical to SUCRName the repetition is omitted.

PSM
The following describes the artifacts generated by xGenerator to go from PIM to PSM (Section 3.2). Figure 28 shows the MVC layers of the source code to be generated.  The execution of Step 2 (Structural aspect) and Steps 2 and 3 (about the Graphical User Interface) generate the classes of the remaining architectural layers (Figure 30a,b).

The Code
xGenerator generates the code and the deployable unit (if required). Figure 32 shows the Web Graphical User Interface that corresponds to the Withdraw System UC Realization. Notice that, the structure of the Eclipse ATMProject ( Figure 33) is specular to that of the design layers ( Figure 28).    Table 1 shows the numbers about the ATMProject. The number of Nested Classes are not mentioned in Table 1. According to the generation gap pattern (Section 2), the code comprises 12 superclasses and 12 subclasses. The generated subclasses (namely: BankAccount, Transaction, Currancy and ATM) are empty, therefore they do not add methods, while they add 3 extra lines of code per class.

Related Work
This section starts with an overview about code generation in the MDE domain, then it turns to the code generation in the MDA domain, eventually it provides a closer look to a recently appeared paper that is very close to ours.

Code Generation within MDE
Model-driven development is an alternative to conventional software development. Automatic code generation from UML models is an active research area. Nowadays, there exist many software development tools able to generate code from a model. In 2019, Kahani, et al. [27] have identified 60 tools based on the used transformation approach. Of the identified 60 tools, 31 carry out a model-to-text (e.g., source code, documentation, or configuration files) transformation. Their study provides an up-to-date, in depth picture of the state-of-the art about tools and model transformation techniques. 100% source code generation is the ultimate aim of the MDE field. Unfortunately, the goal of replacing programming by modeling has not been achieved yet. So far there are many empirical studies showing that the adoption of the MDE brings to a partial code generation. Hereafter, we mention few of them.
Parada et al. [28] present an MDE approach to automate code generation that takes into account UML 2.x class and sequence diagrams for embedded systems. From each class of the Class diagram, a Java file is generated, describing its attributes, method signatures, and the constructor method with attributes initialization passed as parameter. The sequence of method invocations, including arguments and return, come from Sequence diagrams. Conditionals and loops are also captured from this diagram generating the corresponding switch/if-else and for/while Java statements. This approach generates (through a tool called GenCode whose input is a the XMI of the UML model) code up to the level of method invocations, while variable assignments or math operations cannot be generated. Reference [29] is another paper that aims at automatic code generation. The work proposes an MDE approach that adopts as starting point UML 2.x Sequence Diagrams of Use Cases. The XMI representation of the Sequence Diagram of a Use Case (exported from a UML modeling tool) is used to construct a graph model that captures information related to messages, control flow and method scope of interactions. These information are used to generate the code. The authors carried out an experiment: the development of a Restaurant Automation System. The experimental results are the following: 48% of the total number of lines of code of Controller classes were generated from Sequence Diagrams, while for Boundary classes and Entity classes, it was around 6 and 11%, respectively. The major limitations regarding code generation from Sequence Diagrams, as reported by Kundu et al., are the following. The generated code about class methods may not be complete, since all behavioral information necessary for complete code of class methods is not captured in an Sequence Diagram. The code is not generated for all class methods. The generated code is not executable as type information about variables are missing. The programmer needs to resolve several issues in the generated code (e.g., exception handling).

Code Generation within MDA
Object-oriented software includes class declarations, method definitions, and the statements that implement the control flow. Many contributions about code generation, starting from UML models, support automatic generation of class declarations [30][31][32], while less papers produce class declaration plus a portion of method definitions [33,34]. There are also proposals that implement class declarations, control flow and a portion of the method definition that, however, remains incomplete [29,35,36].
In Reference [25], Sunitha and Samuel push a bit further the process of automatic code generation. In fact, they claim to be able to generate the code about class declarations, method definitions and around the 80% of the control flow. Their method generates Java code starting from UML State machine, Activity diagrams and Sequence diagrams. They make reference to MDA, but only partially, in fact the behavioral modeling starts at the PIM level. During code generation, each Activity diagram is converted to a class while each node in the activity diagram gives rise to a function call in the main() of the class. The interface of methods inside a class comes from a message inside a specific Sequence diagram. The body of methods is filled out by taking into account the State machines, while their actual parameters come from OCL expressions (Object Constraint Language is an OMG standard [37]). The transformation rules for converting the XMI file to Java is written in XSLT.

Comparison with an MDA Approach for Web Application Development
Reference [18] reports on the state-of-the-art of code generation using MDA research in software engineering. The authors identified 50 primary studies out of 2.145 related MDA articles over the period 2008-2018. From this study comes out that the five main areas of interest are: "mobile application development, simulation and verification, security, Web engineering and GUI development". Our paper belongs to Web engineering. Moreover, the authors have reached 50 relevant publications using MDA arriving at the generation of code (executable or not) automatically. The survey reports that most studied approaches employ PIMs and PSMs only, avoiding the inclusion of CIMs in the model architecture. Our Software Development Process starts at the CIM layer.
In Reference [38], the authors apply MDA to develop MVC Web Applications. Their proposal combines UML class and sequence diagrams to constitute one source meta-model of the transformation language. They use ATL (Atlas Transformation Language) as transformation language. The proposed method ignores the CIM level. The method is applied to a case study concerning a PC online shopping. The authors claim that the generated code has reached about 85% of total code. In References [39,40], the authors present an MDA-based approach that allows the implementation of Graphical User Interface for Rich Internet Applications with JavaFX platform as a target, respecting the MVC pattern. The proposed method starts at the PIM level.
The research by Essebaa, Chantit and Ramdani [41] constitutes a very recent testimony of application of MDA to Web applications. Their work describes a tool (MoDAr-WA) aiming to automate transformations from CIM to code. Authors use QVT rules for transformations between models (CIM to PIM and PIM to PSM) and Acceleo for generating the code that respects the MVC architecture from PSM models. The authors compare their proposal with a large number of related works. The conclusion was that their solution is the unique one that besides covering CIM and PIM aspects, provide transformation rules between CIM and PIM, automate them and allow their traceability. Because of this claim, we conclude the section by comparing our work with that of Reference [41]. Figures 8 and 35 depict the differences between our and their approach, at the various levels of MDA. Below, we discuss the three relevant differences between the two approaches. In our approach, at CIM the analyst collects the system requirements (i.e., the structural and behavioral Business Rules) and expresses them in his own language; then he produces the diagrams about Business UC Realizations and Business Objects, and the sequence diagram of the business scenarios. In Reference [41], the analyst expresses the system requirements using the OMG standard Business Vocabulary and Business Rules (SBVR) [42]; then MoDAr-WA generates the UC diagram from SBVR. A SBVR model is composed of one or more business vocabularies and may contain sets of business rules, which are based on concepts defined in the aforesaid business vocabularies.
The idea to formalize the system requirements in terms of SBVR statements is great in principle, but at the time of writing it suffers several problems. We discuss them hereafter. First, "SBVR is a relatively complex and large standard with business vocabulary part alone containing over one hundred elements representing various aspects of business domain." [43] p. 114. Second, "without proper tooling, the development of such vocabularies from scratch will always require considerable amount of additional effort, which in some cases may be a decisive negative factor against such approach." [43] p. 112. To mitigate both the above issues, in 2018, Skersys, Danenas, and Butleris [43] suggested to approach the formalization of the business requirements by taking the other way around, that is, they suggested to draw first the business UC diagrams and then the (semi-)automatic extraction of the SBVR business vocabularies and business rules from those diagrams by applying a rule-based transformation algorithm.
The model transformations involved in the MDA process can be automated if they are bijective and modular, seamless. In the proposed approach (Section 3.2), the Business Object construct (the structural aspect of the system) and the UC construct (the behavioral aspect of the system) are present from CIM to Code. In this way, both requirements above are satisfied. Figure 35 shows that in the approach of Essebaa et al. [41] the Object construct is present both at the PIM level (inside the Detailed Class Diagram) and at the Code level, while the same cannot be said for the UC construct that is present at the CIM level but it is not explicitly traced in the subsequent levels. In fact, the UC-Java classes are missing in the code, that is why we are unable to say if and how the aforementioned two requirements are met. The presence of the UC construct at the Code level is fundamental since it allows to encapsulate in the classes of the generated Web application the UC behaviors and its paths (the scenarios) as formulated at CIM level (i.e., in the Business Modeling phase). This is the second difference between the two proposals.
xGenerator implements the generation gap pattern (Section 2) to separate the generated code from the non-generated code (if any), while MoDAr-WA does not. This is the last difference between us.

Conclusions and Future Work
The research presented in this paper is the result of a prolonged R&D initiative of the authors and the team of developers of xGenerator. The first steps of the research date back to 2008. The paper described an automatic process to develop enterprise Web applications from UML diagrams. The generated source code respects the MVC architecture. The frame of reference is MDA, while the pillars of the proposal are UCs, class and sequence diagrams.
For the Case Study, the code generation was total. With respect to the general case, the current version of xGenerator is not able to generate the control flow inside the body of the subclasses of Figure 2, because it is not possible to model it with sequence diagrams. The control flow inside those subclasses implements computational aspects and the Input/Output of database records. In our experience of several years of adopting the proposed approach and the companion xGenerator tool mostly for the development of business Web applications for banking, the code concerning the control flow of the subclasses of Figure 2 to be written by programmers never has exceeded the 20% of the total. This numerical finding is close to that reported in Reference [41], where Essebaa, Chantit and Ramdani compared the output of the MoDAr-WA plug-in against that returned by five tools (three based on academic approaches and two from the industry domain) for the same example. In fact, the authors reported that MoDAr-WA generated 86.56% of the source code from the system requirements. We are working on an extension of the xGenerator which introduces two important improvements to the current version. The first involves modeling the control flow by means of UML diagrams. The second improvement concerns the introduction of a set of UML domain stereotypes and constraints, to realize a lightweight extension to the UML using the profiling approach introduced by OMG [2]. UML is a general purpose modeling language. Stereotypes were introduced for customizing UML in order to be tailored to specific application domains. Therefore, stereotypes are a mechanism to convert UML into a domain specific modelling language. This approach is extensively adopted, for instance, in the security and privacy domains (e.g., References [44][45][46]). We are confident that by stereotyping the Business UCs will improve the enterprise software development process toward full code generation.
Our experience of several years of adopting the proposed approach and the companion xGenerator tool goes in countertrend if compared with the findings of many scholars which have reported that the adoption in industry of the MDE approach is far from successful (Section 1). We can assert that moving from the standard Object-Oriented programming paradigm to the model-based paradigm made Software Industriale (an Italian small software company, structured as a network of four branches located in different regions of the Country-https://www.softwareindustriale.it/) more competitive. Model Driven Engineering (MDE) has emerged as a new software engineering discipline which emphasizes both software productivity and software quality, besides a easier communication with our clients carried out at the business modeling level. When new developers are hired for a project, before they are aggregated to the core development team, they receive an internal training about MDE, MDA and the xGenerator tool for one working week. The research team of Software Industriale is in charge of the training. This action implements one of the three best practices suggested in Reference [12], for MDE to be successful.
Future research and development directions will be aimed at extending the proposed Software Development Process to domains different from enterprise Web applications. The first domain of our interest concerns the Mechatronics. The development of mechatronic systems involves the use of disciplines from mechanical engineering, electronics engineering and computer science. Traditionally, every discipline was developed independently and then integrated to generate the final system. This approach is criticized as inappropriate for the complexity and the dynamics of today's systems (see, for instance, Reference [47]). High-quality designs cannot be achieved without simultaneously considering all the engineering disciplines. The complexity of the automation of the software embedded into mechatronic systems is rising since the proportion of system functionality that is realized by software is increasing, too. Therefore, the modeling approach seems to be particularly suitable for handling the software complexity. At present, we are investigating the formalization of a minimal set of ad-hoc UML profiles to deal with the complexities of the mechatronics domain. The survey by Wortmann et al. [48] is an up-to-date source about the role of UML in the Industry 4.0.
With the diffusion of smartphones equipped with GPS, WiFi and various sensors, monitoring the position of people and relevant goods is technically possible today (e.g., References [49,50]). The difficult task is the development of the source code of Web applications accessing such big data. We plan to extend our approach and, hence, the xGenerator to this domain.

Conflicts of Interest:
The authors declare no conflict of interest. Figure A1 shows the UML Component diagram of xGenerator. It is composed of xFramework (a tool that provides components and elements to speed up the creation of Web GUI and takes care of the management of the persistence) and additional components (the latter implement common use cases about, for instance: the Basic Registry, the Login, and the Web Services). xFramework embeds and wraps two important open source frameworks: Hibernate and Vaadin. It was implemented many years ago. Reference [51] describes this component of xGenerator.  Table A1 shows the numbers about the classes, methods and lines of code of xGenerator, grouped by components, that is, the xFramework, the Additional components (BasicRegistry, Login, and WebService) and xGenerator (Tools, Core, Editor, Engine, Validation, XMI_to_Parser). The development of xGenerator took about 2500 man/days; the people involved in the development were: UML Analysts with expertise in modeling of complex systems; Java software Architects; Software designers; and Java programmers. The development language used was Java, while the tools used were:  Figure A2 shows the architecture of the Web applications that can be developed with xGenerator. This architecture extends the basic MVC pattern (Section 2). Model is composed of Bean and QueryContainer class sub-layers. The Bean classes are mapped to database's tables through the Resource component that wraps Hibernate, [52]. The QueryContainer classes define the filter criteria for the execution of queries against the database. View is composed of three class sub-layers: the ViewBeanInfo layer displays (in a panel) the information of a Bean, the ViewQueryInfo layer dispalys (in a panel) the query criteria, and the UseCasePanel sends the information to the browser. Controller is composed of the layer of the UseCases classes; the latter implement the standard behavior of UCs and the navigation of the panels they are composed of.