Notice: This Wiki is now read only and edits are no longer 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 (→Introduction) |
m (→Introduction) |
||
| Line 18: | Line 18: | ||
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. | 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) to design different aspects of a system based on distributed components with RTSJ constraints | + | 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 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 define the kinds of component with their input ports (exposing some previously defined interfaces) and the output ports. | ||
Revision as of 11:15, 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
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.