|
|
| (126 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | = Evolution Specification: UML Generator for Embedded C =
| + | #REDIRECT [[Eclipse_UML_Generators/Specification/EmbeddedCGenerator/Contribution]] |
| − | | + | |
| − | 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:'''
| + | |
| − | | + | |
| − | *[https://bugs.eclipse.org/bugs/show_bug.cgi?id=438003 Bug TBD] - Feature enhancement
| + | |
| − | | + | |
| − | == Introduction ==
| + | |
| − | | + | |
| − | Major provider of IT systems on-board satellites and space vehicles, Spacebel cumulates more than one century of experience in On Board Software. The expertise encompasses the whole flight software development lifecycle, from the early concept studies, including the analysis and the specification over the architecture, the design and the development, to the validation and the final integration of these critical software systems.
| + | |
| − | | + | |
| − | When developing embedded systems, software designers are squeezed by two trends — shrinking development cycles and growing design intricacy. The divide-and-conquer strategy for developing these complex systems means coordinating the resources of people with expertise in a wide range of disciplines. Quickly, it appears that the text-based approach of embedded system design is not efficient to manage such complex systems. There is a need for modeling C components in order to avoid repetitive and heavy low level processes.
| + | |
| − | | + | |
| − | As indicated in the title, the feature is able to generate C code from UML models. What distinguishes Embedded C from regular C generator are:
| + | |
| − | | + | |
| − | *repeatable and reliable generation of code (preservation of implementation)
| + | |
| − | *highly documented detailed design
| + | |
| − | *compliance to MISRA guidelines of C language in critical systems
| + | |
| − | *traceability of the specification (requirements) in the sources
| + | |
| − |
| + | |
| − | Modeling a complete embedded software written in C with UML is not straightforward. Indeed, the UML standard is sometimes too generic with a high level of abstraction. In order to mitigate the abstraction of UML, the generator comes up with an UML profile: the ''Embedded_C'' profile.
| + | |
| − | | + | |
| − | == 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.
| + | |
| − | | + | |
| − | [[Category:Eclipse_UML_Generators]]
| + | |
| − | [[Category:Eclipse_UML_Generators/Specification]]
| + | |
