OVERVIEW OF A MODEL-TO-CODE TRANSFORMATION APPROACH

FOR GENERATING SERVICE-BASED INTERACTIVE APPLICATIONS

FOR GOOGLE ANDROID
Marius Feldmann, Vladyslav Oleniuk, Larissa Globa, Alexander Schill
Fakultat Informatik, Institut iur Systemarchitektur, Lehrstuhl Rechnernetze
Technische Umversiiet Dresden
Germany
E-mail: marius.feldmann@tu-dresden.de
Abstract - This paper reports on an approach for generating
interactive applications for Google Android within a Model-driven
development chain. The described Model-to-Code transformation
is used within a methodology applying a visual authoring ap-
proach of interactive applications upon Service infrastructures.
The central contribution of this paper is a proof-of-concept that
the Meta-Model developed for this approach to describe complete
Service-based interactive applications and intended to express
models close to the final platforms can be applied to the genera-
tion of fat clients running on mobile devices.
I. Introduction
Service-orientation is a well-established concept for
building applications from reusable functional fragments in
the area of Business-to-Business communication. How-
ever, the creation of interactive applications upon com-
posed Services is still a time-consuming task. For this
reason a unique development approach for a visual com-
position of Services enhanced by reusable parts of User
Interfaces and of interactive applications (Service annota-
tions) is currently worked out. The information fragments
created by the visual authoring tool are transformed au-
tomatically to the source code that can be compiled,
packaged and deployed in a last step. The defined meth-
odology should be used within an end-user development
approach [4]. In order to first bring the model representing
the complete interactive Service-based application closer
to the finally generated result and thus to ease the code
generation, an intermediary Model-to-Model transforma-
tion step is applied. The methodology currently developed
for the creation of the interactive applications can be ap-
plied to the application development for different plat-
forms. Thus the two intermediary models have to be reus-
able for holding all necessary information for different tar-
get platforms. Currently it is evaluated if the Meta-Model
used as a target during the Model-to-Model transformation
fulfills this requirement. In order to prove the applicability
for generating applications for mobile fat client applica-
tions, this paper reports on the Model-to-Code generation
for the Google Android platform. Though Model-driven
development approaches for Android (e.g. [1]) exist, to our
knowledge none of them is embedded into a visual devel-
opment of interactive applications upon Service infrastruc-
tures.
The paper is structured as follows: In section II an
overview of the Meta-Model used to describe source
models for the Model-to-Code mapping is provided in or-
der to give a basic understanding of its structure and con-
tained information fragments. In section III the mapping of
application models to the Google Android platform is de-
scribed. The concrete realization of this mapping is ex-
plained in some more details in section IV. The paper
concludes with a summary and outlook in section V.
II. Overview of Meta-Model
The developed Meta-Model has been designed with
respect to enable the description of models of interactive
applications that
1. are intended for different target platforms
2. differ in the way of application partitioning
3. may be build upon heterogeneous Service tech-
nologies
4. offer dynamic and reactive User Interfaces
5. enable a mapping between different data types
used by the Service infrastructure and the UIs
6. support basic Service composition patterns
Furthermore, the description of models should be
close to the final source code thus avoiding complex
Model-to-Code transformation steps for the intended plat-
forms.
The Meta-Model is structured into three central areas:
The UIManager, the Model-Controll-Adapter (MCA) and
the ServiceManager (depicted in figure 1).
The stateless ServiceManager is responsible for the
Service invocation. It contains one ServiceController that
itself contains the (potentially technological heterogene-
ous) Services used by the interactive application. It holds
a reference to the functional interface description of a
Service and the operation signatures (input/output pa-
rameter names and types) of used Service operations.
The MCA forms the central part of the Meta-Model. It
coordinates the interaction between the User Interface
and the Service infrastructure. Its glue component is the
StateControlier. It contains a set of States and transitions
between them. Every State manages a set of StateMod-
elEntities for storing State-wide data or data shared be-
tween States. The StateModelEntities may be constants
or dynamic values. Both variants have a type definition
associated with them. The type can be specified by just
using a type name (as a string). Furthermore the State
has got a defined behavior. It is expressed by a contained
set of Activities formed by sequences of reusable atomic
Actions with well-defined semantics. An Action may be for
example a transition between states or an interaction with
the UIManager or with the ServiceManager. Every state is
associated with exactly one Page.
UIManager
I I
MeA
Pages
States
I I
Structure
ServiceManager
State Flow
I
Layout
I
I.....
I
Services
I
Model
I I
Model
Behavior
I
Behavior
I
Figure 1. Structural overview
The Page builds the entry point into the UIManager.
This part of the application defines the structure and lay-
out of every Page. Furthermore it assigns a PageModel to
every Page containing several PageModelEntities e.g. to
store the values of UI Interactors. Analogous to the
StateModelEntities the PageModelEntities may be con-
stants or dynamic values.
362
200919th Int. Crimean Conference "Microwave &Telecommunication Technology" (CriMiCo'2009). September, Sevastopol, Crimea, Ukraine
2009: CriMiCo'2009 Organizing Committee; CrSTC. ISBN: IEEE Catalog Number: CFP09788
Figure 3. Structure of generated applications
The overall structure of a generated application is de-
picted in figure 3. Every Activity is executed within an own
thread (of the Google Android operating system). Events
created by the user within the view of this Activity result in
the invocation of methods associated formerly to the
PageCommand triggered by this event. If the Activity as-
sociated with this PageCommand contains a StatelnterAc-
tion, a method conforming to the former StateCommand is
invoked. In the case the StateCommand schedules a Ser-
vicelnterAction, a ServiceCommand is sent to a thread
running in the background. This implies that the Service-
Commands are mapped one to one from the model to
source code. The receiving thread has been generated to
handle the interaction with the Service infrastructure.
Every instantiated ServiceCommand is mapped during
execution of the application to a method call within the
Singleton ServiceManager by an application component
named ServiceCommandResolver. Based on the Service
command name the right method within the ServiceMan-
ager is derived and invoked. The source code embedded
into the abstract parent class of every created Activity
handling this mapping is depicted in figure 4.
The method invoked within the ServiceManager hands
over the control to the stub generated for every Service.
Background
thread
Implementation of
methods for
State Corrmend
Implementation of
methods for
PageCorrmand
Visualization
Activit y
lhread
every PageCommand. Thus the scheduling of a Pageln-
terAction leads to the invocation of a method implement-
ing the actions triggered by the appropriate PageCom-
mand. In the case of a StateTransitionAction (Action lead-
ing to the activation of a new State), the Google Android
Intent mechanism is used in order to navigate to the new
Activity generated from the target state.
For every Activity a model for storing all necessary
model entities is generated. If the Page- and StateMod-
elEntities of the source State and associated Page are
connected with each other via a CommandModelEntity,
they are merged. All constant values are mapped to data
embedded into an XML file created for the apropriate Ac-
tivity within the Android's "res/values" folder. PageMod-
elEntities representing the values of interactors are
mapped to instances of a specifically introduced class that
binds the model entity to the UI element. Further model
entities are mapped to objects storing the value and the
type information. Before a command is sent, its contained
model entities have to be set to the intended values. The
code for this purpose can be derived easily from the in-
stances of the Meta-Model as well.
The User Interface for every generated Activity is in-
ferred from the Page assigned to the appropriate State.
For every Page a file for storing an XML-based UI defini-
tion is created. Every ContentGroup is mapped to an ap-
propriate layout definition (such as LinearLayout) embed-
ded into this file. The PresentationAreaContainers are
transformed into ViewSwitcher objects. Every Interactor
contained in one of these ViewGroups is transformed to
the concrete UI elements specified by the type definition
attribute of the Interactor. If no concrete UI element is
specified, a simple mapping from the types of associated
model entities to default UI elements is applied. Events
associated with the interactors are registered as native
Google Android UI events.
Figure 2. Root classes of the Ecore Meta-Model
The interaction between the ServiceManager, the
MCA and the UIManager is realized by using Commands.
The Commands are named in regards of the receiving
party. Thus PageCommands, StateCommands and Ser-
viceCommands can be instantiated. The PageCommands
and the StateCommands are linked to Activities defined
by the different Pages and States. Thereby the com-
mands trigger their behavior. The Commands themselves
contain CommandModelEntites. In the case of the Page-
Commands and StateCommands these entities are asso-
ciated with model entities contained in the command
source and the command target. By this relation the
model entities located in the Page or the State are associ-
ated with each other.
Every ServiceCommand is mapped to a Service op-
eration. The model entities contained in this command are
associated with parameters of the appropriate Service
operation; the Services' return value is mapped to a Sta-
teCommand.
Commands can be triggered by specific Actions avail-
able within the Activities of the UIManager and State, by
the return of a Service invocation or by events taking
place within the Page.
III. Structure of generated applications
After providing an overview of the Meta-Model and in-
troducing the necessary vocabulary, this section is in-
tended to provide an insight into the relations between
Meta-Model elements and the Google Android platform.
Classes and constructs used by this platform are format-
ted in italic. Definitions of these terms can be found in [2].
The starting point of the platform mapping builds the
generation of an Activity from every State contained in the
source model. Every StateCommand used to access one
of these states is transformed to a method embedded into
the appropriate Activity. The implementation of these me-
thods is formed by the different Actions defined within the
Activity associated with the StateCommand. The same
mechanism of method generation is applied to every
Due to the fact that dynamic and reactive Uls should
be supported, a Page includes a behavior. It is defined
analogously to the behavior of a State.
The structure of a page is defined by a set of View-
Groups which are made up of ContentGroups and Pre-
sentationAreaContainers. A ContentGroup contains a set
of Interactors such as text fields, buttons or lists of items.
An Interactor offers an attribute for specifying its concrete
representation after the Model-to-Code transformation.
The Interactors are connected to model entities located
within the Page. The PresentationAreaContainer is in-
tended to encapsulate content that can be replaced by
other content. By this structural element a partial ex-
change of content within a Page is enabled. Interactors
intended for user input are associated with events.
The root of the Meta-Model is formed by the Applica-
tion (figure 2) class. It aggregates the StateController and
ServiceController. Furthermore it may contain a Lan-
guageKeyValueMap for supporting internationalization
and a set of Properties to describe for example name-
spaces used by the application.
200919th Int. Crimean Conference "Microwave & TelecommunicationTechnology" (CriMiCo'2009). 14-18September, Sevastopol, Crimea, Ukraine
2009: CriMiCo' 2009 Organizing Committee: CrSTC. ISBN: 978-966-335-244-2. IEEE CatalogNumber: CFP09788 363
Figure 4. Service command to method invocation
Figure 5. Role of Command Resolver and Forwarder
The oAW workflow triggers Xpand templates that real-
ize the following six coarse-grained steps:
1. Generation of the
res/value/<stateName>values.xml files for con-
stants within a State and Page aggregated to
one Google Android Activity
2. Generation of the appropriate res/layout/ <page-
Name>.xml files for every page
3. Generating a <application_package>/activities
/<stateName>.java file for every Activity that con-
tains the complete source code for executing the
Activity thus it embeds e.g. the methods imple-
menting the different Page- and StateCom-
mands
4. Generating the ServiceManager file with the differ-
ent method hooks for invoking the Services
5. Generating the data objects for the PageModelEn-
tities and store them in file conforming to the
schema <application_package>/dataobjects
/<entityName>.java
6. Generating the stubs for the Service invocation
The test applications used WSDL described Services
and XML-RPC Services. For the realization of the stub for
accessing the WSDL described Services via SOAP,
kSOAP 2 [7] has been used. For invoking XML-RPC op-
erations the android-xmlrpc library has been utilized.
Our implementation has been applied to several test
scenarios proving that the code generation for the de-
scribed source model can be realized in a straight-forward
manner for the Google Android platform.
V. Summary and Outlook
This paper provided an overview of a code-generation
approach for creating interactive Service-based applica-
tions for the Google Android platform. It has been demon-
strated that the Meta-Model intended to describe models
for various platforms can be applied to the generation of
fat clients. Some of the fundamental concepts used within
the Meta-Model such as the command triggered Service
invocation and the Service return to StateCommand map-
ping have been applied in the resulting application one-by-
one.
Future work will focus on developing further platform
mappings. Currently a Model-to-Code transformation for
the Spring framework is under development. After the
usability of the Meta-Model as a source for the code gen-
eration step for very diverse target platforms has been
proven, the Model-to-Model transformation step men-
tioned in the introduction will be implemented.
VI. References
[1) AndroMate - The Android Modeller and Code generator:
http://www.lab.telin.nl/-msteen/andromate/
[2) Developerresources for Google Android:
http://developer.android.com/
[3) ServFace project website: http://www.servface.eu
[4) Burnett M.:What is End-User Software Engineering and Why
Does It Matter?", IS-EUD 2009, LNCS 5435, 2009 , pp.15-28
[5) openArchitectureWare project website:
http://www.openarchitectureware.org/
[6) ApacheAnt project website: http://anl.apache.org/
[7) kSOAPproject website: http://ksoap2.sourceforge.nell
[8) XMLRPClibrary for the Google Android platform:
http://code.google.com/p/android-xmlrpcl
Acknowledgment
Parts of the results presented in this paper have
been achieved within the FP7 project ServFace [3].
Service
Manager
Corrmand Method
Resolver
State
L- -'
Figure 5 summarizes the role of the Comman-
dResolver used to map commands intended for the Ser-
viceManager to one of its methods and of the Command-
Distributor used to map commands - generated after a
Service invokation returned - to methods within the cur-
rently scheduled Activity.
The described mechanisms show that the command
concept used within the model of the application can be
natively applied to the interaction with the ServiceManager
within the generated application instance. It leads to a
very generic concept of command-to-method mapping
based on reusable code.
IV. Implementation of code generation
The described mapping from a model conforming to
the described Meta-Model to source code fragments has
been implemented by using the openArchitectureWare
(oAW, [5]) generator framework. It requires the definition
of a Workflow file that triggers the different generation
steps. The oAW workflow is triggered by a separate
Apache Ant [6] script. After generating the code it builds
and signs the application package thus preparing it for the
direct deployment. Thus the complete process from Mod-
el-to-Code mapping to the deployment is realized fully
automatically.
The inverse communication back to the UI is done via
a native application of State Commands. The Service-
Manager instantiates a class named StateCommand in
order to reply the return values of a Service invocation to
an Activity. The command is sent to a Singleton named
CommandDistributor. This component holds a reference
to the currently activated Activity and forwards the com-
mand to a component offered within all Activities named
StateCommandHandler. It is intended for invoking the
methods generated from the StateCommand by mapping
the name of the state command to the appropriate method
name. The mechanism of the CommandDistributor implies
that every started Activity has to fetch the instance of this
Singleton and has to register itself as current Activity.
ServiceCommand ServiceCommand =
(ServiceCommand) msg.obj ;
Object[) args =ServiceCommand.getArgumentsO;
String commandName =ServiceCommand.getNameO;
ServiceManager smlnstance =ServiceManager
.qetlnstancet);
Method method =smlnstance.getClassO.getMethod(
"process"+ commandName.substring(O, 1).
touppercaset)- commandName.substring(1) ,
getClassArray(args ;
method.invoke(smlnstance, args);
The stubs are generated from the information fragments
within the ServiceManager. A reference to every stub is
included into the ServiceManager during the code genera-
tion. For invoking the physical Service only the operation
name and the necessary parameters have to be sent by
the ServiceManager to the Service stub.
364
200919th lnt , Crimean Conference "Microwave & TelecommunicationTechnology" (CriMiCo'2009) . 14-18September, Sevastopol, Crimea, Ukraine
2009: CriMiCo'2009 Organizing Committee; CrSTC. ISBN: 978-966-335-244-2. IEEE Catalog Number: CFP09 788