Issue 17255: 9.3.2.9 What is InterfaceBlock? (sysml-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: 9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now. InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort. Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties? Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only" constraint [4] - it must be constraint[4] for FullPort??? Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: March 20, 2012: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: End of Annotations:===== s is issue # 17255 From: Nerijus Jankevicius 9.3.2.9 What is InterfaceBlock? 9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now. InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort. Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties? Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only" constraint [4] - it must be constraint[4] for FullPort??? X-Trusted-NM: yes From: Nerijus Jankevicius Subject: Value properties in InterfaceBlocks Date: Thu, 12 Apr 2012 12:18:26 +0300 Cc: Conrad Bock To: "sysml-rtf@omg.org (sysml-rtf@omg.org)" X-Mailer: Apple Mail (2.1084) returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! From: "BERNARD, Yves" To: Nerijus Jankevicius , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: Conrad Bock Date: Thu, 12 Apr 2012 11:42:31 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0YjMrMoCL+cOuCTO++03iI8T4HywAAi6mQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Hi Nerijus, The initial intent was to prevent Interface blocks to have .an internal structure. since their primary purpose is to type proxy port. To me, this is what this constraint#2 intends to implies. I agree that we can probably do better. And I suggest changing it for v1.4 with the following one: Constraint [2] . Interface blocks cannot have internal connectors {OCL} self.ownedConnector->isEmpty() What do you think? Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: jeudi 12 avril 2012 11:18 To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=J7sHVtb5MU0AtJCNiytI09+Ba3X7SnC1OQtlwDAaJFA=; b=y042PuaD6WkKMs1CKAFfTFcy98k0DTTIP8MH3GfjN/5PmqXIxIiQjtNE/YwYkrW6wp bn2+oiWu6zpZEGwKwadg9OAcQkcmB1ZScrd4QVHKSg2efSbtTRCwU0EFl/ec2zzshe+r 3/Rhn7RWE2M7CP+ihRrnkQOM67yKdHWEi3lTjNjiUgtuY3oAyXh+3K2Pc1fwh91R2eLe IrSBtfpLya4S9PW0lqYBWBxahUum4gNsU+DNbUAU84Gt8Hri4g0aIVtn1RmQ5kPLYpoI 8hozgUFlhqP/u6rCzl0/RDV67lhS5EYzhJ7fzC2fovDFOKB2/TuDam54ymtnVupYLWjN RW2A== From: "Sanford Friedenthal" To: "'Nerijus Jankevicius'" , Cc: "'Conrad Bock'" Subject: RE: Value properties in InterfaceBlocks Date: Thu, 12 Apr 2012 09:51:30 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0YjNymcVajhFuARXKOfNUHfnJEJQAJkaqA Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! From: "BERNARD, Yves" To: Sanford Friedenthal , "'Nerijus Jankevicius'" , "sysml-rtf@omg.org" CC: "'Conrad Bock'" Date: Fri, 13 Apr 2012 08:58:28 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0YjNymcVajhFuARXKOfNUHfnJEJQAJkaqAACNiOSA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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-Trusted-NM: yes Subject: Re: Value properties in InterfaceBlocks From: Nerijus Jankevicius Date: Fri, 13 Apr 2012 10:17:26 +0300 Cc: Sanford Friedenthal , "sysml-rtf@omg.org" , "'Conrad Bock'" To: "BERNARD, Yves" X-Mailer: Apple Mail (2.1084) Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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: "BERNARD, Yves" To: Nerijus Jankevicius CC: Sanford Friedenthal , "sysml-rtf@omg.org" , "'Conrad Bock'" Date: Fri, 13 Apr 2012 12:36:53 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0ZRRPf+Rwqb7h6SOy6crqIvqHvSwAF99/A Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=hBHVHOQgtSHcduVcTqURiG93XO3naX01a7goQN2CGYs=; b=T1Of0oTfkAFCETDO329vDbPc/CBrDrDboZqxinW7UYSqrhH9NNYJLtQTQ1MPK+Q1Ji 33IKUly2INW9QkTVU5UPGVSfBanw0enNDoukbNGWhxI+8YrTUkoZGZeKpM64H0S59Fl1 vZZNRAIObqSwCRl2P8M7cgc/ZE88WiIzoFTavUQ2Q1IpFH9grHXZUVYw4LEIzvTZs/2s oJOu/fZV+kKm0FCnA13mFDgbahkMCT0vXiLuZlyzkIzP/ZPdI4G2iOpf1ChYhVSNcBlu DkatT16SevCN4QuVz2Rv2anbJAfKhaITFtlPoymt0gATGPHNm43Vh4uv9Uk5zsxHThT5 yoUQ== From: "Sanford Friedenthal" To: "'BERNARD, Yves'" , "'Nerijus Jankevicius'" Cc: , "'Conrad Bock'" Subject: RE: Value properties in InterfaceBlocks Date: Fri, 13 Apr 2012 07:58:47 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0ZRRPf+Rwqb7h6SOy6crqIvqHvSwAF99/AAAPIUKA= Yves, Nerijus The original question was whether value properties should be allowed in Interface Blocks. The answer should be yes. That has certainly been the intent from early on. If our language constrains this, we need to fix the language. We may need to make more clear delineations between the different types of properties in order to support this. If so, let.s file an issue with this as the motivation and prepare a proposed resolution. We can.t have the language determine the needs. We should determine what we want from the language and the language should provide it where ever practical. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 13, 2012 6:37 AM To: Nerijus Jankevicius Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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: "BERNARD, Yves" To: Sanford Friedenthal , "'Nerijus Jankevicius'" CC: "sysml-rtf@omg.org" , "'Conrad Bock'" Date: Fri, 13 Apr 2012 14:03:27 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0ZRRPf+Rwqb7h6SOy6crqIvqHvSwAF99/AAAPIUKAAAEEW4A== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Sandy, I agree. Nerijus, Would fill the issue? I will then write a proposal we can discuss in the RTF. Thanks, Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: vendredi 13 avril 2012 13:59 To: BERNARD, Yves; 'Nerijus Jankevicius' Cc: sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Yves, Nerijus The original question was whether value properties should be allowed in Interface Blocks. The answer should be yes. That has certainly been the intent from early on. If our language constrains this, we need to fix the language. We may need to make more clear delineations between the different types of properties in order to support this. If so, let.s file an issue with this as the motivation and prepare a proposed resolution. We can.t have the language determine the needs. We should determine what we want from the language and the language should provide it where ever practical. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 13, 2012 6:37 AM To: Nerijus Jankevicius Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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. 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-Trusted-NM: yes Subject: Re: Value properties in InterfaceBlocks From: Nerijus Jankevicius Date: Fri, 13 Apr 2012 16:03:20 +0300 Cc: Sanford Friedenthal , "sysml-rtf@omg.org" , "'Conrad Bock'" To: Yves BERNARD , Juergen Boldt X-Mailer: Apple Mail (2.1084) Clarification of the InterfaceBlock constraint is the issue # 17255. Juergen will attach this discussion thread to it. The NEW issue - clarification, what "part property" is, as new port types typed by Blocks changed everything, they fit into "part properties" definition. SysML 1.3, Page 43 : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Juergen, please assign the number. Nerijus On Apr 13, 2012, at 3:03 PM, BERNARD, Yves wrote: Sandy, I agree. Nerijus, Would fill the issue? I will then write a proposal we can discuss in the RTF. Thanks, Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: vendredi 13 avril 2012 13:59 To: BERNARD, Yves; 'Nerijus Jankevicius' Cc: sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Yves, Nerijus The original question was whether value properties should be allowed in Interface Blocks. The answer should be yes. That has certainly been the intent from early on. If our language constrains this, we need to fix the language. We may need to make more clear delineations between the different types of properties in order to support this. If so, let.s file an issue with this as the motivation and prepare a proposed resolution. We can.t have the language determine the needs. We should determine what we want from the language and the language should provide it where ever practical. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 13, 2012 6:37 AM To: Nerijus Jankevicius Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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. 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: "BERNARD, Yves" To: Sanford Friedenthal , "'Nerijus Jankevicius'" , "sysml-rtf@omg.org" CC: "'Conrad Bock'" Date: Fri, 13 Apr 2012 08:58:28 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0YjNymcVajhFuARXKOfNUHfnJEJQAJkaqAACNiOSA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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-Trusted-NM: yes Subject: Re: Value properties in InterfaceBlocks From: Nerijus Jankevicius Date: Fri, 13 Apr 2012 10:17:26 +0300 Cc: Sanford Friedenthal , "sysml-rtf@omg.org" , "'Conrad Bock'" To: "BERNARD, Yves" X-Mailer: Apple Mail (2.1084) Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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: "BERNARD, Yves" To: Nerijus Jankevicius CC: Sanford Friedenthal , "sysml-rtf@omg.org" , "'Conrad Bock'" Date: Fri, 13 Apr 2012 12:36:53 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0ZRRPf+Rwqb7h6SOy6crqIvqHvSwAF99/A Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=hBHVHOQgtSHcduVcTqURiG93XO3naX01a7goQN2CGYs=; b=T1Of0oTfkAFCETDO329vDbPc/CBrDrDboZqxinW7UYSqrhH9NNYJLtQTQ1MPK+Q1Ji 33IKUly2INW9QkTVU5UPGVSfBanw0enNDoukbNGWhxI+8YrTUkoZGZeKpM64H0S59Fl1 vZZNRAIObqSwCRl2P8M7cgc/ZE88WiIzoFTavUQ2Q1IpFH9grHXZUVYw4LEIzvTZs/2s oJOu/fZV+kKm0FCnA13mFDgbahkMCT0vXiLuZlyzkIzP/ZPdI4G2iOpf1ChYhVSNcBlu DkatT16SevCN4QuVz2Rv2anbJAfKhaITFtlPoymt0gATGPHNm43Vh4uv9Uk5zsxHThT5 yoUQ== From: "Sanford Friedenthal" To: "'BERNARD, Yves'" , "'Nerijus Jankevicius'" Cc: , "'Conrad Bock'" Subject: RE: Value properties in InterfaceBlocks Date: Fri, 13 Apr 2012 07:58:47 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0ZRRPf+Rwqb7h6SOy6crqIvqHvSwAF99/AAAPIUKA= Yves, Nerijus The original question was whether value properties should be allowed in Interface Blocks. The answer should be yes. That has certainly been the intent from early on. If our language constrains this, we need to fix the language. We may need to make more clear delineations between the different types of properties in order to support this. If so, let.s file an issue with this as the motivation and prepare a proposed resolution. We can.t have the language determine the needs. We should determine what we want from the language and the language should provide it where ever practical. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 13, 2012 6:37 AM To: Nerijus Jankevicius Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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: "BERNARD, Yves" To: Sanford Friedenthal , "'Nerijus Jankevicius'" CC: "sysml-rtf@omg.org" , "'Conrad Bock'" Date: Fri, 13 Apr 2012 14:03:27 +0200 Subject: RE: Value properties in InterfaceBlocks Thread-Topic: Value properties in InterfaceBlocks Thread-Index: Ac0ZRRPf+Rwqb7h6SOy6crqIvqHvSwAF99/AAAPIUKAAAEEW4A== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Sandy, I agree. Nerijus, Would fill the issue? I will then write a proposal we can discuss in the RTF. Thanks, Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: vendredi 13 avril 2012 13:59 To: BERNARD, Yves; 'Nerijus Jankevicius' Cc: sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Yves, Nerijus The original question was whether value properties should be allowed in Interface Blocks. The answer should be yes. That has certainly been the intent from early on. If our language constrains this, we need to fix the language. We may need to make more clear delineations between the different types of properties in order to support this. If so, let.s file an issue with this as the motivation and prepare a proposed resolution. We can.t have the language determine the needs. We should determine what we want from the language and the language should provide it where ever practical. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 13, 2012 6:37 AM To: Nerijus Jankevicius Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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. 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-Trusted-NM: yes Subject: Re: Value properties in InterfaceBlocks From: Nerijus Jankevicius Date: Fri, 13 Apr 2012 16:03:20 +0300 Cc: Sanford Friedenthal , "sysml-rtf@omg.org" , "'Conrad Bock'" To: Yves BERNARD , Juergen Boldt X-Mailer: Apple Mail (2.1084) Clarification of the InterfaceBlock constraint is the issue # 17255. Juergen will attach this discussion thread to it. The NEW issue - clarification, what "part property" is, as new port types typed by Blocks changed everything, they fit into "part properties" definition. SysML 1.3, Page 43 : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Juergen, please assign the number. Nerijus On Apr 13, 2012, at 3:03 PM, BERNARD, Yves wrote: Sandy, I agree. Nerijus, Would fill the issue? I will then write a proposal we can discuss in the RTF. Thanks, Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: vendredi 13 avril 2012 13:59 To: BERNARD, Yves; 'Nerijus Jankevicius' Cc: sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Yves, Nerijus The original question was whether value properties should be allowed in Interface Blocks. The answer should be yes. That has certainly been the intent from early on. If our language constrains this, we need to fix the language. We may need to make more clear delineations between the different types of properties in order to support this. If so, let.s file an issue with this as the motivation and prepare a proposed resolution. We can.t have the language determine the needs. We should determine what we want from the language and the language should provide it where ever practical. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, April 13, 2012 6:37 AM To: Nerijus Jankevicius Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus, Note that Interface blocks are kinds of blocks too and therefore proxy ports shall also be considered .part properties. (SysML sense). Then forbidding .part properties. on InterfaceBlocks would also prevent proxy ports to be nested. IBD is not the internal structure of a block but only a representation of it. Deleting all the IBD from a block does not delete its internal structure and most of the modeling tools (including MagicDraw I guess) allow to create the model element defining an internal structure without an IBD (i.e. directly through the browser, using a script, .). The concept of .internal. vs .external. came in UML with that of .structured classifier.. The .port. concept is used to designed properties which constitute the .external. structure while other (non-port) properties together with the connectors define the .internal. structure. Assume we disallow all features added by the UML::StructuredClassifier metaclass for an InterfaceBlock, we get something very similar to a UML port (from a tool implementation point of view at least). The point is we lose the ability to nest proxy port. Then if you just add the ability to own ports (but not connectors) you will restore the ability of defining an external structure and of nesting ports but not that one of defining an internal structure which generate the issue. Yves From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: vendredi 13 avril 2012 09:17 To: BERNARD, Yves Cc: Sanford Friedenthal; sysml-rtf@omg.org; 'Conrad Bock' Subject: Re: Value properties in InterfaceBlocks Yves, You are right, ports are parts in UML, but in SysML we have special definition, what is the "part property" : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. " Of course, full ports are now typed by Blocks,so can be considered as part properties :) This is one more issue, the text should say "part properties" are properties which are NOT PORTS. InterfaceBlock constraint may say that InterfaceBlock can't own "part properties" and maybe internal structure (IBD diagram?). BTW, in previous email you suggested to disallow Connectors. Are you sure it can't own for example binding connector between two proxy ports (a la delegation pattern/interface)? What do you think? Nerijus Sandy, I.m afraid we cannot state that since, according to the definition of .part. we get from UML, a port (either proxy or full) shall actually be considered a UML::StructuredClassifier::part, cf. v2.4.1, §9.3.14: · ./part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 12 avril 2012 15:52 To: 'Nerijus Jankevicius'; sysml-rtf@omg.org Cc: 'Conrad Bock' Subject: RE: Value properties in InterfaceBlocks Nerijus We should allow value properties in interface blocks. That was the intent. Please propose a resolution to the issue and we can get on a near term ballot. The resolution should say that the interface block cannot contain part properties. Thx. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, April 12, 2012 5:18 AM To: sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Conrad Bock Subject: Value properties in InterfaceBlocks returning to a hot discussion we had in Reston: InterfaceBlock can't own composite properties, so value properties too. (constraint [2] - Interface blocks cannot have composite properties that are not ports.) Conrad and Eldad said value properties are not mandatory composite, there is no such rule in the spec, but there is: page 43 of SysML 1.3 spec says: "A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. " So, as a consequence of InterfaceBlock constraint, we can't define and use value properties in InterfaceBlocks. Please help me to decide ASAP, should I ignore this constraint or not. Should we allow value properties in InterfaceBlocks or not? We have SysML1.3 implementation beta release in two weeks. Additionally, does it make sense to use reference and shared properties too? Thanks, -- 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 - UML made simple! 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. 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. 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. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=mrdwihoSTCUu3AkjQmYN6TFz4yKdbWkeINNImpJdAMI=; b=L2J8U672L1FC9FbxdfExnKm3CUsxznM+5tbYoRM99nxzme4P4ozNVfuADFqmKndNy4 OeUgPafQDy5/nEEyYmuq9LaEAlUMBfdIS9U2Nu/NeUHYDebdN9GIPP0RK/HjjNU7C9Cu xxx/Oy7PqtgyILpjT/IAY40J7RVE5wKaJF0lGYq0XNyPRUU/oAF5CyyZq+GXJAXpb5nN D6SYQELVi0WX1YLwSvhebXVLRCHShiNGuJLg+B4KktAwbX2GmFh4erq3iPgOAl4R078b jdiSsqvK7G13OUVMNqSoDAnqdsAvu2SOe9ZbEXXcZg+8F5ptoVGycglLsAvn6M+JNq+C vFoA== From: "Sanford Friedenthal" To: "'Bock, Conrad'" Cc: "''Eldad Palachi''" , Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Date: Fri, 23 Nov 2012 10:57:14 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3JkOV/RwMEHrKqSUOoK0aeOs215AAAHx4Q Conrad, Ok. I have proposed updated text to Issue 17255 to improve the clarity and conciseness. Current text is: 9.3.2.9 InterfaceBlock Description Interface blocks cannot have behaviors, including classifier behaviors or methods, or internal parts. Sandy proposed update to revised text: They are used to type ports without imposing realization constraints on the owning block. Current proposed revised text: They are used when the modeler wants to declare that a block should only specify interactions with other blocks, for example, with flow properties, directed features, and constraint properties. These interactions are supported by behaviors defined in other classifiers that specialize or realize interface blocks. See Subclauses 9.3.2.12 and 9.4.4 for usage.. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, November 23, 2012 10:41 AM To: Sanford Friedenthal Cc: 'Eldad Palachi' (eldad.palachi@il.ibm.com) Subject: RE: SysML, next issue cleanup, chapter leads, 17255 P.S. This is the current wording Eldad and I are considering. > They are used to specify black box interfaces without imposing > implementation constraints. This has some circularity (uses the term "interface" to define "interface block"), and the term "implement" is a bit informal for this part of the spec. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Fri, 23 Nov 2012 11:06:26 -0500 Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Thread-Topic: SysML, next issue cleanup, chapter leads, 17255 Thread-Index: Ac3JkOV/RwMEHrKqSUOoK0aeOs215AAAHx4QAAB97yA= Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Sandy, > Ok. I have proposed updated text to Issue 17255 to improve the clarity and > conciseness. > They are used to type ports without imposing realization constraints on the > owning block. Sorry, realization isn't a constraint. And it's too short to respond to the issue filed, which asked for more explanation. Eldad and I have exchanged a fair amount of email on the current text. It uses terminology and elaboration consistent with the rest of the spec. I'd suggest we go with it unless someone sees something broken. Conrad 17255_resolved1.doc Disposition: Resolved OMG Issue No: 17255 Title: 9.3.2.9 What is InterfaceBlock? Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Summary: 9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now. InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort. Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties? Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only" constraint [4] - it must be constraint[4] for FullPort??? Resolution: Include more motivation in the Description section in 9.3.2.9. Constraint [2] should also except value properties. Constraint [3] does not require ports on interface blocks to be proxy ports. It only requires them to be typed by interface blocks. SysML 1.3 does not have a constraint [4] in section 9.3.2.9. Revised Text: In section 9.3.2.9, at the end of the first paragraph, add: They are used when the modeler wants to declare that a block should only specify interactions with other blocks, for example, with flow properties, directed features, and constraint properties. These interactions are supported by behaviors defined in other classifiers that specialize or realize interface blocks. See Subclauses 9.3.2.12 and 9.4.4 for usage.. In section 9.3.2.9, at the end of the constraint [2], add: or value properties Disposition: Resolved DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; bh=O2NYEnlrw2F1erfaQSlcFp3nUoFDgdt68r4lqEXWvpo=; b=gQQvDvm/7DnU2H+Qq3z6E8Hl4ECrjM6v04HQBTyS+yMUVd7r3ZeoIEzlk4BiI2vZoX 59lsdsHb+UHhJhxomg1kx72+iV8a0nv5QWTeRW6n04wqzfzBTxcgBgk2HfpjstVZwlAg 3XdbUSylR1RCKhXQYVjj9JssT/5LwkUTfSx/xXF9lto4re/Op7ZYOZCnLby9HOCk4F/a Tx8C3Zi2sHdj6EhsiGm/NzyHaJCRe0OQsQfgVNSpDWpXXGbm2SKhjLz3rh2P6eDXDR65 dcxtIcHdUu8Zd3zJNYX+qiIStPFeM5p1H0zkMCpVXubOMIo7WjjvHWpWOEg+Fnuyvg9L ZNmQ== From: "Sanford Friedenthal" To: "'Bock, Conrad'" , Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Date: Fri, 23 Nov 2012 11:10:38 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3JkOV/RwMEHrKqSUOoK0aeOs215AAAHx4QAAB97yAAAGo08A== Conrad I don't' find the current text clear or consise. Please pull it for more discussion. Sandy -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, November 23, 2012 11:06 AM To: sysml-rtf@omg.org Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Sandy, > Ok. I have proposed updated text to Issue 17255 to improve the clarity and > conciseness. > They are used to type ports without imposing realization constraints on the > owning block. Sorry, realization isn't a constraint. And it's too short to respond to the issue filed, which asked for more explanation. Eldad and I have exchanged a fair amount of email on the current text. It uses terminology and elaboration consistent with the rest of the spec. I'd suggest we go with it unless someone sees something broken. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Fri, 23 Nov 2012 11:12:03 -0500 Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Thread-Topic: SysML, next issue cleanup, chapter leads, 17255 Thread-Index: Ac3JkOV/RwMEHrKqSUOoK0aeOs215AAAHx4QAAB97yAAAGo08AAACXUg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Sandy, > I don't' find the current text clear or consise. > Please pull it for more discussion. It already is. That's why I sent my original email to just you and Eldad. Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; bh=CKrVDzJFStQKulST54ScdpX5YFohJIHuvyy5GlM1B5E=; b=zLdBgF/KufzlbaYStuBm00qMUO7Dj2jN+tVJCZyKsohBhVEPJn8qlYRpgtJv9FPC28 5GObAwRFdJcfin38dWMrWJ5OpAInNjuzyI7+jL7FLWEPt/XBS915eDKLFmONlCDYKMUX 7LiaGtotozaqDHiYkFrX9OmSkPU8FiFio+lxecG5HarqimZT/DmnyqsnLtdztYAv5tyJ ruxEa31akklvGXly3r71wWZTKCYMuElHFWj1PNRG+J0W2SfImfLwBEIh3lF1iZR08lJX hhLkEHVG9fyED69O2UCFJG+Tc8xI1mT7GO+fPob7C7SDQXb/CydxkszprM/1+hLdpgEm wJxQ== From: "Sanford Friedenthal" To: "'Bock, Conrad'" , Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Date: Fri, 23 Nov 2012 11:13:08 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3JkOV/RwMEHrKqSUOoK0aeOs215AAAHx4QAAB97yAAAGo08AAACXUgAAAQtzA= Ok. Thx. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, November 23, 2012 11:12 AM To: sysml-rtf@omg.org Subject: RE: SysML, next issue cleanup, chapter leads, 17255 Sandy, > I don't' find the current text clear or consise. > Please pull it for more discussion. It already is. That's why I sent my original email to just you and Eldad.