- 1 - Correct ness Robust ness Secur it y Overview Process - - PDF document

1

Eif f el in Depth

Bertrand Meyer Emmanuel Stapf (Eif f el Sof tware) Pei Yu & members of the ETH Chair of Sof tware Engineering

Chair of Sof t w are Engineering

2

Plan of these slides

1 Overview 2 The environment (s) 3 Met hod overview 4 Language basics 5 Dynamic model 6 Genericit y & inherit ance 7 Design by Cont r act ™ 8 Ext er nal int er f ace 9 Agent s 10 Advanced design 11 Advanced mechanisms 12 Conclusion 13 Supplement s

3

Course organization

Course page:

ht t p:/ / se.inf .et hz.ch/ t eaching/ 2009-H/ eif f el-0291/ index.ht ml

Teaching st af f :

Lect urer: Bert rand Meyer & members of t he Chair of

Sof t war e Engineer ing

Course assist ant : Yu (Max) Pei

Grading: 70% proj ect , 30% exam Proj ect will be a web-based syst em using t he new Eif f elWeb Exam will be on last lect ure slot of t he semest er: 15 Dec.

4

Purpose of this course

To give you an in-dept h under st anding of a sof t war e met hod, language and environment : Eif f el (and Eif f elSt udio) To improve your under st anding of sof t war e engineer ing and sof t war e ar chit ect ur e To give you a f eel f or t he challenges involved in bot h sof t war e design and language design

5

The softw are of the future

Product qualit y Correct ness Robust ness Secur it y Process qualit y Fast development No semant ic gap (“impedance mismat ch”) bet ween developers and ot her st akeholders Self -validat ing, self -t est ing Ease of change Reusabilit y

6

• 1 -

Overview

2

7

Why Eiffel?

Product ivit y: f ast er t ime t o market , f ewer developers Reliabilit y: f ewer bugs Ext endibilit y: be responsive t o cust omer needs Reuse: st and on t he shoulder of giant s Ef f iciency: make t he best use of hardware resources Maint ainabilit y: spend your t ime on new development s

8

Language versions

Eif f el 1, 1986 Classes, cont r act s, genericit y, single and mult iple inherit ance, garbage collect ion, … Eif f el 2, 1988 (Obj ect -Or ient ed Sof t ware Const r uct ion) Except ions, const rained genericit y Eif f el 3, 1990-1992 (Eif f el: The Language) Basic t ypes as classes, inf ix & pref ix oper at ors… Eif f el 4, 1997 “P recur sor” and agent s Eif f el 5, ECMA St andard, 2005, revised 2006, and I SO st andard, November 2006

www.ecma-int er nat ional.org/ publicat ions/ st andards/ Ecma-367.ht m

At t ached t ypes, conversion, assigner commands…

9

Eiffel: Method, Language, Environment

Met hod :

Applicable t hroughout t he lif ecycle Obj ect -orient ed t o t he core Seamless development Based on Design by Cont ract ™ principles

Language :

Full power of obj ect t echnology Simple yet powerf ul, numerous original f eat ur es I SO st andard (2006)

Envir onment :

I nt egrat ed, provides single solut ion, including

analysis and modeling

Lot s of plat f orms (Unix, Windows, VMS, .NET…

)

Open and int eroperable

10

Some typical users

Axa Rosenberg I nvest ment management : f r om $ 2 billion t o > $ 100 billion 2 million lines Chicago Boar d of Tr ade Price report ing syst em Eif f el + CORBA + Solar is + Windows + … Xont ech (f or Boeing) Lar ge-scale simulat ions

• f missile def ense

Nort hrop-Grumman Swedish social securit y: accident report ing & management

(Eif f el) Price Report ing Syst em The Chicago Boar d of Tr ade

See: eif f el.com

11

Learning Eiffel

Simple synt ax, no cr ypt ic symbols Eif f el pr ogr ammer s know all of Eif f el Wide var iet y of user backgrounds “I f you can writ e a condit ional, you can wr it e a cont r act ” Fast lear ning cur ve Lot s of good models t o learn f rom St r ong st yle rules May need t o “unlearn” needless t ricks

12

The Eiffel method: some principles

Abst r act ion I nf ormat ion hiding Seamlessness Reversibilit y Design by Cont ract Open-Closed pr inciple Single choice pr inciple Single model pr inciple Unif or m access principle Command-query separ at ion pr inciple Opt ion-operand separ at ion pr inciple St yle mat t er s ... See next ...

3

13

The Eiffel language

Classes Unif orm t ype syst em, covering basic t ypes Genericit y I nher it ance, single and mult iple Conversion Covar iance St at ically t yped Built -in Design by Cont r act mechanisms Agent s: obj ect s encapsulat ing behavior “Once” mechanisms, replacing st at ics and globals Void saf et y (new!)

14

Libraries

Fundament al dat a st r uct ur es and algor it hms Por t able gr aphics I nt ernet , Web Lexical analysis, par sing Dat abase int erf aces

15

Dogmatism and flexibility

Dogmat ic wher e it count s:

I nf ormat ion hiding (e.g. no x.a := b) Over loading “One good way t o do anyt hing” St yle rules

Flexible when it makes no point t o har ass pr ogr ammer s:

Give st andar d not at ions (e.g. a + b) an O-O

int erpr et at ion

Synt ax, e.g. semicolon

16

The Eiffel language: there is a hidden agenda That you f orget it even exist s

17

• 2 -

The environment

18

EiffelStudio

Serializat ion EiffelStore

Eif f elStudio

Ansi C Executable system I L Eif f elBase WEL Eif f elVision Eif f elNet Eif f elWeb Eif f elMath Eif f elCOM Persistent

• bjects

Eif f el Runtime Dat abases (Rel, OO)

C compilation Jitter Eif f el compilation

User classes

General library Win32 library Networking Web development Advanced numerics

Ext ernal C/ C++/ Java . NET Assemblies

Eif f elBuild

GUI builder

Multiplatf orm GUI library

• Browsing, f ast compiling

(Melting I ce™), debugging, diagrams, met rics. . .

4

19

EiffelStudio: Melting Ice™ Technology

Fast recompilat ion: t ime depends on size of change, not size of pr ogr am Full t ype checking “Fr eeze” once in a while Opt imized compilat ion: f inalize. Small pr ogr am Lar ge pr ogr am Small change Big change

20

Melting Ice Technology FROZEN

MELTED

Eif f elSt udio Your syst em

Machine code (f r om C code)

Edit, browse, execute, debug, test…

Freeze Melt

21

Performance

“Finalizat ion” mode of compilat ion applies ext ensive

• pt imizat ions:

I nlining Dead code r emoval Cont r act r emoval ...

Opt imizat ions ar e compiler-applied and aut omat ic; no need f or manual hacking Compact ing garbage collect ion t akes care of memory issues I nt ended t o mat ch t he most exact ing demands of indust r y applicat ions

22

EiffelStudio brow sing and debugging

You are dealing wit h “development obj ect s”:

Classes Feat ures Run-t ime obj ect s (f or debugging)

To work on an obj ect , “pick-and-drop” it int o an appropriat e t ool

23

Openness

Eif f el can be used as “component combinat or” t o package element s f rom dif f er ent sources:

Mechanisms f or int egrat ing element s in C, C++, J ava,

CI L (.NET)

I nt er f aces and libraries: SQL, XML, UML (XMI ),

CORBA, COM, ot her s

Par t icular ly sophist icat ed mechanisms f or C/ C++

int er f acing

Out side of .NET, compiles down t o ANSI C code,

f acilit at es suppor t f or C and C++ easier .

On .NET, seamless int egr at ion wit h C# , VB .NET et c.

24

C/C++ support

Funct ions, macros, include f iles, set t ers, get t ers, const r uct ors, dest ruct ors et c. I nline C From t he out side int o Eif f el:

CECI L (C-Eif f el Common I nt erf ace Library)

5

25

Portability

Source- code port abilit y across:

Windows NT, 2000, XP, Vist a Windows 98, Me .NET Solar is, ot her commer cial Unix var iant s Linux Mac OS X (f ort hcoming) BSD (Berkeley Syst em Dist ribut ion) VMS

26

• 3 -

The met hod

27

The w aterfall model of the lifecycle

Feasibilit y st udy Requirement s Global design Det ailed design Deployment V & V Specif icat ion I mplement at ion

28

Traditional lifecycle model

Rigid model:

Wat er f all: separ at e t asks,

impedance mismat ches

Var iant s, e.g. spir al, r et ain

some of t he pr oblems Separ at e t ools:

Pr ogr amming envir onment Analysis & design t ools, e.g. UML

Consequences:

Har d t o keep model, implement at ion,

document at ion consist ent

Const ant ly r econciling views I nf lexible, har d t o maint ain syst ems Har d t o accommodat e bout s of lat e wisdom Wast es ef f or t s Damages qualit y Feasibilit y st udy Requirement s Global design Det ailed design Deployment V & V Specif icat ion I mplement at ion

29

The Eiffel model

Seamless development :

Single not at ion, t ools,

concept s, pr inciples t hroughout

Eif f el is as much f or analysis &

design as implement at ion & maint enance

Cont inuous, incr ement al

development

Keep model, implement at ion

and document at ion consist ent

Rever sibilit y: go back & f or t h Saves money: invest in single

set of t ools

Boost s qualit y

Example classes: P LANE, ACCOUNT, TRANSACTI ON… STATE, COMMAND… HASH_TABLE… TEST_DRI VER… TABLE…

Analysis Design I mplemen- t at ion V&V Generali- zat ion

30

Seamlessness Seamlessness Principle

Sof tware development should rely

• n a single set of notations & tools

6

31

Reversibility Reversibilit y P rinciple

The sof tware development process, notations and tools should allow making changes at any step in the process

32

The seamless, reversible model

Example classes: P LANE, ACCOUNT, TRANSACTI ON… STATE, COMMAND… HASH_TABLE… TEST_DRI VER… TABLE…

Analysis Design I mplemen- t at ion V&V Generali- zat ion

33

Class invar iant

P

• st condit ion

P r econdit ion

Specif ied, not implement ed

Analysis classes

def erred class VAT inherit TANK f eat ure in_valve, out _valve : VALVE f ill

• - Fill t he vat .

require in_valve.open

• ut _valve.closed

def erred ensure in_valve.closed

• ut _valve.closed

is_f ull end empt y, is_f ull, is_empt y, gauge, maximum, invariant is_f ull = (gauge > = 0.97 * maximum) and (gauge < = 1.03 * maximum) end

34

Single model

Use a single base f or everyt hing: analysis, design, implement at ion, document at ion... Use t ools t o ext r act t he appropr iat e views.

Single Model Principle

All the inf ormation about a sof tware system should be in the sof tware text

35

The seamless, reversible model

Analysis Design I mplemen- t at ion V&V Generali- zat ion

36

Generalization

Prepare f or reuse:

Remove built -in limit s Remove dependencies on

specif ics of proj ect

I mprove document at ion,

cont r act s...

Abst r act Ext r act commonalit ies,

revamp inherit ance hier ar chy

36

A D I V

G

A * B Y * X Z T U

7

37

The cluster model

A D I V G

Permits dynamic reconfiguration

A D I V G A D I V G A D I V G A D I V G A D I V G

Mix of sequential and concurrent engineering

38

Tool support for seamless development

Diagr am Tool

• Syst em diagr ams can be pr oduced aut omat ically

f rom sof t ware t ext

• Works bot h ways: updat e diagr ams or updat e t ext

– ot her view immediat ely updat ed

No need f or separ at e UML t ool Met rics Tool P

r of iler Tool

Document at ion generat ion t ool ...

39

EiffelStudio diagram tool

40

Text-graphics equivalence

41

Equivalence Equivalence Principle

Textual, graphical and other views should all represent the same model

42

Eiffel mechanisms

Classes, obj ect s, ... Single and mult iple inher it ance I nherit ance f acilit ies: redef init ion, undef init ion,

renaming

Gener icit y, const rained and unconst rained Saf e covariance Disciplined except ion handling, based on principles of

Design by Cont ract

Full GC Agent s (power of f unct ional programming in O-O!) Unrest rict ed st reaming: f iles, dat abases, net works...

8

43

What is not in Eiffel

Got o Funct ions as ar gument s P

• int er arit hmet ic

Special increment synt ax, e.g. x++, ++x I n-class f eat ure overloading

44

Syntax conventions

Semicolon used as a separ at or (not t er minat or) I t ’s opt ional almost all t he t ime. J ust f or get about it ! St yle rules are an import ant part of Eif f el:

Every f eat ure should have a header comment Every class should have an indexing clause Layout , indent at ion Choice of names f or classes and f eat ures

45

The class

From t he module viewpoint :

Set of available services (“f eat ur es”) I nf ormat ion hiding Classes may be client s of each ot her

From t he t ype viewpoint :

Describes a set of run-t ime obj ect s (t he inst ances of

t he class)

Used t o declare variables (more generally, ent it ies),

e.g. x : C

Possible t ype checking Not ion of subt ype

46

Information hiding I nf ormat ion Hiding principle

Every module should have a public specif ication, listing a subset of its properties

47

pr epend animat e append

An object has an interface

count st at ions f ir st last

48

pr epend animat e append count f ir st

An object has an im plem entation

count st at ions f ir st last

9

49

Information hiding

pr epend animat e append count st at ions f ir st last

50

Information Hiding

The designer of every module must select a subset

• f it s pr opert ies as t he
• f f icial inf ormat ion about

t he module, made available t o aut hors of client modules P ublic P r ivat e

51

Uniform access Unif orm access principle

I t does not matter to the client whether you look up or compute

52

Uniform Access: an example

balance = list _of _deposit s.t ot al – list _of _wit hdr awals.t ot al (A1)

200 100 500 1000 800 100 100

(A2)

200 300 500 1000 800 100 100

list _of _deposit s list _of _wit hdr awals list _of _deposit s list _of _wit hdr awals balance 1000

53

Uniform access

A call such as your_account.balance could use an at t ribut e or a f unct ion

Unif orm access principle

I t does not matter to the client whether you look up or compute

54

POI NT : as an abstract data type

x : POI NT REAL y : POI NT REAL : POI NT REAL : POI NT REAL Class POI NT: Choose a represent at ion (polar, cart esian) I n polar represent at ion, and are at t ribut es, x and y ar e rout ines. y x

10

55

POI NT: as a class

class POI NT f eature x, y : REAL

• - Car t esian coor dinat es

move (a, b : REAL)

• - Move by a hor izont ally and b ver t ically.

do x := x + a y := y + b end scale (f act or : REAL)

• - Scale by f act or .

do x := f act or x y := f act or y end

56

Class POI NT

dist ance (p : POI NT ): REAL

• - Dist ance t o p

do Result := sqr t ((x – p.x)^2 + (y – p.y)^2) end r o: REAL

• - Dist ance t o or igin (0, 0)

do Result := sqr t (x ^ 2 + y ^ 2) end t het a : REAL

• - Angle t o hor izont al axis

do … end end

57

Uniform access through feature call

To access a f eat ur e of a point , same not at ion r egar dless

• f repr esent at ion.

Example: p1.x

Cart esian r epr esent at ion: at t r ibut e call P

• lar represent at ion: f unct ion call

No dif f erence f or client s (except possibly per f ormance)

58

Uniform access in practice

Class COMP LEX, swit ching silent ly and on demand bet ween cart esian and polar repr esent at ion Secr et at t ribut es: car t esian_upt odat e, polar_upt odat e: BOOLEAN Represent at ion invar iant : invariant at _least _one: car t esian_upt odat eor polar_upt odat e

59

Updating representation: secret routine

updat e_car t esian require polar _ok: polar_upt odat e do if not car t esian_upt odat e t hen int er nal_x := r o cos (t het a) int er nal_y := r o sin (t het a) end ensure car t _ok: car t esian_upt odat e polar _ok: polar_upt odat e end

60

Public query

x : REAL

• - Abscissa of cur rent point

do if not car t esian_available t hen updat e_car t esian end Result := x_int er nal ensure car t _ok : car t esian_upt odat e same_as_int er nal : Result = x_int er nal end

11

61

Adding tw o complex numbers

plus (ot her : COMP LEX )

• - Add ot her t o current complex number .

do updat e_car t esian x_int er nal := x_int er nal + ot her.x y_int er nal := y_int er nal + ot her.y ensure car t esian_ok : car t esian_upt odat e end

62

Beyond information hiding Single choice principle I f a system supports a set of choices,

• nly one of its elements should know the list

63

Single choice: examples Graphic syst em: set of f igures Edit or: set of commands Compiler: set of language const ruct s Single choice principle I f a system supports a set of choices,

• nly one of its elements should know the list

64

Without dynamic binding! display (f : FI GURE) do if ‘‘f is a CI RCLE’’ then ... elseif ‘‘f is a POLYGON’’ then ... end end and similarly f or all ot her rout ines! Tedious; must be changed whenever t here’s a new f igure t ype

65

With inheritance & associated techniques

f : FI GURE c : CI RCLE p : POLYGON creat e c.make (...) creat e p.make (...) if ... t hen f := c else f := p end f .move (...) f .r ot at e (...) f .display (...)

• - and so on f or every
• - oper at ion on f !

Wit h: I nit ialize: and: Then j ust use:

66

Memory management Memory management principle I t is the implementation’s responsibility to reclaim unused objects

12

67

What to do w ith unreachable objects

Ref erence assignment s may make some

• bj ect s useless.

Two possible approaches:

Manual “f r ee” (C++). Aut omat ic gar bage collect ion

“Almaviva” name landlor d loved_one a O1 “Figaro” O2 “Susanna” O3

• 68

The C programmer’s view

Newsgroup post ing by I an St ephenson, 1993 (as cit ed in Obj ect -Or ient ed Sof t ware Const r uct ion, 2nd edit ion): I say a big NO ! Leaving an unref erenced

• bj ect

around is BAD P ROGRAMMI NG. Obj ect point er s ARE like or dinar y point er s — if you allocat e an obj ect you should be responsible f or it , and f r ee it when it s f inished wit h. (Didn' t your mot her always t ell you t o put your t oys away when you' d f inished wit h t hem?)

69

Arguments for automatic collection

Manual r eclamat ion is danger ous f or r eliabilit y.

Wrong “f r ees” are among t he most dif f icult bugs t o

det ect and cor rect . Manual reclamat ion is t edious. Modern garbage collect ors have accept able perf ormance

• verhead.

GC is t unable: disabling, act ivat ion, par amet er izat ion....

70

Properties of a garbage collector (GC)

Soundness: I f t he GC reclaims an obj ect , it is unreachable Complet eness : I f an obj ect is unr eachable, t he GC will

r eclaim it Soundness is an absolut e requirement . Bet t er no GC t han an unsound GC But : saf e aut omat ic gar bage collect ion is har d in C-based languages

71

Language style Consist ency principle

The language should of f er

• ne good way to do anything usef ul

72

Language style Compat ibilit y principle

Traditional notations should be supported with an O- O semantics

13

73

Infix and prefix operators

I n

a b

t he oper at or is “inf ix” (writ t en bet ween oper ands) I n

b

t he oper at or is “pr ef ix” (writ t en bef ore t he operand)

74

The object-oriented form of call

some_t arget.some_f eat ure (some_argument s) For example: my_f igur e.display my_f igur e.move (3, 5) x := a.plus (b) ???????

75

Operator features

expanded class I NTEGER f eature plus alias "+" (ot her : I NTEGER): I NTEGER

• - Sum wit h ot her

do ... end t imes alias "" (ot her : I NTEGER): I NTEGER

• - Pr oduct by ot her

do ... end minus alias "-" : I NTEGER

• - Unar y minus

do ... end ... end Calls such as i.plus ( j ) can now be wr it t en i + j

76

Assignment commands

I t is possible t o def ine a query as t emper at ur e: REAL assign set _t emperat ur e Then t he synt ax x.t emperat ure := 21.5 is accept ed as an abbr eviat ion f or x.set _t emperat ur e(21.5) Ret ains cont ract sand any ot her supplement ar y oper at ions

Not an assignment , but a pr ocedur e call

77

Command-query separation Command-Query Separat ion P rinciple

A f unction must not change its target object’s state

78

Command-Query separation

A command (procedur e) does somet hing but does not ret urn a r esult . A query (f unct ion or at t ribut e) ret urns a result but does not change t he st at e.

14

79

Command-Query Separation

Asking a quest ion should not change t he answer!

80

Command-query separation Command-Query Separat ion P rinciple

A f unction must not change its target object’s state

This pr inciple excludes many common schemes, such as using f unct ions f or input (e.g. C’s get int or equivalent ).

81

Referential transparency

I f t wo expressions have equal value,

• ne

may be subst it ut ed f or t he ot her in any cont ext where t hat ot her is valid. I f a = b, t hen f (a) = f (b) f or any f . Prohibit s f unct ions wit h side ef f ect s. Also:

For any int eger i, nor mally i +

i = 2 x i

But even if get int () = 2, get int () + get int () is

usually not equal t o 4.

82

Command-query separation

I nput mechanism using Eif f elBase (inst ead of n := get int ()): io.read_int eger n := io.last _int eger

83

A discipline of development Reuse Pr inciple

Design with reuse in mind

84

Typical API in a traditional library (NAG)

nonlinear _ode (equat ion_count : in I NTEGER; epsilon : in out DOUBLE; f unc : procedure (eq_count : I NTEGER; a: DOUBLE; eps : DOUBLE; b : ARRAY [DOUBLE]; cm : point er Libt ype); lef t _count , coupled_count : I NTEGER … ) [And so on. Alt oget her 19 ar gument s, including:

• 4 in out values;
• 3 arrays, used bot h as input and out put ;
• 6 f unct ions, each wit h 6 or 7 argument s, of which

2 or 3 ar r ays!] Or dinar y dif f erent ial equat ion

15

85

The EiffelMath routine

... Cr eat e e and set -up it s values (ot her t han def ault s) ...

e.solve

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

86

The Consistency Principle

Two component s:

Top-down and deduct ive (t he overall design). Bot t om-up and induct ive (t he convent ions).

Consist ency Principle

All the components of a library should proceed f rom an overall coherent design, and f ollow a set of systematic, explicit and unif orm conventions.

87

The key to building a library

Devising a t heor y of t he underlying domain

88

Some of the theory behind EiffelBase

CONTAINER BOX FINITE INFINITE BOUNDED UNBOUNDED FIXED RESIZABLE COLLECTION

BAG SET TABLE ACTIVE SUBSET

DISPENSER INDEXABLE CURSOR_ STRUCTURE SEQUENCE TRAVERSABLE HIERAR_ CHICAL LINEAR BILINEAR

* * * * * * * * * * * * * * * * * * * * * *

COUNTABLE

*

Representation Access Iteration

89

The size of feature interfaces

Mor e r elevant t han class size f or assessing complexit y. St at ist ics f r om Eif f elBase and associat ed libr ar ies: Number of f eat ur es 4408 Per cent age of quer ies 66% Per cent age of commands 34% Aver age number of ar gument s t o a f eat ur e 0.5 Maximum number 5 No ar gument s 57% One ar gument 36% Two ar gument s 6% Thr ee or mor e ar gument s 1%

90

Operands and options

Two possible kinds of ar gument t o a f eat ure:

Operands: values on which f eat ure will operat e Opt ions: modes t hat govern how f eat ur e will operat e

Example (non-O-O): print ing a real number

• print (r eal_value, number_of _signif icant _digit s,

zone_lengt h, number_of _exponent _digit s, ...) The number is an operand; f ormat propert ies (e.g. number

• f signif icant digit s, widt h) ar e opt ions

O-O example:

my_window.display (x_posit ion, y_posit ion,

height , widt h, t ext , t it le_bar_t ext , color , ...)

16

91

Recognizing options from operands

Two crit er ia t o recognize an opt ion:

There is a reasonable def ault value. During t he evolut ion of a class, oper ands will

nor mally r emain t he same, but opt ions may be added.

92

Option-Operand separation

Opt ion values:

Def ault s (specif ied universally, per t ype, per obj ect ) To set specif ic values, use appr opriat e “set t er”

procedures Example: my_window.set _background_color ("blue") ... my_window.display

Opt ion-Operand Principle

Only operands should appear as arguments of a f eature

93

Naming (classes, features, variables…)

Tradit ional advice (f or or dinar y applicat ion pr ogr amming): Choose meaningf ul variable names!

94

ent er push add insert

Original

Class ARRAY STACK QUEUE HASH_TABLE ent r y t op

• ldest

value pop remove_oldest delet e Feat ures

names for EiffelBase classes

put put put put it em it em it em it em remove remove remove

Final

ent er push add inser t

Class ARRAY STACK QUEUE HASH_TABLE

r emove_oldest delet e

Feat ures put put put it em it em it em it em remove remove remove

ent r y t op

• ldest

value

put

New and old names for EiffelBase classes

95

Naming rules

Achieve consist ency by syst emat ically using a set of st andar dized names. Emphasize commonalit y over dif f erences. Dif f er ences will be capt ured by:

Signat ures (number and t ypes of ar gument s &

result )

Asser t ions Comment s

96

Some standard names

Quer ies (non-boolean): count , capacit y it em t o_X, f rom_X Queries (boolean) : wr it able, r eadable, ext endible, prunable is_empt y, is_f ull

• - Usual invar iant s:

0 < = count ; count < = capacit y is_empt y = (count = 0) ; is_f ull = (count = capacit y) if s.delet able t hen s.delet e (v) end

• - Some rej ect ed names:

if s.addable t hen s.add (v) end Commands: put , ext end, r eplace, f orce wipe_out , remove, prune make -- For creat ion