Component Composition: Types, Incompatibility, and Specification

1. CBSE 2014Component specification

2. Bibliography • Main bibliography: • Sommerville: Software Engineering, 8th Edition • Chapter 19.3 Component Composition • Ivica Crnkovic, Magnus Larsson (Eds.): Building reliable component-based systems • Chapter 2: Specification of Software Components • Chapter 6: Semantic Integrity in Component Based Development • Other readings: • B.Meyer: Applying Design by Contract • Mary Shaw, Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does

3. Review: Component models Components must obey to common conventions or standards ! Only in this way they will be able to connect and communicate to each other

4. Review: Component Frameworks Platform Services: allow components written according to the model to communicate; locating, linking, replacing components Component Component Component Component platform (component framework) Middleware Operating System Horizontal Services: application-independent services used by different components. Concurrency, security, transaction management, Resource management Hardware

5. Component composition • Composition involves integrating components with each other and with the component infrastructure. • The ways in which components are integrated with this infrastructure are specific for each component model • In the discussion of this chapter, we assume that the components to be subject to composition belong to the same component model, thus they can be integrated • Component composition is the process of assembling the components to create a system. • Normally you have to write ‘glue code’ to compose components.

6. Types of composition • Sequential composition where the composed components are executed in sequence. This involves composing the provides interfaces of each component. • Glue code: calls component A, collects result, then calls component B with that result as parameter • Hierarchical composition where one component calls on the services of another. The provides interface of one component is composed with the requires interface of another. • Additive composition where the interfaces of two components are put together to create a new component.

7. Types of composition Figure 19.9 from [Sommerville]

8. Component incompatibility • When you design components specially for composition, interfaces are designed to be compatible • When the components are developed independently for reuse, interfaces may be incompatible: • Interface incompatibility (Syntactic incompatibility) • Semantic incompatibility • We recall that only components belonging to same component model are considered (thus integration is physically possible)

9. Example • Expression Component – Multiplier Component • Interface incompatibility: The expression component requires an operation multiply, while the multiplier component provides an operation named do_op • Semantic Incompatibility: The multiplier component implements the operation by repeated addition, thus it works if the second number is a positive integer. The expression component needs to multiply any integers (positive and negative).

10. Interface incompatibility • Situations of Interface incompatibility: • Parameter incompatibility where operations have the same name but are of different types. • Operation incompatibility where the names of operations in the composed interfaces are different. • Operation incompleteness where the provides interface of one component is a subset of the requires interface of another • Interface incompatibility is addressed by writing adaptors • Adaptors address the problem of component incompatibility by reconciling the interfaces of the components that are composed. • Different types of adaptor may be required depending on the type of composition.

11. Semantic incompatibility • Component composition assumes you can tell from the component documentation whether the interfaces are compatible • Semantic compatibility: the meaning of parameters is right • You have to rely on component documentation to decide if interfaces that are syntactically compatible are actually compatible.

12. Component specification • There should be no difference between: • What a component does • What we know it does • The only way we get to know what a component does is from its component specification • Levels of a component specification: • Syntax: includes specifications on the programming language level. • Semantic: functional contracts • Non-functional: deals with quality of service.

13. Component specification levels • Levels of a component specification: • Syntax: includes specifications on the programming language level. • Semantic: functional contracts • Non-functional: deals with quality of service.

14. Components and Interfaces • A component provides: • The implementation of a set of named interfaces, or types, each interface being a set of named operations • The following diagram is a UML metamodel • This model allows an interface to be implemented by several different components, and an operation to be part of several different interfaces

15. Metamodel of the concepts used in syntacticspecification of software components Figure 2.1 from [Crnkovic]

16. Example: component SpellChecker • Implementation as a COM component: • Uses an IDL

17. IDL Example interface ISpellCheck : IUnknown { HRESULT check([in] BSTR *word, [out] bool *correct); }; interface ICustomSpellCheck : IUnknown { HRESULT add([in] BSTR *word); HRESULT remove([in] BSTR *word); }; library SpellCheckerLib { coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; }; };

18. Uses of Syntactic Specification • The primary uses of syntactic specifications are: • Type checking (static of dynamic) of client code. • Base for interoperability between independently developed components and applications. • Interoperability may be achieved in different ways: • Binary format for interfaces • IDL to programming language mappings • An important aspect of interface specifications is how they relate to substitution and evolution of components

19. Substitution • Substituting a component Y for a component X is said to be safe if: • All systems that work with X will also work with Y • From a syntactic viewpoint, a component can safely be replaced if: • The new component implements at least the same interfaces as the older components, or • The interface of the new component is a subtype of the interface of the old component.

20. Forms of syntactic specification • All component models use syntactic specification of interfaces: • Programming language • IDL • Examples • Microsoft’s Component Object Model (COM) • Common Object Request Broker Architecture (CORBA) • JavaBeans

21. Component specification levels • Levels of a component specification: • Syntax: includes specifications on the programming language level. • Semantics: functional contracts • Non-functional: deals with quality of service.

22. Contracts Contracts for the semantic specification of components are a kind of Meyer’s Design by Contract: “Applying Design by Contract,” B. Meyer, IEEE Computer, pp. 40-51, October 1992.

23. Design-by-contract background A Client-Server Design Server Objects Provides services for client objects to use The object whose methods are being invoked Client Object Consumes the services offered by the supplier object The object that invokes the methods of the supplier object Contract A set of benefits and obligations that are mutually agreed upon by the client and supplier In practice, specified by the supplier object Clients implicitly accept the contract by using objects of the supplier class Good contracts are always in writing!

24. Contracts in real life - Example Contract with a courier delivery service: Table 1 from [Meyer]

25. What is a Contract? A contract between a client and a supplier protects both sides It protects the client by specifying how much should be done to get the benefit. The client is entitled to receive a certain result. It protects the supplier by specifying how little is acceptable. The supplier must not be liable for failing to carry out tasks outside of the specified scope. If a party fulfills its obligations it is entitled to its benefits No Hidden Clauses Rule: no requirement other than the obligations written in the contract can be imposed on a party to obtain the benefits

26. Contracts for softwareExample: add node to tree • Contract is between: • Client = caller • Supplier = called routine • Example: • A class Tree describing tree nodes • A routine put_child for adding a new child to the tree node Current • The routine put_child receives a reference to an existing node object and adds it as a child of Current • Problem: a reference is either void or attached to an object. • Question: who should check if new is void ? • Approaches: • Defensive programming: include as many checks as possible, even if redundant with checks done by caller -> leads to increased complexity, which leads to probability of errors • Contracts Table 2 from [Meyer]

27. Contracts for softwareExample: add node to tree Informal description of contract:: Table 2 from [Meyer]

28. Contracts for softwareExample: add node to tree • Contracts for software are expressed through: • preconditions - the obligations of the client • postconditions - properties that are ensured in return by the execution of the function call • Example: Operation put_child (new:Node); -- add new to the children of Current Precondition: new is not void Postcondition: new’s parent is Current and the children-count of current has been increased by 1

29. Weak and strong contracts“Who has to check all the conditions?” • Postconditions • specify the exit conditions guaranteed by an operation at its end provided the precondition was satisfied at the entry in the operation • The outcome when the precondition was not satisfied is explicitly left undefined [Meyer] • Strong contract: • the precondition specifies conditions for success • postconditions need to specify only the outcome in the well-defined situations • Back-end-components usually have strong contracts • Weak contract: • the precondition is incomplete, the component must be able to filter out invalid uses • The postconditions will specify also the outcome of the invalid uses • Front-end-components (such as GUI-components) usually have weak contracts

30. Contracts for components Contracts for components are expressed through: • Pre-conditions • Post-conditions • Invariants

31. A Pre-condition • Is an assertion that the component assumes to be fulfilled before an operation is invoked. • Is a predicate over the operation’s input parameters and this component’s state

32. A Post-condition • Is an assertion that the component guarantees will hold just after an operation has been invoked, provided the operation’s pre-conditions were true when it was invoked. • Is a predicate over both input and output parameters as well as the state just before the invocation and the state just after

33. An Invariant • Is a predicate over the interface’s state model that will always hold • A set of invariants may be associated with an interface.

34. Metamodel of the concepts used in semantic specification of software components Figure 2.2 from [Crnkovic]

35. Semantic specification of components • Semantic specification of a component comprises: • Specify component interfaces • For each interface, specify: • Model of state and Invariants • Operations with pre- and post-conditions • The model allows that different interfaces act on the same state model • Inter-interface constraints Note that state models and operation semantics are associated with interfaces rather than with a component !

36. Component specificationExample: component SpellChecker Specifying a component that provides interfaces

37. Interface specification diagramExample: Interface ISpellCheck • State: words • Operations: • check (in word:String, out correct:Boolean):HRESULT; • Pre: the word to be checked is non-empty string • Post: if the return value indicates success, then the value of correct is true if word was a member of words and false otherwise

38. Interface specification diagramExample: ICustomSpellCheck • State: words • Operations: • add (in word:String):HRESULT; • Pre: the word to be added is non-empty string • Post: if the return value indicates success, then word has been added to words • remove(in word:String):HRESULT; • Pre: the word to be removed is non-empty string • Post: if the return value indicates success, then word has been removed from words

39. Inter-interface Constraints • The component specification can be completed by the specification of its inter-interface constraints: • Relationships between the models of state associated with the different interfaces context SpellChecker ISpellCheck::words = ICustomSpellCheck::words

40. Uses of Semantic Specification • Tool support for component developers • Tool support for developers of component-based applications

41. Substitution extended with semantics • Substituting a component Y for a component X is said to be safe if: • All systems that work with X will also work with Y • From a semantic viewpoint, a component can safely be replaced if: • A client that satisfies the preconditions for X must always satisfy the preconditions specified for Y • A client that can rely on postconditions ensured by X can also be ensured it can rely on Y • Conditions for component Y: • Interfaces of Y can have weaker preconditions on operations • Interfaces of Y can have stronger postconditions on operations • State models of X and Y need not be identical

42. Levels of Formalism for Semantic Specifications • The levels of formalism, in an increasing order of formalism: • No semantics • Intuitive semantics • Structured semantics • Executable semantics • Formal semantics

43. An Example • Component RandomAccess • controlls the access to random access file of a record type R • records of a fixed size • access to the file is by record number, numbers start from 0. • It is assumed that the file is continuous, thus record numbers go up to the current maximum number, called the high water mark • Operations: • addRecord • getRecord • delRecord • getHighWaterMark

44. The contract • Operation getRecord – retrieves a record with a given number • The precondition : • the single input parameter of the operation is the number of the record concerned, which must exist in the file. • The post-condition: • If an unrecoverable system error occurs (file system error) the operation indicates a failure • Weak part of the contract: client does not have to check file status before • the result of the operation is the required data record of type R. • Strong part of the contract: assumes that record number is always correctly given

45. Level 0: No Semantics • The following definition of the operation getRecord illustrates how a purely syntactic specification would be given:

46. Level 1: Intuitive Semantics • Plain text, unstructured description and comments about a component and its parts • An intuitive specification of the operation getRecord:

47. Level 2: Structured Semantics • The semantics is presented in a structured way but needs not be in accordance with any particular syntax or formalism • A structured specification of the operation getRecord:

48. Level 3: Executable Semantics • The semantics is expressed in a way that can be executed and controlled by the system during run-time. • The executable specification is included in the implementation of the component • Limitation: not all conditions can be expressed in an executable way Executable specification for getRecord:

49. Examples of executable semantics • For program implementations: • Assertions in Java: http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html • MSDN: Code Contracts: http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx • For UML models: OCL (Object Constraint Language) • General rules: • The execution of the assertions should not add functionality ! • Assertions serve to detect coding errors and should not try to handle or compensate for them

50. Ensuring a Correct Call • The client code must check the precondition before the call, as illustrated below: