Eclipse UML Generators/Specification/C++ Generation/Specification of the C++ Generation
- 1 Specification of the C++ Generation
- 1.1 Preamble
- 1.2 Introduction
- 1.3 Detailed Specification
- 1.4 Backward Compatibility and Migration Paths
- 1.5 Tests and Non-regression strategy
- 1.6 Implementation choices and tradeoffs
- 1.7 Refences
- 1.8 Contributors
Specification of the C++ Generation
Current status is PROPOSAL
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
C++ code is one of the top performing languages regarding processing speed1, 2, 3. 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++114 advances like variadic templating among others.
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):
- UML StateMachine to UML Class Diagram model to model (M2M) translation with QVTo transformation.
- 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 specification5 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."
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.
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.
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.
- Google Publishes C++, Go, Java and Scala Performance Benchmarks
- The Computer Language Benchmarks Game:Which programs are fast?
- An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl
- UML 2.5 Specification