Omg issue Number

Disposition: Deferred

OMG Issue No: 11840

Title: Support for flows in activities

Source:

Thales (Sébastien Demathieu, [e-mail])

Summary:

Subject: Support for flows in activities. Details: The current specification provides a limited support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction stereotype. However, there is no way to indicate the pins used to define the data to send. At the same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It seems that activity parameters are an interesing alternative to specify incoming and outgoing flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through activity parameters (maybe a stereotype would need to be defined here).

Discussion:

Defining a complete support for flow in activities can be done with two different approaches.

The first approach is to define actions for sending and receiving flows. GCM currently follows this approach but provides an incomplete support because it defines only a SendFlowAction action and not its accept/receive counterpart.

The second approach is to follow SysML and to extend activity parameters and pins by a specific stereotype. This approach has advantages as it leverages more the capabilities offered by plain UML, for which execution semantics have been already precisely defined.

The FTF as a whole did not have the opportunity to discuss the pros and cons of the two approaches. Therefore, it is better to defer this issue to collect everyone’s input on this issue.

Related issue: 11662

Disposition: Deferred

Disposition: Deferred

OMG Issue No. 11845

Title: Runtimes may have multiple stacks

Source:

THALES (Mr. Sebastien Demathieu, [e-mail])

Summary:

Runtimes may have multiple stacks. How to reference a specific stack size (e.g., primary or secondary) in SRM? It seems to miss a concept.

Discussion:

This is already possible to describe multiple stacke because the multiplicty of the  staskSizeElement attribute is unlimited (concurrentResource stereotype).

It seems that there is a need to describe more precisely several stacks : primiary stack, secondary stack ...

One solution leads to describe an explicit "Stack" stereotype.

Such solution deeply modifies the SRM chapter.
Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11849

Title: Mode and End to End flow representation representation

Source:

THALES (M. Faugère, [e-mail])

Summary:

The use of UML native concepts for some of the AADL constructs should be revised from a pragmatic viewpoint. For instance:

1. 
   The use of pure state machines to model AADL operational modes is sometimes insufficient. In the examples provided in MARTE (p.376; ptc/07-08-04), the relationship between a system configuration (modelled by a Collaboration) and a State specifying a Mode, is reflected by the “Name”. I.e., there is no an explicit association between both. It seems that providing a “Mode” stereotype in MARTE, with an appropriate relationship with other modelling elements could be very useful. This would facilitate model extraction/transformation when different kinds of state machines exist in a UML model. The relation between The AADL concepts of “mode transition” and “mode transition trigger” and UML state machines elements should be clarified.
   
2. 
   AADL Flows and EndToEndFlows are modelled by UML Activity diagrams. However, there is already the EndToEndFlow concept in MARTE (SAM chapter), which encloses the same semantics, and furthermore, provides a set of attributes (stereotype properties) that match with the AADL ones (e.g., end-to-end deadline, end to end time). The use of MARTE EndToEndFlows should be evaluated
   

Discussion:

AADL mode and mode dependent property values representation in UML/MARTE should be analysed regarding QoS and SysML profile.

End to end Flow representation will be presented in issue 11854.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11850

Title: Annex A: guidance nature of the Annex

Source:

Thales (M. Faugère, [e-mail])

Summary:

The set of new stereotypes provided in the AADL annex of MARTE (e.g., port group, subprogram, data type) seems to show that MARTE (and UML) does not support some AADL concepts. However:

1. 
   AADL Subprogram clearly maps to an UML Operation. More refined Operations can be modelled by “Requested Service” (GQAM chapter, p.263).
   
2. 
   b) AADL Data concept clearly maps to MARTE MutualExclusionResource (GRM chapter) or SharedResource (SAM chapter). The latter includes additional stereotype attributes useful for schedulability analysis. It may be a combination of both. This brings up the question of what the overlap and difference is between MutualExclusionResource and SharedResource. One represents the mechanism to achieve mutual exclusion, while the second is the entity that may require mutual exclusion in the context of concurrent access.
   

Discussion:

In order to keep the guidance role of the annex A, and the in there defined stereotypes shall be removed. UML/MARTE construct have been proposed in issue #11848 to express AADL data, AADL System, AADL end-to-end flows, inverse concept, AADL Port Group, Server subprogram, AADL subprogram, Thread group.

Delayed (sampled, immediate) communication types are missing in MARTE.
Disposition: Deferred