of the feature model (see Figure5.4), we have to additionally consider all required features. Moreover, the focused features can be mapped to the requirements given in the preceding chapter and the requirements which will be introduced in the second part of this thesis. Table5.1shows which requirement (from the preceding chapter) can be addressed through which feature group.
5.5
Evaluation
In order to evaluate a feature model, there are two approaches: first, Lee et al. 5.25
[Lee+02, Sec.4] propose several guidelines (e.g., domain selection and scoping,
feature identification and categorization, feature organization, feature refinement) to validate a feature model and propose refactorings to improve insufficient feature models. These guidelines guarantee the quality and structural integrity of feature models. However, the characterizing power of a feature model can be tested and ensured only by the second evaluation method: Kang et al. [Kan+90, Sec. 5.1.4.3] propose using domain experts, who are not consulted while creating the feature model, and existing mobile applications, which should be characterized by the feature model. Similar to the domain experts, the selected mobile applications should not be used earlier for the derivation of the particular features of the feature model.
While we apply already Lee’s guidelines and refactorings already during the con- 5.26
struction of the feature model, we can nonetheless report that the feature model was successfully reviewed by external domain experts from academia (cf. Vaupel et al. [Vau+18b]) as well.
63
Chapter 6
Domain-Specific Modeling
Language and Model Editors
The core of our model-driven development infrastructure is the domain-specific 6.1
modeling language captured in a metamodel. In this chapter, we first present the main design decisions that guided us during the design of our domain-specific modeling language for mobile applications. Thereafter, we present the defining metamodel including selected well-formedness rules restricting allowed model structures. To illustrate the domain-specific modeling language, we show selected parts of a simple phone book app model, which will be used as a running ex- ample in this chapter. Furthermore, we provide a description of an application programming interface of the domain-specific modeling language that serves as a language library for all further components of the model-driven development infrastructure (e.g., textual or graphical model editors, model quality tools, code generators). Subsequently, the facilities to create app models by a graphical model editor will be presented. Finally, the presented domain-specific modeling language and its model editors are evaluated with respect to the requirements, the design guidelines for domain-specific modeling languages and the guidelines for user interface description languages.
6.1
Design Decisions
Based on the results of our domain analysis, we want to support the generation 6.2
of mobile applications that can be flexibly configured by providing users. This requirement is reflected in our modeling approach by distinguishing two levels of modeling: app models specify all potential facilities of mobile applications, and provider models define the actual variants of the mobile applications. We illustrate this general modeling approach in Figure6.1. While app models are used to generate Android and iOS projects (Step 1) to be deployed afterward (Step 2), provider models are interpreted at runtime by the generated Android and iOS applications (Step 3). Provider models can therefore be used to change functionality without redeployment of the mobile application. Provider models can be executed in two ways: usually, a provider model is interpreted at runtime, since it does not have to exist at design time. However, it is also possible to make it available at design time by adding it to the resources of its generated mobile application projects. It will then be considered in the build process.
Chapter 6. Domain-Specific Modeling Language and Model Editors Object model Style model Process instance model Provider model (M0) Data model GUI model Process model App model (M1) Data meta model GUI meta model Process meta model Metamodel (M2) interpreted in iOS App (3)
uses is instance of
End user Providing user Application developer Infrastructure developer Android Project iOS Project Compile time Run time generated to (1) generated to (1) single deploy (2) single deploy (2) interpreted in Android App (3)6.1. Design Decisions 65
The general approach to the domain-specific modeling language is component- 6.3
based: an app model consists of a data model defining the underlying class structure, a GUI model containing the definition of pages and style settings for the graphical user interface, and a process model that defines the behavior of a mobile application in form of processes and tasks. The data model and the GUI model do not have a direct link. However, the process model includes dependencies to both sub-models (see Figure6.1) by referring to their elements. The GUI model just contains an abstract definition of pages (see Figure6.6), instead of detailed layout descriptions. The data model indirectly defines the structure and the default layout of the graphical user interface. We will see later, during the explanation of the code generators, how the data model is used for the automatic generation of the graphical user interface (cf. Figure7.5).
A provider model contains an object model defining an object structure as an instance 6.4
of the data model. It also contains a style model defining explicit styles and pages for customized graphical user interfaces. Finally, it contains a process instance model selecting a subset of processes and providing them to specify the behavior of the intended variant of the mobile application. Similar to the app model, object and style models are independent of each other but used by the process instance model.
For the design of the domain-specific modeling language, we follow the overall 6.5
credo: “Model your mobile application as abstract as possible and as concrete as needed.” This means that the standard design and behavior of a mobile application can be modeled in an abstract way. This can be very useful for the rapid prototyping of mobile applications. A mobile application with a large share of custom behavior needs an app model with more details than a mobile application with a large share of standard behavior. In fact, all special styles, pages, and processes that may be used in the intended mobile application have to be defined in the app model. Since the provider model will be defined by domain experts, these are already completely domain-specific and follow the predefined app model. Provider models support the development of software product lines in the sense that a set of common features are shared and some variability is supported. Differences between mobile application variants are modeled separately by different provider models.
The GUI model specifies views along with their purposes, e.g., viewing and editing 6.6
an object, searching objects from a list and showing search results, doing a login, and choosing a process from the set of available processes. A GUI model is not usually intended to specify the inherent hierarchical structure of graphical user interface components as in rich layout editors like the Interface Builder [Pip10], Android Common XML Editor [GR11], and Android Studio [Zap13]. However, the model can be gradually refined to obtain more specificity in the generated mobile application. Style settings are specified independently from views and follow the same design idea, i.e., the more default the look and feel, the more abstract the model.
Processes and tasks covering usual purposes such as CRUD functionality including 6.7
searching, choosing processes, as well as invoking graphical user interface compo- nents, operations and processes. The modeling of custom behavior is supported by more specific model elements such as control structures and assignment tasks. More specific purposes may be covered by utilizing the well-known concept of libraries, i.e., a basic language is extended by language components for different purposes, as is done for LabView [Bis11].
To support the security and permission concepts of mobile platforms, the process 6.8
model includes platform-independent permission levels. The permission concept is fine granular (i.e., on the level of single tasks). However, some platforms like Android support only coarse granular permissions (i.e., on the level of applications). Another security-related feature is the user-specific instantiation of processes. Po- tentially, features of an application can be disabled by a restricted process instance model.