UML has become a language that allows modeling the components of a process for building software that provides a modeling language, the success of UML is its use in successful projects and the increase in the need for support tools and documentation for software. However, in spite of being a fundamental part, of the generation of the documentation of the code and components involved in the construction of software, the importance of documentation in a project is not given enough value. This paper proposes the theoretical bases that allow the generation of rules for the generation of a domain metamodel of UML diagrams. The rules are defined allowing a specification where ambiguities and the need to learn a specific programming language are avoided thanks to the use of a modeling framework. This is where model transformation chains are an alternative to propose a pattern that identifies an input model (domain-specific metamodel that are the diagrams that make up the UML documentation) and convert it into an expected output model that generates value to the documentation in a software project. For the development of the proposed metamodel, the stages of research and review of documentation of the EMF tool, analysis, and implementation of the general components and construction of the project were carried out.
The software life cycle includes a series of phases, called: definition, analysis, design,
implementation, deployment, testing, and maintenance [
UML has been widely used to model information systems and in recent years it is regaining
prominence thanks to Model Driven Engineering since it is the preferred language for the most
popular approaches in this topic [
Eclipse is one of the best open-source development platforms and it is highly extensible
through plugins, there are many projects around a large community of users and developers
[
For the generation of the specific domain metamodel of our case study, functionalities and EMF projects must be established, to then build the Ecore metamodel corresponding to the context that surrounds UML.
In the context of software construction, the documentation of projects has become very important, so much so that it is currently considered part of the applications. The generation of the documentation saves several features, from the methodology used for its implementation to the syntax, notation, and visualization with which it is represented. The importance of documentation lies especially in the fact that what is expressed with the diagrams and mechanisms used must be totally consistent with the totality of the project it represents, referring to any aspect involved in its development. This will involve the entire context of infrastructure, technology, methodology, framework, and architecture related to the represented system.
The purpose of Model Driven Engineering (MDE) is to allow the representation of reality
through models [
Bézivin [
One important diference between the old modeling practices and modern MDE is that the new vision is not to use models only as simple documentation but as formal input/output for computer-based tools implementing precise operations. As a consequence model-engineering frameworks have progressively evolved towards solid proposals like the MDA defined by the OMG. We may clearly see the three levels of principles (general MDE principles as described in this paper), of standards (e.g. the OMG/MDA set of standards), and of tools (like the EMF, Eclipse Modeling Framework, or the Visual Studio Team system).
Progressively we come to understand much better the possibilities and limits of this new
way of considering information systems. The notion of a metamodel is strongly related to the
notion of ontology. A metamodel is a formal specification of abstraction, usually consensual and
normative. From a given system we can extract a particular model with the help of a specific
metamodel. A metamodel acts as a precisely defined filter expressed in a given formalism [
Ludewig [
Diagrammatic representation allows the reuse of potential applications as part of a larger system. For example, if the construction of user authentication and registration system is required, the schematization of this requirement will be equally valid for a banking system, a health care system, or an academic system.
Florez [
The model transformation chains are the result that was decided to obtain as a metamodel from a series of transformations, which, being sequential and using the output of the previous transformation as input (under the action of transformation models derived from a transformation metamodel), which will allow obtaining a final element that in the case raised is a UML documentation model.
The use of MDE and specifically model transformation chains difers from reverse engineering. Reverse engineering, also known as return engineering, works backward, part of the final result, divides the product, and performs analysis and measurements to recover the original design information. In the approach of this project with MDE, the start is made from zero and forward, for the generation of UML documentation as a starting point and design of the construction of a product.
Figure 1 is the simplest representation of a model transformation chain, where: • MM: Metamodel • m: Model • MMt: Metamodel transformation • mt: Model transformation
In the field of software construction, the documentation of projects has become very important, so much so that it is currently considered part of the applications. The generation of the documentation houses several features, from the methodology used for its implementation to the syntax, notation, and visualization with which it is represented.
The importance of documentation lies especially in the fact that what is expressed with the diagrams and mechanisms used must be totally consistent with the totality of the project it represents, referring to any aspect involved in its development. This will involve the entire context of infrastructure, technology, methodology, framework, and architecture related to the represented system.
Additionally, the representation by means of diagrams allows the reuse of potential applications as part of a larger system. For example, if the construction of user authentication and registration system is required, the schematization of this requirement will be equally valid for a banking system, a health care system, or an academic system.
UML has become a standard language that allows modeling all the components of the software
construction process. UML does not intend to establish a standard development model, what it
really intends is to provide only a modeling language. In UML, the development processes are
structured according to the diferent work domains [
The unified modeling language allows showing systems at all levels of abstraction, so that users, leaders, and programmers understand all the features of the application. The models allow to establish better communication with the user for several reasons: • They show the client an approximation of what the final product will be. • They provide a first approximation to the problem that allows visualizing how the result will look.
• Show systems at all levels of abstraction.
More and more users use UML for its semantic similarities with other methods (Booch, OMT, OOSE, etc); however, the success of UML is its use in successful projects and the increased need for support tools. and documentation for software.
Although the UML provides a concrete language, it is not the limit to future modeling enhancements. Diferent techniques have emerged that have gained importance such as cloud development technologies, architecture-based engineering, and Model Driven Engineering; however, other techniques in the future are expected to impact new versions of the UML. Currently, the UML is potentially the basis for many tools, among which we have tools for visual modeling, tools for simulation, and tools for running development environments. UML and its close relationship with object-oriented programming allow the establishment of diferent methodologies for software development according to new technologies. Currently, there is talk of component-based development and research into its implementation, as a complement to current programming paradigms. If the use of components tends to increase, it would not imply that these techniques can totally replace the current and already established ones.
A model is a conceptual structure of all the topics related to a specific problem. [
The domain model is created to represent the vocabulary and key concepts of the problem domain. It also identifies the relationships between all entities within the scope of the problem domain, and commonly identifies their attributes. Finally, it provides a structural view of the domain that can be complemented by other dynamic viewpoints.
In UML the static structure of the objects in a system is presented in Figure 2, where the base structure of the domain model for the UML context is illustrated.
A metamodel contains the analysis, construction, and development of applicable and useful schemes, rules, constraints, models, and theories for the modeling of predefined classes of problems. It is a global representation that defines how all models are represented. Basically, it marks a syntax about how the elements of the domain and their relationships should be defined in the representation levels of lower abstraction. The metamodels contain the concrete specification of an application domain that follows the syntactic restrictions (an example would be E/R diagrams).
The graphic representation of the domain model for the specific domain worked on in the current project is presented in Figure 3 representing the general components required for the generation of the domain metamodel worked on for the generation of UML documentation using transformation chains.
The purpose of Model Driven Engineering (MDE) is to allow the representation of reality through models, which facilitates the implementation of information systems. However, as already mentioned, despite being a fundamental part, the generation of the documentation of the code and components involved in its construction is not given importance, that is where the model transformation chains are an alternative to take. control, due to the possibility they ofer to propose a pattern that identifies an input model and converts it into an expected output model. So, it is possible to obtain diferent solutions not only for an application but also the representation of the whole system, which in our case are UML diagrams.
Using the Model Driven Engineering alternative and through sequential transformations, it is possible to represent diferent problems raised and abstracted from reality. We can obtain a final product through a model transformation chain to represent the problems mentioned, which are basically the diagrams that make up the UML documentation.
The generated representation is the basis for the construction of systems that will solve the problem initially established and modeled, regardless of the technology being worked on, regardless of whether it is defined and established or whether it is a new and experimental one.
The mechanism that we decided to implement to carry out a series of sequential transformations is the model transformation chains, using as input, the output of a previous transformation (by means of transformation models derived from a transformation metamodel), which will allow obtaining a final element that in the case raised in this project is a UML documentation model, as presented in Figure 4. The most important thing is that the result is an exact and understandable representation both for the user who requests the requirement and for the user developer engineer who performs software coding with the solution to the requirement.
Figure 4 is the representation with a conceptual map of the software development cycle, where diferent factors intervene during each of the stages. In this conceptual map, each of the elements that can intervene is reflected at a general level, emphasis is placed on the highlighted part in red, they are the components related to the execution of the project for the generation of UML documentation through transformation chains. of models.
For the continuation of the project Generation of UML documentation through model transformation chains, the use of EMF for the construction of the domain metamodel is proposed. EMF (Eclipse Modeling Framework)2 is a modeling framework with easy code generation for building tools and other applications based on a structured data model. From a specification of the model described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of classes that allow command-based viewing and editing of the model, and a basic editor. Models can be specified using Java Annotation, XML documents, or modeling tools such as Rational Rose.
Generation of UML documentation through model transformation chains to be imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications.
The Eclipse Modeling Framework, better known as EMF, is the framework provided by Eclipse
for the creation of models and metamodels that facilities for automatic code generation and for
the construction of model-based tools [
EMF allows automatically generating Java classes that implement elements of our models, as well as adapter classes that allow modelers to view and edit a model.
The main functionalities of EMF are: • Design Ecore metamodels, with two types of editors: – Editor based on a tree-like structure – Visual editor, like a UML class diagram • Build model editors based on a tree-like structure, EMF allows generating Java classes that support the metamodel and classes for testing with JUnit.
persistence of models through XMI serialization and in addition to an API for reflection of objects. • EMF.Edit is a framework that allows generating Java classes to edit an EMF model and consists of: – Classes that support editing properties, content providers (content and label provider), and editing Property Sheets (property sheets). – A command framework for building an EMF model that includes undo and redo operations. • EMF.Codegen is a tool that allows the generation of a complete editor from an Ecore metamodel.
• EPackage: component that allows organizing classes and data types. • EClass: concepts in the metamodel • EReference: association among concepts • EAttribute: concept properties • EDataType: type of an attribute
Ecore components have the relationships, attributes, and operations presented in Figure 5, which is a diagram created with EcoreTools, which is part of the Eclipse modeling package. Represents Ecore components, references, and attributes.
The image may be complex at first glance; however, it contains detailed and important information. With this diagram, it is possible to obtain and understand the operation of all the components of Ecore only by performing the interpretation of this diagram.
The implementation of the metamodel in EMF with Ecore allows having the starting point of the general objective of the project, which is the realization of a model transformation chain to obtain UML diagrams of an application.
The construction of the metamodel is done in the Eclipse Modeling Tool development IDE. In the tool palette, we add to the diagram the classes required for the object domain model of this project, documentation with UML.
The Ecore file allows you to define the elements detailed below and is presented in Figure 6: • EClass: Element(Object Name), Entity, Actor, Type, Relation • EReference: Reference • EAttribute: Name and description. • EDataType: Figure Enumeration
UML has become a standard language that allows modeling all the components of the software construction process. UML does not intend to establish a standard development model, what it really intends is to provide only a modeling language. In UML, development processes are structured according to diferent work domains. The unified modeling language allows systems to be displayed at all levels of abstraction, so that users, leaders, and developers understand all the features of the application.
Using the Model Driven Engineering alternative and through sequential transformations, it will be possible to represent diferent problems raised and abstracted from reality.
The generated result, which is basically the diagrams that make up the UML documentation, would be important because it is an exact and understandable representation both for the user who requests the requirement and for the developer who codified the solution to the problem. The level of detail used in the UML diagrams facilitates the construction of the domain model and, consequently, the transformations required for the result of the project in progress.
Likewise, it is important to highlight that much of the semantic information required for the generation of UML diagrams rests on the structure defined in the domain metamodel and the generation templates, so it can be concluded that the platform is not only made up of its model but also by the templates that are specific to each technology.
Modeling the domain metamodel separately uproots elements of the logical and physical views of the specific modeling tool, as the design patterns are generalizable and completely independent of application modeling. Therefore, the same logical view can be used for diferent application models, or reciprocally, diferent logical architectures can be used for the same application model, which translates into saving eforts when modeling with EMF.
The implementation of the metamodel in EMF with Ecore allows having the starting point of the general objective of the project, which is the realization of a model transformation chain to obtain UML diagrams of an application. EMF ofers a variety of elements that are suficient to build the core of the context, establishing rules through relationships and attributes. This practical advance will allow following with the investigation to continue with the elaboration of the transformations that are required to fulfill the goal of the final work.
The generation of UML documentation using MDE and applying model transformation chains allows us to have the first input as a starting point in the construction of an application. Additionally, it will work in parallel in the development stage to provide the diagrams that define the correct coding flow of the software required. However, there is the possibility of taking advantage of the power of MDE to implement a project that allows generating the code from the construction of models and metamodels from which a partial generation of source code can be obtained.