Latest revision as of 15:41, 25 September 2016

Specification of the C++ Generation

Current status is PROPOSAL

Preamble

Summary: UML to canonical C++ code generator.

The possible status are (roughly inspired by PEP-0001):

• DRAFT: Initial version and revisions based on internal feedback and discussions. DRAFT versions may never be completed. They have version numbers 0.x.

• PROPOSAL: When the document is considered ready for discussion with the community, it becomes a PROPOSAL. The first such version is numbered 1.0. Feedback from the community are integrated in further versions 1.x which are still PROPOSALs. Changes from one version to the next should be documented inside the document (as the community does not have access to the source repository).

• ACCEPTED: Once agreement has been reached with the community, the document becomes ACCEPTED.This version becomes the authoritative one for guiding the evolution's actual implementation. It should normally be considered freezed. Any change to it should be exceptional and subject to approval by the project manager. Such changes must be clearly documented and justified.

• ARCHIVED: Once the evolution has been implemented _and_ its specification has been integrated into the reference documentation, this document is ARCHIVED. Any further change to the same features should be another __evolution__ .

_Relevant tickets_ (links to the Bugzilla tickets which are related to the change):

• Bug 500763 - initial contribution

Introduction

C++ code is one of the top performing languages regarding processing speed¹, ², ³. It is also a high level language which can represent quite well the UML modeled functionality in an elegant and safe manner without compromising processing speed performance. With the advent of scripting languages increadible advances, C++ development practices received a lot of contributions from their cousin languages to extend its tool set to a whole new level.

The present C++ generator aims to deliver top performance for the applications generated from UML modeling. It is a great candidate to do so because of the C++ best practices being utilized which includes latest C++11⁴ advances like variadic templating among others.

Detailed Specification

The objective of this generator is to stabilish grounds for a fully functional UML to code generator.

The generator includes both structural and behavioral functionality with most utilized diagrams (class and statemachine diagrams):

1. UML StateMachine to UML Class Diagram model to model (M2M) translation with QVTo transformation.
2. UML Class diagrams to canonical C++ code model to text (M2T) translation.

As C++ is an object oriented language, once a UML class diagram is obtained from any other UML diagram, the M2T translation of item 2 can be triggered to generate canonical C++ code.

The M2M translation utilizes the Behavior StateMachine Diagram Meta Model from page 304 of the UML 2.5 specification⁵ as input to the QVTo translation coded in StateMachine_ClassDiagram.qvto file. The result of that transformation is a UML class diagram fully compatible with the M2T translation for generating automatically a fully functional code that makes the statemachine behavior happen in a clean and safe way.

As the generated class diagram includes opaque behavior, once the code is generated,compiled and run, statemachine diagrams can be debugged in the console in a straight forward manner. Event inputs can be given to the state machine via the terminal input data.

Next steps are to make the M2M translation of the remaining UML diagrams. As the framework for that was already set with this proposal, likewise solutions can be utilized for the other diagrams.

Backward Compatibility and Migration Paths

Every one of the sections below should be present. Even if there is no corresponding change (for example no API change), it should exist to mention explicitly "This evolution does not change any API."

Metamodel Changes

Document any change to the Viewpoint metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.

API Changes

List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.

User Interface Changes


It is possible to select to include or not the memory leak test funcionality. Also it has the option to select the compiler to be utilized.

Documentation Changes

List every documentation needing an update here, starting by the New and Noteworthy documentation.

Tests and Non-regression strategy

This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.

Implementation choices and tradeoffs

Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.

Refences

1. Google Publishes C++, Go, Java and Scala Performance Benchmarks
2. The Computer Language Benchmarks Game:Which programs are fast?
3. An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl
4. Wikipedia:C++11
5. UML 2.5 Specification

Contributors

• Daniel Kaminski de Souza
• Marcelo Giesteira Campani