Regarding Figure1.2, we address the first three dimensions – platform, device, and 1.37
user context – using a two-level model-driven development approach. This approach uses design-time models for code generation and runtime models to adapt already generated mobile applications at runtime. The approach is based on the generation of native mobile applications, as web-based solutions are generally unable to work offline and limited in hardware access.
Supporting different system contexts (e.g., connection context) requires additional 1.38
applications. However, mobile application modelers should not be involved in specifying the detailed architecture of the resulting mobile applications because we cannot assume that they are technical experts. Thus, mobile application modelers just declare the kind of the architecture (e.g., online- and offline-capable, only offline- capable, only online-capable), and the code generators configure the architectural components depending on the given requirements. The general architectural design is based on a generic extended client-server architecture supporting context-aware data and transaction management for mobile applications.
This overall approach has three major advantages. First, the model-driven de-
1.39
velopment approach covers the platform context very well since different code generators can be used to generate platform-specific implementations from the platform-independent design models. Second, the flexibility of design models (e.g., through model transformation) allows the generation of device- and user context- specific versions of the mobile application. Moreover, runtime models enable some of this flexibility even during runtime. Finally, the approach makes domain experts capable of creating system context-aware mobile applications without requiring a special expertise in architectural design and the technical requirements. These advantages are evaluated by several case examples.
1.4.1
Design Models and Runtime Models
In order to support platform, device, and user contexts better, we propose a two-level
1.40
modeling approach as a first fundamental difference from the existing one-level modeling approaches. iOS project Android project Provider model (M0) App model (M1) single deploy (2) Co m p ile t im e R u n tim e
Android platform iOS platform
instance of interpreted in (3) generated to (1) generated to (1) interpreted in (3) single deploy (2)
FIGURE1.3: Two-level modeling approach
Figure1.3shows this novel approach in detail. A mobile application developer (not
1.41
necessarily a technical expert) creates an app model. The app model conforms to a domain-specific modeling language (DSML) for mobile applications, which is developed during the course of this work. The mobile application developer can generate mobile application projects including source code and further artifacts (e.g., platform-specific graphical user interface descriptions, external libraries) for different platforms (Step 1). This already covers the platform context. After compil- ing these projects, a mobile application can be deployed to the mobile device of the respective platform (Step 2).
Using a traditional model-driven development approach, the deployed applications
1.42
1.4. Approach 15 again in order to realize the modification. They could not provide many configu- rations for different user groups or platform types at the same time. Hence, our approach uses a second modeling level. A providing user may create one or more provider models. A configuration given through this provider model is interpreted at runtime by the deployed mobile applications (Step 3). Hence, redeployment is not necessary. The provider model may modify the appearance, behavior, or data used in the mobile applications. This architecture implements a hybrid approach because runtime models are used as well as static application code [Ben+11]. The resulting applications provide runtime adaptability [Flo+06] but are not solely interpreted. This provides user and device contexts in an appropriate way, as shown later in detail by several case examples.
1.4.2
Extended Client-Server Architecture
As a second fundamental difference, we abandon the strict client-server and rich- 1.43
client paradigm used by many existing model-driven development approaches. Based on the work of Satyamaran [Sat96] (cf. also Fuchß [Fuc09]), we follow an architectural paradigm called blurred roles. Blurred roles denote a relaxation of the commonly used client-server architecture. Parts of the server are duplicated on the client-side.
Extended Client (EC) Application GUI Application logic Local transaction manager (TM) Replication manager Synchronization/Re- integration manager Log offline online Local DBMS DB Client (C) Application GUI Application logic Server (S) Central transaction manager (TM) DB Central DBMS
FIGURE1.4: Extended client-server architecture vs. client-server architecture
A mobile application that follows the traditional client-server architecture, as is 1.44
shown on the right-hand side of Figure1.4, cannot operate when the connection of the client C and the server S is interrupted: required services, such as the database (DB), are no longer available. In turn, an extended client EC (left-hand side of Figure1.4) can provide replicated data and transaction logging as part of a local transaction manager (T M ). These facilities can be used while the extended client (EC) is disconnected from the server S. Moreover, the architecture of the extended client exploits a particular mobile transaction model (affects the implementation of the gray colored areas in the figure). Such mobile transaction models are required to avoid and resolve conflicts in multi-user environments. As we see later, the generated architecture of the mobile application plays an important role in increasing the transactional throughput of mobile applications.