Eiffel Programming Research Articles

A failed proof can yield a useful test

AbstractA successful automated program proof is, in software verification, the ultimate triumph. In practice, however, the road to such success is paved with many failed proof attempts. Unlike a failed test, which provides concrete evidence of an actual bug in the program, a failed proof leaves the programmer in the dark. Can we instead learn something useful from it? The work reported here takes advantage of the rich information that some automatic provers internally collect about the program when attempting a proof. If the proof fails, the Proof2Test tool presented in this article uses the counterexample generated by the prover (specifically, the SMT solver underlying the Boogie tool used in the AutoProof system to perform correctness proofs of contract‐equipped Eiffel programs) to produce a failed test, which provides the programmer with immediately exploitable information to correct the program. The discussion presents Proof2Test and the application of the ideas and tool to a collection of representative examples.

Translation from Event-B into Eiffel

Formal modelling languages play a key role in the development of software: they enable users to specify functional requirements that serve as documentation as well; they enable users to prove the correctness of system properties, especially for critical systems. However, there is still an open question on how to map formal models to a specific programming language. In order to propose a solution, this paper presents a source-to-source mapping between Event-B models, a formal modelling language for reactive systems, and Eiffel programs, an Object Oriented (O-O) programming language. The mapping not only generates an actual Eiffel code of the Event-B model, but also translates model properties as contracts. The contracts follow the Design by Contract principle and are natively supported by the programming language. The mapping is implemented in the freely available Rodin plug-in EB2Eiffel. Thus, users can develop systems (i) starting with the modelling of functional requirements (properties) in Event-B, then (ii) formally proving the correctness of such properties in Rodin and finally (iii) by using EB2Eiffel to translate the model into Eiffel. In Eiffel, users can extend/customise the implementation of the model and formally prove it against the initial model. This paper also presents different Event-B models from the literature to test EB2Eiffel and its limitations. The article is published in the authors’ wording.

Some advances in tools and algorithms for the construction and analysis of systems

Because of the complexity of software systems and their increasing criticality, there is a pressing need for sophisticated and highly automated tools for the analysis of software artifacts and their expected behavioral properties. A growing body of research is using formal methods to produce increasingly powerful and scalable analysis tools, although several challenges still remain. We briefly outline some recent achievements in automated analysis represented by four selected papers from the 21st International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2015). Two of the selected papers describe major achievements in the field of parallel model checking. The third paper presents an auto-active theorem prover for the verification of Eiffel programs. The fourth paper reports on a non-trivial case study with hybrid automata and interactive theorem proving techniques.

Применимость AutoProof: учебный пример верификации ПО

Verification tools are often the result of several years of research effort. The development happens as a distributed effort inside academic institutes relying on the ability of senior investigators to ensure continuity. Quality attributes such as usability are unlikely to be targeted with the same accuracy required for commercial software where those factors make a financial difference. In order for such tools to become of widespread use, it is therefore necessary to spend an extra effort and attention on users' experience, and allow software engineers to benefit out of them without the necessity of understanding the mathematical machinery in full detail. In order to put the spotlight on usability of verification tools we chose an automated verifier for the Eiffel programming language, AutoProof, and a well-known benchmark, the Tokeneer problem. The tool is used to verify parts of the implementation of the Tokeneer so to identify AutoProof's strengths and weaknesses, and finally propose the necessary updates. The results show the efficacy of the tool in verifying a real piece of software and automatically discharging nearly two thirds of verification conditions. At the same time, the case study shows the demand for improved documentation and emphasizes the need for improvement in the tool itself and in the Eiffel IDE.

Q&A

The creator of the Eiffel programming language discusses his career in industry and academia, "Design by Contract," and his views on Agile software development.

A Framework for Adding Design by ContractTM to the .NET Object-Oriented Programming Languages.

Design contracts can be used in software development to ensure the preservation of assertions for program correctness. This can increase reliability in software design. Design by ContractTM (DBC) was developed by Bertrand Meyer and is supported by the Eiffel programming language. Eiffel provides support for checking preconditions, postconditions, and class invariants automatically at runtime. Even though DBC has been supported by Eiffel since 1985, other programming languages that offer built-in DBC support are still rare. Redundant efforts have taken place to implement the support of DBC for different object-oriented programming languages. This paper presents the design and implementation of a framework for extending object-oriented programming languages to support DBC. The framework can eliminate the redundant effort for various languages by simplifying the addition of DBC mechanisms for programming language developers.

Cameo: an alternative model of concurrency for Eiffel

Abstract We present a new concurrency model for the Eiffel programming language. The model is motivated by describing a number of semantic problems with the leading concurrency model for Eiffel, namely SCOOP. Our alternative model aims to preserve the existing behaviour of sequential programs and libraries wherever possible. Comparison with the SCOOP model is made. The concurrency aspects of the alternative model are presented in CSP along with a model of exceptions. The results show that while the new model provides increased parallelism, this comes with the price of increased overhead due to lock management.

Contract Specification in Java: Classification, Characterization, and a New Marker Method

Design by Contract (DBC), originated in the Eiffel programming language, is generally accepted as a practical method for building reliable software. Currently, however, few languages have built-in support for it. In recent years, several methods have been proposed to support DBC in Java. We compare eleven DBC tools for Java by analyzing their impact on the developer's programming activities, which are characterized by seven quality attributes identified in this paper. It is shown that each of the existing tools fails to achieve some of the quality attributes. This motivates us to develop ezContract, an open source DBC tool for Java that achieves all of the seven quality attributes. ezContract achieves streamlined integration with the working environment. Notably, standard Java language is used and advanced IDE features that work for standard Java programs can also work for the contract-enabled programs. Such features include incremental compilation, automatic refactoring, and code assist.

Contracts for concurrency

AbstractThe SCOOP model extends the Eiffel programming language to provide support for concurrent programming. The model is based on the principles of Design by Contract. The semantics of contracts used in the original proposal (SCOOP_97) is not suitable for concurrent programming because it restricts parallelism and complicates reasoning about program correctness. This article outlines a new contract semantics which applies equally well in concurrent and sequential contexts and permits a flexible use of contracts for specifying the mutual rights and obligations of clients and suppliers while preserving the potential for parallelism. We argue that it is indeed a generalisation of the traditional correctness semantics. We also propose a proof technique for concurrent programs which supports proofs—similar to those for traditional non-concurrent programs—of partial correctness and loop termination in the presence of asynchrony.

Reflecting on an Existing Programming Language.

Reflection has proven to be a valuable asset for programming languages, especially object-oriented ones, by promoting adaptability and extensibility of programs. With more and more applications exceeding the boundary of a single address space, reflection comes in very handy for instance for performing conformance tests dynamically. The precise incentives and thus mechanisms for reflection vary strongly between its incarnations, depending on the semantics of the considered programming language, the architecture of its runtime environment, safety and security concerns, etc. Another strongly influential factor is legacy, i.e., the point in time at which the corresponding reflection mechanisms are added to the language. This parameter tends to dictate the feasible breadth of the features offered by an implementation of reflection. This paper describes a pragmatic approach to reflection, consisting in adding introspection to an existing object-oriented programming language a posteriori, i.e., without extending the programming language, compiler, or runtime environment in any specific manner. The approach consists in a pre-compiler generating specific code for types which are to be made introspectable, and an API through which this code is accessed. We present two variants of our approach, namely a homogeneous approach (for type systems with a universal root type) and a heterogeneous approach (without universal root type), and the corresponding generators. We discuss limitations such as infinite recursion, and compare the code generated with these two approaches by Erl-G, a reflection library generator for the Eiffel programming language, thereby quantifying the benefits of a universal root type. Erl-G is being used by several tools for development in Eiffel.

Composing atomic features

SCOOP (Simple Concurrent Object-Oriented Programming) is a model of concurrency that builds on the concept of contracts for synchronizing accesses to objects. This model is based on a pessimistic concurrency control scheme whose reservation semantics avoids race conditions altogether — alas at the expense of parallelism. In this paper we propose to extend the initial SCOOP model by adding transactional semantics, aspiring to an increase of performance but also reliability of distributed object-oriented programs executing in the presence of partial failures. Our solution consists in programming language support for the specification of atomicity properties of particular features (routines or attributes). With such support, the application programmer is assisted by the compiler in composing atomic features, which substantially alleviates the task of constructing reliable distributed software. We investigate the impact of concepts such as nesting, inheritance, polymorphism, and contracts in such a statically typed approach, illustrated in the context of the Eiffel programming language. In particular, we depict how our solution enables the composition of atomic features from not only elementary atomic features (such as updates applied to variables which can be rolled back — backward recovery) but also from non-atomic ones by making use of compensation mechanisms (forward recovery).

ERC – An object-oriented refinement calculus for Eiffel

Abstract. We present a refinement calculus for transforming object-oriented (OO) specifications (or ‘contracts’) of classes into executable Eiffel programs. The calculus includes the usual collection of algorithmic refinement rules for assignments, if-statements, and loops. However, the calculus also deals with some of the specific challenges of OO, namely rules for introducing feature calls and reference types (involving aliasing). The refinement process is compositional in the sense that a class specification is refined to code based only on the specifications (not the implementations) of the classes that the specification depends upon. We discuss how automated support for such a process can be developed based on existing tools. This work is done in the context of a larger project involving methods for the seamless design of OO software in the graphical design notation BON (akin to UML). The goal is to maintain model and source code integrity, i.e., the software developer can work on either the model or the code, where (ideally) changes in one view are reflected instantaneously and automatically in all views.

A Proposal for Making Eiffel Type-safe

Statically type-correct Eiffel programs may produce run-time errors because (1) attributes may be redeclared during inheritance, invalidating assignments in the superclass, (2) a formal method argument type may be restricted in violation of the contravariance of function types, and (3) two applications of a generic class are assumed to conform if the actual arguments conform. The third problem is solved by case analysis on the variance of generic parameters. Declaration by association provides a solution to the first two problems, but is suffers from additional difficulties. Type attributes, or generic parameters with default values, are suggested as a replacement for most cases of declaration by association. The special association type used to express type recursion cannot be explained using type attributes, and its appears to be a truly novel construct for typing object-oriented programs. One consequence of this construct is that Eiffel's conformance hierarchy is a proper subset of its inheritance hierarchy.

Eiffel : A language and environment for software engineering

The Eiffel language and environment address the problem of building quality software in practical development environments. Two software quality factors were deemed essential in the design of the language: reusability and reliability. They led to the following choices: language features that support the underlying bottom-up software design methodology; modular structures based on the object-oriented approach, with support for both generic parameters and multiple inheritance (including a new extension, repeated inheritance); automatic storage management; highly dynamic execution model; support for polymorphism and dynamic binding; fully static typing; information hiding facilities; assertions and invariants that may be monitored at run-time. The Eiffel programming environment, using C as an intermediate language, supports separate compilation of classes and achieves a good run-time performance in both space and time. The environment takes care of automatically recompiling classes as needed after a change, ensuring that only up-to-date versions of classes are used, but avoiding unnecessary recompilations. A set of tools is provided to support the development of sizable software systems. An important part of the environment is the library of reusable classes. Significant extracts of this library are given in the appendix to this article, providing a set of model reusable software components, carefully designed for robustness and extendibility.