AXIOM: A Model-driven Approach to Cross-platform Application

Development

Xiaoping Jia and Chris Jones

School of Computing, DePaul University, 243 S. Wabash Ave., Chicago, IL, U.S.A.

Keywords:

Model-driven Engineering, Domain-speciﬁc Languages, Mobile Application Development.

Abstract:

The development and maintenance of mobile applications for multiple platforms is expensive. One approach

to reducing this cost is model-driven engineering (MDE). In this paper, we present AXIOM, a model-driven

approach for developing cross-platform mobile applications. Our approach uses a domain speciﬁc language

(DSL) for deﬁning platform-independent models (PIM) of mobile applications. It also deﬁnes a multi-phase,

customizable transformation process to convert platform-independent models into native applications for target

mobile platforms. Our approach could signiﬁcantly reduce the development cost and increase the product

quality of mobile applications. A prototype tool has been developed to demonstrate the feasibility of the

approach. The preliminary ﬁndings are promising and show signiﬁcant gains in development productivity.

1 INTRODUCTION

In recent years, there has been tremendous growth in

the popularity of mobile applications targeting smart

phones and tablets. With the ever-improving capabil-

ities of these devices, mobile applications are becom-

ing increasingly sophisticated and complicated, while

also having to address challenging constraints and re-

quirements, such as responsiveness, limited memory

and low energy consumption. Furthermore, there are

currently several competing mobile platforms on the

market, including Google’s Android and Apple’s iOS.

For mobile application developers, it is highly desir-

able for their applications to run on all major mobile

platforms. Although these competing platforms are

similar in capability, they differ signiﬁcantly in pro-

gramming languages and APIs, making it expensive

to port a mobile application to different platforms.

An appealing approach to cross-platform develop-

ment is model-driven engineering (MDE). In MDE,

software systems are built by ﬁrst deﬁning platform-

independent models (PIMs), which capture the com-

positions and core functionalities of the system in a

way that is independent of implementation concerns.

The PIMs are then transformed into platform-speciﬁc

models (PSMs), from which the native application

code for each platform can be generated. MDE shifts

the development focus away from writing code (Selic,

2003) and toward the development of models, such as

those in UML and its proﬁles.

Despite its potential beneﬁts and proven success

in large-scale industrial applications (Object Manage-

ment Group, 2011), MDE faces signiﬁcant challenges

to its widespread adoption including: limitations of

UML (France et al., 2006; Henderson-Sellers, 2005);

inadequate tool support; model transformation com-

plexity; and apparent incompatibility with popular

Agile software development methodologies such as

eXtreme Programming (XP) and Scrum.

The Agile and MDE approaches to software de-

velopment are each oriented toward different kinds

of software. For example, MDE often targets ma-

ture middleware platforms with widely adopted com-

mon standards such as JEE, .NET, and SOA. In con-

trast, applications developed using Agile techniques

often ﬁt certain well-understood patterns, such as be-

ing web-based and database-driven, and using an n-

tier MVC architecture. It would be beneﬁcial if the

strengths of these two approaches could be combined

and their shortcomings mitigated.

In this paper, we present a novel model-driven ap-

proach to cross-platform mobile application develop-

ment using a domain speciﬁc language (DSL), called

AXIOM (Agile eXecutable and Incremental Object-

oriented Modeling). Our approach deﬁnes a frame-

work for describing the PIMs, design decisions, and

implementation details of applications. We also pro-

vide tools to carry out the transformation of PIMs into

native implementations across multiple platforms. A

prototype tool has been developed to demonstrate the

Jia X. and Jones C..

AXIOM: A Model-driven Approach to Cross-platform Application Development.

DOI: 10.5220/0004022500240033

In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 24-33

ISBN: 978-989-8565-19-8

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

feasibility of the approach. The prototype currently

targets mobile applications in general with an empha-

sis on the Android and iOS platforms in particular.

2 APPROACHES TO

PLATFORM-INDEPENDENCE

Platform-independence is not a new goal and the cost

savings that can be realized through such indepen-

dence have long been recognized. The advent of high-

level languages signiﬁed an early means of provid-

ing such platform-independence through the use of

greater abstractions. Languages such as C and C++

were only partially successful in achieving platform-

independence because of the decision to leave some

runtime aspects of the language, such as integral

datatype sizing (Kernighan and Ritchie, 1988; El-

lis and Stroustrup, 1990), up to compiler providers.

This allowed the same source code to be compiled for

many different target platforms, but did not guarantee

that all of the runtime semantics would be consistent

across those platforms.

Languages based on virtual machines (VMs), like

Java (Gosling et al., 2000), provide true platform-

independence by specifying a well deﬁned, standard-

ized runtime environment. Higher-level languages

are converted into VM instructions, which are then

executed on the target platform using the native in-

struction set. Because both the language and the VM

are governed by speciﬁcations the behavior of the ap-

plication across different platforms tends to be more

consistent than when using languages without such

comprehensive speciﬁcations.

The combination of high-level languages with a

standardized runtime environment provides a power-

ful foundation on which platform-independent appli-

cations can be built. This approach can be further re-

ﬁned through the use of domain-speciﬁc languages

(DSLs), which expose domain-speciﬁc concepts to

developers, thus providing a high level of abstrac-

tion and expressiveness within that domain. DSLs

are available for speciﬁc domains like mobile and

web development. Figure 1 describes several differ-

ent ways in which DSLs, VMS and native instructions

can interact.

DSLs can be external, meaning that their syntax is

not the same as the host language, or internal, where

they share the host language. This ﬂexibility allows

for DSLs that can be transformed into higher-level

languages, directly into VM instructions, or even into

native code for the target platform. DSLs based on

languages like Ruby or Groovy are internal and ul-

timately generate high-level language code based on

Figure 1: Approaches to platform-independence.

the host language. The beneﬁt to this approach is that

the DSL can take advantage of the power of its host

language, including its compiler and associated opti-

mizations.

A second approach is to provide a DSL that ul-

timately produces native VM instructions. This pro-

vides a mechanism that allows for the power of a DSL

along with potential optimizations for a particular VM

instruction set. However, the process of converting

the DSL code into VM instructions involves the same

effort as writing a compiler, potentially making it a

more expensive approach than allowing the DSL to

produce high-level language code for which a com-

piler already exists.

A third approach is to use a DSL that produces na-

tive code for the target platform. The same drawbacks

exist for this approach that exist for the conversion to

VM instructions. However, done well, the potential

power and optimizations realized by converting di-

rectly to the native instruction set can prove valuable.

This approach may also be used when few, if any,

compilers exist for a target platform, such as might

be the case with specialized hardware or chipsets.

3 UML AS A BASIS FOR MDE

DSLs have also been used in the form of model-

ing notations, the best-known of which is UML (Ob-

ject Management Group, 2010), which, along with

OCL (Object Management Group, 2003b), seeks to

provide a common language for describing software

models. The Object Management Group’s (OMG)

approach to model-driven engineering, MDA (Object

Management Group, 2003a), relies on UML mod-

els that are then consumed and transformed into ex-

ecutable code.

Unfortunately, MDE in general and MDA in par-

ticular, has not seen the same industry adoption rates

as Agile approaches like XP or Scrum. Some reasons

for this may include:

• A lack of adequate tool support in creating, main-

taining and understanding the complex models

derived from UML and related OMG standards.

Visual models make complex structures compre-

AXIOM:AModel-drivenApproachtoCross-platformApplicationDevelopment

hensible, but are difﬁcult and time consuming to

create and maintain without strong tool support.

• The difﬁculty in the interchange of visual models

across different tools using the XMI (Object Man-

agement Group, 2007) standard for UML inter-

change. One study of some of the most commonly

used UML tools showed that the success rate of

attempted model interchanges amongst these tools

was less than 5% (Lundell et al., 2006).

• The lack of executability in UML models leads to

long development cycles. UML models are thus

ill-suited for Agile development processes and are

generally used only for heavyweight processes.

• A lack of modeling resources comparable to the

extensive frameworks and libraries available to

Agile approaches. Most models must be de-

veloped from scratch rather than being built on

known, proven, and previously adopted solutions.

4 AXIOM: DSL-BASED MDE

We propose to leverage the power of a DSL based on

the dynamic language, Groovy, to provide a new ap-

proach to model-driven engineering. Our approach

is called AXIOM (Agile eXecutable and Incremental

Object-oriented Modeling). AXIOM retains the key

elements of MDE such being model-centric and us-

ing using transformations to convert the models into

executable code, but differs in the speciﬁcs. Whereas

MDA relies on MOF (Object Management Group,

2006) metamodels to facilitate the transformation of

UML models into executable code, AXIOM instead

provides a modeling DSL written in a dynamic lan-

guage. AXIOM supports a limited subset of UML in

the form of class diagrams and state charts as a means

if visualizing the DSL models. This allows it to main-

tain some of the most powerful aspects of MDD such

as model visualization, while also being easily acces-

sible to existing designers and developers who are fa-

miliar with UML and its notation.

AXIOM uses the dynamic language, Groovy, as

its core modeling language and deﬁnes a DSL specif-

ically for modeling mobile applications. The DSL

provides an abstraction of the features and capabilities

supported by the Android and iOS platforms. The aim

of the DSL is to provide an abstract way of accessing

the complete native API of each platform, and not just

a limited subset of the API (often known as the low-

est common denominator). By using a DSL, AXIOM

also allows platform-independent models to be exe-

cutable. This shortens development time and allows

for the early detection and remediation of errors and

anomalies. Because AXIOM is Groovy-based, it has

access to a rich set of modeling elements and frame-

works that UML alone does not provide.

AXIOM supports customizable model transfor-

mations and code generation. It permits both kinds

of MDE: completely generative, where all of the

code comes from the model, and partially generative,

where nearly complete code is generated with some

parts to be completed manually. The model transfor-

mations can be customized through the use of annota-

tions on the model as well as developer-customizable

code templates for patterns and idioms. The aim is to

allow the generated code to be optimized for perfor-

mance and other quality requirements through tech-

niques supported by native platforms including multi-

threading, memory management, and application life-

cycle management.

It should be noted that while we emphasize the

development of mobile applications for our initial re-

search and in this paper, AXIOM is by no means lim-

ited to such applications. As we will see, AXIOM’s

basic DSL-centric approach is suited to a variety of

applications.

5 AXIOM INTENT MODELS

Applications are ﬁrst deﬁned as platform-independent

intent models using AXIOM’s DSL. Intent models de-

scribe the core functions, user interfaces, and interac-

tions of the application in a way that is completely de-

void of references to implementation-speciﬁc aspects

of any platform. The intent model is composed of

two core perspectives: the interaction perspective, vi-

sualized using UML state diagrams, and the domain

perspective, visualized using UML class diagrams.

Consider a simple application that associates users

with roles, perhaps as part of a broader application

security component. We want the ability to associate

each user with multiple roles, from which they will

ultimately derive their application privileges. To pro-

vide these capabilities we must be able to manage

both user and role information as well as manage the

associations of users to roles. In the next few sections

we examine how AXIOM represents the key elements

of this simple application.

5.1 Interaction Perspective

The interaction perspective describes the user inter-

face and the application’s behavior in response to user

and system events. Figure 2 shows the interaction

perspective of our simple application with the corre-

sponding AXIOM DSL shown in Figure 3.

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

Figure 2: Graphical depiction of interaction perspective.

app(name:’Configure User Role’) {

def roles = [ ... ]

def users = [ ... ]

ListView(id:user) {

roles.each {role -> Section(title:role) {

users.findAll{it.role == role}.each {

user -> Item(text:user.name,

next: [event:Selection,

target:detail, data:user])}}}

}

View(id:detail, title:’User Details’) {

entry(data) = {user = data}

Panel(orientation:’horizontal’) {

Label(text:’Name’)

Text(id:name_value,text:data.name)

}

Panel(orientation:’horizontal’) {

Label(text:’Roles’)

Selection(id:role_value,

options:roles, selected:user.role)

}

Panel(orientation:’horizontal’) {

Button(id:btn_cancel, text:’Cancel’,

next:[event:Click, target:user])

Button(id:btn_save, text:’Save’,

next:[event:Click, target:user,

guard:isValid(), action: {

user.name = name_value.text

user.role = role_value.selected

}])

}

Figure 3: Partial DSL of interaction perspective.

The interaction perspective deﬁnes the composition

of the two screens. The ﬁrst screen is a list view with

several sections. The names ListView, Section, and

Item in the model refer to the UI elements. The sec-

ond screen is a view containing several types of logi-

cal UI controls including labels, buttons, a text ﬁeld,

and a selection. The logical UI controls in the in-

tent model only deﬁne their intended functions and

not the actual widgets that implement these functions.

Figure 4: Graphical depiction of domain perspective.

@Entity

class User {

String username

String password

@Relation

hasMany = [memberOf : Role];

}

@Entity

class Role {

String name

@Relation

hasMany = [member : User];

}

Figure 5: Partial DSL of domain perspective.

The names View, Panel, Label, Button, Text, and

Selection in the model also refer to the UI elements.

Each view in the UI corresponds to a state in the in-

teraction model. Transitions are deﬁned as the next

attribute of the UI control that triggers the transition.

Optional guard conditions and actions can also be de-

ﬁned on the transitions.

5.2 Domain Perspective

The domain perspective describes business entities.

These are typically persistent and are transferred and

referenced among different parts of the application.

Figure 4 shows the domain perspective for our simple

example with the corresponding AXIOM DSL shown

in Figure 5.

AXIOM’s domain perspective is deﬁned using a

notation that is based on the GORM (Rocher et al.,

2009) framework. GORM provides for persistence

and relationship management between persistent ob-

jects. This makes it suitable for deﬁning both stan-

dalone domain objects as well as for incorporating

persistence when required.

Each entity describes the properties and relation-

ships of a domain object. This allows for the precise

deﬁnition of the entity’s properties. GORM supports

both ﬁeld and cross-ﬁeld validations on its properties

although we have not yet incorporated that notation

into AXIOM.

Entities can also have relationships, indicated by

the @Relation annotation. The nature of each rela-

AXIOM:AModel-drivenApproachtoCross-platformApplicationDevelopment

tionship is used to manage the lifecycle and validation

required to maintain it. Each such relationship deﬁnes

a role name, which is used to deﬁne additional proper-

ties of the entity, as well as its cardinality and naviga-

bility. Cardinality is reﬂected using single- or multi-

valued properties deﬁned using GORM’s hasOne and

hasMany property names respectively. Navigability is

deﬁned by the presence or absence of a property that

allows for navigation to the reciprocal entity in the re-

lationship. In this example each entity has a reference

to the other associated with its hasMany property, in-

dicating that these entities support bi-directional nav-

igability.

We assume that any class annotated by @Entity

will be persisted although the precise persistence

mechanism is not encoded within the model. That de-

cision will be made during the structural transforma-

tion phase of the AXIOM’s transformation process.

5.3 Intent Models and Transformations

Intent models are declarative and capture the intent of

applications completely. They are also executable for

the purpose of demonstration and validation. How-

ever, intent models must be informed by additional

decisions in order to produce high quality and ﬁnished

applications:

• Structural. These include architecture and de-

sign decisions such as choice of platform, lan-

guage, framework, API; the use of architecture

and design patterns and implementation idioms

and related techniques. These decisions typically

have a signiﬁcant impact on the code that is ulti-

mately generated as well as on the organization of

that code. This is particularly true when a multi-

tier architecture is desired or when speciﬁc non-

functional requirements must be satisﬁed. Struc-

tural transformations are discussed in more detail

in Section 6.1.

• Reﬁning. These include decisions about vari-

ous aspects of the application such as styles and

themes. This might also include intra-class deci-

sions such as algorithm selection. In general these

decisions, while signiﬁcant, do not have as great

an impact on the generated code as the structural

decisions although they can certainly affect how

well the ﬁnished application meets its require-

ments. Reﬁning transformations are discussed in

more detail in section 6.2.

Structural and reﬁning decisions almost always af-

fect the platform-speciﬁc model. While structural de-

cisions typically have a much broader impact on the

ﬁnished application than reﬁning decisions, they both

Figure 6: AXIOM transformation process.

Figure 7: Evolution of AXIOM AMTs.

serve to narrow the range of possible implementations

that meet the functional, non-functional and platform

needs. All structural and reﬁning decisions are made

during the transformation process.

6 AXIOM TRANSFORMATION

PROCESS

A critical component of MDE is model transforma-

tion, which converts the abstract PIM of an applica-

tion into executable code. The structural and reﬁn-

ing decisions are introduced during AXIOM’s three-

phase transformation process that includes: structural

transformation, reﬁning transformation, and code

generation as shown in Figure 6.

All AXIOM models are represented as abstract

model trees (AMTs) corresponding to the logical

structure and elements of the models. For example,

each UI view and logical UI control in the intent

model is represented as a node in the AMT. The AMT

is similar to an AST, but allows for cross-node rela-

tionships and references. Each node in the AMT sup-

ports attributes both in the form of simple name-value

pairs as well as more complex types such as collec-

tions and closures.

Each phase in an AXIOM model transformation

reconﬁgures the AMT. Figure 7 illustrates the changes

introduced by each phase of the transformation pro-

cess.

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

6.1 Structural Transformations

The structural transformation phase applies architec-

ture and design rules to the intent model and may alter

both the structure of the AMT as well as the attributes

of its nodes. This yields a new AMT that can be struc-

turally different from the original intent model. Struc-

tural decisions often impact the macro-organization

of the components in the application and their in-

teractions. The structural transformations are rule-

based and generally reusable. The result of the struc-

tural transformation is a design model that is function-

ally isomorphic to the original intent model, but that

also deﬁnes the macro-organization of the application

driven by the platform-speciﬁc technology and API.

The design model can be mapped to a design of the

application with the modules, classes and their rela-

tions determined.

Some common examples of structural decisions

include target language and platform, framework se-

lection, and code distribution. Thus transforming the

intent model into an iOS-based mobile application

will yield very different code than transforming it into

a JEE-based web application. Similarly, the decision

for a web application to run within a single JEE con-

tainer will yield different code than one that will be

deployed into different physical tiers.

6.2 Reﬁning Transformations

During the reﬁning transformation phase, the struc-

ture of the design model AMT is preserved but the

attributes of the nodes may be changed. This re-

sults in an output tree that is not only function-

ally isomorphic to the original intent model, but that

is also structurally isomorphic to the design model.

Reﬁning transformations decorate the design model

with additional platform-speciﬁc elements to address

intra-class, micro-organizational decisions. The re-

sulting implementation model maintains the macro-

organization of the design model, but includes all the

necessary details needed to generate high quality, efﬁ-

cient code. The decorations applied during the reﬁn-

ing transformation phase are usually not application

speciﬁc, and are highly reusable.

Examples of reﬁning transformations include al-

gorithm selection, visual layout and theme. This

means that while it may be a functional requirement

that a given list of items be sortable, we can reﬁne the

approach to emphasize the characteristics of one sort

algorithm over another. This becomes critical when

we consider that we must make different time-space

tradeoffs based on the target platform.

6.3 Code Generation

During the code generation phase, the implementa-

tion model is converted into native source code for

the target platform. Code generation is based on a

set of platform-speciﬁc templates that are application-

independent and reusable. The code generation is

completely automated and highly customizable.

7 BENEFITS

AXIOM has several notable beneﬁts for software

development. First, the DSL provides higher lev-

els of abstraction that enable the construction of the

platform-independent intent models while also per-

mitting a high degree of expressiveness. Because the

DSL is written in Groovy, modelers gain instant ac-

cess to existing Java-based frameworks and libraries,

which saves the effort that would otherwise be re-

quired to model them. The DSL also grants the AX-

IOM intent models a degree of executability that fa-

cilitates rapid development and veriﬁcation, an ap-

proach that aligns perfectly with the principles of

modern Agile approaches, which emphasize a rapid

turnaround from concept to completion.

Second, the fact that AXIOM is encoded in a tex-

tual model rather than a graphical one ensures a de-

gree of tool independence; all that is required is a text

editor. Related problems such as concurrent model

development, model versioning, and model merging

can be addressed through existing source code con-

trol systems.

Third, even though the models look more like a

programming language, AXIOM supports a limited

subset of UML models, thus retaining some of the vi-

sual expressiveness of UML.

Finally, the AXIOM transformation rules and tem-

plates can be used across entire families of applica-

tions and technologies rather than being speciﬁc to

a particular application domain as is often the case

with many model compilers. In addition, while many

model compilers are “black box” in the sense that a

change to the generated code often requires a change

to the compiler’s code, AXIOM attempts to take a

“white box” approach by externalizing the various

transformation rules and templates. This approach al-

lows for the reuse of the templates and transformation

rules across different applications rather than binding

them to only a single application.

AXIOM also has some limitations. First, AXIOM

only honors a subset of the available UML diagrams,

speciﬁcally class diagrams and state charts. Other

UML diagrams may provide additional beneﬁts, but

AXIOM:AModel-drivenApproachtoCross-platformApplicationDevelopment

Figure 8: Screen shots of generated application on iOS.

are currently unrecognized. Second, AXIOM cannot

easily make up for the limitations of a given platform,

a challenge for any MDE approach. Finally, AXIOM

deviates from the standard OMG deﬁnition of MDA

by using a DSL for its representation rather than a

MOF-based metamodel.

8 THE PROTOTYPE AND

PRELIMINARY RESULTS

A proof-of-concept prototype tool has been devel-

oped to demonstrate the feasibility of AXIOM. The

prototype targets two popular mobile platforms: An-

droid and iOS. AXIOM models can be transformed

into native implementations in Java for Android

and Objective-C for iOS. The generated application

source code is then compiled using the native SDKs

on the target platform to produce executable appli-

cations. The design of the generated code follows

the common MVC architecture. Figure 8 shows the

screen shots of the iOS application generated from the

sample application described in Figure 2. An Android

implementation can also be generated.

Using the prototype tool, we conducted prelimi-

nary analyses to assess the effectiveness of AXIOM.

Using a small set of working examples (n = 29), we

compared the sizes of the AXIOM intent models and

the generated source code on both iOS and Android

platforms. Our assumptions are that: a) developer

productivity measured in lines-of-code per person-

hour (LOC/PH) is roughly constant regardless of lan-

guages used; and b) the native applications produced

by the prototype tool are comparable in size and com-

plexity to the same applications developed manually.

An admittedly subjective review of the code gener-

ated by AXIOM is that it is consistent with industry

best-practices such as separation of concerns and the

corresponding creation of appropriate abstraction lay-

ers.

Under these assumptions the reduction in the size

of the AXIOM intent models compared to the size of

the generated applications would translate into a sig-

niﬁcant reduction in development time, hence an in-

crease in development productivity. Based on our pre-

liminary studies, shown in Table 1, the median size (in

LOC) of the AXIOM intent models is 7% of the size

of the generated applications for Android and about

10% of the size of the generated applications for iOS.

Similarly, Kennedy’s relative power met-

ric (Kennedy et al., 2004), ρ

, also based on LOC,

measures the impact of AXIOM on developer pro-

ductivity. Kennedy’s relative power metric is given

by:

(P)

(1)

where I

and I

are the lines of native and AX-

IOM code respectively that are required to implement

application P.

These early results suggest a potentially signif-

icant increase in productivity when compared with

manually developed applications using standard de-

velopment tools on native mobile platforms.

9 RELATED WORK

9.1 Model-driven Engineering

There are different approaches to MDE. Some of

these closely follow the MDA standard while others

amend either the MDA process or its deliverables.

AndroMDA (Bohlen et al., 2003) is an open-

source, UML-based, template-driven MDA frame-

work. It accepts UML models in an XMI format and

uses them for code generation. AndroMDA is not a

modeling environment and is thus limited by the qual-

ity of the XMI output produced by other tools.

The Eclipse Foundation provides UML-based

technologies that support MDD in terms of both

model construction and model transformation. These

projects include Generative Modeling Technologies

(GMT) (The GMT Team, 2005) and the ATL Trans-

formation Language (ATL) (The ATL Team, 2005).

Executable UML (xUML) is an approach to

software development that uses UML models as

the primary mechanism by which applications are

built (Mellor and Balcer, 2002). Like AXIOM, xUML

advocates the beneﬁts of UML executability. One sig-

niﬁcant challenge of xUML is that the process of writ-

ing a model compiler may require as much effort as

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

Table 1: LOC of intent model vs. generated code.

(n = 29) AXIOM iOS Android

AXIOM as % of ρ

compared to

iOS Android iOS Android

Median 19.5 168.0 279.0 10.3 7.0 8.6 14.3

Average 27.2 222.1 328.5 11.5 7.7 8.2 12.1

Minimum 8.0 126.0 77.0 5.8 3.2 15.8 9.6

Maximum 98.0 539.0 646.0 31.9 15.2 5.5 6.6

producing the original models. There are examples

of publicly available xUML compilers such as xUml-

Compiler (xUML Compiler, 2009), but each compiler

targets a speciﬁc set of technologies for its code gen-

eration processes.

There have also been attempts to introduce

more formalism into MDE. Examples include Al-

loy (Jackson, 2002), UML Speciﬁcation Environ-

ment (USE) (Gogolla et al., 2007; Kuhlmann and

Gogolla, 2008), Z (Clarke et al., 1996; Hamil-

ton et al., 1995) and its object-oriented extensions

like MooZ (Meira and Cavalcanti, 1990), Object-

Z (Smith, 2012), OOZE (Alencar and Goguen, 1991),

Z++ (Lano, 1991), and ZEST (Cusack and Rafsan-

jani, 1992).

The overall process of MDE has also been ex-

amined for ways to improve on its ability to deliver

applications. Continuous Model Driven Engineering

(CMDE) as deﬁned by eXtreme model-driven design

(XMDD) (Margaria and Steffen, 2008) uses process

modeling as its means of eliciting the necessary re-

quirements and behavior. Agile Model Driven Devel-

opment (AMDD) (Ambler, 2009) shares the notations

and tools commonly used in MDD but retains code as

the central focus of the development effort. AMDD

has been executed in combination with the MIDAS

framework (C

aceres et al., 2004; C

aceres et al., 2003)

as a means of implementing web-based applications.

Each of these approaches takes a slightly different

approach to MDE and thus has its own challenges.

Many of the approaches are deeply rooted in UML

and thus suffer from UML’s shortcomings including

the lack of ﬁrst-class support for UI design. Ap-

proaches that rely on the creation of custom model

compilers or transformations simply shift the devel-

opment burden from the application and its models

to the transformation framework. Most formal ap-

proaches were never designed for MDE and thus do

not provide true model executability. Approaches that

change the overall MDD process either lose model-

centricity or are rooted in notations that deviate from

mainstream UML.

AXIOM encourages the development of exe-

cutable models using a DSL that supports interac-

tion, UI and domain design while also retaining the

widely adopted graphical notation associated with

UML class and state diagrams.

9.2 DSL-based Development

One approach for cross-platform mobile application

development is to use languages and virtual machines

that are common across different platforms, such as

HTML and While this approach is adequate for cer-

tain types of applications, it has known shortcomings

and limitations. Canappi (Convergence Modelling

LLC., 2011) uses a DSL to deﬁne and generate cross-

platform mobile applications as front-ends to web ser-

vices. Unlike AXIOM, it allows neither access to na-

tive APIs nor customizable code generation.

WebDSL and Mobl (Visser et al., 2010; Hammel

et al., 2010) are two DSLs that target web and mo-

bile applications speciﬁcally. WebDSL is similar to

Ruby’s Rails and Groovy’s Grails in that it allows for

the rapid development of applications using a custom

DSL. However, neither Mobl nor WebDSL addresses

the model-driven aspect of the development process.

Thus while the DSL code may indeed be ultimately

transformed into executable code, the models them-

selves are not executable and are not considered major

artifacts of the software development process.

AXIOM is partly based on the ZOOM (Liu and

Jia, 2010; Jia et al., 2007; Jia et al., 2008) project as

well as on OMG’s MDA. AXIOM retains some key

parts of UML, such as state and class diagrams, but

unlike MDA, AXIOM deﬁnes a domain-speciﬁc mod-

eling notation and a transformation framework that is

not based on MOF.

10 FUTURE WORK

Our research into the AXIOM approach is in its early

stages yet, but the preliminary results are promising.

We intend to continue reﬁning the approach so that it

can work with even more complex models. One key

area of work that remains is the further development

AXIOM:AModel-drivenApproachtoCross-platformApplicationDevelopment

of the rule-based transformations and the associated

templates. In particular these transformations must

be able to handle cases where given functionality is

supported to different extents on different platforms.

Some of those challenges have already been encoun-

tered and addressed in the user interface, but other

such challenges remain such as the implementation

of persistence.

Another area that remains to be addressed is the

introduction of non-functional requirements into the

models and the various decisions that advise the struc-

tural and reﬁning transformations. Such architectural

concerns are central to the ability to model and trans-

form an application for a particular platform. For ex-

ample, it would be desirable for the model transfor-

mations to choose algorithms that are appropriate for

each target platform’s memory and persistent storage

characteristics.

These enhanced models will be used to drive com-

parative experiments to determine if the early bene-

ﬁts seen in the preliminary results continue to man-

ifest as the scale and complexity of the applications

increases, particularly in the areas of developer pro-

ductivity, generated source code quality, and the run-

time performance, efﬁciency and defect densities of

the executable application.

11 CONCLUSIONS

AXIOM is a model-driven approach for developing

high quality, cross-platform applications. We have

successfully demonstrated its feasibility in develop-

ing cross-platform mobile applications for Android

and iOS platforms. AXIOM uses a DSL to provide

a high level abstraction of mobile platforms. Applica-

tions are represented as intent models using the DSL

and are then augmented with structural decisions and

reﬁned with other platform-speciﬁc elements during a

multi-phase transformation process to produce source

code for native applications.

The potential beneﬁts of AXIOM include signif-

icant cost savings in software development owing to

dramatic increases in productivity. AXIOM supports

executable models, which enable iterative and incre-

mental development and allow early validation of the

applications. Product quality can be signiﬁcantly im-

proved due to the reduced amount of hand-written

code. The highly customizable transformation pro-

cess offers a high degree of control over code genera-

tion.

Our preliminary ﬁndings in terms of the potential

gains in productivity are promising. We intend to fur-

ther enhance the prototype tool to provide more com-

prehensive support of mobile platforms. This will en-

able us to conduct more extensive comparative stud-

ies and experiments using AXIOM. We plan to collect

and analyze data in a number of different aspects, in-

cluding developer productivity, the source code qual-

ity of generated applications, and the performance, ef-

ﬁciency and defect density of generated applications.

REFERENCES

Alencar, A. J. and Goguen, J. A. (1991). OOZE: An object

oriented Z environment. In ECOOP’91, pages 180–

199.

Ambler, S. (2009). Agile model driven

development (AMDD): The key to

scaling agile software development.

http://www.agilemodeling.com/essays/amdd.htm/.

Bohlen, M., Brandon, C., et al. (2003). AndroMDA.

http://www.andromda.org/docs/index.html.

aceres, P., Daz, F., et al. (2004). Integrating an Agile Pro-

cess in a Model Driven Architecture.

aceres, P., Marcos, E., et al. (2003). A mda-based ap-

proach for web information system development. In

Proceedings of Workshop in Software Model Engi-

neering.

Clarke, E. M., Wing, J. M., et al. (1996). Formal methods:

state of the art and future directions. ACM Computing

Surveys, 28:626–643.

Convergence Modelling LLC. (2011). Canappi.

http://www.canappi.com/.

Cusack, E. and Rafsanjani, G.-H. B. (1992). Zest. In Ob-

ject Orientation in Z, Workshops in Computing, pages

113–126. Springer.

Ellis, M. A. and Stroustrup, B. (1990). The Annotated C++

Reference Manual. Addison Wesley.

France, R. B., Ghosh, S., Dinh-Trong, T., and Solberg, A.

(2006). Model-driven development using UML 2.0:

Promises and pitfalls. Computer, 39(2):59–66.

Gogolla, M., B

uttner, F., et al. (2007). USE: A UML-Based

Speciﬁcation Environment for Validating UML and

OCL. Science of Computer Programming, 69:27–34.

Gosling, J., Joy, B., et al. (2000). The Java Language Spec-

iﬁcation, 2nd Edition. Addison Wesley.

Hamilton, D., Covington, R., et al. (1995). Experiences in

applying formal methods to the analysis of software

and system requirements. Industrial-Strength Formal

Speciﬁcation Techniques, Workshop on, 0:30.

Hammel, Z., Visser, E., et al. (2010). mobl: the new lan-

guage of the mobile web. http://www.mobl-lang.org/.

Henderson-Sellers, B. (2005). UML - the good, the bad or

the ugly? perspectives from a panel of experts. Soft-

ware and System Modeling, 4(1):4–13.

Jackson, D. (2002). Alloy: a lightweight object mod-

elling notation. ACM Trans. Softw. Eng. Methodol.,

11(2):256–290.

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

Jia, X. et al. (2007). Executable visual software model-

ing:the ZOOM approach. Software Quality Journal,

15(1).

Jia, X., Liu, H., et al. (2008). A model transforma-

tion framework for model driven engineering. In

MSVVEIS-2008, Barcelona, Spain.

Kennedy, K., Koelbel, C., et al. (2004). Deﬁning and mea-

suring the productivity of programming languages.

The International Journal of High Performance Com-

puting Applications, (18)4, Winter, 2004:441–448.

Kernighan, B. and Ritchie, D. (1988). The C Programming

Language, 2nd Edition. Prentice Hall.

Kuhlmann, M. and Gogolla, M. (2008). Modeling and

Validating Mondex Scenarios Described in UML and

OCL with USE. Formal Aspects of Computing,

20(1):79–100.

Lano, K. (1991). Z++, an object-orientated extension to

z. In Proceedings of the Fifth Annual Z User Meeting

on Z User Workshop, pages 151–172, London, UK.

Springer-Verlag.

Liu, H. and Jia, X. (2010). Model transformation using a

simpliﬁed metamodel. In Journal of Software Engi-

neering and Applications, pages 653–660.

Lundell, B., Lings, B., et al. (2006). UML model inter-

change in heterogeneous tool environments: An anal-

ysis of adoptions of XMI 2. In MoDELS 2006, Gen-

ova, Italy, pages 619–630.

Margaria, T. and Steffen, B. (2008). Agile it: Thinking

in user-centric models. In Margaria, T. and Steffen,

B., editors, ISoLA, volume 17 of Communications in

Computer and Information Science, pages 490–502.

Springer.

Meira, S. R. L. and Cavalcanti, A. L. C. (1990). Modu-

lar Object-Oriented Z Speciﬁcations. In Nicholls, J.,

editor, Z User Workshop, Workshops in Computing,

pages 173 – 192, Oxford - UK. Springer-Verlag.

Mellor, S. J. and Balcer, M. J. (2002). Executable UML: A

Foundation for Model-Driven Architectures. Addison-

Wesley Longman Publishing Co., Inc., Boston, MA,

USA. Foreword By-Ivar Jacoboson.

Object Management Group (2003a). MDA guide.

http://www.omg.org/mda.

Object Management Group (2003b). UML 2.0 OCL.

http://www.omg.org/docs/ad/03-01-07.pdf.

Object Management Group (2006). OMG’s MetaObject Fa-

cility. http://www.omg.org/spec/MOF/2.0/PDF/.

Object Management Group (2007). XML

model interchange (XMI), version 2.11.

http://www.omg.org/spec/XMI/2.1.1/.

Object Management Group (2010). Uniﬁed Modeling Lan-

guage. http://www.omg.org/spec/UML/2.3/.

Object Management Group (2011). Success stories.

http://www.omg.org/mda/products success.htm/.

Rocher, G., Ledbrook, P., et al. (2009). GORM -

standalone GORM. http://www.grails.org/GORM+-

+StandAlone+Gorm.

Selic, B. (2003). The pragmatics of model-driven develop-

ment. IEEE Software, 20(5):19–25.

Smith, G. (2012). Object-Z.

http://itee.uq.edu.au/ smith/objectz.html.

The ATL Team (2005). ATL Transformation Language.

http://eclipse.org/atl/.

The GMT Team (2005). GMT Project.

http://www.eclipse.org/gmt/.

Visser, E. et al. (2010). WebDSL. http://webdsl.org/home.

xUML Compiler (2009). xUML Compiler- Java Model

compiler Based on “Executable UML” proﬁle.

http://code.google.com/p/xuml-compiler/.

AXIOM:AModel-drivenApproachtoCross-platformApplicationDevelopment