Issue 1079: Association IDL generation needs to consider AssociationEnd.isChangeable (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The Association Template for IDL generation should consider the isChangeable attribute value of the AssociationEnd objects. For instance, the derived Association DependsOn should have no generated operations which could change the links. Adding a dependency through the association makes no sense. Since both association ends of that association are defined with isChangeable=false, the IDL generation rules should provide only query capabilities for that association. Resolution: closed, resolved Revised Text: Actions taken: March 18, 1998: received issue July 23, 1999: closed issue Discussion: Response: There are two separate issues here. 1. If an AssociationEnd has is_changeable=false, then: 1a. What operations should be present in the Association template (Section 7.3.6)? 1b. What operations should be present in a Reference template for this AssociationEnd or the other AssociationEnd (Section 7.3.8)? 2. Should derived Associations be update-able? Or should derived Associations be readon-ly? Or should we allow them to be defined explicitly as readonly or not? The semantics of is_changeable are somewhat difficult to understand (especially the way in which non-change-ability of one AssociationEnd seems to impact on the other Associa-tionEnd). We note that this approach was taken to maximise alignment with UML, but it does complicate the MOF semantics. Obviously, one option would be a clearer expression of the is_changeable semantics and the consequent IDL generation rules (including the generation rules for factory IDL). An alternative is to remove the concept of "is_changeable" from AssociationEnd and re-place it with an is_changeable attribute on Association. An Association with "is_changeable=false" would not generate any update operations for the Association or any Reference to its AssociationEnds. The only way that the links of the Association could be set/updated would be through the use of Operations on that Association. This would also enable derived Associations to be either readonly or not, depending on whether or not the mechanism for the derivation was information-losing (this is the old view-update problem). Possible courses of action on IDL issue: 1. Obtain a clearer expression of the intended M1 level semantics of is_changeable on AssociationEnds [action: UNISYS]. The appropriate options for the IDL genera-tion rules (including the generation rules for factory IDL) will then be apparent. 2. Move is_changeable from AssociationEnd to Association. An Association with is_changeable==false would not have any update operations for the Association or for any References to its AssociationEnds. The only way that the links of the Asso-ciation could be created or updated would be through the use of Operations. Possible courses of action on updateable derived Associations: 1. Require derived Associations to have is_changeable==false. 2. Allow the designer to specify updateable derived Associations if he believes that they are implementable given the intended derivation rules. (Note that these rules are not currently specifiable in the metamodel.) 1/12 : Washington1.If the Association_End called X has isChangeable==False, then the modify_X operation is the Association will be suppressed. If there is a reference coming from the other End, then the set_ReferenceName operation will be suppressed on the oth-er End 3. Derived Associations are READ ONLY and don’t have add, remove and modify op-erations suppressed. 4. Any references used in the Association will also have add, remove and modify op-erations suppressed. [Potential UML alignment issue - check the consistency rules in UML AssociationSeman-tics.] Following discussions with the UML RTF, the following points of agreement have been established. Consider the example of two Classes Man and Woman with an Assocation called Married with AssociationEnd husband (of type Man) and AssociationEnd wife (of type Woman). If AssociationEnd husband has is_changeable set to false, then it should not be possible us-ing the association object to add/remove husband-wife pairs nor to do a modify_husband operation (i.e. change the husband of a given wife). It is OK to do a modify_wife operation (i.e. change the wife of a given husband). Further it was agreed that the issue of changeability of the AssociationEnds and whether the Association is derived were orthogonal issues. It will still be possible to update derived associations (provided their AssociationEnds are changeable). Implementation: Added the requirement that both association ends must be change-able for the generation of the add operation, the add_before opera-tion( both templates), and the remove operation in Section 5.8.10, “Association Template,” on page 5-60. Added the requirement that the generation of the modify_<associationend1> operation requires associationend1 to be changeable and that the generation of the modify_<associationend2> operation requires associationend2 to be changeable in Section 5.8.10, “Association Template,” on page 5-60. Modified the texual description of the templates corre-spondingly in Section 5.8.10, “Association Template,” on page 5-60. Done [KR]. Text rewritten as part of resolution of #1502. Done. [SC] Implementation: There are consequential changes required to the MOF spec. The DependsOn Association has two roles, dependent and provider, both of which are not changeable. The add, modify_dependent, modify_provider, and remove operations have been suppressed in the DependsOn interface in Appendix B.1 “MOF IDL Summary” and in Section 3.5.9, “DependsOn,” on page 3-83. Done [KR] Implementation: Note the Reference required_elts in ModelElement is related to the DependsOn Association, but does not require any consequential changes as the update operations for References are always sup-pressed (note that there is currently a contraint that forces a Refer-ence to have the same changeability as its referencedEnd. Nothing to do [KR].Implementation: Added text to Section 5.3.3, “Association Access and Update Se-mantics for the IDL Mapping,” on page 5-11 to point out that an non-changeable end in a non-derived Association is brain-dead. Done [SC] End of Annotations:===== Return-Path: From: "Khalsa, GK" To: issues@omg.org, mof-rtf@omg.org Subject: MOF-RTF: Association IDL generation needs to consider Association End.isChangeable Date: Wed, 18 Mar 1998 12:17:55 -0600 The Association Template for IDL generation should consider the isChangeable attribute value of the AssociationEnd objects. For instance, the derived Association DependsOn should have no generated operations which could change the links. Adding a dependency through the association makes no sense. Since both association ends of that association are defined with isChangeable=false, the IDL generation rules should provide only query capabilities for that association.