1
play

1 Properties of contracts Contracts for analysis 7 8 deferred - PDF document

Jul 25, 2023 •356 likes •434 views

1 2 Last update: 21 April 2004 Programming in the large Lecture 6: Design by Contract Bertrand Meyer by Karine Arnout Chair of Softw are Engineering Programming in the large Lecture 6 Chair of Softw are Engineering Programming in

  1. 1 2 Last update: 21 April 2004 Programming in the large Lecture 6: Design by Contract™ Bertrand Meyer by Karine Arnout Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 Design by Contract Design by Contract 3 4 � A discipline of analysis, design, implementation, � Every software element is intended to satisfy a management certain goal, for the benefit of other software elements (and ultimately of hum an users). � This goal is the element’s contract. � The contract of any software element should be � Explicit. � Part of the software element itself. Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 A human contract A view of software construction 5 6 � Constructing system s as structured collections of cooperating software elements — suppliers and OBLIGATIONS BENEFITS deliver clients — cooperating on the basis of clear (Satisfy precondition:) (From postcondition:) definitions of obligations and benefits. Client Bring package before Get package delivered 4 p.m.; pay fee. by 10 a.m. next day. � These definitions are the contracts. (Satisfy postcondition:) (From precondition:) Supplier Deliver package by Not required to do 10 a.m. next day. anything if package delivered after 4 p.m., or fee not paid. Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 1

  2. Properties of contracts Contracts for analysis 7 8 deferred class � A contract: PLANE � Binds two parties (or m ore): supplier, client. feature Precondition � Is explicit (written). start_take_off is -- Initiate take - o ff procedures. � Specifies mutual obligations and benefits. require controls.passed -- i.e. specified only. assigned_runway.is_clear � Usually maps obligation for one of the parties deferred -- not implemented. ensure into benefit for the other, and conversely. assigned_runway . owner = Current moving � Has no hidden clauses: obligations are those end Postcondition specified. start_landing , increase_altitude , decrease_altitude , moving , altitude , speed , time_since_take_off � Often relies, im plicitly or explicitly, on general ... [ Other features] ... Class invariant rules applicable to all contracts (laws, invariant regulations, standard practices). ( time_since_take_off < = 20) im plies ( assigned_runway . owner = Current ) moving = ( speed > 10) end Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 Contracts for analysis Contracts for analysis 9 10 deferred class TANK OBLIGATIONS BENEFITS fill feature in_valve , out_valve : VALVE Precondition (Satisfy precondition:) (From postcondition:) fill is Client -- Fill the tank. Make sure input valve Get filled-up tank, with require is open, output valve is both valves closed. in_valve.open -- i.e. specified only. out_valve.is_closed closed. deferred -- not implemented. ensure (Satisfy postcondition:) (From precondition:) in_valve.is_closed Supplier out_valve.is_closed Fill the tank and close Simpler processing is_full both valves. thanks to assumption Postcondition end that valves are in the empty , is_full , is_empty , gauge , maximum , ... [ Other features] ... proper initial position. Class invariant invariant is_full = ( gauge > = 0.97 * maximum ) and ( gauge < = maximum ) end Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 So, is it like “assert.h”? Some benefits: technical 11 12 � Development process becomes more focused. (Source: Reto Kramer) Writing to spec. � Design by Contract goes further: � Sound basis for writing reusable software. � “Assert” does not provide a contract. � Exception handling guided by precise definition of � Clients cannot see asserts as part of the “normal” and “abnormal” cases. interface. � Interface docum entation always up-to-date, can � Asserts do not have associated semantic be trusted. specifications. � Documentation generated automatically. � Not explicit whether an assert represents a � Faults occur close to their cause. Found faster and precondition, post-conditions or invariant. more easily. � Asserts do not support inheritance. � Guide for black-box test case generation. � Asserts do not yield automatic documentation. Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 2

  3. Some benefits: managerial Correctness in software 13 14 � Library users can trust documentation. � Correctness is a relative notion: consistency of � They can benefit from preconditions to validate implementation vis-à-vis specification. (This their own software. assumes there is a specification!) � Test manager can benefit from more accurate � Basic notation: ( P , Q : assertions, i.e. properties of estimate of test effort. � Black-box specification for free. the state of the computation. A : instructions). � Designers who leave bequeath not only code but { P } A { Q } intent. � Common vocabulary between all actors of the � “Hoare triple” process: developers, managers, potentially customers. � What this means (total correctness): � Component-based development possible on a solid � Any execution of A started in a state satisfying P basis. will term inate in a state satisfying Q . Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 Hoare triples: a simple example Specifying a square root routine 15 16 { n > 5} n : = n + 9 { n > 13} { x > = 0} � Most interesting properties: ... Square root algorithm to compute y ... � Strongest postcondition (from given { abs ( y ^ 2 – x ) < = 2 * epsilon * y } precondition). -- i.e.: y approximates exact square root of x � Weakest precondition (from given -- within epsilon postcondition). � “ P is stronger than or equal to Q ” m eans: P implies Q � QUIZ: What is the strongest possible assertion? The weakest? Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 Software correctness A contract (from EiffelBase) 17 18 � Consider extend ( new : G ; key : H ) -- Assum ing there is no item of key key , { P } A { Q } -- insert new with key ; set inserted . � Take this as a job ad in the classifieds. require key_not_present: not has ( key ) � Should a lazy employment candidate hope for a ensure weak or strong P ? What about Q ? insertion_done: item ( key ) = new � Two special offers: key_present: has ( key ) � 1. { False } A { ...} inserted: inserted � 2. { ...} A { True } one_more: count = old count + 1 Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 3

  4. The contract A class without contracts 19 20 class ACCOUNT OBLIGATIONS BENEFITS feature -- Access Routine balance : INTEGER Client PRECONDITION POSTCONDITION -- Balance Minimum_balance : INTEGER is 1000 Supplier POSTCONDITION PRECONDITION -- 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 Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 A class without contracts Introducing contracts 21 22 feature -- Deposit and withdrawal operations class ACCOUNT create deposit ( sum : INTEGER ) is -- Deposit sum into the account. do make add ( sum ) end feature { NONE } -- Initialization withdraw ( sum : I NTEGER ) is make ( initial_amount : INTEGER ) is -- Withdraw sum from the account. do -- Set up account with initial_amount . add (– sum ) require end large_enough: initial_amount > = Minimum_balance do may_withdraw ( sum : INTEGER ): BOOLEAN is balance : = initial_amount -- Is it permitted to withdraw sum from the account? do ensure Result : = ( balance - sum > = Minim um _balance ) balance_set: balance = initial_amount end end end Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 Introducing contracts Introducing contracts 23 24 feature -- Access feature -- Deposit and withdrawal operations balance : INTEGER -- Balance deposit ( sum : I NTEGER ) is -- Deposit sum into the account. Minimum_balance : INTEGER is 1000 -- Minimum balance require feature { NONE } -- Implementation of deposit and withdrawal not_too_small: sum > = 0 do add ( sum : INTEGER ) is -- Add sum to the balance (secret procedure). add ( sum ) do ensure balance : = balance + sum increased: balance = old balance + sum ensure increased: balance = old balance + sum end end Chair of Softw are Engineering Programming in the large – Lecture 6 Chair of Softw are Engineering Programming in the large – Lecture 6 4

Recommend

More recommend