Issue 4504: Optimize Instance data values (uml2-superstructure-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Revision Severity: Significant Summary: Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations. There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances. Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode. NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost). Resolution: see above Revised Text: Actions taken: August 16, 2001: received issue March 9, 2005: closed issue Discussion: Instances are expected to be revised for UML 2.0 as a result of aligning UML and MOF UML 2.0 has quite a different Instances metamodel and AttributeLink is not used: instead there is Slot which links to ValueSpecification. Unlike UML 1.x this has a proper mechanism for representing the data value (not just DataValue.name which the issue was complaining about): indded DataValues do not have the overhead of a name at all. UML 2.0 also avoid the problem of Packages having to own DataValues directly – since in 2.0 the ValueSpecifications are contained by the Slot. And the problem of the redundant link from DataValue to Classifier. Finally the suggestion of having the data value as a string on AttributeLink (Slot at 2.0) is no longer appropriate due to the more sophisticated modeling possibilities through ValueSpecification. End of Annotations:===== From: webmaster@omg.org Message-Id: <200108162246.f7GMkSt24217@emerald.omg.org> Date: 16 Aug 2001 18:50:08 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: /PC!!g4~!!H[T!!f<%e9 Name: Pete Rivett Company: Adaptive mailFrom: pete Notification: Yes Specification: UML Section: 2.9.2 and 5.1 FormalNumber: not known Version: 1.4 RevisionDate: 02/2001 Page: various Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description Optimize Instance data values Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations. There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances. Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode. NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost).