Issue 5924: representation of arrays of values in an action language (uml2-superstructure-ftf) Source: (, ) Nature: Clarification Severity: Significant Summary: While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23]; However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict? Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics. Resolution: see above - resolved Revised Text: Actions taken: April 30, 2003: received issue March 8, 2005: closed issue Discussion: It is indeed the case that arrays are represented using the feature multiplicity property. Whether values are sets or not is determined by the setting of the “isUnique” property of the feature, so that both bags and sets are supported. However, the phrase “set of values” is not meant to imply set characteristics but was meant to convey the notion of a collection. For this reason, the phrase “set of values” needs to be replaced by the phrase “collection of values” in the following places: Superstructure ?? Page 42 in the Semantics section of MultiplicityElement (4 occurrences) ?? In the second sentence of the second paragraph of Property (section 7.11.4) on page 89 ?? In the first sentence of the second paragraph of the Description subsection of StructuralFeature (7.9.5) on page 75. Infrastructure ?? Page 73 in the Semantics section of MultiplicityElement (4 occurrences) ?? In the second sentence of the second paragraph of Property (section 11.3.5) on page 123 ?? In the first sentence of the second paragraph of the Description subsection of StructuralFeature (11.3.11) on page 129. End of Annotations:===== From: webmaster@omg.org Date: 30 Apr 2003 09:32:43 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Martin Jung Company: FAU Erlangen mailFrom: jung@informatik.uni-erlangen.de Notification: Yes Specification: Unified Modeling Language Section: 2.21.7 FormalNumber: formal/2003-03-01 Version: 1.5 RevisionDate: 03/01/03 Page: 2-263 to 2-266 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5 Description While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23]; However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict? OMG Issue No: 5924 Title: representation of arrays of values in an action language Source: Summary: While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23]; However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict? Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics. Discussion: Proposed Resolution: Replace the explanation of MultiplicityElement.isUnique:Boolean The new explanation shall read: "This attribute specifies whether the numbers for cardinality are counted by the rules of set or bag semantics, which is to say, if duplicate values are not allowed, the value of isUnique shall be True (set), and if the same value may recur any number of times the value of isUnique shall be False.(bag). " Discussion: The Issue raised regarding differentiating between set and bag semantics was intended to be answered by the attribute isUnique of the MultiplicityElement. The wording in the adopted spec was evidently inadequate to realize this intent. Disposition: Unresolved OMG Issue No: 5924 Title: representation of arrays of values in an action language Source: Summary: While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23]; However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict? Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics. Discussion: Proposed Resolution: Replace the explanation of MultiplicityElement.isUnique:Boolean The new explanation shall read: "This attribute specifies whether the cardinalities are counted by the rules of set or bag semantics, which is to say, if duplicate values are not allowed, the value of isUnique shall be True (set), and if the same value may recur any number of times the value of isUnique shall be False.(bag). " Discussion: The Issue raised regarding differentiating between set and bag semantics was intended to be answered by the attribute isUnique of the MultiplicityElement. The wording in the adopted spec was evidently inadequate to realize this intent. BRAN: I think that the problem here is the text that is in section 7.9.5 (StructuralFeature) on page 75 where the offending statement occurs. The folks who raised the issue are clearly mathematically oriented and they tripped over the relatively colloquial usage of the word .set.. To get around that, I suggest that we simply replace the word .set. by the word .collection.. I agree with Karl that the problem of bag vs. set semantics is effectively handled through the .isUnique. attribute, but I see no reason to change the current definition of this attribute in the spec, since it is not what caused the problem. (BTW, int[23] foo would be represented as foo : int[23} (not foo : int[0..23] as suggested in the issue text.) Disposition: Unresolved OMG Issue No: 7336 Title: UML 2 Super / missing owners of concepts Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The owners of the metaclasses InformationFlow, ParameterSet, and PrimitiveFunction are not defined Discussion: (1) InformationFlow: Make UML::AuxiliaryConstructs::InformationFlows::InformationFlow a specialization of UML::Classes::Kernel::PackageableElement so that instances can be contained in packages (as with dependencies) as follows: Change required: in figure 413 on page 532, add PackageableElement (from Kernel) to the diagram and add a generalization from InformationFlow to PackageableElement. (2) ParameterSet . Make ParameterSet owned by Behavior. Changes required: (i) in figure 189 on page 275 add a new metaclass called Behavior (inheriting from Behavior (fromBasicBehaviors)) into the diagram and show a composite aggregation between UML::Activities::CompleteActivities::Behavior and UML::Activities::CompleteActivities::ParameterSet per diagram below (ii) add section 12.3.9 following section 12.3.8 (ActivityPartition) as follows: 12.3.9 Behavior (as specialized) (CompleteActivities) Behavior is specialized to own zero or more ParameterSets. Description The concept of Behavior is extended to own ParameterSets. Attributes No additional attributes. Associations · ownedParameterSets : ParameterSet[0..*] The ParameterSets owned by this Behavior. Constraints [1] The owned parameter sets of a behavior are the parameter sets of the parameters of the behavior. Semantics See semantics of ParameterSet on page 354. Notation See notation for ParameterSet on page 354. Examples See examples for ParameterSet on page 354. Changes from previous UML ParameterSet is new in UML 2.0. (3) PrimitiveFunction . Changes required: (i) In figure 143 on page 207 replace the parent PrimitiveFunction with PackageableElement: Disposition: Resolved Subject: RE: Proposed resolutions for Ballot 18 Date: Sun, 4 Jul 2004 14:30:32 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed resolutions for Ballot 18 Thread-Index: AcRhW6ibjYXgVAmoSCKmOfo5OBSDCwArZEVw From: "Karl Frank" To: "Branislav Selic" , , , X-OriginalArrivalTime: 04 Jul 2004 21:30:43.0250 (UTC) FILETIME=[2923E920:01C4620E] I have attached one proposed resolution for the next ballot. Ballot 18, Issue 5924 Don, from discussions I believe you have a special interest in this. I know its not much, but I had to work on a beautiful 4th of July afternoon to even get this one done. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 03 July, 2004 8:06 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Proposed resolutions for Ballot 18 Attached, please find the proposed resolutions for 5 issues assigned to me that I will plan to submit for ballot 18: 6872 (state machines) 7056 (kernel) 7068 (kernel) 7159 (kernel) 7336 (done in conjunction with Conrad B) In particular, note that resolutions 7056 and 7068 are shared issues with the Infra FTF and contain text for chanigng both documents. They have not yet been approved by the Infra FTF, but since there is not Infra FTF ballot for it yet, we might as well approve it in the Super FTF first (in this case, the order does not matter). Note also, that the resolution to issue 7159 is a modified version of the resolution to the same issue that was proposed earlier but was vetoed. Since the architecture board has made a strong recommendation that this area needs to be resolved, the resolution is very similar to the one that was proposed earlier. Regards, Bran Issue5924proposedResolution.doc OMG Issue No: 5924 Title: representation of arrays of values in an action language Source: Summary: While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23]; However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict? Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics. Discussion: This problem report is mainly about definition of MultiplicityElement and in particular its attribute, .isUnique.. We will handle the .another question. indirectly by clarifying where bag semantics apply. UML 2 does handle the problem reported here, but users of the spec fail to understand how, because a wrong name and vague explanation were used for the isUnique attribute of MultiplicityElement. The name is wrong because it is not the collection that is or is not unique, but the elements of the collection. In short .unique. does not mean what the authors of this naming thought, and this has caused misunderstanding. Anybody who doesn.t already get it that .isUnique. doesn.t mean .is a set and not a bag.. Is not likely to understand. The resolution is to change the name and rewrite the explanatory text. We considered renaming the attribute to .isSet. but rejected this because in the context of attributes, .is Set. usually means has a non-null value. A direct answer to the questions raised in this .issue. is contained in the revised text. We quote this part of our resolution here as an answer to whoever raised this issue:: By specifying a multiplicityElement with attribute isBag = true and isOrdered = true, one can specify that an array is intended. Context: Multiplicity Element is in the final adopted spec as follows: Revised Metamodel The attribute .isUnique. of MultiplicityElement and shall be renamed in the abstract syntax to be the attribute isBag, default = no. In addition, we note the format for defining attributes has not been followed in respect to specifiying default values for MultiplicityElement. The UML 2 document rules stipulate that in specifying an attribute, default values should be shown by following the data type with . = .. Revised Text To correct the defect in respect to specifying default values for attributes, the Attribute isOrdered for multiplicityElement shall have the string = false appended after the word Boolean . After this, the first attribute will be specified as: isOrdered Boolean = false The Description of MultiplicityElement in 7.4.1 shall be revised. The entire new Description section will be as follows: MultiplicityElement is an abstract metaclass to enable UML 2 to represent sets or bags(also known as multisets) of ordered or unordered values. MultiplicityElement has mandatory attributes to indicate which of these alternatives is represented by any given instance of MultiplicityElement. By specifying a multiplicityElement with attribute isBag = true and isOrdered = true, one can specify that an array is intended. MultiplicityElement also has optional attributes for specifying lower and upper bounds for number of values. The Attribute .isUnique: Boolean. and its description shall be removed, and in its place, MultiplicityElement shall have an attribute isBag. isBag : Boolean = false This attribute specifies whether an instantiation of MultiplicityElement represents a bag or a set of values. Bag is understood in the usual sense as a multiset, which is to say, as a collection of elements in which members need not be distinct from one another. In this case, when counting the elements collected in a MultiplicityElement, for determining lower and upper bounds, the rule is to count the number of elements, not the number of distinct values. If isSet = true, the collection is understood to be a set, which is to say it does not include two or more members with the same value or identity. Disposition: Resolved Subject: RE: Proposed resolutions for Ballot 18 Date: Mon, 5 Jul 2004 06:10:55 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed resolutions for Ballot 18 Thread-Index: AcRhW6ibjYXgVAmoSCKmOfo5OBSDCwArZEVwABswF7A= From: "Pete Rivett" To: "Karl Frank" , "Branislav Selic" , , , This is really an infrastructure issue. In fact Don already raised the problem being addressed as issue 5976. I prefer Don's suggestion (in that issue) of isDistinct since isBag is not quite accurate: my understanding of Bag is that order is unimportant: in particular in this case an Array (with ordering) is not a Bag despite isBag being true - so the proposal will potentially cause a different confusion. One could even define a derived attribute isBag as (self.isDistinct and not self.isOrdered) though I'm not suggesting this. Pete. 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: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, July 04, 2004 10:31 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Donald.Baisley@unisys.com Subject: RE: Proposed resolutions for Ballot 18 I have attached one proposed resolution for the next ballot. Ballot 18, Issue 5924 Don, from discussions I believe you have a special interest in this. I know its not much, but I had to work on a beautiful 4th of July afternoon to even get this one done. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 03 July, 2004 8:06 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Proposed resolutions for Ballot 18 Attached, please find the proposed resolutions for 5 issues assigned to me that I will plan to submit for ballot 18: 6872 (state machines) 7056 (kernel) 7068 (kernel) 7159 (kernel) 7336 (done in conjunction with Conrad B) In particular, note that resolutions 7056 and 7068 are shared issues with the Infra FTF and contain text for chanigng both documents. They have not yet been approved by the Infra FTF, but since there is not Infra FTF ballot for it yet, we might as well approve it in the Super FTF first (in this case, the order does not matter). Note also, that the resolution to issue 7159 is a modified version of the resolution to the same issue that was proposed earlier but was vetoed. Since the architecture board has made a strong recommendation that this area needs to be resolved, the resolution is very similar to the one that was proposed earlier. Regards, Bran Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics.