Issue 6692: Operations and derived attributes (uml2-rtf) Source: TimeWarp Engineering Ltd. (Mr. Steven T. Cramer, scramer(at)timewarpllc.com) Nature: Uncategorized Issue Severity: Summary: I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes? In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute? Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation? Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required? Resolution: Revised Text: Actions taken: December 10, 2003: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: It is usually a question of balance between efficiency and the need to minimize the storage requirements for storing models (in both dynamic and persistent store). In principle, anything that can be computed should be defined as an operation. Non-derived attributes provide the basic input data from which such computations can be effected. Derived attributes are typically used when the computation is judged to be inefficient in some sense. (Clearly, there is a discretionary element in this, and such criteria are not necessarily applied consistently in the spec.) In the particular case of MultiplicityElement::lowerBound(), this was necessary since it is possible that no lower bound was actually specified by the modeler. Concerning derived values, the intent is to provide a specification of how each derived feature is computed, whether through a formally specified formula (in OCL, for example), or, where this is impractical or infeasible for some reason, in precise natural language. However, because this is a lengthy undertaking requiring significant resources, it was deemed impractical to hold up release of the specification until this task was completed. Instead, its completion has been relegated to subsequent revision task forces. The same applies to various constraints. Disposition: Closed, no change End of Annotations:===== Subject: Operations and derived attributes Date: Wed, 10 Dec 2003 12:49:33 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations and derived attributes Thread-Index: AcO/Vrv2lD/whqIqQI6FhlJPUqbbHQ== From: "Steven T. Cramer" To: , I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes? In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute? Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation? Why canÞ²t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()Þ¥ what makes the lowerBound() operation required? Steven T. Cramer SCramer@TimeWarpEngineering.com Subject: RE: Resolution proposals for classes and Infrastructure Date: Thu, 11 Aug 2005 20:08:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution proposals for classes and Infrastructure Thread-Index: AcWewITOG6i8q30ITySBu+6d0nZeUwACOzWA From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com This is generally OK - some minor comments (and philosophy - sorry) below. In 6630 there is a slight lack of clarity in the resolution as to whether the property is only to be made non-navigable (for which we have no notation) or in addition whether its ownership should be changed from the Class to the Association: I think the latter is intended but it could be made clearer. Even if we do clarify I'd probably abstain on the issue: I can see the argument for the resolution in terms of consistency, but remain unhappy about how the new definition of navigability is applied in the UML metamodel itself (in fact it has not been explicitly applied - we kept the metamodel as it was despite changing what navigability meant). The original issue 6630 is IMHO somewhat muddled when it refers to an element 'knowing about its dependencies': model elements cannot 'know' anything and IMHO such anthropomorphic phrasing tends to really cloud discussion. In practice any model-processing application/tool (for which the UML metamodel is really the design/specification model) will need to have direct access to the elements at both ends of any such Dependency (if only to allow the user to draw the line). And the intention of UML is to allow such tools to perform impact analysis etc (i.e. bidirectional navigation): so the fact that we don't reflect that expected access in the metamodel is a shame: we're not talking about a 'real' business application here. -------- For 6692 I agree that it should be Close no change, but don't think the response really answers the question of when to use derived attributes vs operations. I don't agree that ". Derived attributes are typically used when the computation is judged to be inefficient in some sense. " One reason could be if there is the possibility of setting the value (which we have in the metamodel itself). Another if there may be the need to serialize it (e.g. via XMI). My own view is that if something represents 'data' then it should be a derived attribute since it gives a lot more capability and provides a more uniform interface to client tools. In fact I don't think we do have any (non-helper) operations as part of the metamodel itself. In the specific case of lowerBound() the reason for an operation is that this is not a true part of the metamodel but a helper operation used only in the constraint for specifying the derived attribute. --------- There is a typo in 8015: there is an extraneous 'in' before 'with': "Compositions may be linked in a directed acyclic graph in with transitive deletion characteristics" -------- One thing we need to add, I suggest to the resolution to 6492, is the convention for naming Associations: CMOF requires all Associations to have a name, and none at all are explicitly named in the Infra or Super specs. The convention I used in creating the XMI (which was also used in the UML 1.x XMI) is to name associations as "A_" followed by the name of the 1st end followed by "_" followed by the name of the 2nd end (where the name ends are as per the current proposed resolution if not explicit). PS we may want to add something to the following in the 6492 resolution text "in general, there is no need to refer to them explicitly either in the text or in formal constraints" while true, there is the need to refer to them in generated MOF language bindings for the UML metamodel (which is why CMOF requires the names). So I suggest adding "though they may be needed for other purposes such as MOF language bindings that use the metamodel." Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, 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: Thursday, August 11, 2005 10:42 PM To: uml2-rtf@omg.org Subject: Resolution proposals for classes and Infrastructure Here are 10 resolution proposals that I hope to submit to ballot 8. Most of them are in the Classes and Infrastructure areas, so they should probably be carefully scrutinized. Cheers, Bran To: "Pete Rivett" Cc: uml2-rtf@omg.org Subject: RE: Resolution proposals for classes and Infrastructure X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 12 Aug 2005 19:22:32 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/12/2005 19:22:34, Serialize complete at 08/12/2005 19:22:34 Thanks for the feedback, Pete. > In 6630 there is a slight lack of clarity in the resolution as to > whether the property is only to be made non-navigable (for which we > have no notation) or in addition whether its ownership should be > changed from the Class to the Association: I think the latter is > intended but it could be made clearer. I have added some text to clarify both the intent and the meaning of the resolution. > -------- > For 6692 I agree that it should be Close no change, but don't think > the response really answers the question of when to use derived > attributes vs operations. I don't agree that ". Derived attributes > are typically used when the computation is judged to be inefficient > in some sense. " > One reason could be if there is the possibility of setting the value > (which we have in the metamodel itself). I believe that I mentioned this reason. > Another if there may be the > need to serialize it (e.g. via XMI). Can you please clarify the above point? I am not following the reasoning. > My own view is that if > something represents 'data' then it should be a derived attribute > since it gives a lot more capability and provides a more uniform > interface to client tools. I completely am missing your point on this one as well. > In fact I don't think we do have any > (non-helper) operations as part of the metamodel itself. Not directly in the metamodel, but certainly in the spec. > There is a typo in 8015: there is an extraneous 'in' before 'with': " > Compositions may be linked in a directed acyclic graph in with > transitive deletion characteristics" fixed. Thanks. > One thing we need to add, I suggest to the resolution to 6492, is > the convention for naming Associations: CMOF requires all > Associations to have a name, and none at all are explicitly named in > the Infra or Super specs. > The convention I used in creating the XMI (which was also used in > the UML 1.x XMI) is to name associations as "A_" followed by the > name of the 1st end followed by "_" followed by the name of the 2nd > end (where the name ends are as per the current proposed resolution > if not explicit). Included. > PS we may want to add something to the following in the 6492 resolution text " > in general, there is no need to refer to them explicitly either in > the text or in formal constraints" while true, there is the need to > refer to them in generated MOF language bindings for the UML > metamodel (which is why CMOF requires the names). So I suggest > adding "though they may be needed for other purposes such as MOF > language bindings that use the metamodel." This too was included in the latest version. Thanks again...Bran Subject: RE: Ballot 8 - revised (sans 4448 and 8449) Date: Fri, 2 Sep 2005 05:33:36 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 8 - revised (sans 4448 and 8449) Thread-Index: AcWqYeX118Yq0N86SpirjWA9gueHfwFRh5Fg From: "Pete Rivett" To: "Branislav Selic" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j82Cpmhh009145 Adaptive votes YES to all the proposed resolutions, except 6692 to which it ABSTAINS and 8341, 8706 to which it votes NO. 8341: I agree with the sentiment of uniform terminology but don't think it justifies the break in compatibility with the finalized UML 2.0 by changing the Enumeration name. No problem though with adding the extra literal. Interestingly issue 8348 in this same ballot (rightly IMHO) rejects a virtually identical (in spirit) proposed name change: we should have a consistent line on this sort of thing. 8706: I've commented on this before and assumed it would be fixed - and had not noticed it getting into the Ballot until now. The principle is OK but the current text needs more work. I suggest people really try to read and follow what's proposed. Overall if we adopt this resolution it will come back to bite us - with a slew of further issues. - the phrase 'the most detailed namespace" does not have a meaning - the following clause totally loses me however many times I try to read it "only the referenced elements which owned elements are not referenced are filtered (shown) by the profile." - I'm totally confused as to whether you <> an element to show it or hide it. The latter seems counter-intuitive and at odds with the description of Profile::metamodelreference "References a package containing (directly or indirectly) metaclasses that may be extended." - The explanation as a whole is not helped the seeming use of 'filtered' to mean 'shown' (normally 'filtered' is used as in 'filtered out') - I just don't understand what makes Metaclass1 'hidden' in the example given that myProfile as a whole has an import/reference to its package myMetamodel. - What's more Metaclass1 has a stereotype explicitly attached - so how can the stereotype ever be applied to an instance of Metaclass1 if those instances are hidden (apparently instances of Metaclass1 are not hidden if the stereotype has already been applied - but how would anyone apply a stereotype to an instance that is hidden). - The Notation section of Profile should be updated to reflect the use of <> I suggest the cleanest approach rather than struggling with English is to define a helper function 'Profile::availableMetamodelElements()' which explicitly via OCL specifies which elements are available (we should avoid the term 'visible' which has a quite separate meaning). 6692: as previously commented I agree with the 'closed no change' but not the detail of the explanation describing when to use derived attributes and which IMHO does not really answer the issue. ---------- Comments not affecting my vote: Issue 8327 is interesting since the constraint is expressed in terms of diagram (refers to 'above') rather than the metamodel. Though I have not voted against since it is consistent with the existing DestructionEvent. I guess this will get picked up if/when we try to do these in OCL! 8340: Discussion is quite wrong when it says "The specializations of associations are not normally mentioned in the text. ". The document invariably DOES have "{subsets X}" or the incorrect "(Specialized from X)" in the text for Associations as well as in the diagrams. 8345 has it more accurate when it says 'in the Interactions chapter' However I'm not comfortable with closing such quite reasonable issues 'closed no change' in this way. Maybe we should have a general issue 'for Properties add subsets to text and replace specializes by subsets' so that we can close specific issues as a duplicate of this and do the general cleanup at editor convenience. ----------- Editorial fixes --------- 8038: the issue text starts with an odd "done)". I checked and it was in the original from Juergen. I suggest just deleting the "done)" to avoid others having to make the same checks for inadvertently deleted text. 8147: replace 'specialized from' by 'subsets' (unless we're letting these go and cleaning them all up with a global replace) 8152: ditto 8170: 2nd change 'remove MultiplicityElement increment' is a bit unclear: suggest replacing by 'remove MultiplicityElement from Figure 143' or similar 8706: there should not be a paragraph break at the end of the main block of new text - between "For example, he can" and "build a specific..." 8706: the first column in table at end should say "PackageImport" not "PackagedImport", and the 3rd column "metaclassReference" not "metaclasReference" 8706: The Notation should update Table 24 not Table 23 8706: there are grammatical typos which could do with being fixed editorially if we adopt this resolution (which I hope we do not in its current form) Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448