Color-Blind Specifications for Transformations of Reactive Synchronous Programs

Abstract

Abstract. Execution environments are used as specifications for specialization of input-output programs in the derivation of product lines. These environments, formalized as color-blind I/O-alternating transition systems, are tolerant to mutations in a given program's outputs. Execution environments enable new compiler optimizations, vastly exceeding usual reductions. We propose a notion of context-dependent refinement for I/O-alternating transition systems, which supports composition and hierarchical reuse. The framework is demonstrated by discussing adaptations to realistic design languages and by presenting an example of a product line.

Extending modal transition systems with structured labels

“…Moreover, the subspecifications S i (i = 1, 2) may have to specify behaviours that are not at all relevant in the context C. Again it seems that the above compositional analysis can be substantially harder than necessary. A more recent use of relativised bisimulation includes the use of environment information to produce environmentspecific (reduced) code from embedded system specifications (Larsen et al 2005) and to generate relevant test sequences from real-time specifications (Larsen et al 2004). Here, in order to reduce the overall effort, the observational equivalence ≡ is relativised with information about the context C. The required proofs I i ≡ S i can thus be replaced with proofs of the more specific I i ≡ e S i , where e is some partial information (stated as a labelled transition system) about the context C. Larsen and Milner (1987; applied the relativised bisimulation to the compositional verification of the Alternating Bit Protocol, and Pierce and Sangiorgi (2000) introduced a proof technique for polymorphic Pi-Calculus based on polymorphic types, which can be regarded as a 'disciplined instance' of relativised bisimulation.…”

Modal I/O Automata for Interface and Product Line Theories

“…The theory supports deciding whether given requirements can be satisfied by choosing concrete instances from the set of available assets. This theory, though very small, is to the best of our knowledge one of the very few attempts at describing software product lines in a behavioral fashion, and unlike the previous work [14], which takes a top-down approach to describing product families, it facilitates a bottom up construction of products, which is how product line development is more typically understood in the software engineering community. This contribution is not meant to be comprehensive, highly developed and well set in the tradition of the product line development.…”

Interface Input/Output Automata

“…It was so far applied in the setting of protocol verification [18], automatic testing [19] and modeling software product lines [7]. Here we adapt it to a language inclusion based refinement.…”

“…As we have also argued in [7] the separation supports a simple declarative style of modeling assumptions: simple properties can be modeled as standalone automata and combined using the process algebraic operators of sum and product, corresponding to disjunction and conjunction of properties respectively.…”

“…Thus the same guarantees can be used for multiple interfaces. In [7] we have argued that this is useful for modeling software product lines: a family of component variants may be specified using a single specification (guarantee) and multiple environmental restrictions (assumptions). An advanced compiler may use the assumptions to derive specialized versions of the component from the same source code.…”