Issue 14066: Properties need not be owned (uml2-rtf) Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org) Nature: Uncategorized Issue Severity: Summary: Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional. As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything. So can you have a “free-floating” property? Where can you put it? Since Properties are not packagable, they can’t be owned by Packages. There are (at least) two ways of solving this (I prefer the first) 1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties. 2) Fix the hole and make properties required to be owned by something. A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable. In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams Again there are two ways of solving this (I prefer the first) 1) Make connectors packageable. 2) Fix the hole and make connectors required to be owned by something. A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes. Resolution: Revised Text: Actions taken: July 9, 2009: received issue Discussion: End of Annotations:===== te: Thu, 09 Jul 2009 14:03:30 -0400 From: "Chonoles, Michael J" Subject: Properties need not be owned. To: Issues@omg.org, uml2-rtf@omg.org Thread-Topic: Properties need not be owned. Thread-Index: AcoAv4/D2uo0tAoZQJeybvwCIIioBA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 09 Jul 2009 18:05:26.0374 (UTC) FILETIME=[D6120860:01CA00BF] Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional. As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything. So can you have a .free-floating. property? Where can you put it? Since Properties are not packagable, they can.t be owned by Packages. There are (at least) two ways of solving this (I prefer the first) 1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties. 2) Fix the hole and make properties required to be owned by something. A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable. In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams Again there are two ways of solving this (I prefer the first) 1) Make connectors packageable. 2) Fix the hole and make connectors required to be owned by something. A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes. Michael Chonoles LMCO Subject: RE: Properties need not be owned. Date: Thu, 9 Jul 2009 13:07:53 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Properties need not be owned. Thread-Index: AcoAv4/D2uo0tAoZQJeybvwCIIioBAAEK0Mw From: "Pete Rivett" To: "Chonoles, Michael J" , I don.t see what the .hole. is that needs to be solved. As you imply, Properties cannot practically be free-standing of a Classifier. However someone could extend the UML metamodel or create a profile to make this possible. And I would not want the UML Spec to suddenly change to prevent this. As per recent thread, to make them packageable in UML would also require a means of reusing them in classifiers, which is I think too much for an RTF (though it is something we.re addressing the SMOF submission) Pete From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 09 July 2009 11:04 To: Issues@omg.org; uml2-rtf@omg.org Subject: Properties need not be owned. Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional. As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything. So can you have a .free-floating. property? Where can you put it? Since Properties are not packagable, they can.t be owned by Packages. There are (at least) two ways of solving this (I prefer the first) 1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties. 2) Fix the hole and make properties required to be owned by something. A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable. In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams Again there are two ways of solving this (I prefer the first) 1) Make connectors packageable. 2) Fix the hole and make connectors required to be owned by something. A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes. Michael Chonoles LMCO From: "Rouquette, Nicolas F" To: "Chonoles, Michael J" , "Issues@omg.org" , "uml2-rtf@omg.org" Date: Thu, 9 Jul 2009 12:50:42 -0700 Subject: Re: Properties need not be owned. Thread-Topic: Properties need not be owned. Thread-Index: AcoAv4/D2uo0tAoZQJeybvwCIIioBAADvq1/ 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 Michael, On 7/9/09 11:03 AM, "Chonoles, Michael J" wrote: Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional. As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything. So can you have a .free-floating. property? Where can you put it? Since Properties are not packagable, they can.t be owned by Packages. There are (at least) two ways of solving this (I prefer the first) 1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties. NFR: So you mean: Property would inherit from StructuralFeature and PackageableElement. However, this kind of inheritance can be deceiving because a Property-as-StructuralFeature makes sense when the property is defined in the context of a classifier by virtue of the RedefinableElement nature of a StructuralFeature. In contrast, a Property-as-PackageableElement makes sense when the property is defined in the context of a package by definition of PackageableElement. These facets of a Property are mutually excelusive *except* for the very convoluted albeit possible case of a conjunctive specialization of Package + Classifier, e.g., a ClassifierPackage which is logically possible and could have a non-vaccuous extent in some extension of the UML kernel which means pretty much an extension of every metamodel we have at the OMG. This is not a trivial kind of change because of the mutually-exclusive nature of this specialization which is very different than a simpler fully-conjunctive specialization such as AssociationClass = Association + Class. 2) Fix the hole and make properties required to be owned by something. NFR: There is no hole to fix for a property is always owned by something and that something ins.t necessarily a classifier; it can be another property. See the notion of property qualifier in AssociationClass. A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable. In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams NFR: Instead of trying to make properties and connectors packageable elements, one could consider a simpler fully-conjunctive specialization of Classifier + Package = ClassifierPackage. Again there are two ways of solving this (I prefer the first) 1) Make connectors packageable. 2) Fix the hole and make connectors required to be owned by something. A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes. NFR: Making Feature = RedefinableElement + PackageableElement would be introducting a subtle case of disjunctive specialization in the sense that there is no instance of a feature that is both redefinable and packageable except for the case where the owner is simultaneously a classifier and a package. So I think you.d be better off considering whether you really need a fully-conjunctive concept of ClassifierPackage = Classifier + Package instead of a mostly disjunctive concept of RedefinableElement + PackageableElement. - Nicolas. Michael Chonoles LMCO Subject: RE: Properties need not be owned. Date: Thu, 9 Jul 2009 16:17:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Properties need not be owned. thread-index: AcoAv4/D2uo0tAoZQJeybvwCIIioBAADvq1/AADHSMA= From: "Ed Seidewitz" To: "Rouquette, Nicolas F" , "Chonoles, Michael J" , , Nicolas -- . NFR: There is no hole to fix for a property is always owned by something and that something ins.t necessarily a classifier; it can be another property. See the notion of property qualifier in AssociationClass. [EVS] I.m glad you reminded us of this . it explains why featuredClassifier needs to have multiplicity lower bound of 0! . NFR: Making Feature = RedefinableElement + PackageableElement would be introducting a subtle case of disjunctive specialization in the sense that there is no instance of a feature that is both redefinable and packageable except for the case where the owner is simultaneously a classifier and a package. So I think you.d be better off considering whether you really need a fully-conjunctive concept of ClassifierPackage = Classifier + Package instead of a mostly disjunctive concept of RedefinableElement + PackageableElement. [EVS] I had earlier made the suggestion of separating Property from StructuralFeature, and then allowing a property to be associated with a StructuralFeature in a somewhat similar way that a Behavior can be associated with a BehavioralFeature as a method. A StructuralFeature would then remain a RedefiniableElement but not a PackageableElement, as it is now, while a Property would be a PackageableElement, but not longer a RedefinableElement. I think this would be a big change for an RTF, though. -- Ed Date: Fri, 10 Jul 2009 09:37:41 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.6 (X11/20070728) To: "Chonoles, Michael J" CC: Issues@omg.org, uml2-rtf@omg.org Subject: Re: Properties need not be owned. X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4A56FDDB.01B7:SCFSTAT5015188,ss=1,fgs=0 The assertion that properties need not be owned isn't true because of constraint 7.3.14 [2]: self.mustBeOwned() implies owner->notEmpty() and additional operation 7.3.14 [2]: Element::mustBeOwned() : Boolean; mustBeOwned = true The only redefinition of mustBeOwned() is in 7.3.37 [1]: Package::mustBeOwned() : Boolean mustBeOwned = false So the only objects that cannot have owners are packages and thus the answer to your "free-floating" property question is no as (2) is already implemented. Cheers, Dave Chonoles, Michael J wrote: Based on UML 2.2 Diagram 9.2, it appears that /Property/ is optionally part of /StructuredClassifer/. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional. As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything. So can you have a .free-floating. property? Where can you put it? Since Properties are not packagable, they can.t be owned by Packages. There are (at least) two ways of solving this (I prefer the first) 1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties. 2) Fix the hole and make properties required to be owned by something. A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable. In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams Again there are two ways of solving this (I prefer the first) 1) Make connectors packageable. 2) Fix the hole and make connectors required to be owned by something. A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes. Michael Chonoles LMCO * * -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.