Issue 11846: Enhance the concept of Observer in GQAM (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Enhancement Severity: Significant Summary: Subject: 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 Actions taken: December 20, 2007: received issue February 17, 2010: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 20 Dec 2007 15:26:57 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: UML profile for MARTE Section: 15 FormalNumber: 07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 272 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description Subject: 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? Date: Thu, 17 Apr 2008 16:33:18 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: marte-ftf@omg.org Subject: issue 11846 suggestion This issue from Huascar asks for a more general kind of observer, able for instance to observe the total energy used between a start and end event. It is sufficient for MARTE to define what is to be observed. A solution within the scope of the FTF could be to define an optional expression for the quantity to be observed, in terms of variables representing NFPs. The observation would be the integral of this expression with respect to time, over the time interval from start to end. The default for the expression would be 1. The observation would itself be an NFP, but one of mutable type depending on the type of the expression. What would its type be? Clearly care would have to be taken to create a correct expression. Huascar could say if this is possible with NFPs, I cannot tell. All could comment if this is desirable. 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)