Issue 6474: Section 8.1 Overview (uml2-superstructure-ftf) Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com) Nature: Uncategorized Issue Severity: Summary: This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both. They are not required to have both types. Resolution: see above Revised Text: Actions taken: November 7, 2003: received issue March 8, 2005: closed issue Discussion: Replace the third sentence of the second paragraph in section 8.1 on page 133 from: It has one or more provided and required interfaces (potentially exposed via ports), and its internals are hidden and inaccessible other than as provided by its interfaces with: It has one or more provided and/or required interfaces (potentially exposed via ports), and its internals are hidden and inaccessible other than as provided by its interfaces End of Annotations:===== ection 8.1 Overview Date: Wed, 21 Jan 2004 15:46:09 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Pete Rivett , Branislav Selic CC: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, ocl2-ftf@omg.org Subject: Re: Ballot 5 DRAFT X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Pete, Thanks for your comments. Regarding the component ones, some comments below (preceded by "GR>" ) Issue 2613: this is an example of the more general problem of intended/unintended inheritance. This issue states that though Node inherits from Class (and thus inherits the ability to realise Interfaces) the spec does not make clear whether that is the intention. The proposed response is merely to say "In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired." and Closed no change. Personally I don't think addresses the original issue which is about the intention of the spec. More broadly, the structure of the metamodel - in particular the inheritance from very general classes such as Classifier, Behavior, Class - means that lots of capabilities are inherited into subclasses which make no sense at all: (I remember Steve Cook at one stage came up with a pretty long list of absurd examples which I cannot lay my hands on right now): it cannot be assumed that just because they're inherited that they're intended, useful or meaningful. It makes it very hard for tool vendors to achieve useful interchange: faced with a whole host on inherited features (on e.g. Node) it becomes a somewhat random choice as to which they will actually choose to populate into the XMI file. And of course each vendor is likely to make a somewhat different choice. This is not an easy issue to address but I think it's important to at least try. Approaches are: - List all the semantically valid inherited features against each class in the spec - Introduce/document an explicit redefinition for each semantically valid inherited feature - Introduce OCL constraints to explicitly state that all non-semantically-valid inherited features should be empty - Show a complete instance diagram in the spec for meaningfully-complex examples GR> This issue was known to the team when the UML2 meta model was constructed. Some users want interfaces on nodes, and the model supports that. The specification should not needlessly repeat features of supertypes under the label "intention" - books can do that. Note that this is not "unintended" inheritance, but actually "intended" inheritance. Perhaps there are other issues related to "unintended" inheritance in the specs, but 2613 is not one of them, I believe. Issue 6352: (Very picky point) This resolution refers to fixing the MDL: technically the MDL is not normative (since as a principal OMG does not want a proprietary tool representation as normative): the MOF XMI is the normative representation of the metamodel. Though the XMI is generated from the MDL (for the time being) I think it would be preferable in formal issue resolutions to refer to fixing the XMI. GR> Whether normative or not, the spec has the right name, and the XMI should be updated to use this name. * Issue 6352: Should more clearly identify 'the corresponding figure': as far as I can see Figure 126 in the spec is correct. GR> It appears you are referring to the wrong issue number. Issue 6474: Should remove 'e.g.' from the resolution - the resolution must contain the actual replacement text not example replacement text GR> Agreed. Bran has kindly agreed to update the ballot. ** Issue 6476: The resolution is far too vague as to which diagrams are to have the Stereotype added. This is not acceptable as a resolution. GR> Add to diagrams 85, 86, 87, 91. Bran has kindly agreed to update the ballot. Thanks, Guus Pete Rivett wrote: Here are comments on the draft. In general they are not about the content of the resolutions but about how they are expressed. IMHO those marked ** must be addressed, those marked * should be addressed to achieve resolutions that can be properly reviewed by the AB, and the others are more minor. The broader point I make about issue 2613 I think needs more general discussion at an FTF meeting/telecon. Issue 2613: this is an example of the more general problem of intended/unintended inheritance. This issue states that though Node inherits from Class (and thus inherits the ability to realise Interfaces) the spec does not make clear whether that is the intention. The proposed response is merely to say "In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired." and Closed no change. Personally I don't think addresses the original issue which is about the intention of the spec. More broadly, the structure of the metamodel - in particular the inheritance from very general classes such as Classifier, Behavior, Class - means that lots of capabilities are inherited into subclasses which make no sense at all: (I remember Steve Cook at one stage came up with a pretty long list of absurd examples which I cannot lay my hands on right now): it cannot be assumed that just because they're inherited that they're intended, useful or meaningful. It makes it very hard for tool vendors to achieve useful interchange: faced with a whole host on inherited features (on e.g. Node) it becomes a somewhat random choice as to which they will actually choose to populate into the XMI file. And of course each vendor is likely to make a somewhat different choice. This is not an easy issue to address but I think it's important to at least try. Approaches are: - List all the semantically valid inherited features against each class in the spec - Introduce/document an explicit redefinition for each semantically valid inherited feature - Introduce OCL constraints to explicitly state that all non-semantically-valid inherited features should be empty - Show a complete instance diagram in the spec for meaningfully-complex examples ** At some stage Super FTF needs to endorse the shared issues that Infra took the lead on and accepted resolutions for in Infra Ballot 2. * Issue 6209: It should be clearer where the abstract syntax changes are reflected in the specification text/diagrams Issue 6352: (Very picky point) This resolution refers to fixing the MDL: technically the MDL is not normative (since as a principal OMG does not want a proprietary tool representation as normative): the MOF XMI is the normative representation of the metamodel. Though the XMI is generated from the MDL (for the time being) I think it would be preferable in formal issue resolutions to refer to fixing the XMI. * Issue 6352: Should more clearly identify 'the corresponding figure': as far as I can see Figure 126 in the spec is correct. Issue 6358: The constraint should really have OCL Issue 6364: There is a typo in the first new sentence - it needs an 'of' after 'supertype' * Issue 6406: Should be more precise about where the spec should be updated; see above re 'MDL file' Issue 6441: Item a) in the issue does not seem unreasonable to address in the FTF Issue 6474: Should remove 'e.g.' from the resolution - the resolution must contain the actual replacement text not example replacement text ** Issue 6476: The resolution is far too vague as to which diagrams are to have the Stereotype added. This is not acceptable as a resolution. ** Issue 6480: There is another occurrence of 'return message' at bottom of p417 - this should presumably also be replaced to fully address the issue. Issue 6605: There is a typo in the discussion which I would not normally comment on but it seems to have a large effect on understanding: in the following there seems to be a word missing after "defining the": "either defining the in the namespace of the context classifier, where..." ** Issue 6680: The existing association is from Activity to StructuredActivityEdge not ActivityEdge as stated. When making an association derived I think it's essential to describe in the text how the derivation id defined - ideally by using OCL. General: is there any meaning attached to the fact that some Discussions (resolutions) are in red and some black? Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Wednesday, January 21, 2004 1:51 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 5 DRAFT Attached please find a DRAFT of Ballot 5. The vote on this ballot is scheduled to start tomorrow at noon, so please make sure that it is correct (it took several hours to assemble requiring lots of editing and it is quite possible that I made a mistake somewhere). The list consists of 86 proposed resolutions that were mailed to the superstructure team. Note that I did not automatically include all the resolutions that were proposed, eliminating those that are likely to be challenged. Therefore, only the most trivial ones and the ones that have been officially vetted by the work group are included. So, work group leads need to go through this list very carefully to make sure they do not inadvertently retire issues that were excluded from the ballot. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both. They are not required to have both types