Issue 6401: UML 2 Super / Interface / missing owner of operation (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property. Resolution: see below Revised Text: interface: Interface[0..1] The interface that owns this operation. (Subsets RedefinableElement::redefinitionCont ext, NamedElement::namespace and Feature::featuringClassifier.) (EDITOR COMMENTS: Had to modify this fix to fit document conventions) Actions taken: October 31, 2003: received issue March 8, 2005: closed issue Discussion: Agreed. We shall add such an operation. In Figure 11 of the Abstract Syntax, both the Class and the (newly added) Interface attributes shall be added to the diagram. In 7.3.36 of the 040725 Interim FAS, under the Attributes subsection, insert text after the following existing text: End of Annotations:===== ubject: UML 2 Super / Interface / missing owner of operation X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 31 Oct 2003 20:25:33 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/31/2003 20:25:35, Serialize complete at 10/31/2003 20:25:35 Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 OMG Issue No: 6401 Title: UML 2 Super / Interface / missing owner of operation Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property. Discussion: Agreed. We shall add such an operation. In Figure 11 of the Abstract Syntax, both the Class and the (newly added) Interface attributes shall be added to the diagram. In 7.3.36 of the 040725 Interim FAS, under the Attributes subsection, insert text after the following existing text: Inserted Text interface: Interface[0..1] The interface that owns this operation. (Subsets RedefinableElement::redefinitionContext, NamedElement::namespace and Feature::featuringClassifier.) Disposition: Resolved From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , , Subject: RE: Merged resolution for Ballot 21 Date: Wed, 28 Jul 2004 21:51:01 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) I do not think that the solution to 6401 is a good idea. I would go the opposite route and question why we have Operation.class in the first place. Before adding yet another such association, let's come up with a convincing story why we should have it. (Keep in mind that an Operation is only a behavioral feature, so clearly you would not need the class to define any computation of the operation.) Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, July 27, 2004 10:44 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Merged resolution for Ballot 21 As I said in earlier, I like the idea of generalizing to Classifier. In the attached I have merged our two oroposed resolutions to combine the advantages of both. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran Subject: RE: Merged resolution for Ballot 21 Date: Thu, 29 Jul 2004 09:35:48 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Merged resolution for Ballot 21 Thread-Index: AcR1Fu1qq8i19gD6Q5aIQqtdCyO9PwAco1IA From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , , X-OriginalArrivalTime: 29 Jul 2004 16:35:58.0090 (UTC) FILETIME=[204A66A0:01C4758A] Thomas, Questioning why we have an Operation class in the first place is a different issue altogether, and a new one at a late date. Issue 6401 is a Question Re: Parameter. Best, Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, 28 July, 2004 10:51 PM To: Karl Frank; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Merged resolution for Ballot 21 I do not think that the solution to 6401 is a good idea. I would go the opposite route and question why we have Operation.class in the first place. Before adding yet another such association, let's come up with a convincing story why we should have it. (Keep in mind that an Operation is only a behavioral feature, so clearly you would not need the class to define any computation of the operation.) Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, July 27, 2004 10:44 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Merged resolution for Ballot 21 As I said in earlier, I like the idea of generalizing to Classifier. In the attached I have merged our two oroposed resolutions to combine the advantages of both. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran Subject: Recall: Merged resolution for Ballot 21 Date: Thu, 29 Jul 2004 09:37:12 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Merged resolution for Ballot 21 Thread-Index: AcR1ij5LMGPuBo1nRTSqhQ8P/ncE5Q== Priority: Urgent Expiry-Date: Sat, 31 Jul 2004 09:37:10 -0700 From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , , X-OriginalArrivalTime: 29 Jul 2004 16:37:21.0454 (UTC) FILETIME=[51FABCE0:01C4758A] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6TGmtlj028798 Karl Frank would like to recall the message, "Merged resolution for Ballot 21". Subject: RE: Merged resolution for Ballot 21 Date: Thu, 29 Jul 2004 09:41:45 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Merged resolution for Ballot 21 Thread-Index: AcR1Fu1qq8i19gD6Q5aIQqtdCyO9PwAco1IA From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , , X-OriginalArrivalTime: 29 Jul 2004 16:41:54.0210 (UTC) FILETIME=[F48E0020:01C4758A] Sorry, first response misidentified 6401, it is really about an operation to retrieve the owner. Your suggestion was relevant. So I owe you a different response. The issuer of the report 6401 was happy with having the operation in the case of a class, and wanted to have it available for interfaces as well, so eliminating such an operation altogether would appear hostile to the spirit of the issue, which was asking for consistency in having more, not less. - Karl -------------------------------------------------------- Thomas, Questioning why we have an Operation class in the first place is a different issue altogether, and a new one at a late date. Issue 6401 is a Question Re: Parameter. Best, Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, 28 July, 2004 10:51 PM To: Karl Frank; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Merged resolution for Ballot 21 I do not think that the solution to 6401 is a good idea. I would go the opposite route and question why we have Operation.class in the first place. Before adding yet another such association, let's come up with a convincing story why we should have it. (Keep in mind that an Operation is only a behavioral feature, so clearly you would not need the class to define any computation of the operation.) Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, July 27, 2004 10:44 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Merged resolution for Ballot 21 As I said in earlier, I like the idea of generalizing to Classifier. In the attached I have merged our two oroposed resolutions to combine the advantages of both. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , , Subject: RE: Merged resolution for Ballot 21 Date: Thu, 29 Jul 2004 14:48:22 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Operation.class should be justified first, hostile or not, before you add even more things. Note that operation.class is just another example of the backwards dependencies that we just had a long discussion about... Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, July 29, 2004 11:42 AM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Merged resolution for Ballot 21 Sorry, first response misidentified 6401, it is really about an operation to retrieve the owner. Your suggestion was relevant. So I owe you a different response. The issuer of the report 6401 was happy with having the operation in the case of a class, and wanted to have it available for interfaces as well, so eliminating such an operation altogether would appear hostile to the spirit of the issue, which was asking for consistency in having more, not less. - Karl -------------------------------------------------------- Thomas, Questioning why we have an Operation class in the first place is a different issue altogether, and a new one at a late date. Issue 6401 is a Question Re: Parameter. Best, Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, 28 July, 2004 10:51 PM To: Karl Frank; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Merged resolution for Ballot 21 I do not think that the solution to 6401 is a good idea. I would go the opposite route and question why we have Operation.class in the first place. Before adding yet another such association, let's come up with a convincing story why we should have it. (Keep in mind that an Operation is only a behavioral feature, so clearly you would not need the class to define any computation of the operation.) Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, July 27, 2004 10:44 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Merged resolution for Ballot 21 As I said in earlier, I like the idea of generalizing to Classifier. In the attached I have merged our two oroposed resolutions to combine the advantages of both. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Draft of ballot 21 -- please review and provide feedback if you have it Date: Thu, 29 Jul 2004 21:59:05 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments... 6399: Why don't we just add an association Classifier.nestedClassifier, rather than making this association explicit in all subtypes? This potentially makes sense in all the classifiers we have... Looking through the list: Class: nestedClassifier Behavior, Interaction, Statemachine, Usecase, Activity all inherited nestedClassifier from Class Interface: nestedClassifier (added by this proposal) Artifact: nestedArtifact Node: nestedNode (redefined) Without ability to nest classifier: Actor Datatype However, I can also see situations where you would want a Datatype to be defined using nested classifier definitions. 6401: As I already stated, there seems no reason to add this link as it just establishes another questionable twodirectional dependency between metaclasses. "Operation.class" is also questionable. Without having a good justification why this dependency should be added (other than symmetry reasons), we should hold back. 7370: Conrad pointed out that there could be functions matching the syntactic definition of constructors which do not create new data (which is one reading of constructor). So it is better to tune the first sentence in the proposed solution (submitted by me) to "A constructor has a single return result parameter of the type of the owning class". Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 29, 2004 6:02 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 21 -- please review and provide feedback if you have it It's been hard to keep track of who has proposed what for ballot 21. So, it is likely that this draft may have some omissions or, possibly, outdated versions of the many resolutions that have been flying about. Please do have a good look at it -- there are only 12 resolutions on the ballot (slim pickings this time around!). Thanks, Bran e-mail: bselic@ca.ibm.com