copyright w. howden1 lecture 13: programming by contract
Post on 20-Dec-2015
218 views
TRANSCRIPT
![Page 1: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/1.jpg)
Copyright W. Howden 1
Lecture 13: Programming by Contract
![Page 2: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/2.jpg)
Copyright W. Howden 2
PreConditions and PostConditions
• PreCondition– what you assume to be true before an operation
or process
• PostCondition– what you assert to be true after an operation or
process
• Contract: If Preconditions hold before, then Postconditions will hold afterwards
![Page 3: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/3.jpg)
Copyright W. Howden 3
PreConditions and Data Validation
• Precondition client’s responsibility• Input validation is not required• Documented so it does not slip through the cracks• Clarifies when and where data needs to be
checked• Redundant checks lead to
– decreased performance– less clarity– increased opportunity for errors
![Page 4: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/4.jpg)
Copyright W. Howden 4
Kinds of Postconditions
• Low level– Conditions and relationships on variable values– Return value properties
• Higher level– Objects created or deleted– Associations formed or deleted
![Page 5: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/5.jpg)
Copyright W. Howden 5
Applications
• Low level– Algorithms– Classes
• class and method properties
• Higher level– Use case assumptions and results – System and subsystem operations identified
during requirements analysis and elaboration
![Page 6: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/6.jpg)
Copyright W. Howden 6
Algorithms and Pre/PostConditions
• Formal specifications
• Proofs of correctness of algorithms– verification, formal verification
![Page 7: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/7.jpg)
Copyright W. Howden 7
Assertions
• Assertion: Condition that should be true at an associated location in the algorithm
• PreCondition= input assertion• PostCondition = output assertion• Intermediate assertion – intermediate state
of system/program• Loop invariant = assertion about state at
some location in a loop
![Page 8: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/8.jpg)
Copyright W. Howden 8
Algorithms and Verification
• Suppose that A1 is the precondition for an algorithm A and An is the postcondition.
• Correctness: A is correct if it is partially correct and it always terminates
• Partial correctness of A– if A1 is true at the beginning of A and if A is
executed and terminates, then An will be true at the end of the execution
![Page 9: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/9.jpg)
Copyright W. Howden 9
Proof Technique
• Add intermediate assertions Ai to the algorithm. Make sure that each loop has at least one intermediate assertion
• For each pair of assertions (X,Y) where there is a subpath p from X to Y, which has no other assertions on it, prove that if
Control is at the location of X and X is true,
and if control flows along p to Y, then Y will be true
![Page 10: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/10.jpg)
Copyright W. Howden 10
Proof Method Validity
• Assume that we prove validity for each assertion pair (X,Y) joined by a subpath p
• For any execution of the algorithm, a path P will be followed from the precondition to the postcondition
• The path P can be broken up into subpaths p between assertion pairs (X,Y)
• Proofs for the subpaths p implies correctness for whole path P
![Page 11: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/11.jpg)
Copyright W. Howden 11
Sample Algorithm
• Multiplies two numbers x and y by adding up y x times
• Input (precondition) assertion Pre, output (postcondition) assertion Post, intermediate loop invariant assertion IA
![Page 12: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/12.jpg)
Copyright W. Howden 12
![Page 13: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/13.jpg)
Copyright W. Howden 13
Verification Conditionsfor Sample Algorithm
• Prove that – if Pre is true then IA will be true– if IA is true and Count = 0 then Post will be
true– If IA is true and Count 0 then IA will be true
![Page 14: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/14.jpg)
Copyright W. Howden 14
Termination Proof?
• Termination proof– Count initialized to x >=0– Loop terminates if Count == 0– For each iteration Count is decremented by 1 so
loop must terminate
• Note: if Precondition x>=0 is removed and input is negative, algorithm will not always terminate but is still partially correct
![Page 15: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/15.jpg)
Copyright W. Howden 15
Classes and Pre/Post Conditions
• Method Pre and Post conditions– algorithm input/output conditions– state changes for object
• Class invariants– true after constructor, and true before and after
each method application– could also document as pre and post conditions
for each method to ensure compliance
![Page 16: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/16.jpg)
Copyright W. Howden 16
Sample Class Invariants
• e.g. LogOn object created by DomainLogic when someone logs on to DS
• Has a class variable called name which is never null-valued after LogOn is constructed. i.e. it is initialized in the constructor
class invariant: {this.logOn null}
![Page 17: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/17.jpg)
Copyright W. Howden 17
Sample Class
• Stack Class (parameterized)• Written in a language with
• class invariant statement
• precondition and postcondition statements for methods
![Page 18: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/18.jpg)
Copyright W. Howden 18
![Page 19: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/19.jpg)
Copyright W. Howden 19
Use Cases and Pre/Post Conditions
• Use case is a story that may contain a number of system operations
• Use case pre/postconditions– for whole story
![Page 20: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/20.jpg)
Copyright W. Howden 20
DS Example - Precondition
• Use Case: user changing his/her data in the DS data base
• Assume that the use case does not include the log on subtask, which will always be performed before this use case and which will have confirmed that the user was a member before this use case began
• PreCondition: User is a member of the Dating System and has a member record in the Data Base
![Page 21: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/21.jpg)
Copyright W. Howden 21
DS Example – Postcondition
• Use Case: user changing his/her data in the DS data base
• Suppose that m is the current user record for U in the data base, and c specifies changes to the data. Let m’ = change(m,c), the result of making changes c to m.
• Postcondition: User record for U == m’
![Page 22: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/22.jpg)
Copyright W. Howden 22
Systems/subsystems and Pre/Postconditions
• Operations determined during requirements analysis and elaboration
• Systems and subsystem events correspond to actor actions or messages received
• Events are responded to by system/subsystem operators
• Pre and post conditions describe required operator functionality
![Page 23: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/23.jpg)
Copyright W. Howden 23
Operator Pre and Postconditions
• High level, more informal than algorithm and method conditions
• More object oriented e.g.– Objects created and deleted– Associations between instances of classes
created and deleted– Attributes of objects altered
![Page 24: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/24.jpg)
Copyright W. Howden 24
DS Examples – 1
Subsystem: GUI
Operation: Create(DomainLogic Dl)
Preconditions: Domain Logic object is created
Postconditions: GUI object is created
![Page 25: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/25.jpg)
Copyright W. Howden 25
DS Examples - 2
• Subsystem: GUI
• Operation: name entered during Logon
• Precondition: Logon is visible
• Postconditions:– LogOn is not visible– Appropriate user options dialog (member,
admin, unauthorized) created and visible
![Page 26: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/26.jpg)
Copyright W. Howden 26
DS Examples – 3
• Subsystem: GUI
• Operation: EnterMemberData option is chosen from member options dialog
• Preconditions: member options dialog is visible
• Postconditions: EnterMemberData Dialog is visible
![Page 27: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/27.jpg)
Copyright W. Howden 27
DS Examples – 4
• Subsystem: DL• Operation: logOn• Preconditions: DataBase is associated with
DL• Postconditions:
– LogOn object created and associated with DL– LogOn userName and userType attributes are
set
![Page 28: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/28.jpg)
Copyright W. Howden 28
DS Examples – 5
• SubSystem: DL• Operation: addMember(String name)• Preconditions: DataBase is associated with
DL• Postcondition: (none for DL, i.e. no changes
for DL)/* Recall: postcondition will only refer to object/subsystem under consideration */
![Page 29: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/29.jpg)
Copyright W. Howden 29
DS Examples – 6
• Subsystem: DL• Operation: deleteMember(String name)• PreCondition: DataBase is associated with DL• PostCondition:
/* in the design and implementation a value is returned by the method for this operation which would be in a more detailed postcondition */
![Page 30: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/30.jpg)
Copyright W. Howden 30
DS Examples – 7
• Subsystem: DataBase
• Operation: Create (File file)
• Precondition: file exists and contains member records in expected format
• PostCondition: the MemberData[] object associated with DataBase will be filled with the member records from the file
![Page 31: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/31.jpg)
Copyright W. Howden 31
DS Examples – 8
• Subsystem: DataBase
• Operation: getMemberData(String name)
• Precondition:
• Postcondition
/* no changes to DataBase object. Obviously there is a return value from the operation */
![Page 32: Copyright W. Howden1 Lecture 13: Programming by Contract](https://reader036.vdocuments.net/reader036/viewer/2022062714/56649d415503460f94a1bd96/html5/thumbnails/32.jpg)
Copyright W. Howden 32
DS Examples – 9
• Subsystem: Data Base• Operation: addMember(String name)• Precondition: DataBase has a
MemberData[] collection object associated with it
• Postcondition: the MemberData[] object is altered to include a new MemberData instance with this name