Transcript se.inf.ethz.ch

Eiffel in Depth
Bertrand Meyer
With material by Emmanuel Stapf
(Eiffel Software)
& members of the ETH Chair of
Software Engineering
Chair of
Software Engineering
Plan of these slides
1
2
3
4
5
6
7
Overview
The environment(s)
Method overview
Language basics
Dynamic model
Genericity &
inheritance
Design by Contract™
 8 External interface
 9 Agents
 10 Advanced design
 11 Advanced mechanisms
 12 Conclusion
 13 Supplements
2
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
3
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
4
-1Overview
5
Why Eiffel?
Productivity: faster time to market, fewer developers
Reliability: fewer bugs
Extendibility: be responsive to customer needs
Reuse: stand on the shoulder of giants
Efficiency: make the best use of hardware resources
Maintainability: spend your time on new developments
6
Language versions
Eiffel 1, 1986
Classes, contracts, genericity, single and multiple
inheritance, garbage collection, …
Eiffel 2, 1988 (Object-Oriented Software Construction)
Exceptions, constrained 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 2006
www.ecma-international.org/publications/standards/Ecma-367.htm
Attached types, conversion, assigner commands…
7
Eiffel: Method, Language, Environment
Method :
Applicable throughout the lifecycle
 Object-oriented to the core
 Seamless development
 Based on Design by Contract™ principles
Language :
 Full power of object technology
 Simple yet powerful, numerous original features
 ISO standard (2006)
Environment :
 Integrated, provides single solution, including
analysis and modeling
 Lots of platforms (Unix, Windows, VMS, .NET…)
 Open and interoperable

8
Some typical users
Axa Rosenberg
Investment management: from $2 billion to >$100 billion
2 million lines
The Chicago Board of Trade
Chicago Board of Trade
Price reporting system
Eiffel + CORBA +
Solaris + Windows + …
Xontech (for Boeing)
(Eiffel) Price
Large-scale simulations
Reporting System
of missile defense
Northrop-Grumman
See:
eiffel.com
Swedish social security: accident reporting & management
9
Learning Eiffel
 Simple syntax, no cryptic symbols
Eiffel programmers know all of Eiffel
 Wide variety of user backgrounds
“If you can write a conditional,
you can write a contract”
 Fast learning curve
 Lots of good models to learn from
 Strong style rules
 May need to “unlearn” needless tricks
10
The Eiffel method: some principles
 Abstraction
 Information hiding
 Seamlessness
 Reversibility
 Design by Contract
 Open-Closed principle
 Single choice principle
 Single model principle
 Uniform access principle
 Command-query separation principle
 Option-operand separation principle
 Style matters
... See next...
11
The Eiffel language
 Classes
 Uniform type system, covering basic types
 Genericity
 Inheritance, single and multiple
 Conversion
 Covariance
 Statically typed
 Built-in Design by Contract mechanisms
 Agents: objects encapsulating behavior
 “Once” mechanisms, replacing statics and globals
 Void safety (new!)
12
Libraries
 Fundamental data structures and algorithms
 Portable graphics
 Internet, Web
 Lexical analysis, parsing
 Database interfaces
13
Dogmatism and flexibility
Dogmatic where it counts:
Information hiding

Overloading
“One good way to do anything”
Style rules


.
(e.g. no x a := b)

Flexible when it makes no point to harass programmers:
 Give standard notations (e.g. a + b) an O-O
interpretation
 Syntax, e.g. semicolon
14
The Eiffel language: there is a hidden agenda
That you forget it even exists
15
-2The environment
16
EiffelStudio
EiffelBuild
EiffelBase
General library
EiffelVision
GUI builder
User
classes

Multiplatform GUI library
WEL
Browsing, fast compiling
(Melting Ice™), debugging,
diagrams, metrics...
Serialization
Win32 library
Ansi C
EiffelWeb
Web development
EiffelStudio
Eiffel compilation
EiffelMath
Jitter
Eiffel
Runtime
EiffelNet
EiffelCOM
C compilation
Executable
system
IL
Advanced numerics
Networking
Persistent
objects
External
C/C++/Java
.NET
Assemblies
EiffelStore
Databases
(Rel, OO)
17
EiffelStudio: Melting Ice™ Technology
Fast recompilation:
time depends on
size of change, not
size of program
Full type checking
“Freeze” once in a
while
Small
change
Big
change
Small program
Large program
Optimized
compilation: finalize.
18
Melting Ice Technology
EiffelStudio
Your system
Freeze
FROZEN
Edit, browse, execute,
debug, test…
Machine code
(from C code)
Melt
MELTED
19
Performance
“Finalization” mode of compilation applies extensive
optimizations:
 Inlining
 Dead code removal
 Contract 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
20
EiffelStudio browsing and debugging
You are dealing with “development objects”:



Classes
Features
Run-time objects (for debugging)
To work on an object, “pick-and-drop” it into an
appropriate tool
21
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, others
Particularly sophisticated mechanisms for C/C++
interfacing
Outside of .NET, compiles down to ANSI C code,
facilitates support for C and C++ easier.
On .NET, seamless integration with C#, VB .NET etc.
22
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)
23
Portability
Source-code portability across:
Windows NT, 2000, XP, Vista
 Windows 98, Me
 .NET
 Solaris, other commercial Unix variants
 Linux
 Mac OS X (forthcoming)
 BSD (Berkeley System Distribution)
 VMS

24
-3-
The method
25
The waterfall model of the lifecycle
Feasibility
study
Requirements
Specification
Global design
Detailed design
Implementation
V&V
Deployment
26
Traditional lifecycle model
Feasibility
study
Rigid model:
 Waterfall: separate tasks,
Requirements
impedance mismatches
 Variants, e.g. spiral, retain
Specification
some of the problems
Separate tools:
Global design
 Programming environment
Detailed design
 Analysis & design tools, e.g. UML
Consequences:
Implementation
 Hard to keep model, implementation,
documentation consistent
V&V
 Constantly reconciling views
 Inflexible, hard to maintain systems
Deployment
 Hard to accommodate bouts of late wisdom
 Wastes efforts
 Damages quality
27
The Eiffel model
Example classes:
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 & forth
Saves money: invest in single
set of tools
Boosts quality
Analysis
Design
Implementation
V&V
Generalization
PLANE, ACCOUNT,
TRANSACTION…
STATE, COMMAND…
HASH_TABLE…
TEST_DRIVER…
TABLE…
28
Seamlessness
Seamlessness Principle
Software development should rely
on a single set of notations & tools
29
Reversibility
Reversibility Principle
The software development process,
notations and tools
should allow making changes
at any step in the process
30
The seamless, reversible model
Example classes:
Analysis
Design
Implementation
V&V
Generalization
PLANE, ACCOUNT,
TRANSACTION…
STATE, COMMAND…
HASH_TABLE…
TEST_DRIVER…
TABLE…
31
Analysis classes
deferred class VAT inherit
feature
TANK
in_valve, out_valve : VALVE
fill
require
Precondition
-- Fill the vat.
in_valve.open
out_valve.closed
deferred
ensure
end
in_valve.closed
out_valve.closed
is_full
Specified, not
implemented
Postcondition
Class invariant
empty, is_full, is_empty, gauge, maximum,
invariant
end
is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum)
32
Single model
Use a single base for everything: analysis, design,
implementation, documentation...
Use tools to extract the appropriate views.
Single Model Principle
All the information
about a software system
should be in the software text
33
The seamless, reversible model
Analysis
Design
Implementation
V&V
Generalization
34
Generalization
A D
Prepare for reuse:
Remove built-in limits
Remove dependencies on
specifics of project
Improve documentation,
contracts...
Abstract
Extract commonalities,
revamp inheritance
hierarchy
I
G
V
A*
T
B
Y*
U
X
Z
35
35
The cluster model
Mix of sequential and
concurrent engineering
A
D
A
I
D
V
I
G
V
G
A
D
I
V
G
Permits dynamic
reconfiguration
A
D
I
V
G
36
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 tool
Metrics Tool
Profiler Tool
Documentation generation tool
...
37
EiffelStudio diagram tool
38
Text-graphics equivalence
39
Equivalence
Equivalence Principle
Textual, graphical and other views
should all represent the same model
40
Eiffel mechanisms









Classes, objects, ...
Single and multiple inheritance
Inheritance facilities: redefinition, undefinition,
renaming
Genericity, constrained and unconstrained
Safe covariance
Disciplined exception handling, based on principles of
Design by Contract
Full GC
Agents (power of functional programming in O-O!)
Unrestricted streaming: files, databases, networks...
41
What is not in Eiffel
 Goto
 Functions as arguments
 Pointer arithmetic
 Special increment syntax, e.g. x++, ++x
 In-class feature overloading
42
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 comment
 Every class should have a note clause
 Layout, indentation
 Choice of names for classes and features
43
The class
From the module viewpoint:
 Set of available services (“features”)
 Information hiding
 Classes 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: C
 Possible type checking
 Notion of subtype
44
Information hiding
Information Hiding principle
Every module should have a public
specification,
listing a subset of its properties
45
An object has an interface
animate
append
prepend
first
last
count
stations
46
An object has an implementation
animate
append
prepend
first
first
last
count
count
stations
47
Information hiding
animate
append
prepend
first
last
count
stations
48
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
49
Uniform access
Uniform access principle
It does not matter to the client
whether you look up or compute
50
Uniform Access: an example
.
.
balance = list_of_deposits total – list_of_withdrawals total
(A1)
(A2)
list_of_deposits
200
100
500
list_of_withdrawals
800
100
100
list_of_deposits
200
300
500
list_of_withdrawals
800
100
100
balance
1000
1000
1000
51
Uniform access
Uniform access principle
It does not matter to the client
whether you look up or compute
A call such as
.
your_account balance
could use an attribute or a function
52
POINT : as an abstract data type
x : POINT  REAL
y : POINT  REAL
 : POINT  REAL
 : POINT  REAL
y


x
Class POINT: Choose a representation (polar, cartesian)
In polar representation,  and  are attributes, x and y are
routines.
53
POINT: as a class
class POINT feature
x, y : REAL
-- Cartesian coordinates
move (a, b : REAL)
do
end
-- Move by a horizontally and b vertically.
x := x + a
y := y + b
scale (factor : REAL)
do
end
-- Scale by factor.
x := factor * x
y := factor * y
54
Class POINT
distance (p : POINT ): REAL
do
end
ro : REAL
do
end
theta : REAL
do
end
end
-- Distance to p
Result := sqrt ((x – p.x)^2 + (y – p.y)^2)
-- Distance to origin (0, 0)
Result := sqrt (x ^ 2 + y ^ 2)
-- Angle to horizontal axis
…
55
Uniform access through feature call
To access a feature of a point, same notation regardless
of representation.
Example:
p1.x


Cartesian representation: attribute call
Polar representation: function call
No difference for clients (except possibly performance)
56
Uniform access in practice
Class COMPLEX, switching silently and on demand between
cartesian and polar representation
Secret attributes:
cartesian_uptodate, polar_uptodate : BOOLEAN
internal_x, internal_y, internal_ro, internal_theta :
REAL
Representation invariant:
invariant
at_least_one : cartesian_uptodate or polar_uptodate
57
Updating representation: secret routine
update_cartesian
require
polar_ok: polar_uptodate
do
if not cartesian_uptodate then
internal_x := ro * cos (theta)
internal_y := ro * sin (theta)
end
ensure
cart_ok: cartesian_uptodate
polar_ok: polar_uptodate
end
58
Public query
x : REAL
do
-- Abscissa of current point
if not cartesian_uptodate then
update_cartesian
end
Result := x_internal
ensure
cart_ok : cartesian_uptodate
same_as_internal : Result = x_internal
end
59
Adding two complex numbers
plus (other : COMPLEX )
do
-- Add other to current complex number.
update_cartesian
x_internal := x_internal + other.x
y_internal := y_internal + other.y
ensure
cartesian_ok : cartesian_uptodate
end
60
Beyond information hiding
Single choice principle
If a system supports a set of choices,
only one of its elements should know the list
61
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
62
Without dynamic binding!
display (f : FIGURE )
do
end
if ‘‘f is a CIRCLE’’ then
...
elseif ‘‘f is a POLYGON’’ then
...
end
and similarly for all other routines!
Tedious; must be changed whenever there’s a new
figure type
63
With inheritance &associated techniques
With:
f : FIGURE
c : CIRCLE
p : POLYGON
Initialize:
if ... then
f := c
else
f := p
end
and:
create c.make (...)
create p.make (...)
Then just use:
f.move (...)
f.rotate (...)
f.display (...)
-- and so on for every
-- operation on f !
64
Memory management
Memory management principle
It is the implementation’s responsibility
to reclaim unused objects
65
What to do with unreachable objects
Reference assignments
may make some
objects useless.
a

name
landlord
loved_one
O2
“Figaro”
“Almaviva”
O1
O3
“Susanna”
Two possible approaches:
 Manual “free” (C++).
 Automatic garbage collection
66
The C programmer’s view
Newsgroup posting by Ian Stephenson, 1993 (as cited in
Object-Oriented Software Construction, 2nd edition):
I say a big NO ! Leaving an unreferenced
object around is BAD PROGRAMMING.
Object pointers ARE like ordinary pointers —
if you allocate an object you should be
responsible for it, and free it when its
finished with. (Didn't your mother always tell
you to put your toys away when you'd
finished with them?)
67
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....
68
Properties of a garbage collector (GC)
Soundness:
If the GC reclaims an object, it is unreachable
Completeness : 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
69
Language style
Consistency principle
The language should offer
one good way to do anything useful
70
Language style
Compatibility principle
Traditional notations should be supported
with an O-O semantics
71
Infix and prefix operators
In
a−b
the − operator is “infix”
(written between operands)
In
−b
the − operator is “prefix”
(written before the operand)
72
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)
???????
73
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
...
end
do ... end
-- Unary minus
.
Calls such as i plus ( j ) can now be written i + j
74
Assignment commands
It is possible to define a query as
temperature: REAL assign set_temperature
Then the syntax
x.temperature := 21.5
Not an assignment, but a
procedure call
is accepted as an abbreviation for
x.set_temperature (21.5)
Retains contracts and any other supplementary operations
75
Array access
Object-oriented forms:
a : ARRAY [T ]
a put (x, 23)
x := a item (23)
.
.
Usual forms:
a [23] := x
x := a [23]
Usual form:
a [i ] := a [i ] + 1
Object-oriented form:
.
a put (a.item (i ) + 1, i )
76
Using the bracket alias
In class ARRAY [G ] :
item
alias "[ ]" (i : INTEGER): G
require
i >= lower and i <= count
do … end
assign put
put (x : G ; i : INTEGER): G
require
i >= lower and i <= count
do … end
Not an assignment!
.
a put (a.item (i ) + 1, i )
.
a item (i ) := a.item (i ) + 1
a [i ] := a [i ] + 1
77
Bracket alias
population [“Lugano ] := 50000
table [a, b, c] := d
78
Command-query separation
Command-Query Separation Principle
A function must not change
its target object’s abstract state
79
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.
80
Command-Query Separation
Asking a question
should not change the answer!
81
Command-query separation
Command-Query Separation Principle
A function must not change
its target object’s state
This principle excludes many common schemes, such as
using functions for input (e.g. C’s getint or equivalent).
82
Referential transparency
If two expressions have equal value, one may be
substituted for the other in any context where that other
is 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 i
 But even if getint () = 2, getint () + getint () is
usually not equal to 4.
83
Command-query separation
Input mechanism using EiffelBase
(instead of n := getint ()):
io.read_integer
n := io.last_integer
84
A discipline of development
Reuse Principle
Design with reuse in mind
85
Typical API in a traditional library (NAG)
nonlinear_ode
Ordinary
differential
(equation_count : in INTEGER;
equation
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!]
86
The EiffelMath routine
... Create e and set-up its values (other than defaults) ...
e.solve
... Answer available in
e.x and e.y ...
87
The Consistency Principle
Consistency Principle
All the components of a library
should proceed from an overall
coherent design, and follow
a set of systematic, explicit
and uniform conventions.
Two components:
 Top-down and deductive (the overall design).
 Bottom-up and inductive (the conventions).
88
The key to building a library
Devising a theory of the underlying domain
89
Some of the theory behind EiffelBase
*
C O N TA IN E R
Representation
*
C O L LE C TIO N
B OX
*
*
I NF IN ITE
F IN ITE
B O U N*DE D
*
FIX E D
*
U N BO UN D E D
*
RE S I ZA BL E
*
CO UN TA B LE
*
I ND E X A BL E
*
BAG
*
TABLE
* OR _
C UR S
S T RU C TU RE
Iteration
Access
*
*
SET
*
A C T IV E
*
D IS P E N S E R
*
TR AV E RS A B LE
* A R_
H IE R
C HI CA L
*
S U B SE T
*
LI NE A R
*
B ILI NE A R
*
S E Q U E NC E
90
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
Maximum number
0.5
5
No arguments
57%
One argument
36%
Two arguments
6%
Three or more arguments
1%
91
Operands and options
Two possible kinds of argument to a feature:
 Operands: values on which feature will operate
 Options: modes that govern how feature will operate
Example (non-O-O): printing a real number

print (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
O-O example:

my_window.display (x_position, y_position,
height, width, text, title_bar_text, color, ...)
92
Recognizing options from operands
Two criteria to recognize an option:

There is a reasonable default value.

During the evolution of a class, operands will
normally remain the same, but options may be added.
93
Option-Operand separation
Option-Operand Principle
Only operands should appear
as arguments of a feature
Option values:
 Defaults (specified universally, per type, per object)
 To set specific values, use appropriate “setter”
procedures
Example:
my_window.set_background_color ("blue")
...
my_window.display
94
Naming (classes, features, variables…)
Traditional advice (for ordinary application programming):
Choose meaningful variable names!
95
Original
for EiffelBase
classes
Final
New
andnames
old names
for EiffelBase
classes
Class
Features
ARRAY
put
enter
put
STACK
push
put
put
QUEUE
put
add
put
put
HASH_TABLE insert
put
enter
push
add
insert
entry
item
item
top
item
item
entry
top
pop
remove
remove
oldest
item
item
oldest
remove_oldest
remove
remove
remove_oldest
value
item
item
value
delete
remove
remove
delete
96
Naming rules
Achieve consistency by systematically using a set of
standardized names.
Emphasize commonality over differences.
Differences will be captured by:
 Signatures (number and types of arguments &
result)
 Assertions
 Comments
97
Some standard names
Queries (non-boolean):
count, capacity
item
to_X,
from_X
-- Some rejected names:
if s.addable then
s.add (v)
end
if s.deletable then
Commands:
s.delete (v)
put, extend, replace, force
end
wipe_out, remove, prune
make -- For creation
Queries (boolean) :
writable, readable, extendible, prunable
is_empty, is_full
-- Usual invariants:
0 <= count ; count <= capacity
is_empty = (count = 0) ; is_full = (count = capacity)
98
-4Design by Contract
99
Design by Contract
Contract Principle
Every software element
should be characterized
by a precise specification
100
Design by Contract: applications
Getting the software right
 Analysis
 Design
 Implementation
 Debugging
 Testing
 Management
 Maintenance
 Documentation

101
Design by Contract: the basic idea
Every software element is intended to satisfy a certain
goal, for the benefit of other software elements (and
ultimately of human users)
This goal is the element’s contract
The contract of any software element should be
 Explicit
 Part of the software element itself
102
A counter-example: Ariane 5, 1996
(See: Jean-Marc Jézéquel and Bertrand Meyer: Design by
Contract: The Lessons of Ariane, IEEE Computer, January
1997, also at http://www.eiffel.com)
37 seconds into flight, exception in Ada program not
processed; order given to abort the mission. Ultimate cost
in billions of euros
Cause: incorrect conversion of 64-bit real value
(“horizontal bias” of the flight) into 16-bit integer
Systematic analysis had “proved” that the exception could
not occur!
103
Ariane-5 (continued)
It was a REUSE error:
The
analysis was correct – for Ariane 4 !
The
assumption was documented – in a design document !
With assertions, the error would almost certainly detected by either
static inspection or testing:
integer_bias (b : REAL): INTEGER
require
do
representable (b)
…
ensure
end
equivalent (b, Result)
104
The contract view of software construction
Constructing systems as structured collections of
cooperating software elements — suppliers and clients —
cooperating on the basis of clear definitions of obligations
and benefits
These definitions are the contracts
105
Contracts for analysis
fill
Client
Supplier
OBLIGATIONS
(Satisfy precondition:)
BENEFITS
(From postcondition:)
Make sure input valve is
open, output valve closed
Get filled-up tank, with
both valves closed
(Satisfy postcondition:)
(From precondition:)
Fill the tank and close
both valves
Simpler processing
thanks to assumption
that valves are in the
proper initial position
106
Constracts for analysis
deferred class VAT inherit
feature
TANK
in_valve, out_valve : VALVE
fill
require
Precondition
-- Fill the vat.
in_valve.open
out_valve.closed
deferred
ensure
end
in_valve.closed
out_valve.closed
is_full
Specified, not
implemented
Postcondition
Class invariant
empty, is_full, is_empty, gauge, maximum,
invariant
end
is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum)
107
A class without contracts
class
ACCOUNT
feature -- Access
balance : INTEGER
-- Balance
Minimum_balance: INTEGER = 1000
-- Minimum balance
Secret
features
feature {NONE } -- Deposit and withdrawal
add (sum : INTEGER)
-- Add sum to the balance.
do
end
balance := balance + sum
108
A class without contracts
feature -- Deposit and withdrawal operations
deposit (sum : INTEGER)
-- Deposit sum into the account.
do
end
add (sum)
withdraw (sum : INTEGER)
-- Withdraw sum from the account.
do
end
add (– sum)
may_withdraw (sum : INTEGER): BOOLEAN
-- Is it permitted to withdraw sum from the account?
do
end
end
Result := (balance - sum >= Minimum_balance)
109
Introducing contracts
class
ACCOUNT
create
make
feature {NONE } -- Initialization
make (initial_amount: INTEGER)
-- Set up account with initial_amount.
require
large_enough: initial_amount >= Minimum_balance
do
balance := initial_amount
ensure
end
balance_set: balance = initial_amount
110
Introducing contracts
feature -- Access
balance: INTEGER
-- Balance
Minimum_balance : INTEGER = 1000
-- Lowest permitted balance
feature {NONE} -- Implementation of deposit and withdrawal
add (sum : INTEGER)
-- Add sum to the balance.
do
ensure
end
balance := balance + sum
increased: balance = old balance + sum
111
Introducing contracts
feature -- Deposit and withdrawal operations
Precondition
deposit (sum : INTEGER)
-- Deposit sum into the account.
require
not_too_small: sum >= 0 Postcondition
do
add (sum)
ensure
increased: balance = old balance + sum
end
112
Introducing contracts
withdraw (sum : INTEGER)
-- Withdraw sum from the account.
require
not_too_small: sum >= 0
not_too_big: sum <= balance – Minimum_balance
do
add (–sum)
-- i.e. balance := balance – sum
ensure
decreased: balance = old balance - sum
end
Value of balance, captured
on entry to routine
113
The contract
withdraw
Client
Supplier
OBLIGATIONS
BENEFITS
(Satisfy precondition:)
(From postcondition:)
Make sure sum is neither
too small nor too big
Get account updated with
sum withdrawn
(Satisfy postcondition:)
(From precondition:)
Update account for
withdrawal of sum
Simpler processing: may
assume sum is within
allowable bounds
114
The imperative and the applicative
do
ensure
balance := balance - sum
balance = old balance - sum
PRESCRIPTIVE
DESCRIPTIVE
How?
What?
Operational
Denotational
Implementation
Specification
Command
Query
Instruction
Expression
Imperative
Applicative
115
Introducing contracts
may_withdraw (sum : INTEGER ): BOOLEAN
-- Is it permitted to withdraw sum from account?
do
end
Result := (balance - sum >= Minimum_balance)
invariant
not_under_minimum: balance >= Minimum_balance
end
116
The class invariant
Consistency constraint applicable to all instances of a
class.
Must be satisfied:
 After creation
 After execution of any feature by any client
Qualified calls only: x f (...)
.
117
The correctness of a class
create x.make (…)
For every creation procedure cp :
S1
.
x f (…)
{Precp } docp {INV and Postcp }
S2
For every exported routine r :
S3
{INV and Prer } dor {INV and Postr }
S4
.
x g (…)
.
x h (…)
118
Uniform Access
(A1)
(A2)
list_of_deposits
200
100
500
list_of_withdrawals
800
100
100
list_of_deposits
200
300
500
list_of_withdrawals
800
100
100
balance
1000
1000
1000
balance = deposits.total – withdrawals.total
119
What are contracts good for?
Writing correct software (analysis, design,
implementation, maintenance, reengineering)
Documentation (the “contract” form of a class)
Effective reuse
Controlling inheritance
Preserving the work of the best developers
Quality assurance, testing, debugging (especially in
connection with the use of libraries)
Exception handling
120
A contract violation is not a special case
For special cases
(e.g. “if the sum is negative, report an error...”)
use standard control structures, such as if ... then ... else...
A run-time assertion violation is something else: the
manifestation of
A DEFECT (“BUG”)
121
Contracts and quality assurance
Precondition violation: Bug in the client.
Postcondition violation: Bug in the supplier.
Invariant violation: Bug in the supplier.
{P }
A
{Q }
122
Contracts: run-time effect
Compilation options (per class, in Eiffel):
 No assertion checking
 Preconditions only
 Preconditions and postconditions
 Preconditions, postconditions, class invariants
 All assertions
123
Contracts for testing and debugging
Contracts express implicit assumptions behind code
 A bug is a discrepancy between intent and code
 Contracts state the intent!
In EiffelStudio: select compilation option for run-time
contract monitoring at level of:
 Class
 Cluster
 System
May disable monitoring when releasing software
A revolutionary form of quality assurance
124
Lists in EiffelBase
before
after
item
“Munich"
1
count
Cursor
back
forth
start
finish
index
125
Trying to insert too far right
after
"Munich"
1
count
Cursor
(Already past last element!)
126
A command and its contract
Precondition
Postcondition
127
Moving the cursor forward
before
after
"Munich"
1
count
Cursor
forth
index
128
Two queries, and command forth
129
Where the cursor may go
before
after
"Munich"
0
1
index
count
count + 1
Valid cursor positions
130
From the invariant of class LIST
Valid cursor positions
131
Contracts and bug types
Preconditions are particularly useful to find bugs in client
code:
YOUR
APPLICATION
your_list.insert (y, a + b + 1)
COMPONENT
LIBRARY
class LIST [G ] feature
insert (x : G ; i : INTEGER)
require
i >= 0
i <= count + 1
132
Contracts and quality assurance
Use run-time assertion monitoring for quality assurance,
testing, debugging.
Compilation options (reminder):





No assertion checking
Preconditions only
Preconditions and postconditions
Preconditions, postconditions, class invariants
All assertions
133
Contracts and quality assurance
Contracts enable QA activities to be based on a precise description of
what they expect.
Profoundly transform the activities of testing, debugging and
maintenance.
“I believe that the use of Eiffel-like module contracts is the
most important non-practice in software world today. By that I mean
there is no other candidate practice presently being urged upon us
that has greater capacity to improve the quality of software
produced. ... This sort of contract mechanism is the sine-qua-non of
sensible software reuse. ”
Tom de Marco, IEEE Computer, 1997
134
Contracts and documentation
Contract view: Simplified form of class text, retaining
interface elements only:
 Remove any non-exported (private) feature
For the exported (public) features:
 Remove body (do clause)
 Keep header comment if present
 Keep contracts: preconditions, postconditions, invariant
 Remove any contract clause that refers to a secret
feature
(This raises a problem; can you see it?)
135
Flat, interface
Flat view of a class: reconstructed class with all the
features at the same level (immediate and inherited).
Takes renaming, redefinition etc. into account.
The flat view is an inheritance-free client-equivalent form
of the class.
Interface view: the contract view of the flat view. Full
interface documentation.
136
Uses of the contract &interface forms
Documentation, manuals
Design
Communication between developers
Communication between developers and managers
137
Contracts and inheritance
Issues: what happens, under inheritance, to

Class invariants?

Routine preconditions and postconditions?
138
Invariants
Invariant Inheritance rule:

The invariant of a class automatically includes the
invariant clauses from all its parents, “and”-ed.
Accumulated result visible in flat and interface forms.
139
Contracts and inheritance
a1 : A
…
r
A
C

.
ensure
a1 r (…)

Correct call in C:
if a1. then
a1.r (...)
-- Here a1. holds
end
Client
Inheritance
require
++
D
B
r ++
require

ensure

Redefinition
140
Assertion redeclaration rule
When redeclaring a routine, we may only:

Keep or weaken the precondition

Keep or strengthen the postcondition
141
Assertion redeclaration rule in Eiffel
A simple language rule does the trick!
Redefined version may have nothing (assertions kept by
default), or
require else new_pre
ensure then new_post
Resulting assertions are:

original_precondition or new_pre

original_postcondition and new_post
142
Contracts as a management tool
High-level view of modules for the manager:

Follow what’s going on without reading the code

Enforce strict rules of cooperation between units of
the system

Control outsourcing
143
Managerial benefits
Library users can trust documentation.
They can benefit from preconditions to validate their own
software.
Test manager can benefit from more accurate estimate of
test effort.
Black-box specification for free.
Designers who leave bequeath not only code but intent.
Common vocabulary between all actors of the process:
developers, managers, potentially customers.
Component-based development possible on a solid basis.
144
Genericity and inheritance
Abstraction
Inheritance
SET_OF_
CARS
Genericity
Type parameterization
LIST_OF_
CITIES
Type parameterization
LIST_OF_
CARS
LIST_OF_
PERSONS
LINKED_LIST_
OF_CARS
Specialization
145
Extending the basic notion of class
Inheritance
SET_OF_
CARS
SET_OF_
PERSONS
Genericity
LIST_OF_
CITIES
LIST_OF_
CARS
LINKED_LIST_
OF_CITIES
LINKED_LIST_
OF_CARS
LIST_OF_
PERSONS
146
An inheritance hierarchy
center *
*
*
FIGURE
display *
rotate *
perimeter *
OPEN_
FIGURE
*
deferred
+ effective
*
CLOSED_
FIGURE
++ redefined
+
perimeter
SEGMENT
POLYLINE
POLYGON
+
perimeter
ELLIPSE
...
perimeter
++ TRIANGLE
...
side1
RECTANGLE side2
++
perimeter
diagonal
CIRCLE
SQUARE
side
perimeter
++
147
Redefinition 1: polygons
class POLYGON inherit
CLOSED_FIGURE
create
make
feature
vertex : ARRAY [POINT]
vertex_count : INTEGER
perimeter : REAL
do
end
invariant
vertex [i ]
-- Perimeter length
from ... until ... loop
Result := Result + vertex [i ]
...
end
vertex [i + 1]
. distance (vertex [i + 1])
vertex_count >= 3
vertex_count = vertex.count
end
148
Redefinition 2: rectangles
class RECTANGLE inherit
POLYGON
redefine
perimeter
end
create
make
diagonal
side2
feature
diagonal, side1, side2 : REAL
perimeter : REAL
side1
-- Perimeter length
do Result := 2 * (side1 + side2) end
invariant
end
vertex_count = 4
149
Inheritance, typing &polymorphism
Assume:
p : POLYGON ; r : RECTANGLE ; t : TRIANGLE ;
x : REAL
Permitted:
x := p.perimeter
x := r.perimeter
x := r.diagonal
p := r
NOT permitted:
x := p.diagonal
r := p
p

(POLYGON )
r
(RECTANGLE )
-- Even just after p := r !
150
Definitions: Polymorphism
An attachment (assignment or argument passing) is
polymorphic if its target variable and source expression
have different types.
An entity or expression is polymorphic if it may at
runtime — as a result of polymorphic attachments —
become attached to objects of different types.
Polymorphism is the existence of these possibilities.
151
Dynamic binding
What is the effect of this (assuming some_test true)?
if some_test then
p := r
else
p := t
end
x := p.perimeter
Redefinition: A class may change an inherited feature, as
with POLYGON redefining perimeter
Polymorphism: p may have different forms at run-time.
Dynamic binding: Effect of p.perimeter depends on runtime form of p
152
Definitions (Dynamic binding)
Dynamic binding (a semantic rule) is the property that
any execution of a feature call will use the version of
the feature best adapted to the type of the target
object.
153
Without dynamic binding!
display (f : FIGURE )
do
end
if ‘‘f is a CIRCLE’’ then
...
elseif ‘‘f is a POLYGON’’ then
...
end
and similarly for all other routines!
Tedious; must be changed whenever there’s a new
figure type
154
With inheritance &associated techniques
With:
f : FIGURE
c : CIRCLE
p : POLYGON
Initialize:
if ... then
f := c
else
f := p
end
and:
create c.make (...)
create p.make (...)
Then just use:
f.move (...)
f.rotate (...)
f.display (...)
-- and so on for every
-- operation on f !
155
Extending the basic notion of class
Abstraction
Inheritance
SET_OF_
CARS
Genericity
Type parameterization
LIST_OF_
CITIES
Type parameterization
LIST_OF_
CARS
LIST_OF_
PERSONS
LINKED_LIST_
OF_CARS
Specialization
156
Genericity
Unconstrained
LIST [G]
e.g. LIST [INTEGER], LIST [PERSON]
Constrained
HASH_TABLE [G ―> HASHABLE ]
VECTOR [G ―> NUMERIC ]
157
Genericity: Ensuring type safety
How can we define consistent “container” data structures, e.g.
list of accounts, list of points?
What if
wrong?
Dubious use of a container data structure:
c : CITY ; p : PERSON
cities : LIST ...
people : LIST ...
---------------------------------------------------------
people.extend ( p )
cities.extend
(c )
c := cities.last
c. some_city_operation
158
A generic class
Formal generic parameter
class LIST [G ] feature
extend (x : G ) ...
last : G ...
end
To use the class: obtain a generic derivation, e.g.
cities : LIST [CITY ]
Actual generic parameter
159
Using generic derivations
cities : LIST [CITY ]
people : LIST [PERSON]
c : CITY
p : PERSON
...
STATIC TYPING
cities.extend (c)
people.extend (p)
The compiler will reject:
c := cities.last

people.extend (c)

cities.extend (p)
c. some_city_operation
160
Static typing
Type-safe call (during execution):
A feature call x.f such that the object attached
to x has a feature corresponding to f.
[Generalizes to calls with arguments, x.f (a, b) ]
Static type checker:
A program-processing tool (such as a compiler)
that guarantees, for any program it accepts, that
any call in any execution will be type-safe.
Statically typed language:
A programming language for which it is possible to
write a static type checker.
161
Using genericity
LIST [CITY ]
LIST [LIST [CITY ]]
…
A type is no longer exactly the same thing as a class!
(But every type remains based on a class.)
162
Genericity + inheritance 1: Constrained genericity
class VECTOR [G
] feature
plus alias "+" (other : VECTOR [G]): VECTOR [G]
-- Sum of current vector and other
require
local
do
end
lower = other.lower
upper = other.upper
a, b, c: G
... See next ...
end
... Other features ...
163
Adding two vectors
u
+
v
=
w
+
b
=
c
2
i1
a
164
Constrained genericity
Body of plus alias "+":
create Result.make (lower, upper)
from
until
loop
end
i := lower
i > upper
a := item (i)
b := other.item (i)
c := a + b
-- Requires “+” operation on G!
Result.put (c, i)
i := i + 1
165
The solution
Declare class VECTOR as
class VECTOR [G
–>
NUMERIC ] feature
... The rest as before ...
end
Class NUMERIC (from the Kernel Library) provides
features plus alias "+", minus alias "-"and so on.
166
Improving the solution
Make VECTOR itself a descendant of NUMERIC,
effecting the corresponding features:
class VECTOR [G –> NUMERIC ] inherit
NUMERIC
feature
... Rest as before, including infix "+"...
end
Then it is possible to define
v : VECTOR [INTEGER ]
vv : VECTOR [VECTOR [INTEGER ]]
vvv : VECTOR [VECTOR [VECTOR [INTEGER ]]]
167
Extending the basic notion of class
Inheritance
SET_OF_
CARS
SET_OF_
PERSONS
Genericity
LIST_OF_
CITIES
LIST_OF_
CARS
LINKED_LIST_
OF_CITIES
LINKED_LIST_
OF_CARS
LIST_OF_
PERSONS
168
Genericity + inheritance 2: Polymorphic data structures
class LIST [G ] feature
extend (v : G) do …
end
last : G
…
end
figs : LIST [FIGURE ]
p1, p2 : POLYGON
c1, c2 : CIRCLE
e : ELLIPSE
figs.extend (p1 ) ; figs.extend (c1 ) ; figs.extend (c2 )
figs.extend (e ) ; figs.extend (p2 )
(POLYGON)
(CIRCLE)
(CIRCLE)
(ELLIPSE)
(POLYGON)
169
Combining abstractions
Given the classes
 TRAIN_CAR, RESTAURANT
how would you implement a DINER ?
170
Examples of multiple inheritance
Combining separate abstractions:





Restaurant, train car
Calculator, watch
Plane, asset
Home, vehicle
Tram, bus
171
Composite figures
172
Multiple inheritance: Composite figures
Simple figures
A composite figure
173
Defining the notion of composite figure
center
display
hide
rotate
move
…
LIST
[FIGURE ]
FIGURE
count
put
remove
…
COMPOSITE_
FIGURE
174
In the overall structure
LIST
[FIGURE ]
FIGURE
OPEN_
FIGURE
SEGMENT
POLYLINE
CLOSED_
FIGURE
perimeter*
POLYGON
ELLIPSE
perimeter+
perimeter+
diagonal
RECTANGLE
TRIANGLE
perimeter++
SQUARE
COMPOSITE_
FIGURE
CIRCLE
perimeter++
perimeter++
175
A composite figure as a list
after
item
Cursor
forth
176
Composite figures
class COMPOSITE_FIGURE inherit
FIGURE
LIST [FIGURE]
feature
display
do
-- Display each constituent figure in turn.
from start until after loop
item.display
end
end
forth
Requires dynamic
binding
end
... Similarly for move, rotate etc. ...
177
Multiple inheritance: Combining abstractions
<, <=,
>, >=,
…
NUMERIC
COMPARABLE
+, –,
*, /
…
(commutative
ring)
(total order
relation)
INTEGER
REAL
STRING
COMPLEX
178
Renaming
‘‘Graphical’’ features: height, width, change_height,
change_width, xpos, ypos, move...
‘‘Hierarchical’’ features: superwindow, subwindows,
change_subwindow, add_subwindow...
class WINDOW inherit
RECTANGLE
TREE [WINDOW]
rename
parent as superwindow,
children as subwindows,
add_child as add_subwindow
…
end
feature
...
end
BUT: see style
rules about
uniformity of
feature names
179
-5-
Some new
developments
180
Some recent developments
Void safety
Automatic testing
Concurrency
181
Basic O-O operation…
x.f (args)
Semantics: apply the
feature f, with given
args if any, to the
object to which x is
attached
… and basic issue
studied here:
How do we guarantee
that x will always be
“attached” to an object?
(If not, call produces an exception and usually termination)
182
Void safety: requirements

Statically, completely void safe: no exceptions

Handles genericity

Simple for programmer, no mysterious rules

Reasonably simple for compiler

Compatibility or minimum change for existing code
(Plus for me: 1st semester teachability)
183
Components of the solution
1. Some patterns guaranteed void-safe
(“Certified Attachment Patterns” or CAPS)
2. Void value permitted only for types declared as
“detachable”. By default types are “attached”
3. Initialization rules ensure that any variable of an
attached type has a non-void initialization value
4. Special rules for arrays
184
Automatic testing
Two tools:
 AutoTest: takes a set of classes and tests them
automatically (push-button, no manual test cases, no
test oracles, nothing…)

CDD (Contract-Driven Development): automatically
extracts test cases from execution failures
Integrated into EiffelStudio 6.3 and 6.4
185
Caveat
I am mostly talking about:

Functional testing

Unit testing
186
What is testing about?
To test a software system is to try to make it fail
Testing is none of:
 Ensuring software quality
 Assessing software quality
 Debugging
(Terminology: failure, fault, mistake)
Fiodor Chaliapine
as Mephistopheles
“Ich bin der Geist, der stets verneint”
Goethe, Faust, Act I
187
Seven principles of software testing
1.
To test a program is to try to
make it fail
2. Tests are no substitute for
specifications
Bertrand Meyer, Seven
Principles of Software Testing,
IEEE Computer, August 2008
3. Any failed execution must yield a test case, to remain forever remain
part of the regression test base
4. Determining success or failure (oracles) must be automatic
4’: Oracles should be part of the program, as contracts
5. A test suite must include both manual and automated cases
6. Don’t believe your testing insights: evaluate any testing strategy
through objective criteria
7. The most important criterion is number of faults found against time:
fc (t)
188
“Automated testing”
What can be automated:

Test suite execution

Resilience

Regression testing

Test case generation

Test result verification (oracles)

Test case minimization
189
189
Contracts for testing
Contracts provide the right basis:
 A fault is a discrepancy between intent and reality
 Contracts describe intent
A contract violation always signals a fault:
 Precondition: in client
 Postcondition or invariant: in routine (supplier)
In EiffelStudio: select compilation option for contract
monitoring at level of class, cluster or system.
190
190
AutoTest: automatic test framework
Ilinca Ciupa
Andreas Leitner

Input: set of classes + testing time

Generates instances, calls routines with automatically
selected arguments

Oracles are contracts:
(SOFSEM 2007 etc.)

Direct precondition violation: skip

Postcondition/invariant violation: bingo!

Value selection: Random+ (use special values such as 0,
+/-1, +/-10, max and min)

Add manual tests if desired

Any test (manual or automated) that fails becomes part
of the test suite
191
Minimization through dynamic slicing
auto_test system.ace –t 120 ACCOUNT CUSTOMER
create {STRING} v1
v1.wipe_out
v1.append_character (’c’)
v1.append_double (2.45)
create {STRING} v2
v1.append_string (v2)
v2.fill (’g’, 254343)
...
create {ACCOUNT} v3.make (v2)
v3.deposit (15)
v3.deposit (100)
v3.deposit (-8901)
...
class
ACCOUNT
create
make
feature
make (n : STRING)
require
n /= Void
do
name := n
balance := 0
ensure
name = n
end
balance = 0
name : STRING
balance : INTEGER
deposit (v : INTEGER)
do
balance := balance + v
ensure
balance =
old balance + v
end
invariant
name /= Void
balance >= 0
end
192
AutoTest strategies

Object pool
 Get objects through creation procedures (constructors)
 Diversify through procedures

Routine arguments
 Basic values: heuristics for each type
 Objects: get from pool

193
Test all routines, including inherited ones (“Fragile base
class” issue)
193
Random testing: example bug found
Bernd Schoeller
Test:
s1, s2 : SET
s2  s1
*
SET
+
SET1
*
*
+
+

SET2
+

*: Deferred
+: Effective
194
Some AutoTest results (random strategy)
TESTS
Library
EiffelBase
(Sep 2005)
Gobo Math
ROUTINES
Total
Failed
Total
Failed
40,000
3%
2000
6%
1500
1%
140
6%
195
195
Testing results and strategy
“Smart” ideas not always better
Don’t believe your intuition
Measure and assess objectively
Define good assessment criteria:

Number of faults found

Time to find all faults
Class STRING
fc (t)
Time
Experimental law:
fc (t ) = a – b / t
196
Fault categories
Specification faults -- examples:
 Precondition:

Missing non-voidness precondition (will go away)

Missing min-max precondition

Too strong precondition
 Postcondition:

Missing

Wrong
Implementation faults -- examples:
 Faulty supplier
 Missing implementation
 Case not treated
 Violating a routine’s precondition
 Infinite loop
197
Who finds what faults?
I.Ciupa, A. Leitner,
M.Oriol, A. Pretschner
(submitted)
On a small EiffelBase subset,
we compared:
 AutoTest
 Manual testing (students) (3 classes, 2 with bugs
seeded)
 User reports from the field
AutoTest: 62% specification, 38% implementation
User reports: 36% specification, 64% implementation
198
AutoTest vs manual testers
On three classes (two with seeded bugs):
 Humans found 14 faults, AutoTest 9 of them
 AutoTest found 2 faults that humans did not (in large
class)
 3 faults not found by AutoTest found by 60% of
humans (one is infinite loop)
 2 faults not found by AutoTest are missing
preconditions (void, min-max)
199
AutoTest vs user reports
On 39 EiffelBase classes:
 AutoTest found 85 faults,
Plus 183 related to RAW_FILE,
PLAIN_TEXT_FILE, DIRECTORY (total 268)
 4 of these also reported by users
 21 faults solely reported by users
 30% of AutoTest-found bugs related to extreme values;
users never report them
AutoTest finds only 1 out of 18 (5%) of implementation faults
and 3 out of 7 specification faults
AutoTest bad at over-strong preconditions, wrong operator
semantics, infinite loops, missing implementations
Users never find faulty suppliers (blame on client)
200
AutoTest developments

Large-scale extensive tests, empirical assessment of
criteria & strategies

Comparison with manual efforts

Complete integration with EiffelStudio IDE

Background, unobtrusive, continuous testing

Distributed cooperative testing (“Testi@home”)
201
CDD (Contract-Driven Development)
Like Test-Driven Development, but
 Tests derived from spec (contracts)
 Not the other way around!
Record every failed execution, make it reproducible by
retaining objects
Turn it into a regression test
202
Specified but unimplemented routine
20
Running the system and entering input
(erroneous)
20
204
Error caught at run time as contract violation
Postcondition
violated
The violated clause:
balance > old balance
20
This has become a test case
206
20
Correcting and recompiling
20
One fault corrected, the other not
20
Test tools: lessons
1. Testing should be automatic
2. You need built-in contracts as in Eiffel
3. Testing is one of the tools for verification
4. Testing should be continuous and unobtrusive
209
Concurrency: the SCOOP model
General-purpose
Multi-threading, Web services, distribution,
multiprogramming...
Simplifies concurrent programming
Based on Design by Contract ideas
210
Summary
Bring every one of your development days
to the level of your best days
211
Gustave Eiffel, 1885
Must it be assumed that because we are engineers beauty is
not our concern, and that while we make our constructions
robust and durable we do not also strive to make them
elegant?
Is it not true that the genuine conditions of strength always
comply with the secret conditions of harmony?
The first principle of architectural esthetics is that the
essential lines of a monument must be determined by a
perfect adaptation to its purpose.
Gustave Eiffel, 1887
From his response in Le Temps to a petition by members of the
literary and artistic Establishment protesting his project of elevating
a tower of iron in Paris
212