Legacy Issue Number: 12225
Source: INRIA ( Frederic Mallet)
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 10.3.2.20 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
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