ANSI-C Code Generation from UML2 Models - It works!
ANSI-C Code Generation from UML2 Models - It works!
ANSI-C Code Generation from UML2 Models - It works!
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
1 von 32<br />
ViPER <strong>Code</strong>Gen<br />
<strong>ANSI</strong>-C code generation <strong>from</strong> <strong>UML2</strong> models<br />
Motivation & Requirements<br />
<strong>UML2</strong> Structural <strong>Models</strong><br />
Conceptual Design<br />
Technical Design<br />
Summary
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
2 von 32<br />
Motivation<br />
MeDUSA: Method for Designing <strong>UML2</strong>-based Embedded<br />
System Software Architectures<br />
MeDUSA is a design method that was developed by the Research<br />
Group Software Construction and the ABB Research Centre Germany<br />
as an advancement to the COMET method developed by Hassan<br />
Gomaa.<br />
<strong>It</strong> is instance-driven (run-time structure is modeled rather than classstructure)<br />
and object-based (inheritance and polymorphism are not<br />
regarded) design method, relying on a <strong>UML2</strong> notation.<br />
MeDUSA was developed to best support the application domain of small<br />
embedded control systems (field devices) and the organizational<br />
environment of distributed development teams.<br />
<strong>It</strong> should overcome the shortcomings and overhead of the COMET<br />
method that was noticed during its practical application in ABB Business<br />
Unit Instrumentation.<br />
ViPER: Visual Modeling Platform for Embedded System<br />
Software ARchitectures<br />
ViPER was developed to demonstrate how tool-support for the MeDUSA<br />
method could be defined.<br />
<strong>It</strong> is a <strong>UML2</strong>-based modeling platform integrated into Eclipse that is<br />
conformant to the <strong>UML2</strong> standard.<br />
ViPER was designed to be extensible so that further research<br />
experience could be integrated (e.g. support for modeling product<br />
families).
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
3 von 32<br />
Motivation<br />
An <strong>ANSI</strong>-C code generator integrated into the<br />
ViPER platform was essential to demonstrate how<br />
the MDD-approach of the MeDUSA method could<br />
be tool-supported:<br />
Without a code generator for <strong>ANSI</strong>-C it would not be<br />
possible to convince developers in the regarded<br />
application domain of the benefits of model-driven<br />
development.<br />
No state-of-the-art tool was (and is) capable of generating<br />
code <strong>from</strong> the structural information that can be captured<br />
in <strong>UML2</strong> models via the newly introduced <strong>UML2</strong><br />
composite structure diagrams, which are heavily<br />
employed by MeDUSA<br />
Decision was made to develop such a code<br />
generator in a diploma thesis, which was started by<br />
Mathias Funk in April 2006 and will end in October<br />
2006.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
4 von 32<br />
Requirements - ViPER <strong>Code</strong> Generator<br />
The code generator should at first support<br />
generation of <strong>ANSI</strong>-C code <strong>from</strong> the structural<br />
information that can be specified via <strong>UML2</strong> models.<br />
The code generator shall be easily customizable in<br />
such a way that a generic (non-optimized) code<br />
generation is provided, which can then be tailored to<br />
generate customized (optimized) code for MeDUSAprofiled<br />
models, or even for product-line models.<br />
<strong>It</strong> shall be extensible so that integration of code<br />
generation support for behavioral aspects.<br />
<strong>It</strong> shall be integrated into the ViPER platform and<br />
should be able to process EMF-based <strong>UML2</strong> models<br />
edited via the ViPER <strong>UML2</strong> editor.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
5 von 32<br />
<strong>UML2</strong> Structural <strong>Models</strong><br />
So, what information should <strong>ANSI</strong>-C code be generated <strong>from</strong>?<br />
Or different, what structural information can be specified by<br />
<strong>UML2</strong> models?<br />
<strong>UML2</strong> offers six diagram types to specify structural system<br />
aspects, <strong>from</strong> which four can be seen as “first-level”.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
6 von 32<br />
<strong>UML2</strong> Structural <strong>Models</strong><br />
<strong>UML2</strong> Package diagrams offer the modeling<br />
elements Package, Package Import, and Package<br />
Merge<br />
Package Merge and Package Import were decided<br />
to be out of scope of ViPER <strong>Code</strong>Gen, as they are<br />
solely used in application models.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models UML 2 Class diagrams offer the modeling elements Class,<br />
Interface, Association, Generalization, Dependency, Usage,<br />
and Interface Realization.<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
7 von 32<br />
<strong>UML2</strong> Structural <strong>Models</strong><br />
Generalization was decided to be – at first – out of scope of<br />
ViPER <strong>Code</strong>Gen (although it should be extensible to support<br />
generalization if needed)
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
8 von 32<br />
<strong>UML2</strong> Structural <strong>Models</strong><br />
<strong>UML2</strong> Composite Structure diagrams offer the modeling<br />
elements Structured Class, Part, Port, Connector, Exposed<br />
Interface, Collaboration, Collaboration Occurrence, and Role<br />
Binding<br />
Collaboration, Collaboration Occurrence, and Role Binding<br />
were decided to be out of scope of ViPER <strong>Code</strong>Gen
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
9 von 32<br />
<strong>UML2</strong> Structural <strong>Models</strong><br />
<strong>UML2</strong> Component diagrams offer the modeling elements<br />
Component, Port, Connector, Interface, Interface Realization,<br />
Usage, and Artifact<br />
Artifacts were decided to be out of scope of ViPER <strong>Code</strong>Gen,<br />
as they focus on deployment
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
10 von 32<br />
Conceptual Design<br />
While taking composite structure and component<br />
diagrams as the primary diagram types, code<br />
generator has to take into account the structural<br />
information that can be specified via composite<br />
structure, component, class and package diagrams.<br />
The structural information specified via package and class<br />
diagrams is quite straightforward, as the modeling<br />
concepts offered are rather concrete, and code<br />
generation for such elements is largely understood.<br />
Composite structure and component diagrams have to be<br />
specially regarded, as they offer newly introduced and<br />
rather abstract modeling concepts.<br />
These rather abstract concepts are in detail:<br />
Structured Classifier & Encapsulated Classifier<br />
Port, Part (Property), Connector (Assembly & Delegation)<br />
Required Interface, Provided Interface (Usage, Interface<br />
Realization)
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models Taking a look at the classifier/instance relationship<br />
of these elements, it can be determined that<br />
Interfaces themselves cannot be instantiated and do only<br />
serve as auxiliary constructs to specify the signature of<br />
other Classifiers<br />
Parts represent instances of a Type owned by another<br />
Structured Classifier. This may be an instance of a<br />
Structured or Encapsulated Classifier or just a plain<br />
Classifier.<br />
Ports represent interaction points (instances) of an<br />
Encapsulated Classifier. They are typed by a Type, which<br />
specifies the provided and required interfaces exposed<br />
via the port (through Usage and InterfaceRealization<br />
dependencies).<br />
Connectors represent instances of Associations that are<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
11 von 32<br />
Conceptual Design<br />
owned by a StructuredClassifier. The roles connected via<br />
the ConnectorEnds (parts or ports) have to be typed<br />
according to the association ends.<br />
For code generation, the classifiers are the<br />
“elements-of-scope”.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
12 von 32<br />
Conceptual Design<br />
The conversion of Classifiers into <strong>ANSI</strong>-C code<br />
should be done in a transparent and universal way<br />
The generated <strong>ANSI</strong>-C code for a Classifier should only<br />
depend on its meta type, regarding if it is an Encapsulated<br />
or Structured Classifier, an Association, or just a plain<br />
Classifier<br />
The generated <strong>ANSI</strong>-C code of a Classifier should NOT<br />
depend on how concrete instances of that classifier are<br />
used. Example: <strong>ANSI</strong>-C code for an Association should<br />
be independent on if it is used to type a delegation or<br />
assembly connector.<br />
Regarding that design rationale, how can the<br />
transformation of Classifiers, Associations and<br />
Structured & Encapsulated Classifiers be<br />
realized?
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
13 von 32<br />
Conceptual Design - Classifier<br />
Classifier are equipped with provided and<br />
required methods
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
14 von 32<br />
Conceptual Design - Association<br />
Associations offer required and provided<br />
methods of association end types
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
15 von 32<br />
Conceptual Design - Structured Classifier<br />
Assembly connector between two parts with<br />
ports
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
16 von 32<br />
Conceptual Design - Structured Classifier<br />
Assembly connectors between to parts (with and<br />
without ports)
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
17 von 32<br />
Conceptual Design - Encapsulated Classifier<br />
Behavior port directly connected to the behavior<br />
of its owning Encapsulated Classifier
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
18 von 32<br />
Conceptual Design - Encapsulated Classifier<br />
Non-behavior ports connected to an internal part<br />
(with port)
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
19 von 32<br />
Technical Design - Concept<br />
A single-stage generation process to directly generate Cfiles<br />
<strong>from</strong> a <strong>UML2</strong> model would lead to some severe<br />
shortcomings:<br />
Complexity of such a monolithic code generator would be<br />
tremendous, leading to a complicated development and a<br />
decreased maintainability<br />
Customization/extension capabilities would be decreased<br />
because the conceptual conversion knowledge would be<br />
intertwined with many merely technical aspects, e.g. the<br />
generation and merging of files.<br />
A two-staged generation process consisting of a <strong>UML2</strong>-to-<br />
<strong>ANSI</strong>-C transformation stage and a <strong>ANSI</strong>-C-to-<strong>Code</strong><br />
generation stage would offer outstanding benefits:<br />
Conceptual conversion process (transformation) and actual<br />
generation process can be developed and maintained<br />
independently of each other<br />
Transformation is most likely subject to change and may be<br />
altered e.g. to generate customized/optimized code for MeDUSAprofiled<br />
models<br />
<strong>Generation</strong> is quite stable and may only be altered to adapt to<br />
new platforms, e.g. for M16C<br />
Interim <strong>ANSI</strong>-C Model can be easily validated, compared, and<br />
augmented.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
20 von 32<br />
Technical Design - Concept
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
21 von 32<br />
<strong>ANSI</strong>-C Meta Model<br />
So first, an <strong>ANSI</strong>-C meta model had to be<br />
designed that captures the c-language concepts<br />
and can be directly transformed into code.<br />
No such <strong>ANSI</strong>-C model is (indeed!) publicly<br />
available so, decision was made to develop it<br />
proprietarily.<br />
The abstract syntax tree (AST) implemented by the<br />
Eclipse CDT project (C/C++ Development Tooling) was<br />
taken as a starting point (core concepts)<br />
Container and model constructs were added to offer<br />
capabilities to group multiple translation units and to<br />
further structure models hierarchically.<br />
Annotations (comments and protected regions) were<br />
added additional information not covered by the C syntax.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
22 von 32<br />
<strong>ANSI</strong>-C Meta Model - Core
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
23 von 32<br />
<strong>ANSI</strong>-C Meta Model - Container
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
24 von 32<br />
<strong>ANSI</strong>-C Meta Model - ASTElement
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
25 von 32<br />
<strong>ANSI</strong>-C Meta Model –PreprocessorElement
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
26 von 32<br />
<strong>ANSI</strong>-C Meta Model – Technical Aspects<br />
The decision was made to implement the <strong>ANSI</strong>-C meta model<br />
using EMF (Eclipse Modeling Framework) technology<br />
“EMF provides tools and runtime support to produce a set of<br />
Java classes for the model, a set of adapter classes that enable<br />
viewing and command-based editing of the model, and a basic<br />
editor […]. Most important of all, EMF provides the foundation<br />
for interoperability with other EMF-based tools and applications”<br />
This is reasonably because the <strong>UML2</strong> meta model provided by<br />
the Eclipse technology project, which is used by ViPER <strong>UML2</strong><br />
is also an EMF-based implementation.<br />
If the same underlying EMF-technology is used, an EMF-based<br />
generation framework can be employed to realize the<br />
transformation/generation stages of the code generator<br />
So far, openArchitectureWare is the first-choice state-of-the-art<br />
transformation framework for EMF-based models<br />
Note: As the Rational Software Architect uses the same<br />
underlying <strong>UML2</strong> model, ViPER <strong>Code</strong>Gen could also be used<br />
for <strong>UML2</strong> model provided by the RSA.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
27 von 32<br />
openArchitectureWare<br />
“openArchitectureWare (oAW) is a modular MDA/MDD<br />
generator framework implemented in Java(TM).<br />
<strong>It</strong> supports parsing of arbitrary models, and a language family<br />
to check and transform models as well as generate code based<br />
on them.<br />
Supporting editors are based on the Eclipse platform. OAW<br />
has strong support for EMF (Eclipse Modelling Framework)<br />
based models but can work with other models, too (e.g. <strong>UML2</strong>,<br />
XML or simple JavaBeans).<br />
At the core there is a workflow engine allowing the definition of<br />
generator/transformation workflows.<br />
A number of prebuilt workflow components can be used for<br />
reading and instantiating models, checking them for constraint<br />
violations, transforming them into other models and then finally,<br />
for generating code.”
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
28 von 32<br />
ViPER <strong>Code</strong>gen – Technical Design
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
29 von 32<br />
Validation with OAW Check<br />
Example: Check Integrity of <strong>UML2</strong> Connector<br />
/* Check integrity of Connector */<br />
context uml::Connector ERROR "Connector must have a connector kind" :<br />
uml::ConnectorKind.isInstance(kind)<br />
;<br />
context uml::Connector ERROR "Connector must have a name" :<br />
name != null<br />
;<br />
context uml::Connector ERROR "Connector type must not be empty but an association" :<br />
type != null && uml::Association.isInstance(type)<br />
;<br />
context uml::Connector ERROR "Assembly connector ends must both have a<br />
partWithPort assigned if role type is uml::Port" :<br />
( kind == uml::ConnectorKind::delegation)<br />
|| end.forAll(e|(e.role.metaType != uml::Port)<br />
|| e.partWithPort != null )<br />
;<br />
context uml::ConnectorEnd ERROR "ConnectorEnd.role's type should have one or<br />
more interfaces associated" :<br />
( (uml::Class)role.type).getUsedInterfaces().size > 0<br />
|| ((uml::Class)role.type).getImplementedInterfaces().size > 0<br />
;
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
30 von 32<br />
Transformation with OAW xTend<br />
Example: Transform <strong>UML2</strong> Component<br />
extension org::nyssen::viper::codegen::uml22ansic::transformation::generic::AllExtensions;<br />
ansic::Container createComponent(uml::Component c, uml::Model m) :<br />
;<br />
// create new container holding the translation units that constitute the component<br />
let d = new ansic::Container :<br />
d.setName(c.name) -><br />
d<br />
// create source, header, and forward declaration translation units<br />
d.translationUnit.add(c.createSourceFile(c.name)) -><br />
d.translationUnit.add(c.createHeaderFile(c.name)) -><br />
d.translationUnit.add(c.createForwardDecl(c.name)) -><br />
// create classifiers contained as owned packageable elements as subcontaines<br />
d.subContainer.addAll(c.getGeneratedClassifiers().createClassifier(m)) ->
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
31 von 32<br />
<strong>Generation</strong> with OAW xPand<br />
Example: <strong>Generation</strong> of AnsiC TranslationUnit<br />
«IMPORT org::nyssen::viper::codegen::ansic»<br />
«EXTENSION org::nyssen::viper::codegen::uml22ansic::generation::generic::Utils»<br />
«DEFINE E FOR ansic::TranslationUnit»<br />
«FILE container.getFullFilePath() + "/" + name-»<br />
/*************************************************************<br />
* File: «name»<br />
* Generated by ViPER.<strong>Code</strong>gen<br />
*************************************************************/<br />
«EXPAND ASTElement::E FOREACH getOrphanPreprocessorStatements()»<br />
«EXPAND ASTElement::E FOREACH cElement-»<br />
«ENDFILE»<br />
«ENDDEFINE»
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
32 von 32<br />
ViPER <strong>Code</strong>gen – Plugin Design<br />
ViPER<br />
Feature<br />
Visual Modeling<br />
ViPER<br />
Common<br />
ViPER<br />
<strong>UML2</strong><br />
Eclipse Platform<br />
Eclipse Tools (GEF, EMF, <strong>UML2</strong>)<br />
Eclipse Technology (EMFT)<br />
ViPER Platform<br />
Transformation/<strong>Generation</strong><br />
ViPER<br />
OAW <strong>UML2</strong><br />
ViPER<br />
OAW Common<br />
ViPER<br />
<strong>Code</strong>Gen<br />
Open Architecture Ware
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
33 von 32<br />
Summary and Outlook<br />
Summary<br />
ViPER <strong>Code</strong>Gen offers generic <strong>ANSI</strong>-C code generation<br />
for <strong>UML2</strong> models based on structural information<br />
specified via Component, Composite Structure, Class and<br />
Package diagrams.<br />
ViPER <strong>Code</strong>Gen is extensible and customizable through<br />
its modular design.<br />
ViPER <strong>Code</strong>Gen is interoperable with modeling tools<br />
using the <strong>UML2</strong> meta model provided by the Eclipse<br />
<strong>UML2</strong> technology project, which are amongst others,<br />
ViPER-<strong>UML2</strong> and Rational Software Architect.<br />
Outlook and Future Work<br />
Transformation can be optimized (singletons, simple<br />
types, connectors) and customized (MeDUSA-profiled<br />
models).<br />
<strong>Generation</strong> can be adapted to special platforms (e.g.<br />
M16C, MSP430)<br />
ViPER <strong>Code</strong>Gen can be extended to support e.g.<br />
generation of behavioral code or product-line platform<br />
code.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
34 von 32<br />
Thank you for your attention!
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
35 von 32<br />
MeDUSA profile models<br />
How are the structural diagrams employed by<br />
MeDUSA?<br />
MeDUSA makes use of composite structure,<br />
component, and class diagrams to specify the<br />
software system’s detailed design. Package<br />
diagrams could be used but are not enforced.<br />
A component diagram is used in form of a Structural<br />
System Architecture Diagram to denote the internal<br />
decomposition of the system into subsystem (instances).<br />
Composite structure diagrams are used in the form of<br />
Subsystem Design diagrams to specify the internal<br />
decomposition of each subsystem into component<br />
(instances) or objects.<br />
Class diagrams are used as Detailed Design Diagrams to<br />
specify the class design.
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
36 von 32<br />
MeDUSA-profiled models<br />
The System Architecture Diagram (Component<br />
respectively Composite Structure Diagram) captures the<br />
system architecture in terms of<br />
A structured component representing the system<br />
Internal parts (with ports) representing the aggregated<br />
subsystem (instances)<br />
Assembly connectors (ball-and-socket) denoting structural<br />
relationships between those subsystems<br />
The Subsystem Design Diagrams (Composite Structure)<br />
capture the design of a subsystem in terms of<br />
A structured class with ports representing the subsystem<br />
(component)<br />
Internal parts (optionally with ports) representing the aggregated<br />
application objects (or components, in case of complex<br />
subsystems)<br />
Assembly and delegation connectors representing the structural<br />
relationships between the objects/components among each<br />
other and towards the surrounding subsystem<br />
The Detailed Design Diagram (Class Diagram) captures the<br />
detailed class design of the application objects and port<br />
types/interfaces in terms of<br />
Classes, interfaces, associations, interface realizations and<br />
interface usages
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
37 von 32<br />
System Architecture - Example<br />
This should indeed be a Component<br />
diagram showing subsystem instances and<br />
their structural interdependencies in form<br />
of bass-and-socket assembly connectors!
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
38 von 32<br />
Subsystem Design - Example
ViPER<br />
<strong>Code</strong>Gen<br />
Ansi-C code generation<br />
<strong>from</strong> <strong>UML2</strong> models<br />
RWTH<br />
Aachen<br />
Alexander Nyßen<br />
Research Group<br />
Software Construction<br />
Prof. Dr. H. Lichter<br />
39 von 32<br />
Class Design - Example