Issue 1712: Navigability constraint expressed wrongly (mof-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: The "is_navigable" attribute on AssociationEnd is intended to allow a modeler to prevent the creation of References for the end. Unfortunately the Constraint that expresses this is on the AssociationEnd and the "is_navigable" attribute rather than on Reference. This means that the existence of References constrains the value of "is_navigable" rather than the other way around. Resolution: resolved and closed Revised Text: Actions taken: July 22, 1998: received issue July 23, 1999: closed issue Discussion: Status: Resolved, to be implemented. Washington: If isNavigable is set to false, then it is not possible to naviagate from otherEnd to thisEnd. This will suppress one of the with Operation in Association Interface and the ability to cre-ate references in the other end. This raises the issue that the 'WITH' operation of the Association Interface may be mis-named because the current operation name is based on input parameter not the result. Make WITH and MODIFY consistent. If an AssociationEnd called X has isNavigable set to false, then the with_X operation will be suppressed in the association interface AND no references may be created on the class at that AssociationEnd. Issue : Potential UML alignment issue 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 the husband AssociationEnd is not navigable, then it is not possible to navigate from a wife to her husband(s), but it is possible to navigate from a husband to his wife(s). There-fore, it is not possible to create a Reference for which husband is the referencedEnd (e.g. it is not possible to create a my_husbands Reference in the Woman class). Also, any opera-tion that must lookup the husbands of a wife must be suppressed. That is, the operations "with_wife" and "modify_husband" must be suppressed. It was also agreed that the "with_wife" operation is poorly named, and that calling it "husband" would be more logi-cal. That means, that if the "husband" AssociationEnd is not navigable, the "husband" and "modify_husband" operations are suppressed. Implementation: Replaced all the "with_<end1>" operations by "<end2>" opera-tions in Section 5.8.10, “Association Template,” on page 5-60, and reordered them so that the "<end1>" operation will appear before the "<end2>" operation. Updated the text describing this genera-tion in Section 5.8.10, “Association Template,” on page 5-60. Re-vised the following interfaces in Appendix B.1 “MOF IDL Summary”: AttachesTo, DependsOn, Contains, Generalizes, Alias-es, Constrains, CanRaise, Exposes, RefersTo, IsOfType. Propagat-ed these changes through to Section 3.5.1, “Contains,” on page 3-71, Section 3.5.2, “Generalizes,” on page 3-73, Section 3.5.3, “RefersTo,” on page 3-74, Section 3.5.4, “Exposes,” on page 3-76, Section 3.5.5, “IsOfType,” on page 3-78, Section 3.5.6, “CanRaise,” on page 3-79, Section 3.5.7, “Aliases,” on page 3-80, Section 3.5.8, “Constrains,” on page 3-81, Section 3.5.9, “DependsOn,” on page 3-83, Section 3.5.10, “At-tachesTo,” on page 3-85. Done [KR] Implementation: Revised the IDL generation rules in Section 5.8.10, “Association Template so that <associationend> operations (formerly "with_*" operations) and modify_<associationend> operations are only gen-erated if the association end is navigable. Done [KR] Implementation: There are no non-navigable association ends in the MOF model, so there are no changes required to the IDL in the MOF spec. [SC] Implementation: Revised the constraint on AssociationEnd to be a constraint on Ref-erence instead. See “ReferencedEndMustBeNavigable” on page 3-108. Done. [SC] Implementation: If association modify operations are suppressed for non-navigable ends, Don says that association add_before ops should be too. His reasoning is that you have to navigate (index?) the before end. Im-plemented this in Section 5.8.10, “Association Template,” on page 5-60, and Section 6.2.4, “Reflective::RefAssociation,” on page 6-25. Also rewrote the description of isNavigable in Section 3.4.17, “AssociationEnd,” on page 3-53, and Section 4.7.4, “AssociationEnd Navigability,” on page 4-16. [SC] Implementation: Documented what is happening with the UML diagrams where our convention is that an association with an arrowhead indicates that there is a reference: Section 3.2.7, “UML Diagrams,” on page 3-10. Also that all ends are navigable: “References” on page 3-5. Done. [SC] End of Annotations:===== Return-Path: To: mof-rtf@omg.org Subject: Navigability constraint expressed wrongly Date: Wed, 22 Jul 1998 16:40:27 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Minor The 'is_navigable' attribute on AssociationEnd is intended to allow a modeler to prevent the creation of References for the end. Unfortunately the Constraint that expresses this is on the AssociationEnd and the 'is_navigable' attribute rather than on Reference. This means that the existence of References constrains the value of 'is_navigable' rather than the other way around.