Paths with user-defined propagation points

[buzden]

User-defined propagation points can be used when our architectural model is not as precise as what we want to express with error model. So, we can consider three stages of expressiveness (in case when error model need to be not less expressive than architectural one):

• we use real features as propagation points -- when both architecture and error model have enough;
• we use internal ports -- when architectural model needs to express one side of something partially modelled; and error model needs too;
• we use user-defined propagation points -- when architectural model does not contain anything related, but error model needs something.

But there is some little inconsistency in expressiveness when we moving between these three cases.

In particular, user-defined propagation point requires to have some containing subcomponent in propagation path. qualified_propagation_point grammar rule has subcomponent_identifier with +, not with *.

This disallows us to model a situation where e.g. we have propagations from our subcomponents to something not modelled in architectural model (as if it was modelled with "incoming" internal port but when we don't have an ability to have it).

We always can have a d̶i̶r̶t̶y̶ ̶h̶a̶c̶k workaround by putting our error model to the one more container system, but this implies additional unwanted architecture change and lots of boilerplate code.

So, what we suggest is to have an arbitrary (starting from zero) count of subcomponent_identifier (i.e., to have * instead of +) in the qualified_propagation_point rule in the error model annex.

[reteprelief]

Agreed that user-defined propagation path should be able to go from/to a propagation point to one inside a (nested) subcomponent. Also you want to be able to have one end be a real error propagation while the other is a user defined propagation point (see #40 ). Interesting that I have a comment about this in the Word document of EMV2 but could not find a record in the issues.

[jjhugues]

At this stage, there is no strong demand for that capability. We defer to v3 topics