MARTE — What are semantics of real-time features on provided/required interfaces?

This resolution proposes general clarifications on the usage of the stereotype
«RtFeature» (including its usage and underlying semantics in the context of
provided/required interfaces).
The stereotype «RtFeature» can be applied to multiple elements Additionnaly, issue 12954 also requires some clarifications. These clarifications
require modifications to figures that are modified in this resolution. We therefore
propose to resolve problems identified in issue 12954 in this document, and we
state resolution to issue 12954 as duplicate/merge with this resolution 11838.
More specifically, issue 12954 has identified the following problems: 1- In figure
3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. : In the proposed
modification of figure 3.10, this inconsistency is removed. 2- In section 13.3.2.8
the stereotype «RtFeature» is said to extend the UML Behavior element;
however in section 3.10 this extension is not shown. : In the proposed resolution,
«RtFeature» does not apply anymore to behavior. 3- Figure 3.11 does not show
all the attributes of the «RtAction» stereotype. The new version of figure 3.11
proposed in this resolution includes all the attributes. 4- The use of the
stereotype «RtBehavior» is not clear. An example in 13.4 would be of great help.
This stereotype has been deleted. Its attributes are indeed only characterizations
of the event pool of an active object. Its attributes have been added to
«RtFeature», and prefixed with ‘sr’ (for Schedulable Resource).
(InvocationAction, BehavioralFeature, Message, Signal). In order to clarify to
meaning of these multiple extensions, some text is added in the section
describing the stereotype «RtFeature» to explain that: the most basic element on
which «RtFeature» can be applied is InvocationAction, and that any other places
where this stereotype is applied enables to specify a kind of default value in the
case where the stereotype «RtFeature» has not been applied on a particular
InvocationAction.
Additionnaly, the title of this issue suggests that real-time features could be
contextual to the usage of interfaces (for example, one may want to specify that a
real-time feature concerns an operation of an interface that is provided on a
given port). Therefore, we propose the following modifications:
The stereotype «RtFeature» is modified so that it now also extends the Port
metaclass. The stereotype «RtSpecification» is introduced, and it extends the
Comment metaclass.
All the attributes of «RtFeature» are removed from «RtFeature», and they are
added to «RtSpecification».
An «RtFeature» can now own multiple «RtSpecification», and it is possible to
specify the behavioral feature that is concerned by this «RtSpecification». For
example, a port can be stereotyped with «RtFeature». It can then own multiple
«RtSpecification», where each of these «RtSpecification» may concern a
behavioral feature of a provided or required interface of this port.