Consistency rule in error propagation section: All features must have a propagation or containment declaration

[buzden]

Well, this rule definitely looks nice for full and completely EMV-annotated models. But there are two points against.

---

One of the points arises in a situation when model in not complete. There are two cases, one of them is rather simple, another is more or less complicated.

Simple case: we completely don't know yet

In this case, we can consider that we have a component for which we completely haven't decided yet whether this or that feature can be used for propagation and containment of an error. This still allows us to perform different kinds of analyses:

• those which does not involve underspecified feature/component at all or
• which work with particular error types which definitely does not affect this feature (e.g. which is contained in all components connected to this feature).

So it means that if your consistency rule is present, it won't allow us to use incomplete models for nevertheless reasonable analysis.

More complicated case: partial decisions

Another case considering which we can think that this rule is not so good (as it is, at least) is the following.

Consider we are designing some component and its error model. For instance, we have decided that some feature would definitely accept some incoming propagation of error E1 and that it would definitely not accept any incoming propagation of error E2. And consider that we are completely uncertain about other types of error propagations yet. The question is how can we write this decision to the model? There are at least three variants:

• we can write down in-propagation of E1 and non-acceptance of E2 as an obligatory declaration (according to the proposed rule); but this would leave an uncertainty (that we've raised about a year ago in the mailing-list, actually), i.e. the current standard does not have particular semantics and interpretation for this case, so different analyzers can interpret this situation
  • as an error,
  • in a pessimistic or
  • in an optimistic way,
  • or whatever they like;
• we can leave this feature without any declaration (yet) and leave a comment that when model would be complete, this feature must have a propagation for E1 and rejection for E2; the problem here is that we cannot perform analysis until model would be completed;
• we can invent special syntax or special semantics rule that gives explicit uncertainty about propagations of particular features; this syntax or rule both declares that the model is explicitly incomplete but allows to perform analysis (for kinds of analyses that support such incomplete models, of course); then the topicstarter rule seems to make sense in conjunction with ability to explicitly set up uncertainty.

---

There is another point regarding to the topic and it is a boilerplate specification code. When I have for instance several tens of features (for instance, 32-port switch from some AADL-library), this rule makes me write something on features even if they're not used in my model. This looks like an annoying boilerplate. In this case it would probably better to consider nicer semantic rules for defaults (i.e. for cases when no propagation declaration exists) instead of inventing a consistency rule that obligates everyone to write a lot of dummy specifications.

[jjhugues]

This issue has not been reported as discussed. At this stage I prefer to close it