Extending object-oriented languages with backward error recovery integrated support

https://doi.org/10.1016/j.cl.2009.05.001Get rights and content

Abstract

One of the requirements of software robustness is controlling and managing runtime errors that might arise at certain points of application execution. In most object-oriented programming languages, this requirement is commonly implemented by means of exception handling. Although exception handling is a powerful tool to avoid system failure arising, there are still many situations where it is not sufficient to restore the system to a consistent state. Exception handling allows the developer to detect and locate errors, but it gives no information or tools to cover the error recovering task. Therefore, we propose an extension of the semantics of common object-oriented languages to restore the previous consistent state of the system in the presence of runtime errors, avoiding some of the tasks that exception-handling mechanisms delegate to developers. Our proposed solution is centered in the concept of “reconstructor”, a declarative component oriented to automatically return the system to its last stable state. Based on this concept, we develop a non-intrusive code enrichment tool for Java, and we apply it to a real application in order to check the feasibility of the proposal. We evaluated the performance of the resulting code, obtaining reasonable and viable rates and overload.

Introduction

Ever since the NATO conference on software development in 1968, this task was viewed as an engineering process, and consequently a new objective emerged in every software project: every product needed to reach minimum levels of software quality.

Thirty years later, a great number of research lines are still devoted to obtaining new techniques and technologies to increase software quality. This work considers a specific factor of software quality: software robustness.

Software robustness can be defined as the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions [1], [15]. It depends on two complementary factors: technological support and the developer's professional capacities. The wider the technological coverage given by the platform, the easier the developer's task of implementing robust software. The logic needed to implement recovery mechanisms in low-level languages was therefore more complicated and harder to maintain than the logic needed nowadays when developed with more mature technologies like modern object-oriented platforms.

The current exception-handling mechanism, present in almost all object-oriented languages, covers the tasks of detection and localization of the error source, but does not help to solve the third task that must be carried out to maintain consistency in the presence of any critical error: error recovering. This task is delegated to the developer who, as it will be seen later in this document, sometimes does not have enough information to reach his/her objective without developing complementary support processes.

In our opinion, some of these tasks can be implemented automatically by means of the information contained in the source code, so it is possible to avoid some of the work a developer must do to implement the necessary mechanism for maintaining consistency in the presence of errors. That is the motivation of this paper, which can be summarized thus:

The modern object-oriented languages can be extended with a new semantic layer that complements current exception-handling mechanisms, simplifying the implementation of these processes purely oriented to consistency maintenance in the presence of exceptional scenarios.

What we propose in this document is the implementation of a mechanism to make consistency restoration easier for the developer. Since this is a very compressed expression of the idea, the next section justifies this work, starting from the analysis of some of the scenarios where the current exception-handling mechanism does not cover all the requirements of consistency maintenance, and describing the solution proposed as an extension of the modern object-oriented software development platforms. This extension is based on the concept of the reconstructor, and it is integrated with modern object-oriented platforms as a new semantic layer by the decoration of the source code.

Section snippets

Analyzing the problem: exception-handling limitations

As we said before, exception-handling is not always powerful enough to reach its objective: to return the system to a consistent state and continue program execution, especially when the only way to recover the consistency is to recover the last consistent state the system was in. It works right over the first two tasks of detecting and localizing the error source, but it does not cover error recovering or correction. This task is usually delegated to the developer, who must implement the catch

Related work

Before we developed any proposal, existing related solutions were studied to evaluate their convenience in solving the described problem. There have been several attempts to reach model consistency recovery in object-oriented applications since the beginning of this paradigm, especially in distributed and fault-tolerant oriented languages, where transactional processing is necessary to coordinate remote nodes. All of them have been evaluated from the perspective of current development

Analyzing the reconstructors

The solution proposed in this work is inspired by the generalization of the concept of reconstructors introduced earlier and proposed as part of the RDM architecture. Despite the fact that RDM reconstructors are a complete solution in their original context, because of their design they are not available for general-purpose applications:

  • They must be applied inside the scope of the framework RDM. Since RDM reconstructors are designed to live inside the framework, they need resources and support

Redefining reconstructors

First, let us clarify that, as in RDM, the reconstructor will still be an element specialized in restoring the consistency of a specific part of the model. Like Hansel and Gretel's pieces of bread, each reconstructor can disallow one specific change in an operation execution. A reconstructor will therefore be generated each time a reconstructable action is executed.

As they are created, the reconstructors are stacked in the reconstruction path, a sequence of reconstructors that stores the

Integrating reconstructors into object-oriented languages

As we saw in Section 3, there are several ways to extend an existing programming language or paradigm with new features. The most radical option would be the implementation of a new version of the language, but it would not be a practical solution for the actual problems in real development projects. A solution based on design pattern proposal or on new framework implementations would solve some of the problems, but force the developer to implement even more processes that can be generated

Implementing the prototype: Ariadna tool

The Ariadna tool is the prototype we developed to test the feasibility of the solution proposed in this work. It is a Java application that enriches the original Java code guided by the annotations described above. Its implementation uses the Recoder API [26], a Java API that generates a kind of AST tree with the information of the syntax structure of the source program, allowing us to modify and enrich it (Fig. 17).

Ariadna works in two phases. During the first one, the source code is analyzed

Applying Ariadna to a real project

In order to evaluate the feasibility of Ariadna, we tested it on a real research project while developing Premosgames tool, a plant-growing simulation application developed in the Netherlands Institute of Ecology (NIIO-KNAW, Yerseke, Netherlands), as part of the Predictive model of seagrass growth and meadow spreads (PREMOSGAMES) research project (EU Contract MEIF-CT-2005-515071). Ariadna was applied to the second version of the application (PREMOSGAMES 2.0), solving some of the problems found

Benefits and performance

Our experience with Premosgames showed that reconstructors permit the developer to focus more on the domain login and less on the secondary task of consistency maintenance, but there is not enough information to quantify the savings only with the Premosgames results. In order to quantify the benefits and penalties when using reconstructors, we applied Ariadna to a set of model cases.

The first question to solve was the definition of the set of model cases to which the tool should be applied and,

Future work

Ariadna is not the end of the story. Several lines of work are trying to improve reconstructors and make them a more powerful tool for software developers. We are developing a new version of Ariadna integrated with the Eclipse IDE as a plug-in. The way that we integrate reconstructors with the Java language is also being evaluated. A new version of reconstructors implemented under the Aspect Oriented Programming [5] paradigm has been developed in our labs [17] and it is being tested as a new

Conclusions

In this work, we identified the limitations of exception-handling mechanisms that force the developer to implement certain tasks not directly related to the domain. The most representative solutions for similar purposes have been studied and evaluated. As a result of these evaluations, a new extension of the object-oriented languages paradigm has been proposed, based on the concept of reconstructor introduced by the RDM architecture.

The new semantic layer we added to the object-oriented

References (29)

  • IEEE glossary of software engineering terminology. IEEE Standards, 729;...
  • Leyton M. Interoperability and objects. International Journal of Product Lifecycle Management 2006;1(2):98–128(31),...
  • Blanck Lisbôa ML, Pereira Fernandes A. Reflective implementation of an object recovery design pattern. In: VII...
  • Randerll B, Campbell RH, Anderson T. Practical fault tolerance software for asyncronous systems. In: IPAC Safecom 83....
  • Walker RJ, Baniassad ELA, Murphy GC. An initial assessment of aspect-oriented programming. In: International conference...
  • H. Hecht et al.

    Fault-tolerant software

    (1986)
  • Cristian F. A recovery mechanism for modular software. In proceedings of the fourth international conference on...
  • E. Gamma et al.

    Design patterns: elements of reusable object-oriented software

    (1995)
  • Garthwaite A, Nettles S. Transactions for Java. In: International conference on computer languages, 1998. p....
  • Guelfi N, Astesiano E, Reggio G, editors. Scientific engineering for distributed Java applications. In: International...
  • Izquierdo R. RDM: Arquitectura Software para el Modelado de Dominios en Sistemas Informáticos. PhD thesis, University...
  • Krall A. Efficient JavaVM just-in-time compilation. In Gaudiot JL, editor. International conference on parallel...
  • Fowler M, Beck K, Brant J, Opdyke W, Roberts D. Refactoring: Improving the design of existing code. Addison-Wesley...
  • K. Beck

    Smalltalk best practice patterns

    (1997)
  • Cited by (9)

    • A multi-user selective undo/redo approach for collaborative CAD systems

      2014, Journal of Computational Design and Engineering
      Citation Excerpt :

      The initial research of Undo/Redo models are in single-user environments [9-10]. The Undo/Redo models in single-user environments are classified into 4 categories: 1) the single-step Undo/Redo model [2], 2) the linear Undo/Redo model [3], 3) the US&R (Undo, Skip, Redo) model [11], and 4) the history Undo/Redo model [12]. However, in a multi-user collaborative editing system, operations are interleaved at different sites.

    • A group Undo/Redo method in 3D collaborative modeling systems with performance evaluation

      2013, Journal of Network and Computer Applications
      Citation Excerpt :

      Implementation details are different with the following aspects. In programming language (Lanvin and Castnedo, 2010; Plank et al., 1996), a checkpoint is created automatically according to some preset triggering mechanism. However, in configuration management systems (Carnduff and Goonetillake, 2004) and version control systems (http://bazaar-vcs.org/); (http://subversion.apache.org/), the creation of a checkpoint is performed by user instructions.

    • Extending the consistency property of software transactional memory systems with business constraints in OCL and incremental checking

      2017, IMCIC 2017 - 8th International Multi-Conference on Complexity, Informatics and Cybernetics, Proceedings
    • Integrating automatic backward error recovery in asynchronous rich clients

      2016, Proceedings - International Conference on Software Engineering
    • Invariant implementation for domain models applying incremental ocl techniques

      2016, Communications in Computer and Information Science
    • OCL for rich domain models implementation: An incremental aspect based solution

      2015, ICSOFT-PT 2015 - 10th International Conference on Software Paradigm Trends, Proceedings; Part of 10th International Joint Conference on Software Technologies, ICSOFT 2015
    View all citing articles on Scopus
    View full text