Revision as of 06:08, 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 (Kind of components definition).
• a view to create the applicative system, instantiating components from the defined kinds and creating the links between the components' ports (RTSJ Component Applicative Design).

Detailed Specification

Views

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.

Kind of components definition

On each UML Package, give the ability to create a new Diagram if the UML Package contains a kind of component at least (a UML Class owning one UML Port at least).

In this Diagram:

• Display each kind of component, in the UML Package, as a box (kind of component).
  • In this box (kind of component), display each UML Port, in the UML Class, as a list element (port), differentiating the input and output ports:
    • An input port is a UML Port where its type is set. These ports will be located on the top of the list elements.
    • An output port is a UML Port where its type is not set.
• Make available a tool to create a new kind of component (UML Class) with an output port at least (in order to be directly known as a kind of component).
• Make available a tool to create a new output port (UML Port).
• Make available a tool to create a new input port (UML Port) with a wizard to set its type, selecting a previously defined UML Interface.
• Give the facility to navigate from a kind of component to the used interfaces via its ports. A wizard will give the list of the concerned diagrams displaying these interfaces to navigate to. The related interfaces will be selected after opening the chosen diagram.
• Give the facility to see the provided services from an input port definition (via tool tip e.g.).

RTSJ Component Applicative Design

On each UML Package, give the ability to create a new Diagram if the UML Package contains an entry point of the system to design (UML Class stereotyped RTSJ::Root) at least.

In this Diagram:

• Display each UML Property of the entry points as a box (component) (instance of a kind of component).
  • In this box (component), display each UML Port from the related kind of component, through the type of the UML Property, as box in border (port), differentiating the input and output ports:
    • Input ports will be in green color.
    • Output ports will be in red color.
  • In this box (component), display each UML Behavioral Feature from the interfaces used by the ports of the related kind of component, as a list element (service).
• Display each UML Connector as an edge between the input and ports.
• Make available a tool to create a new component (UML Property in the first found entry point and a type set to the selected kind of component), with a wizard to select the kind of component to instantiate.
• Make available a tool to create a new edge (UML Connector) between an output port and an input port.
• Give the facility to navigate from a component to the related kind of component in a concerned diagram and selected by a wizard.
• Give the facility to see the link between the exposed services and the input ports (indicating the name of each port and referencing these names from each service in the list elements e.g.).

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.