fix: allow Aggregation/Composition from Grouping/Location to Junction

[mvanhorn]

Summary

ArchiMate 3 Appendix B specifies that Grouping and Location may have Aggregation or Composition relationships to any concept, including Junctions. Archi blocked these when the target Junction already participated in other relationship types (e.g., Triggering), due to the Junction homogeneity constraint in ArchimateModelUtils.isValidRelationship.

Why this matters

Users modeling ArchiMate diagrams that include Grouping or Location elements structurally containing a Junction (e.g., grouping a flow pattern) received an incorrect "invalid relationship" error. The tool was non-compliant with the spec for this combination. Reported in #1229.

Changes

• ArchimateModelUtils.java: Add a bypass in the target-Junction homogeneity block (lines 94-107). When the source concept is IGrouping or ILocation and the relationship type is AggregationRelationship or CompositionRelationship, skip the Junction type-homogeneity loops and fall through to the RelationshipsMatrix check, which already permits these combinations per the ArchiMate 3 matrix.
• ArchimateModelUtilsTests.java: Add five JUnit tests covering Grouping/Location + Aggregation/Composition to a Junction with existing Triggering relationships (now valid), plus regression cases confirming Junction homogeneity is still enforced for regular elements and Junction-to-Junction relationships.

Fixes #1229

[Phillipus]

Thanks for this PR. Just so I know when I review it, I have to ask if any of the code submitted is AI generated and have you manually tested the changes in Archi?

[mvanhorn]

Hi @Phillipus, thanks for taking a look, and a fair question to ask.

Yes, this was written with AI assistance. I reviewed it and understand the change: it targets the Junction homogeneity check in isValidRelationship so a Grouping or Location can form an Aggregation/Composition to a Junction. Per ArchiMate 3 Appendix B those two source types may always use Aggregation/Composition to any concept, including a Junction, regardless of the relationship types the Junction already carries (the case in #1229). The bypass is scoped to exactly that combination - Grouping/Location as source with Aggregation or Composition - so all other Junction validation is unchanged.

On testing: I added four unit tests to ArchimateModelUtilsTests covering Grouping and Location with both Aggregation and Composition into a Junction that already holds a different relationship type, and the full model test suite passes locally (1386 tests). I also built the product and tested it manually in Archi: I created a Grouping plus a Junction that already had a Triggering relationship and confirmed an Aggregation from the Grouping to that Junction is now allowed in the UI.

[Phillipus]

@mvanhorn Thanks for the clarification. I ask because, ultimately, it's me that has to handle things if a regression or bug arises further down the line (unless the PR provider is prepared to fix it) and I need to understand the code in the PR.

One thing I found:

1. Add a Business Actor, a Junction and a Grouping to a View
2. Create an Assignment relationship from the BA to the Junction
3. Create a Composition relationship from the Grouping to the Junction

The above works as expected.

Now do it this way:

1. Add a Business Actor, a Junction and a Grouping to a View
2. Create a Composition relationship from the Grouping to the Junction
3. Try to create an Assignment relationship from the BA to the Junction - you can't, you can only create a Composition relationship

Is that expected behaviour?

[mvanhorn]

Good catch, and no - that's not expected behaviour, it was a bug in this PR. The Grouping composition bypassed the homogeneity check on the way in but still counted toward the Junction's relationship set, so creating it first blocked the ordinary Assignment. Fixed in 6de55f1: the homogeneity check now excludes bypassed Grouping/Location Aggregation/Composition relationships in both directions (shared predicate for both call sites), so your two orderings behave identically. I added a regression test for your exact scenario (Composition first, then Assignment). And to your broader point - yes, I'm prepared to fix issues that arise from this change down the line.

[Phillipus]

Hi, thanks for the changes. Could you please squash the two commits into one commit and rebase onto the latest master branch.

[mvanhorn]

Done - squashed to a single commit (a485ea3) and rebased onto latest master. The rebase was clean and the diff is unchanged from what you reviewed (verified with git patch-id).

[Phillipus]

Thanks, I'll take a look at it soon...