Previous Table of Contents Next


Part IV
Eiffel

9  Eiffel

Chapter 9
Eiffel

by Bertrand Meyer

9.1. Eiffel Overview

Eiffel is a method and language for the efficient description and development of quality systems.

Eiffel is more than a programming language. It covers not just programming in the restricted sense of implementation but the whole spectrum of software development:

  Analysis, modeling, and specification, where Eiffel can be used as a purely descriptive tool to analyze and document the structure and properties of complex systems (even nonsoftware systems).
  Design and architecture, where Eiffel can be used to build solid, flexible system structures.
  Implementation, where Eiffel provides practical software solutions with an efficiency comparable to solutions based on such traditional approaches as C and Fortran.
  Maintenance, where Eiffel helps because of the architectural flexibility of the resulting systems.
  Documentation, where Eiffel permits automatic generation of documentation, textual and graphical, from the software itself, as a partial substitute for separately developed and maintained software documentation.

Although the language is the most visible part, Eiffel is best viewed as a method, which guides system analysts and developers through the process of software construction. The Eiffel method is focused on both productivity (the ability to produce systems on time and within budget) and quality, with particular emphasis on the following quality factors:

  Reliability—Producing bug-free systems, which perform as expected.
  Reusability—Making it possible to develop systems from prepackaged, high-quality components and to transform software elements into such reusable components for future reuse.
  Extendibility—Developing software that is truly soft—easy to adapt to the inevitable and frequent changes of requirements and other constraints.
  Portability—Freeing developers from machine and operating system peculiarities and enabling them to produce software that runs on many different platforms.
  Maintainability—Yielding software that is clear, readable, well structured, and easy to continue enhancing and adapting.

9.2. General Properties

Here is an overview of the facilities supported by Eiffel:

  Completely object-oriented (OO) approach—Eiffel is a full-fledged application of object technology, not a hybrid of OO and traditional concepts.
  External interfaces—Eiffel is a software composition tool and is easily interfaced with software written in lower-level languages such as C, C++, and Java.
  Full lifecycle support—Eiffel is applicable throughout the development process, including analysis, design, implementation, and maintenance.
  Classes as the basic structuring tool—A class is the description of a set of runtime objects, specified through the applicable operations and abstract properties. An Eiffel system is made entirely of classes, serving as the only module mechanism.
  Fully consistent type system—Every type is based on a class, including basic types such as integer, boolean, real, character, string, and array.
  Design by contract—Every system component can be accompanied by a precise specification of its abstract properties, governing its internal operation and its interaction with other components.
  Assertions—The method and notation support writing the logical properties of object states to express the terms of the contracts. These properties, known as assertions, can be monitored at runtime for testing and quality assurance. They also serve as a documentation mechanism. Assertions include preconditions, postconditions, class invariants, and loop invariants and are also used in check instructions.
  Exception handling—Abnormal conditions, such as unexpected operating system signals or more generally contract violations, can be caught and corrected.
  Information hiding—Each class author decides, for each feature, whether it is available to all client classes, to specific clients only, or for internal purposes only.
  Self-documentation—The notation is designed to enable environment tools to produce abstract views of classes and systems, textual or graphical, and is suitable for reusers, maintainers, and client authors.
  Inheritance—One can define a class as extension or specialization of others.
  Redefinition—An inherited feature (operation) can be given a different implementation or signature.
  Explicit redefinition—Any feature redefinition must be explicitly stated.
  Subcontracting—Redefinition rules require new assertions to be compatible with inherited ones.
  Deferred features and classes—It is possible for a feature, and the enclosing class, to be specified—including with assertions—but not implemented. Deferred classes are also known as abstract classes.
  Polymorphism—An entity (variable, argument, and so on) can become attached to objects of many different types.
  Dynamic binding—Calling a feature on an object always triggers the version of the feature specifically adapted to that object, even in the presence of polymorphism and redefinition.
  Static typing—A compiler can check statically that all type combinations are valid so that no runtime situation occurs in which an attempt is made to apply a nonexistent feature to an object.
  Assignment attempt (type narrowing)—It is possible to check at runtime whether the type of an object conforms to a certain expectation—for example, if the object comes from a database or a network.
  Multiple inheritance—A class can inherit from any number of others.
  Feature renaming—To remove name clashes under multiple inheritance, or to give better names locally, a class can give a new name to an inherited feature.
  Repeated inheritance: sharing and replication—If, as a result of multiple inheritance, a class inherits from another through two or more paths, the class author can specify, for each repeatedly inherited feature, that it yields either one feature (sharing) or two (replication).
  No ambiguity under repeated inheritance—Conflicting redefinitions under repeated inheritance are resolved through a selection mechanism.
  Unconstrained genericity—A class can be parameterized, or generic, to describe containers of objects of an arbitrary type.
  Constrained genericity—A generic class can be declared with a generic constraint to indicate that the corresponding types must satisfy some properties, such as the presence of a particular operation.
  Garbage collection—The dynamic model is designed so that memory reclamation, in a supporting environment, can be automatic rather than programmer-controlled.
  No-leak modular structure—All software is built out of classes, with only two interclass relations, client and inheritance.
  Once routines— A feature can be declared as once so that it is executed only for its first call, subsequently returning always the same result (if required). This serves as a convenient initialization mechanism and for shared objects.
  Standardized library—The kernel library, providing essential abstractions, is standardized across implementations.
  Other libraries—Eiffel development is largely based on high-quality libraries covering many common needs of software development, from general algorithms and data structures to networking and databases.


Previous Table of Contents Next