ComponentBased Software Engineering Components and Interfaces Paul Krause

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

Contents Ø Interfaces as Contracts Ø Future Proofing Ø Non-functional requirements Ø Are we done? Ø Describing Contracts

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

Components and Interfaces A requires certain functionality to fulfil its obligations. A B 1 B 2 B 1 and/or B 2 provide that functionality. An interface mediates between clients and providers.

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

Components in UML 2. 0 <<component>> A A IName 1 IName 2 IName 3 <<component>> IName 4 B • Component A provides IName 1 & IName 2 • Component A requires IName 3 • Component B provides IName 3 • Component B requires IName 4 Components A and B are composed on the basis of interfaces provided by one and required by the other (i. e. interface IName 3)

Pre- and Post-Conditions Ø Pre-conditions: l l What the client must establish before calling the operation The provider can rely on this condition being true whenever the operation is called Ø Post-conditions: l l 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

Example public interface Directory { public void add. Entry(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

Contents Ø Interfaces as Contracts Ø Future Proofing Ø Non-functional requirements Ø Are we done?

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

Future Proofing public interface Arithmetic { public double process. Numbers(double x, double y); // pre x > 5 and y > 5 // post if r = this. process. Numbers(x, y) then r > 10 } public double process. Numbers(double x, double y) { if ((x < 0) || (y < 0)) throw new Illegal. Argument. Exception(“Args must be >=0”); return x + y + 20. 0; }

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 preconditions return >= 20 implies return > 10 Ø The new implementation provides more than the interface specifies Ø The implementation “strengthens” the postconditions

Contents Ø Interfaces as Contracts Ø Future Proofing Ø Non-functional requirements Ø Are we done?

What else can go wrong? public interface Directory { public void add. Entry(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

Non-functional requirements We have seen how respecting pre- and postconditions 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 Ø l What about a new implementation that improves accuracy?

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

Time and Space Requirements Specifying execution time is platform dependent Ø So what can realistically be included in a contract? Ø Could use complexity bounds Ø l Ø 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

Contents Ø Interfaces as Contracts Ø Future Proofing Ø Non-functional requirements Ø Are we done?

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

No! ¨ Pauls Pictures ¨ Pauls Documents ¨ Pauls Pictures ¨ Pauls Sums ¨ Pauls Documents ¨ Pauls Homework ¨ Pauls Sums ¨ Pauls Homework ¨ Pauls To. Do Lists

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

Contents Ø Is there a role formality? Ø Formalisation of a software component l l Static characteristics (structure) Dynamic characteristics (behaviour)

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!

Formalising components Ø Component-based development could benefit from a formal component model which would allow us to make safe assumptions on: l l 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

A typical software component <<component>> IName 1 CName IName 2 IName 3

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

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 l l l is the set of provided interfaces is the set of required interfaces hence, is the set of methods associated with interface

Example <<component>> ISearch. Fre CMenu IFine. Tune {a 1, a 2} {b 1, b 2, b 3} {c 1} IDetect. Signal I = {ISearch. Fre, IFine. Tune, IDetect. Signal}, M = {a 1, a 2, b 1, b 2, b 3, c 1} P = {ISearch. Fre, IFine. Tune} β(ISearch. Fre) = {a 1, a 2} R = {IDetect. Signal} β(IFine. Tune) = {b 1, b 2, b 3} β(IDetect. Signal) = {c 1}

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

Dynamics (behaviour) Formally, 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.

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

Example cont. <<component>> ISearch. Fre CMenu IFine. Tune {a 1, a 2} {b 1, b 2, b 3} {c 1} IDetect. Signal Here, we are forming triples where,

Example cont. <<component>> ISearch. Fre CMenu IFine. Tune {a 1, a 2} {b 1, b 2, b 3} {c 1} IDetect. Signal 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 b 2 b 3, Λ), (a 1 a 2, b 1, c 1)}

Formalisation of a component Definition: A component l l is a pair where, is the sort 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