Lecture Building reliable component-based systems - Chapter 6: Semantic integrity in component based development

This chapter presents the following content: Introduction, general issues of semantic concern, levels of formalism for semantic specifications, phases in a component’s life, a taxonomy for component semantics.

Trang 1

Building Reliable Componentbased Systems

Chapter 6 Semantic Integrity in Component Based Development

Chapter 6 Semantic Integrity in Component Based

Development

Trang 2

Overview

Introduction

General Issues of Semantic Concern

Levels of Formalism for Semantic Specifications

Phases in a Component’s Life

A Taxonomy for Component Semantics

Trang 3

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

Trang 4

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.

Trang 5

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

Trang 6

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

Trang 7

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

Trang 8

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.

Trang 9

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.

Trang 10

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

Trang 11

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.

Trang 12

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

Trang 13

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

Trang 14

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

}

Trang 15

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 */ }

}

Trang 16

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

i : 0 hwm { records(i) }

Trang 17

Formal Semantics Continued

The file operation is defined as a state schema called

getRecord and is illustrated below:

getRecord

RandomAccess

record!: R

status!: {OK, FileSystemError}

number? hwm

((status! = OK) record! = records(number?))

(status! = FileSystemError)

Trang 18

A Taxonomy for Component Semantics

Lifecycle

Creation Use Maintenance

No semantics

Intuitive semantics

Structured semantics

Executable semantics

Formal semantics

Semantic formalism

**

***

*******

****

*

********

*

****

*

*******

*********

******

***

Định dạng
Số trang	18
Dung lượng	427,01 KB