Issue 15207: Timing Diagram and interchange (uml2-rtf) Source: International Business Machines (Mr. James Bruck, nobody) Nature: Uncategorized Issue Severity: Summary: In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another. In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle". Some facts: If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram. StateInvariant is an InteractionFragment. The StateInvariant is kept in the Interaction::Fragment ordered collection. Issue: The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state? StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first. Having to duplicate the StateInvariant and/or Constraint seems incorrect? ( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous ) Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient. Any insight would be appreciated. Resolution: Revised Text: Actions taken: April 16, 2010: received issue Discussion: End of Annotations:===== c: Tao Weng , Dusko Misic Subject: Question about Timing Diagram and interchange. X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: James Bruck Date: Fri, 16 Apr 2010 14:33:27 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 04/16/2010 14:33:30, Serialize complete at 04/16/2010 14:33:30 Hi All, In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another. In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle". Some facts: If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram. StateInvariant is an InteractionFragment. The StateInvariant is kept in the Interaction::Fragment ordered collection. Issue: The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state? StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first. Having to duplicate the StateInvariant and/or Constraint seems incorrect? ( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous ) Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient. Any insight would be appreciated. Regards, - James. To: model-interchange@omg.org, uml2-rtf@omg.org Cc: Dusko Misic , Tao Weng Subject: Re: Question about Timing Diagram and interchange. X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: James Bruck Date: Fri, 16 Apr 2010 16:18:29 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 04/16/2010 16:18:30, Serialize complete at 04/16/2010 16:18:30 .. Another idea is that the timing diagram is showing Constraint and not StateInvariant. The constraint could be owned by the lifeline and the constrainedElement() collection of Constraint could refer to some State - perhaps this is the intent of the terminology "State or Condition" used in the spec.? If that is the case, the problem then boils down to an interchange issue: If I give another person my semantic model, how could they draw the timing diagram - I've built in a lot of assumptions on using constraints and where they are located and how the constrainedElement collection is to be used. Also, if I don't use StateInvariants on the timing diagram (but rather Constraint), how could I accurately create the SequenceDiagram from the same interaction. For any given interaction, I should be able to create consistent Timing and Sequence diagrams that show the same elements, should I not? If I do indeed use StateInvariants, the problem becomes one of having to duplicate constraints unecessarily. What would really resolve this issue would be a diagram with the correctly formatted XMI that goes with it - a bit of a chicken and egg situation perhaps :) All input is greatly appreciated. Regards, - James. Question about Timing Diagram and interchange. James Bruck to: uml2-rtf, model-interchange 04/16/2010 02:37 PM Cc: Tao Weng, Dusko Misic -------------------------------------------------------------------------------- Hi All, In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another. In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle". Some facts: If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram. StateInvariant is an InteractionFragment. The StateInvariant is kept in the Interaction::Fragment ordered collection. Issue: The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state? StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first. Having to duplicate the StateInvariant and/or Constraint seems incorrect? ( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous ) Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient. Any insight would be appreciated. Regards, - James. To: Juergen Boldt Subject: Re: Question about Timing Diagram and interchange. X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: James Bruck Date: Fri, 16 Apr 2010 16:47:05 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 04/16/2010 16:47:07, Serialize complete at 04/16/2010 16:47:07 Hi Juergen, Yes please. Any way you slice it, I think there are problems. Thanks, - James. Re: Question about Timing Diagram and interchange. Juergen Boldt to: James Bruck 04/16/2010 04:23 PM -------------------------------------------------------------------------------- Hi James, want me to file an issue for this? -Juergen At 04:18 PM 4/16/2010, you wrote: .. Another idea is that the timing diagram is showing Constraint and not StateInvariant. The constraint could be owned by the lifeline and the constrainedElement() collection of Constraint could refer to some State - perhaps this is the intent of the terminology "State or Condition" used in the spec.? If that is the case, the problem then boils down to an interchange issue: If I give another person my semantic model, how could they draw the timing diagram - I've built in a lot of assumptions on using constraints and where they are located and how the constrainedElement collection is to be used. Also, if I don't use StateInvariants on the timing diagram (but rather Constraint), how could I accurately create the SequenceDiagram from the same interaction. For any given interaction, I should be able to create consistent Timing and Sequence diagrams that show the same elements, should I not? If I do indeed use StateInvariants, the problem becomes one of having to duplicate constraints unecessarily. What would really resolve this issue would be a diagram with the correctly formatted XMI that goes with it - a bit of a chicken and egg situation perhaps :) All input is greatly appreciated. Regards, - James. Question about Timing Diagram and interchange. James Bruck to: uml2-rtf, model-interchange 04/16/2010 02:37 PM Cc: Tao Weng, Dusko Misic -------------------------------------------------------------------------------- Hi All, In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another. In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle". Some facts: If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram. StateInvariant is an InteractionFragment. The StateInvariant is kept in the Interaction::Fragment ordered collection. Issue: The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state? StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first. Having to duplicate the StateInvariant and/or Constraint seems incorrect? ( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous ) Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient. Any insight would be appreciated. Regards, - James. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org