A flexible model driven software development

A flexible model driven software development
process for component based embedded control
systems
Joseba Andoni Agirre, Goiuria Sagardui, Leire Etxeberria
Electronics and Computer Science department
Mondragon Goi Eskola Politeknikoa
Loramendi 4, 20500 Mondragon (Gipuzkoa), Spain
{jaagirre, gsagardui, letxeberria }@eps.mondragon.edu
Abstract— Embedded Systems can characterize themselves for
having dedicated hardware with limited resources. Moreover,
non-functional requirements, such as reliability and response
time, can be critical. Hence, programming languages with small
memory footprint, low performance overhead and hardware
dependability are selected to implement their software. C is often
the language of choice. However, this software can have
maintainability problems in the long run due to the lack of
characteristics such as encapsulation and replaceability of this
language.
In order to enhance the implementation of such systems with
these features, this paper presents a semi-automatic Model
Driven Software Development (MDSD) process that allows the
transformation of a KOBRA model to a reduced ANSI C
implementation. Apart from the maintainability increase, the
application of MDSD decouples the high-level system design from
the implementation platform and improves communication
among the multidisciplinary team involved in the development of
the embedded system. A staged transformation from design to
implementation permits the future introduction of new features
or platforms in the process. The MDSD process has been
designed to maximize the transformations reuse when some
implementation requisites changes.
Keywords- Model Driven Software Development ; Meta-Model ;
Model To Model Transformation ; ATL ; Superimposition ; Model
To Text Transformation ; XPAND 2 ; Component Based SW
Development ; KOBR A ; Variability Points
I.
INTRODUCTION
The combination of model driven software development
(MDSD) [1] and component based software development
(CBSD) [2] is considered especially advantageous for
developing complex systems such as embedded systems [3].
The MDSD paradigm raises the abstraction level of system
specifications and increases automation in system
development. CBSD helps to manage complexity by promoting
the separation of concerns which facilitates the reuse and
maintenance of the software. The mix of those approaches
offers adaptable embedded applications with high software
reuse rate [4].
This work presents a Component Based MDSD process for
embedded control applications. The MDSD process focused on
offering a platform to generate semi-automatically software in
ANSI-C from previously designed components in UML2 using
KOBRA[5] methodology. KOBRA defines a methodology to
design component based object oriented software. KOBRA
uses UML as modeling language. This way, concepts of CBSD
and advantages of MDSD can be achieved in embedded
systems implemented in ANSI-C.
One of the main issues in embedded software is evolution.
Software evolution is concerned with the complete life cycle of
software systems, from initial development to maintenance,
and includes introducing new features, improving old features,
and repairing bugs [6]. How does the designed and
implemented MDSD process adapt to new changes?
The aim of the work is to generate ANSI-C code from a
component based SW design with flexible transformations to
offer variation points to non-functional properties [7] such as
portability, reliability, safety and maintenance reducing the
development cost of the MDSD process when new and non
predicted requirements are requested.
The novelty of the proposed design approach is that it
allows specifying component based software architectures.
And then generate the code automatically using MDSD
techniques that introduce component concepts in ANSI C code.
This helps to overcome the lack of explicit components and
object existence in C and facilitate the evolution of the design.
First the work motivation is overviewed. In the next section
the meta-models and frameworks used in the MDSD process
are explained. The fourth section describes the model to model
transformation (M2MT) and the model to text transformation
(M2TT).
II. MODEL DRIVEN SOFTWARE DEVELOPMENT AND NON
FUNCTIONAL PROPERTIES EVOLUTION
Non-functional properties are those related to
characteristics that somehow can limit the system:
performance, memory footprint, platform compatibility,
reliability, robustness, safety, security, etc. Unplanned
modification to accommodate change requests affects different
viewpoints: the structural viewpoint, the behavioral viewpoint,
system requirements, documentation, and, of course,
implementation.
MDSD support a layered construction of systems, in which
the (platform independent) functional aspects are kept separate
from architectural and non-functional (platform specific)
aspects, where the final system is obtained by combining these
aspects later using model transformations. This architecture
helps the management of non functional properties.
Embedded software different evolution needs affect in
different dimensions in MDSD [9]. For example, more
expressivity in the design phase is obtained by extending metamodels. Or when new technological features appear integration
and composition of meta-models may be required. Also, to
adapt the software to new requisites or to obtain a different
software product in a Software Product Line the MDSD
platform must offer the possibility to manage the variability in
the models and transformations. Techniques such as Model
Weaving [10] [11], Higher-Order Transformations [12] [13]
and Aspects [14] [15] can help in those cases. Last, and one of
the most critic points in embedded systems, is the platform
evolution. In these cases the code generation phase is mainly
affected.
The staged MDSD process presented in this article offers a
design to deal with non functional requirements affecting
directly the code implementation. One of the main advantages
of the MDSD process design is the possibility of maintaining
and evolving the software from component models and
generating different implementations of software components
so that they can meet different non functional requirements
related to the code implementation minimizing the
maintainability cost of the transformations.
III.
MODEL DRIVEN SOFTWARE DEVELOPMENT PROCESS
ARCHITECTURE
The model-driven-engineering community uses models
conforming meta-models to describe well-defined software
aspects at a higher abstraction level than source code. Using
transformations the design model becomes in the final source
code.
<<Meta-Model>>
UML-KOBRA
<<Meta-Model>>
SimpleC
conforms to
conforms
Application design Model
conforms
conforms to
M2M Transformation
Rules
ANSI-C Application
Model
M2T transformation
Templates
based
ANSI-C Code
SimpleC models by a composed ATL [16] M2MT. Once a
SimpleC model is obtained a template based oAW-XPAND2
[23] M2TT is applied to obtain the ANSI-C source code. This
process is represented in Figure 1.
Different elements have been defined for
transformation of KOBRA models to ANSI C code:
•
UML-KOBRA meta-model to design software
components
•
Components Instances meta-model
•
SimpleC meta-model to describe ANSI-C
applications (This meta-model is an abstraction of
an ANSI-C subset)
•
And a framework to deal with components in
ANSI-C.
As illustrated in Figure 1 the MDSD process generates the
C code in two steps. First the design level models, conforming
UML-KOBRA meta-model, are transformed in SimpleC
models (using an intermediate Component type hierarchy
model that conforms to Components Instances meta-model as
explained later on). Once SimpleC model is obtained it is
transformed via XPAND2 M2TT in C code. Using an
intermediate ANSI-C specific meta-model the M2TT can be
reused even if the above meta-model changes, but in any case
the whole framework can be reused for different products.
Also splitting the code generation in two transformation steps
the variability characteristics affecting different abstraction
levels can be treated in different transformations
independently.
ANSI-C does not have direct support for OO or KOBRA
component concepts. A simple component framework
defining coding guidelines and programming techniques are
needed to allow writing component based object oriented
ANSI-C programs. These coding guidelines have been the
core to design the mapping between UML-KOBRA and
SimpleC meta-model.
A. Meta-Models
All the meta-models are implemented using Eclipse EMF
Ecore [17] meta-meta-model. During the process the following
meta-models are used:
based
TABLE I.
Meta-model
ANSI-C Component
Framework Definition
C progamming Style
Figure 1 MDSD process
The nucleus of the platform is a meta-model of KOBRA
and a meta-model representing a sub-set of ANSI-C called
SimpleC meta-model. KOBRA models are transformed in
the
UML2KOBRA
META-MODELS
Description
The starting point for code generation is
an UML design stereotyped with
KOBRA
profile.
Following
the
specification of OMG MDA [18], this
meta-model is Platform Independent
(PIM). This meta-model contains
stereotypes required by KOBRA:
«Komponent»,
«RootKomponent»,
«StateMachine» and «NewType».
Meta-model
Component
instances
SimpleC
Description
A component that conforms to this
design methodology has the following
UML diagrams: Internal Specification
(Class Diagram), Behavior Diagram
(State Machine Diagram), Interfaces
Specification (Class Diagram), Interfaces
Realization
(Class
Diagram),
Components Instances (HierarchicalTree Diagram) and Interfaces Relation
Diagram (Class Diagram).
Due to the complexity that UML brings
when working with instances and
components
deployment,
KOBRA
propose a hierarchical meta-model to
represent the components instances. This
meta-model is used to specify
component instances of the application
and elements of each component.
Following the specification of OMG
MDA, this meta-model is Platform
Independent (PIM). Using this metamodel the transformations rules have
been simplified. With this meta model
the hierarchical component model of
KOBRA can be represented.
This meta-model is used for defining
models containing basic concepts of a C
program. Following the specification of
OMG MDA, this meta-model is Platform
Specific (PSM). The existence of this
meta-model allows reusing M2TT
Transformations in other projects. This
meta-model contains all the basic
elements of a C code: module, File,
Field, Method, Macro, Modifier, etc. and
some concepts as threads that are not
ANSI-C. A model that conforms to this
meta-model is not dependant on the
components nor the framework, it is only
a generic specification of a C program.
In Figure 2 the meta-model is
represented.
The designed and implemented transformations must be
the simplest possible to facilitate the growing of the MDSD
architecture when new requirements are needed or when a new
MDSD process must be defined reusing the base MDSD
process. To simplify the M2TT instead of using VIPER ANSIC meta-model [19] SimpleC have been defined. SimpleC
meta-model describes only a subset of ANSI-C, reducing the
platform specific meta-model elements comparing with
VIPER. KOBRA methodology is used instead of MARMOT
[32] (a KOBRA extension for embedded systems) to use the
minimal concepts of software components, reducing the
elements of the meta-model used to describe component based
system. This way the number of elements in the source metamodel and target meta-model in the M2MT is reduced,
obtaining a base transformation that can evolve incrementally.
B. ANSI-C based Simple Component Framework(ANSI-C
SCF)
The ANSI-C Based Simple Component Framework (ANSIC SCF) [20] adds guidelines to deal with KOBRA components
to the methodologies defined in [21] [22] to implement Object
orientation and UML concepts in ANSI-C. Concretely it
defines the way to create and deploy component instances and
the binding of the components.
The component implementation coding style defines a
standard way also to add behavior (state machines) and
connections to other software components by required and
offered interfaces.
Initially the framework only offered guidelines to work
with statically created, initialized and composed components.
Static creation and composition is done using a header file and
a .c source file for each component instance. In the header, the
instance and its internal elements are created statically: internal
classes instance and interfaces. In order to allow the instance to
use the data types and functions of the definition of the
component the component’s main class header is included in
the header. Finally, each component instance has a create,
destroy
and
exec
function
(InstanceName_create,
InstanceName_destroy, InstanceName_exec). When some code
needs to use an instance it can use it including the header of the
instance.
To include the encapsulation concept in code, the class
concept is required. Class is defined by a structure that contains
class attributes. All the class functions have an argument that is
a pointer to the class structure. Each class is composed of a
header and a .c file. In the header data structure, macros and
functions are defined. In .c file, functions are implemented.
The class structure is composed by proprietary attributes, i.e.,
fields that reference other classes that compose it.
IV.
FROM KOBRA TO ANSI-C CODE.
TRANSFORMATIONS
The MDSD process is divided into two main
transformations. The first transformation is a composed ATL
Model To Model transformation between UML-KOBRA metamodel and an ANSI-C base meta-model called SimpleC. The
second transformation is a XPAND2 Model to Text
Transformation applied to SimpleC models to obtain ANSI-C
source code.
A. Model to Model Transformation- From UML2-KOBRA to
SimpleC
The transformation has been development using the ATL
language and virtual machine [24]. The primary target of ATL
is to offer a platform for the model to model transformation.
The main unit of transformation of ATL denominates module.
A module is the source file where the transformation rules are
defined.
Model Transformation composition allows for the creation
of smaller, maintainable and reusable model transformation
definitions that can scale up to a larger model transformation.
For the Composition of model transformations ATL offers
Figure 2 SimpleC Meta-mode
Output: Component type hierarchy model
different techniques. Rule inheritance, called rules and
helpers allow the composition of a rule. ATL superimposition
[25] permits the composition of transformation modules.
The designed M2MT aim is to map UML KOBRA source
meta-model elements to SimpleC target meta-model elements.
The M2MT is composed by five transformation modules, see
Figure 3. While the final transformation is being composed
more details are added to the SimpleC output model
incrementally. Using this stepwise refinement based on ATL
module superimposition, different CBSD concepts are applied
in each transformation module: component hierarchy,
component internal structure, component interfaces, interface
realization and component instantiation.
This M2MT design besides facilitating the maintenance of
the transformation modules it allows replacing a transformation
module by another reusing the other transformation modules
when new requirements require some different transformation
rules. This way different transformation chains can be
implemented reusing common transformation rules.
For each transformation step where different CBSD
concepts are used an ATL transformation file related to those
aspects is used. Using the ANT task provided by ATL the
transformation modules are chained. Now each step is
explained.
a)
Component Type Hierarchy
Input: UML+KOBRA model
b)
•
With all classes stereotyped as «Komponent», a
tree structure is created. Next, relations of children
of each node/component are created by
transforming compositions between «Komponent»
classes.
•
This transformation is performed due to the fact
that «Komponent» classes will be related to more
than one element of SimpleC meta-model. This
usually implies in ATL to increase the number of
lazy rules. To avoid this, and facilitate the
traceability, we have decided to generate by model
mixing new information which is easily navigable
and will be used in next steps together with the
initial model converting the relation from 1 to n, to
2 to n.
Component Internal Structure
Input: UML+KOBRA model, Component type
hierarchy model
Output: first version of the SimpleC Model
•
For each component in the component type
hierarchy a header and .c file are created. Besides,
an element representing an abstract data structure
is created to contain component attributes.
•
For each component a Directory/ Package is
created.
•
For each class a header element and its file are
created. Attributes are created in the
corresponding data structure. If any attribute
reference a class, header of the referenced class is
included to the header/module of the father class.
•
d)
Class internals to a component are related to the
father component directory.
•
Each class is related with the classes that it
contains, by creating for each composition a field
in the corresponding data structure.
•
Functions and its arguments are created and
associated to the corresponding modules.
e)
Interfaces Realization
Input: UML+KOBRA model, second version of the
SimpleC Model
Output: third version of the SimpleC Model
•
For each interface implementation the header and
the source file are created with its struct and
functions.
•
For each required interface implementation a field
is created in its owner interface and for in each
provided interface implementation a reference to
the provided interface is added.
•
The information for the relation between provided
realization and required realization interfaces is
added.
Components Instances
Input: UML+KOBRA model, third version of the
SimpleC Model, Hierarchical Tree model of
Components Instances
Output: Final version of the SimpleC Model
•
In this refinement all the elements associated with
components instances are added to the SimpleC
model. To specify the components instances a
Hierarchical Tree model is used as input instead of
a UML2 Component diagram. The aim of this
transformation is to create the entire infrastructure
that requires a component creation using the
components framework, presented before, in the
SimpleC model. Depending on whether the
creation must be static or dynamic a different
transformation rule file must be used in this step.
Currently only transformation rules for static
creation and composition have been implemented.
B. Model to Text Transformation-From SimpleC to C code
Once the SimpleC model representing the component based
component is generated, the information is transformed into
ANSI-C code. This transformation is done based on templates
defined in XPAND2 and using as input model the SimpleC
model obtained in the M2MT.
Figure 3 . Model to model transformation chain.
c)
Component Interfaces
Input: UML+KOBRA model , first version of the
SimpleC Model
Output: second version of the SimpleC Model
•
•
For each interface, required or offered, a header
and a source file are created with its struct and
functions.
For each component using the interfaces, elements
of the Framework are created. Thus, offered and
required interfaces are differentiated.
For each element of SimpleC meta-model a template that
defines the text related to each of them is provided. Templates
create structures, header files, data fields, functions and other
elements. For example, the template for header files is in
Figure 4.
An oAW workflow file run the templates and outputs the
final source code. This final code presents the static code and
the code related to the composition and binding of components.
«DEFINE cabecera FOR Module»
«LET path + "//" +
name +".h" AS fileName»
«FILE fileName»
«REM» Hau extensio bateko
funztioarekin «ENDREM»
#ifndef _«name»_H
#define _«name»_H
#ifdef _«name»_C
#define _PUB_«name»
#else
#define _PUB_«name» extern
#endif
[4]
Figure 4. Template for SimpleC Header Element
V.
CONCLUSIONS AND FUTURE LINES
The implemented MDSD process has been used to generate
part of the code of the door management software of an
elevator door management, where the tight mapping between
design and implementation had considerably decreased the
maintenance costs of the system.
This platform has been developed to create the “first stone”
in the evolution from a C implementation of a Elevator Doors
Management System to a Component Based implementation.
This platform is a UML+KOBRA design centric development
architecture. This means that the knowledge is in the
Component based design and not in the legacy code. This
characteristic allows easy evolution to different and more
sophisticated component implementation frameworks, such as
FRACTAL THINK-C [28] or OROCOS [31], without
changing the design, just creating the transformations needed
to create the selected platform code.
The MDSD process usages a PSM meta-model to divide
the code generation process into two main transformations, in
order to reuse de M2TT templates. This division of the
generation in two stages allows working in each of them with
different evolutionary aspects independently.
The composed M2MT allows reusing the common
transformation rules for different platforms and just requires
changes in located steps of the transformation chain, thus
increasing the reusability of the transformations.
In search of a generic model for the transformation of
component based software design the M2MT rules are being
adapted to be able to generate a SimpleC model that represents
an application based on FRACTAL THINK-C framework. The
main objective is to obtain a generic model for the
transformation where MDSD advantages can be applied to the
transformation itself. This way, when unplanned changes
appear MDSD techniques could be applied to the MDSD
process, making evolution intrinsic to MDSD process.
ACKNOWLEDGMENT
The work has been developed by the embedded system
group supported by the Department of Education, Universities
and Research of the Basque Government. We want to thank
Orona for providing the case study that has been the starting
point and the motivation of this research.
REFERENCES
[1]
[2]
[3]
[5]
Thomas Stahl , Markus Voelter , Krzysztof Czarnecki, Model-Driven
Software Development: Technology, Engineering, Management, John
Wiley & Sons, 2006
Clemens Szyperski. Component Software: Beyond Object-Oriented
Programming. 2nd ed. Addison-Wesley, 2002
C. Bunse, H. Gross, C. Peper, Applying a Model-based Approach for
Embedded System Development, 33rd EUROMICRO Conference on
Software Engineering and Advanced Applications (EUROMICRO
2007), Lubeck, Germany, August 28-August 31, 2007
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
Christian Bunse, Hans-Gerhard Groß, Christian Peper: Embedded
System Construction - Evaluation of Model-Driven and ComponentBased Development Approaches. MoDELS Workshops 2008: 66-77
Colin Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver
Laitenberger, Roland Laqua, Dirk Muthig, Barbara Paech, Jurgen Wust,
Jorg Zettel, Component-Based Product Line Engineering with UML,
Addison-Wesley Professional, 2001
Svein Hallsteinsen , Maddali Paci,Experiences in Software Evolution
and Reuse: Twelve Real World Projects, Springer , 1997
Roel Wuyts , Stéphane Ducasse.Non-Functional Requirements in a
Component Model for Embedded Systems. INTERNATIONAL
WORKSHOP ON SPECIFICATION AND VERIFICATION OF
COMPONENT-BASED SYSTEMS, OOPSLA, 2001
Software product lines: practices and patterns by Paul Clements and
Linda Northrop, Addison-Wesley Longman Publishing Co.,Inc., Boston,
MA, 2001
A. van Deursen, E. Visser, and J. Warmer, Model-driven software
evolution: A research agenda, in Proceedings of Int. Workshop on
Model-Driven Software Evolution (MoDSE) held with the ECSMR'07,
March 2007
Marcos Didonet Del Fabro, Jean Bézivin, Frédéric Jouault, Erwan
Breton, Guillaume Gueltas, AMW: A Generic Model Weaver.
Proceedings of IDM05, 2005.
Hugo Arboleda, Rubby Casallas, and Jean-Claude Royer. Implementing
an MDA Approach for Managing Variability in Product Line
Construction Using the GMF and GME Frameworks. Proceedings of the
5th Nordic Workshop on Model Driven Software Engineering (NWMoDE07), Ronneby, Sweden, pages 67--82, August 2007
Oldevik, J., Haugen, O.; Higher-Order Transformations for Product
Lines.Software Product Line Conference, 2007. SPLC 2007. 11th
International Volume , Issue , 10-14 Sept. 2007 Page(s):243 - 254
Massimo Tisi, Frédéric Jouault , Piero Fraternali, Stefano Ceri and Jean
Bézivin , On the Use of Higher-Order Model Transformations , Model
Driven Architecture - Foundations and Applications, Springer, 2009
Page(s):18-33
Markus Voelter, Iris Groher , Bernd Kolb, Mechanisms for Expressing
Variability in Models and MDD Tool Chains, SIG MDSE Workshop on
MDSD in Embedded Systems, 2005.
Markus Voelter, Iris Groher, Handling Variability in Model
Transformations and Generators, OOPSLA 2007 Domain Specific
Modeling Workshop , 2007
Jouault, F., Kurtev, I.: Transforming models with ATL. In: Model
Transformations in Practice Workshop at MoDELS 2005, Montego Bay,
Jamaica (2005)
Eclise
Modeling
Framework
Project,
,
http://www.eclipse.org/modeling/emf/ , 2010
Kleppe A., Warmer J., Bast W.: MDA Explained: The Model Driven
Architecture: Practice and Promise. Addison Wesley, Reading (2003)
Mathias Funk, Alexander Nyßen, Horst Lichter (2008): "FROM UML
TO ANSI-C - An Eclipse-based Code Generation Framework",
Proceedings of ICSOFT 2008, Porto, Portugal.
Joseba Andoni Agirre, Sagardui Goiuria , Leire Etxeberria. Plataforma
DSDM para la Generación de Software Basado en Componentes en
Entornos Empotrados ,”MDSD Platform for Component Based
Embedded Software”. XV Jornadas de Ingeniería del Software y Bases
de Datos. CEDI 2010, Valencia , Spain.
Mohammad Ullah Khan, Kurt Geihs, Felix Gutbrodt, Peter Göhner,
Roland Trauter: Model-Driven Development of Real-Time Systems with
UML 2.0 and C. MDB/MOMPES 2006: 33-42
Schreiner A.T, Object oriented programming with ANSI-C, Publisher:
N/A , Creative Commons License, 1993
OpenArchitectureWare webpage, http://www.openarchitectureware.org/,
2010
ATLAS group, LINA and INRIA, Nantes, France: Specification of the
ATL Virtual Machine. http://www.eclipse.org/m2m/atl/doc/ATL_V
MSpecification%5Bv00.01%5D.pdf.Version 0.1 (2005)
[25] Dennis Wagelaar, Ragnhild Van Der Straeten and Dirk Deridder,
Module superimposition: a composition technique for rule-based model
transformation languages, Software and Systems Modeling, 2009
[26] Paul Kaufmann ,
Marco Platzner. Toward self-adaptive
embedded systems: multi-objective hardware evolution.Proceeding
ARCS'07 Proceedings of the 20th international conference on
Architecture of computing systems Springer-Verlag Berlin, Heidelberg
2007
[27] MISRA-C Official website, http://www.misra.org.uk/ , 2011.
[28] Think , Object Web Open source Middleware , http://think.ow2.org/
[29] POSIX:2008, The Open Group Base Specifications Issue
7,http://pubs.opengroup.org/onlinepubs/9699919799/, 2011.
[30] Real Time Application Interface , RTAI, https://www.rtai.org/, 2011
[31] The
Orocos
project,
Open
Robot
Control
Software,
http://www.orocos.org/, 2011.
[32] Christian Bunse, Hans-Gerhard Gross, Christian Peper: Embedded
system construction – evaluation of model-driven and component-based
development approchaches. Springer – Verlag Berlin Heidelberg, 2009.