Issue 7973: UML 2 Super / Incorrect statement on port visibility (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The updated UML spec p162 states: "UML Superstructure 2.0 Draft Adopted Specification A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default)." This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). Resolution: Revised Text: Replace the first paragraph of the Notation section on p.177, section 9.3.11 (Port) by "A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. The port symbol may be placed either operlapping the boundary of the rectangle symbol denoting that classifier or it may be shown inside the rectangle symbol." Actions taken: December 10, 2004: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== ubject: UML 2 Super / Incorrect statement on port visibility X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 10 Dec 2004 16:56:53 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 12/10/2004 16:56:53, Serialize complete at 12/10/2004 16:56:53 The updated UML spec p162 states: "UML Superstructure 2.0 Draft Adopted Specification A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default)." This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 Issue 7973: UML 2 Super / Incorrect statement on port visibility Issue summary The updated UML spec p162 states: 'UML Superstructure 2.0 Draft Adopted Specification A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default).' This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). Discussion The author of this issue contends that the port notation should not define the visibility of ports through the placement of the port symbol. However, this is what the specification has defined; no discussion as to the removal of this notation has taken place, to my recollection. Moreover, this is a convenient notation to express visibility of ports. The author of this issue is invited to demonstrate, through examples, why this notation is not suitable. -- ThomasWeigert - 17 May 2005 I must admitt that I thought this was only applicable for the frame not for all classifier symbols. When e.g. a class symbol is used in the normal fashion, i.e. with compartments for name, attributes and operations it is not easy to put ports inside the symbol. But when reading the current text this seems to be the idea. So I think I would be in favour of making this a recommended style guide instead of an absolute rule. -- AndersEk - 17 May 2005 I happen to recall this discussion well (I think it was either in oslo or Stockholm), but let's not quibble about that. New arguments have come up since that discussion that favour not tying the graphical placement of structural elements of a composite to their visibility. Specifically, in Sys ML? as well as in several other applications in different domains that have come up from some of our users (e.g. in business modeling), there is a need to be able to connect directly to a part that has public visibility; that is, without having to go through an intervening public port. Unless we start putting parts on the border (which clearly does not scale up well and it looks godawful), we really have no choice. While connecting directly to parts (i.e., without going through an intervening public port and a delegation connector) is not possible in either SDL or UML-RT, it seems useful to be able to do that in other cases. After all, parts are properties and, like other properties such as attributes, they should be able to have either public or private visibility. It is a minor but useful (and, more importantly, required) generalization of what is already there. For those domains, such as UML-RT and SDL where this is not allowed, the appropriate profile simply has to define constraints that force all parts to be non-public. So, if we accept the possibility that parts of a composite can be made public and that they can be connected from the outside, then it will not be possible to retain the convention that things inside the border are necessarily private/protected. If this is the case for parts, then the same reasoning should apply to ports. -- BranSelic - 19 May 2005 Bran, it is not clear why the question of whether the placement of ports should carry special semantics is necessarily connected to the question of whether one can connect to parts directly. Bran's argument seems to be that because we might at some point need to allow direct connection to parts (and that is a big if) we should not have a notation for ports that differentiates between public and private ports. I don't quite see how that follows. -- ThomasWeigert - 04 Jun 2005 I have spent much time with the SysML on their need to connect to parts directly. I believe this need is due to a misunderstanding of what internal structure is and a reaction of a submitter to push their hobby horse which was rejected in the UML2 SysML has insisted on representing items in a manner inconsistent with the UML2, where it would have been very easy to be consistent. I have no sympathy for such. -- ThomasWeigert - 20 May 2005 Couldn't find any technical content in the above, so I'll add a bit more nontechnical content: Thomas, you completely misunderstand what is happening in Sys ML?. Would be glad to discuss sometime. -- ConradBock - 25 May 2005 Conrad, why don't you go into some detail of why the SysML needs to connect directly to parts. As you know, if have provided the relevant chapter to SysML with only leveraging the UML 2 spec and not making any changes. That proposal, I believe accomplished everything they were trying to do without messing around with the UML 2. -- ThomasWeigert - 26 May 2005 Rereading the above, it seems like the issue is whether non-port properties can notated overlapping the border. It would be helpful to allow any property to be shown on the border. As to the semantics of overlapping, I guess people are assuming it means the element is public, but presumably alot of diagrams have fully contained elements that are public. It would be a hassle to put all public properties on the border. This would argue against allowing any property to overlap the border, I guess. Whatever the resolution of the above complications, there are going to be alot of parts that are public and support connectors to them. The only difference between a part and port is the isService / isBehavior forwarding stuff, which are actually the least used aspects among classical systems engineers. They use connectors as contextualized associations, per the RFP requirement that U2P said it supported with composite structure, see http://www.jot.fm/issues/issue_2004_11/column5. Sys ML? also uses connectors to non-part properties, for parametric constraints. -- ConradBock - 03 Jun 2005 Conrad, the issue is not whether there are symbols allowed at the border, as they are. The issue is whether there should be a semantic difference between ports shown on the border and ports shown inside the compartment. -- ThomasWeigert - 04 Jun 2005 Thomas, I must have missed the proposed SysML chapter you sent. What was the date of the message, or is there a link to the document? -- ConradBock - 03 Jun 2005 Revised Test Resolution From: "Thomas Weigert" To: "'Branislav Selic'" Cc: Subject: Some proposals for ballot 7 from Thomas Date: Thu, 28 Jul 2005 03:02:24 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 http://www.modeldrivenengineering.org/bin/view/Umlrtf/CurrentProposals?ballot=7 RtfIssue1000000019 (28 Jul 2005 - 07:41 - r1.11 - ThomasWeigert) Issue 7973: UML 2 Super / Incorrect statement on port visibility Issue summary The updated UML spec p162 states: 'UML Superstructure 2.0 Draft Adopted Specification A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default).' This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). Discussion The author of this issue contends that the port notation should not define the visibility of ports through the placement of the port symbol. However, this is what the specification has defined; no discussion as to the removal of this notation has taken place, to my recollection. Moreover, this is a convenient notation to express visibility of ports. The author of this issue is invited to demonstrate, through examples, why this notation is not suitable. -- ThomasWeigert - 17 May 2005 I must admitt that I thought this was only applicable for the frame not for all classifier symbols. When e.g. a class symbol is used in the normal fashion, i.e. with compartments for name, attributes and operations it is not easy to put ports inside the symbol. But when reading the current text this seems to be the idea. So I think I would be in favour of making this a recommended style guide instead of an absolute rule. -- AndersEk - 17 May 2005 I happen to recall this discussion well (I think it was either in oslo or Stockholm), but let's not quibble about that. New arguments have come up since that discussion that favour not tying the graphical placement of structural elements of a composite to their visibility. Specifically, in Sys ML? as well as in several other applications in different domains that have come up from some of our users (e.g. in business modeling), there is a need to be able to connect directly to a part that has public visibility; that is, without having to go through an intervening public port. Unless we start putting parts on the border (which clearly does not scale up well and it looks godawful), we really have no choice. While connecting directly to parts (i.e., without going through an intervening public port and a delegation connector) is not possible in either SDL or UML-RT, it seems useful to be able to do that in other cases. After all, parts are properties and, like other properties such as attributes, they should be able to have either public or private visibility. It is a minor but useful (and, more importantly, required) generalization of what is already there. For those domains, such as UML-RT and SDL where this is not allowed, the appropriate profile simply has to define constraints that force all parts to be non-public. So, if we accept the possibility that parts of a composite can be made public and that they can be connected from the outside, then it will not be possible to retain the convention that things inside the border are necessarily private/protected. If this is the case for parts, then the same reasoning should apply to ports. -- BranSelic - 19 May 2005 Bran, it is not clear why the question of whether the placement of ports should carry special semantics is necessarily connected to the question of whether one can connect to parts directly. Your argument seems to be that because we might at some point need to allow direct connection to parts (and that is a big if) we should not have a notation for ports that differentiates between public and private ports. I don't quite see how that follows. -- ThomasWeigert - 04 Jun 2005 Regarding the need of the SysML to connect directly to parts... I have spent much time with the SysML on their need to connect to parts directly. I believe this need is due to a misunderstanding of what internal structure is. For example, equations about abstract relations between system properties are being represented as connectors and parts in SysML while they are best represented as collaborations. If you do the latter, no changes to the UML are required, and in addition, no questions about the instantiation of equiations as objects arise. SysML has insisted on representing items in a manner inconsistent with the UML2, where it would have been very easy to be consistent. I have no sympathy for such. -- ThomasWeigert - 20 May 2005 Couldn't find any technical content in the above, so I'll add a bit more nontechnical content: Thomas, you completely misunderstand what is happening in Sys ML?. Would be glad to discuss sometime. -- ConradBock - 25 May 2005 Conrad, why don't you go into some detail of why the SysML needs to connect directly to parts. As you know, if have provided the relevant chapter to SysML with only leveraging the UML 2 spec and not making any changes. That proposal, I believe accomplished everything they were trying to do without messing around with the UML 2. -- ThomasWeigert - 26 May 2005 Rereading the above, it seems like the issue is whether non-port properties can notated overlapping the border. It would be helpful to allow any property to be shown on the border. As to the semantics of overlapping, I guess people are assuming it means the element is public, but presumably alot of diagrams have fully contained elements that are public. It would be a hassle to put all public properties on the border. This would argue against allowing any property to overlap the border, I guess. Whatever the resolution of the above complications, there are going to be alot of parts that are public and support connectors to them. The only difference between a part and port is the isService / isBehavior forwarding stuff, which are actually the least used aspects among classical systems engineers. They use connectors as contextualized associations, per the RFP requirement that U2P said it supported with composite structure, see http://www.jot.fm/issues/issue_2004_11/column5. Sys ML? also uses connectors to non-part properties, for parametric constraints. -- ConradBock - 03 Jun 2005 Conrad, the issue is not whether there are symbols allowed at the border, as they are. The issue is whether there should be a semantic difference between ports shown on the border and ports shown inside the compartment. -- ThomasWeigert - 04 Jun 2005 As there have been no further discussion of the question as to whether the placement of ports on the border should carry semantics I propose to close this issue. -- ThomasWeigert - 20 Jul 2005 How are ports shown inside the border distinguished visually from other properties? -- ConradBock - 21 Jul 2005 The name of the port and its optional classifier are placed outside of the small rectangle symbol standing for the port, while for parts the name is inside the box. (see p. 190 in the spec) -- ThomasWeigert - 28 Jul 2005 Revised Test Resolution Closed no change RtfIssue1000000022 (28 Jul 2005 - 07:59 - r1.15 - ThomasWeigert) From: "Thomas Weigert" To: "'Thomas Weigert'" , "'Branislav Selic'" Cc: Subject: RE: Some proposals for ballot 7 from Thomas Date: Fri, 29 Jul 2005 02:15:16 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Updated current proposals RtfIssue1000000019 (28 Jul 2005 - 07:41 - r1.11 - ThomasWeigert) Issue 7973: UML 2 Super / Incorrect statement on port visibility Issue summary The updated UML spec p162 states: 'UML Superstructure 2.0 Draft Adopted Specification A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default).' This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). Discussion The author of this issue contends that the port notation should not define the visibility of ports through the placement of the port symbol. However, this is what the specification has defined; no discussion as to the removal of this notation has taken place, to my recollection. Moreover, this is a convenient notation to express visibility of ports. The author of this issue is invited to demonstrate, through examples, why this notation is not suitable. -- ThomasWeigert - 17 May 2005 I must admitt that I thought this was only applicable for the frame not for all classifier symbols. When e.g. a class symbol is used in the normal fashion, i.e. with compartments for name, attributes and operations it is not easy to put ports inside the symbol. But when reading the current text this seems to be the idea. So I think I would be in favour of making this a recommended style guide instead of an absolute rule. -- AndersEk - 17 May 2005 I happen to recall this discussion well (I think it was either in oslo or Stockholm), but let's not quibble about that. New arguments have come up since that discussion that favour not tying the graphical placement of structural elements of a composite to their visibility. Specifically, in Sys ML? as well as in several other applications in different domains that have come up from some of our users (e.g. in business modeling), there is a need to be able to connect directly to a part that has public visibility; that is, without having to go through an intervening public port. Unless we start putting parts on the border (which clearly does not scale up well and it looks godawful), we really have no choice. While connecting directly to parts (i.e., without going through an intervening public port and a delegation connector) is not possible in either SDL or UML-RT, it seems useful to be able to do that in other cases. After all, parts are properties and, like other properties such as attributes, they should be able to have either public or private visibility. It is a minor but useful (and, more importantly, required) generalization of what is already there. For those domains, such as UML-RT and SDL where this is not allowed, the appropriate profile simply has to define constraints that force all parts to be non-public. So, if we accept the possibility that parts of a composite can be made public and that they can be connected from the outside, then it will not be possible to retain the convention that things inside the border are necessarily private/protected. If this is the case for parts, then the same reasoning should apply to ports. -- BranSelic - 19 May 2005 Bran, it is not clear why the question of whether the placement of ports should carry special semantics is necessarily connected to the question of whether one can connect to parts directly. Your argument seems to be that because we might at some point need to allow direct connection to parts (and that is a big if) we should not have a notation for ports that differentiates between public and private ports. I don't quite see how that follows. -- ThomasWeigert - 04 Jun 2005 Regarding the need of the SysML to connect directly to parts... I have spent much time with the SysML on their need to connect to parts directly. I believe this need is due to a misunderstanding of what internal structure is. For example, equations about abstract relations between system properties are being represented as connectors and parts in SysML while they are best represented as collaborations. If you do the latter, no changes to the UML are required, and in addition, no questions about the instantiation of equiations as objects arise. SysML has insisted on representing items in a manner inconsistent with the UML2, where it would have been very easy to be consistent. I have no sympathy for such. -- ThomasWeigert - 20 May 2005 Couldn't find any technical content in the above, so I'll add a bit more nontechnical content: Thomas, you completely misunderstand what is happening in Sys ML?. Would be glad to discuss sometime. -- ConradBock - 25 May 2005 Conrad, why don't you go into some detail of why the SysML needs to connect directly to parts. As you know, if have provided the relevant chapter to SysML with only leveraging the UML 2 spec and not making any changes. That proposal, I believe accomplished everything they were trying to do without messing around with the UML 2. -- ThomasWeigert - 26 May 2005 Rereading the above, it seems like the issue is whether non-port properties can notated overlapping the border. It would be helpful to allow any property to be shown on the border. As to the semantics of overlapping, I guess people are assuming it means the element is public, but presumably alot of diagrams have fully contained elements that are public. It would be a hassle to put all public properties on the border. This would argue against allowing any property to overlap the border, I guess. Whatever the resolution of the above complications, there are going to be alot of parts that are public and support connectors to them. The only difference between a part and port is the isService / isBehavior forwarding stuff, which are actually the least used aspects among classical systems engineers. They use connectors as contextualized associations, per the RFP requirement that U2P said it supported with composite structure, see http://www.jot.fm/issues/issue_2004_11/column5. Sys ML? also uses connectors to non-part properties, for parametric constraints. -- ConradBock - 03 Jun 2005 Conrad, the issue is not whether there are symbols allowed at the border, as they are. The issue is whether there should be a semantic difference between ports shown on the border and ports shown inside the compartment. -- ThomasWeigert - 04 Jun 2005 As there have been no further discussion of the question as to whether the placement of ports on the border should carry semantics I propose to close this issue. -- ThomasWeigert - 20 Jul 2005 How are ports shown inside the border distinguished visually from other properties? -- ConradBock - 21 Jul 2005 The name of the port and its optional classifier are placed outside of the small rectangle symbol standing for the port, while for parts the name is inside the box. (see p. 190 in the spec) -- ThomasWeigert - 28 Jul 2005 Revised Test Resolution Closed no change RtfIssue1000000022 (28 Jul 2005 - 07:59 - r1.15 - ThomasWeigert) X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.4,AWL: 0.262,HTML_60_70: 0.516, HTML_MESSAGE: 0.001,SARE_RECV_ADDR: 0.027 X-Spam-Level: From: "Thomas Weigert" To: "'Branislav Selic'" Cc: Subject: Issue 7973 Date: Thu, 3 Nov 2005 23:33:28 -0600 X-Mailer: Microsoft Outlook, Build 10.0.6626 Bran, you had some concern regarding Issue 7973, in that the current port notation interfered with the modeling of a SAP. The current notation is that (i) a port at the border has public visibility, and that (ii) a port inside is protected by default, but can be made public by setting its visibility to public. Do you still think this is an issue that requires resolution, or is it sufficient as stated? If you want an inside port public, one merely needs to change its visibility. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, November 03, 2005 8:52 AM To: Oystein Haugen Cc: conrad.bock@nist.gov; 'Eran Gery'; jamsden@us.ibm.com; Kenneth Hussey; Thomas Weigert; uml2-rtf@omg.org Subject: Re: Draft ballot 11 Subject: RE: Issue 7973 Date: Sat, 5 Nov 2005 08:13:50 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 7973 Thread-Index: AcXhc33uzgTb0+UkR9mfrnXCa+J9uQAAHskgABaX4gAAFNHGIA== From: "Karl Frank" To: "Mellor, Stephen" , "Branislav Selic" , "Thomas Weigert" Cc: X-OriginalArrivalTime: 05 Nov 2005 16:14:50.0074 (UTC) FILETIME=[0C2A83A0:01C5E224] Stephen, sure, but.. Its not an all-or-nothing issue. UML is a graphic notation as well as an abstract syntax, and so yes, the graphics must have some semantic dimension, the issue is relative position in respect to touching border lines, protruding, or completely "inside" The goals as I see this issue: 1 to prevent aesthetic decisons from having semantic implications of which the layout artist may be unaware, and 2. to prevent a programmatically implemented interpretation of the model from having to pay any attention to graphic attributes. 3. the graphic attributes that do have semantic implications should be very clear and consistent, as for example having having features be listed inside compartments of a classifier node is OK, because it is an all-or-nothing graphic attribute, not a matter of whether it is on the border of deep innside or protruding. - Karl -------------------------------------------------------------------------------- From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] Sent: Saturday, November 05, 2005 1:05 AM To: Karl Frank; Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 In my experience, aesthetic layout is an enormous aid in understanding, and therefore getting the semantics correct. I see far too many models that are thrown together on the page, and have one or two new classes per diagram. See the previous versions of the QVT spec. (among other OMG specs for an example. When I queried the low information density (1.3 classes per diagram), I was told it too hard to lay out. -- stephen -------------------------------------------------------------------------------- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 2005-11-04, Friday 12:17 To: Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 I strongly agree with Bran, a graphic tool (especially given that it may have "snap to grid" behavior or be used by a diagram designer more concerned with aesthetic layout than semantics) cannot be relied on to represent visibility by relative graphic position attributes. = Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, November 04, 2005 2:10 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: Re: Issue 7973 Thanks for asking about this (I had meant to include a resolution to the issue but forgot in the flurry of other resolutions). I would like the visibility of ports to be independent of their position. BTW, I think this should be true for all structural features. In addition to SAPs (which are implementation-specific but have to be public because they are connected to things outside) this capability will be needed for SysML. Just like attributes, it should be possible to declare parts to have different kinds of visibility. The graphical positioning of parts, on the other hand, should be just a function of drawing convenience not of their visibility. The fix is easy: just remove the phrase that says that visibility is implied by position. Thanks, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 11/04/2005 12:33 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject Issue 7973 Bran, you had some concern regarding Issue 7973, in that the current port notation interfered with the modeling of a SAP. The current notation is that (i) a port at the border has public visibility, and that (ii) a port inside is protected by default, but can be made public by setting its visibility to public. Do you still think this is an issue that requires resolution, or is it sufficient as stated? If you want an inside port public, one merely needs to change its visibility. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, November 03, 2005 8:52 AM To: Oystein Haugen Cc: conrad.bock@nist.gov; 'Eran Gery'; jamsden@us.ibm.com; Kenneth Hussey; Thomas Weigert; uml2-rtf@omg.org Subject: Re: Draft ballot 11 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.4,AWL: -0.582,HTML_50_60: 1.053, HTML_MESSAGE: 0.001,HTML_TAG_EXIST_TBODY: 1.014,SARE_RECV_ADDR: 0.027 X-Spam-Level: From: "Thomas Weigert" To: "'Karl Frank'" , "'Mellor, Stephen'" , "'Branislav Selic'" Cc: Subject: RE: Issue 7973 Date: Sat, 5 Nov 2005 10:59:38 -0600 X-Mailer: Microsoft Outlook, Build 10.0.6626 I agree with Stephen... Graphical modeling should be able to use all the capabilities of graphics to express meaning, where that helps. Inside vs. outside of a shape is a clear delineation and can be used to convey a difference in semantics. The constraints on graphics is that they need to be scalable, printable in black and white without loss of meaning, etc. We should discuss each case on these dimensions. Bran's concern on 7973 was not that it was easy to confuse. His concern was that he wanted to use the inside vs on-border to express a different meaning than visibility, namely the purpose of the port (SAP vs horizontal port). So to return to that, we have two options: 1. Positioning of port indicates visibility by default (public on border, private inside), but can be changed for inside ports. 2. Ports are always public by default, but can be hidden for inside ports. I think we should pick at least a default as in (2), as it would be a nuisance to have to state visibility for every port, albeit the vast majority is public... Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, November 05, 2005 10:14 AM To: Mellor, Stephen; Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 Stephen, sure, but.. Its not an all-or-nothing issue. UML is a graphic notation as well as an abstract syntax, and so yes, the graphics must have some semantic dimension, the issue is relative position in respect to touching border lines, protruding, or completely "inside" The goals as I see this issue: 1 to prevent aesthetic decisons from having semantic implications of which the layout artist may be unaware, and 2. to prevent a programmatically implemented interpretation of the model from having to pay any attention to graphic attributes. 3. the graphic attributes that do have semantic implications should be very clear and consistent, as for example having having features be listed inside compartments of a classifier node is OK, because it is an all-or-nothing graphic attribute, not a matter of whether it is on the border of deep innside or protruding. - Karl -------------------------------------------------------------------------------- From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] Sent: Saturday, November 05, 2005 1:05 AM To: Karl Frank; Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 In my experience, aesthetic layout is an enormous aid in understanding, and therefore getting the semantics correct. I see far too many models that are thrown together on the page, and have one or two new classes per diagram. See the previous versions of the QVT spec. (among other OMG specs for an example. When I queried the low information density (1.3 classes per diagram), I was told it too hard to lay out. -- stephen -------------------------------------------------------------------------------- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 2005-11-04, Friday 12:17 To: Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 I strongly agree with Bran, a graphic tool (especially given that it may have "snap to grid" behavior or be used by a diagram designer more concerned with aesthetic layout than semantics) cannot be relied on to represent visibility by relative graphic position attributes. = Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, November 04, 2005 2:10 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: Re: Issue 7973 Thanks for asking about this (I had meant to include a resolution to the issue but forgot in the flurry of other resolutions). I would like the visibility of ports to be independent of their position. BTW, I think this should be true for all structural features. In addition to SAPs (which are implementation-specific but have to be public because they are connected to things outside) this capability will be needed for SysML. Just like attributes, it should be possible to declare parts to have different kinds of visibility. The graphical positioning of parts, on the other hand, should be just a function of drawing convenience not of their visibility. The fix is easy: just remove the phrase that says that visibility is implied by position. Thanks, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 11/04/2005 12:33 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject Issue 7973 Bran, you had some concern regarding Issue 7973, in that the current port notation interfered with the modeling of a SAP. The current notation is that (i) a port at the border has public visibility, and that (ii) a port inside is protected by default, but can be made public by setting its visibility to public. Do you still think this is an issue that requires resolution, or is it sufficient as stated? If you want an inside port public, one merely needs to change its visibility. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, November 03, 2005 8:52 AM To: Oystein Haugen Cc: conrad.bock@nist.gov; 'Eran Gery'; jamsden@us.ibm.com; Kenneth Hussey; Thomas Weigert; uml2-rtf@omg.org Subject: Re: Draft ballot 11 From: "Thomas Weigert" To: "'Karl Frank'" , "'Mellor, Stephen'" , "'Branislav Selic'" Cc: Subject: RE: Issue 7973 Date: Sun, 6 Nov 2005 22:16:16 -0600 X-Mailer: Microsoft Outlook, Build 10.0.6626 "Mounted on the inside" (or outside) is subject to exactly the same arguments as "mounted on the border" (i.e., protruding both to the inside and outside). So if you think these are appropriate and graphically unambiguous, you will have to accept the "on the border" case also. Actually, none of the argument turn on ambiguity, as these are certainly not ambiguous. Your concerns appear to be about precision of positioning.... Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, November 05, 2005 2:17 PM To: Thomas Weigert; Mellor, Stephen; Branislav Selic Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 [am resending this with examples attached. Doesn't help much to talk about graphics and not use graphics. The portOrPartInside diagram pasted in above shows the ambiguity we can get into with little boxes inside big boxes when we already have a graphic involving boxes inside classifier boundaries. How close to the edge is "inside"? Howfar protruding must it be to be outside? What we have now is unambiguous, lets keep it that way. The test.jpg pasted in below shows one very different and unambiguous way to show differences in ports with minimal impact on current graphics for ports. A graphic should be clear as to the metaclass of the model element before it begins to make fine tuning for the properties of the instance. I too agree with Stephen. But I disagree with Thomas in that we have many more than the two GRAPHIC options "inside or on the border", to express the two semantically different kinds of ports. "inside" allows two much visual borderline cases, and whether Bran is concerned about it or not, it allows a slippery slope down to "on the border" I recommend graphicall unambiguous representation, such as: mounted on the outside surface, (no part of the port projects inside the surface) versus mounted on the inside. (no part of the port projects outside the surface) The "surface" is the boundary line at the perimeter of the classifier owning the port. My recommendation is in part an issue of clean graphic programming and the silliness of allowing one to aesthetically manipulate the relative position of the port box, when a clearly exclusive alternation is to be represented. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, November 05, 2005 12:00 PM To: Karl Frank; 'Mellor, Stephen'; 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 I agree with Stephen... Graphical modeling should be able to use all the capabilities of graphics to express meaning, where that helps. Inside vs. outside of a shape is a clear delineation and can be used to convey a difference in semantics. The constraints on graphics is that they need to be scalable, printable in black and white without loss of meaning, etc. We should discuss each case on these dimensions. Bran's concern on 7973 was not that it was easy to confuse. His concern was that he wanted to use the inside vs on-border to express a different meaning than visibility, namely the purpose of the port (SAP vs horizontal port). So to return to that, we have two options: 1. Positioning of port indicates visibility by default (public on border, private inside), but can be changed for inside ports. 2. Ports are always public by default, but can be hidden for inside ports. I think we should pick at least a default as in (2), as it would be a nuisance to have to state visibility for every port, albeit the vast majority is public... Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, November 05, 2005 10:14 AM To: Mellor, Stephen; Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 Stephen, sure, but.. Its not an all-or-nothing issue. UML is a graphic notation as well as an abstract syntax, and so yes, the graphics must have some semantic dimension, the issue is relative position in respect to touching border lines, protruding, or completely "inside" The goals as I see this issue: 1 to prevent aesthetic decisons from having semantic implications of which the layout artist may be unaware, and 2. to prevent a programmatically implemented interpretation of the model from having to pay any attention to graphic attributes. 3. the graphic attributes that do have semantic implications should be very clear and consistent, as for example having having features be listed inside compartments of a classifier node is OK, because it is an all-or-nothing graphic attribute, not a matter of whether it is on the border of deep innside or protruding. - Karl -------------------------------------------------------------------------------- From: Mellor, Stephen [mailto:Stephen_Mellor@mentor.com] Sent: Saturday, November 05, 2005 1:05 AM To: Karl Frank; Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 In my experience, aesthetic layout is an enormous aid in understanding, and therefore getting the semantics correct. I see far too many models that are thrown together on the page, and have one or two new classes per diagram. See the previous versions of the QVT spec. (among other OMG specs for an example. When I queried the low information density (1.3 classes per diagram), I was told it too hard to lay out. -- stephen -------------------------------------------------------------------------------- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 2005-11-04, Friday 12:17 To: Branislav Selic; Thomas Weigert Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 I strongly agree with Bran, a graphic tool (especially given that it may have "snap to grid" behavior or be used by a diagram designer more concerned with aesthetic layout than semantics) cannot be relied on to represent visibility by relative graphic position attributes. = Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, November 04, 2005 2:10 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: Re: Issue 7973 Thanks for asking about this (I had meant to include a resolution to the issue but forgot in the flurry of other resolutions). I would like the visibility of ports to be independent of their position. BTW, I think this should be true for all structural features. In addition to SAPs (which are implementation-specific but have to be public because they are connected to things outside) this capability will be needed for SysML. Just like attributes, it should be possible to declare parts to have different kinds of visibility. The graphical positioning of parts, on the other hand, should be just a function of drawing convenience not of their visibility. The fix is easy: just remove the phrase that says that visibility is implied by position. Thanks, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 11/04/2005 12:33 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject Issue 7973 Bran, you had some concern regarding Issue 7973, in that the current port notation interfered with the modeling of a SAP. The current notation is that (i) a port at the border has public visibility, and that (ii) a port inside is protected by default, but can be made public by setting its visibility to public. Do you still think this is an issue that requires resolution, or is it sufficient as stated? If you want an inside port public, one merely needs to change its visibility. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, November 03, 2005 8:52 AM To: Oystein Haugen Cc: conrad.bock@nist.gov; 'Eran Gery'; jamsden@us.ibm.com; Kenneth Hussey; Thomas Weigert; uml2-rtf@omg.org Subject: Re: Draft ballot 11 Subject: RE: Issue 7973 Date: Mon, 7 Nov 2005 08:12:25 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 7973 Thread-Index: AcXjWxxc9ISYJtc5Sp22ai1JMXUZlwAWqrYA From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" Cc: X-OriginalArrivalTime: 07 Nov 2005 16:12:26.0563 (UTC) FILETIME=[0B73F930:01C5E3B6] This resolution is OK. It enables Anyone who wishes to use the internal position to aesthetically emphasize the hidden nature of a particular port is free to do so, if their diagramming tool supports it. But it is an option. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Monday, November 07, 2005 12:11 AM To: 'Branislav Selic' Cc: uml2-rtf@omg.org Subject: RE: Issue 7973 Bran, the proposed resolution to 7973 is at http://modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000019 per the discussion below and earlier. The set of all proposals from the struc and beh group is at http://modeldrivenengineering.org/bin/view/Umlrtf/CurrentProposals?ballot=11. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, November 04, 2005 1:10 PM To: Thomas Weigert Cc: uml2-rtf@omg.org Subject: Re: Issue 7973 Thanks for asking about this (I had meant to include a resolution to the issue but forgot in the flurry of other resolutions). I would like the visibility of ports to be independent of their position. BTW, I think this should be true for all structural features. In addition to SAPs (which are implementation-specific but have to be public because they are connected to things outside) this capability will be needed for SysML. Just like attributes, it should be possible to declare parts to have different kinds of visibility. The graphical positioning of parts, on the other hand, should be just a function of drawing convenience not of their visibility. The fix is easy: just remove the phrase that says that visibility is implied by position. Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 07 Nov 2005 08:29:07 -0800 To: UML-RTF From: Joaquin Miller Subject: Issue 7973 Steve is right, aesthetic layout is a powerful aid to understanding. Karl is right, having the meaning of a drawing depend on delicate positioning of an element is a very bad idea. 'On the border' is ambiguous. These phrases are not ambiguous: On the outside of the border On the inside of the border These are even better: On the outside of the border and touching it On the inside of the border and touching it Yes, touching is delicate, but a) some tools will help b) humans will cut the draftsperson some slack. This is asking for lots of trouble: Tiny boxes that are positioned delicately crossing a border so that part of the tiny box is inside the larger box and part is outside the larger box. Let's not ask either users or tool vendors to deal with that. Cordially, Joaquin e-mail: bselic@ca.ibm.com