|Issue #||Status||Forum Page||Resolution doc link||Notes|
|Issue 14893||Deferred||Waiting for some stable QUVD model: alignment with Ontology and Time Modelling at OMG are under way||14893_deferred.doc||Align the NFP profile and domain model with the QUVD meta-model|
|Issue 14427||CLOSED NO CHANGE||Already done in MARTE v1.0||14427_closednochange_ballot2.doc||NFP_Constraint metaclass syncho with its underlying stereotype|
|Issue 14428||CLOSED NO CHANGE||singular names should be the rule||14428_closednochange_ballot2.doc||NfpConstraint stereotype: rename property mode to modes|
|Issue 15032||RESOLVED||Fix XMI file||15032_resolved_ballot2.doc||Figure 8.5 UML profile diagram for NFPs modeling|
|Issue 14910||under discussion||Under discussion||14910_resolved_ballot2.doc||NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -)|
Issue 14427 NFP_Constraint metaclass syncho with its underlying stereotype
The stereotype NFPConstraint owns a property to denotes in which modes the constaint is attached. The metaclass NFP_Constraint defined in the domain model of MARTE should be updated to reflect that property.
Proposal: ClosedNoChange: The domain model already shows the Nfp_Constraint relationship to a Mode (Fig. 8.3)
Issue 14428 NfpConstraint stereotype: rename property mode to modes
The property mode of the stereotype NfpCinstaint has a multiplicity [0 ..*]. To reflect that I propose to rename this latter mode to modes.
Proposal: ClosedNoChange: Although, there are no rules for naming of associations, it seems that UML uses singular names for all associations (independently of the role multiplicity). So, we should try to keep the same naming convention in MARTE.
Issue 14910 NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -)
NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such “(end - start) < (value=10.0, unit=ms)” (where start and stop are TimeObservation
Proposal: UnderDiscussion: VSL uses an object-oriented operational style for primitive operations (e.g., in binary arithmetic operations, one of the arguments acts as the “target” of the operation invocation). All operations in VSL, including basic arithmetic and logical operations such as for example multiplicative and additive operations, are declared as UML::Operation of DataTypes.
The issue itself may be solved by adding the required operations (e.g., =, >, <, *, +, -) in the required data types (e.g., NFP_Duration). However, this issue raises some more general issues: - Extensibility of the data type functions (e.g., new operations for existing DataTypes that might be needed for further math/logical functions)
> Issue : With the current approach, we must modify the DataType library every time a new operation/function is required.
- Operator priority (i.e., type evaluation order)
>Issue : With the current approach, priorities are defined in the Data type libraries. This means that a parser is dependent on the library to dynamically evaluate types.
To solve both the issue limitations and the more general issues, the following changes shall be done in VSL:
1. Integrate the basic operators that need determine priority evaluation order in the VSL grammar (and metamodel) itself. This includes multiplicative and additive operators.
2. Change the style to define data type operations from an object-oriented style to a procedural style. This implies to define some predefined libraries of Behaviors that must be provided by any parser & type checking tool. Additional behavior libraries may also provide additional operation/functions.
While clause 1.) is easy to solve (but may need a lot of modifications in the VSL spec.), clause 2.) needs special care:
- For reuse concerns, it would be useful to allow creating polymorphic behaviors (e.g., Addition is applied to several data types).
- VSL expression would need long (qualified) names to specify operations. E.g., VSL.PrimitiveBehaviors.Add(a,b). This creates a usability issue that VSL users would prefer to avoid.
- Addition of new Behavior libraries must be taken into account in the parser and type checkers. This needs a more careful study of implementation aspects.
> The last three points must be assessed in detail to provide a definitive Resolution.
Issue 15032 Figure 8.5 UML profile diagram for NFPs modeling
StereoType “Unit” has a Tag of convOffset but the xmi import has named it offsetFactor.
Proposal: Resolved: The right name is convOffset. The xmi must be fixed.