UML24 — Some associations in the normative XMI has one memberEnd

The problems regarding some associations with one memberEnd actually started in the "unmerged" model but show themselves in the "merged" model.

In 2.3, we added copy-down merge increments for some associations, in particular we added:

a- InternalStructures::A_feature_classifier (Figure 9.2) as a merge increment for Kernel::A_feature_featuringClassifier (Figure 7.10)
b- BasicComponents::A_role_connectorEnd (Figure 8.3) as a merge increment for InternlStructures::A_end_role (Figure 9.3)
c- BasicComponents::A_end_connector (Figure 8.3) as a merge increment for InternalStructures::A_end_connector (Figure 9.3)

The problem in (a) and (b) is that the merge-increment association has a different name than the original association, thus the package merge algorithm could not match them by name and they ended up both in the merged model. Since the navigable ends of those associations still have similar names, they were matched and merged in their respective Classes but their "association" references were set to the merge-increment associations, leaving the original association with only one reference in their "memberEnd" collections.

Trying to rename the merge increment associations in (a) and (b) similar to the original associations (by renaming the non-navigable ends and also switching the order of memberEnds references in (b)) and re-performing the package merge, the associations got matched up and only one association in each case ended up in the merged model, as expected. However, the merge algorithm could not merge the non-navigable ends of the merge increment associations with their corresponding navigable ends in the original associations (due to a bug in the algorithm implementation I think), which should have resulted in keeping only the navigable ends, so both ends showed up in the merged model and the "memberEnd" collections had 3 references. To fix that temporarily (until the bug is fixed), I manually deleted the extraneous non-navigable ends from the resulting associations in the merged model.

**These fixes affect Figures 9.2 and 8.3 to show the names of the non-naviagle ends

The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, I just had to put the "aggregation" and "multipclity" of the merge increment similar to the original.

As suggested by the issue, for cases (a) and (b), both the original and the copy down association need to have the same association names, same role names and same role navigability/ownership, in order for package merge to merge them into “one” association in the target package.
The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, the "aggregation" and "multiplicity" of the role in the merge increment association should be similar to the original.