DYNAMIC LANGUAGES AS MODELING NOTATIONS

IN MODEL DRIVEN ENGINEERING

Xiaoping Jia and Chris Jones

College of Computing and Digital Media, DePaul University, 243 S. Wabash Ave., Chicago, IL, U.S.A.

Keywords:

Model driven engineering, Dynamic language, Modeling language.

Abstract:

There has been a gradual but steady convergence of dynamic programming languages with modeling lan-

guages. Modern dynamic languages such as Groovy and Ruby provide for the creation of domain-speciﬁc

languages that can provide a level of abstraction comparable to that of modeling languages such as UML. This

convergence makes dynamic languages suitable as modeling languages but with beneﬁts that traditional mod-

eling languages do not provide. One area that can beneﬁt from this convergence is model driven engineering.

By using a dynamic language as an augmentation to MDE’s traditional UML notation, it is possible to create

models that are executable, exhibit ﬂexible type checking, and which provide a smaller cognitive gap between

business users, modelers and developers.

1 INTRODUCTION

Programming languages and modeling languages are

gradually but steadily converging. Languages such as

Groovy and Ruby allow for the creation of domain-

speciﬁc languages (DSLs), which are languages that

describe a particular problem domain. DSLs can pro-

vide a level of abstraction comparable to modeling

languages like UML.

UML is itself a DSL that describes software mod-

els. While it has always captured critical informa-

tion such as the structural and behavioral aspects of

software, UML has evolved to include the Object

Constraint Language (OCL), the MetaObject Facility

(MOF) and XML Metadata Interchange (XMI). This

evolution has made UML and its related standards

the backbone of another, more ambitious approach

to software development: model driven engineering

(MDE).

MDE hasthe potential to delivergreat cost savings

in software development by automating many time-

consuming and error-prone tasks such as detailed de-

sign, coding, and testing. These savings are com-

poundedwhen one application can be deployed across

diverse operating systems and hardware platforms,

such as is the case with mobile applications.

Despite its potential beneﬁts, MDE faces signiﬁ-

cant challenges to its adoption including: limitations

of UML; inadequate tool support; model transforma-

tion complexity; and its apparent incompatibility with

popular Agile software development methodologies.

In this paper we describe MDE as it exists today

and discuss the possible beneﬁts of adopting a new

modeling notation that is based both on a dynamic

language and UML. Section 2 gives an overview of

MDE and dynamic languages. Section 3 examines

the challenges facing MDE in greater detail. Section 4

introduces dynamic languages and describes their use

in Agile methodologies. In section 5 we propose an

approach, called AXIOM, that brings MDE and dy-

namic languages together and Section 6 examines the

potential beneﬁts of that synergy. Finally, section 7

provides our conclusions and closing thoughts.

2 BACKGROUND

2.1 Model Driven Engineering

Model driven engineering builds software systems by

deﬁning platform independent models (PIMs), which

capture the compositions and the core functionalities

of the system in a way that is independent of im-

plementation concerns. The PIMs are transformed

into platform speciﬁc models (PSMs) from which ex-

ecutable code is ultimately generated. MDE shifts

the development focus away from writing code (Selic,

2003) and toward the development of visual models

such as those in UML and its proﬁles.

220

Jia X. and Jones C..

DYNAMIC LANGUAGES AS MODELING NOTATIONS IN MODEL DRIVEN ENGINEERING.

DOI: 10.5220/0003607102200225

In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 220-225

ISBN: 978-989-8425-77-5

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

Some key characteristics of MDE include:

• An emphasis on visual modeling that allows com-

ponents and relationships to be viewed in a more

comprehensible form. This is critical in dealing

with complex, large-scale software systems.

• The use of a high-levelabstract modelingand con-

straint language like UML to deﬁne platform in-

dependentmodels. This allows the softwarearchi-

tecture, design, and logic to be deﬁned completely

and separately from implementation concerns.

• Customizable model transformations that allow

for ﬂexibility in deﬁning the PIMs and realizing

their corresponding PSMs.

2.2 Dynamic Languages

While MDE is based on UML, most software devel-

opment still relies on programming languages such

as Java or Groovy. Dynamic languages like Groovy

often infer data types based on program execution

rather than requiring that those type be explicitly de-

clared in the program source code. This is fundamen-

tally different from static languages, where data types

must be explicitly declared before the code is even

compiled. Dynamic languages give developers the

same kind of ﬂexibility that modelers have enjoyed

with UML, which is the ability to deﬁne only what is

needed, when it is needed.

Dynamic languages are increasingly popular, es-

pecially in software development projects using Agile

methodologies. This is in part because of their expres-

sive syntax, but also because they often support a high

level of abstraction either through the use of abstract

data types or through the deﬁnition of DSLs. Such

DSLs lend themselves to writing code that is expres-

sive and understandable to developers and modelers

alike.

3 CHALLENGES OF MDE

MDE has proven effective and successful in many in-

dustrial enterprise applications targeting mature mid-

dleware platforms with widely adopted common stan-

dards such as JEE, .NET, and SOA (Object Manage-

ment Group, 2010). Nevertheless there remain critical

challenges to its widespread industry adoption (Uhl,

2008; Staron, 2006) including:

• Limitations of UML and its related standards.

• Inadequate tool support.

• Model transformation complexity.

• Incompatibility with agile methodologies.

3.1 Limitations of UML

UML and its related standards contain some inherent

weaknesses (France et al., 2006; Henderson-Sellers,

2005). First, UML models can be incomplete and/or

inconsistent (Lange et al., 2003) and the OCL, which

provides a degree of formalism to those models, has

an awkward, non-intuitive syntax that limits its prac-

tical usefulness. Second, UML is not executable,

which means that model veriﬁcation is limited to in-

spections and model checkers. While there are ex-

ecutable extensions to UML such as xUML (Mel-

lor and Balcer, 2002), support for such extensions

varies widely. Third, UML lacks powerful model-

ing frameworks and libraries. While speciﬁc frame-

works and libraries are always language and platform

speciﬁc and are therefore ill-suited for platform inde-

pendent notations such as UML, comparable frame-

works and libraries are available for most platforms

and languages. For example, Java supports the Java

Persistence API (JPA) for object-relational mapping,

whereas Ruby supports Active Record. So deﬁning

platform independent models without the beneﬁts of

such frameworks and libraries is a huge and unneces-

sary obstacle.

3.2 Inadequate Tool Support

Another obstacle to the adoption of MDE is the

limited availability and effectiveness of supporting

tools. For example, issues that are readily addressed

in source code control systems can be problems for

models. The merging of changes, conﬂict resolu-

tion and the ability to revert to earlier versions of the

model are all examples of problems that require tool-

speciﬁc solutions.

A related problem is that UML enjoys only lim-

ited support for its XMI standard, which provides for

the interchange of UML models across different UML

modeling tools. One recent study found that the suc-

cess rate for such interchange among leading UML

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

3.3 Model Transformation Complexity

The process of creating the ﬁnal executable from

MDE models is non-trivial and typically requires a

custom code generator. If the code is to be gener-

ated completely from the model, then the transforma-

tion often requires signiﬁcant development (Heijstek

and Chaudron, 2010). On the other hand, if the gen-

erated code is only a skeleton to be ﬂeshed out by

developers, then the model and the implementation

will rapidly diverge. Round-trip engineering of mod-

DYNAMIC LANGUAGES AS MODELING NOTATIONS IN MODEL DRIVEN ENGINEERING

221

els from code is often inadequate in practice, so this

divergence must be avoided if the model isn’t to be a

throwaway artifact. Since a key tenet of MDE is the

ability to generate multiple PSMs from a single PIM,

this challenge is signiﬁcant.

3.4 Incompatibility with Agile Software

Development Methodologies

At ﬁrst glance, MDE appears to be incompatibile with

Agile software development approaches like eXtreme

Programming (XP) and Scrum. Agile software de-

velopment methodologies adopt the principles articu-

lated in the Agile Manifesto (Beedle et al., 2001) in-

cluding: embracing changes; refactoring throughout

the development process; using working software as

the primary measure of progress; and developing it-

eratively and incrementally. Agile methodologies re-

ject most software artifacts if they do not directly con-

tribute to the ﬁnal, working application code, an ap-

proach that is at odds with the basic premise of MDE,

which is that models are everything.

There have been several attempts to combine agile

and model driven development. Two such examples

are Agile Model Driven Development (AMDD) (Am-

bler, 2009) and Continuous Model Driven Engineer-

ing (CMDE) (Margaria and Steffen, 2009).

Agile Model Driven Development (AMDD) is an

iterative software development process that shares

the notations and tools commonly used in MDE, but

deviates from traditional MDE in one notable way:

AMDD keeps the code as the focus of the develop-

ment effort. While AMDD supports sophisticated

code-generating models, there is an explicit assump-

tion that only 5-10% of models can beneﬁt from such

treatment. Most AMDD models are strictly passive,

serving only as a communication medium, and are not

used to generate code.

Continuous Model Driven Engineering (CMDE)

combines model driven design, extreme program-

ming, and process modeling into eXtreme model-

driven design (XMDD) (Margaria and Steffen, 2008).

XMDD deviates from traditional MDE by using pro-

cess models as the means of eliciting requirements

and behavior, which allows for simulation and pro-

cess execution via BPM engines. The process models

can be decorated as needed with temporal constraints,

symbolic type information and cross-cutting concerns

and thus serve the same purpose as UML and OCL.

Both AMDD and CMDE alter the core MDE ap-

proach. In AMDD, the use of models is relegated to

a supporting role rather than being the primary focus.

In CMDE, the model retains a central role, but the

core UML foundation has been replaced with a pro-

cess model. Ideally, we would like an approach that

retains the beneﬁts of UML while compensating for

its deﬁciencies.

4 THE PROMISE OF DYNAMIC

LANGUAGES

4.1 Properties of Dynamic Languages

Many properties that are essential to modeling lan-

guages are present in modern dynamic languages.

While the speciﬁcs of each dynamic language are dif-

ferent, most of them share some common traits such

as a very succinct syntax, being interpreted, and being

dynamically or optionally typed. They often provide

abstract data types such as sets, lists, maps, iterators,

generators, and closures, and thus support high lev-

els of abstraction. The ability to use highly abstract

data types and to provide little or no type information

is extremely useful to developers because it permits

them to deﬁne what they know, when they know it,

and to ﬁll in the gaps later as more information be-

comes available.

Modern dynamic languages are highly extensi-

ble by virtue of their support for meta-programming

and domain-speciﬁc languages. This property allows

them to provide even greater levels of abstraction that

can help reduce the cognitive gap between software

designs and their implementations.

Another property of dynamic languages is their

ability to use existing frameworks and libraries. Some

dynamic languages such as Groovy are based on Java

and can use not only their own libraries and frame-

works, but all of the libraries and frameworks avail-

able to Java in general. This makes these languages

extremely powerful and reduces the amount of hand-

written code to be provided. Indeed, these libraries

and frameworks allow developers to focus on the

business-speciﬁc aspects of an application and to de-

fer the lower-level details until necessary.

4.2 Dynamic Languages in Agile

Software Development

While Agile methodologies can be applied to soft-

ware development using any language, of particu-

lar interest is one branch of Agile methods using

dynamic languages and their associated frameworks.

This style of Agile development, pioneered by Ruby

on Rails, has gained a great deal of popularity. How-

ever, Agile development methods using dynamic lan-

guages have not been widely adopted in critical en-

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

222

terprise applications. One reason is that the runtime

environments are not yet considered sufﬁciently ma-

ture, robust, and trustworthy as compared to JEE or

.NET. Furthermore, there are inherent risks with dy-

namic typing and meta-programming, which allow

new kinds of application defects to be introduced and

which may signiﬁcantly impact application perfor-

mance.

5 THE AXIOM APPROACH

Our approach, called AXIOM, uses a dynamic lan-

guage to augment UML as the core MDE modeling

notation. The prototype of AXIOM uses Groovy, but

in principle any modern dynamic language could be

used.

5.1 Core Modeling Notation

Groovy is executable and supports many of the fea-

tures found in traditional speciﬁcation and constraint

languages such as Z and OCL including: high-level

abstract data types such as sets, bags, lists, maps, and

relations; high-level constructs such as iterators and

closures; and extensivesupport of object-orientedfea-

tures including mix-ins, categories, and delegations.

Groovy already supports the important features nec-

essary for adequately deﬁning constraints in object-

oriented models. Groovy is fully compatible with the

Java language and JVM, a mature runtime environ-

ment with extensive libraries and frameworks and a

broad install base. Groovy is highly extensible be-

cause of its meta-programmingcapabilities, which al-

lows additional features to be added to the base lan-

guage in the form of DSLs.

AXIOM uses only the subset of Groovy’s features

that are suited to modeling. A few simple extensions

are added to Groovy to provide useful modeling con-

cepts that are not natively supported, such as asso-

ciations and design contracts. Groovy’s annotation

mechanism is used to support MDE stereotypes and

proﬁles. In addition, we augment the Groovy lan-

guage in two notable ways. First, we provide dual

visual and textual representations that are consistent

with a subset of UML. Second, we add a state ma-

chine mechanism based on the UML state diagram to

act as a coordinator for the various application com-

ponents.

5.1.1 Visual Representation

Since visual modeling is one of the cornerstones of

MDE, our ﬁrst major augmentationto the Groovy lan-

guage is to have complete and interchangeable visual

and textual representations of all models. The con-

crete syntax of both visual and textual representations

will be formally deﬁned. The textual representation

is human readable Groovy code. The visual represen-

tations are based on, and are consistent with, UML

class and state diagrams.

5.1.2 Dynamic Modeling

The second major augmentation to Groovy is to pro-

vide visual formalism by deﬁning the UML state

diagram as a DSL. State diagrams are used to de-

ﬁne behavioral logic, which is important in many

control-oriented, multi-threaded applications such as

real-time control systems, mobile applications, com-

puter games, and animations. State diagrams are

also amenable to an analysis of certain concurrency-

related properties (Yu et al., 2008; Paltor and Lilius,

1999). Furthermore, using state diagrams to deﬁne

behavioral logic is cognitively more natural than us-

ing linear textual code and allows us to retain one of

the major beneﬁts of UML, which is improved com-

munication between business users, modelers and de-

velopers.

5.2 Prototype

Preliminary work on the AXIOM models and tools is

already underway. As shown in Figure 1, simple AX-

IOM models can currently be transformed into imple-

mentations in Java and Objective-C. Our goal is to

fully develop the model transformation tool so that it

can be used in case studies to demonstrate the feasibil-

ity of the AXIOM approach by transforming AXIOM

models of mobile applications into implementations

for the Android (Java) and iPhone OS (Objective-C)

platforms.

Figure 1: AXIOM development approach.

The AXIOM modeling tool supports two perspec-

tives, one for the textual representation and one for

the visual representation. Models can be created and

manipulated either textually or visually and alternated

between the two. Switching between the two perspec-

DYNAMIC LANGUAGES AS MODELING NOTATIONS IN MODEL DRIVEN ENGINEERING

223

tives automatically triggers the conversion from one

representation to the other.

AXIOM is based on the prior research of the

ZOOM (Z-based Object-Oriented Modeling) (Jia

et al., 2007; Jia et al., 2008) and HRMT (Hierarchi-

cal Relational Metamodel Transformation) (Liu and

Jia, 2010) projects. ZOOM is an extension of OCL

that is based on Z. HRMT, based on ZOOM, is a

template-based model transformation framework that

uses a simpliﬁed metamodel.

6 DISCUSSION

6.1 Beneﬁts

The AXIOM approach of augmenting UML with

a dynamic language makes MDE accessible to a

broader range of applications than MDE with UML

alone. This is because AXIOM addresses the chal-

lenges of MDE by combining the model-centricity of

UML with the ﬂexibility of a dynamic language.

6.1.1 Flexible Typing

Most dynamic languages are optionally typed, so de-

velopers can provide as much or as little type infor-

mation as desired. It is possible to imagine tools us-

ing conﬁgurable type inferencing that would permit

modelers and developers to deﬁne a scale of typing

strictnesses. Such a scale could be used within the

models to ensure that enough type information has

been providedto avoid common type-checking errors.

Minimal type information could be provided during

the early stages of a project when requirements are

changing rapidly. More type information could then

be added as an application matures and code quality

becomes of greater importance.

6.1.2 Model Executability

In addition to being optionally typed, dynamic lan-

guages are executable. This means that DSLs built

using those languages, and thus the models based on

those DSLs, are also executable. This executability

can reduce the cycle times between modeling, imple-

mentation and testing. Similarly, errors in the models

can be discovered and addressed quickly. This in turn

facilitates MDE that is targeted to smaller, more Agile

software development efforts, where minimal time is

spent in the development of classic design artifacts in

favor of working, executable code.

6.1.3 Frameworks & Libraries

Because all model code is native dynamic language

code, the models themselves can takeadvantage of the

vast assortment of frameworks and libraries available

to the underlying programming language and plat-

form. The ability to draw upon such artifacts can sig-

niﬁcantly reduce the time needed to create and up-

date the models. In addition, the code generated from

the PSM will be improved because it can draw upon

industry-standard technologies and techniques. For

example, Groovy can fully leverage all the frame-

works and libraries available for Java, such as EJB,

Spring, Android and others. The availability of this

extensive collection of runtime frameworks and li-

braries removes one of the major obstacles to MDE.

6.1.4 Reduced Cognitive Gap

The use of dynamic languages as modeling languages

also ensures less of a cognitive gap between business

users, modelers and developers, making it more at-

tractive to smaller-scale development efforts or those

projects following an Agile methodology. This ben-

eﬁt is derived in two ways. First, a DSL is built that

allows for high-level reasoning about the application.

Second, because the DSL and all model represen-

tations are in a single language, it is comparatively

simple for someone ﬂuent in that language to under-

stand the DSLs and their models as well as any lower-

level code that is required to transform those mod-

els. This approach permits both kinds of MDE: com-

pletely generative, where all of the code comes from

the model, and partially generative, where only skele-

ton code is generated that must then be completed by

a developer. Because only a single language is used, it

may also be easier to provide round-trip engineering

if necessary.

6.1.5 Improved Model Interchange

The use of a dynamic language as a modeling lan-

guage also helps eliminate one of the most trouble-

some aspects of MDE, which is the need for model

interchange using XMI and the varying degrees to

which it is supported. By using a programming lan-

guage the interchange becomes one of syntax rather

than of model representation. Sophisticated modeling

tools are not required, even though they will certainly

be useful, and issues such as the merging of, reverting

of and overall control of the modeling ﬁles can easily

be handled by existing source code control systems

like CVS, Subversion or Git.

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

224

6.2 Limitations & Challenges

The AXIOM approach has several limitations and

challenges. First, it deviates slightly from the clas-

sic MDE approach. Second, it may prove chal-

lenging to achieve true platform independence even

though Groovy compiles to JVM bytecode and is thus

portable. This may prove particularly challenging

when the target platform is not Java-based as is the

case with the iPhone OS. Third, there is limited tool

support for this approach. While many tools support

UML models or Groovy code in isolation, AXIOM

requires that they be uniﬁed and interchangeable.

7 CONCLUSIONS

Through the use of dynamic languages, model driven

engineering becomes more feasible than if it remains

bound solely to UML. Existing MDE models suffer

from UML limitations, a lack of adequate tool support

and limited access to useful frameworks and libraries.

AXIOM’s goal is to evolve MDE by augmenting

UML with a dynamic language and while there are

challenges to overcome, the beneﬁts provided by this

synthesis are signiﬁcant. Many dynamic languages

support high degrees of abstraction in the form of

DSLs. Models based on these languages have ac-

cess to all of the language’s libraries and frameworks.

Tool support for these models is readily available in

the form of existing text editors and source code con-

trol systems, which provide well understood means

of model interchange. Finally, dynamic languages

yield executable models, which can be rapidly val-

idated and veriﬁed. By retaining the key visual el-

ements of UML, these models remain accessible to

modelers and developers alike.

The AXIOM approach will yield models that are

faster to develop, easier to verify, and which will be

compatible with mainstream Agile methodologies. If

AXIOM’s promise is realized, it has the potential to

deliver signiﬁcant cost savings, particularly for cross-

platform application development, while improving

overall application quality.

REFERENCES

Ambler, S. (2003-2009). Agile model

driven development (AMDD): The key

to scaling agile software development.

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

Beedle, M. et al. (2001). Manifesto for agile software de-

velopment. http://agilemanifesto.org/.

France, R. B. et al. (2006). Model-driven development

using UML 2.0: Promises and pitfalls. Computer,

39(2):59–66.

Heijstek, W. and Chaudron, M. R. (2010). The impact of

model driven development on the software architec-

ture process. Software Engineering and Advanced Ap-

plications, Euromicro Conference, 0:333–341.

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.

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

ing:the zoom approach. Software Quality Journal,

15(1).

Jia, X. et al. (2008). A model transformation framework for

model driven engineering. In Workshop on Modelling,

Simulation, Veriﬁcation and Validation of Enterprise

Information Systems, 2008, Barcelona, Spain.

Lange, C. et al. (2003). An empirical investigation in quan-

tifying inconsistency and incompleteness of uml de-

signs. In Incompleteness of UML Designs, Proceed-

ings of the IEEE Workshop on Consistency Problems

in UML-based Software Development, 6th Intl. Con-

ference on UML, pages 26–34.

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

simpliﬁed metamodel. Journal of Software Engineer-

ing and Applications, 3(7):653–660.

Lundell, B. et al. (2006). UML model interchange in hetero-

geneous tool environments: An analysis of adoptions

of XMI 2. In MoDELS 2006, pages 619–630.

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

user-centric models. In ISoLA 2008, pages 490–502.

Margaria, T. and Steffen, B. (2009). Continuous model-

driven engineering. Computer, 42(10):106–109.

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

Foundation for Model-Driven Architectures. Addison-

Wesley, Boston, MA, USA.

Object Management Group (2010). Success stories.

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

Paltor, I. and Lilius, J. (1999). Formalising uml state ma-

chines for model checking. In UML, pages 430–445.

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

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

Staron, M. (2006). Adopting model driven software devel-

opment in industry - a case study at two companies.

In MoDELS 2006, pages 57–72.

Uhl, A. (2008). Model-driven development in the enter-

prise. IEEE Software, 25(1):46–49.

Yu, L. et al. (2008). Scenario-based static analysis of uml

class models. In MoDELS 2008, pages 234–248.

DYNAMIC LANGUAGES AS MODELING NOTATIONS IN MODEL DRIVEN ENGINEERING

225