{'fraction_non_alphanumeric': 0.02590069905000896, 'fraction_numerical': 0.005153253271195555, 'mean_word_length': 5.095875443867795, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Towards a New Perspective of Building Tools for Context-Aware Mobile Applications

Technological growth has been exponential in relation to mobile devices (such as embedded sensors as GPS or accelerometer) that have allowed developing context-aware mobile applications for the market. This growth generates a new challenge about how to support the creation of this kind of application to adapt them to the current user’s demand. Nowadays, there are several approaches that could be used to create context-aware mobile applications, but these approaches are not designed to support variability in the kind of generated applications. The aim of this paper is to propose a building tool that allows generating a wide variety of context-aware mobile applications. Our tool has been designed from scratch considering a taxonomy of variability concepts which help to identify the potential variability points to obtain more flexible building approaches. The first version of our tool is presented which is based on UML tools like Eclipse, Sirius Obeo, and JBoss. Finally, a discussion of different aspects is detailed to help designers to have guidelines to select the appropriate development environment for the design of building tools for context-aware mobile applications.


Introduction
Technological growth has been exponential in relation to mobile devices (such as embedded sensors as GPS or accelerometer) that have allowed to develop contextaware mobile applications for the market which are described in [1]. Moreover, it has emerged a new issue as is presented in [2], which consists of how to build contextaware mobile applications that are useful for users, something that is vital in today's market. This growth generates a new challenge about how to support the creation of this kind of application to adapt it to the current user's demand.
Context-aware mobile applications are used in different domains, for example, traffic assistance, medical monitoring, tourism, etc. [1,2]; but they could also be used in other potential scenarios, as mention in [3] for future mobile applications for education. Thus, building tools for this kind of applications should be designed to support new requirements. In [4], the authors identify two kinds of new requirements those that maintain the same goal of the application (associated with adaptation) and those that change the main goal of the application (related to evolution). According to [4], integrating runtime adaptation and evolution is crucial for the sustainability of software systems; and the building tools are not the exception.
There are currently several building tools that could be used to create context-aware mobile applications. However, there is not yet an agreed solution for this kind of application as it is mentioned in [5], so, it is an open area of research. There are building approaches for both non-expert users as is presented in [6]; and experts which require some technical knowledge for the modelling of features such as is detailed in [7]. Nevertheless, these tools are not designed to support variability in the kind of generated applications; for example, they only provide GPS as a location mechanism that is related to the available APIs. This limitation is one of the motivations of this paper.
When different building approaches for context-aware mobile applications are designed from scratch, the designer should identify the potential variability points in order to obtain more flexible tools. A possible way of handling some variability concept was exemplified in [8] for conceptual building approaches; however, it is not detailed from the building tool's perspective, so, this is the motivation for the research presented in this paper.
Therefore, the aim of this paper is to propose a building tool to support variability in while generating applications that have been designed using the taxonomy of variability concepts proposed in [8]. This tool is based on UML standards in order to have more interoperability with other existing tools.
In this paper, the first version of our tool is presented which is implemented following the UML specification described in [9]; and it integrates Eclipse, Sirius Obeo, and JBoss.
We hope that this paper helps designers to know a possible way of handling variability in building tools for context-aware mobile applications. To do so, a discussion in relation to this topic is presented, and details are presented on how to consider the variability in these tools to generate a wide variety of applications. This discussion could be used as guidelines to select the appropriate development environment for the design of these building tools.
The paper is structured as follows. Section 2 presents the methodology. Section 3 presents the first version of our building tool for context-aware mobile applications. Section 4 presents a discussion and the outlook of the paper. Finally, conclusions and future works are detailed in Sect. 5.

Methodology
Our building tool for context-aware mobile applications has been designed using the taxonomy of variability concepts described in [8]. This section describes a survey of the proposed taxonomy [8], in order to help the reader to better understand how our tool handles variability. In addition, our building tool is based on the UML standard to have more interoperability with other existing tools. Therefore, in this section, UML tools are also detailed to understand the interdependence with the tool.

Variability Concepts Used to Design Our Building Tool
We have been working on the topic of mobile applications for more than ten years. In the past, we have proposed in [10] a model approach to handling variability in contextaware mobile applications; which considers the separation between the aware-objects concept of its context-feature and in addition to the sensors (which assign values to these features).
We have been creating some authoring tools for this kind of application. For example, in [11] is presented an authoring tool to create in-situ location-based experiences; this tool has been extended in [12] in order to provide support for locationbased educational activities. Besides, in [13] is presented an authoring tool to in-situ co-design location-based applications inside indoor spaces.
Based on our experience, an initial taxonomy version of variability concepts for building approaches for context-aware mobile applications has been presented in [14]. The taxonomy presented in [14] defines the following concepts: relevance, combination, categorization, precision and accuracy's margins, configuration type, and execution type. These concepts have been selected in order to help designers to identify the potential variability points to obtain more flexible building approaches. Only a brief description of each concept of this taxonomy is detailed in [14], without going into details on how should be handled in building approaches.
In [8] a possible way of handling each variability concept of [14] was exemplified for conceptual building approaches. In [8], each concept of the taxonomy is described using a pattern-based format, detailing how and what could be considered in the design phase of this kind of approach. However, in [8] is not detailed from the building tool's perspective, so, this is the motivation for the research presented in this paper.
Note that, when a building tool is designed from scratch considering the variability concepts presented in [8] and [14]; this eases the generation of a wide variety of context-aware mobile applications. Our previous works [8,14] analyses variability concepts only describing them without the details of a concrete implementation.
The main contributions of this paper, in contrast with our previous works [8,14], is to provide a building tool which handler variability concept to generate a wide variety of context-aware mobile applications.
A survey of the variability concepts presented in [8,14] is presented below. This survey supports the reader to better understand the variability concepts handled by our building tool (which is presented in Sect. 3).
• Relevance: each context feature has its own relevance in each application; for some applications, some of them are critical and other optional. A building tool should provide a scale of relevance in order to choose, for example, the most important context-features to generate reduced versions of applications. In addition, it is required to handle the heuristics of what actions to take based on the selected context features. This last functionality can be complex to implement from a building tool. • Combination: context-aware mobile applications could require the combination of various context-features to trigger some services or actions. The complexity of implementing this combination in a building tool is to define clear rules of how to react to each value that these context-features could take. • Precision and Accuracy's Margins: each physical sensor used in context-aware mobile applications has its precision and accuracy's margin. When a tool generates an application, it should define how to react to each sensed value from these physical sensors; but also how to consider the precision and accuracy of them in order to trigger the correct action. • Categorization: in context-aware mobile applications, there are different awareobjects, for example, the user or the environment. These aware-objects should have different treatment in the generated applications. Thus, the building tool should define the heuristics to handle the behavior based on each category of aware object. • Configuration Type: the physical sensors used in context-aware mobile applications have default, passive or active configuration type, according to [8]. The building tool should handle each configuration type. The active configuration type is more complex to handle because it requires automatic learning. • Execution Type: the physical sensors used in context-aware mobile applications have a passive or active execution type, according to [1]. The building tool should handle each execution type. The passive execution type is more complex to handle because it requires details of how the application will interact with the user; as well as, how it will react to each possible interaction.
Note that, the variability concepts described above are related to different aspects of the context-aware mobile application. Categorization is associated with aware-objects, Relevance and Combination are related to specific context-features of aware-objects; and the rest of the variability concepts (Precision and Accuracy's Margins, Configuration Type and Execution Type) are associated with physical sensors. A possible way to represent the variability concepts is presented in [8] which is based on the concepts presented in [10].
Using the representation presented in [8], in Fig. 1 are details the variability concepts used to design our building tool. The figure shows that some variability concepts are related to the concrete sensor, but others to the aware-objects or context-features as it has been mentioned.

Development Environment Used by Our Tool
In this section, the UML tools used by our tool are detailed in order to help the readers to understand why they have been chosen. Note that, there are lots of tools that could be used together to create context-aware mobile applications, but they have not been designed for this purpose. However, we have selected only UML tools to have more interoperability with other existing tools because they are based on the UML standard specification [9]. The selection of these UML tools has been focused on obtaining more flexibility in order to implement each variability concept described in Sect. 2.1.
There are two key points related to our selection; first, the tools should allow the possibility to represent information associated with each variability concept, and then they should allow a generation of applications using this information. We have considered these key points to choose which UML tools could be used together to design our tool.
The UML tools used to design our tool have been selected considering some research that compares different features of existing tools. For example, in [15] is reviewed the main features, potential advantages and current limitations of the main tools that exist for the development of graphical editors for visual Domain Specific Languages (DSL). In [16] is analysed the performance characteristics of the mobile applications developed with a number of common approaches and tools for mobile application development, including the native SDK's of Google Android and Apple iOS, and cross-platform tools of Apache Cordova, Microsoft Xamarin, and Appcelerator Titanium. In addition, in Nueva [17] we had been analysed different UML development environment for the design of building tools for context-aware mobile applications; according to the variability concepts described in [8]. For each UML development environment, we had analysed, for example, the complexity to represent different concrete data, how could be generated mobile applications and the complexity of this, and what sensors could be used and how these could be integrated into the generated applications. In [17] had only analysed different UML development environment; but it had not presented a concrete solution, as it is the proposal in this paper.
Considering that mentioned above, we have chosen to use Eclipse [18] as a development environment combined with Sirius Obeo [19] in order to represent each concept using visual DSL's [20], and JBoss [21] to generate Android mobile applications. Thus, the meta-models are defined with Eclipse, and then these meta-models are used by Sirius Obeo to specify the visual DSLs. This allows specifying values related to each variability concept in a rapid and easy way.
In addition, Eclipse has a lot of plugins to access the device's sensors (such as GPS and Compass) that are compatible with JBoss; to generate mobile applications with sensor`s functionalities. Moreover, JBoss allows creating new plugins to specify additional functionalities that are embedded inside the generated mobile applications.
Note that, JBoss works in conjunction with Hybrid Mobile tools [22] and extensive support Apache Cordova multiplatform [23] for the generation of hybrid applications; this lets using plugins for mobile device control and geolocation, among other features.

Results
The first version of our building tool is presented in this section which has been developed using Eclipse as the development environment combined with Sirius Obeo (to represent each concept using visual DSLs) and JBoss to generate Android mobile applications. Figure 2 shows how these technologies are integrated into our building tool. Note that, an Ecore Meta-Model [24] is created using Sirius Obeo and JBoss used both the Ecore Meta-Model and Sirius Obeo models in order to generate Android applications. The first step creates the Ecore meta-model with each concept described in Fig. 1. This offers the designers the possibility of using this meta-model to facilitate the task of creating concrete mobile applications because they could consume these concepts that have been defined. So, our building tool provides this meta-model as a baseline to generate mobile applications which are shown in Fig. 3.
Using the Ecore meta-model, we have created the visual DSL with Sirius Obeo as it is shown in Fig. 4. The main idea is that the designer gives specific values to the visual concept in a fast and easy way. Currently, we are working to improve the icons related to each concept and look for an easy way that designers could set the value of each concept. Figure 4 shows an aware-object classified as the user which has a locationfeature (that is set by the GPS sensor and has a margin of precision) with a medium relevance. In this case, a rule could be to trigger services according to different location value.
When the visual DSL has been created three intermediate models are generated: cams model code (classes that represent the meta-model concepts), cams edit (classes associated with edition) and cams editor (classes associated with the visual editor). These intermediate models are shown in Fig. 5.
Currently, we are working on generating Android applications using JBoos integrated with its available sensor plugins. To do that, we have been researching some existing sensor tools, and we are working on an automatic derivation. Besides, we are defining a new plugin with this functionality. We have to emphasize that we want to obtain a version of our tool that allows designers to define and set the values to both basic context-aware and variability concepts in a rapid and easy way, but also to generate functional mobile applications.

Discussion
This section discusses different aspects of building tools for context-aware mobile applications to help designers to have guidelines in order to handle variability to facilitate them to choose the appropriate development environment.
Note that, this paper is focused on the variability concepts described in Sect. 2.1, but the variability is a feature of context-aware mobile applications which has been studied from different perspectives. For example, in [25] is analysed 36 different ways of modelling context-aware, which implies variability in the form of representation of this kind of application. In some cases, context-aware models allow variability not only at the design level, but also at execution time [10]. This allows, for example, to  Towards a New Perspective of Building Tools dynamically add context while the application is running without requiring to be compiled again. Therefore, to have this support, the modelling approach should be designed to consider variability. A taxonomy is presented in [26] which is useful to understand the differences and similarities in how variability is handled in contextaware software. Therefore, the researchers as [10,25] and [26] could be used to enrich building tools for context-aware mobile applications with other variability concepts.
There are important key points related to select the appropriate development environment, in order to design building tools for context-aware mobile applications as is described below. First, the development environment should allow the possibility of represent information related at least to each variability concept described in Sect. 2.1, and it is important to mention that our tool provides visual DSLs to do this.
It should be considered that variability concepts are related to basic context-aware concepts. For example, precision and accuracy's margins, configuration type and execution type concepts are related to concrete physical sensors. The relevance and combination concepts are related to context-features and the classification concepts are associated with aware-objects. So, this requires representing basic context-aware concepts in a way that they are decoupled from each other's to allow reuse and extensibility. A possible representation to do that is presented in [10]. When decoupling basic concepts to be considered from a building approach, it allows the combination of different layers and thus, to handle the first level of variability. To do that, our tool provides meta-models with the basic context-aware concepts in order to have the first level of variability and based on this the designer could choose the value related to each variability concept using visual DSLs.
Another key point is that the development environment should generate applications using the information of basic context-aware and variability concepts. Sometimes, these development environments only bring support to embed physical sensors inside the generated applications such as JBoss. However, it is important to know that there are other ways to set context-feature values as described in [27]; the sensors could be of different types, for example, physical, virtual (using applications and services), direct user input, etc. Each of them has its own configuration and way of execution. So, the development environment should provide a way to represent these different sensors, for example, by using Eclipse and JBoss we could create plugins in order to handle each of them.
The combination variability concept implies to define the heuristics to specify how it behaves when the value of each combined context-features change. To do this, the development environment should allow the definition of these heuristics; in the case of Eclipse and JBoss, this could be done by creating a new plugin for each heuristic. Something similar occurs with the active configuration type because it requires an automatic learning program which in Eclipse and JBoss could be specified using a new plugin that implements the logic of this automatic configuration.
These discussion points are important when designers need to choose the appropriate development environment to design a building tool for context-aware mobile applications. We have considered these key points in the design of our tool in order to have the flexibility to implement the variability concepts. This paper has proposed a building tool to support variability for the generation of applications designed using the taxonomy of variability concepts proposed in [8]. This tool is based on UML standard tools like Eclipse, Sirius Obeo, and JBoss. The first version of our tool and some main features are presented in this paper.
In addition, a discussion and analysis are presented with recommendations that should be considered to select the appropriate development environment for the design of building tools for context-aware mobile applications.
We continue working to improve our tool to provide automatic generation of mobile applications. Besides, we will improve the tool with more plugins to increase functionalities for other sensors such as virtual sensors (using applications and services) and we will analyse how to define rules related to combined context-features easily.
In the future, we will analyse other variability features to enrich our building tool. For example, [26] to handler more variability in the generated mobile applications.