IEEE COMPUTER 1

Developing Applications Using Model-driven

Design Environments
Krishnakumar Balasubramanian, Member, IEEE, Aniruddha Gokhale, Member, IEEE, Gabor Karsai, Senior
Member, IEEE, Janos Sztipanovits, Fellow, IEEE, and Sandeep Neema, Member, IEEE

Abstract— Model-driven development (MDD) is an emerging MDD, models are used in most system development activities,
paradigm that improves the software development lifecycle, i.e., models serve as input and output at all stages of system
particularly for large software systems by providing a higher- development until the final system is itself generated.
level of abstraction for designing and developing the system
than is possible with third-generation programming languages. This paper describes one variant of MDD called Model-
The MDD paradigm relies on the use of (1) Domain-Specific Integrated Computing (MIC) [1], which focuses on using
Modeling Languages that incorporate elements of the domain Domain-Specific Modeling Languages (DSMLs) to represent
being modeled and their relationship as first-class objects, and (2) system elements and their relationships, and transformations
model transformations that transform the models into platform- from these languages to platform-specific artifacts. We have
specific artifacts, such as code. This paper illustrates several
key characteristics of the MDD approach that differentiate it successfully applied the concept of MIC to develop a num-
from traditional software development approaches. Additionally, ber of DSML tool-suites. In this paper we will focus on
the paper describes meta-programmable tools used to con- two such tool suites: (1) Platform-Independent Component
struct domain-specific tool-suites, and provides two example tool Modeling Language (PICML), which assists developers in
suites drawn from different domains. These tool-suites are (a) the development, configuration and deployment of systems
PICML, which supports the development of standards-compliant
component-based applications, and (b) ECSL, which supports built using component middleware technology, such as CCM;
software development for distributed embedded controllers. (2) Embedded Control Systems Language (ECSL), which
supports development of distributed embedded automotive
Index Terms— Model-Integrated Computing, GME, CCM,
CoSMIC, Deployment & Configuration applications.
Both of these tool-suites are built using the Generic
I. I NTRODUCTION Modeling Environment (GME) [2], an open-source meta-
programmable domain-specific design environment, which al-

H ISTORICALLY, software development methodologies

have focused on improving the individual tools like
programming languages, much more than tools that assist
lows development of both DSMLs and the models that con-
form to these DSMLs, within the same graphical environment.
Another popular variant of MDD is the Object Manage-
system composition and system integration. Component-based ment Group’s Model-Driven Architecture (MDA) [3], which
middleware like Enterprise Java Beans, Microsoft .NET and relies on representing systems using the Unified Modeling
the CORBA Component Model (CCM) have helped improve Language (UML), a general purpose modeling language, and
the re-usability of software through the abstraction of com- transforming these models into artifacts that run on a variety
ponents. However, as systems are being built more frequently of platforms like EJB, CCM and .NET. Unlike MDA, which
using commercial-off-the-shelf (COTS) technologies, a wide focuses on the use of a general-purpose modeling language
gap has been created in the availability and level of sophis- like UML (along with specific profiles), MIC focuses on
tication of tools that help with software development like developing modeling languages that are tailored to a particular
compilers, debuggers, linkers and virtual machines, as opposed domain of interest.
to tools that allow developers to compose, analyze and test a
The remainder of the paper is organized as follows: Sec-
complete system, or system of systems. As a result, the task
tion II describes the concept of DSML and the key ele-
of system integration continues to be accomplished using ad
ments defined in it; Section III describes PICML and shows
hoc methods without the support of automated tools.
how PICML addresses the challenges involved in developing
Model-Driven Development (MDD) is an emerging
component-based applications; Section IV describes ECSL
paradigm which solves a number of problems associated with
and shows how ECSL resolves the challenges in developing
the composition and integration of large-scale systems while
embedded automotive applications; Section V compares our
also leveraging the advances in software development, such
work with other MDD frameworks and tools; and finally
as component-based middleware. The focus of MDD is to
Section VI presents concluding remarks.
elevate software development to a higher level of abstraction
than that provided by third generation programming languages.
The MDD approach relies on the use of models to represent II. D OMAIN -S PECIFIC M ODELING L ANGUAGES
the system elements of the domain and their relationships. In DSMLs are the backbone for realizing the vision of Model-
Contact Author e-mail: [email protected] Integrated Computing (MIC), a variant of MDD. One differ-
The authors are with Vanderbilt University, Nashville, TN, USA. ence between other variants of MDD like MDA and MIC is
IEEE COMPUTER 2

the emphasis on the “domain-specific” aspect of the modeling Sidebar 1: Generic Modeling Environment
languages. This section provides an overview of DSMLs and
explains the steps needed to create a DSML.
Generic Modeling Environment (GME) is an open-
source, visual, configurable design environment for creat-
A. Overview of DSML ing DSMLs and program synthesis environments, available
for download from escher.isis.vanderbilt.edu/
The domain of interest of a DSML can range from some- downloads?tool=GME. A unique feature of GME is that it
thing very specific, such as the elements of a radar system, is a meta-programmable environment. By meta-programmable,
or can be as broad as the set of all the component-based we refer to the fact that GME is not only used to build DSMLs,
middleware applications built using platforms such as EJB, or but also to build models that conform to a DSML. In fact, the
environment used to build DSMLs in GME is itself built using
CCM. The key idea behind DSMLs is their ability to capture
another DSML (also known as the meta-metamodel) called
the elements of the domain as first-class objects. “MetaGME”. GME provides the following elements to define
A DSML can be viewed as a five-tuple [4] consisting of: a DSML:
1) Concrete Syntax (C), which defines the specific no- • Project, which is the top-level container in a DSML,
• Folders, which are used to group collections of similar
tation (textual or graphical) used to express domain
elements together,
elements, • Atoms, which are the indivisible elements of a DSML,
2) Abstract Syntax (A), which defines the concepts, re- and used to represent the leaf-level elements in a DSML,
lationships and integrity constraints available in the • Models, which are the compound objects in a DSML,
language, and are used to contain different types of elements like
3) Semantic Domain (S), which defines the formalism References, Sets, Atoms, Connections et al. (the elements
that are contained by a Model are known as parts),
used to map the semantics of the models to a particular • Aspects, which are primarily used to provide a different
domain, viewpoint of the same Model (every part of a Model is
4) Syntactic Mapping (MC : A→C), which assigns syntac- associated with an Aspect),
tic constructs (e.g., graphical and/or textual) to elements • Connections, which are used to represent relationships

of the abstract syntax, and between the elements of the domain,

• References, which are used to refer to other elements in
5) Semantic Mapping (MS : A→S), which relates the different portions of a DSML hierarchy (unlike connec-
syntactic concepts to those of the semantic domain. tions which can be used to connect elements within a
Thus the abstract syntax determines all the (syntactically) Model),
• Sets, which are containers whose contained elements
correct “sentences”, i.e., models, in the language. A DSML
are defined within the same aspect and have the same
is also known as a “metamodel”, since a DSML is (itself) a container as the owner.
model that defines all the possible models that can be built
using it. To support the development of DSMLs, we have de-
veloped a “meta-programmable” modeling environment called
the Generic Modeling Environment (GME). of GME, i.e., UML class diagrams, to capture the elements
of the DSML as shown in Figure 1. It is important to note
that the concrete syntax of the elements of your DSML, i.e.,
B. Creating a DSML using GME visualization of elements of the DSML, is defined when you
DSMLs are defined visually in GME. The following are the are defining the types of your your DSML. GME provides the
typical steps in creating a DSML using GME: ability to customize the concrete syntax, i.e., customize the
1. Identifying the domain elements and their relationships. visualization of elements in your DSML. Customization of
The first step in creating a DSML is to identify the different visualization is done using decorators in GME. A decorator
elements of the domain that we want to model, and their is a component (written using a traditional programming
relationships. This is usually done with input from a domain language) that implements a set of standard callback interfaces.
expert. It is unlikely that all the elements are defined in a Once a decorator is registered with GME, GME invokes the
single iteration. Just like software development, MDD is also callbacks whenever GME needs to display the element.
an iterative process, and any MDD tool infrastructure should 4. Defining static semantics of the DSML. The use of
allow modification of the elements (or relationships between UML class diagrams as the notation for concrete syntax of
elements) with ease. DSMLs in GME allows capturing some semantics of the
2. Mapping the elements of the domain to concepts in association between the different elements. This is because
GME. Sidebar 1 provides more information about the GME some semantics like cardinality of associations can be suffi-
concepts. Once we have enumerated the elements of the ciently represented using the notations offered by UML class
domain, we need to map these domain concepts to GME diagrams. For constraining the associations between elements
concepts like Models, Atoms, et al. This process is very further, GME provides a built-in constraint manager. GME’s
similar to defining the types in a program when coding using constraint manager allows the definition of constraints using
a language like C/C++. OMG’s Object Constraint Language (OCL) [5] as shown in
3. Using GME concrete syntax to realize the mapping. Figure 2. The semantics of the DSML that are enforceable
With the mapping of elements of the domain to concepts in using OCL can be viewed as static semantics, since they do
GME complete, the next step is to use the concrete syntax not take the system dynamics into account.
IEEE COMPUTER 3

Fig. 1: Realizing the domain mapping using concrete syntax in GME

Fig. 2: Defining static semantics in GME

5. Generating the DSML environment. Now that we have registered with the GME environment. It is now possible to
defined the elements of the DSML and the associated static create models that conform to the DSML that we have built
semantics, we instruct GME to generate our customized using GME.
DSML environment. This is done using a process called
meta-interpretation. Meta-interpretation takes the definition of 6. Defining dynamic semantics of the DSML. Though
the DSML from the previous step, runs a set of standard we have defined the elements, relationships and the static
transformations (which ensure consistency of the language) semantics of the DSML, it is necessary to define dynamic
just like a traditional compiler and creates a paradigm. The semantics to make the DSML useful for complex real-world
paradigm file, which actually defines the DSML, is then applications. Dynamic semantics of a DSML can be enforced
using interpreters. An interpreter is a component that is written
IEEE COMPUTER 4

using a traditional programming language like C++, Python developers of component-based systems to define application
or Java. Interpreters need to be registered with GME. When interfaces, QoS parameters, and system software building
an interpreter is invoked, it is given access to the model rules, as well as generate metadata, XML descriptor files,
hierarchy by GME, and can be used to perform different that enable automated system deployment. PICML also pro-
kinds of validation and generative operations on the models. vides capabilities to handle complex component engineering
One such operation can include generating platform-specific tasks, such as multi-aspect visualization of components and
artifacts like code directly from the models. the interactions of their subsystems, component deployment
planning, and hierarchical modeling of component assemblies.
III. A PPLYING MIC TO D EVELOP C OMPONENT- BASED Currently, PICML is used in conjunction with the Component-
A PPLICATIONS Integrated ACE ORB (CIAO), our CCM implementation, and
Deployment and Configuration Engine (DAnCE) [6], a QoS-
This section describes a DSML called Platform-Independent
enabled deployment engine. However, PICML’s design has
Component Modeling Language (PICML). First we describe
been driven by the goal to allow integration of systems built
the challenges in system composition and integration when
using different component technologies like Microsoft .NET
using component-middleware technologies without adequate
and EJB.
tool support. Then we describe how we have applied the MDD
PICML is defined as a metamodel in GME for describing
approach to develop PICML, and show how the features in
components, types of allowed interconnections between com-
PICML help resolve the challenges with development, config-
ponents, and types of component metadata for deployment.
uration and deployment of component-based applications.
From this metamodel, ∼20,000 lines of C++ code (which
represents the modeling language elements as equivalent C++
A. Component-based Application Development Challenges types) is generated. This generated code allows manipulation
A common trend in the transition to component middleware of modeling elements, i.e., instances of the language types
technologies is the use of metadata to capture properties using C++, and forms the basis for writing model interpreters,
of applications that were previously tightly coupled with which traverse the model hierarchy to generate XML-based
the implementation. This allows declarative specification of deployment plan descriptors (described in Sidebar 2) needed
properties of applications using platform-agnostic technologies to support the OMG Deployment and Configuraion (D&C)
like XML, which are read by tools during deployment, and specification [7].
allows for automating the deployment and configuration of
Component Package
applications. Component Component Component Component

The availability of higher-level abstractions like virtual Component

Assembly
Component
Assembly
Component Component
Component Component

machines, execution containers, and extra information about

systems via rich metadata, has an indirect effect in allowing
(3) omp

tio r
r a to
ne crip
C
Hie os

Component
Ge Des
rar ition

people to build systems that are more heterogeneous than Packager

ch

(4)
ica
l

previously possible. This results in an increase in the amount itio

n ge
ne
Component
Deployer
Assembly
os ra
tio
of information that must be managed by the system developer Component Component

Component
(2) Interaction
Definition
co
mp

PICML
n

(5) Deployment planning Deployment

y

ning
mbl

as well as an increase in the complexity of system integra- Assembly

plan
asse

Component Component Assembly

specification
tion. However, the infrastructure for managing such complex Component
Assembler
DAnCE
Framework
deployment was essentially lacking in previous generation
(1) Interface
Definition

Assembly

middleware. Most deployments were done in an ad hoc Component

Developer

basis and there was hardly any reuse of the deployment Component
Impl Impl Impl
infrastructure. Moreover, these ad hoc techniques had no Resource Properties

basis for scientifically verifying and validating the correctness Requirements

of the system. The amount of heterogeneity in the systems

being deployed was also less compared to systems built using Fig. 3: Model-driven Application Development Lifecycle
component-based middleware. The lack of simplification and
automation in resolving the challenges outlined above can Figure 3 shows the typical steps involved in developing
significantly hinder the effective transition to – and adoption component-based applications using PICML’s MDD approach.
of – component middleware technology to develop systems, The following describes the key steps in component-based
thereby negating the benefits of component middleware tech- application development, while describing the features in
nologies. PICML used in this process:
1. Visual component interface definition. A set of com-
ponent, interface and other datatype definitions defined via
B. Platform-Independent Component Modeling Language CORBA’s Interface Definition Language (IDL) may be created
To address the problems outlined above, we have developed in PICML using either of the following two approaches: (1)
a DSML called Platform-Independent Component Modeling Adding to existing definitions imported from IDL. In this
Language (PICML). PICML is an open-source DSML avail- approach, existing CORBA software systems can be easily
able for download as part of the CoSMIC MDD framework migrated to PICML using its IDL Importer, which takes any
at www.dre.vanderbilt.edu/CoSMIC. PICML enables number of CORBA IDL files as input, maps their contents to
IEEE COMPUTER 5

the appropriate PICML model elements, and generates a single PICML can be used to specify the target environment where
XML file that can be imported as a PICML model; (2) Cre- the system will be deployed, which includes nodes, inter-
ating IDL definitions from scratch. In this approach, PICML’s connects among nodes, and bridges among interconnects, all
graphical modeling environment provides support for design- of which collectively represent the target environment. Once
ing the interfaces using an intuitive “drag and drop” technique the target environment is specified via PICML, allocation of
making this process largely self-explanatory and independent component instances onto nodes of the target target environ-
of platform-specific technical knowledge. CORBA IDL can ment can be performed. PICML currently provides facilities
be generated from PICML enabling generation of software for specifying static allocation of components.
artifacts in languages having a CORBA IDL mapping.
2. Valid component interaction definition. By elevating Sidebar 2: Deployment Metadata
the level of abstraction via MDD techniques, the well-
formedness rules of DSMLs like PICML actually capture PICML generates the following types of deployment descrip-
semantic information, such as constraints on composition of tors based on the OMG D&C specification:
models, and constraints on allowed interactions. There is a • Component Interface Descriptor (.ccd) – Describes the

significant difference in the early detection of errors in the interfaces – ports, attributes of a single component.
• Implementation Artifact Descriptor (.iad) – Describes
MDD paradigm compared with traditional object-oriented or the implementation artifacts (e.g., DLLs and executables)
procedural development using a conventional programming of a single component.
language compiler. In PICML, OCL constraints are used to • Component Implementation Descriptor (.cid) – De-
define the static semantics of the modeling language, thereby scribes a specific implementation of a component inter-
disallowing invalid systems to be built using PICML, i.e., face; also contains component interconnection informa-
tion.
PICML enforces the correct-by-construction approach to sys- • Component Package Descriptor (.cpd) – Describes
tem development. multiple alternative implementations (e.g., for different
3. Hierarchical composition. In a complex system with OSes) of a single component.
thousands of components, visualization becomes an issue • Package Configuration Descriptor (.pcd) – Describes

because of the practical limitations of displays, and the lim- a component package configured for a particular require-
ment.
itations of human cognition. Without some form of support • Component Deployment Plan (.cdp) – Plan which
for hierarchical composition, observing and understanding guides the runtime deployment.
system representations in a visual medium does not scale. • Component Domain Descriptor (.cdd) – Describes the
To increase scalability, PICML defines a hierarchy construct, deployment target i.e., nodes, networks on which the
which enables the abstraction of certain details of a system components are to be deployed.
into a hierarchical organization, such that developers can view
their system at multiple levels of detail depending upon their
needs. The support for hierarchical composition in PICML not
only allows system developers to visualize their systems, but IV. A PPLYING MIC TO DEVELOP EMBEDDED AUTOMOTIVE
also allows them to compose systems from a set of smaller APPLICATIONS
subsystems. This feature supports unlimited levels of hierarchy Embedded automotive systems are becoming notoriously
(constrained only by the physical memory of the system difficult to design and develop. Over the past years there
used to build models) and promotes the reuse of component has been an explosion in the scale and complexity of these
assemblies. PICML therefore enables the development of systems, owing to a push towards drive-by-wire technologies,
repositories of predefined components and subsystems. The increasing feature levels, and increasing capabilities in the em-
hierarchical composition capabilities provided by PICML are bedded computing platforms. In order to address this level of
only a logical abstraction, i.e., deployment plans generated complexity, the automotive industry has in general embraced
from PICML flatten out the hierarchy to connect the two the model-based approach for embedded systems development.
destination ports directly (which if not done will introduce However, the approach is confined to only the functional
additional overhead in the communication paths between the aspects of the system design, and restricted to a limited suite
two connected ports), thereby ensuring that at runtime there of tools, most notably the Mathworks family of Matlab® ,
is no extra overhead that can be attributed to this abstraction. Simulink® (SL), Stateflow® (SF) tools. Undeniably, Simulink
4. Valid deployment descriptor generation. In addition to and Stateflow are very powerful, graphical system design tools
ensuring design-time integrity of systems built using OCL for modeling and simulating continuous and discrete event-
constraints, PICML also generates the complete set of deploy- based behavior of a dynamic system. However, these tools
ment descriptors that are needed as input to the component by no means cover the entire spectrum of embedded systems
deployment mechanisms. The descriptors generated by PICML development. There are several other complex activities such
conform to the descriptors defined by the standard OMG D&C as requirements specification, verification, mapping on to a
specification [7]. Sidebar 2 shows an example of the types distributed platform, scheduling, performance analysis, and
of descriptors that are generated by PICML, with a brief synthesis in the embedded systems development process.
explanation of the purpose of each type of descriptor. Although there are tools which individually support one or
5. Deployment planning. Systems are often deployed in het- more of these other developmental activities, the integration
erogeneous execution environments. To support these needs, among these tools and the Mathworks family of tools is
IEEE COMPUTER 6

often lacking, which makes it extremely difficult to maintain architectural topology of the distributed embedded platform.
a consistent view of the system as the design progresses Refinements of this activity include design of individual ECUs,
through the development process, and also requires significant selecting the processors, determining the memory and I/O
manual effort in creating different representations of the same requirements.
system. To address the deficiencies in the development process Mapping includes activities involving both software and
for distributed automotive embedded systems, we built the hardware objects, like decisions regarding the deployment of
Embedded Control Systems Language (ECSL) that provides certain complete or partial functions to hardware nodes which
the ability to import existing SL/SF models into a GME are part of the network, and the assignment of signals to bus
environment, and supports: (1) The annotation of structural messages.
design, SW-component design, and behavior implementation Code Generation/Implementation involves creation of low-
to supply information needed by a code generator, (2) Cre- level coding artifacts, which include RTOS configuration,
ation of HW-topology design models, Electronic Control Unit firmware configuration code, and behavioral implementation
(ECU)-design models, and firmware implementation design of the components.
models, and (3) Creation of deployment models that capture Figure 4 captures an abstraction of the design process,
component and communication mapping. which is made concrete by a number of supporting tools,
which include: GME/ECSL. This is the Generic Modeling
A. Embedded System Development using ECSL Environment tailored to support the ECSL modeling lan-
guage. ECSL/CG. A specialized code generator that produces
Figure 4 depicts the conceptual view of activities in an various production artifacts (e.g., source code, configuration
automotive embedded systems development process, as sup- files) from ECSL models. ML2ECSL. Import translators that
ported by the ECSL tools. Each rounded block denotes a allow importing SL and SF models into the ECSL modeling
particular activity and arrows indicate the workflow between environment. SL/SF. These are the Simulink and Stateflow
different activities. Activities can roughly be grouped in three tools.
blocks: Hardware Design, Software Design, and Mapping.
Requirements Engineering is not within the scope of this tool- B. Embedded Control Systems Language
suite, although it is the basis for most of the modeling and
ECSL is a graphical modeling language built using GME.
development activities.
It contains modeling concepts for specification of the design
activities listed above. The language has been designed as a
Requirements Analysis
composition of a suite of sub-languages as shown below:
Functional Modeling. The Simulink and Stateflow sub-
Software Design
Hardware Design
(Refinement) languages of ECSL were designed to mirror the capabilities
HW-Topology Design Structural Design found in SL and SF, such that all models could be imported
into the GME environment configured to support ECSL.
SL/SF

ECU-Design SW-Component Design

Mapping
Simulink follows a dataflow-diagram like visual notation,
GME/ECSL

ML2ECSL
Component
Firmware Mapping Behavior while Stateflow supports Statechart-like hierarchical finite state
Implementation Implementation
machines.
Communication
Mapping Component Modeling. This sub-language allows software
modeling in two stages: (1) integrating models that were
imported from SL/SF, and (2) allowing their componentiza-
Firmware ECU Integration Behavior tion. A component is defined as a portion of the software
Code Generation Code Generation
model, which is deployed as a unit. The componentization is
System Code
Generation/Integration
Code Generation specified using the GME containment and reference capabil-
ECSL/CG
ities: Components are GME models that contain references
to elements of the functional model (imported from SL).
Fig. 4: ECSL Process Components consist of ports which allow the specification
of inter-component communication, as well as interfaces to
Software Design deals with: a) Structural design, which refers physical devices including sensors and actuators. Attributes of
to the hierarchical decomposition of the embedded system into ports capture the required communication properties like data
subsystems and sub-subsystems, from a functional viewpoint, type, scaling, and bit width. The intra-component dataflow
b) Component design, which is another form of decomposition exists within the functional models and it is imported from
not independent of the functional decomposition, deals with SL/SF. The inter-component dataflow is introduced by the
more of the classical embedded software concerns such as designer after creating components from the imported SL/SF
real-time requirements, real-time tasks, periodicity, deadline, models.
and scheduling, and c) Functional/behavioral design, which Hardware Topology Modeling. The hardware modeling sub-
refers to the elaboration of the leaf elements of the hierarchical language of ECSL allows the designer to specify the hardware
structural design in terms of a synthesizable realization. topology, including the processors and communication links
Hardware Design includes the specification of ECUs in between the processors. ECU models represent specific pro-
a network and their connections with buses, defining an cessors in the system. An ECU model has two kinds of ports
IEEE COMPUTER 7

for representing the I/O channels and the bus connections. I/O V. R ELATED W ORK
channel ports come in two variants: sensor ports and actuator This section summarizes related efforts associated with de-
ports. The specifics of the ECU firmware, characterization with veloping design environments supporting the MDD approach
respect to memory sizes and CPU speed, are captured with and compares these efforts with our work.
attributes. Bus models represent communication pathways
used to connect ECUs. Buses are expressed as GME atoms A. Cadena
and their attributes specify various properties of the physical
Cadena [9] is an integrated environment developed at
communication system (e.g. bit rates).
Kansas State University (KSU) for building and modeling
Deployment (Mapping) Modeling. This modeling sub- component-based systems, with the goal of applying static
language captures how software components are deployed on analysis, model-checking, and lightweight formal methods to
the hardware. The ECU model has a “deployment aspect” enhance these systems. Cadena also provides a component
that allows the designer to capture SW component to ECU assembly framework for visualizing and developing compo-
mapping using GME’s reference concept. Note that deploy- nents and their connections. Unlike PICML, however, Cadena
ment models are separate from software models, thus allowing does not support activities such as component packaging and
the reuse of software models in different HW architectures. generating deployment descriptors, component deployment
Furthermore, component ports are connected to ECU ports planning, and hierarchical modeling of component assemblies.
(sensor, actuators, and bus connections) to indicate how the To develop a complete MDD environment that seamlessly
component software interfaces map to actual sensors, actuators integrates component development and model checking ca-
and buses. pabilities, we are working with KSU to integrate PICML
with Cadena’s model checking tools, so we can accelerate the
C. Generating code and other artifacts development and verification of DRE systems.

The ECSL/CG tool is a code generator that produces code B. Kennedy Carter Modeling Tool-suite
artifacts necessary for system implementation as shown on Kennedy Carter [10] provides a solution called iUML,
Figure 5. which uses the MDA approach to develop systems using
executable UML. iUML provides a full fledged modeling
Extended framework as well as a model testing, debugging and execution
SL/SF-Model
environment. iUML also provides a ready to use code gener-
OSEK OS OSEK Application Application Glue Code CAN Driver
ation framework so that developers can translate the models
Oil File Tasks and Code Behaviour-Code .c, .h Files Configuration
using a proprietary code generation framework. Like UML,
iUML is also a generic framework and the developers will have
Generate
Code Configure to customize the tool to create domain-specific artifacts. It is
possible that Kennedy Carter will target DSMLs for vertical
OSEK OS
specific .h Files
CAN Driver
CANoe Emulation
domains which use this generic framework.
OSEK OS Libs Compile+
CANoe Emulation Link C. Eclipse Modeling Framework
Eclipse Modeling Framework(EMF) [11] is a modeling
NodeLayer-DLL
for CANoe
framework targeting the MDA approach to MDD. EMF uses
For each HW node
MOF [12] as the underlying meta-metamodel. EMF supports
Generated by Vanderbilt Code-Generator
CANoe
specification of the models using XML Metadata Interchange
Vector Tools or Standard Code-Modules
(XMI), annotated Java, and XML Schema. EMF generates
Java code that allows a user to manipulate the elements in a
Fig. 5: ECSL Code Generation model. There are efforts like Graphical Modeling Framework
(GMF) which are currently underway with the goal of adding
The following types of files are generated: (1) OSEK capabilities for visual specification of DSMLs just like GME.
Implementation Language (OIL) File - For each ECU-node
in the network an OIL file is generated, that includes a listing D. Microsoft DSL Tools
of all used OSEK [8] objects and their relations, (2) OSEK Microsoft has recently released a set of tools with the
Tasks and Code - All tasks are implemented in one or more goal of realizing the vision of Software Factories [13]. Like
C files, (3) Application Behavior Code - A separate function PICML, the release includes a DSML for building .NET
is generated for each application component that implements based Web Services applications called Visual Studio for
the behavior of the component. This function is called out Team Architects (VSTA), which provides tight integration with
from within a task frame, (4) Glue Code - The glue code code, and generates descriptors necessary for deploying these
comprises one or more C code/header files that resolve the applications. Microsoft is also developing another set of tools
calls to the Controller Area Network (CAN) driver or the called the domain-specific language (DSL) tools. The DSL
firmware in order to provide access to CAN signals or HW tools are like GME and EMF and allow development of DSLs
I/O signals. using a proprietary meta-metamodel.
IEEE COMPUTER 8

VI. C ONCLUDING R EMARKS

Model-driven development (MDD) is a promising paradigm
to tackle the system composition and integration challenges.
MDD elevates the level of abstraction of software develop-
ment and bridges the gap between technology domains by
allowing domain experts (who may not be experts in software
development) to be able to design and build systems. The
higher level of abstraction provided by MDD also allows
transformation between models in different domains without
the need to resort to low-level integration solutions like using
standard network protocols. MDD guarantees the semantic
consistency of the systems that are built by enforcing the
philosophy of “correct-by-construction”. MDD also solves a
lot of the accidental complexities, due to the heterogeneity of
the underlying component middleware technologies, that arise
during system integration. For example, applying MDD to
develop component-based applications using PICML relieves
the users from having to capture the metadata in the form of
XML descriptors, which are tedious and error-prone to write
manually.
With improvements in generative techniques, MDD has the
potential to automate the generation of code just like compilers
replaced assembly language/machine-code programming. This
allows people to augment their existing software methodolo-
gies with MDD, and helps in easing the transition from a pure
coding based approach to a pure MDD approach.

R EFERENCES
[1] J. Sztipanovits and G. Karsai, “Model-Integrated Computing,” IEEE
Computer, vol. 30, no. 4, pp. 110–112, Apr. 1997.
[2] A. Ledeczi, A. Bakay, M. Maroti, P. Volgysei, G. Nordstrom, J. Sprinkle,
and G. Karsai, “Composing Domain-Specific Design Environments,”
IEEE Computer, pp. 44–51, November 2001.
[3] D. Frankel, Model Driven Architecture: Applying MDA to Enterprise
Computing. Indianapolis, IN: John Wiley and Sons, 2003.
[4] G. Karsai, J. Sztipanovits, A. Ledeczi, and T. Bapty, “Model-Integrated
Development of Embedded Software,” Proceedings of the IEEE, vol. 91,
no. 1, pp. 145–164, Jan. 2003.
[5] Unified Modeling Language: OCL version 2.0 Final Adopted Specifi-
cation, OMG Document ptc/03-10-14 ed., Object Management Group,
Oct. 2003.
[6] G. Deng, J. Balasubramanian, W. Otte, D. C. Schmidt, and A. Gokhale,
“DAnCE: A QoS-enabled Component Deployment and Configuration
Engine,” in Proceedings of the 3rd Working Conference on Component
Deployment, Grenoble, France, Nov. 2005.
[7] Deployment and Configuration Adopted Submission, OMG Document
mars/03-05-08 ed., Object Management Group, July 2003.
[8] OSEK, “Open systems and the corresponding interfaces for automotive
electronics,” www.osek-vdx.org/.
[9] J. Hatcliff, W. Deng, M. Dwyer, G. Jung, and V. Prasad, “Cadena:
An Integrated Development, Analysis, and Verification Environment for
Component-based Systems,” in Proceedings of the 25th International
Conference on Software Engineering, Portland, OR, May 2003.
[10] K. Carter, “Kennedy Carter iUML 2.2,” www.kc.com, 2004.
[11] F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. J. Grose,
Eclipse Modeling Framework. Reading, MA: Addison-Wesley, 2003.
[12] MetaObject Facility (MOF) 2.0 Core Specification, OMG Document
ptc/03-10-04 ed., Object Management Group, Oct. 2003.
[13] J. Greenfield, K. Short, S. Cook, and S. Kent, Software Factories:
Assembling Applications with Patterns, Models, Frameworks, and Tools.
New York: John Wiley & Sons, 2004.