Issue 11496: It is not allowed in UML to display stereotypes of related elements (sysml-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references): a) Stereotypes i. Block stereotypes are displayed on parts ii. Block stereotypes are displayed on object nodes iii. Parameter stereotypes are displayed on ActivityParameterNode iv. Behavior or operation stereotypes are displayed on CallActions b) Tags i. Block allocations are displayed on parts ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype c) Constraints i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30) Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: September 19, 2007: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Some of the cases raised by this issue may be covered by the resolution for Issue 11819, Internal Block Diagram Extensions, including the discussion within that resolution. Other cases raised by this issue, may not be fully covered by that issue or may require additional mechanisms for the requested display capability. The issue is being deferred so that all these cases can continue to be explored. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== m: "Nerijus Jankevicius" This is issue # 11496 It is not allowed in UML to display stereotypes of related elements Stereotypes, tags and constraints are displayed on elements that can.t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references): a) Stereotypes i. Block stereotypes are displayed on parts ii. Block stereotypes are displayed on object nodes iii. Parameter stereotypes are displayed on ActivityParameterNode iv. Behavior or operation stereotypes are displayed on CallActions b) Tags i. Block allocations are displayed on parts ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype c) Constraints X-WSS-ID: 0K0EJJU-05-JCC-01 Subject: RE: Ballot3: On 11819, 11496: propose (instead) deferring in favour of new notation: <> {property_tag = "val": class_tag ="val2"} Date: Mon, 5 May 2008 10:40:48 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot3: On 11819, 11496: propose (instead) deferring in favour of new notation: <> {property_tag = "val": class_tag ="val2"} Thread-Index: Aciuo5hg4AEJ591cSqG9Bj0VvfkQOwAHu7EA From: Burkhart Roger M To: "Darren R C KELLY" , Cc: "Nerijus Jankevicius" X-OriginalArrivalTime: 05 May 2008 15:40:49.0638 (UTC) FILETIME=[64B4B060:01C8AEC6] Sandy Friedenthal has already recorded an initial vote of "no" on the proposed resolution to issue 11819 based on the message below. In keeping with the ground rules I suggested, given the short period we've ended up for discussion prior to voting, if there is significant debate on any issue I'd prefer to pull it from the pending vote and just replace it with a resolution of "Deferred" so that further discussion can carry over to the next RTF. Anyone can raise a request to pull an issue for subsequent reconsideration prior to voting "no," even after resolutions have already been frozen for voting. The UML RTF has withdrawn resolutions for further consideration when there's a consensus that they should be reconsidered. Note that for Ballot 4, there will be no option to slip a resolution to a subsequent ballot, which is all the more reason to raise any concerns this week while discussion is still open and changes can still be considered. If concerns are raised next week after Ballot 4 has already begun voting, the only recourse would be either to vote no, or to pull any resolution so that no vote on an issue takes place at all, in which case it would automatically be deferred. I'll end up using a straw poll of the RTF before making any such decision. On this particular issue, Darren raises additional cases of wanting to show stereotypes of related elements even beyond those originally raised by issue 11496, and proposes further extensions to cover a wider range of cases. Here are two options for how we could proceed: 1. Go ahead with the proposed "duplicate/merged" resolution of Issue 11496 as having been substantially addressed by Issue 11819 (which discusses specific cases that it raised), and then raise a new issue covering additional cases which are requested to be covered, with more specific detail about cases not already covered by 11819. 2. Pull the resolution for Issue 11496 from Ballot 3 and include it in Ballot 4 with a "Deferred" resolution. Even with this resolution, a new issue could also be raised to provide more specific detail about wider cases also to be considered, as well as additional detail about proposed new notations as included in the message below. My personal preference would be to go with Option 1 since it leaves the current ballots alone and doesn't preclude covering additional cases in greater detail beyond those already covered by 11819. I'm willing to go with Option 2, however, if keeping the original issue rather than raising a new one is preferred by those concerned about the original issue. Darren or Nerijus, if you could let me know whether you have a strong preference between the two options, I'll use that as an initial basis to move forward in the next day or two. --Roger -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Monday, May 05, 2008 5:29 AM To: sysml-rtf@omg.org Cc: Nerijus Jankevicius Subject: Ballot3: On 11819, 11496: propose (instead) deferring in favour of new notation: <> {property_tag = "val": class_tag ="val2"} 11496 It is not allowed in UML to display stereotypes of related elements. [Duplicates 11819] I do not agree that 11496 duplicates 11819 (as the diagrams below from MD SysML demonstrate). It is not so that: ' All the cases itemized by Issue 11496 are covered either by explicit diagram extensions on activities or the use of compartments from a property type on an ibd.' Because 11496 does not mention IBDs anywhere, and I know the problem to be much broader. This is the situation addressed by the proposed resolution for 11819 ("show block stereotypes at property elements typed by those blocks in an ibd"), however that resolution does not at all cover cases that don't involve IBDs. The problem also arises with stereotypes of properties in Block compartments: [diagram omitted for size ...] Note two problems above: top_speed: the ValueType's unit metadata (the tagged value from the <> applied to the Type of the Property) has been "screened" by the assignment of <> with the tagged value /satisfies = "must be fast". There are many other example like this. if one (send me to Azkaban already) uses an instance of the Block, the Slots are now in fact expressing "tertiary" stereotypes to display the Unit metadata. The proposed resolution involves leveraging the :colon notation for block compartments in an IBD (which I support for :values compartment) for stereotypes (for which I think we need a better solution): 'The internal block diagram already allows any compartment of a block or value type that types a property to be shown within the property box on the diagram. Section 8.3.1.2 Internal Block Diagram, subsection .Compartments on internal properties. specifies, .SysML permits any property shown on an internal block diagram to also show compartments within the property box. These compartments may be given standard or user-customized labels just as on block definitions.. A valid use of this option is to show a stereotype compartment, with or without any stereotype properties, as one of the compartments on the property box. This provides an existing graphical option to display the stereotype for a block or value type that types a property on an ibd.' While I can see the benefits (in terms of reuse of existing SysML specs and notations) of the resolution proposed for 11819, it does not cover elegantly a wide range of cases - also UML situations - and I would like to suggest here deferring this (as it concerns "secondary stereotypes" in favour of the following suggestion for next round: -------------------------------------------------------------------------------- My suggestion <> {property_tag = "val": class_tag ="val2"} When a "Classifier level" stereotype appears on a Block in a BDD it would appear as follows (the usual notation): <> When it appears on a Property in an IBD it would be prefixed by a colon, thus: <<:ForClassifier>> If there is a Property level stereotype it then reads well in an IBD thus: <> For a value property in a BDD one gets: top_speed : km/h = 110 {Satisfies = must be fast : unit = KilometerPerHour} The tagged values for the Classifier-level ValueType now no longer clash with the tagged values for the Property-level value. It also addresses cases like this, mentioned in the resolution: 'The colon prefix can also be used on an .allocatedFrom. or .allocatedTo. compartment label, as defined in Chapter 15 Allocations, to distinguish an allocation already established on the type of property from the property itself.' This similarly addresses literally hundreds of similar cases quite elegantly. I would like it to be adopted by UML2, eventually, too. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Date: Mon, 05 May 2008 20:28:59 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: sysml-rtf@omg.org Cc: Nerijus Jankevicius Subject: Ballot3: On 11819, 11496: propose (instead) deferring in favour of new notation: <> {property_tag = "val": class_tag ="val2"} X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on mail.nomagicasia.com X-Virus-Status: Clean 11496 It is not allowed in UML to display stereotypes of related elements. [Duplicates 11819] I do not agree that 11496 duplicates 11819 (as the diagrams below from MD SysML demonstrate). It is not so that: ' All the cases itemized by Issue 11496 are covered either by explicit diagram extensions on activities or the use of compartments from a property type on an ibd.' Because 11496 does not mention IBDs anywhere, and I know the problem to be much broader. This is the situation addressed by the proposed resolution for 11819 ("show block stereotypes at property elements typed by those blocks in an ibd"), however that resolution does not at all cover cases that don't involve IBDs. The problem also arises with stereotypes of properties in Block compartments: Note two problems above: top_speed: the ValueType's unit metadata (the tagged value from the <> applied to the Type of the Property) has been "screened" by the assignment of <> with the tagged value /satisfies = "must be fast". There are many other example like this. if one (send me to Azkaban already) uses an instance of the Block, the Slots are now in fact expressing "tertiary" stereotypes to display the Unit metadata. The proposed resolution involves leveraging the :colon notation for block compartments in an IBD (which I support for :values compartment) for stereotypes (for which I think we need a better solution): 'The internal block diagram already allows any compartment of a block or value type that types a property to be shown within the property box on the diagram. Section 8.3.1.2 Internal Block Diagram, subsection .Compartments on internal properties. specifies, .SysML permits any property shown on an internal block diagram to also show compartments within the property box. These compartments may be given standard or user-customized labels just as on block definitions.. A valid use of this option is to show a stereotype compartment, with or without any stereotype properties, as one of the compartments on the property box. This provides an existing graphical option to display the stereotype for a block or value type that types a property on an ibd.' While I can see the benefits (in terms of reuse of existing SysML specs and notations) of the resolution proposed for 11819, it does not cover elegantly a wide range of cases - also UML situations - and I would like to suggest here deferring this (as it concerns "secondary stereotypes" in favour of the following suggestion for next round: -------------------------------------------------------------------------------- My suggestion <> {property_tag = "val": class_tag ="val2"} When a "Classifier level" stereotype appears on a Block in a BDD it would appear as follows (the usual notation): <> When it appears on a Property in an IBD it would be prefixed by a colon, thus: <<:ForClassifier>> If there is a Property level stereotype it then reads well in an IBD thus: <> For a value property in a BDD one gets: top_speed : km/h = 110 {Satisfies = must be fast : unit = KilometerPerHour} The tagged values for the Classifier-level ValueType now no longer clash with the tagged values for the Property-level value. It also addresses cases like this, mentioned in the resolution: 'The colon prefix can also be used on an .allocatedFrom. or .allocatedTo. compartment label, as defined in Chapter 15 Allocations, to distinguish an allocation already established on the type of property from the property itself.' This similarly addresses literally hundreds of similar cases quite elegantly. I would like it to be adopted by UML2, eventually, too. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Date: Wed, 07 May 2008 17:05:07 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Burkhart Roger M Cc: sysml-rtf@omg.org, Nerijus Jankevicius , Tim Weilkiens Subject: Re: Ballot3: On 11819, 11496: propose (instead) deferring in favour of new notation: <> {property_tag = "val": class_tag ="val2"} X-Virus-Scanned: ClamAV 0.91.2/7046/Wed May 7 10:35:44 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.2 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_PBL,RDNS_NONE,USER_IN_WHITELIST autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.nomagicasia.com Burkhart Roger M wrote: Sandy Friedenthal has already recorded an initial vote of "no" on the proposed resolution to issue 11819 based on the message below. In keeping with the ground rules I suggested, given the short period we've ended up for discussion prior to voting, if there is significant debate on any issue I'd prefer to pull it from the pending vote and just replace it with a resolution of "Deferred" so that further discussion can carry over to the next RTF. I am for deferring this important issue (hoping Tim is comforted by our desire to address it well). The topic is broader than can be addressed with short discussion time. A deferred issue is a still a very useful issue. On this particular issue, Darren raises additional cases of wanting to show stereotypes of related elements even beyond those originally raised by issue 11496, (Nerijus and I have often discussed many examples, only some of which appeared in his 11496 summary) and proposes further extensions to cover a wider range of cases. Here are two options for how we could proceed: 1. Go ahead with the proposed "duplicate/merged" resolution of Issue 11496 as having been substantially addressed by Issue 11819 (which discusses specific cases that it raised), and then raise a new issue covering additional cases which are requested to be covered, with more specific detail about cases not already covered by 11819. I prefer not to, I don't agree 11496 is completely addressed by 11819, and even for 11819 I prefer the solution proposed in the subject header (which can nevertheless work well with a solution correctly described by ?Roger in 11819). 2. Pull the resolution for Issue 11496 from Ballot 3 and include it in Ballot 4 with a "Deferred" resolution. Yes please. Even with this resolution, a new issue could also be raised to provide more specific detail about wider cases also to be considered, as well as additional detail about proposed new notations as included in the message below. My personal preference would be to go with Option 1 since it leaves the current ballots alone and doesn't preclude covering additional cases in greater detail beyond those already covered by 11819. I think I need to prepare an exhaustive list of cases which demonstrate why 11819 can't work well as proposed. I'm willing to go with Option 2, however, if keeping the original issue rather than raising a new one is preferred by those concerned about the original issue. Darren or Nerijus, if you could let me know whether you have a strong preference between the two options, I'll use that as an initial basis to move forward in the next day or two. I will try to chat with Nerijus a.s.a.p. thanks for your attention to this subtle yet important one, Darren -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30)