Eiffel in Depth Bertrand Meyer With material by Emmanuel Stapf (Eiffel Software) & members of the...

Eiffel in Depth

Bertrand Meyer

With material by Emmanuel Stapf (Eiffel Software)

& members of the ETH Chair of Software Engineering

Chair ofSoftware 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

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

4

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

5

- 1 -

Overview

6

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

7

Language versions

Eiffel 1, 1986Classes, contracts, genericity, single and

multipleinheritance, 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 2006www.ecma-international.org/publications/standards/Ecma-367.htm

Attached types, conversion, assigner commands…

http://www.ecma-international.org/publications/standards/Ecma-367.htm

http://www.ecma-international.org/publications/standards/Ecma-367.htm

8

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

99

Some typical users

Axa RosenbergInvestment management: from $2 billion to >$100 billion 2 million linesChicago Board of Trade Price reporting system Eiffel + CORBA + Solaris + Windows + …Xontech (for Boeing) Large-scale simulations of missile defenseNorthrop-Grumman

Swedish social security: accident reporting & management

(Eiffel) Price Reporting System

The Chicago Board of Trade

See: eiffel.co

m

1010

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

11

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...

12

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!)

13

Libraries

Fundamental data structures and algorithms

Portable graphics

Internet, Web

Lexical analysis, parsing

Database interfaces

14

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 interpretation

Syntax, e.g. semicolon

15

The Eiffel language: there is a hidden agenda

That you forget it even exists

16

- 2 -

The environment

17

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...

18

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

19

Melting Ice Technology

FROZEN

MELTED

EiffelStudio Your system

Machine code(from C code)Edit, browse,

execute,debug, test…

Freeze

Melt

20

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

21

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

22

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.

23

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)

24

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

25

- 3 -

The method

26

The waterfall model of the lifecycle

Feasibility study

Requirements

Global design

Detailed design

Deployment

V & V

Specification

Implementation

27

Traditional lifecycle model

Rigid model:Waterfall: separate tasks,

impedance mismatchesVariants, e.g. spiral, retain

some of the problemsSeparate 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

28

The Eiffel model

Seamless development:Single notation, tools, concepts, principles throughout Eiffel is as much for analysis & design as implementation & maintenanceContinuous, incremental developmentKeep model, implementation and documentation consistentReversibility: 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

29

Seamlessness

Seamlessness Principle

Software development should relyon a single set of notations & tools

30

Reversibility

Reversibility Principle

The software development process,notations and tools

should allow making changesat any step in the process

31

The seamless, reversible model

Example classes:PLANE, ACCOUNT, TRANSACTION…

STATE, COMMAND…

HASH_TABLE…

TEST_DRIVER…

TABLE…

Analysis

Design

Implemen-

tation

V&V

Generali-zation

32

Class invariant

Postcondition

Precondition

Specified, notimplemented

Analysis classesdeferred class VAT inherit

TANKfeature

in_valve, out_valve : VALVE

fill -- Fill the vat.

requirein_valve.openout_valve.closed

deferred

ensurein_valve.closed

out_valve.closedis_full

end

empty, is_full, is_empty, gauge, maximum,

invariantis_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum)

end

33

Single model

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

34

The seamless, reversible model

Analysis

Design

Implemen-

tation

V&V

Generali-zation

35

Generalization

Prepare for reuse:Remove built-in limitsRemove dependencies on specifics of project

Improve documentation, contracts...

Abstract Extract commonalities, revamp inheritance hierarchy

35

A D I V G

A *

B

Y *

X Z

T

U

36

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

37

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 ...

38

EiffelStudio diagram tool

39

Text-graphics equivalence

40

Equivalence

Equivalence Principle

Textual, graphical and other viewsshould all represent the same model

41

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...

42

What is not in Eiffel

Goto Functions as arguments Pointer arithmetic Special increment syntax, e.g. x++, ++x

In-class feature overloading

43

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

44

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

45

Information hiding

Information Hiding principle

Every module should have a publicspecification,

listing a subset of its properties

46

prepend

animate

append

An object has an interface

count stations

first last

47

prepend

animate

appendcount

first

An object has an implementation

count stations

first last

48

Information hiding

prepend

animate

appendcount stations

first last

49

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

50

Uniform access

Uniform access principle

It does not matter to the clientwhether you look up or compute

51

Uniform Access: an example

balance = list_of_deposits.total – list_of_withdrawals.total

(A1)200 100 500 1000

800 100 100

(A2)

200 300 500 1000

800 100 100

list_of_deposits

list_of_withdrawals

list_of_deposits

list_of_withdrawals

balance 1000

52

Uniform access

A call such as

your_account.balance

could use an attribute or a function

Uniform access principle

It does not matter to the clientwhether you look up or compute

53

POINT : as an abstract data type

x : POINT REAL

y : POINT REAL

: POINT REAL

: POINT REAL

Class POINT: Choose a representation (polar, cartesian)

In polar representation, and are attributes, x and y are routines.

y

x

54

POINT: as a class

class POINT feature

x, y : REAL-- Cartesian coordinates

move (a, b : REAL)-- Move by a horizontally and b vertically.

dox := x + ay := y + b

end

scale (factor : REAL)-- Scale by factor.

dox := factor * xy := factor * y

end

55

Class POINT

distance (p : POINT ): REAL-- Distance to p

doResult := sqrt ((x – p.x)^2 + (y –

p.y)^2)end

ro : REAL-- Distance to origin (0, 0)

doResult := sqrt (x ^ 2 + y ^ 2)

end

theta : REAL-- Angle to horizontal axis

do…

endend

56

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)

57

Uniform access in practice

Class COMPLEX, switching silently and on demand between cartesian and polar representation

Secret attributes:

cartesian_uptodate, polar_uptodate : BOOLEANinternal_x, internal_y, internal_ro, internal_theta :

REAL

Representation invariant:

invariantat_least_one : cartesian_uptodate or

polar_uptodate

58

Updating representation: secret routine

update_cartesianrequire

polar_ok: polar_uptodatedo

if not cartesian_uptodate theninternal_x := ro * cos (theta)internal_y := ro * sin (theta)

endensure

cart_ok: cartesian_uptodatepolar_ok: polar_uptodate

end

59

Public query

x : REAL -- Abscissa of current pointdo

if not cartesian_uptodate thenupdate_cartesian

endResult := x_internal

ensurecart_ok : cartesian_uptodate

same_as_internal : Result = x_internal

end

60

Adding two complex numbers

plus (other : COMPLEX )

-- Add other to current complex number. do

update_cartesian

x_internal := x_internal + other.xy_internal := y_internal + other.y

ensurecartesian_ok : cartesian_uptodate

end

61

Beyond information hiding

Single choice principle

If a system supports a set of choices,only one of its elements should know the list

62

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

63

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

64

With inheritance &associated techniques

f : FIGUREc : CIRCLEp : POLYGON

create c.make (...)create p.make (...)

if ... then f := c

else f := p

end

f.move (...)f.rotate (...)f.display (...)

-- and so on for every -- operation on f !

With:

Initialize:

and:

Then just use:

65

Memory management

Memory management principle

It is the implementation’s responsibilityto reclaim unused objects

66

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

67

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?)

68

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....

69

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

70

Language style

Consistency principle

The language should offerone good way to do anything useful

71

Language style

Compatibility principle

Traditional notations should be supportedwith an O-O semantics

72

Infix and prefix operators

In

a − bthe − operator is “infix”

(written between operands)

In

− bthe − operator is “prefix”

(written before the operand)

73

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) ???????

74

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

75

Assignment commands

It is possible to define a query as

temperature: REAL assign set_temperature

Then the syntax

x.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

76

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 )

77

Using the bracket alias

In class ARRAY [G ] :

item (i : INTEGER): Grequire

i >= lower and i <= countdo … end

put (x : G ; i : INTEGER): Grequire

i >= lower and i <= countdo … end

alias "[ ]" assign put

a.put (a.item (i ) + 1, i )

a.item (i ) := a.item (i ) + 1

a [i ] := a [i ] + 1

Not an assignment!

78

Bracket alias

population [“Lugano ] := 50000

table [a, b, c] := d

79

Command-query separation

Command-Query Separation Principle

A function must not changeits target object’s abstract state

80

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.

81

Command-Query Separation

Asking a questionshould not change the answer!

82


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).

83

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.

84


Input mechanism using EiffelBase(instead of n := getint ()):

io.read_integer

n := io.last_integer

85

A discipline of development

Reuse Principle

Design with reuse in mind

86

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

87

The EiffelMath routine

... Create e and set-up its values (other than defaults) ...

e.solve

... Answer available in e.x and e.y ...

88

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 overall

coherent design, and followa set of systematic, explicitand uniform conventions.

89

The key to building a library

Devising a theory of the underlying domain

90

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

91

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%

92

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

operateExample (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, ...)

93

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.

94

Option-Operand separation

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

Option-Operand Principle

Only operands should appearas arguments of a feature

95

Naming (classes, features, variables…)

Traditional advice (for ordinary application programming):

Choose meaningful variable names!

96

enter

push

add

insert

Original

Class

ARRAY

STACK

QUEUE

HASH_TABLE

entry

top

oldest

value

pop

remove_oldest

delete

Features

names for EiffelBase classes

put

put

put

put

item

item

item

item

remove

remove

remove

Final

enter

push

add

insert

Class

ARRAY

STACK

QUEUE

HASH_TABLE

remove_oldest

delete

Features

put

put

put

item

item

item

item

remove

remove

remove

entry

top

oldest

value

put

New and old names for EiffelBase classes

97

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

98

Some standard namesQueries (non-boolean):

count, capacityitem

to_X, from_X

Queries (boolean) :writable, readable, extendible, prunableis_empty, is_full

-- Usual invariants:0 <= count ; count <= capacityis_empty = (count = 0) ; is_full = (count =

capacity)

if s.deletable thens.delete (v)

end

-- Some rejected names:

if s.addable thens.add (v)

end

Commands:put, extend, replace, forcewipe_out, remove, prunemake -- For creation

99

- 4 -

Design by Contract

100

Design by Contract

Contract Principle

Every software elementshould be characterized

by a precise specification

101

Design by Contract: applications

Getting the software right Analysis Design Implementation Debugging Testing Management Maintenance Documentation

102

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

103

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!

http://www.eiffel.com/

104

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

requirerepresentable (b)

do…

ensureequivalent (b, Result)

end

105

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

106

Contracts for analysis

Client

Supplier

(Satisfy precondition:)

Make sure input valve is open, output valve closed

(Satisfy postcondition:)

Fill the tank and close both valves

OBLIGATIONS

(From postcondition:)

Get filled-up tank, with both valves closed

(From precondition:)

Simpler processing thanks to assumption that valves are in the proper initial position

BENEFITSfill

107

Class invariant

Postcondition

Precondition

Specified, notimplemented

Constracts for analysis

deferred class VAT inherit

TANKfeature

in_valve, out_valve : VALVE

fill -- Fill the vat.

requirein_valve.openout_valve.closed

deferred

ensurein_valve.closed

out_valve.closedis_full

end

empty, is_full, is_empty, gauge, maximum,

invariantis_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum)

end

108

A class without contracts

classACCOUNT

feature -- Access

balance : INTEGER-- Balance

Minimum_balance: INTEGER = 1000-- Minimum balance

feature {NONE } -- Deposit and withdrawal

add (sum : INTEGER)-- Add sum to the balance.

dobalance := balance + sum

end

Secret features

109

A class without contracts

feature -- Deposit and withdrawal operations

deposit (sum : INTEGER)-- Deposit sum into the account.

doadd (sum)

end

withdraw (sum : INTEGER)-- Withdraw sum from the account.

doadd (– sum)

end

may_withdraw (sum : INTEGER): BOOLEAN-- Is it permitted to withdraw sum from the

account?do

Result := (balance - sum >= Minimum_balance)

endend

110

Introducing contracts

classACCOUNT

create

make

feature {NONE } -- Initializationmake (initial_amount: INTEGER)

-- Set up account with initial_amount.

require

large_enough: initial_amount >= Minimum_balance

dobalance := initial_amount

ensure

balance_set: balance = initial_amountend

111


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

balance := balance + sum ensure

increased: balance = old balance + sum end

112


feature -- Deposit and withdrawal operations

deposit (sum : INTEGER)-- Deposit sum into the account.

requirenot_too_small: sum >= 0

doadd (sum)

ensureincreased: balance = old balance +

sumend

Precondition

Postcondition

113


withdraw (sum : INTEGER)-- Withdraw sum from the account.

requirenot_too_small: sum >= 0not_too_big: sum <= balance –

Minimum_balancedo

add (–sum)

-- i.e. balance := balance – sumensure

decreased: balance = old balance - sum

endValue of balance, captured on entry to routine

114

The contract

Client

Supplier

(Satisfy precondition:)

Make sure sum is neither too small nor too big

(Satisfy postcondition:)

Update account for withdrawal of sum

OBLIGATIONS

(From postcondition:)

Get account updated with sum withdrawn

(From precondition:)

Simpler processing: may assume sum is within allowable bounds

BENEFITSwithdraw

115

The imperative and the applicative

do

balance := balance - sum

ensure

balance = old balance - sum

PRESCRIPTIVE DESCRIPTIVE

How?

Operational

Implementation

Command

Instruction

Imperative

What?

Denotational

Specification

Query

Expression

Applicative

116


may_withdraw (sum : INTEGER ): BOOLEAN-- Is it permitted to withdraw sum from

account?do

Result := (balance - sum >= Minimum_balance)

end

invariantnot_under_minimum: balance >= Minimum_balance

end

117

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 (...)

118

The correctness of a class

For every creation procedure cp :

{Precp } docp {INV and Postcp }

For every exported routine r :

{INV and Prer } dor {INV and Postr }

x.f (…)

x.g (…)

x.h (…)

create x.make (…) S1

S2

S3

S4

119

Uniform Access

balance = deposits.total – withdrawals.total

(A1)list_of_deposits

list_of_withdrawals

200 100 500 1000

800 100 100

(A2)

200 300 500 1000

800 100 100

list_of_deposits

list_of_withdrawals

balance 1000

120

What are contracts good for?

Writing correct software (analysis, design, implementation, maintenance, reengineering) Documentation (the “contract” form of a class)Effective reuseControlling inheritancePreserving the work of the best developers

Quality assurance, testing, debugging (especially in connection with the use of libraries) Exception handling

121

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”)

122

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 }

123

Contracts: run-time effect

Compilation options (per class, in Eiffel): No assertion checking Preconditions only Preconditions and postconditions Preconditions, postconditions, class invariants All assertions

124

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 softwareA revolutionary form of quality assurance

125

Lists in EiffelBase

Cursor

item

index

count1

forthback

finishstart

afterbefore

“Munich"

126

Trying to insert too far right

Cursor

(Already past last element!)

count1

after

"Munich"

127

A command and its contract

Precondition

Postcondition

128

Moving the cursor forward

Cursor

index

forth

count1

afterbefore

"Munich"

129

Two queries, and command forth

130

Where the cursor may go

Valid cursor positions

0 index1

afterbefore

"Munich"

count count + 1

131

From the invariant of class LIST

Valid cursor positions

132

Contracts and bug types

Preconditions are particularly useful to find bugs in client code:

YOUR APPLICATION

COMPONENT LIBRARY

your_list.insert (y, a + b + 1)

i <= count + 1

insert (x : G ; i : INTEGER)require

i >= 0

class LIST [G ] feature

133


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

134


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

135

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?)

136

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.

137

Uses of the contract &interface forms

Documentation, manualsDesignCommunication between developersCommunication between developers and managers

138

Contracts and inheritance

Issues: what happens, under inheritance, to

Class invariants?

Routine preconditions and postconditions?

139

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.

140

Contracts and inheritance

require

ensure

rrequire

ensure

a1 : A

a1.r (…)

…

Correct call in C: if a1. then a1.r (...) -- Here a1. holds end

r ++

C A

D B

ClientInheritance ++ Redefinition

141

Assertion redeclaration rule

When redeclaring a routine, we may only:

Keep or weaken the precondition

Keep or strengthen the postcondition

142

A simple language rule does the trick!

Redefined version may have nothing (assertions kept by default), or

require else new_preensure then new_post

Resulting assertions are: original_precondition or new_pre

original_postcondition and new_post

Assertion redeclaration rule in Eiffel

143

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

144

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.

145

Genericity and inheritance

LIST_OF_CARS

SET_OF_CARS

LINKED_LIST_OF_CARS

LIST_OF_CITIES

LIST_OF_PERSONS

Abstraction

Specialization

Type parameterization


Genericity

Inheritance

146

Extending the basic notion of class

LIST_OF_CARS

SET_OF_CARS

LINKED_LIST_OF_CARS

LIST_OF_CITIES

LIST_OF_PERSONS

LINKED_LIST_OF_CITIES

SET_OF_PERSONS

Genericity

Inheritance

147

An inheritance hierarchy

center * display

*rotate *

perimeter *

perimeter+

perimeter+

perimeter+

+

diagonal

...

...

perimeter+

+

side2

* deferred

+ effective

++ redefined

perimeter+

+

side1

CLOSED_FIGURE

OPEN_FIGURE

FIGURE

SEGMENT POLYLINE

TRIANGLE

POLYGON

ELLIPSE

RECTANGLE

SQUARE

CIRCLE

side

*

**

148

Redefinition 1: polygons

class POLYGON inheritCLOSED_FIGURE

createmake

featurevertex : ARRAY [POINT]vertex_count : INTEGER perimeter : REAL

-- Perimeter lengthdo from ... until ... loop

Result := Result + vertex [i ] . distance (vertex [i + 1])

... endend

invariantvertex_count >= 3vertex_count = vertex.count

end

vertex [i ]

vertex [i + 1]

149

Redefinition 2: rectangles

class RECTANGLE inheritPOLYGON

redefine perimeter

endcreate

make

featurediagonal, side1, side2 : REAL

perimeter : REAL-- Perimeter length

do Result := 2 * (side1 + side2) endinvariant

vertex_count = 4end

side1

side2diagonal

150

Inheritance, typing &polymorphism

(POLYGON )

(RECTANGLE )

p

r

Assume: p : POLYGON ; r : RECTANGLE ; t : TRIANGLE ; x : REAL

Permitted:

x := p.perimeterx := r.perimeterx := r.diagonalp := r

NOT permitted:

x := p.diagonal -- Even just after p := r ! r := p

151

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.

152

Dynamic binding

What is the effect of this (assuming some_test true)?

if some_test thenp := r

elsep := 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 run-time form of p

153

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.

154

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

155

With inheritance &associated techniques

f : FIGUREc : CIRCLEp : POLYGON

create c.make (...)create p.make (...)

if ... then f := c

else f := p

end

f.move (...)f.rotate (...)f.display (...)

-- and so on for every -- operation on f !

With:

Initialize:

and:

Then just use:

156


LIST_OF_CARS

SET_OF_CARS

LINKED_LIST_OF_CARS

LIST_OF_CITIES

LIST_OF_PERSONS

Abstraction

Specialization



Genericity

Inheritance

157

Genericity

Unconstrained

LIST [G]e.g. LIST [INTEGER], LIST [PERSON]

Constrained

HASH_TABLE [G ―> HASHABLE ]

VECTOR [G ―> NUMERIC ]

158

Genericity: Ensuring type safety

How can we define consistent “container” data structures, e.g. list of accounts, list of points? Dubious use of a container data structure:

c : CITY ; p : PERSONcities : LIST ... people : LIST ... ---------------------------------------------------------people.extend ( )

cities.extend ( )

c := cities.last

c. some_city_operation

What if wrong?

p

c

159

A generic class

class LIST [G ] feature

extend (x : G ) ...

last : G ...

end

To use the class: obtain a generic derivation, e.g.

cities : LIST [CITY ]

Formal generic parameter

Actual generic parameter

160

Using generic derivations

cities : LIST [CITY ]people : LIST [PERSON]c : CITYp : PERSON...

cities.extend (c)people.extend (p)

c := cities.last

c. some_city_operation

STATIC TYPING

The compiler will reject:

people.extend (c)

cities.extend (p)

161

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.

162

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.)

163

Genericity + inheritance 1: Constrained genericity

class VECTOR [G ] feature plus alias "+" (other : VECTOR [G]): VECTOR [G]

-- Sum of current vector and otherrequire

lower = other.lower

upper = other.upperlocal

a, b, c: Gdo

... See next ...end

... Other features ...end

164

Adding two vectors

i a b c=+

+ =u v w

1

2

165

Constrained genericity

Body of plus alias "+":

create Result.make (lower, upper)

from i := lower

until i > upper

loopa := item (i)b := other.item (i)c := a + b -- Requires “+” operation on G!

Result.put (c, i)i := i + 1

end

166

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.

167

Improving the solution

Make VECTOR itself a descendant of NUMERIC,

effecting the corresponding features:

class VECTOR [G –> NUMERIC ] inheritNUMERIC

feature... Rest as before, including infix "+"...

endThen it is possible to define

v : VECTOR [INTEGER ]vv : VECTOR [VECTOR [INTEGER ]]vvv : VECTOR [VECTOR [VECTOR [INTEGER ]]]

168


LIST_OF_CARS

SET_OF_CARS

LINKED_LIST_OF_CARS

LIST_OF_CITIES

LIST_OF_PERSONS

LINKED_LIST_OF_CITIES

SET_OF_PERSONS

Genericity

Inheritance

169

Genericity + inheritance 2: Polymorphic data structures

figs : LIST [FIGURE ]p1, p2 : POLYGONc1, c2 : CIRCLEe : ELLIPSE

(POLYGON) (CIRCLE) (POLYGON)(CIRCLE) (ELLIPSE)

class LIST [G ] featureextend (v : G) do

… endlast : G…

end

figs.extend (p1 ) ; figs.extend (c1 ) ; figs.extend (c2 )

figs.extend (e ) ; figs.extend (p2 )

170

Combining abstractions

Given the classes

TRAIN_CAR, RESTAURANT

how would you implement a DINER ?

171

Examples of multiple inheritance

Combining separate abstractions:

Restaurant, train car Calculator, watch Plane, asset Home, vehicle Tram, bus

172

Composite figures

173

Multiple inheritance: Composite figures

A composite figure

Simple figures

174

Defining the notion of composite figure

COMPOSITE_FIGURE

centerdisplayhiderotatemove…

countputremove…

FIGURELIST

[FIGURE ]

175

In the overall structure

COMPOSITE_FIGURE

FIGURELIST [FIGURE ]

OPEN_FIGURE

CLOSED_FIGURE

SEGMENT POLYLINE POLYGON ELLIPSE

RECTANGLE

SQUARE

CIRCLE

TRIANGLE

perimeter+

perimeter*

perimeter++

diagonal

perimeter++

perimeter++

perimeter+

176

A composite figure as a list

Cursor

item

forth

after

177

Composite figures

class COMPOSITE_FIGURE inheritFIGURE

LIST [FIGURE]feature

display-- Display each constituent figure in turn.

dofrom start until after loop

item.display

forth endend... Similarly for move, rotate etc. ...

end

Requires dynamic binding

178

Multiple inheritance: Combining abstractions

COMPARABLE NUMERIC

STRING COMPLEX

INTEGER

REAL

<, <=, >, >=, …

+, –, *, / …(total order

relation)(commutative ring)

179

Renaming

‘‘Graphical’’ features: height, width, change_height, change_width, xpos, ypos, move...‘‘Hierarchical’’ features: superwindow, subwindows, change_subwindow, add_subwindow...

class WINDOW inheritRECTANGLETREE [WINDOW]

renameparent as superwindow,children as subwindows,add_child as add_subwindow…

endfeature

...end

BUT: see style rules about

uniformity of feature names

180

- 5 -

Some newdevelopments

181

Some recent developments

Void safety

Automatic testing

Concurrency

182

Basic O-O operation…

x.f (args)

… and basic issue studied here:

(If not, call produces an exception and usually termination)

Semantics: apply the feature f, with given args if any, to the object to which x is attached

How do we guarantee that x will always be “attached” to an object?

183

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)

184

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

185

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

186

Caveat

I am mostly talking about:

Functional testing

Unit testing

187

What is testing about?

To test a software system is to try to make it fail

Testing is none of:Ensuring software qualityAssessing software

qualityDebugging

(Terminology: failure, fault, mistake)Fiodor Chaliapineas Mephistopheles

“Ich bin der Geist, der stets verneint”

Goethe, Faust, Act I

188

1. To test a program is to try tomake it fail

2. Tests are no substitute forspecifications

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 contracts5. A test suite must include both manual and automated cases6. Don’t believe your testing insights: evaluate any testing

strategy through objective criteria7. The most important criterion is number of faults found against

time: fc (t)

Seven principles of software testing

Bertrand Meyer, Seven Principles of Software Testing, IEEE Computer, August 2008

189189

“Automated testing”

What can be automated: Test suite execution Resilience Regression testing Test case generation Test result verification (oracles) Test case minimization

190190

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.

191

AutoTest: automatic test framework

Input: set of classes + testing time Generates instances, calls routines with

automaticallyselected arguments

Oracles are contracts: 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

Ilinca CiupaAndreas Leitner

(SOFSEM 2007 etc.)

192

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)...

classACCOUNT

createmake

featuremake (n :

STRING)

require

n /= Void

do

name := n

balance := 0

ensure

name = n

balance = 0end

name : STRING

balance : INTEGERdeposit (v : INTEGER) do

balance := balance + v

ensure balance = old balance + v

endinvariant name /= Void balance >= 0end

193193

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

Test all routines, including inherited ones (“Fragile base class” issue)

194

Random testing: example bug found

*SET

**

+SET1

+SET2

+ +

Test:s1, s2 : SETs2 s1

*: Deferred +: Effective

Bernd Schoeller

195

195

Some AutoTest results (random strategy)

Library Total Failed Total Failed

EiffelBase (Sep 2005) 40,000 3% 2000 6%

Gobo Math 1500 1% 140 6%

TESTS ROUTINES

196

Testing results and strategy

“Smart” ideas not always better

Don’t believe your intuitionMeasure and assess

objectively

fc (t)

Class STRING

Define good assessment criteria: Number of faults found Time to find all faults

Time

Experimental law:

fc (t ) = a – b / t

197

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

198

Who finds what faults?

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% implementationUser reports: 36% specification, 64% implementation

I.Ciupa, A. Leitner,M.Oriol, A. Pretschner

(submitted)

199

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)

200

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)

201

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”)

202

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

203

Specified but unimplemented routine

204

Running the system and entering input

(erroneous

)

20

205

Postcondition violated

The violated clause:

balance > old balance

Error caught at run time as contract violation

206

This has become a test case

206

207

Correcting and recompiling

208

One fault corrected, the other not

209

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

210

Concurrency: the SCOOP model

General-purposeMulti-threading, Web services, distribution, multiprogramming...Simplifies concurrent programmingBased on Design by Contract ideas

211

Summary

Bring every one of your development

days

to the level of your best days

212

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, 1887From 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

Eiffel in Depth Bertrand Meyer With material by Emmanuel Stapf (Eiffel Software) & members of the...

Documents

Transcript of Eiffel in Depth Bertrand Meyer With material by Emmanuel Stapf (Eiffel Software) & members of the...