Changing Persistent Applications

  • Alex Farkas
  • Alan Dearle
Conference paper
Part of the Workshops in Computing book series (WORKSHOPS COMP.)


During the lifetime of an application, the objects and bindings in a persistent store may require modification in order to fix bugs or incorporate changes. Two mechanisms, Octopus and Nodules, supporting the evolution of persistent applications are presented. The first, Octopus permits code and data values to be evolved, even if they are encapsulated. Type evolution is addressed by the separation of type information from the executable code. In many cases type evolution is possible, without the expense of total or partial system recompilation. Nodules are a complementary mechanism to Octopus in that they allow generic templates to be defined independently of any referencing environment. Nodules may be specialised in order to yield instances by binding them to values and types. When combined into a single system, Nodules and Octopus enable a rich collection of information about the structure and state of applications to be maintained and made available to programmers not only during the construction phase, but during the entire lifetime of applications.


Type Evolution Type Part Object Graph Quantity Field Executable Code 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Booch, G. “Object Oriented Design”, Benjamin-Cummings, 1991.Google Scholar
  2. 2.
    Connor, R. C. H. “The Napier Type-Checking Module”, Universities of Glasgow and St Andrews, Technical Report PPRR-58-88, 1988.Google Scholar
  3. 3.
    Dearie, A. and Brown, A. L. “Safe Browsing in a Strongly Typed Persistent Environment”, The Computer Journal vol 31, 6, pp. 540–545, 1988.CrossRefGoogle Scholar
  4. 4.
    Dearie, A., Cutts, Q. and Connor, R. “Using Persistence to Support Incremental System Construction”, Microprocessors and Microsystems, vol 17, 3, pp. 161–171, 1993.CrossRefGoogle Scholar
  5. 5.
    Farkas, A. and Dearie, A. “The Octopus Model and its Implementation”, in Proceedings of the 17th Australian Computer Science Conference, Australian Computer Science Communications, vol 16, pp. 581–590, 1994.Google Scholar
  6. 6.
    Farkas, A. and Dearie, A. “Octopus: A Reflective Language Mechanism for Object Manipulation”, in Proceedings of the Fourth International Workshop on Database Programming Languages, New-York, Springer-Verlag, 1994.Google Scholar
  7. 7.
    Kirby, G. N. C, Connor, R. C. H., Cutts, Q. I., Dearie, A., Farkas, A. M. and Morrison, R. “Persistent Hyper-Programs”, 5th International Workshop on Persistent Object Systems, San Miniato, Persistent Object Systems, Springer-Verlag, Workshops in Computing, pp. 86–106, 1992.Google Scholar
  8. 8.
    Liskov, B. H. and Zilles, S. N. “Programming with Abstract Data Types”, SIGPLAN Notices, vol 9, 4, 1974.Google Scholar
  9. 9.
    Morrison, R., Brown, A. L., Connor, R. C. H. and Dearie, A. “Polymorphism, Persistence and Software Reuse in a Strongly Typed Object Oriented Environment”, Universities of Glasgow and St Andrews, Technical Report PPRR-32-87, 1987.Google Scholar
  10. 10.
    Morrison, R., Brown, A. L., Connor, R. C. H. and Dearie, A. “The Napier88 Reference Manual”, University of St Andrews, Technical Report PPRR-77-89, 1989.Google Scholar
  11. 11.
    Farkas, A. and Dearie, A. “Integrated Support for Incremental Software Development and Evolution”, University of Adelaide, Technical Report PS-24, May 1994.Google Scholar

Copyright information

© British Computer Society 1995

Authors and Affiliations

  • Alex Farkas
    • 1
  • Alan Dearle
    • 1
  1. 1.Department of Computer ScienceUniversity of AdelaideAdelaideAustralia

Personalised recommendations