1. CSC 480 Software Engineering Design by Contract

2. Detail Design Road Map Begin with architectural models  Class model: domain classes  Overall state model  Use case model Refine classes, make consistent, ensure complete Specify class invariants, if any Specify methods with  Pre- and post-conditions  Flowcharts and pseudocode Sketch unit test plans

3. Design by Contract Design by contract is about adding assertions to o-o programs  Used mostly at design and coding stages  Concepts are applicable to other stages as well Assertions are fact about a program that must be true for the program to be bug-free  Pre- and post-conditions  Invariants

4. Principles of Design by Contract Principle I - Separate queries from commands. Queries return a result but do not change the visible properties of the object. Commands might change the object but do not return a result. Principle 2 - Separate basic queries from derived queries. Derived queries can be specified in terms of basic queries. Principle 3 - For each derived query, write a post- condition that specifies what result will be returned, in terms of one or more basic queries. Then, if we know the values of the basic queries, we also know the values of the derived queries.

5. Principles (cont’d) Principle 4 - For each command, write a post-condition that specifies the value of every basic query. Now we know the total visible effect of each command. Principle 5 - For every query and command, decide on a suitable precondition. Preconditions constrain when c may call the queries and commands. Principle 6 - Write invariants to define unchanging properties of objects. Concentrate on properties that help the reader build an appropriate conceptual model of the abstraction the class embodies.

6. A Sample Class – Queue

7. Application Guidelines Guideline I - Add physical constraints where appropriate. Typically, these will be constraints that variables should not be void. Guideline 2 - Make sure that queries used in preconditions are cheap to calculate. If necessary, add cheap-to-calculate derived queries whose post- conditions verify them against more expensive queries. Guideline 3 - Constrain attributes using an invariant. When a derived query is implemented as an attribute, it can be constrained to be consistent with other queries by an assertion in the class’s invariant section.

8. Application Guidelines (cont’d) Guideline 4 - To support redefinition of features, guard each post-condition clause with its corresponding precondition. This allows unforeseen redefinitions by those developing subclasses. Guideline 5 - Place constraints on desired changes and frame rules In separate classes. This allows developers more freedom to extend your classes.