1. Component-Based Software Engineering Components and Interfaces Paul Krause

2. Lecture 6 - Interfaces Contents  Interfaces as Contracts  Future Proofing  Non-functional requirements  Are we done?

3. Components and Interfaces A B1B2 A requires certain functionality to fulfil its obligations. B1 and/or B2 provide that functionality. An interface mediates between clients and providers.

4. Interfaces as contracts  Can view an interface specification as a “contract” between the client and a provider  So the interface specification must state: What the client needs to do What the client needs to do What a provider can rely on What a provider can rely on What a provider must promise in return What a provider must promise in return What the client can rely on What the client can rely on

5. Pre- and Post-Conditions  Pre-conditions: What the client must establish before calling the operation What the client must establish before calling the operation The provider can rely on this condition being true whenever the operation is called The provider can rely on this condition being true whenever the operation is called  Post-conditions: What the provider must establish before returning to the client What the provider must establish before returning to the client The client can rely on this condition being true whenever the call to the operation returns The client can rely on this condition being true whenever the call to the operation returns

6. Example public interface Directory { public void addEntry(String name, File file); // pre name != “” and file != null // post File file = map.get(name) } Associate pre- and post-conditions to every method in the interface

7. Lecture 6 - Interfaces Contents  Interfaces as Contracts  Future Proofing  Non-functional requirements  Are we done?

8. Future proofing  An interface acts as a contract between client and provider  Suppose an interface remains unchanged  Is there any scope for revising an implementation without introducing a risk of “breaking” old clients?  Ans: The revised implementation may require less and/or provide more

9. Future Proofing public interface Arithmetic { public double processNumbers(double x, double y); // pre x > 5 and y > 5 // post if r = this.processNumbers(x, y) then r > 10 } public double processNumbers(double x, double y) { if ((x < 0) || (y < 0)) throw new IllegalArgumentException(“Args must be >=0”); return x + y + 20.0; }

10. Future Proofing x > 5 and y > 5 implies x >=0 and y >= 0  The new implementation requires less than the interface  The implementation “weakens” the pre- conditions return >= 20 implies return > 10  The new implementation provides more than the interface specifies  The implementation “strengthens” the post- conditions

11. Lecture 6 - Interfaces Contents  Interfaces as Contracts  Future Proofing  Non-functional requirements  Are we done?

12. What else can go wrong? public interface Directory { public void addEntry(String name, File file); // pre name != “” and file != null // post File file = map.get(name) }  strictly this is only a guarantee of partial correctness  the operation either terminates correctly or does not terminate at all!  progress conditions:  something guaranteeing the pre-condition will lead to something guaranteeing the post-condition

13. Non-functional requirements  We have seen how respecting pre- and post- conditions reduces the risk of a revised implementation “breaking” a client  But are changes in the functional behaviour the only way an implementation can break a client?  Consider a Maths interface, with methods to support an animation package What about a new implementation that improves accuracy? What about a new implementation that improves accuracy?

14. Specifying the Service Level Now add guarantees for levels of:  Availability;  Mean time between failures;  Mean time to repair;  Throughput;  Data safety;  Capacity.

15. Time and Space Requirements  Specifying execution time is platform dependent  So what can realistically be included in a contract?  Could use complexity bounds E.g. perform an operation on n elements in n log n time, using at most log n additional storage cells E.g. perform an operation on n elements in n log n time, using at most log n additional storage cells  A client can then determine the absolute time and space bounds for a given provider on a given platform

16. Lecture 6 - Interfaces Contents  Interfaces as Contracts  Future Proofing  Non-functional requirements  Are we done?

17. Are we done?  Interfaces act as contracts between clients and providers  Suggest you think about: Pre-conditions Pre-conditions Post-conditions Post-conditions Leads-to conditions Leads-to conditions Non-functional requirements Non-functional requirements  As that it?

18.  Pauls Pictures  Pauls Documents  Pauls Sums  Pauls Homework No!  Pauls Pictures  Pauls Documents  Pauls Sums  Pauls Homework  Pauls ToDo Lists