Keep diagram selection after dragging and record native port evidence
This commit is contained in:
@@ -71,7 +71,7 @@ RelationBody::PortAllocation {
|
||||
- Provided interfaces, required interfaces, function item contracts, component kind, and component orientation are separate facts. Keep provision/requirement roles visible and independently editable. Their union may describe potential carried items, but cannot prove role matching. New port-level provision/requirement relations use Component ports; participant-level relations retain their current meaning. Preserved relations on Legacy ports, or resolved function ports retaining `legacy`, remain visible compatibility declarations with warnings and do not replace function item contracts. Ordinary creation does not offer interface roles on function ports.
|
||||
- For a Standard connection, stored endpoint order does not establish provider/consumer roles. A required interface is satisfied by a partner-provided identical interface; R6 may also use its explicitly compatible interface specialization. Unsatisfied requirements are located completeness warnings. Never infer that Out provides or In requires: Operation call/reply direction is independent of those roles. Participant interface declarations are not silently inherited by every owned port.
|
||||
- At a component port with explicit provided/required interface declarations, carried items must fit their effective interface-item union using `item_satisfies`. Absence of declarations means unspecified compatibility and may warn; an explicitly empty interface does not accept arbitrary items. Do not manufacture interface relations to make a connection pass. Legacy uses its preserved interface association and the old item checks until resolved; after resolution that association is displayed as preserved/unclassified data and is not another active typed constraint.
|
||||
- `BoundaryExchange.oriented` is independent of port kind/orientation. New Standard connections default false; directional Flow connections default true. For oriented Flow endpoints, source must permit Out and target In. A known contradictory direction is an error; Unset warns. For an unoriented connection between Flow ports, at least one communication direction must be possible: In-only/In-only or Out-only/Out-only conflicts. Standard has no Flow direction. Mixed Standard/Flow connections warn that transport compatibility is unspecified; they do not assert an adapter.
|
||||
- `BoundaryExchange.oriented` is independent of port kind/orientation. New Standard connections default false; directional Flow connections default true. For oriented Flow endpoints, source must permit Out and target In. A known contradictory direction is an error; Unset warns. For an unoriented connection between Flow ports, at least one communication direction must be possible: In-only/In-only or Out-only/Out-only conflicts. Standard has no Flow direction. Typed Standard/Flow endpoints must have the same kind; mixed connections are structural errors. Preserved Legacy endpoints retain their explicit compatibility warnings. This follows the native Capella Component Exchange tool, which requires matching kinds; do not assert an implicit adapter.
|
||||
- A BoundaryExchange connects different participant owners. Typed component endpoints are SA-only. Preserved OA boundary exchanges retain Legacy participant endpoints and an explanatory compatibility warning.
|
||||
- PortAllocation is same-layer Component-to-typed-FunctionPort, unique per pair. Its function must have an actual work Allocation to the component owning the allocating port. A missing/contradictory allocation is an error for this new relation; the authoring action must resolve that work allocation first. Do not use computed allocation-summary nesting as evidence. Flow In permits input, Out output, InOut either, and Unset warns. Standard may allocate either direction. Multiple allocations are allowed when these invariants hold; no unsupported one-to-one cardinality is imposed.
|
||||
- A typed SA ExchangeAllocation requires both boundary endpoints to allocate the corresponding FE ports through explicit PortAllocation relations. An unoriented boundary can correspond in either stored order; an oriented boundary must correspond in its direction. The boundary item set must cover the allocated FE items using the same compatibility helper. Legacy exchange allocations retain prior owner/item checks and a warning that typed port allocation remains unresolved.
|
||||
|
||||
Reference in New Issue
Block a user