Issue 18727: The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features. For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable: // difference in the parameter direction op1(String) op1():String // difference in the parameter effect op2(update String) op2(delete String) // difference in the parameter exception op3(Throwable) op3() throws Throwable // difference in the parameter collection characteristics op4(Set(String)) op4(String[1]) This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …) This can be easily fixed. In the OCL for BehavioralFeature::isDistinguishableFrom(), replace: ...->isUnique(ownedParameter->collect(type)) With: …->isUnique(ownedParameter->collect(p|Tuple{name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper})) Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures. Resolution: Revised Text: Actions taken: May 22, 2013: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: Juergen Boldt CC: Ed Seidewitz , Steve Cook Subject: Re: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Topic: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Index: AQHOVvmIE1F+RxVBlUSoq/7rSCM9NJkRWG2A Date: Wed, 22 May 2013 15:44:07 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Jurgen, Yes, there are 2 issues. Based on Ed's useful comments, I corrected the description of the 1st issue. Issue 1: The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice. The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features. For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable: // difference in the parameter direction op1(String) op1():String // difference in the parameter effect op2(update String) op2(delete String) // difference in the parameter exception op3(Throwable) op3() throws Throwable // difference in the parameter collection characteristics op4(Set(String)) op4(String[1]) This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, .) This can be easily fixed. In the OCL for BehavioralFeature::isDistinguishableFrom(), replace: ...->isUnique(ownedParameter->collect(type)) With: .->isUnique(ownedParameter->collect(p|Tuple{name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper})) Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures. From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml25-ftf@omg.org" Subject: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Topic: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Index: AQHOVvKpnCd895tD5kqDrPPrhoocZQ== Date: Wed, 22 May 2013 13:45:46 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same kind but with different Parameter signatures are not distinguishable; for example, two StateMachines with distinct Parameter signatures are not Namespace distinguishable. This means that a given BehavioredClassifier with distinguishable BehavioralFeatures, e.g., op() and op(String) cannot have nested Behaviors as the methods of these BehavioralFeatures, e.g., SM() and SM(String) -- a notation shortcut for StateMachines with, respectively, no Parameters and a single Parameter typed by String. Clearly, Behavior needs to override NamedElement::isDistinguishableFrom(); perhaps using the same criteria as BehavioralFeature::isDistinguishableFrom(). However, the latter refers to an undefined operation: isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is also unclear what information about Parameters should be included in the signature of a BehavioralFeature or of a Behavior: name, direction, effect, isException, isStream, type. - Nicolas. From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml25-ftf@omg.org" Subject: Re: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Topic: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Index: AQHOVvKpnCd895tD5kqDrPPrhoocZZkRPhwA Date: Wed, 22 May 2013 14:09:44 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org I think there are two separate issues: 1) Bug in BehavioralFeature::isDistinguishableFrom() isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is unclear what information about Parameters should be included in the signature as a criteria for distinguishing different BehavioralFeatures of the same name and kind: name, direction, effect, isException, isStream, type. 2) Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are. For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable. It is unclear whether this is an explicit intent of the spec or a bug in the spec. - Nicolas. From: , JPL Date: Wednesday, May 22, 2013 6:45 AM To: "issues@omg.org" Cc: "uml25-ftf@omg.org" Subject: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same kind but with different Parameter signatures are not distinguishable; for example, two StateMachines with distinct Parameter signatures are not Namespace distinguishable. This means that a given BehavioredClassifier with distinguishable BehavioralFeatures, e.g., op() and op(String) cannot have nested Behaviors as the methods of these BehavioralFeatures, e.g., SM() and SM(String) -- a notation shortcut for StateMachines with, respectively, no Parameters and a single Parameter typed by String. Clearly, Behavior needs to override NamedElement::isDistinguishableFrom(); perhaps using the same criteria as BehavioralFeature::isDistinguishableFrom(). However, the latter refers to an undefined operation: isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is also unclear what information about Parameters should be included in the signature of a BehavioralFeature or of a Behavior: name, direction, effect, isException, isStream, type. - Nicolas. X-Virus-Scanned: OK From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" , "issues@omg.org" CC: "uml25-ftf@omg.org" Subject: RE: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Topic: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Index: AQHOVvKpnCd895tD5kqDrPPrhoocZZkRPhwAgAABtQA= Date: Wed, 22 May 2013 14:31:51 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.216.31.36] X-Virus-Scanned: amavisd-new at omg.org Nicolas . On your first issue, .isUnique. is defined in subclause 11.9.1.3 of the OCL 2.3.1 spec (formal/12-01-01): 11.9.1.3 isUnique Results in true if body evaluates to a different value for each element in the source collection; otherwise, result is false. source->isUnique (iterator | body) = source->collect (iterator | Tuple{iter = Tuple{iterator}, value = body}) ->forAll (x, y | (x.iter <> y.iter) implies (x.value <> y.value)) isUnique may have at most one iterator variable. Beyond that, considering more than parameter type for behavioral feature distinguishability would make overload resolution very difficult. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, May 22, 2013 9:10 AM To: issues@omg.org Cc: uml25-ftf@omg.org Subject: Re: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() I think there are two separate issues: 1) Bug in BehavioralFeature::isDistinguishableFrom() isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is unclear what information about Parameters should be included in the signature as a criteria for distinguishing different BehavioralFeatures of the same name and kind: name, direction, effect, isException, isStream, type. 2) Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are. For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable. It is unclear whether this is an explicit intent of the spec or a bug in the spec. - Nicolas. From: , JPL Date: Wednesday, May 22, 2013 6:45 AM To: "issues@omg.org" Cc: "uml25-ftf@omg.org" Subject: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same kind but with different Parameter signatures are not distinguishable; for example, two StateMachines with distinct Parameter signatures are not Namespace distinguishable. This means that a given BehavioredClassifier with distinguishable BehavioralFeatures, e.g., op() and op(String) cannot have nested Behaviors as the methods of these BehavioralFeatures, e.g., SM() and SM(String) -- a notation shortcut for StateMachines with, respectively, no Parameters and a single Parameter typed by String. Clearly, Behavior needs to override NamedElement::isDistinguishableFrom(); perhaps using the same criteria as BehavioralFeature::isDistinguishableFrom(). However, the latter refers to an undefined operation: isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is also unclear what information about Parameters should be included in the signature of a BehavioralFeature or of a Behavior: name, direction, effect, isException, isStream, type. - Nicolas. From: "Rouquette, Nicolas F (313K)" To: Juergen Boldt CC: Ed Seidewitz , Steve Cook Subject: Re: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Topic: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Thread-Index: AQHOVvmIE1F+RxVBlUSoq/7rSCM9NJkRWG2A Date: Wed, 22 May 2013 15:44:07 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Jurgen, Yes, there are 2 issues. Based on Ed's useful comments, I corrected the description of the 1st issue. Issue 1: The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice. The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features. For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable: // difference in the parameter direction op1(String) op1():String // difference in the parameter effect op2(update String) op2(delete String) // difference in the parameter exception op3(Throwable) op3() throws Throwable // difference in the parameter collection characteristics op4(Set(String)) op4(String[1]) This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, .) This can be easily fixed. In the OCL for BehavioralFeature::isDistinguishableFrom(), replace: ...->isUnique(ownedParameter->collect(type)) With: .->isUnique(ownedParameter->collect(p|Tuple{name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper})) Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures. Issue 2: Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are. For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable. It is unclear whether this is an explicit intent of the spec or a bug in the spec. - Nicolas. From: Juergen Boldt Date: Wednesday, May 22, 2013 7:34 AM To: JPL Subject: Re: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() Nicolas, so you want me to file these two issues as stated? -Juergen At 10:09 AM 5/22/2013, you wrote: I think there are two separate issues: 1) Bug in BehavioralFeature::isDistinguishableFrom() isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is unclear what information about Parameters should be included in the signature as a criteria for distinguishing different BehavioralFeatures of the same name and kind: name, direction, effect, isException, isStream, type. 2) Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are. For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable. It is unclear whether this is an explicit intent of the spec or a bug in the spec. - Nicolas. From: , JPL < nicolas.f.rouquette@jpl.nasa.gov> Date: Wednesday, May 22, 2013 6:45 AM To: "issues@omg.org" Cc: "uml25-ftf@omg.org" Subject: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same kind but with different Parameter signatures are not distinguishable; for example, two StateMachines with distinct Parameter signatures are not Namespace distinguishable. This means that a given BehavioredClassifier with distinguishable BehavioralFeatures, e.g., op() and op(String) cannot have nested Behaviors as the methods of these BehavioralFeatures, e.g., SM() and SM(String) -- a notation shortcut for StateMachines with, respectively, no Parameters and a single Parameter typed by String. Clearly, Behavior needs to override NamedElement::isDistinguishableFrom(); perhaps using the same criteria as BehavioralFeature::isDistinguishableFrom(). However, the latter refers to an undefined operation: isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It specifies that they must have different signatures. body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()) implies Set{self}->including(n.oclAsType(BehavioralFeature))->isUnique(ownedParameter->collect(type)) The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. It is also unclear what information about Parameters should be included in the signature of a BehavioralFeature or of a Behavior: name, direction, effect, isException, isStream, type. - Nicolas. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=327a6lRqHX8A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=VbOeyx5u4VUA:10 a=vJv5mCtPP0cCuFiQzUIA:9 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 Date: Wed, 22 May 2013 16:52:24 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "uml25-ftf@omg.org" Subject: Re: Bug in BehavioralFeature::isDistinguishableFrom() and missing operation Behavior::isDistinguishableFrom() X-Virus-Scanned: amavisd-new at omg.org On 22/05/2013 14:45, Rouquette, Nicolas F (313K) wrote: The comparison of signatures is flawed: there is no "isUnique()" operation defined in OCL or in UML. See OCL 2.0 11.9.1 where the isUnique iteration is specified. Regards Ed Willink