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.