Rapidly increasing numbers of applications and users make the development of mobile applications to one of the most promising fields in software engineering. Due to short time-to-market, differing platforms and fast emerging technologies, mobile application development faces typical challenges where model-driven development (MDD) can help. An infrastructure for MDD has a high potential for accelerating the development of software applications. While just modeling the applicationspecific data structures, processes and user interfaces, runnable apps can be generated for multiple platforms such as Android and iOS. Hence, MDD can lift software development to a higher abstraction level leaving all technical details to the generators. Moreover, the domain-specific model of a mobile application can be the starting point for validation and verification based on formal models. In this paper, we consider the state-of-the-art in MDD of mobile applications and consider future research directions such as the MDD support for higher mobility in changing contexts, a combination of sensors, and augmented reality. Moreover, we discuss quality assurance of mobile applications.
The use of mobile applications has become an indispensable part of daily life. This has already and will lead to rapidly increasing numbers of applications and users that make the development of mobile applications to one of the most promising fields in software engineering. Mobile application development faces several specific challenges that come on top of commonplace software production problems. Popular platforms differ widely in hardware and software characteristics and typically show short life and innovation cycles with considerable changes. The market often requires that apps must be available for several platforms which makes a very time and cost-intensive multiple platform development a necessity. Available solutions try to circumvent this problem by using web-based approaches, often struggling with restricted access to the technical equipment (e.g. sensors) of the mobile device and making less efficient use of the device compared to native apps. Furthermore, web-based solutions require an app to stay on-line more or less permanently which may cause considerable costs and usability restrictions. Model-driven development (MDD) can help to improve this situation by a faster and easier development process of native apps and easier adaptability to new features of underlying platforms. Mobile apps are modeled in a modeling language focusing on main system aspects being enough to automatically generate platform-specific code. Hence, MDD allows to develop applications on a higher abstraction level, neglecting technical details. Furthermore, code quality may improve since code can be generated according to standards. In addition, the validation of app models w.r.t. system requirements may be facilitated by deducing formal models on a similar abstraction level.
The heart and soul of model-driven development is the domain-specific modeling language (DSML). Our developed DSML covers three aspects of mobile apps: its data entities and relations, its behavior including data management, access of sensors, use of other apps, etc., and its user interface. The design of our modeling language follows the credo: “Model as abstract as possible and as concrete as needed.” This means the following: Standard solutions are modeled very abstractly while more specific solutions are modeled in more details. E.g. data management by the usual CRUD functionality (using create, read, update, and delete operations) may be modeled by one predefined model element type while application-specific behavior is specified on the level of usual control structures.
To efficiently work with the DSML, we provide an Eclipse-based tool
environment consisting of a graphical editor with three different views for data, behavior
and user interface models as well as two code generators to Android [
Considering our approach to MDD of mobile apps, the following issues are still open: (1) Due to spatial movement, mobile apps offer new possibilities to interact with the environment: They support an increasing variety of sensors such as cameras, global positioning system (GPS), compass, etc. which can be advantageously used to position a mobile device and to inform the user about its position. These capabilities are especially interesting for augmented reality (AR) and navigation in space. (2) Mobile applications claim to operate reliably during spatial movement, however, developers have to deal with the effects of changing environmental contexts. One of the most important contexts is the connectivity of mobile devices. Since mobile applications are increasingly used as front-ends of transaction systems, they have to be designed for being able to deal with intentional or accidental loss of connection. In order to support higher mobility - in the sense that operations may execute across the boundaries of changing network states - problems and requirements for context-aware architectures of mobile applications are considered. We discuss how these issues may be supported by model-driven development as well.
A faster and easier development of mobile apps is nothing if their quality cannot be assured. We discuss what software quality means for mobile apps and what kinds of quality assurance techniques may be promising. 2
The core of an MDD infrastructure is the domain-specific modeling language. It is used to model the specific aspects of applications in a so-called app model. This model is platform-independent and the input to available code generators, here, Android and iOS. The generator results are platform-specific software projects containing runnable apps. For an overview see Figure 1.
instance of
iOS code generator
iOS project
An app model consists of three sub-models: the data model, the process model
to describe the app behavior, and the graphical user interface (GUI) model.
In the following, we focus on the main language features. A detailed language
definition can be found in [
The data model contains the typical elements of object-oriented data modeling like classes, attributes, aggregations, associations, etc. It is not only used to generate the underlying data access objects (DAOs) but also determines the design of the user interface that is concerned with data input and output.
The GUI model defines the graphical user interface of an app. It contains pages, style settings, and menus. The page type indicates the purpose of the page (e.g. to select a processor or to edit and view data). Thus, app modelers describe the required user interface just by selecting a page type (e.g., EditPage or ViewPage) and the code generator deduces the detailed structure of the interface (e.g. labels, edit and text fields, check boxes, etc.) by consulting the data model.
The process model defines the behavior of an app. This model part is structured in processes, including various types of sequentially performed tasks. A number of tasks are pre-defined such as tasks to create, read, update and delete data objects. The process model may refer to the data types of the data model and invoke pages of the GUI model; hence, it uses the other two model parts.
PhoneBook allPersons 0..*
Person ForenameB:BEString SurnameB:BEString MobileNumberB:BEString OfficeNumberB:BEString callMobileNumber toString address 0..1
Address CityB:BEString ZIPB:BEString StreetB:BEString NumberB:BEString
In the following, we consider the app model of a simple phone book app. This app shall support the management of personal contacts as well as the search for phone numbers and the set up of a phone call. A simple data model is depicted in Figure 2. Contact data is structured in classes Person and Address. The class PhoneBook is just a container for Persons and not intended to be viewed.
The modeled user interface of our phone book app is shown in Figure 3. This part of the app model is pretty simple, it just contains a style setting, a menu, and five pages, namely a ProcessSelectorPage, an EditPage, a ViewPage, a SelectableListPage for Person objects, and a MapPage for Address objects. Note that we just add these pages to the model and use them to specify behavior but do not specify their layout. Main MainProcesses ProcessesOverview : ProcessSelectorPage CRUDPerson , SearchPerson , CallPerson , ShowPersonAddressOnMap , NearToMe CRUDPerson CRUDPerson ALL
Person (a) Main Process (b) CRUD Process CallPerson PersonSearchPattern
PersonResultList
SelectedPerson CreatePersonSearchPattern Person PersonSearchPattern : Person
ReadAllPersons PersonSearchPattern : Person PersonResultList : Person
ChoosePersonFromResultList PersonResultList : Person SelectPerson SelectedPerson : Person
CallPerson CALL callMobileNumber
SelectedPerson : Person (c) Call Person Process
The behavior of the phone book app is modeled by a process selector as main process that contains processes for all use cases provided. Figures 4(a) and 4(b) show processes Main being a process selector and CRUDPerson covering the whole CRUD functionality for contacts. Figure 4(c) shows how to connect to a phone app to call a person. After searching for a person, operation callMobileNumber() is invoked on the selected Person object. Just a few lines of code (not shown) are needed to start the corresponding Android activity or iOS service. I.e. the operation is implemented manually.
Figure 5 shows selected screen shots of the phone book app, already generated by our Android generator. Little arrows indicate the order of views shown. The first sub-figure (Figure 5(a)) shows the main menu containing a standard CRUD process (Manage Person) to create, edit, and delete persons. The standard behavior and user interface for this task have been generated from a simple CRUD process (see Figure 4(b)) which the app modeler has created before. Moreover, the app considers the user location context to find contacts near the current location of the user (Figure 5(b)). Phone numbers are connected with an installed phone app in such a manner that whenever the user has selected a phone number, it automatically starts dialing (Figure 5(c)). 3
The modeling language is defined on the basis of the Eclipse Modeling Framework
(EMF) [
Two code generators are available, one for Android [
All the generated mobile apps have the following overall, platform-independent architecture: The architecture of generated mobile apps reflects the separation of data, process, and GUI aspects in app models leading to a model-view-controller (MVC) architecture. Since we generate data-oriented mobile applications, the architecture of each generated mobile app has a data layer. This layer contains the modeled data entities (e.g., persons and addresses) and provides functionality to serialize and deserialize these objects. The data layer forms the model of the application. The controller layer implements the behavior specified by the process model, i.e., it holds the application logic. It is the intermediary layer between the model and the view. The controller invokes the interactive user dialogs and processes events returning from user dialogs. The view layer provides all dialogs. This layer is most platform-specific because it uses the graphical components provided by the envisioned platform. These dialogs do not contain any calculations and navigation logics (except of input validation), and return all events to the controller. Finally, the architecture of a generated mobile app implements a transaction concept. A process invoked by the initial process selector dialog opens a transaction based on the data layer. If the user returns to this initial process selector dialog by confirming all steps, this transaction is committed. Otherwise, the user can cancel the transaction at any passing dialog, and the changes made are consequently lost. 4
Mobile applications change contexts as no other type of application does. A
context can be any information that can be used to characterize the situation of
a person, place, or object that is considered relevant for the interaction between a
user and an application. An app is context-aware if it uses the context to provide
relevant information and/or services to the user [
Using context information for navigation and travel Most of the apps for navigation and travel use the GPS to localize a mobile device. For example, a public transport app can dynamically list the nearest bus stop from which a bus will leave. Such a context-aware app uses the GPS position and the time of the request for calculating the next reachable connection and departure point. Indoor navigation is more challenging, because GPS is usually not available inside a building. Hence, we developed a prototype app (cf. screen shots in Figure 6) that combines different sensors (Barometer, Compass, WLAN Access Points, Camera & QR-Codes) to get a more accurate positioning in buildings. Additionally, the indoor navigation app provides different methods of sensor processing (trilateration, distance comparison, field intensity, weighted average) showing advantages/disadvantages in accordance with the buildingspecific installation of access points.
Another application of combined sensor information is related to augmented
reality (AR): AR uses the built-in camera to recognize objects and to augment
the live view with different types of virtual objects. This is usually very
processorintensive and mobile devices often have limited processor capacity. Hence, the
recognition and augmentation of many objects being close together is not
feasible since the device cannot compare all trained patterns with the current view
captured from the camera in an acceptable time. In order to circumvent this
problem, the number of patterns can be reduced through an accurate
positioning of the device. For example, an AR application is used to augment exhibits in
a museum. The accurate positioning of the device inside the building (floor and
room) can reduce the amount of data that must be processed (location-based
filtering). This approach was tested in [
(c) Map view and position
This way of mobility-related interaction with the environment is not yet fully
capable in the DSML. It is intended to use the realized prototypes for extending
the DSML as well as the code generators in an agile way [
Modeling context-aware apps Although there are no pre-defined modeling elements at the moment to model context-awareness, it is possible to model a context-aware app with the standard modeling elements. Our DSML already provides full access to the device sensors. Focusing on data-driven apps, we can demonstrate the location-based filtering of data that is already covered by our MDD approach. The phone book app contains a Process Near to me. This process uses the location context of the device (user) and filters the addresses of contacts accordingly. Only contacts within a given radius appears on the list. Thus, the list of contacts depends on the location of the device. 4.2
Dangers of changing contexts
Mobility and changes of contexts caused thereby can also be a danger. The
changing context, especially the connection context, usually makes mobile
applications with standard architectures non-operable in off-line situations. A look
at real-world applications gives evidence that application developers hardly
realize connection-aware mobile applications. None of the available apps for on-line
shopping supports transactions (such as ordering of products) in a disconnected
mode although a sudden stop in the middle of an ordering process may prevent
potential customers from eventually ordering selected products. To construct
mobile applications that are on-line and off-line capable, the applications have
to have a context-aware architecture supporting additional architectural
components like replication, synchronization and local transaction managers.
Providing a context-aware app architecture Processes that use connecting
operations are, in general discarded in an off-line context. These may be used
anyway if the conflict-free reintegration of locally modified data can be
guaranteed. Certain mobile transaction models can coordinate isolated changes of local
copies. Two of them are especially interesting: The Keypool transaction model
[
Usually, developers have to acquire a lot of knowledge about mobile
transaction processing before they are able to design on-line and off-line capable
applications. Our basic approach is the provision of code generators that can
create mobile applications with such a generic context-aware app architecture
[
As for any kind of software system, the quality notion for mobile apps covers various quality aspects such as correct functionality, reliability, security, usability, maintainability, just mention a few. Since correctness and reliability are usually the most important ones, we concentrate on those in the following.
In model-driven software development, software quality is extremely dependent of the platform-independent model since the code generator takes it directly as input. Hence, the generated code is not considered directly but the input model is analyzed instead for discovering potential problems. Moreover, the actual app behavior can be analyzed during runtime as possible for apps being classically developed. 5.1
Quality of app models To analyze the quality of app models, syntax checks such as smells or translations to formal models are possible approaches. The second is especially interesting to verify semantical properties. Moreover, an app model can be used to generate skeleton code for test cases, not necessarily for the generated application code but for separately implemented, i.e., non-generated code.
Smells represent modeling knowledge being condensed from developer experiences; they point to model parts that are suspicious w.r.t. quality. This means that modelers should have a look at smelling model parts and should decide which have to be improved. Model smells may produce code smells, i.e. generated code parts do not have high quality. A model smell in an app model may point to, e.g., processes with too many tasks leading to loosely structured services.
The translation of an app model to a formal model of choice can help to find potential reliability problems. Interesting questions are for example: Which processes are potentially in conflict? Which objects are potentially accessed concurrently? Can the modeled processes run into deadlocks? To get a meaningful formal model, app models may be preprocessed replacing standard processes such as the CRUD process by more detailed processes showing process behavior on a homogeneous abstraction level. 5.2
Quality assurance at run time App behavior cannot only be analyzed at development time but also at run time. There are two main approaches: To test individual operations implemented by hand, skeleton code for test cases may be generated. Another way to analyze the run time behavior is to log relevant information and to process it further.
App developers do not have to test all the code of the generated app. Since a code generator is reused again and again, it should result in a mature tool that ensures reliable code generation. If the intended app shows individual behavior, however, this behavior is not generated but has to be implemented manually and integrated into the generated code. These manually written code parts are encapsulated in operations which should be tested for their correctness. Based on their signatures and their embedding into generated code, it is possible to generate skeleton code for testing them in unit tests. The skeleton code sets up a test suite and has to be completed by semantical information about operations under test.
To find out how generated behavior interacts with individually specified behavior, it may be worthwhile to analyze the run time behavior of an app. This is also useful to get realistic information about, e.g., execution time, energy efficiency, and net usage of the app. As a basis, we could log relevant information in a log file. This may comprise information about active services, called operations with actual arguments, and much more. Condensing the log information in a log model would lead to a basis for further analyses. As proposed for the app model, the log model could be translated to a formal model of choice to use suitable analysis techniques. Interesting questions to answer are for example: How many transactions finished successfully? What are the execution times for performed transactions?
The model-driven development of mobile applications is an innovative field which has not been tackled much in the literature. Nevertheless, there are already some approaches which we compare to ours in the following.
MD2 [
Two further MDD approaches focusing on data-centric apps are applause [
Another kind of development tools for Android apps is the event-driven
approach App Inventor [
Besides the generation of native apps, there are several approaches to the
model-driven development of mobile Web apps being originated in the
generation of Web applications. Although Web apps show platform independence by
running in a Web environment, they have to face some limitations wrt.
devicespecific features, due to the use of HTML5 [
To summarize, our approach supports the model-driven development of native apps by high-level modeling of data structures, behavior and user interfaces while supporting the role-based configuration of app variants and in thus differs considerably from approaches aiming at comparable goals.
Model-driven development of mobile apps is a promising approach to face fast emerging technology development for several mobile platforms as well as short time-to-market with support for several if not all noteworthy platforms. In this paper, a modeling language for mobile applications is presented that allows to model mobile apps as abstract as possible and as concrete as needed. Two code generators are available to produce Android and iOS apps. The considered domain are data-oriented apps that may be enriched by specific behavior elements such as interaction with sensors and other apps as well as entertainment elements as, e.g, little games. Example apps are, e.g., tourist and conference guides as well as an app for home automation (SmartPlug).
Future work will be concerned with language extensions to cover mobilityrelated aspects such as mobile transaction models allowing reasonable off-line usage of apps, flexible sensor handling and, based on various sensors, advanced augmented reality. Moreover, generated apps shall show high software quality; criteria of interest are correctness, usability, energy efficiency, and security. Translating the app model or log information that has been collected at run time, to a formal model of choice may help to provide powerful analysis techniques.