Revision as of 04:12, 1 August 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 (Interfaces and Provided Services definition).
• 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

Interfaces and Provided Services definition

On each UML Package, give the ability to create a new Diagram if the UML Package contains a UML Interface at least.

In this Diagram:

• Display each UML Interface, in the UML Package, as a box (interface) with a different aspect according to the RTSJ stereotype applied on it:
  • style 1 when no stereotype applied (synchronous case)
  • style 2 when RTSJ::Asynchronous stereotype applied
  • style 3 when RTSJ::EventData stereotype applied
    • In this box (interface), display each UML Behavioral Feature, in the UML Interface, as a list element (service)
• Make available a tool to create a new UML Interface (synchronous)
• Make available a tool to create a new UML Interface with RTSJ::Asynchronous stereotype applied (asynchronous)
• Make available a tool to create a new UML Interface with RTSJ::EventData stereotype applied (event data)
• Make available a tool to create a new list element (service) in a box (interface):
  • If the interface is synchronous then create a UML Operation in the UML Interface.
  • Else, create a UML Signal in the current UML Package, and create a UML Reception in the UML Interface with the same name of the UML Signal. At last, set the UML signal feature of the UML Reception with the created UML Signal.
• Give the facility to automatically propagate any UML Reception name changes onto the related UML Signal name to keep consistency.

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 handle of the Diagram Editors.

Documentation Changes

A new user manual should be made.

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.