Eiffel in a NutshellHere is what everyone needs to know about ISE 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 ISE Eiffel?
The language itself is not just a programming language but also covers analysis, design and implementation. What are the goals of ISE Eiffel?
To lower your maintenance and support
costs by letting you produce bug-free software -- software that works the
first time around.
To allow you to react quickly to market
demands by producing software that is easy to change and extend in
response to user requests.
To preserve your investment by giving
you robust software that can be reused in many different developments.
What's so great about ISE Eiffel?
Its seamlessness, providing a single
thread throughout the software construction lifecycle.
The full application of object-oriented principles, distinguishing Eiffel from "hybrid" approaches. Eiffel's openness to the outside world, enabling it to serve a glue between software elements that may be written in many different languages (such as C or C++) besides those written in Eiffel. Its unique emphasis on reliability mechanisms, in particular through Eiffel's unique method of Design by ContractTM. Is Eiffel intended for any specific application area?
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 bug-free "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, ISE 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?
Must I forsake my existing software investment?
Calling C functions from Eiffel.
Accessing C++ classes and all their components
(functions or "methods", data members, constructors, destructors etc.)
from Eiffel.
Accessing Eiffel mechanisms from C or C++
through the Cecil library (C-Eiffel Call-In Library).
Automatically producing a "wrapper" Eiffel class from a C++ class. What about run-time performance?
What is the "Melting Ice Technology"?
Is it true that Eiffel compiles into C?
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 ISE Eiffel written in?
What about graphics?
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:
On OS/2, you can similarly use PEL (Presentation-manager
Eiffel Library), whose design is very close to WEL.
For Motif (Unix), use MEL, the Motif Eiffel Library. What about relational databases?
ISE Eiffel has also been interfaced with such object-oriented databases as Matisse (interface available from ISE), Versant and O2. What does the environment look like?
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?
What does a class look like?
description: "Counters that you can increment by one, decrement, and reset" class
feature -- Access
-- Counter's value.
-- Increase counter by one. do item := item + 1 end decrement is
reset is
... my_counter.increment ... my_counter.decrement ... print (my_counter.item) 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 value of counter to some_value. do item := some_value end A counter is great, but how do I write a real system?
The Eiffel mechanisms for abstraction, reliability and simplicity provide a power of expression unmatched in the software world. What about reusability?
ISE 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?
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:
COUNTER feature ... invariant item >= 0 end
-- Decrease counter by one. require item > 0 do item := item - 1 ensure item = old item - 1 end The precondition tells the client:
A precondition on a
file opening routine may express that the file must be readable.
A postcondition on
a paragraph justification routine may express that all lines will have
the same length.
An invariant on a class describing bank accounts may express that the current balance is equal to the sum of deposits minus the sum of withdrawals. 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 ISE Eiffel technology papers. Assertions look nice, but how do they help me?
Design aid.
By working with Design by Contract, you build software together with the
arguments that justify its correctness. This makes it much more realistic
to produce bug-free software.
Testing and debugging
mechanism. Using the ISE Eiffel compiler, you select which assertions
will be monitored at run time; you can set different levels (no check,
preconditions only, preconditions and postconditions, everything) separately
for each class. Then if an assertion is found at run time to be violated
-- meaning a bug remains in your software -- an exception will interrupt
execution. This is a tremendous help for getting software right quickly:
testing and debugging are no longer blind searches; they are helped by
a precise description both of what the software does (the actual executable
texts, given by the
do clauses)
and of what it should do (the assertions).
Documentation. To give the users of a class a precise description of what a class provides, without giving out implementation details, you use the Eiffel notion of the short form of a class, which keeps the feature headers and comments as well as their assertions, but discards any implementation stuff. For example:
description: "Counters that you can increment by one, decrement, and increment" class interface
feature -- Access
-- Counter's value.
-- Increase counter by one. ensure item = old item + 1 decrement is
reset is
item >= 0 end What about inheritance?
indexing
class
inherit
redefine register end
-- Register for one year starting from registration_date. do ... The specific operations for registering cars ... end Does Eiffel support multiple inheritance?
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?
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 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?
How did Eiffel come about, and what is its history?
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 ISE.) The last iteration of the original technology was version 2.3, released in the Summer of 1990. The next version, ISE Eiffel 3, resulted from the lessons of the initial version and was written entirely in Eiffel; it was bootstrapped from 2.3. ISE 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 ISE Eiffel one of the most widely portable solutions in the software industry. The latest milestones in Eiffel technology is ISE Eiffel 4, a major new advance described in detail in other web pages. By the way, where does the name come from?
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 ISE'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 ISE Eiffel? "Design by Contract" is a trademark of Interactive Software Engineering.
URL for this page: http://eiffel.com/eiffel/nutshell.html ©1999 Interactive Software Engineering, Inc. All rights reserved. |