Issue 12222: 09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port (sysml-rtf) Source: No Magic, Inc. (Dr. Darren R.C. Kelly, nobody) Nature: Enhancement Severity: Significant Summary: Experience modelling a wide range of heterogeneous systems has proven that the representation of logical channels as information flows across connections between flowports nested within standard ports is a very useful idiom. It would help if this possibility is explicitly stated in both 9.3.2.3 FlowPort, 9.3.2.7 Standard Port, and illustrated in specification figures. Example: a software application acquires encoded signals representing physical positon and rotation via a high-level software API to a low-level A./D card in a computer. The software application is connected to an A/D module subject to a contract represented by an Interface provided by a standard port (subject ot a protocol). The flow of information corresponding to logical acquired channels can be well represented as flowports nested within the standard port of the A/D module. This example is illustrated in detail at: http://school.nomagic.com/node/194 It is marked as 'significant' because without this idiom of nesting flowports on standard ports it is impossible or very difficult to model a wide range or real-world systems. Resolution: Revised Text: Actions taken: February 14, 2008: received issue Discussion: Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 14 Feb 2008 05:12:21 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Darren Kelly Company: No Magic mailFrom: drdarrenkelly@nomagicasia.com Notification: Yes Specification: SysML1.0 Section: 09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port: formally permit useful idiom of flowport nested within standard port to represent information flow FormalNumber: formal/2007-09-01 Version: 1.0 RevisionDate: 09/01/2007 Page: p.59+ Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1) Gecko/20061023 SUSE/2.0-30 Firefox/2.0 Description Experience modelling a wide range of heterogeneous systems has proven that the representation of logical channels as information flows across connections between flowports nested within standard ports is a very useful idiom. It would help if this possibility is explicitly stated in both 9.3.2.3 FlowPort, 9.3.2.7 Standard Port, and illustrated in specification figures. Example: a software application acquires encoded signals representing physical positon and rotation via a high-level software API to a low-level A./D card in a computer. The software application is connected to an A/D module subject to a contract represented by an Interface provided by a standard port (subject ot a protocol). The flow of information corresponding to logical acquired channels can be well represented as flowports nested within the standard port of the A/D module. This example is illustrated in detail at: http://school.nomagic.com/node/194 It is marked as 'significant' because without this idiom of nesting flowports on standard ports it is impossible or very difficult to model a wide range or real-world systems. X-SoftScan-Status: clean Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Wed, 7 May 2008 11:44:08 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gADs9ZgAAHeKq0A== From: "Eldad Palachi" To: "Tim Weilkiens" , "Burkhart Roger M" , Tim . It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You CAN type a port by a classifier that owns ports . but this does not mean nested ports. For flow ports it means that an instance of this classifier is related (if the classifier is a Block) and for service ports it means that it is a complex port with the behavior based on the classifier. The whole nesting of connectors on the latter case is not well defined (to the best of my knowledge) and I am certainly not aware of a notation to interpret this situation as nesting of ports. Eldad -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 06, 2008 10:27 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I don't agree with the resolution closed, no change. The discussion section says thst nested ports are not allowed in SysML and UML without referring to a constraint in the specification. I can't find that it is forbidden to type a port with a Classifier that owns ports. We evaluate the ability to use SysML for a complex system in the INCOSE MBSE Challenge Team SE^2. Our system is a part of a telescope. One of our result is that nested ports are a very powerful and useful feature. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 5:13 PM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4. Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Wed, 7 May 2008 11:57:55 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gADs9ZgAAHeKq0AAAcyxg From: "ESPINOZA Huascar 218344" To: "Eldad Palachi" , "Tim Weilkiens" , "Burkhart Roger M" , X-OriginalArrivalTime: 07 May 2008 09:57:56.0387 (UTC) FILETIME=[D2EB3730:01C8B028] Eldad, Tim, I was just reading resolution 12222. I tend to agree with Tim. The term .nested. to refer to Parts TYPED by a classifier containing other parts (which is not a full composition, and it seems the point of disagreement of Eldad) is already used in UML and SysML. So, the use of the term .nested. for Ports, typed by a given classifier containing Parts (or Ports?) could be used for adopting what the issue requests. Note that this would be only a notation convention, the metamodel already supports it. You will not need modifications or extensions to UML. Regards, Huascar -------------------------------------------------------------------------------- De : Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Envoyé : mercredi 7 mai 2008 11:44 À : Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Objet : RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Tim . It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You CAN type a port by a classifier that owns ports . but this does not mean nested ports. For flow ports it means that an instance of this classifier is related (if the classifier is a Block) and for service ports it means that it is a complex port with the behavior based on the classifier. The whole nesting of connectors on the latter case is not well defined (to the best of my knowledge) and I am certainly not aware of a notation to interpret this situation as nesting of ports. Eldad -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 06, 2008 10:27 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I don't agree with the resolution closed, no change. The discussion section says thst nested ports are not allowed in SysML and UML without referring to a constraint in the specification. I can't find that it is forbidden to type a port with a Classifier that owns ports. We evaluate the ability to use SysML for a complex system in the INCOSE MBSE Challenge Team SE^2. Our system is a part of a telescope. One of our result is that nested ports are a very powerful and useful feature. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 5:13 PM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4. Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Date: Wed, 07 May 2008 06:54:53 -0400 From: "Friedenthal, Sanford" Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) To: ESPINOZA Huascar 218344 , Eldad Palachi , Tim Weilkiens , Burkhart Roger M , sysml-rtf@omg.org Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gADs9ZgAAHeKq0AAAcyxgAAIYI0A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 May 2008 10:54:53.0447 (UTC) FILETIME=[C7A53170:01C8B030] Eldad, Tim, Huascar When having this discussion, please determine how the composite connector fits into this. Refer to the usage example of a faucet and spigot bank ini the blocks chapter in 8.4.4. The concept of nested ports should also be supported by the composite connector. I understand that to be part of th eoriginal intent. When you nested a port, you would also 'decompose' the connector to connect them. Any thoughts on this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Sent: Wednesday, May 07, 2008 5:58 AM To: Eldad Palachi; Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Eldad, Tim, I was just reading resolution 12222. I tend to agree with Tim. The term .nested. to refer to Parts TYPED by a classifier containing other parts (which is not a full composition, and it seems the point of disagreement of Eldad) is already used in UML and SysML. So, the use of the term .nested. for Ports, typed by a given classifier containing Parts (or Ports?) could be used for adopting what the issue requests. Note that this would be only a notation convention, the metamodel already supports it. You will not need modifications or extensions to UML. Regards, Huascar -------------------------------------------------------------------------------- De : Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Envoyé : mercredi 7 mai 2008 11:44 À : Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Objet : RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Tim . It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You CAN type a port by a classifier that owns ports . but this does not mean nested ports. For flow ports it means that an instance of this classifier is related (if the classifier is a Block) and for service ports it means that it is a complex port with the behavior based on the classifier. The whole nesting of connectors on the latter case is not well defined (to the best of my knowledge) and I am certainly not aware of a notation to interpret this situation as nesting of ports. Eldad -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 06, 2008 10:27 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I don't agree with the resolution closed, no change. The discussion section says thst nested ports are not allowed in SysML and UML without referring to a constraint in the specification. I can't find that it is forbidden to type a port with a Classifier that owns ports. We evaluate the ability to use SysML for a complex system in the INCOSE MBSE Challenge Team SE^2. Our system is a part of a telescope. One of our result is that nested ports are a very powerful and useful feature. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 5:13 PM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4. Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Subject: AW: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Thu, 8 May 2008 07:58:33 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gADs9ZgAAHeKq0AAAcyxgACouUks= From: "Tim Weilkiens" To: "ESPINOZA Huascar 218344" , "Eldad Palachi" , "Burkhart Roger M" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m4861MPQ025373 I compare the ports with parts. They are similar. Both are structural features of a classifier. If the type of a part has ports they are shown in the ibd. Why not showing ports of the type of a port in the diagram? Tim ________________________________ Von: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Gesendet: Mi 07.05.2008 11:57 An: Eldad Palachi; Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Betreff: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Eldad, Tim, I was just reading resolution 12222. I tend to agree with Tim. The term 'nested' to refer to Parts TYPED by a classifier containing other parts (which is not a full composition, and it seems the point of disagreement of Eldad) is already used in UML and SysML. So, the use of the term 'nested' for Ports, typed by a given classifier containing Parts (or Ports?) could be used for adopting what the issue requests. Note that this would be only a notation convention, the metamodel already supports it. You will not need modifications or extensions to UML. Regards, Huascar ________________________________ De : Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Envoyé : mercredi 7 mai 2008 11:44 À : Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Objet : RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Tim - It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You CAN type a port by a classifier that owns ports - but this does not mean nested ports. For flow ports it means that an instance of this classifier is related (if the classifier is a Block) and for service ports it means that it is a complex port with the behavior based on the classifier. The whole nesting of connectors on the latter case is not well defined (to the best of my knowledge) and I am certainly not aware of a notation to interpret this situation as nesting of ports. Eldad ________________________________ From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 06, 2008 10:27 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I don't agree with the resolution closed, no change. The discussion section says thst nested ports are not allowed in SysML and UML without referring to a constraint in the specification. I can't find that it is forbidden to type a port with a Classifier that owns ports. We evaluate the ability to use SysML for a complex system in the INCOSE MBSE Challenge Team SE^2. Our system is a part of a telescope. One of our result is that nested ports are a very powerful and useful feature. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de ________________________________ From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 5:13 PM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger ________________________________ From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4 . Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Subject: AW: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Thu, 8 May 2008 07:58:51 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gADs9ZgAAHeKq0AAAcyxgAAIYI0AAKBjwcA== From: "Tim Weilkiens" To: "Friedenthal, Sanford" , "ESPINOZA Huascar 218344" , "Eldad Palachi" , "Burkhart Roger M" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m4862KI4025435 Sandy, good point! I hadn't time to think about it in detail. As a first shot I would say that it is no problem. The connector is connected with the enclosing port or with a port of the port type. For the composite connector it doesn't matter whether the port is a nested one or not. Tim ________________________________ Von: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Gesendet: Mi 07.05.2008 12:54 An: ESPINOZA Huascar 218344; Eldad Palachi; Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Betreff: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Eldad, Tim, Huascar When having this discussion, please determine how the composite connector fits into this. Refer to the usage example of a faucet and spigot bank ini the blocks chapter in 8.4.4. The concept of nested ports should also be supported by the composite connector. I understand that to be part of th eoriginal intent. When you nested a port, you would also 'decompose' the connector to connect them. Any thoughts on this? Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 ________________________________ From: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Sent: Wednesday, May 07, 2008 5:58 AM To: Eldad Palachi; Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Eldad, Tim, I was just reading resolution 12222. I tend to agree with Tim. The term 'nested' to refer to Parts TYPED by a classifier containing other parts (which is not a full composition, and it seems the point of disagreement of Eldad) is already used in UML and SysML. So, the use of the term 'nested' for Ports, typed by a given classifier containing Parts (or Ports?) could be used for adopting what the issue requests. Note that this would be only a notation convention, the metamodel already supports it. You will not need modifications or extensions to UML. Regards, Huascar ________________________________ De : Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Envoyé : mercredi 7 mai 2008 11:44 À : Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Objet : RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Tim - It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You CAN type a port by a classifier that owns ports - but this does not mean nested ports. For flow ports it means that an instance of this classifier is related (if the classifier is a Block) and for service ports it means that it is a complex port with the behavior based on the classifier. The whole nesting of connectors on the latter case is not well defined (to the best of my knowledge) and I am certainly not aware of a notation to interpret this situation as nesting of ports. Eldad ________________________________ From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 06, 2008 10:27 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I don't agree with the resolution closed, no change. The discussion section says thst nested ports are not allowed in SysML and UML without referring to a constraint in the specification. I can't find that it is forbidden to type a port with a Classifier that owns ports. We evaluate the ability to use SysML for a complex system in the INCOSE MBSE Challenge Team SE^2. Our system is a part of a telescope. One of our result is that nested ports are a very powerful and useful feature. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de ________________________________ From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 5:13 PM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger ________________________________ From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4 . Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Date: Thu, 08 May 2008 05:58:35 -0400 From: "Friedenthal, Sanford" Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) To: Tim Weilkiens , ESPINOZA Huascar 218344 , Eldad Palachi , Burkhart Roger M , sysml-rtf@omg.org Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: AciutRQ+ioNzdd07R+udoIz4h0p/YwADHG4gADs9ZgAAHeKq0AAAcyxgACouUksACFogIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 May 2008 09:58:36.0332 (UTC) FILETIME=[152416C0:01C8B0F2] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m48A2PhW002625 I have always assumed showning this type of nesting of ports is perfectly acceptable. Sanford Friedenthal Lockheed Martin (703) 293-5557 -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, May 08, 2008 1:59 AM To: ESPINOZA Huascar 218344; Eldad Palachi; Burkhart Roger M; sysml-rtf@omg.org Subject: AW: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I compare the ports with parts. They are similar. Both are structural features of a classifier. If the type of a part has ports they are shown in the ibd. Why not showing ports of the type of a port in the diagram? Tim ________________________________ Von: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Gesendet: Mi 07.05.2008 11:57 An: Eldad Palachi; Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Betreff: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Eldad, Tim, I was just reading resolution 12222. I tend to agree with Tim. The term 'nested' to refer to Parts TYPED by a classifier containing other parts (which is not a full composition, and it seems the point of disagreement of Eldad) is already used in UML and SysML. So, the use of the term 'nested' for Ports, typed by a given classifier containing Parts (or Ports?) could be used for adopting what the issue requests. Note that this would be only a notation convention, the metamodel already supports it. You will not need modifications or extensions to UML. Regards, Huascar ________________________________ De : Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Envoyé : mercredi 7 mai 2008 11:44 À : Tim Weilkiens; Burkhart Roger M; sysml-rtf@omg.org Objet : RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Tim - It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You CAN type a port by a classifier that owns ports - but this does not mean nested ports. For flow ports it means that an instance of this classifier is related (if the classifier is a Block) and for service ports it means that it is a complex port with the behavior based on the classifier. The whole nesting of connectors on the latter case is not well defined (to the best of my knowledge) and I am certainly not aware of a notation to interpret this situation as nesting of ports. Eldad ________________________________ From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 06, 2008 10:27 PM To: Burkhart Roger M; sysml-rtf@omg.org Subject: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I don't agree with the resolution closed, no change. The discussion section says thst nested ports are not allowed in SysML and UML without referring to a constraint in the specification. I can't find that it is forbidden to type a port with a Classifier that owns ports. We evaluate the ability to use SysML for a complex system in the INCOSE MBSE Challenge Team SE^2. Our system is a part of a telescope. One of our result is that nested ports are a very powerful and useful feature. Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de ________________________________ From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 5:13 PM To: sysml-rtf@omg.org Subject: update of draft Ballot 4 SysML RTF-- I've posted an update to the Ballot 4 which now includes resolutions to all issues for this RTF except those in the Blocks chapter which relate to property-specific types and the defaultValue compartment, which we decided at the Washington meeting to rename to initialValues. I'm trying to get all those issues resolved as a block, since they all relate to each other in one way or another. I expect to have those final resolutions posted by the end of today, at which time I expect no further resolutions for the draft ballot 4 currently under discussion. In the meantime, the current draft ballot has 14 additional proposed resolutions, in the Blocks, Constraint Blocks, and General sections. The table on the ballot page includes the numbers and titles of all the issues in the draft ballot, organized by chapter. --Roger ________________________________ From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, May 05, 2008 8:37 AM To: sysml-rtf@omg.org Subject: draft Ballot 4 available for discussion through May 10, 2008 I thought I had sent the message below last night, but for some reason it was stuck in my outbox, so I'm resending. More updates shortly ... SysML RTF-- An initial draft Ballot 4 is now available for review and discussion on the SysML RTF wiki at http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf:ballot4 . Ballot 4 will be open for discussion through May 10, 2008. Voting is scheduled to begin Sunday, May 11 so that voting can be completed by the RTF report deadline of Monday, May 26. This current draft ballot includes 54 proposed resolutions including issues which are being deferred because no resolution was reached by the RTF. Deferred resolutions are not included for issues received by OMG later than the January 1, 2008 RTF Issue, since OMG will automatically defer these issues to the next RTF. I expect to include some additional draft resolutions for the Blocks and Constraint Blocks chapters, and one in the General category, later on Monday, May 5. Otherwise, this draft ballot covers the entire set of current issues against the SysML 1.0 spec. Because of the large number of issues, please try to begin reviewing these draft proposals and raise any questions and concerns while there is still at least some time for discussion. Because of the shortened time for this last discussion period, if major questions arise about any proposed resolution we can consider changing the resolution to "Deferred" so that further discussion can continue to occur in the next RTF. Thanks to everyone who contributed draft resolutions to this ballot. --Roger Date: Sat, 10 May 2008 18:40:17 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Eldad Palachi , sysml-rtf@omg.org, Tim Weilkiens Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7082/Sat May 10 10:33:49 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-97.9 required=5.0 tests=AWL,BAYES_50, HTML_IMAGE_RATIO_02,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 Hi Eldad, Nested ports work, both for UML2.1.2 and SysML.10 with no change to the metamodel, at all. And you can't possibly seriously do systems engineering without nested ports for a huge range of real-world problems. They are also much easier to use than FlowSpecification for many situations. Eldad Palachi wrote: Tim . It is not a matter of a constraint. The meta relationship for port to be nested in another port simply does not exist in UML (and SysML). You don't need a metarelationship for it. A Port extends Property; that's it. A Property has a Type. If the Type of that Property is a Block with a Port then it nests; that's it. All that is required is a few diagrams of nested ports in the SysML spec to demonstrate the notation. The following works already in MD SysML (I was one of the MagicDraw customers who wanted it already many years ago, when I was was misappropriating UML2 for modelling of signal processing in scientific instruments like radiotelescopes): Eldad wrote: You CAN type a port by a classifier that owns ports . but this does not mean nested ports ... Yes it does. The Universe nests systems. It is basic holon theory: http://en.wikipedia.org/wiki/Holon_(philosophy) Ports are just one way of nesting systems. (A Port is part-like.) Visit also: http://school.nomagicasia.com/nested_flowports_as_logical_channels HOWTO use nested flowports within standard ports to model logical channels 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 ! Date: Sat, 10 May 2008 19:04:04 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Eldad Palachi , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7082/Sat May 10 10:33:49 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-97.2 required=5.0 tests=AWL,BAYES_50, HTML_IMAGE_ONLY_32,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 No Magic definitely votes "no" to closing this issue without change. This is one of the most important idioms in all of engineering and science. It needs to be explicitly demonstrated through illustration in the SysML spec. and I am will to supply those illustrations. The issue should be deferred and I will provide a new resolution. The proposed resolution states: It is not possible in SysML and UML to have nested ports (or any property within a property). I assert it is. Because "nesting" is merely a matter of interpretation. It has nothing, at all, to do with the metamodel per se. Mentioning it and showing it in the example is wrong. I assert it is most useful, and certainly not "wrong". Nature does it; engineers do it; and SysML should to it too. UML permits it in the metamodel (it just does not show notational examples). Tools need do nothing to change their repository. They just draw what is there nested. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. You don't need a 'Property within a Property' ! Now that is indeed "wrong". A Port is a Property. A Property is TypedElement. If the TypedElement.type has a Port then it "nests". -- 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 ! Date: Sat, 10 May 2008 19:17:57 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: "Friedenthal, Sanford" , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7082/Sat May 10 10:33:49 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.0 required=5.0 tests=AWL,BAYES_40, HTML_IMAGE_RATIO_02,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 Hi Sandy, Friedenthal, Sanford wrote: Eldad, Tim, Huascar When having this discussion, please determine how the composite connector fits into this. Refer to the usage example of a faucet and spigot bank ini the blocks chapter in 8.4.4. The concept of nested ports should also be supported by the composite connector. I understand that to be part of th eoriginal intent. When you nested a port, you would also 'decompose' the connector to connect them. Any thoughts on this? I have been using nested ports exactly to achieve much of what is achieved in SysML using strategies like FlowSpecifications, ParticipantProperty etc. for decomposition. And it works essentially out of the box. You can even have the same model shown in different diagrams: unstructured connection between the "top-level" ports. finer connections between the nested ports. See how the images below show "data channels" as flows within a Data Acquisition connection: 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 ! Date: Sat, 10 May 2008 20:35:27 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: "Friedenthal, Sanford" Cc: ESPINOZA Huascar 218344 , Eldad Palachi , Tim Weilkiens , Burkhart Roger M , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7082/Sat May 10 10:33:49 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.3 required=5.0 tests=AWL,BAYES_20, HTML_IMAGE_RATIO_02,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 Hi Sandy, Friedenthal, Sanford wrote: Eldad, Tim, Huascar When having this discussion, please determine how the composite connector fits into this. Refer to the usage example of a faucet and spigot bank ini the blocks chapter in 8.4.4. The concept of nested ports should also be supported by the composite connector. I understand that to be part of th eoriginal intent. When you nested a port, you would also 'decompose' the connector to connect them. 8.4.4 Water Delivery in MD SysML http://school.nomagic.com/node/418 Nested ports are like Christmas coming early. 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 ! Date: Sat, 10 May 2008 08:35:19 -0400 From: "Friedenthal, Sanford" Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) To: Darren R C KELLY , Eldad Palachi , sysml-rtf@omg.org Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: AciyfYwCzou56++CQ6OIAS6GXblMSQAG3f4w X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 May 2008 12:35:19.0343 (UTC) FILETIME=[4E9933F0:01C8B29A] Darren I have no issue with nesting like ports within ports. However, I do not know the semantics of a flow port nested within a standard port or a standard port nested within a flow port. This is not currently specified in the spec. We have said that you cannot bind a flow port to a standard port directly via a connector as well. The integration of standard ports and flow ports need to be better understood before I would vote for allowing this. However, I do agree that the discussion text in this proposed resolution shown below is overly restrictive and should be replaced as follows: From It is not possible in SysML and UML to have nested ports (or any property within a property). Mentioning it and showing it in the example is wrong. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. To Nesting of like ports is allowable within SysML. However, the interpretation of nesting a flow port within a standard port or nesting a standard port within a flow port is not defined at this time. The discussion text should be modified. In addition, I would not have a problem deferring this issue if Darren and others want to have further discussion on it. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Saturday, May 10, 2008 5:04 AM To: Eldad Palachi; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) No Magic definitely votes "no" to closing this issue without change. This is one of the most important idioms in all of engineering and science. It needs to be explicitly demonstrated through illustration in the SysML spec. and I am will to supply those illustrations. The issue should be deferred and I will provide a new resolution. The proposed resolution states: It is not possible in SysML and UML to have nested ports (or any property within a property). I assert it is. Because "nesting" is merely a matter of interpretation. It has nothing, at all, to do with the metamodel per se. Mentioning it and showing it in the example is wrong. I assert it is most useful, and certainly not "wrong". Nature does it; engineers do it; and SysML should to it too. UML permits it in the metamodel (it just does not show notational examples). Tools need do nothing to change their repository. They just draw what is there nested. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. You don't need a 'Property within a Property' ! Now that is indeed "wrong". A Port is a Property. A Property is TypedElement. If the TypedElement.type has a Port then it "nests". -- 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 ! Date: Sat, 10 May 2008 08:53:42 -0400 From: "Friedenthal, Sanford" Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) To: Darren R C KELLY , sysml-rtf@omg.org Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: Aciyfr/nIDxOt0D6SD+XYxnOhYsaWwAG8wVw X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 May 2008 12:53:43.0062 (UTC) FILETIME=[E0775B60:01C8B29C] Darren I do think the discussion of nesting ports should also address how they are used in conjunction with association blocks and ParticipantProperties. This capability enables the modeler to "decompose" a composite connector into subconnectors. If one decomposes a port into nested ports, then this capability also allows the connector to be decomposed in a similar way and maintain the relationship to the original composite connector. In your example, you show nested ports (e.g., c0, c1, ..) on one side of the connector, but they are not nested on the other side. If they were, this capability would apply. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Saturday, May 10, 2008 5:18 AM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Hi Sandy, Friedenthal, Sanford wrote: Eldad, Tim, Huascar When having this discussion, please determine how the composite connector fits into this. Refer to the usage example of a faucet and spigot bank ini the blocks chapter in 8.4.4. The concept of nested ports should also be supported by the composite connector. I understand that to be part of th eoriginal intent. When you nested a port, you would also 'decompose' the connector to connect them. Any thoughts on this? I have been using nested ports exactly to achieve much of what is achieved in SysML using strategies like FlowSpecifications, ParticipantProperty etc. for decomposition. And it works essentially out of the box. You can even have the same model shown in different diagrams: unstructured connection between the "top-level" ports. finer connections between the nested ports. See how the images below show "data channels" as flows within a Data Acquisition connection: 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 ! Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Sat, 10 May 2008 21:20:29 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: AciyfYwCzou56++CQ6OIAS6GXblMSQAG3f4wAA4l0uA= From: "Tim Weilkiens" To: "Friedenthal, Sanford" , "Darren R C KELLY" , "Eldad Palachi" , Sandy, I agree to change the discussion text like you proposed. The disposition should be changed to defer. For SysML users: That means it is allowed to work with nested flow ports and (s)he has the outlook that the semantics are better defined in future versions of SysML. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Saturday, May 10, 2008 2:35 PM To: Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Darren I have no issue with nesting like ports within ports. However, I do not know the semantics of a flow port nested within a standard port or a standard port nested within a flow port. This is not currently specified in the spec. We have said that you cannot bind a flow port to a standard port directly via a connector as well. The integration of standard ports and flow ports need to be better understood before I would vote for allowing this. However, I do agree that the discussion text in this proposed resolution shown below is overly restrictive and should be replaced as follows: From It is not possible in SysML and UML to have nested ports (or any property within a property). Mentioning it and showing it in the example is wrong. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. To Nesting of like ports is allowable within SysML. However, the interpretation of nesting a flow port within a standard port or nesting a standard port within a flow port is not defined at this time. The discussion text should be modified. In addition, I would not have a problem deferring this issue if Darren and others want to have further discussion on it. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Saturday, May 10, 2008 5:04 AM To: Eldad Palachi; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) No Magic definitely votes "no" to closing this issue without change. This is one of the most important idioms in all of engineering and science. It needs to be explicitly demonstrated through illustration in the SysML spec. and I am will to supply those illustrations. The issue should be deferred and I will provide a new resolution. The proposed resolution states: It is not possible in SysML and UML to have nested ports (or any property within a property). I assert it is. Because "nesting" is merely a matter of interpretation. It has nothing, at all, to do with the metamodel per se. Mentioning it and showing it in the example is wrong. I assert it is most useful, and certainly not "wrong". Nature does it; engineers do it; and SysML should to it too. UML permits it in the metamodel (it just does not show notational examples). Tools need do nothing to change their repository. They just draw what is there nested. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. You don't need a 'Property within a Property' ! Now that is indeed "wrong". A Port is a Property. A Property is TypedElement. If the TypedElement.type has a Port then it "nests". -- 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 ! X-SoftScan-Status: clean Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Sun, 11 May 2008 09:30:38 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: AciyfYwCzou56++CQ6OIAS6GXblMSQAG3f4wAA4l0uAAAIsOMAAAyZegABbr95A= Priority: Urgent From: "Eldad Palachi" To: "Tim Weilkiens" , "Burkhart Roger M" , "Friedenthal, Sanford" , "Darren R C KELLY" , Cc: "Eran Gery" I STRONGLY object to the statement .Nesting of like ports is allowable within SysML.. THERE IS NO NESTING OF PORTS AND OF COURSE IT IS A META-MODEL ISSUE!!! Let.s start with the simple case . flow port. A flow port can be typed by a data type, value type, block or flow specification. If you type a flow port by a block it means that the port relays an instance of the block and the fact that this block may or may not have ports is irrelevant. If you type a flow port by a flow specification, then you should remember that a flow specification is a stereotype of an interface and interfaces cannot own ports since they are not encapsulated classifiers (see section 9.3.8 in UML 2.1.1 superstructure). So there is no way for flow ports to have nested ports in SysML! For service ports, the port is typed by a classifier that may or may not have ports but the interaction is fully characterized by the set of provided and required interfaces (see section 9.3.11 in UML which states: .The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port with respect to the data communicated at this port and the behaviors that may be invoked through this port..). The way the provided and required interfaces are derived is described in section 7.3.24 in UML: .The set of interfaces realized by a classifier are its provided interfaces, which represent the obligations that instances of that classifier have to their clients. They describe the services that the instances of that classifier offer to their clients. Interfaces may also be used to specify required interfaces, which are specified by a usage dependency between the classifier and the corresponding interfaces. Required interfaces specify services that a classifier needs in order to perform its function and fulfill its own obligations to its clients.. So the fact that a classifier that types a port has its own ports is meaningless to the interaction at the port since it does not affect the provided and required interfaces of the port and there are no rules or any mentioning what so ever to such nesting. The .free interpretation. proposed below might be very useful to end users of a specific tool but from the UML and SysML standard point of view this is simply wrong. Remember that some tools (like Rhapsody) actually produce execution code based on these specifications and this is not just a matter of drawing or notation, it is definitely a matter of semantics and meta-modeling. Bottom line: I don.t object for the issue to be deferred or to the principle that some users may want to have nested ports, but I strongly object to the statement that SysML\UML support nested ports since this is a false and misleading statement! Tools that do it are deviating from the UML and SysML standards. Eldad -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Saturday, May 10, 2008 10:50 PM To: Burkhart Roger M; Friedenthal, Sanford; Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Sorry, I missed that. There are too many discussions going on at the moment Thanks, Tim -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Saturday, May 10, 2008 9:29 PM To: Tim Weilkiens; Friedenthal, Sanford; Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Please note that in my message yesterday I already included this issue in the list of those to be changed to Deferred, because active discussion is still underway now that we've reached the point where all resolutions for Ballot 4 have to be frozen for voting. (See my 2008-05-09 message with subject line "Ballot 4 issue deferral plans".) --Roger -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Saturday, May 10, 2008 2:20 PM To: Friedenthal, Sanford; Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Sandy, I agree to change the discussion text like you proposed. The disposition should be changed to defer. For SysML users: That means it is allowed to work with nested flow ports and (s)he has the outlook that the semantics are better defined in future versions of SysML. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Saturday, May 10, 2008 2:35 PM To: Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Darren I have no issue with nesting like ports within ports. However, I do not know the semantics of a flow port nested within a standard port or a standard port nested within a flow port. This is not currently specified in the spec. We have said that you cannot bind a flow port to a standard port directly via a connector as well. The integration of standard ports and flow ports need to be better understood before I would vote for allowing this. However, I do agree that the discussion text in this proposed resolution shown below is overly restrictive and should be replaced as follows: From It is not possible in SysML and UML to have nested ports (or any property within a property). Mentioning it and showing it in the example is wrong. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. To Nesting of like ports is allowable within SysML. However, the interpretation of nesting a flow port within a standard port or nesting a standard port within a flow port is not defined at this time. The discussion text should be modified. In addition, I would not have a problem deferring this issue if Darren and others want to have further discussion on it. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Saturday, May 10, 2008 5:04 AM To: Eldad Palachi; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) No Magic definitely votes "no" to closing this issue without change. This is one of the most important idioms in all of engineering and science. It needs to be explicitly demonstrated through illustration in the SysML spec. and I am will to supply those illustrations. The issue should be deferred and I will provide a new resolution. The proposed resolution states: It is not possible in SysML and UML to have nested ports (or any property within a property). I assert it is. Because "nesting" is merely a matter of interpretation. It has nothing, at all, to do with the metamodel per se. Mentioning it and showing it in the example is wrong. I assert it is most useful, and certainly not "wrong". Nature does it; engineers do it; and SysML should to it too. UML permits it in the metamodel (it just does not show notational examples). Tools need do nothing to change their repository. They just draw what is there nested. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. You don't need a 'Property within a Property' ! Now that is indeed "wrong". A Port is a Property. A Property is TypedElement. If the TypedElement.type has a Port then it "nests". -- 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 ! Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Sun, 11 May 2008 11:11:25 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: AciyfYwCzou56++CQ6OIAS6GXblMSQAG3f4wAA4l0uAAAIsOMAAAyZegABbr95AABC8QAA== From: "ESPINOZA Huascar 218344" To: "Eldad Palachi" , "Tim Weilkiens" , "Burkhart Roger M" , "Friedenthal, Sanford" , "Darren R C KELLY" , Cc: "Eran Gery" X-OriginalArrivalTime: 11 May 2008 09:11:25.0925 (UTC) FILETIME=[FD538150:01C8B346] Hi Eldad, As Darren said, I guess that.s a matter of interpretation or additional semantics (not provided in UML) but the matamodel seems to not require further modifications/extensions. When building nested ports, you shouldn.t use Interfaces to type .composite ports., just other classifier. In this case the classifier would act as a Port type. This port type would contain other ports, which could be susceptible of being represented as .nested. ports. The word nested, which is generally used in UML to describe .ownedElements. (see the various meta-attributes called nestedXXXX in the UML spec), is different than the usage in SysML for Parts, to describe levels of typing/properties. While the first case is related to a meta relationship, the second one is built at M1 level. The question of the semantics of nested ports, and how the Interfaces of the .port type. should manage/forward the requests along nested ports, should be discussed. Cheers, Huascar -------------------------------------------------------------------------------- De : Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Envoyé : dimanche 11 mai 2008 09:31 À : Tim Weilkiens; Burkhart Roger M; Friedenthal, Sanford; Darren R C KELLY; sysml-rtf@omg.org Cc : Eran Gery Objet : RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Importance : Haute I STRONGLY object to the statement .Nesting of like ports is allowable within SysML.. THERE IS NO NESTING OF PORTS AND OF COURSE IT IS A META-MODEL ISSUE!!! Let.s start with the simple case . flow port. A flow port can be typed by a data type, value type, block or flow specification. If you type a flow port by a block it means that the port relays an instance of the block and the fact that this block may or may not have ports is irrelevant. If you type a flow port by a flow specification, then you should remember that a flow specification is a stereotype of an interface and interfaces cannot own ports since they are not encapsulated classifiers (see section 9.3.8 in UML 2.1.1 superstructure). So there is no way for flow ports to have nested ports in SysML! For service ports, the port is typed by a classifier that may or may not have ports but the interaction is fully characterized by the set of provided and required interfaces (see section 9.3.11 in UML which states: .The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port with respect to the data communicated at this port and the behaviors that may be invoked through this port..). The way the provided and required interfaces are derived is described in section 7.3.24 in UML: .The set of interfaces realized by a classifier are its provided interfaces, which represent the obligations that instances of that classifier have to their clients. They describe the services that the instances of that classifier offer to their clients. Interfaces may also be used to specify required interfaces, which are specified by a usage dependency between the classifier and the corresponding interfaces. Required interfaces specify services that a classifier needs in order to perform its function and fulfill its own obligations to its clients.. So the fact that a classifier that types a port has its own ports is meaningless to the interaction at the port since it does not affect the provided and required interfaces of the port and there are no rules or any mentioning what so ever to such nesting. The .free interpretation. proposed below might be very useful to end users of a specific tool but from the UML and SysML standard point of view this is simply wrong. Remember that some tools (like Rhapsody) actually produce execution code based on these specifications and this is not just a matter of drawing or notation, it is definitely a matter of semantics and meta-modeling. Bottom line: I don.t object for the issue to be deferred or to the principle that some users may want to have nested ports, but I strongly object to the statement that SysML\UML support nested ports since this is a false and misleading statement! Tools that do it are deviating from the UML and SysML standards. Eldad -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Saturday, May 10, 2008 10:50 PM To: Burkhart Roger M; Friedenthal, Sanford; Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Sorry, I missed that. There are too many discussions going on at the moment Thanks, Tim -------------------------------------------------------------------------------- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Saturday, May 10, 2008 9:29 PM To: Tim Weilkiens; Friedenthal, Sanford; Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Please note that in my message yesterday I already included this issue in the list of those to be changed to Deferred, because active discussion is still underway now that we've reached the point where all resolutions for Ballot 4 have to be frozen for voting. (See my 2008-05-09 message with subject line "Ballot 4 issue deferral plans".) --Roger -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Saturday, May 10, 2008 2:20 PM To: Friedenthal, Sanford; Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Sandy, I agree to change the discussion text like you proposed. The disposition should be changed to defer. For SysML users: That means it is allowed to work with nested flow ports and (s)he has the outlook that the semantics are better defined in future versions of SysML. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Saturday, May 10, 2008 2:35 PM To: Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Darren I have no issue with nesting like ports within ports. However, I do not know the semantics of a flow port nested within a standard port or a standard port nested within a flow port. This is not currently specified in the spec. We have said that you cannot bind a flow port to a standard port directly via a connector as well. The integration of standard ports and flow ports need to be better understood before I would vote for allowing this. However, I do agree that the discussion text in this proposed resolution shown below is overly restrictive and should be replaced as follows: From It is not possible in SysML and UML to have nested ports (or any property within a property). Mentioning it and showing it in the example is wrong. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. To Nesting of like ports is allowable within SysML. However, the interpretation of nesting a flow port within a standard port or nesting a standard port within a flow port is not defined at this time. The discussion text should be modified. In addition, I would not have a problem deferring this issue if Darren and others want to have further discussion on it. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Saturday, May 10, 2008 5:04 AM To: Eldad Palachi; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) No Magic definitely votes "no" to closing this issue without change. This is one of the most important idioms in all of engineering and science. It needs to be explicitly demonstrated through illustration in the SysML spec. and I am will to supply those illustrations. The issue should be deferred and I will provide a new resolution. The proposed resolution states: It is not possible in SysML and UML to have nested ports (or any property within a property). I assert it is. Because "nesting" is merely a matter of interpretation. It has nothing, at all, to do with the metamodel per se. Mentioning it and showing it in the example is wrong. I assert it is most useful, and certainly not "wrong". Nature does it; engineers do it; and SysML should to it too. UML permits it in the metamodel (it just does not show notational examples). Tools need do nothing to change their repository. They just draw what is there nested. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. You don't need a 'Property within a Property' ! Now that is indeed "wrong". A Port is a Property. A Property is TypedElement. If the TypedElement.type has a Port then it "nests". -- 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 ! Date: Tue, 13 May 2008 01:11:55 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: "Friedenthal, Sanford" , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7102/Mon May 12 20:06:15 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.2 required=5.0 tests=AWL,BAYES_40,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 Friedenthal, Sanford wrote: Darren I do think the discussion of nesting ports should also address how they are used in conjunction with association blocks and ParticipantProperties. As long as the raison d'etre of nested ports is not tied to to whether or not particpant properties etc. cover some of that territory. They are extremely useful, notationally and as a modelling and they should be part of any serious engineering system. In your example, you show nested ports (e.g., c0, c1, ..) on one side of the connector, but they are not nested on the other side That was only to show a comparison, i.e. that one need not have equal levels of nesting each side. Most examples I've shown are symmetric w.r.t. nesting levels. 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 ! Date: Tue, 13 May 2008 01:19:56 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Tim Weilkiens Cc: "Friedenthal, Sanford" , Eldad Palachi , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7102/Mon May 12 20:06:15 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-99.4 required=5.0 tests=AWL,BAYES_00,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 Sandy, Tim, Eldad, I can live well with Sandy's suggested rewriting, which I repeat: Nesting of like ports is allowable within SysML. However, the interpretation of nesting a flow port within a standard port or nesting a standard port within a flow port is not defined at this time. thanks, Darren Tim Weilkiens wrote: Sandy, I agree to change the discussion text like you proposed. The disposition should be changed to defer. For SysML users: That means it is allowed to work with nested flow ports and (s)he has the outlook that the semantics are better defined in future versions of SysML. Tim -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Saturday, May 10, 2008 2:35 PM To: Darren R C KELLY; Eldad Palachi; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Darren I have no issue with nesting like ports within ports. However, I do not know the semantics of a flow port nested within a standard port or a standard port nested within a flow port. This is not currently specified in the spec. We have said that you cannot bind a flow port to a standard port directly via a connector as well. The integration of standard ports and flow ports need to be better understood before I would vote for allowing this. However, I do agree that the discussion text in this proposed resolution shown below is overly restrictive and should be replaced as follows: From It is not possible in SysML and UML to have nested ports (or any property within a property). Mentioning it and showing it in the example is wrong. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. To Nesting of like ports is allowable within SysML. However, the interpretation of nesting a flow port within a standard port or nesting a standard port within a flow port is not defined at this time. The discussion text should be modified. In addition, I would not have a problem deferring this issue if Darren and others want to have further discussion on it. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Saturday, May 10, 2008 5:04 AM To: Eldad Palachi; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) No Magic definitely votes "no" to closing this issue without change. This is one of the most important idioms in all of engineering and science. It needs to be explicitly demonstrated through illustration in the SysML spec. and I am will to supply those illustrations. The issue should be deferred and I will provide a new resolution. The proposed resolution states: It is not possible in SysML and UML to have nested ports (or any property within a property). I assert it is. Because "nesting" is merely a matter of interpretation. It has nothing, at all, to do with the metamodel per se. Mentioning it and showing it in the example is wrong. I assert it is most useful, and certainly not "wrong". Nature does it; engineers do it; and SysML should to it too. UML permits it in the metamodel (it just does not show notational examples). Tools need do nothing to change their repository. They just draw what is there nested. If the need to have nested ports is great then an issue for the next UML version should be entered to allow property within a property. You don't need a 'Property within a Property' ! Now that is indeed "wrong". A Port is a Property. A Property is TypedElement. If the TypedElement.type has a Port then it "nests". -- 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 ! -- 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 ! X-SoftScan-Status: clean Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Mon, 12 May 2008 17:30:49 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: Aci0Q2hsMxqgigqIRu6r7zCWrkdI0QAAFRaw From: "Eldad Palachi" To: "Darren R C KELLY" , "Friedenthal, Sanford" , I disagree with the statement that nested ports are a must: it simply depends on how you interpret ports. To me ports are no more than interaction points . meaning a simple relay points that encapsulate blocks in the sense that it specifies the inputs and outputs (flows) or the .service contract. (service ports). Giving them an internal structure of their own is a huge change of concept in my opinion. Eldad -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Monday, May 12, 2008 6:12 PM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Friedenthal, Sanford wrote: Darren I do think the discussion of nesting ports should also address how they are used in conjunction with association blocks and ParticipantProperties. As long as the raison d'etre of nested ports is not tied to to whether or not particpant properties etc. cover some of that territory. They are extremely useful, notationally and as a modelling and they should be part of any serious engineering system. In your example, you show nested ports (e.g., c0, c1, ..) on one side of the connector, but they are not nested on the other side That was only to show a comparison, i.e. that one need not have equal levels of nesting each side. Most examples I've shown are symmetric w.r.t. nesting levels. 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 ! Date: Tue, 13 May 2008 01:50:53 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Eldad Palachi , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7102/Mon May 12 20:06:15 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.5 required=5.0 tests=AWL,BAYES_20,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 Hi Eldad, Eldad Palachi wrote: I STRONGLY object to the statement .Nesting of like ports is allowable within SysML.. Bottom line: I don.t object for the issue to be deferred or to the principle that some users may want to have nested ports, but I strongly object to the statement that SysML\UML support nested ports since this is a false and misleading statement! Tools that do it are deviating from the UML and SysML standards. Please send me to Azkaban prison. I am a very naughty boy. Not only do I use nested ports freely, I do it in public, and \ I even show people how to do it, and that it is a very good idea. It is a good thing to do with a UML tool and/or a SysML tool. And I use UML2 Components as wrappers, too ! I also do this to model real world machines. That run. -- 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 ! From: Alan Moore To: Eldad Palachi , Darren R C KELLY , "Friedenthal, Sanford" , "sysml-rtf@omg.org" Date: Mon, 12 May 2008 17:30:37 +0100 Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Thread-Index: Aci0Q2hsMxqgigqIRu6r7zCWrkdI0QAAFRawAAIgBiA= Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Like Eldad I am confused how flow ports can have nested ports. As Eldad said the mapping from the nested flow port notation to the SysML metamodel seems to depend on the type of the Flow Port itself having Flow Ports. To repeat Eldad.s argument (I think). The types of Flow Ports can have one of 4 metatypes: Value Type (base: Data Type) Flow Specification (base: Interface) Block (base: Class) Signal Of these only Block may have Flow Ports and the definition of Flow Port suggests that this means that the whole block instance (ports an. all) flows through the Flow Port. Given this I don.t see how in SysML you can build a model whose structure could support the nested port notation. Alan. -------------------------------------------------------------------------------- From: Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Sent: Monday, May 12, 2008 4:31 PM To: Darren R C KELLY; Friedenthal, Sanford; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I disagree with the statement that nested ports are a must: it simply depends on how you interpret ports. To me ports are no more than interaction points . meaning a simple relay points that encapsulate blocks in the sense that it specifies the inputs and outputs (flows) or the .service contract. (service ports). Giving them an internal structure of their own is a huge change of concept in my opinion. Eldad -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Monday, May 12, 2008 6:12 PM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Friedenthal, Sanford wrote: Darren I do think the discussion of nesting ports should also address how they are used in conjunction with association blocks and ParticipantProperties. As long as the raison d'etre of nested ports is not tied to to whether or not particpant properties etc. cover some of that territory. They are extremely useful, notationally and as a modelling and they should be part of any serious engineering system. In your example, you show nested ports (e.g., c0, c1, ..) on one side of the connector, but they are not nested on the other side That was only to show a comparison, i.e. that one need not have equal levels of nesting each side. Most examples I've shown are symmetric w.r.t. nesting levels. 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 ! Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Tue, 13 May 2008 19:59:26 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: Aci0Q2hsMxqgigqIRu6r7zCWrkdI0QAAFRawAAIgBiAANX/+8A== From: "Tim Weilkiens" To: "Alan Moore" , "Eldad Palachi" , "Darren R C KELLY" , "Friedenthal, Sanford" , Alan, the type of a flow port defines clearly the objects that could flow through that port. Either directly as a atomic flow port or more indirectly via a flow specification. I don't see any nested ports here. But the type of a standard port could be a type that owns for example flow ports. One of my projects uses that feature to describe an interaction point of a block that again contains several interaction points. To be more concrete the interaction point is a "service point" that provides the flow of fluids and power. I know that it is possible to mode it without using nested ports, but nested ports is most intuitive and accepted by the systems engineers. Tim -------------------------------------------------------------------------------- From: Alan Moore [mailto:Alan.Moore@mathworks.co.uk] Sent: Monday, May 12, 2008 6:31 PM To: Eldad Palachi; Darren R C KELLY; Friedenthal, Sanford; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Like Eldad I am confused how flow ports can have nested ports. As Eldad said the mapping from the nested flow port notation to the SysML metamodel seems to depend on the type of the Flow Port itself having Flow Ports. To repeat Eldad.s argument (I think). The types of Flow Ports can have one of 4 metatypes: Value Type (base: Data Type) Flow Specification (base: Interface) Block (base: Class) Signal Of these only Block may have Flow Ports and the definition of Flow Port suggests that this means that the whole block instance (ports an. all) flows through the Flow Port. Given this I don.t see how in SysML you can build a model whose structure could support the nested port notation. Alan. -------------------------------------------------------------------------------- From: Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Sent: Monday, May 12, 2008 4:31 PM To: Darren R C KELLY; Friedenthal, Sanford; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I disagree with the statement that nested ports are a must: it simply depends on how you interpret ports. To me ports are no more than interaction points . meaning a simple relay points that encapsulate blocks in the sense that it specifies the inputs and outputs (flows) or the .service contract. (service ports). Giving them an internal structure of their own is a huge change of concept in my opinion. Eldad -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Monday, May 12, 2008 6:12 PM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Friedenthal, Sanford wrote: Darren I do think the discussion of nesting ports should also address how they are used in conjunction with association blocks and ParticipantProperties. As long as the raison d'etre of nested ports is not tied to to whether or not particpant properties etc. cover some of that territory. They are extremely useful, notationally and as a modelling and they should be part of any serious engineering system. In your example, you show nested ports (e.g., c0, c1, ..) on one side of the connector, but they are not nested on the other side That was only to show a comparison, i.e. that one need not have equal levels of nesting each side. Most examples I've shown are symmetric w.r.t. nesting levels. 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 ! Date: Thu, 15 May 2008 09:51:41 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Alan Moore Cc: Eldad Palachi , "Friedenthal, Sanford" , "sysml-rtf@omg.org" Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7124/Thu May 15 04:11:00 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: Like Eldad I am confused how flow ports can have nested ports. Alan, my examples showed flow ports (used as information channels) nested within "extended/adapted/misappropratiated" standard ports. There are in fact also cases where nesting flowports is useful (one can apply them fractal-like), and I can demonstrate those elsewhere/when Darren As Eldad said the mapping from the nested flow port notation to the SysML metamodel seems to depend on the type of the Flow Port itself having Flow Ports. To repeat Eldad.s argument (I think). The types of Flow Ports can have one of 4 metatypes: Value Type (base: Data Type) Flow Specification (base: Interface) Block (base: Class) Signal Of these only Block may have Flow Ports and the definition of Flow Port suggests that this means that the whole block instance (ports an. all) flows through the Flow Port. Given this I don.t see how in SysML you can build a model whose structure could support the nested port notation. Alan. -------------------------------------------------------------------------------- From: Eldad Palachi [mailto:Eldad.Palachi@telelogic.com] Sent: Monday, May 12, 2008 4:31 PM To: Darren R C KELLY; Friedenthal, Sanford; sysml-rtf@omg.org Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) I disagree with the statement that nested ports are a must: it simply depends on how you interpret ports. To me ports are no more than interaction points . meaning a simple relay points that encapsulate blocks in the sense that it specifies the inputs and outputs (flows) or the .service contract. (service ports). Giving them an internal structure of their own is a huge change of concept in my opinion. Eldad -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Monday, May 12, 2008 6:12 PM To: Friedenthal, Sanford; sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Friedenthal, Sanford wrote: Darren I do think the discussion of nesting ports should also address how they are used in conjunction with association blocks and ParticipantProperties. As long as the raison d'etre of nested ports is not tied to to whether or not particpant properties etc. cover some of that territory. They are extremely useful, notationally and as a modelling and they should be part of any serious engineering system. In your example, you show nested ports (e.g., c0, c1, ..) on one side of the connector, but they are not nested on the other side That was only to show a comparison, i.e. that one need not have equal levels of nesting each side. Most examples I've shown are symmetric w.r.t. nesting levels. 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 ! -- 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 ! Date: Thu, 15 May 2008 10:24:18 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Tim Weilkiens Cc: Alan Moore , Eldad Palachi , "Friedenthal, Sanford" , sysml-rtf@omg.org Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7124/Thu May 15 04:11:00 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 Tim Weilkiens wrote: Alan, the type of a flow port defines clearly the objects that could flow through that port. Either directly as a atomic flow port or more indirectly via a flow specification. I don't see any nested ports here. If FlowPorts nest in FlowPorts then the information simply splits; large scale flow can be decomposed into finer scale flow, including continuous flows that are not synchronised. This enables modelling of very realistic systems. 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 ! Date: Thu, 15 May 2008 11:57:34 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Eldad Palachi Cc: Tim Weilkiens , Burkhart Roger M , "Friedenthal, Sanford" , sysml-rtf@omg.org, Eran Gery Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) X-Virus-Scanned: ClamAV 0.91.2/7124/Thu May 15 04:11:00 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 Eldad Palachi wrote: Let.s start with the simple case . flow port. A flow port can be typed by a data type, value type, block or flow specification. If you type a flow port by a block it means that the port relays an instance of the block and the fact that this block may or may not have ports is irrelevant. Except that a Port is a property (and if typed by a Block it is a special kind of part Property), so a flow packet arriving at a flowport typed by a Block with nested FlowPorts in fact is a packet with many parts. So you have just thrown away the single biggest idea in information theory and signal processing, namely that a data packet may have things inside it. Open up the packet and there are more packets. Engineers everywhere will be most grateful that you have thrown away those packets (parts). I am not so sure that your Telelogic colleagues also want to throw away those inner packets (parts). 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 ! X-SoftScan-Status: clean Subject: RE: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Date: Thu, 15 May 2008 09:09:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) thread-index: Aci2L0JFaZWPHuG+QbS6F91d5nbpfwAKvf2w From: "Eldad Palachi" To: "Darren R C KELLY" Cc: "Tim Weilkiens" , "Burkhart Roger M" , "Friedenthal, Sanford" , , "Eran Gery" Dear Dr. Kelly, Although both port and part are properties, a port is not a part, it is an interaction point. Please revisit the UML and SysML standards. I never said that the block being transmitted cannot be a composite block. Eldad -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Thursday, May 15, 2008 4:58 AM To: Eldad Palachi Cc: Tim Weilkiens; Burkhart Roger M; Friedenthal, Sanford; sysml-rtf@omg.org; Eran Gery Subject: Re: Issue 12222: flowports nested within standard ports (update of draft Ballot 4) Eldad Palachi wrote: Let.s start with the simple case . flow port. A flow port can be typed by a data type, value type, block or flow specification. If you type a flow port by a block it means that the port relays an instance of the block and the fact that this block may or may not have ports is irrelevant. Except that a Port is a property (and if typed by a Block it is a special kind of part Property), so a flow packet arriving at a flowport typed by a Block with nested FlowPorts in fact is a packet with many parts. So you have just thrown away the single biggest idea in information theory and signal processing, namely that a data packet may have things inside it. Open up the packet and there are more packets. Engineers everywhere will be most grateful that you have thrown away those packets (parts). I am not so sure that your Telelogic colleagues also want to throw away those inner packets (parts). 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 ! Date: Fri, 16 May 2008 05:38:51 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: "sysml-rtf@omg.org" Cc: Juergen Boldt Subject: Ballot4: 12222: flowports nested within standard ports X-Virus-Scanned: ClamAV 0.91.2/7130/Fri May 16 00:37:07 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-97.3 required=5.0 tests=AWL,BAYES_50, HTML_IMAGE_ONLY_24,HTML_IMAGE_RATIO_04,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 Was: Re: Nested FlowPorts: examples Juergen, do please file this now formally with 12222. Acknowledged deferred for later discussion. Example only. This best counts as: "Case: flowports nested within standard ports" rather than "Case: nested flowports (only)" because one needs a headphone jack contract. http://school.nomagic.com/node/490 Darren R C KELLY wrote: -------------------------------------------------------------------------------- Example: A HiFiFactory produces HiFis, and has a HiFi flowport that outputs manufactured HiFis. A HiFi has flowports, like o:Audio, and iPower:ElectricalEnergy. A HiFi warehouse has an input flowport for receiving HiFis (which have flowports). Therefore the output FlowPort and the input FlowPort of both HiFiFactory and HiFiWarehouse are nested flowports. In fact, one does well to "upgrade" both the output and input ports to nest within standard ports, so that they can have a protocol and act to relay independently of the type of the flowport (HiFi). More on that later. -------------------------------------------------------------------------------- -- 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 ! Date: Fri, 16 May 2008 06:20:28 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: "sysml-rtf@omg.org" Cc: Juergen Boldt Subject: Ballot4: 12222: 'flowports nested within standard ports' related discussion on Port vs part Property with SysML nested connector X-Virus-Scanned: ClamAV 0.91.2/7130/Fri May 16 00:37:07 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-97.3 required=5.0 tests=AWL,BAYES_50, HTML_IMAGE_ONLY_24,HTML_IMAGE_RATIO_04,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 Was: "nested part with nested connector is like a port" Juergen, do please also file this now formally with 12222. Acknowledged deferred for later discussion. Example only. http://school.nomagic.com/node/492 Stub email to record idea: diagram and model later. part connected across environment boundary is just like a port. SysML nested connector enables one to "cross" the environment boundary. Consider Port symbol: part of rectangle outside the environment is like public part. where rectangle crosses owner boundary is like protected part. (extra-dimension; inheriting blocks are INTO the page, so can't show protected dimension except for small box crossing boundary) (owning block is friend to port.) private part is like on inside of environment. part is a property. Can connect from outside boundary to inner "relaying" part with SysML nested connector. To the extent that the inner part has public service or data external clients can ask it to relay (to other inner parts). Can "upgrade" relaying part with nested connector to port with normal connector = "exporting" the relaying part. Still relays. It makes no difference whether part or port. SysML nested connector across boundary is like export. -- 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 !