a pragmatic application of pbc karlstads university computer science a pragmatic application of...
Post on 30-Dec-2015
218 Views
Preview:
TRANSCRIPT
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC3
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC4
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC5
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC6
Traceability of Errors
• Where do delivered “bugs” come from?
12Coding
14Bad fixes
14Documentation
26Design
34Requirements
Delivered defects (%)Defect origins
Karlstads UniversityComputer Science
A Pragmatic Application of PbC7
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC8
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC9
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)
Karlstads UniversityComputer Science
A Pragmatic Application of PbC10
Programming by Contract (PbC)
• The constituants of PbC
– preconditions
– postconditions
– class invariants
– (loop invariants) precondition
work
postcondition
Karlstads UniversityComputer Science
A Pragmatic Application of PbC11
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC12
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);
Karlstads UniversityComputer Science
A Pragmatic Application of PbC13
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC14
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC15
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC16
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();
Karlstads UniversityComputer Science
A Pragmatic Application of PbC17
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;
Karlstads UniversityComputer Science
A Pragmatic Application of PbC18
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();
Karlstads UniversityComputer Science
A Pragmatic Application of PbC19
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;
Karlstads UniversityComputer Science
A Pragmatic Application of PbC20
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC21
Design Contracts: Basic Principles
SupplierClient
Preconditionmet
SupplierClient
Preconditionnot met
Correct
Postconditionmet
! QIQO
Postconditionnot met
?
Correct
GIGOresult undefined
Karlstads UniversityComputer Science
A Pragmatic Application of PbC22
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC23
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC24
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC25
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC26
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC27
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC28
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC29
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC30
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC32
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.
Karlstads UniversityComputer Science
A Pragmatic Application of PbC33
Example 1: Marked existing spec
• 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.
Karlstads UniversityComputer Science
A Pragmatic Application of PbC34
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?
Karlstads UniversityComputer Science
A Pragmatic Application of PbC35
Example 1: Alternativ suggestion
• Insert a node (2) Syntax
void Insert(struct List* list, struct Node* node, struct Node* pred);
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC36
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC37
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.
Karlstads UniversityComputer Science
A Pragmatic Application of PbC38
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC39
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC40
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
Karlstads UniversityComputer Science
A Pragmatic Application of PbC41
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
top related