Issue 6316: UML2 Super/Ports (uml2-superstructure-ftf) Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk) Nature: Uncategorized Issue Severity: Summary: 03-08-02.pdf: This from the descrciption of Ports(p169): "For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Chapter 13, "Common Behaviors")," Is how this works a semantic variation point - if so then it should say so. IMO, the very least we should allow is that Port can participate in an Association so that its class can have an association end that points to its parent, and so can delegate behaviour appropriately Resolution: Revised Text: Actions taken: October 14, 2003: received issue March 9, 2005: closed issue Discussion: Regarding the first paragraph of the summary, there is nothing additional to specify. As the specification stated, the behavior port forwards any arriving signals to the owning classifier. The behavior of that classifier deals with that signals in the manner specified by that behavior. This is not a semantic variation, but just a consequence of the way how behavior is specified (see Chapter 13). In response to the second paragraph of the issue summary, only classifiers participate in associations. As a port is not a classifier but a feature of a classifier, associations do not apply to it. However, the type of the port (a classifier) can participate in associations. Disposition: Closed, no change End of Annotations:===== From: "Moore, Alan" To: "'issues@omg.org'" Subject: UML2 Super/Ports Date: Tue, 14 Oct 2003 17:03:30 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) 03-08-02.pdf: This from the descrciption of Ports(p169): "For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Chapter 13, "Common Behaviors")," Is how this works a semantic variation point - if so then it should say so. IMO, the very least we should allow is that Port can participate in an Association so that its class can have an association end that points to its parent, and so can delegate behaviour appropriately. From: "Moore, Alan" To: "'thomas.weigert@motorola.com'" , Branislav Selic , uml2-superstructure-ftf@omg.org Subject: RE: Updated: Proposed issue resolution for common behavior and co mposite structure working groups Date: Tue, 2 Dec 2003 08:20:33 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) Thomas, Comments on your resolutions: 6251: I can't see how the metamodel (even with associated text) prohibits the case I outlined - in fact I'm not clear that encaspsulation of parts is enforced. Could you give me a reference (page, figure ...) please. 6316: My concern about behaviour ports is how can the port, via the behaviour of its type, forward signals to its parent, when they have no reference to their parent. I thought that at least if the port could participate in an association to its parent (I assume the other end of the association that allows the parent to contain the port) then it could have a property that referenced its parent. I also assume that this works for other types of requests, not just signals. 6356: Surely if port was a subtype of property then they could participate in composite associations (see my comment on 6316 above). Regards, Alan -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 30 November 2003 04:36 To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: thomas.weigert@motorola.com Subject: Updated: Proposed issue resolution for common behavior and composite structure working groups Dear all, I discovered that there are many more issues assigned to these two working groups in a later version of the FTF report that I had been looking at. Thus here comes a second installment based on FTF-report-draft-031031.doc (I hope this is the latest version). These two documents include the earlier sent one, so you can just ignore that one. Please pay attention to the discussion suggested for issue 6373. This issue would best be resolved by making a change to Kernel, which unfortunately means also changing the infrastructure. I believe it does not have any significant effect on anything, but changing the infrastructure is always highly controversial. Please advise. All the best, Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, November 29, 2003 7:56 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: Thomas Weigert Subject: Proposed issue resolution for common behavior and composite structure working groups Dear all, please find attached two documents discussing the issues assigned to the common behavior and composite structure working group, respectively. Each document has a summary page indicating the proposed action. Most issues do not require any change, as the UML 2.0 most often has already resolved the issue. There are 2 proposed changes for common behavior and one proposed change for composite structure, all minor. Regarding common behavior there are three issues (6148, 6149, and 6150) which I propose for discussion. While they would not require any change as the solution in the document is as was intended, the issues nevertheless could be addressed: 1. 6148 and 6149 implicitly propose an alternative means of showing textually defined behavior as associated with the Behavior metaclass and making that metaclass concrete. This is as good a solution as the one currently implemented; in my opinion a matter of taste. 2. 6150 requests a notation for method which is reasonable but should be decided upon by teamwork (as nobody ever is satisfied with notation). Please provide feedback on the proposed solution and also provide input to the issues labeled as for discussion. I will propose solutions for those after I have heard from at least several others on the FTF. All the best, Th. OMG Issue No: 6316 Title: UML2 Super/Ports Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: This from the descrciption of Ports(p169): "For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Chapter 13, "Common Behaviors")," Is how this works a semantic variation point - if so then it should say so. IMO, the very least we should allow is that Port can participate in an Association so that its class can have an association end that points to its parent, and so can delegate behaviour appropriately Discussion: Regarding the first paragraph of the summary, there is nothing additional to specify. As the specification stated, the behavior port forwards any arriving signals to the owning classifier. [Conrad: the question is how this can happen when ports cannot refer back to their containing classifier. See suggestions at 6251] The behavior of that classifier deals with that signals in the manner specified by that behavior. This is not a semantic variation, but just a consequence of the way how behavior is specified (see Chapter 13). From: "Moore, Alan" To: "'Branislav Selic'" , conrad.bock@nist.gov Cc: mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: 2nd Draft of Ballot 7 Date: Wed, 4 Feb 2004 23:05:01 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) wrt 6316 - I've never seen the second paragraph of Thomas's discussion before - if it was posted previously then I missed it. My point was that Port should be able to be an owned or memberEnd of an Association,i.e. Port should be a subtype of Property. If there's another issue that deals with this then I'm happy that this one (which was poorly phrased) be closed. However, if not then I'd like to see more discussion about Ports being subtypes of Property against this issue if necessary. Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 04 February 2004 22:19 To: conrad.bock@nist.gov Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 2nd Draft of Ballot 7 You guys are not making this easy for me. Here is what I have decided: 6316: Thomas added text to deal with this issue and I it provides the answer that was sought. So, I left it in the ballot. 6355: There is really no solution being proposed here, just an explanation and Thomas provided it. However, I recall myself being confused by this bit of metamodelling subtlety (trickery?) and it is certainly not obvious, although it works. Maybe some more clarification is required in the text. Therefore, I have pulled this from the ballot, so that we can provide a bit of clarifying text to help readers understand. 6356: I agree with Conrad that it is a duplicate of 6316 not of 6281. I will, therefore, pull it from the ballot. Sorry if I got it wrong, but I figure it is better to be safe: you have to remember that we cannot vote on the same resolution twice. Hence, it is quite important to ensure that we have the right resolution for a formal vote. Regards, Bran "Conrad Bock" 02/04/2004 03:30 PM Please respond to conrad.bock To: cc: , Subject: RE: 2nd Draft of Ballot 7 Bran, Thomas, Comments on the second draft ballot 7: 6316 (UML2 Super/Ports) should be held for more discussion, per Bran's suggestion. 6355 (partWithPort without ports) proposes a solution to 6316, so is actually a duplicate. 6356 is duplicate with 6316, not 6281, which is about PDF/MDL inconsistency. Thanks, Conrad To: Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 7 (official version -- please vote on this!) - revote X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 17:26:52 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 17:26:55, Serialize complete at 02/17/2004 17:26:55 Conrad, I am sorry if the resolution to 6316 made it into the ballot over your objections. I have no idea how that happened. Normally, I will pull out an issue that is (a) contentious and (b) has not been discussed in depth before (however, it is a different matter if the issue HAS been discussed and it is clear that only a vote will break the deadlock). I have applied that rule consistently. As final measure, I also publish the draft ballot on the morning of the start of the vote so that any last minute problems can be flagged. It may be that one or more e-mails get overlooked in the general e-mail flurries on this mailing list. If you are concerned about a proposed resolution and if you would like to challenge it, please make sure that I have acknowledged your concern. There are over 600 issues and a lot of administrative work in tracking it all, so the process is not foolproof. Regards, Bran "Conrad Bock" 02/17/2004 05:04 PM Please respond to conrad.bock To: cc: Subject: RE: Ballot 7 (official version -- please vote on this!) - revote NIST votes yes on all of Ballot 7, except: No on 6310 for the reasons given by Adaptive. No on 6354 The issue asked if association end names could be presented on connectors, but answer addressed connector end names. Some users would like to show association end names on connectors to remind them of what the connector is instantiated from. No on 6316 The answer to the second part did not address the issue, which is that Port is a kind of StructuralFeature, rather than Property, so it cannot be the end of an association. This is required to navigate from the port to the classifier containing it. I had asked for this issue to be removed from the ballot before it was posted. Thanks, Conrad Disposition: Closed, no change