On

the

Frame

Problem

in

Procedure

Alex

Borgida

Rutgers

University

John

Mylopoulos

University

of

Toronto

Raymond

Reiter

University

of

Toronto

and

the

Canadian

Institute

for

Advanced

Research

Abstract

We

give

examples

of

situations

where

formal

specifications

of

procedures

in

the

standard

pre/postcondition

style

become

lengthy

cumbersome

and

difficult

to

change

a

problem

which

is

particularly

acute

in

the

case

of

object-oriented

specifications

with

inheritance

We

identify

the

problem

as

the

inability

to

express

that

a

procedure

changes

only

those

things

it

has

to

leaving

everything

else

unmodified

and

review

some

attempts

at

dealing

with

this

frame

problem

in

the

Software

Specification

community

The

second

part

of

the

paper

adapts

a

recent

proposal

for

a

solution

to

the

frame

problem

in

Artificial

Intelligence

the

notion

of

explanation

closure

axioms

to

provide

an

approach

whereby

one

can

state

such

conditions

succinctly

and

modularly

with

the

added

advantage

of

having

the

specifier

be

reminded

of

things

that

she

may

have

omitted

saying

in

procedure

specifications

Since

this

approach

is

based

on

standard

Predicate

Logic

its

semantics

is

relatively

straight-forward

The

paper

also

suggests

an

algorithm

which

generates

syntactically

the

explanation

closure

axioms

from

the

pre/postcondition

specifications

provided

they

are

written

in

a

restricted

language

and

suggests

a

model

theory

supporting

it

This

paper

is

a

modified

and

extended

version

of

the

paper

titled

And

Nothing

Else

Changes

The

Frame

Problem

in

Procedure

Specifications

presented

by

the

authors

at

the

Fifteenth

International

Conference

on

Software

Engineering

Baltimore

May

This

research

was

supported

by

grants

from

the

National

Science

and

Engineering

Research

Council

of

Canada

and

the

Institute

for

Robotics

and

Intelligent

Systems

-LRB-

IRIS

-RRB-

funded

by

the

Government

of

Canada

through

the

Networks

of

Centres

of

Excellence

programme

Author

's

full

address

Department

of

Computer

Science

Rutgers

University

New

Brunswick

NJ

USA

Author

's

full

address

Department

of

Computer

Science

University

of

Toronto

King

's

College

Road

Toronto

Ontario

Canada

Introduction

The

arguments

for

preparing

first

a

formal

specification

of

a

program

before

implementing

it

in

some

programming

language

are

by

now

well

known

and

widely

accepted

Program

specifications

present

what

the

desired

program

is

supposed

to

do

rather

than

how

it

is

going

to

accomplish

it

using

some

suitable

notation

which

we

shall

call

a

formal

specification

language

-LRB-

or

just

specification

language

-RRB-

The

adequacy

of

such

language

is

determined

by

general

criteria

such

as

expressiveness

but

also

by

notational

suitability

i.e.

the

degree

to

which

a

specification

language

makes

it

possible

for

the

specifier

to

express

the

intent

of

a

procedure

in

a

precise

yet

simple

concise

understandable

modular

and

easily

modifiable

way

capacity

to

support

formal

treatment

i.e.

the

extent

to

which

a

formal

specification

language

provides

a

foundation

and

lends

support

to

a

methodology

for

formally

proving

properties

about

the

program

and

its

development

The

first

criterion

focuses

on

human

engineering

concerns

in

contrast

to

its

expressiveness

The

importance

of

such

concerns

is

supported

by

much

of

the

research

on

formal

specification

languages

After

all

one

could

state

everything

that

is

needed

for

a

formal

specification

using

the

notations

of

a

sufficiently

rich

set

theory

or

predicate

logic

and

if

it

was

only

an

issue

of

expressive

power

there

would

be

no

need

for

VDM

Z

Larch

etc.

nor

for

notions

such

as

object-orientation

The

second

criterion

measures

the

degree

to

which

formality

leads

to

a

methodology

preferably

supported

by

tools

for

proving

properties

about

specifications

One

familiar

kind

of

proof

involving

specifications

is

to

show

that

some

implementation

meets

it

Another

kind

of

proof

obligation

which

arises

in

the

use

of

model-based

specification

techniques

such

as

VDM

and

Z

requires

the

specifier

to

show

that

each

procedure

maintains

the

global

program-state

invariants

that

are

part

of

the

specification

-LRB-

e.g.

see

-LSB-

Cohen

-RSB-

-RRB-

State

invariants

-LRB-

for

example

Only

students

who

have

paid

their

registration

fees

can

appear

on

a

class

list

-RRB-

are

also

known

as

integrity

constraints

in

the

world

of

databases

Such

constraints

are

usually

stated

as

part

of

the

database

definition

independently

of

procedures

that

access

or

update

the

database

because

the

database

persists

between

runs

of

procedures

and

because

system

evolution

often

requires

new

procedures

to

be

added

If

a

procedure

p

is

specified

in

terms

of

a

pair

of

assertions

-LRB-

pre-p

post-p

-RRB-

referring

to

the

conditions

required

to

hold

before

the

invocation

of

p

and

those

required

to

hold

once

p

terminates

and

if

I

is

an

invariance

assertion

-LRB-

involving

a

single

program

state

-RRB-

then

this

proof

obligation

usually

has

the

form

Ibefore

pre-p

post-p

fi

Iafter

where

Ibefore

evaluates

the

invariant

I

with

respect

to

the

program

state

before

execution

of

procedure

p

-LRB-

the

state

in

which

pre-p

is

evaluated

-RRB-

and

Iafter

with

respect

to

the

state

in

which

post-p

is

evaluated

We

'll

have

the

opportunity

to

discuss

these

proof

obligations

in

a

more

formal

setting

later

in

the

paper

The

first

aim

of

this

paper

is

to

make

the

reader

aware

of

a

family

of

problems

which

arise

in

formal

specifications

using

the

pre/postcondition

notation

and

which

is

related

to

a

long-standing

problem

in

the

field

of

Artificial

Intelligence

-LRB-

hereafter

AI

-RRB-

called

the

frame

problem

-LSB-

-RSB-

We

present

examples

illustrating

this

problem

which

becomes

a

serious

impediment

for

large

object-oriented

specifications

where

inheritance

plays

a

central

role

The

examples

are

intended

to

demonstrate

that

failure

to

deal

with

the

frame

problem

compromises

a

formal

specification

language

with

respect

to

its

notational

suitability

and

its

capacity

to

support

a

methodology

for

formally

proving

properties

of

specifications

The

rest

of

the

paper

discusses

some

ways

in

which

existing

specification

languages

endeavor

to

cope

with

the

problem

and

then

presents

a

novel

approach

based

on

recent

work

intended

to

solve

the

frame

problem

in

planning

applications

within

AI

The

Frame

Problem

Theme

and

Variations

Since

the

claims

in

the

sequel

apply

equally

well

to

any

specification

language

based

on

pre/postcondition

assertions

we

have

used

the

more

neutral

notation

of

-LRB-

First

Order

-RRB-

Predicate

Logic

to

express

our

examples

However

in

order

to

establish

this

claim

of

generality

we

will

repeatedly

also

show

specifications

in

the

notation

of

one

of

the

more

familiar

specification

languages

such

as

VDM

or

Z.

The

Frame

Problem

Consider

part

of

the

specification

of

a

simple

procedure

enrolInCourse

which

records

the

enrollment

of

a

student

st

in

a

course

crs

enrolInCourse

-LRB-

st

crs

-RRB-

PRE

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

POST

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

Here

size

and

classLimit

are

functions

while

EnrolledIn

is

a

To

refer

to

the

values

of

the

variables

immediately

before

and

after

the

execution

of

the

procedure

we

adopt

the

usual

unprimed/primed

notation

The

above

specification

then

declares

as

precondition

to

enrolling

in

a

course

the

availability

of

places

-LRB-

i.e.

that

the

number

of

students

already

enrolled

in

the

course

is

less

than

the

class

limit

-RRB-

and

that

the

particular

student

st

has

n't

already

enrolled

in

the

particular

course

The

postcondition

on

the

other

hand

specifies

the

effect

of

the

procedure

on

the

final

state

including

incrementing

the

size

and

changing

the

EnrolledIn

predicate

so

that

it

is

true

for

st

crs

Unfortunately

the

specification

of

enrolInCourse

is

subject

to

at

least

two

readings

Moreover

the

more

intuitive

reading

is

the

harder

one

to

formulate

in

Predicate

Logic

To

see

the

problem

consider

two

implementations

of

this

specification

The

first

results

in

exactly

two

changes

to

a

program

state

as

required

by

the

postcondition

The

second

makes

these

changes

but

also

changes

some

other

predicate

such

as

CourseCompleted

or

EnrolledIn

at

some

other

argument

The

more

intuitive

tighter

reading

of

the

specification

is

inconsistent

with

the

second

implementation

because

that

implementation

does

more

than

what

is

necessary

to

make

the

postcondition

true

In

other

words

the

intuitive

reading

includes

a

clause

of

the

form

and

nothing

else

changes

to

circumscribe

the

modifications

effected

by

a

procedure

The

second

looser

reading

of

the

specification

does

not

include

the

nothing

else

changes

clause

and

is

consistent

with

both

implementations

mentioned

earlier

This

reading

is

less

intuitive

in

that

it

merely

places

a

lower

bound

on

the

effects

of

the

procedure

that

has

been

specified

On

the

other

hand

this

reading

has

two

advantages

It

is

less

restrictive

thus

offering

greater

implementation

freedom

a

desirable

property

of

specifications

And

it

affords

a

simple

formalization

in

Predicate

Logic

first

view

states

as

models

for

formulae

involving

unprimed

predicates

and

functions

the

variables

that

the

program

will

update

the

eventual

implementation

must

then

establish

a

state

where

the

postcondition

formula

evaluates

to

true

with

primed

predicates

evaluated

in

the

final

state

and

unprimed

ones

in

the

initial

state

Second

note

that

the

priming

of

predicates

allows

us

to

put

together

the

theories

of

the

initial

state

and

final

state

into

a

single

theory

for

the

entire

pre/post-condition

formula

Note

that

the

relationship

between

predicates

R

and

R

is

entirely

through

convention

-LRB-

and

through

the

postcondition

-RRB-

they

may

as

well

be

called

by

completely

different

names

In

particular

any

proof

obligation

of

the

form

mentioned

in

the

introduction

which

involves

a

program

state

invariant

I

and

a

procedure

p

with

pre/postconditions

pre-p

-LRB-

x

-RRB-

post-p

-LRB-

x

-RRB-

has

to

be

stated

as

In

general

function

symbols

used

in

formulas

will

begin

with

a

lower

case

letter

and

predicate

symbols

with

upper

case

ones

while

class

names

will

be

fully

in

capital

letters

Preconditions

are

assumed

to

define

partial

functions

so

that

if

somehow

the

procedure

is

invoked

with

the

precondition

false

it

will

not

terminate

Normally

additional

specifications

would

be

conjoined

to

this

one

to

specify

exception

handling

x

-LSB-

I

pre-p

-LRB-

x

-RRB-

post-p

-LRB-

x

-RRB-

fi

primed

-LRB-

I

-RRB-

-RSB-

where

primed

-LRB-

I

-RRB-

represents

the

invariant

I

with

all

its

predicates

and

functions

primed

Now

suppose

that

we

have

some

simple

state

invariant

y.Q

-LRB-

y

-RRB-

where

Q

is

a

predicate

then

the

proof

obligation

amounts

to

demonstrating

the

following

formula

st

crs

-LSB-

x.Q

-LRB-

x

-RRB-

-LRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

-RRB-

-LRB-

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

-RRB-

fi

x.Q

-LRB-

x

-RRB-

-RSB-

This

can

not

be

proven

because

the

postcondition

of

the

procedure

says

nothing

about

the

predicate

Q

Therefore

such

proof

obligations

can

not

be

achieved

using

the

looser

reading

of

the

specification

unless

the

specifier

takes

the

trouble

to

mention

explicitly

in

her

specification

not

just

the

things

that

are

changed

by

the

procedure

but

also

all

those

that

are

not

Thus

if

the

specifier

wants

to

state

that

nothing

else

changes

she

has

to

state

so

explicitly

in

the

specification

by

adding

a

clause

of

the

form

x

-LSB-

-LRB-

P

-LRB-

x

-RRB-

fi

P

-LRB-

x

-RRB-

-RRB-

-LRB-

P

-LRB-

x

-RRB-

fi

P

-LRB-

x

-RRB-

-RRB-

-RSB-

or

equivalently

x

-LSB-

P

-LRB-

x

-RRB-

P

-LRB-

x

-RRB-

-RSB-

for

every

predicate

P

other

than

EnrolledIn

-LRB-

such

as

Q

-RRB-

and

a

clause

of

the

form

x

-LSB-

f

-LRB-

x

-RRB-

f

-LRB-

x

-RRB-

-RSB-

for

every

function

f

other

than

size

In

addition

there

have

to

be

clauses

that

state

that

EnrolledIn

and

size

remain

unchanged

for

all

arguments

other

than

st

crs

x

-LSB-

x

crs

fi

size

-LRB-

x

-RRB-

size

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

x

st

y

crs

fi

-LRB-

EnrolledIn

-LRB-

x

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RRB-

-RSB-

Assuming

that

program

states

are

described

by

only

two

functions

size

and

classLimit

and

two

predicates

EnrolledIn

and

Q

a

complete

specification

of

enrolInCourse

which

states

explicitly

that

nothing

else

changes

is

as

follows

enrolInCourse

-LRB-

st

crs

-RRB-

PRE

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

POST

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

x

-LSB-

x

crs

fi

size

-LRB-

x

-RRB-

size

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

x

st

y

crs

fi

-LRB-

EnrolledIn

-LRB-

x

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RRB-

-RSB-

x

-LSB-

classLimit

-LRB-

x

-RRB-

classLimit

-LRB-

x

-RRB-

-RSB-

x

-LSB-

Q

-LRB-

x

-RRB-

Q

-LRB-

x

-RRB-

-RSB-

The

extra

clauses

that

were

needed

to

state

explicitly

that

nothing

else

changes

have

been

called

frame

axioms

-LSB-

-RSB-

while

the

general

problem

of

stating

succinctly

the

nothing

else

changes

clause

is

precisely

the

frame

problem

We

hope

that

the

reader

already

agrees

that

requiring

the

specifier

to

provide

the

frame

axioms

makes

specification

a

lengthier

less

perspicuous

and

more

error-prone

process

Failure

to

deal

with

the

frame

axioms

on

the

other

hand

limits

the

extent

to

which

formal

properties

of

specifications

can

be

proven

In

the

rest

of

this

section

we

focus

on

the

ways

such

problems

have

been

treated

in

existing

specification

languages

and

on

presenting

three

special

kinds

of

specifications

for

which

these

solutions

-LRB-

as

well

as

the

standard

FOPC

approach

-RRB-

appear

to

be

inadequate

Stating

Frame

Axioms

in

Specification

Languages

In

practice

specification

languages

are

enhanced

to

allow

the

specifier

to

state

explicitly

but

more

conveniently

what

elements

of

a

program

state

remain

unchanged

To

see

such

features

in

action

we

consider

several

widely

known

specification

languages

such

as

Z

-LSB-

-RSB-

and

VDM

-LSB-

-RSB-

These

are

based

on

the

notation

of

mathematics

and

set

theory

where

the

functions

and

predicates

of

our

predicate-calculus

notation

are

naturally

converted

to

functions

and

relations

which

are

often

viewed

as

sets

of

tuples

In

such

a

case

the

predicate

assertion

EnrolledIn

-LRB-

st

crs

-RRB-

translates

naturally

to

-LRB-

st

crs

-RRB-

enrolledIn

The

notation

of

set-theory

is

then

normally

used

to

express

some

part

of

the

frame

axioms

by

stating

enrolledIn

enrolledIn

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

and

size

size

-LCB-

crs

fi

size

-LRB-

crs

-RRB-

-RCB-

These

statements

have

the

effect

of

asserting

that

EnrolledIn

and

size

do

not

change

at

arguments

other

than

st

and

crs

We

are

then

left

only

with

the

task

of

stating

that

enroling

in

a

course

does

not

modify

the

classLimit

or

other

predicates

such

as

Q.

For

this

task

Z

provides

the

X

predicate

constructor

which

allows

one

to

take

a

named

list

of

variables

N

-LRB-

xk

-RRB-

and

produce

the

assertion

XN

def

x

xk

xk

By

naming

the

list

of

remaining

variables

Rest

-LRB-

classLimit

Q

-RRB-

we

can

then

express

the

desired

meaning

of

enrol

as

the

Z

enrolInCourse

st

STUDENT

crs

COURSE

X

Rest

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

-LRB-

st

crs

-RRB-

enrolledIn

enrolledIn

enrolledIn

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

size

size

-LCB-

crs

fi

size

-LRB-

crs

-RRB-

-RCB-

This

approach

works

well

if

we

can

modularize

the

presentation

to

give

names

to

appropriate

subsets

of

variables

such

as

Rest

above

Many

other

specification

languages

such

as

Larch

-LSB-

-RSB-

and

VDM

-LSB-

-RSB-

take

a

second

approach

whereby

a

procedure

specifier

is

required

to

identify

the

variables

that

it

might

modify

with

the

implicit

assertion

that

any

variable

not

so

declared

remains

unchanged

-LRB-

This

implicit

assertion

must

then

be

expanded

by

some

automatic

background

tool

or

used

by

special-purpose

theorem

provers

-RRB-

Specifically

in

VDM

the

specification

of

enrol

would

indicate

that

it

needs

access

only

to

external

variables

size

classLimit

and

enrolledIn

with

the

second

one

being

a

read

only

so

that

it

might

modify

at

Both

here

and

elsewhere

we

have

chosen

to

use

a

sometimes

more

self-explanatory

syntax

in

order

to

avoid

frequent

detours

into

notation

For

example

according

to

proper

Z

style

the

input

parameters

should

be

named

st

and

crs

and

we

should

also

have

included

statements

of

the

form

D

enrolledIn

in

order

to

introduce

the

symbols

enrolledIn

and

enrolledIn

most

size

and

enrolledIn

-LRB-

For

variety

in

this

case

we

will

model

class

enrolments

as

a

function

from

students

to

sets

of

courses

Also

we

will

take

the

liberty

of

continuing

to

use

theconvention

of

priming

the

variables

in

the

post-state

although

languages

such

as

VDM

and

COLD

use

different

syntactic

conventions

-RRB-

ENROL-IN-COURSE

-LRB-

st

STUDENT

crs

COURSE

-RRB-

ext

wr

size

CourseToInt

rd

classLimit

CourseToInt

wr

enrolledIn

Student

fi

Course-set

pre

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

crs

enrolledIn

-LRB-

st

-RRB-

post

enrolledIn

enrolledIn

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

size

size

-LCB-

crs

fi

size

-LRB-

crs

-RRB-

-RCB-

The

specification

language

COLD

-LSB-

-RSB-

has

an

even

more

refined

way

of

stating

so-called

modification

rights

by

using

complex

expressions

that

delimit

the

subset

of

the

state

space

over

which

the

operation

can

act

differently

than

the

identity

mapping

For

example

in

the

COLD

specification

below

the

line

MOD

indicates

that

only

the

enrolment

of

the

specific

student

st

and

the

size

of

the

specific

course

crs

may

change

PROC

enrolInCourse

STUDENT

COURSE

fi

IN

st

crs

PRE

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

-LRB-

crs

-RRB-

enrolledIn

-LRB-

st

-RRB-

MOD

enrolledIn

-LRB-

st

-RRB-

size

-LRB-

crs

-RRB-

POST

enrolledIn

-LRB-

st

-RRB-

enrolledIn

-LRB-

st

-RRB-

-LCB-

crs

-RCB-

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

Larch

-LSB-

-RSB-

provides

a

modifies

at

most

clause

with

similar

capabilities

Clearly

these

techniques

work

quite

well

in

this

simple

case

However

we

present

next

a

series

of

examples

that

do

not

fare

as

well

Conditional

Specifications

Suppose

we

now

want

to

redefine

enrolInCourse

so

that

if

there

is

no

room

left

in

the

course

but

the

student

is

in

her

fourth

year

of

school

her

request

is

added

to

a

waiting

list

otherwise

the

student

is

sent

a

notice

rejecting

her

request

Moreover

assume

that

waitSize

and

rejectSize

are

functions

counting

respectively

the

number

of

enrollment

attempts

on

a

waiting

list

or

rejected

Returning

to

our

Predicate

Calculus

notation

we

might

be

inclined

to

state

the

new

postcondition

of

enrolInCourse

as

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

fi

-LRB-

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

Year

-LRB-

st

-RRB-

fi

-LRB-

waitSize

-LRB-

crs

-RRB-

waitSize

-LRB-

crs

-RRB-

Waiting

-LRB-

st

crs

-RRB-

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

Year

-LRB-

st

-RRB-

fi

-LRB-

rejectSize

-LRB-

crs

-RRB-

rejectSize

-LRB-

crs

-RRB-

Rejected

-LRB-

st

crs

-RRB-

-RRB-

But

once

again

we

run

into

the

frame

problem

we

forgot

to

state

for

each

branch

of

the

conditional

what

portions

of

the

program

state

remain

unchanged

We

must

therefore

write

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

fi

-LRB-

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

-RRB-

-LRB-

x

-LSB-

x

crs

fi

size

-LRB-

x

-RRB-

size

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

x

st

y

crs

fi

-LRB-

EnrolledIn

-LRB-

x

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RRB-

-RSB-

x

-LSB-

waitSize

-LRB-

x

-RRB-

waitSize

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

Waiting

-LRB-

x

y

-RRB-

Waiting

-LRB-

x

y

-RRB-

-RSB-

x

-LSB-

rejectSize

-LRB-

x

-RRB-

rejectSize

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

Rejected

-LRB-

x

y

-RRB-

Rejected

-LRB-

x

y

-RRB-

-RSB-

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

Year

-LRB-

st

-RRB-

fi

-LRB-

waitSize

-LRB-

crs

-RRB-

waitSize

-LRB-

crs

-RRB-

Waiting

-LRB-

st

crs

-RRB-

-RRB-

-LRB-

x

-LSB-

x

crs

fi

waitSize

-LRB-

x

-RRB-

waitSize

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

x

st

y

crs

fi

-LRB-

Waiting

-LRB-

x

y

-RRB-

Waiting

-LRB-

x

y

-RRB-

-RRB-

-RSB-

x

-LSB-

size

-LRB-

x

-RRB-

size

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

EnrolledIn

-LRB-

x

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RSB-

x

-LSB-

rejectSize

-LRB-

x

-RRB-

rejectSize

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

Rejected

-LRB-

x

y

-RRB-

Rejected

-LRB-

x

y

-RRB-

-RSB-

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

Year

-LRB-

st

-RRB-

fi

-LRB-

rejectSize

-LRB-

crs

-RRB-

rejectSize

-LRB-

crs

-RRB-

Rejected

-LRB-

st

crs

-RRB-

-RRB-

-LRB-

x

-LSB-

x

crs

fi

rejectSize

-LRB-

x

-RRB-

rejectSize

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

x

st

y

crs

fi

-LRB-

Rejected

-LRB-

x

y

-RRB-

Rejected

-LRB-

x

y

-RRB-

-RRB-

-RSB-

x

-LSB-

size

-LRB-

x

-RRB-

size

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

EnrolledIn

-LRB-

x

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RSB-

x

-LSB-

waitSize

-LRB-

x

-RRB-

waitSize

-LRB-

x

-RRB-

-RSB-

x

y

-LSB-

Waiting

-LRB-

x

y

-RRB-

Waiting

-LRB-

x

y

-RRB-

-RSB-

-RRB-

To

complete

this

postcondition

we

must

also

add

frame

axioms

for

functions

and

predicates

that

are

not

affected

in

any

of

the

cases

by

the

procedure

-LRB-

the

function

classLimit

for

example

-RRB-

Specification

of

the

frame

axioms

here

is

even

more

cumbersome

partly

because

each

case

requires

a

different

set

of

such

axioms

Even

in

Z

VDM

or

COLD

we

would

need

to

say

at

the

beginning

that

rejected

rejectSize

waiting

waitSize

size

and

enrolledIn

all

might

be

modified

and

then

state

for

each

branch

what

does/doesn

t

change

as

in

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

fi

-LSB-

enrolledIn

enrolledIn

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

size

size

-LCB-

crs

fi

size

-LRB-

crs

-RRB-

-RCB-

waitSize

waitSize

waiting

waiting

rejectSize

rejectSize

rejected

rejected

-RSB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

year

-LRB-

st

-RRB-

fi

-LSB-

waiting

waiting

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

waitSize

waitSize

-LCB-

crs

fi

waitSize

-LRB-

crs

-RRB-

-RCB-

size

size

enrolledIn

enrolledIn

rejectSize

rejectSize

rejected

rejected

-RSB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

year

-LRB-

st

-RRB-

fi

-LSB-

rejected

rejected

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

rejectSize

rejectSize

-LCB-

crs

fi

waitSize

-LRB-

crs

-RRB-

-RCB-

size

size

enrolledIn

enrolledIn

waitSize

waitSize

waiting

waiting

-RSB-

The

problem

here

is

that

we

have

to

state

ahead

of

time

the

list

of

things

that

might

change

in

the

procedure

and

this

forces

us

to

state

explicitly

for

any

branch

of

the

conditional

the

things

that

do

not

change

Conjoining

Specifications

Consider

now

a

procedure

switchCourse

which

involves

dropping

one

course

and

enrolling

in

another

Suppose

that

the

system

being

specified

already

includes

the

specification

of

procedures

enrolInCourse

and

dropCourse

and

we

are

now

asked

to

specify

a

procedure

switchCourse

It

is

natural

and

in

fact

desirable

from

the

point

of

view

of

reuse

and

propagation

of

changes

to

try

to

define

switchCourse

by

making

use

of

the

other

two

specifications

In

Z

this

is

accomplished

simply

by

using

the

schema

composition

notation

-LSB-

-RSB-

switchCourse

-LRB-

st

-RRB-

def

dropCourse

-LRB-

st

-RRB-

enrolInCourse

-LRB-

st

-RRB-

where

is

a

binary

operation

on

specifications

which

conjoins

its

operands

-LRB-

in

our

case

conjoining

their

pre

and

-RRB-

Unfortunately

such

an

operation

leads

to

meaningless

specifications

if

the

two

conjoined

procedures

include

their

respective

frame

axioms

For

example

assume

that

dropCourse

is

defined

as

follows

dropCourse

st

STUDENT

crs

COURSE

X

Rest

-LRB-

st

crs

-RRB-

enrolledIn

enrolledIn

enrolledIn

-LCB-

-LRB-

st

crs

-RRB-

-RCB-

size

size

-LCB-

crs

fi

size

-LRB-

crs

-RRB-

-RCB-

Then

clearly

the

conjunction

of

the

postconditions

of

enrolInCourse

and

dropCourse

is

inconsistent

since

it

includes

among

other

clauses

enrolledIn

enrolledIn

-LCB-

-LRB-

st

-RRB-

-RCB-

enrolledIn

enrolledIn

-LCB-

-LRB-

st

-RRB-

-RCB-

Note

that

exactly

the

same

situation

occurs

in

VDM

and

even

COLD

the

conjunction

of

the

postconditions

will

have

the

form

POST

enrolledIn

-LRB-

st

-RRB-

enrolledIn

-LRB-

st

-RRB-

-LCB-

-RCB-

size

-LRB-

-RRB-

size

-LRB-

-RRB-

enrolledIn

-LRB-

st

-RRB-

enrolledIn

-LRB-

st

-RRB-

-LCB-

-RCB-

size

-LRB-

-RRB-

size

-LRB-

-RRB-

which

is

inconsistent

for

enrolledIn

-LRB-

st

-RRB-

The

problem

in

this

case

is

caused

by

the

use

of

settheoretic

notation

to

state

part

of

the

frame

axiom

This

example

suggests

that

the

nothing

else

changes

clause

should

read

more

precisely

nothing

else

changes

unless

otherwise

stated

Note

that

if

we

had

It

has

been

suggested

to

us

-LRB-

James

Power

personal

communication

-RRB-

that

Z

's

facility

for

hiding

identifiers

might

be

used

to

abbreviate

the

above

to

some

extent

if

XV

is

a

schema

asserting

that

all

variables

remain

unchanged

then

to

each

case

of

the

conditional

one

can

conjoin

XV

with

the

variables

modified

in

that

case

being

hidden

Note

that

such

a

conjoin

operation

makes

no

assumptions

on

the

order

in

which

the

two

conjoined

procedures

will

be

carried

out

it

only

ensures

that

the

effect

of

both

is

carried

out

been

able

to

describe

enrolInCourse

and

dropCourse

with

post-conditions

of

the

form

crs

enrolledIn

-LRB-

st

-RRB-

and

crs

enrolledIn

-LRB-

st

-RRB-

then

the

final

conjunction

would

have

had

the

consistent

form

enrolledIn

-LRB-

st

-RRB-

enrolledIn

-LRB-

st

-RRB-

However

this

requires

different

frame

axioms

for

EnrolledIn

in

the

context

of

enrolInCourse

dropCourse

and

switchCourse

If

frame

axioms

are

treated

as

textual

elements

of

a

procedure

specification

language

facilities

such

as

the

schema

conjunction

operation

may

be

rendered

problematic

or

at

best

ineffective

Inheritance

and

Object-Oriented

Specifications

The

above

problems

could

be

shrugged

off

as

mere

annoyances

Unfortunately

they

lie

at

the

heart

of

object-oriented

specifications

which

appear

to

be

of

increasing

interest

-LRB-

see

for

example

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

and

the

collections

-LSB-

-RSB-

-LSB-

-RSB-

-RRB-

Two

distinguishing

features

of

object-oriented

programming

languages

-LRB-

OOPLs

for

short

-RRB-

are

taken

to

be

-LRB-

i

-RRB-

the

presence

of

class

hierarchies

with

inheritance

where

what

is

stated

in

a

class

need

not

be

repeated

for

its

subclasses

-LRB-

ii

-RRB-

the

selection

of

procedure

versions

-LRB-

methods

in

OOPL

jargon

-RRB-

to

execute

based

on

the

type

of

the

arguments

It

is

exactly

these

features

that

distinguish

object-oriented

languages

such

as

Eiffel

-LSB-

-RSB-

or

Taxis

-LSB-

-RSB-

from

those

that

merely

support

data

encapsulation

such

as

ADA

or

CLU

The

arguments

for

the

benefits

of

inheritance

presented

for

OOPLs

also

apply

to

object-oriented

specification

languages

-LRB-

e.g.

-LSB-

-RSB-

-RRB-

and

include

abbreviating

specifications

propagating

changes

and

encouraging

reuse

As

argued

among

others

in

-LSB-

-RSB-

an

important

and

desirable

property

of

subclasses

with

inheritance

is

the

ability

to

specialize

the

specification

of

superclasses

For

example

if

the

class

EDUCATOR

has

attribute

degrees

which

is

required

to

be

a

subset

of

the

enumeration

-LCB-

BA

BS

Ms

Phd

-RCB-

then

it

is

desirable

to

allow

the

type

of

degree

to

be

specialized

to

-LCB-

PhD

-RCB-

for

the

subclass

PROFESSOR

of

EDUCATOR

The

same

principle

is

applicable

to

the

specialization

of

methods

-LSB-

-RSB-

For

example

if

a

class

of

equations

has

a

method

solve

that

finds

roots

within

an

error

bound

of

say

then

some

subclass

-LRB-

for

which

a

special

technique

might

be

found

or

which

is

particularly

important

-RRB-

should

be

able

to

offer

the

same

method

but

with

a

tighter

error

bound

of

say

As

it

turns

out

inheritance

is

accomplished

in

almost

all

object-oriented

specification

languages

by

simply

conjoining

the

specification

of

the

superclass

-LRB-

es

-RRB-

to

the

additional

assertions

associated

with

the

subclass

For

example

-LSB-

Alencar

-RSB-

shows

how

in

OOZE

one

can

obtain

the

class

from

the

simple

conjunction

of

two

parent

classes

and

However

as

we

have

seen

in

Section

conjunction

of

specifications

will

run

into

serious

trouble

unless

we

take

the

loosest

possible

way

of

stating

post-conditions

In

particular

in

any

specification

language

supporting

bulk

data-types

such

as

sets

relations

records

etc.

if

a

procedure

P

specifies

a

change

to

a

variables

of

such

a

type

then

no

specialization

of

P

can

ever

modify

any

other

aspect

of

s

if

some

part

of

the

frame

assertion

appears

explicitly

in

the

post-condition

of

P.

For

example

if

P

calls

for

the

removal

from

set

s

of

all

values

satisfying

some

predicate

Y

then

no

specialization

of

P

may

strengthen

this

to

some

stronger

predicate

F

which

removes

additional

elements

from

s.

Or

if

s

records

some

property

of

individuals

such

as

salary

or

size

then

changing

s

-LRB-

a

-RRB-

for

one

object

prevents

s

-LRB-

b

-RRB-

from

being

modified

for

any

other

object

b

in

a

specialization

Such

limitations

are

particularly

bothersome

in

objectcentered

information

systems

that

rely

on

data

bases

-LRB-

e.g.

-LSB-

-RSB-

-RRB-

where

data

about

individuals

is

globally

visible

-LRB-

encapsulation

is

not

the

issue

here

-RRB-

and

is

recorded

by

making

attributes

be

binary

relations/functions

to

sets

which

are

bulk

data

types

of

the

kinds

subject

to

the

above

mentioned

restrictions

We

illustrate

this

problem

with

several

further

examples

Consider

a

university

where

students

in

courses

are

eventually

assigned

-LRB-

absolute

-RRB-

numeric

grades

from

to

and

we

want

to

associate

with

every

course

a

list

of

honors

students

in

it

Using

a

composite

of

notations

we

could

model

this

as

the

class

The

very

specific

framing

statements

of

COLD

and

Larch

can

actually

deal

with

this

problem

class

COURSE

enrolment

Set

of

STUDENT

grade

STUDENT

fi

honors

Set

of

STUDENT

initially

empty

methods

findHonors

-LRB-

-RRB-

PRE

domain

grade

enrolment

MOD

honors

POST

honors

-LCB-

s

enrolment

grade

-LRB-

s

-RRB-

-RCB-

Suppose

now

that

for

senior

courses

among

others

we

wish

to

lower

the

requirement

for

honors

to

since

grades

are

presumably

harder

to

get

The

obvious

specification

of

this

would

be

something

like

class

SENIOR-COURSE

subclass

of

COURSE

methods

findHonors

-LRB-

-RRB-

POST

honors

-LCB-

s

enrolment

grade

-LRB-

s

-RRB-

-RCB-

This

would

result

in

the

specification

of

SENIOR-COURSE

findHonors

-LRB-

-RRB-

having

post-condition

honors

s

grade

-LRB-

s

-RRB-

-RCB-

honors

s

grade

-LRB-

s

-RRB-

-RCB-

which

at

best

would

imply

that

there

are

no

students

with

grades

between

and

Notice

that

the

specialization

we

have

in

mind

is

conceptually

consistent

the

students

assigned

honors

in

the

original

courses

would

still

get

them

but

additional

ones

would

also

do

so

-LRB-

This

is

in

contrast

with

non-strict

inheritance

as

practiced

in

Smalltalk

say

where

the

specialized

procedure

may

do

anything

even

contradictory

to

its

more

general

version

-RRB-

The

problem

here

lies

in

the

frame

assertion

implicit

in

the

settheoretic

notation

the

MOD

clause

already

restricts

as

carefully

as

possible

the

state

variables

that

will

change

but

had

we

stated

the

post-conditions

in

the

form

x/enrolment

grades

-LRB-

x

-RRB-

fi

x

honors

the

loose

reading

would

not

prevent

honors

from

containing

all

students

for

example

As

another

example

consider

the

class

COURSE-WITH-COREQ

a

subclass

of

COURSE

where

we

wish

to

maintain

a

list

of

courses

which

need

to

be

taken

at

the

same

time

as

this

course

In

this

case

the

drop

method

must

be

refined

for

COURSE-WITH-COREQ

to

remove

the

student

who

is

droping

this

course

from

the

enrolments

of

all

corequisites

Here

are

partial

specifications

of

the

two

classes

using

the

notation

of

Predicate

Calculus

in

this

case

together

with

some

of

the

explicit

frame

axioms

class

COURSE

HasEnrolled

COURSE

x

STUDENT

methods

drop

-LRB-

self

COURSE

st

STUDENT

-RRB-

PRE

HasEnrolled

-LRB-

self

st

-RRB-

POST

HasEnrolled

-LRB-

self

st

-RRB-

x/STUDENT

y/COURSE

-LSB-

x

st

y

self

fi

In

this

case

unlike

standard

object-oriented

specifications

we

introduce

the

variable

self

explicitly

rather

than

having

for

each

method

a

privileged

but

unnamed

first

argument

-LRB-

HasEnrolled

-LRB-

y

x

-RRB-

HasEnrolled

-LRB-

y

x

-RRB-

-RRB-

-RSB-

class

COURSE-WITH-COREQ

subclass

of

COURSE

Coreqs

COURSE-WITH-COREQ

x

COURSE

drop

-LRB-

self

COURSE

st

STUDENT

-RRB-

POST

x/COURSE

Coreq

-LRB-

self

x

-RRB-

fi

HasEnrolled

-LRB-

x

st

-RRB-

-RSB-

-LRB-

other

frame

axioms

-RRB-

By

inheritance

the

full

specification

of

COURSE-WITH-COREQ

drop

is

obtained

by

conjoining

the

assertions

stated

on

COURSE

drop

with

the

additional

material

associated

with

drop

in

COURSE

WITH-COREQ

However

this

is

clearly

inconsistent

because

COURSE

drop

states

that

HasEnrolled

only

changes

at

one

argument

while

COURSE-WITH-COREQ

drop

calls

for

additional

changes

whenever

there

are

corequisites

It

is

important

to

note

that

it

is

our

intention

that

in

any

system

implementation

generated

from

this

specification

an

object

could

be

made

an

instance

of

the

class

COURSE

without

necessarily

being

an

instance

of

COURSE-WITH-COREQ

Therefore

we

can

not

leave

out

the

frame

axioms

from

the

definition

of

COURSE

drop

or

if

we

do

so

we

need

to

rename

COURSE

to

COURSE

a

dummy

class

introduced

strictly

for

technical

reasons

and

make

COURSE

its

subclass

with

the

frame

assertion

added

to

drop

We

find

the

latter

alternative

less

acceptable

from

the

point

of

view

of

notational

convenience

and

naturalness

As

a

final

example

suppose

we

track

among

others

the

addresses

of

employees

and

wish

to

provide

a

method

move

for

changing

the

address

of

an

employee

class

EMPLOYEE

livesAt

EMPLOYEE

fi

ADDRESS

EMPLOYEE.move

-LRB-

self

EMPLOYEE

new

ADDRESS

-RRB-

MOD

livesAt

POST

livesAt

-LRB-

self

-RRB-

new

y.

-LRB-

y?self

fi

livesAt

-LRB-

y

-RRB-

livesAt

-LRB-

y

-RRB-

-RRB-

-LRB-

other

frame

axioms

-RRB-

Now

for

the

subclass

of

married

employees

we

need

to

change

move

so

that

the

spouse

's

address

is

also

changed

move

POST

livesAt

-LRB-

spouse

-LRB-

self

-RRB-

-RRB-

new

y.

-LRB-

y?self

y?spouse

-LRB-

self

-RRB-

-RRB-

fi

livesAt

-LRB-

y

-RRB-

livesAt

-LRB-

y

-RRB-

-LRB-

other

frame

axioms

-RRB-

Only

a

very

refined

modifies

at

most

facility

has

a

hope

of

dealing

with

this

situation

if

EMPLOYEE

move

has

MOD

livestAt

-LRB-

self

-RRB-

while

MARRIED-EMPLOYEE

move

has

MOD

livesAt

-LRB-

spouse

-LRB-

self

-RRB-

-RRB-

Conclusions

from

the

Examples

The

necessity

of

stating

explicitly

that

some

parts

of

a

program

state

remain

unchanged

has

been

shown

to

make

specifications

longer

more

difficult

to

comprehend

and

change

more

error

prone

-LRB-

what

if

the

specifier

overlooks

some

frame

axioms

-RRB-

and

presents

an

obstacle

to

aspects

of

inheritance

and

hence

object-orientation

In

fact

without

extending

the

language

features

object-oriented

formal

specifications

seem

possible

only

if

one

assumes

that

local

variables

of

a

class

are

not

visible

to

its

subclasses

and

procedure

specifications

can

not

be

refined

in

subclasses

a

restriction

not

shared

by

popular

objectoriented

programming

languages

such

as

C++

Smalltalk

and

Eiffel

Even

if

one

were

prepared

to

accept

the

above

there

is

an

additional

cost

that

arises

from

the

fact

that

for

a

specification

involving

n

procedures

and

m

functions

and

predicates

describing

program

states

there

are

going

to

be

in

general

O

-LRB-

m

n

-RRB-

frame

axioms

These

can

make

proofs

of

consistency

of

a

specification

prohibitively

expensive

thereby

removing

a

major

argument

in

favor

of

formal

program

specifications

A

Novel

Approach

to

the

Frame

Problem

in

Procedure

Specifications

We

propose

a

new

approach

to

the

frame

problem

in

procedure

specifications

inspired

by

work

reported

in

-LSB-

-RSB-

on

the

frame

problem

in

AI

planning

Foundations

of

the

Approach

In

short

our

proposed

approach

adds

a

second

component

to

the

specification

process

in

addition

to

specifying

post-conditions

we

also

look

for

a

set

of

assertions

that

explain

the

circumstances

under

which

each

predicate

or

function

might

change

value

from

one

program

state

to

the

next

There

are

several

ways

in

which

this

can

be

achieved

and

for

present

purposes

we

have

chosen

a

moderately

complex

approach

which

could

in

fact

be

used

to

reason

more

generally

about

procedures

The

approach

reifies

procedures

by

adding

actions

as

a

new

sort

in

the

specification

language

with

all

the

procedure

names

being

function

symbols

of

this

sort

and

taking

as

arguments

the

formal

parameters

of

the

procedure

For

example

the

procedure

enrolInCourse

would

be

formally

named

by

the

two-place

function

symbol

enrolInCourse

so

that

enrolling

Ann

into

would

be

represented

by

the

term

enrolInCourse

-LRB-

ann

-RRB-

To

talk

about

actions

we

also

introduce

the

single

variable

a

and

the

predicate

Occur

-LRB-

-RRB-

which

takes

an

action

argument

The

intended

interpretation

of

Occur

-LRB-

-RRB-

is

that

the

procedure

which

is

its

argument

executed

successfully

For

every

procedure

p

-LRB-

x

-RRB-

with

specification

-LRB-

pre-p

-LRB-

x

-RRB-

post-p

-LRB-

x

-RRB-

-RRB-

we

generate

first

a

socalled

effect

axiom

x

-LSB-

Occur

-LRB-

p

-LRB-

x

-RRB-

-RRB-

fi

pre-p

-LRB-

x

-RRB-

post-p

-LRB-

x

-RRB-

-RSB-

describing

the

effect

of

the

procedure

i.e.

if

the

procedure

was

executed

-LRB-

and

this

is

often

an

external

decision

like

choosing

to

enroll

in

a

course

-RRB-

this

axiom

assures

us

of

some

necessary

conditions

that

must

have

held

For

example

the

effect

axiom

for

the

initial

specification

of

enrolInCourse

would

be

x

y

-LSB-

Occur

-LRB-

enrolInCourse

-LRB-

x

y

-RRB-

-RRB-

fi

-LRB-

size

-LRB-

y

-RRB-

classLimit

-LRB-

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RRB-

-LRB-

size

-LRB-

y

-RRB-

size

-LRB-

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RRB-

-RSB-

Note

that

this

omits

frame

axioms

these

will

be

specified

separately

and

from

a

different

perspective

through

explanation

closure

axioms

-LRB-

called

change

axioms

for

short

-RRB-

For

every

predicate

R

the

specifier

must

write

two

such

axioms

describing

under

what

circumstances

R

might

change

truth

value

-LRB-

from

positive

to

negative

or

negative

to

positive

-RRB-

the

circumstances

include

the

actions

that

took

place

their

parameters

the

values

where

R

changed

as

a

result

and

complex

conditions

involving

both

a

y

-LSB-

R

-LRB-

y

-RRB-

R

-LRB-

y

-RRB-

Occur

-LRB-

a

-RRB-

fi

-LRB-

a

-LRB-

-RRB-

YR

-LRB-

-RRB-

-RRB-

-LRB-

a

-LRB-

-RRB-

YR

-LRB-

-RRB-

-RRB-

We

leave

to

a

different

paper

the

matter

of

termination

and

the

possibility

of

several

actions

occuring

at

the

same

time

a

y

-LSB-

R

-LRB-

y

-RRB-

R

-LRB-

y

-RRB-

Occur

-LRB-

a

-RRB-

fi

-LRB-

a

-LRB-

-RRB-

YR

-LRB-

-RRB-

-RRB-

-LRB-

a

-LRB-

-RRB-

YR

-LRB-

-RRB-

-RRB-

Here

pi

qi

are

action

symbols

and

YR

pi

-LRB-

resp

YR

qi

-RRB-

describes

the

circumstances

under

which

p

i

-LRB-

resp

qi

-RRB-

can

be

executed

to

change

R

and

wj

is

a

vector

of

values

chosen

from

among

the

constants

and

variables

in

y

and

zj

For

functions

a

single

change

axiom

is

sufficient

a

y

-LSB-

f

-LRB-

y

-RRB-

f

-LRB-

y

-RRB-

Occur

-LRB-

a

-RRB-

fi

-LRB-

a

-LRB-

-RRB-

Yf

-LRB-

-RRB-

-RRB-

-LRB-

a

-LRB-

-RRB-

Yf

-LRB-

-RRB-

-RRB-

These

axioms

offer

a

state-oriented

rather

than

a

procedure-oriented

perspective

to

the

frame

problem

Thus

instead

of

asking

the

specifier

to

assert

what

each

procedure

does

not

change

we

ask

her

to

declare

what

procedures

could

have

effected

a

change

to

a

particular

element

of

the

program

state

As

an

example

of

change

axioms

consider

the

predicate

EnrolledIn

and

suppose

that

the

only

procedure

affecting

it

is

the

procedure

enrolInCourse

though

there

may

be

many

other

procedures

around

such

as

assignRoom

assignTeacher

etc.

The

change

axioms

then

are

a

s

c

-LRB-

EnrolledIn

-LRB-

s

c

-RRB-

EnrolledIn

-LRB-

s

c

-RRB-

Occur

-LRB-

a

-RRB-

-RRB-

fi

false

indicating

that

no

procedure

removes

students

from

courses

and

a

st

crs

-LRB-

EnrolledIn

-LRB-

st

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

Occur

-LRB-

a

-RRB-

-RRB-

fi

-LRB-

a

enrolInCourse

-LRB-

st

crs

-RRB-

-RRB-

-RSB-

indicating

that

only

enrolInCourse

can

add

a

student

to

the

course

Likewise

the

change

axiom

for

the

function

size

is

a

crs

-LSB-

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

Occur

-LRB-

a

-RRB-

-RSB-

fi

st

a

enrolInCourse

-LRB-

st

crs

-RRB-

Observe

how

elegantly

these

axioms

capture

the

fact

that

in

a

closed

system

-LRB-

where

all

procedures

are

known

-RRB-

the

only

source

for

change

of

the

predicate

EnrolledIn

is

the

procedure

enrolInCourse

This

means

that

the

pre/postcondition

specifications

of

all

the

other

procedures

need

not

say

anything

about

how

they

affect

EnrolledIn

Also

note

that

the

change

axiom

for

size

need

not

explain

the

nature

of

the

change

to

that

function

This

information

is

already

captured

by

the

effect

axioms

of

the

procedures

Incidentally

proof

obligations

concerning

invariants

maintained

by

a

procedure

p

-LRB-

x

-RRB-

could

now

be

recast

to

simply

assume

as

a

premise

the

occurrence

of

a

procedure

x

-LSB-

I

Occur

-LRB-

p

-LRB-

x

-RRB-

-RRB-

fi

primed

-LRB-

I

-RRB-

-RSB-

together

with

some

assurances

that

no

other

action

has

occured

We

emphasize

again

that

here

it

is

the

responsibility

of

the

specifier

to

write

down

the

change

axioms

and

that

these

may

need

to

be

modified

as

new

procedures

are

added

or

old

ones

are

altered

For

example

if

we

now

were

to

add

a

procedure

dropCourse

with

its

own

specification

dropCourse

-LRB-

st

crs

-RRB-

PRE

EnrolledIn

-LRB-

st

crs

-RRB-

POST

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

then

we

would

have

to

add

appropriate

clauses

to

the

change

axioms

of

EnrolledIn

and

size

This

can

be

done

quite

cleanly

by

adding

disjuncts

a

st

crs

EnrolledIn

-LRB-

st

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

Occur

-LRB-

a

-RRB-

fi

false

-LRB-

a

dropCourse

-LRB-

st

crs

-RRB-

-RRB-

a

crs

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

Occur

-LRB-

a

-RRB-

fi

-LSB-

st.a

enrolInCourse

-LRB-

st

crs

-RRB-

st.a

dropCourse

-LRB-

st

crs

-RRB-

-RSB-

It

is

worth

noting

that

although

the

frame

axioms

about

a

single

procedure

are

now

spread

over

possibly

several

change

axioms

the

process

of

thinking

about

these

axioms

is

systematic

In

particular

if

there

is

a

change

in

the

postcondition

of

some

procedure

p

then

we

must

only

consider

the

change

axioms

for

those

predicates

which

were

added

dropped

or

modified

by

the

change

and

even

here

we

only

need

to

consider

that

sub-formula

of

the

explanation

axiom

which

starts

with

z

-LRB-

a

p.

-RRB-

Furthermore

any

time

the

state

is

extended

with

another

predicate

or

function

there

is

no

concern

that

this

now

might

be

inadvertently

be

left

open

to

change

by

some

procedure

specification

In

order

to

reason

appropriately

with

the

above

axioms

we

will

need

to

add

two

additional

axioms

dealing

with

the

reification

of

procedures

one

stating

that

the

only

one

action

occurs

at

one

time

a.Occur

-LRB-

a

-RRB-

and

another

one

that

the

actions

are

distinct

iff

their

names

and

arguments

are

distinct

-LRB-

the

so

called

unique

name

axioms

-RRB-

for

i?j

x

y

-LSB-

-LRB-

pi

-LRB-

x

-RRB-

pj

-LRB-

y

-RRB-

-RRB-

-LRB-

pi

-LRB-

x

-RRB-

pi

-LRB-

y

-RRB-

fi

x

y

-RRB-

-RSB-

Details

of

the

axiomatization

and

a

discussion

of

its

limitations

can

be

found

in

-LSB-

-RSB-

In

particular

as

described

here

change

axioms

do

not

always

have

their

intended

effects

for

instance

in

cases

involving

non-deterministic

procedures

For

an

approach

to

change

axioms

in

the

presence

of

non-determinism

see

-LSB-

-RSB-

Frame

Problem

Variations

Revisited

To

show

how

this

approach

handles

the

problems

raised

earlier

consider

again

the

examples

of

sections

With

the

frame

axioms

out

of

the

way

the

specification

of

the

more

complex

enrolment

's

postcondition

in

Section

would

be

as

at

the

beginning

of

that

section

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

fi

-LRB-

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

Year

-LRB-

st

-RRB-

fi

-LRB-

waitSize

-LRB-

crs

-RRB-

waitSize

-LRB-

crs

-RRB-

Waiting

-LRB-

st

crs

-RRB-

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

Year

-LRB-

st

-RRB-

fi

-LRB-

rejectSize

-LRB-

crs

-RRB-

rejectSize

-LRB-

crs

-RRB-

Rejected

-LRB-

st

crs

-RRB-

-RRB-

The

change

axioms

for

EnrolledIn

and

size

would

be

a

st

crs

EnrolledIn

-LRB-

st

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

Occur

-LRB-

a

-RRB-

fi

-LRB-

a

enrolInCourse

-LRB-

st

crs

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

-RRB-

a

st

crs

EnrolledIn

-LRB-

st

crs

-RRB-

EnrolledIn

-LRB-

st

crs

-RRB-

Occur

-LRB-

a

-RRB-

fi

false

a

crs

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

Occur

-LRB-

a

-RRB-

fi

st

-LRB-

a

enrolInCourse

-LRB-

st

crs

-RRB-

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

-RRB-

We

would

have

similar

change

axioms

for

waiting

sizeWaiting

etc.

Conjoining

of

procedure

specifications

also

works

out

without

surprises

as

long

as

we

state

the

postconditions

in

a

loose

way

The

specification

of

enrolInCourse

dropCourse

and

switchCourse

in

Z

might

then

be

enrolInCourse

def

-LSB-

st

Student

crs

Course

D

enrolledIn

size

size

-LRB-

crs

-RRB-

classLimit

-LRB-

crs

-RRB-

-LRB-

st

crs

-RRB-

enrolledIn

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

-RSB-

dropCourse

def

-LSB-

st

Student

crs

COURSE

D

enrolledIn

size

-LRB-

st

crs

-RRB-

enrolledIn

-LRB-

st

crs

-RRB-

enrolledIn

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

-RSB-

switchCourse

-LRB-

st

-RRB-

def

dropCourse

-LRB-

st

-RRB-

enrolInCourse

-LRB-

st

-RRB-

and

the

change

axioms

could

be

stated

a

st

crs

-LRB-

st

crs

-RRB-

enrolledIn

enrolledIn

Occur

-LRB-

a

-RRB-

fi

a

enrolInCourse

-LRB-

st

crs

-RRB-

a

switchCourse

-LRB-

st

crs

-RRB-

a

st

crs

-LRB-

st

crs

-RRB-

enrolledIn

enrolledIn

Occur

-LRB-

a

-RRB-

fi

a

dropCourse

-LRB-

st

crs

-RRB-

a

switchCourse

-LRB-

st

crs

-RRB-

a

crs

size

-LRB-

crs

-RRB-

size

-LRB-

crs

-RRB-

Occur

-LRB-

a

-RRB-

fi

st.

a

enrolInCourse

-LRB-

st

crs

-RRB-

st.

a

dropCourse

-LRB-

st

crs

-RRB-

st

-LRB-

a

switchCourse

-LRB-

st

crs

-RRB-

a

switchCourse

-LRB-

st

crs

-RRB-

-RRB-

The

exact

syntax

of

change

axioms

for

various

specification

languages

should

be

the

subject

of

further

study

Note

that

only

the

disjunctive

clauses

involving

switchCourse

are

contributed

by

the

introduction

of

the

switchCourse

procedure

-LRB-

four

clauses

in

all

-RRB-

For

the

object-oriented

specification

of

Section

we

explicitly

name

the

function

and

put

the

privileged

argument

self

back

into

the

function

call

in

order

to

simplify

the

presentation

In

the

case

of

courses

with

co-requisites

the

specifications

of

actions

for

drop

would

be

class

COURSE

drop

-LRB-

self

COURSE

st

STUDENT

-RRB-

PRE

HasEnrolled

-LRB-

self

st

-RRB-

POST

HasEnrolled

-LRB-

self

st

-RRB-

class

COURSE-WITH-COREQ

subclass

of

COURSE

drop

-LRB-

self

COURSE-WITH-COREQS

st

STUDENT

-RRB-

POST

x

Coreq

-LRB-

self

x

-RRB-

fi

HasEnrolled

-LRB-

x

st

-RRB-

and

change

axioms

for

HasEnrolled

would

state

a

st

crs

HasEnrolled

-LRB-

crs

st

-RRB-

HasEnrolled

-LRB-

crs

st

-RRB-

Occur

-LRB-

a

-RRB-

fi

a

COURSE

add

-LRB-

crs

st

-RRB-

a

stHasEnrolled

-LRB-

crs

st

-RRB-

HasEnrolled

-LRB-

crs

st

-RRB-

Occur

-LRB-

a

-RRB-

fi

-LRB-

a

COURSE

drop

-LRB-

crs

st

-RRB-

-LRB-

crs

COURSE-WITH-COREQ

-RRB-

-RRB-

-LRB-

a

COURSE-WITH-COREQ

drop

-LRB-

crs

st

-RRB-

HasEnrolled

-LRB-

crs

st

-RRB-

-RRB-

In

the

case

of

employees

moving

the

specifications

would

be

EMPLOYEE

move

-LRB-

self

EMPLOYEE

new

ADDRESS

-RRB-

MOD

livesAt

POST

livesAt

-LRB-

self

-RRB-

new

move

-LRB-

self

new

ADDRESS

-RRB-

POST

livesAt

-LRB-

spouse

-LRB-

self

-RRB-

-RRB-

new

and

the

change

axioms

for

livesAt

would

state

a

x

livesAt

-LRB-

x

-RRB-

livesAt

-LRB-

x

-RRB-

Occur

-LRB-

a

-RRB-

fi

n

a

EMPLOYEE

move

-LRB-

x

n

-RRB-

n

a

move

-LRB-

x

n

-RRB-

n

y

a

move

-LRB-

y

n

-RRB-

x

spouse

-LRB-

y

-RRB-

Finally

for

the

case

of

honors

students

the

specifications

would

look

like

class

Course

findHonors

-LRB-

self

COURSE

-RRB-

PRE

domain

grade

enrolment

POST

-LCB-

s

grade

-LRB-

s

-RRB-

-LRB-

self

-RRB-

-RCB-

honors

-LRB-

self

-RRB-

class

SENIOR-COURSE

subclass

of

COURSE

findHonors

-LRB-

self

SENIOR-COURSE

-RRB-

POST

-LCB-

s

grade

-LRB-

s

-RRB-

-LRB-

self

-RRB-

-RCB-

honors

-LRB-

self

-RRB-

so

the

conjunction

of

the

post

conditions

for

SENIOR-COURSE

findHonors

would

yield

-LCB-

s

grade

-LRB-

s

-RRB-

-LRB-

self

-RRB-

-RCB-

honors

-LRB-

self

-RRB-

The

initial

value

of

honors

would

be

the

empty

set

and

the

effect

axiom

for

honors

could

read

a

c

s.

s

honors

-LRB-

c

-RRB-

honors

-LRB-

c

-RRB-

Occur

-LRB-

a

-RRB-

fi

a

COURSE

findHonors

-LRB-

c

-RRB-

-LRB-

grades

-LRB-

s

-RRB-

-LRB-

c

-RRB-

-RRB-

domain

grade

enrolment

a

SENIOR-COURSE

findHonors

-LRB-

c

-RRB-

-LRB-

grades

-LRB-

s

-RRB-

-LRB-

c

-RRB-

-RRB-

domain

grade

enrolment

A

Syntactic

Technique

for

Generating

Explanation

Axioms

-LRB-

Sometimes

-RRB-

The

astute

reader

may

have

noticed

that

we

followed

a

relatively

mechanistic

process

in

building

the

change

axioms

For

the

predicate

EnrolledIn

for

instance

we

looked

at

the

postcondition

of

each

procedure

p

such

as

enrolInCourse

and

dropCourse

and

if

it

asserted

EnrolledIn

-LRB-

w

-RRB-

-LRB-

respectively

EnrolledIn

-LRB-

w

-RRB-

-RRB-

for

some

argument

w

then

we

added

the

clause

-LRB-

a

p

-LRB-

w

-RRB-

-RRB-

as

an

additional

disjunct

to

the

positive

-LRB-

respectively

negative

-RRB-

change

axiom

For

conditional

postconditions

with

cases

of

the

form

g

-LRB-

x

-RRB-

fi

EnrolledIn

-LRB-

w

-RRB-

where

g

only

includes

unprimed

predicates

and

functions

we

added

a

disjunctive

clause

of

the

form

x

-LRB-

a

p

-LRB-

x

-RRB-

g

-LRB-

x

-RRB-

y

w

-RRB-

where

w

consists

of

constants

and

variables

from

x

to

the

positive

change

axiom

for

Q

whose

antecedent

is

Q

-LRB-

y

-RRB-

Q

-LRB-

y

-RRB-

Occur

-LRB-

a

-RRB-

This

process

can

be

easily

translated

into

an

algorithm

which

generates

change

axioms

In

the

spirit

of

our

earlier

arguments

concerning

the

need

for

flexibility

we

would

however

only

advocate

the

use

of

such

an

algorithm

as

a

tool

that

would

assist

the

specifier

in

adding

more

quickly

the

change

axioms

Semantic

Aspects

of

the

Approach

A

problem

that

can

arise

with

any

purely

syntactic

approach

such

as

the

one

suggested

in

the

previous

section

is

that

it

is

often

affected

by

the

particular

syntax

chosen

to

express

postconditions

and

is

not

necessarily

self-consistent

Logicians

rely

on

model

theory

and

proofs

of

soundness

and

completeness

to

avoid

such

pitfalls

for

their

syntactic

manipulations

As

it

happens

it

is

possible

to

provide

a

modeltheoretic

foundation

for

frame

axioms

as

explored

in

the

literature

on

non-monotonic

reasoning

Recall

that

the

problem

with

the

loose

reading

of

a

post-condition

such

as

EnrolledIn

-LRB-

st

crs

-RRB-

is

that

it

does

not

rule

out

any

other

changes

In

other

words

among

the

models

of

the

formula

we

find

some

in

which

the

student

's

name

has

changed

-LRB-

i.e.

where

name

-LRB-

st

-RRB-

and

name

-LRB-

st

-RRB-

differ

-RRB-

as

well

as

ones

where

they

do

not

Model-theoretically

we

would

therefore

like

to

select

out

those

models

of

the

postcondition

in

which

things

changed

only

if

they

had

to

In

other

words

differences

between

primed

This

section

is

somewhat

more

technical

and

assumes

that

the

reader

is

familiar

with

the

model

theory

of

First

Order

Predicate

Logic

and

unprimed

versions

of

predicates

are

minimized

in

the

sense

that

there

is

no

model

of

the

postcondition

that

has

fewer

changes

For

this

we

can

turn

to

the

technique

of

circumscription

-LSB-

-RSB-

which

has

in

fact

been

used

to

attack

the

frame

problem

in

AI

Circumscription

essentially

selects

only

those

models

of

a

theory

which

minimize

the

extents

of

certain

specified

predicate

-LRB-

s

-RRB-

Circumscription

may

be

illustrated

by

showing

how

it

captures

the

notion

of

negation

by

failure

familiar

to

Prolog

programmers

given

the

clauses

P

-LRB-

-RRB-

Q

-LRB-

x

-RRB-

P

-LRB-

x

-RRB-

negation

by

failure

would

allow

one

to

conclude

the

following

list

of

atoms

Q

-LRB-

-RRB-

Q

-LRB-

-RRB-

Q

-LRB-

-RRB-

while

classical

logic

only

entails

the

first

atom

This

is

achieved

by

making

all

predicates

have

the

smallest

-LRB-

positive

-RRB-

extent

necessary

to

satisfy

the

originally

given

facts

-LCB-

P

-LRB-

-RRB-

x.P

-LRB-

x

-RRB-

fi

Q

-LRB-

x

-RRB-

-RCB-

In

our

case

since

we

have

stated

that

we

are

interested

in

minimizing

changes

we

can

introduce

for

every

predicate

R

two

new

predicate

symbols

D+R

and

D-R

with

defining

axiom

D+R

-LRB-

y

-RRB-

def

R

-LRB-

y

-RRB-

R

-LRB-

y

-RRB-

D-R

-LRB-

y

-RRB-

def

R

-LRB-

y

-RRB-

R

-LRB-

y

-RRB-

Technically

we

are

then

interested

in

circumscribing

-LRB-

minimizing

-RRB-

the

predicates

in

the

set

-LCB-

D+R

D-R

-RCB-

subject

to

the

constraint

that

the

effect

axioms

of

procedures

hold

as

do

the

axioms

defining

DR

and

the

various

unique

name

axioms

This

minimization

is

to

be

done

while

keeping

the

extents

of

unprimed

predicates

fixed

but

varying

the

extents

of

primed

ones

In

our

example

the

theory

would

therefore

have

the

effect

axioms

for

enrolInCourse

dropCourse

etc.

such

as

x

y

-LSB-

Occur

-LRB-

enrolInCourse

-LRB-

x

y

-RRB-

-RRB-

fi

-LRB-

size

-LRB-

y

-RRB-

classLimit

-LRB-

y

-RRB-

-LRB-

-LSB-

EnrolledIn

-LRB-

x

y

-RRB-

-RSB-

-RRB-

-RRB-

-LRB-

size

-LRB-

y

-RRB-

size

-LRB-

y

-RRB-

EnrolledIn

-LRB-

x

y

-RRB-

-RRB-

-RSB-

plus

the

unique

name

axioms

x

y

-LSB-

-LRB-

enrol

-LRB-

x

-RRB-

drop

-LRB-

y

-RRB-

-RRB-

-LRB-

enrol

-LRB-

x

-RRB-

enrol

-LRB-

y

-RRB-

fi

x

y

-RRB-

-RSB-

Appropriate

circumscription

using

the

above

theory

would

restrict

us

to

consider

only

those

of

its

models

in

which

the

predicates

D+E

nrolledIn

D-EnrolledIn

D

size

etc.

have

minimal

extents

-LRB-

in

the

sense

that

if

any

tuple

is

removed

from

any

of

their

denotations

the

resulting

valuation

is

no

longer

a

model

of

the

theory

derived

from

the

specification

-RRB-

The

invariant

would

then

have

to

be

proven

to

be

maintained

only

in

these

specially

selected

models

At

first

glance

such

a

model-theoretic

description

would

appear

to

be

of

only

purely

theoretical

interest

However

there

is

the

possibility

of

finding

some

syntactic

formulation

that

can

be

proven

to

be

sound

and

possibly

even

complete

with

respect

to

it

In

fact

the

change

axioms

generated

from

the

effect

axioms

by

the

algorithm

sketched

in

the

previous

section

can

be

shown

to

select

out

exactly

the

models

that

would

be

chosen

by

the

circumscription

scheme

outlined

in

this

section

for

a

limited

class

of

specifications

This

should

increase

considerably

our

confidence

in

the

syntactic

treatment

of

the

frame

problem

discussed

earlier

Other

Approaches

to

the

Frame

Problem

Approaches

in

Artificial

Intelligence

The

frame

problem

in

AI

has

been

studied

within

a

different

formal

framework

called

the

situation

calculus

-LSB-

-RSB-

which

makes

explicit

the

relationship

between

the

predicates

describing

the

program

state

before

and

after

the

procedure

a

relationship

maintained

purely

by

the

priming

convention

in

our

approach

This

is

done

by

also

reifying

states

as

follows

for

each

function

f

-LRB-

x

-RRB-

in

the

specification

introduce

a

function

f

-LRB-

x

s

-RRB-

called

a

fluent

where

s

is

a

term

of

sort

state

-LRB-

or

situation

-RRB-

Likewise

for

each

predicate

R

-LRB-

x

-RRB-

of

the

specification

let

there

be

a

fluent

R

-LRB-

x

s

-RRB-

Given

this

formulation

it

is

then

possible

to

consider

the

primed-predicate

notation

as

simply

an

abbreviation

in

specifying

procedure

p

every

occurrence

of

an

unprimed

atom

or

term

f

-LRB-

y

-RRB-

should

be

read

as

f

-LRB-

y

s

-RRB-

while

every

atom

or

term

of

the

form

f

-LRB-

y

-RRB-

stands

for

f

-LRB-

y

do

-LRB-

p

-LRB-

x

-RRB-

s

-RRB-

-RRB-

where

do

is

a

special

function

symbol

intended

to

the

denote

the

state

obtained

by

executing

an

action

its

first

argument

in

the

start

state

its

second

argument

The

full

situation

calculus

is

therefore

more

expressive

in

that

it

allows

one

to

reason

about

sequences

of

actions/procedures

e.g.

Mary

is

enrolled

in

after

Mary

added

in

state

and

then

Ann

dropped

EnrolledIn

-LRB-

mary

do

-LRB-

drop

-LRB-

ann

-RRB-

do

-LRB-

added

-LRB-

mary

-RRB-

-RRB-

-RRB-

-RRB-

Since

it

was

first

pointed

out

by

McCarthy

and

Hayes

-LRB-

-RRB-

the

frame

problem

has

been

the

subject

of

intense

investigation

in

AI

During

the

's

and

early

's

nonmonotonic

reasoning

has

been

the

formal

approach

of

choice

-LRB-

see

-LRB-

-RRB-

for

a

review

of

this

field

-RRB-

The

intuition

underlying

this

appeal

to

nonmonotonic

logics

is

that

the

frame

axioms

are

the

product

of

a

form

of

closed

world

assumption

with

respect

to

the

causal

laws

-LRB-

what

we

have

been

calling

effect

axioms

-RRB-

In

other

words

it

is

assumed

that

the

causal

laws

specified

by

the

axiomatizer

are

all

and

only

the

causal

laws

for

the

domain

and

therefore

if

there

is

no

law

specifying

that

action

p

affects

a

given

predicate?s

truth

value

then

that

predicate

must

be

unaffected

by

p.The

technical

problem

is

to

provide

a

formal

account

of

this

closed

world

assumption

and

since

circumscription

-LSB-

-RSB-

is

the

most

general

formalization

of

closed

world

reasoning

the

majority

of

approaches

to

the

frame

problem

have

focussed

on

it

-LSB-

-RSB-

-LSB-

-RSB-

-RRB-

Despite

this

emphasis

on

circumscription

a

few

attempts

were

made

to

solve

the

frame

problem

without

appealing

to

nonmonotonic

logics

notably

-LSB-

-RSB-

-LSB-

-RSB-

and

-LSB-

-RSB-

In

particular

Haas

and

Schubert

first

proposed

the

concept

of

an

explanation

closure

axiom

-LRB-

or

as

we

have

been

calling

them

change

axioms

-RRB-

for

specifying

the

frame

axioms

while

Pednault

was

the

first

to

formulate

a

mechanism

for

automatically

obtaining

the

frame

axioms

given

only

the

causal

laws

for

the

domain

of

application

By

combining

and

extending

the

ideas

of

Haas

Schubert

and

Pednault

-LSB-

-RSB-

provided

the

solution

to

the

frame

problem

that

underlies

the

proposal

of

this

paper

This

proposal

was

recently

semantically

characterized

-LSB-

-RSB-

by

showing

that

the

circumscription

described

in

-LSB-

-RSB-

characterizes

Reiter

's

solution

Accordingly

we

now

have

both

semantic

and

syntactic

characterizations

of

the

frame

problem

in

the

situation

calculus

and

a

proof

of

their

equivalence

An

additional

source

of

difficulties

for

solutions

to

the

frame

problem

is

the

presence

of

state

constraints

-LRB-

what

we

have

called

state

invariants

or

what

are

known

as

integrity

constraints

in

data

bases

-RRB-

Unlike

the

stance

adopted

in

this

paper

-LRB-

where

the

specifier

is

expected

to

prove

that

the

procedure

specification

is

sufficiently

complete

to

re-establish

any

state

invariants

-RRB-

in

AI

it

is

considered

desirable

to

derive

from

causal

laws

and

state

constraints

new

causal

laws

which

then

affect

the

frame

axioms

This

version

of

the

frame

problem

known

as

the

ramification

problem

is

considerably

more

difficult

and

can

not

yet

be

said

to

have

a

satisfactory

solution

For

an

attempt

to

reconcile

Reiter

's

solution

to

the

frame

problem

with

the

presence

of

state

constraints

see

-LSB-

-RSB-

Alternate

Approaches

in

Software

Specification

Even

with

appropriate

language

enhancements

program

specifiers

may

forget

to

state

the

ubiquitous

frame

axioms

For

this

reason

some

specification

languages

have

opted

for

a

richer

semantics

which

implicitly

adds

the

nothing

else

changes

clause

to

every

procedure

specification

In

other

words

such

languages

support

an

interpretation

of

the

initial

specification

of

enrolInCourse

that

is

consistent

with

the

tight

reading

mentioned

in

Section

The

advantage

of

such

implicit

frame

axioms

is

that

if

we

apply

them

to

procedure

specifications

after

inheritance

conjunction

etc.

have

been

expanded

then

we

get

the

desired

effect

of

things

not

changing

unless

otherwise

stated

Several

systems

such

as

INSCAPE

-LSB-

-RSB-

make

the

meta-assertion

that

variables

are

not

changed

unless

explicitly

said

so

and

then

implement

it

operationally

in

the

sense

that

the

specific

reasoning

done

by

the

system

take

this

into

account

In

the

case

of

INSCAPE

the

system

concerns

itself

mostly

with

propagating

necessary

or

possible

changes

to

the

interfaces

and

does

not

support

constructing

proofs

that

invariants

are

maintained

The

ASLAN

specification

language

-LSB-

-RSB-

introduces

into

the

language

special

connectives

ifthen-else

and

alternate

which

have

a

procedural

reading

of

the

kind

familiar

to

programmers

The

aim

is

to

provide

an

explicit

-LRB-

declarative

-RRB-

and

formal

expression

of

the

intuitive

statement

that

nothing

else

changes

The

aforementioned

paper

offers

algorithms

for

computing

such

assertions

in

this

limited

case

and

provides

ample

evidence

of

the

difficulties

one

runs

into

because

of

context

and

subscripted

variables

difficulties

related

to

the

meaning

of

the

procedural

reading

as

well

as

the

correctness

of

the

implementation

To

their

credit

Schuman

and

Pitt

-LSB-

-RSB-

discovered

the

frame

problem

for

object-oriented

specifications

in

Z

and

proposed

a

technique

for

defining

a

completing

assertion

that

can

be

added

to

a

postcondition

in

order

to

capture

the

frame

axioms

Their

approach

is

based

on

the

observation

that

in

a

set-theoretic

notation

s

s

-LCB-

-RCB-

can

be

equivalently

stated

as

-LRB-

s

-RRB-

-LRB-

s

-LCB-

-RCB-

s

-LCB-

-RCB-

-RRB-

so

that

with

a

postcondition

of

the

form

-LRB-

s

-RRB-

we

are

looking

for

a

weaker

version

of

the

frame

axiom

s

s

Their

scheme

relies

on

finding

maximally

consistent

subsets

of

so-called

neutral

assertions

Unfortunately

this

approach

suffers

from

the

problem

that

it

is

computationally

intractable

-LRB-

in

fact

not

even

semi-decidable

-RRB-

since

it

relies

on

proving

consistency

of

subsets

of

formulas

Independently

we

stumbled

across

the

problem

in

our

own

attempts

to

develop

a

specification

language

specially

suited

for

information

systems

Since

we

were

aware

that

expressing

nothing

else

changes

was

one

of

the

motivating

examples

of

the

field

of

Non-monotonic

Reasoning

our

language

proposal

TaxisDL

-LSB-

-RSB-

explicitly

states

the

frame

axioms

using

Default

Logic

a

particular

version

of

Nonmonotonic

Logic

Unfortunately

this

scheme

is

also

not

effectively

computable

since

it

also

relies

on

the

non-provability

relation

Obviously

the

non-effectiveness

of

the

above

schemes

severely

compromises

a

formal

specification

language

with

respect

to

its

capacity

to

support

the

formal

treatment

of

specifications

since

one

of

the

prime

uses

of

procedure

specifications

is

to

prove

that

they

leave

state

invariants

intact

Such

proofs

can

then

no

longer

be

automated

In

addition

to

the

computational

problem

another

major

drawback

with

embedding

the

frame

axioms

in

the

specification

language

semantics

is

that

in

some

circumstances

the

specifier

may

want

the

freedom

not

to

make

them

or

to

state

them

in

some

different

way

-LSB-

-RSB-

and

-LSB-

-RSB-

are

other

recent

proposals

which

embed

some

frame

axioms

in

the

semantics

of

the

specification

language

by

allowing

the

specifier

to

differentiate

actions

or

attributes

for

which

the

assumptions

are

to

be

made

from

those

for

which

they

are

not

A

different

compromise

between

placing

the

full

responsibility

on

the

specifier

on

one

hand

and

embedding

the

frame

axioms

in

the

semantics

of

the

specification

language

on

the

other

is

to

provide

a

computer

tool

which

once

a

specification

is

considered

finished

makes

a

pass

over

it

expands

abbreviations

and

suggests

frame

axioms

to

be

added

to

each

specification

If

the

user

is

unhappy

with

the

proposed

axioms

she

can

modify

them

to

her

liking

At

the

very

least

such

a

tool

would

be

very

helpful

in

catching

omissions

It

must

be

stressed

however

that

such

a

tool

ought

to

be

viewed

as

a

compiler

when

changes

are

made

to

the

specification

the

tool

needs

to

be

re-run

The

work

in

-LSB-

-RSB-

and

to

some

Regrettably

their

insights

seem

to

have

been

ignored

by

more

recent

papers

on

object-oriented

specifications

extent

-LSB-

-RSB-

exemplifies

this

approach

though

it

only

deals

with

a

restricted

subset

of

formulas

Our

proposal

for

syntactically

generating

change

axioms

can

be

viewed

in

the

same

light

Concluding

Remarks

We

have

presented

evidence

that

in

specifying

procedures

in

the

popular

style

of

pre

and

postconditions

defined

over

program

states

it

is

useful

to

have

some

mechanism

to

make

blanket

statements

of

the

form

and

nothing

else

changes

rather

than

explicitly

enumerating

the

things

that

do

not

change

This

facility

would

seem

to

be

essential

if

we

are

to

develop

a

proper

notion

of

object-oriented

specifications

to

support

programming

in

OOPLs

such

as

C++

and

Eiffel

We

critically

reviewed

some

of

the

mechanisms

in

extant

specification

languages

that

attempt

to

address

this

problem

Secondly

we

have

applied

a

technique

that

has

been

recently

used

in

AI

to

deal

with

the

frame

problem

the

idea

of

axioms

explaining

what

changes

could

occur

to

a

particular

component

of

the

program

state

through

the

application

of

known

procedures

This

idea

we

have

argued

produces

short

effective

and

relatively

modular

specifications

for

software

and

deals

effectively

with

a

number

of

problems

that

are

not

properly

addressed

by

other

approaches

Moreover

our

proposal

has

the

added

advantage

of

being

phrased

entirely

within

Predicate

Logic

thus

making

it

unnecessary

to

build

special

theorem

provers

to

reason

with

specifications

We

also

note

that

the

specialized

context

of

reasoning

about

procedure

specifications

as

currently

performed

in

software

engineering

makes

it

possible

to

simplify

considerably

the

machinery

used

in

AI

We

have

also

argued

that

for

a

small

class

of

specifications

it

is

possible

to

generate

syntactically

some

explanation

closure

axioms

that

coincide

with

those

suggested

by

our

intuitions

and

that

these

intuitions

are

supported

by

a

model-theory

in

which

the

extents

of

predicates

are

minimized

The

following

are

just

some

of

the

issues

that

remain

to

be

explored

How

large

is

the

class

of

specifications

for

which

we

can

generate

automatically

reasonable

change

axioms

starting

from

pre/postconditions

What

are

appropriate

notations

that

allow

these

ideas

to

be

incorporated

into

familiar

specification

languages

such

as

Z

VDM

Larch

COLD

etc.

without

violating

or

extending

too

much

their

underlying

philosophy

The

explicit

inclusion

of

frame

axioms

into

the

specification

also

causes

difficulties

with

reasoning

about

concurrency

in

specification

as

observed

by

-LSB-

-RSB-

Our

approach

can

form

a

starting

point

for

exploring

new

approaches

by

allowing

the

Occur

predicate

to

hold

at

more

than

one

argument/action

at

a

time

In

some

circles

it

has

been

suggested

that

in

order

to

support

maximal

reuse

there

should

be

no

limitation

on

the

kinds

of

changes

that

one

can

make

to

a

procedure?s

specification

when

specializing/refining

it

to

a

subclass

The

wider

use

of

Occur

predicate

in

post-conditions

may

allow

for

the

explicit

cancellation

of

inheritance

Acknowledgment

We

are

grateful

to

Eric

Hehner

for

his

comments

and

much

appreciated

moral

support

to

Klaus

Dieter

Schewe

and

Don

Cohen

for

clarifications

concerning

certain

formal

specification

systems

and

to

the

reviewers

References

-LSB-

-RSB-

A.

J.

Alencar

and

J.

A.

Goguen

Specification

in

OOZE

with

Examples

in

-LSB-

-RSB-

pp.

-LSB-

-RSB-

A.

Auernheimer

and

R.

Kemmerer

Procedural

and

Nonprocedural

Semantics

of

the

ASLAN

Formal

Specification

Language

Ptoc

Hawaii

Int

Conf

on

System

Sciences

-LRB-

HICS

-RRB-

pp.

-LSB-

-RSB-

A.

Borgida

On

the

definition

of

specialization

hierarchies

for

procedures

Proc

IJCAI

Vancouver

BC

August

pp.

-LSB-

-RSB-

A.

Borgida

J.

Mylopoulos

and

H.

K.

T.

Wong

Generalization/Specialization

as

a

Basis

for

Software

Specification

in

On

Conceptual

Modeling

Perspectives

from

Artificial

Intelligence

Databases

and

Programming

Languages

M.

Brodie

J.

Mylopoulos

and

J.

Schmidt

-LRB-

eds

-RRB-

Springer

Verlag

-LSB-

-RSB-

A.

Borgida

J.

Mylopoulos

J.

Schmidt

and

I.

Wetzel

Support

for

Data-Intensive

Applications

Conceptual

Design

and

Software

Development

in

Database

Programming

Languages

R.Hull

R.

Morrison

D.Stemple

-LRB-

eds

-RRB-

Morgan

Kaufmann

Publishers

San

Mateo

CA.

-LSB-

-RSB-

B.

Cohen

W.T.Harwood

and

M.I.Jackson

The

Specification

of

Complex

Systems

Addisson

Wesley

-LSB-

-RSB-

Duke

D.

and

R.

Duke

Towards

a

Semantics

for

Object

Z

in

VDM

and

Z

Formal

Methods

in

Software

Development

Lecture

Notes

in

Computer

Science

Vol

Springer

Verlag

Berlin

-LSB-

-RSB-

J.

Guttag

J.J.

Horning

and

J.W.

Wing

Larch

in

Five

Easy

Pieces

TR

DEC

Systems

Research

Center

-LSB-

-RSB-

Haas

A.

R.

The

Case

for

Domain

Specific

Frame

Axioms

in

Brown

F.

M.

-LRB-

ed

-RRB-

The

Frame

Problem

in

Artificial

Intelligence

Proceedings

of

the

Workshop

Morgan

Kaufmann

Publishers

Inc.

-LSB-

-RSB-

A.

Hall

Using

Z

as

a

Specification

Calculus

for

Object-Oriented

Systems

VDM

and

Z

Formal

Methods

in

Software

Development

Lecture

Notes

in

Computer

Science

Vol

Springer

Verlag

Berlin

-LSB-

-RSB-

J.

Haugelstein

and

D.

Roclants

Reconciling

Operational

and

Declarative

Specifications

Proceedings

International

Conference

on

Advanced

Information

Systems

Engineering

-LRB-

CAiSE

-RRB-

Manchester

May

-LSB-

-RSB-

C.B.

Jones

Systematic

Software

Development

Using

VDM

Prentice

Hall

London

-LSB-

-RSB-

H.B.M.Jonkers

Updating

the

pre

and

postcondition

technique

in

VDM

Formal

Software

Development

Methods

Lecture

Notes

in

COmputer

Science

Springer

Verlag

-LSB-

-RSB-

K.

Lanno

and

H.

Haughton

Object-oriented

Specification

Case

Studies

Prentice

Hall

-LSB-

-RSB-

Lifschitz

V.

Toward

a

Metatheory

of

Action

Proceedings

of

the

Second

International

Conference

on

Principles

of

Knowledge

Representation

and

Reasoning

-LRB-

KR

-RRB-

Morgan

Kaufmann

Publishers

Inc.

-LSB-

-RSB-

Lin

F.

and

Shoham

Y.

Provably

Correct

Theories

of

Action

Proceedings

of

the

National

Conference

on

Artificial

Intelligence

-LSB-

-RSB-

Lin

F.

and

Reiter

R.

State

Constraints

Revisited

Journal

of

Logic

and

Computation

-LSB-

-RSB-

L.

Marshall

and

L.

Simon

Using

VDM

within

an

Object-Oriented

Framework

VDM

and

Z

Formal

Methods

in

Software

Development

Lecture

Notes

in

Computer

Science

Vol

Springer

Verlag

Berlin

-LSB-

-RSB-

J.

McCarthy

Situations

Actions

and

Causal

Laws

technical

report

Stanford

University

also

reprinted

in

Semantic

Information

Processing

Minsky

M.

-LRB-

ed

-RRB-

MIT

Press

-LSB-

-RSB-

J.

McCarthy

and

P.

Hayes

Some

Philosophical

Problems

from

the

Standpoint

of

Aritificial

Intelligence

Machine

Intelligence

Melzter

B.

and

Michie

D.

-LRB-

eds

-RRB-

Edinburgh

University

Press

-LSB-

-RSB-

McCarthy

J.

Applications

of

Circumscription

to

Formalizing

Commonsense

Knowledge

Artificial

Intelligence

-LSB-

-RSB-

B.

Meyer

Object

Oriented

Software

Construction

Prentice

Hall

-LSB-

-RSB-

J.

Mylopoulos

P.

Bernstein

and

H.

Wong

A

Language

Facility

for

Designing

Data-Intensive

Applications

ACM

TODS

-LRB-

-RRB-

June

-LSB-

-RSB-

Pednault

E.P.D.

ADL

Exploring

the

Middle

Ground

Between

STRIPS

-RCB-

and

the

Situation

Calculus

Proceedings

of

the

First

International

Conference

on

Principles

of

Knowledge

Representation

and

Reasoning

-LRB-

KR

-RRB-

Morgan

Kaufmann

Publishers

Inc.

-LSB-

-RSB-

D.

Penny

R.

C.

Holt

M.

Godfrey

Formal

Specifications

in

Metamorphic

Programming

VDM

Formal

Software

Development

Methods

Lecture

Notes

in

Computer

Science

Springer

Verlag

-LSB-

-RSB-

D.

Perry

The

Inscape

Environment

Proc

Int

Conf

on

Software

Engineering

Pittsburgh

May

-LSB-

-RSB-

R.

Reiter

Nonmonotonic

Reasoning

Annual

Review

of

Computer

Science

Annual

Reviews

Inc.

-LSB-

-RSB-

R.

Reiter

The

Frame

Problem

in

the

Situation

Calculus

A

Simple

Solution

-LRB-

Sometimes

-RRB-

and

a

Completeness

Result

for

Goal

Regression

in

V.

Lifschitz

-LRB-

ed

-RRB-

Artificial

Intelligence

and

the

Mathematical

Theory

of

Computation

Papers

in

Honor

of

John

McCarthy

Academic

Press

San

Diego

CA

-LSB-

-RSB-

R.

Reiter

On

Specifying

Database

Updates

Journal

of

Logic

Programming

-LRB-

to

appear

-RRB-

-LSB-

-RSB-

M.

Ryan

J.

Fiadeiro

and

T.

Maibaum

Sharing

actions

and

attributes

in

modal

action

logic

in

Theoretical

Aspects

of

Computer

Software

Springer

Verlag

lecture

Notes

in

Computer

Science

no.

-LSB-

-RSB-

K-D

Schewe

J.

W.

Schmidt

and

I.

Wetzel

Specification

and

Refinement

in

an

Integrated

Database

Application

Environment

VDM

Formal

Software

Development

Methods

Lecture

Notes

in

Computer

Science

Springer

Verlag

-LSB-

-RSB-

Schubert

L.

K.

Monotonic

Solution

of

the

Frame

Problem

in

the

Situation

Calculus

An

Efficient

Method

for

Worlds

with

Fully

Specified

Actions

in

Kyberg

H.

E.

Loui

R.

P.

and

G.N.

Carlson

-LRB-

eds

-RRB-

Knowledge

Representation

and

Defeasible

Reasoning

Kluwer

Academic

Press

-LSB-

-RSB-

S.A.

Schuman

and

D.H.Pitt

Object-Oriented

Subsystem

Specification

in

Program

Specification

and

Transformation

L.G.L.T.Meertens

-LRB-

ed

-RRB-

North

Holland

-LSB-

-RSB-

J.M.

Spivey

The

Z

Notation

A

Reference

Manual

Prentice

Hall

-LSB-

-RSB-

S.

Stepney

R.

Barden

and

D.

Cooper

-LRB-

eds

-RRB-

Object

Orientation

in

Z

Workshops

In

Computing

Series

Springer

Verlag

formal specification languages
formal specifications
inheritance
proof obligations