Chapter 6
Semantic Integrity in Component Based
Development
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 1
Overview
 Introduction
 General Issues of Semantic Concern
 Levels of Formalism for Semantic Specifications
 Phases in a Component’s Life
 A Taxonomy for Component Semantics
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 2
Introduction
 The specification of an interface:


is partly syntactic,
partly semantic
 The semantic component properties are expressed:

using invariants for the component as a whole

contracts expressed through pre- and postconditions, for
each operation
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 3
Specification Levels
 Levels of a component specification:

Syntax: includes specifications on the programming
language level.

Behavior: relates to contracts.

Synchronization: describes the dependencies between
services provided by a component.

Quality of service: deals with quality of service.
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 4
Contracts
 The semantics of an operation are described with a
contract.

Pre-condition: specifies the required entry conditions for
activating the operation.

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.
 The outcome in case the pre-condition was not satisfied
is explicitly left undefined.
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 5
Required and Provided Interfaces
 To be composable solely on the basis of its
specification, a component needs to be equipped with:

Explicit declarations of functionality, synchronization and
quality
required properties
provided properties
Component
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 6
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
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 7
An Example
 C omponent RandomAccess

controlling the access to random access file of a record
type R

records of a fixed size

access to the file is by record number.

It is assumed that the file is continuous.
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 8
The contract
 The precondition for this interface contract

single input parameter of the operation is the number of
the record concerned, which must exist in the file.
 The post-condition

result of the operation is the required data record of type
R.
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 9
Level 0: No Semantics
 The following definition of the operation getRecord
illustrates how a purely syntactic specification would be
given:
public R getRecord(int number)
throws IOException
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 10
Intuitive Semantics
 An intuitive specification of the operation getRecord:
The operation getRecord retrieves a record by its number,
returning the record requested. If an error occurs, such as a disk
read error or a file system error, the an I/O error is returned.
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 11
Structured Semantics
 A structured specification of the operation getRecord:
getRecord returns a record identified by its number.
Parameters:
number: the number of the record to retrieve, counted from zero
Precondition: number >= 0 and number <= the high water mark
Postcondition: the record with the given number is returned,
unless a file system error occurs, in which case a file system
error is reported and the value returned is undefined.
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 12
Executable Semantics
 By “executable semantics”

expressed in a way that can be executed and controlled
by the system during run-time.
Executable specification for getRecord:
getRecord returns a record identified by its number.
Parameters:
number: the number of the record to retrieve, counted from zero
Precondition: (0 <= number) && (number <= hwm())
Postcondition: throw IOException || (result == record(number))
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 13
Trapping Offending Calls
 For debugging purposes, the component itself may use
the executable precondition to trap offending calls:
public R getRecord(int number) throws IOException
{
System.assert((0 <= number) && (number <= hwm()));
// the implementation of the method
}
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 14
Ensuring a Correct Call
 The client code may also take advantage of the
executable assertions by checking the precondition
before the call, as illustrated below:
if ((0 <= number) && (number <= theFile.hwm()))
{
try {
record = theFile.getRecord(number);
// record == the record requested
}
catch (IOException e)
{ /* unrecoverable IO error */ }
}
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 15
Formal Semantics
 The visible state of the random access component is
defined in a state schema called RandomAccess
 The term records represent all the records in the file and
R is the record data type.

The variable hwm (for 'high water mark') shows how
much of the file is in use.
RandomAccess
records: N  R
hwm: N
i : 0..hwm  { records(i) }  
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 16
Formal Semantics Continued
 The file operation is defined as a state schema called
getRecord and is illustrated below:
getRecord
 RandomAccess
number?: N
record!: R
status!: {OK, FileSystemError}
number?  hwm
((status! = OK)  record! = records(number?)) 
(status! = FileSystemError)
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Page 17
A Taxonomy for Component Semantics
Semantic formalism
********
*
*********
****
Structured semantics
*******
***
*******
******
***
Executable semantics
Intuitive semantics
**
****
Formal semantics
*
*
No semantics
Creation
Use
Maintenance
Building Reliable Component-based Systems
Chapter 6 - Semantic Integrity in Component Based Development
Lifecycle
Page 18