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 speciﬁc 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 speciﬁc 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 ﬁeld of application. So the project combines an

intelligent route planning system with dynamic range

prediction, based on the detailed knowledge of major

inﬂuencing 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 ofﬂine 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 speciﬁc 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,

simpliﬁed 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 ﬁrst 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

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-

ﬂow 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

• Conﬁgurable 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 speciﬁed 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, trafﬁc 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 ﬁnd 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

deﬁned by leading companies (for example SAP), in-

terfaces for ﬁnancial information like DATEV and ﬁ-

nancial accounting, ﬁle based interfaces like spread-

sheets, ASCII or XML ﬁles, 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 ﬂexibility 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 speciﬁc 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 ﬁeld 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-

ciﬁc 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 ﬁg-

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 workﬂow for data exchange

would perform a broadcast about some speciﬁc event

with public available information. An interested com-

ponent listens for events related to those speciﬁc 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 ﬁgure 2, which combines the

described communication and MVC semantic, de-

ﬁnes four components used to handle model speciﬁc

tasks. The ﬁrst 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 modiﬁed 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

Mobile Client

Telematic Unit

existing IT-solution

Communication Bus

System

E-Vehicles

ext. Systeme

Knowledge Base

Components

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 conﬁgurable interface sys-

tem which can be easily modiﬁed to match speciﬁc

requirements. In preparation three strategies were

developed to handle communication in SCL. The

ﬁrst 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 deﬁned 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 ﬁxed order to handle a speciﬁc com-

munication stack like shown in ﬁgure 3. The last one

describes a strategy where the interface itself isn’t

handle directly. The architecture should describe a

well deﬁned 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 conﬁgurable interfaces.

MVC, internal communication, data model de-

ﬁned by the knowledge base, micro services described

within components and the idea about conﬁgurable

Socket

e.g. TCP/IP

PreHandling

e.g. TLS

PreHandling

e.g. HTTP

…

PreHandling

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 ﬁgure 4(a) has

to be used to reduce complexity, but reﬂects speciﬁc

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 speciﬁc SCL requirements about

creating a generative framework in addition to the

SCL reference architecture, a classiﬁcation of avail-

able tools has to be done. As shown in table 1, these

classiﬁcations 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 Uniﬁed 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 speciﬁc 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 speciﬁc 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 ﬁgure 4(a)

would result in something like ﬁgure 4(b). This is

nearly the same as the original diagram with slightly

modiﬁed 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

ﬁgure 4(a) would result in something like ﬁgure 4(c),

which might be exactly the same as the intended

one. MagicDraw let you choose the required target

language by creating a speciﬁc 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 conﬁgured 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 ﬁrst 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 workﬂow 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-speciﬁc model (PSM)

phase, when modeling has to be created from scratch.

5 CONCLUSIONS

MDE is challenging in speciﬁed use cases with pre-

deﬁned runtime environments. This is getting much

more difﬁcult 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-

ciﬁc 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 speciﬁc 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 deﬁne 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

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 Latiﬁ, 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

ofﬂer, 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