Omg issue Number

Disposition: Deferred

OMG Issue No: 11764

Title: Section: NFP

Source:

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

Summary:

[NFP] A very useful concept for NFP annotations could be the notion of ‘NFP level’. For instance, a NFP level may identify a group of non-functional values that are valid for a specific system operation mode. More specifically, in a component-based architecture, components can support different working modes, and these working modes may provide different non-functional values or qualities for the same services. In infrastructures supporting dynamic resource management, the resources may offer different non-functional values depending on the system load. From a conceptual viewpoint, a NFP level can identify a level of model refinement. For example, one may define NFP values according to available estimates in early development phases, while further accurate measurement values may be annotated in the same models. A NFP level, in this case, can offer a mechanism to organize non-functional values according to successive refinement stages.

Resolution:

This concept is useful but it needs a careful evaluation, not only, from a discussion viewpoint, but also from a tooling viewpoint. This means that we should figure out how a tool would manage these different value versions and make them available for users.

This issue can be considered as an enhancement of the NFP chapter for a more advanced usage, and it may wait for further MARTE versions.

Hence, we propose to defer this issue

Revised Text:

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11817

Title: Section: HRM

Source:

THALES (Dr. Laurent Rioux, [e-mail])

Summary:

Some stereotype in the HRM profile do not have icons. And the icons proposed in the specification need to be improved to clarify the understanding of the model. possible solution: change icons on HRM and add icons on stereotype do not have yet

Discussion:

The description of the issue concerns an improvement of the spec rather than the resolution of a real issue. I would propose to address the remark as an improvement of MARTE, in a next version of the spec.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11820

Title: ports in GCM

Source:

CEA-List (Chokri Mraidha, [e-mail])

Summary:

This issue is about ports in GCM. In UML if a port is typed with an interface, this interface is automatically considered as provided by the port (see port description section 9.3.11 in UML Superstructure). In GCM it is possible to type a MessagePort with an interface (BFeatureSpecification). Moreover if a MessagePort direction is specified to be "required", and if the port is typed with a BFeatureSpecification interface, this interface contents are considered to be provided by the port according to UML. This results in a confusing specification: a MessagePort specifying a required interface provides that interface at the same time.

Discussion:

While flow ports brings new concepts that are relevant for the real-time and embedded domain (flow-oriented communications), message ports have been introduced in MARTE just as a short-hand notation for existing UML features (provided and required interfaces).

As a consequence, using message ports may create redundancy and inconsistency with the UML composite structures, as mentioned in the summary of this issue.

Providing a clarification on this issue might require starting a discussion on the rationale of message ports in GGM. Unfortunately, this discussion cannot be organized in the time frame of the current FTF.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11838

Title: Explain the Meaning of NFP Constraints which are Applied to Provided and Required Interfaces

Source:

THALES Mr. Sebastien Demathieu (Sebastien DOT demathieu AT thalesgroup DOT com)

ARTiSAN Software Lonnie VanZandt (lonnievz AT artisansw DOT com)

Summary:

What are the semantics of real-time features on provided/required interfaces? A section of Chapter 13 should explain how real-time service and real-time features from RTEMoCC can be applied on provided and required interfaces of a component (such as those of the CORBA Component Model). More precisely, what are the semantics of a real-time feature (e.g. a deadline) on a provided/required interface? Is there an underlying notion of contract between required/provided interfaces?

Resolution:

An interface is a contract. Today, for software systems, interfaces typically express only a specification for available behaviors (e.g. Operations) or permissible information (e.g. to some extent FlowSpecs). Arguably, though, one ought to be able to express performance, cost, reliability, quality, and other non-functional properties in an interface specification. Therefore, it is not unreasonable to infer that an NFP Constraint on an interface is a constraint also on any realization of that interface. If NFP Constraints on a Provided interface conflict with NFP Constraints on a Required interface, clearly any attempt to pair the two entities should be difficult.

As there currently is no section within Chapter 13 which discusses Interfaces generally or specifically applying NFP Constraints to Interfaces, the topic should be, at this late date, deferred to a subsequent revision of the MARTE specification.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11839

Title: the GCM [now RTEMoCC] chapter should define a causality model for flows

Source:

THALES (Mr. Sebastien Demathieu, Sebastien DOT demathieu AT thalesgroup DOT com)

Summary:

The GCM [now RTEMoCC] chapter should define a causality model for flows. The GCM chapter introduces the notion of flow port as a structural feature of a structured class. However, the specification does not states what happens when a flow comes into / get out of a flow port. There should be a reference to behaviors owned by this structured class. Proposed resolution: enhance the GCM [RTEMoCC] chapter.

Discussion:

This issue was accepted in transfer from the GCM working group.

The consensus of the MARTE FTF is that this issue raises a valid point, that the RTEMoCC chapter should describe the causality implications of the MARTE flows, there is some synergy with the Executable UML specifications, and that there is insufficient time available to document this material prior to the voting on Ballot 2. Therefore, it is, for now, to be deferred.

Disposition: Deferred