Issue 17307: clarification, what "part property" is (sysml-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: 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. " Resolution: Revised Text: Actions taken: April 13, 2012: received issue Discussion: End of Annotations:===== ted-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: Burkhart Roger M To: Sanford Friedenthal , "sysml-rtf@omg.org" Date: Sun, 22 Jul 2012 19:53:58 -0500 Subject: RE: Comments and Proposed Updates to: draft ballot 2 available for discussion through Friday, August 3, 2012 Thread-Topic: Comments and Proposed Updates to: draft ballot 2 available for discussion through Friday, August 3, 2012 Thread-Index: Ac1mtZGhFXy2219yTAO8Wn3juoG66gAi/mMgAEpGC/AAALxcEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-07-22_06:2012-07-20,2012-07-22,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-07-22_06:2012-07-20,2012-07-22,1970-01-01 signatures=0 Sandy-- On Issue 17246, my resolution had already proposed to keep the current first sentence of the paragraph in question ("It is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects.") I'm OK with your new version, however, including making the first sentence for engineers in general, and your single sentence to follow ("As a general purpose modeling language, SysML is intended to be used with a diverse set of discipline and domain specific modeling languages.") On Issue 17307, thanks for the catch that my editing instructions hadn't removed the old sentence now subsumed by the new. I'll fix it in the next update. On Issue 15075 ("Including Property Notation for Redefinition and Subsetting"), I didn't try to address it in this ballot. This ballot was to include only resolutions we expect to be non-controversial, and I don't know whether that one will be or not. I'd prefer to go one step at a time, and postpone any further consideration on that additional issue until after we finish this ballot. --Roger From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, July 21, 2012 9:23 AM To: sysml-rtf@omg.org Subject: Comments and Proposed Updates to: draft ballot 2 available for discussion through Friday, August 3, 2012 SysML RTF I have included the following comments and proposed updates to the resolutions per below. Thanks. Sandy Issue 17246 Part 1, 4th paragraph Current text: It is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers. Text in proposed resolution: The SysML language is intended to provide a common systems engineering context which can be integrated with the diverse modeling languages used by systems engineers. Contents of additional modeling languages, tools, and techniques can be mapped into a SysML systems model for use across the systems development life cycle. Suggested modified text in proposed resolution: (modifications in strikethrough and yellow highlighted text) It is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. As a general purpose modeling language, SysML is intended to be used with a diverse set of discipline and domain specific modeling languages. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers. Issue 17307 In addition to the proposed text change, suggest you also delete the sentence in the current text that is highlighted below since it is subsumed in the proposed modified text. Current text: 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. Constraint properties are further defined in Clause 10, .Constraint Blocks.. A port is another category of property, as further defined in Clause 9, .Ports and Flows.. Suggested modified text in proposed resolution: (modifications in strikethrough and yellow highlighted text) A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special cases of ports and constraint properties. Ports are further defined in Clause 9, .Ports and Flows,. and constraint properties are further defined in Clause 10, .Constraint Blocks.. A port is another category of property, as further defined in Clause 9, .Ports and Flows. Issue 17120 While we address the addition of the derived property notation to blocks, this seems like a good time to address another somewhat related issue 25075 to include redefinition and subsetting in the table. If it is too late to address in this ballot, please address .Issue 15075: Including Property Notation for Redefinition and Subsetting. in next ballot. Issue 17250 Suggest we add the operations label to the compartment to be consistent with the block notation in Table 8.2.1. Although it may be ok not to include a compartment label, we should encourage consistent use of the notation in the specification to avoid confusion. Issue 13153 I don.t understand the motivation for adding an additional action stereotype called ReadExecution. Shouldn.t this be something that should be done in UML? Issue 16406 The resolution of this issue on the rate stereotype refers to Issue 13153. I don.t see how the proposed resolution to Issue 13153 addresses this issue. Issue 15302 The create message should be a dashed line in the figure as indicated in the statement of the issue. Issue 17445 This resolution proposes adding some existing state machine notation to the diagram tables. Adding the composite notation is good since this is pretty intuitive and standard. I am questioning whether adding the connection point reference notation (via .)is sufficiently used and intuitive to warrant adding to SysML notation tables. Can we include this separately so it can be voted on separately. From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Friday, July 20, 2012 4:24 PM To: sysml-rtf@omg.org Subject: draft ballot 2 available for discussion through Friday, August 3, 2012 A draft Ballot 2 is available for review and discussion on the SysML 1.4 RTF wiki at http://www.omg.org/members/sysml-rtf-wiki. (Click on the Ballot 2 link.) Ballot 2 will be open for discussion through Friday, August 3, 2012. The normal two-week voting period will then begin by Monday, August 6. Following are ballot review instructions which appear at the bottom of the ballot page: The review period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which will be frozen at the start of voting. If you have any concerns or questions about any of the proposed resolutions, please send a message to the sysml-rtf@omg.org mailing list. This ballot is intended to continue our cleanup of (relatively) easily disposed issues, picking up where ballot 1 left off. These resolutions are intended to be noncontroversial. If significant debate or discussion is raised during the review period, we will likely remove those resolutions from ballot 2 prior to voting. A review and discussion of this ballot will occur on the regularly scheduled RTF telecon on Thursday, July 26, 2012 at 10:00 ET, and in any subsequent telecons as required. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Thu, 26 Jul 2012 09:07:57 -0400 Subject: RE: draft ballot 2 available for discussion through Friday, August 3, 17307 (clarification, what "part property" is) Thread-Topic: draft ballot 2 available for discussion through Friday, August 3, 17307 (clarification, what "part property" is) Thread-Index: Ac1rLo9c0pgdQ6kAQbaO5nxQsX5eYw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ballot2ers, 17307 excludes ports from the definition of part properties, but full ports are "parts on the boundary". In verbal discussion we've been using the term "internal part" alot and I think it would be good to add it to the standard terminology (a composite property typed by a block that isn't a port). Then full ports can remain parts, and still be distinguished from internal parts.