Issue 12283: TimingObserver in GQAM should be renamed to TimedObserver (marte-ftf) Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca) Nature: Uncategorized Issue Severity: Summary: s discussed in the telecon today, the TimingObserver in GQAM should be renamed to TimedObserver, and the text should show that it can collect any measure, including time intyervals but also energy memory etc, over an interval bounded by two events. This is a separate issue from 11775 which suggests moving this concept to the Time chapter. 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 Actions taken: March 18, 2008: received issue February 17, 2010: closed issue Discussion: End of Annotations:===== te: Tue, 18 Mar 2008 12:08:46 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: issues@omg.org Subject: MARTE: Generalize TimingObserver to TimedObserver As discussed in the telecon today, the TimingObserver in GQAM should be renamed to TimedObserver, and the text should show that it can collect any measure, including time intyervals but also energy memory etc, over an interval bounded by two events. This is a separate issue from 11775 which suggests moving this concept to the Time chapter. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html)