Issue 5363: Composite nodes: Derivation of implementingComposition (uml-edoc-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: Summary: Figure 6-4: The diagram is misleading and the actual derivation needed (which is hinted at under Constraint but should be more formally defined as in 6.2.4) would seem to rely on non-navigable references in the FCM metamodel: the new derived 'implementingComposition' association would not be based on the 'nodes' association shown between FCMComposition and FCMNode: this is already inherited by FCMCommand and shows where it is included into other 'larger' compositions. The new 'implementingComposition' reference to FCMComposition can, as far as I can see looking at FCM, only be derived from the following list of reference navigations: FCMCommand.performedBy (giving FCMComponent); FCMComponent.instanceOf (giving FCMType); FCMType.compositionBinding (giving FCMCompositionBinding - however this is not navigable!); FCMCompositionBinding.composition (finally giving FCMComposition). An alternative route is to follow FCMCommand.invokes (giving FCMOperation); FCMOperation.type (giving FCMType though this is not navigable) and then navigating from FCMType as above. [One would hope that both navigation routes would give the same FCMType though this constraint is not documented in FCM, nor is any description provided there for FCMType!]. Resolution: Revised Text: Actions taken: June 12, 2002: received issue March 10, 2004: transferred to EDOC FTF Discussion: See discussion for issue 4865 End of Annotations:===== This is issue # 5363 Composite nodes: Derivation of implementingComposition Summary: Figure 6-4: The diagram is misleading and the actual derivation needed (which is hinted at under Constraint but should be more formally defined as in 6.2.4) would seem to rely on non-navigable references in the FCM metamodel: the new derived 'implementingComposition' association would not be based on the 'nodes' association shown between FCMComposition and FCMNode: this is already inherited by FCMCommand and shows where it is included into other 'larger' compositions. The new 'implementingComposition' reference to FCMComposition can, as far as I can see looking at FCM, only be derived from the following list of reference navigations: FCMCommand.performedBy (giving FCMComponent); FCMComponent.instanceOf (giving FCMType); FCMType.compositionBinding (giving FCMCompositionBinding - however this is not navigable!); FCMCompositionBinding.composition (finally giving FCMComposition). An alternative route is to follow FCMCommand.invokes (giving FCMOperation); FCMOperation.type (giving FCMType though this is not navigable) and then navigating from FCMType as above. [One would hope that both navigation routes would give the same FCMType though this constraint is not documented in FCM, nor is any description provided there for FCMType!]. Subject: [EAI FTF] New Vote time: Proposed transfer of all issues relating to EAI FTF Section 6.2 To: uml-eai-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Rob Phippen" Date: Thu, 24 Apr 2003 18:43:32 +0100 X-MIMETrack: Serialize by Router on D06ML022/06/M/IBM(Release 5.0.9a |January 7, 2002) at 24/04/2003 18:46:49 Dear FTFers, I propose to close all issues relating to "Section 6.2 FCM Derived Associations" of the UML for EAI spec. The issues I raised against the EDOC FTF (and the resolutions to them proposed by Barbara Price) cover the intent of this section, so I propose to reduce section 6.2 to a very brief description that just references the EDOC material. From an 'Issue Disposition' point of view, I am suggesting that we record these issues as 'Transferred to EDOC FTF' (which appears to be a permitted disposition). The issues covered are; 5384 5365 5364 5363 5362 4866 4867 Although the resolution to the EDOC issues has not yet been agreed by the EDOC FTF, I would like to initiate a vote on the 'Transferred' status of theses EAI Issues. Voting deadline: 0900 GMT Thursday 1st May 2003 Regards, Rob. __________________________ Rob Phippen Websphere Platform Messaging Hursley Park, UK Tel. +44 1962 816200 eMail phippen@uk.ibm.com __________________________