Issue 15884: Another issue with allocate (sysml-rtf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that’s ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. I’ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn’t work. MagicDraw doesn’t allow blocks to be owner of a allocate. I’m not sure whether it is a tool issue or if I’ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I’m not sure if that’ll solve my problem. Any ideas? Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: December 9, 2010: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: End of Annotations:===== ubject: Another issue with allocate Date: Thu, 9 Dec 2010 18:54:43 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another issue with allocate Thread-Index: AcuXyij9E7WwbYwmQbCDOCQ7mrlX2A== From: "Tim Weilkiens" To: Thanks for help for my previous allocate issue. I.m sorry, but here comes another one. See screenshot: The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that.s ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. I.ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn.t work. MagicDraw doesn.t allow blocks to be owner of a allocate. I.m not sure whether it is a tool issue or if I.ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I.m not sure if that.ll solve my problem. Any ideas? Thanks, Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Date: Thu, 09 Dec 2010 13:21:18 -0500 From: "Friedenthal, Sanford" Subject: RE: Another issue with allocate To: Tim Weilkiens , "sysml-rtf@omg.org" Thread-Topic: Another issue with allocate Thread-Index: AcuXyij9E7WwbYwmQbCDOCQ7mrlX2AAApaYA Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-09_08:2010-12-09,2010-12-09,1970-01-01 signatures=0 Tim I believe this is the original intent of the ambiguous block hierarchy issue that I raised. However, I don.t think the original issue was stated properly and clearly. It is pretty fundamental. Let me summarize as follows: Assume you have a Block A, B, and C. Assume A is composed of b1:B and b2:B, and B is composed of c:C. You cannot differentiate between the c that is part of b1 and the c that is part of b2. The dot notation makes this distinction, and you can show it in the diagram, but there is no difference in the actual model between the c that is part of b1 and the c that is part of b2. In order to address this, we need some way to identify the path from the top level block down each level of the hierarchy, similar to the this is done with nested connector ends. However, this has the potential to explode the model repository unless it is done on a selective basis (i.e. only when you have more than one role name on a particular block). I thought Roger was going to investigate this as one of the blocks issues, but I have not heard back anything on this. The access to nested elements may apply to other areas as well. Sandy From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Thursday, December 09, 2010 12:55 PM To: sysml-rtf@omg.org Subject: EXTERNAL: Another issue with allocate Thanks for help for my previous allocate issue. I.m sorry, but here comes another one. See screenshot: The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that.s ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. I.ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn.t work. MagicDraw doesn.t allow blocks to be owner of a allocate. I.m not sure whether it is a tool issue or if I.ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I.m not sure if that.ll solve my problem. Any ideas? Thanks, Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: Re: Another issue with allocate From: Fredrick A Steiner Date: Thu, 9 Dec 2010 13:25:20 -0500 To: "Tim Weilkiens" , "sysml-rtf" X-MIMETrack: Serialize by Router on ES2-MSG01/SRV/Raytheon(Release 8.5.1FP2|March 17, 2010) at 12/09/2010 10:25:24 This is a bigger problem than allocation... It's really a problem with specifying context for nested parts. Don't deep nested connectors have the same issue? Certainly requirement relationships do. So, can part specific properties also handle connectors, allocations, and requirement relations? Cheers, -Rick Rick Steiner Raytheon Integrated Defense Systems 858.522.2008 -------------------------------------------------------------------------------- From: "Tim Weilkiens" [Tim.Weilkiens@oose.de] Sent: 12/09/2010 06:54 PM CET To: Subject: Another issue with allocate Thanks for help for my previous allocate issue. I.m sorry, but here comes another one. See screenshot: The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that.s ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. I.ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn.t work. MagicDraw doesn.t allow blocks to be owner of a allocate. I.m not sure whether it is a tool issue or if I.ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I.m not sure if that.ll solve my problem. Any ideas? Thanks, Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de To: , From: "Tim Weilkiens" Date: Thu, 09 Dec 2010 22:34:42 +0100 X-Mailer: TouchDown Thread-Topic: Another issue with allocate Thread-Index: AcuXzoNtYjaSp0jZSeqApaVzTOJn6wAGnM3E Subject: Re: Another issue with allocate Properties can't own connectors or relationships. Sandy proposed a solution using the dot notation. I'm not sure how it is mapped to the repository. It's not an easy one. Tim Mobil geschrieben. Tippfehler möglich. -----Original Message----- From: Fredrick A Steiner [fsteiner@raytheon.com] Received: Donnerstag, 09 Dez. 2010, 19:25 To: Tim Weilkiens [Tim.Weilkiens@oose.de]; sysml-rtf [sysml-rtf@omg.org] Subject: Re: Another issue with allocate This is a bigger problem than allocation... It's really a problem with specifying context for nested parts. Don't deep nested connectors have the same issue? Certainly requirement relationships do. So, can part specific properties also handle connectors, allocations, and requirement relations? Cheers, -Rick Rick Steiner Raytheon Integrated Defense Systems 858.522.2008 ________________________________ From: "Tim Weilkiens" [Tim.Weilkiens@oose.de] Sent: 12/09/2010 06:54 PM CET To: Subject: Another issue with allocate Thanks for help for my previous allocate issue. Iâm sorry, but here comes another one. See screenshot: The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think thatâs ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. Iâve tried to assign the ownership of the allocate relationship to the TopLevel block which doesnât work. MagicDraw doesnât allow blocks to be owner of a allocate. Iâm not sure whether it is a tool issue or if Iâve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless Iâm not sure if thatâll solve my problem. Any ideas? Thanks, Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, Björn Schneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de , E-Mail: office@oose.de From: "BERNARD, Yves" To: Fredrick A Steiner , Tim Weilkiens , sysml-rtf Date: Fri, 10 Dec 2010 08:13:11 +0100 Subject: RE: Another issue with allocate Thread-Topic: Another issue with allocate Thread-Index: AcuXzp9+SEGihH48Sfu5LaMNNz7z0AAaKkRg Accept-Language: fr-FR, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Agree. Nicolas has identified that issue while working on the SysML for Modelica WG. In fact deep nested connectors are the ones that can deal with it thanks to the propertyPath property of the NestedConnectorEnd. I agree with Sandy : the issue about .ambiguous block hierarchy. initially raised to deal with that problem should be revised: by itself, the block hierarchy is not ambiguous. The point is that, as defined today, UML relationships are unable to deal with composite structures which have more than one level. Therefore, to me it is an UML issue, first. There is the same issue with Comment.s annotatedElement property and Constraint.s constrainedElement property and maybe others that I.ve not identified yet. Yves From: Fredrick A Steiner [mailto:fsteiner@raytheon.com] Sent: jeudi 9 démbre 2010 19:25 To: Tim Weilkiens; sysml-rtf Subject: Re: Another issue with allocate This is a bigger problem than allocation... It's really a problem with specifying context for nested parts. Don't deep nested connectors have the same issue? Certainly requirement relationships do. So, can part specific properties also handle connectors, allocations, and requirement relations? Cheers, -Rick Rick Steiner Raytheon Integrated Defense Systems 858.522.2008 -------------------------------------------------------------------------------- From: "Tim Weilkiens" [Tim.Weilkiens@oose.de] Sent: 12/09/2010 06:54 PM CET To: Subject: Another issue with allocate Thanks for help for my previous allocate issue. I.m sorry, but here comes another one. See screenshot: The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that.s ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. I.ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn.t work. MagicDraw doesn.t allow blocks to be owner of a allocate. I.m not sure whether it is a tool issue or if I.ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I.m not sure if that.ll solve my problem. Any ideas? Thanks, Tim ----------------------------------------------------------------- Tim Weilkiens Managing Director OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßnbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 Managing Directors Christian Weiss, BjöSchneider, Tim Weilkiens Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de 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.