Issue 6216: UML 2 Super/pg.75/kinds of changeability (uml2-rtf) Source: International Business Machines (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: pg. 75: StructuralFeature::isReadOnly Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values: Changeable (unrestricted) readOnly (no changes after initialization) [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.] The following additional choices were available in UML1: CreateOnly (add a set any time after initialization but no further changes) addOnly (may add members to the set but not change or remove any) Both of these occur in practice often enough. Resolution: see above Revised Text: Infrastructure Spec: Remove section 9.2.1 ChangeabilityKind. It s not part of the UML2 metamodel and is not referenced anywhere else in the InfrastructureLibrary or Superstructure specification. Actions taken: September 7, 2003: received issue August 23, 2006: closed issue Discussion: The only subclass of abstract metaclass StructuralFeature in UML2 is Property which already has ownedAttribute isReadOnly: Boolean. This property comes from package Basic and is part of the alignment with MOF2. MOF2 also has a number of rules about initialization of read-only properties that may make the distinctions between changeable and readOnly unnecessary. It is not clear what the value for createOnly would be over having a default for a read-only property. And addOnly semantics may be better handled by the containing class rather than the feature itself. End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/pg.75/kinds of changeability X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:49:16 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:49:19, Serialize complete at 09/07/2003 09:49:19 pg. 75: StructuralFeature::isReadOnly Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values: Changeable (unrestricted) readOnly (no changes after initialization) [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.] The following additional choices were available in UML1: CreateOnly (add a set any time after initialization but no further changes) addOnly (may add members to the set but not change or remove any) Both of these occur in practice often enough. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 OMG Issue No: 6216 Title: UML 2 Super/pg.75/kinds of changeability Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 75: StructuralFeature::isReadOnly Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values: Changeable (unrestricted) readOnly (no changes after initialization) [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.] The following additional choices were available in UML1: CreateOnly (add a set any time after initialization but no further changes) addOnly (may add members to the set but not change or remove any) Both of these occur in practice often enough. Discussion: If nothing else, it seems that this should be supported for backward compatibility. Suggest: · Introduce a new metaclass: ChangeabilityKind with the following values: {unrestricted, readOnly, createOnly, addOnly} · Replace StructuralFeature::isReadOnly by changeability : ChangeabilityKind From: "Thomas Weigert" To: "Branislav Selic" , Cc: , Subject: RE: INFRASTRUCTURE: some resolution proposals Date: Sat, 8 May 2004 13:31:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Feedback on the two issues: 2582: Translated into UML2 terminology, this issue seems to suggest that Enumerations are DataTypes (which they are now) made up of EnumerationLiterals (which they are now, with some caveats discussed below). It also suggests that EnumerationLiteral.enumeration is specialized from InstanceSpecification.classifier. The latter is not the case but is a good suggestion. You are raising the additional question of whether an enumeration literal should actually be a value specification. I think this question would have to be answered in a much broader sense. We currently have three things: Classifiers (or their subtypes), InstanceSpecifications (or their subtypes), and ValueSpecification (or their subtypes). ValueSpecifications denote values either by describing the computation that yields them (as in Expression, OpaqueExpression) or by referencing a description of the value (as in LiteralExpression, InstanceSpecification). You may wonder why we need this level of indirection when we want to speak about the instances. The reason for having to go through InstanceValue has to do with ownership. There are many model elements that own a description of some value (e.g., default values, initial values), and they may point to instances. But they cannot own the instances directly, as there may be many other model elements referring in the same manner to these instances. E.g., the Enumeration owns its EnumerationLiterals; thus some Attribute that has one of the literals as its default value cannot own it as well. My recommendation would be to adopt the suggestion to subtype the association between Enumeration and EnumerationLiteral but otherwise make no change. 6216: We had originally decided to retire these other options. Remember, the UML2 was supposed to get rid of less used constructs, rather than being completely backwards compatible. However, for flexibility of profiles it might be a good idea to make the attribute an enumeration, so that profiles can extend the range of values. I would not add these new values, but have only "unrestricted", and "readOnly", but I don't feel strongly about it (this would keep with the spirit of retiring some aspects of the language). However, this points again to a general issue. There may be other Boolean meta attributes which should be expressed as Enumerations instead to allow extensions in profiles. I suggest that we examine the specification for other such attributes. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, May 07, 2004 3:17 PM To: mu2i-ftf@omg.org Cc: uml2-superstructure-ftf@omg.org; ocl2-ftf@omg.org Subject: INFRASTRUCTURE: some resolution proposals I've copied the OCL and Super people on this e-mail since this may be relevant to them, but the following resolutions are intended for the INFRASTRUCTURE FTF and not the Superstructure. I have four resolutions, two of which look like "no-brainers" to me (3391 and 4448). However, on the remaining ones, there may be some debate necessary: 2582: the question here is whether EnumerationLiterals should be InstanceSpecifications (which is what they are now) or ValueSpecifications (LiteralSpecifications)? 6216: is a rather basic change to the definition of changeability that restores it to what it was in 1.x at least (I tend to agree with the issue submitter on how to deal with this, but others may think differently) So, I am hoping to see opinions expressed on the last two issues at least. Cheers, Bran Disposition: Unresolved To: Branislav Selic Cc: mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: INFRASTRUCTURE: some resolution proposals X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Fri, 14 May 2004 19:31:55 -0600 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF303 | April 20, 2004) at 05/14/2004 19:31:56 Bran, Is 6216 for the Super spec or for the Infra? The resolution does not indicate the section and the page # in the issue is not correct. The proposed resolution should not apply to infrastructure's Constructs package as that would change CMOF, it should be specified as an addition outside Constructs. Perhaps this issue should be Super and not Infra? Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 Branislav Selic 05/07/2004 01:16 PM To: mu2i-ftf@omg.org cc: uml2-superstructure-ftf@omg.org, ocl2-ftf@omg.org Subject: INFRASTRUCTURE: some resolution proposals I've copied the OCL and Super people on this e-mail since this may be relevant to them, but the following resolutions are intended for the INFRASTRUCTURE FTF and not the Superstructure. I have four resolutions, two of which look like "no-brainers" to me (3391 and 4448). However, on the remaining ones, there may be some debate necessary: 2582: the question here is whether EnumerationLiterals should be InstanceSpecifications (which is what they are now) or ValueSpecifications (LiteralSpecifications)? 6216: is a rather basic change to the definition of changeability that restores it to what it was in 1.x at least (I tend to agree with the issue submitter on how to deal with this, but others may think differently) So, I am hoping to see opinions expressed on the last two issues at least. Cheers, Bran OMG Issue No: 6216 Title: UML 2 Super/pg.75/kinds of changeability Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 75: StructuralFeature::isReadOnly Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values: Changeable (unrestricted) readOnly (no changes after initialization) [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.] The following additional choices were available in UML1: CreateOnly (add a set any time after initialization but no further changes) addOnly (may add members to the set but not change or remove any) Both of these occur in practice often enough. Discussion: If nothing else, it seems that this should be supported for backward compatibility. Suggest: · Introduce a new metaclass: ChangeabilityKind with the following values: {unrestricted, readOnly, createOnly, addOnly} · Replace StructuralFeature::isReadOnly by changeability : ChangeabilityKind Disposition: Unresolved To: uml2-rtf@omg.org Subject: Issue 6216 StructuralFeature::isReadOnly X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 20 Jul 2005 17:32:24 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M6_06302005 Beta 4|June 30, 2005) at 07/20/2005 15:32:26, Serialize complete at 07/20/2005 15:32:26 Issue 6216 proposes adding StrucutralFeature::changeability {changeable, readOnly, createOnly, addOnly} the only subclass of abstract metaclass StructuralFeature that appears in UML2 is Property which also has ownedAttribute isReadOnly: Boolean. This property comes from package Basic and is part of the alignment with MOF2. MOF2 also has a number of rules about initialization of read-only properties that may make the distinctions between changeable and readOnly unnecessary. Its not clear what the value for createOnly would be over having a default for a read-only property. And addOnly semantics may be better handled by the containing class rather than the feature itself. Should we close this issue with no change? I don't have a good understanding of all the possible use cases. Note that Property::isReadOnly would have to become derived in Superstructure in order to be consistent with the changeability inherited property. e-mail: bselic@ca.ibm.com