Omg issue Number

Disposition: Closed, no change

OMG Issue No: 11163

Title: Consider adding a new attribute to «boundedSubtype»

Source:

The MathWorks (Mr. Alan Moore, [e-mail])

Summary:

Consider adding a new attribute to «boundedSubtype» to specify what the default value for the new type is. Something like <>.defaultValue

Resolution:

A BoundedSubtype, as other data types, defines a space of valid values. However, it doesn’t describe any particular value property. Specifying a default value is to be done at property declaration level, and it’s already supported by UML itself. This approach is natural from a pragmatic viewpoint (different properties typed by the proposed BoundedSubtypes could have different default values), and from the general practice in (modeling, programming) languages.

For these reasons, we don’t add default values for BoundedSubtype, or whatever data types.
Disposition: Closed, no change

Disposition: Closed No Change

OMG Issue No: 11548

Title: Annex B VSL BNF

Source:

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

Summary:

In the VSL BNF, the use of the "[ ]" symbol should not be limited to collections. One may want to use it along with variable call expressions (e.g. "collec[2]"), property call expressions. Maybe other kinds of value specifications also apply.

Resolution:

The current mechanism of defining operations on data types allows one to define a given operation independently of the current value itself. For instance, a property could be typed by a Collection of Integers, and this collection could be specified by a Variable. So, we can apply to this variable, all the operations defined for Collections.

This issue is also related to Issue 11547, and do not need any modification in the spec.
Disposition: Closed No Change

Disposition: Closed, no change

OMG Issue No: 11619

Title: Section: 14/2

Source:

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

Summary:

In HRM, a stereotype called HwResource is used in the HwLogical subpackage to provide a logical representation of a hardware resource. At the same time, a stereotype with the name is used in the HwPhysical subpackage to provide a physical representation of a hardware resource. Although it is legal in this context, defining two stereotypes with the same names that have different semantics may create confusion in a user's mind. I would suggest renaming HwResource into HwLogicalResource / HwPhysicalResource. The same thing applies for HwLogical::HwResourceService and HwPhysical::HwResourceService.

Discussion:

HwLogical and HwPhysical both address the issue of hardware modeling, proposing two different abstraction levels for hardware modeling. It means that if two stereotypes (one defined in each package) have the same name, they do not fundamentally differ from a semantic view point. They just reflect a level of detail that is consistent with the abstraction level that is addressed by the package. In this context, it is not necessary to define a particular name for each stereotype. This remark concerns both HwResource and HwResourceService.

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11658

Title: Section: 11.2.1

Source:

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

Summary:

FlowPort and MessagePort are subclasses of InteractionPort. These two classes have common properties: isConjugated and isAtomatic (there is actually a third one, “direction”, but I think there is an issue with this property). These properties could be directly defined as properties of the common parent class, i.e. InteractionPort.

Discussion:

The design rationale for GCM was to rely on the concept of FlowPort already defined in SysML. MARTE-specific message ports currently sit aside flow ports as a short-hand notation for exiting UML features.

As semantics of message ports are not totally clear (see issue 11820), and in the context of coordination efforts between the MARTE and SysML languages, it is maybe wiser not to create a strong couple between flow ports and message ports.

Note that the semantics of isConjugated for flow ports and message ports are close but not entirely similar. A conjugated flow ports means that the flow is relayed in the opposite direction of the one indicated on the port (in, out, inout). On the other hand a conjugated message port deals with provided/required behavioral features.

Disposition: Closed, no change

Disposition: Closed, no change

OMG Issue No: 11659

Title: Section: 11.2.1

Source:

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

Summary:

The ability to type FlowPorts by Signals (or by FlowSpecifications containing FlowProperties typed by Signals) is confusing. MessagePorts (which are just a light specialization of UML ports) already enable signal-based communications. Things would be clearer if FlowPorts would only enable data-flow communications, and if MessagePorts would be used for service or signal-based communications (just as classical UML ports are). I suppose that this feature is inherited from SysML, but this is however confusing in the context of UML

Discussion:

The design rationale for GCM was to rely on the concept of FlowPort already defined in SysML. The ability to type a flow port by a signal directly comes from SysML. That needs to be leave as unchanged to keep the consistency with the SysML::FlowPort.

Disposition: Closed, no change