Expand flow specifications over feature group arrays 🤖

[lwrage]

Fixes #3113

Cause and correction

FlowSpecArrayExpander decided whether a flow specification end was an array element by testing
FeatureInstance.getIndex() on the end itself. A feature declared inside a feature group type is never
indexed — the index sits on the enclosing feature group instance — so an end reached through a feature
group that is an array looked like a scalar, the pairing was skipped, and every element but the first was
left without a flow specification instance. Nothing was reported.

ConnectionArrayExpander already treats an indexed enclosing feature group instance as a dimension of a
connection end, so the connection set covered every element while the flow specifications covered only
the first, and the end-to-end flows built over them inherited the disagreement.

The fix adds arrayEnd, which walks up from an end to the indexed feature instance — the end itself when
it is a feature array, the enclosing feature group instance otherwise — recording the features that lead
back down. The dimension size is the number of elements of that feature instance, and elementAt takes
the sibling with the paired-up index and follows the recorded features down again. A direct feature array
has an empty descent, so it behaves exactly as before.

At most one step of a path is ever indexed, because a feature declared inside a feature group type may not
be an array (AS5506D section 8 legality rule 3, enforced by the validator and reported by
InstantiateModel.instantiateFGFeatures). The nearest indexed ancestor is therefore the only one, which
the code and its javadoc state explicitly.

Nothing else needed changing. The pairing arithmetic in ArrayPatternExpansion does not care where an
index came from, and the end-to-end flows already fork over the flow specification instances of a
specification and keep a branch on its element by requiring the next connection instance to start exactly
at the previous element's destination feature instance.

Regression model and assertions

core/org.osate.core.tests/models/issue3113/Issue3113.aadl declares an array of feature groups on two
devices, a flow source and a flow path over it on one and a flow sink on the other, a feature group
connection that joins the two arrays, and an end-to-end flow over that connection. emit has one array
end and relay has two, which is the pairing the default One_To_One applies to.

Issue3113Test asserts:

• one flow specification instance per element, named and paired the way Flow specifications need to be able to reference features in a feature array #2787 established for an end that
  is a feature array itself: emit_1/emit_2, relay_1/relay_2, absorb_1/absorb_2;
• one end-to-end flow instance per element, ete_1 and ete_2, each over the connection instance of its
  own element;
• the four connection instances, alongside the flows, so the assertions show the two sides agreeing rather
  than a bare count;
• no diagnostics, so the silence is not traded for a warning.

Before the fix both tests failed with everything pinned to element 1: three flow specification instances
instead of six, and a single ete. The connection assertion passed before the fix, which is what
localizes the defect to the flow side.

Supporting change

Serializer1Test.testFlowSpecification recorded the old behavior for the one array feature group in its
fixture, so its f7 becomes f7_1 and f7_2. Its f6, an array declared inside a feature group type, is
still instantiated as a single feature and still a single flow. Folded into the fix commit so that every
commit on the branch is green.

Validation

• mvn -Dtest=Issue3113Test -DfailIfNoTests=false: 2/2 pass; both fail before the fix for the intended
  reason.
• Full org.osate.core.tests: 836 tests, 0 failures. Per-class non-zero counts confirmed for
  Issue2787Test (6), Issue1833Test (9), Issue3037ArrayFeatureGroupTest (7),
  Issue3037FeatureArrayTest (4), FlowSpecificationInstantiationTest (4),
  FeatureArrayInstantiationTest (3), FeatureGroupInstantiationTest (6), Issue3048Test, Issue3049Test.
• Clean root-reactor build, mvn -s releng/osate.releng/settings.xml -Plocal -Dtycho.localArtifacts=ignore -Dpr.build=true -Dsign=false -Dspotbugs=false -Dcodecoverage=false -Djavadoc=false -DfailIfNoTests=false clean install: BUILD SUCCESS, 2862 tests, 0 failures, 0 errors. Reproduced with -T6.

Dependencies

None. Branched from master at 7729ae9 and independent of the other open issue branches.

Residual risk

elementAt still falls back to the original end when a lookup misses, as it always did, so an internal
inconsistency would pin the element rather than fail. No diagnostic was added, to keep the fix narrow.

Nested feature group arrays are not a concern for the reason above: a feature inside a feature group type
may not be an array, so no path has two indexed steps. Note that ConnectionArrayExpander carries a single
fgidx and makes the same assumption.

🤖 Generated with Claude Code