From Eiffel and Design by Contract to Trusted

From Eiffel and Design by Contract to Trusted Components Bertrand Meyer ETH Zürich / Eiffel Software Webinar for Chinese readers, 7 July 2004 Copyright © Bertrand Meyer, 2004 1

My background l Since 1985: Founder (now Chief Architect) of Eiffel Software, in Santa Barbara. Produces advanced tools and services to improve software quality, based on Eiffel ideas l Since 2001: Professor of Software Engineering at ETH Zürich (department chair starting October 2004) l Also adjunct professor at Monash University in Australia (1998 -2003) 2

Software engineering The collection of processes, methods, techniques, tools and languages for developing quality operational software. 3

The challenge l What does it take to bring software engineering to the next level? 4

Today’s software is often good enough Overall: l Works most of the time l Doesn’t kill too many people l Negative effects, esp. financial, are diffuse Significant improvements since early years: l Better languages l Better tools l Better practices (configuration management) 5

Eiffel l Method, language and environment l Fully object-oriented; not a hybrid with other approaches l Focuses on quality, especially reliability, extendibility and reusability l Emphasizes simplicity l Used for many mission-critical projects in industry l International standard in progress through ECMA 6

Large Eiffel projects in industry AXA Rosenberg Chicago Board of Trade Boeing AMP Investments Lockheed Martin EMC Environmental Protection Agency Swedish National Health Board Hewlett Packard ENEA Cap Gemini Ernst & Young Northrop Grumman 7

Environment: the two offerings from Eiffel Software l Eiffel. Studio (“Classic Eiffel”) Windows, Unix, Linux, VMS, . NET. . . l ENVi. Sio. N! for Visual Studio. NET Projects are compatible 8

Eiffel. Studio Eiffel. Base User classes General library Eiffel. Build GUI builder Persistent objects Browsing, fast compiling (Melting Ice™), debugging, diagrams, metrics. . . Eiffel. Vision Multiplatform GUI library Serialization WEL Ansi C Win 32 GUI Eiffel. Web scripting Eiffel. Studio Eiffel compilation Advanced numerics Eiffel Runtime Eiffel. Net Eiffel. COM Jitter Executable system IL Eiffel. Math Networking C compilation External C/C++/Java . NET Assemblies Eiffel. Store Databases (Rel, OO) 9

Eiffel. Studio: Melting Ice™ Technology l l l Fast recompilation: time depends on size of change, not size of program “Freeze” once in a while Optimized compilation: finalize. 10

Melting Ice Technology YOUR SYSTEM Machine code (from C code) FROZEN FREEZING Execution, browsing, debugging, documentation. . . EIFFELSTUDIO MELTING MELTED 11

Portability Full source-code portability across: l Windows NT, 2000, XP l Windows 98, Me l Solaris, other commercial Unix variants l Linux l BSD (Berkeley System Distribution) l VMS 12

Portable graphics Eiffel. Vision 2 library: l Simple programming model l Produce impressive GUI simply and quickly l Easy to learn l Completely portable across supported platforms l Rich set of controls, matches users’ most demanding needs l Adapts automatically to native look & feel 13

Eiffel. Vision layers Eiffel. Vision WEL GEL etc. 14

Openness to other approaches l Extensive mechanisms to support C and C++ constructs l Java interface l On. NET, seamless integration with C#, Visual Basic etc. 15

Special syntax for C/C++ support class RECT_STRUCT feature -- Access x (a_struct: POINTER): INTEGER is external "C struct RECT access x use <windows. h>" end feature -- Settings set_x (a_struct: POINTER; a_x: INTEGER) is external "C struct RECT access x type int use <windows. h>" end 16

Performance l Optimizations are automatic: Inlining, dead code removal… l Garbage collection takes care of memory issues l Performance matches the demand of the most critical industry applications 17

Eiffel mechanisms l l l l l 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. . . 18

Genericity Since 1986 (First time genericity & inheritance combined) Unconstrained LIST [G] e. g. LIST [INTEGER], LIST [PROFESSOR] Constrained HASH_TABLE [G ―> HASHABLE] VECTOR [G ―> NUMERIC] 19

Multiple inheritance TRAIN_CAR RESTAURANT_ CAR 20

Common examples of multiple inheritance l Combining separate abstractions: • • • Restaurant, train car Calculator, watch Plane, asset 21

Multiple inheritance: Combining abstractions * COMPARABLE * NUMERIC INTEGER REAL STRING DOUBLE COMPLEX 22

l deferred class COMPARABLE [G] feature infix "<" (other: COMPARABLE [G]): BOOLEAN is deferred end infix "<=" (other: COMPARABLE [G]): BOOLEAN is do Result : = Current < other or equal (Current, other) end infix ">=" (other: COMPARABLE [G]) is … infix ">" (other: COMPARABLE [G]) is … … end 23

Multiple inheritance: Nested windows ‘‘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] feature. . . end 24

Multiple inheritance: Composite figures Simple figures A composite figure 25

Multiple inheritance: Composite figures Simple figures A composite figure 26

Defining the notion of composite figure display hide rotate move … * FIGURE LIST [FIGURE] count put remove … COMPOSITE_ FIGURE 27

Defining the notion of composite figure through multiple inheritance * FIGURE OPEN_ FIGURE SEGMENT CLOSED_ FIGURE perimeter* POLYLINE perimeter+ POLYGON ELLIPSE … TRIANGLE LIST [FIGURE] COMPOSITE_ FIGURE diagonal perimeter++ … RECTANGLE CIRCLE SQUARE perimeter++ 28

A composite figure as a list item start forth after 29

Composite figures class COMPOSITE_FIGURE inherit FIGURE redefine display, move, rotate, . . . end LIST [FIGURE] feature display is -- Display each constituent figure in turn. do from start until loop end after item. display forth end. . . Similarly for move, rotate etc. . end 30

Name clashes under multiple inheritance foo A B foo C 31

Resolving name clashes foo A B foo rename foo as fog rename foo as zoo C 32

Development: the traditional model Separate tools: l Programming environment l Analysis & design tools, e. g. UML Consequences: l Hard to keep model, implementation, documentation consistent l Constantly reconciling views l Inflexible, hard to maintain systems l Hard to accommodate bouts of late wisdom l Wastes efforts l Damages quality 33

Event-driven programming Publishers Subscribers Routine 34

A solution: Observer Pattern * PUBLISHER * attach detach LIBCLASS * Deferred (abstract) + Effective (implemented) SUBSCRIBER APPCLASS update* update+ Inherits from Client (uses) 35

Disadvantages of observer pattern l Publishers know about subscribers l Subscriber may subscribe to at most one publisher l May subscribe at most one operation l Not reusable — must be coded anew for each application 36

Mechanisms in other languages l C and C++: “function pointers” l C#: delegates (more limited form of agents) 37

The Eiffel Event Library The basic class is EVENT_TYPE On the publisher side, e. g. GUI library: • (Once) declare event type: click: EVENT_TYPE [TUPLE [INTEGER, INTEGER]] • (Once) create event type object: create click • To trigger one occurrence of the event: click. publish ([x_coordinate, y_coordinate]) On the subscriber side, e. g. an application: click. subscribe (agent my_procedure) 38

Subscriber variants click. subscribe (agent my_procedure) my_button. click. subscribe (agent my_procedure) click. subscribe (agent ) your_procedure (a, ? , b) click. subscribe (agent other_object. other_procedure ) 39

Another example of using agents b ò my_function (x) dx a b ò your_function (x, u, v) dx a my_integrator. integral ( agent my_function , a, b) my_integrator. integral (agent your_function ( ? , u, v), a, b) 40

Development: the Eiffel model Seamless development: l l l l Single set of notation, tools, concepts, principles throughout Eiffel is as much for analysis & design as for implementation & maintenance Continuous, incremental development Keep model, implementation and documentation consistent Reversibility: can go back and forth Saves money: invest in single set of tools Boosts quality 41

Seamless development (1) Specification TRANSACTION, PLANE, CUSTOMER, ENGINE. . . Example classes 42

Seamless development (2) Specification Design TRANSACTION, PLANE, CUSTOMER, ENGINE. . . STATE, USER_COMMAND. . . Example classes 43

Seamless development (3) Specification Design Implementation TRANSACTION, PLANE, CUSTOMER, ENGINE. . . STATE, USER_COMMAND. . . HASH_TABLE, LINKED_LIST. . . Example classes 44

Seamless development (4) Specification Design TRANSACTION, PLANE, CUSTOMER, ENGINE. . . STATE, USER_COMMAND. . . Implementation HASH_TABLE, LINKED_LIST. . . V & V TEST_DRIVER, . . . Example classes 45

Seamless development (5) Specification Design TRANSACTION, PLANE, CUSTOMER, ENGINE. . . STATE, USER_COMMAND. . . Implementation HASH_TABLE, LINKED_LIST. . . V & V TEST_DRIVER, . . . Generalization AIRCRAFT, . . . Example classes 46

Eiffel for analysis deferred class VAT inherit TANK feature in_valve, out_valve: VALVE Precondition fill is -- Fill the vat. require deferred ensure in_valve. open out_valve. closed in_valve. closed out_valve. closed is_full -- Specified only. -- not implemented. Postcondition end empty, is_full, is_empty, gauge, maximum, . . . [Other features]. . . invariant Class invariant is_full = (gauge >= 0. 97 * maximum) and (gauge <= 1. 03 * maximum) end 47

Seamless development Specification Design Implementation V & V Generalization TRANSACTION, PLANE, CUSTOMER, ENGINE. . . STATE, USER_COMMAND. . . HASH_TABLE, LINKED_LIST. . . TEST_DRIVER, . . . AIRCRAFT, . . . Example classes 48

Reversibility 49

Inheritance structure (in Eiffel. Studio) 50

Design by Contract™ l l l Get things right in the first place Automatic documentation Self-debugging, self-testing code Get inheritance right Give managers the right control tools 51

Applications of contracts l Analysis, design, implementation: Get the software right from the start l Testing, debugging, quality assurance l Management, maintenance/evolution l Inheritance l Documentation 52

Design by Contract l A discipline of analysis, design, implementation, management 53

A view of software construction l Constructing systems as structured collections of cooperating software elements — suppliers and clients — cooperating on the basis of clear definitions of obligations and benefits. l These definitions are the contracts. 54

Design by Contract (cont’d) l Every software element is intended to satisfy a certain goal, for the benefit of other software elements (and ultimately of human users). l This goal is the element’s contract. l The contract of any software element should be • • Explicit. Part of the software element itself. 55

A human contract deliver Client Supplier OBLIGATIONS (Satisfy precondition: ) Bring package before 4 p. m. ; pay fee. (Satisfy postcondition: ) Deliver package by 10 a. m. next day. BENEFITS (From postcondition: ) Get package delivered by 10 a. m. next day. (From precondition: ) Not required to do anything if package delivered after 4 p. m. , or fee not paid. 56

Properties of contracts A contract: • Binds two parties (or more): supplier, client. • Is explicit (written). • Specifies mutual obligations and benefits. • Usually maps obligation for one of the parties into benefit for the other, and conversely. • Has no hidden clauses: obligations are those specified. • Often relies, implicitly or explicitly, on general rules applicable to all contracts (laws, regulations, standard practices). 57

A human contract deliver Client Supplier OBLIGATIONS (Satisfy precondition: ) Bring package before 4 p. m. ; pay fee. (Satisfy postcondition: ) Deliver package by 10 a. m. next day. BENEFITS (From postcondition: ) Get package delivered by 10 a. m. next day. (From precondition: ) Not required to do anything if package delivered after 4 p. m. , or fee not paid. 58

A class without contracts class ACCOUNT feature -- Access balance: INTEGER -- Balance Minimum_balance: INTEGER is 1000 -- Minimum balance feature {NONE} -- Implementation of deposit and withdrawal add (sum: INTEGER) is -- Add sum to the balance (secret procedure). do balance : = balance + sum end 59

Without contracts (cont’d) feature -- Deposit and withdrawal operations deposit (sum: INTEGER) is -- Deposit sum into the account. do add (sum) end withdraw (sum: INTEGER) is -- Withdraw sum from the account. do add (– sum) end may_withdraw (sum: INTEGER): BOOLEAN is -- Is it permitted to withdraw sum from the account? do Result : = (balance - sum >= Minimum_balance) end 60

Introducing contracts class ACCOUNT create make feature {NONE} -- Initialization make (initial_amount: INTEGER) is -- Set up account with initial_amount. require large_enough: initial_amount >= Minimum_balance do balance : = initial_amount ensure balance_set: balance = initial_amount end 61

Introducing contracts (cont’d) feature -- Access balance: INTEGER -- Balance Minimum_balance: INTEGER is 1000 -- Minimum balance feature {NONE} -- Implementation of deposit and withdrawal add (sum: INTEGER) is -- Add sum to the balance (secret procedure). do balance : = balance + sum ensure increased: balance = old balance + sum end 62

With contracts (cont’d) feature -- Deposit and withdrawal operations deposit (sum: INTEGER) is -- Deposit sum into the account. require not_too_small: sum >= 0 do add (sum) ensure increased: balance = old balance + sum end 63

With contracts (cont’d) withdraw (sum: INTEGER) is -- 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 64

The contract withdraw Client Supplier OBLIGATIONS (Satisfy precondition: ) Make sure sum is neither too small nor too big. (Satisfy postcondition: ) Update account for withdrawal of sum. BENEFITS (From postcondition: ) Get account updated with sum withdrawn. (From precondition: ) Simpler processing: may assume sum is within allowable bounds. 65

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 66

With contracts (end) may_withdraw (sum: INTEGER): BOOLEAN is -- Is it permitted to withdraw sum from the -- account? do Result : = (balance - sum >= Minimum_balance) end invariant not_under_minimum: balance >= Minimum_balance end 67

The class invariant l Consistency constraint applicable to all instances of a class. l Must be satisfied: • • After creation. After execution of any feature by any client. (Qualified calls only: a. f (. . . )) 68

Lists with cursors before after item 0 1 count+1 Valid cursor positions 69

From the invariant of class LIST Valid cursor positions 70

Applications of contracts l Analysis, design, implementation: Get the software right from the start l Testing, debugging, quality assurance l Management, maintenance/evolution l Inheritance l Documentation 71

Contracts and documentation l Rich documentation produced automatically from class text l Available in text, HTML, Postscript, RTF, Frame. Maker and many other formats l Numerous views, textual and graphical 72

Contracts as automatic documentation Demo LINKED_LIST Documentation, generated by Eiffel. Studio 73

Contracts for analysis deferred class VAT inherit TANK feature in_valve, out_valve: VALVE Precondition fill is -- Fill the vat. require deferred ensure in_valve. open out_valve. closed in_valve. closed out_valve. closed is_full -- Specified only. -- not implemented. Postcondition end empty, is_full, is_empty, gauge, maximum, . . . [Other features]. . . invariant Class invariant is_full = (gauge >= 0. 97 * maximum) and (gauge <= 1. 03 * maximum) end 74

Contracts for testing and debugging l l l Contracts express implicit assumptions behind code A bug is a discrepancy between intent and code Contracts state the intent! In Eiffel. Studio: select compilation option for run-time contract monitoring. Can be set a system, cluster, class level. May disable monitoring when releasing software A revolutionary form of quality assurance 75

Contract monitoring A contract violation always signals a bug: l Precondition violation: bug in client l Postcondition violation: bug in routine 76

Contracts and inheritance: invariants l l 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. 77

Contracts and inheritance C A a 1: A … a 1. r (…) r is require ensure D Correct call: if a 1. then a 1. r (. . . ) -- Here a 1. holds. end B r is require ensure 78

Assertion redeclaration rule l When redeclaring a routine: • • Precondition may only be kept or weakened. Postcondition may only be kept or strengthened. 79

Assertion redeclaration rule in Eiffel l A simple language rule does the trick! l Redefined version may have nothing (assertions kept by default), or require else new_pre ensure then new_post l Resulting assertions are: • original_precondition or new_pre • original_postcondition and new_post 80

Principles in the Eiffel method l l l Design by Contract Abstraction Information hiding Seamlessness Reversibility Open-Closed principle Single choice principle Single model principle Uniform access principle Command-query separation principle Option-operand separation principle Style matters 81

Single-model principle All the information about a system should be in the system‘s text Automatic tools extract various views: • • • Interface Implementation Inheritance structure Client-supplier structure Operations (features) etc. 82

From Eiffel and Design by Contract. . . l . . . to Trusted Components 83

Today’s software is often good enough Overall: l Works most of the time l Doesn’t kill too many people l Negative effects, esp. financial, are diffuse Significant improvements since early years: l Better languages l Better tools l Better practices (configuration management) 84

From “good enough” to good? l l Beyond “good enough”, quality is economically bad He who perfects, dies Quality Release Optimal 1 Actual 2 3 4 Time 85

From “good enough” to good? l l Beyond “good enough”, quality is economically bad He who perfects, dies Quality Release Optimal 1 2 3 Actual 4 Time 86

The economic argument l Stable system: • Sum of individual optima = Global optimum l Non-component-based development: • Individual optimum = “Good Enough Software” • Improvements: I am responsible! l Component-based development: • Interest of both consumer and producer: Better components • Improvements: Producer does the job 87

Quality through reuse l The good news: Reuse scales up everything 88

Quality through reuse l The good news: Reuse scales up everything l The bad news: Reuse scales up everything 89

Software design in the future Component-based for • • • Guaranteed quality Faster time to market Ease of maintenance Standardization of software practices Preservation of know-how 90

Trusted components l Confluence of • • Quality engineering Reuse 91

Hennessy (Stanford) l “Most of the improvement in the reliability of computer systems has come from improvement in the basic components” l “You’ll see ever increasing portions of the effort devoted to design and verification” 92

Component quality: the inevitable issue The key issue • Bad-quality components are major risk Deficiencies scale up, too • High-quality components could transform the state of the software industry (if it wanted to — currently doesn’t) 93

Where to focus effort? 94

Perfectionism l Component design should be Formula-1 racing of software “engineering”. l In component development, perfectionism is good. 95

Our experience: Eiffelbase l Collection classes (“Knuthware”) l Consistency principle l Strict design principles: command-query separation, operand-option separation, taxonomy, uniform access. . . l Strict interface and style rules 96

Eiffelbase hierarchy 97

Trusted Components: how to get there l Low road: • • l Component Certification Center Component Quality Model High road: • Proofs of correctness 98

A Component Certification Center l Principles l Methods and processes l Standards: Component Quality Model l Services for component providers and component consumers 99

Component Quality Model A: Acceptance B: Behavior C: Constraints D: Design E: Extension 100

Component Quality Model A: Acceptance B: Behavior A. 1 Some reuse attested A. 2 Producer reputation A. 3 Published evaluations C: Constraints D: Design E: Extension 101

Component Quality Model A: Acceptance B: Behavior C: Constraints D: Design B. 1 Examples B. 2 Usage documentation B. 3 Preconditioned B. 4 Some postconditions B. 5 Full postconditions B. 6 Observable invariants E: Extension 102

Component Quality Model A: Acceptance B: Behavior C: Constraints D: Design C. 1 Platform spec C. 2 Ease of use C. 3 Response time C. 4 Memory occupation C. 5 Bandwidth C. 6 Availability C. 7 Security E: Extension 103

Contract levels 1. Type 2. Functional specification 3. Performance specification 4. Quality of Service (Source: Jézéquel, Mingins et al. ) 104

Component Quality Model A: Acceptance B: Behavior C: Constraints D: Design E: Extension E. 1 Portable across platforms E. 2 Mechanisms for addition E. 3 Mechanisms for redefinition E. 4 User action pluggability 105

Component Quality Model A: Acceptance B: Behavior C: Constraints D: Design E: Extension D. 1 Precise dependency doc D. 2 Consistent API rules D. 3 Strict design rules D. 4 Extensive test cases D. 5 Some proved properties D. 6 Proofs of preconditions, postconditions & invariants 106

Proof technology and formal methods l Constant advances in recent years l Most applications: life-critical systems in transportation, defense etc. Example: security system of Paris Metro METEOR line, using the B method 107

Formal methods and reuse l Components should be good l Proofs should be economical! 108

“Proving classes” Eiffel. Base libraries (fundamental data structures and algorithms): l Classes are equipped with contracts l “Proving a class” means proving that the implementation satisfies the contracts 109

Scope of our work at ETH: basics l l Help move software technology to the next level through • • • Trusted Components Advanced O-O techniques Teaching (including introductory) Approaches of special interest • • • Eiffel. NET B 110

Scope of our work at ETH: other l Journal of Object Technology JOT www. jot. fm l Numerous workshops and conferences l LASER (Laboratory for Applied Software Engineering Research); summer school starting September 2004 111

Proofs of Class Correctness l Use model for contracted Eiffel classes l Use B to prove properties of model and implementation 112

Contracts and Tests l Contracts in non-Eiffel libraries • The Closet Contract Conjecture • We performed a systematic analysis of the. NET Collection library and found many implicit contracts • Contract elicitation can be partially automated l Contracts and Testing • Contracts provide the best known basis for automatic test generation • Extensive tool under development • Supported by database for regression testing • Push-button testing: never write test suites, never worry about test oracles, just use contracts! Testing is completely automatic 113

From patterns to components l Pattern elimination conjecture: patterns are good, components are better l Karine Arnout performed systematic analysis of Go. F patterns to see which ones can be turned into components l Language mechanisms play critical role, e. g. genericity, multiple inheritance l Expected outcome: pattern library; book. 114

O-O development: Concurrency l SCOOP model • Very simple and high level language extension (one keyword: separate) supporting many different forms of concurrency and distribution • Processor: An autonomous thread of control capable of supporting the sequential execution of instructions on one or more objects (processors can be mapped e. g. to threads, processes, coroutines, …) l Research directions • Access control in concurrent object-oriented programming • Applying concurrent object-oriented programming to real-time applications • Implementation of SCOOP for. NET and multithreading 115

O-O development: Persistence General framework for persistent programming l l Seamless approach: No explicit programming of • • store/retrieve operations or database interactions Schema evolution: • • Class differs from stored objects Object retrieval mismatch Retrieve objects from the storage when their class descriptions have changed 116

O-O development: Eiffel l l ECMA standard in progress About 6 meetings so far Hope to have a standard by 2004 Conservative and innovative 117

Teaching introductory programming today l l Long, prestigious tradition of teaching programming at ETH Ups and downs of high-tech economy Widely diverse student motivations, skills Some have considerable operational knowledge • New forms of development: “Google-and-Paste” programming l Short-term pressures (e. g. families), IT industry fads l The “Bologna process” 118

The objectives Educate students so that they will: l l l Understand today’s software engineering. Become competent professionals. Find work and have a successful career. 119

“Outside-in” The key skill that we should convey: abstraction Teach, don’t preach. l l Start from libraries “Progressive opening of the black boxes”, “Inverted Curriculum” From programmer to producer Not bottom-up or top-down; outside-in. Students are able, right from the start, to “program” impressive and significant applications. 120

My first program class TOUR inherit TRANSPORT feature explore is -- Prepare -- and animate -- route do Paris. display Louvre. spotlight Line 8. highlight Route 1. animate end Text to input 121

Summary ● Bring every one of your developers to the level of your best developers ● Bring every one of your development days to the level of your best days ● Open, portable, reusable, flexible, efficient 122

For info “Object-Oriented Software Construction”, 2 nd edition Prentice Hall http: //www. eiffel. com http: //se. inf. ethz. ch http: //www. inf. ethz. ch/~meyer 123