Issue 10656: clarification on Behavior::specification / meaning of InterfaceRealization (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: In 7.3.25 InterfaceRealization Semantics the UML2 spec says "For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the realizing classifier will provide functionality that maintains the state represented by the property." While section 7.3.45 Realization Semantics says "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." If you interpret this as a literal constraint, then the realizing Classifier would need to copy all of the BehavioralFeatures it realizes. However, it seems unnecessarily redundant to realize an interface and to have to copy all the operations into the realizing classifier too. This means that for an Activity, the "signature" content of an operation could have to be specified up to 6 times: 1. An Operation in a provided Interface 2. The same Operation copied into a realizing Class used as the type of a Port 3. An Operation of a Component containing the Port 4. The method Behavior whose specification is the Operation owned by the Class 5. If the Behavior is an Activity, the ActivityParameterNodes 6. The InputPins and OutputPins of a CallOperationAction that invokes the operation In addition, there would be no way for an ownedBehavior's specification to refer to an Operation of an Interface provided through a Port since different ports can realize the same interface but have different implementations. There is no explicit constraint that the Classifier has to have a matching Operation, so you could read the above semantics to mean that adding the InterfaceRealization effectively means the Realizing Classifier has the Interface's behavioral features. This seems to be common practice, you don't often see all the realized operations cloned into the realizing classifier as this is redundant and somewhat tedious to do and maintain. Consider changing the description of property Behavior::specification in section 13.3.2 from: Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole). to: Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be realized or inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole). The possible problems with this change are: 1 Subclasses cannot redefine realized operations of their superclasses unless the operation is duplicated in the superclass. This is because there would be no redefined element to reference in the superclass. This can be solved by cloning the operations that need to be redefined, or (more likely) redefining an ownedBehavior of the Superclass, not an Operation. So there is no change here. 2. Setting the specification of an ownedBehavior would result in an update of the realized interface since the opposite of the specification property is the Interface's method property. This is unfortunate coupling between an interface and its method implementations, but there are many other such cases in UML2, and the method property is multi-valued. So this isn't really that much of a problem. Some advantages are: 1. It matches the common understanding or realization 2. It reduces redundancy in the model 3. It allows an ownedBehavior's specification to be an Operation of an Interface provided through a Port in an EncapsulatedClassifer. This allows a EncapsulatedClassifier to provide different implementations for the same operation provided through different ports. This would not be possible if the specification operation had to be owned by the containing classifier as there would be no way to distinguish which operation the different behaviors corresponded to. Resolution: Revised Text: Actions taken: February 9, 2007: received issue Discussion: End of Annotations:===== c: Kenneth Hussey , Natalia Balaba-Liaskovski , Branislav Selic , James Bruck Subject: UML2: Need clarification on Behavior::specification and the meaning of InterfaceRealization X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Jim Amsden Date: Fri, 9 Feb 2007 10:46:16 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 02/09/2007 08:46:23, Serialize complete at 02/09/2007 08:46:23 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org In 7.3.25 InterfaceRealization Semantics the UML2 spec says "For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the realizing classifier will provide functionality that maintains the state represented by the property." While section 7.3.45 Realization Semantics says "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of ..implementation.. is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." If you interpret this as a literal constraint, then the realizing Classifier would need to copy all of the BehavioralFeatures it realizes. However, it seems unnecessarily redundant to realize an interface and to have to copy all the operations into the realizing classifier too. This means that for an Activity, the "signature" content of an operation could have to be specified up to 6 times: 1. An Operation in a provided Interface 2. The same Operation copied into a realizing Class used as the type of a Port 3. An Operation of a Component containing the Port 4. The method Behavior whose specification is the Operation owned by the Class 5. If the Behavior is an Activity, the ActivityParameterNodes 6. The InputPins and OutputPins of a CallOperationAction that invokes the operation In addition, there would be no way for an ownedBehavior's specification to refer to an Operation of an Interface provided through a Port since different ports can realize the same interface but have different implementations. There is no explicit constraint that the Classifier has to have a matching Operation, so you could read the above semantics to mean that adding the InterfaceRealization effectively means the Realizing Classifier has the Interface's behavioral features. This seems to be common practice, you don't often see all the realized operations cloned into the realizing classifier as this is redundant and somewhat tedious to do and maintain. Consider changing the description of property Behavior::specification in section 13.3.2 from: Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole). to: Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be realized or inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole). The possible problems with this change are: 1 Subclasses cannot redefine realized operations of their superclasses unless the operation is duplicated in the superclass. This is because there would be no redefined element to reference in the superclass. This can be solved by cloning the operations that need to be redefined, or (more likely) redefining an ownedBehavior of the Superclass, not an Operation. So there is no change here. 2. Setting the specification of an ownedBehavior would result in an update of the realized interface since the opposite of the specification property is the Interface's method property. This is unfortunate coupling between an interface and its method implementations, but there are many other such cases in UML2, and the method property is multi-valued. So this isn't really that much of a problem. Some advantages are: 1. It matches the common understanding or realization 2. It reduces redundancy in the model 3. It allows an ownedBehavior's specification to be an Operation of an Interface provided through a Port in an EncapsulatedClassifer. This allows a EncapsulatedClassifier to provide different implementations for the same operation provided through different ports. This would not be possible if the specification operation had to be owned by the containing classifier as there would be no way to distinguish which operation the different behaviors corresponded to. Subject: RE: Draft Ballot #5 Date: Tue, 4 Mar 2008 09:27:49 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Ballot #5 Thread-Index: Ach84ehc9z05Xn2XSROnCIkG/yZH0gBGSPNA From: "Kenn Hussey" To: "Bran Selic" , X-OriginalArrivalTime: 04 Mar 2008 14:27:52.0452 (UTC) FILETIME=[EE169C40:01C87E03] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15766.003 X-TM-AS-Result: No--36.060000-8.000000-31 Bran, Here are my comments. 10656 This seems like a large change to be making in an RTF. Rather than changing the way interfaces are realized, why not consider just - making BehavioralFeature::method derived (so that a behavioral feature need not be .modified. in order to describe the behavior of one of its implementations) - adding a constraint to ensure that a classifier which realizes an interface has an operation that conforms to every operation in the interface Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Sunday, March 02, 2008 10:50 PM To: uml2-rtf@omg.org Subject: Draft Ballot #5 Attached, please find draft ballot #5. Please review the proposed resolutions and provide any feedback on them by Friday, March 14. Pretty slim pickings, this one. There are just 4 proposed resolutions on this ballot, all of them thanks to Jim Amsden. I guess UML 2 is closing in on perfection. Regards...Bran CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. To: uml2-rtf@omg.org Subject: Re: Draft Ballot #5 X-KeepSent: 7FA2E71B:134596B3-85257402:006552D5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Tue, 4 Mar 2008 13:30:55 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/04/2008 11:30:57, Serialize complete at 03/04/2008 11:30:57 In Java, a Class is not required to repeat all the operations it implements from other interfaces, it only has to provide a method that implements each one. That does repeat the signature, but only once. I'd like the same capability in UML2. Currently the operation appears in the interface, again in the realizing class as the specification of a method behavior that implements the operation. That repeats the signature three times, not twice. This results in very inconvenient modeling and extra unnecessary constraints. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Nerijus Jankevicius" 03/04/2008 09:41 AM To "Kenn Hussey" , "Bran Selic" , cc Subject Re: Draft Ballot #5 Kenn, Abstract class could realize an interface, but don't need to have operations. Only subclasses of this abstract class are required to implement operations. It works in Java. Nerijus ----- Original Message ----- From: Kenn Hussey To: Bran Selic ; uml2-rtf@omg.org Sent: Tuesday, March 04, 2008 4:27 PM Subject: RE: Draft Ballot #5 Bran, Here are my comments. 10656 This seems like a large change to be making in an RTF. Rather than changing the way interfaces are reaalized, why not consider just - making BehavioralFeature::method derived (so that a behavioral feature need not be ..modified. in order to describe the behavior of one of its implementations) - adding a constraint to ensure that a classifier which realizes an interface has an operation that conforms to every operation in the interface Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Sunday, March 02, 2008 10:50 PM To: uml2-rtf@omg.org Subject: Draft Ballot #5 Attached, please find draft ballot #5. Please review the proposed resolutions and provide any feedback on them by Friday, March 14. Pretty slim pickings, this one. There are just 4 proposed resolutions on this ballot, all of them thanks to Jim Amsden. I guess UML 2 is closing in on perfection. Regards...Bran CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Subject: RE: Draft Ballot #5 Date: Tue, 4 Mar 2008 15:00:07 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Ballot #5 Thread-Index: Ach+Jla39qSzIyKuRV67hjxRR4JOkgAB0/Yg From: "Kenn Hussey" To: "Jim Amsden" , X-OriginalArrivalTime: 04 Mar 2008 20:00:12.0887 (UTC) FILETIME=[5B838670:01C87E32] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15766.003 X-TM-AS-Result: No--33.260000-8.000000-31 Jim, Whether or not it.s a .large. change is a matter of perspective, I suppose. but I.m concerned about the impact to existing tools. 1. Note that the updated OCL for allFeatures() would need to be provided. When I look at the existing OCL, I see that it is based on selecting all of the features that are in the classifier.s namespace. Should operations of a realized interface, then,, be in the namespace of the realizing classifier? Perhaps not, since operations on realized interfaces may in fact overlap/collide. But do callers of this operation currently expect all of a classifier.s features to be in its namespace? 2. I think there is a constraint which covers this ([2] The implemented behavioral feature must be a feature (possibly inherited) of the context classifier of the behavior.). Depending how tools are currently enforcing this constraint, they may or may not need to change; for example, a tool that simply checks that the result of allFeatures() includes the behavior.s specification might not need to change if the algorithm for allFeatures() is changed (as per 1). 3. It would seem that the semantics section of InterfaceRealization would need to be updated (i.e. the part that says .For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..). What concerns me here is that, currently, tools are presumably copying all of an interface.s operations into a realizing classifier when it is realized. if we were to maake this optional (indeed to support the redefinition use case), how are the operations to be distinguished when included in the classifier.s list of features (e.g. in cases where an operation in an interface has in fact also been copied to the classifier)? Currently, the situation it consistent, albeit cumbersome . all operations from realized interffaces must be .copied into. their realizing classifiers, and when redefinition occurs, no additional .copying. needs to be done. If we change the semantics to make .copying. of the operations optional, e.g. only necessary in cases where it needs to be redefined, a more general classifier may need to be .modified. in order to specialize it, e.g. the realized interface operation would need to be .copied over. to the general classifier in order to be able to redefine it in the specific classifier. This makes me wonder whether classes (for example) should be allowed to have operations at all, or whether they should only be allowed to have methods (behaviors). which makes we wonder whether we have a handlle on the true extent of this problem (e.g. do we need to revisit the semantics of redefinition?). Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 04, 2008 1:23 PM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, Why do you see this is a large change? It only changes two things: 1. Classifier::allFeatures includes the features of any realized interfaces 2. The specification of a behavior must be a behavioral feature owned by the containing classifier, inherited by it or in an interface it realizes All this does in allow operations of realized interfaces to be considered operations of the realizing classifier without having to repeat them. It doesn't address the issue of setting the method of an operation changing the operation. Your second bullet is just what I was hoping to avoid - having to copy down all the realized operations and then set their methods. This repeats the parameters three time. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Kenn Hussey" 03/04/2008 09:27 AM To "Bran Selic" , cc Subject RE: Draft Ballot #5 Bran, Here are my comments. 10656 This seems like a large change to be making in an RTF. Rather than changing the way interfaces are realized, why not consider just - making BehavioralFeature::method derived (so that a behavioral feature need not be .modified. in order to describe the behavior of one of its implementations) - adding a constraint to ensure that a classifier which realizes an interface has an operation that conforms to every operation in the interface Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Sunday, March 02, 2008 10:50 PM To: uml2-rtf@omg.org Subject: Draft Ballot #5 Attached, please find draft ballot #5. Please review the proposed resolutions and provide any feedback on them by Friday, March 14. Pretty slim pickings, this one. There are just 4 proposed resolutions on this ballot, all of them thanks to Jim Amsden. I guess UML 2 is closing in on perfection. Regards...Bran CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 X-KeepSent: 9DA70088:BD4FFB3E-85257402:0077AFE1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Tue, 4 Mar 2008 17:54:40 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/04/2008 15:54:42, Serialize complete at 03/04/2008 15:54:42 Kenn, I see your point. I think the fundamental issue is that we don't fully understand the distinction between InterfaceRealization (or Realization in general) and Specialization/Generalization. Jim Odell and I were just having this conversation a few days ago. For specialization, the features of the general classifier do not have to be copied down into the special classifier in order to be defined, available in allFeatures(), or redefined. InterfaceRealization should have been treated the same way. The difference between specialization and realization is not precisely defined, but I think it has more to do with coupling than whether realized elements should be copied down or not. An Interface can't be instantiated, only an instance of a realizing classifier can be instantiated. The realizing classifier provides the stateful properties and methods that implement the specification defined by the Interface. This reduces coupling because clients that depend on the Interface are completely decoupled from any implementation. Contrast with an abstract Class and specialization. The abstract superclass could still contain (partial) implementations. So clients that reference the abstract superclass could still end up coupled with those implementations, even if they are all overridden by the subclasses. This is not possible with Interfaces and realizations. You're ensured there is no coupling with any implementation. So I realize that the changes resulting from this apparently simple resolution could have significant consequences for tool vendors who are relying on copy down for interface operations. This is clearly unfortunate. Collisions resulting from the same operation being realized through more than one interface is essentially the same problem as multiple inheritance and should be handled the same way. The semantics you refer to below: ..For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..may be considered OK since the definition of InterfaceRealization says the realizing classifier will have an operation or reception for every one defined by the interface given the change to allFeatures(). Classes can have operations because interfaces are optional. Again this is a coupling issue. Depending on the situation, coupling to particular classes and their method implementations may be fine. Operations are needed for CallOperationAction too. For completeness, redefinition could be extended to work across realizations as well as specialization/generalization. However, I don't think this is necessary. A Class could "copy down" its realized operations, or users could choose to duplicate the operations in the class just so they can see them all in one place. In this case, the operation in the class would simply duplicate the realized operation and could be considered the same operation, just like it is now. Then redefinition would continue to work exactly as it does now, and wouldn't need to be defined across realizations. Tools that require copy down today would still work without change (I think). And if they happened to use allFeatures() to see if a classifier has a feature, and it contained the realized features too, then they might equally work on new models that didn't copy the operations down. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Kenn Hussey" 03/04/2008 03:00 PM To Jim Amsden/Raleigh/IBM@IBMUS, cc Subject RE: Draft Ballot #5 Jim, Whether or not it..s a ..large. change is a matter of perspective, I suppose. but I..m concerned about the impact to existing tools. 1. Note that the updated OCL for allFeatures() would need to be provided. When I look at the existing OCL, I see that it is based on selecting all of the features that are in the classifier..s namespace. Should operations of a realized interface, then, be in the namespace of the realizing classifier? Perhaps not, since operations on realized interfaces may in fact overlap/collide. But do callers of this operation currently expect all of a classifier..s features to be in its namespace? 2. I think there is a constraint which covers this ([2] The implemented behavioral feature must be a feature (possibly inherited) of the context classifier of the behavior.). Depending how tools are currently enforcing this constraint, they may or may not need to change; for example, a tool that simply checks that the result of allFeatures() includes the behavior..s specification might not need to change if the algorithm for allFeatures() is changed (as per 1). 3. It would seem that the semantics section of InterfaceRealization would need to be updated (i.e. the part that says ..For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..). What concerns me here is that, currently, tools are presumably copying all of an interface..s operations into a realizing classifier when it is realized. if we were to make this optional (indeed to support the redefinition use case), how are the operations to be distinguished when included in the classifier..s list of features (e.g. in cases where an operation in an interface has in fact also been copied to the classifier)? Currently, the situation it consistent, albeit cumbersome . all operations from realized interfaces must be ..copied into. their realizing classifiers, and when redefinition occurs, no additional ..copying. needs to be done. If we change the semantics to make ..copying. of the operations optional, e.g. only necessary in cases where it needs to be redefined, a more general classifier may need to be ..modified. in order to specialize it, e.g. the realized interface operation would need to be ..copied over. to the general classifier in order to be able to redefine it in the specific classifier. This maakes me wonder whether classes (for example) should be allowed to have operations at all, or whether they should only be allowed to have methods (behaviors). which makkes we wonder whether we have a handle on the true extent of this problem (e.g. do we need to revisit the semantics of redefinition?). Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 04, 2008 1:23 PM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, Why do you see this is a large change? It only changes two things: 1. Classifier::allFeatures includes the features of any realized interfaces 2. The specification of a behavior must be a behavioral feature owned by the containing classifier, inherited by it or in an interface it realizes All this does in allow operations of realized interfaces to be considered operations of the realizing classifier without having to repeat them. It doesn't address the issue of setting the method of an operation changing the operation. Your second bullet is just what I was hoping to avoid - having to copy down all the realized operations and then set their methods. This repeats the parameters three time. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Kenn Hussey" 03/04/2008 09:27 AM To "Bran Selic" , cc Subject RE: Draft Ballot #5 Bran, Here are my comments. 10656 This seems like a large change to be making in an RTF. Rather than changing the way interfaces are realized, why not consider just - making BehavioralFeature::method derived (so that a behavioral feature need not be ..modified. in order to describe the behavior of one of its implementations) - adding a constraint to ensure that a classifier which realizes an interface has an operation that conforms to every operation in the interface Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Sunday, March 02, 2008 10:50 PM To: uml2-rtf@omg.org Subject: Draft Ballot #5 Attached, please find draft ballot #5. Please review the proposed resolutions and provide any feedback on them by Friday, March 14. Pretty slim pickings, this one. There are just 4 proposed resolutions on this ballot, all of them thanks to Jim Amsden. I guess UML 2 is closing in on perfection. Regards...Bran CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 X-KeepSent: 95BF4F6E:EFE7475B-85257403:00479270; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Jim Amsden Date: Wed, 5 Mar 2008 08:08:43 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 03/05/2008 06:08:45, Serialize complete at 03/05/2008 06:08:45 Kenn, There probably is no solution here that doesn't have some issues. But the current spec, and the use of copy-down of operations, is probably not the best. Further comments embedded below... Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Kenn Hussey" 03/04/2008 09:27 PM To Jim Amsden/Raleigh/IBM@IBMUS, cc Subject RE: Draft Ballot #5 Jim, Thanks. I do understand the problem you are trying to address; I just question what the best solution is. Note that it should be possible for a class to realize two interfaces that declare operations with a compatible signature. In such situations, which operation is the ..real. one if a conforming operation is not defined on the class? Which one does a behavior (method) reference as its specification? What happens when one of the interface realizations gets removed? This is a problem for the copy down approach too. Which operation gets copied? Both? When the interface realizations are removed, are the copied operations removed too? I think if a classifier realizes interfaces that have overlapping operations, the conflicts should be reported and the user should decide how to refactor to remove the conflict, just like the would with multiple inheritance. When an interface realization is removed, the classifier no longer provides those operations, and any of its behaviors what had those operations as their specification simply no longer have specifications. What concerns me most about the proposed resolution is the inconsistency that it allows . I..d rather sayy that behavioral features from realized interfaces always be ..copied down. or not. Leaving the choice to tools will no doubt lead to problems, among them being further interoperability challenges. There's really no inconsistency. The semantics apply whether the operations are copied down or not as long as allFeatures() includes the realized operations. Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 04, 2008 5:55 PM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, I see your point. I think the fundamental issue is that we don't fully understand the distinction between InterfaceRealization (or Realization in general) and Specialization/Generalization. Jim Odell and I were just having this conversation a few days ago. For specialization, the features of the general classifier do not have to be copied down into the special classifier in order to be defined, available in allFeatures(), or redefined. InterfaceRealization should have been treated the same way. The difference between specialization and realization is not precisely defined, but I think it has more to do with coupling than whether realized elements should be copied down or not. An Interface can't be instantiated, only an instance of a realizing classifier can be instantiated. The realizing classifier provides the stateful properties and methods that implement the specification defined by the Interface. This reduces coupling because clients that depend on the Interface are completely decoupled from any implementation. Contrast with an abstract Class and specialization. The abstract superclass could still contain (partial) implementations. So clients that reference the abstract superclass could still end up coupled with those implementations, even if they are all overridden by the subclasses. This is not possible with Interfaces and realizations. You're ensured there is no coupling with any implementation. So I realize that the changes resulting from this apparently simple resolution could have significant consequences for tool vendors who are relying on copy down for interface operations. This is clearly unfortunate. Collisions resulting from the same operation being realized through more than one interface is essentially the same problem as multiple inheritance and should be handled the same way. The semantics you refer to below: ..For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..may be considered OK since the definition of InterfaceRealization says the realizing classifier will have an operation or reception for every one defined by the interface given the change to allFeatures(). Classes can have operations because interfaces are optional. Again this is a coupling issue. Depending on the situation, coupling to particular classes and their method implementations may be fine. Operations are needed for CallOperationAction too. For completeness, redefinition could be extended to work across realizations as well as specialization/generalization. However, I don't think this is necessary. A Class could "copy down" its realized operations, or users could choose to duplicate the operations in the class just so they can see them all in one place. In this case, the operation in the class would simply duplicate the realized operation and could be considered the same operation, just like it is now. Then redefinition would continue to work exactly as it does now, and wouldn't need to be defined across realizations. Tools that require copy down today would still work without change (I think). And if they happened to use allFeatures() to see if a classifier has a feature, and it contained the realized features too, then they might equally work on new models that didn't copy the operations down. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Kenn Hussey" 03/04/2008 03:00 PM To Jim Amsden/Raleigh/IBM@IBMUS, cc Subject RE: Draft Ballot #5 Jim, Whether or not it..s a ..large. change is a matter of perspective, I suppose. but I..m concerned about the impact to existing tools. 1. Note that the updated OCL for allFeatures() would need to be provided. When I look at the existing OCL, I see that it is based on selecting all of the features that are in the classifier..s namespace. Should operations of a realized interface, then, be in the namespace of the realizing classifier? Perhaps not, since operations on realized interfaces may in fact overlap/collide. But do callers of this operation currently expect all of a classifier..s features to be in its namespace? 2. I think there is a constraint which covers this ([2] The implemented behavioral feature must be a feature (possibly inherited) of the context classifier of the behavior.). Depending how tools are currently enforcing this constraint, they may or may not need to change; for example, a tool that simply checks that the result of allFeatures() includes the behavior..s specification might not need to change if the algorithm for allFeatures() is changed (as per 1). 3. It would seem that the semantics section of InterfaceRealization would need to be updated (i.e. the part that says ..For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface..). What concerns me here is that, currently, tools are presumably copying all of an interface..s operations into a realizing classifier when it is realized. if we were to make this optional (indeed to supportt the redefinition use case), how are the operations to be distinguished when included in the classifier..s list of features (e.g. in cases where an operation in an interface has in fact also been copied to the classifier)? Currently, the situation it consistent, albeit cumbersome . all operations fromm realized interfaces must be ..copied into. their realizing classifiers, and when redefinition occurs, no additional ..copying. needs to be done. If we change the semantics to make ..copying. of the operations optional, e.g. only necessary in cases where it needs to be redefined, a more general classifier may need to be ..modified. in order to specialize it, e.g. the realized interface operation would need to be ..copied over. to the general classifier in order to be able to redefine it in the specific classifier. This makes me wonder whethher classes (for example) should be allowed to have operations at all, or whether they should only be allowed to have methods (behaviors). which makes we wonder whetherr we have a handle on the true extent of this problem (e.g. do we need to revisit the semantics of redefinition?). Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 04, 2008 1:23 PM To: uml2-rtf@omg.org Subject: RE: Draft Ballot #5 Kenn, Why do you see this is a large change? It only changes two things: 1. Classifier::allFeatures includes the features of any realized interfaces 2. The specification of a behavior must be a behavioral feature owned by the containing classifier, inherited by it or in an interface it realizes All this does in allow operations of realized interfaces to be considered operations of the realizing classifier without having to repeat them. It doesn't address the issue of setting the method of an operation changing the operation. Your second bullet is just what I was hoping to avoid - having to copy down all the realized operations and then set their methods. This repeats the parameters three time. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 "Kenn Hussey" 03/04/2008 09:27 AM To "Bran Selic" , cc Subject RE: Draft Ballot #5 Bran, Here are my comments. 10656 This seems like a large change to be making in an RTF. Rather than changing the way interfacess are realized, why not consider just - making BehavioralFeature::method derived (so that a behavioral feature need not be ..modified. in order to describe the behavior of one of its implementations) - adding a constraint to ensure that a classifier which realizes an interface has an operation that conforms to every operation in the interface Cheers, Kenn Hussey Program Manager, EA/Studio Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Sunday, March 02, 2008 10:50 PM To: uml2-rtf@omg.org Subject: Draft Ballot #5 Attached, please find draft ballot #5. Please review the proposed resolutions and provide any feedback on them by Friday, March 14. Pretty slim pickings, this one. There are just 4 proposed resolutions on this ballot, all of them thanks to Jim Amsden. I guess UML 2 is closing in on perfection. Regards...Bran CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. X-MailScanner-Watermark: 1206473266.45827@N1NEzTDadqZfOhFCCNUtKw Reply-To: From: "Conrad Bock" To: Subject: RE: Draft Ballot #5, 10656 Date: Tue, 18 Mar 2008 15:27:41 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach84hqN3o38m19mRreAV0NzvHf+IwIcj7fAAPZbjpA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m2IJRfx2010548 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No RTFers, See the last sentence below from the proposed resolution to 10656 (clarification on Behavior::specification / meaning of InterfaceRealization): For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the realizing classifier will provide functionality that maintains the state represented by the property. That is, the additional operation Classifier::allFeatures includes the features of the realized interfaces. Therefore Classifier::allFeatures may contain more features than the feature derived union. As nearly as I can tell, this is contradicting the semantics of derived union. Can someone clarify or file an objection to remove it from the ballot? Conrad