7.3 Construction of Code Generators
7.3.6 Code Generator Implementation
Finally, the Eclipse plugins, namely pimar.generator.frontend.ios and pimar.generator.-
7.101
frontend.android, implement the code generators for the desired platforms (cf. Table
7.3). A separate plugin for the back end generation of each platform is provided inside the code generator projects respectively.
TABLE7.3: Fourth set of plugins shaping the MDD infrastructure
Plugin project name Content Type
pimar.generator.frontend.ios Code generator (iOS) manual
pimar.generator.frontend.android Code generator (Android) manual pimar.generator.frontend.android.test Test cases (Android) manual The code generators implement a builder mechanism and can be registered in an
7.102
EMF-based project that contains app models (cf. Figure6.19). The code generators automatically track each change in the model files and regenerate the application
7.3. Construction of Code Generators 121 code. However, they might deactivate temporarily until the mobile application modeler completes a part of the model.
The plugin pimar.generator.frontend.android.test implements test cases for the Android 7.103
code generator. Currently, a test-suite for the iOS code generator has not been implemented yet. However, manual test cases can be reused because the structure of the resulting mobile applications (Android and iOS) is similar and their behavior should be identical.
7.3.6.1 Similarity Between the Code Generators
A review of the code generators shows that both code generators have a similar 7.104
structure but also some differences which are not reasoned only by the different implementers. Since the Android generator was implemented before the iOS generator, the iOS implementer tried to adopt as many architectural design decisions as possible. Both generators provide similar packages for the interaction of the code generator plugin with the IDE and particular the common used graphical model editor. The mechanisms to setup the project folder structure of the IDEs are also similar. As shown in the Tables7.4and7.5, the Android code generator is more structured, i.e., provides more packages. In turn, not all packages and the corresponding content are necessary for the iOS code generator. For example, the iOS platform does not require external layouts, menus, and strings (cf. A.9) and adapter or dialog (A.2 and A.3) generators. Thus, the iOS generator has no directly corresponding packages, but rather uses implicit equivalents inside the denoted packages (I.2; I.3; I.4).
TABLE7.4: Packages and content of the iOS code generator
No. Packages (pimar.*) Description Maps to
I.1 .generator Setup of the project folder structure
and meta-files
A.11 I.2 .generator.controller Creates the process selector, the se-
quence of task invocations and the predefined CRUD element
A.1
I.3 .generator.controller.crud Creates the individual CRUD opera- tions like Create, Read, and Delete
A.6 I.4 .generator.controller.-
invokegui
Creates the invocations of GUIs and the different pages (e.g., EditPage and ViewPage)
A.4; A.5 I.5 .generator.infrastructure Plugin code for adding the IOS gen-
erator to the Eclipse IDE
A.8
I.6 .generator.model Generates the DAO classes A.11
I.7 .generator.util Utility code used by the Plugin A.12
The alignment and shared use of similar and especially non-generating parts of the 7.105
code generators might reduce the effort for maintenance of several code generator implementations. Nonetheless, we recommend that platform-specific code gener- ators should reflect the targeted platform and intended artifacts (e.g., declarative layouts). Based on our experience it is very useful to generate human-readable code and respect the intended project structure of the desired software platform. This ensures an easy adoption of prototypical code which is written and tested in a generated prototype to the code templates.
The similarity between the resulting mobile applications is discussed at the end of 7.106
TABLE7.5: Packages and content of the Android code generator
No. Packages (pimar.*) Description Maps to
A.1 .generator.controller Creates the process selector, the se- quence of task invocations and the predefined CRUD element
I.2
A.2 .generator.controller.adapter Creates List adapter I.2; I.3;
I.4
A.3 .generator.controller.dialog Creates Dialogs I.2; I.3;
I.4 A.4 .generator.controller.-
invokegui
Creates the invocations of GUIs I.4 A.5 .generator.controller.-
invokegui.pagegenerator
Creates different pages (e.g., Edit- Page and ViewPage)
I.4
A.6 .generator.crud Creates the individual CRUD opera-
tions like Create, Read, and Delete I.3
A.7 .generator.helper Helper classes used by the code gen-
erator templates to create code snip- pets
I.7
A.8 .generator.model Generates the DataAccessLayer
which imports the EMF Library project (<project>.Lib)
I.6
A.9 .generator.resources Generator dependent Android
resources (e.g., Menus, Layouts, Strings)
I.2; I.3; I.4 A.10 .generator.util Utility classes to copy static code to
the generated project
I.1
A.11 .infrastructure Plugin code for adding the IOS gen-
erator to the Eclipse IDE and setup of the project folder structure and meta-files
I.1; I.6
A.12 .infrastructure.util Utility code used by the Plugin I.7
7.4
Evaluation
The preceding sections presented the facilities for code generation. Together with the
7.107
infrastructure components presented in Chapter6the model-driven development infrastructure can be used by mobile application developers for creating mobile applications in a platform-independent way. Hence, we will now discuss whether or not the requirements given in Chapter4are now satisfied completely (Question 1). Moreover, since our model-driven development infrastructure is able to generate mobile applications, we come up with the following question: do the generated mobile applications reflect the focused features and the features of the initially provided reference applications (Question 2)?
As mentioned during the evaluation of the domain-specific modeling language,
7.108
the appropriateness of a developed domain-specific modeling language depends not just on the compliance to generally accepted design guidelines, but also on the acceptance of the desired user group, i.e., the mobile application developers that use this domain-specific modeling language. Hence, we ask: how easily can the domain- specific modeling language and the model-driven development infrastructure be adopted by users of different skill levels (Question 3)?
Finally, we evaluate more technical aspects of the designed model-driven devel-
7.109
opment infrastructure by discussing questions such as: how similar are the code generators and the generated mobile applications for the particular platforms, i.e.,
7.4. Evaluation 123 Android/iOS (Question 4)? Do the code generators work correctly (Question 5)? Do the code generators scale (Question 6)?
7.4.1
Setup
To answer the first set of questions (Question 1 and Question 2), we again use the 7.110
acceptance criteria of the requirements to demonstrate that the created artifacts within this chapter cover and comply with the requirements. To show that the generated mobile applications reflect the focused features and the features of the initially used reference applications, we discuss three case examples. These case examples, i.e., the mobile applications and their features, cover most of the features given in Table7.1.
In order to answer the question of how easily the model-driven development in- 7.111
frastructure could be adopted by users of different skill levels (Question 3), we conducted several hands-on tutorials. We will report on the qualitative observa- tions.
The set of technical questions (Question 4 – Question 6) is discussed by presenting 7.112
the mapping of the generated Android and iOS applications (Question 4), providing a test suite for functionality tests of the code generator (Question 5) and conducting scalability tests to test the runtime behavior of the code generators (Question 6).
7.4.2
Requirement Coverage (Question 1)
The parts of the overall implementation of the model-driven development infrastruc- 7.113
ture which are shipped by the plugins denoted in Table7.3cover the requirements
4.2.1,4.2.2, and4.3.2(cf. Table4.1).
The plugins pimar.generator.frontend.ios/android (cf. Table7.3) implement the afore- 7.114
mentioned requirements completely: first, they form the code generator component as part of the tooling (cf. Section4.3.2). Second, they determine the architecture of the generated mobile applications. Within this part of the thesis, we focus on data- driven mobile applications (cf. Section4.2.1) which form a single-user standalone system with back-end access (cf. Section4.2.2).
The data-driven acceptance criterion posits that the generated mobile applications 7.115
(Android and iOS) must be able to serialize the acquired data. Using the func- tionality described in Section7.3.3.2(Mapping of the data model), the designed model-driven development infrastructure fulfills this criterion for the desired plat- forms.
The designed model-driven development infrastructure generates mobile applica- 7.116
tions that are able to work as a standalone system with back-end access as described in the Sections7.2.2.1and7.2.2.2. Finally, the acceptance criteria for the code gen- erator requirement are fulfilled if a representative set of models can be used for the generation of runnable mobile applications for different platforms. This holds true to the extent as the case examples and the functionality test demonstrate that the code generators are able to create runnable mobile applications for many dif- ferent app models and, in turn, the test models reach a high coverage of the code generator.
7.4.3
Feature Coverage (Question 2)
The designed model-driven development infrastructure primarily allows the model- 7.117
driven development of mobile applications, which is a key contribution of the first part of this thesis. The model-driven development approach employs abstract and
TABLE7.6: Focused features and coverage by the model-driven development infrastructure
Feature group ◃ ... ◃ Feature/s
Case example 1 Case example 2 Case example 3 Covered by the MDD infrastructure
Application type ◃ Standalone X X × X
Application type ◃ Information system × × X X
Application type ◃ Transaction system × × × (X)
Software platform ◃ Android X X X X
Software platform ◃ iOS × X × X
Hardware platform ◃ Screen ◃ Resolution × × × (X)
Hardware platform ◃ (Actors/Sensors/Interfaces/Memory) X X × X
Application architecture ◃ Native application X X X X
Application architecture ◃ Interpreter application × × X X
Application architecture ◃ Hybrid application × × X X
Application development ◃ Model-driven X X X X
Model-driven ◃ Design model (Abstract/Detailed) X X X X
Model-driven ◃ Runtime model × × X X
Data and transaction management ◃ Local X × × X
Data and transaction management ◃ Central × × X X
Graphical User Interface ◃ Dynamic × × X X
Context-awareness ◃ Platform context-awareness × X × X
detailed design models and runtime models. Since the domain-specific modeling lan- guage is platform-independent, the available code generators compile the models to different software platforms (currently Android and iOS).
According to the model-driven development approach, which does not focus on
7.118
technical details, the code generator conceals the technical details and the architec- ture of the mobile applications. The implicit architecture of the generated mobile applications is native but contains also interpreter functionality (used during the implementation of the context-awareness in the second part of this thesis). Hence, we call the application architecture of the generated mobile applications hybrid application. Due to the nativeness of the generated mobile applications, different actors, sensors, interfaces, and memory of the hardware platforms can be accessed. The type of the generated mobile applications can be standalone (with preset data) or an information system if a back end is used. This requires local data and transaction management. Additionally, transaction systems with central data and transaction management can be realized.
Table7.6shows the covered features. Compared with the features that are covered
7.119
by the initial reference applications (cf. Table7.1) now all features are covered. Please note that the features transaction system and device-specific resolution, as well as corresponding case examples, will be covered/introduced in the second part of this thesis. Moreover, we will introduce and discuss additional features in the second part.
To demonstrate the applicability and usefulness of the model-driven development
7.120
infrastructure, we consider three case examples for the first part of this thesis. Please note that the following prototypes do not yet demonstrate the two-level modeling approach using provider models or the context-aware behavior. Such prototypes will be shown later in the second part of this thesis.
7.4. Evaluation 125
7.4.3.1 Case Example 1 (Mathematikum)
Our first case example is a mobile application designed for a local science museum, 7.121
called Mathematikum1. The Mathematikum is a museum with a huge collection of exhibits that explain complex mathematical topics in a playful manner, making them accessible for laypeople and children. To follow this philosophy, the mobile application requires a very intuitive and highly interactive graphical user interface and should not only present mere text-based information statically.
FIGURE7.8: Caesar’s ciphered text “Knack den Code” (Break the code)
To meet this requirement, two game-like activities are implemented. One of them 7.122
is concerned with an exhibit where a ciphered text has to be decoded by clever guessing (cf. Figure7.8). Successful guesses are shown to the mobile user. Moreover, they see the text that still has to be deciphered. The second game-like activity uses Caesar’s cipher for ciphering short texts and sending them by SMS or a messaging application like WhatsApp.
(A) Object detection and support offering (B) Overlayed solution hint FIGURE7.9: Traveling Salesman Problem “Deutschlandtour” (Germany Tour)
Using augmented reality, users can get interactive guidance to understand exhibits. 7.123
(A) Overlayed animation (Man) (B) Overlayed animation (Mouse) FIGURE7.10: π Approximation “PI-Kreis” (PI-Circle)
This functionality is used here to interactively explain the Traveling Salesman Problem (TSP). When visitors try to solve this problem hands-on by building a tour through Germany, the mobile application can give them hints on finding the right solution (see Figure7.9). To demonstrate how π can be approximated (dividing the sum of different-sized footsteps around a circle by the diameter of this circle), augmented reality features are used to create animated explanation scenarios (see Figure7.10). The mobile application is available at [57].
The Mathematikum application is a standalone application that operates perma-
7.124
nently offline. Hence, the data and transaction management are local. It is first generated for the Android platform, i.e., a native implementation is generated. A native iOS version could also be generated, but customized code (annotated in the app model) must be written again for iOS. The model-driven development process of this application requires only a design model, as a start- or runtime adaptation of the graphical user interface or the behavior was not required. The application makes use of the device hardware (e.g., the built-in camera). The corresponding features of this mobile application are marked in Table7.6(Case example 1).
7.4.3.2 Case Example 2 (SmartPlug)
The second case example demonstrates how a generated mobile application can
7.125
deal with external hardware devices. The SmartPlug application provides wireless remote control for home appliances and electronics. Users can turn off and on electronic devices that are attached to a manageable power distribution unit (e.g., NETIO-230B [22]) controlled by SmartPlug. SmartPlug logs the electricity usage and can forecast the costs for electrical energy based on the logged switching intervals. Figure7.11shows the main use cases of the mobile application.
The main menu (Figure7.11a) contains the use cases Configure device, Switch devices,
7.126
Show protocol, and Power consumption. The use case Switch devices (Figure7.11b) shows the registered devices and current states (in brackets). The screen Power consumption (Figure7.11c) shows the calculated energy consumption broken down to the devices. The mobile application uses manually written code (extending EOperations) and existing libraries (e.g., java.net.Socket) to establish the connection
7.4. Evaluation 127
(A) Main menu (B) Switch devices (C) Power consumption FIGURE7.11: The mobile application SmartPlug
to the external device. After an adaptation of the manually written platform- specific code (i.e., EOperations), the app model could be used to generate a mobile application version for iOS.
The SmartPlug application is a standalone application that operates permanently 7.127
offline (except for the connection to local devices through a Wi-Fi, NFC, or Bluetooth connection). The app model of the SmartPlug application does not contain a lot of customized code, and can thus be easily used for generating native implementations for Android and iOS without much effort. Consequently, the development process is platform-aware, as different software platforms can be operated. The SmartPlug application can interact with external hardware (e.g., sensors/actors) through the interfaces of the mobile device. Table7.6(Case example 2) shows the features of this mobile application.
7.4.3.3 Case Example 3 (TV Reminder)
The third case example shows a data-oriented mobile application that provides 7.128
mostly standard processes and tasks (e.g., CRUD functionality). The TV Reminder mobile application organizes the broadcast times of the mobile user’s favorite TV shows. By browsing the list of upcoming broadcasts, the mobile user can view and select favorites. The selected favorites are shown in a separate list in ascending order to get a quick overview of the upcoming broadcasts. Additionally, the user may export the selected favorites to the calendar to get a notification when a TV show begins. The mobile application creates a calendar entry based on the broadcast time and duration by using the calendar provider. Contrary to the mobile applications
(A) Main menu (B) View upcoming broad- casts (including favorites)
(C) Detail view (Tv show and episodes) FIGURE7.12: The mobile application TV Reminder
presented before, the TV Reminder does not provide any means to create, update, or delete broadcasting elements. Moreover, the detail view of TV shows/episodes can be customized at runtime by a runtime model. Figure7.12shows the main use cases of the mobile application.
The TV Reminder application is an information system that relies on a central
7.129
database, i.e., its data management is centralized. It is generated for the Android platform, but can be generated for iOS as well. Its native implementation allows the interpretation of data and style models at start- and runtime. This requires a model-driven development approach that contains both design- and runtime models. Thus, we call its application architecture hybrid. The features of this mobile application are summarized in Table7.6(Case example 3).
7.4.3.4 Potentials and Limits
During the development of the shown example applications, we learned that our
7.130
domain-specific modeling language can be applied best if the mobile application focuses on data management. Data structures, their graphical user interface repre- sentation, and the CRUD functionality can be modeled on a high abstraction level. Our case examples also reveal that individual behavior may be added, sensors may be used, and external devices may be controlled. Relatively small numbers of model elements compared to huge amounts of generated code boost productivity for this kind of mobile applications. The situation may differ for mobile applications that focus less on data management. The Mathematikum application, for example, has a larger amount of game-like behavior that is not generated, but manually coded. In particular, this application shows that code generation and manual coding can be in- tegrated seamlessly. It also shows the limitations of our model-driven development approach in its current form. Although some high-level behavior can be specified by abstract modeling elements (e.g., CRUD processes), and simple logic can be modeled using the control structures (e.g., If-Else, While, Assign), it is preferable to hand-code more complex behavior. The reason for this does not necessarily lie in the limited expressiveness of the domain-specific modeling language. Rather, it is a matter of convenience to code complex algorithms manually and in a text-based way instead of modeling them on a similar abstraction level in a graphical model editor using a visual domain-specific modeling language.
7.4.4
User Experience Evaluation (Question 3)
In addition to the rather technical evaluation of the domain-specific modeling