TABLE7.1: Focused features and mobile application features
Feature group ◃ ... ◃ Feature/s Covered by application
Application type ◃ Standalone not covered
Application type ◃ Information system key2guide
Application type ◃ Transaction system key2operate
Software platform ◃ Android key2guide
Software platform ◃ iOS key2guide
Hardware platform ◃ Screen ◃ Resolution not covered
Hardware platform ◃
(Actors/Sensors/Interfaces/Memory)
key2guide, key2operate
Application architecture ◃ Native application key2guide, key2operate Application architecture ◃ Interpreter application key2operate
Application architecture ◃ Hybrid application key2guide
Application development ◃ Model-driven not covered
Model-driven ◃ Design model (Abstract/Detailed) not covered
Model-driven ◃ Runtime model key2operate
Data and transaction management ◃ Local key2guide, key2operate
Data and transaction management ◃ Central key2operate
Graphical User Interface ◃ Dynamic key2operate
Context-awareness ◃ Platform context-awareness not covered
(MPIS). Information can be retrieved in a manner similar to key2guide from a back- end system, but transactions can also be made (e.g., supplies requests). key2operate is a native mobile application that uses industry-typical sensors, i.e., barcode scan- ner. Moreover, local memory is required to store data during offline situations. However, key2operate synchronizes transactions made offline using a centralized backend system. Hence, the data and transaction management are both local and centralized. key2operate is designed as an interpreter, because manufacturing and production processes are company-specific. It applies a runtime model that specifies the behavior of the mobile application and the graphical user interface.
To sum up, the two main contributions of this thesis (cf. Sections1.5.1and1.5.2) 7.30
cover all focused features. The mobile applications generated by the model-driven development preserve the existing features of the prototypes but will additionally cover the features which are not yet covered. At the end of this chapter, we will show which features are covered by the model-driven development infrastructure (cf. Table7.6). The remaining, uncovered features are discussed in the second part of this thesis.
7.2
Forward Engineering of Reference Applications
Forward engineering follows the goal to create a representative reference application 7.31
that, firstly, combines the identified architectural features of the analyzed mobile applications, and secondly, provides native program code of good quality which can be adopted by the code generators.
7.2.1
Front End
At first, forward engineering of the front end delivers a mobile application for 7.32
each of the desired software platforms (Android and iOS). The process of forward engineering was mostly identical for the Android and iOS reference applications, but there were some differences, because some tools were only available for Eclipse
rather than XCode. Forward engineering focuses on the product key2guide, but aspects of key2operate have also been realized.
At the beginning of the forward engineering, the mobile applications use the origi-
7.33
nal back-end system. Thus, the first implementation step was to provide mobile applications that can login to the back end and download the project files and, if applicable, the related media files.
Since key2operate provides a dynamic data model in the opposite direction of the
7.34
static data model of key2guide, forward engineering adopts dynamic modeling. In order to provide a flexible data model, the corresponding classes of a domain model (Ecore model) were already generated in a model-driven way by EMF. The forward engineers for the iOS front-end variant must additionally implement a corresponding code generator that generates data access objects (DAO) because EMF was not able to generate the Objective-C code. Moreover, the iOS application variant uses a lightweight database instead of the file-based XMI serialization used for the Android application variant. These data-oriented parts of the re-engineered reference applications could be reused later while creating the code generators of the model-driven development infrastructure, because they were already developed in a model-driven way.
Due to the requirement of using the original back end, the forward engineers have
7.35
to write parsers that parse the vendor-specific project file obtained by the back end (e.g., the content management system – CMS) and convert them to the internally used data model. This part of the reference applications will not be used later while constructing the code generators. Instead, it enables carrying out a compatibility test of the forward-engineered front-end applications using the already existing back end. The mentioned parts (i.e. the parsers) can be removed when the forward engineering of the back end is completed.
Finally, the forward engineers realize the graphical user interface of the application
7.36
that presents the parsed and converted data. As the mentioned mobile applications provide extensive configuration capabilities of the graphical user interface at run- time, the forward-engineered applications must provide the same configurations. Consequently, the forward engineering of the front end provides an Android and
7.37
an iOS application that reflect several features of key2guide and key2operate. Figure
7.1illustrates the forward-engineered reference applications showing data from an university’s mathematical collection that are created in the existing back-end system as a test project.
7.2.2
Back End
The information provided in the mobile applications (Figure7.1) was obtained
7.38
from the original back-end system. In the original setting, the analyzed mobile applications need such a content management system because it provides the only facility to create application data and configure the mobile applications. Using EMF as the underlying technology in the forward-engineered mobile applications facilitates the creation of standard model editors for all relevant models, as shown in Figure6.10. Henceforth, models can be created and edited locally by rich-client model editors and uploaded directly to the mobile devices. Besides, the mobile applications to be generated will provide CRUD functions, which provide self- service functionality to create and modify runtime models directly on the mobile device. Hence, it is at first appropriate to provide a platform just for runtime model distribution rather than creation and editing. A simple back end was created to cope with this task. Moreover, to provide web-based editing of runtime models, a web-based back-end model editor was developed, similar to the content management system used in key2guide.
7.2. Forward Engineering of Reference Applications 107
(A) Main screen (Android) (B) Object view (Android) (C) eLearning (Android)
(D) Main screen (iOS) (E) Object view (iOS) (F) eLearning (iOS) FIGURE7.1: Forward-engineered mobile application variants (Android/iOS)
7.2.2.1 Simple Back End
The simple back end (called SeVVerl – Serveranwendung zur Verwaltung und 7.39
Verteilung von Laufzeitmodellen; engl. Server application for administration and distribution of runtime models) supports the following features:
• User-roles and groups: the back end implements user management. Different users can be grouped together with their different levels of authorization. Since the back end can administer several runtime models of different types of mobile applications, every user is allocated to a particular application. • Login and logout of users: corresponding to the mobile front ends, the back
end supports the login and logout of mobile devices, i.e., their users.
• Delivery of metadata: following the login, the back end delivers a list of the available runtime models for the particular user. This list of data may vary depending on the user authorization level.
• Download of a selected runtime model: after selecting one runtime model, the mobile application retrieves the runtime model and applicable additional media files, if any.
• Upload of a selected runtime model: users can also upload models to the back end. Here it does not matter whether the runtime model was locally created or downloaded before and modified.
• Deletion of runtime models: users can delete models. This function is only available in the web-based front end of the back end.
• Sharing of runtime models: users can share models. Using this function, the runtime models can be made available to other users or groups.
The simple back end does not provide any editing functionality apart from the
7.40
runtime editing in the mobile applications. Besides, concurrently modified run- time models (e.g., modified by two independently working mobile users) cannot be joined together when both are uploaded. In such cases the simple back end provides two update strategies: (i) the existing runtime model will be overwritten completely by a modified and uploaded runtime model, regardless of the loss of already per- formed modifications of another mobile user; (ii) Modified and uploaded runtime models are stored separately with a new revision number. However, modifications of other users cannot be integrated into this model.
7.2.2.2 Web-Based Back-End Model Editor
The web-based back-end model editor (PIMARWebEdit) was developed to provide
7.41
a platform-independent model editor for provider models (cf. Section6.1). This application adopts most of the features of the simple back end, but extends the functionality considerably in terms of model-editing. Figure7.2shows the design of the editor’s graphical user interface.
FIGURE7.2: Web-based model editor for runtime models (editing a GUI model)
Similar to the simple back end, the web-based back-end model editor provides no
7.42
features for collaboration in terms of joining the modified models. As shown later, different frameworks such as CDO [59], Teneo/Hibernate [71] [LM10] or EMFStore [KH10] [64] can be used to provide concurrent access to the runtime models.
7.2.3
Evaluation of the Forward Engineered Reference Applications
To argue that the forward-engineered reference applications are representative, two
7.43
goals must be pursued:
The first goal concerns the functionality of the reference applications. The forward-
7.44
7.3. Construction of Code Generators 109