Model-Driven Design for the Development of Multi ... - IEEE Xplore

Model-Driven Design for the Development of Multi-Platform Smartphone Applications G. Botturi, E. Ebeid, F. Fummi, D. Quaglia Dep. of Computer Science — University of Verona, Italy

[giulio.botturi|emad.ebeid|franco.fummi|davide.quaglia]@univr.it Abstract—To ensure revenues, developers of smartphone applications should support all the main leading platforms which share the market thus increasing time-to-market and development cost. To solve this problem, the paper proposes a Model-Driven Design flow to develop a single version of the application that can be automatically translated into the main platform-dependent versions. The approach is based on code generation so that no additional library or process is needed on the smartphone to support different platforms. We introduce a UML2 profile to represent the elements of the application independently of the target platform; the behavior of the application is modeled as a finite-state machine while the graphical user interface is modeled by using classes and objects. A set of translation rules is defined to obtain a platform-dependent representation and then the actual code. The methodology has been validated by creating an application for both the Android and Windows Phone platform and by comparing the obtained code to the corresponding versions written in the traditional way. Keywords—UML, PIM, PSM, Statechart, Android, Windows Phone

I.

I NTRODUCTION

Technological revolution specifically in telecommunication has created a large market for mobile phones and everyday hundreds of different applications are developed for smartphones due to their diverse uses. A smartphone is built on a mobile computing platform, with more advanced computing capability and connectivity than a feature phone [1]. Development of smartphone applications is the process by which software is developed for resource-constrained devices and it is executed over a specific operating system like Android, Windows Mobile, iPhone iOS, and Nokia Symbian. Moreover, each platform uses a different programming language, such as Java [2] for Android or Objective-C [3] for iPhone, and has a slightly different development process. Therefore, the main limitation in smartphone application development is that the application provided for a platform cannot be executed on the other ones and the developer should provide a version for each leading platform thus increasing time-to-market and cost. To solve this problem, in [1], the authors present a comprehensive middleware architecture for mobile application to support interoperability and portability of mobile applications. The middleware is a software layer between the operating system and the user application. At run-time, the middleware translates platform-independent application operations into the platform-specific counterparts;

Fig. 1.

Traditional software development flow.

the drawback of this solution is the consumption of device resources (e.g., CPU time, memory and thus energy from the battery) for the run-time middleware environment. Other works [4]–[7] propose to use a library (there is a specific version of the library for each platform) which provides a standard interface to application developers. Again, additional device resources are used at run-time to translate application calls into native calls. Finally, [8], [9] propose to develop the mobile application as a web application which is portable across all browser-enabled platforms. The main drawback regards the impossibility to access directly to hardware features of the mobile device and the difficulty to achieve user-interface effects not usually present in web pages. Model-Driven Design [10] and Platform-Independent Models (PIM) [11] offer a reasonable solution to model the application independently of the target device and automating the porting to different platforms. The contribution of this work is a Model-Driven Design methodology to develop smartphone applications independently of a specific platform. Starting from the analysis of the main smartphone platforms, we introduce a UML2 profile to represent the elements of the application independently of the target platform; the behavior of the application is modeled as a finite-state machine while the graphical user interface is modeled by using classes and objects. Then, a set of translation

rules is defined to obtain the platform-dependent representation and then the actual code for two different platforms. This paper is organized as follows. Section II describes the traditional application development process for the most common smartphone platforms. Section III presents the proposed methodology to develop multi-platform applications. Section IV describes the proposed UML2 profile for the PIM. Section V shows the transformation rules for Android and WindowsPhone. Section VI presents the experimental validation on a real-life application. Finally, conclusions are drawn in Section VII. II.

T RADITIONAL DEVELOPMENT

If smartphone application developers want to reach a wide audience, they have to support the most popular operating systems for smartphones on the market, such as Google’s Android, Apple’s iOS, Nokia’s Symbian, Microsoft’s Windows Phone and so on. The traditional development flow is illustrated in Figure 1. The first phase is focused on requirements and thus it is platform-independent, while coding, testing and deploying strictly depend on the specific HW/SW platform thus leading to different flow branches. Considering that a significant amount of time is spent in this second phase, the support for different platforms severely affects time-to-market and cost. A smartphone application consists of structural aspects (e.g., interconnection between modules and libraries as well as structure of the Graphical User Interface - GUI) and behavioral aspects (e.g., reaction to events and applicationspecific computations). In the following text we highlight similarities and differences among various platforms as the basis of the proposed UML2 profile and design methodology. A. Android platform Android1 is a Linux-based operating system for mobile devices such as smartphones and tablet computers, and it is developed by the Open Handset Alliance2 led by Google. Android software platform consists of a Linux-based kernel, a middleware for communication and some key applications such as the web browser and the file manager. Developers can freely download the software development kit (SDK), that includes compiler, debugger and the Eclipse plugin to work more efficiently in the Integrated Development Environment. The SDK also provides a software emulator for ARM-based mobile devices. Alternatively, applications can run directly on the physical device connected to the developer’s machine via USB cable. Concerning behavioral aspects, the coding language is Java, with a specific class library that binds to some system components (communication middleware, device camera, audio, sensors, etc.). Android uses the Dalvik Virtual Machine with just-in-time compilation to run Dalvik dex-code (Dalvik Executable), which is usually translated from Java bytecode. Each 1 http://www.android.com 2 http://www.openhandsetalliance.com/

Fig. 2.

The Android Activity life cycle.

application is hosted by a different Dalvik Virtual Machine to protect the system from malicious code. A good starting point to the study of this platform is [12]. The main component of an Android application is the Activity, which represents a single screen with a user interface. An activity can exist in essentially three states: •

Resumed - The activity is in the foreground of the display and it has the user’s focus.

•

Paused - Another activity is in the foreground and has the focus, but this one is still in execution.

•

Stopped - The activity is completely replaced by another activity

The complete activity life cycle schema is depicted in Figure 2. If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. Concerning structural aspects, the application consists of a set of classes while the GUI is described in XML resource files with a custom format. The Android SDK tools compile the code, along with any data and resource files, into a package, i.e., an archive file with the .apk suffix.

B. Windows Phone platform In 2010 Microsoft presented Windows Phone 7 (WP7) specifically created for touchscreen devices. Microsoft, like Google, provides a Software Development Kit to allow developers to design, compile, debug and deploy applications. The SDK comes with the Windows Phone Emulator, a desktop application that emulates a Windows Phone device. The emulator provides a virtualized environment in which applications can be debugged and tested without the physical device. Concerning behavioral aspects, Windows Phone application code is based on the .Net Framework and C#. The main component of a WP7 application is the Page, which represents a single screen with a user interface. The page’s life cycle is similar to the one shown in Figure 2. Concerning structural aspects, the GUI is described through an XML-based language named Extensible Application Markup Language (XAML). The GUI relies on a library named Silverlight, that provides a retained mode3 graphics system similar to Windows Presentation Foundation4 (used for desktop GUI), and integrates multimedia, graphics, animations and interactivity into a single runtime environment. In Silverlight applications for Windows Phone, user interface is declared in XAML and programmed by using a subset of the .NET Framework. Resource table is quite different from Android, and it includes only images, strings or generic files embedded in the application package. C. iPhone platform iOS (iPhone OS prior to June 2010) is the Apple’s mobile operating system which run on Apple hardware only. Also for this platform, a Software Development Kit is provided and it runs only on Mac iOS operating system. Applications are written by using an object-oriented language named Objective C. The GUI layout is described separately, according to the schema seen for Android and Windows Phone. D. Platform comparison For each platform, application development covers structural and behavioral aspects of the application. Regarding the behavior, user interaction is quite similar. Because of the limited size of the screen, the GUI is organized as a sequence of pages; each page contains graphical elements to display information or to receive user actions (e.g., buttons, check boxes, and lists); actions can have an effect either on the same page or lead to page replacement; a pre-defined button is used to go to the previous page. Actions on GUI elements are expressed through different programming languages such as Java for Android, C# for WP7 and Objective-C for iPhone. Regarding the structure, for all the platforms, application code is organized as a set of classes while GUI elements 3 Retained

mode rendering is a style for application programming interfaces of graphics libraries, in which the libraries retain a complete model of the objects to be rendered 4 http://msdn.microsoft.com/en-us/library/aa970268.aspx

Fig. 3.

Block diagram of the proposed design methodology.

are described by XML files whose format is different among platforms. This analysis suggests a Model-Driven Design approach where a platform-independent meta-model can be used to design: •

the GUI as a set of pages containing graphical elements of the application

•

the evolution of the application in term of page replacement

Then generation rules are needed to address platform differences, i.e., code language and XML format. This approach is explained in the next section. Pages are named screens in the following text to distinguish them from their platformdependent counterparts. III.

P ROPOSED METHODOLOGY

Figure 3 shows the proposed methodology to apply the Model-Driven Design approach to the development of smartphone applications. The flow starts by specifying, in a platform-independent way, both the structural aspects of the application, i.e., GUI and classes that implement the application logic, and the behavioral aspects, namely the management of transitions between the screens in response to user interactions and system events. Such elements represent the Platform-Independent Model (PIM). Transformation rules allow moving from the PIM to the Platform-Specific Model (PSM) which is different for each smartphone platform even if for all of them there is a separation from code structure and behavior, from one side, and GUI layout from the other side. Transformation rules are formalized so that a conversion tool can implement them. Finally, this tool must be able to generate the application code (classes, method signatures and some blocks of code), thus avoiding to write repetitive code. The flow takes into account extensibility since the elements in the second and third levels can be integrated with external code and models. In the second level (i.e., PSM) external libraries can be added to the set of classes, composing the

structure of the application as well as XML GUI resources can be added to the GUI layout. In the third level, external code can be added to reuse past work or to introduce complex behavior through low-level code. The proposed flow refers to the development of the most common type of smartphone applications consisting of a number of screens, composed by a set of widgets, with which users can interact in order to perform different tasks. The approach can be easily extended to tablet applications. Other applications that require advanced graphics or customized widgets, like games, are not covered in this discussion because of their specific nature. IV.

P LATFORM I NDEPENDENT M ODEL

The first step is to define the meta-model to describe the PIM. We decided to adopt the whole UML meta-model [13] and specify a Profile Diagram to provide classes, interfaces and other artifacts. This choice was made necessary because PIM is not just a representation of the structure of the application, but also a basic model that developers can integrate with other classes or methods, like in a typical UML design. The UML Profile for Platform Independent Model provides the following elements: •

A list of Widget Classes, each of which represents a particular widget that can be found in every smartphone platform. All these classes extends an abstract class Widget, that has a set of attribute that describe the position on the screen. Developers can specialize widget classes to design custom widgets.

•

A class Screen, that represents a single screen of the GUI

•

Menu and Submenu classes. Menu, indeed, are not considered widgets because they cannot be placed freely in the screen, but typically they are managed directly by the system.

•

A stereotype ScreenTransition applicable to the element Transition of the UML meta-model in the Statechart Diagram.

•

A list of Enumerations that represent user-defined data types. They are useful for those attributes that are bound to particular and significant values.

Fig. 4.

(title, permissions, and version) and the abstract device. For each screen, a class that extends the abstract class Screen, must be added to the model. The following attributes define an application screen: •

widgets collects all the widgets that make up the GUI

•

orientation specifies screen orientation (landscape or portrait)

•

fullScreen specifies whether the screen should cover the system menu and the entire display

•

layout specifies the layout of the widgets on the screen. A Linear layout places each widget in a new line while Relative layout places widgets relative to the others that are around.

•

menu links the current screen to an instance of the Menu class that represents a menu and its submenu.

Figure 4 depicts the entire proposed UML Profile. The next sections discuss the use of two UML diagrams, each of which constitutes a fundamental element in the model to represent structural and behavioral aspects of the application, respectively. A. Class Diagram The Class Diagram defines the structure of the smartphone application. A number of classes represents the basic elements of Graphical User Interface, such as screens, widgets and menu. Other classes collect information about application

UML Profile for the Platform Independent Model.

The class Application collects, in addition to general information, the list of resources that the application needs to access. Device resources are quite standard on each platform, and refer to: •

Personal Information Manager - information like messages, personal contacts, calendar and so on

originator widget), an eventual transition-enabling condition (label 2) and an action (label 3). V.

P LATFORM S PECIFIC M ODELS

Model transformations represent the core of Model-Driven Design. A transformation consists of a set of rules that maps a source element on to the specific one (or more than one) of the target model, and should meet the three principles: tractability, incremental consistency and bidirectionality. The main purpose of the next sections is the definition of the set of rules that carry out the transformations, to allow their implementation in a conversion tool. Fig. 5. Example of statechart diagram representing the behavior of threescreens application.

•

Network communication - the protocol stacks, such as IP or Bluetooth

•

Device Camera - the integrated camera that allows the user to take photos and record video

•

ExternalStorage - additional memory cards to expand device storage capacity

•

Phone - outgoing and incoming phone calls

To make the rules more accurate, concise and understandable, we introduce the following sets, definitions and notations: •

Generalization association from class A to class B is an UML association that links the specific class A to the generic class B. Namely, B generalizes the class A and A specializes the class B.

•

Interface creation of interface I by class C is an UML specialized type of implementation relationship between a classifier and a provided interface.

•

Instance specification I of a class C, is an element that represents an instance of the class C from the Class Diagram. Instance specification uses slots to show the attributes of the object. Each slot corresponds to a single attribute or feature, and may include a value for that entity.

•

Dependency relationship from an Instance specification I1 to another Instance specification I2 is called, in UML, supplier-client relationship, where supplier provides something to the client, and thus the client is in some sense incomplete because it is semantically or structurally dependent on the supplier element.

•

W IDGET S = {w|w is a widget class of PIM }. The set collects all widget classes of the PIM.

•

Dot notation X.attr is used to refer to an instance specification slot, a class attribute or a XML tag attribute.

B. Statechart Diagram Once defined the structure of the application, we need to describe its behavior. In smartphone applications, the behavior is mainly represented by the user interactions with the GUI and the reaction to events coming from sensors (e.g., the compass). Common smartphone applications consist of a collection of screens and the user goes from one to another by using GUI controls. The transition between two screens can happen because of the following events: 1) 2)

3) 4)

A Click or Touch event raised by a widget. The user interacts with a widget on the current screen. Each widget can react to the user’s “touch” action The user presses a special device button, like “Home” or “Back” button. Almost all smartphone platforms have two special buttons: Home to put the application in background and to show the main system screen, and Back to return to the previous screen. iPhone is a special case, since it has only one button since the Back button is usually implemented in the GUI. A Click or Touch event raised by a submenu of a screen menu. Invocation of a particular class method (callback) that explicitly performs the transition as a reaction on system events (e.g., low battery alert or incoming call alert).

This typical behavior suggests using statecharts to represent the evolution of the application in a platform-independent way. Figure 5 shows an example of behavior of an application consisting of three screens. Each transition reports an event (e.g., label 1 denotes an event that has the name of the

The rules work on UML meta-model elements (Generalization association, Interface creation, Instance specification, Dependency relationship and so on); they use constructs such as For each or Exists and tables mapping PIM elements on to PSM elements. A. Statechart Diagram Transformation The following transformation rules are common in Android and WindowsPhone platforms: •

Copy all states, transitions and the initial pseudo-state in the new PSM Statechart Diagram.

•

For each Transition from state Q1 to state Q2 , on which the ScreenTransition stereotype is applied, apply the ActivityTransition stereotype to the Transition counterpart element in the PSM Statechart Diagram.

•

Map the content of the tagged values in the source Stereotype to the corresponding tagged values in target Stereotype of type String.

B. PIM to Android-PSM Transformation The next subsections describe briefly the rules implementing the transformation from PIM to Android Platform Specific Model and the complete description of the transformation rules is reported in a technical report [14]. Rules 1-7, reported in Section V-B1, perform the transformation of the Class Diagram, and generate the new Class Diagram, the Android Manifest file and the resources file String.xml. This mapping is necessary because in PIM the tagged values of stereotype ScreenTransition refer to Instance specification elements, no longer present in the PSM, because the Object Diagram has been transformed into XML Layout files. Regarding to the adaptation of the layout to different screen resolutions, Android transparently handles any scaling of the DP units, as necessary, based on the actual density of the screen in use. In this way, it ensures proper display of the GUI on screens with different densities. For this reason, the coordinates of the widget can be copied from PIM to AndroidPSM, without any conversion. 1) Structure Transformation: 1) 2) 3) 4) 5)

6) 7)

Initialization: Create a new Class Diagram and apply to it the Android-PSM UML Profile. ProfileClass Mapping : This rule maps a PIM class onto the Android-specific one. ResourcePermissions Mapping : This rule maps a PIM resource permission onto the Android-specific one. Structure Mapping : Add the classes PhoneApplicationPage, ContentControl to the Class Diagram. Interfaces Implementation: For each Instance specification I of class W , where W = Listbox, if exists a Dependency relationship from instance specification S to instance specification I, where S is an instance of a class P specializing Screen, then link the class P , by Interface creation relationship, to the interface OnItemClickListener. Resources File : Create the String.xml file, that will contain the string-resources of the application. Manifest File : Let I the Instance specification of the class Application in the PIM Object Diagram.

XML files, Java/C# files). The problem is how to (and where) obtain the information needed to generate a particular target element. For the same reason, also the order of the rules within a transformation (Structure Transformation, GUI Layout Transformation and so on) can change. For instance, Interface creation rule (Android platform) creates an interface implementation relationship in PSM, from some classes to the OnItemClickListener interface. This rule is not needed in WindowsPhone platform because the event handling is managed by the XAML description. D. Code generation The final step of the Model-Driven Design is the generation of the application code from each Platform Specific Model. The generated code covers both structural and behavioral aspects. The structural code concerns the structure of class files, i.e., constructors, interface implementations and methods signature and it can be performed by almost all UML modeling tools (e.g., IBM Rational [15], Artisan Studio [16], etc.). The behavioral code implements the initialization of the GUI and statechart transitions, which are related to interaction of the user with the GUI (e.g., Back button action). Therefore, the code generation procedure is based on informations coming from the PSM Class Diagram and from the UML Statechart Diagram for the behavioral aspects and it can be provided by some UML modeling tools (e.g., Matlab-Stateflow [17], Sparx [18], IBM Rational). VI.

E XPERIMENTAL VALIDATION

This section presents the Platform Independent Model of a sample application. The transformation and code-generation rules will be applied, to compare the resulting application structure with a version of the same application, previously developed for both Android and Windows Phone platform. Due to the limitations of the number of paper pages, the implementation details are reported in Chapter 6 of the technical report [14]. The sample application, named MapNavigator, aims at supporting the visit of museums. It reads QRCode labels through the smartphone-integrated camera, put them in relationship with tags on a pre-loaded digital map and retrieves the corresponding information. The application is structured according to the main activities that the user can perform, as follows: •

choose a map, from the internal or external storage memory (screen ChooseMap)

Structural transformation rules are similar to Android’s ones which are explained in Section V-B1.

•

browse the map and its points of interest (screen NavigateMap)

In general, the number of transformation rules can be different for each platform even if the elements to transform are the same. Depending on the target platform, subsets of the source elements (in this case, structural element) can be transformed by a single rule or by two or more rules, due to the different structure of the target description (e.g.,

•

acquire a QRCode with the integrated camera (screen AcquireQRCode)

•

browse the points of interest list (screen TagList)

•

read the information about a single point of interest (screen TagInfo)

C. PIM to WindowsPhone-PSM Transformation

•

edit some basic preferences about the application (screen Preferences)

The Class Diagram in Figure 6 shows the seven classes, one for each Screen of the application, specializing the class Screen.

Fig. 8.

Fig. 6.

PIM Class Diagram for the sample application.

In the following, the transformation of the PIM into Android-PSM is presented.

Resource file for the Android version of sample application.

and, on the right, the manually written code. The Welcome screen presents a list of icons and the user can touch an icon to perform the corresponding task. The manually developed application adopts the Android widget named ImageButton, i.e., a touchable image, that is not supported by the presented PIM. Therefore, during PIM to Android PSM translation, the widgets named ImageView and Button are used.

Regarding Rule 4 (Structure Mapping), Figure 7 shows the generated class diagram for Android with the seven classes that specialize the Activity class and the interfaces implemented by some of them.

Fig. 9. Comparison of GUI layout code: (a) automatically generated, (b) manually written.

Regarding the generation of the application code, in Appendix C of [14] the following code blocks are reported:

Fig. 7.

Class Diagram for the Android version of sample application.

Regarding Rule 6 (Resource File), Figure 8 shows the generated file containing the widget description for the Android platform. With respect to manually written code, the only difference is the standardized format of the entries ([activityName]_[widgetName]_text). Regarding GUI Layout, the parallel listings in Figure 9 show part of the description of the Welcome screen; on the left, the XML code obtained by the transformation rules

•

Code Block C.1. Android resource file R.java is the file that collects all the resources of the application (widgets, layouts, menu, strings and images) and assigns them a numeric constant. This file is substantially the same as the manually generated, except for the values of the assigned constants.

•

Code Block C.2. The auto-generated Java file of the Welcome activity can be compared with Code Block C.3, which reports the manually written version. The main difference is the number of methods and variables added to the class. In fact, to handles the touch event of the widgets, the code-generation rules create, for each widget composing the Activity and that may trigger the event, a private method with the suffix Click. The invocation of the correct method is handled by the switch statement in the private method onClick(). Furthermore, for each widget composing the Activity, the rules add a private variable to the class. This variable serves as a pointer to the

widget and it is initialized even if it is not necessary and it will never used. The manually developed file is more compact, because uses a smaller number of variables and handles the touch events directly in the private method onClick(). •

Code Block C.4. The auto-generated Java file of the TagList activity can be compared with Code Block C.5, which reports the manually written version. In this file we analyze the generated code in the presence of the ListBox widget. The code-generation rules add, for each ListBox widget composing the Activity, the private method with suffix ItemClick to the class. The switch statement, in the private method onItemClick, allows to invoke the correct method handler for the widget that has trigged the onItemClick event. This is necessary because, implementing the interface OnItemClickListener, only one main onItemClick event handler can be used. In the manually written file, whenever there is only one Listbox widget, the additional method ItemClick may be omitted.

The examined code blocks cover the most interesting cases. In all other cases, the automatically generated code conforms to what should be developed manually. Finally, the Code Block C.6 shows the auto-generated code of the NavigateMap activity. This activity implements a Menu and the redirection of the Back Button to the Welcome screen.

[2]

[3]

[4] [5] [6] [7] [8]

[9] [10]

[11]

[12] [13]

[14]

[15]

VII.

C ONCLUSIONS

We presented a Model-Driven Design approach to the design of multi-platform smartphone applications. The approach is based on code generation so that no additional library or process is needed on the smartphone to support different platforms. To achieve this goal, we analyzed the major smartphone platforms on the market and their software development environments. The analysis has led to highlight the common aspects between different platforms and different development approaches. A UML2 Profile has been proposed for the platform-independent specification. It contains elements to create Class and Statechart Diagrams to describe the GUI Layout of the screens that compose the application and the transitions between them. Then two Platform-Specific Models have been described for both Android and Windows Phone platforms, together with a set of detailed model transformation rules. The methodology has been validated by creating an application for the two platforms and by comparing the obtained code to the corresponding versions written in the traditional way. Future work will also consider other GUIenabled embedded systems (e.g., tablets and industrial control panels) so that they can benefit from this resource-saving approach. R EFERENCES [1]

S. Cha, J. Kurz, and W. Du, “Toward a Unified Framework for Mobile Applications,” in Seventh Annual Communication Networks and Services Research Conference, May 2009, pp. 209 –216.

[16] [17] [18]

Y.-H. Lee, P. Chandrian, and B. Li, “Efficient Java Native Interface for Android Based Mobile Devices,” in IEEE 10th International Conference on Security and Privacy in Computing and Communications (TrustCom), Nov. 2011, pp. 1202 –1209. R. Rawlings, “Objective-C: an object-oriented language for pragmatists,” in IEE Colloquium on Applications of Object-Oriented Programming, Nov. 1989, pp. 2/1 –2/3. “App development made easy,” URL: http://www.mosync.com/. “Widgetpad,” URL: http://newcritics.com/blog1/categories/widgetpad/. “Rhodes,” URL: http://www.motorolasolutions.com/USEN/RhoMobile+Suite/Rhodes. “Appcelerator Platform,” URL: http://www.appcelerator.com/. J. Klein, “Building Enhanced HTML Help with DHTML CSS [Book Review],” IEEE Transactions on Professional Communication, vol. 46, no. 1, pp. 68 – 69, Mar. 2003. “PhoneGap - Easily create apps using the web technologies you know and love: HTML, CSS, and JavaScript,” URL: http://phonegap.com/. M. Streit, H. Schulz, A. Lex, D. Schmalstieg, and H. Schumann, “Model-Driven Design for the Visual Analysis of Heterogeneous Data,” IEEE Transactions on Visualization and Computer Graphics, vol. 18, no. 6, pp. 998 –1010, Jun. 2012. V. C. Nguyen and X. Qafmolla, “Agile Development of Platform Independent Model in Model Driven Architecture,” in Third International Conference on Information and Computing (ICIC), vol. 2, Jun. 2010, pp. 344 –347. J. DiMarzio, “Android - A Programmer’s Guide,” McGraw-Hill, 2008. “Catalog of OMG Modeling and Metadata Specifications,” 2011, URL: http://www.omg.org/technology/documents/ modeling spec catalog.htm. G. Botturi and D. Quaglia, “Multi-Platform Design of Smartphone Applications,” 2012, URL: http://www.di.univr.it/?ent=pubbdip&id=441737. “IBM Rational Software,” URL: http://www01.ibm.com/software/rational/uml. “Artisan Studio - Atego,” URL: http://www.atego.com/products/artisanstudio. “State Chart Stateflow Simulink,” URL: http://www.mathworks.com/products/stateflow. “Enterprise Architect,” URL: http://www.sparxsystems.com.au/.