Issue 8147: Section: 11.3.3 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: Fig. 142 does not list Dependencies as a generalization. Associations /input:InputPin[*] and /output:OutputPin[*] need the specialization or subset statement as shown in fig. 143 Association /context:Classifier[1] does not agree with multiplicity in fig. 142 Delete headers Examples and Rationale as these sections are blank Resolution: see above Revised Text: Actions taken: January 27, 2005: received issue August 23, 2006: closed issue Discussion: In Actions, Action: Generalizations, remove “Dependencies”. Editor’s note: not done since this is an automatic cross reference to a header (cannot remove part of the header) Associations: /input and /output entries, at beginning of text, add (Specialized from Element:ownedElement) Editor’s note: adjusted to conform to document conventions /context entry, change multiplicity to 0..1. End of Annotations:===== m: webmaster@omg.org Date: 27 Jan 2005 11:51:33 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 11.3.3 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 251-251 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Fig. 142 does not list Dependencies as a generalization. Associations /input:InputPin[*] and /output:OutputPin[*] need the specialization or subset statement as shown in fig. 143 Association /context:Classifier[1] does not agree with multiplicity in fig. 142 Delete headers Examples and Rationale as these sections are blank. 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