Issue 11117: Section: 12. Interactions (sysml-rtf) Source: International Business Machines (Mr. Eldad Palachi, eldad.palachi(at)il.ibm.com) Nature: Enhancement Severity: Significant Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: July 4, 2007: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: Multiple suggestions to address this issue were discussed by the RTF, but a final resolution was not reached. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Multiple suggestions to address this issue were discussed by the RTF, but a final resolution was not reached. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 04 Jul 2007 08:30:02 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Eldad Palachi Company: Telelogic mailFrom: eldad.palachi@telelogic.com Notification: Yes Specification: Ports and Flows Section: 12. Interactions FormalNumber: ptc/06-05-04 Version: 1.0 RevisionDate: 1.0 Page: 101-108 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Description I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Subject: On the usage of UML2's Interaction within SysML Date: Mon, 3 Mar 2008 12:24:59 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: On the usage of UML2's Interaction within SysML thread-index: Ach9ITet7On4crdjTI2OZaBIbnybpA== From: "GERARD Sebastien 166342" To: X-OriginalArrivalTime: 03 Mar 2008 11:25:00.0210 (UTC) FILETIME=[37B59920:01C87D21] Hi all, I was wondering how to use UML2.s interaction completely with SysML. The component model defined within SysML enables both message and data passing between components through respectively the usage of standard or flow ports. UML2.Interaction are based on message passing paradigm for communication between lifelines involved in a given interaction. In this context, how is it possible within SysML to use both the flow port concept within Interaction. I think SysMl should define some extension to the UML2.s event concept to define as for example SendItemFlowEvent and ReceiveItemFlowEvent extensions in order to enable to specify flow-based (I also call data-based) communication between lifelines. Reactions, comments? Thanks, Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment Subject: RE: On the usage of UML2's Interaction within SysML Date: Mon, 3 Mar 2008 12:38:32 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On the usage of UML2's Interaction within SysML Thread-Index: Ach9ITet7On4crdjTI2OZaBIbnybpAAAbRmQ From: "Tim Weilkiens" To: "GERARD Sebastien 166342" , Sébastien, you'r right and we already have an issue about that: http://www.omg.org/issues/issue11117.txt I think that could be a difficult thing. How to integrate continuous item flows in the interaction model? Tim -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Monday, March 03, 2008 12:25 PM To: sysml-rtf@omg.org Subject: On the usage of UML2's Interaction within SysML Hi all, I was wondering how to use UML2.s interaction completely with SysML. The component model defined within SysML enables both message and data passing between components through respectively the usage of standard or flow ports. UML2.Interaction are based on message passing paradigm for communication between lifelines involved in a given interaction. In this context, how is it possible within SysML to use both the flow port concept within Interaction. I think SysMl should define some extension to the UML2.s event concept to define as for example SendItemFlowEvent and ReceiveItemFlowEvent extensions in order to enable to specify flow-based (I also call data-based) communication between lifelines. Reactions, comments? Thanks, Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment Subject: RE: On the usage of UML2's Interaction within SysML Date: Mon, 3 Mar 2008 12:40:40 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: On the usage of UML2's Interaction within SysML thread-index: Ach9ITet7On4crdjTI2OZaBIbnybpAAAbRmQAAAVToA= From: "GERARD Sebastien 166342" To: "Tim Weilkiens" , X-OriginalArrivalTime: 03 Mar 2008 11:40:41.0623 (UTC) FILETIME=[68D5D270:01C87D23] Continuous flow integration within interaction will need to define a very new semantics to UML2.s interactions for which the causality model is fundamentally discrete. -------------------------------------------------------------------------------- De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé : lundi 3 mars 2008 12:39 À : GERARD Sebastien 166342; sysml-rtf@omg.org Objet : RE: On the usage of UML2's Interaction within SysML Sébastien, you'r right and we already have an issue about that: http://www.omg.org/issues/issue11117.txt I think that could be a difficult thing. How to integrate continuous item flows in the interaction model? Tim -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Monday, March 03, 2008 12:25 PM To: sysml-rtf@omg.org Subject: On the usage of UML2's Interaction within SysML Hi all, I was wondering how to use UML2.s interaction completely with SysML. The component model defined within SysML enables both message and data passing between components through respectively the usage of standard or flow ports. UML2.Interaction are based on message passing paradigm for communication between lifelines involved in a given interaction. In this context, how is it possible within SysML to use both the flow port concept within Interaction. I think SysMl should define some extension to the UML2.s event concept to define as for example SendItemFlowEvent and ReceiveItemFlowEvent extensions in order to enable to specify flow-based (I also call data-based) communication between lifelines. Reactions, comments? Thanks, Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment Subject: RE: On the usage of UML2's Interaction within SysML Date: Mon, 3 Mar 2008 12:42:36 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: On the usage of UML2's Interaction within SysML thread-index: Ach9ITet7On4crdjTI2OZaBIbnybpAAAbRmQAAArVqA= From: "GERARD Sebastien 166342" To: "Tim Weilkiens" , X-OriginalArrivalTime: 03 Mar 2008 11:42:36.0824 (UTC) FILETIME=[AD801980:01C87D23] Ok. Do you have a draft for resolution ? Eldad, do you have already setup a solution? -------------------------------------------------------------------------------- De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé : lundi 3 mars 2008 12:39 À : GERARD Sebastien 166342; sysml-rtf@omg.org Objet : RE: On the usage of UML2's Interaction within SysML Sébastien, you'r right and we already have an issue about that: http://www.omg.org/issues/issue11117.txt I think that could be a difficult thing. How to integrate continuous item flows in the interaction model? Tim -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Monday, March 03, 2008 12:25 PM To: sysml-rtf@omg.org Subject: On the usage of UML2's Interaction within SysML Hi all, I was wondering how to use UML2.s interaction completely with SysML. The component model defined within SysML enables both message and data passing between components through respectively the usage of standard or flow ports. UML2.Interaction are based on message passing paradigm for communication between lifelines involved in a given interaction. In this context, how is it possible within SysML to use both the flow port concept within Interaction. I think SysMl should define some extension to the UML2.s event concept to define as for example SendItemFlowEvent and ReceiveItemFlowEvent extensions in order to enable to specify flow-based (I also call data-based) communication between lifelines. Reactions, comments? Thanks, Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment Subject: RE: On the usage of UML2's Interaction within SysML Date: Mon, 3 Mar 2008 12:47:00 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On the usage of UML2's Interaction within SysML Thread-Index: Ach9ITet7On4crdjTI2OZaBIbnybpAAAbRmQAAArVqAAACTWcA== From: "Tim Weilkiens" To: "GERARD Sebastien 166342" , No. I didn't work on that issue. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Monday, March 03, 2008 12:43 PM To: Tim Weilkiens; sysml-rtf@omg.org Subject: RE: On the usage of UML2's Interaction within SysML Ok. Do you have a draft for resolution ? Eldad, do you have already setup a solution? -------------------------------------------------------------------------------- De : Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Envoyé : lundi 3 mars 2008 12:39 À : GERARD Sebastien 166342; sysml-rtf@omg.org Objet : RE: On the usage of UML2's Interaction within SysML Sébastien, you'r right and we already have an issue about that: http://www.omg.org/issues/issue11117.txt I think that could be a difficult thing. How to integrate continuous item flows in the interaction model? Tim -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Monday, March 03, 2008 12:25 PM To: sysml-rtf@omg.org Subject: On the usage of UML2's Interaction within SysML Hi all, I was wondering how to use UML2.s interaction completely with SysML. The component model defined within SysML enables both message and data passing between components through respectively the usage of standard or flow ports. UML2.Interaction are based on message passing paradigm for communication between lifelines involved in a given interaction. In this context, how is it possible within SysML to use both the flow port concept within Interaction. I think SysMl should define some extension to the UML2.s event concept to define as for example SendItemFlowEvent and ReceiveItemFlowEvent extensions in order to enable to specify flow-based (I also call data-based) communication between lifelines. Reactions, comments? Thanks, Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment Date: Mon, 28 Apr 2008 06:39:17 -0400 From: "Chonoles, Michael J" Subject: Proposed resolution for 11117 To: sysml-rtf@omg.org Thread-Topic: Proposed resolution for 11117 Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQ X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Apr 2008 10:39:23.0654 (UTC) FILETIME=[1FBA4A60:01C8A91C] Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin image001.emz oledata.mso Date: Mon, 28 Apr 2008 23:15:58 -0400 From: "Friedenthal, Sanford" Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams To: "Chonoles, Michael J" Cc: sysml-rtf@omg.org Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uA= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Apr 2008 03:15:59.0120 (UTC) FILETIME=[589A5100:01C8A9A7] Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin Date: Mon, 28 Apr 2008 23:25:04 -0400 From: "Chonoles, Michael J" Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams To: "Friedenthal, Sanford" Cc: sysml-rtf@omg.org Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Apr 2008 03:25:10.0132 (UTC) FILETIME=[A1081340:01C8A9A8] If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin Date: Mon, 28 Apr 2008 23:29:15 -0400 From: "Friedenthal, Sanford" Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams To: "Chonoles, Michael J" Cc: sysml-rtf@omg.org Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQ X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Apr 2008 03:29:16.0115 (UTC) FILETIME=[33A61A30:01C8A9A9] Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Date: Tue, 29 Apr 2008 09:30:12 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQAAhiZUA= From: "GERARD Sebastien 166342" To: "Friedenthal, Sanford" , "Chonoles, Michael J" Cc: X-OriginalArrivalTime: 29 Apr 2008 07:30:13.0495 (UTC) FILETIME=[DCEB3870:01C8A9CA] Hi guys, I had the same requireent to be able to use sequence diagram in the case of data flow. In one project, I did the following proposal (may be useful for SysML): We need to extend the message concept as defined within the chapter Interactions of the UML2 specification in order to enable UML2 interaction to support data-based communication. As shown in Figure 8, we then define the stereotype «ADLDataMessage». This latter owns a property, value, which models the data value conveyed by the message. The type of this property is a UML OpaqueExpression. An opaque expression consists of a set of body description described in some given language defining how to interpret each text string contained in the bodies. For our purpose, it is expected that users will use the Value Specification Language (VSL inshort) defined in the Marte specification to describe the value conveyed by a message. But the user is also free to adopt any kind of other language, such Java or C++ for example, or even natural language. Figure 9. UML profile diagram for EAST-ADL2 data-based message In UML2, a message owns generally two message ends: one refers to the event occurrence related to the posting of the message, whilst the other refers to the event occurrence related to the receipt of the message. Currently, due its initial intend, the UML2 interactions chapter defines only specific events dedicated to either operation-based message or signal-based message. For our concern, i.e. enabling data-based communication within UML2.s interactions, we will then need to also extend the concept of UML2.s Event as defined in the package UML::CommonBehaviors::Communications. Figure 10 denotes the proposed extensions we defined for that concern. It consists in extending the Event concept of UML2 by introducing an abstract stereotype, «ADLDataEvent» and to reify this latter in order to introduce both concepts of event related to posting and reception of data. Figure 10. UML profile diagram for EAST-ADL2 data event Firstly, we define an abstract stereotype «EADLDataEvent» and we generalize this latter into both stereotypes, «EADLSendDataEvent» and «EADLReceiveDataEvent». Both stereotype references a SysML ItemFlow which is used to denote the data that may be conveyed through the message. Finally, on the notation point of view, we propose to introduce a new representation of message in order to distinguish clearly data-based communication from signal-based and operation-based communications. A data-based message will then be represented as a line with a hollow triangle as an arrowhead (see next example). The name of the message will consist of the text string contained in the body of data referenced by one of the end event (either EADLSendDataEvent or EADLReceiveDataEvent). In case of complete messages (i.e. messages with two messages ends), it is the EADLSendDataEvent that is taken into account. In the diagram shown above, let.s consider ADLOutFlowPort and ADLInFLowPort as equivalent to SysML::Flowport. Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 29 avril 2008 05:29 À : Chonoles, Michael J Cc : sysml-rtf@omg.org Objet : RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin Date: Tue, 29 Apr 2008 06:43:02 -0400 From: "Chonoles, Michael J" Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams To: "Friedenthal, Sanford" Cc: sysml-rtf@omg.org Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQAA74Y6A= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Apr 2008 10:43:10.0530 (UTC) FILETIME=[D15E9220:01C8A9E5] Sandy Consider this as an approach to include flows in a sequence diagram . using message to carry data is fine when we are using standard ports and interfaces. Howe do we model on sequence diagrams flows arriving on flow ports. We must integrate the two worlds Else, We really are saying that the sequence diagrams do not support any of the changes we added to SysML to handle information flow, physical flow, etc. This need has been recognized by others, e.g.. Telelogic, and even by us within LMCO. Miichael. -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:29 PM To: Chonoles, Michael J Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin From: Alan Moore To: GERARD Sebastien 166342 , "Friedenthal, Sanford" , "Chonoles, Michael J" Cc: "sysml-rtf@omg.org" Date: Fri, 2 May 2008 11:08:31 +0100 Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQAAhiZUAAm/wAkA== Accept-Language: en-US, en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Hello Seb, I have a couple of concerns about your proposal. Firstly, «ADLDataEvent» extends Event which is abstract, and can.t have instances. So presumably, instances of «ADLSendDataEvent» and «ADLReceiveDataEvent», must extend instances of some concrete subclass of Event. Do you not care which? Or are you implicitly choosing SendSignalEvent and ReceiveSignalEvent (or something else)? Secondly, this proposal seems to deal with a push model of data flow, but what about a pull model? Cheers, Alan. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, April 29, 2008 8:30 AM To: Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hi guys, I had the same requireent to be able to use sequence diagram in the case of data flow. In one project, I did the following proposal (may be useful for SysML): We need to extend the message concept as defined within the chapter Interactions of the UML2 specification in order to enable UML2 interaction to support data-based communication. As shown in Figure 8, we then define the stereotype «ADLDataMessage». This latter owns a property, value, which models the data value conveyed by the message. The type of this property is a UML OpaqueExpression. An opaque expression consists of a set of body description described in some given language defining how to interpret each text string contained in the bodies. For our purpose, it is expected that users will use the Value Specification Language (VSL inshort) defined in the Marte specification to describe the value conveyed by a message. But the user is also free to adopt any kind of other language, such Java or C++ for example, or even natural language. Figure 9. UML profile diagram for EAST-ADL2 data-based message In UML2, a message owns generally two message ends: one refers to the event occurrence related to the posting of the message, whilst the other refers to the event occurrence related to the receipt of the message. Currently, due its initial intend, the UML2 interactions chapter defines only specific events dedicated to either operation-based message or signal-based message. For our concern, i.e. enabling data-based communication within UML2.s interactions, we will then need to also extend the concept of UML2.s Event as defined in the package UML::CommonBehaviors::Communications. Figure 10 denotes the proposed extensions we defined for that concern. It consists in extending the Event concept of UML2 by introducing an abstract stereotype, «ADLDataEvent» and to reify this latter in order to introduce both concepts of event related to posting and reception of data. Figure 10. UML profile diagram for EAST-ADL2 data event Firstly, we define an abstract stereotype «EADLDataEvent» and we generalize this latter into both stereotypes, «EADLSendDataEvent» and «EADLReceiveDataEvent». Both stereotype references a SysML ItemFlow which is used to denote the data that may be conveyed through the message. Finally, on the notation point of view, we propose to introduce a new representation of message in order to distinguish clearly data-based communication from signal-based and operation-based communications. A data-based message will then be represented as a line with a hollow triangle as an arrowhead (see next example). The name of the message will consist of the text string contained in the body of data referenced by one of the end event (either EADLSendDataEvent or EADLReceiveDataEvent). In case of complete messages (i.e. messages with two messages ends), it is the EADLSendDataEvent that is taken into account. In the diagram shown above, let.s consider ADLOutFlowPort and ADLInFLowPort as equivalent to SysML::Flowport. Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 29 avril 2008 05:29 À : Chonoles, Michael J Cc : sysml-rtf@omg.org Objet : RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin Date: Fri, 02 May 2008 13:04:49 -0400 From: "Chonoles, Michael J" Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams To: Alan Moore , GERARD Sebastien 166342 , "Friedenthal, Sanford" Cc: sysml-rtf@omg.org Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQAAhiZUAAm/wAkAAOWYsQ X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 02 May 2008 17:04:53.0604 (UTC) FILETIME=[A3E79240:01C8AC76] In my, more simplistic proposal, of just adding an enumeration literal, to MessagSort, I wish not distinguishes between push/pull. I.m interested in being able to show a non-implementation sending of discrete data from one life-line to another. Sebastian.s proposed notation -- that of a dashed line with the arrow in the middle is certainly fine, and may be more attractive than mine. Michael -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Friday, May 02, 2008 6:09 AM To: GERARD Sebastien 166342; Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hello Seb, I have a couple of concerns about your proposal. Firstly, «ADLDataEvent» extends Event which is abstract, and can.t have instances. So presumably, instances of «ADLSendDataEvent» and «ADLReceiveDataEvent», must extend instances of some concrete subclass of Event. Do you not care which? Or are you implicitly choosing SendSignalEvent and ReceiveSignalEvent (or something else)? Secondly, this proposal seems to deal with a push model of data flow, but what about a pull model? Cheers, Alan. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, April 29, 2008 8:30 AM To: Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hi guys, I had the same requireent to be able to use sequence diagram in the case of data flow. In one project, I did the following proposal (may be useful for SysML): We need to extend the message concept as defined within the chapter Interactions of the UML2 specification in order to enable UML2 interaction to support data-based communication. As shown in Figure 8, we then define the stereotype «ADLDataMessage». This latter owns a property, value, which models the data value conveyed by the message. The type of this property is a UML OpaqueExpression. An opaque expression consists of a set of body description described in some given language defining how to interpret each text string contained in the bodies. For our purpose, it is expected that users will use the Value Specification Language (VSL inshort) defined in the Marte specification to describe the value conveyed by a message. But the user is also free to adopt any kind of other language, such Java or C++ for example, or even natural language. Figure 9. UML profile diagram for EAST-ADL2 data-based message In UML2, a message owns generally two message ends: one refers to the event occurrence related to the posting of the message, whilst the other refers to the event occurrence related to the receipt of the message. Currently, due its initial intend, the UML2 interactions chapter defines only specific events dedicated to either operation-based message or signal-based message. For our concern, i.e. enabling data-based communication within UML2.s interactions, we will then need to also extend the concept of UML2.s Event as defined in the package UML::CommonBehaviors::Communications. Figure 10 denotes the proposed extensions we defined for that concern. It consists in extending the Event concept of UML2 by introducing an abstract stereotype, «ADLDataEvent» and to reify this latter in order to introduce both concepts of event related to posting and reception of data. Figure 10. UML profile diagram for EAST-ADL2 data event Firstly, we define an abstract stereotype «EADLDataEvent» and we generalize this latter into both stereotypes, «EADLSendDataEvent» and «EADLReceiveDataEvent». Both stereotype references a SysML ItemFlow which is used to denote the data that may be conveyed through the message. Finally, on the notation point of view, we propose to introduce a new representation of message in order to distinguish clearly data-based communication from signal-based and operation-based communications. A data-based message will then be represented as a line with a hollow triangle as an arrowhead (see next example). The name of the message will consist of the text string contained in the body of data referenced by one of the end event (either EADLSendDataEvent or EADLReceiveDataEvent). In case of complete messages (i.e. messages with two messages ends), it is the EADLSendDataEvent that is taken into account. In the diagram shown above, let.s consider ADLOutFlowPort and ADLInFLowPort as equivalent to SysML::Flowport. Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 29 avril 2008 05:29 À : Chonoles, Michael J Cc : sysml-rtf@omg.org Objet : RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin X-SoftScan-Status: clean Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Date: Sun, 4 May 2008 08:52:07 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams thread-index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQAAhiZUAAm/wAkAAOWYsQAE+m8cA= From: "Eldad Palachi" To: "Chonoles, Michael J" , "Alan Moore" , "GERARD Sebastien 166342" , "Friedenthal, Sanford" Cc: Just one comment . the notation below suggest that the data is relayed asynchronously (the send and receive occur at different times) however I would expect that flow ports relaying a data item would do so synchronously (once the value is relayed from the sender, the receiver immediately receives it and updates the relevant property). This is how we do it in Rhapsody and I think it also fits other tools that do data exchange like Simulink or Scade. Perhaps synchronous vs. asynchronous relay is something that needs to be précised in the Ports chapter? Eldad -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Friday, May 02, 2008 8:05 PM To: Alan Moore; GERARD Sebastien 166342; Friedenthal, Sanford Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams In my, more simplistic proposal, of just adding an enumeration literal, to MessagSort, I wish not distinguishes between push/pull. I.m interested in being able to show a non-implementation sending of discrete data from one life-line to another. Sebastian.s proposed notation -- that of a dashed line with the arrow in the middle is certainly fine, and may be more attractive than mine. Michael -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Friday, May 02, 2008 6:09 AM To: GERARD Sebastien 166342; Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hello Seb, I have a couple of concerns about your proposal. Firstly, «ADLDataEvent» extends Event which is abstract, and can.t have instances. So presumably, instances of «ADLSendDataEvent» and «ADLReceiveDataEvent», must extend instances of some concrete subclass of Event. Do you not care which? Or are you implicitly choosing SendSignalEvent and ReceiveSignalEvent (or something else)? Secondly, this proposal seems to deal with a push model of data flow, but what about a pull model? Cheers, Alan. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, April 29, 2008 8:30 AM To: Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hi guys, I had the same requireent to be able to use sequence diagram in the case of data flow. In one project, I did the following proposal (may be useful for SysML): We need to extend the message concept as defined within the chapter Interactions of the UML2 specification in order to enable UML2 interaction to support data-based communication. As shown in Figure 8, we then define the stereotype «ADLDataMessage». This latter owns a property, value, which models the data value conveyed by the message. The type of this property is a UML OpaqueExpression. An opaque expression consists of a set of body description described in some given language defining how to interpret each text string contained in the bodies. For our purpose, it is expected that users will use the Value Specification Language (VSL inshort) defined in the Marte specification to describe the value conveyed by a message. But the user is also free to adopt any kind of other language, such Java or C++ for example, or even natural language. Figure 9. UML profile diagram for EAST-ADL2 data-based message In UML2, a message owns generally two message ends: one refers to the event occurrence related to the posting of the message, whilst the other refers to the event occurrence related to the receipt of the message. Currently, due its initial intend, the UML2 interactions chapter defines only specific events dedicated to either operation-based message or signal-based message. For our concern, i.e. enabling data-based communication within UML2.s interactions, we will then need to also extend the concept of UML2.s Event as defined in the package UML::CommonBehaviors::Communications. Figure 10 denotes the proposed extensions we defined for that concern. It consists in extending the Event concept of UML2 by introducing an abstract stereotype, «ADLDataEvent» and to reify this latter in order to introduce both concepts of event related to posting and reception of data. Figure 10. UML profile diagram for EAST-ADL2 data event Firstly, we define an abstract stereotype «EADLDataEvent» and we generalize this latter into both stereotypes, «EADLSendDataEvent» and «EADLReceiveDataEvent». Both stereotype references a SysML ItemFlow which is used to denote the data that may be conveyed through the message. Finally, on the notation point of view, we propose to introduce a new representation of message in order to distinguish clearly data-based communication from signal-based and operation-based communications. A data-based message will then be represented as a line with a hollow triangle as an arrowhead (see next example). The name of the message will consist of the text string contained in the body of data referenced by one of the end event (either EADLSendDataEvent or EADLReceiveDataEvent). In case of complete messages (i.e. messages with two messages ends), it is the EADLSendDataEvent that is taken into account. In the diagram shown above, let.s consider ADLOutFlowPort and ADLInFLowPort as equivalent to SysML::Flowport. Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 29 avril 2008 05:29 À : Chonoles, Michael J Cc : sysml-rtf@omg.org Objet : RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin From: Alan Moore To: "Chonoles, Michael J" , GERARD Sebastien 166342 , "Friedenthal, Sanford" Cc: "sysml-rtf@omg.org" Date: Tue, 6 May 2008 17:06:05 +0100 Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Topic: Proposed resolution for 11117 - adding data flow to sequence diagrams Thread-Index: AciJQyEWtWFaNdDBQka1x5yxxJEq9gEdpEigAVon9qAAz3uy0ANezcpwACkpeKAA6KbVUAA+PahQAACIRPAAAFUzcAAAhV4AACF70uAAABnwIAAAVGSQAAhiZUAAm/wAkAAOWYsQALV0IQA= Accept-Language: en-US, en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Hi Michael, I don.t think that simply extending the enumeration is sufficient. What are you going to use as Events on the Message Ends of the Message? Alan. -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Friday, May 02, 2008 6:05 PM To: Alan Moore; GERARD Sebastien 166342; Friedenthal, Sanford Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams In my, more simplistic proposal, of just adding an enumeration literal, to MessagSort, I wish not distinguishes between push/pull. I.m interested in being able to show a non-implementation sending of discrete data from one life-line to another. Sebastian.s proposed notation -- that of a dashed line with the arrow in the middle is certainly fine, and may be more attractive than mine. Michael -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Friday, May 02, 2008 6:09 AM To: GERARD Sebastien 166342; Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hello Seb, I have a couple of concerns about your proposal. Firstly, «ADLDataEvent» extends Event which is abstract, and can.t have instances. So presumably, instances of «ADLSendDataEvent» and «ADLReceiveDataEvent», must extend instances of some concrete subclass of Event. Do you not care which? Or are you implicitly choosing SendSignalEvent and ReceiveSignalEvent (or something else)? Secondly, this proposal seems to deal with a push model of data flow, but what about a pull model? Cheers, Alan. -------------------------------------------------------------------------------- From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Tuesday, April 29, 2008 8:30 AM To: Friedenthal, Sanford; Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Hi guys, I had the same requireent to be able to use sequence diagram in the case of data flow. In one project, I did the following proposal (may be useful for SysML): We need to extend the message concept as defined within the chapter Interactions of the UML2 specification in order to enable UML2 interaction to support data-based communication. As shown in Figure 8, we then define the stereotype «ADLDataMessage». This latter owns a property, value, which models the data value conveyed by the message. The type of this property is a UML OpaqueExpression. An opaque expression consists of a set of body description described in some given language defining how to interpret each text string contained in the bodies. For our purpose, it is expected that users will use the Value Specification Language (VSL inshort) defined in the Marte specification to describe the value conveyed by a message. But the user is also free to adopt any kind of other language, such Java or C++ for example, or even natural language. Figure 9. UML profile diagram for EAST-ADL2 data-based message In UML2, a message owns generally two message ends: one refers to the event occurrence related to the posting of the message, whilst the other refers to the event occurrence related to the receipt of the message. Currently, due its initial intend, the UML2 interactions chapter defines only specific events dedicated to either operation-based message or signal-based message. For our concern, i.e. enabling data-based communication within UML2.s interactions, we will then need to also extend the concept of UML2.s Event as defined in the package UML::CommonBehaviors::Communications. Figure 10 denotes the proposed extensions we defined for that concern. It consists in extending the Event concept of UML2 by introducing an abstract stereotype, «ADLDataEvent» and to reify this latter in order to introduce both concepts of event related to posting and reception of data. Figure 10. UML profile diagram for EAST-ADL2 data event Firstly, we define an abstract stereotype «EADLDataEvent» and we generalize this latter into both stereotypes, «EADLSendDataEvent» and «EADLReceiveDataEvent». Both stereotype references a SysML ItemFlow which is used to denote the data that may be conveyed through the message. Finally, on the notation point of view, we propose to introduce a new representation of message in order to distinguish clearly data-based communication from signal-based and operation-based communications. A data-based message will then be represented as a line with a hollow triangle as an arrowhead (see next example). The name of the message will consist of the text string contained in the body of data referenced by one of the end event (either EADLSendDataEvent or EADLReceiveDataEvent). In case of complete messages (i.e. messages with two messages ends), it is the EADLSendDataEvent that is taken into account. In the diagram shown above, let.s consider ADLOutFlowPort and ADLInFLowPort as equivalent to SysML::Flowport. Cheers, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment -------------------------------------------------------------------------------- De : Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Envoyé : mardi 29 avril 2008 05:29 À : Chonoles, Michael J Cc : sysml-rtf@omg.org Objet : RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael My issue is that this is inconsistent with the semantics of interactions as I said below and I think this is a bad precedent. My suggestion is to use messages to carry data as they are intended (e.g. as arguments of the call operation). We clearly can use activity diagrams as an alternative which represents the data flow quite well. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 11:25 PM To: Friedenthal, Sanford Cc: 'sysml-rtf@omg.org' Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams If you think this is insufficient, of course, you.re welcome to suggest fixes. However as we have discussed, messages and calls can carry data, but they require specific mechanisms (interfaces, operations, return values.) When a model indicates that there is a data flow between two blocks from flow port to flow port there is not way of indicating that this flow occurs on a sequence diagram without specifying one of those mechanisms. I proposed using this approach in LMCO recently and you seemed to not have complained (though you may not have noticed). By introducing flows into SysML, we.re obligated to make them work consistently in the all the diagrams Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 11:16 PM To: Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Proposed resolution for 11117 - adding data flow to sequence diagrams Michael I think this is a bad idea to deviate from the semantics of interactions. This has no tie in with the actual underlying metamodel and would cause a great deal of confusion. I do think there are mechanisms for using messages that include data emabeeded in the signal or call operation, but not directly as data flow. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 7:06 AM To: Friedenthal, Sanford Subject: RE: Proposed resolution for 11117 No, this is the notation recently introduced in Rhapsody, but it makes sense to extend the sequence diagrams messaging capabilities to indicate data exchange. This relates to the issue we had last week . how do we indicate data or material flow (across flow ports) in a sequence diagram without indicating a specific implementation. This allows the sequence diagram to capture the flows from sequence diagram and the flows on activity diagrams. As far as the particular notation, we use the information flow (data flow) from UML (SysML) arrow head to tie the flow to the activity diagram notation. Michael -------------------------------------------------------------------------------- From: Friedenthal, Sanford Sent: Monday, April 28, 2008 6:52 AM To: Chonoles, Michael J Subject: RE: Proposed resolution for 11117 Michael Is this a standard UML notation? What type of message is this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Chonoles, Michael J Sent: Monday, April 28, 2008 6:39 AM To: sysml-rtf@omg.org Subject: Proposed resolution for 11117 Disposition: Proposed Resolved OMG Issue No: 11117 Title: Flow of data in sequence diagrams Source: Telelogic AB (Mr. Eldad Palachi, eldad.palachiATtelelogic.com) Summary: I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario. Resolution: The submitter is correct. Lacking the ability to describe the flow of data makes SysML models incomplete and diagrams potentially inconsistent Revised Text: At the end of Table 12.1 add row indicating the following Data Message SysML::Interactions ::MessageSort (Notation is dashed line utilizing the same arrowhead that the flow in block diagrams use) In Section 12.3.1 Diagram Extensions add new paragraph 12.3.1.2 .12.3.1.2 Data Messages Exchange of data may be shown by a dashed arrow using a arrowhead identical to that used by Block diagrams to indicate flow. Create a new Section 12.3.2 .12.3.2 Stereotypes SysML adds to the MessageSort enumeration the value dataflow indicating that the message was generated by a data flow. Michael Jesse Chonoles Lockheed Martin Date: Wed, 07 May 2008 16:43:36 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Alan Moore , sysml-rtf@omg.org Subject: Re: Proposed resolution for 11117 - adding data flow to sequence diagrams X-Virus-Scanned: ClamAV 0.91.2/7046/Wed May 7 10:35:44 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_PBL,RDNS_NONE,USER_IN_WHITELIST autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.nomagicasia.com Alan Moore wrote: Secondly, this proposal seems to deal with a push model of data flow, but what about a pull model? Exactly what I had wondered. I am very interested in 11117, very worthy aim. BTW I want to be able to "drag n drop" data types or "instance-like" packets onto messages, like one currently can in MD SysML for ItemFlow (and itemProperty) on Association and Connector. Darren -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple !