Chapter 5 - Creating and Using Temporal Statechart Assertions

Abstract

There are numerous reasons for keeping assertions separate from the model, regardless of the language used to capture them. The reasons discussed in the chapter are—assertions as automated monitors, assertions in the context of statechart model changes, assertion reuse, nondeterministic assertions, early requirement simulation, and requirement tracking. Some assertions are conveniently described as nondeterministic statecharts. Nondeterminism provides a mechanism for creating simple and succinct assertions for rather complex requirements. Assertions can be applied in three ways—testing time assertions, simulation time assertions, and runtime assertions. There are three types of temporal contract assertions—temporal contracts concerning valid input sequences, temporal contracts concerning valid output sequences, and temporal contracts concerning valid input-to-output sequences. One of the reasons for having assertions separate from the statechart controller they are monitoring is assertion reuse, and therefore the value of assertion libraries, either for a single project, or perhaps universal. One of the two libraries is the Kansas State University (KSU) specification patterns library, known formally as the specification patterns for finite-state verification library. The other library, the StateRover, is a small, extendible library of both deterministic and nondeterministic state-chart assertions.