ST6RI-907: Cannot correctly render nested inherited connections with SHOWINHERITED style (PlantUML)

[himi]

The model below could not be rendered correctly with SHOWINHERITED. This is caused by the inappropriate matching against inherited feature, in this case a0. The current code wrongly assumes the first feature of feature chains directly inherited and fails to find a nested feature.

package TestInheritFlow1 {
    part p0 {
        action a0 {
            action a1 {
                out o1;
            }
            action a2 {
                in i1;
            }
            flow f1 from a1.o1 to a2.i1;
        }
    }
    part p1 :> p0;
}

[himi]

After this fix, it is correctly rendered as:

[himi]

I also found that in the model below, the flow ends of f21 redefines the feature of f1 instead of a11.output or a12.input.
More specifically, for example, f21.a11.output :>> f1.a11.output instead of f21.a11.output :>> a1.a11.output (these notations are not so correct because f1 itself does not own output feature, rather the end of f1 owns it).

So I traced the chain of the redefined features to find out the root redefined features to find out source and target.

package TestInheritFlow2 {
    action a1 {
        action a11 {
            out output;
        }
        flow f1 from a11.output to a12.input;
        action a12 {
            in input;
        }
    }
    action a2 :> a1 {
        flow f21 :>> f1 from a11.output to a12.input;
    }
}

[seidewitz]

I also found that in the model below, the flow ends of f21 redefines the feature of f1 instead of a11.output or a12.input.

The flow ends of f21 redefine the ends of f1, because that is always the case with end features of a specialized connection. The two flow ends of f21 reference subset a11 and a12, respectively, because the flow is a connector from a11 to a12 (the same as f1). This is the way it has always been. (For details, see KerML 8.4.4.6.1 on connectors and KerML 8.4.4.10.2 and SysML 8.4.12.2 on flows.)

[himi]

@seidewitz thank you for the explanation. I read KerML 8.4.4.10.2 to understand the rule but I could only found the phrase.

The textual notation for a Flow, of the form

flow of i : T from f1.f1_out to f2.f2_in;

is parsed with i : T as a PayloadFeature and having two FlowEnds, one referencing f1 with an owned Feature redefining f1_out ...

So I interpreted this implies f1_out here is the redefined flow's f1_out if the flow redefines a flow. Is that the correct? That means in the example above, in Flow f21, the redefined output must be f1's output instead of a11's output. Actually, I did not know that is the rule.

BTW, I confirmed it also implicitly redefines Transfers::Transfer::source::sourceOutput as the standard specifies.

[seidewitz]

So I interpreted this implies f1_out here is the redefined flow's f1_out if the flow redefines a flow. Is that the correct? That means in the example above, in Flow f21, the redefined output must be f1's output instead of a11's output. Actually, I did not know that is the rule.

That is not really what it says in what you quoted from the specification. What the spec says is that the FlowEnd has an owned Feature redefining f1_out. It doesn't say actually anything about what happens if the flow itself redefines another flow. However, a redefinition of these nested features kind of happens anyway due to the implied redefinitions of sourceOutput and targetInput.

In your example, the redefined flow f1 is parsed like (with implied specializations added):

flow f1 subsets Flows::flows {
    // First FlowEnd
    end references a11 redefines Flows::flows::source {
        out redefines a11::output, Transfers::Transfer::source::sourceOutput;
    }
    // Second FlowEnd
    end references a12 redefines Flows::flows::target {
        in redefines  a12::input, Transfers::Transfer::target::targetInput;
    }
}

The redefining flow is then parsed like:

flow f2 redefines a1::f1 {
    // First FlowEnd
    end references a11 redefines a1::f1::source {
        out redefines a11::output, Transfers::Transfer::source::sourceOutput;
    }
    // Second FlowEnd
    end references a12 redefines a1::f1::target {
        in redefines  a12::input, Transfers::Transfer::target::targetInput;
    }
}

Because of the checkFeatureEndRedefinition constraint, the ends of f2 redefine the ends of f1. The features nested in the two ends (output and input, respectively) don't explicitly redefine the corresponding nested features from the ends of f1. However, the corresponding nested features both redefine the same ancestor feature (sourceOutput or targetInput). As a result, by the semantics of redefinition, the nested feature f2::source::output effectively redefines f1::source::output (and, in fact, f1::source::output is therefore not inherited), and similarly for f1::target::input.

This was a particularly subtle aspect of redefinition that we had to carefully work out when we formalized the computation of inherited memberships!