Omg issue Number

Disposition: Deferred

OMG Issue No: 11871

Title: NFP does not introduce the concept of dimension

Source:

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

Summary:

Subject: NFP does not introduce the concept of dimension. Details: NFP defines the notion of unit attached to a type but it does explicitly express the dimension related to this unit. This should be fixed to provide a comprehensive support for modeling quantities in RTES.

Resolution:

The Dimension concept, and its possible attributes such as the base dimensions, is required to do dimensional analysis and verify consistency of expressions with quantitative NFPs.

SysML also includes this concept, but a revision is being considered, not only to refine the Dimension concept with the required attributes, but to align the modeling approach for quantities, units and dimensions with the MARTE approach.

In this alignment work, some contributors of MARTE are also participating. So, we propose to wait for some concrete results in SysML (extended metaclass for Dimension and its attributes), in order to adopt a consistent modeling approach.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11872

Title: VSL

Source:

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

Summary:

Subject: VSL should support definition and application of functions, derivatives, sequences and series. Details: In the early stage of a development process, it may be useful to model control laws of a RTES. VSL seems to be a very good fit for that purpose. However, it misses several mathematical concepts to provide a comprehensive support. VSL should support definitions of functions, derivatives, sequences and series.

Resolution:

The number of functions that could be added to VSL, and useful in the real-time and embedded system domain, is very large. In MARTE, we do not attempt to define all these functions. Instead, we propose only a basic subset useful for general expressions. Further libraries could extend VSL to support this function.

A further work could be done to define a mathematical library, but this is outside of the MARTE FTF. We propose to defer this issue to evaluate if such mathematical functions would be easily integrated in new libraries.
Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11876

Title: MARTE primitive types

Source:

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

Summary:

MARTE primitive types: Integer, String, UnlimitedNatural and Boolean are redefined in the MARTELib. To facilitate integration, I would suggest making them subclasses of their UML counterpart.

Resolution:

This issue should be solved together with Issue 11544. Also, some aspect should be evaluated before deciding if an inheritance between primitive types is a good/valid practice, and if this modification adds consistency between UML and VSL.

Hence, we propose to defer this issue.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11878

Title: Annex B: how VSL constructs shall be typed and evaluated

Source:

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

Summary:

Subject: Annex B doesn't clearly define how VSL constructs shall be typed and evaluated

Details: Our problem: it seems to be missing some information in the current VSL specification that explains how language constructs shall be typed and evaluated. We had a look at other standard programming languages (ANSI C, Java) to see how such information is defined. In the ANSI C language reference, *every* section introducing a language element is organised with the same structure: a subsection that introduces the syntax, a subsection defining the constraints (including type constraints) and finally a subsection regarding the semantics (other type constraints plus explanations regarding the evaluation).
For instance, we can have a look at an extract that introduces the function calls: > 6.5.2.2 Function calls > > *Syntax* > > primary-expression: > identifier > constant > string-literal > ( expression ) > > > *Constraints* > 1
The expression that denotes the called function shall have type pointer to function > returning void or returning an object type other than an array type. > > 2 If the expression that denotes the called function has a type that includes a prototype, the > number of arguments shall agree with the number of parameters. Each argument shall > have a type such that its value may be assigned to an object with the unqualified version > of the type of its corresponding parameter. > > *Semantics* > 3
A postfix expression followed by parentheses () containing a possibly empty, commaseparated > list of expressions is a function call. The postfix expression denotes the called > function. The list of expressions specifies the arguments to the function. > > 5 If the expression that denotes the called function has type pointer to function returning an > object type, the function call expression has the same type as that object type, and has the > value determined as specified in 6.8.6.4. Otherwise, the function call has type void. If > an attempt is made to modify the result of a function call or to access it after the next > sequence point, the behavior is undefined.
In VSL, we have a definition of the abstract syntax (the meta-model) and the concrete syntax (the BNF) in the Annex B and we have a detailed description of the domain classes (abstract syntax elements) in the Annex F. It seems that the current "constraint" and "semantics" sections of the metaclass descriptions miss some detailed information on the way constructs shall be typed and evaluated.
The information does not seem to be systematic and homogeneous. Examples: > F.13.6 ConditionalExpression (from Expressions) > Generalizations >
• Expression (from Expressions) on page 560 > Associations >

• conditionExpr: VSL::ValueSpecification [1] Boolean expression to be evaluated. >

• ifTrueExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to True. >

• ifFalseExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to false. > Semantics > Conditional Expressions define "if-then-else" statements, which can be used inside an expression. The result of evaluating > this expression will be the result of => Here it is not stated that the consequence (ifTrueExpr) and the alternative (ifFalseExpr) shall have the same type or that the type of such an expression if a boolean. OR > F.13.8 DurationExpression (from TimeExpressions) > Generalizations >

• TimeExpression (from TimeExpressions) on page 567 > Semantics > DurationExpression is a time expression that denotes a duration value. => Again, here it may miss more detailed information on the type of the expression. This is the kind of information we missed when implementing the VSL editor and which we need to figure out by ourselves. Sometimes it's obvious but it happens to be definitely tricky. That's why we think that it would be beneficial for MARTE and VSL to complete the Annex F to add this information. In that context, we propose that: 1) every VSL domain class in Annex F shall provide information about its type. 2) if the type cannot be directly known, there shall be an explanation on how it can be computed (this is the case of all the subclasses of Expression and TimeExpression). 3) if information about the evaluation / execution semantics is provided then it shall be distinguished from the type information (because this is something really different). All this information would complete either the "constraint" and/or "semantics" section of Annex F..

Resolution:

This requires a lot of work. We agree that this is a real issue. This relates a fundamental problem of VSL which is to define what is part of the language and is defined in libraries. This requires to define a mechanism to formalize datatype operation semantics at library level. This also requires to revise if we need a primitive type for Time-related values. We should also try to align to OCL, which already define a chapter for the semantics and expression evaluation.

This should be defined with a careful work. So we propose to defer this issue.

Disposition: Deferred