The problem statement: A Client subscribes to an output value property but does not know what computes it or how

A block Client has a reference to an abstract contract block I_A, which has an "output" value property o.

The Parametric diagram shows that value property o bound to the constraint property o with a BindingConnector o-o (which is named to make tracking of redefinitions easier) on a constraint property c of abstract type ConstraintA.

The aim of the game is to replace ("inject") various sub-blocks of I_A at run time that carry concrete variations with specific concrete constraint blocks compatible with ConstraintA.

The constraint {o=null} is merely a placeholder; concrete ConstraintBlock variants will have more constraint parameters and constraint equations that use them.

SysML constraint parameters have no intrinsic sense of input/output direction; it is only the binding of known (input) and unknown (output) value properties to the parameters that give them any sense of input/output, and this can vary for each binding usage context.

The SysML DirectedFeature approach for the value properties does not quite work here, it does not really make sense to have a reqd value property o on Client. For exasmple, what happens if it also depends on many "outputs" from many providers, all with the same value property name o?

One can use the UML derived property indicator '/'. However, when working with SysML Parametrics, this simple Webel Best Practice tip can really help:

You might be tempted to use an InterfaceBlock for I_A, noting that:

Sometimes this works well, however, it has some restrictions:

Taken literally, this would mean it can't have a composite constraint property. So an abstract block is used here for the contract I_A.