Issue 4865: Use of Derived Associations (uml-edoc-ftf)
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity: 
Summary: Document: UML Profile and Interchange Models for EAI 
Section: 6.2.1 (Motivation) 

Description: 
The last paragraph of this section (beginning "Note that these derived associations...") is not entirely clear to me. I believe that the intent is the following:

Derived associations are included in the metamodel and result in corresponding generated elements in the DTD. However, derived associations can always be computed from other information in the metamodel. Therefore, a tool would not necessarily need to store derived associations internally, though it would effectively have to compute them if it generated XML for interchange.

Recommendation: 
Reword the paragraph along the lines of what I wrote above. Also, be sure, to include the appropriate constraint for every derived association to define how it can be computed.
Resolution: 
Revised Text: Section 6.2 to be replaced with the following text;>

6.2 FCM support for recursive composition
The UML profile for EDOC provides support for the definition of 'composite nodes', whose function is defined by an FCMComposition. The FCMNodes in an FCMComposition may themselves be conposite. Terminals on a composite FCMNode have an association with either an FCMSource or an FCMSink in the FCMComposition that defined an FCMCompositeNode. This is detailed in section x.x of the 'UML profile for EDOC' document number ad/xx-xx-xx

Actions taken:
February 20, 2002: received issue
March 10, 2004: rransferred to EDOC FTF
Discussion: 
This issue (and others relating to FCM derived associations) is transferred to EDOC as EDOC Issues 5441, 5442, 5443 and 5444. These issues require an explanation of the FCM mechanism for recursive composition. The result of this is that the content of section 6.2 of the EAI specification is now covered by revisions to the FCM Model described in the 'UML Profile for EDOC'. Section 6.2 is retained, but its complete text is replaced with a brief description referencing the revised sections of the "UML Profile for for EDOC" (document number adxx-xx-xx.
End of Annotations:=====
From: Edwin Seidewitz <eseidewitz@intelidata.com>
To: "'uml-eai-ftf@omg.org'" <uml-eai-ftf@omg.org>
Cc: "'issues@omg.org'" <issues@omg.org>, Jean Payne
     <jpayne@intelidata.com>,
   "Igor Teselko (E-mail)"
    <iteselko@homeaccount.com>
Subject: Issues on the UML for EAI Specification (2)
Date: Wed, 20 Feb 2002 17:15:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	      boundary="----_=_NextPart_001_01C1BA5C.20A8DE60"
X-UIDL: $QI!!Q<Od9<pMe9NgD!!
Status: RO


These are some issues from my own review of Chapter 6 (more to
come!). 


Issue: Use of Derived Associations 
Document: UML Profile and Interchange Models for EAI 
Section: 6.2.1 (Motivation) 

Description: 
The last paragraph of this section (beginning "Note that these derived
associations...") is not entirely clear to me. I believe that the
intent is the following:

Derived associations are included in the metamodel and result in
corresponding generated elements in the DTD. However, derived
associations can always be computed from other information in the
metamodel. Therefore, a tool would not necessarily need to store
derived associations internally, though it would effectively have to
compute them if it generated XML for interchange.

Recommendation: 
Reword the paragraph along the lines of what I wrote above. Also, be
sure, to include the appropriate constraint for every derived
association to define how it can be computed.

-