Issue 14447: Ambiguous Block Hierarchy (sysml-rtf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Clarification Severity: Significant Summary: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. Resolution: Revised Text: Actions taken: October 4, 2009: received issue Discussion: 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: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: Subject: #14447: Ambiguous Block Hierarchy Date: Tue, 6 Oct 2009 08:22:23 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14447 -- SysML RTF issue Thread-Index: AcpF1HK+Dff4CJoYTy6RLoAOkTFwDgAdsoAw From: "BERNARD, Yves" To: X-OriginalArrivalTime: 06 Oct 2009 06:22:23.0700 (UTC) FILETIME=[5E008940:01CA464D] In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-SENDER-IP: 10.37.225.65 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208,217";a="141647339" X-SENDER-IP: 10.44.64.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208,217";a="69267626" From: "Sawyer, George A (US SSA)" To: "sysml-rtf@omg.org" Date: Tue, 6 Oct 2009 08:05:06 -0400 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpF1HK+Dff4CJoYTy6RLoAOkTFwDgAdsoAwAAvAdkA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-OriginalArrivalTime: 06 Oct 2009 12:05:07.0379 (UTC) FILETIME=[3EE8F030:01CA467D] The issue report seems to suggest that when when a previously defined block type is placed on a bdd, it should be automatically updated to show all of the composition associations in order to ensure consistency. But, maybe I'm reading too much into Sandy's issue identification. For example, if 'A' was already on a bdd and 'B' was placed on the same diagram, then should the two composition associations would automatically be populated. In different example, if 'A' was already on the diagram and 'C' was placed on the diagram, then would the bdd be automatically updated to show 'B' and the associations between it and 'A' plus the associations between 'B' and 'C'? This is good from the standpoint of ensuring developers don't inadvertantly duplicate/recreate composition associations, but it also removes lessens their control of the appropriate visualization. That is, it seems like a reasonable feature for new modelers, but potentially undesirable for more experienced modelers. George -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 2:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-WSS-ID: 0KR3E9Z-08-DM7-02 X-M-MSG: From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: Tue, 6 Oct 2009 07:20:23 -0500 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpF1HK+Dff4CJoYTy6RLoAOkTFwDgAdsoAwAAzF5NA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. X-Trusted-NM: yes From: "Nerijus Jankevicius" To: "Sawyer, George A \(US SSA\)" , Subject: Re: #14447: Ambiguous Block Hierarchy Date: Tue, 6 Oct 2009 15:41:29 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-EsetScannerBuild: 5773 I don't think automatically populated associations is a good idea. There are two equivalent ways to show the same model: When association/composition exists, but not represented in the diagram, the part/property should be visible in Class/Block compartment. If association is represented, property is displayed as role on association and should disappear from compartment. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Sawyer, George A (US SSA) To: sysml-rtf@omg.org Sent: Tuesday, October 06, 2009 3:05 PM Subject: RE: #14447: Ambiguous Block Hierarchy The issue report seems to suggest that when when a previously defined block type is placed on a bdd, it should be automatically updated to show all of the composition associations in order to ensure consistency. But, maybe I'm reading too much into Sandy's issue identification. For example, if 'A' was already on a bdd and 'B' was placed on the same diagram, then should the two composition associations would automatically be populated. In different example, if 'A' was already on the diagram and 'C' was placed on the diagram, then would the bdd be automatically updated to show 'B' and the associations between it and 'A' plus the associations between 'B' and 'C'? This is good from the standpoint of ensuring developers don't inadvertantly duplicate/recreate composition associations, but it also removes lessens their control of the appropriate visualization. That is, it seems like a reasonable feature for new modelers, but potentially undesirable for more experienced modelers. George -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 2:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: #14447: Ambiguous Block Hierarchy X-KeepSent: C485C46A:9A89425D-C2257647:0050C5AD; type=4; name=$KeepSent To: Burkhart Roger M Cc: "sysml-rtf@omg.org" , "BERNARD, Yves" X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eran Gery Date: Tue, 6 Oct 2009 16:49:48 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 06/10/2009 16:50:33 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n96EnECa020730 Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Tue, 6 Oct 2009 10:58:47 -0400 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlLIep8qLRgqARPmjDwG8gzYZnAAAI2dw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n96EvM8X022964 Eran, > Here is the problem: How do you allocate a constrain to a > property a.b1.c1? Some composition models reify the path, rather than using an ordered list. This enables them to be associaited with constraints, or used to specify the end of more than one connector. Conrad Subject: RE: #14447: Ambiguous Block Hierarchy X-KeepSent: B00465AD:FFC64F92-C2257647:0052AA31; type=4; name=$KeepSent To: "Bock, Conrad" Cc: "sysml-rtf@omg.org" X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eran Gery Date: Tue, 6 Oct 2009 17:10:01 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 06/10/2009 17:10:43 Conrad: didn't follow... are you saying it is possible in UML/SysML? How do you practically designate the property A::b1.c1.x? Where b1 is a property of A of type B, c1 property of B of type C, and x is a property of C of type integer. How would you allocate a constrain Z to A::b1.c1.x ? Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: 10/06/2009 05:01 PM Subject: RE: #14447: Ambiguous Block Hierarchy Eran, > Here is the problem: How do you allocate a constrain to a > property a.b1.c1? Some composition models reify the path, rather than using an ordered list. This enables them to be associaited with constraints, or used to specify the end of more than one connector. Conrad To: "Nerijus Jankevicius" , sysml-rtf@omg.org Subject: Re: #14447: Ambiguous Block Hierarchy X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Hans-Peter.de.Koning@esa.int Date: Tue, 6 Oct 2009 20:20:10 +0200 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 6.5.5FP1 | April 14, 2006) at 10/06/2009 20:20:14, Serialize complete at 10/06/2009 20:20:14 We encountered exactly the same problem in our ECSS (European Cooperation for Space Standardization) conceptual data model standard for the space system life cycle. We solve it by having three distinct decomposition hierarchies and keeping them in sync. A first implicit definitional decomposition with blocks and usages, which we call the definition/usage tree. This is exactly the same as a one-level deep SysML bdd or idb. A second explicit decomposition which we call the expanded occurrence tree. This tree is generated and maintained in sync with the definition/usage tree by the modelling tool. In a modelling tool's GUI it may be presented as a tree browser that is updated on the fly, similar to the package browser in many UML/SysML tools. We use it also for deeply nested connections and interface-ends. We allow for absolute and relative occurrence reference. Absolute is from system top-level, relative is w.r.t. any lower level, similar to absolute and relative filepaths under Unix or Windows. A third representation which is called the realization tree which associates a serial-numbered item with each relevant occurrence, to capture the as-built/as-operated configuration of a system. We need to be able to associate properties to all four types of elements: (1) definitions (blocks i.e. types), (2) usages (parts, ports or connectors directly owned by a block), (3) occurrences (deeply nested parts, ports or connectors), (4) realizations (serial numbered realizations of a definition and associated with an occurrence). For example we need to be able to associate a generic calibration formula (constraint) to a definition, a more specific calibration formula to a usage or an occurrence, and an even more specific calibration formula to a serial numbered item. These calibration formulas are associated at different stages of the life cycle as the design matures and the system is realized. In my understanding SysML currently allows to model (1) and (2) fully, and (3) partially through (deeply) nested connector ends. (4) may perhaps be supported through instance specifications, but I have not seen clear SysML implementations/examples of this. So, I don't think there is ambiguity in the SysML bdd, but it is not so easy for (new) users since they have to be aware that they are always working with at least two hierarchies at the same time: the implicit definitional one and the explicit expanded one. On the other hand this pattern is established best practice in the major 3D CAD tools etc. for years now. Best regards, Hans Peter -- E: Hans-Peter.de.Koning@esa.int T: +31 (71) 56 53452 F: +31 (71) 56 56142 ESA / ESTEC (European Space Research and Technology Centre) Directorate of Technical and Quality Management Mechanical Engineering Department / Thermal Division Keplerlaan 1, 2201 AZ Noordwijk, The Netherlands (visits & courier) P.O. Box 299, 2200 AG Noordwijk, The Netherlands (regular mail) "Nerijus Jankevicius" 2009-10-06 14:41 To "Sawyer, George A \(US SSA\)" , cc Subject Re: #14447: Ambiguous Block Hierarchy I don't think automatically populated associations is a good idea. There are two equivalent ways to show the same model: When association/composition exists, but not represented in the diagram, the part/property should be visible in Class/Block compartment. If association is represented, property is displayed as role on association and should disappear from compartment. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Sawyer, George A (US SSA) To: sysml-rtf@omg.org Sent: Tuesday, October 06, 2009 3:05 PM Subject: RE: #14447: Ambiguous Block Hierarchy The issue report seems to suggest that when when a previously defined block type is placed on a bdd, it should be automatically updated to show all of the composition associations in order to ensure consistency. But, maybe I'm reading too much into Sandy's issue identification. For example, if 'A' was already on a bdd and 'B' was placed on the same diagram, then should the two composition associations would automatically be populated. In different example, if 'A' was already on the diagram and 'C' was placed on the diagram, then would the bdd be automatically updated to show 'B' and the associations between it and 'A' plus the associations between 'B' and 'C'? This is good from the standpoint of ensuring developers don't inadvertantly duplicate/recreate composition associations, but it also removes lessens their control of the appropriate visualization. That is, it seems like a reasonable feature for new modelers, but potentially undesirable for more experienced modelers. George -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 2:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Tue, 6 Oct 2009 16:29:30 -0400 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGl036kJB65uaVQ32PI1QZcVIRNgAK78Qw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n96KSOr9031941 Eran, > are you saying it is possible in UML/SysML? No, in other modeling languages the connector end path is reified, eg, ftp://ftp.omg.org/pub/docs/dtc/08-05-11/pages/332337ee43550235.htm. It could easily be reified in UML/SysML also if needed. Conrad X-WSS-ID: 0KR4NTA-08-OVB-02 X-M-MSG: From: Burkhart Roger M To: Eran Gery , "sysml-rtf@omg.org" CC: "BERNARD, Yves" Date: Tue, 6 Oct 2009 23:43:57 -0500 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlGAXT18ltUslRP6Jivl0TK1c/AAdEoRg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n974gWX6021135 Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. Subject: RE: #14447: Ambiguous Block Hierarchy Date: Wed, 7 Oct 2009 09:17:33 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlGAXT18ltUslRP6Jivl0TK1c/AAdEoRgAAOyNWA= From: "BERNARD, Yves" To: X-OriginalArrivalTime: 07 Oct 2009 07:17:33.0519 (UTC) FILETIME=[3D3895F0:01CA471E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n977H9YH014601 Maybe what Eran point out has something to do with the OO paradigm that is an intrinsic characteristic of SysML. SysML Blocks are classes, as defined by the OO paradigm. If the constraints on A.b1.c1 and on A.b2.c1 are not the same it means that b1 and b2 don't have (exactly) the same type (at least one of them shall be typed by a subclass of B). The ibd you can display in the "b1 box" of the ibd of A is not specific to the b1 part but is actually the ibd of Block B. Then, if you modify something on this "b1 ibd", the modifications actually apply to all elements having the same type than b1. You cannot get rid of the OO paradigm in SysML because of the way it is built (UML profile). Nevertheless, SysML provides a bypass solution through the PropertySpecificType. Except if i miss something, using this concept it should be possible to cover the remaining needs held by the #3 of Hans-Peter's list and since the v1.2 of SysML now supports instance specifications, it should also be possible to model realization (point #4 of the list). Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 06:44 À : Eran Gery; sysml-rtf@omg.org Cc : BERNARD, Yves Objet : RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-WSS-ID: 0KR574Y-05-RF8-02 X-M-MSG: From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: Wed, 7 Oct 2009 06:41:22 -0500 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlGAXT18ltUslRP6Jivl0TK1c/AAdEoRgAAOyNWAACgPQoA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n97Bdvwl017755 Yves-- A constraint block, and its bindings to properties in a containing block context such as A, does not change the type of properties to which it is bound, such as b1.c1 or b2.c1. It is owned directly by A, and its constraints apply only in the context of property values held by A. The classes which type b1, b2, or c1 remain unmodified and may be used to type other elements anywhere else in the model. Property-specific types do create a class which is unique to a property, but they are not unique to any containing path which could reach the property, so they do not satisfy Hans Peter's case #3, custom definitions such as a calibration formula on a deep-nested occurrence. Such a calibration formula could be attached by a constraint block which is external to the deep-nested property and bound to it in the larger usage context to which it applies. The larger usage context could also define an ordinary UML constraint which includes in its constraint expression the navigation to the specific nested property to which the constraint applies. Since Eran also used the term "allocate" in reference to a constraint, it's also worth clarifying that SysML does not currently support allocation relationships (Chapter 15) to a deep-nested usage. While we do allow allocation on a property (Chapter 15 only shows part properties but I see no reason this couldn't be any property), it's only to a property directly owned by a containing block, not to a more deeply nested occurrence of a property. On Hans Peter's fourth type of property association, a serial numbered realizations, you're right that instance specifications could be used to supply values to these realizations, such as the serial number itself or values which apply to the specific realization, but instance specifications do not support the ability to define formulas or other constraints on these instances. They can only be used to supply values which fill the instance slots. (I'm not sure that UML restricts the ability to attach UML constraints even to instance specifications, but there's certainly no ability to respecify the classes which type the slots in an instance specification.) --Roger -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, October 07, 2009 2:18 AM To: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy Maybe what Eran point out has something to do with the OO paradigm that is an intrinsic characteristic of SysML. SysML Blocks are classes, as defined by the OO paradigm. If the constraints on A.b1.c1 and on A.b2.c1 are not the same it means that b1 and b2 don't have (exactly) the same type (at least one of them shall be typed by a subclass of B). The ibd you can display in the "b1 box" of the ibd of A is not specific to the b1 part but is actually the ibd of Block B. Then, if you modify something on this "b1 ibd", the modifications actually apply to all elements having the same type than b1. You cannot get rid of the OO paradigm in SysML because of the way it is built (UML profile). Nevertheless, SysML provides a bypass solution through the PropertySpecificType. Except if i miss something, using this concept it should be possible to cover the remaining needs held by the #3 of Hans-Peter's list and since the v1.2 of SysML now supports instance specifications, it should also be possible to model realization (point #4 of the list). Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 06:44 À : Eran Gery; sysml-rtf@omg.org Cc : BERNARD, Yves Objet : RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: #14447: Ambiguous Block Hierarchy X-KeepSent: B88A4B0D:A77E5BE5-C2257648:0049537B; type=4; name=$KeepSent To: Burkhart Roger M Cc: "sysml-rtf@omg.org" , "BERNARD, Yves" X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eran Gery Date: Wed, 7 Oct 2009 15:41:57 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 07/10/2009 15:52:53 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n97DpPQE017460 Roger: Here are 3 cases which you cannot do with a connector: - Assign a constraint to the property - Connect a flow (not using a connector) to the property (currently not directly supported by SysML but we need to fix that - there is no need for a connector to designate a flow). - Describing any type of a dependency from/to that property - Also assigning the value using the chain of instance specifications: this actually demonstrates some inconsistent design approach where to assert a value on a property you need all that instance tree, and to bind it to a constrain block you simply use a chain of property references. Using instance specification to assert something on a nested property is odd and I treat it as a back door. In short, designating a nested property only in a context of a connector is limiting as you cannot use it for any other type of relationship or purpose. A nested property shall be a first class concept for the above reasons and also simply because we treat it as a concept - we talk about nested properties, and in an independent context not just for relating binding connectors. Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: Eran Gery/Haifa/IBM@IBMIL, "sysml-rtf@omg.org" Cc: "BERNARD, Yves" Date: 10/07/2009 06:44 AM Subject: RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. Subject: RE: #14447: Ambiguous Block Hierarchy Date: Thu, 8 Oct 2009 12:11:19 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlGAXT18ltUslRP6Jivl0TK1c/AAdEoRgAAOyNWAACgPQoAAE1z+Q From: "BERNARD, Yves" To: X-OriginalArrivalTime: 08 Oct 2009 10:11:19.0513 (UTC) FILETIME=[AE02C490:01CA47FF] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98AALHR028184 Roger, It is not so obvious that the ability offered to binding connectors to have deep nested connector ends cannot violate the principles of the OO paradigm on which SysML is built. My mathematical skills are not sufficient to study that point formally but I think the question can be asked. Anyway, i think (but maybe i'm wrong) that the point raised by Eran go over the case of constraint blocks to address any kind of restrictions that one might want to make on a deep-nested part. Your objection about the ability of PropertySpecificType to cover Hans Pater case #3 is not clear to me. If we have the same understanding of what "calibrate" means, the ability of a component to be calibrate is a service that is provided to the outside through something like a port. Using deep-nested connectors to connect a public exposed feature of a deep-nested part does not violate the paradigm and is feasible with the current specification of SysML. About Allocations, i would underline that in the sepcification there is no constraint to restrict what can be the clients and the suppliers of an allocation. Allocation is defined as an extension of the UML Abstraction relationship that can virtually have any kind of NamedElement for client and supplier. A part is a NamedElement, regardless its "nestedness". The point is that, that's true, we have no means to designate a deep-nested part except through a deep-nested connector. UML constraints can be attached to any UML Element, then it is actually possible to constrain a Slot. Nevertheless an InstanceSpecification can only be used as an illustration of a possible instance of a model and not to provide additional specification (what would violate the paradigm). Then, it does not make sens to constrain a Slot: if a constraint is required, it should be specified at Classifier level. Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 13:41 À : BERNARD, Yves; sysml-rtf@omg.org Objet : RE: #14447: Ambiguous Block Hierarchy Yves-- A constraint block, and its bindings to properties in a containing block context such as A, does not change the type of properties to which it is bound, such as b1.c1 or b2.c1. It is owned directly by A, and its constraints apply only in the context of property values held by A. The classes which type b1, b2, or c1 remain unmodified and may be used to type other elements anywhere else in the model. Property-specific types do create a class which is unique to a property, but they are not unique to any containing path which could reach the property, so they do not satisfy Hans Peter's case #3, custom definitions such as a calibration formula on a deep-nested occurrence. Such a calibration formula could be attached by a constraint block which is external to the deep-nested property and bound to it in the larger usage context to which it applies. The larger usage context could also define an ordinary UML constraint which includes in its constraint expression the navigation to the specific nested property to which the constraint applies. Since Eran also used the term "allocate" in reference to a constraint, it's also worth clarifying that SysML does not currently support allocation relationships (Chapter 15) to a deep-nested usage. While we do allow allocation on a property (Chapter 15 only shows part properties but I see no reason this couldn't be any property), it's only to a property directly owned by a containing block, not to a more deeply nested occurrence of a property. On Hans Peter's fourth type of property association, a serial numbered realizations, you're right that instance specifications could be used to supply values to these realizations, such as the serial number itself or values which apply to the specific realization, but instance specifications do not support the ability to define formulas or other constraints on these instances. They can only be used to supply values which fill the instance slots. (I'm not sure that UML restricts the ability to attach UML constraints even to instance specifications, but there's certainly no ability to respecify the classes which type the slots in an instance specification.) --Roger -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, October 07, 2009 2:18 AM To: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy Maybe what Eran point out has something to do with the OO paradigm that is an intrinsic characteristic of SysML. SysML Blocks are classes, as defined by the OO paradigm. If the constraints on A.b1.c1 and on A.b2.c1 are not the same it means that b1 and b2 don't have (exactly) the same type (at least one of them shall be typed by a subclass of B). The ibd you can display in the "b1 box" of the ibd of A is not specific to the b1 part but is actually the ibd of Block B. Then, if you modify something on this "b1 ibd", the modifications actually apply to all elements having the same type than b1. You cannot get rid of the OO paradigm in SysML because of the way it is built (UML profile). Nevertheless, SysML provides a bypass solution through the PropertySpecificType. Except if i miss something, using this concept it should be possible to cover the remaining needs held by the #3 of Hans-Peter's list and since the v1.2 of SysML now supports instance specifications, it should also be possible to model realization (point #4 of the list). Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 06:44 À : Eran Gery; sysml-rtf@omg.org Cc : BERNARD, Yves Objet : RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-WSS-ID: 0KR72X1-05-IPJ-02 X-M-MSG: From: Burkhart Roger M To: Eran Gery CC: "sysml-rtf@omg.org" , "BERNARD, Yves" Date: Thu, 8 Oct 2009 07:05:25 -0500 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpHVXpjOPlpcAAdTz2MxcnG3FOE2AAuHu8w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98C3voD016803 Eran-- I generally agree with everything you say below. On assigning a constraint to a property, while you can't do it with a connector alone, you could use a unary constraint block to package the constraint, and tie its single parameter to the property by a single connector. I had noted that the tree of instance specifications to assert nested values was equivalent to a nested property chain reference, and I agree it's a back door that's not consistent with nested properties for connector ends. If we build a new kind of element to designate a property chain from an initial containing context, I agree it would be best to unify all use cases (e.g. your flow connection proposal, or dependencies including allocations which do not currently support deep-nested properties). If we come up with a more general form of nested property designation, one form it could take could be defining a new property at the containing level and applying a stereotype that declares it as the equivalent of the chain of nested properties. This internally generated property could then be connected just like any other property, for all uses which might arise. It would be like a derived property in that its values are equivalent to the results of navigating through the chain, but unlike a derived property it could have its own constraints (ordinary UML constraints) along with its own assigned value. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Wednesday, October 07, 2009 8:42 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger: Here are 3 cases which you cannot do with a connector: - Assign a constraint to the property - Connect a flow (not using a connector) to the property (currently not directly supported by SysML but we need to fix that - there is no need for a connector to designate a flow). - Describing any type of a dependency from/to that property - Also assigning the value using the chain of instance specifications: this actually demonstrates some inconsistent design approach where to assert a value on a property you need all that instance tree, and to bind it to a constrain block you simply use a chain of property references. Using instance specification to assert something on a nested property is odd and I treat it as a back door. In short, designating a nested property only in a context of a connector is limiting as you cannot use it for any other type of relationship or purpose. A nested property shall be a first class concept for the above reasons and also simply because we treat it as a concept - we talk about nested properties, and in an independent context not just for relating binding connectors. Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: Eran Gery/Haifa/IBM@IBMIL, "sysml-rtf@omg.org" Cc: "BERNARD, Yves" Date: 10/07/2009 06:44 AM Subject: RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. X-WSS-ID: 0KR73J2-08-0CF-02 X-M-MSG: From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: Thu, 8 Oct 2009 07:18:29 -0500 Subject: RE: #14447: Ambiguous Block Hierarchy Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlGAXT18ltUslRP6Jivl0TK1c/AAdEoRgAAOyNWAACgPQoAAE1z+QAC8xYpA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98CHCS0019898 Yves-- SysML is not built on a strict OO paradigm. For example, Systems Engineering has a long history of purely functional decomposition, which SysML is intended to support equally. Deep-nested connector ends do violate encapsulation, but they're required to describe the connection relationships of real physical systems, where all kinds of interactions can occur that don't respect a particular kind of design practice appropriate in a purely constructed domain such as software. I agree it's perfectly valid to connect to deep-nested parts that may have property-specific types. However, anything declared in that property-specific type will apply to any path which is capable of reaching it, and cannot be qualified to a specific nesting chain. While there's nothing that restricts what an allocation can be connected to, I think we agree there's no ability to designate a particular nesting context for an allocation end, and so there's nothing to connect to. If you connect an allocation directly to a property, it applies to all paths capabable of reaching the property, not just a particular one. I agree that it violates the intent of instance specifications to declare UML constraints on them, even if the UML metamodel is permissive enough to allow them. We could consider adding a restriction to this effect in the SysML profile, but to minimize differences from UML it's probably OK to just leave this as part of recommended usage guidelines. --Roger -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, October 08, 2009 5:11 AM To: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy Roger, It is not so obvious that the ability offered to binding connectors to have deep nested connector ends cannot violate the principles of the OO paradigm on which SysML is built. My mathematical skills are not sufficient to study that point formally but I think the question can be asked. Anyway, i think (but maybe i'm wrong) that the point raised by Eran go over the case of constraint blocks to address any kind of restrictions that one might want to make on a deep-nested part. Your objection about the ability of PropertySpecificType to cover Hans Pater case #3 is not clear to me. If we have the same understanding of what "calibrate" means, the ability of a component to be calibrate is a service that is provided to the outside through something like a port. Using deep-nested connectors to connect a public exposed feature of a deep-nested part does not violate the paradigm and is feasible with the current specification of SysML. About Allocations, i would underline that in the sepcification there is no constraint to restrict what can be the clients and the suppliers of an allocation. Allocation is defined as an extension of the UML Abstraction relationship that can virtually have any kind of NamedElement for client and supplier. A part is a NamedElement, regardless its "nestedness". The point is that, that's true, we have no means to designate a deep-nested part except through a deep-nested connector. UML constraints can be attached to any UML Element, then it is actually possible to constrain a Slot. Nevertheless an InstanceSpecification can only be used as an illustration of a possible instance of a model and not to provide additional specification (what would violate the paradigm). Then, it does not make sens to constrain a Slot: if a constraint is required, it should be specified at Classifier level. Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 13:41 À : BERNARD, Yves; sysml-rtf@omg.org Objet : RE: #14447: Ambiguous Block Hierarchy Yves-- A constraint block, and its bindings to properties in a containing block context such as A, does not change the type of properties to which it is bound, such as b1.c1 or b2.c1. It is owned directly by A, and its constraints apply only in the context of property values held by A. The classes which type b1, b2, or c1 remain unmodified and may be used to type other elements anywhere else in the model. Property-specific types do create a class which is unique to a property, but they are not unique to any containing path which could reach the property, so they do not satisfy Hans Peter's case #3, custom definitions such as a calibration formula on a deep-nested occurrence. Such a calibration formula could be attached by a constraint block which is external to the deep-nested property and bound to it in the larger usage context to which it applies. The larger usage context could also define an ordinary UML constraint which includes in its constraint expression the navigation to the specific nested property to which the constraint applies. Since Eran also used the term "allocate" in reference to a constraint, it's also worth clarifying that SysML does not currently support allocation relationships (Chapter 15) to a deep-nested usage. While we do allow allocation on a property (Chapter 15 only shows part properties but I see no reason this couldn't be any property), it's only to a property directly owned by a containing block, not to a more deeply nested occurrence of a property. On Hans Peter's fourth type of property association, a serial numbered realizations, you're right that instance specifications could be used to supply values to these realizations, such as the serial number itself or values which apply to the specific realization, but instance specifications do not support the ability to define formulas or other constraints on these instances. They can only be used to supply values which fill the instance slots. (I'm not sure that UML restricts the ability to attach UML constraints even to instance specifications, but there's certainly no ability to respecify the classes which type the slots in an instance specification.) --Roger -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, October 07, 2009 2:18 AM To: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy Maybe what Eran point out has something to do with the OO paradigm that is an intrinsic characteristic of SysML. SysML Blocks are classes, as defined by the OO paradigm. If the constraints on A.b1.c1 and on A.b2.c1 are not the same it means that b1 and b2 don't have (exactly) the same type (at least one of them shall be typed by a subclass of B). The ibd you can display in the "b1 box" of the ibd of A is not specific to the b1 part but is actually the ibd of Block B. Then, if you modify something on this "b1 ibd", the modifications actually apply to all elements having the same type than b1. You cannot get rid of the OO paradigm in SysML because of the way it is built (UML profile). Nevertheless, SysML provides a bypass solution through the PropertySpecificType. Except if i miss something, using this concept it should be possible to cover the remaining needs held by the #3 of Hans-Peter's list and since the v1.2 of SysML now supports instance specifications, it should also be possible to model realization (point #4 of the list). Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 06:44 À : Eran Gery; sysml-rtf@omg.org Cc : BERNARD, Yves Objet : RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: #14447: Ambiguous Block Hierarchy Date: Thu, 8 Oct 2009 15:39:49 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #14447: Ambiguous Block Hierarchy Thread-Index: AcpGlGAXT18ltUslRP6Jivl0TK1c/AAdEoRgAAOyNWAACgPQoAAE1z+QAC8xYpAAA0ZQgA== From: "BERNARD, Yves" To: X-OriginalArrivalTime: 08 Oct 2009 13:39:50.0171 (UTC) FILETIME=[CEF1AEB0:01CA481C] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98DdUBY008098 Roger, I agree that System Engineering is not built on an OO paradigm, my point was about SysML not about System Engineering in general. SysML is built on UML, each SysML concepts in an (extended) UML one, and UML is OO, then SysML is OO. That's a fact. OO is not a design practise but a paradigm, that is: a set of rules that define a viewpoint of the universe. You can perfectly use this veiwpoint to describe a functional decomposition, as long as you do not violate the rules. The main difference between Software and System Engineering, from an OO point of view, is that when you design a software you can *decide* whether a property is encapsulated or not. In System Engineering you deal with things from the real world and for some properties of those "things" you cannot choose whether they're encapsulated or not: the (physical) laws of the real world *impose* it to you. If you don't take it into account your model will not be representative and if you violate the paradigm on which your modeling language is built to take care of it your model will be inconsistent. Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : jeudi 8 octobre 2009 14:18 À : BERNARD, Yves; sysml-rtf@omg.org Objet : RE: #14447: Ambiguous Block Hierarchy Yves-- SysML is not built on a strict OO paradigm. For example, Systems Engineering has a long history of purely functional decomposition, which SysML is intended to support equally. Deep-nested connector ends do violate encapsulation, but they're required to describe the connection relationships of real physical systems, where all kinds of interactions can occur that don't respect a particular kind of design practice appropriate in a purely constructed domain such as software. I agree it's perfectly valid to connect to deep-nested parts that may have property-specific types. However, anything declared in that property-specific type will apply to any path which is capable of reaching it, and cannot be qualified to a specific nesting chain. While there's nothing that restricts what an allocation can be connected to, I think we agree there's no ability to designate a particular nesting context for an allocation end, and so there's nothing to connect to. If you connect an allocation directly to a property, it applies to all paths capabable of reaching the property, not just a particular one. I agree that it violates the intent of instance specifications to declare UML constraints on them, even if the UML metamodel is permissive enough to allow them. We could consider adding a restriction to this effect in the SysML profile, but to minimize differences from UML it's probably OK to just leave this as part of recommended usage guidelines. --Roger -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, October 08, 2009 5:11 AM To: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy Roger, It is not so obvious that the ability offered to binding connectors to have deep nested connector ends cannot violate the principles of the OO paradigm on which SysML is built. My mathematical skills are not sufficient to study that point formally but I think the question can be asked. Anyway, i think (but maybe i'm wrong) that the point raised by Eran go over the case of constraint blocks to address any kind of restrictions that one might want to make on a deep-nested part. Your objection about the ability of PropertySpecificType to cover Hans Pater case #3 is not clear to me. If we have the same understanding of what "calibrate" means, the ability of a component to be calibrate is a service that is provided to the outside through something like a port. Using deep-nested connectors to connect a public exposed feature of a deep-nested part does not violate the paradigm and is feasible with the current specification of SysML. About Allocations, i would underline that in the sepcification there is no constraint to restrict what can be the clients and the suppliers of an allocation. Allocation is defined as an extension of the UML Abstraction relationship that can virtually have any kind of NamedElement for client and supplier. A part is a NamedElement, regardless its "nestedness". The point is that, that's true, we have no means to designate a deep-nested part except through a deep-nested connector. UML constraints can be attached to any UML Element, then it is actually possible to constrain a Slot. Nevertheless an InstanceSpecification can only be used as an illustration of a possible instance of a model and not to provide additional specification (what would violate the paradigm). Then, it does not make sens to constrain a Slot: if a constraint is required, it should be specified at Classifier level. Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 13:41 À : BERNARD, Yves; sysml-rtf@omg.org Objet : RE: #14447: Ambiguous Block Hierarchy Yves-- A constraint block, and its bindings to properties in a containing block context such as A, does not change the type of properties to which it is bound, such as b1.c1 or b2.c1. It is owned directly by A, and its constraints apply only in the context of property values held by A. The classes which type b1, b2, or c1 remain unmodified and may be used to type other elements anywhere else in the model. Property-specific types do create a class which is unique to a property, but they are not unique to any containing path which could reach the property, so they do not satisfy Hans Peter's case #3, custom definitions such as a calibration formula on a deep-nested occurrence. Such a calibration formula could be attached by a constraint block which is external to the deep-nested property and bound to it in the larger usage context to which it applies. The larger usage context could also define an ordinary UML constraint which includes in its constraint expression the navigation to the specific nested property to which the constraint applies. Since Eran also used the term "allocate" in reference to a constraint, it's also worth clarifying that SysML does not currently support allocation relationships (Chapter 15) to a deep-nested usage. While we do allow allocation on a property (Chapter 15 only shows part properties but I see no reason this couldn't be any property), it's only to a property directly owned by a containing block, not to a more deeply nested occurrence of a property. On Hans Peter's fourth type of property association, a serial numbered realizations, you're right that instance specifications could be used to supply values to these realizations, such as the serial number itself or values which apply to the specific realization, but instance specifications do not support the ability to define formulas or other constraints on these instances. They can only be used to supply values which fill the instance slots. (I'm not sure that UML restricts the ability to attach UML constraints even to instance specifications, but there's certainly no ability to respecify the classes which type the slots in an instance specification.) --Roger -----Original Message----- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, October 07, 2009 2:18 AM To: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy Maybe what Eran point out has something to do with the OO paradigm that is an intrinsic characteristic of SysML. SysML Blocks are classes, as defined by the OO paradigm. If the constraints on A.b1.c1 and on A.b2.c1 are not the same it means that b1 and b2 don't have (exactly) the same type (at least one of them shall be typed by a subclass of B). The ibd you can display in the "b1 box" of the ibd of A is not specific to the b1 part but is actually the ibd of Block B. Then, if you modify something on this "b1 ibd", the modifications actually apply to all elements having the same type than b1. You cannot get rid of the OO paradigm in SysML because of the way it is built (UML profile). Nevertheless, SysML provides a bypass solution through the PropertySpecificType. Except if i miss something, using this concept it should be possible to cover the remaining needs held by the #3 of Hans-Peter's list and since the v1.2 of SysML now supports instance specifications, it should also be possible to model realization (point #4 of the list). Yves -----Message d'origine----- De : Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Envoyé : mercredi 7 octobre 2009 06:44 À : Eran Gery; sysml-rtf@omg.org Cc : BERNARD, Yves Objet : RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. To: Burkhart Roger M Cc: sysml-rtf@omg.org Subject: RE: #14447: Ambiguous Block Hierarchy X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 From: Hans-Peter.de.Koning@esa.int Date: Thu, 8 Oct 2009 17:39:05 +0200 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 6.5.5FP1 | April 14, 2006) at 10/08/2009 17:39:11, Serialize complete at 10/08/2009 17:39:11 Roger, Do I understand correctly that one kind of "a more general form of nested property designation" is the "delegation port" described in section 6.4.3 / page 126 of the SysML book by Sandy Friedenthal et al.? If so do we need to formalize the concepts of "delegation port" and more in general "delegation property"? In our work we have also called this "proxy" port / connector-end / interface-end. In my example of attaching a calibration formula to a realization (my #4 serial-numbered item) I was not thinking of specifying a new type of constraint, but rather just different coefficients in a formula defined at block or usage level. Since such coefficients are only values, this could be handled without problem using instance specifications. Best regards, Hans Peter Burkhart Roger M 2009-10-08 14:05 To Eran Gery cc "sysml-rtf@omg.org" , "BERNARD, Yves" Subject RE: #14447: Ambiguous Block Hierarchy Eran-- I generally agree with everything you say below. On assigning a constraint to a property, while you can't do it with a connector alone, you could use a unary constraint block to package the constraint, and tie its single parameter to the property by a single connector. I had noted that the tree of instance specifications to assert nested values was equivalent to a nested property chain reference, and I agree it's a back door that's not consistent with nested properties for connector ends. If we build a new kind of element to designate a property chain from an initial containing context, I agree it would be best to unify all use cases (e.g. your flow connection proposal, or dependencies including allocations which do not currently support deep-nested properties). If we come up with a more general form of nested property designation, one form it could take could be defining a new property at the containing level and applying a stereotype that declares it as the equivalent of the chain of nested properties. This internally generated property could then be connected just like any other property, for all uses which might arise. It would be like a derived property in that its values are equivalent to the results of navigating through the chain, but unlike a derived property it could have its own constraints (ordinary UML constraints) along with its own assigned value. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Wednesday, October 07, 2009 8:42 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger: Here are 3 cases which you cannot do with a connector: - Assign a constraint to the property - Connect a flow (not using a connector) to the property (currently not directly supported by SysML but we need to fix that - there is no need for a connector to designate a flow). - Describing any type of a dependency from/to that property - Also assigning the value using the chain of instance specifications: this actually demonstrates some inconsistent design approach where to assert a value on a property you need all that instance tree, and to bind it to a constrain block you simply use a chain of property references. Using instance specification to assert something on a nested property is odd and I treat it as a back door. In short, designating a nested property only in a context of a connector is limiting as you cannot use it for any other type of relationship or purpose. A nested property shall be a first class concept for the above reasons and also simply because we treat it as a concept - we talk about nested properties, and in an independent context not just for relating binding connectors. Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: Eran Gery/Haifa/IBM@IBMIL, "sysml-rtf@omg.org" Cc: "BERNARD, Yves" Date: 10/07/2009 06:44 AM Subject: RE: #14447: Ambiguous Block Hierarchy Eran-- A constraint block has its parameters bound to a nested property only by means of a connector that references the property. A deep-nested connector end is created to identify the property path as needed for this case. There is no other form of designation of a nested property. If you show a nested property on an ibd, using either the graphical notation of nested property boxes or the equivalent textual shorthand of the dot syntax such as b1.c1 in a property box, this does not create any form of designation or any other semantics unless a connector end is bound to the property. It's only a way of displaying a property which could be referenced by a connector end inside that context. This display option is not even limited just to part properties; it could equally be used to show an accessible property through a chain of reference (non-part) properties using dashed-outline property boxes, in addition to any solid-outline boxes for part properties. As Hans-Peter de Koning mentioned, multiple part hierarchies are important to deal with multiple ways of decomposing a complex system. Any connector, however, must explicitly designate the property path through any such decomposition which is used to identify the connector end. Is there any other form of designation of a property path which carries any semantics other than its use as a connector end? An initialValues compartment can also be shown on a nested property on an ibd, but for that case we specify a tree of instance specifications on the containing block to carry the nested values, with only the property slots filled in that are necessary to carry the values, recursively through the levels of the path. That could be considered the equivalent of another form of path expression. I don't know of any other form of path expression which needs to be designated by any other semantic construct currently included in SysML. --Roger -----Original Message----- From: Eran Gery [mailto:eran.gery@il.ibm.com] Sent: Tuesday, October 06, 2009 9:50 AM To: Burkhart Roger M Cc: sysml-rtf@omg.org; BERNARD, Yves Subject: RE: #14447: Ambiguous Block Hierarchy Roger Here is the problem: How do you allocate a constrain to a property a.b1.c1? There is currently no semantics to do this. I agree that the issue is not ambiguity in the spec, but simply the lacking of the spec to designate such a property path. Deep nested connector address a subset of this problem, but we cannot designate a nested property other than making up a connector that references it. As Sandy specified in the issue, the current dot notation to designate a nested part has no semantic backing and this is the essence here. Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: Burkhart Roger M To: "BERNARD, Yves" , "sysml-rtf@omg.org" Date: 10/06/2009 02:22 PM Subject: RE: #14447: Ambiguous Block Hierarchy I agree; I don't think there's any ambiguity or other problem. What the nesting expresses is a path through a chain of properties, so all four nested combinations of b1/b2 and c1/c2 could be shown on the same ibd. Which instances are actually accessible through which path has to be resolved by the instances that fill each of the property value slots. The values referenced by all four paths could be distinct. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Tuesday, October 06, 2009 1:22 AM To: sysml-rtf@omg.org Subject: #14447: Ambiguous Block Hierarchy In the example given, formally there is a c1 part in both b1 and b2 (ie. b1.c1 and b2.c1) , the same for c2. That is: you will have four parts of typed by Block C at the end. Yves -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : lundi 5 octobre 2009 17:56 À : issues@omg.org; sysml-rtf@omg.org Objet : issue 14447 -- SysML RTF issue From: webmaster@omg.org Date: 04 Oct 2009 09:38:32 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sanford Friedenthal Company: Lockheed Martin mailFrom: sanford.friedenthal@lmco.com Notification: Yes Specification: SysML Section: 8 FormalNumber: formal/2008-11-02 Version: 1.1 to 1.2 RevisionDate: Nov, 2008 Page: 31-59 Title: Ambiguous Block Hierarchy Nature: Clarification Severity: Significant test: 3qw8 B1: Report Issue Description: There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies. From: "BERNARD, Yves" To: "Sysml-Rtf (sysml-rtf@omg.org)" Date: Thu, 21 Feb 2013 15:56:05 +0100 Subject: [SysML 1.4 RTF] Ballot 4 review: #14447 Thread-Topic: [SysML 1.4 RTF] Ballot 4 review: #14447 Thread-Index: Ac4QQ5MAruX4BtWYSpOQRjjkCckZHA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAwr+n5EdGLWYHRjNKA== X-Brightmail-Tracker: AAAAAA== The statement in the summary is false since, according to the multiplicity shown on the BDD, both b1 and b2 parts owns both c1 and c2 (sub)parts. In addition, the example given to illustrate the issue is unnecessarily complicated, leading to a cumbersome and unclear description in the Resolution section. We first claim that the model is unambiguous and then, in the next sentence, we explain that it is not self-sufficient. I suggest building the resolution on simpler example, as follow: Modify block B so that it owns only one c:C property Keep only one ibd showing parts b1 an b2 with their respective c parts Replace the current text of the resolution by this one: .If a directed relationship, such as a dependency, was linked to one of the c part, it would not be possible from the underlying model alone (without the diagram) whether the directed relationship was referring to values of c from the b1 part of from the b2 part because directed relationships do not currently support property paths, as connector ends do when NestedConnectorEnd is applied. Introduce an abstract stereotype of DirectedRelationship with property paths for their sources and targets, that generalizes SysML Stereotypes based on DirectedRelationship or its specializations.. Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "Sysml-Rtf (sysml-rtf@omg.org)" Date: Thu, 21 Feb 2013 10:04:18 -0500 Subject: RE: [SysML 1.4 RTF] Ballot 4 review: #14447 Thread-Topic: [SysML 1.4 RTF] Ballot 4 review: #14447 Thread-Index: Ac4QQ5MAruX4BtWYSpOQRjjkCckZHAAALsVQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR0YtZg= X-Brightmail-Tracker: AAAAAA== Yves, > The statement in the summary is false since, according to the > multiplicity shown on the BDD, both b1 and b2 parts owns both c1 and > c2 (sub)parts. In addition, the example given to illustrate the issue > is unnecessarily complicated, leading to a cumbersome and unclear > description in the Resolution section. We first claim that the model > is unambiguous and then, in the next sentence, we explain that it is > not self-sufficient... > I suggest building the resolution on simpler example, as follow: The summary is part of the filed issue, we can't change it. It's not part of the revised text. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=4gTX/HG3Nw4V4ndC2NKFFAqJT0PvbEGG1gIdeYw24MI=; b=z1ge8qmL9chiitd6kecxRVHYmt2wXAZs7Xnk56gJ/K7E6HfexQpsQoFBuUYv6k2lJG hUv1PHgj/gLexQWwyfVKLNcTz1M4WFKQ+OatnAPfDLXB/lk2SaNMvyR0uVR5IVgILf5a hwBoZmPK+nrPcCHcAemKmiKgD2UaeA92I9WPqGZP/BxE2wrn/Mij5UbRA4NVwxbGioKX a4j1hopyqX9mThcmq4yfH2ztUQ70pc+naAwCvPrPlW3507SWMZeFxWwfqSg1as/koz8O pGldGD6saG9Nfql5jWSl2pfu7JP0Rdq/3aLKKFWxjMXSJlE6IhTj1nh+oCJgf24Q90Ha k3vg== X-Received: by 10.49.74.198 with SMTP id w6mr12399734qev.57.1361470138978; Thu, 21 Feb 2013 10:08:58 -0800 (PST) From: "Sanford Friedenthal" To: "'Bock, Conrad'" , Cc: "'Sysml-Rtf'" Subject: RE: [SysML 1.4 RTF] Ballot 4 review: #14447 Date: Thu, 21 Feb 2013 13:08:36 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4QQ5MAruX4BtWYSpOQRjjkCckZHAAALsVQAAZ44RA= X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAwzCY6MdGLWYHRjNKA== X-Brightmail-Tracker: AAAAAA== Conrad, Yves Perhaps it would be worth restating the issue in the resolution discussion to clarify the issue. I file the original issue and agree with the restatement as Yves provided. Sandy -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, February 21, 2013 10:04 AM To: Sysml-Rtf (sysml-rtf@omg.org) Subject: RE: [SysML 1.4 RTF] Ballot 4 review: #14447 Yves, > The statement in the summary is false since, according to the > multiplicity shown on the BDD, both b1 and b2 parts owns both c1 and > c2 (sub)parts. In addition, the example given to illustrate the issue > is unnecessarily complicated, leading to a cumbersome and unclear > description in the Resolution section. We first claim that the model > is unambiguous and then, in the next sentence, we explain that it is > not self-sufficient... > I suggest building the resolution on simpler example, as follow: The summary is part of the filed issue, we can't change it. It's not part of the revised text. Conrad From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, February 21, 2013 9:56 AM To: Sysml-Rtf (sysml-rtf@omg.org) Subject: [SysML 1.4 RTF] Ballot 4 review: #14447 The statement in the summary is false since, according to the multiplicity shown on the BDD, both b1 and b2 parts owns both c1 and c2 (sub)parts. In addition, the example given to illustrate the issue is unnecessarily complicated, leading to a cumbersome and unclear description in the Resolution section. We first claim that the model is unambiguous and then, in the next sentence, we explain that it is not self-sufficient. I suggest building the resolution on simpler example, as follow: 1. Modify block B so that it owns only one c:C property 2. Keep only one ibd showing parts b1 an b2 with their respective c parts 3. Replace the current text of the resolution by this one: "If a directed relationship, such as a dependency, was linked to one of the c part, it would not be possible from the underlying model alone (without the diagram) whether the directed relationship was referring to values of c from the b1 part of from the b2 part because directed relationships do not currently support property paths, as connector ends do when NestedConnectorEnd is applied. Introduce an abstract stereotype of DirectedRelationship with property paths for their sources and targets, that generalizes SysML Stereotypes based on DirectedRelationship or its specializations." Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: SysML RTF telecon, Feb 14, ballot 4 updates, 2 X-KeepSent: 263E8010:955282C4-C2257B20:0050171F; type=4; name=$KeepSent To: "Bock, Conrad" Cc: "sysml-rtf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Thu, 28 Feb 2013 16:43:43 +0200 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 28/02/2013 16:43:35 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13022814-0542-0000-0000-00000488DD66 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR0Zvw0= X-Brightmail-Tracker: AAAAAA== Conrad, Why did you remove the modification to item flow in 14447? (in the original ballot it was also inhering DirectedRelatioshipPropertyPath) As fir 17248 - from looking at slide 8 it does not look like it is not an easy discussion so I am OK with removing it from ballot 4. Eldad From: "Bock, Conrad" To: "sysml-rtf@omg.org" , Date: 22/02/2013 03:11 PM Subject: RE: SysML RTF telecon, Feb 14, ballot 4 updates, 2 P.S. Correction to 14447 attached. Conrad SysMLers, Notes from the review of ballot 4 today are at http://tinyurl.com/afjohhl. Main points: - 18269 (Units and QK) is updated per Sandy's comments, see Nicolas's email (slide 5). - The CRP proposals (18407, 14447) are updated to: define DirectedRelationshipPropertyPath in the Blocks chapter, and to define ElementPropertyPath in the same figure. use associations for property paths instead of just properties. (slides 6-7). - 17562 (binary allocations) has more accurate wording in the discussion section (slide 7). - 17248 (full port type) is tentatively pulled from the ballot. If Eldad wants to lead to agreement in the next few days, we can put it back on (slide 8). - 17254 (bindings to full ports) has reworded constraint to make it purely syntactic and clearer. Updates for the above attached (except the first, see Nicolas' email). Conrad http://www.omg.org/members/sysml-rtf-wiki/lib/exe/fetch.php?id=rtf4%3Ameeting_minutes&cache=cache&media=rtf4:meetings:rtf-general-130221_a.ppt [attachment "18407_resolved-v4.doc" deleted by Eldad Palachi/Haifa/IBM] [attachment "14447_resolved-v5a.doc" deleted by Eldad Palachi/Haifa/IBM] [attachment "17562_resolved.docx" deleted by Eldad Palachi/Haifa/IBM] There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies.