Static and dynamic property-preserving updates☆
Introduction
Update is a relevant topic [1], both for automatic updates, as in the context of adaptive systems [2] or autonomic computing [3], and for manual updates. Update may be triggered by different needs, e.g., to fix bugs, to satisfy changing user requirements, or to match changes in the computing environment. Answering these needs is necessary since one wants systems to last for a long time in a changing scenario. However, a main point, namely correctness of the system after update, has received less attention till now, as remarked also in [4]. A real-world example highlighting the importance of this aspect is the following: what was called “one of the biggest computer errors in banking history”, deducting about $15 millions from over 100000 customers' accounts, was due to a software update [5].
In this paper we consider a very simple yet general update mechanism, which replaces a part of the system with a new one. Formally, the system is seen as a context containing the component1 to be updated , i.e., the system has the form . An update replaces component with a new component , thus the system upon update has the shape . The update can be performed either statically, that is is shut down, and the new system starts in the initial state, or dynamically, by replacing with without restarting (dynamic updates are also called live updates, or on-the-fly updates). In this second case, when starts, is in the same state as when has been removed.
In the simpler case of static update a basic question is: how to build a most general new component such that if system satisfies a given property Φ, then also system satisfies the same property? This question is answered in Section 3. Note that system may satisfy further properties that system does not satisfy. The answer to the question above, which relates components and , depends both on the context and on the property Φ. From this observation two generalisations emerge naturally. On one side, one may ask how to build a most general new component such that for a given context , all the properties satisfied by system are also satisfied by system (Section 3). We call such an update correct for a given context w.r.t. any property. On the other side, one may ask how to build a most general new component such that for each context if system satisfies property Φ, then system satisfies the same property (Section 4). We say that such an update is correct (w.r.t. property Φ), hence it can be applied in any context. Finally, one may combine the two generalisations asking how to build a most general new component to ensure correctness of update in any context and w.r.t. any property (Section 4).
The questions above can be rephrased also for dynamic update, by requiring that the system behaving first as , and then as , satisfies the desired properties. Here there is an additional element coming into play, namely how to select the state in which starts, depending on the state of just before the update. This problem is known as the state transfer problem, and has been first studied in [6]. The problem is notoriously hard and is normally dealt with by manual tedious work, as reported, e.g., in [7], [8]. We will compute (Section 5) a partial function that, for each state of , tells us whether the update can be safely performed or not and, in the first case, which states of can be selected as starting states.
The questions above are very general, and the detailed answer depends on the choice of the model for components and contexts, of the composition operators, and of the formalism for expressing properties. We consider here components, contexts and properties represented as Constraint Automata [9], [10], which have been used in the literature, e.g., to give a formal semantics to REO connectors [11] and Rebeca actors [12]. We use sets of prefix-closed finite and infinite traces as semantic framework. We concentrate on safety properties, thus prefix-closed sets of traces are enough. We consider both asynchronous and synchronous composition for components and contexts. We leave the systematic exploration of the research space above to future work. We illustrate the main results of our approach by means of a simple running example. All the operations on Constraint Automata were computed using the tool GOAL [13],2 an interactive tool for defining and manipulating automata, which we extended to deal with Constraint Automata.
The present paper is an extended and revised version of [14], which concentrated on static update. Here we also consider dynamic update, hence the state transfer problem. We also provide more efficient constructions for update in a given context (both for a single property and for all properties) when the selected context is input-deterministic. The present paper includes full proofs of all the results, which were absent in [14]. Finally, the whole paper has been carefully revised, and extended with additional examples and a more detailed description of related work.
Section snippets
Constraint automata
We model components, contexts and properties as (nondeterministic) Constraint Automata (CAs) [9], defined below. Throughout the paper we assume a finite set of data values which can be communicated and a finite set of states for the CAs. As in [9], the finiteness assumption is needed for the effectiveness of our constructions.
Definition 1 Constraint Automata A Constraint Automaton is a tuple where: Q is a finite set of states; N is a finite set of nodes representing the interface between the CA and the outside
Updates correct for a given context
We start this section with a formal definition of correct update.
Definition 7 Correct update Given a system , an update replacing component with a new component is correct w.r.t. a property Φ iff whenever also .
We assume that components and have the same interface, that is, the same set of nodes. This is not restrictive since one can always add nodes that are never used.
This section considers both the cases “all properties, given context” and “given property, given context”. We show that they can
Updates correct for all contexts
In this section we study both the cases “given property, all contexts” and “all properties, all contexts”. Similarly to the previous section, we can assume without loss of generality that components and have the same interface U, and that all the contexts we consider have U as internal interface.
Let us start from the case of a given property. The property defines a minimum set of nodes O that the external interface of the context should provide. For some properties, replacing component
From static to dynamic update
Previous sections concentrate on static update, where the system is shut down before update, and computation restarts from the initial state after update. We consider here dynamic update, where the component is replaced by at runtime. In particular, when starts, the context is not necessarily in the initial state, but it is in the same state it was in when was removed. In this setting, starting in the initial state may be wrong. This raises the issue of defining how state transfer
Related work
While many approaches tackle system update [1], the problem of ensuring correctness of a system upon update has received less attention till now. We discuss below relevant classes of related work.
Refinement. Approaches based on behavioural congruences, such as [24], allow one to prove the correctness of updates when a component is replaced by a syntactically different, but semantically equivalent one. Similarly, approaches based on refinement, such as [25] in the context of Reo, allow one
Conclusion
We studied the problem of finding out whether an update replacing a component with a component in a given context is correct w.r.t. a safety property Φ. We also characterised the updates correct in any context (for a given property), for any property (in a given context), and for any property in any context. In all the cases, we considered both synchronous and asynchronous composition. In order to support dynamic update, we also studied how to map the state of the original component
Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
References (45)
- et al.
Modeling component connectors in Reo by constraint automata
Sci. Comput. Program.
(2006) Temporal and modal logic
Finite automata and unary languages
Theor. Comput. Sci.
(1986)- et al.
Compositional and behavior-preserving reconfiguration of component connectors in Reo
J. Vis. Lang. Comput.
(2013) - et al.
Modeling dynamic reconfigurations in Reo using high-level replacement systems
Sci. Comput. Program.
(2011) - et al.
Dynamic adaptation with distributed control in Paradigm
Sci. Comput. Program.
(2014) - et al.
Synthesis of reactive(1) designs
J. Comput. Syst. Sci.
(2012) - et al.
A survey of dynamic software updating
J. Softw. Evol. Process
(2013) - et al.
A systematic literature review of service choreography adaptation
Serv. Oriented Comput. Appl.
(2013) - et al.
A survey of autonomic computing - degrees, models, and applications
ACM Comput. Surv.
(2008)
Specifying and verifying the correctness of dynamic software updates
Glitch makes teller machines take twice what they give
A formal framework for on-line software version change
IEEE Trans. Softw. Eng.
Providing dynamic update in an operating system
Live updating operating systems using virtualization
Formal verification for components and connectors
Reo: a channel-based coordination model for component composition
Math. Struct. Comput. Sci.
Compositional semantics of an actor-based language using constraint automata
GOAL for games, omega-automata, and logics
Most general property-preserving updates
Weak automata for the linear time μ-calculus
Complexity of model checking recursion schemes for fragments of the modal mu-calculus
Log. Methods Comput. Sci.
Cited by (2)
Special Issue: Selected papers of the 11th International Conference on Language and Automata Theory and Applications, LATA 2017
2021, Information and ComputationFormally Characterizing the Effect of Model Transformations on System Properties
2022, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)
- ☆
The authors acknowledge the support from the Italian INdAM – GNCS projects 2016 Logic, automata and games for self-adaptive systems and 2017 Logic and automata for interval model-checking. The authors also thank the anonymous reviewers for their useful comments and suggestions.