Automating

the

Evolution

of

Object-Oriented

Systems

Walter

L.

and

Linda

M.

Z?uhlke

Engineering

AG

Switzerland

Northeastern

University

College

of

Computer

Science

Abstract

A

formal

framework

is

presented

for

maintaining

behavior

and

consistency

of

object-oriented

systems

during

software

evolution

The

framework

effectively

couples

a

change

avoidance

approach

based

on

Adaptive

Object-Oriented

Software

with

a

change

management

mechanism

to

fully

automate

evolution

Schema

transformations

may

render

existing

objects

and

programs

inconsistent

The

framework

identifies

the

introduced

inconsistencies

and

provides

the

necessary

object

and

program

transformations

to

reinstate

consistency

while

maintaining

the

behavior

of

the

system

A

formal

definition

of

behavioral

equivalence

is

given

To

prove

behavioral

equivalence

of

adaptive

programs

the

paper

includes

a

formal

semantics

for

adaptive

software

Finally

the

feasibility

of

the

framework

is

demonstrated

for

a

representative

set

of

primitive

schema

transformations

Introduction

Code

management

is

important

because

poor

code

management

costs

more

money

and

time

than

good

code

management

Kevin

Jameson

-LSB-

-RSB-

Object-oriented

languages

are

often

touted

as

facilitating

reuse

reducing

the

cost

of

both

development

time

and

maintenance

and

simplifying

the

evolution

of

software

systems

But

even

when

built

with

advanced

object-oriented

technology

today

's

software

systems

are

not

immune

against

the

effects

of

change

The

foundation

of

an

object-oriented

system

is

its

schema

The

schema

defines

the

structure

of

classes

and

their

interfaces

It

comprises

the

basis

upon

which

the

functionality

of

the

system

is

built

It

also

defines

the

structure

of

the

objects

stored

in

the

database

Consequently

changes

to

the

schema

may

require

maintenance

of

the

persistent

object

store

and

the

programs

This

paper

presents

the

Famous

-LRB-

Fully

Automated

Method

and

Object

Update

System

-RRB-

framework

for

automatically

maintaining

consistency

and

behavior

of

a

system

during

schema

evolution

Maintaining

consistency

implies

Research

conducted

while

at

Northeastern

University

and

supported

by

an

Academic

Research

Grant

from

Mettler

Toledo

AG

Switzerland

propagating

changes

to

the

persistent

object

store

and

the

programs

Maintaining

behavior

guarantees

that

the

updated

programs

executed

on

the

updated

object

store

produce

equivalent

results

as

the

original

Preserving

behavior

is

important

for

two

reasons

First

it

is

crucial

for

all

modifications

that

are

part

of

the

preventive

maintenance

of

a

system

In

particular

when

the

intention

of

the

modification

is

to

improve

the

system

e.g.

to

make

it

more

reusable

readable

maintainable

portable

and

so

forth

It

is

typically

a

case

of

hindsight

by

which

one

realizes

how

the

system

could

have

been

designed

better

System

administrators

are

often

reluctant

to

perform

such

preventive

improvements

out

of

fear

of

breaking

code

Second

the

behavior

preserving

property

can

also

facilitate

the

extension

of

a

system

's

behavior

In

order

to

make

use

of

behavior

preservation

one

needs

to

break

down

the

extension

into

two

phases

Phase

one

only

performs

the

necessary

structural

changes

on

the

system

while

still

maintaining

the

original

behavior

This

phase

makes

use

of

the

behavior

preserving

modifications

The

resulting

system

then

serves

as

a

platform

for

phase

two

which

only

needs

to

extend

the

behavior

without

having

to

deal

with

structural

problems

Hence

the

behavior

preserving

modifications

of

phase

one

constitute

a

critical

first

step

in

the

overall

extension

of

the

system

The

framework

consists

of

three

parts

First

it

describes

the

dependencies

between

the

main

components

of

an

object-oriented

system

and

defines

the

meaning

of

consistency

amongst

the

components

Second

it

defines

a

notion

of

behavioral

equivalence

between

evolving

versions

of

a

system

Third

it

presents

a

process

model

for

maintaining

consistency

and

behavior

of

the

system

's

components

The

framework

is

kept

independent

of

the

implementation

of

each

of

the

system

's

components

In

particular

it

does

not

rely

on

a

specific

underlying

object

model

or

programming

language

The

effectiveness

of

the

evolution

framework

is

enhanced

by

coupling

it

with

a

change

avoidance

and

anticipation

approach

The

philosophy

behind

the

change

avoidance

approach

is

quite

different

from

conventional

evolution

and

maintenance

approaches

While

conventional

approaches

employ

a

brute-force

method

to

fix

everything

that

becomes

inconsistent

after

a

schema

update

change

avoidance

employs

a

more

subtle

method

whose

goal

is

to

engineer

software

in

a

way

that

makes

it

adaptive

and

robust

to

schema

changes

Change

avoidance

tries

to

anticipate

or

fix

inconsistencies

before

they

occur

Thus

change

avoidance

can

be

characterized

as

an

active

as

opposed

to

reactive

update

mechanism

The

employed

change

avoidance

mechanism

is

based

on

the

Adaptive

ObjectOriented

Software

model

-LSB-

-RSB-

which

supports

change

avoidance

by

minimizing

dependencies

between

the

program

text

and

the

class

structure

Other

change

avoidance

approaches

support

evolution

at

the

more

coarse-grained

level

of

tool

integration

minimizing

dependencies

between

tools

-LSB-

-RSB-

Traditional

object-oriented

programs

build

undesirable

dependencies

when

hardcoding

the

details

of

the

class

structure

into

the

methods

Because

the

class

structure

specifies

the

relations

between

objects

and

since

object

collaboration

is

implemented

in

methods

by

sending

messages

along

these

relations

the

class

structure

becomes

hardcoded

into

the

methods

Consequently

changes

to

the

class

structure

require

changes

to

the

methods

Using

adaptive

software

changes

to

the

class

structure

require

only

minimal

program

maintenance

To

illustrate

the

impact

of

schema

evolution

on

program

consistency

consider

the

first

class

structure

shown

in

Figure

which

describes

a

simple

design

of

a

vehicle

registration

system

Rectangles

represent

classes

and

ovals

represent

primitive

classes

Thin

labeled

edges

represent

named

reference

relations

and

thick

unlabeled

edges

represent

inheritance

relations

The

figure

depicts

part

of

a

vehicle

registration

system

with

three

types

of

transport

vehicles

cars

trucks

and

trailers

The

classes

Car

and

Truck

have

an

attribute

numPassenger

and

the

class

Car

Truck

and

Trailer

inherit

an

attribute

vehID

from

class

TransportVehicle

Part

of

a

C++

program

for

the

task

of

printing

information

on

all

registered

transport

vehicles

within

a

registry

is

shown

alongside

the

figure

Original

Class

StructureRegistryTruckStringCarTrailerIntegervehIDATransport

Vehicle

regVehicle

Registry

Aregistered

TruckStringCarTrailerIntegervehIDTransport

Vehicle

vehicle

APassenger

Vehicle

RegistrationEvolved

Class

StructurenumPassengernumPassengernumPassenger

void

Registry

PrintRegistered

-LRB-

-RRB-

-LCB-

regVehicle

PrintRegistered

-LRB-

-RRB-

-RCB-

virtualvoid

TransportVehicle

PrintRegistered

-LRB-

-RRB-

-LCB-

cout

vehID

-RCB-

void

Car

PrintRegistered

-LRB-

-RRB-

-LCB-

cout

vehID

numPassenger

-RCB-

void

Truck

PrintRegistered

-LRB-

-RRB-

-LCB-

cout

vehID

numPassenger

-RCB-

void

Registry

PrintRegistered

-LRB-

-RRB-

-LCB-

registered

PrintRegistered

-LRB-

-RRB-

-RCB-

void

Registration

PrintRegistered

-LRB-

-RRB-

-LCB-

vehicle

PrintRegistered

-LRB-

-RRB-

-RCB-

virtualvoid

TransportVehicle

PrintRegistered

-LRB-

-RRB-

-LCB-

cout

vehID

-RCB-

void

PassengerVehicle

PrintRegistered

-LRB-

-RRB-

-LCB-

cout

vehID

numPassenger

-RCB-

Fig.

Example

Class

Transformation

If

the

original

class

structure

in

Figure

evolves

to

the

second

one

the

C++

code

requires

manual

update

to

maintain

behavior

and

consistency

with

the

evolved

class

structure

In

contrast

an

adaptive

program

could

be

written

such

that

it

remains

consistent

with

both

class

structures

and

exhibits

equivalent

behavior

In

general

an

adaptive

program

does

make

some

assumptions

on

the

class

structure

Therefore

there

are

cases

when

change

avoidance

is

not

sufficient

and

even

an

adaptive

program

needs

to

be

updated

to

maintain

consistency

and

behavior

Consequently

the

change

avoidance

approach

needs

to

be

coupled

with

a

change

management

mechanism

to

fully

automate

evolution

Most

change

management

mechanisms

of

object-oriented

systems

were

developed

in

the

database

community

addressing

the

problems

of

schema

evolution

with

emphasis

on

maintaining

the

consistency

of

the

schema

and

the

persistent

object

store

-LSB-

-RSB-

Recently

there

has

been

increasing

attention

on

the

issue

of

maintaining

behavioral

consistency

-LSB-

-RSB-

and

behavioral

equivalence

-LSB-

-RSB-

The

contributions

of

our

research

include

-LRB-

-RRB-

a

formal

definition

of

behavioral

equivalence

and

development

of

a

proof

technique

to

demonstrate

equivalence

of

adaptive

programs

-LRB-

-RRB-

the

presentation

of

a

set

of

primitive

class

structure

transformations

and

their

corresponding

object

and

program

transformations

-LRB-

-RRB-

the

definition

of

a

formal

and

fully

executable

semantics

for

Adaptive

Software

extending

the

one

in

-LSB-

-RSB-

and

-LRB-

-RRB-

the

demonstration

of

the

feasibility

of

the

framework

for

automatically

updating

a

software

system

during

schema

evolution

Due

to

space

limitations

the

application

of

the

framework

is

not

given

in

detail

In

particular

the

formal

definitions

of

the

transformations

and

their

equivalence

proofs

are

not

included

in

this

paper

but

can

be

found

in

-LSB-

-RSB-

The

paper

is

organized

as

follows

Section

details

our

framework

for

evolution

by

defining

behavioral

equivalence

and

an

evolution

process

model

Section

demonstrates

the

feasibility

of

the

framework

using

the

Adaptive

Software

model

and

a

representative

set

of

primitive

schema

transformations

To

illustrate

the

proof

mechanism

for

behavioral

equivalence

an

example

transformation

is

presented

The

appendix

formally

defines

the

underlying

object-oriented

data

and

behavioral

model

including

the

semantics

of

Adaptive

Software

Software

Evolution

Framework

The

evolution

framework

characterizes

and

supports

the

process

of

transforming

an

object-oriented

system

from

one

consistent

state

to

another

while

preserving

the

behavior

of

the

system

This

section

defines

the

relevant

system

components

the

evolution

process

model

and

the

notions

of

system

consistency

and

behavioral

equivalence

System

Consistency

For

the

purpose

of

this

paper

the

relevant

components

of

an

object-oriented

system

are

-LRB-

-RRB-

a

schema

-LRB-

-RRB-

a

run-time

environment

including

a

persistent

object

store

and

-LRB-

-RRB-

a

program

consisting

of

a

set

of

methods

The

overall

consistency

of

a

system

relies

on

both

the

inter

and

intra-component

consistency

which

depend

on

the

underlying

data

and

program

language

model

The

consistency

of

a

schema

is

defined

in

terms

of

a

set

of

schema

invariants

that

must

hold

in

every

quiescent

state

of

the

system

Schema

consistency

is

also

referred

to

as

well-formedness

Rather

than

checking

schema

consistency

after

performing

a

schema

transformation

a

set

of

preconditions

may

be

defined

for

a

given

transformation

which

ensure

that

schema

consistency

will

be

maintained

The

schema

constrains

the

consistency

of

both

the

objects

and

the

program

-LRB-

see

Figure

-RRB-

Object

consistency

is

also

constrained

by

the

employed

data

model

which

may

enforce

additional

data

integrity

constraints

Program

consistency

is

additionally

constrained

by

the

rules

of

the

programming

language

A

notion

of

consistency

between

programs

and

objects

is

defined

by

transitivity

through

their

consistency

with

the

schema

Of

course

system

consistency

does

not

imply

program

correctness

swpconsistent

tconsistentPP

SS

OO

computes

with

computes

with

Fig.

Schema

Object

and

Program

Transformations

Behavioral

Equivalence

Figure

illustrates

the

evolution

of

an

object-oriented

system

hS

O

Pi

characterized

by

the

three

interrelated

components

schema

objects

and

program

Given

a

schema

transformation

oe

it

is

necessary

to

apply

an

object

transformation

and

a

program

transformation

ss

to

the

object

store

and

program

respectively

to

maintain

the

consistency

of

the

system

The

transformation

of

the

system

as

a

whole

is

thus

described

by

the

triple

o

hoe

ssi

Figure

illustrates

the

notion

of

behavioral

equivalence

The

behavior

preservation

problem

presents

itself

as

follows

given

the

software

system

hS

O

Pi

and

the

transformations

oe

and

find

a

program

transformation

ss

such

that

the

transformed

program

working

on

the

transformed

objects

behaves

like

the

original

program

working

on

the

original

objects

A

difficulty

arises

when

comparing

the

two

resulting

environments

of

the

programs

P

and

P

The

two

environments

can

not

be

directly

tested

for

equality

since

they

belong

to

two

different

class

structures

namely

S

and

S

What

is

actually

meant

is

that

the

resulting

state

of

P

must

correspond

to

the

resulting

state

of

P

with

the

correspondence

relation

being

the

object

transformation

Formally

behavioral

equivalence

can

be

defined

by

requiring

that

the

diagram

in

Figure

commute

Assume

o

is

a

system

transformation

o

hoe

ssi

in

a

software

system

with

schema

S

and

program

P

Let

O

and

O

be

two

environments

for

schema

S

such

that

O

is

the

resulting

environment

after

executing

P

on

the

run-time

environment

initialized

by

O

If

Run

is

the

partial

function

that

executes

the

program

P

on

the

object

environment

O

then

the

resulting

environment

is

denoted

by

O

Run

-LRB-

P

O

-RRB-

Similarly

let

O

and

O

be

two

environments

for

schema

oe

-LRB-

S

-RRB-

such

that

O

Run

-LRB-

-RRB-

wwOO

SS

wO

-LRB-

O

-RRB-

w

-LRB-

O

-RRB-

O

Run

-LRB-

P

O

-RRB-

Run

-LRB-

P

O

-RRB-

Fig.

Behavioral

Equivalence

The

diagram

in

Figure

commutes

if

the

following

equation

holds

for

all

environments

O

consistent

with

S.

Run

-LRB-

-LRB-

O

-RRB-

-RRB-

-LRB-

Run

-LRB-

P

O

-RRB-

-RRB-

or

equivalently

Run

ffi

ffi

Run

The

above

notion

of

behavioral

equivalence

is

a

partial

equivalence

that

is

the

equality

only

holds

when

Run

terminates

This

form

of

equivalence

has

also

been

termed

weak

equivalence

-LSB-

-RSB-

Process

Model

of

the

Framework

Following

the

activity

flow

of

most

life-cycle

models

changes

to

the

system

are

introduced

first

at

the

more

abstract

design

level

In

object-oriented

systems

changes

are

typically

first

introduced

to

the

schema

A

transformation

applied

to

the

schema

may

cause

previously

existing

objects

and

programs

to

be

inconsistent

with

the

new

schema

Thus

the

changes

must

subsequently

be

propagated

further

to

the

object

store

and

the

code

Given

a

specific

instance

of

a

system

transformation

o

hoe

ssi

and

given

a

schema

S

a

program

P

consistent

with

S

and

an

environment

O

consistent

with

S

the

following

process

will

be

performed

to

restore

consistency

Check

that

S

satisfies

the

preconditions

of

the

transformation

Apply

the

schema

transformation

oe

such

that

oe

-LRB-

S

-RRB-

Apply

the

object

transformation

such

that

-LRB-

O

-RRB-

Apply

the

program

transformation

ss

such

that

ss

-LRB-

P

-RRB-

The

goal

of

the

system

transformations

is

to

restore

consistency

and

maintain

behavior

Consequently

when

defining

a

type

of

schema

transformation

object

and

program

transformations

must

be

defined

along

with

it

and

it

must

be

proven

that

consistency

and

behavioral

equivalence

hold

each

time

a

specific

instance

of

the

transformation

is

applied

The

following

template

process

for

the

definition

of

a

system

transformation

is

used

Define

schema

transformation

oe

such

that

oe

-LRB-

S

-RRB-

Define

a

set

of

preconditions

that

guarantees

S

is

well-formed

Define

object

transformation

such

that

-LRB-

O

-RRB-

Prove

-LRB-

O

-RRB-

consistent

with

S

Define

program

transformation

ss

such

that

ss

-LRB-

P

-RRB-

-LRB-

a

-RRB-

Prove

that

ss

-LRB-

P

-RRB-

is

consistent

with

S

-LRB-

b

-RRB-

Prove

that

P

and

ss

-LRB-

P

-RRB-

are

behaviorally

equivalent

Application

of

Framework

The

above

framework

is

generally

applicable

to

the

evolution

process

of

objectoriented

systems

independent

of

the

employed

programming

and

schema

description

language

To

demonstrate

its

feasibility

the

framework

is

applied

using

-LRB-

-RRB-

a

specific

schema

and

programming

model

the

adaptive

software

model

-LSB-

-RSB-

and

-LRB-

-RRB-

a

set

of

schema

transformations

As

part

of

the

research

presented

in

this

paper

a

fully

executable

semantics

of

adaptive

software

has

been

developed

both

to

demonstrate

proof

of

concept

and

to

be

able

to

prove

behavioral

equivalence

The

next

subsection

briefly

introduces

the

basic

concepts

of

Adaptive

Software

For

a

more

detailed

discussion

refer

to

-LSB-

-RSB-

and

-LSB-

-RSB-

The

formal

semantics

is

given

in

the

appendix

This

section

also

presents

a

comprehensive

set

of

thirteen

primitive

schema

transformations

which

have

been

selected

to

show

the

framework

's

versatility

Adaptive

Software

In

contrast

to

many

other

object-oriented

models

adaptive

software

supports

the

decoupling

of

behavior

from

structure

As

a

consequence

the

structural

and

the

behavioral

parts

of

the

schema

are

textually

separated

with

minimal

dependency

between

them

The

structural

part

is

modeled

as

a

class

graph

where

vertices

represent

concrete

and

abstract

classes

and

edges

represent

inheritance

and

reference

relations

The

behavioral

part

of

an

adaptive

program

consists

of

a

collection

of

propagation

patterns

each

implementing

a

specific

task

performed

by

a

group

of

collaborating

classes

An

adaptive

program

is

written

at

a

higher

schematic

level

that

abstracts

the

details

of

object

traversal

and

navigation

Different

tasks

tend

to

exhibit

similar

traversal

paths

in

the

class

structure

These

traversal

patterns

are

effectively

separated

from

the

other

aspects

of

the

task

A

similar

motivation

is

found

behind

several

design

patterns

as

described

in

-LSB-

-RSB-

including

the

Visitor

Observer

and

Chain

of

Responsibility

patterns

A

propagation

pattern

consists

of

three

parts

-LRB-

-RRB-

a

name

N

for

the

task

-LRB-

-RRB-

a

propagation

directive

D

that

specifies

the

group

of

collaborating

classes

and

a

set

of

traversal

paths

among

them

and

-LRB-

-RRB-

a

functional

component

that

specifies

the

task

's

behavior

aside

from

traversal

as

a

set

M

of

method

bodies

written

in

some

object-oriented

programming

language

A

propagation

pattern

is

not

executable

on

its

own

since

it

is

underspecified

with

respect

to

the

class

structure

A

propagation

pattern

becomes

executable

when

it

is

instantiated

with

a

particular

class

graph

In

this

sense

it

is

a

kind

of

metaprogramming

-LSB-

-RSB-

Often

the

consistency

and

behavioral

equivalence

of

the

high-level

adaptive

program

is

maintained

when

the

class

structure

evolves

As

an

example

of

an

adaptive

program

consider

again

the

first

class

structure

shown

in

Figure

A

propagation

pattern

for

the

task

of

printing

information

of

all

registered

transport

vehicles

within

a

registry

is

given

below

OPERATION

void

PrintRegistered

-LRB-

-RRB-

DIRECTIVE

-LSB-

Registry

TransportVehicle

-RSB-

PREFIX

TransportVehicle

-LCB-

cout

vehID

-RCB-

PREFIX

Car

Truck

-LCB-

cout

vehID

numPassenger

-RCB-

The

name

of

the

task

is

PrintRegistered

The

directive

selects

the

paths

in

the

class

graph

between

Registry

and

TransportVehicle

The

functional

component

consists

of

two

method

bodies

one

for

class

TransportVehicle

and

one

for

the

classes

Car

and

Truck

During

traversal

the

vehID

of

all

TransportVehicle

objects

and

the

numPassenger

of

all

Car

and

Truck

objects

will

be

printed

In

general

method

bodies

can

be

written

in

any

object-oriented

programming

language

e.g.

C++

If

the

class

structure

in

Figure

evolves

to

the

second

one

the

adaptive

program

can

simply

be

instantiated

with

the

evolved

class

structure

The

resulting

program

would

continue

to

correctly

implement

the

task

since

there

still

exists

a

path

from

Registry

to

TransportVehicle

In

contrast

conventional

object-oriented

programs

require

manual

update

of

the

code

Primitive

Transformations

The

goal

of

the

framework

is

to

maintain

behavior

therefore

of

the

transformations

may

delete

information

from

the

object

store

For

example

the

deletion

of

a

concrete

class

would

cause

the

subsequent

deletion

of

all

instances

of

that

class

and

thus

previous

behavior

could

not

be

preserved

In

general

the

framework

allows

only

transformations

that

are

information

preserving

The

following

list

covers

a

variety

of

schema

modifications

In

particular

it

includes

all

the

object-preserving

and

the

object-extending

transformations

from

-LSB-

-RSB-

For

a

formal

definition

of

each

transformation

refer

to

-LSB-

-RSB-

Figure

illustrates

most

of

the

transformations

The

figure

presents

a

sequence

of

incremental

transformations

applied

to

the

initial

class

graph

number

one

-LCB-

Addition

of

Concrete

Class

-LRB-

AddC

-RRB-

adds

a

new

concrete

class

without

any

incoming

or

outgoing

edges

-LRB-

class

graph

number

-RRB-

CarTruckTrailerIntegerRegistryRegistrationregisteredTransport

Vehicle

Original

Class

Telescoping

of

Reference

-LRB-

TelR

-RRB-

Addition

of

Concrete

Class

-LRB-

AddC

-RRB-

Addition

of

Reference

-LRB-

AddR

-RRB-

Distribution

of

Common

Reference

-LRB-

DisR

-RRB-

Addition

of

Abstract

Class

-LRB-

AddA

-RRB-

Abstraction

of

Common

Reference

-LRB-

AbsR

-RRB-

Replacement

of

Reference

-LRB-

RepR

-RRB-

Deletion

of

Abstract

Class

-LRB-

DelA

-RRB-

Generalization

of

Reference

-LRB-

GenR

-RRB-

StringRegistryregisteredCarTruckTrailerIntegerTransport

Vehicle

AvehIDStringvehIDnumPassengernumPassengernumPassengernumPassengerCarTr

Vehicle

AvehiclePersonStringvehIDnumPassengernumPassengerCarTruckTrailerIntege

Vehicle

AvehiclePersonseizedownerStringvehIDnumPassengernumPassengerStringCarT

Vehicle

AvehiclePersonseizedownervehIDvehIDnumPassengernumPassengervehIDString

vehIDCarTruckTrailerIntegerRegistryRegistrationregisteredvehiclePerson

seizedownervehIDTransport

Vehicle

AAAPassenger

Vehicle

Registered

Vehicle

vehIDnumPassengernumPassengerStringvehIDCarTruckTrailerRegistryRegistr

ationregisteredvehiclePersonseizedownerTransport

Vehicle

AARegistered

Vehicle

IntegerAPassenger

Vehicle

numPassengerStringvehIDCarTruckTrailerRegistryRegistrationregisteredve

hiclePersonseizedownerTransport

Vehicle

AARegistered

Vehicle

IntegerAPassenger

Vehicle

hiclePersonseizedownerIntegerAPassenger

Vehicle

ARegistered

Vehicle

hiclePersonseizedownerIntegerAPassenger

Vehicle

ARegistered

Vehicle

numPassenger

Fig.

Class

Graph

Transformations

-LCB-

Addition

of

Subclass

-LRB-

AddS

-RRB-

adds

a

new

class

as

a

subclass

of

an

existing

abstract

class

-LCB-

Addition

of

Abstract

Class

-LRB-

AddA

-RRB-

adds

a

new

abstract

class

to

the

class

graph

The

new

abstract

class

has

neither

incoming

nor

outgoing

reference

edges

and

no

outgoing

inheritance

edges

It

may

have

incoming

inheritance

edges

from

existing

classes

in

the

graph

-LRB-

number

applied

twice

-RRB-

-LCB-

Deletion

of

Abstract

Class

-LRB-

DelA

-RRB-

is

the

opposite

transformation

of

-LRB-

AddA

-RRB-

where

an

abstract

class

is

deleted

from

the

graph

The

class

to

be

deleted

must

not

have

any

incoming

or

outgoing

reference

edges

nor

outgoing

inheritance

edges

-LRB-

number

-RRB-

-LCB-

Addition

of

Reference

-LRB-

AddR

-RRB-

adds

a

reference

edge

between

two

existing

classes

-LRB-

number

applied

twice

-RRB-

-LCB-

Abstraction

of

Common

Reference

-LRB-

AbsR

-RRB-

abstracts

a

reference

edge

that

a

group

of

subclasses

have

in

common

by

moving

the

edge

up

the

inheritance

hierarchy

to

a

common

superclass

-LRB-

number

applied

three

times

-RRB-

-LCB-

Distribution

of

Common

Reference

-LRB-

DisR

-RRB-

performs

class

flattening

where

a

reference

edge

is

pushed

down

the

inheritance

hierarchy

from

a

superclass

to

all

of

its

direct

subclasses

-LRB-

number

-RRB-

-LCB-

Replacement

of

Reference

-LRB-

RepR

-RRB-

reroutes

the

target

of

a

reference

edge

from

one

abstract

class

v

to

another

abstract

class

w

where

v

and

w

have

the

same

set

of

concrete

subclasses

-LRB-

number

-RRB-

-LCB-

Generalization

of

Reference

-LRB-

GenR

-RRB-

reroutes

the

target

of

a

reference

edge

from

a

subclass

to

its

superclass

-LRB-

number

applied

twice

-RRB-

-LCB-

Renaming

of

Class

-LRB-

RenC

-RRB-

renames

a

class

while

preserving

the

property

that

all

classes

are

uniquely

named

-LCB-

Renaming

of

Reference

-LRB-

RenR

-RRB-

renames

the

label

of

a

reference

edge

while

preserving

the

property

that

all

direct

and

inherited

references

for

a

class

are

uniquely

labeled

-LCB-

Telescoping

of

Reference

-LRB-

TelR

-RRB-

replaces

a

single

reference

edge

between

vertices

with

two

reference

edges

routing

through

another

vertex

-LRB-

number

-RRB-

-LCB-

Telescoping

of

Inheritance

-LRB-

TelI

-RRB-

replaces

a

single

inheritance

edge

between

two

vertices

with

two

inheritance

edges

that

route

through

another

vertex

For

each

of

the

above

schema

transformations

the

template

process

as

outlined

by

the

process

model

in

Section

has

been

followed

identifying

the

preconditions

for

the

class

graph

transformation

as

well

as

the

necessary

object

and

program

transformations

including

the

proofs

of

consistency

and

equivalence

Due

to

space

limitations

only

one

representative

transformation

is

discussed

in

full

for

the

others

refer

to

-LSB-

-RSB-

Proof

Techniques

Of

the

steps

prescribed

by

the

evolution

framework

proving

behavioral

equivalence

-LRB-

step

-RRB-

is

substantially

more

involved

than

the

others

The

ultimate

goal

of

proving

equivalence

is

accomplished

by

showing

that

Run

-LRB-

-LRB-

O

-RRB-

-RRB-

-LRB-

Run

-LRB-

P

O

-RRB-

-RRB-

In

adaptive

software

an

executable

program

PG

results

from

instantiation

of

a

propagation

pattern

P

-LRB-

N

D

M

-RRB-

with

a

given

class

graph

G.

Running

the

program

PG

means

executing

method

bodies

in

M

while

traversing

the

class

graph

according

to

the

path

set

defined

by

the

propagation

directive

D

starting

from

a

given

initial

object

o

O

-LRB-

see

appendix

A.

-RRB-

In

short

Run

-LRB-

PG

O

-RRB-

TravG

M

-LRB-

o

PathSet

-LRB-

G

D

-RRB-

O

-RRB-

The

traversal

of

the

propagation

pattern

in

the

class

graph

G

is

computed

by

the

function

Trav

Proving

behavioral

equivalence

then

means

showing

that

M

-LRB-

o

PathSet

-LRB-

-RRB-

-LRB-

O

-RRB-

-RRB-

-LRB-

TravG

M

-LRB-

o

PathSet

-LRB-

G

D

-RRB-

O

-RRB-

-RRB-

Note

that

o

refers

to

the

object

ID

and

is

therefore

not

subject

to

the

transformation

The

proof

technique

depicted

in

Figure

is

employed

to

show

this

equality

The

technique

consists

of

four

building

blocks

The

major

work

is

done

by

a

traversal

theorem

which

proves

the

desired

equality

The

traversal

theorem

typically

relies

on

path

set

equivalence

and

method

execution

equivalence

which

in

turn

relies

on

method

lookup

equivalence

-LRB-

see

details

in

the

appendix

-RRB-

Lookup

Lookup

Execute

Execute'PathSet

PathSet

Lookup

Lemma

Execute

Lemma

PathSet

Lemma

Trav

Trav

Traversal

Theorem

Fig.

Behavioral

Equivalence

Proof

Technique

Example

Distribution

of

Common

Reference

Distribution

of

common

reference

-LRB-

DisR

-RRB-

moves

a

reference

of

type

w

from

a

superclass

v

to

all

its

direct

subclasses

vn

The

reference

will

be

duplicated

in

the

subclasses

rather

than

inherited

from

v.

Class

graph

transformation

The

class

graph

transformation

oe

is

defined

by

the

operation

DisR

-LRB-

G

v

w

-RRB-

which

produces

a

class

graph

such

that

the

direct

reference

-LRB-

w

-RRB-

is

dropped

from

v

and

added

to

all

subclasses

of

v

The

preconditions

to

guarantee

consistency

of

the

transformed

schema

are

that

v

must

be

a

superclass

with

a

direct

reference

labeled

of

type

w.

Environment

transformation

Any

object

in

O

consistent

with

G

is

also

consistent

with

G

Therefore

the

object

transformation

is

simply

the

identity

transformation

I

implying

-LRB-

O

-RRB-

O.

Program

transformation

The

original

propagation

directive

remains

compatible

with

the

class

graph

The

set

of

method

bodies

needs

to

be

modified

if

there

existed

a

method

body

for

v

that

refers

to

the

distributed

reference

variable

In

that

case

the

method

body

may

not

be

statically

correct

for

G

and

the

programming

language

used

in

the

method

body

The

inconsistency

is

corrected

by

pushing

such

a

method

body

down

to

the

direct

subclasses

of

v

each

of

which

now

contains

the

reference

The

program

transformation

ss

must

produce

a

new

method

body

attachement

scheme

M

in

which

a

method

attached

to

v

is

pushed

down

to

those

direct

subclasses

of

v

that

do

n't

define

their

own

method

Program

consistency

Consistency

of

the

propagation

pattern

P

with

G

and

the

method

body

language

continues

to

hold

Although

the

method

attachment

M

was

changed

its

bodies

remained

unchanged

and

M

is

therefore

still

syntactically

correct

Static

correctness

is

also

unchanged

Behavioral

equivalence

Behavioral

equivalence

can

be

shown

by

using

the

Traversal

Theorem

The

prerequisites

can

be

shown

to

hold

In

particular

the

set

of

paths

defined

by

the

original

propagation

directive

stays

the

same

in

both

class

graphs

PathSet

-LRB-

G

D

-RRB-

PathSet

-LRB-

D

-RRB-

using

the

PathSet

Lemma

In

addition

since

the

method

bodies

were

not

changed

by

the

transformation

and

since

DisR

does

not

introduce

problems

of

scoping

for

class

graphs

it

is

straightforward

to

show

the

execution

premise

for

DisR

To

prove

that

the

method

lookup

remains

invariant

the

DisR-Lookup

Lemma

is

employed

This

concludes

the

steps

of

the

process

model

for

DisR

The

majority

of

transformations

follow

a

similar

pattern

for

proving

equivalence

and

utilize

the

general

set

of

techniques

that

were

briefly

discussed

in

section

Individual

transformations

might

require

specialized

proofs

Conclusion

A

formal

framework

for

maintaining

behavior

and

consistency

of

object-oriented

systems

during

software

evolution

has

been

presented

The

framework

constitutes

a

novel

approach

in

software

maintenance

by

coupling

a

change

avoidance

with

a

change

management

mechanism

to

fully

automate

evolution

As

part

of

our

research

a

formal

semantics

for

adaptive

software

was

defined

together

with

a

set

of

proof

techniques

for

the

semantics

Both

were

used

to

prove

partial

behavioral

equivalence

of

the

transformed

and

the

original

system

The

semantics

is

currently

being

implemented

at

the

XEROX

Palo

Alto

Research

Center

using

S

an

experimental

object-oriented

version

of

Scheme

The

feasibility

of

the

framework

was

demonstrated

by

applying

it

to

a

representative

primitive

class

structure

transformation

The

framework

eliminates

the

need

for

program-based

regression

testing

for

certain

transformations

Future

work

will

include

investigating

additional

primitive

transformations

which

require

a

more

detailed

analysis

of

the

method

bodies

Behavior

extending

transformations

are

another

interesting

topic

to

be

explored

For

example

the

addition

of

an

attribute

to

a

class

is

usually

followed

by

an

extension

of

the

program

to

manipulate

and

modify

the

added

attribute

Such

transformations

will

need

more

semantic

information

to

enable

program

updates

Finally

the

authors

are

currently

working

on

an

extended

semantics

of

Adaptive

Software

which

introduces

Adaptive

Behavioral

Components

-LRB-

ABCs

-RRB-

as

a

novel

programming

construct

that

represents

a

level

of

abstraction

above

the

class

level

ABCs

allow

the

encapsulation

of

a

slice

of

behavior

into

a

single

program

unit

in

an

adaptive

manner

-LSB-

-RSB-

Acknowlegdments

Many

useful

comments

on

earlier

drafts

were

received

by

Karl

Lieberherr

Cristina

Lopes

Will

Clinger

and

Betty

Salzberg

This

work

has

been

partially

supported

by

the

National

Science

Foundation

under

grant

numbers

-LRB-

Research

Instrumentation

-RRB-

and

-LRB-

Software

Engineering

-RRB-

The

first

author

was

supported

by

a

research

grant

from

Mettler-Toledo

AG

Switzerland

while

at

Northeastern

University

References

J.

Banerjee

W.

Kim

H.-J

Kim

and

H.

F.

Korth

Semantics

and

Implementation

of

Schema

Evolution

in

Object-Oriented

Databases

In

Proceedings

of

ACM/SIGMOD

Annual

Conference

on

Management

of

Data

pages

-LCB-

San

Francisco

California

December

ACM

Press

SIGMOD

Record

Vol

No.

P.

Bergstein

Object-Preserving

Class

Transformations

In

Object-Oriented

Programming

Systems

Languages

and

Applications

Conference

in

Special

Issue

of

SIGPLAN

Notices

pages

-LCB-

Phoenix

Arizona

ACM

Press

SIG

PLAN

Notices

Vol

-LRB-

November

-RRB-

P.

L.

Bergstein

Managing

the

Evolution

of

Object-Oriented

Systems

PhD

thesis

College

of

Computer

Science

Northeastern

University

Boston

MA

June

P.

L.

Bergstein

and

W.

L.

H?ursch

Maintaining

Behavioral

Consistency

during

Schema

Evolution

In

S.

Nishio

and

A.

Yonezawa

editors

International

Symposium

on

Object

Technologies

for

Advanced

Software

pages

-LCB-

Kanazawa

Japan

November

JSSST

Springer

Verlag

Lecture

Notes

in

Computer

Science

V.

Berzins

Luqi

and

A.

Yehudai

Using

Transformations

in

Specification-Based

Prototyping

IEEE

Transactions

on

Software

Engineering

-LRB-

-RRB-

-LCB-

May

C.

Delcourt

and

R.

Zicari

The

Design

of

an

Integrity

Consistency

Checker

-LRB-

ICC

-RRB-

for

an

Object

Oriented

Database

System

In

P.

America

editor

European

Conference

on

Object-Oriented

Programming

pages

-LCB-

Geneva

Switzerland

July

Springer

Verlag

Lecture

Notes

in

Computer

Science

Vol

E.

Gamma

R.

Helm

R.

Johnson

and

J.

Vlissides

Design

Patterns

Elements

of

Reusable

Object-Oriented

Software

Professional

Computing

Series

AddisonWesley

Reading

MA

October

ISBN

W.

L.

H?ursch

Should

Superclasses

be

Abstract

In

European

Conference

on

Object-Oriented

Programming

Bologna

Italy

July

Springer

Verlag

Lecture

Notes

in

Computer

Science

W.

L.

H?ursch

Maintaining

Consistency

and

Behavior

of

Object-Oriented

Systems

during

Evolution

PhD

thesis

College

of

Computer

Science

Northeastern

University

Boston

MA

September

W.

L.

H?ursch

and

L.

M.

Keszenheimer

Automating

the

Evolution

of

ObjectOriented

Systems

Technical

Report

College

of

Computer

Science

Northeastern

University

Boston

MA

April

K.

Jameson

Multi-Platform

Code

Management

O'Reilly

Associates

Inc.

Sebastopol

CA

August

ISBN

G.

Kiczales

Towards

a

New

Model

of

Abstraction

in

the

Engineering

of

Software

In

International

Workshop

on

Reflection

and

Meta-Level

Architecture

Tama-City

Tokyo

Japan

November

B.

S.

Lerner

and

A.

N.

Habermann

Beyond

Schema

Evolution

to

Database

Reorganization

In

N.

Meyrowitz

editor

Proceedings

OOPSLA/ECOOP

pages

-LCB-

Ottawa

Canada

October

ACM

Press

Special

Issue

of

SIGPLAN

Notices

Vol

No.

K.

J.

Lieberherr

Adaptive

Object-Oriented

Software

The

Demeter

Method

with

Propagation

Patterns

PWS

Publishing

Company

Boston

ISBN

K.

J.

Lieberherr

W.

L.

H?ursch

and

C.

Xiao

Object-Extending

Class

Transformations

Formal

Aspects

of

Computing

-LCB-

July

K.

J.

Lieberherr

I.

Silva-Lepe

and

C.

Xiao

Adaptive

Object-Oriented

Programming

using

Graph-Based

Customization

Communications

of

the

ACM

-LRB-

-RRB-

May

W.

F.

Opdyke

and

R.

E.

Johnson

Refactoring

An

Aid

in

Designing

Application

Frameworks

and

Evolving

Object-Oriented

Systems

In

Proceedings

of

the

Symposium

on

Object-Oriented

Programming

emphasizing

Practical

Applications

-LRB-

SOOPA

-RRB-

pages

-LCB-

Poughkeepsie

NY

September

ACM

J.

Palsberg

C.

Xiao

and

K.

Lieberherr

Efficient

Implementation

of

Adaptive

Software

ACM

Transactions

on

Programming

Languages

and

Systems

-LRB-

-RRB-

-LCB-

Mar.

L.

M.

Seiter

W.

L.

H?ursch

and

K.

J.

Lieberherr

Composing

Collaborations

Using

Adaptive

Behavioral

Components

Technical

Report

College

of

Computer

Science

Northeastern

University

Boston

MA

December

K.

J.

Sullivan

and

D.

Notkin

Reconciling

Environment

Integration

and

Software

Evolution

ACM

Transaction

on

Software

Engineering

and

Methodology

-LRB-

-RRB-

-LCB-

July

T.

Watanabe

and

A.

Yonezawa

Reflection

in

an

Object-Oriented

Concurrent

Language

In

A.

Yonezawa

editor

ABCL

An

Object-Oriented

Concurrent

System

chapter

pages

-LCB-

The

MIT

Press

Cambridge

Massachusetts

ISBN

R.

Zicari

A

Framework

for

Schema

Updates

in

an

Object-Oriented

Database

System

In

F.

Bancilhon

C.

Delobel

and

P.

Kanellakis

editors

Building

an

ObjectOriented

Database

System

the

Story

of

chapter

pages

-LCB-

Morgan

Kaufmann

San

Mateo

CA

ISBN

A

Appendix

Formal

Semantics

of

Adaptive

Software

A.

Data

Model

Class

graph

A

class

graph

denoted

G

-LRB-

V

E

L

-RRB-

is

a

finite

labeled

directed

graph

where

V

is

a

set

of

vertices

E

V

V

is

a

set

of

edges

and

L

is

a

set

of

labels

Each

vertex

represents

either

an

abstract

or

a

concrete

class

and

each

edge

represents

either

an

inheritance

or

a

reference

relationship

between

classes

The

set

of

vertices

V

is

partitioned

into

three

disjoint

sets

V

V

A

-LSB-

V

C

-LSB-

V

P

where

V

A

represents

a

set

of

abstract

classes

V

C

represents

a

set

of

concrete

nonprimitive

classes

and

V

P

represents

a

set

of

concrete

primitive

classes

The

predicate

Abstract

is

true

of

vertices

that

represent

abstract

classes

and

is

false

otherwise

The

set

of

abstract

vertices

is

defined

as

V

A

fv

V

j

Abstract

-LRB-

v

-RRB-

g

The

set

of

primitive

vertices

is

defined

as

V

P

fInteger

Real

String

Booleang

Finally

V

C

fv

V

V

P

j

Abstract

-LRB-

v

-RRB-

g

contains

all

concrete

vertices

not

in

V

P

Vertices

are

labeled

by

the

function

Classname

V

LV

that

assigns

each

vertex

v

a

unique

class

name

Classname

-LRB-

v

-RRB-

LV

where

LV

L

It

is

assumed

that

-LRB-

LV

<=-RRB-

is

a

total

order

Example

for

class

graph

in

Figure

V

A

fTransportVehicleg

V

C

fRegistry

Car

Truck

Trailerg

Each

edge

is

labeled

by

an

element

of

LE

-LSB-

f?g

where

LE

L

If

an

edge

e

-LRB-

u

v

-RRB-

has

a

label

then

e

is

called

an

inheritance

edge

indicating

that

the

class

represented

by

u

is

a

subclass

of

the

class

represented

by

v.

Inheritance

edges

are

restricted

to

-LRB-

V

C

-LSB-

V

A

-RRB-

V

A

that

is

primitive

classes

can

not

inherit

from

other

classes

and

superclasses

must

be

The

set

of

inheritance

edges

is

denoted

EI

The

inheritance

edges

define

a

relation

=-RRB-

on

V

V

A

such

that

for

every

u

V

and

v

V

A

u

-RRB-

v

if

and

only

if

-LRB-

u

v

-RRB-

EI

The

transitive

and

the

reflexive

transitive

closure

of

the

=-RRB-

relation

are

denoted

by

=-RRB-

and

=-RRB-

respectively

Example

Car

-RRB-

TransportVehicle

A

vertex

v

V

A

is

considered

to

be

inheritance

reachable

from

vertex

u

V

if

and

only

if

u

-RRB-

v

The

set

of

all

direct

sub

and

superclasses

of

v

and

the

set

of

all

sub

and

superclasses

of

v

are

defined

as

follows

DirectSubclasses

-LRB-

v

-RRB-

fuju

-RRB-

vg

DirectSuperclasses

-LRB-

v

-RRB-

fujv

-RRB-

ug

Subclasses

-LRB-

v

-RRB-

fuju

-RRB-

vg

Superclasses

-LRB-

v

-RRB-

fujv

-RRB-

ug

Subclasses

-LRB-

v

-RRB-

fuju

-RRB-

vg

Superclasses

-LRB-

v

-RRB-

fujv

-RRB-

ug

If

an

edge

e

-LRB-

u

v

-RRB-

has

a

label

LE

then

e

is

sometimes

written

-LRB-

u

v

-RRB-

and

is

called

a

reference

edge

indicating

that

the

class

represented

by

u

has

an

instance

variable

named

with

a

class

type

represented

by

v.

ER

denotes

the

set

of

references

edges

Reference

edges

are

restricted

to

-LRB-

V

C

-LSB-

V

A

-RRB-

V

that

is

primitive

classes

can

not

have

references

It

is

assumed

that

-LRB-

LE

<=-RRB-

is

a

total

order

so

that

for

each

vertex

its

outgoing

reference

edges

are

ordered

The

set

of

inheritance

edges

EI

and

the

set

of

reference

edges

ER

build

a

partition

of

the

set

of

all

edges

E

ER

-LSB-

EI

The

reference

relation

expresses

direct

and

inherited

references

between

vertices

in

G.

For

two

vertices

u

and

v

the

reference

relation

u

v

holds

if

and

only

if

one

of

the

following

holds

-LRB-

-RRB-

LE

-LRB-

u

v

-RRB-

ER

-LRB-

direct

reference

-RRB-

-LRB-

-RRB-

V

A

LE

s.t.

u

-RRB-

w

and

-LRB-

w

v

-RRB-

ER

-LRB-

inherited

reference

-RRB-

The

set

of

direct

references

of

v

is

defined

as

DirectRefs

-LRB-

v

-RRB-

f

-LRB-

u

-RRB-

j

-LRB-

v

u

-RRB-

ERg

The

set

of

-LRB-

direct

and

inherited

-RRB-

references

of

v

is

defined

as

Refs

-LRB-

v

-RRB-

f

-LRB-

u

-RRB-

jv

ug

The

set

of

reference

labels

of

V

is

defined

as

RefLabels

-LRB-

v

-RRB-

f

j

-LRB-

u

-RRB-

Refs

-LRB-

v

-RRB-

g

For

example

Refs

-LRB-

Car

-RRB-

f

-LRB-

numPassenger

Integer

-RRB-

-LRB-

vehID

String

-RRB-

g

A

vertex

v

V

is

considered

to

be

reference

reachable

from

vertex

u

V

if

and

only

if

u

v

A

class

graph

is

well-formed

if

there

are

no

inheritance

cycles

every

reference

of

a

class

has

a

unique

label

and

every

class

is

uniquely

labeled

All

class

graphs

in

this

paper

are

assumed

to

be

well-formed

The

concrete

subclass

operator

C

maps

a

given

vertex

to

the

set

of

all

its

concrete

subclasses

C

-LRB-

v

-RRB-

fu

V

Cju

-RRB-

vg

Similarly

C

maps

a

given

edge

to

the

set

of

edges

connecting

all

the

concrete

subclasses

C

-LRB-

u

v

-RRB-

f

-LRB-

-RRB-

C

-LRB-

u

-RRB-

and

C

-LRB-

v

-RRB-

g

It

is

straightforward

to

extend

C

to

sets

of

vertices

and

sets

of

edges

Example

C

-LRB-

Car

-RRB-

fCarg

C

-LRB-

TransportVehicle

-RRB-

fCar

Truck

Trailerg

Object

graph

An

object

graph

is

a

finite

connected

directed

graph

-LRB-

V

E

L

-RRB-

representing

a

group

of

objects

inter-connected

through

reference

relations

Each

vertex

represents

an

object

and

the

function

Class

maps

each

vertex

to

its

class

that

is

a

concrete

class

in

some

class

graph

For

a

given

vertex

o

if

Class

-LRB-

o

-RRB-

V

P

then

o

represents

the

primitive

value

if

Class

-LRB-

o

-RRB-

V

C

then

o

represents

a

unique

object

identifier

-LRB-

OID

-RRB-

Each

edge

in

an

object

graph

is

labeled

by

an

element

of

L

The

edge

-LRB-

u

v

-RRB-

indicates

that

the

object

represented

by

u

has

a

reference

object

represented

by

v.

For

each

vertex

u

and

each

label

L

there

is

at

most

one

outgoing

edge

from

u

with

label

See

-LSB-

-RSB-

for

a

discussion

of

advantages

and

disadvantages

of

the

abstract

superclass

rule

An

object

graph

is

consistent

with

a

class

graph

G

if

for

every

vertex

o

of

-LRB-

-RRB-

Class

-LRB-

o

-RRB-

V

C

-LSB-

V

P

-LRB-

-RRB-

-LRB-

o

-RRB-

E

-LRB-

v

-RRB-

Refs

-LRB-

Class

-LRB-

o

-RRB-

-RRB-

such

that

Class

-LRB-

-RRB-

-RRB-

v

-LRB-

-RRB-

-LRB-

v

-RRB-

Refs

-LRB-

Class

-LRB-

o

-RRB-

-RRB-

-LRB-

o

-RRB-

E

such

that

Class

-LRB-

-RRB-

-RRB-

v

Environment

An

environment

E

consists

of

a

set

of

object

graphs

representing

both

a

persistent

object

store

and

a

run-time

environment

Every

environment

contains

a

distinguished

object

stream

of

type

String

that

simulates

output

There

is

an

accessor

function

EnvLookup

which

returns

the

object

vertex

referenced

by

a

given

variable

with

an

environment

Given

an

object

vertex

o

in

an

object

graph

in

E

and

a

label

EnvLookup

-LRB-

o

E

-RRB-

returns

the

object

vertex

where

the

edge

-LRB-

o

-RRB-

is

in

An

environment

is

consistent

with

a

class

graph

G

if

all

its

object

graphs

are

consistent

with

G.

For

two

given

class

graphs

G

and

G

an

object

transformation

transforms

environments

consistent

with

G

to

environments

consistent

with

G

Object

transformations

leave

the

stream

object

invariant

An

environment

E

is

an

extension

of

environment

E

written

as

E

E

if

for

each

object

graph

in

E

there

exists

an

object

graph

in

E

such

that

A.

Behavioral

Model

Calling

reachability

For

two

concrete

vertices

u

v

in

a

class

graph

the

relation

u

v

holds

if

an

instance

of

u

can

send

a

message

to

an

instance

of

v

through

its

-LRB-

direct

or

inherited

-RRB-

instance

variable

u

v

if

and

only

if

y

V

such

that

-LRB-

x

y

-RRB-

ER

u

-RRB-

x

v

-RRB-

y

The

message

may

be

dynamically

dispatched

since

the

actual

type

of

might

be

a

superclass

of

v

The

calling

reachability

relation

denoted

by

is

the

transitive

closure

of

the

relation

Example

Registryregistered

Truck

CarvehID

String

Calling

path

A

calling

path

p

in

G

is

a

sequence

n

vni

-LRB-

n

-RRB-

such

that

for

i

n

vi`i

vi

Vertex

is

called

the

source

of

the

calling

path

denoted

Source

-LRB-

p

-RRB-

and

vn

is

called

the

target

of

the

calling

path

denoted

Target

-LRB-

p

-RRB-

Note

that

all

vertices

V

-LRB-

p

-RRB-

in

a

calling

path

are

concrete

It

follows

directly

from

the

above

definition

that

for

any

u

v

V

there

is

a

path

p

hu

vi

from

u

to

v

if

and

only

if

u

v.

Note

however

that

for

two

given

vertices

u

and

v

with

u

v

there

may

be

more

than

one

path

from

u

to

v

The

edges

E

-LRB-

p

-RRB-

of

a

path

p

vni

-LRB-

n

-RRB-

are

defined

as

follows

E

-LRB-

p

-RRB-

f

-LRB-

vi

i

vi

-RRB-

j

i

ng

Similarly

L

-LRB-

p

-RRB-

is

the

set

of

labels

of

the

calling

path

p

If

P

is

a

set

of

calling

paths

then

the

following

operators

are

defined

on

P

Car

returns

the

set

of

first

edges

in

P

Cdr

returns

the

set

of

remaining

paths

when

truncating

the

first

edges

and

finally

Filt

filters

those

paths

that

start

with

a

given

vertex

and

edge

label

The

label

argument

to

Filt

can

be

replaced

by

a

wildcard

implying

all

edge

labels

should

be

matched

Car

-LRB-

P

-RRB-

f

-LRB-

-RRB-

j

vni

Pg

Cdr

-LRB-

P

-RRB-

vni

j

vni

Pg

Filt

-LRB-

P

v

-RRB-

vni

P

j

v

-LRB-

-RRB-

g

Propagation

directive

A

propagation

directive

is

a

triple

denoted

D

-LRB-

S

X

T

-RRB-

where

S

is

a

nonempty

set

of

vertices

from

a

class

graph

called

the

source

vertices

X

are

the

traversal

exclusion

constraints

consisting

of

a

set

of

edges

-LRB-

u

v

-RRB-

called

bypassing

edges

where

u

v

are

vertices

and

is

a

label

in

a

class

graph

T

is

a

set

of

vertices

in

a

class

graph

called

the

target

vertices

of

the

vertices

involved

in

S

X

T

may

be

primitive

vertices

A

propagation

directive

D

specifies

all

calling

sequences

from

source

vertices

to

target

vertices

that

satisfy

the

traversal

exclusion

constraints

Thus

a

propagation

directive

D

-LRB-

S

X

T

-RRB-

denotes

a

set

of

calling

paths

in

a

given

class

graph

as

follows

PathSet

-LRB-

G

D

-RRB-

fp

j

p

is

a

calling

path

in

G

such

that

Source

-LRB-

p

-RRB-

C

-LRB-

S

-RRB-

Target

-LRB-

p

-RRB-

C

-LRB-

T

-RRB-

E

-LRB-

p

-RRB-

C

-LRB-

X

-RRB-

g

A

propagation

directive

D

-LRB-

S

X

T

-RRB-

is

considered

to

be

compatible

with

a

class

graph

if

all

vertices

mentioned

in

a

directive

exist

in

the

class

graph

and

there

is

at

least

one

path

in

the

class

graph

that

meets

the

directive

constraints

In

the

PrintRegistered

propagation

pattern

S

fRegistryg

T

fTransportVehicleg

and

D

fS

Tg

The

path

set

of

D

applied

to

the

class

graph

in

Figure

is

f

-LRB-

Registry

registered

Car

-RRB-

-LRB-

Registry

registered

Truck

-RRB-

-LRB-

Registry

registered

Trailer

-RRB-

g.

Lemma

PathSet

Lemma

Let

G

and

G

be

two

class

graphs

and

D

-LRB-

S

X

T

-RRB-

a

propagation

directive

compatible

with

and

in

canonical

form

with

respect

to

both

G

and

G

DG

D

If

the

following

three

conditions

hold

-LRB-

-RRB-

V

C

V

C

LE

-LRB-

-RRB-

w

V

C

LE

v

G

w

iff

v

and

-LRB-

-RRB-

V

C

V

C

s

S

t

T

s

implies

u

then

D

defines

the

same

path

sets

in

both

G

and

G

PathSet

-LRB-

G

D

-RRB-

PathSet

-LRB-

D

-RRB-

Method

map

A

method

map

is

a

mapping

from

vertices

in

some

class

graph

to

method

bodies

for

a

specific

method

In

CLOS

terminology

a

method

map

defines

methods

for

a

single

generic

function

Method

bodies

are

simply

sequences

of

statements

and

expressions

in

some

object-oriented

programming

language

for

example

C++

If

no

method

body

is

defined

for

a

vertex

then

the

method

map

returns

ffl

Note

that

there

is

a

distinction

between

an

empty

method

body

and

ffl

There

are

typically

three

method

bodies

executed

when

an

object

is

processed

by

an

adaptive

program

first

a

prefix

body

followed

by

a

traversal

body

and

a

suffix

body

The

programmer

provides

the

prefix

and

suffix

method

bodies

while

the

adaptive

software

compiler

automatically

provides

the

traversal

body

according

to

the

propagation

directives

Each

of

the

three

methods

is

bound

dynamically

In

C++

terminology

each

method

is

virtual

A

method

map

is

ambiguous

if

there

exists

a

vertex

in

the

class

graph

that

multiply

inherits

two

different

method

bodies

without

defining

its

own

method

body

As

in

C++

method

maps

must

conform

to

the

ambiguity

constraint

which

requires

method

maps

to

be

unambiguous

A

method

map

is

considered

to

be

compatible

with

a

class

graph

if

all

vertices

for

which

a

method

is

defined

occur

in

the

class

graph

The

syntactic

and

static

correctness

of

a

method

body

is

dependent

on

the

language

L

in

which

it

is

implemented

Method

bodies

are

considered

as

black

boxes

until

a

specific

language

and

a

semantics

for

that

language

is

provided

Propagation

pattern

A

propagation

pattern

is

formally

denoted

by

a

triple

P

-LRB-

N

;D

M

-RRB-

where

N

is

a

method

name

D

is

a

propagation

directive

and

M

-LRB-

MP

MS

-RRB-

is

a

pair

of

method

maps

one

for

prefix

methods

MP

and

one

for

suffix

methods

MS.

A

propagation

pattern

is

considered

to

be

compatible

with

a

class

graph

if

D

and

M

are

compatible

with

G

and

if

M

is

not

ambiguous

for

G

If

P

is

compatible

with

G

and

if

its

method

bodies

are

syntactically

and

statically

correct

for

a

language

L

then

P

is

consistent

with

G

and

L.

Method

lookup

Method

lookup

is

performed

by

the

function

Lookup

that

computes

for

a

given

class

vertex

v

and

a

given

method

map

M

the

relevant

method

body

for

the

class

The

argument

M

is

either

a

prefix

or

a

suffix

method

map

and

returns

a

prefix

or

suffix

method

body

respectively

Lookup

uses

the

function

Lookup

to

implement

the

method

lookup

mechanism

which

is

a

simple

depth-first

search

up

the

inheritance

hierarchy

of

the

class

The

result

of

the

Lookup

is

a

possibly

empty

sequence

of

all

applicable

method

bodies

Lookup

returns

the

first

body

in

this

sequence

by

using

the

First

operator

ffl

is

the

identity

for

the

concatenation

operator

that

is

S

ffl

ffl

S

S.

LookupG

-LRB-

v

M

-RRB-

First

-LRB-

Lookup?G

-LRB-

v

M

-RRB-

-RRB-

Lookup?G

-LRB-

v

M

-RRB-

M

-LRB-

v

-RRB-

Lookup?G

-LRB-

M

-RRB-

Lookup?G

-LRB-

vn

M

-RRB-

where

vi

DirectSuperclassesG

-LRB-

v

-RRB-

n

and

vn

The

recursion

terminates

with

Lookup?G

-LRB-

v

M

-RRB-

M

-LRB-

v

-RRB-

when

DirectSuperclassesG

-LRB-

v

-RRB-

Semantics

of

propagation

patterns

The

semantics

of

propagation

patterns

is

given

by

the

function

Call

Call

is

defined

in

terms

of

two

functions

PathSet

and

Trav

Trav

in

turn

is

defined

in

terms

of

the

functions

ExecuteL

RTC

and

Lookup

The

function

ExecuteL

takes

as

arguments

an

object

vertex

o

a

method

body

and

an

environment

E

The

function

executes

the

method

on

the

object

in

the

environment

and

returns

the

resulting

environment

The

following

is

assumed

for

any

language

ExecuteL

-LRB-

o

ffl

E

-RRB-

E

The

specifics

of

how

ExecuteL

operates

on

the

expressions

within

the

body

depend

on

the

semantics

of

the

language

L

Since

that

language

is

left

open

the

exact

definition

of

Execute

will

remain

unspecified

for

the

time

being

The

Trav

function

traverses

a

given

object

o

consistent

with

a

class

graph

G

guided

by

a

path

set

PS

starting

with

an

initial

environment

E

and

executing

methods

from

method

maps

in

M

Due

to

dynamic

binding

a

run-time

check

is

required

to

prevent

traversal

along

edges

not

reflected

in

the

path

set

The

run-time

check

is

performed

by

the

function

RTC

which

may

call

Trav

recursively

When

Trav

is

called

for

object

o

the

applicable

prefix

method

for

o

is

executed

then

the

outgoing

edges

labeled

ln

from

o

are

traversed

as

constrained

by

path

set

PS

and

finally

an

applicable

suffix

method

for

o

is

executed

Execution

of

a

method

may

change

the

environment

The

environment

resulting

from

execution

of

the

prefix

method

will

be

used

for

the

first

recursive

call

to

Trav

through

edge

whose

resulting

environment

will

be

used

for

the

next

call

to

Trav

and

so

on

until

the

environment

returned

from

the

last

call

to

Trav

through

edge

n

is

used

by

the

suffix

method

for

o

It

is

assumed

that

during

the

traversal

the

environment

represents

only

object

graphs

consistent

with

the

class

graph

G

The

following

is

the

definition

of

the

function

Trav

TravG

M

-LRB-

o

PS

E

-RRB-

ExecuteL

-LRB-

o

LookupG

-LRB-

Class

-LRB-

o

-RRB-

MS

-RRB-

RTCG

M

-LRB-

o

n

PS

RTCG

M

-LRB-

o

PS

ExecuteL

-LRB-

o

LookupG

-LRB-

Class

-LRB-

o

-RRB-

MP

-RRB-

E

-RRB-

-RRB-

:-RRB-

-RRB-

where

n

and

i

are

determined

by

the

set

f

i

j

-LRB-

Class

-LRB-

o

-RRB-

i

ui

-RRB-

Car

-LRB-

Filt

-LRB-

PS

Class

-LRB-

o

-RRB-

-RRB-

-RRB-

i

ng

The

order

of

the

calls

to

RTC

is

determined

by

the

labels

lj

lk

for

j

k

n.

Note

that

for

a

given

object

o

n

is

determined

purely

by

the

class

graph

and

independent

of

how

the

environment

changes

during

execution

The

run-time

check

performed

by

RTC

tests

to

see

whether

the

class

of

the

object

referenced

by

o

is

contained

in

the

path

set

If

it

is

contained

then

Trav

is

called

to

continue

the

traversal

to

o

otherwise

RTC

simply

returns

the

environment

RTCG

M

-LRB-

o

PS

E

-RRB-

TravG

M

-LRB-

EnvLookup

-LRB-

o

E

-RRB-

Cdr

-LRB-

Filt

-LRB-

PS

Class

-LRB-

o

-RRB-

-RRB-

-RRB-

E

-RRB-

if

-LRB-

Class

-LRB-

o

-RRB-

Class

-LRB-

EnvLookup

-LRB-

o

E

-RRB-

-RRB-

-RRB-

Car

-LRB-

Filt

-LRB-

PS

Class

-LRB-

o

-RRB-

-RRB-

-RRB-

E

otherwise

Finally

given

a

class

graph

G

-LRB-

V

E

L

-RRB-

a

propagation

pattern

P

-LRB-

N

D

M

-RRB-

consistent

with

G

and

language

L

an

environment

E

consistent

with

G

and

a

vertex

o

in

E

such

that

Class

-LRB-

o

-RRB-

C

-LRB-

S

-RRB-

the

semantics

of

P

is

given

by

the

function

Call

Call

-LRB-

G

P

o

E

-RRB-

TravG

M

-LRB-

o

PathSet

-LRB-

G

D

-RRB-

-RRB-

E

-RRB-

The

following

lemma

proves

a

property

used

by

the

subsequent

traversal

theorem

Lemma

If

E

and

E

are

two

environments

such

that

E

E

then

for

all

object

vertices

o

in

E

and

for

all

labels

of

o

RTCG

M

-LRB-

o

PS

E

-RRB-

terminates

immediately

to

E

if

and

only

if

M

-LRB-

o

PS

E

-RRB-

terminates

immediately

to

E

Theorem

Traversal

Theorem

Let

G

and

G

be

two

class

graphs

M

and

M

two

method

maps

consistent

with

language

L

and

with

G

and

G

respectively

let

PS

be

a

path

set

and

let

be

an

object

transformation

from

environments

consistent

with

G

to

environments

consistent

with

G

such

that

for

all

environments

E

consistent

with

G

E

-LRB-

E

-RRB-

Furthermore

if

for

all

o

E

-LRB-

ExecuteL

-LRB-

o

LookupG

-LRB-

Class

-LRB-

o

-RRB-

M

-RRB-

E

-RRB-

-RRB-

ExecuteL

-LRB-

o

-LRB-

Class

-LRB-

o

-RRB-

-RRB-

-LRB-

E

-RRB-

-RRB-

then

the

following

implication

holds

If

TravG

M

-LRB-

o

PS

E

-RRB-

terminates

in

a

recursive

descent

of

depth

d

with

result

E

then

M

-LRB-

o

PS

-LRB-

E

-RRB-

-RRB-

terminates

in

a

recursive

descent

of

depth

d

with

result

-LRB-

E

-RRB-

For

a

specific

primitive

transformation

to

utilize

the

Traversal

Theorem

the

following

properties

must

be

shown

is

such

that

PathSet

-LRB-

G

D

-RRB-

PathSet

-LRB-

-RRB-

M

is

consistent

with

G

and

some

language

L.

is

such

that

E

-LRB-

E

-RRB-

E

-LRB-

ExecuteL

-LRB-

o

LookupG

-LRB-

Class

-LRB-

o

-RRB-

M

-RRB-

E

-RRB-

-RRB-

ExecuteL

-LRB-

o

-LRB-

Class

-LRB-

o

-RRB-

-RRB-

-LRB-

E

-RRB-

-RRB-

Once

all

of

the

above

premises

for

the

theorem

have

been

established

partial

behavioral

equivalence

can

be

concluded

A.

Example

Transformation

Distribution

of

Common

Reference

Distribution

of

common

reference

-LRB-

DisR

-RRB-

moves

a

reference

-LRB-

w

-RRB-

from

a

superclass

v

to

all

its

direct

subclasses

vn

The

reference

will

be

duplicated

in

the

subclasses

rather

than

inherited

from

v.

Class

graph

transformation

Preconditions

v

V

A

-LRB-

w

-RRB-

DirectRefs

-LRB-

v

-RRB-

Assume

DirectSubclasses

-LRB-

v

-RRB-

vng

Then

the

class

graph

transformation

distribution

of

common

reference

v

is

performed

by

the

operation

oe

DisR

-LRB-

G

v

-RRB-

which

produces

a

class

graph

-LRB-

V

L

-RRB-

such

that

-LRB-

ER

f

-LRB-

v

w

-RRB-

g

-RRB-

-LSB-

f

-LRB-

vi

w

-RRB-

j

i

ng

Environment

transformation

Any

object

in

E

consistent

with

G

is

also

consistent

with

G

Therefore

the

environment

transformation

is

simply

the

identity

transformation

I

implying

E

-LRB-

E

-RRB-

E

Program

transformation

The

original

propagation

directive

remains

compatible

with

the

class

graph

The

method

map

needs

to

be

modified

if

there

existed

a

method

body

for

v

that

refers

to

the

distributed

reference

label

In

that

case

the

method

body

is

not

statically

correct

for

G

The

inconsistency

is

corrected

by

pushing

such

a

method

body

down

to

the

direct

subclasses

of

v

each

of

which

now

contains

the

reference

ss

DisR

-LRB-

P

v

-RRB-

P

-LRB-

N

D

M

-RRB-

The

method

map

transformation

produces

a

new

method

map

M

in

which

a

method

attached

to

v

is

pushed

down

to

those

direct

subclasses

of

v

that

do

n't

define

their

own

method

The

function

UseSet

returns

the

set

of

labels

referenced

in

a

method

-LRB-

u

-RRB-

M

-LRB-

v

-RRB-

if

u

DirectSubclassesG

-LRB-

v

-RRB-

M

-LRB-

u

-RRB-

ffl

UseSet

-LRB-

M

-LRB-

v

-RRB-

-RRB-

hi

if

u

v

UseSet

-LRB-

M

-LRB-

v

-RRB-

-RRB-

M

-LRB-

u

-RRB-

otherwise

Program

consistency

Consistency

of

P

with

G

holds

Although

the

method

map

M

was

changed

its

bodies

remained

unchanged

and

M

is

therefore

still

syntactically

correct

It

also

stays

statically

correct

since

V

UseSet

-LRB-

-LRB-

v

-RRB-

-RRB-

RefLabels

-LRB-

-LRB-

v

-RRB-

-RRB-

Finally

neither

compatibility

nor

ambiguity

are

affected

by

the

distribution

of

the

common

reference

Behavioral

equivalence

Behavioral

equivalence

can

be

shown

by

using

the

Traversal

Theorem

The

prerequisites

are

fulfilled

-LRB-

-RRB-

PathSet

-LRB-

G

D

-RRB-

PathSet

-LRB-

D

-RRB-

using

the

PathSet

Lemma

-LRB-

-RRB-

Method

map

consistency

is

subsumed

by

program

consistency

-LRB-

-RRB-

E

-LRB-

E

-RRB-

=-RRB-

E

-LRB-

E

-RRB-

-LRB-

-RRB-

Since

the

method

bodies

were

not

changed

by

the

transformation

it

is

straightforward

to

show

the

execution

premise

for

DisR

Lemma

DisR-Lookup

Lemma

Given

a

class

graph

G

a

vertex

v

V

and

a

label

LE

let

DisR

-LRB-

G

v

-RRB-

be

the

transformed

graph

of

G

under

DisR

Similarly

let

M

be

a

method

map

unambiguous

and

compatible

with

G

and

M

DisR

-LRB-

G

M

v

-RRB-

the

transformed

method

map

as

defined

by

DisR

Then

for

all

u

V

u

v

-LRB-

u

-RRB-

LookupG

-LRB-

u

M

-RRB-

management of change
object-oriented system evolution


Baltzer Journals Unimodal Loading Problems Monica Bianchini1 , Stefano Fanelli2 , Marco Gori1 , and Marco Protasi2 1Dipartimento di Sistemi e Informatica , Universit?a degli Studi di Firenze Via di Santa Marta , 3 - 50139 Firenze - Italy Tel. +39 -LRB- 55 -RRB- 479.6265 - Fax +39 -LRB- 55 -RRB- 479.6363 E-mail : -LCB- monica , marco -RCB- @mcculloch . ing.unifi.it 2Dipartimento di Matematica , Universit?a di Roma \ Tor Vergata '' Via della Ricerca Scientifica - 00133 Roma - Italy Tel. +39 -LRB- 6 -RRB- 7259.4681 - Fax +39 -LRB- 6 -RRB- 7259.4699 E-mail : -LCB- fanelli , protasi -RCB- @mat . utovrm.it This paper deals with optimal learning and provides a unified viewpoint of most significant results in the field . The focus is on the problem of local minima in the cost function that is likely to affect more or less any learning algorithm . We give some intriguing links between optimal learning and the computational complexity of loading problems . We exhibit a computational model such that the solution of all loading problems giving rise to unimodal error functions require the same time , thus suggesting that they belong to the same computational class . 1 Learning as optimisation Supervised learning in multilayered networks -LRB- MLNs -RRB- can be accomplished thanks to Backpropagation -LRB- BP -RRB- , which is used to minimise pattern misclassifications by means of gradient descent for a particular nonlinear least squares fitting problem . Unfortunately , BP is likely to be trapped in local minima and indeed many examples of local extremes have been reported in the literature . The presence of local minima derives essentially from two different reasons . First , they may arise because of an unsuitable joint choice of the functions which defines the network dynamics and the error function . Second , local minima may be inherently related to the structure of the problem at hand . In -LSB- 5 -RSB- , these two cases have been referred to as spurious and structural local minima , respectively . Problems of sub-optimal solutions may also arise when learning with high initial weights , as a sort of premature neuron saturation arises , which is strictly related to the neuron fan-in . An interesting way of facing this problem is to use the \ relative cross-entropy metric '' -LSB- 10 -RSB- , for which the erroneous saturation of the output neurons does not lead to plateaux , but to very high values of the M. Bianchini et al. / Unimodal Loading Problems 2 cost . When using the cross-entropy metric , the repulsion from such configurations is much more effective , and underflow errors are likely to be avoided . There have also been attempts to provide theoretical conditions aimed at guaranteeing local minima free error surfaces . So far , however , only some sufficient conditions have been identified that give rise to unimodal error surfaces . Examples are the the case of pyramidal networks -LSB- 8 -RSB- , commonly used in pattern recognition , radial basis function networks -LSB- 2 -RSB- , and non-linear autoassociators -LSB- 3 -RSB- . The identification of similar conditions ensures global optimisation just by using simple gradient descent . Instead of looking for local algorithms like gradient descent , techniques that guarantee global optimisation may be explored . Of course , one of the main problems to face is that most interesting tasks give rise to the optimisation of functions with even several thousand variables . This makes it very unlikely that most classic approaches -LSB- 11 -RSB- can be directly and successfully applied . Instead , the proposal of successful algorithms has to face effectively the curse of dimensionality typical of most interesting practical problems . Statistical training methods have been previously proposed in order to alleviate the local convergence problem . These methods introduce noise to connection weights during training , but suffer from extremely slow convergence due to their probabilistic nature . Several numerical algorithms for global optimisation have also been presented , in which BP is revisited from the viewpoint of dynamical system theory . Barhen et al. -LSB- 1 -RSB- have proposed the TRUST algorithm -LRB- for Terminal Repeller Unconstrained Subenergy Tunneling -RRB- that formulates global optimisation as the solution of a system of deterministic differential equations , where E -LRB- W -RRB- is the function to be optimised , while the connection weights are the states of the system . The dynamics used is achieved upon application of the gradient descent to a modified cost which transforms each encountered local minimum into a maximum , so that the gradient descent can escape from it to a lower valley . A related algorithm , called Magic Hair-Brushing , has been proposed in -LSB- 6 -RSB- . The system dynamics is now modified through a deformation of the gradient field for eliminating the local minima , while preserving the global structure of the function . All these algorithms exhibit a good performance in many practical cases but , unfortunately , their optimal convergence is not formally guaranteed , unless starting from a \ good '' initial point . 2 The class of unimodal loading problems Most experiments with multilayer perceptrons and BP are performed in a sort of magic atmosphere where data are properly supplied to the network which begins learning without knowing whether or not the experiment will be successful either in terms of optimal convergence and generalisation . A trial and error scheme is usually employed , aimed at adjusting the architecture in subsequent experiments so as to meet the desired requirements . To some extent , this way of performing experiments is inherently plagued by the suspect that the used numerical optimisation algorithm might fail . Moreover , though optimal learning may be attained with networks having a growing number of hidden neurons -LSB- 14 -RSB- , the generalisation to new examples is not guaranteed . The intuitive feeling that , in order to obtain a good convergence behaviour , generalisation must be sacrificed , may be effectively formalised in a sort of \ uncertainty principle of learning '' in which the variable representing optimal convergence and generalisation are like conjugate variable in Quantum Mechanics -LSB- 7 -RSB- . These potential sources of failure of learning algorithms give M. Bianchini et al. / Unimodal Loading Problems 3 rise to a sort of suspiciousness that turns out to be the unpleasant companion of every experiment . This seems to be interwound with the ambitious task of learning too general functions . Let us focus on the complexity issues related to the loading of the weights independently of the consequent generalisation to new examples . This makes sense once a consistent formulation of the learning problem in terms of both the chosen examples and the neural architecture was provided . We address the problem of establishing the computational requirements of special cases in which the loading of the weights can be expressed in terms of optimisation of unimodal error functions . 2.1 Canonical form of gradient descent learning Let us consider the following learning equation : dW dt = ? rWE = f -LRB- t ; W -RRB- ; -LRB- 1 -RRB- where E -LRB- W -RRB- is the cost function and W 2 Rm is the weight vector . Let us choose : = ? -LRB- E -RRB- krWEk2 , being ? a non-negative continuous function of E. Based on this choice of the learning rate , the dynamics of the error function becomes dE dt = -LRB- rWE -RRB- T dW dt = -LRB- rWE -RRB- T ? ? ? -LRB- E -RRB- k rWE k2 rWE ? = ?? -LRB- E -RRB- ; -LRB- 2 -RRB- which makes the cost function continuously decreasing to zero . Those configurations for which rWE = are singular points that attract the learning trajectory -LSB- 4 -RSB- . Special cases of this reduction to a canonical structure , where the learning is forced by function ? and is independent of the problem at hand , have been explored in the literature . White -LSB- 13 -RSB- has suggested to introduce a varying learning rate so that the error dynamics evolves following the equation dEdt = ?? -LRB- E -RRB- : = ? aE ; a > 0 , whose solution is a decaying exponential such that reaching the E = attractor will theoretically take infinite time . In practice , this may not necessarily be a problem , as the attractor may be approached sufficiently close in a reasonable amount of time , even if , for ill-conditioned systems , it can still be prohibitive to reach a satisfactory solution . Unfortunately , feedforward neural networks do often result in dynamical systems that are ill-conditioned or mathematically stiff and thus the convergence is generally very slow . In -LSB- 12 -RSB- the canonical reduction of equation -LRB- 2 -RRB- is based on choosing ? -LRB- E -RRB- : = Ek , < k < 1 , which leads to an error dynamics based on the differential equation dEdt = ? Ek , having a singularity at E = violating the Lipschitz condition . If E0 > = is the initial value of the cost , then the closed form solution is E -LRB- t -RRB- = -LRB- E1?k ? -LRB- 1 ? k -RRB- t -RRB- 11 ? k ; t < = te , where te = E1?k 1 ? k -LRB- Fig. 1a -RRB- . In the finite time te the transient beginning from E -LRB- 0 -RRB- = E0 reaches the equilibrium point E = 0 , which is a \ terminal attractor . '' In this paper , we are interested in finding terminal attractors and , particularly , in minimising the time te required to approach the optimal solution . The choice ? -LRB- E -RRB- : = ? fulfills our needs . Consequently te = E0 = ? and , in particular , when selecting ? = E0 = oe , the terminal attractor is approached for te = oe -LRB- Fig. 1b -RRB- , independently of the problem at hand , while the corresponding weight updating equation becomes dW dt = ? E0 oe rE jjrEjj2 : -LRB- 3 -RRB- M. Bianchini et al. / Unimodal Loading Problems 4 E0 E tt e E0 E tt e -LRB- a -RRB- -LRB- b -RRB- Figure 1 : Terminal attraction using -LRB- a -RRB- ? -LRB- E -RRB- : = Ek , < k < 1 , and -LRB- b -RRB- ? -LRB- E -RRB- : = ? . This way of forcing the dynamics leads to establish intriguing links between the concept of unimodal problems and their computational complexity . In fact , learning attractors in finite time is not only useful from a numerical point of view but , in the light of the considerations on the canonical equations -LRB- 2 -RRB- , is interesting for the relationships that can be established between different problems giving rise to local minima free cost functions . 2.2 Computational analyses Let us introduce the following classes of loading problems -LSB- 9 -RSB- . Definition 1 A loading problem P is unimodal , P 2 UP , provided that there exists an associated unimodal error function E -LRB- P ; W -RRB- whose optimisation represents the solution of P . Note that a given loading problem can be approached in the framework of optimisation using different error functions . For example , the loading of the weights in a multilayer perceptron using linearly-separable patterns may led to sub-optimal solution when choosing error functions where the targets are different from the asymptotical values of the squashing functions . Nevertheless , it is always possible to get rid of these spurious local minima and provide a formulation based on a local minima free error function . In order to evaluate the computational cost for learning problems belonging to UP it is convenient to refer to the parallel computational model offered by differential equation -LRB- 1 -RRB- . We assume that there exists a continuous system implementing this differential equation and then consider the following computational class . Definition 2 Let us consider the class of loading problems P for which there exists a formulation according to the differential equation -LRB- 1 -RRB- such that 8o > the loading of the weights ends in a finite time te : te < = o . This class is referred to as the class of finite time loading problems and is denoted by FT . Because of the previous analysis on gradient descent the following result holds . M. Bianchini et al. / Unimodal Loading Problems 5 Problems Problems FT Universe Loading Problem UP Figure 2 : The class of unimodal learning problem can be learned in constant time . Theorem 3 UP ae FT . Proof If P 2 UP then one can always formulate the loading according to differential equation -LRB- 3 -RRB- and the gradient descent is guaranteed not to get stuck in local minima . Because of equation -LRB- 2 -RRB- the learning process ends for te = oe . Hence , 8o > 0 , if we choose oe < = o we conclude that P 2 FT . This theoretical result should not be overvalued since it is based on a computational model that does not care of problems due to limited energy . When choosing o arbitrarily small , the slope of the energy in Fig. 1b goes in fact to infinite . One may wonder whether problems can be found in FT that are not in UP -LRB- see Fig. 2 -RRB- . This does not seem easy to establish and is an open problem that we think deserves further attention . 3 Conclusions The presence of local minima does not necessarily imply that a learning algorithm will fail to discover an optimal solution , but we can think of their presence as a boundary beyond which troubles for any learning technique are likely to begin . In this paper we have proposed a brief review of results dealing with optimal learning , and we have discussed of problems of sub-optimal learning . Most importantly , when referring to a continuous computational model , we have shown that there are some intriguing links between computational complexity and the absence of local minima . Basically all loading problems that can be formulated as the optimisation of unimodal functions are proven to belong to a unique computational class . Note that this class is defined on the basis of computational requirements and , therefore , seems to be of interest independently of the neural network context in which it has been formulated . We are confident that these theoretical results open the doors for more thoroughly analyses involving discrete computations , that could shed light on the computational complexity based on ordinary models of Computer Science . M. Bianchini et al. / Unimodal Loading Problems 6 Acknowledgments We thank P. Frasconi , M. Maggini , F. Scarselli , and F. Schoen for fruitful discussions and suggestions . References -LSB- 1 -RSB- J. Barhen , J. W. Burdick , and B. C. Cetin , Terminal Repeller Unconstrained Subenergy Tunneling -LRB- TRUST -RRB- for fast global optimization , Journal of Optimization Theory and Applications , 77 , -LRB- 1993 -RRB- , 97 -LCB- 126 . -LSB- 2 -RSB- M. Bianchini , P. Frasconi , and M. Gori , Learning without local minima in radial basis function networks , IEEE Transactions on Neural Networks , 6 , -LRB- 1995 -RRB- , 749 -LCB- 756 . -LSB- 3 -RSB- M. Bianchini , P. Frasconi , and M. Gori , Learning in multilayered networks used as autoassociators , IEEE Transactions on Neural Networks , 6 , -LRB- 1995 -RRB- , 512 -LCB- 515 . -LSB- 4 -RSB- M. Bianchini , M. Gori , and M. Maggini , Does terminal attractor backpropagation guarantee global optimization ? , in International Conference on Artificial Neural Networks , SpringerVerlag , 1994 , pp . 377 -LCB- 380 . -LSB- 5 -RSB- M. Bianchini and M. Gori , Optimal learning in artificial neural networks : a theoretical view . Accepted for publication on Neurocomputing . -LSB- 6 -RSB- J. Chao , W. Ratanasuwan , and S. Tsujii , How to find global minima in finite times of search for multilayer perceptrons training , in International Joint Conference on Neural Networks , IEEE Press , Singapore , 1991 , pp. 1079 -LCB- 1083 . -LSB- 7 -RSB- P. Frasconi and M. Gori , Multilayered networks and the C-G uncertainty principle , in SPIE International Conference , Science of Artificial Neural Networks , Orlando , Florida , 1993 , pp. 396 -LCB- 401 . -LSB- 8 -RSB- M. Gori and A. Tesi , On the problem of local minima in backpropagation , Transactions on Pattern Analysis and Machine Intelligence , 14 , -LRB- 1992 -RRB- , 76 -LCB- 86 . -LSB- 9 -RSB- J. S. Judd , Neural Network Design and the Complexity of Learning . Cambridge , London : The MIT Press , 1990 . -LSB- 10 -RSB- T. Samad , Backpropagation improvements based on heuristic arguments , in International Joint Conference on Neural Networks , IEEE Press , Washington DC , 1990 , pp. 565 -LCB- 568 . -LSB- 11 -RSB- Torn and Zilinkas , Global Optimization , Lecture Notes in Computer Sciences , 1987 . -LSB- 12 -RSB- S. Wang and C. H. Hsu , Terminal attractor learning algorithms for backpropagation neural networks , in International Joint Conference on Neural Networks , IEEE Press , Singapore , 1991 , pp. 183 -LCB- 189 . -LSB- 13 -RSB- H. White , The learning rate in backpropagation systems : an application of Newton 's method , in International Joint Conference on Neural Networks , IEEE Press , Singapore , 1991 , pp. 679 -LCB- 684 . -LSB- 14 -RSB- X. Yu , Can backpropagation error surface not have local minima ? , IEEE Transactions on Neural Networks , 3 , -LRB- 1992 -RRB- , 1019 -LCB- 1020 .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 B I 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 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 B I I I 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 B I 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 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 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 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 B I 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 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 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

backpropagation
computational complexity
optimal learning
spurious and structural local minima
terminal attractor