Issue 8453: Profiles::ExtensionEnd has wrong default multiplicity (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default. Recommendation: Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd. Resolution: OK, that is a more accurate specification. Revised Text: The following changes need to be made in the Superstructure spec (ptc/04-10-02) and the corresponding sections in the Infrastructure spec (ptc/04-11-16) In 18.3.3 ExtensionEnd, Attributes Replace No Additional Attribute By lower : integer = 0 redefines MultiplicityElement::lower This redefinition changes the default multiplicity of association ends, since model elements are usually extended by 0 or 1 instance of the extension stereotype. In Figure 446, Add as an attribute of ExtensionEnd lower {redefines lower}: integer = 0 Actions taken: March 4, 2005: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== ssue Y1:Profiles::ExtensionEnd has wrong default multiplicity Source: Pete Rivett, IBM Software Summary: ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default. Recommendation: Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd Issue 8453: Profiles::ExtensionEnd has wrong default multiplicity Click here for this issue's archive. Source: Adaptive Ltd. (Mr. Pete Rivett, mailto:%20pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default. Recommendation: Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd. Discussion: OK, that is a more accurate specification. Revised Text: In 18.3.3 ExtensionEnd, Attributes Replace No Additional Attribute By Lower : integer = 0 redefines MultiplicityElement::lower This redefinition changes the default multiplicity of association ends, since model elements are usually extended by 0 or 1 instance of the extension stereotype. Resolution: Resolved Subject: RE: [Profile] - set of issue resolution Date: Tue, 17 May 2005 15:46:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Profile] - set of issue resolution Thread-Index: AcVbBYj0t8dIUYKARSixD5NEYkQzcwAB/2SQ From: "Pete Rivett" To: , X-Virus-Scanned: by amavisd-new at sentraliant.com Here are some comments by issue number.... In general where there are changes made to the document they should be applied to the equivalent section in Infrastructure also. Issue 8256: I think the phrase 'at least one instance of the stereotype extension graph' is a bit cryptic: I suggest 'at least one instance of the stereotype or one of its subclasses' Issue 8449: I am not sure about Image inheriting from Element: I see Image as more of a Data value. I think this needs more discussion. If it does inherit from Element then it should be "InfrastructureLibrary::Constructs::Element" rather than from Abstractions. Issue 8453: Also needs the diagram (Figure 446) to be updated to show the redefined 'lower' property on ExtensionEnd. Issue 8596: It would be helpful to correct the start of the issue text and clarify that it is referring to the 'isRequired' attribute in section 18.3.2. I think the text of the spec needs correcting by replacing "The attribute value is derived from the multiplicity of Extension::ownedEnd" by "The attribute value is derived from the multiplicity of the Property referenced by Extension::ownedEnd". Adding OCL would be even better. Also the issue has a point about Figure 448: it could be made clearer by indicating that's it's an instance diagram (at the MOF level which is what it's about). Just change the names in the boxes to: Interface:CMOF::Class and Home:CMOF::Stereotype. The diagram change in the current resolution should be to add "{redefines ownedEnd}" as opposed to "{subsets ownedEnd}". This is already reflected in 18.3.2 so the 2nd change is not necessary at all. Issue 8598: the '/' indicates that the Association is derived so I do not see any reason to remove it. This is official notation for a derived Assoaiction (see 2nd bullet on p39). Isue 8600: "{subsets type}" should be "{redefines type}" as in the Issue and as in the text of 18.3.3. hence the change " In ExtensionEnd, Association, type Add subsets TypedElement::type." is redundant and wrong. Rather than deleting "which was 1" completely, it might be useful to replace it by "which normally, for MultiplicityElements, evaluates to 1 if empty" Issue 8601: I disagree with removing the notation option of allowing '1' instead of {required}. This is not fixing a real problem and introducing such incompatibilities (it invalidates some diagrams, and tools, which are currently valid) is not something an RTF should be doing in the absence of a compelling reason. Issue 8603: rather than addign text "OCL is not available", why not add the OCL? 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 > -----Original Message----- > From: Desfray [mailto:Philippe.Desfray@softeam.fr] > Sent: Tuesday, May 17, 2005 6:07 PM > To: uml2-rtf@omg.org > Subject: [Profile] - set of issue resolution > > Dear all, > For the next resolution thread, and to the particular attention of the > Profile WG > > Here is the thread of numerous and easy issues (typos, light > issues) for > profiles. The remaining issues will stem from the teleconf > of the 20th on > Profile. > > To be integrated in the Ballot 4 if everyone is enthousiast with these > resolutions. > Best regards > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com >