Issue 2582: class EnumerationLiteral issue (uml2-superstructure-ftf) Source: (, ) Nature: Clarification Severity: Significant Summary: Summary: I think that the class EnumerationLiteral should be an heir of DataValue (this inheritance relationship is currently missing). Once this is fixed, the association between EnumerationLiteral and Enumeration should be seen as a refinement of the association between DataValue and DataType (itself implicitly inherited from the association between Instance and classifier), with a supplementary OCL constraint in the case of EnumerationLiteral, namely that self.classifier.oclIsKindOf(Enumeration) (to ensure covariance, as is done for DataValue wrt DataType). BTW, shouldn"t there be a symetric OCL constraint in DataType specifying that its Instances are all DataValues, and similarly in Enumeration specifying that its instances are all EnumerationLiterals ? Resolution: Revised Text: Actions taken: April 12, 1999: received issue March 9, 2005: closed issue Discussion: In UML 2.0 EnumerationLiteral has been made a subclass of InstanceSpecification. Hence, some of the arguments above do not apply. Of course, it could be argued that EnumerationLiteral should be made a kind of ValueSpecification (like other literals) but that would probably require more overhead, since, in most realizations, the definition of an EnumerationLiteral typically occupies more resources than a pointer to that definition (i.e., an InstanceValue). Unfortunately, there does not seem to be a specialization of ValueSpecification that distinguishes a “pure” value specification from an object instance. Therefore, it is not possible to write a constraint to the effect that only pure values can be stored in InstanceSpecifications that correspond to DataTypes. End of Annotations:===== Date: Mon, 12 Apr 1999 13:36:21 -0400 (EDT) From: aleguenn@irisa.fr To: juergen@omg.org, web-incoming@omg.org Subject: Issue Report Name: Alain Le Guennec Company: IRISA mailFrom: aleguenn@irisa.fr Notification: Yes Specification: UML1.3 betaR1 Section: UML Semantics 2.7.2 Formal #: Version: Revision_Date: Page: 2-77 Nature: Clarification Severity: Significant full_desc: I think that the class EnumerationLiteral should be an heir of DataValue (this inheritance relationship is currently missing). Once this is fixed, the association between EnumerationLiteral and Enumeration should be seen as a refinement of the association between DataValue and DataType (itself implicitly inherited from the association between Instance and classifier), with a supplementary OCL constraint in the case of EnumerationLiteral, namely that self.classifier.oclIsKindOf(Enumeration) (to ensure covariance, as is done for DataValue wrt DataType). BTW, shouldn't there be a symetric OCL constraint in DataType specifying that its Instances are all DataValues, and similarly in Enumeration specifying that its instances are all EnumerationLiterals ? submit: Submit Issue Report Resolutions for debate: OMG Issue No: 2582 Title: class EnumerationLiteral issue Source: Summary: I think that the class EnumerationLiteral should be an heir of DataValue (this inheritance relationship is currently missing). Once this is fixed, the association between EnumerationLiteral and Enumeration should be seen as a refinement of the association between DataValue and DataType (itself implicitly inherited from the association between Instance and classifier), with a supplementary OCL constraint in the case of EnumerationLiteral, namely that self.classifier.oclIsKindOf(Enumeration) (to ensure covariance, as is done for DataValue wrt DataType). BTW, shouldn"t there be a symetric OCL constraint in DataType specifying that its Instances are all DataValues, and similarly in Enumeration specifying that its instances are all EnumerationLiterals ? Discussion: In UML 2.0 EnumerationLiteral has been made a subclass of InstanceSpecification (rather than ValueSpecification). Therefore, the rest of the issue is no longer applicable. Disposition: Unresolved 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 Resolutions for debate: OMG Issue No: 2582 Title: class EnumerationLiteral issue Source: Summary: I think that the class EnumerationLiteral should be an heir of DataValue (this inheritance relationship is currently missing). Once this is fixed, the association between EnumerationLiteral and Enumeration should be seen as a refinement of the association between DataValue and DataType (itself implicitly inherited from the association between Instance and classifier), with a supplementary OCL constraint in the case of EnumerationLiteral, namely that self.classifier.oclIsKindOf(Enumeration) (to ensure covariance, as is done for DataValue wrt DataType). BTW, shouldn"t there be a symetric OCL constraint in DataType specifying that its Instances are all DataValues, and similarly in Enumeration specifying that its instances are all EnumerationLiterals ? Discussion: In UML 2.0 EnumerationLiteral has been made a subclass of InstanceSpecification (rather than ValueSpecification). Therefore, the rest of the issue is no longer applicable. Disposition: Unresolved Subject: RE: INFRASTRUCTURE: some resolution proposals - 2582 EnumerationLiteral Date: Tue, 8 Jun 2004 07:16:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFRASTRUCTURE: some resolution proposals - 2582 EnumerationLiteral Thread-Index: AcQ0cWCpayCIO8suT7yeGNSx2RORpwY0uslA From: "Pete Rivett" To: "Branislav Selic" , "Thomas Weigert" Cc: , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i58BBaun017791 Bran, I will include the first 2 resolutions in the draft ballot I am constructing. What about the other 2? I see there has been some discussion with Thomas - was there a consensus? I think they need more discussion from what I've seen - particularly as I have my own thoughts about 2582. On 2582 FWIW I agree with the sentiment of the issue and disagree with the resolution to close no change. In order to address Thomas' point about ownership of ValueSpecifications, and to avoid confusion between Literals (which is the use of a value) and actual values, it seems to me that what we need is the following: - rename the current class EnumerationLiteral to EnumerationValue - add a new class called LiteralEnumeration in Literals package. This inherits from LiteralSpecification and will have a single-valued attribute called 'value' to EnumerationValue This also makes the scheme for Enumerations reasonably consistent with Boolean which is what people would intuitively expect. I disagree with making EnumerationLiteral/Value inherit from InstanceSpecification which is described as "An instance specification specifies existence of an entity in a modeled system". On 6216 I have no strong opinion - but if we make it an enumeration we should consider retaining a derived attribute isReadOnly. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, May 07, 2004 9: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 OMG Issue No: 2582 Title: class EnumerationLiteral issue Source: Summary: I think that the class EnumerationLiteral should be an heir of DataValue (this inheritance relationship is currently missing). Once this is fixed, the association between EnumerationLiteral and Enumeration should be seen as a refinement of the association between DataValue and DataType (itself implicitly inherited from the association between Instance and classifier), with a supplementary OCL constraint in the case of EnumerationLiteral, namely that self.classifier.oclIsKindOf(Enumeration) (to ensure covariance, as is done for DataValue wrt DataType). BTW, shouldn"t there be a symetric OCL constraint in DataType specifying that its Instances are all DataValues, and similarly in Enumeration specifying that its instances are all EnumerationLiterals ? Discussion: In UML 2.0 EnumerationLiteral has been made a subclass of InstanceSpecification. Hence, some of the arguments above do not apply. Of course, it could be argued that EnumerationLiteral should be made a kind of ValueSpecification (like other literals) but that would probably require more overhead, since, in most realizations, the definition of an EnumerationLiteral typically occupies more resources than a pointer to that definition (i.e., an InstanceValue). Unfortunately, there does not seem to be a specialization of ValueSpecification that distinguishes a .pure. value specification from an object instance. Therefore, it is not possible to write a constraint to the effect that only pure values can be stored in InstanceSpecifications that correspond to DataTypes. It is useful to add the following constraint to DataType: [1] The types of all attributes of a DataType must themselves be kinds of DataType ownedAttribute->forAll(a|a.type->notNil() implies a.type->oclIsKindOf(DataType)) This needs to be inserted in both the Infrastructure and the Superstructure specs. Specifically: In the Infrastructure Spec (ptc/03-09-15) On page 134 of the Infrastructure document, for the DataType class, in the Constraints section, replace the sentence: No additional constraints. with the constraint defined above. In the Superstructure Spec (ptc/03-08-02) On page 95 of the Superstructure document, for the DataType class, in the Constraints section, replace the sentence: No additional constraints. with the constraint defined above. Disposition: Resolved Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Wed, 14 Jul 2004 16:34:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Some comments on your ballot 19 resolutions. Conrad - Issue 2582 (class EnumerationLiteral issue) A data types could be a struct that points to objects, so I don't think the constraint is correct. In any case, it isn't what the issue is about. - Issue 3391 (Multiple languages for uninterpreted strings) The issue is asking for the various body/language string attributes to support multiple languages, for example by both being multi-valued and ordered. The resolution addresses a different issue. - Issue 4448 (Does visibility apply to creating an destroying links?) Agreed, visibility is a design-time concept, but so are actions, ie, they exist in the model. The purpose of visibility is to constrain models not to specify actions that violate it. For example, if an attribute is private, there shouldn't be a ReadStructuralFeature action in a method of another object that access the private attribute. Since links can affect objects in UML 2, the issue asks if visibility applies to manipulating them To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: More resolutions for Ballot 19 from Bran X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 14 Jul 2004 22:29:55 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/14/2004 22:29:59, Serialize complete at 07/14/2004 22:29:59 Thanks, Conrad for reviewing these. Some responses and some questions embedded below: > - Issue 2582 (class EnumerationLiteral issue) > > A data types could be a struct that points to objects, so I don't > think the constraint is correct. In any case, it isn't what the > issue is about. A pointer to an object (Instancevalue) is still a kind of DataType, so the constraint still looks valid to me. I agree that the issue was not about that directly, but I thought it useful to add that constraint, because it is implicit in the issue. Alternatively, I can take the constraint out and close the issue "No change". What do you think? > - Issue 3391 (Multiple languages for uninterpreted strings) > > The issue is asking for the various body/language string > attributes to support multiple languages, for example by both > being multi-valued and ordered. The resolution addresses a > different issue. That's not how I read it, but since you raised the issue, I am sure you know what you meant. What resolution do you propose? > - Issue 4448 (Does visibility apply to creating an destroying links?) > > Agreed, visibility is a design-time concept, but so are actions, > ie, they exist in the model. The purpose of visibility is to > constrain models not to specify actions that violate it. For > example, if an attribute is private, there shouldn't be a > ReadStructuralFeature action in a method of another object that > access the private attribute. Since links can affect objects in > UML 2, the issue asks if visibility applies to manipulating them > also. And, the answer is that it does not -- perhaps I should make that clearer. You seem to be implying some kind of capability mechanism that keeps visibility information around at run time. I think that this is assuming too much. Thanks again....Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 15:44:26 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Followup discussion below, Conrad > > - Issue 2582 (class EnumerationLiteral issue) > > A data types could be a struct that points to objects, so I don't > > think the constraint is correct. In any case, it isn't what > > the issue is about. > A pointer to an object (Instancevalue) is still a kind of DataType, > so the constraint still looks valid to me. OK, that makes sense. > What do you think? > > > - Issue 3391 (Multiple languages for uninterpreted strings) > > > > The issue is asking for the various body/language string > > attributes to support multiple languages, for example by both > > being multi-valued and ordered. The resolution addresses a > > different issue. > > That's not how I read it, but since you raised the issue, I am > sure you know what you meant. What resolution do you propose? I think the various places that have body/language attributes should be: body : String [1..*] {ordered} language : String [0..*] {ordered} So multiple strings can be specified in multiple languages. The body and language strings would be matched by order. > > - Issue 4448 (Does visibility apply to creating an destroying links?) > > > > Agreed, visibility is a design-time concept, but so are actions, > > ie, they exist in the model. The purpose of visibility is to > > constrain models not to specify actions that violate it. For > > example, if an attribute is private, there shouldn't be a > > ReadStructuralFeature action in a method of another object that > > access the private attribute. Since links can affect objects in > > UML 2, the issue asks if visibility applies to manipulating them > > also. > And, the answer is that it does not -- perhaps I should make > that clearer. You seem to be implying some kind of capability > mechanism that keeps visibility information around at run time. > I think that this is assuming too much. Visibility only applies to design time, as you said, we're in agreeement on that. I'm saying design time is when actions are created, ie, when the metaclass CreateLinkAction is instantiated, etc. Visibility applies to where those instances of CreateLinkAction, etc, can be put. For example, an instance of ReadStructuralFeatureAction for a private attribute cannot be put in an activity used as a method for a class other than the one on which the attribute is declared. Visibility is a well-formedness rule on user-level models. I personally think if ReadStructuralFeatureAction must obey visibility, as it does curerently, that CreateLinkAction should, at least in the