Generating Phone Applications fromModels

Ersel Aker

School of Computer Science

University of Manchester

Supervised by Dr. Andy Carpenter

This dissertation is submitted for the degree of

Bachelor of Science

April 2015

Abstract

This project involves using Model Driven Software Development to generate Android appli-cations. Work undertaken allows users to define their desired application via models. Theend-product, a mobile phone application with CRUD capabilities supported by persistentstorage is generated from the user defined models.

This report starts with defining the aims and objectives of the project, in the introduc-tion chapter an overview of the mobile software industry is given along with the currentsoftware development approaches and ecosystem. Model Driven Software Development andModel Driven Architecture are explained. Development effort and technologies are discussedin detail in the implementation chapter. The end-product of the project and the artefactsproduced are evaluated by explaining how the software was validated and tested.

Finally, report concludes by reflecting on the outcome of the project and also listing consider-ations for future development.

Acknowledgements

I take this opportunity to express gratitude to my loving family for their support and encour-agement throughout my studies, without whom none of this would have been possible.

Table of contents

List of figures ix

1 Introduction 11.1 Aim and Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Current Software Development Ecosystem . . . . . . . . . . . . . . . . . . 21.3 What is Model Driven Software Development? . . . . . . . . . . . . . . . 3

1.3.1 Model Driven Software Development . . . . . . . . . . . . . . . . 31.3.2 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.1 Walking Skeleton Practice . . . . . . . . . . . . . . . . . . . . . . 51.4.2 Benefits of Applying Walking Skeleton Practice . . . . . . . . . . . 5

2 Technology and Implementation 72.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Eclipse Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Eclipse Modelling Framework . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 The Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 The Meta-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 The Meta-meta Model . . . . . . . . . . . . . . . . . . . . . . . . 102.3.4 Domain Specific Languages . . . . . . . . . . . . . . . . . . . . . 102.3.5 The Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.6 A Meta-Model for Mobile Applications Domain . . . . . . . . . . 122.3.7 Generating Modelling Plugins Using EMF . . . . . . . . . . . . . 122.3.8 Eclipse Runtime for Modelling and Code Generation . . . . . . . . 142.3.9 Sample Mobile Application Models . . . . . . . . . . . . . . . . . 15

2.4 Code Generation for Android Platform . . . . . . . . . . . . . . . . . . . . 16

viii Table of contents

2.4.1 Model to Text Languages . . . . . . . . . . . . . . . . . . . . . . . 162.4.2 Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 Data Persistency . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.4 Android Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Evaluation 253.1 Validation of Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Achievements and Conclusion 294.1 Knowledge Gained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Difficulties Encountered . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

References 33

List of figures

2.1 Tools and Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Ecore Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Ecore meta-models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Ecore in XMI format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Ecore meta-model for mobile applications . . . . . . . . . . . . . . . . . . 132.6 Generating Eclipse Modelling Plugins . . . . . . . . . . . . . . . . . . . . 142.7 Eclipse Runtime for Modelling and Code Generation . . . . . . . . . . . . 152.8 Model of a contact list application . . . . . . . . . . . . . . . . . . . . . . 162.9 Model of a league table application . . . . . . . . . . . . . . . . . . . . . . 172.10 Acceleo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Acceleo workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.12 SQLite Database Adapter Template . . . . . . . . . . . . . . . . . . . . . 212.13 List View Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.14 Strings.xml Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.15 List Layout Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.16 AndroidManifest.xml Template . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Model validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Model validation info window . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 List View of a generated application . . . . . . . . . . . . . . . . . . . . . 314.2 Edit View of a generated application . . . . . . . . . . . . . . . . . . . . . 32

Chapter 1

Introduction

1.1 Aim and Vision

1.1.1 Aim

The aim of the project is to use model driven software development methodology to generatemobile applications which can perform create, update and delete operations with use of apersistent data store. Google’s Android platform was selected as the target platform for thisproject. Applications generated are Java programs using the Android SDK which can run onmobile devices with Android operating system. Eclipse Foundation provides a modellingframework which can work with the Java language. As Android applications are developedusing the Java language as well, Android platform and Eclipse Modelling Project proved tobe a viable set of tools for this project.

1.1.2 Vision

The vision is to produce a model driven software project, so that users can define theirdesired mobile applications with the help of models. User defined application models thenwill be turned into android source code automatically. End-product of user’s modellingeffort will be a program ready to run on Android devices. This will allow people withnon-technical backgrounds to be able to design mobile applications with ease. On the otherhand, developers will be able to apply further optimization if they want to as they will haveaccess to the Android source code for the generated application.

2 Introduction

1.2 Current Software Development Ecosystem

Over the past three decades, the number of mobile devices have been increasing significantly.Advancements in the fields of electronics and computers have made mobile devices smaller,smarter, more interconnected and accessible. In 2014, the number of mobile devices hassurpassed the human population on the globe, reaching a tremendous amount of 7.22 billiondevices [16] .

With respect to these developments, mobile application industry has been growing in parallel.US based IT research company Gartner, expects the number of mobile application downloadsto reach 268 billion by 2017 [13]. As the data shows, there is a growing mobile applicationsmarket, hence an increasing demand for mobile software development.

Software development comes at a cost, it is a complex process prone to human error andmisjudgment. The success of a software development process depends on many factorsranging from organisational structure, managerial style, technical acumen, number of per-sonnel, personnel capabilities to application complexity and so on. A research conducted byIrish Software Engineering Research Centre states that there are more than 44 situationalfactors affecting the software development process which can be further expanded into 170sub-factors. In order to tackle these factors and minimize their impact on the developmentprocess, various tools and methodologies were developed over the last four decades [5].

In terms of tools, higher level programming languages were developed to allow the de-velopers to focus on providing solutions to business problems rather than dealing with lowerlevel technical aspects like memory management [31]. Specialized software suites called Inte-grated Development Environments (IDE) were also developed. IDEs make use of windowedgraphical user interfaces and provide a dashboard which contains various tools to developsoftware. IDEs help developers to write code, debug their programs and also to organizetheir repositories [25]. Software source code consists of many lines of code segregated ina number of files. Version control systems were developed to keep track of changes madeto various files during the development process. These systems let developers to revert thesoftware to an earlier point in its development life-time. They also help detect conflictingchanges made to the same part of the software, so these can be resolved without breakingthe intended functionality [14]. Furthermore, to ease the process of building and deployingsoftware, automated build tools were introduced. These tools can build the software, run teststo validate its functionality and then deploy the software to designated sources. Repetitiveand time-consuming tasks can be automated by utilizing various development tools, which in

1.3 What is Model Driven Software Development? 3

turn increases the productivity of developers and reduces the overall development effort [29].

On the other hand, many different approaches to organising the software developmentprocess were introduced and tried throughout the last four decades. Starting with its inceptionin 1970s, Winston Royce’s waterfall development methodology was the dominant approachadopted by the industry until agile methods were introduced [4]. Royce’s waterfall approachfollows a sequential process where requirements are captured, architecture designed, im-plemented, verified and finally maintenance carried out until software becomes obsolete.Waterfall model assumes software can be developed in one-go within well-defined phases,which paved the way for it, to be criticised for being too strict and procedural. It was not until2001 that agile manifesto was published to highlight the impromptu and dynamic aspectsof software development [1]. Agile manifesto sparked the introduction of new, flexibledevelopment methodologies such as eXtreme Programming (XP), Scrum and Feature DrivenDevelopment (FDD). Agile methodologies gained wide-spread adoption throughout thesoftware industry. Although their benefits were reported in various studies, they have alsobeen criticised for being suited to smaller development teams with experienced developers[5].

1.3 What is Model Driven Software Development?

1.3.1 Model Driven Software Development

Model Driven Software Development (MDSD) follows a very common notion which can beobserved in many other fields of engineering. Engineers make use of models while designingcomplex systems. Models are a way to abstract the system and its environment; so issuescan be resolved and architecture can be improved. Building models and applying tests onthose models is a fast, cost-effective solution to many engineering problems [26, 27]. Modelshave been used in the software industry as well. Unified Modelling Language (UML) wasdeveloped as a means of documenting software products. UML models aid in communica-tion during the software development process. In situations where software architecture iscomplex or is develop by a number of teams, UML diagrams are vital communication aids.One UML diagram can represent thousands lines of code [17]. Changing requirements ofsoftware projects can make models obsolete if they are not updated along with the sourcecode over the duration of the project. Unlike other engineering fields, models in softwaredevelopment have been primarily used as sketches or blueprints for software products. Dueto this nature models are often considered as an overhead for software projects [27]. Agilemanifesto puts working software at the forefront of the development process, documentation

4 Introduction

and other artefacts are only produced if they are requested by the client or if they add valueto the process [1].

Model Driven Software Development (MDSD) takes a different approach. Models arenot used merely for documentation purposes, but also to generate source code automaticallyas well. Models are regarded equal to code with the MDSD approach, as code generationis an automated process based on the model definitions within the project [26]. The majorstrength of this approach lies in the automation of code generation, which in turn increasesthe productivity of developers. Solutions to the requirements can be transcribed in a higherabstraction level with the use of models. This property of MDSD does not only help toproduce better and more maintainable code, but also helps business domain experts to takerole in designing and producing systems. Approach taken by MDSD is an evolutionary step todeveloping software, its effects on the development process can be compared to the inductionof first higher-level languages when assemblers and low-level programming languages werethe status quo. As the name suggests, the emphasis on “driven” puts the models in centre andthere are three primary prerequisites for model driven software development.

1. Domain-specific languages are needed to be able to define models in the context of aproblem.

2. Model transformation languages are needed to be able to define in which ways modelswill be converted into code.

3. Tools to carry out compilation, generation and transformation operations are needed tobe able to define, transform and generate executable code to run on targeted platforms[27].

1.3.2 Model Driven Architecture

Object Management Group have put forward a set of standards and technologies underthe Model Driven Architecture (MDA) initiative. Despite the fact that both MDA andMDSD follow a very similar approach which involves automation of code generation throughmodels, MDA differs in terms of flexibility and implementation due to the motivationsbehind its development. MDA offers interoperability between different tools, strictly usesUML based modelling languages for model definitions and aims for the sharing of modelsamong popular software domains. Some of the standards introduced by OMG includeUML, Meta-Object Facility (MOF), XML Metadata Interchange (XMI) format and alsoQuery/View/Transformations (MOF/QVT). As MDA is still in active development, some

1.4 Approach 5

aspects of it must be omitted meanwhile others should be utilized up to some extent in orderto achieve results in MDSD projects [21, 27].

1.4 Approach

1.4.1 Walking Skeleton Practice

This project contains several different tools and platforms working together to achieve itsaim. Some of the tools used include Eclipse Modelling Platform, Acceleo Model-to-Texttransformation language and the Android SDK. Due to project’s interconnected nature whichspans over a variety of tools, an agile practice called walking skeleton was used during thedevelopment. Walking skeleton implementation provides the fundamental backbone, a thinend-to-end slice of functionality. The skeleton project can be used to automate the build anddeployment processes, as well as the validation of the software product. With the walkingskeleton approach, the emphasis is on connecting the various sub-systems involved in theproject. Once the communication between the interconnected elements of the system isvalidated, developers can start working on developing the functionality which will add valueto the product. The initial architecture developed using walking skeleton approach is byno means final, as the development effort on the project is carried out, the infrastructureevolves over time along with the functionality. In order to implement the walking skeletonarchitecture, developer needs to acquire a basic understanding of each of the individualcomponents and with the implementation of first piece of functionality, the context of theproject will be more clear [6].

Walking skeleton approach is an agile practice, however it is often confused with the big-design-up-front (BDUF) waterfall practice. BDUF aims to lay the plans out for the wholearchitecture. Classes and algorithms are carefully planned out before developers start writingany code. On the contrary, walking skeleton practice tries to keep design decisions at aminimum during the early stages of the development. Instead, development effort is focusedon putting the pieces of the puzzle together so that functionality can be developed earlier inthe development period. The feedback gathered from the validation process is a vital part ofthe process, as it leads the further iterations of development [12].

1.4.2 Benefits of Applying Walking Skeleton Practice

Utilization of the walking skeleton practice during the early stages of the development,benefited the project in a number of ways. Firstly, communication between interconnected

6 Introduction

pieces such as the eclipse modelling framework, acceleo generation facility and the AndroidSDK was established at a relatively early stage. This prevented any integration issueshappening later in the project. Functionality was implemented with confidence and resultswere evaluated straight away. Secondly, the big picture behind the project was made clear atthe beginning. I had the chance to get familiar with different parts of the project and betterunderstand their roles and responsibilities. Last but not the least, walking skeleton approachhelped managing the time spent on developing functionality. Infrastructure and integrationissues were kept at minimum throughout the project duration.

Chapter 2

Technology and Implementation

2.1 Overview

The tools used to realize this project include the Eclipse IDE, Eclipse Modelling Framework,Acceleo code generation facility and also the Android SDK. The importance of each tool andtheir usage is explained in this chapter. See figure 2.1 for the workflow of the technologystack.

2.2 Eclipse Platform

Eclipse Project is an open-source platform which includes various tools and frameworks todevelop integrated development environments and also other applications. The developmenteffort behind the project is organized and regulated by the Eclipse Foundation. Eclipse Foun-dation is a non-profit organization consisting of private companies and individual developers[28].

In addition to the Eclipse Project, Eclipse Foundation oversees the development of var-ious other top-level projects. Some of these project which worth mentioning are the ToolsProject, the Modelling Project and the Technology project [28].

The Tools project consists of smaller sub-projects which are aimed at developing flexi-ble development tools. Eclipse Modelling Project started its life as a tools project then it wasseparated as the project matured [28].

The Modelling Project is the flagship MDSD project developed by the Eclipse Founda-

8 Technology and Implementation

Fig. 2.1 Tools and their purpose in the project.

tion. Eclipse Modelling Framework (EMF) provides a wide range tools which can be utilizedin MDSD projects. Model definitions, model transformations and database connectivity canbe achieved using EMF. In addition to these features, EMF provides implementations forUML 2.x metamodel. Custom graphical editors can also be designed using the GraphicalModelling Framework along with the EMF [28].

The Technology Project includes projects which are experimental and theoretical in na-ture. It serves as an incubator facility to further extend Eclipse platform’s capabilities bygiving a chance to researchers and academics to put their ideas to test [28].

2.3 Eclipse Modelling Framework

2.3.1 The Domain

Every software project which is trying to solve a problem, needs to produce a solutionwithin the context of the problem. The context can be defined as a set of concepts and therelationships between them. In the context of this project, the “Mobile Application” domain,concepts include objects for elements, screens for different views within the applicationand the application itself. Domains can involve smaller sub-domains. For instance, atechnical subdomain encompassing user interface and data persistency concepts. A technical

2.3 Eclipse Modelling Framework 9

subdomain may not have direct relationship to the problem domain but is needed for theresulting software product [27].

2.3.2 The Meta-Model

Meta-model defines the structure of a domain. It formalizes the concepts and relationshipsthrough the use of abstract syntax and static semantics so that the automation duties can becarried out. A meta-model is an instance of another meta-meta-model. In Eclipse ModellingFramework, a variant of OMG’s MOF standard is used, which is called Ecore. Ecore provideslanguage constructs which can be used to build other languages. Concepts such as classes,inheritance, properties and data types can be expressed with Ecore meta-models [27].

Ecore implementation provides five fundamental elements which can be used to describesoftware architecture. See figure 2.2 for their java counterparts.

1. EClass represents a class with any number of attributes and references.

2. EAttribute represents an attribute with a name and a data type.

3. EReference is used on the one end of an association between two EClass elements. Itrepresents the relationship between them and any containment property is stored.

4. EDataType represents the data type of an attribute. It can be an existing Java data typeor a custom type defined by the user.

5. EOperation represents methods which will appear in the generated interfaces [30].

10 Technology and Implementation

Fig. 2.2 Fundamental Ecore elements and their Java implementation counterparts [15].

Meta-models are the key components of MDSD, with EMF framework they can be definedusing Java Interfaces, UML diagrams or XML Schemas. Ecore models act as the combiningelement between those three components. Ecore models can be generated from any of theserepresentations and converted to others if required [28]. See figure 2.3 for this behaviour.

In EMF, Ecore meta-models are stored in XML Metadata Interchange (XMI) format sup-ported by Extensible Markup Language. XMI is a specification put forward by the ObjectManagement Group to allow serialization and interchange of meta-models [28]. In figure 2.4ecore meta-model is displayed in Eclipse XMI editor.

2.3.3 The Meta-meta Model

Models are defined using meta-model definitions, similarly meta-models must be definedwithin a formal definition which are called meta-meta-models. In EMF, Ecore is defined interms of Ecore itself, so it is self-referential [27].

2.3.4 Domain Specific Languages

Domain Specific Languages (DSL) are constructed using meta-models, static semantics andconcrete syntax. DSLs provide a higher level abstraction which makes the problem domain

2.3 Eclipse Modelling Framework 11

Fig. 2.3 Ecore meta-models are interchangeable between different formats [28].

Fig. 2.4 Ecore meta-models are in XMI format.

12 Technology and Implementation

modellable. In order to be beneficial for MDSD projects, DSL syntax should be intuitivefor the modellers so that they can produce meaningful models. Furthermore, the semanticsbehind the DSL should be executed correctly during automatic transformations [27].

2.3.5 The Model

Model is an instance of the meta-model so it is expressed in the concrete syntax of the DSLformulated by the meta-model. Automated-transformations are applied on the models, basedon the model definitions concrete implementation counterparts can be generated [27].

2.3.6 A Meta-Model for Mobile Applications Domain

In the context of mobile application development domain, I have identified three mainconcepts which needs to expressible via models designed by user as follows:

1. A top-level class which will hold metadata regarding the modelled application such asthe name of application. It will also encapsulate various screens by having referencesto them. See EClass element titled App in the Ecore tree diagram in figure 2.5.

2. Individual screens of functionality is another EClass element, it will contain the title ofthe screen and also references to the widgets contained within that screen. See EClasselement titled Act in the Ecore tree diagram in figure 2.5.

3. Widgets within the screen are represented by a super class called Object. Objects havea property called title. This title is used while storing data in a SQLite database. Forthe scope of this project, I have included three types of widgets. Each widget is asubclass of the Object class. A text field to store textual information. A drop downselection widget which can be useful to display a list of options for the app user toselect. Finally, a confirmation button which can be used to save data entered into textfields and selected by the drop down options. See EClass element titled Object in theEcore tree diagram in figure 2.5.

2.3.7 Generating Modelling Plugins Using EMF

EMF does not work directly on the ecore metamodel, in order to create models genmodels arerequired as well. While the ecore metamodels hold information about the classes, genmod-els hold information about the code generation such as the file path and control parameters [3].

2.3 Eclipse Modelling Framework 13

Fig. 2.5 An Ecore Meta-Model for mobile applications.

14 Technology and Implementation

Fig. 2.6 Generating modelling plugins from the generator model [3].

Creating genmodels is a straight-forward process, EMF provides a wizard to import ex-isting Ecore metamodel in the current workspace and generate the corresponding genmodel[3]. See figure 2.6 for an overview of the process.

Using the genmodel, EMF can generate edit, editor, model and test plugins for the user.Model contains the java implementation of the metamodel. Factories, adapters and interfaceswill be available under different packages. Edit and Editor plugins are used to create a newEclipse runtime which can be used for modelling with a tree diagram editor based on theecore metamodel [3].

2.3.8 Eclipse Runtime for Modelling and Code Generation

After editor, edit and model projects are generated using the genmodel, a new runtime can belaunched to kickstart modelling and code generation processes. See 2.7 for starting a newEclipse runtime. New runtime will have a serialized version of the meta-model instance.Mobile application models can be created from inside the new run-time environment withthe help of a tree diagram editor. EAttributes options can be altered inside the properties

2.3 Eclipse Modelling Framework 15

Fig. 2.7 Starting a new Eclipse runtime using the generated editor project.

view within the diagram editor See figure 2.8 for the diagram view of a model inside theeclipse runtime.

2.3.9 Sample Mobile Application Models

The strength of MDSD lies in the reuse of resources, meta-models can be reused in differentscenarios in the same problem domain. In order to demonstrate this property of MDSD, Ihave created two different mobile applications which use the same meta-model defined forthe mobile software domain.

First application is a contact list which stores information about user’s contacts. The infor-

16 Technology and Implementation

Fig. 2.8 Model for a contact list application.

mation stored includes the name, surname, phone number and country of the contact. Seefigure 2.8 for the sample contacts application model.

Second application is a league table application which displays the current situation in aseason. It is able to store the team’s current standing position, name and the name of thecoach. See figure 2.9 for the sample contacts application model.

2.4 Code Generation for Android Platform

2.4.1 Model to Text Languages

Model transformations is an important part of MDSD, it is the key process which producesconcrete implementations and documentation from the underlying model. Apart from gen-eration of documentation and code, model transformations can also be used to serialize,visualize and explore models. A standard for model to text transformations were introducedby OMG in 2008, which is the MOF Model to text language (MOFM2T). There are variousmodel to text languages and they differ in syntax and functionality because of the motivationsbehind each of them are different. For instance, Microsoft’s T4 language was developed for

2.4 Code Generation for Android Platform 17

Fig. 2.9 Model for a league table application.

18 Technology and Implementation

seamless integration and interoperability with the .NET framework [24]. On the other hand,EMF project includes a code generation facility called Java Emitter Templates. Java EmitterTemplates is comprised of a subset of the Java Server Pages (JSP) syntax. It was designed tobe a light-weight and easy to use facility [22].

Choosing the right model-to-text language which is in line with the aims and the targetplatform of the project is a very important decision. The lack of interoperability betweenthose languages turns the process of migrating from one language to another into a tediousjob. The development effort spent on the model to text functionality has to be repeated inthe new language if a migration decision is made later in the lifetime of the project. For thisreason, I have decided to use Acceleo which is the only language which tries to adhere tothe MOFM2T standards introduced by the OMG. When model to text languages mature andindustry wide adoption of MDA standards increase in the future, it will be easier to migrateor update the code generation functionality used within the project [24].

2.4.2 Acceleo

In order to start using Acceleo code generation facility, you need to create a new Acceleocode generation project inside the runtime environment where the formal models are defined.Acceleo runs template files defined by the user to generate corresponding text files. Genera-tion process will abide by the definitions of the template files. When defining the templatefiles, user needs to select the meta-model they want to base their code generation process. Inthe context of this project, I used the meta-model defined with the EMF Ecore, see figure2.5. In addition to the various template files required for code generation process, user needsto specify a main template module. This template will act as an entry point when the codegeneration process is initiated. Template files which the user wants to run as a part of thecode generation process needs to be referenced inside the main template module [19].

Acceleo works by taking in a model instance, then it can inspect the elements containedwithin the model instance. MOFM2T specification allows various capabilities. Capabilities Ihave mainly relied on includes; checking types, applying conditional logic and iterating overlists of elements, see 2.10.

2.4 Code Generation for Android Platform 19

Fig. 2.10 Using acceleo to iterate over elements and check their types.

2.4.3 Data Persistency

In order to provide a persistent data store for the CRUD functionality, I have used the SQLitedatabase. SQLite is an open source relational database management system which is availablewith the Android platform. It is managed by the Android platform and does not require anyconfiguration. Databases are stored on the filesystem of the device until they are deleted bythe application or the application is uninstalled.

SQLite is a light-weight, serverless transactional database engine. It supports only three datatypes TEXT, INTEGER and REAL. I have used the TEXT data type for storing text fieldsand INTEGER data type for table keys [18].

2.4.4 Android Architecture

In order to allow users to design their own CRUD mobile applications, I created eightdifferent acceleo templates to generate the android application architecture from the models.See figure 2.11 for the acceleo workspace and template files.

Act EClass instances represented in the models are converted into individual screens for theAndroid application. See figure 2.5 for the meta-model.

For each screen within the application, a SQLite database adapter class is generated. Thistemplate creates the java adapter which contains queries to create the database and tables onclass initialization. Each screen has its own database and a table to store the objects withinthat screen. Adapter class also provides public methods to insert, update and remove recordsfrom the database. See figure 2.12 for public methods.

20 Technology and Implementation

Fig. 2.11 Acceleo workspace with the template files to generate Android applications.

2.4 Code Generation for Android Platform 21

Fig. 2.12 SQLite Adapter’s public methods to create, update and delete records.

22 Technology and Implementation

Fig. 2.13 A snippet from the View generation template.

For each screen within the application, a java class which extends the Android SDK’sListActivity interface is generated. ListActivity encapsulates a list view which can bepopulated using different data sources such as an array or a database cursor [10]. In order topopulate the fields displayed in the list view, I have used a cursor which fetches the fieldsfrom the SQLite database. Cursor gets the information using the public methods availablethrough the corresponding database adapter class. If user taps on a list item, they are taken toa new screen where they can edit the selected item. Delete functionality was implementedusing a floating contextual menu. Menu is initiated when user performs a long-click actionon a list item [11]. See figure 2.13 for a snippet from the list view.

For each screen within the application, an Editor class is also provided. This class extendsAndroid SDK’s Activity interface and handles the operations carried out in the edit view. Itfetches the data from the database and saves changes made to the database upon save actionusing the corresponding database adapter.

2.4 Code Generation for Android Platform 23

Fig. 2.14 Strings resource generation template.

Fig. 2.15 Parent list view layout XML generation template.

Instead of generating strings directly into Java source code (similar to hardcoding), I havegenerated a string resources file. The static texts displayed on the buttons within screensare stored in a “Strings.xml” file. Optional styles and formats can be defined for the sametext resource using the Android SDK [23]. See figure 2.14 for the Strings.xml generationtemplate.

Android SDK lets developers to create user interfaces either by declaring in a XML file orinstantiating layout objects at run-time. I have decided to generate XML files, as separatingapplication code and user interface will make the android source code better structured. Italso means that changes to the layout can be applied without the need of re-compiling androidsource code. Different XML files can be generated for different devices, screen sizes andlanguages [8].

I have generated three XML files for representation purposes. I have used a linear layoutwhich wraps another layout for the list view. Child layout contains the fields of informationas a row. On the other hand, for the edit view I have used an absolute layout which madeit easier to place text fields accordingly. Absolute layouts require x and y positions for theelements on the screen [7, 9]. See figure 2.15 for the parent list view.

24 Technology and Implementation

Fig. 2.16 AndroidManifest template.

Every Android application must have a XML file called “AndroidManifest”, located in theroot directory. This manifest file contains the essential information about the applicationgenerated. [20]. See figure 2.16 for the manifest template.

Chapter 3

Evaluation

3.1 Validation of Models

Checking if the modelled objects are in a correct state can be achieved by using the validationframework provided by the EMF. Inside the model itself, model architect can declare con-straints and invariants to define rules for the validity. Validation process can be invoked usingthe generated editors or through the generated code. The difference between the constraintsand invariants are directly related to their UML counterparts. Constraints are rules whichshould be true for an object during a specific period of time. On the other hand invariantsshould always be satisfied by the model regardless of the time and condition. A preconditionbefore method execution can be represented as a constraint. For instance, the team positionin a football league standing should always be a positive number, this can be represented asan invariant. It is a general rule, which is always true [28].

In order to invoke validation process using the EMF workspace, user has to right-click on themodel file and select “validate” option from the context menu, see figure 3.1. If validation iscompleted successfully, Eclipse displays a confirmation message, see figure 3.2.

26 Evaluation

Fig. 3.1 Validating models.

3.2 User Stories 27

Fig. 3.2 Successful validation.

3.2 User Stories

I have produced some user stories while planning the project and those were the maindocuments used to cross-check the generated functionality.

1. As a modeller, I want to be able to model mobile applications with a list view.

2. As a modeller, I want to be able to store any number of text fields.

3. As a modeller, I want to be able to store any number of dropdown fields.

4. As an application user, I want to be able to create new records.

5. As an application user, I want to be able to update existing records.

6. As an application user, I want to be able to delete records.

7. As an application user, I want the application to retain database status after restartingthe application.

Above user stories have been implemented in the scope of this project.

Chapter 4

Achievements and Conclusion

4.1 Knowledge Gained

I have gained a good understanding of the Model Driven Software Development practiceduring the course of this project. I have also had the chance to discover more ambitiousModel Driven Architecture and its aims. I have used a set of tools used for modelling andcode generation such as the Eclipse Modelling Framework and Acceleo code generationfacility. With Acceleo, I used the OMG standard OMFM2T language. In addition to these,I have learned about developing Android applications so that I could write template fileswhich can convert models into android source code.

4.2 Difficulties Encountered

At the beginning of the project, I have planned to implement a custom graphical editorwhich would have let the users to model their applications. Graphical Modelling Frameworkproject of the Eclipse Foundation can be used to achieve this. After trying to implement thisfunctionality for a considerable time, I decided to scrap this piece of functionality in order tomake progress towards the project’s main goal. Current implementation lets users to modeltheir applications using the EMF provided tree diagram editor. Although a custom graphicaleditor would achieve exactly the same results compared with the tree diagram editor, acustom graphical editor could have made the modelling processes much more intuitive forthe user.

30 Achievements and Conclusion

4.3 Further Work

In order to improve the project, I think the project needs to be specialized in a specificbusiness application domain. This way the benefits of MDSD can be exploited to its fullpotential. Designing a custom graphical editor could greatly help the modellers as it can beconfigured to hide the unwanted functionality and provide easy access to frequently usedelements. During my research, I have come across several companies which are developingMDSD projects and publishing them in the form of Platform as a Service (PaaS) products[2]. If the customers are encouraged to share models amongst them, really powerful MDSDsolutions can be developed with the help of the community. Graphical Modelling Frameworkworks with Eclipse Platform only, so in order to realize this goal a custom web front-endapplication and a middleware software layer are required.

4.4 Conclusion

During the course of this project, I have managed to define a meta-model which can be usedto model basic CRUD Android applications. An acceleo code generation project was alsocreated to generate android application source code from the user defined models. Datapersistency was assured through the use of SQLite databases which help applications to retaintheir data state. In order to implement these capabilities, I have gained knowledge in thedevelopment paradigm Model Driven Software Development, Eclipse Modelling Frameworkand also the Android platform. MDSD is a technique which can be utilized to reduce overalldevelopment effort by raising the abstraction level and also automating code generation.As a result, it enhances developer productivity. EMF provides a set of tools to implementthis paradigm and combined with the Android SDK, I was able to achieve project’s aim ofgenerating mobile applications from models. See figures 4.1 and 4.2 for the screenshots of agenerated application.

4.4 Conclusion 31

Fig. 4.1 Edit View of a generated application.

32 Achievements and Conclusion

Fig. 4.2 Edit View of a generated application.

References

[1] Agilealliance.org. Agile alliance :: The agile manifesto, 2015. URL http://www.agilealliance.org/the-alliance/the-agile-manifesto/.

[2] The Enterprise Architect. The rise of rapid application delivery through model-drivenpaas - by johan den haan, 2015. URL http://www.theenterprisearchitect.eu/blog/2015/01/29/rapid-application-delivery-through-model-driven-paas/.

[3] Vladimir Bacvanski and Petter Graff. Mastering eclipse modeling framework, 2005.URL http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial28.pdf.

[4] Herbert D. Benington. Production of large computer programs. IEEE Annals Hist.Comput., 5(4):350–361, 1983. doi: 10.1109/mahc.1983.10102.

[5] Paul Clarke and Rory V. O’Connor. The situational factors that affect the softwaredevelopment process: Towards a comprehensive reference framework. Information andSoftware Technology, 54(5):433–447, 2012. doi: 10.1016/j.infsof.2011.12.003.

[6] Alistair Cockburn. Alistair.cockburn.us | walking skeleton, 2015. URL http://alistair.cockburn.us/Walking+skeleton.

[7] Developer.android.com. Absolutelayout | android developers, 2015. URL http://developer.android.com/reference/android/widget/AbsoluteLayout.html.

[8] Developer.android.com. Layouts | android developers, 2015. URL http://developer.android.com/guide/topics/ui/declaring-layout.html.

[9] Developer.android.com. Linearlayout | android developers, 2015. URL http://developer.android.com/reference/android/widget/LinearLayout.html.

[10] Developer.android.com. Listactivity | android developers, 2015. URL http://developer.android.com/reference/android/app/ListActivity.html.

[11] Developer.android.com. Menus | android developers, 2015. URL http://developer.android.com/guide/topics/ui/menus.html.

[12] Steve Freeman and Nat Pryce. Growing object-oriented software, guided by tests.Addison Wesley, 2010.

[13] Gartner.com. Gartner says mobile app stores will see annual downloads reach 102billion in 2013, 2015. URL http://www.gartner.com/newsroom/id/2592315.

34 References

[14] Git-scm.com. Git - about version control, 2015. URL http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control.

[15] Maximilian Helming. Emf tutorial « eclipsesource blog, 2015. URL http://eclipsesource.com/blogs/tutorials/emf-tutorial/.

[16] The Business Journals. Update: Number of active mobile devices surpasses worldpopulation - the business journals, 2015. URL http://www.bizjournals.com/prnewswire/press_releases/2014/10/06/NY30877.

[17] Craig Larman. Applying UML and patterns. Prentice Hall PTR, 2005.

[18] Sunguk Lee. Creating and using databases for android applications. InternationalJournal of Database Theory and Application, 5(2):102–103, 2012. URL http://www.sersc.org/journals/IJDTA/vol5_no2/8.pdf.

[19] Lowcoupling.com. Models to text transformations with mofm2tand acceleo, 2015. URL http://lowcoupling.com/post/47347056110/models-to-text-transformations-with-mofm2t-and.

[20] App Manifest. App manifest | android developers, 2015. URL http://developer.android.com/guide/topics/manifest/manifest-intro.html.

[21] Nathalie Moreno, JoséRaúl Romero, and Antonio Vallecillo. An overview of model-driven web engineering and the mda. In Gustavo Rossi, Oscar Pastor, Daniel Schwabe,and Luis Olsina, editors, Web Engineering: Modelling and Implementing Web Ap-plications, Human-Computer Interaction Series, pages 353–382. Springer London,2008. ISBN 978-1-84628-922-4. doi: 10.1007/978-1-84628-923-1_12. URLhttp://dx.doi.org/10.1007/978-1-84628-923-1_12.

[22] Remko Popma. Jet tutorial part 1 (introduction to jet), 2004. URL https://eclipse.org/articles/Article-JET/jet_tutorial1.html.

[23] String Resources. String resources | android developers, 2015. URL http://developer.android.com/guide/topics/resources/string-resource.html.

[24] L.M. Rose, N. Matragkas, D.S. Kolovos, and R.F. Paige. A feature model for model-to-text transformation languages. In Modeling in Software Engineering (MISE), 2012ICSE Workshop on, pages 57–63, June 2012. doi: 10.1109/MISE.2012.6226015.

[25] SearchSoftwareQuality. What is integrated development environment (ide)? - definitionfrom whatis.com, 2015. URL http://searchsoftwarequality.techtarget.com/definition/integrated-development-environment.

[26] B. Selic. The pragmatics of model-driven development. IEEE Softw., 20(5):19–25,2003. doi: 10.1109/ms.2003.1231146.

[27] Thomas Stahl and Markus Vo¨lter. Model-driven software development. John Wiley,2006.

[28] Dave Steinberg. EMF. Addison-Wesley, 2011.

References 35

[29] Thoughtworks.com. Continuous integration | thoughtworks, 2015. URL http://www.thoughtworks.com/continuous-integration.

[30] Vogella.com. Eclipse modeling framework (emf) - tutorial, 2015. URL http://www.vogella.com/tutorials/EclipseEMF/article.html.

[31] Webopedia.com. What is high-level language? webopedia, 2015. URL http://www.webopedia.com/TERM/H/high_level_language.html.