Omg issue Number

Disposition: Closed, no change

OMG Issue No: 11776

Title: Move Observer package to Part I or II

Source:

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

Summary:

GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I’d suggest to move this concepts to a more general package

Discussion:

This is identical to issue 11775, it was submitted or entered twice

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11822

Title: Giving an attribute a variable name and an expression value

Source:

Carleton University (Dr. Murray Woodside, [e-mail])

Summary:

I am not clear of the status of this, but it seems that to use the profile flexibly one needs to be able to assign a variable name to an NFP, and also a value. Then the variable name can be used to change the value in studies, in a traceable way. The value can be an expression too.

A possible resolution would be to allow expressions to read as variable = expression.

Resolution:
This is already supported by VSL: A 'variable declaration' expression can have assigned an "initialExpression". Concretely, the following syntax has been adopted in VSL (page 402):
::= '$' [] ['=' ]
This means that you can have NFP values such as (extended notation):
myLatency = (value= 5.0, expr= $var1=var2+var3/3, unit=ms) or the short notation:

myLatency = (5.0, $var1=var2+var3/3, ms)

Hence, this issue is close with no change.
Revised Text:

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11841

Title: How to model the amount of memory occupied by an OS resource

Source:

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

Summary:

Subject: How to model the amount of memory occupied by an OS resource (eg. File, buffer, blackboard, ARINC ports). Details: We would need to know the memory used by OS objects (buffer, sem, blackboard…). This maybe needs further discussion but why not introducing a memorySizeElements attribute on SwResource? It might be also applicable on a GRM::Resource ?

Discussion:

The SwResource stereotype owns a memorySizeFootprint attribute which allows referencing the amount of memory occupied by an OS resource

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11844

Title: How to model the size of code occupied in ROM?

Source:

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

Summary:

How to model the size of code occupied in ROM? There seems to be a missing concept here.

Discussion:

The GRM:usageResourceType seems adequate

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11864

Title: Names should be identical

Source:

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

Summary:

The Refinement metaclass relates to the ClockRefinement stereotype. Names should be identical.

Discussion:

The domain model is supposed to be a description of the concepts required, whereas the UML representation takes into account the existing UML elements.

For the explanation in the domain model part, it would be odd (or even incorrect) to mention ‘’NfpRefinement’’ or ‘’ClockRefinement’’ and even more strange to refer to ‘’NfpRefine’’ because we really speak about the refinement mechanism as being the inverse operation of the abstraction mechanism.

Unfortunately, in the UML representation we can have name conflicts with existing UML model elements. The name ‘’ClockRefine’’ (and not ‘’ClockRefinement’’) has been chosen to recall the stereotype ‘’Refine’’ of the UML standard profile. It is not possible to call it ‘’refine’’ since this is already a keyword of UML. Calling it “refinement”, which would be the right naming, may lead to many confusions with “refine”. In that particular case, it is really a matter of adding a new constraint to the existing UML stereotype (only one source, multiple targets) and offering a provision for associations with NFP constraints.

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11866

Title: Improve the usability of the RtBehavior stereotype

Source:

THALES Sebastien Demathieu ( sebastien DOT demathieu AT thalesgroup DOT com )

Summary:

To improve the usability of the RtBehavior stereotype, it should also extend the UML::Operation metaclass.

Discussion:

A UML Operation is a BehavioralFeature, not a Behavior, and MARTE’s RtService is the intended stereotype for BehavioralFeatures such as Operation.

A vote of Yes on this issue will leave RtBehavior unable to extend UML::Operation. A vote of No on this issue will only leave the issue Open.

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11873

Title: allocatedTo and allocatedFrom properties should not be derived

Source:

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

Summary:

The concept of allocation in MARTE is quite generic. Any UML::NamedElement can be used as allocation end. That enables the use of allocations in various kinds of diagrams, for multiple purposes (e.g., structural, behavioral allocation.) In the current specification, allocations are supported by three stereotypes: Allocate, ApplicationAllocationEnd and ExecutionPlaformAllocationEnd. The allocatedTo and allocatedFrom properties of ApplicationAllocationEnd and ExecutionPlaformAllocationEnd are derived from the UML::Abstraction that is stereotyped as Allocate. However, creating an abstraction (i.e., a dependency) between two elements implies that these elements belong to the same diagram, which is not always the case. Moreover, it limits the use of allocation to specific diagram types (e.g., not all the UML modeling tools allow the use of dependency on composite structures). Proposed corrections:

1) Do not consider allocatedTo and allocatedFrom as derived properties and allow end users to directly make use of the ApplicationAllocationEnd and ExecutionPlaformAllocationEnd stereotypes to express allocations.

2) Identify mechanisms to allow a characterisation of this allocation (allocation kind, allocation nature) the way it’s done in the Allocate stereotype.

Discussion:

It has been agreed that this is more a tool vendor issue regarding derived properties since nothing should prevent the user to define the allocate dependency directly on the model elements when this cannot be done on the diagrams themselves (because they do not appear in the same frame).

Tool vendors (Artisan and No Magic) have pronounced themselves in favor of keeping the properties as derived properties and have mechanisms to automatically derive the value of these properties from the model repository.

Additionally, making them not derived has the great disadvantage that there is no guarantee when defining a property "allocatedTo" (for instance) that the allocation has been defined, that a corresponding property "allocatedFrom" has also been defined. This is making an even harder tooling issue.

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11874

Title: attribute “GRM::SchedulableResource should have a period property”

Source:

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

Summary:

After some discussion with F. Thomas, it seems that the GRM::SchedulableResource misses a period property.

Resolution:

SchedulableResource in GRM represents the capabilities for obtaining processing capacity from a processing resource. The period is not a fundamental quality of the concurrent units represented. The fact that it may be periodically activated or not is a design choice. To annotate this behavior among other alternatives, a workloadEvent with the periodic arrival pattern may be used.

Revised Text:

Disposition: Close, no change

Disposition: Closed, no change

OMG Issue No: 12185

Title: RTF stereotype

Source:

CEA/LIST Sebastien Gerard ( sebastien DOT gerard AT cea DOT fr )

Summary:

The RTF stereotype should also extend the Behavior Meta-class.

Discussion:

See Issue 11867 for the change in name from “rtf” to “rtFeature”…

We risk confusion by allowing wide applicability (extensability) of the various rt* stereotypes and, even without this change, rtFeature already seems to be a collection of too-loosely-related properties. Furthermore, by naming convention, whether appropriate or not, MARTE’s RtBehavior is the implied, intended stereotype for Behavior.

A vote of Yes on this issue will leave RtFeature unable to extend UML::Behavior. A vote of No on this issue will only leave the issue Open.

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 12209

Title: using $ in naming variables (and variable calls)

Source:

Carleton University (Dr. Murray Woodside, [e-mail])

Summary:

In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name.

Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning.

Examples are found in NFP (Fig 8.9) and many other chapters.

These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement.
In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples.

Resolution:

There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call' expression, we use only the name. We really need to make difference between both because VSL parsers need to distinguish them.

a) Arguments to use ‘let‘ as keyword in variable declarations:
The use of ‘$’ is not ‘conventional’ to declare variables. Other keywords like ‘let [variable-name]’ would be more appropriate. It is recommended to use 'let ' for variable declaration because having a keyword for declaration is the more natural choice in most of languages.
b) Arguments to use ‘$‘ as part of the variable name in variable call expressions:
The absence of the symbol ‘$’ in variable call expressions (“variable use”) would make hard to make the distinction with other ‘names’ in VSL expressions, such as enumeration literals or PropertyCallExpression. The goal of this symbol in the former SPT profile was to identify easily a variable within an expression. With the current notation, the latter is not possible.

.

c) Arguments against a modification of variable notation

Some reasons would suggest avoiding such a modification:
- VSL has an essential difference with other conventional languages: VSL is intended to be used in 'properties values', where compact annotations should be privileged. Also, its use in Constraints tries to mark a difference with OCL, and it's that annotations should be shorter and easier to understand. Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language.
- The UML Time Observation notation works exactly like VSL variables. A symbol (‘@’ for time observation and ‘&’ for duration observation) is used for declarations, and only the name (without the symbol) for expressions. Time observations could be considered as a sort of variables, but with a more specific semantics. So, having the notation of both VSL variables and Time Expression aligned is important for comprehensibility of Profile users.
-In MARTE, most of VSL variable expressions are used at “declaration” level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot (“value”). This means that the variables will be easily identified in a model, because they will include the ‘$’ symbol.
- VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of “parameters” either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions.
d) Conclusions
The argument for using 'let' is more to follow conventional languages, and not pragmatic concerns. Also, the argument that the current mechanism confuses comprehensibility between variable declaration and variable call expression is not sustainable. VSL variable notation works exactly as UML TimeObservation works, and there were not reported any issue related to confusing language users.
For these reasons, we suggest to close this issue with no change.
Disposition: Closed, no change

Disposition: Duplicate/merged

OMG Issue No: 11662

Title: Section: 11.2.1 (data reception)

Source:

CEA-List (Arnaud Cuccuru, [e-mail])

Summary:

The FlowSendAction concept is introduced to enable sending of data via a FlowPort. It seems that there is no equivalent concept (action) for data reception. If a given behavior has to be expressed according to data arriving from an input port, how is the behavior “notified” that a data is available on this port (I mean: is there something equivalent to AcceptCallAction used for service oriented communication schemes)? Once that the notification has occurred in one way or another, do we access to this data with something like a ReadStructuralFeatureAction (because ports are structural features)?

Disposition: See issue 11840 for disposition

Disposition: Duplicate/merged

OMG Issue No: 11663

Title: Section 11.3.2

Source:

CEA-List (Arnaud Cuccuru, [e-mail])

Summary:

FlowPort and MessagePort stereotypes have two common tagged values: isAtomic and isConjugated. These two properties could be inherited from a common ancestor stereotype (for example, an abstract InteractionPort stereotype).

Disposition: See issue 11658 for disposition

Disposition: Duplicate/merged

OMG Issue No: 11666

Title: Section 11.4.1 (marte-ftf)

Source:

CEA-List (Dr. Arnaud Cuccuru, [e-mail])

Summary:

It would probably be clearer if the BFeatureKind enumeration only proposes REQUIRED and PROVIDED enumeration literals (that is to say “qualifiers” that are already used and widely accepted in the UML to denote “direction” of signals and operations in message-oriented communications). IN, OUT, INOUT should be reserved to FlowPorts and FlowProperties (that is to say for data-flow communication schemes).

Disposition: See issue 11661 for disposition

Disposition: Duplicate/merged

OMG Issue No: 11667

Title: Section 11.4.1 (marte-ftf)

Source:

CEA-List (Dr. Arnaud Cuccuru, [e-mail])

Summary:

The Automative Example uses stereotypes that are not defined in the specification (namely SignalSpecification and ServiceSpecification

Disposition: See issue 11551 for disposition

Disposition: Duplicate

OMG Issue No: 11775

Title: Move Observer package to Part I or II

Source:

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

Summary:

GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I’d suggest to move this concepts to a more general package

Discussion:

This is identical to issue 11776. Also, as discussed in issue resolution 11846, these concepts are analysis-specific concepts. There is no need to put them in a more general package.

Disposition: Duplicate

Disposition: Duplicated

OMG Issue No: 11842

Title: attribute “HwMedia.bandwidth attribute may need to be generalized in GRM ancestor class”

Source:

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

Summary:

According to another issue, the RTEConnector.bandwidth attribute could be pushed from RTEMoCC::RTEConnector to GRM. If so, it would make sense to factorize the HwMedia.bandwith with a common ancestor (the concept of "bandwith" being SW/HW agnostic). Proposed resolution: remove the bandwidth attribute from HwMedia and push it into a GRM ancestor class.

Resolution:
The proposed resolution shall be followed and inserted in the resolution of issue 11835.
The bandwidth attribute should be removed from HwMedia and placed in CommunicationMedia in GRM with a more general explanation. This solution unfortunately may impact terminology in future GQAM variations, where different names are used for the same concepts. Now the conflict is not present since there is not direct inheritance. Considering that issue 11835 is in the same ballot all changes should be consistently indicated to vote for them in that issue. Hence this is now in the scope of Issue 11835.

Revised Text:

See issue 11835, where explanation of attribute GRM:: CommunicationMedia should include a text like :

bandwidth: NFP_DataTxRate [0..1]

the capacity of the communication element when applicable

Disposition: Duplicated

Disposition: Duplicate

OMG Issue No: 11879

Title: HRM::HwMemory stereotype

Source:

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

Summary:

In the HRM::HwMemory stereotype, I would suggest removing the Timing datatype and directly pushing the attributes in the HwMemory stereotype, for the sake of usability

Resolution:

cf. resolution of issue 11521.

Disposition: Duplicate

Disposition: Duplicate/merged

OMG Issue No: 11885

Title: page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5 (Arrival pattern data type)

Source:

Carleton University (Dr. Dorina C. Petriu, [e-mail])

Summary:

a) Inconsistent definition of dataType ArrivalPattern as follows:

- on page 263, Fig.15.3 and on page 288, Fig.16.3 the definition contains 7 values (the last two are “open” and “close”)

- on page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5, the same definition contains only 6 values ("open" is missing and should be added).

Example of use of different arrival patterns: “open” in Fig.17.17 and “closed” in 17.22.

Disposition: See issue 11885 (Annex D WG) for disposition

Document ptc/08-05-22