Lecture 12 Programming by Contract

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

Info icon This preview shows pages 1–10. Sign up to view the full content.

Copyright W. Howden 1 Lecture 13: Programming by Contract
Image of page 1

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

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
Image of page 2
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
Image of page 3

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

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
Image of page 4
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
Image of page 5

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

Copyright W. Howden 6 Algorithms and Pre/PostConditions Formal specifications Proofs of correctness of algorithms – verification, formal verification
Image of page 6
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
Image of page 7

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

Copyright W. Howden 8 Algorithms and Verification Suppose that A 1 is the precondition for an algorithm A and A n is the postcondition. • Correctness: A is correct if it is partially correct and it always terminates Partial correctness of A if A 1 is true at the beginning of A and if A is executed and terminates, then A n will be true at the end of the execution
Image of page 8
Copyright W. Howden
Image of page 9

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

Image of page 10
This is the end of the preview. Sign up to access the rest of the document.
  • Fall '07
  • Howden
  • Design by contract, formal methods, W. Howden, Copyright W. Howden

{[ snackBarMessage ]}

What students are saying

  • Left Quote Icon

    As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.

    Student Picture

    Kiran Temple University Fox School of Business ‘17, Course Hero Intern

  • Left Quote Icon

    I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.

    Student Picture

    Dana University of Pennsylvania ‘17, Course Hero Intern

  • Left Quote Icon

    The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.

    Student Picture

    Jill Tulane University ‘16, Course Hero Intern