The software industry nowadays is dealing with some problems like the fulfillment of quality attributes such as Portability, Interoperability, Maintenance, and Documentation. That is why the Object Management Group (OMG) proposed in 2000 the Model Driven Architecture (MDA) as an Interoperability specification. Thus, the purpose of this paper is to show the creation of a complete Model Transformation Chain that will refine a domain model to native code for the Android platform that will manage peripherals in mobile devices.
According to Bezivin [
Model-Driven Engineering (MDE) emphasizes and strives for abstract representations of the knowledge and activities governing a specific application domain, as opposed to focusing solely on computing concepts like algorithms.
The primary objective of this project is to introduce a novel approach to developing mobile applications by applying MDE concepts. This approach ofers several advantages compared to traditional application development methods. It emphasizes the integration of expert domain knowledge throughout the entire software construction process.
Within the realm of MDE, there exists a vast terminology, various concepts, and numerous
areas of study. This project specifically concentrates on one of these areas of study: the Model
Transformation Chain. This choice is made because it efectively illustrates the unifying principle
that "everything is a model" [
Conventional software development typically employs models like the Unified Modeling
Language (UML) solely during the analysis and design phases. The responsibility for
implementation then falls on the source code, creating a disconnect between these two aspects.
While a well-defined software architecture during the design phase may seem like an organized
approach, real-world scenarios often introduce challenges [
This process introduces a conceptual separation between execution platforms and programming languages, shifting the focus from the modeling phase. Consequently, new roles emerge, such as "modelers" and "metamodelers," responsible for creating models and metamodels using a modeling language.
This paper demonstrates the outcomes of a research endeavor that integrates prior findings as
discussed in [
The paper is structured as follows. Section 2 describes the concepts of Model Driven Engineering. Section 3 presents the general overview of the Model Transformation Chain. Section 4 presents the description of the domain metamodel. Section 5 presents the description of the architecture metamodel. Section 6 illustrates the transformations between each of the stages presented in the Model Transformation Chain. Section 7 presents the future work and finally, section 8 concludes the paper.
This section introduces fundamental concepts relevant to the current research.
According to [
MOF provides an open framework to deal with models, this defines the levels used by MDA and
it is the meta-meta model accepted by the MDA architecture. Also, define the interexchange
of models using XML Metadata Interchange (XMI) [
OCL allows us to create restrictions in the model definitions and also is used by Atlas Transformation Language (ATL) to define the rules to transform the models.
Since the core of this project is the model transformation, it was made a revision of ATL which
is a language that permits to create the transformation rules with OCL, this rule indicates to the
ATL virtual machine how to modify the properties of the input model in order to create the
output model conforms to the target metamodel [
EMF, proposed by the Eclipse community, utilizes Ecore as its metamodel, aligning with EMOF.
This choice also enables support for XMI for model serialization/deserialization, fostering
interoperability with other software modeling tools [
Model transformations assume a significant role within the Model-Driven Engineering (MDE)
methodology. Crafting definitions for model transformations is anticipated to evolve into
a routine endeavor in model-driven software development [
The potential exists to string together multiple transformations in order to traverse diverse model facets within the same system under examination. For instance, the final transformation (which entails a model-to-text conversion producing the source code application) generates code that more efectively embodies the nuances of the studied domain. Consequently, generating code grounded in a domain model becomes achievable.
To be able to make a model transformation, it is necessary that the two metamodels conform to the same metameta model. In the present work that is accomplished given that the two metamodels conform to Ecore, which conforms to EMOF, which, in turn, conforms to MOF.
As articulated in [
Two transformations were established among three distinct models (the generated source
code is also considered a model) [
Subsequently, we will introduce the various components comprising this sequence of transformations.
Following the same nomenclature of other model languages accepted by the OMG, this proposal
of DSL was called as "Mobile Peripheral Model Language" from here only MPML. The initial
rendition of the domain metamodel was introduced in [
Regarding the peripherals: this is the higher level of abstraction of the metamodel. It represents every input sensor or output element to be modeled in the device. This element inherits all the other peripherals.
Starting with the input sensors (MPMLInputComponent), according to the website of Android developers https://developer.android.com/guide/topics/sensors/sensors_overview.html there exists the next classification of sensors • Motion sensors: These sensors measure acceleration forces and rotational forces along three axes. This category includes accelerometers, gravity sensors, gyroscopes, and rotational vector sensors. • Environmental sensors: These sensors measure various environmental parameters, such as ambient air temperature and pressure, illumination, and humidity. This category includes barometers, photometers, and thermometers. • Position sensors: These sensors measure the physical position of a device. This category includes orientation sensors and magnetometers.
Complementing the sensor elements, there were defined the next abstract elements: • MPMLOutputComponent: Here are included some elements of the mobile phones that are going to be used only with the purpose of giving an output to the user, this includes the vibrator. • DataStorage (previously InputOutputElement): In order to add more scope to the modeling language, providing it with elements that model interaction with the data, which has the ability to manipulate data in an external or internal mechanism in the device. In this category there was added two concrete elements: – NFCWriter: There was included the interaction to write plain/text information to other devices or in MIFARE NFC Tags. – RealTimeDatabase: For the data storage, the idea is that the user can model the CRUD (Create, Read, Update, and Delete) operations. In order to avoid depending on the implementation of the server logic, choose Firestore Real-Time Database. The components were selected as a result of the ease of storing information without having to create a Schema a priori.
One of the major diferences between the version of MPML presented in [
The basic illustration of the flow elements is presented in the flow chart depicted in Figure 1.
It is crucial to emphasize that these dynamic elements were encapsulated within a static model in the EMF domain, as demonstrated in Figure 2. Within this context, the following elements are discernible: • Start: From the Data Flow perspective, this is the first access point where all the peripherals are chained in order to send/receive models and deal with the data transformations over them. • Connector: Abstract definition of the connection between the diferent Components.
There are 2 types of concrete connectors: – FlowConnector: It connects one InputComponent to an OutputComponent. – DataConnector: It connects the InputComponents and OutputComponents to a DataStorage. The connection from the former is called dataStore and the connection from the last one is called dataSource.
Also, a Transformator has a recursive reference to itself in order to allow to chain several transformations over the same Entity. • App: This element defines the app name and namespace. Additionally, it connects to the Start element in order to define all the dataFlow for the dynamic perspective of the model. From the static perspective of the model, it contains the next collections of elements: – components: 0 to many MPMLComponent elements. – connectors: 0 to many Connector elements. – connectors: 0 to many DataStorage elements.
– start: only one Start access point.
The purpose of the architecture metamodel is to encompass all the app-generated architectural
concepts. Clean Architecture was selected due to its optimal compatibility with the pluggable
attributes of the peripherals, elaborated further in [
This architecture was introduced by Robert C. Martin in [
The hierarchy of peripherals changes in order to accomplish the requirements extracted from the Android platform.
Regarding the peripherals, the element at the top of the hierarchy is the Peripheral abstract element, from which all the peripherals inherit.
Complementing this concept there are the next abstract elements: • InputPeripheral: All the Input Elements are the ones that bring data to the system. • OutputPeripheral: All the Output Elements are the ones that export data outside of the system or to an external system.
The peripherals are classified into any of the types in Table 1.
Clean architecture is a model-centered architecture where the cores are the Entities and
UseCases, This is the business logic and it should not be attached to any platform requirement,
while the Controllers, Gateways, and Presenters are the components that allow the
communication between the UseCases, and finally, the components related to the Framework are the
details, according to Robert C. Martin [
As presented in Table 2, the Camera and the GPS are EmbeddedPeripherals, but their nature is InputPeripherals, so they can be immersed in the Clean Architecture flow in order to communicate with other peripherals.
Even though the primary goal of these transformations is to refine the Domain metamodel with the objective of generating a functional Android source code for a mobile peripheral-centric app. The most important thing to define in each transformation is the intention of the transformation itself.
The artifacts engaged in the model transformation chain are categorized into two: PIM (Platform Independent Model), which comprises elements agnostic to the execution platform, in this instance, the Android operating system, and PSM (Platform Specific Model), which encompasses elements that depend on this platform. The figure 4 depicts this.
The intention of this transformation is to refine the Domain model in order to give some aspects more concerned about the architecture of the Android app to be generated.
Significantly, the nature of ATL is imperative, allowing the creation of blocks that can serve as either matched or called rules.
The components involved in this transformation are visually represented in Figure 5.
The source code is automatically generated in Kotlin specifically tailored for Android platform version 12, codenamed "Snow Cone".
All of the components generated have their contracts, input, and output ports well defined into the component in a folder called "port".
The other point to highlight is that none of the components Adapters, UseCases, and Entities have any reference to any Android framework library, which indeed makes these components reusable to any other app, even more with the interoperability given by the Android framework, they can be connected with other components developed with Kotlin that fulfill the contract defined by these components.
The first module executed is the Acceleo Main Module, which is called Main.mtl, which generates the source code in two steps:
This first step generates the static structure of the Android app. • FrameworkComponent: – If the model contains screens then the transformation will generate some Extension fields that are used for the UI components, the MainActivity (required for any interaction required from an InputPeripheral that is connected from the Start component). – Resources: ∗ colors.xml ∗ styles.xml ∗ dimens.xml ∗ mainLayouts ∗ appbarLayouts ∗ NavHeader ∗ sideNavbar ∗ navgraph ∗ ActivityMainDrawerMenu • Configs: This includes the Manifest.xml, the project Gradle, and the Gradle app module ifles. • In case controllers are included, then it generates the Gradle file and Factory class for the adapters, UseCases, and Entities modules. This Factory class creates the concrete classes that implement the interfaces that will be used as contracts to communicate to other components.
While the static structure validates the existence of screens and controllers in order to generate the files, the dynamic structure follows the Peripherals connected from the Start element, since they are chained for the "connected" attributes then it is a straightforward path to follow, the only bifurcated situation is when the same Peripheral has a dataSource, dataStore and an embeddedConnector, then they are prioritized in that order:
• All the elements explained in the section 5, more specifically the InputPeripheral is generated depending on the type of the InputPeripheral, along with some extra files generated, as shown in the table 3. • goes on the controller or EmbeddedController, as the case may be. Architecture!InputPeripheral Files generated
Screen NFCReader MotionSensor
PositionSensor EnvironmentSensor
ViewModel Fragments NFCReader xml/nfc_tech_filter.xml: listing the technologies supported Activity Activity Activity
Figure 7 shows the elements that are taken from the architecture metamodel in order to generate the Android source code of the adapters ring of Clean Architecture.
Regarding to the Controllers, per each Controller element, it generates the classes: • Controller:
Concrete Controller class. • IController:
Input contract for the Framework component. • DS:
The Data Structure is to be transported from the adapter component. • goes on with the useCaseInteractor. • Gateway:
Concrete Gateway class. • IDAO:
Generates the output IDAO contract that the gateway is going to use.
• goes on with the OutputPeripheral.
Per each Gateway that is connected to a RealTimeDatabase it generates the next classes:
Figure 8 shows the elements that are taken from the architecture metamodel in order to generate the Android source code of the use cases ring of Clean Architecture.
Regarding the UseCases, per each UseCaseInteractor element, it generates the next classes: • UseCase:
Concrete UseCase class. • IUseCases:
Input contract for the adapters component. • Output contract for the adapters component:
IGateway and IPresenter (if needed). • Presenter:
If fulfills the requirements then the Presenter concrete class is also generated in the adapters component. • DTO:
The Data Structure is to be transported from the use cases component.
• goes on with the gateway.
It is necessary to validate the model transformation chain through several business cases under study and compare the time spent between conventional development and the use of the MTC.
Another desirable approach is to validate the efectiveness of model transformation by employing validation methods and unit tests ofered by each of the model transformations.
Finally, the model evolution will be reviewed in response to business requirement changes and software platform upgrades.
The development of the DSL (MPML Mobile Peripheral Model Language) as a means to enhance accessibility for a broader user base. This initiative facilitates the construction of Android applications, catering not only to those lacking software development knowledge but also extending its utility to individuals proficient in computer science. For the latter, the Model Transformation Chain ofers an avenue to concentrate their eforts on augmenting the functionality of semi-automated apps generated through the Model Transformation Chain.
EMF is presented as a user-friendly tool that helps the modeler in the creation of metamodels ofering case tools; supporting the XMI (XML Metadata Interchange) standard specification, and ensuring compatibility and interoperability with other modeling tools and platforms. Moreover, EMF boasts a well-crafted graphical user interface, which serves as a powerful visual representation of the underlying models. This intuitive interface enhances the modeler’s ability to interact with and comprehend complex models, further solidifying EMF as a versatile and indispensable tool for model-driven
The construction of the Model Transformation Chain was afected by several changes due to test and validation processes, demanding changes in all the stages of the Chain. Consequently, it is recommended to other people interested in working in this kind of work to use a Skeleton approach, which indicates to creation of the complete infrastructure with all the metamodels and their transformation models, and over time evolves in its construction.