Revision as of 06:01, 18 March 2015

Evolution Specification: UML Generator for Embedded C

Current status is DRAFT

Preamble

The traditional text-based approach of embedded software design is not efficient enough to handle such advanced/complex systems. There is a need for modeling C components in order to avoid repetitive and heavy low level processes. As initial contribution to the Eclipse UML generators project, Spacebel proposes development methods and a ANSI C code generator for Embedded Software.

Relevant tickets:

• Bug TBD - Feature enhancement

Introduction

This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.

Detailed Specification

This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:

• a clear description of the objective, i.e. why the evolution is needed.
• a justification of the approach chosen. If other approaches were considered and rejected, document it for future reference.
• limits: things that are out of the scope of the evolution.

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

List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.

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.