Issue 14084: Subsets vs. Redefines (uml2-rtf) Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel. For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined). These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly. Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for? Resolution: Revised Text: Actions taken: May 8, 2009: received issue Discussion: End of Annotations:===== ubject: Subsets vs. Redefines To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 8 May 2009 11:01:00 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 05/08/2009 11:01:01 Hi all, Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel. For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined). These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly. Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for? Just a thought... -------------------------------------------------------------------------------- Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab +1 613 270 4651 Reply-To: From: "Conrad Bock" To: Subject: RE: Subsets vs. Redefines Date: Mon, 11 May 2009 16:13:46 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnP7n8zzw4eKjqrQ7eirnIpMU38FACfW7Dw X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4BKDqTB018818 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242677637.66452@I000JoOK1ffYr4EnssROsg X-Spam-Status: No Maged, > Although I have read the sections in Infrastructure that > talks about the meaning of association redefinition and > subsetting, and I understand it for the most part, I find > myself not sure sometimes which one to use when modeling > associations that need to be specialized further down an > inheritance hierarchy. This happened to me as I was > modeling some parts of the new Diagram Definition metammodel. Subsetting means all values of the specialized property / association end are also values of the general property on each instance of the specialized class. For example, the property hasSister subsets hasSibling (everyone's sister is also their sibling). Redefinition is much more drastic, because it eliminates the property being redefined (the higher, more general one) from the specialized class that has the redefinition. The only reason I can think of to do this is if the specialized property has the same name as the general one (subsets requires differently named properties). This is also used on operations to override their methods in specialized classes. > For some cases, it is obvious what to do like when you have > an association with * multipclity that you expect to be > populated differently down the hierarchy so you make it > "derived union" in anticipation of subclasses subsetting > it. However, for an association with 1..1 or 0..1 > multipclity that you expect it to be specialized, I am not > sure whether to declare it as derived union or as a regular > association (in the latter case, I expect it to be redeined). If the association end (Property) has multiplicity max of one, then subsetting ensures that only one of the specialized properties will have a value on each instance of the specialized class. Maybe this is why the "xor" constraint in UML 1 was removed in UML 2. > It is unfortunate, since these association semantics do have a good > mapping to some popular programming languages (like Java as evident > by the Eclipse UML2 implementation) and can help modelers intending > to generate code from models had they know how to use them properly. I gather you mean to generate the accessors to the properties? Most most programming languages don't directly support subsets/redefines. > Maybe we need some section in the spec giving a > practitioner some guidance in when and how to use these > concepts based on different situations that go beyond > explaining what they are for? The text around subsets/redefines could certainly be cleaned up. For example, there is a semantic variation point: The interaction of association specialization with association end redefinition and subsetting is not defined. This isn't true for subsetting, because generalization of association classes has the same semantics as subsetting the ends, by the definitions of these given in the spec. In the earlier hasSister example, the properties could be replaced with associations classes / generalization and everyone's sister would still be their sibling. Conrad Subject: RE: Subsets vs. Redefines To: Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 11 May 2009 17:15:15 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 05/11/2009 17:15:15 Conrad, I saw several cases in the UML spec where redefinition changed the name, like 'Class::superClass' redefines 'Classifier::general', so that made me wonder when to use redefinition vs. subsetting. There are some ovbious cases for both, but I am wondering about the less obvious ones. I think redfinition of a property is allowed to happen "once" at every classifier, where subsetting could be many. However, if you have a designing a 0..1 multiplicity property, wihich you expect to be specialied. Do you use redefinition or subsetting? aren't both equally aplicable if you expect one specialization in every lower classifier? In that case is there some logic to make you choose? For example in DD... a view has a context property of 0..1, do you make thi a derived union, so that more special views can have properties with multipclity 1..1 that subset it? or do you make it a regular property and let subclasses redefine it with a multipclitiy 1..1? The same question goes for a connector's source and target property. Are you saying that for association classes, with specializing the association class itself, there is no need to also specialize the ends with subsetting / redefinition? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Conrad Bock" wrote on 05/11/2009 04:13:46 PM: > Maged, > > > Although I have read the sections in Infrastructure that > > talks about the meaning of association redefinition and > > subsetting, and I understand it for the most part, I find > > myself not sure sometimes which one to use when modeling > > associations that need to be specialized further down an > > inheritance hierarchy. This happened to me as I was > > modeling some parts of the new Diagram Definition metammodel. > > Subsetting means all values of the specialized property / association > end are also values of the general property on each instance of the > specialized class. For example, the property hasSister subsets > hasSibling (everyone's sister is also their sibling). > > Redefinition is much more drastic, because it eliminates the property > being redefined (the higher, more general one) from the specialized > class that has the redefinition. The only reason I can think of to do > this is if the specialized property has the same name as the general one > (subsets requires differently named properties). This is also used on > operations to override their methods in specialized classes. > > > For some cases, it is obvious what to do like when you have > > an association with * multipclity that you expect to be > > populated differently down the hierarchy so you make it > > "derived union" in anticipation of subclasses subsetting > > it. However, for an association with 1..1 or 0..1 > > multipclity that you expect it to be specialized, I am not > > sure whether to declare it as derived union or as a regular > > association (in the latter case, I expect it to be redeined). > > If the association end (Property) has multiplicity max of one, then > subsetting ensures that only one of the specialized properties will have > a value on each instance of the specialized class. Maybe this is why > the "xor" constraint in UML 1 was removed in UML 2. > > > It is unfortunate, since these association semantics do have a good > > mapping to some popular programming languages (like Java as evident > > by the Eclipse UML2 implementation) and can help modelers intending > > to generate code from models had they know how to use them properly. > > I gather you mean to generate the accessors to the properties? Most > most programming languages don't directly support subsets/redefines. > > > Maybe we need some section in the spec giving a > > practitioner some guidance in when and how to use these > > concepts based on different situations that go beyond > > explaining what they are for? > > The text around subsets/redefines could certainly be cleaned up. For > example, there is a semantic variation point: > > The interaction of association specialization with association end > redefinition and subsetting is not defined. > > This isn't true for subsetting, because generalization of association > classes has the same semantics as subsetting the ends, by the > definitions of these given in the spec. In the earlier hasSister > example, the properties could be replaced with associations classes / > generalization and everyone's sister would still be their sibling. > > Conrad > Reply-To: From: "Conrad Bock" To: Subject: RE: Subsets vs. Redefines Date: Mon, 11 May 2009 17:39:59 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2A= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4BLe4Un029715 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242682805.94386@8YYxDRMONHknn2tK1kclsA X-Spam-Status: No Maged, > I saw several cases in the UML spec where redefinition > changed the name, like 'Class::superClass' redefines > 'Classifier::general', so that made me wonder when to use > redefinition vs. subsetting. That's completely eliminates substitutability, you can't even read the redefined property on instances on the subclass, like you can with subsetting (both break substitutability of writing). I'd avoid redefinition that changes the name. > I think redfinition of a property is allowed to happen "once" at > every classifier, where subsetting could be many. Would hope so, but haven't checked the constraints. > However, if you have a designing a 0..1 multiplicity property, > wihich you expect to be specialied. Do you use redefinition or > subsetting? aren't both equally aplicable if you expect one > specialization in every lower classifier? In that case is there some > logic to make you choose? Use subsetting if the specialized property has a different name, and you want to be able to access the general property on instances of the subclass. Use redefinition if the specialized property has the same name as the general property (for example to narrow the type or multiplicity, but have the same name), or if you want to prevent access to the general property on instances of the specialized classifier (the names are different in the case). I can't think how the multiplicity would affect your choice in either case. > For example in DD... a view has a context property of 0..1, > do you make thi a derived union, so that more special views > can have properties with multipclity 1..1 that subset it? > or do you make it a regular property and let subclasses > redefine it with a multipclitiy 1..1? I assume you'd want to read the context property on instances of the specialized views, wouldn't you? This gives applications a uniform way to access the context object regardless of the specializations. If so, use subsetting. > Are you saying that for association classes, with > specializing the association class itself, there is no need > to also specialize the ends with subsetting / redefinition? There's certainly no need for subsetting, since class specialization is already subsetting the links (instances) of the association class, by the definition of generalization (every instance of the specialized class is an instance of the general class). I can't see the need for redefinition if the names are the same. Redefinition with different names would clash with association generalization. Conrad Subject: RE: Subsets vs. Redefines Date: Mon, 11 May 2009 18:22:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Subsets vs. Redefines Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAS+LQA== From: "Ed Seidewitz" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4BMLn0i022046 As was pointed out to me the other day, one should also realize that subsetting can be used with or without a derived union. If the superset property is NOT a derived union, then the semantics of subsetting is simply that of a constraint between two different properties. The set of values for the subset property must be a subset of the set of values of the superset property. On the other hand, if the superset property IS a derived union, then the values of the superset property are DEFINED to be the union of the value of its subsets. That is, one never directly sets the values of the derived union property, but every time a value is added to one of its subset properties it automatically becomes a value of the derived union property. Now, by construction, a subset property of a derived union does meet the general subset constraint. But the semantic implications are different. Without a derived union, one cannot add a value to a subset property that is not already in the superset without violating the constraint. With a derived union, adding a value to a subset property also, implicitly, adds that value to the derived union, so the subset constraint is maintained. As Conrad has pointed out, the semantics of redefinition is significantly different than any of the above -- though sometimes the spec seems to be trying to use it to a similar effect. I would agree with Conrad that this is often wrong. -- Ed > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, May 11, 2009 5:40 PM > To: uml2-rtf@omg.org > Subject: RE: Subsets vs. Redefines > > Maged, > > > I saw several cases in the UML spec where redefinition > > changed the name, like 'Class::superClass' redefines > > 'Classifier::general', so that made me wonder when to use > > redefinition vs. subsetting. > > That's completely eliminates substitutability, you can't even read the > redefined property on instances on the subclass, like you can with > subsetting (both break substitutability of writing). I'd avoid > redefinition that changes the name. > > > I think redfinition of a property is allowed to happen "once" at > > every classifier, where subsetting could be many. > > Would hope so, but haven't checked the constraints. > > > However, if you have a designing a 0..1 multiplicity property, > > wihich you expect to be specialied. Do you use redefinition or > > subsetting? aren't both equally aplicable if you expect one > > specialization in every lower classifier? In that case is there some > > logic to make you choose? > > Use subsetting if the specialized property has a different name, and you > want to be able to access the general property on instances of the > subclass. > > Use redefinition if the specialized property has the same name as the > general property (for example to narrow the type or multiplicity, but > have the same name), or if you want to prevent access to the general > property on instances of the specialized classifier (the names are > different in the case). > > I can't think how the multiplicity would affect your choice in either > case. > > > For example in DD... a view has a context property of 0..1, > > do you make thi a derived union, so that more special views > > can have properties with multipclity 1..1 that subset it? > > or do you make it a regular property and let subclasses > > redefine it with a multipclitiy 1..1? > > I assume you'd want to read the context property on instances of the > specialized views, wouldn't you? This gives applications a uniform way > to access the context object regardless of the specializations. If so, > use subsetting. > > > Are you saying that for association classes, with > > specializing the association class itself, there is no need > > to also specialize the ends with subsetting / redefinition? > > There's certainly no need for subsetting, since class specialization is > already subsetting the links (instances) of the association class, by > the definition of generalization (every instance of the specialized > class is an instance of the general class). I can't see the need for > redefinition if the names are the same. Redefinition with different > names would clash with association generalization. > > Conrad > Subject: RE: Subsets vs. Redefines Date: Mon, 11 May 2009 19:22:47 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Subsets vs. Redefines Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0A== From: "Cory Casanave" To: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4BNLaWH006422 Conrad, I think both concepts (subsets & redefines), as well as renaming, are useful and valid. Redefines or subsets is useful in the situation where you need to further constrain the type of a property in a subclass. Example: Domestic invoice (a subtype of invoice) references domestic address (a subtype of address). In this case it would be a redefines. Providing a new name is useful when the new name is more relevant in the new context - it doesn't mean the old name can't be valid as well, so it ends up being a synonym. Subsets us useful when either of the above (or other constraints) only applies to some of the relations/values - redefines is useful when the new name or constraints are valid for some of the relations/values. Example: "Pepperoni pizza" has-topping "Pepperoni". (Subsets - other toppings are ok as well) In OWL we have subproperty, which seems to me to be well defined and the same as "subsets" - of course you could further constrains it such that it would be a redefines using a restriction. So they seem to have been able to work it out in OWL. I understand that this breaks some peoples conception of "substitutability", but subclasses can introduce constraints and any such constraints will "break" substitutability if it is interpreted very strictly. So it seems to me that the substitutability that is practical is one that allows a subtype to throw an exception (or whatever the technology equ is) if it is put into an invalid state - not one that assumes all states of a supertype are valid for all subtypes. (so, covariance, not contravariance). Example: Square is a rectangle, setting the sides to not be equal would be an exception (or require a change in type). I'm not proposing changing anything (for a change!), but just speaking up for useful features. -Cory -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Monday, May 11, 2009 5:40 PM To: uml2-rtf@omg.org Subject: RE: Subsets vs. Redefines Maged, > I saw several cases in the UML spec where redefinition > changed the name, like 'Class::superClass' redefines > 'Classifier::general', so that made me wonder when to use > redefinition vs. subsetting. That's completely eliminates substitutability, you can't even read the redefined property on instances on the subclass, like you can with subsetting (both break substitutability of writing). I'd avoid redefinition that changes the name. > I think redfinition of a property is allowed to happen "once" at > every classifier, where subsetting could be many. Would hope so, but haven't checked the constraints. > However, if you have a designing a 0..1 multiplicity property, > wihich you expect to be specialied. Do you use redefinition or > subsetting? aren't both equally aplicable if you expect one > specialization in every lower classifier? In that case is there some > logic to make you choose? Use subsetting if the specialized property has a different name, and you want to be able to access the general property on instances of the subclass. Use redefinition if the specialized property has the same name as the general property (for example to narrow the type or multiplicity, but have the same name), or if you want to prevent access to the general property on instances of the specialized classifier (the names are different in the case). I can't think how the multiplicity would affect your choice in either case. > For example in DD... a view has a context property of 0..1, > do you make thi a derived union, so that more special views > can have properties with multipclity 1..1 that subset it? > or do you make it a regular property and let subclasses > redefine it with a multipclitiy 1..1? I assume you'd want to read the context property on instances of the specialized views, wouldn't you? This gives applications a uniform way to access the context object regardless of the specializations. If so, use subsetting. > Are you saying that for association classes, with > specializing the association class itself, there is no need > to also specialize the ends with subsetting / redefinition? There's certainly no need for subsetting, since class specialization is already subsetting the links (instances) of the association class, by the definition of generalization (every instance of the specialized class is an instance of the general class). I can't see the need for redefinition if the names are the same. Redefinition with different names would clash with association generalization. Conrad From: "Rouquette, Nicolas F" To: "conrad.bock@nist.gov" , "uml2-rtf@omg.org" Date: Mon, 11 May 2009 23:34:01 -0700 Subject: RE: Subsets vs. Redefines Thread-Topic: Subsets vs. Redefines Thread-Index: AcnP7n8zzw4eKjqrQ7eirnIpMU38FACfW7DwABXNbRA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4C6XmOS021376 > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, May 11, 2009 1:14 PM > To: uml2-rtf@omg.org > Subject: RE: Subsets vs. Redefines > > Maged, > ... > If the association end (Property) has multiplicity max of one, then > subsetting ensures that only one of the specialized properties will have > a value on each instance of the specialized class. Maybe this is why > the "xor" constraint in UML 1 was removed in UML 2. > > > It is unfortunate, since these association semantics do have a good > > mapping to some popular programming languages (like Java as evident > > by the Eclipse UML2 implementation) and can help modelers intending > > to generate code from models had they know how to use them properly. [NFR] Careful... In the case of the Eclipse UML2 implementation, the mapping of association semantics to a programming language depends on 3 things: 1) the Eclipse UML2 implementation of the package merge rules. These rules can optionally compute when an association A2 must be a specialization of another association A1 if at least one of A2's member ends redefines or subsets one of A1's owned member ends. 2) the Eclipse UML2 code generation which is an extension of the Eclipse EMF code generator 3) the Eclipse UML2 code generation package merge increment which adds to the OMG UML superstructure the annotations that the Eclipse UML2 code generator uses to produce the Eclipse UML2 implementation. > I gather you mean to generate the accessors to the properties? Most > most programming languages don't directly support subsets/redefines. > > > Maybe we need some section in the spec giving a > > practitioner some guidance in when and how to use these > > concepts based on different situations that go beyond > > explaining what they are for? > > The text around subsets/redefines could certainly be cleaned up. For > example, there is a semantic variation point: > > The interaction of association specialization with association end > redefinition and subsetting is not defined. > > This isn't true for subsetting, because generalization of association > classes has the same semantics as subsetting the ends, by the > definitions of these given in the spec. [NFR] Careful... This isn't true for both subsetting and redefinition of association-owned member ends. In the case of subsetting or redefinition of association ends owned by the classifier, the meaning of association specialization is unclear at best; the SVP is warranted in this case. Last year, when I was working on the fUML metamodel, I ran into these questions quite often. After a while, I built my own metamodeling extension for RSA 7.0 / 7.5 for editing property subsets/redefinitions and proposed criteria for user-friendly editing of such things: http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.uml2/msg02386.html So far, the Eclipse UML/OCL implementation is the only major tool out there I found with which I can even contemplate writing a non-trivial expression of this kind and invoke it as part of implementing my extension. With other tools, I've had to program the same thing using the tool-specific API because of various unfortunate issues with the OCL. Hats off to the Eclipse UML/OCL developers! -- Nicolas. > Conrad Subject: RE: Subsets vs. Redefines Date: Tue, 12 May 2009 02:26:07 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Subsets vs. Redefines Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7g From: "Pete Rivett" To: "Cory Casanave" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4C9SHu9019872 > Providing a new name is useful when the new name is more relevant in the new context - it doesn't mean the old name can't be valid as well, so it ends up being a synonym. That's not true: the redefine prevents use of the original name against an instance of the subclass. (it took me a while to track down a reference to back this up. It's in the following (within 7.3.7 Class): [1] The inherit operation is overridden to exclude redefined properties. Class::inherit(inhs: Set(NamedElement)) : Set(NamedElement); inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))->select(redefinedElement->includes(inh))) The semantics of subsets change somewhat when it subsets a derived union - because then it contributes to the distributed definition of the union. Personally I don't much like this 'bottom up' definition but guess we've got to live with it. Another difference is that subsets can apply to another property of the same class - redefines can only apply to a property of the superclass. And there is the constraint [10] that " A Property cannot be subset by a Property with the same name" There are other detailed constraints that differ between subsets and redefines. Bottom line my advice would be: - if it's a derived union then you need to use subsets - if the property is in effect derived via a predicate (e.g. Package::/nestedPackage) then use subsets - if the original property is defined against the same class then use subsets - to retain access to the original property then use subsets: this is especially useful for allowing generic browsing of a composition hierarchy for example When then might it make sense to use {redefines}? I looked for some examples... a) I came across what seems to be a pointless redefinition: in Figure 8.11 Operation::ownedParameter:Parameter[*] {redefines BehavioralFeature:ownedParameter:Parameter[*]} but the redefinition differs not a jot from the original! b) we have Class::/superclass:Class[*] {redefines Classifier::/general:Classifier[*]}. This would IMHO be better as {subsets} - since it would be useful to have 'general' available for generic inheritance tree browsing c) Operation::raisedException:Type[*] is used to 'unify' 2 inherited features Basic::Operation::raisedException:Type[*] and BehavioralFeature::raisedException:Type[*]. However Kernel::Operation does not inherit from Basic and so the redefinition is pointless. d) PackageableElement::visibility:VisibilityKind[1] = true {redefines NamedElement::visibility:VisibilityKind[0..1]} (the latter has no default). This is a genuine use of {redefines} though there is a bug in that 'true' is not a valid literal for VisibilityKind. The tightening of multipicity could have been achieved by a constraints on PackageableElement to say that visibility is not empty, but the change in default value could not. e) CreateLinkAction::endData:LinkEndCreationData[2..*] {redefines LinkAction::endData:LinkEndData[2..*]}. f) DestroyLinkAction::endData:LinkEndDestructionData[2..*] {redefines LinkAction::endData:LinkEndData[2..*]}. ...there are approx 20 more uses of redefines. It might be useful to analyse them all as above. Pete PS Another email in this thread claimed that 'xor' had been dropped from UML2. That's is untrue. See 7.3.10 and Fig 7.34. It is, however, exceptionally badly specified (there is at least one issue for this - I raised it). BTW this is a far more useful discussion than the following text added to the spec - which I voted against at the time since I felt it made the text even less clear than it was (from 7.3.3 Semantics): ---> Subsetting is a relationship in the domain of extensional semantics. Specialization is, in contrast to subsetting, a relationship in the domain of intentional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naïve but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation.: <---- Pete -----Original Message----- From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 May 2009 16:23 To: conrad.bock@nist.gov; uml2-rtf@omg.org Subject: RE: Subsets vs. Redefines Conrad, I think both concepts (subsets & redefines), as well as renaming, are useful and valid. Redefines or subsets is useful in the situation where you need to further constrain the type of a property in a subclass. Example: Domestic invoice (a subtype of invoice) references domestic address (a subtype of address). In this case it would be a redefines. Providing a new name is useful when the new name is more relevant in the new context - it doesn't mean the old name can't be valid as well, so it ends up being a synonym. Subsets us useful when either of the above (or other constraints) only applies to some of the relations/values - redefines is useful when the new name or constraints are valid for some of the relations/values. Example: "Pepperoni pizza" has-topping "Pepperoni". (Subsets - other toppings are ok as well) In OWL we have subproperty, which seems to me to be well defined and the same as "subsets" - of course you could further constrains it such that it would be a redefines using a restriction. So they seem to have been able to work it out in OWL. I understand that this breaks some peoples conception of "substitutability", but subclasses can introduce constraints and any such constraints will "break" substitutability if it is interpreted very strictly. So it seems to me that the substitutability that is practical is one that allows a subtype to throw an exception (or whatever the technology equ is) if it is put into an invalid state - not one that assumes all states of a supertype are valid for all subtypes. (so, covariance, not contravariance). Example: Square is a rectangle, setting the sides to not be equal would be an exception (or require a change in type). I'm not proposing changing anything (for a change!), but just speaking up for useful features. -Cory -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Monday, May 11, 2009 5:40 PM To: uml2-rtf@omg.org Subject: RE: Subsets vs. Redefines Maged, > I saw several cases in the UML spec where redefinition > changed the name, like 'Class::superClass' redefines > 'Classifier::general', so that made me wonder when to use > redefinition vs. subsetting. That's completely eliminates substitutability, you can't even read the redefined property on instances on the subclass, like you can with subsetting (both break substitutability of writing). I'd avoid redefinition that changes the name. > I think redfinition of a property is allowed to happen "once" at > every classifier, where subsetting could be many. Would hope so, but haven't checked the constraints. > However, if you have a designing a 0..1 multiplicity property, > wihich you expect to be specialied. Do you use redefinition or > subsetting? aren't both equally aplicable if you expect one > specialization in every lower classifier? In that case is there some > logic to make you choose? Use subsetting if the specialized property has a different name, and you want to be able to access the general property on instances of the subclass. Use redefinition if the specialized property has the same name as the general property (for example to narrow the type or multiplicity, but have the same name), or if you want to prevent access to the general property on instances of the specialized classifier (the names are different in the case). I can't think how the multiplicity would affect your choice in either case. > For example in DD... a view has a context property of 0..1, > do you make thi a derived union, so that more special views > can have properties with multipclity 1..1 that subset it? > or do you make it a regular property and let subclasses > redefine it with a multipclitiy 1..1? I assume you'd want to read the context property on instances of the specialized views, wouldn't you? This gives applications a uniform way to access the context object regardless of the specializations. If so, use subsetting. > Are you saying that for association classes, with > specializing the association class itself, there is no need > to also specialize the ends with subsetting / redefinition? There's certainly no need for subsetting, since class specialization is already subsetting the links (instances) of the association class, by the definition of generalization (every instance of the specialized class is an instance of the general class). I can't see the need for redefinition if the names are the same. Redefinition with different names would clash with association generalization. Conrad Subject: RE: Subsets vs. Redefines Date: Tue, 12 May 2009 08:32:27 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Subsets vs. Redefines Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gABpT76A= From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4CCbGWT007394 Pete -- Relative to: > > Providing a new name is useful when the new name is more relevant in the > new context - it doesn't mean the old name can't be valid as well, so it > ends up being a synonym. > > That's not true: the redefine prevents use of the original name against an > instance of the subclass. > (it took me a while to track down a reference to back this up. It's in the > following (within 7.3.7 Class): > > [1] The inherit operation is overridden to exclude redefined properties. > Class::inherit(inhs: Set(NamedElement)) : Set(NamedElement); > inherit = inhs->excluding(inh | > ownedMember- > >select(oclIsKindOf(RedefinableElement))->select(redefinedElement- > >includes(inh))) While it is correct that redefinition prevents inheritance of the original member, there is a subtlety. That is, if you have an object whose dynamic type is the subclass with the redefinition, but it is referenced through an element with the static type of the superclass with the original member (an "upcast" in C/Java terms), then you have to use the original name, not the redefined name -- but the original name now refers to the redefined element for the object!. This is why any redefinition is supposed to be "compatible" with what it is redefining. Now, the whole dynamic semantics of inheritance is not very well specified in UML (as opposed to the static semantics of naming, which is actually specified in a good deal of detail). And, for example, the dispatching of polymorphic operations is specifically a semantic variation point. However, the semantics of redefinition is clear in fUML -- largely because it is very restricted. Only operations are allowed to be redefined. And such redefinition is the basis for polymorphic operation calls (at least when using the default redefinition-based dispatch strategy). Redefining an operation is used to override that operation, in an OO polymorphic sense. As far as the dispatching semantics is concerned, the naming of the operation is entirely irrelevant. A call operation action points statically to an operation, and if the target object has an operation that redefines (directly or indirectly) the statically identified one, then the redefining operation is dynamically called -- what ever its name. Thus, using an arbitrary somewhat Java-like syntax, if you have a class: class A { p(x: Integer); } and a subclass class B specializes A { q(x: Integer) redefines A::p; } Then a call like "((A) new B()).p(2)" would actually call q -- that is, it is the same as "(new B()).q(2)" However, "(new B()).p(2)" is illegal, since "p" refers to an operation that is owned by A, not B (a call operation action requires that the static type of the target object actually own the called operation). So, in the context of the namespace of B, it is true that only the redefining operation "q" is available. However, in the context of the namespace of A (that is, when a B object is considered as an instance of A), then only the original operation "p". It is thus a "context sensitive" synonym! -- Ed Reply-To: From: "Conrad Bock" To: "'Rouquette, Nicolas F'" , Subject: RE: Subsets vs. Redefines Date: Tue, 12 May 2009 10:43:56 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnP7n8zzw4eKjqrQ7eirnIpMU38FACfW7DwABXNbRAAEw1y8A== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4CEi10m005742 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242744242.69873@q/FGmo0AfeHXKvzjJbGnpw X-Spam-Status: No Nicolas, > > The text around subsets/redefines could certainly be > > cleaned up. For > > example, there is a semantic variation point: > > > > The interaction of association specialization with association end > > redefinition and subsetting is not defined. > > This isn't true for subsetting, because generalization of > > association classes has the same semantics as subsetting the ends, > > by the definitions of these given in the spec. > This isn't true for both subsetting and redefinition of > association-owned member ends. > In the case of subsetting or redefinition of association > ends owned by the classifier, the meaning of association > specialization is unclear at best; the SVP is warranted in > this case. The defintion of class generalization is very clear (instances of the subtpye are instances of the subtype), and instances of associations are links, so the links of the association subclass are links of the association superclass. Links are reflected directly in property values. The effect of generalization on association classes is semantically identical to subsetting its end properties. Using the semantic variation is inconsistent with the rest of the spec (not mention breaking interoperability as all semantic variations do). Conrad Subject: Specialization Vs. Subsets (was RE: Subsets vs. Redefines) Date: Tue, 12 May 2009 13:51:24 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Specialization Vs. Subsets (was RE: Subsets vs. Redefines) Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gAB7k62A= From: "Cory Casanave" To: "Pete Rivett - Adaptive" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4CHplGL007702 Pete, (Note: In reference to: ----- A naïve but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation.------ I would like to explore this a bit more as I have assumed that UML generalization did imply a subset relation between the extents of the classes. Note: This is somewhat of a theoretical topic and not directly related to a UML issues, other than a clear understanding of what UML means. There is certainly a capability/feature interpretations of classes and generalization as well as, I believe, a set subset interpretation. Certainly the general understanding of generalization represents an "is a" relation between the extents of the classes: rectangle isA shape implies that the set of all rectangles is a subset of the set of all shapes. This is supported by the first sentence in the UML semantics of generalization: "Where a generalization relates a specific classifier to a general classifier, each instance of the specific classifier is also an instance of the general classifier." Of course a subclass could be an equivalent class - having the same extent. The concept of subset includes equivalent sets, so that would still be within the definition and would also apply to empty sets. So I don't understand the inconsistency of the null set. So, as far as I know there is no inconsistency between set semantics and classes with generalization. There are, however, issues. It does not always seem correct that the isA relations map to the hierarchy of features. For example, square isA rectangle but the set of operations you may want on a square may not be the a superset of the set of operations you may want on a rectangle. This "feature hierarchy" seems to sometimes conflict with or even be inverted from the set hierarchy. I have, somewhat, struggled with this disparity and it seems to pollute a lot of class hierarchies (including the UML meta model). -Cory -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, May 12, 2009 5:26 AM To: Cory Casanave; conrad.bock@nist.gov; uml2-rtf@omg.org Subject: RE: Subsets vs. Redefines > Providing a new name is useful when the new name is more relevant in the new context - it doesn't mean the old name can't be valid as well, so it ends up being a synonym. That's not true: the redefine prevents use of the original name against an instance of the subclass. (it took me a while to track down a reference to back this up. It's in the following (within 7.3.7 Class): [1] The inherit operation is overridden to exclude redefined properties. Class::inherit(inhs: Set(NamedElement)) : Set(NamedElement); inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))->select(redefinedElement->includes(inh))) The semantics of subsets change somewhat when it subsets a derived union - because then it contributes to the distributed definition of the union. Personally I don't much like this 'bottom up' definition but guess we've got to live with it. Another difference is that subsets can apply to another property of the same class - redefines can only apply to a property of the superclass. And there is the constraint [10] that " A Property cannot be subset by a Property with the same name" There are other detailed constraints that differ between subsets and redefines. Bottom line my advice would be: - if it's a derived union then you need to use subsets - if the property is in effect derived via a predicate (e.g. Package::/nestedPackage) then use subsets - if the original property is defined against the same class then use subsets - to retain access to the original property then use subsets: this is especially useful for allowing generic browsing of a composition hierarchy for example When then might it make sense to use {redefines}? I looked for some examples... a) I came across what seems to be a pointless redefinition: in Figure 8.11 Operation::ownedParameter:Parameter[*] {redefines BehavioralFeature:ownedParameter:Parameter[*]} but the redefinition differs not a jot from the original! b) we have Class::/superclass:Class[*] {redefines Classifier::/general:Classifier[*]}. This would IMHO be better as {subsets} - since it would be useful to have 'general' available for generic inheritance tree browsing c) Operation::raisedException:Type[*] is used to 'unify' 2 inherited features Basic::Operation::raisedException:Type[*] and BehavioralFeature::raisedException:Type[*]. However Kernel::Operation does not inherit from Basic and so the redefinition is pointless. d) PackageableElement::visibility:VisibilityKind[1] = true {redefines NamedElement::visibility:VisibilityKind[0..1]} (the latter has no default). This is a genuine use of {redefines} though there is a bug in that 'true' is not a valid literal for VisibilityKind. The tightening of multipicity could have been achieved by a constraints on PackageableElement to say that visibility is not empty, but the change in default value could not. e) CreateLinkAction::endData:LinkEndCreationData[2..*] {redefines LinkAction::endData:LinkEndData[2..*]}. f) DestroyLinkAction::endData:LinkEndDestructionData[2..*] {redefines LinkAction::endData:LinkEndData[2..*]}. ...there are approx 20 more uses of redefines. It might be useful to analyse them all as above. Pete PS Another email in this thread claimed that 'xor' had been dropped from UML2. That's is untrue. See 7.3.10 and Fig 7.34. It is, however, exceptionally badly specified (there is at least one issue for this - I raised it). BTW this is a far more useful discussion than the following text added to the spec - which I voted against at the time since I felt it made the text even less clear than it was (from 7.3.3 Semantics): ---> Subsetting is a relationship in the domain of extensional semantics. Specialization is, in contrast to subsetting, a relationship in the domain of intentional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naïve but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation.: <---- Pete -----Original Message----- From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 May 2009 16:23 To: conrad.bock@nist.gov; uml2-rtf@omg.org Subject: RE: Subsets vs. Redefines Conrad, I think both concepts (subsets & redefines), as well as renaming, are useful and valid. Redefines or subsets is useful in the situation where you need to further constrain the type of a property in a subclass. Example: Domestic invoice (a subtype of invoice) references domestic address (a subtype of address). In this case it would be a redefines. Providing a new name is useful when the new name is more relevant in the new context - it doesn't mean the old name can't be valid as well, so it ends up being a synonym. Subsets us useful when either of the above (or other constraints) only applies to some of the relations/values - redefines is useful when the new name or constraints are valid for some of the relations/values. Example: "Pepperoni pizza" has-topping "Pepperoni". (Subsets - other toppings are ok as well) In OWL we have subproperty, which seems to me to be well defined and the same as "subsets" - of course you could further constrains it such that it would be a redefines using a restriction. So they seem to have been able to work it out in OWL. I understand that this breaks some peoples conception of "substitutability", but subclasses can introduce constraints and any such constraints will "break" substitutability if it is interpreted very strictly. So it seems to me that the substitutability that is practical is one that allows a subtype to throw an exception (or whatever the technology equ is) if it is put into an invalid state - not one that assumes all states of a supertype are valid for all subtypes. (so, covariance, not contravariance). Example: Square is a rectangle, setting the sides to not be equal would be an exception (or require a change in type). I'm not proposing changing anything (for a change!), but just speaking up for useful features. -Cory -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Monday, May 11, 2009 5:40 PM To: uml2-rtf@omg.org Subject: RE: Subsets vs. Redefines Maged, > I saw several cases in the UML spec where redefinition > changed the name, like 'Class::superClass' redefines > 'Classifier::general', so that made me wonder when to use > redefinition vs. subsetting. That's completely eliminates substitutability, you can't even read the redefined property on instances on the subclass, like you can with subsetting (both break substitutability of writing). I'd avoid redefinition that changes the name. > I think redfinition of a property is allowed to happen "once" at > every classifier, where subsetting could be many. Would hope so, but haven't checked the constraints. > However, if you have a designing a 0..1 multiplicity property, > wihich you expect to be specialied. Do you use redefinition or > subsetting? aren't both equally aplicable if you expect one > specialization in every lower classifier? In that case is there some > logic to make you choose? Use subsetting if the specialized property has a different name, and you want to be able to access the general property on instances of the subclass. Use redefinition if the specialized property has the same name as the general property (for example to narrow the type or multiplicity, but have the same name), or if you want to prevent access to the general property on instances of the specialized classifier (the names are different in the case). I can't think how the multiplicity would affect your choice in either case. > For example in DD... a view has a context property of 0..1, > do you make thi a derived union, so that more special views > can have properties with multipclity 1..1 that subset it? > or do you make it a regular property and let subclasses > redefine it with a multipclitiy 1..1? I assume you'd want to read the context property on instances of the specialized views, wouldn't you? This gives applications a uniform way to access the context object regardless of the specializations. If so, use subsetting. > Are you saying that for association classes, with > specializing the association class itself, there is no need > to also specialize the ends with subsetting / redefinition? There's certainly no need for subsetting, since class specialization is already subsetting the links (instances) of the association class, by the definition of generalization (every instance of the specialized class is an instance of the general class). I can't see the need for redefinition if the names are the same. Redefinition with different names would clash with association generalization. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: Subsets vs. Redefines Date: Tue, 12 May 2009 14:04:15 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gACZqrlA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4CI4LUd002787 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242756261.40999@XzmbI3STK/VZFdybJtb6yw X-Spam-Status: No X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4CI3GeR011833 Pete, > BTW this is a far more useful discussion than the following text > added to the spec - which I voted against at the time since I felt > it made the text even less clear than it was (from 7.3.3 Semantics): > ---> Subsetting is a relationship in the domain of extensional > semantics. Specialization is, in contrast to subsetting, a > relationship in the domain of intentional semantics, which is to say > it characterized the criteria whereby membership in the collection > is defined, not by the membership. One classifier may specialize > another by adding or redefining features; a set cannot specialize > another set. This is true, but might not be that useful to point out, see below. > A naïve but popular and useful view has it that as the classifier > becomes more specialized, the extent of the collection(s) of > classified objects narrows. In the case of associations, subsetting > ends, according to this view, correlates positively with > specializing the association. This view falls down because it > ignores the case of classifiers which, for whatever reason, denote > the empty set. Adding new criteria for membership does not narrow > the extent if the classifier already has a null denotation.: The above passage assume proper subsetting (the subset has smaller cardinality that the superset), which isn't required anywhere that I'm aware of. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: Subsets vs. Redefines Date: Tue, 12 May 2009 14:10:58 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gACbKLpA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4CIB3oX003909 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242756667.56881@Rz3rSsHEzUuWLaEgBFnV/w X-Spam-Status: No PS. Pete, > The semantics of subsets change somewhat when it subsets a derived > union - because then it contributes to the distributed definition of > the union. Personally I don't much like this 'bottom up' definition > but guess we've got to live with it. The semantics of subsets doesn't change regardless of derived union (the values of the special property are still values of the general one). Derived union is like "isAbstract" for classes, it means the general property cannot have a value the specialized ones don't. > I looked for some examples... > e) CreateLinkAction::endData:LinkEndCreationData[2..*] {redefines LinkAction::endData:LinkEndData[2..*]}. > f) DestroyLinkAction::endData:LinkEndDestructionData[2..*] {redefines LinkAction::endData:LinkEndData[2..*]}. These restrict the type of the property. > ...there are approx 20 more uses of redefines. It might be useful to > analyse them all as above. It would be interested to see if there is any reason to use redefines when the specialized name is different from the general one. > PS Another email in this thread claimed that 'xor' had been dropped > from UML2. That's is untrue. See 7.3.10 and Fig 7.34. It is, however, > exceptionally badly specified (there is at least one issue for this - > I raised it). Thanks for pointing this out. It's very useful in the popular CCTS-style of specialization, where all properties are optional, but some are exclusive of each other. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: Specialization Vs. Subsets (was RE: Subsets vs. Redefines) Date: Tue, 12 May 2009 14:28:15 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gAB7k62AACBIWIA== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4CISKA3006076 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242757702.74478@JOVHXsMBd78moyIs/SIYPg X-Spam-Status: No Cory, > I would like to explore this a bit more as I have assumed > that UML generalization did imply a subset relation between > the extents of the classes. It does, as you pointed out in the semantics of generalization. Every instances of the subclassifier must be an instance of the superclassifier. This is the definition of subsets (not proper subsets, as you mention, the extents can be the same). > There are, however, issues. It does not always seem > correct that the isA relations map to the hierarchy of > features. For example, square isA rectangle but the set of > operations you may want on a square may not be the a > superset of the set of operations you may want on a > rectangle. This "feature hierarchy" seems to sometimes > conflict with or even be inverted from the set hierarchy. > I have, somewhat, struggled with this disparity and it > seems to pollute a lot of class hierarchies (including the > UML meta model). What would be an example of operations on a rectangle yoy don't want on a square? Rectangles might have operations for modifying each side, but in squares using either of these would modify the other also. BTW, models of OO implementations probably want to avoid specializing by either narrowing or widening inherited features, like the type or multiplicity of properties. These models need both read and write substitutability, where read substitutability allows only narrowing and write substitutability allows only widening, meaning you can't do either. Conrad Subject: RE: Specialization Vs. Subsets (was RE: Subsets vs. Redefines) Date: Tue, 12 May 2009 15:26:12 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Specialization Vs. Subsets (was RE: Subsets vs. Redefines) Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gAB7k62AACBIWIAABnvwA From: "Cory Casanave" To: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4CJOxpO008378 Conrad, RE: What would be an example of operations on a rectangle you don't want on a square? Rectangles might have operations for modifying each side, but in squares using either of these would modify the other also. [cbc] Lets expand the example to square --isA--> rectangle --isA--> polygon. The "API" required to manage the shape of the polygon is quite complex and many of the operations would be invalid for a square (changing an angle) or would have to have arbitrary side effects (setting one side sets all). Do you want all of the complexity of managing an arbitrary number of sides of arbitrary length with arbitrary angles as part of the API for a square? Do you want most of these operations throwing exceptions because they are not valid for a square? So what developers typically do is factor their hierarchies by capability (features), not subsets. Only in some cases do these match. While I agree the "proper" way would be to follow the set relations, we would then probably want a way to "hide" parts of the signature and make variables into constants (E.G. number of sides). This would make the hierarchy much better defined - but OO doesn't encourage the practice. So, what we end up with is oddly constructed hierarchies, sometimes inverted from sets. Re: BTW, models of OO implementations probably want to avoid specializing by either narrowing or widening inherited features, like the type or multiplicity of properties. These models need both read and write substitutability, where read substitutability allows only narrowing and write substitutability allows only widening, meaning you can't do either. [cbc] 100% write substitutability doesn't seem practical. For example, in the polygon above, if you were to set an angle to be other than 90 degrees, it would no longer be a rectangle or a square. Narrowing seems to be a proper way to express the real constraints of a subtype - even if this is annoying for substitutability. Substitutability of signature is practical, but expecting that the set of allowable values for all operations is the same would seem to conflict with the idea of the subtype having some discriminator. Of course if the type could change this would not be an issue. I think programmers live with the partial substitutability they have and that is sufficient, but in reality subtypes raise exceptions when the objects have been put into a state that is invalid for the subtype. In all the examples I have come up with covariance properly represents the type hierarchy while contravariance represents a substitutability/capability hierarchy. Covariance with exceptions seems like the only solution that represents reality in OO. -Cory Reply-To: From: "Conrad Bock" To: Subject: RE: Specialization Vs. Subsets (was RE: Subsets vs. Redefines) Date: Tue, 12 May 2009 15:42:59 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnSfabs7LyBruv+QwuxgY0vtMXytQAANVtQAACZi2AAAvEM0AABSy7gAB7k62AACBIWIAABnvwAAADt6eA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n4CJh4fS016572 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242762185.51525@igjU0Rz+BSER+BXJsKhGTw X-Spam-Status: No Cory, > RE: What would be an example of operations on a rectangle > you don't want > on a square? Rectangles might have operations for > modifying each side, > but in squares using either of these would modify the other also. > [cbc] Lets expand the example to square --isA--> rectangle --isA--> > polygon. The "API" required to manage the shape of the polygon is > quite complex and many of the operations would be invalid for a > square (changing an angle) or would have to have arbitrary side > effects (setting one side sets all). Do you want all of the > complexity of managing an arbitrary number of sides of arbitrary > length with arbitrary angles as part of the API for a square? Do > you want most of these operations throwing exceptions because they > are not valid for a square? The more general operations are overriden with constraint maintenance, not exceptions. For example, in most paint tools you can grab one of the vertices of a shape and move it, with the intension of changing the shape. This uses one of the polygon operations. If the shape happens to be a rectangle, the tool will also move the adjacent vertices to maintain the rectangle shape. If it happens to be a square, it will only move the point along the diagonal, no matter where the mouse moves. > So what developers typically do is factor their hierarchies by > capability (features), not subsets. Would make for some very unfreindly tooling, see above example. It's must easier on the user if the general functionality is available on the specialized classes with the tool doing the right thing according the the specialized constraints. This is more work to implement, of course. > Re: BTW, models of OO implementations probably want to avoid > specializing by either narrowing or widening inherited features, > like the type or multiplicity of properties. These models need both > read and write substitutability, where read substitutability allows > only narrowing and write substitutability allows only widening, > meaning you can't do either. > [cbc] 100% write substitutability doesn't seem practical. For > example, in the polygon above, if you were to set an angle to be > other than 90 degrees, it would no longer be a rectangle or a > square. Narrowing seems to be a proper way to express the real > constraints of a subtype - even if this is annoying for > substitutability. The above example applies to write substitutability, and even then it isn't necessary to throw exceptions, see previous point. Breaking read substitutability seems really not so nice on the developer, see next point. > while contravariance represents a substitutability/capability > hierarchy. Contravariance is not read subtitutable. Reading a general property typed by integer and getting a real because of contravariant specialization would be a problem in most cases. > Covariance with exceptions seems like the only solution that > represents reality in OO. See above about contravariance and exceptions. Conrad