Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Eclipse UML Generators/Specifications/Template"
m (→User Interface Changes) |
m (→Backward Compatibility and Migration Paths) |
||
| Line 32: | Line 32: | ||
== Backward Compatibility and Migration Paths == | == Backward Compatibility and Migration Paths == | ||
| − | |||
| − | |||
=== Metamodel Changes === | === Metamodel Changes === | ||
| Line 51: | Line 49: | ||
=== Documentation Changes === | === Documentation Changes === | ||
| − | List every documentation needing an update here, starting by the New and Noteworthy documentation. | + | List every documentation needing an update here, starting by the New and Noteworthy documentation. |
== Tests and Non-regression strategy == | == Tests and Non-regression strategy == | ||
Revision as of 11:33, 31 July 2014
Evolution Specification: Initial Proposal for RTSJ viewpoint
Current status is DRAFT
Preamble
This is a proposal to contribute graphical viewpoints for the UML design of RTSJ applications, based on Sirius technology.
Relevant tickets:
- Bug 440667 - RTSJ viewpoint on UML models describing RTSJ applications
Introduction
UML is a good standard to model "the whole world" but this facility may involve some onerousnesses and weakness of readability to design any simple and specific systems. Indeed, the handle of profiles/stereotypes or the number of steps to create dependencies between elements e.g. may be tiresome for designers. Besides, it may be useful to design more direct business links between objects in different diagrams/representations, to put in relief business data or simplify their reading with adapted colors, shapes or representation kinds, to capitalize some repetitive tasks in relation to business needs.
So, the idea is to propose some views (representations on UML models) to design different aspects of a system based on distributed components with RTSJ constraints:
- a view to define easily and directly some asynchronous, synchronous or event data interfaces and to define the provided services inside.
- a view to define the kinds of component with their input ports (exposing some previously defined interfaces) and the output ports.
- a view to create the applicative system, instantiating components from the defined kinds and creating the links between the components' ports.
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
Metamodel Changes
This evolution does not change any meta-models.
API Changes
This evolution does not change any API.
User Interface Changes
Read the Sirius User Manual to learn how to handle these interfaces.
Specifically, have a look on the use of Modeling Projects and Representations concepts and the use of functionalities on diagrams as kind of representation.
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.