A Pragmatic Application of PbC Karlstads University Computer Science A pragmatic Application of...

A Pragmatic Application of PbCKarlstads UniversityComputer Science

A pragmatic Application of Programming by Contract

Martin Blom / Eivind Nordby

Karlstad University

Karlstads UniversityComputer Science

A Pragmatic Application of PbC2

Disposition

• Background

– Positioning Semla in the context of system development

• Programming by Contract (PbC)

1. How to define a module with contracts (the interface)

2. How to use a module defined with contracts (the clients)

3. How to implement a module defined with contracts (the supplier)

• Perspectives on PbC

– There are contracts and contracts: Weak and strong

– There are errors and errors: External and internal

– Benefits and drawbacks

– Different views on semantic specification

– The paradox of guaranteeing more by checking less



Before We Start

• System development is a team work

• Which is better?

– Microscopic view:

• “I should always protect my module against crashes”

– Macroscopic view

• “I should always protect the system against defects”

• The overall goal is to make the system work well

• That can be done by

– Avoiding errors in the first place

– Detecting and removing errors that sneak in

• Surviving an error is not a goal

– Errors should be detected and removed



The Big Picture of System Development with RUP

Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test

Iterations Iter #1 #2 Iter #3 #4 #5 #6 Iter #7 #8



The Largest Software Problems

A survey from the European Software Process Improvement Training Initiative (ESPITI):

The relative importance of various types of software problems in industry: 3800 responses

0

5

10

15

20

25

30

35

40

45

50

Major problem

Minor problem

No problem

Requirements Specifications

Managing customer requirements

Documentation

Software design and testing

Project managementCoding



Traceability of Errors

• Where do delivered “bugs” come from?

12Coding

14Bad fixes

14Documentation

26Design

34Requirements

Delivered defects (%)Defect origins



Different project perspectives

• The Process Perspective – the Management– Tasks – when, how, by whom - management– Risk management

• The Product Perspective – the Craftmanship– Methodologies, languages, tools

• The Quality Perspective – the Acceptance– Requirements – functional, non-functional

• All aspects are important– We focus on design methods and on formulation requirements– You will normaly work with the five perspectives indicated on the next page



Abstraction and documentation

Analysis (what it looks like)(what, the needs, the concepts

Design (what it is)(how, the solution, the technology)

User level

Requirements, user manuals

System level

System overview

System structure, collaborations

Software mechanisms and risks

System design, DB, comm, sync

Module level

Concepts, abstractions

Module metafors

Module semantics

Interfaces and operations

Code level

Language, coding rules



An Ordinary Project

Enough focus: ExternalRequirements, project mgnt

Enough focus: CodeProgramming, coding rules

Not enough focus: SystemModule and funktion specs

Ab

stra

ctio

n l

evel

High(User level)

Medium(Semantic)

Low (Technical, syntactical)



Programming by Contract (PbC)

• The constituants of PbC

– preconditions

– postconditions

– class invariants

– (loop invariants) precondition

work

postcondition



Contracts – Preconditions and Postconditions

• In module design, the obligations and benefits of the contracts are regulated through preconditions and postconditions

MethodPrecondition

Postcondition

SupplierClient

Obligation:• Assure

precondition

Benefit:• Assume

postcondition

Benefit:• Assume

precondition

Obligation:• Assure

postcondition



Exampel: Contract for listRemove

/** * listRemove: Removes the element at position * 'position' (counted from 0) from the list * * Pre: (position>=0) && (position<listSize(list)) * Post: The element which was at position * 'position' is not in the list any more. * The list size is one less than before. * The updated list has been returned. */ListPtr listRemove(ListPtr list, int position);



Contract programming

• A client require a service from a supplier

– The client calls a function (cfr buys a car)

– The supplier supplies the service (delivers the car)

• Where is the precondition tested?

– By the client (strong contracts – for instance pays first)

– By the supplier (weak contracts – did he pay first?)

– By both (unordered, redundant)

• Where is the postcondition tested?

– By the supplier (for error detection – was the car delivered?)

– In most cases not at all



Testing First Makes the Code Testable

• Lessons Learned by Kent Beck (the XP guru)

– Massimo Arnoldi and I were working on booking payments for a life insurance policy. The requirements and the code were difficult to grasp because of all the special cases – what if they pay too much, what if they pay late, what if they pay for two months at once, etc.

– Every time we got one test working, we discovered the need for three others.

– … we decided to solve a simpler problem. Could we just test and code the part that decided whether booking a payment was possible at all? Sure – if the amount matched, we could book. Otherwise we had to ask for human intervention.

– Next, could we correctly book a payment? Given that the first test passed correctly, we could assume that the source account had the correct balance. Testing and coding was trivial.

http://www.extremeprogramming.org/stories/testfirst.html



The Interface – Strong vs Weak Contracts: Stack.top()

• Strong contracts

– Require more from the client

– Guarantee more

– Are used in internal code

• Strong contract for top

pre: not empty

post: result == top element

• Weak contracts

– Require less from the client

– Guarantee less

– Are used with external code

• Weak contract for top

pre: true

post: if not empty@pre

then result == top element

else EmptyException thrown



The Client – A possible use of top

• With a strong contract

– Assure that the precondition is satisfied

if (!stack.isEmpty()) theTop = stack.top();else doSomethingElse();



The Supplier – Possible implementations of top

• With a strong contract

– Assume that the precondition is satisfied

return topElement;

– Assure that the precondition is satisfied

• Do not promise anything if it is not

if (isEmpty()) crash();else return topElement;



The Client – A possible use of top

• With a weak contract

– Don’t bother whether or not the operation may be carried through

– Be prepared for a failure

try theTop = stack.top();catch (EmptyException e) doSomethingElse();



The Supplier – Possible implementations of top

• With a weak contract

– Verify that the operation may be carried through

• Compensate if it may not

if (isEmpty) throw new EmptyException();else return topElement;



not OK

Weak vs. Strong Contracts

Weak contract

Any input accepted

successfailure

OK

Double responsibility

not qualified qualified

Qualified input

required

Client responsibility

Strong contract



Design Contracts: Basic Principles

SupplierClient

Preconditionmet

SupplierClient

Preconditionnot met

Correct

Postconditionmet

! QIQO

Postconditionnot met

?

Correct

GIGOresult undefined



External and internal errors

• External errors

– Are committed by end users

• or other external parties

– Violate external interfaces

• At individual occasions

• Internal errors

– Are committed by developers

– Result in faults in the software

– Violate internal interfaces

• Are systematic

ProgrammersProgrammers

Error Program Fault

Violation

DesignersDesigners

ErrorDesign Fault

Violation

The system



Variations of error handling

• What happens when a (pre)condition is violated?

– The execution is aborted (strong contract)

• the fault is from an internal error and should be removed

– Exceptions or similar signalling (weak contracts)

• the error was previewed and must be handled

– Don’t care, just carry on executing, possibly after a recovery

• common where contracts are not used at all

• allows faults to persist in the system

• is an option within the framework of strong contracts



Relationship error → contract

• External errors– A correct use cannot be assumed

• The software must handle ”illegal” situations– Is best managed with weak contracts

• The outcome of the ”illegal” situations are specified in the postcondition– The ”illegal” situations become well defined and legal

• Their treatment is defined as part of the contract

• Internal errors– A correct use can be required– Illegal situations should be detected

• and the fault removed by the responsible developer– Is best managed with strong contracts– ”Illegal” situations remain undefined and illegal

• Their treatment is not defined by the contract



Benefits from using contracts

• Many people value error detection

– Many programmers who know about contracts see them as a means for testing and fault detection through conditional compilation of statements like

if not ”Some condition that I feel should be valid here" then

”Scream loudly"

end

– ”Scream loudly” may for instance be to throw an exception or to abort the program execution

– This exploits only a small portion of the potential of contracts

Karine Arnout, Bertrand Meyer: Uncovering Hidden Contracts: The .NET example,http://www.inf.ethz.ch/~meyer/publications/computer/contract_extraction_published.pdf



Five benefits of contracts

1 Clear design – correctness from start– Requiring explicit statements improves understanding

2 Distinct documentation – directly from the source code– Structured, focused requirements on the client

3 Potential error detection – self controlling code– The code may signal contract violations

• Should not be mistaken for traditional error handling• Requires executable (testable) assertions

4 Control over inheritance and change– Contracts indentify whether a situation is at risk or not

5 Management support– Managers and decision makers get an overall understanding



And the drawbacks?

1 Are based on abstractions– Mentally demanding– Unusual to many

2 Require a common understanding– All concerned parties must be trained– Works best with a nearby mentor

• or an initiated project member

3 Certain rules must be respected– Limits the individual freedom

4 Are introduced gradually– Different project groups follow different rules



Views on semantic descriptions

• Some people require exequtable (testable) assertions

• Some people require formal assertions

• We promote structure Formal description

Executable (testable) description

Structured description

Intuitive description

No description



Paradox: Guaranteeing More by Checking Less

• How can quality increase by less testing?

– Simplicity is the allied number one for quality

• Placing conditions on the client allows for a simple implementation

– Hence allows for quality

• Not trusting the client requires testing the conditions

– Both client and supplier need to test

– Hence complicating the implementation

– Hence jeopardizing the quality

• The key issue is who’s “quality” we are looking for

– Microscopic view, just my own module:

• Lots of tests in the supplier code

– Macroscopic view, the system as a whole:

• Place the responsibility where it belongs



Structure of the method (Semla)

• The method is based on contracts (Hoare, Meyer) and is pragmatic and easy to use

• The method includes rules for design, documentation and maintenance

• Each rule has the following structure

– description and motivation

– rule

– procedure

– example

A Pragmatic Application of PbCKarlstads UniversityComputer Science

Appendix

Case study examples

From a project programmed in C



Example 1: Existing specification

• Insert a node (1) Syntax

void Insert(struct List* list, struct Node* node, struct Node* pred);

Description The Insert() function is used for inserting a new node into any position in a

list. It always inserts the node after the specified node that already is a part of the list. This function also handles the special cases when adding to the head of list and to the tail of list. There are other functions which handle the special cases more efficiently.

Parameters list

The list header. node

The node to insert. pred

The list element after which “node” should be inserted. Return values

None.



Example 1: Marked existing spec



Description The Insert() function is used for inserting a new node into any position in a

list. It always inserts the node after the specified node that already is a part of the list. This function also handles the special cases when adding to the head of list and to the tail of list. There are other functions which handle the special cases more efficiently.

Parameters list

The list header. node

The node to insert. pred

The list element after which “node” should be inserted. Return values

None.



Exempel 1: Comments to (1)

• Function description, conditions and results all embedded in the same text.– inserts the node after the specified node (postcondition)

– … that already is a part of the list (precondition)

• Gives an unclear picture of its use– How is a node inserted in the front?

– “There are other functions which handle the special cases more efficiently.”

• Why not tell which ones?



Example 1: Alternativ suggestion



Description Inserts a new node at a specific position in a list. AddHead and AddTail are

the preferred methods for inserting a node at the beginning or at the end of the list.

Parameters list The list header. node The node to insert pred The list element after which ‘node’ should be inserted.

Precondition Newlist has been called for ‘list’ ‘node’ is not contained in of any list ‘pred’ is contained in ‘list’ or NULL

Postcondition ‘node’ is contained in the list after ‘pred’, or at the beginning if ‘pred’==NULL



Example 1: Comments to (2)

• The description is shortened down to functionality only

• Pre- and postconditions replace conditions embedded in the description

• A distinction is made between parameters and assumptions

• Precondition– The general one that the list has been initialized has been made explicit– The special case of ”pred == NULL” has explicitly been allowed

• Postcondition– The result, including the special case, has been made explicit

• The title Return values has been removed

– Replaced by the more general Postcondition



Example 2: Existing spec

• Remove a node Syntax

void Remove(struct Node* node); Description

The Remove() function will remove a specified node from a list. Be sure to specify a node in a list otherwise unpredictable events could occur.

Parameters node

The list element to remove Return values

None.



Example 2: Comments

• The precondition must be satisfied– If not, the result is unspecified

“Be sure to specify a node in a list otherwise unpredictable events could occur.”

– This is mentioned sporadically for this one function only

• Alternative specification Syntax

void Remove(struct Node* node); Description

Removes a node from the list it is contained in. Parameters

node The node to remove Precondition

node is contained in a list Postcondition

node is not contained in any list



Example 3: Existing spec

• Initialize list (1)

Syntax void NewList(struct List* list);

Description Before the list can be used it has to be initialized. This function resets the list

to an empty state. Note that Type remains uninitialized. See "List initialization" on page 146.

Parameters list

The list header.

Return values None



Example 3: Comments (1)

• In addition to a function description, also has an overall description of the context for the call– ”Before the list is used …” belongs to the chapter ”Guidelines for use” or

similay, for instance before Include Files.

• Gives a unclair picture of the usage– “… resets the list to an empty state” sounds as if the function may be used to

empty the list, which is wrong

• Contains irrelevand information– Note that Type remains uninitialized.

• Indicates a mixture of list properties and element content

– See "List initialization" on page 146.• Refers to implementation detalils. Does not belong to the interface

description



Example 3: Comments (2)

• Focus is on the description

• Embedded conditions are replaced by preconditions

• Irrelevant information reduced or removed– Type

• A variable indicating the contents of the data in the list• The module should need to be restructured with cleaner semantic

distinctions. List functions are intemixed with user functions.– "List initialization" on page 146

• Unclear target group: implementers or users?• Implementation details intermixed with interface descriptions. Disclosed

implementation details may encourage client programmers to ”White box” use.

• Little encapsulation, modularity is not encouraged

A Pragmatic Application of PbC Karlstads University Computer Science A pragmatic Application of...

Documents

Transcript of A Pragmatic Application of PbC Karlstads University Computer Science A pragmatic Application of...