Reward Interfaces
with Best-Effort Implementations
Abstract
Interface theories, notably interface automata, serve as expressive frameworks for component-based design, specifying component behavior and interaction in concurrent systems. Traditional interface formalisms specify assumptions that a component’s environment must satisfy and the guarantees that each component provides. This qualitative view of component interaction based on imposing strict assumptions and Boolean guarantees may, however, not be expressive enough to capture the system’s allowed or desired behaviors under different environments.
In this paper, we introduce reward interfaces to support component-based design while accommodating multi-valued correctness requirements and adaptive best-effort satisfaction of component’s guarantees. Building upon interface automata, our framework enables modeling a rich class of quantitative component specifications. We propose formal notions of implementation, refinement and compatibility for reward interfaces. We study a class of reward interfaces with automata-based representations, for which we provide algorithms for checking compatibility and refinement, and existence of best-effort implementations. Our framework offers a comprehensive approach to reward interface specification and design.
Keywords and phrases:
Component-based design, interface automata, quantitative specificationsCopyright and License:
2012 ACM Subject Classification:
Theory of computation Formal languages and automata theoryEditors:
Stefano Guerrini and Barbara KönigSeries and Publisher:
Leibniz International Proceedings in Informatics, Schloss Dagstuhl – Leibniz-Zentrum für Informatik
1 Introduction
In system design and analysis, component-based techniques are essential for managing the increasing size and complexity of modern systems. Specification theories, particularly those based on interfaces or contracts [3, 9, 14], provide structured frameworks to address the challenges posed by concurrent systems. Interface theories [15, 18, 10] are especially suited for expressing interactions and dependencies of subsystems, offering formal specifications for analysis and verification. Here, each component is modeled by an interface, enabling a modular, independent design process, while ensuring compatibility between components.
One well-studied formalism are automata-based stateful interfaces, building on de Alfaro and Henzinger’s seminal work on interface automata [14]. They model components with distinct input and output actions, synchronizing with other components. Key properties are compatibility, which allows abstraction of multiple components into a single subsystem, and refinement, which supports independent component implementation. Interface automata have been extended to express more complex system behaviors. For example, resource interfaces [6] handle quantitative aspects like resource usage, while modal interfaces [20, 23, 21] capture richer properties such as liveness, expanding the expressivity of the framework. Further extensions [25, 24] incorporate state-based contracts, which enables concepts like shared memory in interface theories. A core motivation for interface theories is to simplify the design process by relieving designers from defining responses for every possible input. Typically, interfaces adopt an optimistic stance, allowing components to assume specific behavior from their environment. Inputs are either allowed or disallowed, with no obligation to handle disallowed inputs. This assumption holds as long as the system is closed, meaning all inputs come from other components. However, for open systems, where external inputs are beyond our control, these strong assumptions must be reconsidered.
We introduce a novel approach of reward interfaces, building on interface automata, that aims to enhance the design process while accommodating an unrestricted external environment. Central to our approach is the concept of good-enough satisfaction, based on the idea of good-enough synthesis [2], which says satisfaction of requirements is only necessary under feasible input conditions. This notion enables designers to focus on essential aspects of system behavior, removing the task of considering more explicit environment restrictions. It also naturally lends itself to the quantitative domain, introducing an additional direction in expressing complex properties to interface specifications, such as graceful degradation.
We consider an automaton structure coupled with a multi-valued reward function, defined over sequences of inputs and outputs of the interface, and require best-effort satisfaction from its implementation. While this generally loosens obligations, it selects for high-quality implementations if they exist. The interface automaton provides strict assumptions and guarantees, but is limited to safety properties. The reward function is more flexible, and able to express a substantial class of properties including liveness. This keeps the automaton simple and interpretable, offloading complicated requirements to the function without obscuring essential interaction restrictions. Our approach allows designers to succinctly capture complex system behaviors, which we illustrate below using a simple example.
Example 1.
Suppose we want to design a message distribution system . The system can receive messages and should relay the received messages in the respective order via the output actions and . The system is limited in that it cannot produce an output while receiving an input, and it cannot send more than one output at a time. If the system has to handle both and during an execution, this will consume more resources.
Formally, is modeled via the input actions , controlled by the external environment, and output actions , and , with the following requirements: Once occurs, then must output , and once occurs, must output . If both inputs are received, then and must be produced in the same order. must not perform actions , before or , respectively, has happened. The additional output is unconstrained by the specification.
The specification of is formalized as a reward function which maps the possible execution traces of to numerical values reflecting the extent to which the requirements are satisfied. Concretely, maps (possibly infinite) sequences over the alphabet to values .
Executions where occurs after an , and no input is received, are awarded the maximum value of . The same value is assigned to executions where the only input is , and occurs after. If both and occur, and both and occur in the respective order, the achieved value will be . This represents the more demanding input behavior from the environment, abstracting a lowered efficiency, and is not a penalty on the system. The value is lowered to if the order is reversed. Executions where an input is erroneously or not at all relayed are assigned value , violating the specification. We also give value to sequences without any input, or an infinite sequence of inputs, as the system would be unable to produce output if continuously receiving inputs from the environment.
Since the inputs are under the control of the environment, the system cannot force them to occur. This means that no implementation of can guarantee positive satisfaction of . A more realistic requirement is to ask to achieve the maximal satisfaction value possible for each sequence of input actions produced by the environment. In this best-effort view, the obligations on depend on the input provided by the environment. Thus, if the environment does not provide with an input, is not expected to achieve value higher than . Formally, we identify the so called -hopeful input sequences, which allow for achieving satisfaction value . Here, for these are the sequences of the form or .
Suppose that internally, is to be designed as the composition of two components and . Component is responsible for producing the output , and component for outputs . This is expressed via the interface automata and modeling the allowed interactions of and , as depicted in Figure 1. and synchronize on actions , , and operate independently otherwise. They can enable each other to produce outputs .
However, interface automata alone are unable to capture the quantitative requirement expressed via the function . The modeling framework of reward interfaces that we propose in this paper addresses this limitation. Reward interfaces equip interface automata with reward functions to capture the quantitative specifications that components must satisfy. In the coming sections, we will see how reward interfaces for and model local quantitative specifications such that their combination captures the high-level specification .
As Example 1 shows, our framework offers an elegant way to describe systems of interacting components. Our reward interfaces build directly on interface automata, adding expressivity through the reward function without necessarily making the automata more complex.
We introduce the formal definition of reward interfaces in Section 3, and define reward functions in a general way to maintain a high degree of flexibility. The notions of compatibility and refinement on reward interfaces are defined in Section 4 and Section 5 respectively, and we show that these entail desirable properties of interfaces. In Section 6 we provide a collection of algorithmic solutions for assessing these properties for a specific class of interfaces. Concretely, we consider reward functions with finite range that are represented as automata. For brevity, some of the missing proofs are presented in full in the appendix.
2 Preliminaries
In this section, we introduce necessary notation and preliminaries. Further, we recall and adapt the definition of interface automata and related notions from [14].
Languages and Automata
For an alphabet , the set contains all finite and infinite words over . Given a sequence , we denote with the projection of to , that is, is the sequence obtained from by removing all letters in . For a sequence , we denote with the letter of at the -th position.
A non-deterministic finite automaton (NFA) over an alphabet is a tuple with finite set of states , initial states , transition relation , and a set of accepting states . A run of on a finite word is a finite sequence such that and for every , it holds that . A run is accepting if and only if . A non-deterministic Büchi automaton (NBA) on infinite words instead has a set of Büchi-accepting states of which some must be visited infinitely often. A run of on is defined analogously, and is accepting if and only if for every there exists such that . The language of an automaton is the set of words on which has an accepting run. For a universal co-Büchi automaton (UCW) , a run of on a word is accepting if and only if there exists such that for all , , and is only accepted by if every run is accepting. We define the size of an automaton as the total number of states and transitions, i.e. .
We use to denote the set of real numbers, and define as the elements where for all . The set then contains the real numbers and . We define conventionally the infimum over the empty set as .
Interface Automata
Interface automata [14] are a modeling formalism for specifying the interactions between components and their environment. Components communicate via synchronization on input and output actions. In contrast to the interface automata in [14], we distinguish external inputs , which are external to the overall system and broadcast to all components, from inputs that come from system components outside of and are subject to assumptions specified by . The external inputs enable synchronization between multiple components on the same input action, and are used to model behavior uncontrollable by the system.
Definition 2 (Interface Automaton (adapted from [14])).
An interface automaton is a tuple where:
-
is a finite set of states and is a set of initial states. We require that contains at most one state. If , then is called empty.
-
are mutually disjoint finite sets of input, output, external input and internal actions respectively. Let be the set of all actions of .
-
is a set of transitions such that for every state it holds that:
-
–
for every external input action , there exists such that ;
-
–
for all and with and we have .
-
–
Note that we require to be input enabled on external input actions , i.e., it accommodates any external input in every state. We also require that is input-deterministic on , in order to ensure compositionality of parallel composition [15].
We define the size of as . For , we define the interface automaton obtained from by replacing the set of initial states by .
Let be an interface automaton. An execution of is an alternating sequence of states and actions such that for all . An execution fragment is a finite prefix of an execution ending in a state. A state is reachable in if there exists an execution fragment starting in some that ends in . We denote with the set of states reachable in . For , let be the set of actions from enabled in state .
Two key notions in the theory of interface automata are the composability and product of automata. Whether two interface automata are composable depends on their actions. They must not share input, output and internal actions, but may have joint external inputs. For two composable interface automata, we can construct their product. This is formalized in the definitions below. For the remainder of this section, let and be interface automata.
Definition 3 (Composability [14]).
Two interface automata and are composable if , , , and .
We define , and denote with the set of joint external inputs of and .
Definition 4 (Product).
Let and be composable. Their product is the interface automaton with the components defined as follows:
-
, ,
-
,
-
Note that the actions become internal actions of , and and must synchronize on shared and joint external input actions.
Given two composable interface automata and , a product state is called an illegal state of the product automaton if and only if there exists such that . That is, illegal states are ones in which a shared action can be produced as an output of one of the interface automata but is not allowed as an input by the other one. Let be the set of illegal states of .
We say that two interface automata and are compatible if there exists a way for the rest of the system, supplying the inputs to ensure that illegal states are avoided. This gives rise to the notion of legal environment for and , which we recall next.
Definition 5 (Legal Environment and Compatibility[14]).
A legal environment for is a non-empty interface automaton where:
-
1.
, , , .
-
2.
is composable with , and .
-
3.
.
Two interface automata and are considered compatible if they are non-empty, composable and there exists a legal environment for .
Intuitively, a legal environment for represents the remaining system beyond and . Condition 3 requires that the inputs provided by to the two interfaces steer them away from illegal states in the product.
Definition 6 (Composition of Interface Automata[14]).
Given composable interface automata and , a product state is called compatible if there exists a legal environment for . Let be the set of compatible product states. The composition of and is defined by restricting to . Formally, .
Intuitively, the compatible product states are those from which an environment can prevent reaching illegal states. Thus, and are compatible if and only if . Furthermore, for every , all the external input actions lead to product sates in . If this was not the case, would not be in , since an external input action leading to an illegal state cannot be prevented by a legal environment. If an action leads from to , we prune all -transitions from . Therefore, for compatible interface automata, the composition is a non-empty interface automaton conforming to Definition 2.
Another concept, crucial for independent implementability of interfaces, is refinement. Refinement of interface automata [14] is defined via alternating simulation, recalled below.
For an interface automaton and state , let be the set of states of that can be reached from using only internal actions from . We define:
to be the sets of externally enabled input and output actions at . Further, for actions , let .
Definition 7 (Alternating Simulation [14]).
A binary relation is an alternating simulation from the interface automaton to the interface automaton if for all and , implies that:
-
1.
and .
-
2.
For all and , there exists a state such that .
The existence of an alternating simulation from to guarantees that the interactions of are preserved in . In particular, does not impose more assumptions on the environment than , and satisfies all the output restrictions of . That is, any environment compatible with also is compatible with .
Definition 8 (Interface Automata Refinement [14]).
For interface automata and , we say that refines , written , if and only if , , , and there exists an alternating simulation from to , and states and , such that .
Thus, the relation guarantees that must accept at least all inputs , and may not add any new outputs w.r.t. . The alternating simulation ensures that for any input, the outward behavior of matches that of .
3 Reward Interfaces
We now introduce reward interfaces, the central notion of the framework we propose. They build on the classical interface automata, extending them with an additional quantitative requirement, defined as a reward function that assigns numerical values to sequences of observable actions of the interface. Essentially, a reward function defines a quantitative language [8] over the alphabet of non-internal actions of the given interface automaton.
Definition 9 (Reward Interface).
A reward interface is a pair where is an interface automaton and is a partial function that assigns a value from to sequences over the alphabet of non-internal actions of .
Intuitively, expresses a quantitative specification, by associating reward values with sequences in . The reward value of a sequence describes how well the respective observed behavior satisfies the quantitative requirement. Since is part of the interface specification, it is defined in terms of the actions that are visible to the component’s environment. We deliberately do not impose further restrictions on the functions , in order to retain full generality of the proposed framework. In Section 6 we discuss possible instantiations, in which the reward functions have a natural finite representation.
Example 10.
Continuing from Example 1, we show a possible reward interface for component . The restrictions from (Figure 1(a)) ensure that output can only occur after input . The requirement that must occur after , and not before, is modeled via the reward function , mapping sequences over to values. The reward function follows : We award value if only one type of input or occurs, and require respectively and , instead of , as has no knowledge nor control over . Similarly, if both and occur, the order of and must reflect that to achieve value , otherwise the value is lowered to . In both cases when occurs, and should not be performed infinitely, otherwise the assigned value is .
Note that while we could for example encode the safety requirement that there is no before the first occurrence of as part of the interface automaton, it would make the automaton structure more complicated. Furthermore, as the internal order of and is less relevant for the interaction with component , which is not concerned with , it is more meaningful to capture that in the reward function rather than .
A reward function for a reward interface is defined analogously.
For and , we define to be the set of words which maps to some value . When we write , we implicitly mean that is defined. We define .
Let us fix an interface automaton for the rest of this section. To evaluate implementations of an interface, we define the set of traces of as
That is, is the set that consists of the infinite words over for which there exists an infinite execution, as well as the finite words over where an execution ends in a state with no output or internal action possible. That is, we consider maximal traces, taking into account that the environment inputs are not forced to occur.
For a given input sequence , we define to be the subset of containing the words consistent with . These words represent all possible behaviors of when the environment provides the inputs specified by . If is an alphabet such that , we define to be the projection of on .
Reward functions impose no assumptions on the environment of a component. However, the value that a component can possibly achieve may depend on the behaviour of the environment. Therefore, we require that components implementing a reward interface satisfy the quantitative specification to the best extent possible with respect to the input provided by the component’s environment. This intuition is formalized by the good-enough criterion for interface automata (also used to model implementations).
First, we adapt to our setting the notion of hopeful sequences [2], which is used to characterize the input sequences for which a given reward value is possible. Note that in our setting, we consider asynchronous executions, such that there can be several consecutive inputs with no output in-between, or such that from some point on we only have outputs. This is in contrast to hopeful inputs in [2], which are defined for synchronous executions. We also allow arbitrary hidden actions, which may interleave with the non-internal actions.
Definition 11 (Hopeful Sequences).
Given alphabets and such that , a function and , we say that a sequence is -hopeful if and only if there exists such that , is defined, and . We denote the set of -hopeful -sequences by
We use here to denote a subset of , which will typically be instantiated to be a subset of the inputs , as we will see in the following definition. This notion describes the potential quality of the environment, characterizing the inputs to an interface as hopeful with respect only to specific values of . The hopefulness of an input sequence does not depend on the interface automaton itself, but only on the reward function . An interface automaton is good-enough with respect to a reward function , if, intuitively, the traces it generates on any -hopeful input sequence achieve reward at least .
Definition 12 (Good-Enough Interface Automaton).
Consider an interface automaton and a reward function . We say that is good-enough with respect to if and only if for every value , every input sequence , and every it holds that is defined and .
This definition is in the spirit of [2], as a good-enough interface automaton must perform to the best extent possible according to , but only for the input it receives. In Definition 12 we used a general alphabet . This is useful for the definition of compatibility of reward interfaces with respect to a given reward function.
Now we define the notion of (best-effort) implementation of a reward interface, which must be good-enough with respect the interface’s reward function.
Definition 13 (Best-Effort Implementation).
An interface automaton is an implementation of a reward interface if and only if it satisfies the following conditions.
-
1.
refines the interface automaton .
-
2.
is good-enough with respect to the function .
We denote with the set of all implementations of .
An implementation of a reward interface is an instance of a classical interface automaton, as it does not have a reward function. In the original theory, there is no distinction between an interface and its implementation, as the interface is defined by the automaton structure alone. When considering an interface in isolation, the external inputs and inputs are treated in the same way. However, we differentiate between the two when considering the interface in the context of rest of the system, which generates the inputs .
Example 14.
Let us examine how a best-effort implementation for could act. With respect to the reward function from Example 10, a possible implementation for waits for or , and then expects input to follow with , or produces output , respectively. We give a portion of the respective implementation in Figure 2(a), for the behaviors where occurs first. The missing part has analogous structure for the case when is received first.
As the implementation must not perform unless was received, it waits until happens. Should never appear, has no obligation to perform . This is because, even though does not require , Definition 12 considers the traces of , where must be read before can be produced. While is unable to control or observe , it exercises control by withholding until , which is represented in , and therefore in implementation . If instead, the implementation could immediately produce , the value for would be lower since it could be that no occurred.
4 Compatibility and Composition of Reward Interfaces
In this section, we lift the notions of interface compatibility and composition to reward interfaces. Following the classical interface theory, compatibility of reward interfaces requires the existence of a legal environment for the underlying interface automata. For the quantitative part of our reward interfaces, we define compatibility with respect to a “joint” reward function , which, intuitively, is a quantitative specification with respect to which the composition of the implementations of the two interfaces must be good enough. In top-down component-based design, we need to ensure that the local reward functions for interfaces guarantee that the composition of their implementations is good-enough with respect to a given high-level reward function . This is precisely the -compatibility criterion we define.
For this section, let and be composable reward interfaces with and , and their product [Definition 4].
We now define -compatibility, for a given reward function with alphabet consisting of the non-internal actions of the product automaton .
Definition 15 (-Compatibility).
The reward interfaces and are -compatible for a given function if and only if and are compatible and for all implementations and of and respectively, if and are composable, then is good-enough with respect to .
Example 16.
We now illustrate that the reward interfaces and are -compatible for the reward function from Example 1. In particular, the composition of and refines the high-level specification of expressed by . Clearly, and are composable, and since , we can construct their composition (shown in Figure 2(b)).
To see that and are -compatible, consider any pair of implementations and . Now we explain why the composition must be good-enough with respect to . We examine -hopeful input sequences, and consider the expected behaviors of and . requires to produce once was received, and not before. The same holds with respect to , and and . Since and further constrain and , respectively, this ensures that both and will each have the opportunity to output or respectively, once required. Thus, any pair of best-effort implementations of and together will operate as a best-effort implementation of the high-level reward function .
In top-down design, we may further refine our model, by splitting into two components and . Suppose for example that handles , and can output and some . outputs and , and synchronizes with via . The interface automata and are in Figure 3. The reward function requires that only occurs once did. Similarly, requires after . Through action , can prevent from incorrectly producing .
In the product , the state is illegal, because can output from , but in can not accept it. In the composition , state is therefore removed. It is easy to see that the composition of any pair of implementations of and is good enough with respect to . Thus, and are -compatible.
The -compatibility of and guarantees that is a reward interface, as it requires that the interface automata and are compatible, and has the right domain. Furthermore, the second condition of -compatibility ensures that and can be implemented independently, and composing the resulting implementations yields a good-enough implementation of . By checking -compatibility of two reward interfaces for a given reward function , we can establish whether their individual reward functions are aligned to guarantee the good-enough satisfaction of the specification .
In bottom-up design, on the other hand, we want to construct the composition of two interfaces by combining their reward functions, in order to express the guarantees of two interfaces when put together. For this, we need to provide a definition of composition of reward functions. The definition is parametrized by a function , which specifies how we combine the numeric values assigned by the two functions.
The observable behaviours of the composition are over the alphabet of non-internal actions of . Thus, the domain of the composed reward function must be the set of sequences over . Our goal is to define the composition of and in a way that captures the combined value achieved by any pair of implementations of the two interfaces. Since the implementations of each of the interfaces are constrained by the respective reward function, we cannot assume that any pair of implementations will be cooperating. Therefore, the value assigned to a sequence corresponds to the worst case over all the traces produced by some pair of composable implementations that are compatible with the sequence of inputs in .
Definition 17 (Reward Function Composition).
Let . We define the composition of the functions and , such that for where there exist composable and and such that , we let
and is undefined otherwise.
By taking the worst case in the definition of , we guarantee that as long as and are compatible, the reward interfaces and are -compatible, as shown in the next proposition. Composing and results in the reward interface . and can be implemented independently, and the composition of their implementations will be good enough with respect to .
Proposition 18 (-Compatibility).
Let . For all reward interfaces and with and compatible, it holds that and are -compatible.
We discard any observable traces not resulting from implementations of and , restricting the observable behaviors of interface automata good enough w.r.t. to those resulting from some where and . This composition is associative if the function used to combine the values is associative, and satisfies some monotonicity and continuity conditions (Proposition 29).
Proposition 19 (Quality of the Reward Function Composition).
Consider reward interfaces and with and compatible, and a reward function such that and are -compatible. Then, .
Example 20.
Let us consider components and from Example 1 from the perspective of bottom-up design. Recall the reward function from Example 14, where we impose that for input sequences containing both and , there must be outputs and in the respective order. Now, suppose instead we use a function , which ignores the requirements on , meaning that it only asks for to occur after and , and nothing else. For those input sequences with both and , will always award a value of as long as is produced. Note that this does not disallow , it simply does not require it.
A possible behavior of an implementation of is then to produce once receiving , and be idle otherwise. In particular, it will never produce . Implementations of will, as before, produce only after receiving and .
It is easy to see that the new function allows implementations of which prevent from producing , disabling the best value w.r.t. . Since has no knowledge of , we cannot assume that will be more cooperative than required by and . As and are compatible, choosing to be the sum, we have the guarantee that any is good enough w.r.t. . This guarantee is however weaker than . In this case, that means that for the mentioned input sequences featuring and , where previously the best value of was possible, we will now achieve at least .
In bottom-up design, we can use as the reward interface for the composition of and . This captures the guarantees of the composed components at a higher level of the system, without the need to devise a new reward function and checking if and are compatible with respect to it.
5 Reward Interface Refinement
Supporting different levels of abstraction for the same component is helpful in the design process, as it allows a coarse description of interactions and dependencies while also defining internal details. Refinement enables this independent implementability of an interface, permitting extended functionality as long as original obligations are maintained. For a reward interface to be a refinement of a reward interface , we require as usual that works within the same environments as , and that an implementation of is also an implementation of . This means, in particular, that, similarly to classical interface automata, a refinement of must accept at least all inputs of and not produce more outputs than . In addition, we must consider the reward function w.r.t. best-effort implementations.
The refinement relation for reward interfaces can be defined as the conjunction of refinement between the respective interface automata [Definition 8] and refinement between the respective reward functions. We define the notion of refinement for quantitative reward functions in the context of good-enough satisfaction. Intuitively, for a function to refine a function , each input sequence for must be “as hopeful” w.r.t. as it is w.r.t. , and the value assigned by to a trace must be matched by the value assigned by to the corresponding trace in . This captures the idea that inherits the obligations of and assigns values in a way that is possible in . We formalize this intuition as the existence of a helper function , that suitably relates the ranges and of the functions. The idea is that preserves the relative order of the values in , as it relates to both the hopefulness of input traces and values assigned to the respective full traces.
Definition 21 (Reward Function Refinement).
Suppose that for the reward interfaces and we have , and . We say that refines , denoted , iff there exists a function such that for every value , the following two conditions are satisfied.
-
1.
For every , if ,
then . -
2.
For every , if then .
Definition 21 captures the nature of refinement, because while it retains priority brackets for obligations of the original function, we can also introduce new dependencies or arbitrary subdivisions within each priority. The next example illustrates the refinement relation for reward functions and demonstrates the use of the helper function for establishing the relation.
Example 22.
Going back to the reward interface for with from Example 1, suppose we want to modify the guarantees, requiring to output or for a period of time. More concretely, we ask for to hold as often as possible from the point is first received until the first occurrence of , as to capture the change in input. We add the same requirement on if occurs first. We modify the existing reward function to , where we multiply the assigned value by a factor of if this new condition is violated.
Clearly, a subset of traces that had value for are now assigned value , namely where the other output is interjected. The same holds for traces going from to . The new requirement will always be violated if the order was not preserved in the first place, giving us instead of . However, the old obligations are kept: Any -hopeful input will be paired with a trace that for achieves at least . The function will then be . Thus, the priorities from are preserved in the refinement, even though we are able to strengthen requirements in the reward function .
The refinement relation for reward interfaces combines the two refinement relations.
Definition 23 (Reward Interface Refinement).
A reward interface refines a reward interface , written as , if and only if and .
The rest of this section is dedicated to establishing that the refinement relation we defined has the properties necessary for compositional design. We establish that the refinement relation between reward interfaces is a preorder, i.e. it is reflexive and transitive (Proposition 30). In particular, transitivity of refinement is important, as it allows for an iterative design process, where each refinement needs to only consider the last to maintain a refinement relation to the original specification. It is established by composing the respective helper functions.
As a consequence, an implementation of a refinement is then also an implementation of the original interface. Since the implementation must be good-enough w.r.t. the refined function, by refinement we can show it is also good-enough w.r.t. the original function.
Theorem 24 (Implementation of a Refinement).
If a reward interface refines a reward interface , then .
The other direction of Theorem 24 does not hold in general. First of all, a reward interface constrains the set of implementations through both the interface automaton and the reward function, while the refinement relation treats those two components separately, which makes it stronger than the inclusion relation between the sets of implementations. Moreover, the refinement relation on reward functions alone is stronger than the inclusion between the respective sets of good-enough automata.
The last properties we establish enable independent implementability, by guaranteeing that refinement does not impair the original context of an interface. They concern refinement in the function composition and the property of substitutability. Intuitively, substitutability states that a refinement of a reward interface remains -compatible with any reward interfaces that are -compatible with .
Theorem 25.
Consider and with and compatible, and let be a non-empty refinement of , with . Then if is monotonically increasing, . If and are -compatible for a reward function , then and are also -compatible.
With that, we established that the refinement for reward interfaces in Definition 23 indeed lifts the ideas of interface refinement to the best-effort quantitative setting and has the properties to enable component-based design of systems with quantitative specifications.
6 Checking Compatibility, Refinement, and Implementability
In this section, we study the algorithmic aspects of our theory of reward interfaces, in the context of an automata-based finite representation of the reward functions. We first introduce this representation. Then, we define the decision problems of interest, namely checking compatibility, refinement and implementability of reward interfaces, and outline algorithms for each of them for our representation. Lastly, we discuss quantitative temporal logics and weighted automata as representations of reward functions, and relate them to the representation studied in this section.
6.1 Automata-Based Finite Representation
The framework we introduced is designed to be general, including the representation of the reward function. Here, we study one possible representation, which is based on automata over finite and infinite words. We need both finite automata to model terminating components, as well as -automata to account for infinite behaviors of reactive systems.
We consider functions such that is finite, and which have a finite representation as a set of pairs of automata , where for each , is an NBA, and is an NFA, and . Intuitively, for each of the finitely many possible values of , the set of finite (resp. infinite) words that maps to that value is given as a NFA (resp. NBA). We denote with the function represented by . For a reward interface where the function is given in a finite representation , we abuse notation and write , and instead of . The size of is given by .
6.2 Decision Problems and Automata-Based Algorithms
Assuming reward functions given as defined above, with pairs of automata for each value, we now study the main decision problems for reward interfaces.
Theorem 26 (Checking Compatibility of Reward Interfaces).
For a given finitely represented reward function , checking if and are -compatible can be done in double exponential time.
Proof Sketch.
We reduce the second condition of Definition 15 to checking language inclusion for tree automata, by constructing an automaton capturing the set of joint implementations s.t. and . To this end, we construct a deterministic interface automaton from , which incurs an exponential blowup in the worst case. We construct two universal co-Büchi word automata, one for implementations , and one for good-enough sequences w.r.t. , that are converted to universal co-Büchi tree automata. Checking language inclusion can be done in exponential time, thus in total we can check reward interface compatibility in time double exponential in .
Theorem 27 (Checking Reward Interface Refinement).
Checking if can be done in exponential time.
Proof Sketch.
Checking is done in polynomial time [14]. To find a candidate function according to condition 1 of Definition 21, we iteratively match values of to those in . We compare sets of hopeful input sequences for the respective pairs of values in exponential time, by checking language inclusion. If a candidate was constructed, we verify condition 2 of Definition 21, by checking that for every complete trace achieving value on , the corresponding traces achieve value for . This is done by checking language emptiness. The overall procedure runs in exponential time.
Theorem 28 (Implementations of a Reward Interface).
Checking if for an interface automaton can be done in polynomial time.
Checking if for can be done in time exponential in .
Proof Sketch.
From , we construct an NBA whose language contains all counterexamples a good-enough implementation must not produce, whose size is polynomial in . We check for language emptiness of its product with , which can be done in polynomial time.
For checking the existence of an implementation, we construct from the automaton accepting counterexamples a deterministic parity automaton for the positive case, incurring in the worst case an exponential blow-up in the number of states. We intersect the result with a deterministic automaton obtained from to restrict the language to traces with corresponding executions on . From the combined automaton we construct a parity game and solve it. If there exists a winning strategy, it gives us a possible implementation of . If there is no such strategy, then there exists no implementation. Since the number of states in the game is exponential in , the overall check can be done in exponential time.
6.3 Discussion on Reward Functions and their Representation
The automata-based finite representation of reward functions allows system designers to express a quantitative language with a finite set of possible values in a convenient way, by describing the languages mapped to individual values as finite automata, providing a ranking for sets of execution traces with respect to how desirable these executions are.
This finite representation enables higher-level specification languages for quantitative requirements, such as LTL[] [1], which is a temporal logic with quantitative features, and the derived logic LTLf[] [5] over finite traces. Such logic formulas can be seen as functions mapping infinite and finite words, respectively, to values in . The range of values for LTL[] specifications is finite [1]. Following the construction in [1], we can translate, in exponential time, LTL[] and LTLf[] formulas into the above automata representation.
A reward function can also capture a quantitative language , expressed with a weighted automaton , where is a weight function, and a value function [8]. These automata can serve as a concise specification in the design process. To use the finite representation above and enable the respective algorithms, we restrict the instances of we consider to those where finite. For the value functions or on finite sequences, and , or on infinite sequences, we can construct in at most polynomial time [8], from a quantitative automaton , individual (Boolean) automata for threshold and , such that . We can thus translate a pair of quantitative automata with those value functions into a set of automata . While our theory supports more expressive classes of quantitative languages, such as or , there the language inclusion problem becomes undecidable for nondeterministic automata [8] and deterministic automata lack many essential closure properties [7]. In the future, we plan to investigate decidable subclasses, in order to extend algorithmic support to more expressive representations of reward functions.
7 Related Work
De Alfaro and Henzinger’s interface automata [14] have been extended in various ways, including the timed domain [16, 12], and focusing on communication and synchronization using game semantics [13]. The work on contract-based design by Benveniste et al. [3] provides a comprehensive overview of different interface theories, with a unified set of properties.
Modal interface theories [20, 23, 21] refine the model by introducing modalities, which enable the expression of liveness properties. Extensions by Tripakis et al. [25], or Mouelhi et al. [22] extend the expressive power of interface automata by introducing additional contracts over the input and output variables at each state and globally. A similar idea is presented concerning shared memory [24], where the pre- and post-conditions on transitions are interpreted as modification of shared data on synchronization. These approaches lift interface automata for more expressivity and finer control. We similarly address these issues with requirements on interfaces expressed as a reward function, which by its multi-valued range is able to capture complex specifications in a concise way, and additionally, we define compatibility with respect to arbitrary functions to express higher level goals.
Quantitative aspects of interface automata have been explored in the form of resource interfaces [6], which extend stateful interfaces to include resource labels. Each state is associated with an increase or decrease in the value of an execution if entered. This allows for naturally specifying minimum resource usage, or checking compatibility within a threshold of consumed energy. For a single interface, reward interfaces are able to express the same using the reward function, but our compatibility notion is less strict outside the automaton structure. We could however use a resource interface in place of the function, similarly to a weighted automaton, since it will associate a value for each execution. Still, the semantics will be different since we interpret obligations given by the function in a good-enough context.
Our approaches to algorithmically checking consistency and compatibility of interfaces reduce to synthesis questions, where we need to find a good-enough strategy for an infinite two-player game. Good-enough synthesis [2] is closely related to dominant [11] and admissible [4] strategies, which are strategies that perform as good as the best alternative, such that they are not dominated by another strategy. There has been further work on applying these ideas to the compositional synthesis setting [11, 19, 17].
8 Conclusion
We introduced a novel interface framework for best-effort quantitative requirements, called reward interfaces, building on interface automata. Our formalism can enforce high-quality implementations for unconstrained external environments, while providing notions of compatibility and refinement central to interface theories. It allows for expressing a wide range of both qualitative and quantitative properties in a concise manner, as to not increase the effort required during the component-based design process. The algorithmic solutions we presented are of considerably higher complexity than those for classic interface automata, due to the high degree of flexibility afforded by the quantitative function.
References
- [1] Shaull Almagor, Udi Boker, and Orna Kupferman. Formally reasoning about quality. J. ACM, 63(3):24:1–24:56, 2016. doi:10.1145/2875421.
- [2] Shaull Almagor and Orna Kupferman. Good-enough synthesis. In Shuvendu K. Lahiri and Chao Wang, editors, Computer Aided Verification - 32nd International Conference, CAV 2020, Los Angeles, CA, USA, July 21-24, 2020, Proceedings, Part II, volume 12225 of Lecture Notes in Computer Science, pages 541–563. Springer, 2020. doi:10.1007/978-3-030-53291-8_28.
- [3] Albert Benveniste, Benoît Caillaud, Dejan Nickovic, Roberto Passerone, Jean-Baptiste Raclet, Philipp Reinkemeier, Alberto L. Sangiovanni-Vincentelli, Werner Damm, Thomas A. Henzinger, and Kim G. Larsen. Contracts for system design. Found. Trends Electron. Des. Autom., 12(2-3):124–400, 2018. doi:10.1561/1000000053.
- [4] Romain Brenguier, Jean-François Raskin, and Ocan Sankur. Assume-admissible synthesis. Acta Informatica, 54(1):41–83, 2017. doi:10.1007/s00236-016-0273-2.
- [5] Alberto Camacho, Meghyn Bienvenu, and Sheila A. McIlraith. Finite LTL synthesis with environment assumptions and quality measures. CoRR, abs/1808.10831, 2018. arXiv:1808.10831.
- [6] Arindam Chakrabarti, Luca de Alfaro, Thomas A. Henzinger, and Mariëlle Stoelinga. Resource interfaces. In Rajeev Alur and Insup Lee, editors, Embedded Software, pages 117–133, Berlin, Heidelberg, 2003. Springer Berlin Heidelberg. doi:10.1007/978-3-540-45212-6_9.
- [7] Krishnendu Chatterjee, Laurent Doyen, and Thomas A. Henzinger. Expressiveness and closure properties for quantitative languages. In Proceedings of the 2009 24th Annual IEEE Symposium on Logic In Computer Science, LICS ’09, pages 199–208, USA, 2009. IEEE Computer Society. doi:10.1109/LICS.2009.16.
- [8] Krishnendu Chatterjee, Laurent Doyen, and Thomas A. Henzinger. Quantitative languages. ACM Trans. Comput. Log., 11(4):23:1–23:38, 2010. doi:10.1145/1805950.1805953.
- [9] Taolue Chen, Chris Chilton, Bengt Jonsson, and Marta Kwiatkowska. A compositional specification theory for component behaviours. In Helmut Seidl, editor, Programming Languages and Systems, pages 148–168, Berlin, Heidelberg, 2012. Springer Berlin Heidelberg. doi:10.1007/978-3-642-28869-2_8.
- [10] Chris Chilton, Bengt Jonsson, and Marta Kwiatkowska. An algebraic theory of interface automata. Theoretical Computer Science, 549:146–174, 2014. doi:10.1016/j.tcs.2014.07.018.
- [11] Werner Damm and Bernd Finkbeiner. Automatic compositional synthesis of distributed systems. In Cliff B. Jones, Pekka Pihlajasaari, and Jun Sun, editors, FM 2014: Formal Methods - 19th International Symposium, Singapore, May 12-16, 2014. Proceedings, volume 8442 of Lecture Notes in Computer Science, pages 179–193. Springer, 2014. doi:10.1007/978-3-319-06410-9_13.
- [12] Alexandre David, Kim G. Larsen, Axel Legay, Ulrik Nyman, and Andrzej Wasowski. Timed i/o automata: a complete specification theory for real-time systems. In Proceedings of the 13th ACM International Conference on Hybrid Systems: Computation and Control, HSCC ’10, pages 91–100, New York, NY, USA, 2010. Association for Computing Machinery. doi:10.1145/1755952.1755967.
- [13] Luca de Alfaro, Leandro Dias da Silva, Marco Faella, Axel Legay, Pritam Roy, and Maria Sorea. Sociable interfaces. In Bernhard Gramlich, editor, Frontiers of Combining Systems, pages 81–105, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg. doi:10.1007/11559306_5.
- [14] Luca de Alfaro and Thomas A. Henzinger. Interface automata. SIGSOFT Softw. Eng. Notes, 26(5):109–120, 2001. doi:10.1145/503271.503226.
- [15] Luca de Alfaro and Thomas A. Henzinger. Interface-based design. In Manfred Broy, Johannes Grünbauer, David Harel, and Tony Hoare, editors, Engineering Theories of Software Intensive Systems, pages 83–104, Dordrecht, 2005. Springer Netherlands.
- [16] Luca de Alfaro, Thomas A. Henzinger, and Mariëlle Stoelinga. Timed interfaces. In Alberto Sangiovanni-Vincentelli and Joseph Sifakis, editors, Embedded Software, pages 108–122, Berlin, Heidelberg, 2002. Springer Berlin Heidelberg. doi:10.1007/3-540-45828-X_9.
- [17] Rafael Dewes and Rayna Dimitrova. Compositional high-quality synthesis. In Étienne André and Jun Sun, editors, Automated Technology for Verification and Analysis - 21st International Symposium, ATVA 2023, Singapore, October 24-27, 2023, Proceedings, Part I, volume 14215 of Lecture Notes in Computer Science, pages 334–354. Springer, 2023. doi:10.1007/978-3-031-45329-8_16.
- [18] Laurent Doyen, Thomas A. Henzinger, Barbara Jobstmann, and Tatjana Petrov. Interface theories with component reuse. In Proceedings of the 8th ACM International Conference on Embedded Software, EMSOFT ’08, pages 79–88, New York, NY, USA, 2008. Association for Computing Machinery. doi:10.1145/1450058.1450070.
- [19] Bernd Finkbeiner and Noemi Passing. Dependency-based compositional synthesis. In Dang Van Hung and Oleg Sokolsky, editors, Automated Technology for Verification and Analysis - 18th International Symposium, ATVA 2020, Hanoi, Vietnam, October 19-23, 2020, Proceedings, volume 12302 of Lecture Notes in Computer Science, pages 447–463. Springer, 2020. doi:10.1007/978-3-030-59152-6_25.
- [20] Kim G. Larsen, Ulrik Nyman, and Andrzej Wąsowski. Modal i/o automata for interface and product line theories. In Rocco De Nicola, editor, Programming Languages and Systems, pages 64–79, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.
- [21] Gerald Lüttgen and Walter Vogler. Modal interface automata. In Jos C. M. Baeten, Thomas Ball, and Frank S. de Boer, editors, Theoretical Computer Science - 7th IFIP TC 1/WG 2.2 International Conference, TCS 2012, Amsterdam, The Netherlands, September 26-28, 2012. Proceedings, volume 7604 of Lecture Notes in Computer Science, pages 265–279. Springer, 2012. doi:10.1007/978-3-642-33475-7_19.
- [22] Sebti Mouelhi, Samir Chouali, and Hassan Mountassir. Refinement of interface automata strengthened by action semantics. In FESCA@ETAPS, volume 253 of Electronic Notes in Theoretical Computer Science, pages 111–126. Elsevier, 2009. doi:10.1016/J.ENTCS.2009.09.031.
- [23] Jean-Baptiste Raclet, Éric Badouel, Albert Benveniste, Benoît Caillaud, Axel Legay, and Roberto Passerone. A modal interface theory for component-based design. Fundam. Informaticae, 108(1-2):119–149, 2011. doi:10.3233/FI-2011-416.
- [24] Ayleen Schinko, Walter Vogler, Johannes Gareis, N. Tri Nguyen, and Gerald Lüttgen. Interface automata for shared memory. Acta Informatica, 59(5):521–556, 2022. doi:10.1007/S00236-021-00408-8.
- [25] Stavros Tripakis, Ben Lickly, Thomas A. Henzinger, and Edward A. Lee. A theory of synchronous relational interfaces. ACM Trans. Program. Lang. Syst., 33(4), July 2011. doi:10.1145/1985342.1985345.
Appendix A Appendix: Compatibility of Reward Interfaces
Proposition 18 (-Compatibility). [Restated, see original statement.]
Let . For all reward interfaces and with and compatible, it holds that and are -compatible.
Proof.
Let and be reward interfaces where and are compatible. To prove that and are -compatible, we need to show that for any pair of implementations and that are composable, it holds that is good enough w.r.t. . For the sake of contradiction, assume that there exist composable and such that is not good-enough w.r.t. . That means that for some there exists an input sequence that witnesses this violation, that is,
-
, and
-
for some , is undef. or .
By the first item above, together with the definition of hopeful sequences (Definition 11) and the definition of (Definition 17), there exist composable and and such that and
Since , by the definition of , we have that is defined. Thus, by the second item we have that . This, together with the definition of implies that
This is a contradiction, which concludes the proof.
Proposition 19 (Quality of the Reward Function Composition). [Restated, see original statement.]
Consider reward interfaces and with and compatible, and a reward function such that and are -compatible. Then, .
Proof.
Let and be reward interfaces with automata and that are compatible. Let be a reward function such that and are -compatible.
We have to show that for every it holds that . For the sake of contradiction, suppose that there exists such that . Since , this means that is not good-enough with respect to . Let be the trace witnessing this violation. Thus, is -hopeful for some and is either undefined or strictly smaller than . We will now show that this assumption leads to contradiction.
Let be the set of composed implementations of and . Since implementations do not restrict the allowed inputs, we have that there exists and such that . This implies that is defined. Thus, since is good-enough with respect to , we have that must be defined as well. By the definition of , this implies that there exist and such that . Now, since , and by Proposition 18 is good-enough with respect to , it must be the case that . Since , it also holds that , which is the desired contradiction.
Proposition 29 (Composition Associativity).
Let and be reward interfaces with pairwise compatible interface automata. If the function is symmetric, then . If is associative, monotonically increasing and continuous, then the reward function composition using is associative, that is, .
Proof.
Let and be reward interfaces with pairwise compatible interface automata. Clearly, . The associativity of composition for compatible interface automata is established in [14], thus . Let and .
By the definition of composition, it is clearly the case that for every we have that is defined if and only if is defined. When is symmetric, that, for all we have that , the definition of reward function composition (Definition 17) implies that if defined, the two values are equal.
Suppose that the function satisfies the following conditions for all :
-
(Associativity) .
-
(Monotonicity) If , then and .
-
(Continuity) For every fixed , the functions and are continuous on .
Under these conditions we prove that for any sequence it either holds that , or both are undefined.
Let , , and , and let . Let .
First we show that is defined iff is defined.
Suppose that is defined. Then, there exist composable implementations and and such that . Since is good-enough with respect to , from the properties of composition of reward functions we have that there exist composable and and a trace such that . By the choice of and we have that there exists such that . Since , we can use , and as a witness to the fact that is defined. The other direction of the implication is shown analogously, concluding the first part of the proof.
It remains to show that when both functions are defined on , then their values are equal.
By definition, we have Applying the definition to , we replace by
Due to the monotonicity and continuity properties of , we get
Applying reasoning similar to that in the first part of the proof, we get
Using the associativity of we replace the term
by
Additionally, reorganizing the composition, we obtain
Using again the properties of , we get This is precisely .
Appendix B Appendix: Properties of Reward Interface Refinement
Proposition 30 (Refinement as Preorder).
For all reward interfaces , and , it holds that (1) and (2) if , and , then also .
Proof.
Theorem 4.1 in [14] establishes that the refinement relation between classical interface automata is a preorder. Thus, we show only that reward function refinement is a preorder.
Consider reward interfaces , , and .
(1) is trivial, so we show only (2). Assume that and .
Since and , we have alternating simulations and from to , and from to , respectively. Furthermore we have that , , and . For , we define the relation as . The relation is an alternating simulation from to . Thus, .
Since and , there exist functions , and , which satisfy the conditions of Definition 21. We define the function such that for all . We now show that satisfies the conditions of Definition 21. Let .
-
1.
Let be such that . We have to show that . From the properties of , we get . From that, using the properties of , we get that . Since , this is precisely what we needed to show.
-
2.
Let be such that . We have to show that . Since , from the properties of we have that . From that, by the properties of the function we get . is equal to because of the subset relationships between alphabets of , , and , as stated above, which is precisely what we had to show.
Theorem 24 (Implementation of a Refinement). [Restated, see original statement.]
If a reward interface refines a reward interface , then .
Proof.
Consider reward interfaces and such that is a refinement of . We have to show that . Let . By Definition 13, we need to show that (a) , and (b) is good-enough w.r.t. .
Refinement of interface automata is transitive, and since is a refinement of , and refines , condition (a) is satisfied. To establish condition (b), we have to show that for every with and every trace it holds that is defined and .
Since , there exists a function that satisfies the conditions of Definition 21. Because , and , we know by the first property of that . Then, since we have that for every trace , is defined and . Applying Definition 21, every trace is such that is defined and . Conditions on guarantee that the matching sequence achieves value for . Since , . Thus, it follows that for every trace , is defined and , which is what we had to prove.
Theorem 25. [Restated, see original statement.]
Consider and with and compatible, and let be a non-empty refinement of , with . Then if is monotonically increasing, . If and are -compatible for a reward function , then and are also -compatible.
We will differentiate Theorem 25 into Lemma 31 and Lemma 32.
Lemma 31 (Substitutability).
Let be -compatible with for some function . Then, any non-empty refinement of with is -compatible with .
Proof.
Since and are -compatible, we know that all the following hold:
-
and are non-empty and composable,
-
there exists a legal environment for , and
-
for and composable, is good-enough w.r.t. .
To prove -compatibility of and , we will first construct an interface automaton that is a legal environment for . We will then show that for any and any , is good-enough w.r.t. . By and , we know that , i.e. does not synchronize with on any new actions. We define such that:
-
, ,
-
.
That is, is equal to except for the sets of inputs and outputs actions towards . These are modified to account for the fact that and . Since none of the new outputs of are used in , functionally differs from only in not accepting outputs of that are removed in , that is . To prove that is a legal environment for we need to show that conditions in Definition 5 are met. Meaning that is not empty and
-
1.
, , .
-
2.
is composable with , and .
-
3.
By the definition of and the properties of , the first two conditions hold.
For the third condition, note that since is a refinement of , will never reject an input accepted by . In particular, will not contain illegal states from if did not, since . Thus, the third condition also holds. Therefore, is a legal environment for .
Now we show that for any two implementations and that are composable, is good-enough w.r.t. .
As , by Theorem 24 we have that . Therefore, the -compatibility of and implies that is good-enough w.r.t .
Lemma 32 (Monotonicity of Reward Function Composition).
Consider reward interfaces and with and compatible, and let be a non-empty refinement of , with . If is monotonically increasing, then .
Proof.
Let and be such that and are compatible, and be non-empty, and . We show that if is monotonically increasing, then .
For interface automata, . We show .
From , there is a function that satisfies the conditions of Definition 21. To show , we need to construct a function that satisfies the conditions of Definition 21 for these functions.
For all , let .
For every value we have:
-
Condition 1:
Let be such that . This means that .We know that , so in particular . That means that for we will consider a subset of the implementations, and therefore not more traces when applying , as for . This, together with the above inequality implies . Then it holds that any , for which is defined, is a witness for .
-
Condition 2:
Let be such that . This means that
.We have to show that .
Since we have for the function that . Since this function is used in , then , meaning that by definition of and monotonicity of . Thus, .
Thus, both conditions in Definition 21 hold for . Hence, .
