we will discuss the latter in the chapter on related work in the second part of this thesis (cf. Chapter15).
Mobile application implementation: A major property of a model-driven development 8.12
approach is the program code generation, i.e., the generation of native or cross- platform program code. While identifying model-driven development approaches in the literature, we have to distinguish carefully between these technologies. For ex- ample, in their categorization of cross-platforms and languages, Ribeiro et al. [RS12, Table 2] exclude all approaches that lack a domain-specific modeling language (cf. Palmieri et al. [Pal+12, Table 1]) from the category of model-driven development ap- proaches, because model-driven development requires a domain-specific modeling language in order to increase the level of abstraction.
Mobile application architectures: The architecture of a mobile application is strongly 8.13
related to the kind of application implementation. Since cross-platform implementa- tions mostly tend to be web-based client-server architectures, the native application often realizes a rich-client architecture.
Unfortunately, the literature on the different model-driven development approaches 8.14
for mobile applications generally contains limited or no information as to how the model-driven development approaches and frameworks were developed, particu- larly which software development process model was used for the model-driven development infrastructures. Thus, we cannot position our agile bottom-up devel- opment approach clearly regarding this aspect. Additionally, the literature provides only insufficient information about user evaluation and practical experiences when using the designed model-driven development infrastructures in practice.
8.3
Comparison with Related Approaches
We will consider the following approaches as the most relevant work related to our 8.15
contribution:
MD2: MD2[Hei+13] [Hei13] is a model-driven development framework for cross- 8.16
platform (Android, iOS) development of data-oriented mobile applications. The used domain-specific modeling language is organized in three parts with respect to Model-View-Controller pattern. Thus, the first part of the modeling language that describes the format of data entities is called data model. The view model specifies the graphical user interface of the mobile application at a detailed level (e.g., defines widgets). Finally, the controller model links the view model and the data model, and describes the behavior of the resulting application. The behavior of a mobile application is described in an event-based manner. Different kinds of events can be handled by modeled actions. Based on the modeling techniques, the MD2approach
provides a concrete textual syntax (similar to the Human-Usable Textual Notation – HUTN [32]), corresponding model editors, and code generators that compile models to the mobile applications for different platforms. Model execution is not provided. The generated mobile applications are implemented in the native language of the desired platform. The generated mobile application has a client-server architecture. The model-driven development framework additionally generates a back end (JEE application) used by mobile applications of both platforms (Android, iOS).
MD2shows a high similarity to our approach and has a lot of well thought-out 8.17
solutions. The authors point to many well-known issues (e.g., concept mismatches between Android and iOS and alignment). There are differences in the top-down approach of MD2. In contrast to our agile bottom-up development approach us-
ing reference applications, the authors of MD2 decide on the features of their
model-driven development infrastructure in a top-down manner by prioritizing the frequently found requirements. Further limitations with respect to our approach include the limitation of modeling business logic inside the controller model and the
customization of generated mobile applications. Mobile applications that are gener- ated with the MD2model-driven development infrastructure follow a client-server
architecture. This limits the offline capability of the generated mobile applications because the data is stored on the server and cannot be reached in disconnected situations.
Mobl: Mobl [HV11a] [HV11b] is a model-driven development framework for the
8.18
rapid development of data-driven mobile web applications. The used domain- specific modeling language is organized in two parts with respect to the compo- nents of the Model-View pattern (a modified version of the Model-View-Controller pattern). Controller functionality is not modeled by the user, but added by the code generator. The data model provides facilities for defining classes with typed at- tributes. Moreover, the data model contains an object-oriented sub-language, thereby allowing adding program code to the data model. The view model provides screens as main elements. Screens comprise different kinds of widgets (e.g., buttons, labels, and text fields). Additionally, control elements (e.g., buttons) can be used to link different screens, i.e., to invoke other screens. Besides, the view model contains data bindings to establish a direct connection to the data model. Based on the modeling techniques, the Mobl approach provides a concrete textual syntax, corresponding model editors, and code generators that compile models to deployable server appli- cations coded in HTML/CSS/JavaScript. The resulting web application provides different web services for the exchange of data. Direct model execution is not provided even if the generated artifacts are interpreted locally by the web browsers of the mobile clients. As any other web-based approach, the application implemen- tation is a cross-platform implementation. The overall architecture of the system is a client-server architecture.
With respect to our approach and the majority of other approaches, Mobl shows a
8.19
lot of differences. The framework is strongly focused on data-oriented mobile web applications with standard behavior only. Hence, custom behavior and business logic cannot be modeled, nor can the generated standard behavior be customized. Although the authors claim that the generated mobile application can store data locally and thus the interruption of the network connection may not affect the mobile user negatively, a restart of the browser or the system might cause a problem in terms of data availability.
JUSE4Android: JUSE4Android [SA14b], [SA14a], [Sil+14] is a model-driven devel-
8.20
opment framework for single-platform (Android) development. The approach uses no domain-specific modeling language in the narrow sense. A common UML class diagram serves as the domain model. This model must be equipped with anno- tations that focus on graphical user interface definition, persistence, and declare which classes of the diagram are domain classes as part of a PIM. According to the modeling techniques, the JUSE4Android approach provides different concrete syntaxes (via UML class diagram definition), but no corresponding model editor to add the mentioned annotations to an app model. The code generator compiles the annotated model to a native implementation (currently only Android). However, model execution is not provided. The generated mobile application has a client- server architecture. The additionally generated back end provides the functionality of storing and distributing data objects to and from different front ends (mobile clients).
JUSE4Android is very similar to our approach, especially with respect to the contri-
8.21
butions (e.g., online- and offline capability) made in the second part of this thesis. The JUSE4Android approach realizes extended client-server architecture (cf. Figure
1.4). Due to a replication mechanism, the generated mobile applications can access the data even if they are offline. After reconnecting to the server, they can synchro- nize locally modified data. Since JUSE4Android demonstrates a good architectural design that matches up well with business information systems (BIS), the model- ing concerns are not very elaborated. Apart from the domain model, only little information can be added and the generated behavior is strongly limited to CRUD
8.3. Comparison with Related Approaches 141 functionality. A key difference between JUSE4Android and our approach is the modeling technique. JUSE4Android is based on UML and uses annotations. Hence, a proper definition of application-specific behavior is not possible. As we see in the second part of this thesis, such a behavior model is an essential requirement to generate conflict-free, offline-capable mobile applications.
Modagile: Modagile [Küs+13] is a model-driven development framework for cross- 8.22
platform (Android, iOS, Windows Phone) development of mobile applications. The used domain-specific modeling language is divided into four parts: a mobile application model consisting of DomainEntities, DomainAdapters, UIContainers, and Events. Similar to the MD2approach, the behavior of the resulting mobile appli-
cations is defined in an event-based manner. The domain entities are typed by an Ecore model. The graphical user interface layout can be modeled granularly using abstract, platform-independent widget types. Based on the modeling techniques, the Modagile approach provides a graphical concrete syntax, corresponding model editors, and code generators that compile models to the mobile applications for the different platforms. Similar to the other approaches, models are not executed at runtime. The generated mobile applications are implemented in the native lan- guage of the desired platform. The generated mobile application has a rich-client architecture.
Compared to our approach, we do not follow such a detailed modeling approach 8.23
regarding the graphical user interface. Additionally, we do not employ an event- based behavior modeling approach and follow a more process-oriented modeling approach. Nonetheless, the Modagile [Küs+13] approach is technologically quite similar to our approach, as it is also based on EMF.
The model-driven development frameworks developed by Serral et al. [Ser+10] 8.24
[Muñ+06], Ceri et al. [Cer+07], Escolar et al. [Esc+14], and Kapitsaki et al. [Kap+09]
support additional different contextual dimensions. We include these approaches and frameworks in our discussion of related work herein, but the detailed descrip- tion of these approaches follows in the second part of this thesis because the focus of these approaches is on context-awareness.
Other frameworks and tools such as AppInventor [23] [Wol+14], Canappi mdsl 8.25
[20], and arctis [Kra11] could not be evaluated, because internals about the domain- specific modeling language, the application architecture, or used target languages were not (or no longer) available at the time of evaluation.
More comprehensive reviews of the existing approaches — not just limited to model- 8.26
driven development approaches — are provided by Umuhoza and Brambilla [UB16] (results are partly shown in the middle part of Table8.1), Le Goaer and Waltham [GW13], Gaouar et al. [Gao+15], El-Kassas et al. [EK+15], and Charkaoui et al.
[Cha+14].
Table8.1shows the model-driven development approaches for the development 8.27
of mobile applications and the classification of their main characteristics. A X- symbol indicates that the corresponding feature is supported, whereas an ×-symbol indicates the opposite. An “-” indicates that this feature has not been evaluated.
Most of the model-driven development approaches focus on model compilation 8.28
and thus generate native program code. Only one of the evaluated approaches generates no program code and follows a model interpreter approach. Besides, client-server architectures are more often present. Unfortunately, most frameworks come with their own domain-specific modeling language. The lack of a standard modeling language for mobile application development makes it difficult in general to compare the different approaches.
As seen in Table8.1, the criteria annotation and textual of the criteria group modeling 8.29
techniques, and the criterion cross-platform of the criteria group application implemen- tation are not supported by our approach. Since the annotation criterion is usually used only in combination with general-purpose modeling languages (GPML), this
TABLE8.1: Model-driven approaches to the development of mobile applications (middle part of the table adopted from [UB16])
Name Modeling Aspects Modeling Techniques Application implementation Application architecture Model compiler
Data Behavior GUI Annotation Textual Graphical PIM PSM Native Cross- Platform Model interpreter Client- Server Rich- Client
MD2 X X X × X × X × X × × X × Mobl X × X × X × X × × X × X × JUSE4Android X × X X × × X X X × × X × Modagile X × X × × X X × X × × × X Serral et al. [Ser+10] [Muñ+06] X X × × × X X × × X × X ×
Ceri et al. [Cer+07] X X × × × X X × × X × X ×
Escolar et al. [Esc+14] X X X × X × X × × X × X X Kapitsaki et al. [Kap+09] X X × X × × X × × X × X × MobML [Fra+14] X X X × X × X × X × × - - MIMIC [Elo+14] × × X × × X X × X × × - - Applause [Beh10] X X X × X × X × X × × X X Francese et al. [Fra+15] × × X × X X X × X × × - - MAG [Usm+14] × X X X × × X × X × × - - RUMO [SF13] × × X × X X X × X × × - - WL++ [Str+15] X X X × X X X × X × × - - AXIOM [JJ14] X X X × X X X X X × × - - Mendix App Platform [25] X X X × × X X × × × X - - IBM Rational Rhapsody [19] X X X × X X X × X × × - - WebRatio Mobile Platform [77] X X X × × X X × X × × - - Appian [04] X X X × × X X × X × × - - Our Framework X X X × × X X X X × X X X
criterion is not relevant if a domain-specific modeling language is employed. A textual concrete syntax is not yet realized, but based on the used framework (EMF) such a syntax could be additionally added as future work. Similarly, the criterion of cross-platform code generation is currently not realized. Since the model-driven development approach is not limited to native code generation, this criterion could be fulfilled in the future by writing an additional code generator which generates cross-platform program code.
Our framework for the model-driven development of mobile applications supports
8.30
most of the mentioned features. Moreover, the ability to compile and interpret models and the support of different mobile application architectures lead to the contribution made in the second part of this thesis: the context support.
143
Part II
145
Chapter 9
Context Support – Foundations
and Definitions
The following sections clarify the terms context, context-awareness, and mobility 9.1
which are relevant in the second part of this thesis. Regarding the state of the art, we will shortly summarize the existing solutions and concepts with respect to platform-, device-, and user context support. We will discuss the support for system contexts in more detail. To this, we recall prior work of our own [Vau+16a] to show how we adopted the state-of-the-art extended client-server architecture and created a generic version which is used as the architecture of our generated mobile applications (cf. Figure1.4). This includes an introduction to the essential mobile transaction models.
9.1
Context and Context-Awareness
A significant difference between mobile applications and traditional applications 9.2
is the influence and evaluation of different contexts. In this work, we define a context as anything a mobile application can sense (cf. Abowd et al. [Abo+99, Sec. 2.2] and Dey [Dey01]). Moving on, we can distinguish between simple contexts (e.g., geographical location, temperature, and brightness) and complex contexts (e.g., walking outside, waiting at the check-out line at the supermarket), as Hofer et al.
[Hof+03]1proposed. If a mobile application could sense and react to such contexts,
we would call it context-aware, situation-aware, or self-adaptive (cf. [Abo+99, Sec. 3.2]). For instance, a context can be the time and the location of a mobile user. A context-aware application may use this information to provide the mobile user with context-specific data. Different dimensions of the context have been proposed by Abowd et al. and Dey [Abo+99, Sec. 2.3], Schilit et al. [Sch+94], and Schmidt [Sch+99]. As a summary of these, we use the following four dimensions (cf. Section1.2) in the course of this work: platform-related contexts (e.g., operating system), user-related contexts (e.g., role, personal data), device-related contexts (e.g., display size and available sensors), and system-related contexts (e.g., online/offline, interaction with other devices, services). Figure9.1shows the different contexts that are relevant to this work. Contexts are directed. Thus, to describe that a mobile application can be installed on different mobile devices, we say, “A mobile device is a context for a mobile application.” Contexts may also be transitive Hence, we say, “The system is a context for a mobile application” instead of “The system is a context for a mobile device, which is a context for a mobile application.”
As shown before, the mobile application is the entity that detects and reacts to the ap- 9.3
pearing contexts of different dimensions (cf. Figure9.1). Hence, context-awareness is primarily a property of mobile applications. In other areas, as Computer- supported cooperative work (CSCW) and Human Computer Interaction (HCI), the term context-awareness has also been applied, but in a different manner. In 1 It was originally called the physical context and the logical context respectively.
User context Platform and Device context System context
FIGURE9.1: Considered contexts of mobile applications
this field of research, the (mobile) user and its context-awareness regarding the environment is in focus rather than the context-awareness of the mobile application. Dourish and Bellotti [DB92] reports that during a CSCW task the users must be
9.4
aware of the activities of other users. This provides a context for the own actions and will enable cooperative work. Greenberg and Marwood [GM94] show that the context-awareness of users affect the design of the interface (cf. Rodden et al.
[Rod+98]) since the actions of collaborating objects and subjects must be propagated
to the interface in order to enable context-aware behavior and interaction of the user. Moreover, this artificial reproduction of contexts is strongly related to virtual reality (VR) or augmented reality (AR) applications (cf. Aliaga [Ali97]). In such applications, real objects are simulated, or annotated with additional information. The users of such applications can interact with such virtual or real objects. Hence, the user behavior is driven by these contexts.
To sum up, in this work we will deal with the context and context-awareness of
9.5
mobile applications, even if mobile users also may sense and react to contexts.