Non-specified reception

Course notes for ELG-7187C

What we call non-specifed message reception is a special case of what UML calls "unexpected event reception" which is recognized as a semantic variation point in UML: "The interpretation of the reception of an event in an unexpected situation (current state, state invariant, and pre-condition) is a semantic variation point: the event can be ignored, rejected, or deferred; an exception can be raised; or the application can stop on an error. It corresponds semantically to a pre-condition violation, for which no predefined behavior is defined in UML."

Semantic variation point means that different semantic interpretations are possible (as indicated in the quote above). We consider here the following interpretations:

1. Input is dropped (ignored): This is the semantics of SDL.
2. Complete behavior for all inputs: One assumes that the behavior specification foresees a transition for all inputs in all states. Or it is implicitely assumed that the originally given behavior is extended ("completed") by introducing a transition for all situations that are non-specified. For this completed specification, there will be no non-specified reception. In most cases, one assumes that the behavior is extended by adding an "error" state, and the transitions corresponding to the inputs that were non-specified in the original specification will lead to this errors state. In the error state, all inputs will lead back to this error state.
3. Undefined behavior: The behavior of the described component is not defined in response to the reception of a non-specified message. This means that an arbitrary behavior is allowed in these cases. It corresponds to a "don't care" situation in the specification of hardware designs. The occurrence of a non-specified reception during reachability analysis implies that there is a design error, either in the behavior of the specified component, or in the behavior of its environment.
• If the behavior of a machine in some state is not defined for some particular input, one says that the machine is partially specified.
• The fact that no transition is defined in some state for some particular input may mean that the system may make the assumption that the environment will not send this input when the system is in this state (see requirements with assumptions and guarantees).
• The interpretation of "undefined behavior" is best compatible with object-oriented inheritance and conformance relations between more abstract and more detailed descriptions.
4. Input is deferred and placed in a buffer pool: As discussed here, it is assumed that the message will not be consumed in this state of the specified component, but left in an input buffer ("saved" in the single input queue of SDL, stored in one of several input queues, or placed in a general message pool) from where it it can be consumed when the state has changed appropriately.

In the past, interpretation (3) has been my favorite, because it allows step-wise refinement of behavior specifications with proper inheritance, where all properties of a given partially specified behavior remain valid for any new specification which is obtained from the former by introducing additional transitions to resolve some of the non-specified reception situations. We will discuss this further in the chapter on "comparing specifications". More recently, I have been using interpretation (4) in the context of "deriving protocols" (see later chapter). Interpretation (2) is sometimes useful for analyzing the composition of behaviors - the possibility that one of the behavior may reach its error state is equivalent to the presence of a non-specified reception when the non-completed behaviors are considered.