Issue 6281: UML2 Super/Composite Structures (uml2-superstructure-ftf) Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk) Nature: Uncategorized Issue Severity: Summary: Divergence between XMI/MDL and the PDF/FM The XMI and MDL files for UML 2 super both state that Port is a subclass of Property and yet the appropriate diagram in the spec (fig 97) doesn't - this fragment of the adopted XMI spec illustrates the point: <ownedType xsi:type="cmof:Class" xmi:id="_UML_CompositeStructures_Ports_Port" name="Port" > > superClass="_UML_CompositeStructures_InternalStructures_Property > > _UML_CompositeStructures_InternalStructures_ConnectableElement > > _UML_Classes_Kernel_StructuralFeature"> Resolution: The resolution of issue 6356 removes this problem. Revised Text: Actions taken: October 2, 2003: received issue March 8, 2005: closed issue Discussion: End of Annotations:===== m: "Moore, Alan" To: "'issues@omg.org'" Subject: UML2 Super/Composite Structures Date: Thu, 2 Oct 2003 17:08:18 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Divergence between XMI/MDL and the PDF/FM The XMI and MDL files for UML 2 super both state that Port is a subclass of Property and yet the appropriate diagram in the spec (fig 97) doesn't - this fragment of the adopted XMI spec illustrates the point: > superClass="_UML_CompositeStructures_InternalStructures_Property > > _UML_CompositeStructures_InternalStructures_ConnectableElement > > _UML_Classes_Kernel_StructuralFeature"> To: Cc: "Branislav Selic" , thomas.weigert@motorola.com, uml2-superstructure-ftf@omg.org Subject: Re: Updated: Proposed issue resolution for common behavior and composite structure working groups X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Mon, 1 Dec 2003 10:10:01 -0500 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 12/01/2003 10:10:04, Serialize complete at 12/01/2003 10:10:04 Thomas, I have a couple of questions/comments: Issue 6281 So to be clear, Port should NOT be a subclass of Property? Issue 6206 In order for instances of Trigger (and its subclasses), InformationFlow, and PrimitiveFunction to be owned by a Namespace, these classes must be direct/indirect subclasses of NamedElement; currently they are not. Thanks, Kenn Hussey Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Thomas Weigert" 11/29/2003 11:36 PM Please respond to thomas.weigert To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject Updated: Proposed issue resolution for common behavior and composite structure working groups Dear all, I discovered that there are many more issues assigned to these two working groups in a later version of the FTF report that I had been looking at. Thus here comes a second installment based on FTF-report-draft-031031.doc (I hope this is the latest version). These two documents include the earlier sent one, so you can just ignore that one. Please pay attention to the discussion suggested for issue 6373. This issue would best be resolved by making a change to Kernel, which unfortunately means also changing the infrastructure. I believe it does not have any significant effect on anything, but changing the infrastructure is always highly controversial. Please advise. All the best, Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, November 29, 2003 7:56 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: Thomas Weigert Subject: Proposed issue resolution for common behavior and composite structure working groups Dear all, please find attached two documents discussing the issues assigned to the common behavior and composite structure working group, respectively. Each document has a summary page indicating the proposed action. Most issues do not require any change, as the UML 2.0 most often has already resolved the issue. There are 2 proposed changes for common behavior and one proposed change for composite structure, all minor. Regarding common behavior there are three issues (6148, 6149, and 6150) which I propose for discussion. While they would not require any change as the solution in the document is as was intended, the issues nevertheless could be addressed: 1. 6148 and 6149 implicitly propose an alternative means of showing textually defined behavior as associated with the Behavior metaclass and making that metaclass concrete. This is as good a solution as the one currently implemented; in my opinion a matter of taste. 2. 6150 requests a notation for method which is reasonable but should be decided upon by teamwork (as nobody ever is satisfied with notation). Please provide feedback on the proposed solution and also provide input to the issues labeled as for discussion. I will propose solutions for those after I have heard from at least several others on the FTF. All the best, Th. [attachment "Composite structure issues resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] [attachment "Common behavior issues resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] From: "Thomas Weigert" To: "Kenneth Hussey" Cc: "Branislav Selic" , Subject: RE: Updated: Proposed issue resolution for common behavior and composite structure working groups Date: Mon, 1 Dec 2003 09:29:22 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Ken, thanks for your comments. Please see below... Th. -----Original Message----- From: Kenneth Hussey [mailto:khussey@ca.ibm.com] I have a couple of questions/comments: Issue 6281 So to be clear, Port should NOT be a subclass of Property? Right. The semantics of being strongly owned by the containing class is given directly in Port. The reason for not making it a property is that it behaves a little different from standard properties as for the simple kind of ports (those typed by an interface) the interface is not really the type of the instance that is created but instead, the nature of the boundary object is determined by the semantics of Port taking that type into consideration. I guess I am worried that making it a subtype of property would muddle the semantics as it introduces additional complexities. Is there a reason for why you are concerned? Issue 6206 In order for instances of Trigger (and its subclasses), InformationFlow, and PrimitiveFunction to be owned by a Namespace, these classes must be direct/indirect subclasses of NamedElement; currently they are not. You are, of course, right. These should be PackageableElements. Alternatively, every behavior that uses triggers could be made to own them which would entail changes to state machine and activity. In addition, we need then to figure out how the ports can reference something inside one of the behaviors (for ports qualified by a trigger). While nobody ever would name a trigger, making it a packageable element seems to have the least impact.... OMG Issue No: 6281 Title: UML2 Super/Composite Structures Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: Divergence between XMI/MDL and the PDF/FM The XMI and MDL files for UML 2 super both state that Port is a subclass of Property and yet the appropriate diagram in the spec (fig 97) doesn't . this fragment of the adopted XMI spec illustrates the point: > superClass="_UML_CompositeStructures_InternalStructures_Property > > _UML_CompositeStructures_InternalStructures_ConnectableElement > > _UML_Classes_Kernel_StructuralFeature"> Discussion: The mdl file inadvertently has a specialization relation between Port and Property. Remove this relation from the .mdl file. No changes are required to the metamodel in the FAS or the specification text. Disposition: Resolved