Eiffel Programming Language Research Articles

Применимость 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).