1 Eiffel in Depth Bertrand Meyer Emmanuel Stapf (Eiffel Software) Pei Yu & members of the ETH Chair of Software Engineering Chair of Software Engineering 2 Plan of these slides 1 Overview 2 The environment(s) 3 Method overview 4 Language basics 5 Dynamic model 6 Genericity & inheritance 7 Design by Contract™ 8 External interface 9 Agents 10 Advanced design 11 Advanced mechanisms 12 Conclusion 13 Supplements 3 Course organization Course page: http://se.inf.ethz.ch/teaching/2009-H/eiffel-0291/index.html Teaching staff: Lecturer: Bertrand Meyer & members of the Chair of Software Engineering Course assistant: Yu (Max) Pei Grading: 70% project, 30% exam Project will be a web-based system using the new EiffelWeb Exam will be on last lecture slot of the semester: 15 Dec. 4 Purpose of this course To give you an in-depth understanding of a software method, language and environment: Eiffel (and EiffelStudio) To improve your understanding of software engineering and software architecture To give you a feel for the challenges involved in both software design and language design 5 The software of the future Product quality Correctness Robustness Security Process quality Fast development No semantic gap (“impedance mismatch”) between developers and other stakeholders Self-validating, self-testing Ease of change Reusability 6 - 1 - Overview
16
Embed
Chair of - ETH Zse.inf.ethz.ch/old/teaching/2009-H/eiffel-0291/slides/Lec.01-02.pdf¾Lecturer: Bertrand Meyer & members of the Chair of Software Engineering ¾Course assistant: Yu
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Eiffel in Depth
Bertrand Meyer
Emmanuel Stapf (Eiffel Software)
Pei Yu
& members of the ETH Chair of Software Engineering
Chair ofSoftware Engineering
2
Plan of these slides
1 Overview2 The environment(s)3 Method overview4 Language basics5 Dynamic model6 Genericity &
Eiffel 3, 1990-1992 (Eiffel: The Language)Basic types as classes, infix & prefix operators…
Eiffel 4, 1997“Precursor” and agents
Eiffel 5, ECMA Standard, 2005, revised 2006, and ISO standard, November 2006www.ecma-international.org/publications/standards/Ecma-367.htm
Attached types, conversion, assigner commands…
9
Eiffel: Method, Language, EnvironmentMethod :
Applicable throughout the lifecycleObject-oriented to the coreSeamless developmentBased on Design by Contract™ principles
Language :Full power of object technologySimple yet powerful, numerous original featuresISO standard (2006)
Environment :Integrated, provides single solution, including analysis and modelingLots of platforms (Unix, Windows, VMS, .NET…)Open and interoperable
10
Some typical users
Axa RosenbergInvestment management: from $2 billion to >$100 billion
2 million linesChicago Board of Trade
Price reporting systemEiffel + CORBA +
Solaris + Windows + …Xontech (for Boeing)
Large-scale simulationsof missile defense
Northrop-Grumman
Swedish social security: accident reporting & management
(Eiffel) Price Reporting System
The Chicago Board of Trade
See: eiffel.com
11
Learning Eiffel
Simple syntax, no cryptic symbolsEiffel programmers know all of Eiffel
Wide variety of user backgrounds“If you can write a conditional,you can write a contract”
Fast learning curveLots of good models to learn fromStrong style rules
May need to “unlearn” needless tricks
12
The Eiffel method: some principles
AbstractionInformation hidingSeamlessnessReversibilityDesign by ContractOpen-Closed principleSingle choice principleSingle model principleUniform access principleCommand-query separation principleOption-operand separation principleStyle matters ... See next...
3
13
The Eiffel language
ClassesUniform type system, covering basic typesGenericityInheritance, single and multipleConversionCovarianceStatically typedBuilt-in Design by Contract mechanismsAgents: objects encapsulating behavior“Once” mechanisms, replacing statics and globalsVoid safety (new!)
14
Libraries
Fundamental data structures and algorithms
Portable graphics
Internet, Web
Lexical analysis, parsing
Database interfaces
15
Dogmatism and flexibility
Dogmatic where it counts:
Information hiding (e.g. no x.a := b)Overloading“One good way to do anything”Style rules
Flexible when it makes no point to harass programmers:Give standard notations (e.g. a + b) an O-O interpretationSyntax, e.g. semicolon
16
The Eiffel language: there is a hidden agenda
That you forget it even exists
17
- 2 -
The environment
18
EiffelStudio
Serialization
EiffelStore
EiffelStudio
Ansi C
Executable system
IL
EiffelBase
WEL
EiffelVision
EiffelNet
EiffelWeb
EiffelMath
EiffelCOM
Persistent objects
Eiffel Runtime
Databases (Rel, OO)
C compilation
JitterEiffel compilation
User classes
General library
Win32 library
Networking
Web development
Advanced numerics
External C/C++/Java
.NET Assemblies
EiffelBuild
GUI builder
Multiplatform GUI library
Browsing, fast compiling (Melting Ice™), debugging, diagrams, metrics...
4
19
EiffelStudio: Melting Ice™ Technology
Fast recompilation: time depends on size of change, not size of program
Full type checking
“Freeze” once in a while
Optimized compilation: finalize.
Small program
Large program
Smallchange
Bigchange
20
Melting Ice Technology
FROZEN
MELTED
EiffelStudio Your system
Machine code(from C code)
Edit, browse, execute,debug, test…
Freeze
Melt
21
Performance“Finalization” mode of compilation applies extensive optimizations:
InliningDead code removalContract removal...
Optimizations are compiler-applied and automatic; no need for manual hacking
Compacting garbage collection takes care of memory issues
Intended to match the most exacting demands of industry applications
22
EiffelStudio browsing and debugging
You are dealing with “development objects”:
ClassesFeaturesRun-time objects (for debugging)
To work on an object, “pick-and-drop” it into an appropriate tool
23
Openness
Eiffel can be used as “component combinator” to package elements from different sources:
Mechanisms for integrating elements in C, C++, Java, CIL (.NET)Interfaces and libraries: SQL, XML, UML (XMI), CORBA, COM, othersParticularly sophisticated mechanisms for C/C++ interfacingOutside of .NET, compiles down to ANSI C code, facilitates support for C and C++ easier.On .NET, seamless integration with C#, VB .NET etc.
24
C/C++ support
Functions, macros, include files, setters, getters, constructors, destructors etc.
Inline C
From the outside into Eiffel:CECIL (C-Eiffel Common Interface Library)
5
25
Portability
Source-code portability across:
Windows NT, 2000, XP, VistaWindows 98, Me.NETSolaris, other commercial Unix variantsLinuxMac OS X (forthcoming)BSD (Berkeley System Distribution)VMS
26
- 3 -
The method
27
The waterfall model of the lifecycle
Feasibility study
Requirements
Global design
Detailed design
Deployment
V & V
Specification
Implementation
28
Traditional lifecycle model
Rigid model:Waterfall: separate tasks,impedance mismatchesVariants, e.g. spiral, retainsome of the problems
Separate tools:Programming environmentAnalysis & design tools, e.g. UML
Consequences:Hard to keep model, implementation,documentation consistent Constantly reconciling viewsInflexible, hard to maintain systemsHard to accommodate bouts of late wisdomWastes effortsDamages quality
Feasibility study
Requirements
Global design
Detailed design
Deployment
V & V
Specification
Implementation
29
The Eiffel model
Seamless development:Single notation, tools,
concepts, principles throughout Eiffel is as much for analysis &
design as implementation & maintenance
Continuous, incremental development
Keep model, implementation and documentation consistent
Reversibility: go back & forthSaves money: invest in single
set of toolsBoosts quality
Example classes:
PLANE, ACCOUNT, TRANSACTION…
STATE, COMMAND…
HASH_TABLE…
TEST_DRIVER…
TABLE…
Analysis
Design
Implemen-tation
V&V
Generali-zation
30
Seamlessness
Seamlessness Principle
Software development should relyon a single set of notations & tools
6
31
Reversibility
Reversibility Principle
The software development process,notations and tools
should allow making changesat any step in the process
Use a single base for everything: analysis, design, implementation, documentation...
Use tools to extract the appropriate views.
Single Model Principle
All the informationabout a software system
should be in the software text
35
The seamless, reversible model
Analysis
Design
Implemen-tation
V&V
Generali-zation
36
Generalization
Prepare for reuse:Remove built-in limitsRemove dependencies on specifics of projectImprove documentation, contracts...Abstract Extract commonalities, revamp inheritance hierarchy
36
A D I V G
A *
B
Y *
X Z
T
U
7
37
The cluster model
A
D
I
V
G
Permits dynamic reconfiguration
A
D
I
V
G
A
D
I
V
G
A
D
I
V
G
A
D
I
V
G
A
D
I
V
G
Mix of sequential and concurrent engineering
38
Tool support for seamless development
Diagram Tool• System diagrams can be produced automatically from software text
• Works both ways: update diagrams or update text – other view immediately updated
No need for separate UML toolMetrics ToolProfiler ToolDocumentation generation tool...
39
EiffelStudio diagram tool
40
Text-graphics equivalence
41
Equivalence
Equivalence Principle
Textual, graphical and other viewsshould all represent the same model
42
Eiffel mechanisms
Classes, objects, ...Single and multiple inheritanceInheritance facilities: redefinition, undefinition, renamingGenericity, constrained and unconstrainedSafe covarianceDisciplined exception handling, based on principles of Design by ContractFull GCAgents (power of functional programming in O-O!)Unrestricted streaming: files, databases, networks...
8
43
What is not in Eiffel
GotoFunctions as argumentsPointer arithmeticSpecial increment syntax, e.g. x++, ++x
In-class feature overloading
44
Syntax conventions
Semicolon used as a separator (not terminator)It’s optional almost all the time. Just forget about it!
Style rules are an important part of Eiffel:Every feature should have a header commentEvery class should have an indexing clauseLayout, indentationChoice of names for classes and features
45
The class
From the module viewpoint: Set of available services (“features”)Information hidingClasses may be clients of each other
From the type viewpoint: Describes a set of run-time objects (the instances of the class)Used to declare variables (more generally, entities ), e.g.
x : CPossible type checking Notion of subtype
46
Information hiding
Information Hiding principle
Every module should have a publicspecification,
listing a subset of its properties
47
prepend
animateappend
An object has an interface
count stations
first last
48
prepend
animateappend
count
first
An object has an implementation
count stations
first last
9
49
Information hiding
prepend
animateappend
count stations
first last
50
Information Hiding
The designer of every module must select a subset of its properties as the official information about the module, made available to authors of client modules
Public
Private
51
Uniform access
Uniform access principle
It does not matter to the clientwhether you look up or compute
If a system supports a set of choices,only one of its elements should know the list
63
Single choice: examples
Graphic system: set of figures
Editor: set of commands
Compiler: set of language constructs
Single choice principle
If a system supports a set of choices,only one of its elements should know the list
64
Without dynamic binding!
display (f : FIGURE)do
if ‘‘f is a CIRCLE’’ then...
elseif ‘‘f is a POLYGON’’ then...
endend
and similarly for all other routines!
Tedious; must be changed whenever there’s a new figure type
65
With inheritance &associated techniques
f : FIGUREc : CIRCLEp : POLYGON
create c.make (...)create p.make (...)
if ... thenf := c
elsef := p
end
f.move (...)f.rotate (...)f.display (...)
-- and so on for every-- operation on f !
With:
Initialize:
and:
Then just use:
66
Memory management
Memory management principle
It is the implementation’s responsibilityto reclaim unused objects
12
67
What to do with unreachable objects
Reference assignmentsmay make some objects useless.
Two possible approaches:Manual “free” (C++).Automatic garbage collection
“Almaviva”namelandlor
dloved_one
aO1
“Figaro”O2
“Susanna”O3
68
The C programmer’s view
Newsgroup posting by Ian Stephenson, 1993 (as cited inObject-Oriented Software Construction, 2nd edition):
I say a big NO ! Leaving an unreferencedobject around is BAD PROGRAMMING.Object pointers ARE like ordinary pointers —if you allocate an object you should beresponsible for it, and free it when itsfinished with. (Didn't your mother always tellyou to put your toys away when you'dfinished with them?)
69
Arguments for automatic collection
Manual reclamation is dangerous for reliability.
Wrong “frees” are among the most difficult bugs to detect and correct.
Manual reclamation is tedious.
Modern garbage collectors have acceptable performance overhead.
GC is tunable: disabling, activation, parameterization....
70
Properties of a garbage collector (GC)
Soundness: If the GC reclaims an object, it is unreachableCompleteness : If an object is unreachable, the GC will reclaim it
Soundness is an absolute requirement. Better no GC than an unsound GC
But: safe automatic garbage collection is hard in C-based languages
71
Language style
Consistency principle
The language should offerone good way to do anything useful
72
Language style
Compatibility principle
Traditional notations should be supportedwith an O-O semantics
13
73
Infix and prefix operators
In
a bthe operator is “infix”
(written between operands)
In
bthe operator is “prefix”
(written before the operand)
74
The object-oriented form of call
some_target.some_feature (some_arguments)
For example:
my_figure.display
my_figure.move (3, 5)
x := a.plus (b) ???????
75
Operator features
expanded class INTEGER feature
plus alias "+" (other : INTEGER): INTEGER-- Sum with other
do ... end
times alias " " (other : INTEGER): INTEGER-- Product by other
do ... end
minus alias "-" : INTEGER-- Unary minus
do ... end...end
Calls such as i.plus ( j ) can now be written i + j
76
Assignment commands
It is possible to define a query as
temperature: REAL assign set_temperature
Then the syntaxx.temperature := 21.5
is accepted as an abbreviation for
x.set_temperature(21.5)
Retains contracts and any other supplementary operations
Not an assignment, but a procedure call
77
Command-query separation
Command-Query Separation Principle
A function must not changeits target object’s state
78
Command-Query separation
A command (procedure) does something but does not return a result.
A query (function or attribute) returns a result but does not change the state.
14
79
Command-Query Separation
Asking a questionshould not change the answer!
80
Command-query separation
Command-Query Separation Principle
A function must not changeits target object’s state
This principle excludes many common schemes, such as using functions for input (e.g. C’s getint or equivalent).
81
Referential transparency
If two expressions have equal value, one may besubstituted for the other in any context where that otheris valid.
If a = b, then f (a) = f (b) for any f. Prohibits functions with side effects. Also:
For any integer i, normally i + i = 2 x iBut even if getint () = 2, getint () + getint () is usually not equal to 4.
82
Command-query separation
Input mechanism using EiffelBase(instead of n := getint ()):
io.read_integer
n := io.last_integer
83
A discipline of development
Reuse Principle
Design with reuse in mind
84
Typical API in a traditional library (NAG)
nonlinear_ode(equation_count : in INTEGER;epsilon : in out DOUBLE;func : procedure
(eq_count : INTEGER; a : DOUBLE; eps : DOUBLE; b : ARRAY [DOUBLE];cm : pointer Libtype);
left_count, coupled_count : INTEGER …)
[And so on. Altogether 19 arguments, including:• 4 in out values;• 3 arrays, used both as input and output;• 6 functions, each with 6 or 7 arguments, of which
2 or 3 arrays!]
Ordinary differential
equation
15
85
The EiffelMath routine
... Create e and set-up its values (other than defaults) ...
e.solve
... Answer available in e.x and e.y ...
86
The Consistency Principle
Two components: Top-down and deductive (the overall design).Bottom-up and inductive (the conventions).
Consistency Principle
All the components of a libraryshould proceed from an overallcoherent design, and followa set of systematic, explicit
and uniform conventions.
87
The key to building a library
Devising a theory of the underlying domain
88
Some of the theory behind EiffelBase
CONTAINER
BOX
FINITE INFINITE
BOUNDED UNBOUNDED
FIXED RESIZABLE
COLLECTION
BAG SET
TABLE ACTIVE SUBSET
DISPENSERINDEXABLE CURSOR_STRUCTURE SEQUENCE
TRAVERSABLE
HIERAR_CHICAL LINEAR
BILINEAR
*
* * *
*
*
*
*
* *
* * * * * *
* * * * * *
COUNTABLE*
RepresentationAccess
Iteration
89
The size of feature interfaces
More relevant than class size for assessing complexity.
Statistics from EiffelBase and associated libraries:
Number of features 4408
Percentage of queries 66%
Percentage of commands 34%
Average number of arguments to a feature 0.5
Maximum number 5
No arguments 57%
One argument 36%
Two arguments 6%
Three or more arguments 1%90
Operands and options
Two possible kinds of argument to a feature: Operands: values on which feature will operateOptions: modes that govern how feature will operate
Example (non-O-O): printing a real numberprint (real_value, number_of_significant_digits,
zone_length, number_of_exponent_digits, ...)The number is an operand; format properties (e.g. number of significant digits, width) are options