Conjugated Ports and Connector Direction in a Satellite Payload Controller

The failure is a direction error, not a code-generator bug. A port typed by an interface normally provides that interface to its owner's environment; setting isConjugated = true reverses the effective provided and required sets. By conjugating the ThermalUnit part's port, the modeler made ThermalUnit a consumer of IPower rather than a provider. The assembly connector then joins two ports whose effective directions are both 'required', so the generator correctly emitted a constructor asking for an IPower instance. The textual validator only checks type compatibility between port types; it does not enforce required-to-provided direction, which is why the model passed. The fix is to leave the ThermalUnit port non-conjugated (provides IPower) and put conjugation only on the port whose owner genuinely needs the interface. If the controller needs power, conjugate the controller-side port, or type it with the conjugate interface. Add a validation rule or model review checklist that every assembly connector joins exactly one effectively-provided end to one effectively-required end, and treat 'conjugation is cosmetic' as a false assumption to correct in the team's modeling guide.

Define direction relative to the owning classifier, not relative to the drawing. Convention: a port that the owner provides is non-conjugated and typed by the service interface; a port that the owner needs is conjugated and typed by the same interface. Thus ThermalUnit has a non-conjugated IPower port, and PayloadController has a conjugated IPower port if it consumes power. For delegation, connect the outer conjugated port to the internal part's non-conjugated port; for assembly, connect a conjugated port on one part to a non-conjugated port on another. Document the mapping explicitly: non-conjugated port becomes a provided interface in generated metadata; conjugated port becomes a required constructor parameter or injected dependency. Because the two generators may interpret conjugation differently, add a generator-independent test model with one provided and one required port, run both code generators in continuous integration, and compare the emitted signatures. Do not rely on connector geometry to infer direction; connectors express wiring, while the port's effective interface set expresses contract. This convention also avoids accidental double conjugation, which silently turns a provider into a consumer.

Unspecified navigability is not a synonym for bidirectional. In UML 2.5 an end with unspecified navigability gives no commitment about traversal, so a generator may emit no reference, one reference, or a tool-specific default; that ambiguity is unacceptable when the multiplicity is 1..4. Make the direction explicit: mark the end owned by PayloadController navigable with multiplicity 1..4, and mark the ThermalUnit end non-navigable unless thermal units genuinely need back-pointers. For the DataLink connector, both ends navigable is legal but generates mutual references, which complicates serialization, lifecycle, and garbage collection and can create a cycle in the object graph. If DataLink is a shared bus, model it as a separate part with two directed associations or a shared aggregation rather than a bidirectional connector. If the link itself carries attributes such as link status or latency, reify it as an association class or a full class, because a plain connector cannot own those values. Reserve bidirectional navigability for cases where both directions are part of the contract and the team accepts the referential-integrity cost.