Model-driven Engineering Tool Comparison for Architectures within
Heterogenic Systems for Electric Vehicle
Sebastian Apel, Marianne Mauch and Volkmar Schau
Department of Computer Science, Friedrich Schiller University Jena, Ernst-Abbe-Platz 2, 07743, Jena, Germany
Keywords:
Software Architecture, Code Generator, Model-driven Engineering, Electric Vehicles, Logistic, Freight
Transportation.
Abstract:
System landscapes within logistical scenarios is highly heterogenic. Adding specific mechanisms, e.g. to
support planing, monitoring and analyses for fully electrical powered vehicles, could become a mess or at
least a challenge. While our project Smart City Logistic (SCL) is trying to manage this extension for multiple
logistic scenarios, other projects want to do comparable system extensions as well. The following approach
tries to evaluate how model-driven engineering (MDE) combined with generative frameworks can support the
transfer from platform independent models to deployable solutions within the logistical domain. This paper
compares specific MDE tools which can be used to support such a framework.
1 INTRODUCTION
Enabling inner-city logistics with fully electrical pow-
ered vehicles is a challenge. Exploring the reasons be-
hind this challange will lead to infrastructural issues,
like missing charging stations, but also to missing
trust in predicted ranges. The German Federal Min-
istry for Economic Affairs and Energy (BMWi) initi-
ated the collaborative research project SCL to support
this field of application. So the project combines an
intelligent route planning system with dynamic range
prediction, based on the detailed knowledge of major
influencing factors. The SCL information and com-
munication technology (ICT) system is able to sup-
port dispatchers and drivers with real-time feedback,
optimizing the driving style and providing alternatives
for successful ends of planned tours.
These goals will be achieved by using three main
components: (1) a mobile assistance client for drivers
to display real-time information with offline capabili-
ties, (2) a hardware telematic unit, connected with the
Electric vehicle (EV) on-board electronic, collecting
and broadcasting required data as well as (3) a cen-
tralized server to manage, analyse and persist infor-
mation about transmitted data and offer planned tours.
But the challenge of those kind of systems, to enable
EVs in specific scenarios, is to embed them in highly
closed logistic system landscapes.
This model-driven architecture (MDA) tool com-
parison will proof, how model-driven engineering and
generic infrastructures can be used for reduction of
development effort by using already created platform-
independent model (PIM). SCL wants to use the re-
sults and knowledge about MDE tools within a gener-
ative framework for the SCL reference architecture in
ICT-systems which enables to extend existing logisti-
cal landscapes.
This paper starts with a SCL requirement engi-
neering to show a list of needs for this EV-domain by
analysing the logistical partners. The results are used
to create an architectural draft, the PIM, which shows
the main entities, components and concepts. Based
on this minimal subset of elements, used by this PIM,
simplified test cases can be re-engineered. These en-
tities will be used within multiple model-driven engi-
neering tools to generate source code and to gain an
insight into their generative capabilities.
2 REQUIREMENTS
The SCL ICT-system supports the usage of EVs by
combining components linked over different types of
communication technologies. Figure 1 gives a first in-
sight and visualizes already named main components
like the mobile assistance client, the telematic unit
and the centralized server in addition to other com-
ponents like the electronic freight monitoring and the
existing ICT-systems which SCL has to use as data
sources and sinks.
Apel, S., Mauch, M. and Schau, V.
Model-driven Engineering Tool Comparison for Architectures within Heterogenic Systems for Electric Vehicle.
DOI: 10.5220/0005803806710676
In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 671-676
ISBN: 978-989-758-168-7
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
671
Server
System
Telematic
Unit
Transport Units
Mobile
Client
External Systems
Figure 1: Simple IT-system overview of SCL.
First step was to analyse business processes in
inner-city logistic companies. These analyses were
done by interviewing actors like dispatchers and
drivers about their everyday work (Apel et al., 2014).
Which tools and software are used? Which work-
flow will be handled and which exceptions could
occur? As a result of that multiple business pro-
cesses about planning tours, handling orders, manag-
ing picking and packing and executing delivery were
created. These processes could be compared between
different companies, but they are not identical at all.
Since order handling as well as picking and packing
mostly managed by the ICT-systems, the tour plan-
ning and delivery processes is the important point to
inject additional services to handle range restrictions
of EVs. The following list of basic use cases shows
necessary elements for an extension system like SCL
that has to create.
Collection of core and runtime data, like driver,
car, customer and order data
Configurable interfaces to handle the wide range
of connectivities of transport management sys-
tem (TMS) and warehouse management system
(WMS) solutions
Calculate a forecast of energy consumption when
using EVs in a specified situation, energy opti-
mized routes by using calculation forecasts and
optimized tours by using energy optimized routes
Planning, monitoring, analyses and optimizing
tours by using core and runtime data
A knowledge base about data and dependencies
used by this system
Interfaces to gather data about weather, traffic and
vital data from EVs
Managing exceptions in case of divergences
Followed by the interviews next step was to take
a closer look at software used by logistical com-
panies. This software was found as a subset of
enterprise resource planning (ERP) software, espe-
cially the supply chain management (SCM) systems
(Chopra and Meindl, 2007). In case of inner-city lo-
gistics this would be a TMS, a WMS or an intersec-
tion of their functionalities. By analysing available
interfaces (Busch et al., 2003; Logistik Heute, 2005;
Pirron et al., 1999; Faber and Ammerschuber, 2007)
to extract order related details for tour calculations,
it is possible to find something like HTTP based in-
terfaces (for example Representational State Transfer
(REST) or Simple Object Access Protocol (SOAP))
with data representation in XML or JSON, interfaces
defined by leading companies (for example SAP), in-
terfaces for financial information like DATEV and fi-
nancial accounting, file based interfaces like spread-
sheets, ASCII or XML files, as well as interfaces
based standardized content based on electronic data
interchange (EDI) with transportation layers based on
HTTP or File Transfer Protocol (FTP) for example.
Analysing those TMS and WMS software would
not lead to commonly accepted standards for covering
a dominant set of interfaces. Each solution presents
their own interfaces. Some of them uses compara-
ble types of interfaces (like REST), other one ex-
port functionalities based on EDI, but unfortunately
no common standard at all.
Rising numbers of innovations and technologies
requires more flexibility of these closed ICT-systems.
Projects like Econnect and sMobility point out how
charging management can save the electricity infras-
tructure. Using EVs as energy buffers to keep remain-
ing energy and pass back when requested is shown in
projects like iZEUS by SAP. Finally SCL and iZEUS
shows how tour and order related data can be used
to optimize available ranges when using EVs. Wait-
ing until each TMS and WMS development company
embed each specific use case into their own solutions
the challenging launch of EVs would slow down mas-
sively.
3 ARCHITECTURE
The server architecture has to regard the
SCLrequirements and orchestrate related com-
ponents to handle tasks about planing, monitoring
and analyses of tours. Additionally, this orchestration
has to divide those tasks semantically in components
used as interfaces, views, managing or controlling, as
well as a model.
A look into related work of logistic based archi-
tectures shows several approaches improving them or
specifying the content and meaning of communica-
tions between different companies. These approaches
describe single systems, architectures or object mod-
els to manage situations within companies (Re et al., ;
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
672
Moore et al., 1996; Satapathy et al., 1998; C.Quiroga
et al., 2011). In case of adding additional services,
to handle new innovations and offer a wider field of
business models, a common procedure would be pro-
posed to extend or replace partly the existing system.
Neither SCL nor the related logistical partners don’t
want to replace their systems just to use EVs. There
is a urgent need of a supporting system which can be
used in addition to existing ICT-system landscapes.
SCL has to create an own server architecture to
handle the requirements about a system which ex-
tends existing ICT-systems. As a basic semantic
structure the server uses the Model-View-Controller
(MVC) pattern (Buschmann et al., 1996). Combin-
ing those ideas with loose dependencies, which is
required to easily extend existing systems, a spe-
cific communication between their MVC components
is required. The use of ideas of micro kernel pat-
terns (Buschmann et al., 1996) as well as mecha-
nisms within observer patterns (Gamma et al., 1994)
in combination with an enterprise service bus (Chap-
pell, 2004) leads to an architecture as shown in fig-
ure 2. Each component is a specialized micro service
for small subsets of tasks. Components can broadcast
events to everybody as well as starting a private com-
munication based on a reply to previously received
message. The common workflow for data exchange
would perform a broadcast about some specific event
with public available information. An interested com-
ponent listens for events related to those specific type
of information and can reply to this in order to ask
for more information. The original event broadcaster
would receive this reply and can decide to answer
with more detailed, mostly private information.
The architecture in figure 2, which combines the
described communication and MVC semantic, de-
fines four components used to handle model specific
tasks. The first one describes a precise range predic-
tion model (3). The input would be one or multiple
vectors of parameters which describes e.g. a road seg-
ment based on height, speed, time and weight. The
range model will use these vectors to calculate a pre-
dicted consumption based on previously learned situ-
ations. This range component can be utilized by us-
ing modified route calculations (4) getting energy op-
timized routes, which can be embedded within a third
component to calculate optimized tours (5). In addi-
tion, all related data about drivers, EVs, orders and
shipments as well as charging stations, users, compa-
nies and customers would be handled within a knowl-
edge base.
Beside model components, a bunch of compo-
nents to handle different types of requests has to be
added (2). Those components handle requests about
User
Interfaces
Components
Web View
Controller
Components
Tour Optimization
Components
Route Calculation
Components
Range Estimation
Components
Companies
Vehicles
Drivers
Charing Places
Customers
Users
Vehicle Data
Analyzes
Planning
Monitoring
IT-solution
Mobile Client
Telematic Unit
Communication Bus
System
E-Vehicles
ext. Systeme
Knowledge Base
Components
6
5
1
2
3
4
Figure 2: Architectural overview.
tasks like monitoring, planning and analyses, as well
as managing their related core data like available EVs,
drivers, users and customers in addition to basic data
like EV type data and charging places.
The last part about interfaces and views would be
the entry point for external systems into this server ar-
chitecture. Because of this wide range of in section 2
mentioned possible interfaces, data formats and pro-
tocols SCL has to use a configurable interface sys-
tem which can be easily modified to match specific
requirements. In preparation three strategies were
developed to handle communication in SCL. The
first one handles this wide range by creating a inher-
itance tree for different specializations of interfaces.
The second one use the pipeline concept (Buschmann
et al., 1996, p. 53) to split each transformation step
within a communication stack defined by the OSI ref-
erence model (ISO/IEC JTC 1, 1994). Each step like
TCP, HTTP, Transport Layer Security (TLS) can be
rearranged in a fixed order to handle a specific com-
munication stack like shown in figure 3. The last one
describes a strategy where the interface itself isn’t
handle directly. The architecture should describe a
well defined application programming interface (API)
for each existing request type. An interface developer
has to use this API and implement the whole interface
as a plugin for this system. Because of the expanding
number of dependencies in case of using of inheri-
tance trees and heavily not reusable characteristics of
an API strategy, the SCL platform uses the pipeline
strategy to get configurable interfaces.
MVC, internal communication, data model de-
fined by the knowledge base, micro services described
within components and the idea about configurable
Socket
e.g. TCP/IP
PreHandling
1
e.g. TLS
PreHandling
2
e.g. HTTP
PreHandling
n
e.g. REST
Interpreter
e.g. tour data interpreter
Figure 3: Pipeline strategy for interface components.
Model-driven Engineering Tool Comparison for Architectures within Heterogenic Systems for Electric Vehicle
673
(a)
EntityA
name : EString
doSomething()
EntityB
handleMagic(text EString) : EString
EntityC
value : EInt =
calculateIt(with EInt) : EInt
[0..1] a
[0..1] b
[0..*] cs
(b) (c)
Figure 4: Simple test model with three entities (a) mapped to EMF (b) and MagicDraw (c).
interfaces based on pipelines would be the SCL PIM.
Apart from its manual realization within this project,
SCL proves what can be generated by using MDE
tools.
4 MDE TOOLS IN PRACTISE
SCL wants to use the knowledge about the engi-
neering of embeddable logistical extension systems
to refactor a generic service framework. Based on
this requested framework, it raises the question about
which parts could be covered with generic processes.
Using everything related from the PIM about com-
ponents and interfaces would lead to a whole bunch
of entities, too much to get through available genera-
tor tools. To simplify this model for evaluating tools
an abstracted test model as shown in figure 4(a) has
to be used to reduce complexity, but reflects specific
elements from SCL. The model contains classical
attributes, single- and bidirectional associations and
methods with basic attributes and return values.
4.1 Overview
There are several tools supporting the model-driven
engineering concept. A lot of related work about how
to deal with MDA subject, available tools and case
studies were published. Beydeda (2005) summarize
projects employing MDE and Rempp (2011) intro-
duces modeling methods, languages and tools which
can be used as foundation for the SCL MDA tool
comparison. Silingas (2007) describes a conceptual
framework for model-driven development (MDD)
combined with “a case study of modeling software
for library management”. Calic (2008) on the other
hand works out criteria about an ideal MDA tool
for exemplifying the development of an architec-
ture for a glossary management tool. Finally Alford
(2013) and Silva (2010) compare different modeling
tools which can be used as a initial listing. Within
this related work tools like MagicDraw, EMF, An-
droMDA, BlueAge Forwarded, Cameo E2E Bridge,
Mia Software, Jamda, PathMATE, Rapsody, Modelio
and tools from Sparxsystem can be found.
Table 1: List of considered tools.
Name
Dependency
Runtime!
Environment (e.g.)
Licensing
Generator
Results
MagicDraw
/
plain code like C++ or
Java
Commercial
Generative
Artifcats
EMF
/
plain code like Java,
extendable with plugins
Free
Generative
Artifcats
AndroMDA
MagicDraw,
EMF or other
Java EE / .NET
Free
Generative
Artifcats
BlueAge
Forwarded
MagicDraw or
EMF
Java EE / .NET
Commercial
Full, by using
activity diagrams
Cameo E2E
Bridge
MagicDraw
Cameo E2E Bridge
Server
Commercial
Full, by using
BPMN
Some tools, like Jamda, were skipped because of
their outdated maintenance. Other tools, like Path-
MATE and Mia Software, were ignored because of
missing access through their tools. Furthermore,
some interesting tools like Rapsody from IBM, Mod-
elio from Modeliosoft or tools from Sparxsystem
were skipped in respect to project time scopes. The
chosen tools in table 1 scopes an important known
subset of available solutions.
Based on the specific SCL requirements about
creating a generative framework in addition to the
SCL reference architecture, a classification of avail-
able tools has to be done. As shown in table 1, these
classifications were done based on tool dependencies,
the corresponding runtime environment for generative
results, the offered licensing models and about their
generative capabilities (“Generator Results”).
Within the scope of SCL and based on the re-
quirement to have different kinds of generative re-
sults, three tools are selected. EMF is selected be-
cause of the internal description mechanisms. Magic-
Draw on the other hand were chosen because of the
extended modeling features within the Unified Mod-
eling Language (UML) universe. In addition to Mag-
icDraw and EMF AndroMDA were chosen because
of the capabilities to use MagicDraw and EMF Mod-
els as sources to work with an specific runtime envi-
ronment as well as the way they offer mechanisms to
extend their tool. Cameo E2E Bridge and BlueAge
Forwarded get dropped because of their required run-
time environment.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
674
4.2 Eclipse Modeling Framework
EMF as a powerful framework, embedded within the
Eclipse IDE, can be used as a code-generation facility
for building Java applications. The model created in
EMF works as a connection between XML structures,
Java code and UML diagrams. Within EMF Ecore is
used to represent a meta model to describe those mod-
els, like attributes, classes and references, and can be
used to describe each part of the domain specific ele-
ments. This is were the basic data types comes from,
e.g. integers are known as EInt, strings are known as
EString and so on. (Budinsky, 2004)
A created class diagram based on figure 4(a)
would result in something like figure 4(b). This is
nearly the same as the original diagram with slightly
modified attribute types to match the meta model from
Ecore. After creating this EMF model by using class
diagrams, it is possible to create a generator model.
Generators can be used to map this EMF model to
Java code as well as XML schemata. Looking through
generated Java code some differences between in-
tended entities within the class diagram and the gener-
ated result will be shown. Each class (EntityA, Enti-
tyB and EntityC) will be mapped through an interface.
The implementation, along attributes, can be found in
classes which implements those interfaces (e.g. En-
tityAImpl). In addition to interfaces and implemen-
tations, a couple of patterns and features can be real-
ized like factory pattern, test packages, instance edi-
tors and meta data about entities (e.g.).
4.3 MagicDraw
MagicDraw from NoMagic is an UML tool suite,
which covers most parts like class, sequence, activ-
ity, state and component diagrams. Furthermore this
tool suite has embedded generative capabilities for bi-
directional mapping between entities and source code.
The model is managed within the MagicDraws own
data format and can be exported through Ecore mod-
els to use them within EMF.
Using MagicDraw to create a class diagram from
figure 4(a) would result in something like figure 4(c),
which might be exactly the same as the intended
one. MagicDraw let you choose the required target
language by creating a specific generator. In case
of using Java as target language, MagicDraw gener-
ates, nearly out of the box, the whole entity includ-
ing method signatures and attributes. Adding stereo-
types allows MagicDraw to add functional elements
like implementations for getters and setters. In gen-
eral this generated code will be written as modelled.
Classes will be mapped through classes, interfaces
will be mapped through interfaces and generalizations
are used as intended.
4.4 AndroMDA
AndroMDA is a modularly configured and open
source MDA generator framework and is oriented to-
wards Object Management Group (OMG) MDA stan-
dard. By comparison to MagicDraw or EMF An-
droMDA doesn’t work as a modeling tool itself. This
framework refers to external tools, in detail to their
external metamodels e.g. MagicDraw or Ecore from
EMF. The central element of AndroMDA are car-
tridges. AndroMDA supports BPM4Struts, jBPM,
JSF, EJB, C++, Java and because of its modular built
structure it is extendable by adding further cartridges.
Using AndroMDA will start with several ques-
tions and guides developers to get their first starter
application. Questions about modeling tools, project
name, id, version and detailed information about type
of application to generate (e.g. rich client, j2ee), type
of packaging (e.g. EAR or WAR), type of transac-
tional / persistence cartridge (e.g. hibernate, ejb, ejb3,
spring, none), type of database backend for persis-
tence layers, type of workflow engine capabilities, as
well as web user interface. Sadly the choice about
which kind of application, furthermore the target run-
time environment and dependencies, has to be done
quite before modeling starts. AndroMDA can eas-
ily be used within a platform-specific model (PSM)
phase, when modeling has to be created from scratch.
5 CONCLUSIONS
MDE is challenging in specified use cases with pre-
defined runtime environments. This is getting much
more difficult in case of generative frameworks which
supports development processes based on a platform
independent reference architectures. The tested tools
shows that it is quite easy to map entities bidirec-
tional between model and source code. Unfortunately
the modeling of processes or procedures e.g. with
BPMN or activity diagrams highly depends to spe-
cific development and execution environments. Till
now those environment decision has to be done in the
beginning of the modeling phase, which can not be
done in case of platform independent modeling and
reference architectures. This decision has to be done
by the respective developer.
However, the available tools and meta descriptions
can be used within the intended framework. Ecore
models seem to be a commonly accepted metalan-
guage for entities which can be edited by a lot of free
Model-driven Engineering Tool Comparison for Architectures within Heterogenic Systems for Electric Vehicle
675
and commercial tools like EMF and MagicDraw. In
addition to that it is easy to get generated code from
those models which are based on Ecore.
The missing possibility to describe processes or
procedures has to be added to get the SCL framework
as intended. But furthermore there are tools which
could be used as base to prevent development from
scratch. AndroMDA shows basic structures to extend
the generative capabilities by adding new cartridges
which could extend the plain entity to code mapping
with specific behavior.
SCL will use the results to go further through a
generative framework to support development by us-
ing the SCL reference architecture for logistical sys-
tem extensions. The next step would be to define and
describe how internal mechanisms can be modeled
without losing platform independences.
ACKNOWLEDGEMENTS
We would like to thank all members of the SCL re-
search team here at FSU Jena – there are too many to
name them all in person. We would also like to ex-
tend our gratitude to our partners within the research
consortium, end users as well as research institutions
and industrial developers. This project is supported
by the German Federal Ministry for Economic Affairs
and Energy in the IKT-II fur Elektromobilitat program
under grant 01ME121(-33).
REFERENCES
Alford, R., Simmonds, D., Reinicke, B., and Vetter, R.
(2013). An evaluation of model driven architecture
(mda) tools. Master’s thesis, Annals of the Master
of Science in Computer Science and Information Sys-
tems at UNC Wilmington. 7(2) paper 5.
Apel, S., Schau, V., and Rossak, W. (2014). Darstel-
lung branchentypischer Abl
¨
aufe und Wechselwirkun-
gen in der innerst
¨
adtischen logistik. Technical Re-
port Math/Inf/06/2015, Friedrich-Schiller- Universit
¨
at
Jena, Institut f
¨
ur Informatik, Jena, Germany.
Beydeda, S., Book, M., and Gruhn, V. (2005). Model-
Driven Software Development. Springer Berlin Hei-
delberg.
Budinsky, F. (2004). Eclipse Modeling Framework: A De-
veloper’s Guide. The eclipse series. Addison-Wesley.
Busch, A., Dangelmair, W., Pape, U., and R
¨
uther, M.
(2003). Marktspiegel Supply Chain Management Sys-
teme. Gabler, Wiesbaden.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,
and Stal, M. (1996). A System of Patterns, Pattern-
Oriented Software Architecture. John Wiley and Sons.
Calic, T., of Nevada Reno, U., Dascalu, S., and Egbert, D.
(2008). Tools for mda software development: Evalua-
tion criteria and set of desirable features. In Latifi, S.,
editor, Proceedings of the Fifth International Confer-
ence on Information Technology: New Generations,
pages 44–50. IEEE Computer Society. ITNG 2008.
Chappell, D. (2004). Enterprise Service Bus. O’Reilly Se-
ries. O’Reilly Media, Incorporated.
Chopra, S. and Meindl, P. (2007). Supply Chain Manage-
ment, volume 3. Pearson Education, New Jersey.
C.Quiroga, N.Koncz, E.Kraus, J.Villa, J.Warner, Y.Li, and
D.Winterich (2011). Guidance for developing a
freight transportation data architecture. NCFRP Re-
port 9.
Faber, A. and Ammerschuber, O. (2007). Transporte im
Griff. Logistik Heute, pages 35–37.
Gamma, E., R.Helm, Johnson, R., and Vlissides, J.
(1994). Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley Profes-
sional, 1 edition.
ISO/IEC JTC 1 (1994). ISO 7498-1: Information technol-
ogy - Open Systems Interconnection - Basic Reference
Model, 1 edition.
Logistik Heute (2005). Die Qual der Wahl. Logistik Heute,
pages 36–37.
Moore, M., Kumara, S., and Richbourg, R. (1996). An
architecture for logistics replanning. Expert Systems
with Applications, 11(2):177–190.
Pirron, J., Kulow, B., Hellingrath, B., and Laakmann, F.
(1999). Markt
¨
ubersicht SCM-Software. Logistik
Heute, pages 69–75.
Re, S. D., Campagna, A., and Nanni, U. A reference archi-
tecture for freight transport manangement systems.
Internet, http://freightwise.tec-hh.net/A-reference-
architecture-for-freight-transport-management-
systems.pdf, visited 2015-10-21.
Rempp, G., Akermann, M., L
¨
offler, M., and Lehmann, J.
(2011). Model Driven SOA, Anwendungsorientierte
Methodik und Vorgehen in der Praxis. Xpert.press.
Springer-Verlag Berlin Heidelberg.
Satapathy, G., Kumara, S., and Moore, L. (1998). Dis-
tributed intelligent architecture for logistics (dial). Ex-
pert Systems with Applications, 14:409–424.
Silingas, D. and Vitiutinas, R. (2008). Towards uml-
intensive framework for model-driven development.
In Meyer, B., Nawrocki, J., and Walter, B., editors,
Balancing Agility and Formalism in Software Engi-
neering, volume 5082 2008 of Lecture Notes in Com-
puter Science, pages 116–128. Springer Berlin Hei-
delberg.
Silva, J. and Ar
´
evalo, D. (2010). Modelo compar-
ativo de herramientas mda en ambientes de
software libre. Technical report, Universidad
Aut
´
onoma de Bucaramanga, Colombia. Internet,
http://de.scribd.com/doc/34353208/tecnico-Jamda,
visited 2015-10-21.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
676