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-specific
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 benefits that traditional mod-
eling languages do not provide. One area that can benefit 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 flexible 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-
specific 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 benefits, MDE faces signifi-
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 benefits 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 benefits 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
defining 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 specific 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 profiles.
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
Copyright
c
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 define platform in-
dependentmodels. This allows the softwarearchi-
tecture, design, and logic to be defined completely
and separately from implementation concerns.
Customizable model transformations that allow
for flexibility in defining 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 flexibility that modelers have enjoyed
with UML, which is the ability to define 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 definition 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 verification 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 specific frame-
works and libraries are always language and platform
specific 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 defining
platform independent models without the benefits 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, conflict resolu-
tion and the ability to revert to earlier versions of the
model are all examples of problems that require tool-
specific 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 final 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 significant development (Heijstek
and Chaudron, 2010). On the other hand, if the gen-
erated code is only a skeleton to be fleshed 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 significant.
3.4 Incompatibility with Agile Software
Development Methodologies
At first 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 final, 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 benefit 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 benefits of UML while compensating for
its deficiencies.
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 specifics 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 define what they know, when they know it,
and to fill 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-specific 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-specific 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 sufficiently 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 significantly 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 specification 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 defining 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. Groovys annotation
mechanism is used to support MDE stereotypes and
profiles. 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 first 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 defined. 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 defining the UML state
diagram as a DSL. State diagrams are used to de-
fine 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 define
behavioral logic is cognitively more natural than us-
ing linear textual code and allows us to retain one of
the major benefits 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 simplified metamodel.
6 DISCUSSION
6.1 Benefits
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 flexibility 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 configurable type inferencing that would permit
modelers and developers to define 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-
nificantly 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-
efit 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 fluent 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 files 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 unified 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 benefits provided by this
synthesis are significant. 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 verified. 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 significant 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, Verification 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
simplified 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