Protection

from

the

Underspecified

Gary

T.

Leavens

and

Jeannette

M.

Wing

TR

April

CR

Categories

D.

-LSB-

Software

Engineering

-RSB-

Requirements

Specifications

languages

theory

Larch

D.

-LSB-

Software

Engineering

-RSB-

Distribution

and

Maintenance

documentation

F.

-LSB-

Logics

and

Meanings

of

Programs

-RSB-

Specifying

and

Verifying

and

Reasoning

about

Programs

assertions

logics

of

programs

pre

and

post-conditions

specification

techniques

theory

LSL

Submitted

for

publication

c

Copyright

by

Gary

T.

Leavens

and

Jeannette

M.

Wing

All

rights

reserved

Department

of

Computer

Science

Atanasoff

Hall

Iowa

State

University

Ames

Iowa

USA

Protection

from

the

Underspecified

Gary

T.

Leavens

Department

of

Computer

Science

Iowa

State

University

Ames

Iowa

Jeannette

M.

Wingy

School

of

Computer

Science

Carnegie

Mellon

University

Pittsburgh

Pennsylvania

April

Abstract

Underspecification

is

a

good

way

to

deal

with

partial

functions

in

specification

and

reasoning

However

when

underspecification

is

used

implementations

may

unintentionally

be

forced

to

depend

on

parts

of

the

specification

that

were

supposed

to

be

underspecified

We

show

how

to

write

pre

and

postcondition

specifications

that

avoid

such

problems

by

having

the

precondition

protect

the

postcondition

from

the

effects

of

underspecification

This

approach

is

most

practical

if

the

specification

of

mathematical

vocabulary

is

separated

from

the

specification

of

implementation

behavior

as

in

Larch

because

it

gives

the

specifier

a

chance

to

think

about

protection

separately

from

the

specification

of

mathematical

behavior

We

formalize

the

notion

of

protective

procedure

specifications

and

show

how

to

prove

that

a

specification

is

protective

We

also

extend

the

Larch

Shared

Language

to

allow

specification

of

what

is

intentionally

left

underspecified

which

also

allows

enhanced

debugging

of

such

specifications

Undefinedness

and

Underspecification

Any

method

for

specifying

and

verifying

computer

programs

has

to

deal

with

partial

functions

Our

explanation

of

this

problem

reviews

a

recent

article

by

C.

Jones

-LSB-

-RSB-

Since

the

use

of

underspecification

as

a

solution

to

this

problem

has

been

advocated

by

others

-LSB-

-RSB-

our

point

in

this

review

is

the

need

for

ways

to

ffl

document

what

is

intended

to

be

completely-defined

-LRB-

or

conversely

underspecified

-RRB-

and

Leavens

's

work

was

supported

in

part

by

NSF

grant

yWing

's

research

is

sponsored

by

the

Wright

Laboratory

Aeronautical

Systems

Center

Air

Force

Materiel

Command

USAF

and

the

Advanced

Research

Projects

Agency

-LRB-

ARPA

-RRB-

under

grant

number

Views

and

conclusions

contained

in

this

document

are

those

of

the

authors

and

should

not

be

interpreted

as

necessarily

representing

official

policies

or

endorsements

either

expressed

or

implied

of

Wright

Laboratory

or

the

United

States

Government

ffl

prevent

underspecification

from

having

unintended

consequences

Background

A

partial

function

is

a

function

that

does

not

give

a

value

for

some

elements

of

its

declared

domain

For

example

the

operator

that

returns

the

head

of

a

list

can

be

modeled

as

a

partial

function

on

lists

if

that

is

done

then

head

-LRB-

empty

-RRB-

fails

to

denote

an

element

-LRB-

That

is

head

-LRB-

empty

-RRB-

is

undefined

-RRB-

One

way

to

deal

with

partiality

in

reasoning

is

to

use

a

specialized

logic

for

example

one

with

three

logical

values

and

two

kinds

of

equality

-LSB-

-RSB-

However

because

all

such

logics

either

do

not

satisfy

standard

logical

laws

or

are

not

compositional

such

logics

are

subtle

and

thus

more

difficult

to

use

and

teach

-LSB-

-RSB-

More

importantly

if

one

uses

informal

reasoning

and

informal

specifications

as

is

common

in

real

software

projects

then

there

is

no

hope

of

using

such

a

specialized

logic

We

agree

with

Gries

and

Schneider

-LSB-

-RSB-

that

the

best

approach

to

dealing

with

partiality

is

to

use

underspecification

That

is

one

avoids

specifying

a

value

for

undefined

terms

but

assumes

that

all

functions

are

total

As

a

concrete

example

of

this

approach

consider

the

Larch

Shared

Language

-LRB-

LSL

-RRB-

-LSB-

Chapter

-RSB-

-LSB-

-RSB-

In

LSL

's

logic

all

functions

are

presumed

to

be

total

That

is

head

-LRB-

empty

-RRB-

denotes

some

element

of

the

appropriate

type

even

if

the

user

has

not

specified

what

element

that

term

denotes

Where

an

LSL

specification

is

silent

terms

take

on

some

-LRB-

unspecified

-RRB-

value

In

common

with

other

logics

that

use

underspecification

to

avoid

the

undefined

the

logic

of

LSL

is

classical

and

thus

has

several

pleasing

formal

properties

More

importantly

classical

logic

matches

informal

reasoning

Jones

's

Examples

Recently

Jones

presented

some

counter

examples

to

logics

like

LSL

's

which

use

underspecification

to

deal

with

partiality

-LSB-

-RSB-

We

use

these

examples

to

explain

LSL

underspecification

and

the

problem

we

are

solving

We

translate

Jones

's

first

example

into

the

LSL

trait

shown

in

Figure

This

trait

defines

a

sort

OneElem

a

constant

it

and

a

function

f.

Because

of

the

generated

by

clause

the

sort

OneElem

has

only

one

element

the

constant

it

-LRB-

The

current

version

of

LSL

allows

such

sorts

contrary

to

-LSB-

-RSB-

-RRB-

In

LSL

f

-LRB-

-RRB-

it

because

f

has

to

take

on

some

value

when

applied

to

and

the

only

possible

value

is

it

Although

Jones

notes

that

this

is

not

an

inconsistency

he

says

that

it

is

certainly

likely

to

surprise

someone

who

views

the

definition

of

f

as

specifying

a

partial

function

-LRB-

p.

-RRB-

However

the

amount

of

surprise

would

be

in

direct

proportion

to

the

strength

of

the

person

's

belief

that

they

are

defining

partial

functions

in

LSL

a

view

that

is

simply

mistaken

Thus

rather

than

being

a

counter

example

we

see

this

as

an

educational

example

Although

this

example

illustrates

the

technical

point

that

all

LSL

functions

are

total

we

do

not

expect

that

every

user

of

LSL

understands

it

Instead

we

believe

that

a

practical

specification

formalism

should

allow

the

trait

includes

Integer

introduces

it

OneElem

f

Int

OneElem

asserts

OneElem

generated

by

it

i

Int

f

-LRB-

i

-RRB-

if

i

then

it

else

f

-LRB-

-RRB-

implies

converts

f

Int

OneElem

Figure

Jones

's

counter

example

factTrait

trait

includes

Integer

introduces

fact

Int

Int

asserts

i

Int

fact

-LRB-

i

-RRB-

if

i

then

else

i

fact

-LRB-

-RRB-

implies

equations

fact

-LRB-

-RRB-

fact

-LRB-

-RRB-

fact

-LRB-

-RRB-

Figure

Jones

's

factorial

example

specifier

to

state

what

is

intended

to

be

completely-defined

-LRB-

or

conversely

underspecified

-RRB-

in

such

cases

Jones

's

other

major

example

brings

out

a

more

important

warning

about

the

underspecification

approach

This

example

is

a

recursive

definition

of

the

factorial

function

and

is

translated

into

LSL

in

Figure

Jones

's

warning

about

this

example

is

that

in

a

logic

such

as

LSL

's

a

model

of

fact

must

satisfy

irrelevant

equations

such

as

the

following

which

is

also

highlighted

in

the

redundant

implies

section

of

the

trait

fact

-LRB-

-RRB-

fact

-LRB-

-RRB-

-LRB-

-RRB-

This

follows

because

fact

-LRB-

-RRB-

denotes

some

-LRB-

unspecified

-RRB-

value

Assuming

that

such

equations

are

accidents

of

the

logic

and

not

intended

by

the

specifier

it

would

be

very

serious

if

such

irrelevant

properties

would

have

to

be

implemented

in

a

program

Gries

and

Schneider

-LSB-

-RSB-

in

reply

to

this

last

example

say

that

the

fault

lies

in

the

recursive

definition

rather

than

in

handling

the

undefined

by

un

trait

includes

Integer

introduces

fact

Int

Int

asserts

i

Int

fact

-LRB-

-RRB-

-LRB-

i

-RRB-

-RRB-

fact

-LRB-

i

-RRB-

i

fact

-LRB-

-RRB-

implies

equations

fact

-LRB-

-RRB-

Figure

Gries

and

Schneider

's

improvement

to

Jones

's

factorial

example

derspecification

-LRB-

p.

-RRB-

Their

specification

of

this

example

is

translated

into

LSL

in

Figure

However

Gries

and

Schneider

's

specification

does

not

completely

dispense

with

the

problems

that

Jones

's

factorial

example

raises

The

remaining

problem

is

that

users

might

accidentally

do

what

Jones

's

factorial

example

warns

against

require

implementations

to

satisfy

unintended

constraints

The

point

is

that

users

of

such

a

specification

formalism

are

prone

to

make

such

mistakes

unless

the

formalism

has

some

way

of

preventing

or

catching

such

mistakes

Gries

and

Schneider

's

version

of

the

specification

avoids

the

problems

Jones

warns

against

but

they

offer

only

education

as

a

remedy

While

we

applaud

their

efforts

we

believe

that

more

practical

solutions

should

not

require

so

much

sophistication

especially

if

they

are

to

be

used

informally

Thus

we

advocate

ffl

the

separation

of

an

implementation

's

specification

into

two

tiers

and

ffl

redundant

ways

of

specifying

what

is

intended

to

be

completely-defined

-LRB-

or

underspecified

-RRB-

The

separation

of

a

specification

into

two

tiers

can

be

used

even

in

informal

contexts

-LSB-

-RSB-

to

guard

against

the

problems

Jones

warns

about

The

redundant

ways

of

specifying

intent

can

be

used

to

debug

and

check

formal

specifications

to

further

guard

against

this

problem

In

formal

specifications

redundant

ways

of

specifying

intent

are

needed

because

a

logical

formula

may

encode

information

about

the

intended

domain

of

definition

of

an

operator

in

various

clever

ways

Such

clever

encodings

may

make

it

difficult

to

extract

the

information

that

Gries

and

Schneider

's

definition

so

clearly

displays

For

example

each

of

the

following

formulas

is

equivalent

to

the

last

axiom

in

the

asserts

section

of

Figure

-LSB-

Section

-RSB-

-LRB-

i

-RRB-

fact

-LRB-

i

-RRB-

i

fact

-LRB-

-RRB-

-LRB-

-LRB-

i

-RRB-

fact

-LRB-

i

-RRB-

i

fact

-LRB-

-RRB-

-RRB-

-LRB-

i

-RRB-

-LRB-

fact

-LRB-

i

-RRB-

i

fact

-LRB-

-RRB-

-RRB-

-RRB-

-LRB-

i

-RRB-

Outline

of

the

Paper

In

Section

below

we

show

how

one

can

use

preconditions

in

layered

specifications

as

in

Larch

to

protect

against

the

consequences

of

underspecified

mathematical

vocabulary

In

Section

we

define

protection

and

show

how

to

prove

that

a

behavioral

interface

specification

is

protective

In

Section

we

extend

LSL

to

allow

one

to

specify

what

is

intended

to

be

completelydefined

by

a

trait

and

then

use

that

information

to

give

a

second

proof

technique

for

proving

that

a

behavioral

interface

specification

is

protective

In

Section

we

offer

some

discussion

and

we

conclude

with

a

summary

in

Section

Protection

from

the

Underspecified

The

use

of

pre

and

postconditions

in

a

specification

helps

avoid

imposing

unintended

constraints

on

implementations

Since

one

only

cares

about

the

meaning

of

the

postcondition

when

the

precondition

is

true

the

precondition

can

protect

the

mathematical

operators

used

in

the

postcondition

from

areas

of

underspecification

Thus

when

specifying

the

mathematical

operators

one

need

not

be

as

careful

as

Gries

and

Schneider

To

make

these

ideas

concrete

we

consider

the

Larch

family

of

behavioral

interface

specification

languages

-LRB-

BISLs

-RRB-

-LSB-

-RSB-

In

the

Larch

family

one

specifies

implementations

in

two

tiers

by

describing

ffl

mathematical

vocabulary

in

LSL

and

ffl

syntactic

interfaces

-LRB-

names

types

number

of

arguments

etc.

-RRB-

and

behavior

-LRB-

pre

and

postconditions

-RRB-

in

a

BISL

Each

BISL

is

tailored

to

specifying

interface

details

for

some

specific

programming

language

-LRB-

The

interface

aspects

are

of

no

concern

in

this

paper

-RRB-

The

idea

of

protection

in

a

BISL

was

first

formulated

by

Wing

-LSB-

Section

-RSB-

Although

we

generalize

that

notion

here

what

we

seek

is

the

same

as

Wing

's

original

goal

knowing

when

a

behavioral

interface

specification

has

protected

its

users

from

the

incompleteness

of

the

trait

by

ensuring

that

the

meaning

of

the

procedure

specification

is

independent

of

any

incompleteness

in

the

trait

-LRB-

p.

-RRB-

An

example

of

how

this

idea

can

be

used

informally

is

given

in

Figure

which

specifies

an

integer-valued

factorial

procedure

which

is

to

be

implemented

in

C++

The

informal

pre

and

postconditions

follow

requires

and

ensures

respectively

-LRB-

The

keyword

informally

in

Larch/C

-LSB-

-RSB-

signals

the

start

of

an

informal

predicate

-RRB-

In

this

specification

the

precondition

requires

that

the

argument

x

has

a

well-defined

factorial

Since

the

precondition

protects

the

postcondition

in

this

manner

the

-LRB-

implicit

-RRB-

int

factorial

-LRB-

int

x

-RRB-

-LCB-

requires

informally

x

is

nonnegative

and

not

too

big

ensures

informally

result

is

the

factorial

of

x

-RCB-

Figure

An

informal

version

of

the

factorial

example

uses

factTrait

-LRB-

int

for

Int

-RRB-

int

factorial

-LRB-

int

x

-RRB-

-LCB-

requires

x

x

ensures

result

fact

-LRB-

x

-RRB-

-RCB-

Figure

A

formal

version

of

the

factorial

example

underspecification

of

the

factorial

of

x

when

x

is

negative

does

not

matter

-LRB-

The

requirement

that

x

is

not

too

big

allows

an

implementation

of

factorial

to

guarantee

termination

-RRB-

A

formal

version

of

the

factorial

example

also

specified

in

Larch/C

appears

in

Figure

The

uses

clause

says

that

this

specification

is

written

using

mathematical

vocabulary

drawn

from

-LRB-

some

built-in

traits

and

-RRB-

the

trait

factTrait

of

Figure

Since

the

suspect

trait

is

used

does

a

correct

implementation

of

Figure

have

to

satisfy

irrelevant

consequences

of

factTrait

's

theory

such

as

Equation

-LRB-

-RRB-

It

does

not

because

the

precondition

protects

the

use

of

the

trait

's

fact

operator

in

the

postcondition

That

is

the

precondition

specifies

that

the

argument

must

be

positive

If

the

argument

is

not

positive

then

as

usual

the

specification

says

nothing

about

the

result

So

if

the

precondition

is

not

met

the

implementation

is

under

no

obligation

to

meet

the

postcondition

and

hence

need

not

worry

about

the

consequences

of

Equation

-LRB-

-RRB-

More

importantly

if

the

precondition

is

met

then

the

implementation

need

not

worry

about

the

consequences

of

Equation

-LRB-

-RRB-

because

the

argument

will

be

nonnegative

In

programs

one

often

wants

to

raise

-LRB-

throw

-RRB-

an

exception

when

some

boundary

condition

is

violated

One

way

to

write

such

a

specification

is

shown

in

Figure

In

this

figure

the

abstract

values

of

Table

objects

are

taken

from

the

sort

M

in

the

trait

FiniteMap

-LSB-

p.

-RSB-

-LRB-

A

part

of

this

trait

is

shown

in

Figure

-RRB-

Note

that

the

operator

apply

is

underspecified

and

that

defined

is

simply

another

operator

from

the

trait

FiniteMap

The

term

thrown

-LRB-

NoAssociation

-RRB-

theException

in

the

postcondition

means

that

an

exception

is

raised

and

that

the

exception

's

type

is

NoAssociation

and

that

the

exception

result

's

abstract

value

is

theException

In

Figure

there

are

in

essence

two

preconditions

defined

-LRB-

t

k

-RRB-

and

imports

Table

Elem

Key

NoAssociation

Elem

fetch

-LRB-

Table

t

Key

k

-RRB-

throw

-LRB-

NoAssociation

-RRB-

-LCB-

ensures

-LRB-

defined

-LRB-

t

k

-RRB-

-RRB-

result

apply

-LRB-

t

k

-RRB-

-RRB-

-LRB-

defined

-LRB-

t

k

-RRB-

-RRB-

thrown

-LRB-

NoAssociation

-RRB-

theException

-RRB-

-RCB-

Figure

Protective

specification

of

a

C++

member

function

that

fetches

an

element

from

a

table

FiniteMap

-LRB-

M

D

R

-RRB-

trait

introduces

-LCB-

-RCB-

M

update

M

D

R

M

apply

M

D

R

defined

M

D

Bool

asserts

M

generated

by

-LCB-

-RCB-

update

M

partitioned

by

apply

defined

m

M

d

D

r

R

apply

-LRB-

update

-LRB-

m

r

-RRB-

-RRB-

if

then

r

else

apply

-LRB-

m

-RRB-

defined

-LRB-

-LCB-

-RCB-

d

-RRB-

defined

-LRB-

update

-LRB-

m

r

-RRB-

-RRB-

defined

-LRB-

m

-RRB-

implies

converts

apply

defined

exempting

d

D

apply

-LRB-

-LCB-

-RCB-

d

-RRB-

Figure

Part

of

the

FiniteMap

trait

quoted

from

-LSB-

p.

-RSB-

imports

Table

Elem

Key

Elem

fetch

-LRB-

Table

t

Key

k

-RRB-

throw

-LRB-

NoAssociation

-RRB-

-LCB-

requires

defined

-LRB-

t

k

-RRB-

ensures

result

apply

-LRB-

t

k

-RRB-

requires

defined

-LRB-

t

k

-RRB-

ensures

thrown

-LRB-

NoAssociation

-RRB-

theException

-RCB-

Figure

A

sugared

version

of

the

previous

specification

of

fetch

An

implementation

has

to

satisfy

both

pre

and

postcondition

pairs

its

negation

and

the

first

of

these

is

protecting

the

application

of

apply

This

postcondition

is

well-defined

even

though

apply

is

underspecified

because

apply

takes

on

some

-LRB-

arbitrary

-RRB-

value

for

the

empty

table

and

because

LSL

uses

classical

logic

As

an

aside

users

of

a

specification

language

might

still

worry

that

the

postcondition

of

Figure

is

undefined

if

part

of

it

is

This

worry

can

be

alleviated

in

Larch/C

by

a

syntactic

sugar

that

allows

one

to

split

the

specification

up

into

multiple

cases

each

with

its

own

precondition

This

sugar

would

allow

the

specification

in

Figure

to

be

written

as

in

Figure

Such

multiple

pre

and

postconditions

are

similar

to

guarded

commands

-LSB-

-RSB-

and

have

been

used

in

the

specification

languages

Larch/CLU

-LSB-

Section

-RSB-

and

Fresco

-LSB-

-RSB-

Besides

bringing

the

issue

of

protection

to

the

specifier

's

attention

this

notational

convenience

makes

it

easier

to

automatically

check

that

a

specification

is

protective

Without

such

notation

the

specification

of

Figure

could

be

expressed

in

various

logically

equivalent

ways

that

would

make

it

hard

to

see

what

is

being

protected

We

believe

that

during

interface

specification

a

specifier

would

normally

think

about

such

issues

as

whether

the

mathematical

operators

are

welldefined

on

their

arguments

when

writing

the

precondition

of

such

procedure

specifications

This

belief

is

based

on

our

experience

in

writing

behavioral

interface

specifications

and

in

teaching

students

to

write

such

specifications

The

use

of

two

tiers

with

preconditions

for

specifying

implementations

thus

meshes

well

with

the

underspecification

approach

because

the

values

of

mathematical

operators

outside

their

domains

are

not

needed

to

understand

or

implement

such

a

specification

In

the

rest

of

this

paper

we

explore

the

notion

of

protection

with

the

aim

of

improving

intuition

about

protection

and

providing

more

guidance

to

specifiers

To

this

end

we

concentrate

on

formal

specifications

below

Completely-defined

and

Protective

Specifications

In

this

section

we

formally

define

the

notion

of

protection

in

a

BISL

using

the

more

primitive

notion

of

a

completely-defined

term

We

say

that

an

LSL

term

is

completely-defined

if

it

can

be

proved

to

have

the

same

value

in

all

models

of

its

trait

To

state

this

condition

formally

we

use

a

variation

of

an

idea

found

in

the

Larch

Prover

for

proving

that

an

operator

is

converted

-LSB-

pp.

-LCB-

-RSB-

Let

T

be

a

trait

Let

T

be

a

version

of

the

trait

T

with

every

operator

f

in

T

replaced

by

f

except

that

the

following

operators

are

left

alone

ffl

all

operators

in

the

built-in

trait

Boolean

ffl

all

operators

in

all

instances

of

the

built-in

traits

Conditional

-LRB-

which

specifies

if

then

else

-RRB-

and

Equality

-LRB-

which

specifies

the

operators

and

=-RRB-

and

ffl

all

operators

mentioned

in

a

generated

by

clause

For

example

the

trait

has

fact

replaced

by

but

true

and

the

boolean

operators

are

not

primed

and

neither

are

pred

and

succ

because

they

are

mentioned

in

the

generated

by

clause

of

the

trait

Integer

-LSB-

p.

-RSB-

-LRB-

Operators

mentioned

in

a

generated

by

clause

are

meant

to

be

a

canonical

way

to

describe

values

of

a

given

sort

two

ways

to

describe

such

values

can

not

both

be

canonical

-RRB-

Similarly

if

P

is

a

term

in

the

language

of

T

then

let

P

be

a

copy

of

P

with

every

operator

f

that

appears

in

P

replaced

by

f

with

the

same

exceptions

as

above

For

example

if

P

is

result

fact

-LRB-

x

-RRB-

then

P

would

be

result

-LRB-

x

-RRB-

because

fact

is

not

exempted

from

priming

is

exempt

from

priming

and

result

and

x

are

not

operators

In

what

follows

we

write

T

P

to

mean

that

P

is

provable

from

trait

T

Definition

-LRB-

completely-defined

-RRB-

An

LSL

term

P

-LRB-~x-RRB-

with

free

variables

x

of

sorts

U

is

completely-defined

for

trait

T

if

and

only

if

T

-LSB-

T

x

U

P

-LRB-~x-RRB-

P

-LRB-~x-RRB-

Trivial

examples

of

completely-defined

terms

include

variables

because

in

each

trait

T

T

U

x

x

A

more

interesting

example

is

that

for

factTrait

the

term

fact

-LRB-

-RRB-

is

completely-defined

but

both

fact

-LRB-

-RRB-

and

fact

-LRB-

x

-RRB-

where

x

Int

are

not

Just

because

a

term

is

not

completely-defined

does

not

mean

it

is

bad

For

example

the

term

choose

-LRB-

-LSB-

-RRB-

is

not

completely-defined

for

the

trait

ChoiceSet

-LRB-

of

-LSB-

p.

-RSB-

-RRB-

The

following

definition

of

when

a

procedure

specification

is

protective

says

in

essence

that

the

precondition

must

be

completely-defined

for

the

used

trait

and

that

whenever

the

precondition

holds

then

the

postcondition

must

be

completely-defined

for

the

used

trait

Definition

-LRB-

protective

-RRB-

A

procedure

specification

S

that

uses

trait

T

is

protective

if

for

each

pair

of

precondition

Q

-LRB-~x-RRB-

and

postcondition

R

-LRB-~x-RRB-

ffl

T

-LSB-

T

x

U

Q

-LRB-~x-RRB-

-LRB-~x-RRB-

and

ffl

T

-LSB-

T

x

U

Q

-LRB-~x-RRB-

-RRB-

-LRB-

R

-LRB-~x-RRB-

-LRB-~x-RRB-

-RRB-

The

definition

of

a

protective

procedure

specification

suggests

a

direct

proof

technique

For

example

to

prove

that

the

specification

of

factorial

in

Figure

is

protective

one

must

show

that

factTrait

-LSB-

proves

both

of

the

following

ffl

int

-LRB-

x

x

-RRB-

-LRB-

x

x

-RRB-

and

ffl

int

-LRB-

x

x

-RRB-

-RRB-

-LRB-

result

fact

-LRB-

x

-RRB-

-RRB-

-LRB-

result

-LRB-

x

-RRB-

-RRB-

Although

such

proofs

are

straightforward

they

are

quite

tedious

Proving

Protection

in

a

BISL

In

this

section

we

describe

an

easier

way

to

prove

protection

in

a

BISL

This

proof

technique

uses

extra

information

that

specifiers

would

add

to

LSL

traits

This

extra

information

would

also

allow

a

user

of

LSL

to

more

precisely

specify

and

check

what

is

intended

to

be

completely-defined

Specifying

What

is

Not

Underspecified

LSL

already

has

some

provision

for

specifying

what

is

not

underspecified

the

specification

of

when

an

operator

is

converted

This

is

done

by

using

a

converts

clause

as

was

done

in

Figure

A

converts

clause

says

that

the

axioms

of

the

trait

uniquely

define

the

operators

named

in

the

clause

relative

to

the

other

operators

in

the

trait

-LSB-

p.

-RSB-

-LRB-

See

the

appendix

for

a

more

complete

explanation

of

conversion

-RRB-

Unfortunately

proving

that

an

LSL

operator

is

converted

does

not

mean

it

is

completely-defined

it

may

still

be

underspecified

For

example

consider

the

trait

in

Figure

In

this

trait

the

operator

somewhatBigger

is

defined

to

be

equal

to

muchBigger

however

muchBigger

is

quite

underspecified

since

no

assertions

constrain

it

Yet

the

converts

clause

in

the

implies

section

is

still

provable

because

somewhatBigger

is

completely-defined

relative

to

muchBigger

That

is

once

muchBigger

is

determined

somewhatBigger

becomes

completely-defined

Because

of

this

distinction

between

conversion

and

complete

definition

we

propose

adding

another

implication

clause

to

LSL

This

clause

which

we

call

the

exact

clause

has

a

form

similar

to

that

of

the

LSL

exempting

clause

-LRB-

although

it

would

not

be

a

subclause

of

a

converts

clause

-RRB-

The

idea

is

that

it

would

allow

one

to

specify

terms

that

should

be

completelydefined

For

example

the

exact

clause

in

Figure

says

that

terms

of

the

form

fact

-LRB-

k

-RRB-

are

intended

to

be

completely-defined

if

k

The

extra

information

in

the

exact

clause

can

be

used

to

help

debug

an

LSL

specification

by

trying

to

prove

the

following

property

Definition

-LRB-

exact

for

T

-RRB-

Let

T

be

a

trait

that

contains

an

exact

clause

of

the

form

exact

a

A

such

that

Q

-LRB-

a

-RRB-

P

-LRB-

a

-RRB-

where

Q

-LRB-

a

-RRB-

is

a

predicate

and

P

-LRB-

a

-RRB-

is

a

term

in

the

language

of

T

This

clause

is

exact

for

T

if

and

only

if

T

-LSB-

T

a

A

-LRB-

Q

-LRB-

a

-RRB-

-LRB-

a

-RRB-

-RRB-

-RRB-

P

-LRB-

a

-RRB-

P

-LRB-

a

-RRB-

-LRB-

-RRB-

biggerTrait

trait

includes

Integer

introduces

muchBigger

somewhatBigger

Int

Int

asserts

i

Int

somewhatBigger

-LRB-

i

-RRB-

muchBigger

-LRB-

i

-RRB-

implies

converts

somewhatBigger

Int

Int

Figure

An

LSL

trait

in

which

somewhatBigger

is

convertible

but

somewhatBigger

-LRB-

i

-RRB-

is

not

completely-defined

factTrait

trait

includes

Integer

introduces

fact

Int

Int

asserts

i

Int

fact

-LRB-

i

-RRB-

if

i

then

else

i

fact

-LRB-

-RRB-

implies

equations

fact

-LRB-

-RRB-

exact

k

Int

such

that

k

fact

-LRB-

k

-RRB-

Figure

Factorial

example

demonstrating

the

exact

clause

Exact

-LRB-

x

-RRB-

true

if

x

is

a

variable

Exact

-LRB-

P

-LRB-

E

-RRB-

-RRB-

V

E

Exact

-LRB-

Ei

-RRB-

Q

-LRB-

E

-RRB-

if

the

trait

's

implies

section

contains

a

clause

exact

a

A

such

that

Q

-LRB-

a

-RRB-

P

-LRB-

a

-RRB-

Exact

-LRB-

E

-RRB-

Exact

-LRB-

E

-RRB-

Exact

-LRB-

ffi

-RRB-

Exact

-LRB-

-RRB-

Exact

-LRB-

-RRB-

if

ffi

is

or

a

boolean

operator

or

-RRB-

Exact

-LRB-

x

T

E

-RRB-

x

T

Exact

-LRB-

E

-RRB-

Exact

-LRB-

x

T

E

-RRB-

x

T

Exact

-LRB-

E

-RRB-

Exact

-LRB-

if

then

else

-RRB-

Exact

-LRB-

-RRB-

Exact

-LRB-

-RRB-

Exact

-LRB-

-RRB-

Exact

-LRB-

E

-RRB-

false

otherwise

Figure

Definition

of

Exact

For

example

in

Figure

the

exact

clause

is

exact

for

factTrait

if

the

following

condition

is

provable

from

factTrait

-LSB-

Int

-LRB-

k

k

-RRB-

-RRB-

fact

-LRB-

k

-RRB-

-LRB-

k

-RRB-

The

proof

would

proceed

by

induction

on

k.

Exact

Predicates

For

use

in

proving

protection

we

define

predicates

of

the

form

Exact

-LRB-

E

-RRB-

based

on

the

form

-LRB-

text

-RRB-

of

each

expression

E.

-LRB-

These

resemble

the

domain

predicates

Dom

-LRB-

E

-RRB-

described

by

some

authors

-LSB-

-RSB-

However

they

have

a

different

purpose

since

an

operator

such

as

choose

on

nonempty

sets

may

be

underspecified

for

a

reason

other

than

being

partial

-RRB-

The

definition

of

Exact

-LRB-

-RRB-

is

based

on

the

exact

clauses

given

in

the

trait

's

implications

-LRB-

and

those

of

included

traits

-RRB-

This

definition

is

lifted

to

arbitrary

terms

by

requiring

terms

substituted

for

the

variables

in

an

exact

clause

to

be

themselves

exact

and

using

the

structure

of

terms

formed

from

LSL

's

built-in

trait

operators

-LRB-

boolean

operators

equality

and

conditionals

-RRB-

See

Figure

for

the

definition

For

example

for

the

trait

of

Figure

the

following

holds

Exact

-LRB-

fact

-LRB-

i

-RRB-

-RRB-

-LRB-

i

-RRB-

As

another

example

as

no

exact

clause

is

given

in

Figure

Exact

-LRB-

f

-LRB-

i

-RRB-

-RRB-

is

false

even

though

the

term

is

completely-defined

free

variables

of

these

terms

are

not

important

so

they

are

suppressed

Using

Exact

Predicates

to

Prove

Protection

Provided

the

information

given

in

the

exact

clauses

are

exact

for

a

trait

T

then

Exact

predicates

can

be

used

as

a

sufficient

condition

for

determining

when

a

term

is

completely-defined

for

T

Lemma

Let

T

be

a

trait

in

which

each

exact

clause

is

exact

for

T

Let

R

-LRB-~x-RRB-

be

a

term

with

free

variables

x

U

If

T

x

U

Exact

-LRB-

R

-LRB-~x-RRB-

-RRB-

then

R

-LRB-~x-RRB-

is

completely-defined

for

T

Proof

-LRB-

by

induction

on

the

structure

of

terms

-RRB-

Let

R

-LRB-~x-RRB-

be

such

that

T

x

U

Exact

-LRB-

R

-LRB-~x-RRB-

-RRB-

For

the

basis

suppose

R

-LRB-~x-RRB-

is

a

variable

xi

Then

x

U

xi

xi

is

trivially

provable

and

so

xi

is

completely-defined

by

definition

For

the

inductive

step

suppose

that

the

result

holds

for

all

subterms

of

R

-LRB-~x-RRB-

If

R

-LRB-~x-RRB-

is

an

invocation

of

some

operator

of

T

that

is

not

a

boolean

operator

equality

inequality

or

if

then

else

then

by

definition

it

must

be

that

R

-LRB-~x-RRB-

has

the

form

P

-LRB-

E

-LRB-~x-RRB-

-RRB-

and

that

trait

T

has

a

clause

of

the

form

exact

a

A

such

that

Q

-LRB-

a

-RRB-

P

-LRB-

a

-RRB-

Furthermore

by

definition

of

Exact

-LRB-

-RRB-

it

must

be

the

case

that

T

Ei

-LRB-~x-RRB-

E

-LRB-~x-RRB-

Exact

-LRB-

Ei

-LRB-~x-RRB-

-RRB-

Q

-LRB-

E

-LRB-~x-RRB-

-RRB-

-LRB-

-RRB-

Since

T

is

a

primed

copy

of

T

it

must

also

be

the

case

that

T

-LRB-~x-RRB-

-LRB-~x-RRB-

Exact

-LRB-

-LRB-~x-RRB-

-RRB-

-LRB-

-LRB-~x-RRB-

-RRB-

-LRB-

-RRB-

Because

the

x

are

free

in

the

above

two

formulas

by

universal

generalization

T

-LSB-

T

x

U

Q

-LRB-

E

-LRB-~x-RRB-

-RRB-

-LRB-

-LRB-~x-RRB-

-RRB-

-LRB-

-RRB-

By

the

inductive

hypothesis

since

each

Ei

-LRB-~x-RRB-

is

exact

for

each

i

T

-LSB-

T

x

U

Ei

-LRB-~x-RRB-

-LRB-~x-RRB-

-LRB-

-RRB-

Since

the

exact

clauses

are

assumed

to

be

exact

for

T

by

definition

we

have

T

-LSB-

T

a

A

-LRB-

Q

-LRB-

a

-RRB-

-LRB-

a

-RRB-

-RRB-

-RRB-

P

-LRB-

a

-RRB-

P

-LRB-

a

-RRB-

-LRB-

-RRB-

Instantiating

a

to

E

-LRB-~x-RRB-

and

using

Formula

-LRB-

-RRB-

it

follows

that

T

-LSB-

T

x

U

-LRB-

Q

-LRB-

E

-LRB-~x-RRB-

-RRB-

-LRB-

-LRB-~x-RRB-

-RRB-

-RRB-

-RRB-

P

-LRB-

E

-LRB-~x-RRB-

-RRB-

P

-LRB-

-LRB-~x-RRB-

-RRB-

-LRB-

-RRB-

But

by

-LRB-

-RRB-

the

hypothesis

of

this

implication

is

provable

so

T

-LSB-

T

x

U

P

-LRB-

E

-LRB-~x-RRB-

-RRB-

P

-LRB-

-LRB-~x-RRB-

-RRB-

follows

The

other

cases

follow

directly

from

the

inductive

hypothesis

and

the

definition

of

Exact

-LRB-

-RRB-

However

the

converse

to

the

above

lemma

does

not

hold

One

reason

is

that

the

specifier

of

the

used

trait

may

not

note

when

some

terms

are

exact

But

even

if

the

information

given

is

complete

the

definition

of

Exact

does

bufferTrait

trait

includes

Integer

introduces

bufSize

Int

asserts

equations

bufSize

bufSize

Figure

A

trait

with

an

underspecified

constant

not

take

into

account

other

knowledge

from

the

theory

of

the

trait

For

example

consider

the

trait

bufferTrait

which

is

specified

in

Figure

It

specifies

the

constant

bufSize

but

bufSize

is

underspecified

-LRB-

hence

no

exact

clause

is

given

-RRB-

The

term

bufSize

is

completely-defined

for

bufferTrait

However

Exact

-LRB-

bufSize

-RRB-

false

because

Exact

-LRB-

bufSize

-RRB-

is

false

Definition

-LRB-

exact

procedure

specification

-RRB-

A

procedure

specification

S

that

uses

trait

T

is

exact

if

for

each

pair

of

precondition

Q

-LRB-~x-RRB-

and

postcondition

R

-LRB-~x-RRB-

ffl

T

x

U

Exact

-LRB-

Q

-LRB-~x-RRB-

-RRB-

and

ffl

T

x

U

Q

-LRB-~x-RRB-

-RRB-

Exact

-LRB-

R

-LRB-~x-RRB-

-RRB-

Our

suggested

technique

for

proving

that

a

procedure

specification

is

protective

therefore

is

to

prove

that

it

is

exact

Corollary

Let

T

be

a

trait

in

which

each

exact

clause

is

exact

for

T

Let

S

be

a

procedure

specification

that

uses

trait

T

If

S

is

exact

then

S

is

protective

Proof

Let

Q

-LRB-~x-RRB-

be

the

precondition

of

S

and

let

R

-LRB-~x-RRB-

be

its

postcondition

Suppose

S

is

exact

Then

by

definition

T

x

U

Exact

-LRB-

Q

-LRB-~x-RRB-

-RRB-

So

by

Lemma

Q

-LRB-~x-RRB-

is

completely-defined

for

T

Also

by

definition

T

x

U

Q

-LRB-~x-RRB-

-RRB-

Exact

-LRB-

R

-LRB-~x-RRB-

-RRB-

Suppose

for

each

x

Q

-LRB-~x-RRB-

holds

Then

for

each

x

Exact

-LRB-

R

-LRB-~x-RRB-

-RRB-

holds

and

so

by

Lemma

R

-LRB-~x-RRB-

is

completely-defined

for

T

As

an

example

of

the

use

of

the

above

corollary

we

show

how

to

prove

that

the

specification

of

factorial

in

Figure

is

completely-defined

with

respect

to

the

trait

in

Figure

To

do

this

we

prove

that

the

specification

is

exact

with

respect

to

the

trait

in

Figure

First

the

precondition

is

void

-LRB-

int

x

-RRB-

-LCB-

modifies

x

ensures

true

-RCB-

Figure

The

Larch/C

specification

of

a

procedure

that

is

protective

even

exact

but

not

deterministic

exact

because

Exact

-LRB-

x

-RRB-

is

true

-LRB-

Exact

-LRB-

-RRB-

is

true

because

is

a

generator

We

assume

the

trait

Integer

has

been

extended

with

implications

that

say

that

is

exact

-RRB-

Then

for

the

postcondition

one

can

calculate

as

follows

for

all

x

int

x

-RRB-

Exact

-LRB-

result

fact

-LRB-

x

-RRB-

-RRB-

-LCB-

by

definition

of

Exact

-RCB-

x

-RRB-

-LRB-

Exact

-LRB-

result

-RRB-

Exact

-LRB-

fact

-LRB-

x

-RRB-

-RRB-

-LCB-

by

definition

of

Exact

for

fact

treating

result

as

a

variable

-RCB-

x

-RRB-

-LRB-

true

true

true

x

-RRB-

-LCB-

by

predicate

calculus

-RCB-

true

However

if

a

procedure

specification

is

protective

it

is

not

necessarily

exact

For

example

a

specification

that

uses

the

term

bufSize

as

its

precondition

could

be

protective

without

being

exact

Thus

exactness

is

a

sufficient

but

not

necessary

condition

for

protection

As

another

example

consider

the

specifications

of

the

fetch

procedure

in

Figures

and

Suppose

the

following

exact

clause

were

added

to

the

trait

FiniteMap

in

Figure

exact

m

M

d

:D

such

that

defined

-LRB-

m

d

-RRB-

apply

-LRB-

m

d

-RRB-

Then

the

specification

of

Figure

is

protective

but

not

exact

for

this

augmented

FiniteMap

trait

However

the

specification

of

Figure

is

exact

Discussion

One

might

wonder

whether

a

procedure

specification

is

protective

if

and

only

if

it

is

deterministic

However

the

two

notions

are

orthogonal

For

example

the

specification

given

in

Figure

is

protective

-LRB-

even

exact

-RRB-

but

very

nondeterministic

It

specifies

a

C++

procedure

that

can

change

the

value

of

the

object

x

-LRB-

passed

by

reference

-RRB-

to

any

integer

Figure

is

an

example

of

a

specification

that

is

not

protective

because

the

precondition

is

not

completely-defined

but

the

procedure

specified

must

be

deterministic

when

its

precondition

is

met

One

might

think

that

if

one

could

avoid

incompleteness

at

the

trait

level

then

one

would

not

need

the

underspecification

approach

at

all

The

uses

bufferTrait

int

foo

-LRB-

int

x

-RRB-

-LCB-

requires

bufSize

x

ensures

result

-RCB-

Figure

A

specification

that

is

deterministic

but

not

protective

problem

is

how

to

complete

an

LSL

specification

in

a

general

way

-LRB-

i.e.

one

for

which

some

sensible

logic

exists

-RRB-

One

might

imagine

using

an

initial

-LRB-

or

final

-RRB-

semantics

for

LSL

traits

since

such

a

semantics

is

a

general

way

to

complete

equational

specifications

However

such

initial

-LRB-

or

final

-RRB-

algebras

do

not

exist

in

general

for

specifications

in

LSL

-LSB-

Section

-RSB-

because

LSL

traits

can

contain

generated

by

clauses

which

act

as

hierarchy

conditions

-LRB-

For

example

an

initial

algebra

for

factTrait

in

Figure

would

contain

nonstandard

integers

such

as

fact

-LRB-

-RRB-

which

are

prohibited

by

the

generated

by

clause

in

the

LSL

Integer

trait

-RRB-

Although

for

LSL

and

other

specification

languages

with

powerful

hierarchy

constructs

such

a

completion

of

the

specification

is

impossible

in

general

some

specification

languages

do

have

general

ways

to

complete

specifications

-LRB-

e.g.

VDM-SL

-LSB-

-RSB-

and

COLD

-LSB-

-RSB-

-RRB-

Such

completions

usually

take

advantage

of

the

fact

that

besides

proper

values

each

type

in

a

programming

language

can

be

thought

of

as

having

at

least

one

improper

value

-LRB-

-RRB-

which

is

used

to

model

computations

of

that

type

that

go

into

infinite

loops

or

cause

errors

However

to

avoid

overspecification

-LRB-

i.e.

not

allowing

a

specified

procedure

to

terminate

normally

with

a

proper

value

-RRB-

such

languages

tend

to

have

either

a

complex

semantics

for

procedure

specifications

or

a

specialized

logic

One

might

think

that

in

a

specification

language

such

as

VDM-SL

-LSB-

-RSB-

or

COLD

-LSB-

-RSB-

in

which

the

specification

logic

does

not

use

the

underspecification

approach

the

concept

of

protection

is

not

useful

But

even

in

such

a

language

one

could

use

the

precondition

to

protect

the

postcondition

from

non-classical

or

non-compositional

features

of

the

logic

or

from

the

more

subtle

notions

in

the

logic

Since

such

specifications

would

be

less

dependent

on

the

logical

details

we

believe

that

they

would

be

clearer

In

PVS

-LSB-

-RSB-

the

logic

uses

total

functions

but

each

function

has

a

domain

that

is

precisely

defined

using

a

predicate

Our

use

of

exact

clauses

is

similar

but

allows

one

to

say

what

terms

are

intended

to

be

completelydefined

not

just

what

the

domain

of

an

operator

is

In

PVS

an

attempt

to

apply

a

mathematical

operator

outside

its

domain

would

be

a

type

error

If

PVS

were

used

as

the

mathematical

basis

for

a

BISL

then

one

would

be

forced

to

write

protective

specifications

in

order

to

prevent

type

errors

in

post-conditions

For

Z

-LSB-

-RSB-

it

seems

that

the

draft

standard

has

adopted

the

underspecification

approach

-LSB-

-RSB-

To

apply

our

ideas

to

Z

then

one

would

define

BISLs

that

use

Z

instead

of

LSL

as

the

mathematical

tier

and

then

the

notion

of

Level

Facts

Trait

exact

-RRB-

completely-defined

Lemma

completely-defined

convertible

Figure

BISL

exact

-RRB-

protective

Corollary

protective

deterministic

Figures

and

Table

Summary

of

concepts

discussed

in

this

paper

protection

would

be

used

in

the

BISLs

Protection

is

also

a

useful

concept

when

coupled

with

executable

specifications

In

a

language

like

Eiffel

-LSB-

-RSB-

having

a

precondition

be

flagged

as

false

helps

debugging

more

than

having

an

error

occur

in

the

body

of

a

procedure

or

an

executable

postcondition

Summary

In

this

paper

we

have

shown

that

the

Larch

approach

to

behavioral

interface

specification

has

significant

advantages

in

avoiding

potential

problems

caused

by

underspecification

Using

separate

tiers

for

the

specification

of

mathematical

operators

and

procedure

implementations

allows

procedure

specifications

to

protect

implementations

from

dependence

on

underspecified

mathematical

operators

Thus

the

Larch

approach

mitigates

the

problems

Jones

warned

about

-LSB-

-RSB-

Our

technical

results

are

summarized

in

Table

The

main

concept

is

when

a

BISL

procedure

specification

is

protective

in

the

sense

that

it

does

not

force

implementations

to

satisfy

unintended

consequences

of

an

LSL

trait

We

have

given

two

proof

techniques

for

proving

protection

one

of

which

is

equivalent

to

the

definition

-LRB-

based

on

the

notion

of

completelydefined

terms

-RRB-

and

a

sufficient

-LRB-

but

not

necessary

-RRB-

test

based

on

the

notion

of

exact

terms

that

is

easier

to

apply

The

concept

of

an

exact

term

is

based

on

an

extension

to

LSL

that

allows

one

to

specify

which

terms

are

not

intended

to

be

underspecified

This

extension

to

LSL

provides

better

documentation

and

allows

enhanced

debugging

-LRB-

in

the

sense

of

-LSB-

-RSB-

-LSB-

Chapter

-RSB-

-RRB-

of

LSL

specifications

Although

for

concreteness

these

ideas

have

been

presented

in

the

context

of

Larch

they

could

be

adapted

to

other

formal

specification

languages

that

use

underspecification

Acknowledgments

Thanks

to

Adrian

Fiech

Clyde

Ruby

Krishna

Kishore

Dhara

and

Matt

Markland

for

comments

and

discussions

of

earlier

drafts

Thanks

to

Daniel

Jackson

for

discussions

about

partial

functions

in

Z

and

to

Daniel

and

Jim

Woodcock

for

letting

us

look

at

their

e-mail

exchange

on

that

topic

This

manuscript

is

submitted

for

publication

with

the

understanding

that

the

U.S.

Government

is

authorized

to

reproduce

and

distribute

reprints

for

Governmental

purposes

notwithstanding

any

copyright

notation

thereon

References

-LSB-

-RSB-

H.

Barringer

J.

H.

Cheng

and

C.

B.

Jones

A

logic

covering

undefinedness

in

program

proofs

Acta

Informatica

-LRB-

-RRB-

-LCB-

October

-LSB-

-RSB-

Andrzej

Blikle

The

clean

termination

of

iterative

programs

Acta

Informatica

-LCB-

-LSB-

-RSB-

D.

Coleman

and

J.

W.

Hughes

The

clean

termination

of

Pascal

programs

Acta

Informatica

-LCB-

-LSB-

-RSB-

E.

W.

Dijkstra

Guarded

commands

nondeterminancy

and

formal

derivation

of

programs

Communications

of

the

ACM

-LRB-

-RRB-

-LCB-

August

-LSB-

-RSB-

L.

M.

G.

Feijs

and

H.

B.

M.

Jonkers

Formal

Specification

and

Design

volume

of

Cambridge

Tracts

in

Theoretical

Computer

Science

Cambridge

University

Press

Cambridge

UK

-LSB-

-RSB-

Stephen

J.

Garland

John

V.

Guttag

and

James

J.

Horning

Debugging

Larch

Shared

Language

specifications

IEEE

Transactions

on

Software

Engineering

-LRB-

-RRB-

-LCB-

September

-LSB-

-RSB-

Steven

M.

German

Automating

proofs

of

the

absence

of

common

runtime

errors

In

Conference

record

of

the

Fifth

Annual

ACM

Symposium

on

Principles

of

Programming

Languages

pages

-LCB-

ACM

January

-LSB-

-RSB-

David

Gries

and

Fred

B.

Schneider

A

Logical

Approach

to

Discrete

Math

Texts

and

Monographs

in

Computer

Science

Springer-Verlag

New

York

N.Y.

-LSB-

-RSB-

David

Gries

and

Fred

B.

Schneider

Avoiding

the

undefined

by

underspecification

In

Jan

van

Leeuwen

editor

Computer

Science

Today

Recent

Trends

and

Developments

number

in

Lecture

Notes

in

Computer

Science

pages

-LCB-

Springer-Verlag

New

York

N.Y.

-LSB-

-RSB-

John

V.

Guttag

James

J.

Horning

S.J.

Garland

K.D.

Jones

A.

Modet

and

J.M.

Wing

Larch

Languages

and

Tools

for

Formal

Specification

Springer-Verlag

New

York

N.Y.

-LSB-

-RSB-

John

V.

Guttag

James

J.

Horning

and

Andr?es

Modet

Report

on

the

Larch

Shared

Language

Version

Technical

Report

Digital

Equipment

Corporation

Systems

Research

Center

Lytton

Avenue

Palo

Alto

CA

April

Order

from

src-report@src.dec.com

-LSB-

-RSB-

John

V.

Guttag

James

J.

Horning

and

Jeannette

M.

Wing

The

Larch

family

of

specification

languages

IEEE

Software

-LRB-

-RRB-

September

-LSB-

-RSB-

C.B.

Jones

Partial

functions

and

logics

A

warning

Information

Processing

Letters

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

Cliff

B.

Jones

Systematic

Software

Development

Using

VDM

International

Series

in

Computer

Science

Prentice

Hall

Englewood

Cliffs

N.J.

second

edition

-LSB-

-RSB-

Gary

T.

Leavens

Larch/C

Reference

Manual

Version

In

ftp

or

on

the

world

wide

web

at

the

URL

December

-LSB-

-RSB-

Barbara

Liskov

and

John

Guttag

Abstraction

and

Specification

in

Program

Development

The

MIT

Press

Cambridge

Mass.

-LSB-

-RSB-

Bertrand

Meyer

Object-oriented

Software

Construction

Prentice

Hall

New

York

N.Y.

-LSB-

-RSB-

Sam

Owre

John

Rushby

Natarajan

Shankar

and

Friedrich

von

Henke

Formal

verification

for

fault-tolerant

architectures

Prolegomena

to

the

design

of

PVS

IEEE

Transactions

on

Software

Engineering

-LRB-

-RRB-

-LCB-

February

-LSB-

-RSB-

J.

M.

Spivey

Understanding

Z

a

Specification

Language

and

its

Formal

Semantics

Cambridge

University

Press

New

York

N.Y.

-LSB-

-RSB-

Alan

Wills

Capsules

and

types

in

Fresco

Program

validation

in

Smalltalk

In

P.

America

editor

ECOOP

European

Conference

on

Object

Oriented

Programming

volume

of

Lecture

Notes

in

Computer

Science

pages

-LCB-

Springer-Verlag

New

York

N.Y.

-LSB-

-RSB-

Alan

Wills

Refinement

in

Fresco

In

Kevin

Lano

and

Howard

Houghton

editors

Object-Oriented

Specification

Case

Studies

chapter

pages

-LCB-

Prentice-Hall

Englewood

Cliffs

NJ

-LSB-

-RSB-

Alan

Wills

Specification

in

Fresco

In

Susan

Stepney

Rosalind

Barden

and

David

Cooper

editors

Object

Orientation

in

Z

Workshops

in

Computing

chapter

pages

-LCB-

Springer-Verlag

Cambridge

UK

-LSB-

-RSB-

Jeannette

M.

Wing

Writing

Larch

interface

language

specifications

ACM

Transactions

on

Programming

Languages

and

Systems

-LRB-

-RRB-

-LCB-

January

-LSB-

-RSB-

Jeannette

Marie

Wing

A

two-tiered

approach

to

specifying

programs

Technical

Report

Massachusetts

Institute

of

Technology

Laboratory

for

Computer

Science

-LSB-

-RSB-

Martin

Wirsing

Algebraic

specification

In

J.

van

Leewen

editor

Handbook

of

Theoretical

Computer

Science

volume

B

Formal

Models

and

Semantics

chapter

pages

-LCB-

The

MIT

Press

New

York

N.Y.

-LSB-

-RSB-

Jim

Woodcock

and

Daniel

Jackson

About

the

semantics

of

partial

functions

in

Z.

Personal

communication

April

A

Appendix

Conversion

and

an

Extension

to

LSL

This

appendix

explains

the

notion

of

conversion

in

LSL

and

also

presents

an

extension

to

LSL

that

makes

the

specification

of

conversion

more

expressive

A.

Conversion

In

a

LSL

trait

one

can

state

redundant

properties

-LRB-

theorems

-RRB-

that

one

believes

do

-LRB-

or

should

-RRB-

hold

These

redundant

properties

are

stated

in

the

implies

section

of

the

specification

Proofs

of

such

properties

can

be

attempted

and

are

a

way

of

debugging

the

trait

-LSB-

-RSB-

-LSB-

Chapter

-RSB-

For

our

purposes

the

most

interesting

kind

of

redundant

property

one

can

state

in

the

implies

section

is

that

an

operator

is

well-defined

with

respect

to

other

operators

This

is

done

by

using

a

converts

clause

as

was

done

in

Figure

A

converts

clause

says

that

the

axioms

of

the

trait

uniquely

define

the

operators

named

in

the

clause

relative

to

the

other

operators

in

the

trait

-LSB-

p.

-RSB-

To

prove

this

one

must

show

it

for

all

possible

arguments

The

Larch

Prover

-LRB-

LP

-RRB-

uses

the

following

proof

technique

-LSB-

pp.

-LCB-

-RSB-

Let

T

-LRB-

f

-RRB-

be

a

trait

which

names

operators

f

in

converts

clauses

in

its

implies

section

Let

T

-LRB-

f

-RRB-

be

a

version

of

the

trait

T

-LRB-

f

-RRB-

in

which

each

of

the

operators

fi

named

in

a

converts

clause

is

replaced

by

f

i

Then

one

proves

for

each

such

fi

A

B

Th

-LRB-

T

-LRB-

f

-RRB-

-LSB-

T

-LRB-

f

-RRB-

-RRB-

a

A

fi

-LRB-

a

-RRB-

f

i

-LRB-

a

-RRB-

-LRB-

-RRB-

The

proof

would

show

that

there

can

not

be

two

different

interpretations

of

the

operator

fi

For

example

to

prove

the

converts

clause

for

f

in

Figure

one

axiomatizes

an

operator

f

in

the

same

way

as

f

and

then

proves

the

following

i

Int

f

-LRB-

i

-RRB-

f

-LRB-

i

-RRB-

-LRB-

This

is

proved

by

using

the

rule

given

by

the

generated

by

clause

in

Figure

-RRB-

Often

one

wants

to

prove

that

an

operator

is

converted

except

for

some

arguments

For

example

one

would

want

to

prove

that

the

head

operator

on

lists

is

converted

except

that

head

-LRB-

empty

-RRB-

which

is

purposely

left

underspecified

To

do

this

one

uses

a

converts

clause

of

the

following

form

in

LSL

converts

head

List

-LSB-

T

-RSB-

T

exempting

head

-LRB-

empty

-RRB-

The

exempting

clause

allows

the

specifier

to

state

what

terms

are

intentionally

underspecified

In

terms

of

the

proof

that

head

is

converted

except

where

it

is

not

intentionally

underspecified

the

exempting

clause

allows

one

to

use

the

following

equation

head

-LRB-

empty

-RRB-

head

-LRB-

empty

-RRB-

in

the

proof

that

for

all

lists

l

head

-LRB-

l

-RRB-

head

-LRB-

l

-RRB-

factTrait

trait

includes

Integer

introduces

fact

Int

Int

asserts

i

Int

fact

-LRB-

i

-RRB-

if

i

then

else

i

fact

-LRB-

-RRB-

implies

i

Int

fact

-LRB-

-RRB-

converts

fact

Int

Int

exempting

k

Int

such

that

k

fact

-LRB-

k

-RRB-

Figure

A

trait

demonstrating

the

extended

exempting

clause

A.

An

extension

to

LSL

The

exempting

clause

in

the

current

LSL

-LSB-

Chapter

-RSB-

-LSB-

-RSB-

does

not

have

enough

expressive

power

to

state

in

general

what

is

left

underspecified

One

can

only

exempt

a

class

of

terms

that

are

described

by

constants

or

universally

quantified

variables

For

example

one

can

not

specify

that

fact

in

Figure

is

intentionally

underspecified

by

adding

an

exempting

clause

because

the

current

LSL

only

allows

one

to

specify

that

constants

or

all

integers

are

exempted

That

is

there

is

no

way

to

say

that

only

the

negative

integers

are

exempted

We

propose

extending

LSL

by

allowing

domain

predicates

for

the

variable

declarations

in

an

exempting

clause

For

example

we

would

allow

the

exempting

clause

of

the

trait

given

in

Figure

This

form

of

the

exempting

clause

allows

one

to

specify

the

intended

exemptions

with

an

arbitrary

-LRB-

boolean-valued

-RRB-

LSL

term

The

extension

to

the

LP

proof

technique

for

proving

the

converts

clause

in

Figure

is

simple

The

exempting

clause

gives

one

the

following

formula

k

Int

-LRB-

k

-RRB-

-RRB-

fact

-LRB-

k

-RRB-

fact

-LRB-

k

-RRB-

which

one

can

use

in

the

proof

that

for

all

integers

i

fact

-LRB-

i

-RRB-

fact

-LRB-

i

-RRB-

Given

that

fact

is

axiomatized

with

a

copy

of

the

axioms

for

fact

this

allows

one

to

prove

that

fact

is

converted

where

it

is

not

intentionally

underspecified

This

extension

to

LSL

increases

its

expressive

power

by

its

ability

to

state

redundant

and

checkable

information

is

logical

problem

if

the

predicate

following

such

that

uses

an

operator

being

specified

as

converted

The

simplest

thing

to

do

is

not

to

allow

the

use

of

such

operators

in

the

domain

predicate

-LRB-

following

such

that

-RRB-

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B I O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

larch
protective specifications
specification languages
underspecification