Getting Model of MVVM Pattern from UML Profile

— The rejuvenation of applications to harmonize with technological watch is the major challenge for all computer boxes, frameworks and languages are constantly proliferating by offering a range of improvements in terms of security and performance, which pushes all applications to invest in order to align oneself, to orient oneself towards another perspective of application implementation has become a primacy. MVW is considered the new concept of application models where the developer can choose according to his needs, which component, for example, it can be a controller, a directive or a unit test for applications where we use the AngularJS framework, modeling an application is one of the basic steps to reach it , the emergence of new patterns press IT companies to think to renew their application architecture for more security and performance, moving from an old to a new model meets this need. AngularJS is one of the widely used frameworks for modern single-page web application development which is designed to support dynamic views in the applications. We propose an UML profile for AngularJS for building a model of an Angu-larJS web application, and a set of transformations that transform the model into a code template.


Introduction
We can say that in the IT field, the relevance of the information provided and its adaptation to user's preferences are key factors for the success or rejection of test platforms. Therefore, the solution is to conquer users by providing them with personalized platforms adapted to their needs. A, we are looking in this. We opt for an MDA type approach, allowing semi-automatic generation of the platform. This approach respects the architecture of MDA as it has been proposed by OMG [1].
Our vision to achieve this work is to apply the principles of MDA and use the UML profile for AngularJS for this article and that will be extended to other JS libraries, we will use the XML generated to have full AngularJS application by defining transformation rules.
The paper is organized as follow: Section 2 is dedicated to related work. In section 3 we present the MDA principles. Section 4 defines the MVVM pattern. Sections 5 includes the approach and presents the running example. Finally, section 6 concludes the work and offers some perspectives.

Related Work
Many researches on MDA and generation of code have been conducted in recent years.
The authors of the work [2] show how to generate JSPs and JavaBeans using the UWE [3].
The authors of the work [4] generate the MVW application by using activity diagram which will be transformed to class diagram.
The authors of work [5] generate MVC application by using Business Process Model and Notation.
Based on the same concept [6] apply MDA approach for generating PSM from UML design to MVC 2 Web implementation. That is why they have developed two meta-models handling UML class diagrams and MVC 2 Web applications, then they have to set up transformation rules. These last are expressed in ATL language. To specify the transformation rules (especially CRUD methods) we used a UML profiles. To clearly illustrate the result generated by this transformation. Unfortunately, current model transformation languages do not cover all these features, and thus, the study of languages covering all of them should be object of study, this paper aims to redirect researchers to an important and actual topic which will allow to get MVVM pattern by applying the standard MOF 2.0 QVT to develop the transformation rules with an input model based on UML.

The OMG approach
In November 2000, the OMG (The Object Management Group), a consortium of over 1,000 companies, initiated the MDE (Model Driven Engineering) approach [7] Models depend on metamodels; MDE operations depend on metamodels. Managing evolution for models requires managing the evolution of metamodels. Most solutions to model evolution and co-evolution have focused on metamodels. A different approach would be to discard metamodels entirely -take the view that they get in the way of efficiently supporting evolutionary processes. To what extent can we support MDE without metamodels [8].
MDA is a system design and development methodology intended to facilitate development in a technology-independent approach. MDA was first described by OMG in 2001 [9]. One of the main objectives of the OMG is to establish an open interface, independent of software platforms, and therefore interoperable. In this sense, MDA embodies the vision presenting a global framework to support interoperability with specifications throughout a complete system life cycle. MDA's design philosophy must include a description of business logic, modularization, construction and systems' integration, as well as deployment, management and evolution [9]. A key concept of MDA is the separation of the functionality specification from the implementation, integration and deployment specification [9]. This is accomplished by applying an abstraction to the design process. Abstraction is understood as the removal of irrelevant details, as motivated by the reference model for open distributed systems processing. In the field of MDA, meta-modeling plays a very important role considered to be a common technique to become the abstract syntax of Models and interrelationships between elements of the model. If the model is an abstraction of elements from the real world, the meta-model represents yet another abstraction, denying the properties of the model itself. A model is said to conform to its metamodel [10].
The modeling languages that are used are designed so as to be supported by tools that software engineers are familiar with and expect to be able to use -e.g., editors, syntax highlighters, debuggers, etc. Standard frameworks, such as EMF [11], exist to help define modeling languages in such a way so as to support this. In contrast, formal specification languages are designed to support mathematical reasoning, and as such the priority is to have a sound and complete mathematical semantics, which thereafter be supported by tools.
The key principle of MDE is automating repetitive and error prone tasks. The decisions that we make, with respect to use of particular technologies and theories, the implementation of particular tasks, and the deployment of workbenches to users, should always aim to support that principle.
The transition from one level to another is provided by transformations; that can be defined as the operation of taking elements of one or more models (source) and to match them with other elements of the model (target). There are two types: Model to Model (M2M) and Model to Text transformation (M2T). The first lets us go from CIM to PIM and PIM to PSM. As for the second, it allows the generation of platformspecific code chosen. Fig. bellow shows how the transformations are done. So we can say that this relationship, introduced in [12] and [13] connects two models and is the first step to automation and code generating [14]. CIM: These models describe the system to be designed from an IT-independent perspective. The CIM allows a vision of the system and its environment, while hiding the details of structure and implementation. CIM-level Models reduce the gap between experts in the field and between designers. Therefore, a CIM model is sometimes called a domain model. The technical independence of this model allows it to keep its full interest over time and it is modified only if knowledge or business needs change. The know-how is refocused on the CIM specification instead of the implementation technology.
PIM: It is independent of any technical platform (JEE, EJB, CORBA, .NET ,...) and does not contain information on the technologies that will be used to deploy the application. It is a computer model that represents a partial view of a CIM. The PIM represents the business logic specific to the system or the design model. It represents the functioning of entities and services. It must be lasting and last over time. It describes the system, but does not show the details of its use on the platform. At this level, the formalism used to express a PIM is a class diagram in UML which can be coupled with a constraint language like OCL * (Object Constraint Language). There are several levels of PIM. The PIM may contain information on persistence, transactions, security. These concepts allow the PIM model to be transformed more precisely into the PSM model.
PSM: It is dependent on the technical platform specified by the architect. PSM is essentially used as a basis for the generation of executable code towards the technical platform. PSM describes how the system will use this platform. There are several levels of PSM. The first, resulting from the transformation of a PIM, is represented by a UML scheme specific to a platform. The other PSMs are obtained by successive transformations until the code is obtained in a specific language (Java, C ++, C, etc.). An implementation PSM will contain, for example, information such as program code, types for, related programs, deployment descriptors.
The MDA approach seems very attractive at first. However, do not be mistaken, if it has its fervent followers, it also has its detractors whom advance cautiously in his direction. We will first see the advantages of this approach, then the drawbacks that may result, to finally highlight some feedback on experience.

Transformation of MDA models
A transformation is an automatic generation of one or more target models from one or more source models, respecting a definition of transformation. A transformation's definition is a set of transformation rules that describe how a model in the source language can be transformed into a model in the target language. A transformation's rule is a description of how one or more constructions in the source language can be transformed into one or more constructions in the target language.
To implement this transformation's process, a transformation engine takes as input one or more model (s) conforming to one (s) metamodel (s) source (s) and produces one or more other output (s) model (s) conforming to a target metamodel (s). The transformation engine, composed of a set of rules, must itself be considered as being a model. Consequently, it is based on a corresponding metamodel, which is an abstract definition of the transformation language used. [15] Propose a taxonomy of model transformations where they define two orthogonal dimensions: a horizontal transformation versus a vertical transformation and an endogenous transformation over an exogenous transformation.
• Vertical transformations of the models are used to refine or abstract a model and, in this case, the models are located in different levels of abstraction. The horizontal transformations do not affect the abstraction of the models and they mainly serve to restructure them given that these models belong to the same level of abstraction.

MVVM Design Pattern
The Model-View-View Model (abbreviated MVVM, from the English Model View ViewModel) is an architecture and a design method used in software engineering. MVVM is from Microsoft and suitable for the development of applications based on Windows Presentation Foundation and Silverlight technologies via the MVVM Light tool for example. This method allows, like the MVC model (Model-View-Controller), to separate the view from the logic and from the data access by emphasizing the principles of binding and event. MVVM provides powerful bidirectional data binding between model and view. This eliminates the need for wrappers, getters/setters or class declarations.
It conserves the concept of data applications which are separated into multiple tiers.
The Model defines the data structure and communicates with the server. The View displays Model information and receives user actions. The Controller manages the events and the update of the View and the Model.
We have a first breakdown of the application which already allows us to answer some of our problems. By clearly identifying the logical parts, we can more easily maintain and test our application.
The View therefore has no connection with the Model. Thus the ViewModel takes care entirely of the modification cycle of the latter. It both receives and sends data to the View. We then speak of "data binding". The information displayed is linked between two entities and updated in real time.
This latter mechanism is the key to the MVVM pattern. It allows us to decouple the different parts of our application by being able to develop it in a modular way.

AngularJS as Study Case
AngularJS enables the creation of a single page applications and allows some of the logic (such as validation) to be included on the client side [16]. A module can be considered as a container of different parts of the application like controllers, directives , services.
AngularJS applications must be developed as a hierarchy of Components. Each Component is an isolated part of the application for maintenance reasons.
Initially, AngularJS is a framework for developing One-Page applications. And therefore by definition, there is no need to change pages (since there is only one) and the routing is not useful. However, as the growing framework and its uses became more diverse, it soon became possible to integrate a routing system. In versions prior to 1.2, which were beta versions, developers natively integrated this routing system to the framework for the sake of simplicity (they had many other priorities). However, as of version 1.2 which is stable and which made the renown of AngularJS, it was necessary to refocus it on these primary objectives: these famous applications One-Page. As the project progressed, many functionalities were born and the team decided to separate those that were not essential, a certain page load in AJAX and the result will be added in a portion of the DOM.
Each view works pairwise with a controller. The view consumes data in databinding and calls the controller's methods. It can also include directives and use filters that are declared in the application.
The logic of the views is organized in the controller, so the code in the controller must be simple, that is to say, the controller couldn't interact with the DOM and manipulate data. The role of the controller is to define variables, so called, $scope variables, and to encapsulate views related to logic. When executing AngularJS, the latter will create the different working contexts called scopes. They are organized as a tree of objects, with everything at the top of $rootScope. The Scope allows the join between the Controller and the View by allowing the binding of the variables in both directions. To ensure code capitalization, components that manipulate the DOM can be created as a directive. The directives are the modules used to manipulate DOM, to bind events and define their actions. They translate into HTML components. The business part of code must be in services, they are singletons, that is, single instances of objects. The role of a service is to provide a set of tasks necessary for the operation of the application.

UML profile
A UML profile allows you to adapt the UML language to a domain that it could not properly cover. Profiles are not only used to generate PIM or PSM but also to switch from PIM to PSM. The specificities of each platform can be modeled using UML extension mechanisms defined by UML profiles. For example, stereotypes allow the addition of new elements to the meta-model, tagged values allow the addition of properties to a meta-class and constraints allow the addition or modification of rules. It is possible to associate stereotypes, marked values and constraints with any UML concept (class, attribute, association, use case). These elements make it possible to establish a correspondence between UML concepts and domain concepts.
The OMG has defined several profiles, each of which has a specific role in the transformations. For example: • The EDOC profile (Enterprise Distributed Object Computing, version 1) aims to facilitate the development of business models, systems or organizations. • The EAI (Enterprise Application Integration, version 1) profile simplifies the integration of applications by standardizing the exchanges and translation of metadata. • The SPEM profile (Software Process Engineering Metamodel, version 1) is defined both as a UML profile and as a MOF meta-model. SPEM defines the ways to use UML in software projects and allows the creation of process models (for PIM only). • The Test profile (version 1 adopted) allows the specification of tests for the structural (static) aspects as well as for the behavioral (dynamic) aspects of UML models. • The real-time modeling profile (Schedulability Performance and Time, version 1) for modeling real-time applications.

UML profile for AngularJs
As mentioned in the introduction, MDA has made it possible to reduce the duration of development of computer applications by ensuring a perennial know-how using models.
In the same way, we will use UML profiles for AngularJS and which will be executed by a tool like magic draw, output will be an application of AngularJS.
The elements of Figure. 4 present the cornerstone of our MDA profile.
A stereotype is a model element that defines additional values [17]. In the diagram above, we put under the lightning different parts of our AngularJS profile: This UML profile divides the different parts that an AngularJs application needs to have, the module as a container encompasses all, the routing system via predefined angular services, $ route is the central service of the ngroute module, $ routeProvider Initializes the routing, pointing to the controller and template associated with this route.
The template is loaded by overloading the scope by actions described in the controller, the scope inherits the rootscope, and Each AngularJS application has exactly one root scope, but may have any number of child scopes [18].
The controller can use the service methods, where processing is to be done and calls to other APIs, 5 types of services are present and each has its own interest, but the most used is the factory, one Service returns a promised in AngularJS.

Code generation
The tool will generate an xml that will be retrieved and parsed by a JAVA API and make transformations on this file in order to generate an application.
I will give a study case of an application where well will get AngularJS application, stereotype in this case will be replaced by AngularJS , because this profile can be extended to other js libraries like React or VueJS. The diagram above illustrates an example on which we will apply our UML profile, to display a title and a label containing the name, all configuration files such as bower and the JSON package of nodeJS and the management of tasks by gulp will be generated with JSON files already defined.
While the various other parts will be configurable by the user who will add them either as src for dependencies, inputs, labels and buttons for templates, injections, methods and scope value for the controller, Methods with add, delete, updatefollowed by the property to modify, will be generated for controller and services.

Conclusion
In this paper , UML profile concepts have been taken as the basis on which we can ensure the generation of an application, the use of an UML profile was the way in which we finally proceeded to generate our application, such a Methodology will ensure a gain on the time and durability side.
As a perspective, it is intended to extend to other functionalities by ensuring another user interface for the user to facilitate the description of the skeleton and adding the service layer interacting with the WS REST.
This UML profile can be spread out to generate other applications based on other JS libraries and this will guarantee a closer coverage of the Front Party code generation.