 |
 |
 |
|
|
|||
Eiffel in a NutshellHere is what everyone needs to know about Eiffel. You'll find lots more details in the rest of these Web pages. For the busiest of the busiest there is also the 1-minute summary. After reading the present page you can use the complete Eiffel page to find links to many more detailed entries. What is Eiffel?
Good question. Answering "an object-oriented language" is correct, but only part of the story. Eiffel is the only O-O language that also includes a comprehensive approach to software construction: a method, and an environment (EiffelStudio). The language itself is not just a programming language but also covers analysis, design and implementation. What are the goals of Eiffel?
Eiffel pursues four major goals: What's so great about Eiffel?
In a few words: In even fewer words: Eiffel has a single purpose -- to help you complete your software faster, better, and at lower cost. Is Eiffel intended for any specific application area?
Not really. Eiffel has been used in many application areas, from financial applications to telecommunication systems. It is also widely used for teaching purposes. Eiffel shines particularly for ambitious systems that must be easy to adapt to changing market demands. With Eiffel you can quickly produce a basic version of a system, reliable and efficient, put it into users' hands early (while the competition is still trying to produce a "prototype"), and come up with new releases rapidly, all the time maintaining the standards of robustness that are the hallmark of the approach. Eiffel scales up. Many a 500,000-line system started as a 50,000-line program. Through its abstraction and structuring facilities, Eiffel is one of the few environments that won't let you down when your project grows in size, scope and ambition. OK, for a particular platform then?
Eiffel Software's EiffelStudio environment is available for the major industry platforms: Windows (95, 98, ME, NT, 2000, XP), Linux, Unix (Solaris, SunOS, HP 9000, IBM AIX, Unixware, Silicon Graphics, Data General, Fujitsu, DEC OSF/1 etc.), VMS (Alpha as well as Vax). These implementations are all source-code compatible, making Eiffel one of the most portable software development environments available today. Must I forsake my existing software investment?
Eiffel makes it possible to move to modern software technology while reusing the best results of earlier practices. What about run-time performance?
Eiffel Software's EiffelStudio environment has shown that it is possible to utilize the full power of modern object technology without sacrificing run-time performance. Various benchmarks show run-time efficiency similar to C and Fortran, and in some cases better. Some problems still remain for certain kinds of intensive array computation, where optimizations are currently being implemented. For the vast majority of applications, performance is one more reason to use Eiffel. What is the "Melting Ice Technology"?
This trademarked name describes Eiffel Software's unique incremental compilation technology, which combines compilation (for the generation of optimally efficient code) with bytecode interpretation (for fast turnaround after a change). The bulk of your software, including precompiled libraries, is "frozen", i.e. compiled; what you change gets "melted", i.e. the compiler will quickly generate some interpretable "bytecode" and stop there, making sure that the frozen part calls the melted part (and conversely) when appropriate. Is it true that Eiffel compiles into C?
Actually, the Eiffel compiler generates, as just noted, an internal form known as the "bytecode". The bytecode, as was also noted, can be interpreted directly. But it can also be translated into other forms. To generate the final version of a system, the bytecode is optimized and translated into C, to take advantage of the presence of C compilers on just about every platform under the sun. This is the process known as "finalization", which performs extensive optimizations (routine inlining, static calls, array optimization), permitting the performance achievements mentioned above. Using C as an intermediate language takes advantage of the optimizations performed by C compilers and, most importantly, facilitates interoperability of Eiffel software and software written in C and C++. What's Eiffel written in?
In Eiffel, of course. It is an example of a modern, ambitious system whose sophistication and flexibility require the best method, language and environment. What about graphics?
Eiffel offers a choice of graphical libraries. For portable developments, use EiffelVision, a high-level graphical library covering user interface objects (windows, dialogs, menus, buttons, dialog boxes etc.) as well as geometrical figures (polygons, circles and the like), which will run on all the supported platforms, adapting in each case to the native look-and-feel. For platform-specific developments, to take advantage of the full set of "controls" or "widgets" available on a particular window system, use the platform-specific libraries: Using EiffelVision or one of the platform-specific libraries is not an exclusive proposition: you can mix-and-match the two levels, using EiffelVision for its abstract capabilities and, for example, WEL to take advantage of specific Windows controls. In fact, EiffelVision internally relies, for its implementation on each platform, on the corresponding platform-specific library, so you already have WEL if you are using EiffelVision on Windows. What about relational databases?
Eiffel Software provides the EiffelStore library for object-relational interfaces, with mappings currently available for ODBC (giving access to many dozens of database systems on Windows), Oracle, Sybase and Ingres. Eiffel has also been interfaced with such object-oriented databases as Matisse (interface available from Eiffel Software), Versant and O2. What does the environment look like?
It is described in detail elsewhere in these Web pages, but let's just say that EiffelStudio is a fully graphical environment that includes all you would expect and more: analysis and design workbench with reverse engineering (sometimes called "round-trip engineering"), fast recompilation, editing, sophisticated browsing facilities, automatic documentation (see for example the descriptions of the "short form" below), an advanced debugging mechanism etc. Just as an illustration, without further explanations (which you will find by browsing around our pages), here is a screen from a debugging session:
What does an Eiffel program look like?
Actually we like to talk about "systems". A system is a set of classes, each covering a "data abstraction", that is to say a certain set of objects, from the external world or from the implementation. For example you may have classes AIRPORT, RADAR and RUNWAY in a flight control system, classes CUSTOMER and ACCOUNT in a banking system. In any system you can also have general-purpose classes such as LINKED_LIST and HASH_TABLE, although you would not normally write them but reuse them from a library such as EiffelBase. What does a class look like?
Here is the outline of a simple class COUNTER describing a counter: indexing class feature -- Access item: INTEGER feature -- Element change increment is decrement is reset is end At run time this class will have instances: each instance is an object that represents a separate counter. To create a counter you declare the corresponding entity, say my_counter: COUNTER create the corresponding object create my_counter (where create is the object creation operation), and can then apply to it the operations of the class (its features): my_counter.increment Such operations will appear in features of other classes, called the clients of class COUNTER. If you understand this example, you already know a fair deal of Eiffel! Note how simple the syntax is. Semicolons between instructions are optional (they have been omitted above); no strange symbols, no complicated rules. A couple more comments about this example: all values are initialized by default, so every counter object will start its life with its value, item, initialized to zero (you don't need to call reset initially). Also, item is an attribute, which is exported in read-only mode: clients can say print (my_counter.item) but not, for example, my_counter.item := 657, which would be a violation of "information hiding". Of course the class author may decide to provide such a capability by adding a feature set (some_value: INTEGER) is in which case the clients will simply use my_counter.set (657). But that's the decision of the authors of class COUNTER: how much functionality they provide to their clients. The indexing clause at the beginning of the class does not affect its semantics (i.e. the properties of the corresponding run-time objects), but attaches extra documentation to the class. Such information can be used by tools to help developers search for reusable classes. It is good practice to include at least a description entry providing an informal description of the purpose of the class. A counter is great, but how do I write a real system?
The principles scale up. A class can represent a counter, but it can also represent an assembly line or a factory. The Eiffel mechanisms for abstraction, reliability and simplicity provide a power of expression unmatched in the software world. What about reusability?
As Roland Racko wrote in Software Development: "Everything about Eiffel is single-mindedly, unambiguously, gloriously focused on reusability -- right down to the choice of reserved words and punctuation and right up to the compile time environment". We couldn't say it better. Eiffel was designed from day one to be the vehicle for the new software industry, based on the reuse of high-quality components -- rather than on everyone reinventing the wheel all the time. Eiffel has put these ideas into practice by providing a rich set of professional reusable libraries (several thousand carefully crafted classes): EiffelBase, EiffelVision, EiffelNet, EiffelWeb, EiffelParse, EiffelLex, WEL, MEL, PEL etc. What's this "Design by Contract" thing?
A revolutionary concept for building reliable software, introduced by Eiffel and only implemented in Eiffel. The basic idea is that to build reliable software it does not suffice to "be careful" and put all kinds of checks all over the text; a more systematic engineering approach is essential. You view your system as being made of a number of complementary components -- Eiffel's classes -- which cooperate on the basis of precisely defined statements of mutual obligations and benefits: contracts, as in contracts between two businesses. Alone in design methodologies and languages, Eiffel directly enforces Design by Contract through constructs such as class invariants, preconditions and postconditions. Assume for example that we want our counters to be always non-negative. The class will now have an invariant: indexing ... class and feature decrement now needs a precondition, to make sure that clients do not attempt illegal operations. The keyword require introduces the precondition: decrement is The keyword The precondition tells the client: The postcondition says: The invariant adds the promise that Preconditions, postconditions and invariants are called assertions. Assertions, of course, go far beyond simple properties of integers. For example: So the assertions state the semantic properties of the software and the external systems it models, independently of the implementation. Ironically, this gives Eiffel software, even though it is executable on a computer, more abstract expressive power than many analysis and design methodologies, which are unable to capture such semantic properties precisely. Elsewhere in these pages you will find a more detailed presentation of Design by Contract as part of the on-line Eiffel technology papers. Assertions look nice, but how do they help me?
Assertions radically change the nature of software development. They have three major applications: indexing class interface feature -- Access item: INTEGER feature -- Element change increment is decrement is reset is invariant In the EiffelStudio environment, you get the short form at the click of a button. The short form is an ideal form of documentation: abstract yet precise; and best of all, produced by the environment, not written separately, so you don't need to do any work to get it! No more need to write "interface modules" and then repeat their information in the implementation part. What about inheritance?
Eiffel offers a sophisticated yet easy-to-use form of inheritance, enabling you to build new classes based on others. You might for example start from a class describing vehicles to write a class describing cars: indexing class inherit VEHICLE feature -- Element change register (registration_date: DATE) is end Does Eiffel support multiple inheritance?
Yes. A class can inherit from as many parents as necessary; for example a class COMPANY_PLANE will inherit from PLANE (describing the pilot's and passengers' view) and from ASSET (describing the accountant's view). In the Eiffel Library Kernel Standard, class NUMERIC describes objects equipped with arithmetic operations ("+", "-", "*", "/"); class COMPARABLE describes objects equipped with comparison operations ("<", "<=" etc.); then classes such as INTEGER and REAL inherit from both NUMERIC and COMPARABLE. But isn't multiple inheritance complex and messy?
Not at all! Or to be more precise, not if it is done right. You will need multiple inheritance whenever you have to combine different abstractions, as in the preceding two examples and countless others. Eiffel tames the power of multiple inheritance through a renaming mechanism, which eliminates name clashes, and through a selection facility to remove any ambiguities resulting from multiple redeclarations. Without multiple inheritance you would lose much of the reusability benefits of the object-oriented method. For example not all comparable elements are numeric (think of strings) and not all numeric elements are comparable (think of matrices). Without multiple inheritance you would not be able to select one of these properties when you need to, and both when you need to. What about repeated inheritance?
Tell me about typing and binding.
Eiffel is statically typed to ensure that errors are caught at compile time, not run time. For example if your system may mistakenly try to execute a request to compute the diagonal of a graphical object that happens to be a triangle, the Eiffel compiler will catch the error before it has had time to cause any damage. Most other object-oriented languages use some degree of "dynamic typing" in which such errors can escape the compiler. (Beware in particular of C extensions that are sometimes advertized as statically typed but still permit almost arbitrary type conversions.) Eiffel is dynamically bound to guarantee that the right version of an operation will always be applied depending on the target object. For example if you apply the feature "take off" to an object representing some kind of plane, you have the guarantee that if there are several plane types, each with its own take_off feature, the appropriate one will always be automatically selected. (In contrast, some approaches by default use "static binding", which can result in disastrously incorrect behavior.) What is BON?
The Business Object Notation, an analysis and design method that is based on concepts close to those of Eiffel (Seamlessness, Reversibility, Contracting) and defines simple, intuitive graphical conventions. BON is particularly notable for its ability to scale up when you need to describe large and complex systems, keeping a view of the whole while zooming into the details of components at various levels of abstraction. Like many of the other concepts summarized here, BON has its own page; the method is described in a widely acclaimed book by the authors of the method. Eiffel Software's EiffelCase (now the Diagram Tool within EiffelStudio) analysis and design workbench directly supports BON. How did Eiffel come about, and what is its history?
Eiffel was designed at Eiffel Software (then known as ISE) in 1985, initially as an internal tool to develop some of our products. We wanted a modern, object-oriented environment integrating the concepts of modern software engineering, and there was simply nothing available. The Eiffel 1 environment was first demonstrated in public at the first OOPSLA conference in October of 1986 where it attracted considerable attention, leading us to release it as a commercial product at the end of 1986. The technology spread rapidly over the following years, leading to a set of successful industrial projects in the US, Canada, Europe and the Far East. Right from the beginning Eiffel also impressed the academic community as an ideal way to teach software concepts at all levels, leading to its adoption by numerous universities around the world as the primary teaching language. Successive versions of the environment appeared at the rate of about once a year. Eiffel recognition was given a large boost by the appearance in 1988 of the book Object-Oriented Software Construction by Bertrand Meyer, which quickly became the best-selling title in the field and was translated into eight foreign languages; the book used Eiffel as the natural vehicle to introduce concepts of object technology and Design by Contract. (The greatly expanded second edition is now available; you can find it in bookstores or order your copy from Eiffel Software.) The last iteration of the original technology was version 2.3, released in the Summer of 1990. The next version, Eiffel 3, resulted from the lessons of the initial version and was written entirely in Eiffel; it was bootstrapped from 2.3. Eiffel 3 introduced the Melting Ice Technology for fast recompilation, a fully graphical environment based on innovative user interface concepts, and considerable advances in libraries (graphics, networking...) and optimization of the generated code. The initial versions were available on Unix; since then they have been complemented by fully compatible releases on VMS, OS/2, Linux, and our best-selling Windows versions (Windows 3.1, Windows 95, Windows NT), making Eiffel one of the most widely portable solutions in the software industry. The latest milestones in Eiffel technology is Eiffel 5 and EiffelStudio, a major new advance described in detail in other web pages. By the way, where does the name come from?
When creating Eiffel in 1985, we decided to pay homage to one of the greatest engineers of all time: Gustave Eiffel, the man who built the eponymous Tower in Paris, but also a number of other durable constructions such as the metallic armature of the Statue of Liberty in New York, the Budapest railway station and many others. The Eiffel Tower, built in 1887 for the 1889 World Fair, was completed on time and within budget, as will software projects written in Eiffel. And if you look at that wonderful structure, you will see a small number of robust, elegant design patterns, combined and varied repeatedly to yield a powerful, efficient structure -- exactly like a great Eiffel system built out of Eiffel Software's reusable libraries. Like many software systems today, the Eiffel Tower was initially conceived as a temporary structure; and like many a system built with Eiffel , it was able to endure far beyond its original goals. What better symbol could there be of the engineering principles behind Eiffel? On to the complete Eiffel page. "Design by Contract" is a trademark of Eiffel Software In.
|
Repeated inheritance is the case, illustrated by the figure, in which a class inherits from another through two or more paths. Only in Eiffel can you decide separately for each feature of the common ancestor, such as birth_date or library_privileges in the example, whether it gives one feature or two in the repeated descendant. In the figure, a teaching assistant has the same birth date whether viewed as an instructor or as a student (one feature), but has different library privileges under each of these capacities (two features). This flexibility is indispensable to specify what you want to share and what you want to replicate.