Issue 8455: Profiles::ObjectNode has wrong default multiplicity (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default. Recommendation: Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode. Resolution: See issue 8454 for disposition Revised Text: Actions taken: March 4, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== ssue Y1:Profiles::ObjectNode has wrong default multiplicity Source: Pete Rivett, IBM Software Summary: ObjectNode::upper should have default multiplicity unbounded (.*.) in order of object nodes to be multi-valued by default. Recommendation: Redefine inherited MultiplicityElement::upper to have default .*. in ObjectNode. Subject: RE: DRAFT of ballot 6 Date: Sun, 17 Jul 2005 23:31:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT of ballot 6 Thread-Index: AcWLDFwjyVCT4WBHSaSGhlQjAkpekAALdleg From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com See detailed comments below. I think 8706 needs more work and so should probably be pulled this time round. The discussion for 7967 is contradictory: Oystein says the 'issue is understandable' yet the second comment that 'agrees with Oystein' says the issue should be close due to 'unclear issue formulation'. It cannot be both understandable and unclear! There may be valid reasons to close the issue with no change but this does not seem to be one of them. 8026 seem premature to close - unless Conrad can confirm that he's been convinced. 8028: it seems intuitively wrong to have a constructor dependent on an instance. Also the definition of a constructor as "A constructor is any operation having a single return result parameter of the type of the owning class. " seems over-general. e.g. the Person::getMother() operation returns a Person but is not a constructor by any stretch. Furthermore there are genuine constructors that are not defined on t he owning class (e.g. those owned by factory classes). 8167: Should not be 'closed no change' since it contains a revision to text. 8180: proposes adding "(Specialized from Action:output)" to a property. However there is no such thing as 'specialized from' for a property in UML: it should be subsets. 8508: I disagree with making Model::viewpoint single valued. It both makes a viewpoint mandatory, and is over-restrictive compared with the accompanying text: for example where a model composes two other models (each with different viewpoints it seems reasonable for the containing model's viewpoint to have two values. Restricting the multiplicity in this way seems unnecessary at RTF stage and uncalled for by the issue (which seems to be complaining about the purely textual difference between [0..*] and [*].) 8454 If ObjectNode is not a MultiplicityElement (which seems to be true) then why does it have constraint [2] isUnique=false - since it will not have such a property. However I must admit I cannot make sense of my original issue - sorry. 8593: The preferred style seems to be 'None.' rather than 'No additional associations'. Issue 8706: First para of Discussion is misleading since the mechanism is not based on Import but metamodel/classReference. Need to expand on the practical meaning of 'accessible (visible)' in para 2 of revised text. And the meaning of "the most detailed namespaces " The last clause of this paragraph 2 needs reformulating/punctuating: "only the referenced elements which owned elements are not referenced are filtered (shown) by the profile". As well as not scanning, it seems mistaken in equating 'filtered' (which is normally used in the sense 'filtered out') with '(shown)' Need to say what happens if a normal PackageImport is used by a Profile. In the example I don't see why Metaclass1 is hidden - since it's contained by the Package which is <>d. And why an explicit reference is needed for Metaclass2 when it's owned by the Package. There is clearly something going on that I'm not getting - and I was involved in t he calls on this subject! I think we could do with some OCL to be clear exactly what the set of 'accessible' elements is. Likewise I do not understand the paragraph about combining imports if one Profile imports another. If P1 imports P2 when why combine 'at the P2 level'? Generally there are several typos and the English needs tidying up. 8752: the Issue summary is missing words - it says " instead of " 8759: revised text should refer to "OpaqueAction, Generalizations" not "Actions, Generalizations". 8867: again the final 2 sentences should have 'subsets' not 'specializes'. 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: Sunday, July 17, 2005 8:55 PM To: uml2-rtf@omg.org Subject: DRAFT of ballot 6 Importance: High Slim pickings this time around -- just 31 resolution proposals. However, with vacation season on us, I guess this is to be expected. It does mean, however, that we will need to pick up our pace. We still have close to 400 issues to deal with. Please look at these carefully and raise any concerns that you have with these proposed resolutions before noon EDT on Friday, July 22. Regards, Bran To: "Pete Rivett" Cc: uml2-rtf@omg.org Subject: RE: DRAFT of ballot 6 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 18 Jul 2005 11:53:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/18/2005 11:53:31, Serialize complete at 07/18/2005 11:53:31 Comments on Pete's comments for ballot 6: > I think 8706 needs more work and so should probably be pulled this time round. Since Philippe is not around to defend it, I guess I will pull it. (Also, as I noted earlier, it needs to have an Infra section.) > The discussion for 7967 is contradictory: Oystein says the 'issue is > understandable' yet the second comment that 'agrees with Oystein' > says the issue should be close due to 'unclear issue formulation'. > It cannot be both understandable and unclear! There may be valid > reasons to close the issue with no change but this does not seem to > be one of them. Agreed. > 8026 seem premature to close - unless Conrad can confirm that he's > been convinced. Personally, I think that this is an issue that will require a vote, since I don't think that Conrad will ever be convinced. However, I will pull the issue because I don't think the presentation option proposed by Conrad has been discussed enough. In my view, it can only go as an optional form, since the current form is already in the adopted spec. Although I don't like it myself, it is wrong to argue that the notation is unusable as the example in the document shows. > 8028: it seems intuitively wrong to have a constructor dependent on > an instance. > Also the definition of a constructor as "A constructor is any > operation having a single return result parameter of the type of the > owning class. " seems over-general. e.g. the Person::getMother() > operation returns a Person but is not a constructor by any stretch. > Furthermore there are genuine constructors that are not defined on t > he owning class (e.g. those owned by factory classes). Disagree. We already argued in the past that the meaning of source and destination of a dependency is sometimes ambiguous. It's a problem with the Dependency concept and not with this particular resolution. Nevertheless, I will pull this issue for other reasons, as stated in my comments. > 8167: Should not be 'closed no change' since it contains a revision to text. Will remove the revision and raise an issue for the revision. > 8180: proposes adding "(Specialized from Action:output)" to a > property. However there is no such thing as 'specialized from' for a > property in UML: it should be subsets. Correct. However, I think that this requires a special issue, which I have raised. Leaving this resolution in, in its current (incorrect) form, will at least make the chapter consistent throughout. I have already raised an issue for the more general problem. > 8508: I disagree with making Model::viewpoint single valued. It both > makes a viewpoint mandatory, and is over-restrictive compared with > the accompanying text: for example where a model composes two other > models (each with different viewpoints it seems reasonable for the > containing model's viewpoint to have two values. > Restricting the multiplicity in this way seems unnecessary at RTF > stage and uncalled for by the issue (which seems to be complaining > about the purely textual difference between [0..*] and [*].) I disagree. The spec is pretty clear when it says that a "model captures a view" (note the singular case), which does not remove the possibility of having other models with different views in them. If we allow multiple viewpoints in a single model, then we will not be able to clearly delineate them, since they would all be batched into a single model package. The only question I have here is whether the multiplicity should be [0..1] allowing models that are not committed to any particular viewpoints. This would allow models for specific viewpoints to be grouped into a common viewless model. > 8454 If ObjectNode is not a MultiplicityElement (which seems to be > true) then why does it have constraint [2] isUnique=false - since it > will not have such a property. However I must admit I cannot make > sense of my original issue - sorry. > > 8593: The preferred style seems to be 'None.' rather than 'No > additional associations'. See my previous comments on this. > Issue 8706: First para of Discussion is misleading since the > mechanism is not based on Import but metamodel/classReference. > Need to expand on the practical meaning of 'accessible (visible)' in > para 2 of revised text. And the meaning of "the most detailed namespaces " > The last clause of this paragraph 2 needs reformulating/punctuating: " > only the referenced elements which owned elements are not referenced > are filtered (shown) by the profile". As well as not scanning, it > seems mistaken in equating 'filtered' (which is normally used in the > sense 'filtered out') with '(shown)' > Need to say what happens if a normal PackageImport is used by a Profile. > In the example I don't see why Metaclass1 is hidden - since it's > contained by the Package which is <>d. And why an > explicit reference is needed for Metaclass2 when it's owned by the > Package. There is clearly something going on that I'm not getting - > and I was involved in t he calls on this subject! > I think we could do with some OCL to be clear exactly what the set > of 'accessible' elements is. > Likewise I do not understand the paragraph about combining imports > if one Profile imports another. If P1 imports P2 when why combine > 'at the P2 level'? > Generally there are several typos and the English needs tidying up. Will pull this. > 8752: the Issue summary is missing words - it says " instead > of " I will fix this. > 8759: revised text should refer to "OpaqueAction, Generalizations" > not "Actions, Generalizations". Good eye. I will fix this editorially. > 8867: again the final 2 sentences should have 'subsets' not 'specializes'. See above. Thanks...Bran