ting.getFontColor().getRed()» and generates the specified color value (=255) to the native program code in line 6. A program-code compiler processes the generated native program code, and the resulting mobile application shows the
modeled behavior, i.e., the specified font color.
Assume now the installation of the generated mobile application on different de-
2.34
vices. For example, the mobile application is deployed to an eBook reader that only provides a monochrome color scheme. The mobile application may not be usable because of the unfavorable style scheme. A common practice when using the model-driven development approach is to modify the GUI model and to generate a new mobile application variant that fits better to the desired device type. By follow- ing this approach, to deal with the device heterogeneity, a countless set of mobile applications and app models will result. According to the proposed approach (cf. Section1.4.1) to use design models and runtime models, a better solution seems to be the configuration of some values at runtime. This is what a model interpreter realizes.
Example(Model interpreter). Given the same setting as in the preceding example, a
2.35
slightly changed code template produces the native program code shown in Listing
2.4. The code template generates static code that works similarly to the meta-code statement shown in the preceding example.
LISTING2.4: The partly compiled object ProcessesOverview (excerpt)
1 . . . 2 public c l a s s M a i n P r o c e s s e s A c t i v i t y extends A c t i v i t y { 3 . . . 4 p r i v a t e void c r e a t e P r o c e s s L i s t ( ) { 5 . . . 6 m a i n _ l i s t . s e t F o n t C o l o r ( . . . ( 7 RuntimeModel . g e t S t y l e S e t t i n g ( ) . g e t F o n t C o l o r ( ) . getRed ( ) , 8 . . . ) ) ; 9 . . . 10 } 11 }
2.3. Software Engineering of Mobile Applications 31 The introduced statement in line 7 loads a runtime model at runtime (provided by the class RuntimeModel) and inserts the corresponding color value. Thus, the resulting mobile application can be configured at runtime by a runtime model. Modification of the design model, regeneration of the mobile application, and
redeployment are not necessary.
The question that may arise now is: why construct a model compiler instead of a 2.36
model interpreter? Similar to the traditional discussion regarding interpreters and compilers, both have advantages and disadvantages.
Model compiling has the following advantages (cf. den Haan et al.1) over model 2.37 interpretation:
Model compilers capture a lot of technical domain knowledge in the shape of 2.38
generation rules. The generated mobile applications can be generated in such a way as to look like manually coded mobile applications. Model instances and generation rules remain hidden to the mobile end user. Thus, compiled model-based mobile applications do not reveal too much knowledge about the domain and are easier to understand compared to a model interpreter.
From an infrastructure developer’s perspective, a model compiler approach is easier 2.39
to start with because reference applications can be used for code extraction and concept analysis. Besides, the model compiler approach is more iterative. A number of meta-code statements inside a code template could be increased or refined during the creation of the model-driven development infrastructure. Another great advantage consists in debugging support. The generated native program code can be easily debugged using conventional debugging approaches, while model interpreters are hard to debug.
In contrast, model interpreters have the following advantages over model compilers: 2.40
Model interpreters enable changes at runtime, which is of great importance regarding 2.41
the issue of context-awareness. Regarding platform portability, model interpreters may abstract from concrete platforms and execute platform-independent models. Finally, a model interpreter usually needs to be deployed only once and can then be used for runtime modifications of the mobile application using the runtime model.
Although the model interpreter approach sounds very flexible, not all platforms 2.42
fully support such flexible instantiation. For example, the Android platform does not support the programmatic access to all graphical user interface elements due to a static resource management. Thus, the implementation of the model interpreter is sometimes limited by the runtime behavior of a software platform.
Based on the presented design variants for the different components of a model- 2.43
driven development infrastructure, we developed a domain-specific modeling language as a self-contained language that depends on no other language. We initially focus on a graphical concrete syntax for this language, even if a concrete textual syntax might be useful for certain groups of users (i.e., technically-skilled developers). The code generators follow a template-based approach since most meta-tools support this kind of approach. Moreover, a template-based approach allows a bottom-up construction of code generators. Finally, we followed both a model compiler approach and a model interpreter approach in this thesis, particu- larly to benefit from the advantages of each of the approaches. Later on, we will describe which information can be modeled and evaluated at runtime (cf. Section
7.3.4).
2.3
Software Engineering of Mobile Applications
Next, we turn our attention to the software engineering process of mobile applica- 2.44
tion. Empirical studies reveal that software engineering of mobile applications is dominated by agile methods, as 86% of survey participants confirm that the agile methods are appropriate for the development of mobile applications [Flo+14a]. Scrum was the most closely followed approach. Apart from these empirical find- ings, Abrahamsson shows that agile methods fit very well to the traits observed in mobile software development [Abr05]. Agile methods match well because of small development teams (41% have 5-15 members [Flo+14b]), short development cycle durations (57% projects have a project duration of 6-18 months [Flo+14b]), and high product release frequency (46% of the projects have a monthly release), whereas tra- ditional software engineering processes need more lead time for up-front analysis and design.
Although general agile methods can be applied, the existing agile methods were