ANSI-C Code Generation from UML2 Models - It works!

ViPER 

CodeGen 

Ansi-C code generation 

from UML2 models 

RWTH 

Aachen 

Alexander Nyßen 

Research Group 

Software Construction 

Prof. Dr. H. Lichter 

1 von 32 

ViPER CodeGen 

ANSI-C code generation from UML2 models 

Motivation & Requirements 

UML2 Structural Models 

Conceptual Design 

Technical Design 

Summary

ViPER 




RWTH 

Aachen 





2 von 32 

Motivation 

MeDUSA: Method for Designing UML2-based Embedded 

System Software Architectures 

MeDUSA is a design method that was developed by the Research 

Group Software Construction and the ABB Research Centre Germany 

as an advancement to the COMET method developed by Hassan 

Gomaa. 

It is instance-driven (run-time structure is modeled rather than classstructure) 

and object-based (inheritance and polymorphism are not 

regarded) design method, relying on a UML2 notation. 

MeDUSA was developed to best support the application domain of small 

embedded control systems (field devices) and the organizational 

environment of distributed development teams. 

It should overcome the shortcomings and overhead of the COMET 

method that was noticed during its practical application in ABB Business 

Unit Instrumentation. 

ViPER: Visual Modeling Platform for Embedded System 

Software ARchitectures 

ViPER was developed to demonstrate how tool-support for the MeDUSA 

method could be defined. 

It is a UML2-based modeling platform integrated into Eclipse that is 

conformant to the UML2 standard. 

ViPER was designed to be extensible so that further research 

experience could be integrated (e.g. support for modeling product 

families).

ViPER 




RWTH 

Aachen 





3 von 32 

Motivation 

An ANSI-C code generator integrated into the 

ViPER platform was essential to demonstrate how 

the MDD-approach of the MeDUSA method could 

be tool-supported: 

Without a code generator for ANSI-C it would not be 

possible to convince developers in the regarded 

application domain of the benefits of model-driven 

development. 

No state-of-the-art tool was (and is) capable of generating 

code from the structural information that can be captured 

in UML2 models via the newly introduced UML2 

composite structure diagrams, which are heavily 

employed by MeDUSA 

Decision was made to develop such a code 

generator in a diploma thesis, which was started by 

Mathias Funk in April 2006 and will end in October 

2006.

ViPER 




RWTH 

Aachen 





4 von 32 

Requirements - ViPER Code Generator 

The code generator should at first support 

generation of ANSI-C code from the structural 

information that can be specified via UML2 models. 

The code generator shall be easily customizable in 

such a way that a generic (non-optimized) code 

generation is provided, which can then be tailored to 

generate customized (optimized) code for MeDUSAprofiled 

models, or even for product-line models. 

It shall be extensible so that integration of code 

generation support for behavioral aspects. 

It shall be integrated into the ViPER platform and 

should be able to process EMF-based UML2 models 

edited via the ViPER UML2 editor.

ViPER 




RWTH 

Aachen 





5 von 32 


So, what information should ANSI-C code be generated from? 

Or different, what structural information can be specified by 

UML2 models? 

UML2 offers six diagram types to specify structural system 

aspects, from which four can be seen as “first-level”.

ViPER 




RWTH 

Aachen 





6 von 32 


UML2 Package diagrams offer the modeling 

elements Package, Package Import, and Package 

Merge 

Package Merge and Package Import were decided 

to be out of scope of ViPER CodeGen, as they are 

solely used in application models.

ViPER 



from UML2 models UML 2 Class diagrams offer the modeling elements Class, 

Interface, Association, Generalization, Dependency, Usage, 

and Interface Realization. 

RWTH 

Aachen 





7 von 32 


Generalization was decided to be – at first – out of scope of 

ViPER CodeGen (although it should be extensible to support 

generalization if needed)

ViPER 




RWTH 

Aachen 





8 von 32 


UML2 Composite Structure diagrams offer the modeling 

elements Structured Class, Part, Port, Connector, Exposed 

Interface, Collaboration, Collaboration Occurrence, and Role 

Binding 

Collaboration, Collaboration Occurrence, and Role Binding 

were decided to be out of scope of ViPER CodeGen

ViPER 




RWTH 

Aachen 





9 von 32 


UML2 Component diagrams offer the modeling elements 

Component, Port, Connector, Interface, Interface Realization, 

Usage, and Artifact 

Artifacts were decided to be out of scope of ViPER CodeGen, 

as they focus on deployment

ViPER 




RWTH 

Aachen 





10 von 32 


While taking composite structure and component 

diagrams as the primary diagram types, code 

generator has to take into account the structural 

information that can be specified via composite 

structure, component, class and package diagrams. 

The structural information specified via package and class 

diagrams is quite straightforward, as the modeling 

concepts offered are rather concrete, and code 

generation for such elements is largely understood. 

Composite structure and component diagrams have to be 

specially regarded, as they offer newly introduced and 

rather abstract modeling concepts. 

These rather abstract concepts are in detail: 

Structured Classifier & Encapsulated Classifier 

Port, Part (Property), Connector (Assembly & Delegation) 

Required Interface, Provided Interface (Usage, Interface 

Realization)

ViPER 



from UML2 models Taking a look at the classifier/instance relationship 

of these elements, it can be determined that 

Interfaces themselves cannot be instantiated and do only 

serve as auxiliary constructs to specify the signature of 

other Classifiers 

Parts represent instances of a Type owned by another 

Structured Classifier. This may be an instance of a 

Structured or Encapsulated Classifier or just a plain 

Classifier. 

Ports represent interaction points (instances) of an 

Encapsulated Classifier. They are typed by a Type, which 

specifies the provided and required interfaces exposed 

via the port (through Usage and InterfaceRealization 

dependencies). 

Connectors represent instances of Associations that are 

RWTH 

Aachen 





11 von 32 


owned by a StructuredClassifier. The roles connected via 

the ConnectorEnds (parts or ports) have to be typed 

according to the association ends. 

For code generation, the classifiers are the 

“elements-of-scope”.

ViPER 




RWTH 

Aachen 





12 von 32 


The conversion of Classifiers into ANSI-C code 

should be done in a transparent and universal way 

The generated ANSI-C code for a Classifier should only 

depend on its meta type, regarding if it is an Encapsulated 

or Structured Classifier, an Association, or just a plain 

Classifier 

The generated ANSI-C code of a Classifier should NOT 

depend on how concrete instances of that classifier are 

used. Example: ANSI-C code for an Association should 

be independent on if it is used to type a delegation or 

assembly connector. 

Regarding that design rationale, how can the 

transformation of Classifiers, Associations and 

Structured & Encapsulated Classifiers be 

realized?

ViPER 




RWTH 

Aachen 





13 von 32 

Conceptual Design - Classifier 

Classifier are equipped with provided and 

required methods

ViPER 




RWTH 

Aachen 





14 von 32 

Conceptual Design - Association 

Associations offer required and provided 

methods of association end types

ViPER 




RWTH 

Aachen 





15 von 32 

Conceptual Design - Structured Classifier 

Assembly connector between two parts with 

ports

ViPER 




RWTH 

Aachen 





16 von 32 

Conceptual Design - Structured Classifier 

Assembly connectors between to parts (with and 

without ports)

ViPER 




RWTH 

Aachen 





17 von 32 

Conceptual Design - Encapsulated Classifier 

Behavior port directly connected to the behavior 

of its owning Encapsulated Classifier

ViPER 




RWTH 

Aachen 





18 von 32 

Conceptual Design - Encapsulated Classifier 

Non-behavior ports connected to an internal part 

(with port)

ViPER 




RWTH 

Aachen 





19 von 32 

Technical Design - Concept 

A single-stage generation process to directly generate Cfiles 

from a UML2 model would lead to some severe 

shortcomings: 

Complexity of such a monolithic code generator would be 

tremendous, leading to a complicated development and a 

decreased maintainability 

Customization/extension capabilities would be decreased 

because the conceptual conversion knowledge would be 

intertwined with many merely technical aspects, e.g. the 

generation and merging of files. 

A two-staged generation process consisting of a UML2-to- 

ANSI-C transformation stage and a ANSI-C-to-Code 

generation stage would offer outstanding benefits: 

Conceptual conversion process (transformation) and actual 

generation process can be developed and maintained 

independently of each other 

Transformation is most likely subject to change and may be 

altered e.g. to generate customized/optimized code for MeDUSAprofiled 

models 

Generation is quite stable and may only be altered to adapt to 

new platforms, e.g. for M16C 

Interim ANSI-C Model can be easily validated, compared, and 

augmented.

ViPER 




RWTH 

Aachen 





20 von 32 

Technical Design - Concept

ViPER 




RWTH 

Aachen 





21 von 32 

ANSI-C Meta Model 

So first, an ANSI-C meta model had to be 

designed that captures the c-language concepts 

and can be directly transformed into code. 

No such ANSI-C model is (indeed!) publicly 

available so, decision was made to develop it 

proprietarily. 

The abstract syntax tree (AST) implemented by the 

Eclipse CDT project (C/C++ Development Tooling) was 

taken as a starting point (core concepts) 

Container and model constructs were added to offer 

capabilities to group multiple translation units and to 

further structure models hierarchically. 

Annotations (comments and protected regions) were 

added additional information not covered by the C syntax.

ViPER 




RWTH 

Aachen 





22 von 32 

ANSI-C Meta Model - Core

ViPER 




RWTH 

Aachen 





23 von 32 

ANSI-C Meta Model - Container

ViPER 




RWTH 

Aachen 





24 von 32 

ANSI-C Meta Model - ASTElement

ViPER 




RWTH 

Aachen 





25 von 32 

ANSI-C Meta Model –PreprocessorElement

ViPER 




RWTH 

Aachen 





26 von 32 

ANSI-C Meta Model – Technical Aspects 

The decision was made to implement the ANSI-C meta model 

using EMF (Eclipse Modeling Framework) technology 

“EMF provides tools and runtime support to produce a set of 

Java classes for the model, a set of adapter classes that enable 

viewing and command-based editing of the model, and a basic 

editor […]. Most important of all, EMF provides the foundation 

for interoperability with other EMF-based tools and applications” 

This is reasonably because the UML2 meta model provided by 

the Eclipse technology project, which is used by ViPER UML2 

is also an EMF-based implementation. 

If the same underlying EMF-technology is used, an EMF-based 

generation framework can be employed to realize the 

transformation/generation stages of the code generator 

So far, openArchitectureWare is the first-choice state-of-the-art 

transformation framework for EMF-based models 

Note: As the Rational Software Architect uses the same 

underlying UML2 model, ViPER CodeGen could also be used 

for UML2 model provided by the RSA.

ViPER 




RWTH 

Aachen 





27 von 32 

openArchitectureWare 

“openArchitectureWare (oAW) is a modular MDA/MDD 

generator framework implemented in Java(TM). 

It supports parsing of arbitrary models, and a language family 

to check and transform models as well as generate code based 

on them. 

Supporting editors are based on the Eclipse platform. OAW 

has strong support for EMF (Eclipse Modelling Framework) 

based models but can work with other models, too (e.g. UML2, 

XML or simple JavaBeans). 

At the core there is a workflow engine allowing the definition of 

generator/transformation workflows. 

A number of prebuilt workflow components can be used for 

reading and instantiating models, checking them for constraint 

violations, transforming them into other models and then finally, 

for generating code.”

ViPER 




RWTH 

Aachen 





28 von 32 

ViPER Codegen – Technical Design

ViPER 




RWTH 

Aachen 





29 von 32 

Validation with OAW Check 

Example: Check Integrity of UML2 Connector 

/* Check integrity of Connector */ 

context uml::Connector ERROR "Connector must have a connector kind" : 

uml::ConnectorKind.isInstance(kind) 

; 

context uml::Connector ERROR "Connector must have a name" : 

name != null 

; 

context uml::Connector ERROR "Connector type must not be empty but an association" : 

type != null && uml::Association.isInstance(type) 

; 

context uml::Connector ERROR "Assembly connector ends must both have a 

partWithPort assigned if role type is uml::Port" : 

( kind == uml::ConnectorKind::delegation) 

|| end.forAll(e|(e.role.metaType != uml::Port) 

|| e.partWithPort != null ) 

; 

context uml::ConnectorEnd ERROR "ConnectorEnd.role's type should have one or 

more interfaces associated" : 

( (uml::Class)role.type).getUsedInterfaces().size > 0 

|| ((uml::Class)role.type).getImplementedInterfaces().size > 0 

;

ViPER 




RWTH 

Aachen 





30 von 32 

Transformation with OAW xTend 

Example: Transform UML2 Component 

extension org::nyssen::viper::codegen::uml22ansic::transformation::generic::AllExtensions; 

ansic::Container createComponent(uml::Component c, uml::Model m) : 

; 

// create new container holding the translation units that constitute the component 

let d = new ansic::Container : 

d.setName(c.name) -> 

d 

// create source, header, and forward declaration translation units 

d.translationUnit.add(c.createSourceFile(c.name)) -> 

d.translationUnit.add(c.createHeaderFile(c.name)) -> 

d.translationUnit.add(c.createForwardDecl(c.name)) -> 

// create classifiers contained as owned packageable elements as subcontaines 

d.subContainer.addAll(c.getGeneratedClassifiers().createClassifier(m)) ->

ViPER 




RWTH 

Aachen 





31 von 32 

Generation with OAW xPand 

Example: Generation of AnsiC TranslationUnit 

«IMPORT org::nyssen::viper::codegen::ansic» 

«EXTENSION org::nyssen::viper::codegen::uml22ansic::generation::generic::Utils» 

«DEFINE E FOR ansic::TranslationUnit» 

«FILE container.getFullFilePath() + "/" + name-» 

/************************************************************* 

* File: «name» 

* Generated by ViPER.Codegen 

*************************************************************/ 

«EXPAND ASTElement::E FOREACH getOrphanPreprocessorStatements()» 

«EXPAND ASTElement::E FOREACH cElement-» 

«ENDFILE» 

«ENDDEFINE»

ViPER 




RWTH 

Aachen 





32 von 32 

ViPER Codegen – Plugin Design 

ViPER 

Feature 

Visual Modeling 

ViPER 

Common 

ViPER 

UML2 

Eclipse Platform 

Eclipse Tools (GEF, EMF, UML2) 

Eclipse Technology (EMFT) 

ViPER Platform 

Transformation/Generation 

ViPER 

OAW UML2 

ViPER 

OAW Common 

ViPER 


Open Architecture Ware

ViPER 




RWTH 

Aachen 





33 von 32 

Summary and Outlook 

Summary 

ViPER CodeGen offers generic ANSI-C code generation 

for UML2 models based on structural information 

specified via Component, Composite Structure, Class and 

Package diagrams. 

ViPER CodeGen is extensible and customizable through 

its modular design. 

ViPER CodeGen is interoperable with modeling tools 

using the UML2 meta model provided by the Eclipse 

UML2 technology project, which are amongst others, 

ViPER-UML2 and Rational Software Architect. 

Outlook and Future Work 

Transformation can be optimized (singletons, simple 

types, connectors) and customized (MeDUSA-profiled 

models). 

Generation can be adapted to special platforms (e.g. 

M16C, MSP430) 

ViPER CodeGen can be extended to support e.g. 

generation of behavioral code or product-line platform 

code.

ViPER 




RWTH 

Aachen 





34 von 32 

Thank you for your attention!

ViPER 




RWTH 

Aachen 





35 von 32 

MeDUSA profile models 

How are the structural diagrams employed by 

MeDUSA? 

MeDUSA makes use of composite structure, 

component, and class diagrams to specify the 

software system’s detailed design. Package 

diagrams could be used but are not enforced. 

A component diagram is used in form of a Structural 

System Architecture Diagram to denote the internal 

decomposition of the system into subsystem (instances). 

Composite structure diagrams are used in the form of 

Subsystem Design diagrams to specify the internal 

decomposition of each subsystem into component 

(instances) or objects. 

Class diagrams are used as Detailed Design Diagrams to 

specify the class design.

ViPER 




RWTH 

Aachen 





36 von 32 

MeDUSA-profiled models 

The System Architecture Diagram (Component 

respectively Composite Structure Diagram) captures the 

system architecture in terms of 

A structured component representing the system 

Internal parts (with ports) representing the aggregated 

subsystem (instances) 

Assembly connectors (ball-and-socket) denoting structural 

relationships between those subsystems 

The Subsystem Design Diagrams (Composite Structure) 

capture the design of a subsystem in terms of 

A structured class with ports representing the subsystem 

(component) 

Internal parts (optionally with ports) representing the aggregated 

application objects (or components, in case of complex 

subsystems) 

Assembly and delegation connectors representing the structural 

relationships between the objects/components among each 

other and towards the surrounding subsystem 

The Detailed Design Diagram (Class Diagram) captures the 

detailed class design of the application objects and port 

types/interfaces in terms of 

Classes, interfaces, associations, interface realizations and 

interface usages

ViPER 




RWTH 

Aachen 





37 von 32 

System Architecture - Example 

This should indeed be a Component 

diagram showing subsystem instances and 

their structural interdependencies in form 

of bass-and-socket assembly connectors!

ViPER 




RWTH 

Aachen 





38 von 32 

Subsystem Design - Example

ViPER 




RWTH 

Aachen 





39 von 32 

Class Design - Example

ANSI-C Code Generation from UML2 Models - It works!

Create successful ePaper yourself

Delete template?

Save as template?