10.2 Modeling Language Requirements
10.3.2 Simulation System
Description:A simulation system should predict the transactional throughput of 10.30
the designed and generated online- and offline-capable mobile applications under various system conditions.
Explanation: The consulted domain experts admit that it is generally hard to 10.31
predict how many conflicts actually occur during synchronization in a deployed online- and offline-capable mobile application. The number of conflicts depends on application-specific behavior (conflictuality), the available data records, and the access behavior (e.g., hot spots) of the mobile end users. Hence, the simulation system must predict the transactional throughput of a designed mobile application based on the modeled application behavior. The simulation system should work on initial artificial data (conforming to the application-specific data model). It should also work on real-world data if the application has already been rolled out. Thus, the simulation system delivers detailed data under which conditions an online- and offline-capable mobile application can be used advantageously, particularly which conflict levels should be selected.
Acceptance:The requirement is fulfilled if the simulation system can deliver de- 10.32
tailed simulation results for any app model that follows the domain-specific model- ing language, i.e., its metamodel.
10.4
Discussion
We have again discussed the requirements of both the first and second parts of this 10.33
thesis in light of (i) completeness, (ii) consistency, (iii) feasibility, and (iv) testability, as presented in the first part of this thesis (cf. Section4.4). We can certify that the overall set of requirements is also consistent without contradictions.
169
Chapter 11
Domain Analysis (Mobile Contexts)
In this chapter, we continue the domain analysis from Chapter5to add context- 11.1related features to the feature model. We use the same sources of knowledge and follow the same methodology as in Chapter5. Hence, we start directly with the feature identification and definition.
11.1
Feature Identification and Definition
We identify additional features inside the feature group data and transaction manage- 11.2
ment and context-awareness.
Data and transaction management:The feature group is extended by hybrid data 11.3
and transaction management. Hybrid data and transaction management requires Replication, Synchronization, and Conflicting and Conflict-free transaction management as possible features.
Context-awareness:The feature group user context-awareness is extended by three 11.4
sub-feature groups – user context-awareness, device context-awareness, and system context-awareness.
User context-awareness: The feature group user context-awareness consists of the 11.5
features user preferences, user role, and user location. According to our approach, the feature role can be subdivided into providing user and end user.
Device context-awareness:The awareness of the device context comprises the device 11.6
type feature group.
Device type:The feature group, device type contains Smartphone, TV stick, Wearable, 11.7
and Tablet as possible devices. Device type features usually require or excludes different hardware features. For example, a TV stick device type has no sensors.
System context-awareness:The feature group, system context-awareness comprises 11.8
the feature group network condition. The feature group network condition can be subdivided in online, offline, and hybrid.
Network connection:The required network connection is strongly related to the 11.9
data and transaction management. Features of this feature group are offline and online.
11.2
Feature Model
The hierarchical feature model shown in Figure11.1extends the feature model from 11.10
the first part of this thesis (cf. Figures5.2and5.3) by additional features of the feature group data and transaction management (Figure11.1b) and additional features of the feature group context-awareness (Figures11.1c,11.1d, and11.1e).
Model- driven Design model Runtime model Abstract Detailed (A) Model- driven features Local Hybrid Data and transaction management Central Replication Synchro- nization Conflict-free Conflicting
(B) Data and transaction management features Context- awareness Device context- aware- ness User context- aware- ness Platform context- aware- ness System context- aware- ness De- vice type User prefer- ences User role User loca- tion Network connec- tion (C) Context features
Tablet Wear-able Smart-phone stickTV eBookreader Device
type
(D) Device type features
Offline Online Both Network Connection (E) Network condition features Graphical User Interface Static Dynamic (F) User interface features
Mandatory Optional Alternative Or
FIGURE11.1: Feature model (Pt. III/III)
11.2.1
Feature Composition Rules
According to the extension of the hierarchical feature model, the feature composition
11.11
rules must also be extended. Figure11.2shows the second part of the feature composition rules.
Figure11.2ashows that the device context-awareness requires a dynamic graphical
11.12
user interface, which in turn requires a runtime model. The user context-awareness feature also requires a runtime model. In turn, the runtime model requires an interpreter application. The platform context-awareness indirectly (through the concrete platform) implies the native application feature. Thus, both native and interpreter application features are required. Hence, the generated mobile applications are hybrid applications because they have native, compiled components as well as runtime components.
Figure11.2bshows the composition rules for the introduced system context-awareness
11.13
feature. There is a strong relationship between the application type feature and the system context-awareness which requires different ways of data and transaction management. For example, a standalone system requires only an offline network connection (and excludes an online network connection) which implies a local data and transaction management. In turn, a transaction system which should be online- and offline-capable (both) requires replication and synchronization as part of a hybrid data and transaction management.
11.2.2
Feature Binding
Considering the feature binding, the introduced context features can be instantiated
11.14
11.2. Feature Model 171 Device context- awareness Dynamic Graphical User Interface User context- awareness Runtime model Design model Model- driven Platform context- awareness Android iOS ... Windows Phone Interpreter application Hybrid application Native application Web-based application Appli- cation archi- tecture Software platform
(A) Composition rules for the feature groups Device context-awareness, User context- awareness, Platform context-awareness, Software platform, Graphical user interface, Model-
driven, and Application architecture
Application type Standalone system Information system Transaction system Communication system Data and transaction management Central Hybrid Local Repli- cation Synchro- nization Online Both Offline System context- awareness Network Connection
(B) Composition rules for the feature groups Application type, Data and transaction management, and System context-awareness
Required Excluded
FIGURE11.2: Feature composition rules (Pt. II/II)
context-awareness feature and the user context feature are additional runtime features because they are not necessarily limited to load-time instantiation. However, a running mobile application will not change the underlying device, since we see no usage scenario for runtime device reconfiguration. According to the system context- awareness feature, a runtime instantiation of this feature is not recommended. In this case, i.e., switching from online- and offline-capable mode to an online-only mode requires that all other clients will do the same because the data objects which are distributed must be completely synchronized.
11.3
Focused Features
The second part of this thesis will focus on all context-aware features. Different user
11.15
roles (e.g., provider and end user) create the configuration of a mobile application concerning functionality, graphical user interfaces, and data. Owing to the lack of knowledge about hardware platforms (e.g., screen size) or device types of the applica- tions’ host device and the targeted user group at design time, the mobile application can be flexibly configured at runtime. Otherwise, a default runtime configuration will be derived from the design model. The generated mobile applications also support the integration of other services (e.g., calling other applications and using web services). Given that such mobile applications should be runtime adaptable in terms of user, device and system contexts, their architecture must support a dynamic instantiation of graphical user interfaces, processes, and architectural components. In order to support different network conditions (as part of the system context) in a dynamic manner, the generated application architecture supports a hybrid data and transaction management. In particular, the application can work offline and online according to potentially changing network connections. The generated mobile applications shall support replication and different modes of synchronization including conflict-free and conflicting integration of locally performed transactions. Table11.1shows which requirement is addressed by which feature.
11.16
TABLE11.1: Mapping of the focused feature groups to the requirements of the MDD framework (Pt. II/II)
Part Require-ment No. Requirement name Feature group/s
II 10.1.1 Support of User Roles (User Context) Context-awareness
(User context)
II 10.1.2 Heterogeneous Device Support (Device
Context)
Context-awareness (Device context), Hardware platform
II 10.1.3 Interoperable, Multi-User Systems
Data and transac- tion management, Application type
II 10.1.4 Online and Offline Capability (System
Context)
Context-awareness (Systems context)
II 10.2.1 Declaration of Online- and Offline-
Capable Data
Context-awareness (Systems context)
II 10.3.1 Provider Model Editor
Context-awareness (User context, Device Context)
II 10.3.2 Simulation System Context-awareness
173
Chapter 12
User Contexts
As shown in the presentation of the requirements Chapter10, an aspect of general 12.1
context support is the support of user contexts. As illustrated in Figure9.1, a mobile application is aware of the user context if it can be adapted to the requirements of different mobile users. More precisely, a mobile application generated once and distributed among several mobile devices should support different kinds of mobile users. This should not be confused with a multi-user system, in which different mobile users act simultaneously or asynchronously on an identical mobile application installation, or with a multi-user capable back-end service. Besides, it should be clarified that the user context should be well differentiated from the context of use, which may apply to a mobile user but generally requires more sophisticated context recognition methods (e.g., motion detection, social context detection, and location-awareness) and complex context-processing mechanisms. A mobile user is usually recognized by her/his credentials (e.g., user name) or other individual properties. Hence, the context-sensing mechanism of a user context is trivial.
Different kinds of mobile users are characterized by user-roles (or groups) that 12.2
vicariously define the privileges of a set of concrete mobile end users. These privileges can reduce the accessibility to data objects, or the number of use cases or processes that are available in an installed mobile application. Hence user context- awareness requires the instantiation of mobile application variants according to the privileges a mobile user, and respectively, the associated user role, enjoys. While the context-sensing mechanism of a user context is trivial, the adaptation of mobile applications according to this user context is generally not. The design of the mobile application must reflect the fact that some of its features must be limited or extended depending on the current user, i.e., its user role.
When using a traditional software development process, the user roles of a mobile 12.3
application must usually be declared at design time. A textual description or a use case diagram might declare/visualize the actors (roles) of a software system and the use cases/processes that are available for a particular actor. Mobile application developers will implement this specification in a static way. It is usually fixed during the life cycle of the mobile application. In contrast to this traditional way of user context support by statically coded role concepts, we will show how the designed model-driven development infrastructure handles user roles dynamically and, thus, supports user context-awareness in a more flexible way. The designed model-driven development infrastructure provides both a design time and runtime approach to support different user contexts:
12.1
Design Time Instantiation
The designed model-driven development infrastructure allows the modeling of 12.4
role-based mobile application variants by modifying the process model. Based on a description of user roles and sets of accessible use cases (processes) for each user role, the mobile application developers can create variants of the process model.
Each supported user role needs a variant of the process model which is built as follows: if the actor has a relation to a use case, the process representing this use case and its occurrence in the process selector tasks will not be changed. If the actor has no (transitive)1relation to a particular use case, the representing process must be removed from all process selector tasks in the process model. The resulting process model manifests the mobile application variant for a particular user role. The resulting mobile application provides only the specified processes, and respectively, the use cases.
Example(Design user context-aware variants of the simple phone book application).
12.5
Suppose a company uses the phone book application as a company phone book. In such a scenario, a phone book manager might administer the records of the company phone book using the management process (CRUD) or the individual processes for creating, reading, updating, or deleting contacts. The employees use the phone book in a limited way. They are only allowed to read the contact records and make calls. This user role cannot make any modifications. Figure12.1shows a use case diagram that models the relation between the different use cases and the actors.
Company phone book Company phone book
≪extend≫ ≪include≫ ≪include≫ Manager Employee Create Person Edit Person Delete Person Call Person Search Person View Person Person location Person with
address Show address on map
FIGURE12.1: Actors and use cases of the company phone book application
Based on this information, the mobile application developer can modify the process
12.6
model (cf. Figure6.8a) according to the given roles. Figure12.2shows the variation of the process model for the given roles. Processes that are no longer registered in the ProcessSelector Task might still remain in the process model.
After the modifications to the process model, the code generator can translate
12.7
1 A use case may relate to other use cases by an <<extend>> or <<include>> relation. Similarly, a process relates to other processes by a sub-process relation.
12.1. Design Time Instantiation 175
(A) Main Process for the user role Manager
(B) Main Process for the user role Employee
FIGURE12.2: Modified process model of the company phone book application (excerpt)
the app models into role-specific mobile application variants. The main entry screens of these variants are shown in Figure 12.3. Besides, the code generator recognizes the changes on the process model and generates an optimized version of the mobile applications, as shown in Table12.1. The optimized variants of the mobile application contain only the program code that is required for the desired user context. This can reduce the program code size of the generated mobile
applications considerably.
(A) Main menu for the user role Manager (B) Main menu for the user role Employee FIGURE12.3: Resulting variants of the company phone book application
TABLE12.1: Number of processes and lines of code (LoC) of the mobile application variants
Mobile application (role variant) Processes2 LoC
Corporate phone book 13 14324
Corporate phone book (Manager) 6 9606
Corporate phone book (Employee) 5 5643
Providing different user contexts by design-time instantiation of processes has
12.8
several advantages. The generated mobile application variants are minimalistic in terms of code size because unused program code will not be generated. This also provides more security since the generated mobile applications are steeled against the malicious activation of use cases that should not be available for a certain user context.
There are also disadvantages of the design-time instantiation method. Every user
12.9
role needs its own model. More importantly, every user role runs on a separate implementation variant of the mobile application. In our case, the company phone book application might have up to 8,192 (213) variants because every subset of the
set of processes (here 13) form a potential variant of the mobile application. Besides, a mobile user cannot easily switch between different user roles because s/he has to install different mobile application variants, one of each of the desired user roles.