Issue 15116: Domain concept (definingEvent) not implemented in the UML representation (marte-rtf) Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr) Nature: Revision Severity: Significant Summary: The domain view of the Time Chapter provides clocks to achieve two goals. First, Clocks give an explicit time referential for various kinds of elements. Second, Clocks give an orthogonal mechanism to put temporal information on any events, whereas UML consider TimeEvent as a special case of events. In the domain view, the second position was made concrete by the attribute "definingEvent" that was denoting the event from which a clock was built (occurrences of the events, where the instants of the clock). All the stereotypes provided in the UML representation address the first objective. None address the second one. Suggested resolution, the stereotype "Clock" could extend the metaclass "Event" as well. That would allow clock constraints to constrain/specify the occurrences of events. Resolution: Revised Text: see page 153 - 154 of ptc/2010-08-30 for revised text Actions taken: March 3, 2010: received issue January 14, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 03 Mar 2010 07:55:09 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Fréric Mallet Company: INRIA mailFrom: Frederic.Mallet@sophia.inria.fr Notification: Yes Specification: MARTE Section: 9 FormalNumber: formal/2009-11-02 Version: 1.0 RevisionDate: Novembre 2009 Page: 63 Title: Domain concept (definingEvent) not implemented in the UML representation Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The domain view of the Time Chapter provides clocks to achieve two goals. First, Clocks give an explicit time referential for various kinds of elements. Second, Clocks give an orthogonal mechanism to put temporal information on any events, whereas UML consider TimeEvent as a special case of events. In the domain view, the second position was made concrete by the attribute "definingEvent" that was denoting the event from which a clock was built (occurrences of the events, where the instants of the clock). All the stereotypes provided in the UML representation address the first objective. None address the second one. Suggested resolution, the stereotype "Clock" could extend the metaclass "Event" as well. That would allow clock constraints to constrain/specify the occurrences of events.