R. S. Fabry. How to design systems in which modules can be changed on the fly. In Intl. Conf. on Software Engineering, 1976.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... real time systems that cannot afford to be taken down, for instance, telecommunication systems, command andcontrol systems, and any other systems requiring continuous operation. The idea of dynamically modifying certain lower level elements of an application is not new. In 1976, Fabry [4] presented a technique for replacing types dynamically. Over the years several strategies have been developed and implemented, spanning the range from hardware solutions with redundant processors to software based systems supporting distributed applications. A more detailed overview of previous ....

....the idea of the possibility to exchange the implementation of the type during runtime. This is possible due to the fact that the implementation of an abstract datatype is hidden behind its interface. So, even after the change, the type can be expected to work as if nothing had happened. Fabry [4] presented ways to implement such a system, which he called the dynamic type replacement system. In addition to being transparent, he also makes a demand of the updating mechanism. It should not be necessary to stop the whole system and modify all instances at once; at worst, individual instances ....

[Article contains additional citation context not shown here]

R. Fabry. How to Design A System in Which Modules can be Changed on the Fly. In Proceedings of International Conference on Software Engineering, pages 470--476. IEEE-CS Press, 1976.

....modifications of the whole application. No runtime system support required. As stated above, our technique is designed to work on any program running on any implementation of the JVM that complies to the standard [12] Many solutions to the problem of dynamic software updating have been proposed [2, 3, 5, 6, 9, 8, 10, 13, 16, 18] and several international organizations (including the Object Management Group and the Java Community Process) are developing proposals for specifying models and APIs to support dynamic application updates. Nevertheless, to the best of our knowledge, our technique is currently the only technique ....

....the test suite we used is a coverage adequate test suite for the program. Nevertheless, additional studies with other subjects are needed to address such questions of external validity. 4 Related Work Several dynamic software update techniques and systems have been presented in the literature [2, 3, 5, 6, 9, 8, 10, 13, 16, 18]. Here, we do not consider updating techniques based on hardware redundancy, which are quite costly and have limited application, as we stated in the Introduction. Among the software based techniques, several approaches are targeted to very specific languages and environments and do not directly ....

[Article contains additional citation context not shown here]

R. Fabry. How to design A system in which modules can be changed on the fly. In Proceedings of the Second International Conference on Software Engineering. IEEE, Oct. 1976.

....approach to upgrading takes advantage of the fact that long lived systems are robust : they tolerate node failures, and they allow nodes to recover and rejoin the system. Nodes are prepared for failures and know how to recover to a consistent state. This means that we Dynamic updating systems [18, 19, 21, 24, 25, 32] can reduce the time required to upgrade a node, but they still require time to install new code and to transform a node s state. can model a node upgrade as a soft restart. But even with this assumption, there are several challenges that a general approach for upgrading distributed systems must ....

....13] and Java [38] They also let an administrator add and remove objects and change the links between them. These systems require manual upgrade scheduling and assume compatibility between versions. 9. 2 State Transformation Many upgrade systems allow the transformation of state between versions [14, 18, 19, 21, 24, 26,45]. Most base the correctness of their transform functions on Herlihy and Liskov s value transmission technique for ADTs [23] Some also provide tools that automatically generate transforms from the old and new version of an object s definition [24, 30, 45] Bloom [14, 15] argues that value ....

[Article contains additional citation context not shown here]

R. S. Fabry. How to design systems in which modules can be changed on the fly. In Intl. Conf. on Software Engineering, 1976.

....possible because during run time, the application has all information and capabilities needed to carry out such an operation. In the next section, we present and briefly discuss some works related to dynamic adaptation problem. 3. Related work Dynamic adaptation is not a new problem, R. Fabry [1] explained in 1976 how to develop a system in which modules can be changed on the fly. Several other works dealt with the adaptation problem such as Dynamic Linking, Redundant Hardware and State Transfer. Other more recent approaches are presented in this section. 3.1. DCUP Many adaptation ....

R.S. Fabry, "How to design a system in which modules can be changed on the fly", Proc. 2nd lnt. Conf. on Soft. Eng., pp. 470-476 (1976).

....because during run time, the application has all information and capabilities needed to carry out such an operation. In the next section, we present and briefly discuss some works related to dynamic adaptation problem. 3. Some existing solutions Dynamic adaptation is not a new problem, R. Fabry [1] explained in 1976 how to develop a system in which modules can be dynamically changed. Several other works dealt with the dynamic adaptation such as Dynamic Linking , Redundant Hardware and State Transfer. Other more recent approaches are presented in this section. These approaches are more ....

R.S. Fabry, "How to design a system in which modules can be changed on the fly", Proc. 2nd lnt. Conf. on Soft. Eng., pp. 470-476 (1976).

....and connecting a new version. The aim of this paper is to highlight the reasons of performing an adaptation, to identify and to classify its different types, and to define the problems and the complexity raised by each type. Dynamic adaptation is not a new problem, the first works go back to 1976[1]. We first introduce a short background of the adaptation problem, followed by the presentation of the different adaptation reasons, types and how to evaluate an adaptation approach. The remainder of the paper presents et evaluates the evolution of the adaptation approach from a large spectrum ....

....of our paper, we present three classical approaches followed by three recent studies that deal with the adaptation problem. We conclude by a synthesis in which we classify and compare the presented approaches. 5. Classical adaptation Approaches Dynamic adaptation is not a new problem, R. Fabry [1] explained in 1976 how to develop a system in which modules can be changed on the fly. Several other works dealt with the adaptation problem. 5.1. Dynamic linking In one hand, this term refers to the incremental loading of a program having holes that are filled in at load or at run time such as ....

R.S. Fabry, "How to design a system in which modules can be changed on the fly", Proc. 2nd ln t. Conf. on Soft. Eng., pp. 470-476 (1976).

....Type change is also an issue for dynamic module replacement systems whose goal is to replace program components without stopping execution of a program. In this case there is existing data that may need to be transformed even though it is not necessarily persistent data. Existing systems (such as [Fab76, FS91] recognize the need for such transformation functions, but leave the development of those functions to the maintainer. Tess s comparison algorithms could be used to generate these transformation functions. Another situation in which type comparison may be applicable is schema integration. ....

R. Fabry. How to design a system in which modules can be changed on the fly. In Proceedings of the International Conference on Software Engineering, pages 470--476, Los Alamitos, CA, 1976.

....it can be included without negatively affecting the reliability of Argus programs. As will be seen later, it may be difficult to allow replacement without introducing additional likelihood of error. This work draws on a number of similar areas of research, primarily dynamic type replacement[5], 7] and dynamic hardware reconfiguration [14] This section discusses the relationship of our work to these other areas. As mentioned earlier, this work is also strongly grounded in related work in programming methodology [11] and language design for distributed systems [12] 1.3.1 Dynamic ....

....[14] This section discusses the relationship of our work to these other areas. As mentioned earlier, this work is also strongly grounded in related work in programming methodology [11] and language design for distributed systems [12] 1.3. 1 Dynamic Type Replacement Both Habermann [7] and Fabry [5] address the dynamic type replacement problem. The problem is the following. In any system using data abstraction, objects of user defined types are created and passed to various modules throughout the system. The type m.anager (or cluster in CLU terminology) knows and depends upon the internal ....

[Article contains additional citation context not shown here]

Fabry, R. How to Design A System In Which Modules Can Be Changed On TheFly. Proceedings of the Second International Conference on Software Engineering, IEEE, October, 1976.

....Type change is also an issue for dynamic module replacement systems whose goal is to replace program components without stopping execution of a program. In this case there is existing data that may need to be transformed even though it is not necessarily persistent data. Existing systems (such as [Fabry 1976; Frieder and Segal 1991] recognize the need for such transformation functions, but leave the development of those functions to the maintainer. Tess s comparison algorithms could be used to generate these transformation functions. Another situation in which type comparison may be applicable is ....

Fabry, R. 1976. How to design a system in which modules can be changed on the y. In Proceedings of the International Conference on Software Engineering (Los Alamitos, CA, 1976), pp. 470-476.

....in CLAM that dynamically change the interface by loading different services under different load conditions, but no mention of this is given in the literature. 5. 3 Dynamic Modification of Code Research on programs that dynamically modify running code seems to date back to Fabry s early work [7]. Fabry uses indirect jump statements that can be atomically changed so that subsequent invocations of a service use the new version. Goullon [8] describes an operating system called DAS (dynamically alterable system) that allows dynamic modifications anywhere except the kernel. DAS uses virtual ....

R. S. Fabry. How to design a system in which modules can be changed on the fly. In Proceedings of the 2nd International Conference on Software Engineering, pages 470-- 477, San Francisco, California, October 1976.

....we briefly review some of the previous work in the area of on line software modification. A comprehensive survey can be found in [SF93] 1.2. 1 A Dynamic Type Replacement System Fabry described a system in which implementations of abstract data types (called modules) can be changed on the fly [Fab76] Several processes may access the same module and a module may manage permanent data local to one process or shared by several processes. Fabry only considered the case in which the interface and the semantics of the module being replaced do not change across versions. The system was based on ....

....evaluate the system s performance and an experiment carried out to investigate certain engineering issues involved in on line changes to programs 47 48 4. 1 The Basic Approach and Design Principles Many systems for on line software version change have previously been described in the literature [Fab76, GIL78, Lee83, SF89a] see Chapter 1 for more details) Most of these systems use indirect addressing tables to link the different modules. These tables are dynamically changed if a module has to be replaced by a new version. The changing of the table is done in a manner that it does not cause ....

[Article contains additional citation context not shown here]

R. S. Fabry. "How to design systems in which modules can be changed on the fly". In Proc. 2nd Int. Conf. Software Engg., 1976.

....Some systems allow the configuration of a distributed program to be changed dynamically by reassigning processes or modules to different nodes and by adding and deleting links, processes etc. dynamically[6, 7, 8, 9, 10] A few approaches have been described for on line software version change [11, 12, 13, 14]. The system described in reference [11] is restricted to dynamically changing the implementation of an abstract data type. The data representation within these data types is changed by appropriate conversion routines to suit a new code version, on demand. The DAS operating system [12] has the ....

....program to be changed dynamically by reassigning processes or modules to different nodes and by adding and deleting links, processes etc. dynamically[6, 7, 8, 9, 10] A few approaches have been described for on line software version change [11, 12, 13, 14] The system described in reference [11] is restricted to dynamically changing the implementation of an abstract data type. The data representation within these data types is changed by appropriate conversion routines to suit a new code version, on demand. The DAS operating system [12] has the capability to modify procedures of a ....

R. S. Fabry. "How to design systems in which modules can be changed on the fly". In Proc. 2nd Int. Conf. Software Engg., 1976.

....and satellites. Such systems have complex computer systems aboard that are controlled from earth stations. If new versions of software are to be installed, an on line version change system can be quite useful. A few implementation have been described for supporting on line software version change [4, 7, 10, 13]. The system described in [4] deals with dynamically changing an implementation of an abstract data type. The DAS operating system [7] has the capability to modify individual procedures of a program while it is running but the change is limited to the case when the parameters and the return value ....

....computer systems aboard that are controlled from earth stations. If new versions of software are to be installed, an on line version change system can be quite useful. A few implementation have been described for supporting on line software version change [4, 7, 10, 13] The system described in [4] deals with dynamically changing an implementation of an abstract data type. The DAS operating system [7] has the capability to modify individual procedures of a program while it is running but the change is limited to the case when the parameters and the return value of the procedures to be ....

R. S. Fabry. "How to design systems in which modules can be changed on the fly". In Proc. 2nd Int. Conf. Software Engg., 1976.

....intends to control the changes to preserve the integrity of the software, but any approved changes are installed in the traditional manner. Several systems which support modifications to running programs have been described in the literature, such as Fabry s dynamic type replacement system [1], the DAS operating system [2] DYMOS [3] PODUS [4] 5] and the authors system [6] A survey of many different implementations can be found in [7] There are also systems that allow flexible interconnection of software components to form the complete system [8] 9] 10] However such systems ....

R. S. Fabry, "How to design systems in which modules can be changed on the fly", in Proc. 2nd Int. Conf. Software Engg., 1976.

No context found.

R. S. Fabry. How to design systems in which modules can be changed on the fly. In Intl. Conf. on Software Engineering, 1976.

No context found.

R. S. Fabry. How to design a system in which modules can be changed on the fly. In Proceedings of the 2nd ICSE, pages 470--476, San Francisco, CA, USA, 1976.

No context found.

R. S. Fabry. How to design a system in which modules can be changed on the fly. In Proceedings of the 2nd ICSE, pages 470--476, San Francisco, CA, USA, 1976.

No context found.

R. S. Fabry. How to design a system in which modules can be changed on the fly. In Proceedings of the 2nd ICSE, pages 470--476, San Francisco, CA, USA, 1976.

No context found.

R. S. Fabry. How to design a system in which modules can be changed on the fly. In Proceedings of the 2nd ICSE, pages 470--476, San Francisco, CA, USA, 1976.

No context found.

R. S. Fabry. How to design systems in which modules can be changed on the fly. In Intl. Conf. on Software Engineering, 1976.

No context found.

R. S. Fabry. How to design systems in which modules can be changed on the fly. In Intl. Conf. on Software Engineering, 1976.

No context found.

R. Fabry. How to design a system in which modules can be changed on the y. In Proceedings of the International Conference on Software Engineering (ICSE), pages 470-476, 1976.

No context found.

R. Fabry. How to Design A System in Which Modules can be Changed on the Fly. In Proceedings of International Conference on Software Engineering, pages 470--476. IEEE-CS Press, 1976.

No context found.

R. Fabry. How to Design A System in Which Modules can be Changed on the Fly. In Proceedings of International Conference on Software Engineering, pages 470--476. IEEE-CS Press, 1976.

No context found.

R. S. Fabry, `How to design systems in which modules can be changed on the fly', Proc. 2nd Int. Conf. Software Eng., 1976.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC