A formal framework for on-line software version change

Abstract

| The usual way of installing a new version of a software system is to shut down the running program and then install the new version. This necessitates a sometimes unacceptable delay during which service is denied to the users of the software. An on-line software replacement system replaces parts of the software while it is in execution, thus eliminating the shutdown. While a number of implementations of on-line version change systems have been described in the literature, little investigation has been done on its theoretical aspects. In this paper, we describe a formal framework for studying on-line software version change. We give a general de nition of validity of an on-line change, show that it is in general undecidable and then develop su cient conditions for ensuring validity for a procedural language.

Extending eclipse RCP with dynamic update of active plug-ins.

“…The work of Gupta et al [Gupta96] also includes dynamic software updating although it mostly focuses on validating updates. A method that likewise falls into the domain of dynamic updating is the one presented in [Hicks01].…”

Designing Run-Time Fault-Tolerance Using Dynamic Updates

“…We say that a program p is nonmasking f -tolerant from I p for spec iff the following conditions hold: (1) in the absence of faults, p satisfies spec from I p , and (2) A masking fault-tolerant program always satisfies its safety specification (even in the presence of faults), and eventually recovers to its invariant. More precisely, a program p is masking f -tolerant from I p for spec iff the following conditions hold: (1) in the absence of faults, p satisfies spec from I p , and (2) In order to deal with the complexity of designing runtime fault-tolerance in the presence of unanticipated faults, we propose a hybrid design method by combining two existing approaches: dynamic program updates [18,14,15,26,2] and our previous work [13,24] on offline synthesis of fault-tolerant programs from their fault-intolerant version. Specifically, since it is difficult (if not impossible) to guarantee that p o meets the requirements of (failsafe/nonmasking/masking) fault-tolerance against unanticipated faults f , we make the following design decision to support run-time fault-tolerance:…”

“…For example, Gupta et al [15] propose a formal framework in which developers define a transfer function that specifies how a state of the new program is reached instantaneously. Kramer and Magee [18] enable run-time replacement of a program (or a component thereof) with its new version where the update may be triggered once the running program reaches a set of quiescent states; i.e., states in which the program is in a passive status where no external entity is using or communicating with the running program.…”

“…Gupta and Jalote [14] present a functional approach for transferring the state of the old program to a state of the new program where the transfer functions are developed offline. Gupta et al [15] propose a formal framework for designing and reasoning about dynamic updates, where online change is considered to be an instantaneous process using a transfer function (defined by developers). Duggan [12] presents a type-based hot swapping approach where programmers define two-way mappings that are reflected as type-sharing constraints during update.…”

“…program [18,14,15,26,2] most of which focus on the architectural and programming issues with less emphasis on the effect of faults and fault-tolerance during updates. For example, Kramer and Magee [18] present a framework for specifying and implementing dynamic updates at the architectural (components/connectors) level, thereby separating the functional updates from structural updates.…”