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

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

3. Revised Definition  A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only  A software component can be deployed independently and is subject to composition by third parties 1996 European Conference on Object-Oriented Programming

4. 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.

5. 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

6. Components in UML 2.0 > A B IName1 IName2 IName3 IName4 Component A provides IName1 & IName2 Component A requires IName3 Component B provides IName3 Component B requires IName4 Components A and B are composed on the basis of interfaces provided by one and required by the other (i.e. interface IName3) > A

7. 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

8. 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

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

10. 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

11. 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; }

12. 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

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

14. 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

15. 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?

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

17. 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

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

19. 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  Is that it?

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

21. Describing contracts  An informal approach: pre- and post- conditions  A semi-formal approach: UML, and its OCL  A formal approach: a set-theoretic framework for components

22. Contents  Is there a role for formality?  Formalisation of a software component Static characteristics (structure) Static characteristics (structure) Dynamic characteristics (behaviour) Dynamic characteristics (behaviour)

23. Introducing Formality  Formal methods is the use of mathematics to specify, model, develop and reason about computing systems  Delays coding  Sometimes difficult to grasp  But… unmanned Paris Metro trains don’t crash as regularly as Windows do! crash as regularly as Windows do!

24. Formalising components  Component-based development could benefit from a formal component model which would allow us to make safe assumptions on: the order in which methods of the component’s provided interfaces are called the order in which methods of the component’s provided interfaces are called the order in which the component calls methods on its required interfaces the order in which the component calls methods on its required interfaces

25. A typical software component IName1 IName2 IName3 > CName

26. Static characteristics (structure)  A component in UML, and elsewhere, is viewed as a black box which communicates via a set of provided and required interfaces  Each interface (assuming the oo paradigm) has a number of methods; these are invoked by the component that requires the interface and are implemented by the component that provides the interface

27. Static characteristics (structure) Formally,  Let I be the set of interfaces of a component and M be the set of methods. We define a component sort to be a tuple where is the set of provided interfaces is the set of provided interfaces is the set of required interfaces is the set of required interfaces hence, is the set of methods associated with interface hence, is the set of methods associated with interface

28. Example I = {ISearchFre, IFineTune, IDetectSignal}, M = {a 1, a 2, b 1, b 2, b 3, c 1 } P = {ISearchFre, IFineTune} R = {IDetectSignal} β(ISearchFre) = {a 1, a 2 } β(IFineTune) = {b 1, b 2, b 3 } β(IDetectSignal) = {c 1 } ISearchFre IFineTune IDetectSignal > CMenu {a 1, a 2 } {b 1, b 2, b 3 } {c 1 }

29. Dynamics (behaviour)  In a period of operation, each interface of the component will experience a sequence of method calls (either incoming or outgoing)  The idea is that behaviour of the component as a whole, can be described by assigning to each interface a sequence

30. Dynamics (behaviour) Suppose that is a component sort. We define V to be the set of all functions such that for each We shall refer to elements of V as component vectors. Formally,

31. In further explanation…  We form sets of vectors  Each coordinate corresponds to an interface of the component  Each coordinate contains a sequence of methods calls that may occur on that interface Hence, for n interfaces, where......

32. Example cont. ISearchFre IFineTune IDetectSignal > CMenu {a 1, a 2 } {b 1, b 2, b 3 } {c 1 } Here, we are forming triples where,

33. Example cont. ISearchFre IFineTune IDetectSignal > CMenu {a 1, a 2 } {b 1, b 2, b 3 } {c 1 } V = { (Λ, Λ, Λ), (a 1, Λ, Λ), (Λ, b 1, Λ), (a 1 a 2, Λ, Λ), (Λ, b 1 b 2, Λ), (Λ, b 1 b 3, Λ), (a 1, b 1 b 2, Λ), (a 1 a 2, Λ, c 1 ), (a 1 a 2, b 1, Λ), (a 1, b 1, Λ), (a 1, b 1 b 2 b 3, Λ), (a 1 a 2, b 1, c 1 ) }

34. Formalisation of a component Definition: A component is a pair where, is the sort of is the sort of is the set of component vectors of is the set of component vectors of The notion of sort embodies the static characteristics while the dynamic characteristics are captured by the notion of component vectors