Modular Reasoning in the Presence of Subclassing - Department of ...

Modular Reasoning in the Presence of Subclassing Raymie

Stata

Laboratory

John

V. Guttag

for Computer

Massachusetts

Institute

Cambridge,

Science

of Technology

MA

02139

raymieQlarch.lcs.mit.edu

Abstract

programming

Considerable progress has been made in understanding how to use subtyping in a way that facilitates modular reasoning. However, using subclassing in a way that facilitates modular reasoning is not well understood. Often methods must be overriden as a group because of dependencies on instance variables, and the programmers of subclasses cannot tell which methods are grouped without looking at the code of superclasses. Also, the programmers of subclasses must look at the code of superclasses to tell what assumptions inherited methods make about the behavior of overriden methods. We present a systematic way to use subclassing that facilitates formal and informal modular reasoning. Separate specifications are given to programmers writing code that manipulates instances of a class and to programmers writing subclasses of the class. The specifications given to programmers of subclasses are divided, by division of labor specificaiions, into multiple parts. Subclasses may inherit or override entire parts, but not sub-parts. Reasoning about the implementation of each part is done independently of other parts.

difficulties.

1

Grouping

classes

fosters

code

to be specialized

reuse into

by

allowing

new ones.

share

is not

one

override

Two

classes

need

or more

meth-

If a subclass

of such

all members.

a group,

overit must

Programmers

to know

its

are:

for maintaining

variables.

member

without

problems

responsibility

a set of instance rides

of sub-

the grouping

dependen-

cies of superclasses. Behavior

dependencies.

override

some

exist

subclass

and

superclass

methods

make

source

old

Also,

into

making

subclasses,

changes

However,

to a superclass

This

paper

based

presents

on a new kind

ization

interfaces.

Permission to make digital/hard copy of part or all of this work for personal or classroom use is ranted without fee provided that copies are not made or distributed for pro Brt or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee.

subclasses

different

from

used by programmers ulates

instances

partition ple parts. than

200

the

client

superclasses

it difficult

to know subclasses.

alternative

what

solution for specialinterface

by programmers This

interface,

who write class.

specialization override

methods.

are

will affect

class.

the

to incorporate

about

used

of the

Subclasses

individual

tend

specialization

of the

these at

solutions

of specification

The

the

solve

looking

These

an

a class is the interface write

by

they

pro-

to meet.

often

or

assumptions

the behav-

assumptions

of superclasses.

to errors.

of

Inherited

about

subclasses

undocumented

others,

behaviors

methods.

need

guessing

subclasses

inherit the

methods,

of by

code

prone

among

of subclasses

Programmers problems

and

assumptions

of overriden

grammers

When

methods

dependencies

ior

This research was supported in part by the Advanced Research Projects Agency of the Department of Defense, monitored by the Office of Naval Research under contract N00014-92-J-1795, and in part by the National Science Foundation under grant CCR-9115797.

OOPSlA ‘95 Austin, TX, USA Q 1995 ACM O-89791-703-0/95/001 0...$3.50

subclasses

dependencies.

ods often

Introduction

Subclassing

with

Two important

who

can

be quite

the

interface

code that Our

of

manip-

specifications

interface

into

multi-

entire

parts

rather

Reasoning

about

the

implementation sidering

of each

part

is done

the implementations

alloxvs programmers without

looking

wit,hout

of other

to build

and

at the source

parts;

change

con-

by

the

this

the

sort

cla.sses

code of superclasses

Sec.

2 defines

our Sec.

terminology. behavior presents

our

t.he client

related

work,

and

to

on

how

our

verify

the

a model

except

we

be

classes.

object

types

object

is state

manipulate

the

implemented

along

state.

with

methods

As is usual:

as a set

of instance

variables

jects.

type

Most

The

names

of

and

assume

signatures

t.hat define

state.

space

of a type’s

and

define

methods. of object

of a type’s

in [LiskovSA].

of an

that

abstract

method

Such

ing

We

tion

protected

described

3

specifica-

Y> I,

and

of the

of objects

Fig.

value

subsumed

of values

The

that

described sort

objects

take on: the invariant that

objects

the

constraint

describes

subsumed how

the

C is the

value

class

is designed

and

to

be

subsumed

by the type constraint

by the type values

class

consists by the

using by the

We

a new

types. consists

class,

specify

kind

of class.

object

of a class

defined

must

constraint

of objects

ing

includ-

specializa-

of specification

and

The

code

size.

u multisets,

is in

pattern

are overriden

by

of subclassing.

can inherit they

IntMultiSetClass a specification

member

overall

aspect when

sets.

unordered

of problems

the

of IntSetClass

integer for

a number but

This

other

on self that

operation

Fig. 1 includes

201

for

of code,

a class implementin,

that

subsumed

IntSetClass.

implement

is a fundamental

member

remove,

satisfy;

to both

methods

Subclasses

can on C

class

superclass

to illustrate page

subclasses

set

a

the

classes.

of calling

space

underlying

I is a static

c’ is a dynamic the

a

defined

methods.

1 contains

contrived

c I c M+

C together

type.

can-

An example

a single of the

but

in Sec. 3.

collection -

can be called

on the

by the type: object-type

of

interface

with

a protected

that

are specified

interfaces

the to the

specifications

description

behavior

the

conform

subclasses

methods

methods

a method

of its instances.

interface

specialization

of all the

types

methods

by clients

interfaces

The

of obsignature

We use the behavioral

describe

consist

types

only

specifications

the effects

program’s

behavior

support

object

behavioral

the

cannot A class

superclasses’

As in C++,

by the classes’

client

variables

a method,

must

of a class is a method

overriden

Client describes

languages

specifications

tions

of the old one.

the non-protected

and

overrides

signature

is

code for its methods. An object

a class

of its

A

methods

locally

as one

of the new method

not be called

tha.t

an object

by defining

We

model. and

of its superclass.

signature

and

classes.

inheritance

of a subclass

When

vari-

by the class.

methods

name

a

the instance

variables

variables

same

of

a set of in-

Instance

a method

method

from

The set of

a superclass.

with

be

Instantiating

with

single

overrides methods.

programand

instance

counters might

defines

defined

instance

from

the

that.

code

inherits

of

the behavior

methods.

a new object

a standard

set

of pre- and post-conditions.

and

method

that

in value.

M” define

are encapsulated:

single-inheritance

separate

and

access

types,

standard,

creates

ables

definit,ions

can

of object-oriented

is a fairly

class

subclass

projects.

object

variables

assume

model

on objects,

increase

specifications

stance

concluding

results

always

is a template

how

some

counters

A class

some

8 gives

ming

An

constraint

in terms

6 describes

Sec.

We assume

model,

be

the

each method

Sec. 7 discusses

to existing

Language

Our model

Sec.

interface.

informally

based

might

and

example:

be the

negative,

and 4

For

might

t.he invariant

method

Sec.

t,ime.

type

and

specialization

how

over

are never

we refer

paper.

for the

5 describes

focusing

applied

the

interface;

verify

grouping

an example;

specifications

specialization

remarks,

using

throughout

Sec.

interface.

assumptions

3 illustrat.es

dependencies

to t.his example

2

language

evolve

of a counter

integers, that

or of subclasses.

type

a work-

override (Fig.

add! a),

is one such class. for IntSetClass.

class IntSetClass % state [ s:IntSet, c:IntSet 1 s holds the contents of the set % c caches membership hits % % invariant se1f.c & se1f.s

Although tion

subclasses.

terface,

specification

the

to cache

though

a set groups

and els

must

size

gether

grouping in (l),

than

variable

add,

end % Line 1: self.add(el) self.valid := true self.cache := el end return(true) end member

as

well

code

the

choice

This

remove!

invalidate0

% Ensures selfpo,t.c = {} self. valid := false end invalidate end IntSetClass

of size required version

must

202

also

the

given

line

method

add

instance

method

grouping

that

subclasses

when

The

the

the

ensures

member

they override

same

is true

in remove

for the

rather

than

directly.

dependencies

and

inherit

others.

methods is called in Fig.

by member, implements

make

for

override Programmers

to understand

Consider, which

that

For

on

what about

assumpoverriden

example,

the

method

by member.

The

version

2 happens while

an

to be what equally

the specification:

method size0 returns(Int) % Ensures result = 1to.!?et(selfprc.m)~

class.

to-

of subclasses. member,

by the

bit

need

inherited

methods. size,

and

such as IntMultiSetClass

methods

tions

all three

to programmers

to call

size.

Behavior

of subclasses

% Modifies se1f.c

as

choice

and

Subclasses some

If a sub-

invalidate

manipulating

the valid

3.2

set.

cache

for

to call invalidate

clearing

add,

the instance

the

and

and

is driven

class.

choice

maintain

have to override

the

will be able to inherit

returncfalse)

Memtogether

methods

is important

directly

els

of the

The

member

valid

of superclasses

rather

variables.

together.

Method

marked

for

were to use a tree represen-

maintain

example,

tests,

responsibility

to represent

Similarly,

be overriden

used

to clients.

be overriden

together

used

for sets, it would

methods.

method member(el:Int) returns(Boo1) % Modifies se1f.c % Ensures result = el E se1fpre.s if -self.valid or self.cache -= el then beforeSize:Int := self.size() self.remove(el) if self.sizeO = beforesize then

share

of instance

class of IntSetClass tation

membership

Taligent941).

variable

in-

the cache

is irrelevant

often

bers

remove

suited

dependencies

maintaining ([Lamping93,

of sets

better

esposes

successful

methods

of such

inter-

in terms

For the specialization

the cache

Grouping

Multiple

method size0 returns(Int) % Ensures result = Iselfpre.sl return(self.els.sizeO) end size

1: IntSetClass

to potential

inter-

For the client

of something

3.1

index:Int := self.els.find(el) except when not-found: return end self. invalidate0 % Empty cache := self.els.top() self. els[index] self. els. remhO end remove

specification.

in terms

in attempting

and specialization

rather

than

this specifica-

practice

the client

is expressed

by member

% Ensures selfpost.s = selfpre.s - {el}

usual,

face, the specification

even

method remove(el:Int) % Modifies self

than

of current

both

faces in a single

method add(el:Int) % Modifies se1f.s % Ensures selfpost.s = selfpre.s U {el} index:Int := self.els.find(el) except when not-found: self.els.addb(el) end end add

Figure

formal

is typical

to specify

els:ArrayCInt] % used by add, remove, and size valid:Bool % used by memberand invalidate cache:Int % used by memberand invalidate

protected method

more

plausible

is

class IntMultiSetClass % state [ n?:IntMultiSet, c:IntSet % invariant se1f.c C toSet(se1f.m)

class,

1

so the

make the

superclass IntSetClass els:Table[Int,Int]

fications

method add(el:Int) % Modifies se1f.m % Ensures selfpost. m = add0nce(self$.m, self. els Cell : = self.els[ell + 1 except when not-found: self.els[ell := 1 end end add

perclasses. el)

spaces

are the

freedom

the

superclass

tion

of the

described

4

types

are

labor

specification:

type

abstraction

value

spaces

are

classes

is

IntMultiSet, terms

not

a the

of a different

solution. subclass

state

are

method-name*]

value

space

of

the

code

sub-

illustrated

by

the

in

state

specified

manipulate indirectly

group.

in

explained types

substate

if any then

be overriden,

a of

manipulate

methods

is overriden,

must

subof

representation

methods

by calling

responsible

the

methods

In a subclass,

group

Fig.

in the method

all meth-

and the new

for implementing

specification

the

later). object

of exactly

for IntSetClass

existential

3 (the

as tuples

of IntSetClass

container

203

the

group

of a method

the

other

The

method

maintaining

Only

and

groups

classes.

each

methods

for

substate;

field of the entire

super-

within

The

state

These

substate.

object

into

the

specifi-

the

groups. with

group.

becomes

group’s

partitions

into barriers

directly

group’s

substate’s

than

of

*3

a specialization

responsible

of a method

incorrectly.

As

a division

{ [substate

associated

the substate

is often

interfaces

with

+

substates.

called

group

the

specifications

interfaces?

specialization

specialization

of labor

form

be superclass

Object

labor-div

of a class

is given

Inheriting

client for

together

combination

,4 division methods

class.

to function

is

a signature

object-type

A specialization

member

constraint

+

ods in the group

cause

the

cation.

group

would

specifica-

of objects.

sufficient

specify

an object

labor-div

% protected method invalidate0 Modifies se1f.c % Ensures selfp,,bc = {} % % Code inherited from IntSetClass end IntMultiSetClass

2: IntMultiSetClass

of

that

give both

way to specify

We

with

We call this

types

not

special-spec

% method member(el:Int) returns(Boo1) % Modifies se1f.c Ensures result = el E toSeqse1fpre.m) % Code inherited from IntSetClass %

Figure

This

specification

are a good they

interfaces.

method size0 returns(Int) % Ensures result = c, cozlnt(se1fpre.m.Z) result:Int := 0 for key:Int in self.els.keys() do result := result + self.els[key] end return (result) end size

su-

specifications

object

a behavioral

but

their

specification

requiring

be identical.

have

in Sec. 5.3.

Specialization

and

when

must

on the

without’

not

speci-

from

the

as a constraint

In our model, el)

differently we use

subclass

Even

inheriting

subclasses

to behave Inst.ead,

does

context. same,

is too restrictive:

two specifications

method remove (el : Int ) % Modifies self % Ensures selfpost. m = removeOnce(selfpre.m, count:Int := self.elsCell except when not-found: return end if count > 0 then self.els[ell := count - 1 self.invalidate() end end remove

specification

sense in the subclasses’ value

the

super&sses’

We

describe

with

named

type’s one

method with

the

will

sorts

fields.

of

Each

sort is assigned

is described

field h associated

clause

group.

to The

as an integera method

group

specialization

specification

IntSetClass

IntHolderTrait:

state [ k:IntHolder, c:IntSet 1 invariant e E se1f.c j mem(se1f.k. e)

introduces new: + IntHolder ins: IntHolder ,Int -+ IntHolder del: IntHolder, Int - IntHolder mem: IntHolder, Int -+ Boo1 measure:IntHolder- Int

method group substate C h: IntHolder 1 existential ins, del, measure method add(e1: Int) Modifies self. k Ensures selfp,,t.h = ins(selfm.o.k, el)

asserts IntHolder generated by new, ins Vk:IntHolder, i,zl,12:Int ins(ins(k,

method remove(el : Int 1 Modifies self Ensures selfpost.k = del(selfpre.k,

-mem(

j, iz) = ins(ins(k,

Figure

1

method member(el:Int) returns(Boo1) Modifies se1f.c Ensures result = mem(selfpre.k, el)

After trait

method invalidate () Modifies se1f.c Ensures selfpost.c = {}

giving asserts

property

specification.

signatures their

states

that

The next

assertion

ins.

measure

Informally, tion that

contains

size,

and

method and

group

methods

add:

field

that

remove,

c associated

contains

and with

the methods

member

unordered While

integer

too

scribes

containers

the integer

propriate value

of h. are modeled

sort specific

space

sets

allows

more

tion

symbols

tions;

these

in Fig.

that

subclasses.

functions

defines can

be

define

IntHolderTrait

defines

the functions

new, ins, del,

an

properties used sorts.

IntHolder mem,

The

mem in terms

of new

are properties

of de1

for member. for specializa-

as follows:

A class implements

the methods

for

of that

specialization

its specialization

each

method

group

will implement

of other

their

group,

specifications

implementations meet

of ins

applications

correctness

if,

that

can be

for

method

all

groups

own specifications.

1 are an apBy this

they

a more

using

of

IntHolder.

of IntSetCIass,

values

A trait

a space

called

for subclasses:

IntHolder

([Guttag93]).

used

for clients

using

by

ins functions.

by the code

we define

the

is unordered).

assertions

specification their

values

that

define

specifications Def:

a

invalidate.

The

are

the a cache

states

assumed

values

new and

the

IntHolder

The final

functions,

The generated

all IntHolder

two assertions

and

for these

just

(thus,

and

trait.

properties.

using

next 3: Specialization

i2), il)

4: IntHolder

generated commute

end IntSetClass

Figure

il

new, i)

mem(ins(k, il), &) = (il = iz v mem(h, iz)) mem(k, ;) + ins(del(k, i), i) = k lmem(k,i) j deZ(k,i) = k mem(k, i) + measure(del(k, i)) < measure(k)

el)

method size0 returns(Int) Ensures result = measure(selfpre.k) method group substate [ c:IntSet

trait

group

general

Fig.

4 de-

LSL

trait

plementation every

In this

method

case,

in terms and

if a subclass

specifica-

To

of

measure.

classes

204

the

group of other overrides

groups

the in

of a method

on a particular

method

must

a method

im-

Instead,

for any im-

groups. group,

This

way,

inherited

be correct.

freedom

defining

group.

be correct

method

will still

maximize have

correctness

to depend

of another

method

plementation

of func-

in

definition,

is not allowed

the

designers

of sub-

behavior

of sub-

classes, tions

the

In client

are treated

tified

of specialization

be different

ifications. bols

semantics

must

over

from

specifications,

entire

spec-

function

specifications,

program.

we trea.t

symquan-

where

In specialization

function

of universal

if ol.do-fn(0) = o2.do-fn(O) then x := true else x := false

specifica-

of client

as if t,hey were universally

the

combination

those

symbols

using

and existential

a

fn

the trait:

FnTrait : trait introduces fn:Int -> Int

that

would

program

would

have

symbol

fn used

tion class Fixpoint % state

functions

dinarily, tion

% method group % existential fn deferred method do-fn(x: Int) returns(Int) % Ensures result = fn(z)

and

traits.

function.

or false

fn could

denote

because

must

end Fixpoint

the constraints on fn are weak:

constraints

that

it is a function

In client

are quantified must

from

specifications, the

even

defined.

same

if that

This

making

Inside that group, the symbol using esistential quantification:

t,wo different

modules

function

to make

function

symbols

The only

properties

are

those

bols

are

can denote

contradict

properties

of

assumptions each

one can assume listed

over function

in

assumes

traits,

different

To see the difference,

function

classes,

i.e.,

within

a class,

functions consider

they but

in different the following

facilitates dofn

group

satisfy

by traits. specializaof Fixpoint

for fn and thus

for different

values

of fn.

can

For ex-

returns(Int)

about other

specifications,

quantified the same

authors

that

for

the class:

class Zerof ixpoint superclass Fixpoint method do-fn(x:Int) return(O) end do-fn end Zerof ixpoint

by

globally.

In specialization denote

that

the

modularity local

ample?

symbol

quantification

be specialized

they

the

is interthe code

as it is correct

all functions

on the

interpretation

For example,

uses existential

completely

for independent

about

are shared

i.e.,

throughout is not

supports

other. which

program,

put

be

for exis-

existential

optional

as long

by

can

group

clauses.

t.ion.

like fn

symbol

interpretation

Existential

is

to integers.

symbols

function

approach

it impossible

a symbol

integers

function

over the entire

denote

program,

all we know

on the symbol

one method using

the

for all funct.ions

put

a specification

is correct

Or-

a specifica-

quantification:

be correct

some but not necessarily

The

quantification.

tential preted

func-

a combination

interprets

universal

to (at most)

of the group

so dofn

specifications,

the constraints

% method group method is-f ixpoint (x: Int) returns(Boo1) % Ensures result = (r = fn(~)) return(x = self.do-fn(x)) end is-f ixpoint

With

subclasses

using

group

However,

assigned

02

be true

universal

using

satisfy

the

and

be different.

a method

code of the group that

over

of 01

x could

are interpreted

symbol

because

the same

in specialization

symbols

different semantics,

function dofn

in different

02 could

of existential

[ 1

same thus

to compute

Further,

class:

the and

of

client

if statement

the

semantics,

of 01 and

in the

instances With

if statement

the

different a function

are

after

denote

entire

after

02

be true

specialization

introduces

following

and

of Fixpoint.

x must

quantifi-

cation. Consider

01

subclasses

that

sym-

ent

must

contrast, thus

they

classes.

functions.

isfixpoint possibly

fragment:

205

is the

constant

of Fixpoint The

can

code

uses universal

must

of Fixpoint

code

fn

subclasses

be correct

for

contradictory,

zero;

assume

differ-

isfixpoint,

quantification for

any

can be inherited even though

function

they

fn. into

for fn and As a result, all subclasses

can make

assumptions

in

different:

about

fn.

We can formal

offer a more

now

definition

detailed

of correctness

but

still

in-

section

for specialization

discusses

each

basic

techniques

5.1

Specializing

point

to handle

in turn,

presenting

the common

cases.

specifications:

Def: A class implements specification the

if, for each

code

some

of methods

values

assigned and

its specialization

all

A method

group

G,

in G is correct

of the

specification

existential

(via

for

method

values

for to G

Specialization

Our

approach

specialization simulation

that

is based

specialization

not found

in the traditional

discusses

three

l

symbols,

one can choose

the

verified.

of

group

those

work

to treating

mentioned

in Sec.

specialization

wide

dealing

will satisfy

it by inherited range with

of

ensure

its specification

and

by su-

that and

assumptions

inthat

made

code.

techniques

each of these

this is a central other

specifi-

of their

issues.

are

available

and

for

206

con-

provide about

the

to ab-

invariants functions

they

unordered third

can serve

and to doc-

of mem.

5.2

Verifying

Once

the

been

specialized,

group three

integer

containing

properties

to

sets:

= ins(ins(h,i),i)

i), i’) = (i # ,i’ A mem(h, = C;( mem(h, asserts property

that

ins is idempotent;

containers.

define

i’))

i) ? 1 : O)l

distinguishing

integer

properties

terms

uses into

sets from The

de1 and

second

measure

in

a group

specification the

of a method code

‘The value of the conditional t is true and a otherwise.

The rest of this

ex-

not

and are similar

abstraction

size

IntHolder

The first property As

be constrained

constraints

meets

code

specialization

must

remove

,measure(h)

abstractly.

of subclasses.

specifications

These code

overriden

A

3.2,

of subclasses

herited

methods

must

properties

the method

ins(h,i)

in

interpretation.

representation

invariants,

as-

implementations.

mem(del(h,

treating

abstractly

and Like

regard.

specialize

of the

These

of a group,

been

conservatively

used in reasoning

functions

to ensure

includes

groups

their

add,

be can

be asserted

have

i.e., they

old ones.

information

In IntSetClass,

implementations

specifications

perclasses.

about

This

the

that

must

old properties,

representation

in terms

groups

all

of other

Constraining

the

other

groups.

substate

cations

is verified

the

in this

is

can

group

of behavioral

can

for existential

straction

of a group

properties

properties

implementation

After

rules

to the group

ument

group the

the specifications

the

signed

a group.

independently.

with

following

additional

function

the code of the group

of the

will

addition 0

in verifying

symbols

specialized, The

it

the

step

function

specifications that

quantified

verifying

First,

symbols

auxiliary

inter-

ways.

specification

tradict

of

appropriate

method groups

have been

speci-

function

any interpretation

of existentially is the first

some

and then

in Sec. 5.2.

about

tend

is verified

([Liskov94]).

Second,

verify-

whose

quantify

Choosing

existential

section

When

of methods

existentially

Verifying

This

other

group

by strengthening

methods

The additional

groups.

correctness

symbols

issues

ones:

fications

pretations

be specialized

for

specialization.

of a method

in two

as

properties

code

the

its specification

as long the

the

on method

as discussed

subtyping

raises

(b)

depend

specification

of its

However,

context.

method

symbols.

its

on standard

interfaces

central

Specializing

a cla.ss meets

([Hoare72]).

verifying

ing the

The

to verifying

at least

for a specialized

specialized

specification

be specialized

and

not

by specializing

verification

techniques

those

does

the code

5

can

implements

specification

Code

specification

group

code

groups

symbols.

l

the

in its

symbols

clauses)

of other

(a)

method groups

of the

term

group

group

can

has be

“t? c : a” is c when

A method

verified. dently

of the

groups;

group

implementation

t,his ensures

regardless

of whether

pends

are

on

plement.ed

other

inherited

method

or

groups

it deim-

by

tions

work

superclasses,

overriden

this independence

will

The

two difficulties: The verifier the

code

t,he code group,

of a group

of other

of methods but

ternal

these

to the

know

that

The

not

And

alt.hough

external

instance

of this

from

the

state

and

a single interfaces,

not

know

verifier

does

methods

and

to

the

verifier

does

associated

with

those

about

them

per

group

and

we

take

return

For each

S

tuples

a new

1 and

for verifying

the

S

method

=

the

group,

entire

the substate Ri,

As with

with

named

fields,

ni Si,

where

tuple

dist.inct

with

function

abstract assigned

denote group.

with

tuple

the

S; denote

method

that

subabstraction

in

Let

ith

assume

named Table

substates

S and S; are tuples

products and

into

of self and

to the

we assume

method

section

specifications,

groups.

assigned

ith with

in this

needed

be the

of IntSetClass.

specialization

state

can

denote

variable.

defined

of self is partitioned method

the

instance

values

abstract

languages

R; is a tuple

symbols

particular

In

to

assigned

by

we omit

they R;

or

relaxed

Although Let

and

read

but

assignments,

assume field

be

step,

convention.

We

gives

specificaknow

concrete

field-names

the fields the

of both.

verifier

defines

a

Ai:

When

group.

only

Each

method

fied with it.s own subabstraction

by guaranteeing

groups’

correctness that

method the

group

a single

class

fully

by

in

how

the

to represent

group,

well as the treat

as-

defined

is veri-

verify terms

group’s the

needs

of

the Ai

methods

sub-

h part.

Our

by other that

groups.

solution

i#i

207

the

is, inside

self is described self : R; x n

i not

of self as

is for group

includes That

group does

for example,

the c part

by:

funcfunc-

of A;

because

to manipulate

self as if it already

we assume

is ensured

abstraction

instance

group’s

self. In IntSetClass,

define

is one

without

subabstraction

cannot

directly remove

substate

function

of the

We

the

specializaThere

defines

are used

state.

simulation defines

function

variables

abstraction

verifying

for each

This

sim-

of self is defined

define

of other

this

functions.

functions

Overall

methods

function

state

S;

abstraction

traditional

abstraction

Ai I Ri +

is done

of self to the

that

under In

the

an

state

showing

function

to that

interfaces

establishing

subabstrnction

subabstraction

tions.

by

variables

by

not

can reason

of self.

state

tion

knowledge

enforced

group

group

can

for simplicity. such

variable

method

of that

verification

instance

one

one

a.ssumption

enforce

add method

spec-

does

variables,

([Hoare72]).

these

full

using

of these

verifier

specifications

entire

signed

the

i.e.,

abstract

and

not

exactly

ea,ch instance

methods

extra

summarizes

variables

does the

in terms

and

function

multiple

verifier

of specialization

via simulation,

proofs,

an

that

substat,e.

Verification

function

This

state

substate

variables

it.

group.

only

defined

of external

them

the abstract

their

instance

methods,

tions.

ulate

to the

are overcome the

about

terms

not

verifier

variables

difficulties

of external

instance

does

access The

instance

the specifications

know

ex-

or subclasses.

reason the

verifier

have

self.

Although

code

know

not

locally-defined any

of these

the

the

write

this extension

method

methods

to the

do

of self is a set of instance

state

only

func-

group.

We assume

that

fields: of

the

ifications.

and

call

to

knows

to the

methods

does

superclasses Both

verifier

concrete

adding

code.

verifier

and

The

internal

group

representation knows

does not have access

groups.

of the subabstraction

method

is assigned

overcoming

of self can be constructed

state

the product

of each

variables.

subclasses.

requires

for the entire

by taking

method

group

from

tion

indepen

of other

a method

locally,

Achieving

is verified

Sj

i to

substates group

i

Under

this

assumption,

an abstraction

we verify

: (R; x ES’;,

self a.lready

Because

-

contains

by A;, J$ is not

defined is defined

nj,i

freely

s /, R; is

chosen

according

the

s

the

calls

methods

simulation

to methods

in other

of the

to reason

about

IntSetClass.

We

verification

here,

illustrate

the

Recall

that

assuming function (the

set

instance

do

methods

perform show

are

this for

that

To verify

groups. group

Va,s

by

IntHolder.

group)

empty

values.

to

the specification

into

which

Aars

V ars with which method group: Vars(s)

We

=

ins( toH( rest), i)

to show

the

we verify

for building Aars each

empty

In

con-

code

the

element

method

into the domain

clause

the the

to

of the Va,,

composing

of add yields: el)

proof code

rules of the

of the

el) language

method

meets

its

specification. code

for

is called

in Vars(selfpre).h. proceeds

we compose

of the

= ins( toH(selfp~~.els),

use

add, only

the when

Thus,

addh el

method

is not

the verification

of

already of add

in two cases:

function in the

add

1. When

el

is in selfpe.els,

we can

conclude

that

=

[h 11 Aar-(s).h,c

:= S.C]

=

[h := toH(s.els),c

:= s.c]

mem(Va,s(selfpre).h) Also, because in this

*The tuple denotes a tuple

i

to:

that

self.eIs

set.

abstraction the

then

transformed

words,

by inserting

follows

i

= ins(Vars(selfpre).h,

expands

new

an initially

group

For example,

Vars(selfpost).h

=

In other

an IntHolder

of self.els

for group

in the add group,

specification

the ensures

with

by the group):

addh are functions

and

Array[Int]

From

the

implementation.

the subabstraction function maps els to the

a method

toH(selfpost.els)

toH( addh( rest, i))

structs

c : IntSet]

function

with

transform

where:

and

[h : IntHolder,

Subabstraction

(Ri x njzi Sj) --+ 5’ As (s I Ri) x Ai(s r Ri) As . [h := lo~(s.els), c := s.c]

II

= [h := toH(s.els)12

toH(empty)

add,

a full

pieces

method

assigned

maintained

Aars(s)

groups,

not

Aars, This

variable

substate

method

properties

for its group.

containing

size.

Ri - Si As [h := ioH(s.els)] Function for verifying

(see,

methods

specialized

we need

add,

Vi

i using

=

rather

we have

of IntSetClass

%. t.he

on the add method

use of Vi to verify

integer

To verify

h (the

but

group

for Z = ars,

l-Ii si

the calls.

our approach

values

Instance variables assigned to group i [els : Array [Int]] Sort of substate of group i [h : IntHolder] Sort of entire state of self

rather

these

external

groups.

5’; is

techniques

Where

We illustrate of

group and

and s ‘/ Ri

of group

Dah192]).

specifications

used

method remove,

method

by method

are particular

T Ri)

the Ri fields

without

to standard

[Liskov86,

make

but

for verifying

are parameterized

given

the R; fields.

only

verify

e.g.,

Symbols Also

5’j and

1: Symbols

by the equation:

is s with We

Table

S

T/;(s) = (s 1 R;) x A;(s where

i using

Vi t,hat has the signat.ure:

function K(s)

group

constructor “[fi := ~1, . . ..f., := value where field fz has value v,.

addh is not called

to change

case? we can conclude:

~~1”

Vars(selfpost).h

208

= Vars(selfpre)-h

self

Putting

these

t,wo conclusions

together

which

with

simplifies

to:

the lemma self.valid nzem(ht i)

a

follows

show

that:

from idempotence

= ins(r/g=s(self~~~).h,

So the ensures 2. When to

of ins, we ca.n

this,

member

el

is

reason

clause not

invocation.

is met

the

in this

effects

It follows

from

the

addh

definition

of

toH that:

From

this

we can

e)

show

addh

that

after

the

So the ensures A complete

modifies

the

the

preserves

clause

requires

of add

groups

as described

above.

cannot

explicitly

their

clause

and

that

only

h field

the

modified.

The invariant

of h after

the call if it is a subset

We do not present Verification it depends

these

of IntSetClass.

ing member

and

invalidate,

valid

and

cache

to the

have

[C

:= ( s.valid?

this

we can

define

Composing

the

In this related

1. The

subclass

behave

subab-

group

contain-

the

instance

substate

invariant

of IntSetClass

in

first

field

the

+

mem(self.h,

related

to that

superclass

specifi-

sort,

invariant,

and

of labor

spec-

assumption

the

two

in a mo-

specifications

specifications

are

of all

methods

specifications.

their

of inherited

superclass

their

superclass

ensures

meth-

specifications.

of the

herited

e)

209

seem

specifications.

we can as

assume

specified

that

in the

meet might

that

methods

that in

the

we assume

superclass

rule

However, override

by the

one

because

assumptions

superclass.

class

rule, behave

by stated

only

and

not

stronger.

to inherited

: {})

overriden

superclass

specified

‘The

assumptions

Rule two ensures

It might already

first

methods

about

specifications. the

their

if overriden stated

methods

meet

in

superclass

assumptions that

do

them

something

the

in the

the

superclass.

function

with

specifications

meet

rule

Because

yields: {self.cache}

inherited

specialization

division

this

superclass

subclass

the e E (self.valid?

and

value

case,

a.s specified

them

I= Ami(s).c] function

access

if:

their

methods

: {})]

an abstraction

abstraction

same

ment).

the behavior

this

inherited

verify the

we

of correctness for specialization BY our definition specifications, inherited methods will continue to

because

{s.cache}

= [h := s.h:c

sub-

the same

ods are implied

Vmi for member: Phi(S)

the and

inherited From

the

properly

about =

we that

(we will relax

the call.

c: Ami

that

2. The subclass

specialization

maps

groups

of a class is properly

imply

here.

Ami:

for the method

that

c is a subset

before

of the

of its

of self is

is interesting

on the invariant function

variables

that

verifications

of member

specification straction

requires

each

However?

we do not have

requiring

ification

modifies

The

method

because Instead,

by

constraints,

involves

verifying

the invariant.

verify

code.

Assume

el)

also

IntSetClass)

method

superclasses

the

of its superclass.

is met in this case too.

verification

verifying code

clause

(e.g.,

verifying

from

for

and

subclasses

by explicitly

cations = ins( toH(selfpre.els),

it is correct is true

cache.

no superclasses

specification

method: toH(selfpo,t.els)

equals

Constraining

methods e)) = ins(toH(nrmy)~

that

if valid

can be verified

to

toH(addh(nrruy,

true

to member

A class with

case. we need

of

the

5.3

el)

selfpre.els,

in

about

self.cache)

one can conclude

to return

argument

li~rs(selfp,,~).h

nzen(self.h,

h = ias(h, i) Given

which

+

made

about

a subclass

a method

subclass.

need

inherited

group

By requiring

not. a.pply methods them

by

of the

sub-

that

is in-

that

the

subclass ply

specifications

their

made

superclass

about

ments

methods

that

above

two

may

rules

for soundness.

sub-

and

override the

basic rules

invariant

and

method add(el:Int) Modifies self Ensures selfpost = selfpre end add

requireallow

t.o vary

The

sort

than

the

subclass

can

The

the

be

method remove(el:Int) Modifies self Ensures selfpost = selfpre end remove

different

subclass

ods

groups

tirely

from

the

sort

group.

add

a single

new methods

it is overriding

and

Figure

to meth-

can

add

verification

At

run-time,

a program

not

classes.

Objects not

would

manipulates

goal

by

of

our

In

As

fication

to the

portant

difference

specialization cation the

general

one

in Fig. in

the

is given

is

IntSet yet

internal

cache

specification. tend

than

specialization

To validate client

client

rather

than

client

exposed specific

specification,

the

client yet less

verify

specification

interface

the

more

specialspecifica-

specification but

many

in Fig.

cialization

this

210

To verify

of one

the

of each a single,

of client

method

specialized

for each group specification

specification. are specialized,

must

e.g.,

in [Liskov94].

However,

used.

group

code

specifications

not

imply

by using

For example?

specification

the specializathe

be equal

The implication

ways,

the code in Fig. 1 against 5.

the

this specialized

it need

specification.

described

the code of that

to form

the client

all groups

such follows

of a method

if the specializations

will imply

cation,

of IntSetClass,

are

the

so structured.

specializations

correctly,

tion

detailed

is already

verifying

are chosen After

process

specification

before

are combined

structure

interface

the unspecialized

groups

specification;

specification by the

other

group

of

the

When

group,

the

specifi-

be-

is not avail-

interface

of the client

is specialized

verified.

is to

specialization

section

process,

im-

in terms

superclasses

methods

the verification

previous

and

specifications.

the client

directly

The

the

an

In fact,

method

speci-

of client

In general,

to be more

this

3 illustrates content

is specified

IntHolder,

tions

we could

comparing

specifications. specific

the

ization

the

aside,

of IntSetClass

more

hides

an

for IntSetClass

of the

that

group specification

with

approach

the correctness

in the

client

their

alternative

as well.

methodology

meet

for classes

for verification.

that

client

specifications.

classes

work

verification

objects,

described

specifications. 5.

of IntSetClass.

the code for inherited

An

specialization that

not

cause able

are

ultimate

in Fig.

specification

en-

are possible.

Client

A client

5: Client

groups.

6

be to ensure

method member(el:Int) returns(Boo1) Ensures result = el E selfpre end member end IntSetClass

function. method

can

specifications,

of

can be

into

{el}

method size 0 returns (Int 1 Ensures result = 1toSet(selfpre)1 end size

the

two or more

differences

the

of

superclass

new method

more

space

can merge

of the

The

subclass

if the two specifica.tions

subclass

Thus,

value

by an abstraction

groups

in the

{el}

U

more

in the superclass.

defining

the superclass related

constraint

IntSetClass

along

them.

specifica,tions

can be stronger

must

are passed

are

client specification state IntSet

For example:

The

Even

im-

assumptions

Additional

superclass

broadly.

methods

specifications,

inherited

to subsubclasses The

of inherit,ed

for

client. to the

specificlient

can be checked the the

simulation specialized

IntSetClass

in

rules speis the

specification erties not

in Fig.

for ins, equal

using

3 specialized

del, and

the

with

measure;

specification

the abstraction

in Fig.

be

new prop-

clearly

this

5.

incorporated

that

does

maps

client

However,

Related

[Lamping93] work d(new) d(ins(h,

i))

=

{}

=

d(h)

Client

client

u {i}

work

Client

public

often

not

preserved

clients

by

cannot

invariant

preserve

break and

consider

shown

to

to

help

ited

methods.

the

specialization

ing substate is important

arise

because

properties

that they

can be hidden

from

tion

are

them.

x

value

of x is even).

is

always

cannot

even

guidelines

because

the

guidelines

ization

specifications. the

explain

that

to test

only

the invariant

like member

initial

At the

specialization

likely

the

returns (Int)

be incorporated specification

that

same

time,

and

as explicit or they

can

211

to invoke

declarative

details

work

on behavioral

([LeavensSO,

and

reasoning

modular

use of subtyping,

facilitate

modular

the

is different

and

By

group

ac-

substate, methods

other

methods.

specifications operational

that

are

are ones,

easier

to capture

to un-

accidental

as invocation

order.

is another

area

America91,

Liskov941).

subtyping

ification

of specification

instead.

than

such

subtyping

Work

work

it calls invalidate.

can force

are less likely

lated

add, and

of the group’s

to specifications

meth-

specification

of a method

abstract

of

of member

their

specifications

to be more

of other

specifications

and remove

Behavioral

client

explain

cess to the representation

implementation

can

and

the methods

declarative

the behavior

calls remove,

membership,

would

specifications.

specification

member

informal

by [Kiczales92]

explain

their

sists in the

proposed

i.e., they

special-

uses

we use formal

of invocations

our

C

invariants

[Kiczales92]

where

documen-

to our

in terms

leading

method inc 0 self. add (1) return(x) end inc end D

we feel

documenta-

The

analogous

example,

For

derstand

Client

are

We use declarative

like

which

and

a method

allowing

of subclasses

groups associat-

in a modular

design

specifications

of remove

following: class D superclass

groups,

ods. size

the

partitioning

suggest

for class libraries.

tation

would

(assuming

However,

do

of inher-

method

not

our

e.g., they

subclassing

presents

specifications

method inc2 () returns (Int ) self. add (2 ) return(se1f.x) end inc2 end C

that

into

method

to using

[Kiczales92]

the class:

can incorporate

thus,

where

suggests

it does

the and

the behavior

interface

with

and

[Lamping oriented,

[Lamping

are operational,

interface

subclassing

Both

about

to our

manner.

are

Because

properties,

on

oriented;

one reason

show

protected method add(d: Int) self. x := se1f.x + d end add

invariants

emphasis interface.

is specification help

Also,

The client

to the

are related

are type-system

a client

class C x:Int

interface

[Lamping

as we do; however,

methods.

these

their

implies

invariants

protected

to clients

For example,

be

specification.

specification

specification. methods

can

can be used

invariants

a specialization

in

and

[Lamping

specification

the desired

that

function

specification

work

specialization

not

imply

abstraction

specification.

7

IntSet

where:

specialized

the

specialization

function:

d:IntHolder-+

the

into

the

consists

techniques while

of spec-

to facilitate our

reasoning

use of subclassing. in many

of re-

details.

work

con-

techniques

to

However, The

speci-

fications those

needed

needed

division

and

over

ing requires

strengthen subtyping C?

also

from does

that

the

always

answer

object-calculi answer

and

type

according

has the type

of self).

Many

support

MyType,

object-calculi Our

work provides

and

part

subclassing

of the

client

type

from

cause

of either

As a result, not

system.

the

of a class

the client

specification

of the

differ

or client

client

While verify

is not that

Our

reading

invariants.

to one

We have classing

of a class need of its

and

the

behavior

difficulties,

fication

and

ing dependencies groups.

manner:

state

only

group

ifications

of a subclass

are

some

calls

of speci-

work

Group-

for? but not

the It

Foundation

by

dows Library libraries

tion interfaces

212

substate substates

be used assigned of other

behavior

that

and

such Borland’s

the source

the documentation is inadequate with

of one

specialized

application

suggested

be-

of our of cla.ss

tha.t

vendors

as Microsoft’s Object

Win-

code for those of specia.liza-

([Atkinson92]). our own

is

speci-

documentation

been

distribute

cla.im is consistent

Al-

useful

libraries

because

should

on the

the

Classes

assigned

to another.

the implementation

most has

avoid

the specialization

depend

of object-oriented

the

the spec-

limitations.

what

is in improving

libraries.

method

handled

between

Perhaps

for

variable

can implement

than

To handle

and its superclass. has

A group specific

rules assign

and

assigned

the

it in-

some

groups

of a group not

formally

about should

the abstract

and

of another.

by partitioning

relation

an instance

in a method

should

of a class into

dependencies

a particular

or writing

havior

kind

group-

not

gives

to method

to implement the

do

programmers

variables

fication

sub-

techniques

do

programming

do reason

variables

group

of classes.

are handled

Behavior

methodology

a new

method

methodology

depen-

grouping

reasoning

interface

and abstract

to using

languages

simple

usually they

The instance

more

dependencies.

we define

requiring Our

obstacles

associated

specialization

method

conclusions

two

in a modular

dencies these

identified

groups and over-

existing

using

of the

method

groupings,

First,

group

groups.

and

code, so.

instance

be-

to

Summary

Although

programmers their

for doing

superclass.

8

into

state

independently

method

formally.

the

signifi-

specification

support

implementation

conventions.

subtyp-

specificat,ion

specialization

be a subtype

can

specialization

not

as a whole.

is a semiimplementa-

abstract

be partitioned

ings can be supported

“no” is not

Sec. 6 shows

and

the represen-

the

revealing

De-

to be sub-

there

reveals

without

should

between

that

methods

design.

intended

interface

pro-

Division a syst,em-

about

part-way client

interface The

riden

the

MyType

when

the

st,rategy

class

do not

to separate

such that and

arguments.

designers

classes

t.hat can be understood

type

languages

for answering

even

specifica.tion

cantly

(the

classed tation

details.

sys-

design

we currently

libraries.

for thinking

should

a.re

for designers,

of class give

our

correct-

a.rguments

to such

be useful

specifications

Also,

partial

and

approach

users

framework

tion

dispatch. verifies

termina.tion

should

multi-

tha.t it can be es-

correctness,

and

abstract

subtyp-

languages

reasons

on the

the type

for these

argument

that

MyType

object-oriented

of

Bruce931).

arguments,

expression

compelling.

atic

signers

assume

argue

differ only when

and

grammers?

of

working

total

Our results

to

a subtype

[CookSO,

to these

by itself ing

e.g.,

Separate

of labor

implicitly

systems

(see:

ness

for

clear

multiple

methodology

sym-

If D is a subclass

researchers

to handle only.

it to ha.ndle

it is not

have no systematic

separation

implement

extendeding

verification needed

a subclass

a subtype

the

languages

ing and subclassing tem

to

is “yes,”

is “no”

However,

relates

many

subtyp-

of methods.

subclassing.

D

Although

tended

over the en-

allows

we are

ple inheritance,

uni-

of function

the specifications work

while

allows

only

though

requires mixed

quantification

subtyping

from

of specifica-

class,

the interpretation

while

of C,

a single

,41so, subclassing

to specialize

Our

and

quantification

universal

tire program.

Subclassing

specifications

existential

symbols

bols,

are different

for subtyping.

of labor

versal tion

for subclassing

claim

This that

pro-

gra,mmers

currently

at source

code

have

to deal

bo either

with

guess

grouping

[CookSO]

or look

and

results

need

The

provide source

step

to separate

in

the

specialization client

an

of classes

to use

first

a,pproach that,

code

Inheritance

documentation

less

detailed

than

The

second

step

specifications

of the the

interfaces:

be

to

use

[Dah192]

is

client

of

specific

[Guttag93]

yet

for specialization

of

J.

arose

[Hoare72]

interfaces.

John

Lamping,

Wing ing

discussions Nate voorde.

We thank on earlier

Risacher

and

ideas

David

Evans

helpful

drafts

and

Jeff Schachter

and

com-

and

oriented

programming

tion

ha.vioural Obj.-Or&.

Lung.

Netherlands,

May/June

LA&‘CS 489,

with

pages

60-90.

of

OOPSLA

or fiction. (Vancouver, PLAN

Oct.

Published

as

Notices,

27(10):41-2.

K.

a statically-typed, ming

Safe

B. Bruce.

language.

ACM,

Ott,.

Print.

of Prog.

1993),

pages

type-checking

object-oriented Proc.

20th Annual

Lang. (Charleston,

285-98.

ACM,

Jan.

as SIGACM,

Oct.

J. Lamping

as assertions. Italy, 821,

the

specializa-

‘93 Conf. Oct.

Notices,

Proceed-

1993).

Pub-

28( 10):201-14.

and M. Abadi. MethECOOP ‘94 Proceedings

July

pages

G.

T.

1994).

GO-80.

Leavens

about

use

Published

as

Springer-Verlag,

and

W.

E.

object-oriented

Conf.

Proceedings Published

(Ottawa, as

ACM,

B. Liskov

Weihl.

programs

ECOOP/OOPSLA

subtypes.

1990).

[Liskov86]

Canada,

SIGPLA:V Oct.

specification

MIT

Press/McGraw-Hill

Oct. Notices,

1990. Abstraction

a,nd J. Guttag.

and

‘90

in program

development.

Book

Co.,

1977.

in [Liskov93]

programSymp.

Typing

1993.

25(10):212-23.

as SIG-

1992. [Bruce931

Oct.

Reasoning

Proceedings

Published

Proceedings

Published

DC.

ACM.

[Leavens901

reuse-truth

‘92 Conf.

1992).

Isof class

1994.

The

Springer-Verlag,

Panel:

1992).

as SIGPLAN

that B. Atkinson.

Lamping.

27( 10):435-51.

OOPSL.4

interface.

LNCS

1991. [Atkinson921

J.

specification ‘92 Conf.

J. Lamping.

(Bologna,

be-

(Noordwijkerhout, 1990).

Oct.

lished

ods

object-

Foundations

subtyping.

Informatica, 1972.

and and

ings (Washington,

Sheryl

an

language

of correctness

Acta

K iczales design

Notices,

[Lamping93]

reading.

Designing

Formal

1993.

Proof

OOPSLA

[Lamping94] P. America.

Horning.

Vande-

References [America911

1992.

1992.

Ka-

for proof

G.

PLAN

from

Deepak

paper,

J.

Springer-Verlag,

(Vancouver,

regardGarland,

discussions

of this

[Kiczales92]

in

libraries.

Mark

125-

NJ,

J.

Springer-Verlag,

Jeannette

Steve and

pages

Tools for

representations.

sues in the

benefited

Cardelli,

Proc.

Programming.

and and

C. A. R. Hoare.

we thank

our e-mail

Reinhold:

and

and

thinking

Luca

Mark

pur for lengthy ments

Our

with

Osgood,

Liskov,

answering

papers.

the

in [Lamping93];

Barbara

for patiently their

combining

those

1990),

Cliffs,

Guttag

1(4):273-81.

from

with

S.

labor

Acknowledgements work

V.

Languages

of data

[Liskov93]

Jan.

Englewood

Specification.

P.

of Prog. Lang.

Verifiable

Dahl.

Larch:

specifications. division

O.-J.

and

1990.

Prentice-Hall,

and

specifications more

specialization is

on Print.

CA,

Jan.

L. Hill,

is not subtyping.

Symp.

Francisco,

35. ACM,

eliminate

W.

as documentation.

improving

should

(San

to informal

should

specifica.tions

interfaces

This

Cook,

17th Annual

documentation the

R.

Canning.

behav-

ior dependencies. Our

W.

on

B. Liskov

cations

SC, Jan. 1993.

213

and

their

and

OOPSLA

‘9.5’ Conf.

ton,

Oct.

DC,

J. M. Wing.

use in defining 1993).

Proceedings Published

Specifisubtypes. (Washingas ACM

SIGPLAN Oct.

B. Liskov notion

Prog. Lung. Nov.

28(10):16-28.

ACM,

J. M. Wing.

A behav-

1993.

[Liskov94] ioral

Notices,

and

ACI!~ Trans.

of subtyping.

and Sys., 16(6):1811-41.

on

ACM,

1994.

[Taligent94] signing

Taligent. Programs:

Taligent’s

Guide

to De-

Well-Mannered

Oriented

Design

Reading,

MA a,nd London,

in G-t.

AddisonUK,

ObjectWesley,

1994.

214