Omg issue Number

Disposition: Resolved

OMG Issue No: 11836

Title: Rename Subprofile RTEMoCC

Source:

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

Summary:

Find a better name of the RTEMoCC profile. This acronym is long and does not sound sophisticated. Find for a better alternative.

Resolution:

Replace RTEMoCC with “High-level Application Modeling” and use the acronym of “HLAM”

Revised Text:

Replace all instances of RTEMoCC with HLAM.

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11837

Title: chapter 11 (GCM) should be moved in the Part II of the specification

Source:

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

Summary:

Chapter 11 (GCM) should be moved in the Part II of the specification. Details: The argument to push GCM in Part I of MARTE was that it was used BOTH for modeling and analysis. After having read the whole document, I do not see any dependency from the GQAM to GCM therefore I suggest pushing back GCM in Part II of MARTE (the design part) to make the MARTE foundations thiner. Proposed resolution: move chapter 11 in Part II and update the chapter number accordingly.

Resolution:

Proceed according to the proposed resolution.

Revised Text:

• 
  Remove the GCM package from the MARTE foundations and add it to the MARTE design model, in Figure 6.4, page 13
  
• 
  Change the chapter number of GCM from 11 to 12
  
• 
  Change the chapter number of Alloc from 12 to 11
  
• 
  Move the GCM chapter to Part II
  
• 
  Remove references to GCM, page 19
  
• 
  Update the chapter number of Alloc, page 19
  
• 
  Add a reference to GCM, page 149
  
• 
  Change the section number of GCM in Annex F from F.5 to F.6 and update the sub-section numbers accordingly
  
• 
  Change the section number of Alloc in Annex F from F.6 to F.5 and update the sub-section numbers accordingly
  
• 
  Update the Table Of Content of the specification
  

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11843

Title: How to model the size the heap size of an Ada runtime with SRM?

Source:

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

Summary:

How to model the size the heap size of an Ada runtime with SRM?

Resolution:

An attribute must be added to the MARTE::SRM::SW_Concurrency::swConcurrentResource.

heapSizeElements: UML::Kernel::Classes::TypedElement [0..*]

Revised Text:
Figure 14.5
Old:

New:

Figure 14.25

Old :

New :

Stereotype Description section to update

In the SwConcurrentResource descriptions, an attribute must be added:

heapSizeElements : TypedElement [0..*] elements which maps the semantic of the resource heap size in case of dynamic memory allocation.

Domain Description section to update

heapSizeElements : ModelElement [0..*] elements which maps the semantic of the resource heap size in case of dynamic memory allocation.

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11846

Title: Enhance the concept of Observer in GQAM

Source:

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

Summary:

Enhance the concept of Observer in GQAM. Details: The concept of observer is definitely useful although limited to timing and latency. There should be a way to support (at least) throughput and capacity observers. Maybe a more generic mechanism would be useful here?

Resolution:

After significant discussion it was agreed in a telecon that the existing stereotype has the desired generality. The necessary extensions should be applied to the existing observer by users, as they need them, rather than trying to define something that will satisfy all needs. All that is needed is to describe this process of extension, and to rename the TimingObserver to TimedObserver, signifying an observation over an interval of time.

Revised Text:

The revised text is given in issue 12283, which renamed it to TimedObserver. It is repeated here, including the renaming:

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