Omg issue Number

Disposition: Resolved

OMG Issue No: 12240

Title: picture 11.8, ports "loc" and "ftp" (marte-ftf)

Source:

AdaCore (Matteo Bordin, [e-mail])

Summary:

On picture 11.8, ports "loc" and "ftp" are typed with the type of the interface they require (instead of a classifier requiring the interfaces). Probably the names "loc" and "ftp" are for the ports, but the type is for the (required) interface.

Resolution:

The port “loc” and “fp” are defined in Figure 11.18 and not in Figure 11.8. Still, the issue is totally relevant and the Figure 11.18 is updated according to the proposed resolution.

Revised Text:



Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12242

Title: VSL variable declaration (inconsistency between the BNF and the metamodel)

Source:

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

Summary:

Subject: VSL variable declaration (inconsistency between the BNF and the metamodel) Details: The direction of a VSL variable is refered as optional in the metamodel (multiplicity of 0..1) while it is presented as a mandatory term in the BNF. Proposed resolution: Change to BNF to turn variable declaration into an optional term.

Resolution:

Proceed with proposal: change the BNF to do direction of variable declaration an optional term.

Revised Text:

-In page 402, change the term ‘variable-declaration’ into:

::= [] '$' [] ['=' ]

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12246

Title: Section 16.2.2 (SAM)

Source:

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

Summary:

The first paragraph of page 289 makes reference to 'isSchedulability', which is wrong. The right name is 'isSchedulable'.

Resolution:

Revise the mistake.

Revised Text:

-In page 289, replace in the first paragraph ‘isSchedulability’ with ‘isSchedulable’.

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12247

Title: page 288: change explanation

Source:

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

Summary:

When explaining the semantics of the stereotype atributes 'EndToEndDeadline' and 'EndToEndTime' of an EndToEndFlow (page 289), it is clarified that these measures apply "only one input end-to-end stimuli exist". However, an end-to-end flow can have several execution end points (e.g., an activity diagram with more than 'one activity end' node). So, it is necessary to precise better the semantics of these two attributes. A resolution could be to add at the end of the first paragraph of page 289 something like: "...stimuli exist and only one finalization Step exists".

Resolution:

Proceed with the proposal to clarify semantics.

Revised Text:

-At the end of the first paragraph of page 289, add the following phrase: ...stimuli exist “and only one finalization Step exists".

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12248

Title: Section: Annex B (VSL)

Source:

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

Summary:

There are the following mistakes in the VSL grammar: obsCallExpression (section B.3.3), instead of obs-call-expression value_specification (section B.3.3.10), instead of value-specification.

Resolution:

Fix these typos:

-Rename obsCallExpression (section B.3.3), by obs-call-expression
-Rename value_specification (section B.3.3.10), by value-specification.

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 12283

Title: TimingObserver in GQAM should be renamed to TimedObserver

Source:

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

Summary:

As discussed in the telecon Mar 17 08, the TimingObserver in GQAM should be renamed to TimedObserver, and the text should show that it can collect any measure, including time intervals but also energy memory etc, over an interval bounded by two events.

Resolution:

{The TimedObserver may be extended to return any statistical measure on any NFP over the interval from the startEvent to the EndEvent}

Revised Text:

There are five parts:

1. Old text p 265, at the beginning of Section 15.2.3

Timing Observers (Figure 15.4) are conceptual entities that collect timing requirements and predictions related to a pair of user-defined observed events. In this sense, TimingObserver uses Timed Instant Observations (from the Time subprofile) to define the observed event in a given behavioral model. Normally the observer expresses constraints on the duration between the two time observations, named startObs and endObs in the figure. Timing observers are a powerful mechanism to annotate and compare timing constraints against timing predictions provided by analysis tools. Timing observers can be used as predefined and parameterized patterns (e.g., latency, jitter) or by means of more elaborate expressions (e.g., written in OCL or VSL) since TimingObserver inherits all the modeling capabilities from NfpConstraint.

LatencyObserver specifies a duration observation between startObs and endObs, with a miss ratio assertion (percentage), a utility function which places a value on the duration, and a jitter constraint. Jitter is the difference between maximum and minimum duration.

A timing observer may be attached to the start and end observed events, or to a behavior element such as a Step. In the latter case the start and end events are the start and end events for execution of the behavior element.

1. REvised text:

TimedObservers (Figure 15.4) are conceptual entities that define requirements and predictions for measures defined on an interval between a pair of user-defined observed events, named startObs and endObs in the figure. A TimedObserver must be extended to define the measure that it collects. The LatencyObserver makes this extension to collect the duration between the two events, and some properties of that duration. Other extensions can be defined to describe power or energy usage, memory usage, etc., over a partial behavior.

A TimedObserver uses Timed Instant Observations (from the Time subprofile) to define the start and end events in a given behavioral model. It may express constraints on the defined measure, for instance on the duration between the two time observations. It can use predefined and parameterized patterns (e.g., latency, jitter) or more elaborate expressions (e.g., written in OCL or VSL) since TimedObserver inherits all the modeling capabilities from NfpConstraint.

A TimedObserver may be attached to particular start and end observed events, or to a behavior element such as a Step. In the latter case the start and end events are the start and end events for execution of the behavior element.

LatencyObserver specifies a duration observation between startObs and endObs, with a miss ratio assertion (percentage), a utility function which places a value on the duration, and a jitter constraint. Jitter is the difference between the maximum and minimum duration.

2. Fig 15.4 is revised by renaming TimingObserver to TimedObserver.

3. Profile Fig 15.8 is revised by renaming gaTimingObserver to gaTimedObs

4. Sec 15.3.2.14 p 281

Old text:

15.3.2.14 GaTimingObserver

The GaTimingObs stereotype maps the TimingObserver domain element (section F.10.18) denoted in Annex F.

GaTimingObs is a purely conceptual entity that serves to collect timing requirements and predictions that relates to user-defined observed events. In this sense, GaTimingObs uses UML TimeObservations to define the observed event in a given behavioral model.

New Text:

15.3.2.14 GaTimedObs

The GaTimingObs stereotype maps the TimedObserver domain element (section F.10.18) denoted in Annex F.

GaTimedObs is a purely conceptual entity that serves to collect timing requirements and predictions that relates to user-defined observed events. In this sense, GaTimedObs uses UML TimeObservations to define the observed event in a given behavioral model.

5. Appendix 5 section F.10.18

Replace TimingObserver by TimedObs

Disposition: Resolved