Omg issue Number

Disposition: Deferred

OMG Issue No: 11544

Title: Annex D

Source:

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

Summary:

Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart

Resolution:

One aspect that rises here is that the operations for NFP types like NFP_Real, NFP_String, etc, should be the same as the primitive type counterparts. So, it seems natural to reuse those operation definitions. One mechanism to reuse the operations (e.g., +, -, *, /, =, <, >) is to inherit NFP types from the primitive types. The problem is that as both are different metaclasses (UML primitives and UML data types), the inheritance is not compatible.

Hence, this resolution proposes to defer this issue for a more careful evaluation of a reusable, extensible and straightforward approach to define operations in NFP data types.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11549

Title: Annex B VSL BNF

Source:

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

Summary:

The VSL grammar does not define the "( )" symbol that allows one to indicate priorities in the syntax of arithmetical expressions. In the expression, "((1+2) * 3)" for instance.

Resolution:

Precedence rules to evaluate expressions are missing in VSL. This should be added at the same level where semantic of operations is defined. In this case, operations are defined in the Library annex. However, it’s not clear how the grammar should be updated to support these precedence rules.

The resolution proposes to defer this issue to evaluate the VSL grammar more carefully.

Disposition: Deferred

Disposition: Resolved

OMG Issue No: 11633

Title: Annex B VSL BNF

Source:

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

Summary:

Invalid reference in caption of Figure B.1. The caption of Figure B.1 is currently "Figure B.1 - Structure of the NFP framework" when it should be "Figure B.1 - Structure of the VSL framework".

Resolution:

Revise caption of Figure B.1

Revised Text:
Change caption of Figure B.1 to:
Figure B.1 – Structure of the VSL framework
Disposition: Resolved

Disposition: Deferred

OMG Issue No: 11767

Title: Time: Examples

Source:

Commissariat à l’Energie Atomique-CEA/LIST (Mr. Huascar Espinoza, [e-mail])}

Summary:

One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams

Discussion:

There are ongoing discussions about the introduction of Timing Diagrams in SysML. MARTE is equipped to annotate UML Timing Diagrams. Giving a precise example in the MARTE specification might anticipate the SysML decision. So I suggest to postpone this issue for the FTF and wait for the evolution of SysML.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11768

Title: GRM: Domain Model

Source:

Commissariat a l Energie Atomique-CEA/LIST (Mr. Huascar Espinoza, [e-mail])

Summary:

[GRM: Domain Model] A number of GRM domain concepts make it hard to understand and use. These mainly relate to its mapping with the UML profile and its refinement in the HRM, SRM and analysis profiles:

a) Figures 10.3 and 10.4 illustrate the ‘resource’ concept as two kinds of entities: an instance (ResourceInstance) and a classifier (Resource). This separation is not explained and is not used along the remaining parts of the spec. I.e., all the associated or specialized concepts are related to ‘Resource’. Also, the profile only defines a ‘Resource’ stereotype. Furthermore, NFPs are only associated with ‘Resource’. What about NFPs related to ResourceInstances? ? I’d suggest to remove the ResourceInstance concept, as conceptually, has not any relevance, and create confussion.

b) Fig. 10-13 introduces the concepts of ‘ResourceUsage’, ‘UsageTypedAmount’, which inherits from ‘ResourceAmount’. However, at UML profile definition level, only <> is provided, by using the attributes of UsageTypedAmount (from the domain model). I’d suggest to harmonize both, domain model and profile.

c) A double inheritance of ‘ComputingResource’ from ‘Resource’ has been defined (Fig. 10.6 and, Fig. 10.11 through ‘ProcessingResource’). I’d suggest to remove one of them.

d) GRM attempts to be a generic framework for modelling resources. However, some of the attributes seems too specific and not useful when specializing this package (e.g., HRM & SRM). For instance, ‘packetSize’ in ‘CommunicationEndPoint’ (Fig. 10-8) is related to specific kinds of protocols. ‘speedFactor’ in ‘ProcessingResource’ is an analysis-specific parameters.

Discussion:

1. 
   Instances and Classifiers are consubstantial to UML and their role in MARTE are explained in the CoreElements Chapter. The instances are there to illustrate the finite nature of resources. No change.
   
2. 
   UML View is a utilitarian mapping of the domain model, and in this case the harmonization is already included in the constraints that describe the rules for the utilization of resourceUsage. No change.
   
3. 
   Double inheritance is neither conceptually nor practically a problem. No change.
   
4. 
   Very few attributes have been defined, but all of them are optional and do not jeopardize the conceptual and architectural role of the stereotypes in GRM. No change
   

Considering the interest of the source of the issue in searching for possible enhancements on these topics, it is deferred.

Disposition: Deferred