Omg issue Number

Disposition: Resolved

OMG Issue No: 11555

Title: attribute “Class descriptions are missing in the MARTE model library for GRM (Annex D4)”

Source:

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

Summary:

Class descriptions are missing in the MARTE model library for GRM (Annex D4)

Resolution:
These Class descriptions are in section 10.3.3. They can be referenced from the annex or move to the annex and referenced in section 10.3.3

Revised Text:

Move all class descriptions in section 10.3.3 to the D4 annex and insert a paragraph in section 10.3.3 making a reference such as:

The description of all the elements in the model library for GRM are in annex D4
Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11620

Title: EventTrace attributes

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

Summary:

The stereotype <> defines stereotype attributes: content, format, location that are not defined in the domain model (p. 263). I would suggest adding a definition of these attributes in the EventTrace domain class.

Resolution:

Add definitions to the text of the domain model

Revised Text:

para 3 p 263, before:

One of these options is used and the others are undefined. The arrivalPattern alternatives are described elsewhere, but they include PeriodicPattern, often used for schedulability, and Open and Closed patterns often used for performance analysis, and a variety of less regular patterns.

after:

In practice, one of these options is used and the others are left undefined. The arrivalPattern alternatives are described in Appendix D, but they include the PeriodicPattern, often used for schedulability, the Open and Closed patterns often used for performance analysis, and some less regular patterns. EventTrace has attributes for location (the file location or URL), format (a description of the trace record format) and content (for the trace data itself).

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11631

Title: {title of the issue}

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

Summary:

Inconsistency between GCAM profile definition and SAM example In Figure 16.14, the stereotype <> is applied on a part (i.e. a UML property) of the TeleoperatedRobotSAM composite class. Meanwhile, in Figure 15.6, it seems that this stereotype extends only UML::Classifier. Proposed resolution: either we remove the stereotype from the SAM example or we allow the stereotype <> to extend UML::Classifier and UML::Property. The second option would make sense to me.

Resolution:

The stereotypes are to be removed from the example.

Revised Text:

(1) First sentence of Section 16.3.3.3, change Figure number.

Old text:

In order to define the analysis context for a given pair of workload behaviour and resources platform models, we illustrate how to use structured classifiers (see Figure 16.13).

New text:

In order to define the analysis context for a given pair of workload behaviour and resources platform models, we illustrate how to use structured classifiers (see Figure 16.14).

(2) In Figure 16.14, remove the stereotypes « gaWorkloadBehavior » and «GaResourcesPlatform»

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11632

Title: Section: 14.2.3

Source:

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

Summary:

<< tupleType >> stereotypes would need to be added on HRM datatypes, to enable the use of VSL expressions. The UML representation section of HRM defines several datatypes (Timing, CacheStructure, PLD_Organisation, MemoryOrganisation, Env_Condition) that are not stereotyped as << tupleType >>. As a consequence, it is not possible to edit properties typed by these datatypes as VSL expressions. Proposed resolution: to apply the << tupleType >> stereotype on every datatype defined in HRM.

Resolution:

Proceed with the modification of all the datatypes with tupletype in the HRM chapter.

Revised Text:

-Figures in Issue 11521 already have the required modifications for datatype into tupletype

-Modify all the Classes and Stereotype descriptions in Sections 14.2.3.2 Stereotype descriptions, and F.9 DRM::HRM, by replacing the word “datatype” by “tupletype”

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11644

Title: Section: Annex B.2.4 (direction property is not consistent between MM and grammar)

Source:

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

Summary:

Inconsistency between the VSL BNF and metamodel (Variable declaration) In the VSL annex, Figure B.4 (VSL::Expressions package) indicates that a Variable has "direction" property: VariableDirectionKind [0..1]. On the other hand, in the BNF, the term is not between brackets, which means that it is a mandatory term. Proposed resolution: either we update the BNF or we change the multiplicity of the direction property in the metamodel.

Resolution:

As far as the variable direction is optional, as described in the metamodel, the grammar should be revised and modified with the brackets for the term.

Revised Text:

Page 402 old text:

::= '$' [] ['=' ]

Page 402 new text:

::= [] '$' [] ['=' ]

Disposition: Resolved