Gregor v. Bochmann School of Information Technology and Engineering (SITE) University of Ottawa

Gregor v. Bochmann, University of Ottawa

Submodule construction for specifications with I/O, Nov. 2002 1

Submodule construction for specifications with input assumptions and output guarantees

Gregor v. Bochmann

School of Information Technology and Engineering (SITE)

University of Ottawa

FORTE conference, Houston, November 2002



Thanks

I would like to express my thanks to Philip Merlin with whom I did the first work in this

area in 1969 My PhD students Tao and Drissi whose work was

on equation solving Nina Yevtushenko for some joint work in this

area and for identifying the generalization as a goal

My colleague Cory Butz who gave a talk on stochastic databases during which I saw that databases provide a very general framework for equation solving



Equation solving: Integer division

Multiplication: R1 * R2 = ? Equation solving: R1 * X = R3

What is the value of X ? Solution: definition of the division

operation Written “ X = R3 / R1 ” What does it mean ?

X = biggest Y such that R1 * X ≤ R3 Note: in many cases, there is no exact solution,

that is, there is no X such that R1 * X = R3 For instance: 7 / 3 = 2, and 3 * 2 = 6 ≤ 7



Context of this talk

Multiplication Machine composition Division Submodule construction

(“equation solving”)

Example:

R1 X

R3a1a2

a3R1

? a1a2

a3 R2



Overview

Machine composition and equation solving Applications Solution formulas A generalization: Relational databases The cases of labelled transition systems

(LTS) and synchronous LTS The case of specifications based on

assumptions and guarantees: e.g. synchronous FSMs, IO-Automata and asynchronous FSMs

Conclusions



Equation solving for machines

Given machine R1 and specification R3 for the behavior of the composition of R1 with X, find a behavior of machine X such that

hide a3 in (R1 ∞ X) ≤ R3

Meaning of ≤ : set inclusion of possible execution sequences (“traces”, i.e. sequences of interactions), also called trace inclusion

R1 X

R3a1a2

a3



Applications of machine equation solving

Communication protocols Protocol design (Merlin-Bochmann, 1980) Design of communication gateways

Controller design for discrete event systems

Component reuse, e.g. in software engineering

Embedded testing



Communication protocol design

Protocol entities PE1 and PE2 use the underlying service S and provide the service R3 to the users of the protocol PE1 and S are given PE2 is to be found R1 corresponds to (PE1 ∞ S)

PE1

R3a1a2

S

PE2 R1 X

R3a1a2

a3



Communication gateways

Given desired end-to-end communication service E2E Protocols in the two networks (different)

To be found: gateway behavior (shown by red box)

PE1

R3a1a2

S

PE2 PE’1

R’3a1a2

S’

PE’2

adapterE2E



Controller design

Applications in process control, robotics, etc. Also called “Discrete event systems” (a separate

research community, e.g. [Ramage-Wonham, 1989] and many subsequent papers)

Distinction between non-controllable and controllable interactions (like input/output)

System to be controlled

Controller

Desired properties

a1a2

a3



Component reuse

A given submodule does not completely correspond to the specification of the system to be built

An additional submodule to be built (and designed throught equation solving) makes up the “difference”

Submoduleto be re-used

New subm.to be built

Module to be built

a1a2

a3



Embedded testing

If internal interactions (i.e. a3 ) are not visible, only the properties of the composed system can be observed

The most general behavior of the SUT that leads to conforming behavior for the composed system, is the solution of submodule construction.

This behavior is often more general than the specification for the SUT; the difference can not be observed.

Component assumed correct

Componentunder test

Properties of composed system

a1a2

a3



Equation solving for

labelled transition systems

Rendezvous interactions a3: between R1 and X a2: between R1 and environment a1: between X and environment

Behavior definition set of allowed execution sequences

e.g. for X: execution sequences over interactions at a3 or a1

R1 X

R3a1a2

a3



The problem and its solution

Problem: Find most general X (largest set of execution sequences) such that

hide a3 in (R1 ∞ X) ≤ R3

Solution: X = (a1U a3)* \ (minus)

any sequence that could lead to an observable execution sequence not

in R3 , i.e.

hide a2 in (R1 ∞ ( (a1U a2)* \ R3 ) )

R1 X

R3a1a2

a3

R1 X

R3

a1a2

a3



A comment Since all execution sequences of X must go in

interaction with R1 and R3, we may replace the chaos for X with all sequences that are obtained by the composition of R1 and R3, that is [Merlin and Bochmann, 1980]

Solution: X = hide a2 in (R1 ∞ R3 ) \ (minus)

hide a2 in (R1 ∞ ( (a1U a2)* \ R3 ) )

R1 X

R3a1a2

a3

R1 X

R3

a1a2

a3




synchronous automata Synchronous communication

Simultaneous interactions at all interfaces; at each clock pulse, there is a vector of interactions

Behavior definition set of allowed sequences of interaction vectors

e.g. for X: the interaction vectors include interactions at a3 and a1

R1 X

R3a1a2

a3



Solution of equation solving

Identical form of formulas Meaning of operators have changed

∞ : synchronous composition hide operator

ignores a component of the vector

[Yevtushenko et al., 1999]



Relational database (intro)

A DB is a set of relations A relation is a table

Each column is an attribute Each row is an “object” An element at position (ai, ok) in the table

represents the value that object ok takes for attribute ai

With each attribute ai is associated a set of possible values Di



Relational database concepts

Formal definitions: Attributes: A = {a1, a2, … an} Attribute values: D = U Di

Relation over Ar (Ar A), written R[Ar]:

(possibly infinite) set of mappings T: Ar D

with T(ai) ε Di

Note: each mapping corresponds to a row



Example

Name Age SalaryFred 53 50000

Paul 50 60000

Alice 21 40000

Suzanne 35 50000

Bob 20 30000

Name Project

Fred BigOne

Alice BigOne

Fred SmallOne

Suzanne SmallOne

R1R2



Relational operators

ProjectionGiven R[Ar] and Ax Ar ,

the projection of R[Ar] onto Ax , written projAx (R) ,

is a relation over Ax with

T ε projAx (R) iff exists T’ ε R s.t. ai ε Ax: T(ai) = T’(ai)

JoinGiven R1[A1] and R2[A2], the join of R1 and R2 , written R1 ∞ R2

, is a relation over A1 U A2 with

T ε (R1 ∞ R2) iff projA1 (T) ε R1 and projA2 (T) ε R2

ChaosGiven Ax A, the chaos over Ax , written Ch[Ax], is the

relation which includes all mappings T: Ax D with T(ai) ε Di



Example

Proj{Project} (R2) =

R1 ∞ R2 =

Name Age SalaryFred 53 50000

Paul 50 60000

Alice 21 40000

Suzanne 35 50000

Bob 20 30000

Name Project

Fred BigOne

Alice BigOne

Fred SmallOne

Suzanne SmallOne

R1R2

ProjectBigOne

SmallOne

Name Age Salary ProjectFred 53 50000 BigOne

Fred 53 50000 SmallOne

Alice 21 40000 BigOne

Suzanne 35 50000 SmallOne




relational databases We consider

Three attributes a1, a2 , a3

Two relations R1 [{a3, a2 }], R3 [{a1, a2 }] Problem: What is the biggest relation X [{a1, a3 }]

satisfying proj{a1, a2 }(R1 ∞ X) R3

Solution: X = Ch[{a1, a3 }] \

proj{a1, a3 }(R1 ∞ (Ch[{a1, a2 }] \ R3 ) )

Proof: see paper Greneralization to more complex attribute structures is also easy

R1 X

R3a1a2

a3



D1 = {} D2 = {aa, ab, ba, bb} D3 = {c, d}

X = Ch[{a1, a3 }] \ proj{a1, a3 }(R1 ∞ (Ch[{a1, a2 }] \ R3 ) )

An exampleR1 X

R3a1a2

a3

a1 a2

abR3 R1

a2 a3

ab c

ab d

aa d

a1 a3

c

d

Ch[{a1, a3 }]a1 a2

aa

ba

bb

Ch[{a1, a2 }] \ R3 ) R1 ∞ (Ch[{a1, a2 }] \ R3 )

a1 a2 a3

aa d

a1 a3

c

X



A special case: Trace specifications

Attributes Interfaces Di = Ii * that is, all finite sequences of elements of Ii , the

possible interactions at the interface ai (the “alphabet” at interface ai)

Machine behavior RelationEach row (DB object) represents a possible execution

history (“trace”) ; the value for each attribute describes the interaction sequence occurring at the corresponding interface during that trace

Synchrony constraint: The interaction sequences at the different interfaces for a given trace are of equal length



Two sub-cases: - synchronous operation (as above) - interleaving semantics (below)

Attributes Interfaces Di = (Ii U {null} ) *

(as synchronous case, except that there is a real interaction at only one interface at a time; “interleaving semantics” )

Machine behavior RelationAs in synchronous case, except that the

“interleaving constraint” is satisfied for all mappings of a relation, that is, for any j, the j-th element of T(ai) is non-null for at most one attribute ai



Algorithms for equation solving

Solution: X = Ch[{a1, a3 }] \ proj{a1, a3 }(R1 ∞ (Ch[{a1, a2 }] \ R3 ) )

Algorithms for operations ∞ , \ , proj In general not possible (infinite sets of

mappings) For finite state models :

Polynomial complexity for ∞ , proj proj introduces non-determinism \ requires conversion to deterministic

models, which has exponential complexity



Example

proj (R1 join R3 ) determinized

(a,n)

(b,n)

(a,n) (n,c)

(n,d)

(n,d)R3 R1

(n,n)(b,n)

(b,n)

(a,n)

(a,n)Notation (x2,x1)

Notation (x2,x3)

R3 completed

2 21 213 3

4

5

6

(a,n)

(b,n)

(n,n)

2

1 3

(a,n)(a,n)

(b,n)(b,n)

(n,n)(n,n)

fail

(n,a,n)(n,n,c)

(n,n,d)

(n,n,d)

R1 join R3

(n,b,n)

(n,b,n)

(n,a,n)

(n,a,n)

2,2

21,1 3,3

4,3

5,3

6,1

6,fail

Notation (x1,x2,x3)

(n,n)(n,c)

(n,d)

(n,n)

(n,n)

(n,n)

2,2

1,1 3,3

4,35,3

6,1

6,fail

Notation (x1,x3)

6,1

(n,n)(n,c) (n,n)

(n,n)

2,2

1,1 3,36,1

Notation (x1,x3)

Solution

R1 X

R3

a1a2

a3

{a, b, n}

{c, d, n}

{n}



Systems with input and output

Nature of input/output (non-rendezvous) Output: time and parameters of an interaction

are determined by the system component producing the output

Input: The component receiving the interaction cannot influence the time nor parameter values

Specification of component behavior Output: The specification gives guarantees

about timing and parameter values Input: The specification may make assumptions

about timing of inputs and the received parameter values



Specification paradigmswith hypothesis and guarantees

Software Pre- and postconditions of a procedure call

They define hypotheses on input parameters, and guarantees on output parameters, respectively

Finite state machines (state-deterministic) Unspecified input: hypothesis about the

behavior of the environment: this input will not occur when the machine is in this state



Component specification and interconnection

Each attribute of a relation is either input or output

Constraint on component interconnection No output conflicts: For each interface, there is

only one connected component for which the corresponding attribute is output

For trace specifications: Unit delay constraint Output(s) at time t depend only on previous

interactions of the same component (not on the input received at time t) [e.g. Broy, Lamport]

In FSM context: corresponds to Moore machine



Conformance to specifications

Given a specification R and a trace T Either T R (we say T conforms to R) or … T has wrong input: all prefixes of T up some time t

conform to R, but there is wrong input at time (t+1) T has wrong output: similarly T has wrong input and output at the same time instant

A component conforms to a specification R iff no trace T in which the component participates has wrong output in respect to R Note: if a trace has wrong input, nothing can be

assumed about wrong output at a later time instance



Equation solving for trace specifications with input/output

Find most general specification X such that any trace T of the composition of R1

and X has the following properties: proj{a1, a2} (T) conforms to R3

If proj{a1, a2} (T) has no wrong input in respect to R3 then proj{a2, a3} (T) has no wrong input in resp. to R1

R1 X

R3a1a2

a3



Solution formula Notation:

RWO(t) = set of traces that have wrong output in respect to R at time instant t

RWI(t) : similarly for wrong input Ut : union over all values of t

Solution: X = Ch[{a1, a3 }] \ proj{a1, a3 } Ut (

R1 ∞ R3WO(t) U R1

WI(t) ∞ R3 U R1

WI(t) ∞ R3

WO(t) )



Solution algorithms for I/O

Synchronous FSMs Can be easily derived from above formula The special case of completely defined,

deterministic machines was already solved by Kim et al.

Interleaving semantics Simplification: Never wrong input and output at the

same time instant IO-Automata

Jawad Drissi (PhD thesis) Communicating FSMs

Yevtushenko and Petrenko



Extensions of the specification formalisms

More powerful specification languages Petri nets, CSP, LOTOS, etc.

Different conformance relations Safeness

Trace semantics (as discussed here) Liveness - progress (some good interaction will

occur) Liveness [Thistle] Absense of blockings [Tao, PhD thesis] Optional and required progress [Drissi, PhD thesis]

Real-time aspects Timed automata [Grenoble; work on DES; Drissi, PhD

thesis]



Conclusions (i)

New results presented here: Solution formula for equation solving in

the context of relational databases Equation solving for component composition

based on trace semantics (synchronous and interleaving case) as special cases

Solution formula for trace semantics with input and output



Conclusions (ii) Application areas:

Protocol design (Merlin-Bochmann, 1980) Design of communication gateways Controller design Component reuse, e.g. in software engineering Embedded testing

Future work More powerful specification paradigms

e.g. interaction parameters Tools Practical design methodology based on formal

methods

Documents

Gregor v. Bochmann School of Information Technology and Engineering (SITE) University of Ottawa