1. Page 1 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Chapter 6 Semantic Integrity in Component Based Development

2. Page 2 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Overview qIntroduction qGeneral Issues of Semantic Concern qLevels of Formalism for Semantic Specifications qPhases in a Component’s Life qA Taxonomy for Component Semantics

3. Page 3 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Introduction q The specification of an interface: l is partly syntactic, l partly semantic q The semantic component properties are expressed: l using invariants for the component as a whole l contracts expressed through pre- and postconditions, for each operation

4. Page 4 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Specification Levels q Levels of a component specification: l Syntax: includes specifications on the programming language level. l Behavior: relates to contracts. l Synchronization: describes the dependencies between services provided by a component. l Quality of service: deals with quality of service.

5. Page 5 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Contracts q The semantics of an operation are described with a contract. l Pre-condition: specifies the required entry conditions for activating the operation. l Post-condition: specifies the exit conditions guaranteed by the operation at the end of its execution, provided the pre-condition was satisfied at the entry. q The outcome in case the pre-condition was not satisfied is explicitly left undefined.

6. Page 6 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Required and Provided Interfaces q To be composable solely on the basis of its specification, a component needs to be equipped with: l Explicit declarations of functionality, synchronization and quality F required properties F provided properties Component

7. Page 7 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Levels of Formalism for Semantic Specifications qThe levels of formalism, in an increasing order of formalism: l No semantics l Intuitive semantics l Structured semantics l Executable semantics l Formal semantics

8. Page 8 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development An Example qC omponent RandomAccess l controlling the access to random access file of a record type R l records of a fixed size l access to the file is by record number. l It is assumed that the file is continuous.

9. Page 9 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development The contract q The precondition for this interface contract l single input parameter of the operation is the number of the record concerned, which must exist in the file. q The post-condition l result of the operation is the required data record of type R.

10. Page 10 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Level 0: No Semantics  The following definition of the operation getRecord illustrates how a purely syntactic specification would be given:

11. Page 11 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Intuitive Semantics  An intuitive specification of the operation getRecord :

12. Page 12 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Structured Semantics  A structured specification of the operation getRecord :

13. Page 13 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Executable Semantics q By “executable semantics” l expressed in a way that can be executed and controlled by the system during run-time. Executable specification for getRecord :

14. Page 14 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Trapping Offending Calls qFor debugging purposes, the component itself may use the executable precondition to trap offending calls:

15. Page 15 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Ensuring a Correct Call q The client code may also take advantage of the executable assertions by checking the precondition before the call, as illustrated below:

16. Page 16 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Formal Semantics qThe visible state of the random access component is defined in a state schema called RandomAccess q The term records represent all the records in the file and R is the record data type. l The variable hwm (for 'high water mark') shows how much of the file is in use.

17. Page 17 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Formal Semantics Continued  The file operation is defined as a state schema called getRecord and is illustrated below:

18. Page 18 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development A Taxonomy for Component Semantics Lifecycle CreationUseMaintenance No semantics Intuitive semantics Structured semantics Executable semantics Formal semantics Semantic formalism ** *** ******* **** * ******** * **** * ******* ********* ****** ***