MARTE 1.0b2 FTF Avatar
  1. OMG Issue

MARTE — TimingResource of GRM

  • Key: MARTE-144
  • Legacy Issue Number: 12225
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    My concern is about the TimingResource of GRM. In the domain model (10.2.2, p.89-90 and figure 10.7), TimingResource both refers to a Clock (since it is a Resource) and specializes ChronometricClock. The specialization is not suitable since a TimingResource is not a clock (with the meaning given in the Time profile) but merely refers to a Clock. To make a TimingResource specific to chronometric clocks, it is largely sufficient to refine the association to a Clock by an association to a ChronometricClock. In the UML representation (Figure 10.15) and in I would simply remove the specialization to ClockType. The reference to a Chronometric Clock (idealClock in this precise case) is already implicit by the use of the NFP_Duration type. If you really want to insist on the use of chronometric clock only, a comment in the text should do it.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We propose to remove the specialization from TimingResource to
    ChronometricClock in the domain view. In the UML representation, we remove
    the specialization from ClockType. This latter specialization is very problematic
    since Resource extends several metaclasses (Property, InstanceSpecification,
    Classifier, Lifeline, Connectableelement) and ClockType only extend Class.
    The specializations are not required since a TimingResource being a resource
    can already access to information of Clocks (including if required,

  • Updated: Fri, 6 Mar 2015 20:58 GMT