Object-Oriented

Schema

Extension

and

Abstraction

Walter

H?ursch

and

Karl

Lieberherr

College

of

Computer

Science

Northeastern

University

Sougata

Mukherjea

College

of

Computing

Georgia

Tech

Abstract

An

algorithm

is

presented

that

abstracts

out

the

largest

common

substructure

of

two

given

objectoriented

class

structures

This

abstraction

algorithm

is

based

on

two

concepts

-LRB-

-RRB-

a

mathematical

formulation

of

extension

for

class

structures

containing

part-of

and

inheritance

relationships

and

-LRB-

-RRB-

a

definition

of

similarity

on

the

class

level

The

algorithm

shows

how

class

structures

can

be

optimized

with

respect

to

the

extension

relation

and

how

it

can

be

used

to

abstract

out

a

candidate

parameterized

class

structure

The

algorithm

has

been

implemented

as

a

schema

transformation

and

design

tool

in

the

Demeter

System

Introduction

In

their

paper

on

Designing

reusable

classes

-LSB-

-RSB-

Johnson

and

Foote

ask

for

a

tool

to

help

the

programmer

reorganize

class

hierarchies

When

reorganizing

class

hierarchies

it

is

important

to

reuse

as

many

of

the

old

design

components

as

possible

As

Palsberg

and

Schwartzbach

show

-LSB-

-RSB-

there

are

two

major

approaches

to

reuse

of

software

components

polymorphism

and

prefixing

They

describe

polymorphism

as

reuse

in

applications

and

prefixing

as

reuse

in

definitions

In

prefixing

a

component

may

be

described

as

an

extension

of

another

component

A

typical

example

of

a

prefixing

mechanism

in

object-oriented

systems

is

inheritance

Inheritance

is

not

powerful

enough

to

express

many

interesting

relationships

between

groups

of

classes

and

therefore

a

more

general

prefixing

mechanism

is

needed

The

paper

by

Lieberherr

et

al.

-LSB-

-RSB-

introduces

such

a

mechanism

as

a

set

of

three

increasingly

strong

extension

relations

on

class

dictionary

graphs

A

class

dictionary

graph

is

used

in

the

Demeter

data

model

-LSB-

-RSB-

to

model

object-oriented

schema

designs

Based

on

the

extension

relations

we

introduce

an

algorithm

that

abstracts

out

from

two

given

schema

designs

the

largest

common

subdesign

such

that

both

the

original

designs

are

extensions

of

the

abstracted

one

This

concept

is

illustrated

in

Figure

Schema

Schema

EXTENSION

Figure

The

concept

of

the

abstraction

mechanism

An

algorithm

that

factors

out

the

common

structure

of

two

given

schema

definitions

has

many

uses

One

useful

application

of

this

algorithm

is

that

ideally

one

has

to

write

software

which

is

common

to

both

schema

and

only

once

for

the

classes

in

the

abstracted

schema

Then

by

extension

the

software

for

schema

and

is

reused

Indeed

it

has

been

shown

that

the

extension

relations

have

the

important

property

that

code

which

has

been

written

for

a

given

schema

needs

only

minor

changes

when

the

schema

is

extended

-LSB-

-RSB-

These

changes

can

be

even

further

reduced

if

the

software

is

written

in

an

adaptive

style

using

so-called

propagation

patterns

-LSB-

-RSB-

a

novel

programming

technique

that

avoids

as

much

as

possible

hardwiring

structural

information

into

the

programs

Another

useful

application

of

the

abstraction

algorithm

is

to

provide

a

way

to

succinctly

describe

schemas

Both

extended

schemas

can

be

specified

in

terms

of

the

abstracted

schema

by

simply

giving

for

each

one

the

extension

operations

necessary

to

produce

the

extended

schema

Many

other

areas

benefit

from

the

proposed

abstraction

mechanism

Software

reuse

and

refactoring

Given

a

schema

for

a

finished

application

and

a

schema

for

a

second

planned

application

the

designer

can

try

to

reuse

as

much

of

the

old

schema

as

possible

by

adding

on

to

the

abstracted

schema

Design

of

very

large

applications

Often

several

existing

schemas

have

to

be

integrated

into

a

single

large

schema

This

can

be

achieved

by

creating

a

centralized

system

from

several

existing

systems

by

moving

from

a

distributed

system

to

a

centralized

system

or

by

merging

several

views

into

one

global

schema

Software

reengineering

The

reengineering

of

several

applications

can

be

facilitated

considerably

by

extracting

and

analyzing

the

class

structures

common

to

the

given

applications

In

addition

to

the

information

on

how

to

extract

the

common

class

structure

the

algorithm

can

give

suggestions

on

how

to

parameterize

it

Redundancy

recognition

A

primary

goal

of

good

schema

organization

is

to

recognize

redundancy

and

to

reduce

as

much

of

it

as

desired

The

abstraction

algorithm

automatically

discovers

redundancy

in

groups

of

classes

by

finding

a

maximal

subgroup

common

to

them

This

paper

is

organized

as

follows

In

the

second

section

the

data

model

and

the

concepts

to

describe

the

algorithm

are

formally

introduced

The

third

section

defines

the

extension

relations

The

fourth

section

presents

the

algorithm

as

well

as

several

of

its

key

properties

and

in

the

fifth

section

related

and

future

work

are

discussed

The

Demeter

Data

Model

The

study

at

hand

uses

the

Demeter

data

model

because

of

its

concise

mathematical

notation

and

its

ability

to

model

classes

with

both

their

inheritance

and

part-of

relationship

in

a

uniform

theory

These

two

features

make

it

an

ideal

foundation

for

theoretical

studies

-LSB-

-RSB-

define

the

Demeter

data

model

thoroughly

We

reproduce

enough

of

the

definitions

to

make

this

paper

selfcontained

Readers

already

familiar

with

the

Demeter

data

model

can

skip

this

section

The

Demeter

data

model

captures

the

relevant

information

of

the

class

structure

in

a

graph

called

a

class

dictionary

graph

The

model

distinguishes

two

kinds

of

classes

alternation

classes

and

construction

classes

Any

superclass

is

called

an

alternation

class

and

its

corresponding

alternation

vertex

in

the

graph

is

represented

by

a

hexagon

All

alternation

classes

are

considered

to

be

abstract

classes

that

is

no

objects

of

an

alternation

class

can

be

instantiated

Any

leaf

class

in

the

class

hierarchy

is

called

a

construction

class

and

its

corresponding

construction

vertex

in

the

graph

is

represented

by

a

rectangle

Two

kinds

of

relationships

between

classes

are

distinguished

The

inheritance

-LRB-

or

is-a

-RRB-

relationship

is

represented

by

an

alternation

edge

in

the

graph

and

is

drawn

as

a

double-shafted

arrow

-LRB-

=-RRB-

-RRB-

from

the

superclass

to

the

subclass

Multiple

inheritance

is

possible

The

whole-part

-LRB-

or

part-of

-RRB-

relationship

is

represented

by

a

labeled

construction

edge

in

the

graph

and

is

drawn

as

a

single-shafted

arrow

-LRB-

-RRB-

from

the

whole

to

the

part

The

label

of

the

construction

edge

denotes

the

name

of

the

part

and

the

class

the

edge

points

to

denotes

the

type

of

the

part

Information

about

which

methods

are

attached

to

a

class

is

deliberately

omitted

from

the

class

dictionary

graph

However

the

structural

information

of

class

dictionary

graphs

is

used

by

the

complementary

notion

of

propagation

patterns

to

inject

methods

into

the

classes

-LSB-

-RSB-

Class

dictionary

graphs

are

therefore

pivotal

for

the

behavioral

aspect

of

an

application

To

illustrate

the

notion

of

construction

and

alternation

classes

and

to

explain

how

a

class

structure

is

mapped

into

a

class

dictionary

graph

we

use

a

simple

example

from

a

business

domain

The

class

dictionary

graph

for

this

domain

is

shown

in

Figure

The

depicted

class

dictionary

graph

models

a

division

that

belongs

to

a

company

The

division

is

managed

by

a

manager

and

employs

a

number

of

employees

each

of

whom

has

a

name

and

can

be

either

a

worker

or

a

manager

As

an

example

of

a

construction

class

consider

the

class

Division

Its

three

direct

parts

are

the

company

the

manager

and

the

list

of

employees

modeled

by

the

classes

Company

Manager

and

EmpList

respectively

As

an

example

of

an

alternation

class

consider

an

employee

who

can

be

either

a

worker

or

a

manager

Thus

the

entity

employee

is

modeled

as

an

alternation

class

Employee

with

the

two

alternatives

Worker

and

Manager

Alternatives

can

themselves

be

alternation

or

construction

classes

In

this

case

they

happen

to

be

two

construction

classes

Often

some

of

the

alternatives

have

the

same

parts

For

example

both

types

of

employees

Worker

and

Manager

have

a

part

name

of

class

Ident

The

equal

parts

can

become

the

parts

of

a

common

superclass

-LRB-

in

our

case

Employee

-RRB-

so

that

the

subclasses

inherit

them

Common

parts

of

the

alternatives

are

pointed

to

by

labeled

single

arrows

originating

from

the

alternation

vertex

The

process

of

moving

equal

parts

up

to

a

superclass

is

called

abstraction

of

common

parts

the

inverse

process

is

called

distribution

of

common

parts

-LSB-

-RSB-

A

class

dictionary

graph

with

no

common

parts

is

called

flat

Note

that

a

part

does

not

have

to

be

a

physical

part

any

attribute

of

an

object

is

modeled

as

a

part

of

it

such

as

the

belongsTo

part

of

class

Division

The

part-of

CompanyEmployeeWorkerManagerEmptyNonemptymanagedByfirstrestcontainsDiv

isionIdentnamebelongsToEmpList

Figure

A

class

dictionary

graph

modeling

a

division

with

employees

relationship

in

the

Demeter

model

is

therefore

a

generalization

of

the

aggregation

relationship

which

only

describes

physical

containment

A

part

can

be

either

directly

attached

to

a

class

by

a

construction

edge

or

it

can

be

inherited

from

a

superclass

Note

also

that

in

the

Demeter

model

as

in

-LSB-

-RSB-

alternation

edges

are

drawn

in

the

direction

opposite

to

which

they

are

drawn

in

other

models

-LRB-

e.g.

-LSB-

-RSB-

-RRB-

indicating

the

direction

in

which

properties

are

inherited

Moreover

unlike

many

other

data

models

the

Demeter

data

model

distinguishes

between

and

thus

separates

instantiable

and

abstract

classes

This

separation

does

not

reduce

any

expressibility

and

produces

a

cleaner

design

The

full

Demeter

data

model

exhibits

a

number

of

other

useful

features

such

as

repetition

classes

parameterized

classes

and

optional

parts

-LSB-

-RSB-

While

all

of

these

features

are

convenient

they

are

not

essential

in

the

model

since

they

can

be

expressed

by

alternation

and

construction

classes

As

an

example

the

list

of

employees

is

implemented

by

an

alternation

class

and

two

special

construction

classes

Empty

and

Nonempty

which

together

build

a

linked

list

similar

to

a

list

of

cons

cells

in

Lisp

This

construction

could

equally

well

be

represented

as

a

repetition

class

For

the

kind

of

study

done

in

this

paper

it

suffices

to

give

the

following

formal

definition

of

a

class

dictionary

graph

Definition

A

class

dictionary

graph

is

a

directed

graph

-LRB-

V

C

V

A

EC

EA

-RRB-

with

finitely

many

vertices

V

V

C

-LSB-

V

A.

V

C

is

the

set

of

construction

vertices

V

A

is

the

set

of

alternation

vertices

is

a

finite

set

of

labels

EC

is

a

ternary

relation

on

V

V

An

element

-LRB-

v

w

l

-RRB-

EC

is

called

a

-LRB-

labeled

-RRB-

construction

edge

from

vertex

v

to

vertex

w

with

label

l.

EA

is

a

binary

relation

on

V

A

V

An

element

-LRB-

v

w

-RRB-

EA

is

called

an

alternation

edge

from

vertex

v

to

vertex

w.

For

any

v

V

A

there

must

be

an

edge

-LRB-

v

w

-RRB-

EA

for

some

w

V

The

intuitive

notion

of

alternation-reachability

in

a

class

dictionary

graph

is

extensively

used

in

later

sections

A

formal

recursive

definition

follows

Definition

In

a

class

dictionary

graph

-LRB-

V

C

V

A

EC

EA

-RRB-

a

vertex

w

V

is

alternation-reachable

from

vertex

v

V

-LRB-

written

v

-RRB-

w

-RRB-

-LRB-

-RRB-

via

a

path

of

length

if

v

w

and

-LRB-

-RRB-

via

a

path

of

length

n

if

V

such

that

-LRB-

v

u

-RRB-

EA

and

u

-RRB-

w

via

a

path

of

length

n

The

Demeter

data

model

imposes

two

axioms

for

building

meaningful

and

consistent

class

dictionary

graphs

The

cycle-free

alternation

axiom

requires

that

no

class

inherit

from

itself

The

unique

labels

axiom

guarantees

that

the

construction

edges

of

a

class

-LRB-

inherited

or

not

-RRB-

are

uniquely

labeled

A

class

dictionary

graph

is

considered

legal

if

it

satisfies

both

these

axioms

Throughout

the

rest

of

this

paper

the

term

class

dictionary

graph

will

refer

to

a

legal

class

dictionary

graph

Class

Dictionary

Graph

Extension

The

extension

of

class

dictionary

graphs

can

be

viewed

primarily

from

two

perspectives

A

fine

grained

perspective

considers

the

extension

of

a

class

dictionary

graph

at

the

primitive

elements

of

the

data

model

such

as

adding

a

new

class

renaming

a

class

adding

a

part

to

a

class

changing

the

domain

of

a

part

and

so

forth

Another

perspective

is

more

coarse

grained

since

it

analyzes

the

modeling

power

of

the

class

dictionary

graph

as

a

whole

This

modeling

power

is

determined

by

the

set

of

objects

that

can

be

modeled

by

the

class

dictionary

graph

In

this

section

three

coarse

grained

extensions

are

defined

and

analyzed

The

three

relations

can

be

decomposed

into

fine

grained

primitive

relations

thus

yielding

insight

from

both

perspectives

-LSB-

-RSB-

All

extensions

are

expressed

as

relations

on

class

dictionary

graphs

Each

relation

is

naturally

associated

with

a

transformation

of

a

class

dictionary

graph

The

three

key

extension

relations

are

object-equivalent

weakly-extend

and

extend

Informally

objectequivalence

preserves

the

set

of

objects

modeled

by

the

class

dictionary

graphs

-LSB-

-RSB-

that

is

although

the

structure

of

two

equivalent

class

dictionary

graphs

are

different

they

both

model

the

same

set

of

objects

Weak

extension

enlarges

the

set

of

objects

while

maintaining

the

ability

to

model

the

old

objects

that

is

the

set

of

objects

of

the

weakly

extended

class

dictionary

graph

is

a

superset

of

the

unextended

class

dictionary

graph

Extension

similarly

enlarges

the

set

of

objects

but

in

addition

augments

some

objects

with

new

parts

The

three

extension

relations

represent

a

sequence

of

increasingly

stronger

transformations

The

extension

relations

together

with

their

converse

relations

form

the

basis

for

general

class

dictionary

graph

transformations

The

extension

relations

Before

we

can

present

the

extension

relations

formally

we

need

a

succinct

way

to

specify

all

the

classes

whose

instances

can

be

assigned

to

a

part

of

a

given

class

This

is

described

by

the

notion

of

PartClusters

defined

below

Informally

the

PartClusters

of

a

class

v

are

a

list

of

pairs

one

pair

for

each

part

of

v.

Each

pair

consists

of

a

part

name

and

the

set

of

construction

classes

whose

instances

can

be

assigned

to

the

part

Note

that

since

all

alternation

classes

are

abstract

only

instances

of

construction

classes

can

be

actually

assigned

to

a

part

that

is

even

if

a

construction

edge

points

to

an

alternation

class

w

the

only

objects

that

can

be

assigned

to

the

part

are

instances

of

construction

classes

that

are

alternation-reachable

from

w.

To

illustrate

this

consider

again

Figure

Clearly

the

managedBy

part

of

class

Division

can

only

contain

objects

of

class

Manager

However

the

actual

objects

assigned

to

the

first

part

of

class

Nonempty

may

only

be

objects

of

either

class

Worker

or

class

Manager

but

not

of

the

abstract

class

Employee

A

coverage

relation

is

defined

for

the

PartClusters

of

two

class

dictionary

graphs

The

PartClusters

of

a

class

v

in

one

class

dictionary

graph

are

covered

by

the

PartClusters

of

the

corresponding

class

v

in

a

second

class

dictionary

graph

if

v

has

at

least

as

many

parts

in

the

second

class

dictionary

graph

as

it

has

in

the

first

one

and

if

every

instance

that

can

be

assigned

to

a

part

in

the

first

class

dictionary

graph

can

also

be

assigned

to

the

second

one

In

addition

we

define

the

PartLabels

of

a

class

v

to

be

the

set

of

all

labels

that

denote

a

part

of

v.

Definition

Let

-LRB-

V

C

V

A

EC

EA

-RRB-

be

a

class

dictionary

graph

and

V

V

C

-LSB-

V

A

Then

we

define

for

all

vertices

v

V

The

associated

set

of

v

is

A

-LRB-

v

-RRB-

j

V

C

and

v

-RRB-

PartClusters

-LRB-

v

-RRB-

f

-LRB-

l

A

-LRB-

w

-RRB-

-RRB-

j

l

w

V

-LRB-

w

l

-RRB-

EC

and

-RRB-

vg

PartClusters

-LRB-

v

-RRB-

-LSB-

l

-RSB-

is

the

pair

-LRB-

l

-RRB-

in

PartClusters

-LRB-

v

-RRB-

whose

first

element

is

l

is

called

the

domain

of

the

part

of

v

with

label

l.

Note

that

for

a

given

v

the

label

l

is

unique

because

of

the

unique

label

axiom

PartLabels

-LRB-

v

-RRB-

fl

j

-LRB-

l

-RRB-

PartClusters

-LRB-

v

-RRB-

g

Let

and

be

two

class

dictionary

graphs

with

V

V

and

let

v

V

We

say

that

PartClusters

-LRB-

v

-RRB-

are

covered

by

PartClusters

-LRB-

v

-RRB-

if

for

all

-LRB-

l

-RRB-

PartClusters

-LRB-

v

-RRB-

there

exists

-LRB-

l

-RRB-

PartClusters

-LRB-

v

-RRB-

s.t.

PartClusters

-LRB-

v

-RRB-

are

tightly

covered

by

PartClusters

-LRB-

v

-RRB-

if

PartClusters

-LRB-

v

-RRB-

are

covered

by

PartClusters

-LRB-

v

-RRB-

and

in

addition

PartLabels

-LRB-

v

-RRB-

PartLabels

-LRB-

v

-RRB-

Example

Consider

the

extend

transformation

in

Figure

The

PartClusters

for

the

vertex

Division

are

PartClusters

-LRB-

Division

-RRB-

f

-LRB-

belongsTo

fCompanyg

-RRB-

-LRB-

contains

fEmpty

Nonemptyg

-RRB-

-LRB-

managedBy

fManagerg

-RRB-

g

In

the

same

transformation

the

PartClusters

-LRB-

Nonempty

-RRB-

are

tightly

covered

by

the

PartClusters

-LRB-

Nonempty

-RRB-

since

the

domain

of

the

first

part

in

contains

in

addition

to

the

classes

Manager

and

Worker

also

the

class

Secretary

while

the

domain

of

the

rest

part

is

the

same

in

both

class

dictionary

graphs

The

above

definitions

allow

us

to

define

the

three

extension

relations

of

class

dictionary

graphs

formally

Definition

Let

and

be

two

class

dictionary

graphs

where

-LRB-

V

V

-RRB-

and

-LRB-

V

V

-RRB-

Class

dictionary

graph

and

are

objectequivalent

written

if

V

V

and

for

all

v

V

PartClusters

-LRB-

v

-RRB-

PartClusters

-LRB-

v

-RRB-

Class

dictionary

graph

is

weakly

extended

by

class

dictionary

graph

written

if

V

V

and

for

all

v

V

PartClusters

-LRB-

v

-RRB-

are

tightly

covered

by

PartClusters

-LRB-

v

-RRB-

Class

dictionary

graph

is

extended

by

class

dictionary

graph

written

if

V

V

and

for

all

v

V

PartClusters

-LRB-

v

-RRB-

are

covered

by

PartClusters

-LRB-

v

-RRB-

The

object-equivalent

relation

is

an

equivalence

relation

on

the

set

of

all

class

dictionary

graphs

The

weaklyextend

and

the

extend

relations

are

partial

-LRB-

but

not

total

-RRB-

orders

on

the

equivalence

classes

defined

by

the

object-equivalent

relation

erManagerEmptyNonemptymanagedByfirstrestcontainsDivisionnamebelongsToI

ymanagedByfirstrestcontainsDivisionIdentnamebelongsToEmpList

Figure

Example

of

the

extension

relation

Example

Each

of

the

three

extension

relations

is

illustrated

in

Figure

The

object-equivalent

transformation

is

realized

by

abstracting

the

common

part

name

from

the

two

construction

classes

up

to

their

common

superclass

Emp

and

at

the

same

time

changing

its

name

to

Employee

Note

that

class

names

of

abstract

classes

are

irrelevant

for

object

descriptions

The

weakly-extend

transformation

is

effected

by

adding

another

alternative

to

the

class

Employee

Lastly

the

extend

transformation

is

performed

by

adding

a

new

alternative

Secretary

and

a

new

part

ssn

to

the

Employee

alternation

class

The

new

part

is

inherited

by

all

alternatives

of

Employee

The

modeling

power

of

the

extended

class

dictionary

graphs

can

be

characterized

as

follows

If

two

class

dictionary

graphs

and

are

object-equivalent

then

both

describe

the

same

set

of

objects

If

they

are

in

a

weakly-extend

relation

describes

a

superset

of

the

objects

of

In

other

words

every

class

defined

in

that

is

also

defined

in

has

the

same

number

of

parts

but

a

possibly

wider

domain

in

the

PartClusters

If

and

are

in

an

extend

relation

then

in

addition

objects

of

may

have

a

greater

number

of

parts

The

Abstraction

Algorithm

CDGA

Now

that

the

extension

relation

is

defined

an

interesting

question

arises

Given

two

class

dictionary

graphs

what

is

the

biggest

class

dictionary

graph

such

that

the

former

two

are

extensions

of

it

This

problem

is

similar

to

the

one

of

finding

the

greatest

common

divisor

in

arithmetic

The

answer

to

the

proposed

question

is

of

great

importance

to

many

areas

in

object-oriented

software

engineering

as

described

in

the

introduction

The

abstraction

algorithm

presented

in

this

section

extracts

from

two

given

class

dictionary

graphs

a

third

one

which

is

the

biggest

abstraction

of

the

former

two

Informally

a

class

dictionary

graph

is

in

the

abstraction

set

of

two

given

class

dictionary

graphs

if

both

of

them

are

extensions

of

it

Furthermore

the

class

dictionary

graph

extracted

by

the

algorithm

has

the

property

that

it

is

an

extension

of

all

the

other

class

dictionary

graphs

in

the

abstraction

set

It

is

in

this

sense

that

the

abstracted

class

dictionary

graph

is

the

biggest

Definition

Let

and

be

two

class

dictionary

graphs

abstraction

-LRB-

-RRB-

f

j

and

ABSTRACTION

-LRB-

-RRB-

f

j

abstraction

-LRB-

-RRB-

g

The

algorithm

goes

even

one

step

further

by

giving

suggestions

on

how

the

resulting

class

dictionary

graph

could

be

parameterized

Such

an

abstracted

class

dictionary

graph

is

called

a

template

class

dictionary

graph

and

is

formally

defined

as

follows

Definition

A

template

class

dictionary

graph

OE

is

a

directed

graph

OE

-LRB-

V

EC

EA

-RRB-

with

finitely

many

labeled

vertices

V

V

-LRB-

V

C

-LSB-

V

A

-LSB-

V

P

-RRB-

V

C

and

V

A

are

the

construction

and

alternation

vertices

respectively

while

V

P

are

the

parameterization

vertices

There

are

two

defining

relations

EC

EA

EC

is

a

ternary

relation

on

-LRB-

V

C

-LSB-

V

A

-RRB-

V

called

the

-LRB-

labeled

-RRB-

construction

edges

EA

is

a

binary

relation

on

V

A

-LRB-

V

C

-LSB-

V

A

-RRB-

called

the

alternation

edges

Note

that

the

parameterization

vertices

can

not

be

the

source

of

any

edges

and

can

be

the

targets

of

construction

edges

only

A

template

class

dictionary

graph

is

legal

if

the

corresponding

class

dictionary

graph

formed

by

instantiating

all

the

parameterization

vertices

is

legal

Example

As

an

illustration

of

how

CDGA

works

consider

Figure

is

the

class

dictionary

graph

abstracted

from

and

by

the

algorithm

has

two

parameterized

vertices

one

for

the

belongsTo

part

and

one

for

the

first

part

of

class

Nonempty

After

the

removal

of

the

parameterized

vertices

in

both

and

are

extensions

of

In

order

to

find

the

structures

common

to

two

class

dictionary

graphs

the

algorithm

analyzes

them

at

both

the

vertex

and

edge

level

For

this

purpose

the

notion

of

generalization

is

introduced

and

a

function

abstract

defined

Both

concepts

will

be

used

in

the

algorithm

Informally

a

vertex

is

a

generalization

of

another

vertex

if

the

former

is

an

alternation

predecessor

-LRB-

a

superclass

-RRB-

of

the

latter

For

two

class

dictionary

graphs

this

can

be

formulated

as

in

the

definition

below

Definition

Let

and

be

two

class

dictionary

graphs

where

-LRB-

V

C

V

A

EC

EA

-RRB-

-LRB-

V

C

V

A

EC

EA

-RRB-

A

vertex

v

V

A

generalizes

a

vertex

w

V

C

if

V

C

with

v

-RRB-

w

in

For

two

given

class

dictionary

graphs

and

the

function

abstract

checks

two

vertices

from

each

class

dictionary

graph

for

similarity

and

returns

the

corresponding

abstracted

vertex

in

the

abstracted

class

dictionary

graph

Definition

Let

and

be

two

class

dictionary

graphs

where

-LRB-

V

C

V

A

EC

EA

-RRB-

-LRB-

V

C

V

A

EC

EA

-RRB-

For

a

vertex

v

V

and

a

vertex

w

V

the

function

abstract

V

V

V

-LSB-

V

-LSB-

-LRB-

V

V

-RRB-

is

defined

as

follows

if

v

V

C

w

V

C

and

if

v

w

then

abstract

-LRB-

v

w

-RRB-

v.

if

v

V

C

w

V

A

and

if

w

generalizes

v

then

abstract

-LRB-

v

w

-RRB-

v.

if

v

V

A

w

V

C

and

if

v

generalizes

w

then

abstract

-LRB-

v

w

-RRB-

w.

if

v

V

A

w

V

A

and

if

A

-LRB-

v

-RRB-

A

-LRB-

w

-RRB-

if

v

w

then

abstract

-LRB-

v

w

-RRB-

v.

else

abstract

-LRB-

v

w

-RRB-

vw

where

vw

is

an

alternation

vertex

whose

label

is

the

concatenation

of

the

labels

of

v

and

w

A

is

the

association

set

-LRB-

see

Definition

-RRB-

if

of

the

above

conditions

hold

then

abstract

-LRB-

v

w

-RRB-

Example

In

Figure

consider

the

classes

Employee

and

Manager

in

the

class

dictionary

graphs

and

respectively

Manager

is

alternation-reachable

from

Employee

in

and

therefore

Employee

generalizes

Manager

To

illustrate

the

function

abstract

take

as

an

example

a

call

to

abstract

with

the

arguments

EmpList

and

DepList

of

Figure

This

call

to

abstract

-LRB-

EmpList

DepList

-RRB-

would

return

according

to

case

a

class

with

label

EmpListDepList

-LRB-

EmpDepList

for

short

-RRB-

because

the

associated

sets

of

both

argument

classes

contain

the

construction

classes

Nonempty

and

Empty

The

Algorithm

Given

these

definitions

we

are

now

ready

to

present

the

abstraction

algorithm

Without

loss

of

generality

the

algorithm

assumes

that

the

two

class

dictionary

graphs

are

flat

that

is

all

parts

are

attached

to

construction

classes

There

exists

an

efficient

algorithm

for

converting

any

class

dictionary

graph

to

a

corresponding

flat

class

dictionary

graph

-LSB-

-RSB-

Note

that

a

class

dictionary

graph

and

its

corresponding

flat

counterpart

are

in

an

object-equivalent

relation

INSTANCE

Given

two

flat

class

dictionary

graphs

and

SEARCH

Find

a

template

class

dictionary

graph

-LRB-

V

C

V

A

V

P

EC

EA

-RRB-

such

that

the

following

two

conditions

are

satisfied

If

is

the

class

dictionary

graph

resulting

from

deleting

in

all

the

parameterization

vertices

and

the

edges

leading

to

them

then

ABSTRACT

ION

-LRB-

-RRB-

For

each

-LRB-

v

l

-RRB-

EC

where

V

P

there

exists

V

and

V

such

that

-LRB-

v

l

-RRB-

EC

-LRB-

v

l

-RRB-

EC

and

abstract

-LRB-

-RRB-

The

notation

represents

a

vertex

whose

label

is

the

concatenation

of

the

labels

of

and

INFORMAL

DESCRIPTION

First

the

construction

vertices

of

are

taken

to

be

all

the

construction

gerEmptyNonemptymanagedByfirstrestcontainsDivisionIdentnamebelongsToEm

pListManagerEmptyNonemptymanagedByfirstrestcontainsDivisionIdentnamebe

longsToCompOrgEmplDepEmpDep

List

Figure

Example

of

an

abstraction

of

CDGA

vertices

that

are

present

in

both

and

Second

the

construction

edges

and

their

labels

are

extracted

as

follows

For

each

abstracted

construction

vertex

in

check

each

pair

of

parts

in

and

for

similarity

by

using

the

function

abstract

defined

in

the

previous

section

If

abstract

does

not

return

the

empty

set

the

part

which

is

returned

will

be

abstracted

out

If

the

parts

being

compared

are

both

alternation

vertices

the

procedure

alternation-abstract

is

recursively

called

to

check

how

many

of

their

children

are

similar

For

each

pair

of

children

alternation-abstract

calls

the

function

abstract

and

if

some

pair

matches

the

alternation

vertex

with

the

matching

edges

is

added

Third

the

parameterization

vertices

are

formed

All

parts

with

the

same

label

but

unsimilar

target

vertices

are

abstracted

as

parameterized

parts

ALGORITHM

CDGA

Let

and

be

the

two

input

class

dictionary

graphs

where

-LRB-

V

C

V

A

EC

EA

-RRB-

and

-LRB-

V

C

V

A

EC

EA

-RRB-

The

abstracted

class

dictionary

graph

-LRB-

V

C

V

A

EC

EA

-RRB-

is

constructed

as

follows

Form

V

C

for

all

v

V

C

if

v

V

C

add

v

to

V

C

Form

EC

and

for

all

-LRB-

v

l

-RRB-

EC

where

v

V

C

if

-LRB-

v

l

-RRB-

EC

and

abstract

-LRB-

-RRB-

x

add

l

to

add

-LRB-

v

x

l

-RRB-

to

EC

if

V

A

and

V

A

and

x

V

A

call

alternation-abstract

-LRB-

-RRB-

Form

EA

and

V

A

procedure

alternation-abstract

-LRB-

-RRB-

for

V

A

and

V

A

let

w

abstract

-LRB-

-RRB-

for

all

-LRB-

-RRB-

EA

for

all

-LRB-

-RRB-

EA

if

abstract

-LRB-

-RRB-

y

if

w

V

A

add

w

to

V

A

add

-LRB-

w

y

-RRB-

to

EA

if

V

A

and

V

A

and

y

V

A

call

alternation-abstract

-LRB-

-RRB-

Parametrization

form

V

P

add

to

EC

and

for

all

-LRB-

v

l

-RRB-

EC

where

v

V

C

if

-LRB-

v

l

-RRB-

EC

and

abstract

-LRB-

-RRB-

add

l

to

if

V

P

add

to

V

P

add

-LRB-

v

l

-RRB-

to

EC

Note

that

the

procedure

alternation-abstract

is

recursive

The

termination

of

the

recursion

is

guaranteed

by

the

cycle-free

alternation

axiom

The

abstracted

template

class

dictionary

graph

constitutes

an

important

first

step

towards

the

parameteriza

tion

of

object-oriented

software

A

template

class

dictionary

graph

is

based

solely

on

the

class

structure

A

complete

design

of

a

parameterized

class

structure

must

of

course

also

consider

information

on

methods

In

this

sense

an

abstracted

template

class

dictionary

graph

can

only

be

viewed

as

a

working

basis

from

which

a

final

parameterization

structure

can

be

constructed

Nevertheless

as

a

first

approximation

this

basis

gives

very

valuable

information

A

sample

scenario

that

follows

shows

how

the

abstracted

class

dictionary

graph

could

be

reused

Assuming

that

each

class

knows

how

to

print

itself

we

can

implement

a

program

that

describes

an

object

of

class

Division

in

the

abstracted

class

dictionary

graph

-LRB-

cf.

Fig

-RRB-

First

an

object

of

class

Division

sends

a

print

message

to

its

belongsTo

part

Second

it

sends

a

print

message

to

its

managedBy

part

which

then

prints

its

name

Finally

the

code

iterates

through

the

list

attached

to

the

contains

part

sending

the

message

print

to

each

of

the

first

parts

This

program

would

need

only

minor

revisions

for

the

extended

class

dictionary

graphs

Properties

The

Demeter

data

model

allows

for

formal

proofs

of

a

number

of

properties

of

the

abstraction

algorithm

In

the

following

discussion

these

proofs

are

omitted

due

to

space

limitations

but

are

available

in

-LSB-

-RSB-

The

key

property

of

the

algorithm

is

of

course

its

correctness

As

another

property

the

behaviour

of

the

abstraction

algorithm

can

be

shown

in

two

special

cases

As

a

first

case

we

consider

the

result

of

CDGA

when

the

two

input

class

dictionary

graphs

are

object-equivalent

As

expected

the

abstracted

class

dictionary

graph

is

object-equivalent

to

both

of

them

In

the

second

case

the

second

input

class

dictionary

graph

is

an

extension

of

the

first

one

Then

the

abstracted

class

dictionary

graph

is

object-equivalent

to

the

first

input

class

dictionary

graph

Formally

these

two

properties

can

be

stated

as

follows

If

and

if

CDGA

-LRB-

-RRB-

then

If

and

if

CDGA

-LRB-

-RRB-

then

The

computational

complexity

of

the

algorithm

can

be

shown

to

be

O

-LRB-

-LRB-

nc

nc

-RRB-

-LRB-

-RRB-

-RRB-

where

nc

nc

are

the

total

number

of

construction

edges

in

and

respectively

and

are

the

total

number

of

alternation

edges

in

and

respectively

The

abstraction

algorithm

also

has

the

important

property

that

it

is

able

to

recompute

the

formal

parameter

classes

of

an

instantiated

parameterized

schema

In

other

words

consider

two

schemas

that

have

been

instantiated

from

a

parameterized

schema

by

providing

an

actual

class

for

each

formal

parameter

class

-LSB-

-RSB-

Given

the

resulting

two

instantiated

schemas

as

inputs

the

abstraction

algorithm

produces

the

correct

formal

parameter

classes

Related

and

Future

Work

A

broad

overview

of

database

design

tools

is

given

in

-LSB-

-RSB-

There

Reiner

explores

the

phenomenon

of

automated

tools

and

support

environments

for

database

design

He

also

classifies

tools

by

the

following

taxonomy

Editors

Analyzers

and

Transformers

Transformers

are

defined

to

be

tools

that

produce

new

or

modified

schemas

from

old

ones

Clearly

the

abstraction

tool

presented

in

this

paper

fits

into

this

category

Relations

between

two

groups

of

classes

other

than

our

extension

relations

have

been

proposed

Palsberg

and

Schwartzbach

-LSB-

-RSB-

define

the

relation

which

is

composed

of

the

two

mechanisms

type

substitution

and

inheritance

The

relation

is

more

powerful

than

the

extension

relations

since

it

incorporates

methods

directly

into

the

class

definitions

The

abstraction

algorithm

deals

only

indirectly

with

methods

through

the

propagation

pattern

mechanism

It

would

be

interesting

to

generalize

the

algorithm

such

that

it

copes

with

more

powerful

extension

relations

Bouzeghoub

and

Comyn-Wattiau

's

view

integration

method

-LSB-

-RSB-

is

based

on

similarity

matrices

between

two

schemas

instead

of

on

an

extension

relation

They

consider

view

integration

as

a

unification

process

in

the

sense

of

Knight

's

definition

-LSB-

-RSB-

Given

two

descriptions

x

and

y

can

we

find

an

object

z

that

fits

both

descriptions

However

view

integration

is

more

a

union

type

of

operation

whereas

our

abstraction

is

more

an

intersection

type

of

operation

Class

dictionary

graph

transformations

that

preserve

object-equivalence

or

constitute

an

extension

are

discussed

in

-LSB-

-RSB-

In

the

future

we

plan

to

generalize

the

abstraction

algorithm

so

that

it

is

able

to

abstract

classes

and

parts

that

have

been

renamed

This

will

require

a

more

powerful

algorithm

We

also

plan

to

work

on

an

abstraction

algorithm

that

abstracts

from

one

schema

instead

of

from

two

Such

an

algorithm

should

be

able

to

find

common

subparts

contained

in

two

or

more

locations

of

one

schema

Conclusions

Formal

and

rigorous

approaches

to

data

modeling

are

important

in

order

to

improve

the

reliability

and

robustness

of

systems

The

less

complex

a

data

model

the

easier

it

is

for

people

to

understand

and

use

properly

We

have

presented

an

abstraction

algorithm

based

on

a

formal

simple

object-oriented

data

model

which

helps

the

schema

designer

find

suitable

abstractions

We

have

also

shown

how

to

use

the

algorithm

to

abstract

out

a

candidate

parameterized

schema

design

Although

this

work

focuses

on

extending

class

structures

it

has

been

shown

in

-LSB-

-RSB-

that

methods

attached

to

the

classes

only

need

minor

adjustments

after

extensions

especially

if

they

are

written

in

an

adaptive

manner

using

propagation

patterns

Also

it

is

interesting

to

note

that

the

data

model

is

not

only

powerful

enough

to

express

the

abstraction

algorithm

but

is

also

an

ideal

means

to

prove

the

properties

of

it

The

research

presented

in

this

paper

is

part

of

the

Demeter

project

which

researches

and

develops

tools

for

object-oriented

system

development

The

abstraction

algorithm

has

been

implemented

using

and

is

now

part

of

the

Demeter

System/C

Our

experience

shows

that

the

abstraction

tool

is

useful

in

the

extraction

of

suitable

abstractions

from

class

definitions

The

Demeter

System

-LSB-

-RSB-

also

contains

other

design

time

tools

such

as

a

schema

validation

tool

that

complements

the

schema

abstraction

tool

Acknowledgement

We

are

grateful

to

Lydia

Cartar

and

Ken

Baclawski

for

their

feedback

and

to

the

other

members

of

the

Demeter

team

Paul

Bergstein

Ian

Holland

Linda

Keszenheimer

Ignacio

Silva-Lepe

and

Cun

Xiao

for

their

support

in

numerous

discussions

This

research

was

supported

in

part

by

MettlerToledo

AG

and

the

National

Science

Foundation

under

grants

-LRB-

Software

Engineering

-RRB-

and

CDA

-LRB-

Research

Instrumentation

-RRB-

The

authors

can

be

reached

at

the

following

E

mail

addresses

Walter

H?ursch

and

Karl

Lieberherr

at

fhuersch

j

lieberg@flora.ccs.northeastern.edu,

and

Sougata

Mukherjea

at

sougata@cc.gatech.edu

References

-LSB-

-RSB-

Carlo

Batini

Stefano

Ceri

and

Shamkant

B.

Navathe

Conceptual

Database

Design

an

Entity-Relationship

Approach

Benjamin/Cummings

Redwood

City

CA

ISBN

-LSB-

-RSB-

Paul

Bergstein

Object-preserving

class

transformations

In

Andreas

Paepcke

editor

Object-Oriented

Programming

Systems

Languages

and

Applications

Conference

pages

-LCB-

Phoenix

Arizona

October

ACM

ACM

Press

Special

Issue

of

SIGPLAN

Notices

Vol

No.

-LSB-

-RSB-

Mokrane

Bouzeghoub

and

Isabelle

Comyn-Wattiau

View

integration

by

semantic

unification

and

transformation

of

data

structures

In

Hannu

Kangassalo

editor

International

Conference

on

Entity-Relationship

approach

pages

-LCB-

Lausanne

Switzerland

-LSB-

-RSB-

Margaret

A.

Ellis

and

Bjarne

Stroustrup

The

Annotated

C++

Reference

Manual

Addison-Wesley

Reading

MA

ISBN

-LSB-

-RSB-

Keith

Gorlen

Sandy

Orlow

and

Perry

Plexico

Data

Abstraction

and

Object-Oriented

Programming

in

C++

John

Wiley

Sons

New

York

NY

ISBN

-LSB-

-RSB-

Walter

L.

H?ursch

Preserving

object

behavior

during

schema

evolution

Technical

Report

College

of

Computer

Science

Northeastern

University

Boston

MA

November

-LSB-

-RSB-

Walter

L.

H?ursch

Linda

Seiter

and

Cun

Xiao

In

any

CASE

Demeter

American

Programmer

-LRB-

-RRB-

-LCB-

October

-LSB-

-RSB-

Ralph

E.

Johnson

and

Brian

Foote

Designing

reusable

classes

Journal

of

Object-Oriented

Programming

pages

-LCB-

June/July

-LSB-

-RSB-

Kevin

Knight

Unification

A

multidisciplinary

survey

ACM

Computing

Surveys

-LRB-

-RRB-

-LCB-

March

-LSB-

-RSB-

Karl

J.

Lieberherr

Paul

Bergstein

and

Ignacio

SilvaLepe

From

objects

to

classes

Algorithms

for

objectoriented

design

Journal

of

Software

Engineering

-LRB-

-RRB-

-LCB-

July

-LSB-

-RSB-

Karl

J.

Lieberherr

Walter

H?ursch

Ignacio

Silva-Lepe

and

Cun

Xiao

Experience

with

a

graph-based

propagation

pattern

programming

tool

In

International

Workshop

on

CASE

Montr?eal

Canada

July

IEEE

Computer

Society

-LSB-

-RSB-

Karl

J.

Lieberherr

Walter

L.

H?ursch

and

Sougata

Mukherjea

Optimal

and

efficient

schema

abstraction

Technical

Report

College

of

Computer

Science

Northeastern

University

Boston

MA

December

-LSB-

-RSB-

Karl

J.

Lieberherr

Walter

L.

H?ursch

and

Cun

Xiao

Object-extending

class

transformations

Technical

Report

College

of

Computer

Science

Northeastern

University

Boston

MA

September

-LSB-

-RSB-

Karl

J.

Lieberherr

and

Arthur

J.

Riel

Demeter

A

CASE

study

of

software

growth

through

parameterized

classes

Journal

of

Object-Oriented

Programming

-LRB-

-RRB-

-LCB-

August

September

-LSB-

-RSB-

Karl

J.

Lieberherr

and

Cun

Xiao

Formal

foundations

for

object-oriented

data

modeling

IEEE

Transactions

on

Knowledge

and

Data

Engineering

accepted

for

publication

-LSB-

-RSB-

Karl

J.

Lieberherr

Cun

Xiao

and

Ignacio

Silva-Lepe

Graph-based

software

engineering

Concise

specifications

of

cooperative

behavior

Technical

Report

NU

College

of

Computer

Science

Northeastern

University

Boston

MA

September

-LSB-

-RSB-

Jens

Palsberg

and

Michael

Schwartzbach

Type

substitution

for

object-oriented

programming

In

N.

Meyrowitz

editor

Object-Oriented

Programming

Systems

Languages

and

Applications

Conference

pages

-LCB-

Ottawa

ACM

Press

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

schema evolution
software reuse
view integration


July 16 , 1996 1 Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards . Osmar R. Za?ane , Peter Triantafillou , Jiawei Han Simon Fraser University School of Computing Science -LCB- zaiane , triantaf , han -RCB- @cs . sfu.ca Abstract : Memory cards and smart cards have a large storage capacity turning them into hand-held databases . Assuming seldom connections between hosts , updating these mobile databases can lead to consistency problems . This paper discusses some of these problems and attempts to give some solutions with application in electronic commerce . 1 . Introduction New technologies and the growing use of these technologies bring new challenges to the database field . Memory cards and smart cards are used more and more in banking , communications and different applications to attract and keep regular customers . Their prolific growth and success in today?s society will result in massive use in various application fields . These look-alike bank or credit cards are established to be ideal for some massmemory applications , and represent one of the most interesting developments in recent times -LSB- 4 -RSB- -LSB- 12 -RSB- . Memory cards are credit-card-sized with means to store data like a magnetic stripe , a highly magnetized surface or an optical media . Laser cards and high density magnetic cards with a high coercive field layer -LRB- 5000 Oersteds -RRB- can store up to 4 megabytes . A smart card is also a credit-card-sized device but containing an integrated circuit chip which performs the functions of a microprocessor , memory and an input/output interface . Because smart cards have computing power and capacity for protected data storage they are considered as active cards unlike memory cards which at the current generation are not ? smart ? and are passive . Many systems and applications based on smart card technology carried out in different countries have shown the advantages of this technology and highly rated smart cards with respect to flexibility , security and reliability for storing data on a long term basis . Currently smart cards can hold up to 128 kbits of information but we expect an increase of this capacity to more than 1 megabits in the coming years . Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 2 A typical card system contains a card , a card reader/writer device , a terminal , a host computer and connections between these components . The card reader/writer device is inherently tied to the card technology used . Some other cards known as super-smart-cards have even a 16-character liquid crystal display and a 20-key keyboard incorporated as well as the microprocessor all in the credit-card standard size . This makes the cards powerful and secure means to transport an important amount of data . With a microprocessor placed inside credit-card-sized plastic carriers , smart cards offer the possibility that someday most individuals will carry in their pockets a secure medium for storing and carrying information and means for accessing resources and services . These cards will facilitate a wide range of information processing activities like portable medical records systems , banking and credit services , academic records for students or pre-paid services as in telephone services , parking , fast food or movie theaters . Memory cards and smart cards have a large storage capacity turning them into hand-held databases . These mobile databases are traveling from one host to another transporting information . Hosts are computers with a card reader/writer device and with or without a local database . The hosts can be connected through a network or indirectly through a host coordinator computer . 2 . Problem statement Sharing information is becoming an issue in a loosely connected mobile environment -LSB- 2 -RSB- -LSB- 6 -RSB- -LSB- 7 -RSB- -LSB- 8 -RSB- -LSB- 9 -RSB- -LSB- 11 -RSB- . The mobile computing paradigm was engendered by the advances in wireless technology like portable computers , cellular phones and smart cards . Mobile computing and mobile databases are expected to revolutionize the way computers and cards are used . In this paper , we present a problem that comes to light from the use of cards to hold and transport information in a mobile environment . As mentioned , cards can hold an important amount of information that can be accessed by different computers once a connection is made through a card reader . Host computers can be connected through different networks to a host coordinator or several host coordinators . The number of hosts is potentially very large , which may involve an extremely high cost in communications . Since communication may be considered costly in time and resources , it is better avoided or at least reduced to a minimum . Hosts may also not be connected and there is then no centralized repository of information . Cards can be used as virtual links between hosts , transporting data from one to another . Because of low capital investment in hardware and communication network , the operating costs of a card-based system are expected to be lower . New problems emerge though : problems in controlling access to data , encrypting information , problems with card failures , etc. . The problems that interest us here are those due to replicating data -LSB- 1 -RSB- -LSB- 3 -RSB- . 2.1 Consistency When a direct connection occurs between a host and a card , information may be copied from the card to the local database or vice versa . Both copies may be updated later inde - Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 3 pendently leading to consistency problems . A similar consistency problem appears when a card is replicated for different members of a group -LRB- e.g. , family cards -RRB- . The cards of the different members can be separately updated producing different versions of the same data . Obviously , we have three different kinds of consistencies : a card-host consistency between a card and a host , a card-group consistency between any two card members of the same group and a host-host consistency between any two hosts . Particular attention should be paid to the term consistency . It is obvious that a strong consistency where all hosts have the same state and all members store the same version of data at all times is not possible since there are no connections between cards and there may be no connections between hosts . Keeping all host data mutually consistent is not feasible if we consider only the virtual connection through the cards . Mutual consistency between hosts can be achieved through a coordinator or through the network . For group consistency and card-host consistency , the aim is to give at any given point in time the ability to a host to determine whether processing a transaction would leave the system in a consistent state . Assuming that the cards are given a number of service units to be consumed -LRB- e.g. , theater tickets , credit limits -RRB- , we define a consistent state as a state where no more than the allocated units have been used . For example , consider a group of two cards which share a 20-units limit . If the first member uses 14 units and the second consumes 8 , the system is in an inconsistent state . In this paper , we will focus on how to prevent such inconsistencies . 2.2 Connectivity The group consistency problem does not exist with a group containing a single card . This induces us to classify the problem into two classes : the single-card problem and the groupcards problem . These problems can be solved differently depending upon the connection environment . There are two possible environments : a fully disconnected configuration and a connected configuration . In the disconnected configuration , hosts do not communicate through any links , except for those established by the cards travelling from one host to another . To decide whether to accept a transaction , a host can only use the information stored in the card and in the local database . The connected configuration can be a distributed environment , where the data is stored on different sites and decisions are made by consensus , or a centralized environment where all hosts are connected to a host coordinator . Using the connections between the hosts can bring easy solutions to the card-host and the host-host consistency problems . However , the communication overhead would be large . The number of hosts can be extremely large . This makes the distributed configuration and the configuration with a central host coordinator very costly . Broadcasting data in a large network and reaching consensus may take a long time and causes delays for the transactions . Furthermore , there are other real costs , such as long-distance telephone charges using overseas rates , and bandwidth problems . Even with a host coordinator , communications may be expensive . Dedicated communication lines are beyond most application means . Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 4 FIGURE 1 . The Problem domain Despite the inefficient use of the resources , this solution is the current state of the art . The centralized solution is adopted for the bank credit-card system for example . Currently , each host -LRB- i.e. Automated Teller Machine -RRB- communicates with the coordinator before authorizing any transaction . The same occurs with the telephone card system in some countries where hosts have to communicate with a coordinator to allow a transaction . One aim of our research is to avoid any communication through the network or to seldom use the connections between hosts or between a host and a host coordinator but still get the same service quality . 3 . Solution to the single card problem The one-card problem is obviously straightforward . The mobile database is traveling from one host to another . The data can be copied , if allowed , from the mobile database during the connection and cached into the local database of the host . The local database is a replica or a partial replica of the mobile database and there can be as many replicas as hosts in the system . With a centralized coordinator , all updates are sent to the coordinator which will reflect the exact changes done to the mobile database . All hosts can then have access to the new version and update their local database when needed . If there are several host coordinators , the transactions are broadcast so that the appropriate central databases keep track of the update . In a disconnected environment , at any time t , at most one host Hi can be connected to the card M . If Hi updates M , since the modification is not broadcast through the network of hosts or sent to a coordinator , the other hosts have to wait until they connect to M to update their local database . The same problem of consistency occurs if the card is autonomous and has the ability to update itself without being connected with a host -LRB- e.g. super Disconnected Central host One card Group of duplicated cards Environment Connected Environment Distributed Environmentcoordinator Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 5 smart card or disconnected dumb terminal , disconnected ATM ... -RRB- . At any time , the most updated version of the database is the one in the card and this same copy is somewhere in one host -LRB- i.e. the last that updated the card -RRB- . Each time a host is connected to the card , it compares the version in the card with the one in its local database and updates its cache if necessary . In case of card failure , the hosts have to communicate to compare their logs in order to find the last version of the database . A possibly loosely connected environment , where connections exist but communications are not always used , can be considered . In this case , the version in the card is the one always taken into account like in the fully disconnected environment , but the new version can be sent to a coordinator or broadcast in the network in certain occasions . This scenario takes advantage of the mobility of the card to reduce the communication overhead . With one unique copy of the card , the consistency problem is not a real challenge . Indeed , the consistency problem between the card and a host is solved by always taking the copy in the card since the later has always the most up-to-date copy . The data inconsistency among hosts is solved by the virtual link created by the card itself traveling from one location to another . 4 . Solution to the group cards problem Let us suppose we have several copies of a card : M1 , M2 , ... , Mm called a group . Initially , all members of a group contain the same data . FIGURE 2 . Members of a group of cards with different hosts Example , a movie theater that provides family cards with a number of pre-paid tickets to its family customers . Each family member receives a card using which he or she can attend movies . The requirements are that : 1 . Consistency requirement : in total , the group does not consume more than the pre-paid number of units , and 2 . Quality of service requirement : any member card should receive service if there are unconsumed units . hosts network may or may not be used Group of members independent connection Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 6 With the card mobility and the absence of connections between members , the different copies may at a certain point contain different versions of the data . Each member Mi of a group can travel from one host to another and can be updated independently from the other members of the group . We have a new problem in updating the different replicas . Since cards do not communicate , the data is not consistent each time a card is updated . The group consistency problem between members of the same group is added to the aforementioned consistency problem . The assumption of the host that the version stored in a member is always the latest one does not hold with this scenario . In other words , when a member is connected to a host , the host can not be sure whether one of the versions -LRB- i.e. the one stored in the card and the one stored in the local database -RRB- is the latest one since another member of the group may have been updated by another host . If a member Mi of a group is updated by a host Hk then another member Mj is connected to the same host Hk , the last version may or may not be the one in the card Mj depending upon which one was last updated Mi or Mj . Indeed there are three cases : 1 - The last event may have been Mi visiting Hk . In that case Hk has the last version . 2 - Mj visited another host after Mi was connected to Hk . In this case Mj contains new information of which Hk is not aware yet but Hk will know it as soon as it is connected to Mj . 3 - Mi or another member except Mj visited another host Hn after Mi was connected to Hk and before the connection Hk-Mj . In this new case there is no direct way for Hk to know the latest version . The only versions Hk can have access to is the one stored in the local database and the one stored in the member Mj . However , the latest version might be the one stored in Hn and Mi . Again , let?s take a look at the three configurations ; centralized , distributed and disconnected . In a connected environment , centralized or distributed , the different versions held by the members are not trusted . Each time a connection between a member and a host is established , the host reads the ? real ? version from the coordinator or the network . We are thus sure that each card update is done with the most recent version . Thus , no member will over-use its units . With a disconnected configuration , the hosts deal with different members of a group with different versions of data . The challenge of keeping such a database consistent is obviously harder than the one with a unique copy of the card . It is evident that a host , when faced with a version of the data , can not decide whether the data is up-to-date without having any information about the use of the other members . We want to give the ability to a host to consider a card state and decide whether or not to authorize a transaction , maintaining the system in a consistent state . If a group of m members share x units , we do not want the members to consume more than the x units or at most x + d where d is minimal . The worst case is when each member visits one host H such that no other member was connected to H . In other words , at worst each member has a different and distinct path of visits to hosts . In this case , the group would consume mx units . The worst case is avoided if members cross paths . When more than one Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 7 card visits the same host , the latter can take advantage of the information and becomes aware of all transactions done by the different members connected once to it and updates the current card in consequence . 4.1 Controlled inconsistency A viable solution is a solution between the strong consistency where no overdraft is allowed and a fully relaxed solution where the inconsistency can be maximum . We call a controlled inconsistency a state where there is overdraft but the unit use does not go beyond a controlled limit , known before hand . We establish three limits : a member limit , a group limit and a loan limit . The member limit is the maximum number of units that a particular member can use without the host being obliged to know the unit consumption by the other members of the group . It?s the amount allocated to a specific member . The group limit is the sum of the member limits of all members in a group . The loan limit is similar to a line of credit . A loan-limit is defined for each group.When a member reaches its member limit , it can borrow units from the loan-limit . As long as a member is within its member limit , the host does not have to worry about excessive use and thus , no communication is required . When a member exceeds its member limit , the host has to communicate with a coordinator to warn it about the member limit excess and check if the group limit is reached . If the loan-limit is not reached a loan can be requested . FIGURE 3 . Algorithm executed by a host when Units are needed by member M if M.Units _ consumed + Units_needed < = M.Member _ limit then M.Units _ consumed + = Units_needed Accept transaction for Units_needed else Call Request_Loan -LRB- Loan -RRB- if Authorization granted then M.Units _ consumed + = Units_needed Accept transaction for Units_needed endif endif if M.Member _ limit > = M.Units _ consumed then Loan = Units_needed - -LRB- M.Member _ limit - M.Units _ consumed -RRB- else Loan = Units_needed endif else Reject transaction Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 8 FIGURE 4 . Algorithm for Request_Loan -LRB- loan_amount -RRB- executed by the coordinator For example a couple gets two cards from a bank , one initialized with $ 1200 and the other with $ 800 . The two people are sharing $ 2000 which is the group limit . The amount loaded in each card is the member limit . A loan limit of $ 1000 is allocated to the group . As long as a member stays within its member limit , when a purchase is done , the operation stays local -LRB- i.e. , between the card and the host -RRB- and no communication takes place . Suppose the first member uses $ 1200 and needs more money , the host has to communicate with the host coordinator which will authorize or reject the transaction . If the loan limit has not been reached , the transaction would be authorized . The same solution can be used with service units for a movie theater , a telephone system or any pre-paid service . 4.2 Exploiting card mobility In order to guarantee consistency , restrictions should be placed but without decreasing the accessibility and the mobility of the cards . The mobility of the card creates a virtual network linking the hosts . Whenever a crossing of cards ? paths occurs , more information is collected by the host . This information should be used in order to ensure consistency . We introduce a data structure called units consumption vector -LRB- UCV -RRB- that keeps track of the units consumed by each member . UCV is a vector of m cells , m being the number of members in the group . It is similar to a vector for timestamps -LSB- 5 -RSB- -LSB- 10 -RSB- . UCV -LSB- i -RSB- contains the number of units consumed by the member i . The data structure is stored by all members and all hosts . It keeps track of the information known by its owner about the activity of all the other members of the group . UCV is propagated through the card-host connections . Each time a connection is established between a member M and a host H , both compare their vectors and respectively learn about the group activity known by the other members previously connected to the host H and the group activity known by the hosts which the member M visited . This information allows to update the number of units already used to a state closer to the real one before processing the current transaction . UCV improves the propagation of information without explicit communication . The more hosts are visited by a member or the more members visit a host , the more information is cumulated . Forcing crossing paths may increase the efficiency of the UCV . For example suppose we have a group of two members M1 and M2 , two hosts H1 and H2 and five service units stored in variable X which is stored in all members and all cards . Figure 3 shows a simulation in 4 steps where the arrows symbolize visits . In the first step M1 and M2 visit respectively H1 and H2 . Both hosts will not be aware of the unit purchased at the other host . In step 2 M1 visits H2 which will learn about the previous visit if Loan_limit > = loan_amount then Loan_limit - = loan_amount Return ? Authorization granted ? endif else Return ? Authorization not granted ? Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 9 done by M1 to H1 and updates its UCV in consequence . The member also learns about visits done by other members to the host and updates its UCV . Step 4 shows how M1 propagates to H1 the information about the visits of both members . H1 uses the information to update properly X. Note that at step 4 there are different versions of X . If M2 visits H1 it will be correctly updated but if M2 goes to H2 an inconsistency may occur . This shows the importance of crossing paths . FIGURE 5 . Examples of simulations with a UCV 5 . Future directions Despite the exploitation of the card mobility with the UCV , inconsistency may still occur . It is possible to maximize the amount of information obtained and ensure consistency by imposing restrictions on the mobility of cards , like forcing the crossing of paths of different members . Regarding controlled inconsistency , other issues emerge from other types of transactions accessing the same data . For example a bank may run ? audit ? transactions to determine how much should a group be charged if the group exceeded the group limit . If the group limit has not been exceeded , even though a member has used units from the loan limit , loan interest should not be charged . Similarly , such audit transactions may pay savings interest to debit type cards , also referred to as ? electronic money ? . Alternatively , a hybrid solution using the notion of controlled inconsistency and imposing restrictions on the mobility of the cards can be adopted . Another problem arises with the fact that members of a group do not always have to hold identical data but can individually have specific information . As an example consider an application using a store credit card . Each member of the family holds a card that has its X = 5 X = 5 X = 4 X = 4 H1 H1 H2 H2 X = 5 X = 5 X = 4X = 4 X = 2 X = 4 X = 4 X = 1 X = 4 X = 2 X = 1 X = 2 H2 H2 H1 H1 M2 M2 M2 M2 M1 M1 M1 M1 UCV = 0,0 UCV = 0,0 UCV = 0,0 UCV = 0,0 UCV = 1,0 UCV = 1,0 UCV = 0,1 UCV = 0,1 UCV = 2,1 UCV = 2,1 UCV = 1,0 UCV = 0,1 UCV = 2,1 UCV = 3,1 UCV = 3,1 UCV = 0,1 1 2 43 Consistency in Card-based Mobile Databases : Sharing Digital Money by Replicating Smart Cards.July 16 , 1996 10 own credit limit but all cards share for example the same total credit limit . The consistency algorithm may not be the same with this new restriction . Despite the advent of the internet and the growing popularity of palmtop-based units in wireless environments , the use of the smart-card as a shared mobile ? digital wallet ? in a loosely connected or disconnected environment has its own appeal and advantages for electronic commerce applications . References : -LSB- 1 -RSB- D. Barbara and H. Garcia-Molina . Replicated Data Management in Mobile Environments : Anything New Under the Sun ? IFIP Conference on Applications in Parallel and Distributed Computing , Caracas , Venezuela , April 1994 . -LSB- 2 -RSB- D. Barbara and T. Imielinski . Sleepers and Workaholics : Caching Strategies in Mobile Environments , VLDB Journal , v4 , 1995 , pp 567-602 -LSB- 3 -RSB- P.A. Bernstein , V.Hadzilacos , and N.Goodman . Concurrency Control and Recovery in Database Systems . Addison-Wesley , 1987 . -LSB- 4 -RSB- R. Bright . Smart Cards : Principles , Practice , Applications . Ellis Horwood Limited , 1988 . -LSB- 5 -RSB- C. Fidge , Timestamps in Message Passing Systems that Preserve the Partial Ordering . Proc 11th Australian Computer Science Conference , Brisbane , february 1988 . -LSB- 6 -RSB- G. H. Forman and J. Zahorjan . The Challenge of Mobile Computing . UW CSE Tech Report # 93-11-03 . Computer Science & Engineering , University of Washington , March 1994 . -LSB- 7 -RSB- T. Imielinski and B.R. Badrinath . Mobile Wireless Computing : Challenges in Data Management , Communication of ACM , v37 , n10 , october 1994 , pp 18-28 -LSB- 8 -RSB- T. Imielinski and B.R. Badrinath . Querying in highly mobile distributed environments , Proceedings of the 18th VLDB Conference , Vancouver , Canada , 1992 -LSB- 9 -RSB- J. Kistler and M. Satyanarayanan . Disconnected Operation in the Coda File System , ACM transactions on Computer Systems , february 1992 , pp 3-25 . -LSB- 10 -RSB- L. Lamport . Time , Clocks and the Ordering of Events in a Distributed System . Communications of the ACM , v21 , n7 , july 1978 . -LSB- 11 -RSB- B. Noble and M. Satyanarayanan . A Research Status Report on Adaptation for Mobile Data Access , SIGMOD Record , v24 , march 1995 , pp 10-15 . -LSB- 12 -RSB- O. R. Za?ane , Acc?s logique et compression des donn?es de petite taille dans un dossier m?dical g?r ? par carte ? microprocesseur . Master Theses presented in Qu?bec , Canada , april 1992 , 218p .

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

consistency control
data replication
disconnected operations
distributed systems
hand-held computers
mass-memory cards