Software Development Control Based on Module ... - CiteSeerX

Software

Development Control Based on M o d u l e I n t e r c o n n e c t i o n

W a l t e r F. Tichy D e p a r t m e n t of Computer S c i e n c e Carnegie-Mellon University Pittsburgh, PA 15,,213

Abstract

stage

of

need

C o n s t r t l c t i n g l a r g e s o f t w a r e s y s t e m s is not m e r e l y a m a t t e r atr programming, but also a m a t t e r of c o mmu n i c a t i o n and coordination. Problems arise b e c a u s e m a n y p e o p l e w o r k on a joint p r o j e c t and use e a c h o t h e r ' s p r o g r a m s . This p a p e r p r e s e n t s an integrated d e v e l o p m e n t and m a i n t e n a n c e s y s t e m t h a t p r o v i d e s a c o n t r o l l i n g e n v i r o n m e n t to insure t h e consistency o f a s o f t w a r e s y s t e m at t h e module interconnection l e v e l . It a s s i s t s the programmers w i t h t w o f a c i l i t i e s : I n t e r f a c e control and v e r s i o n control. Interface control estal)lishes consistent i n t e r f a c e s b e t w e e n s o f t w a r e modules and maintains t h i s c o n s i s t e n c y w h e n c h a n g e s are made. Version c o n t r o l c o o r d i n a t e s t h e g~.neration and i n t e g r a t i o n o f t h e v a r i o u s v e r s i o n s and c o n f i g u r a t i o n s . Both f a c i l i t i e s d e r i v e t h e i r i n f o r m a t i o n from an o v e r a l l system (lescription formulated in t h e module interconnection language INTERCOL. A d e m o n s t r a t i o n s y s t e m is s k e t c h e d t h a t runs under t h e UNIX t i m e - s h a r i n g s y s t e m .

the

t h e s y s t e m . As a n o t h e r e x a m p l e for tile

of

communication

phenomenon

of

and c o o r d i n a t i o n consider

c o n t i n u i n g c l l a n g e 2 : All large

a n d w i d e l y u s e d s y s t e m s a r e subj~.ct to an endless stream

of

corrections,

customizations,

improvements,

a n d d i v e r s i f i c a t i o n s , b e c a u s e it is

u s u a l l y c h e a p e r t o m o d i f y t h e m than to rebuild them from

scratch.

means

Ilowever,

contilluing

system

comnluf~ication

structure,

implementation continuing

design

details

control

deterioration

continuing

to

of

to

the

of

the

overall

decisions, the

avoid

modification

(or

slow

system

and

modifiers,

and

down)

into

the

unfixable

unstructuredness. Current

research

programming

in

programming

lan q u a g e s ,

verification

techniques

methodology,

specification

and

t a k e s a d i f f e r e n t v i e w : The

m a i n g o a l is t o reduce t h e c o m p l e x i t y and size of software

systems

However,

1. Introduction

no

approaches

to

matter

manageable how

dimensions.

successful

these

a r e , com;~uter ~,pplications are s u b j e c t

t o t h e P a r k i n s o n i a l ~ l o w t h a t t h e i r s c a l e will e x p a n d Constructing merely

a

large

software

system

is

not

to

a m a t t e r o f progr,~mming, but also a m a t t e r

o f communication and coordination. Communication and

coordination

complexity makes rather

it

and

necessary

than

t e a m 1.

problems size

with

of

arise

software

to

a single

work

b e c a u s e of the systems.

witll

meet

be

systems

a n d shall h a v e t o s o l v e t h e communication

This system,

involved retain

p a r t s , it b e c o m e s e x t r e m e l y

t o e n s u r e t h e c o n s i s t e n c y of t h e s e parts. the

asynchronous

nature

of

a clear

exhaust

human

problems

the

large,

inherent

complex to

their

COl)abilities

the

to

software and

system

prototype

of

an

products

by

addressing

the

c o o r d i n a t i o n problems outlined

I t s f a c i l i t i e s can be v i e w e d as g u a r a n t e e i n g

integrity

of a software

interconnection

p i c t u r e of t h e a c t u a l d e v e l o p m e n t

the

d e v e l o p m e n t and m a i n t e n a n c e

w h o s e g o a l it is t o c o n t r o l t i l e d e v e l o p m e n t

large

above.

presents

software

communication

a c t i v i t i e s and t i l e mass of information

quickly

paper

integrated of

addition,

building

many p e o p l e

programmer or a small

numerous, interrelated

development

with

coordination

t o h u m a n i n t e r a c t i o n . With m a n y p e o p l e working on

In

faced

Thus, w e shall

development.

This i n t r o d u c e s atl t h e d i f f i c u l t i e s inherent

difficult

limits o f technolo~ly.

always and

Size

the

appears

l e v e l 3. as

s y s t e m a t t h e module

At this l e v e l , a s o f t w a r e an

organized

collection

of

29 CH 1479-5/79/0000- 0029500.75 (~) ! 979 IEEE

modules

which

interfaces. this

interact

with

Our s y s t e m

e a c h o t h e r through

it.~

p r o v i d e s t w o f a c i l i t i e s at

A

I n t e r f a c e control and version control.

level:

module

consists

control establisne3 consistent interfaces modules

i n f o r m a t i o n . An e x p o r t e d or p r o v i d e d resource of a

changes

version

a r e m¢=(le.

selection

generation

(or

automatic

regeneration)

multi-configuration

in

a

and

status

m o d u l e is a r e s o u r c e t h a t is d e c l a r e d in tile program

Version control performs

and

data,

text,

Interface when

test

program

between

o,,(I maintains this c o n s i s t e n c y

text,

of

documentation

(sub-)system

text

o f t h e m o d u l e and m a y be used in t h e program

multi-version/

text

of other

module

system.

is

An internal resource of a

modules.

declared

=n t h e

program t e x t

of t h a t

m o d u l e , b u t m a y n o t b e u s e d b y a n o t h e r module. An Both interface

c o n t r o l and v e r s i o n control d e r i v e

imported

t h e i r i n f o r m a t i o n from an o v e r a l l s y s t e m description,

that

formulated

in

in t h e m o d u l e i n t e r c o n n e c t i o n language

or r e q u i r e d r e s o u r c e of a module is one

is n o t d e c l a r e d in t h e module, but may be used

it.

The

INTERCOL. S u c h a d e s c r i p t i o n s p e c i f i e s a s o f t w a r e

together

system

constitutes

at

indicates

module

how

versions they

the

the

in|erconnection

various

modules

level. and

interface

with

each

other.

An

is

not

set

of

provided resources

its

required resources

t h e i n t e r f a c e of t h a t module.

A s y s t e m c o n s i s t s o f a c o l l e c t i o n of components,

INTERCOL

v i z . m o d u l e s or o t h e r s y s t e m s , plus d o c u m e n t a t i o n text,

test

data,

difference INTERCOL 4

a module's

their

is s e p a r a t e from a c t u a l program code.

Although

of the

and how

are grouped into (sub-)systems

specification

It

set with

a subject

of

this

there

and

between

status

information. Thus, a

systems

and modules is t h a t

is n o p r o g r a m t e x t a s s o c i a t e d w i t h a s y s t e m .

p a p e r , w e n e e d t o i n t r o d u c e a f e w of its notions in

A system

a l s o has

an int~.rface of p r o v i d e d and

tile

required

resources.

I l o w e v e r , since t h e r e is no

program

text,

following section.

careful

analysis

In s e c t i o n 3, w e p r e s e n t a of

inter-compilation type-checking important

mechanisms

for

because

our

of

interface

me(hods

of

control.

interface

control

Finally,

a

implementation

running

under

3. Inter-Compilation

the

Type-checking

t i m e - s h a r i n g s y s t e m is d e s c r i b e d in s e c t i o n O.

programs. important

Terminology

the is a n y e n t i t y t h a t can be d e c l a r e d

named

variables, definitions,

verifies tile type-correctness

of

W e w o u l d like t o s t r e s s t h a t w e consider a c r o s s module b o u n d a r i e s to be more

than type-checking

in

a

constants,

progr.:lmming procedures,

language

(e.g.,

o f an a b s t r a c t

type of a resource resource

may

generics, t y p e -

primitive the

d a t a t y p e , e t c . ) . The used

in

a

a

programmers

these

d e t e r m i n e s t h e w a y s in which be

closely

implement

e t c . ) . A subresource is a r e s o u r c e t h a t

an operation

responsibility

small,

is p a r t o f a n o t h e r r e s o u r c e (e.g., a field of a record,

the

Type-Chocking

inside a module, for

t h e f o l l o w i n g r e a s o n s . We assume t h a t a module is

A resource and

and required

components.

type-checking 2.

provided

and

c o n t r o l in s e c t i o n s 4 and 5, r e s p e c t i v e l y . pilot

a system°s

a r e in t u r n p r o v i d e d and required by its

Then w e

version UNiX

resources

a c r o s s compilation emits is t h e most

facility

discuss

the

type -checking,

own

program.

o f a sin qle pro qrammer or of a

interacting module's

team.

provided

In

order

resources,

to the

will u s u a l l y d e c l a r e some other, more

internal resources.

One can assume t h a t

programmers

rar,.,ly m a k e t y p e - e r r o r . 5 in using

resources,

siM,:e U l e y a r e dealing with their

creations,

different

t l o w e v e r , programmers working on

modules

cannot

interact

as closely. In

Type.~checking v e r i f i e s t h a t t h e r e s o u r c e is used in only

those

inspecting

ways. the

Type-checking

is

done

by

program, rather than by executing

= W e do not wlsh to give a more specific definition of the latter two terms, in order to keep the diso.13sion independent of a particular programming language. Clearly, we have 'algoli¢' languages in mind, like PASCAL, ALPHARD, or ADA.

30

p a r t i c u l a r , t h e i m p l e m e n t o r s of a resource e x p o r t e d

We

from

following paragraphs.

a

module

programmers

are

not

using them.

identical

with

tl}e

s h a l l d i s c u s s e a c h column of the array in the

E x p e r i e n c e shows that

m i s u n d e r s t a n d i n g s a t module i n t e r f a c e s are the rule rather

than

the

type-checking The

value

exception.

can d e t e c t of

We

believe

that type-

many of t h e s e errors.

type-checking

across

module

monolithic incremental independent

b o u n d a r i e s has b e e n confirmed with the use of the

compilatioh.

M E S A _ s y s t e m 5, 6 There which

is a small number of language systems

monolithic

PASCAL

provide for inter-compilation type-checking,

m o s t n o t a b l y SIMUIA~37 7, PtlSS 8, and MESA 9. The following

paragraphs they

classify

scheme

is

based

strategy

in w h i c h compilation (i.e., code generation)

the

Tile

various

that

on

use.

the

techniques

classification

observation

that

FORTRAN ', S]MULA67 ! PL/I I ALGOL68C II libraries i

incremental

tl~e ~f

is p e r f o r m e d can b e d e c o u p l e d from the s t r a t e g y in which

interfaces

strategies

are

checked.

FORTRAN PL/I

independent

The compilation

i.e.,

CLUlibrary MESA

checking linkers

w e w i s h to distinguish are as follows:

1. M o n o l i t h i c compilation, s e p a r a t e compilation;

PLISS type-

. . . . . . .

I

no Figure 1 : Inter-compilation type-checking

2. I n c r e m e n t a l compilation, i.e., compilation units are processed a c c o r d i n g t o some partial ordering, s u c h as b o t t o m - u p ;

3.1, Monolithic Type-Checking A n y l a n g u a g e s y s t e m t h a t (toes not provide for

8. I n d e p e n d e n t compilation, i.e., c o m p i l a t i o n units may be p r o c e s s e d in any order.

separate

compilation

(monolithic

c o m p i l a t i o n , monolithic t y p e - c h e c k i n g ) .

fits

into

square

[1,1 ]

The

square

[3,1]

is t h e most densely populated

I n t e r - c o m p i l a t i o n t y p e - c h e c k i n g can be c a t e g o r i z e d

one,

since

most

languaqe

using the same attributes:

separate

programmers. help even

the

two

c a t e g o r i z a t i o n s results

type-checking

on

to

the

T h e s e s y s t e m s do not o f f e r any more bottom-up

order

(square

[2,1]),

in

w h i c h t h e n e c e s s a r y information for t y p e - c l l e c k i n g is a l w a y s are

available.

compiled

types

,.3. I n d e p e n d e n t t y p e - c h e c k i n g , i.e., the i n t e r f a c e s of compilation units may be c h e c k e d in any order. Combining

offer

if one r e s t r i c t s the d e v e l o p m e n t to an

incremental,

2. I n c r e m e n t a l t y p e - c h e c k i n g , i.e., the i n t e r f a c e s of t h e compilation units are c h e c k e d a c c o r d i n g t o some partial o r d e r i n g , such as b o t t o m - u p ;

today

c o m p i l a t i o n , but pass the responsibility for

Inter-compilation

1. M o n o l i t h i c type-checking, i.e., no t y p e - c h e c k i n g a c r o s s compilations;

systems

before

For e x a m p l e , ALGOL-libraries t h e y are used, so t h a t the

o f t h e l i b r a r y e n t r i e s are known. However, it

is s t i l l t h e r e s p o n s i b i l i t y of the programmer to make s u r e h e is using t h e l i b r a r y routines c o r r e c t l y . in an

a r r a y o f nine possibll=ties, as shown in Fig. 1.

We

,3.2. I n c r e m e n t a l T y p e - C h e c k i n g

h a v e e n t e r e d a f e w e x a m p l e s y s t e m s into the grid.

Let

us

first

look a t s q u a r e [ 2 , 2 ] ,

incremental

c o m p i l a t i o n and t y p e - c l l e c k i n g , which is applied in

31

SIMULA677 module

and

M that,

AlgolOSC 10. for

Compilation of

(square[3,2]).

a

It

differs

from

the

incremental

c o m p i l a t i o n o r d e r in t h a t a r e s o u r c e may be used

i n s t a n c e , defines a class C,

r e s u l t s in o b j e c t c o d e and symbol table information.

before

The

t h e t y p e o f t h a t r e s o u r c e is d e r i v e d from the usage

symbol

table

information

is

stored

in

an

i t s t y p e is in the a u x i l i a r y file. In that case

a u x i l i a r y file and can be used by tile compiler at a

site

later

auxiliary

time.

contains

When

a module N is compiled wlfich

an e x t e r n a l

( i f p o s s i b l e ) and t e n t a t i v e l y e n t e r e d into the

actual

d e c l a r a t i o n of class C, tile

file. type

It will l a t e r be matcl]ed with the (see

Fig. 3).

The PLISS-system 8,

t y p e s p e c i f i c a t i o n s d e s c r i b i n g class C are read into

b a s e d on PL/I, uses t h a t approach. A d i s a d v a n t a g e

t h e s y m b o l t a b l e for module N so that full i n t e r f a c e

is t h a t

checking

m a y b e d e l a y e d until long a f t e r the time the module

c a n b e p e r f o r m e d ( s e e Fig. 2).

bottom-up

Thus, a

the type-checking

of a module's i n t e r f a c e

is c o m p i l e d .

c o m p i l a t i o n o r d e r must be o b s e r v e d . Tile

Algo168C s y s t e m has ~ similar arrangement, e x c e p t that

it

is

best

processing-order:

used

with

a

There

top-down

independent

The s e p a r a t e l y compilable units

type-cllecking

a r e n e s t e d b l o c k s , w h i c h can be i n s e r t e d at a later time.

This

symbol-table

is

implemented

by

are

some

systems

compilation,

that

l)ut

allow

perlorn~

for the

a c r o s s compilation units at link-time.

T h i s is an e x t r e m e c a s e of incremental checking. It

transmitting

has

i n f o r m a t i o n from o u t e r blocks to inner

the

checking

b l o c k s t h r o u g h a u x i l i a r y files.

serious until

disadvantage

integration

of

time,

delaying

long

after

the the

p r o g r a m m e r is d o n e w i t l l implenlentation.

~ e ~

derived

-Specs I

u

IType_Spec s class C

Type-S.pecs

F i g u r e 2= I n c r e m e n t a l compilation / t y p e - c h e c k i n g

F i g u r e 3= I n d e p e n d e n t compilation, increm, check

R e f i n i n g t i l e i d e a of t h e ~ x t r a c t e d symbol table information

leads

compilation

in

type-checking

J

J

Module N

to

any in

a

technique

order, an

but

that

allows

performs

incremental

the

fashion

32

3,3. Independent Type-Checking

Type-Specs c ass C

L e t us c o n s i d e r s q u a r e [ 3 , 3 ] , fully i n d e p e n d e n t compilation

a n d t y p r . - c h e c k i n g . The c h a r a c t e r i s t i c

of independent

t y p e - c h e c k i n g is t h a t t h e i n t e r f a c e s

between

the

modules

designed

in

entered

are

form

of

They

are

type-specifications

explicit.

and

i n t o a d a t a b a s e b e f o r e a n y program code

is w r i t t e n . at

the

T h a t m a y s e e m like an undue r e s t r i c t i o n

first

sight,

programmers there

were

no

interfaces, other's

but

in

fact

precise

they

could

is

tile

only

specifications not

resources.

machine-readable matter

it

way ~685f~--~./Tl declare t Class C ]

c a n s t a r t w r i t i n g s e p a r a t e modules: If program

With form,

the

it

is

of

with

each

interfaces

a

J

the in

straight-forward

f o r t h e c o m p i l e r to pick up the n e c e s s a r y

information

before

checking

a

module°

In

the

od~, I

M E S A - s y s t e m 9 f o r i n s t a n c e , t h e d a t a - b a s e of t y p e definitions

consists

of a s e t of d e f i n i t i o n s f i l e s .

E a c h o f t h e s e f i l e s c o n t a i n s the r e s o u r c e s p r o v i d e d by

a

particular

specifications.

module The

in

the

interface

form of

a

of

type-

module

described

in t e r m s of d e f i n i t i o n s files: One for t h e

provided

resources,

required

and

resources.

zero

The

or

more

compiler

for

simply

Figure 4: Independent compilation/type-checking

is (like

the

the

MESA-scheme).

generates

reads

procedures

4).

second

phase

t h e final c o d e . I l o w e v e r , this phase has

to be delayed

t h e s e f i l e s b e f o r e p r o c e s s i n g t h e module ( s e e Fig.

The

until t h e b o d i e s of the n e e d e d inline

are

a v a i l a b l e . This w e

can in]plement

w i t h a n i n c r e m e n t a l s c h e m e similar to t h e SIMULA67 So

far

we

have

only

interface-checking compilation, case actual

procedure is

type-checking

the

same

is

time

perfornlecl

as

(section

before

We

As an e x a m p l e w h e r e this An inline

it

has the

modules.

If

the

is

called header

in of

several that

5.4).

They

a r e of l i t t l e i n t e r e s t since t h e y deal

with monolithic compilation.

same

as a r e g u l a r p r o c e d u r e . Suppose t h a t an

procedure

available

yet

shall r e t u r n t o this problem in a more

h a v e n o t c o n s i d e r e d t i l e s q u a r e s [ 1 , 2 ] and

[1,8].

is a r e s t r i c t e d form of a macro in t h a t its in-line,

We

g e n e r a l f r a m e w o r k w h e n w e discuss v e r s i o n control

represents a

c o n s i d e r inline procechlres.

expanded

semantics inline

at

system.

cases where

Square [2,3]

code-generation.

is d e s i r a b l e , body

occurs

or l a t e r .

where

discussed

4. Interface

Control

different

procedure

In

is

practice,

establish

( f o r e x a m p l e in a d e f i n i t i o n s file), w e can

it t u r n s

out that

it is difficult

to

a n d m a i n t a i n c o n s i s t e n t i n t e r f a c e s among

type-check

all calls t o it, but w e c a n n o t g e n e r a t e

t h e v a r i o u s c o m p o n e n t s of a large, e v o l v i n g system.

code

since

its b o d y m a y not be programmed y e t .

However,

This

compilation

two-phase

translation.

intermediate inline

code

procedures.

interface

problem

can

be

solved

with

for the correct

a

control

The first phase g e n e r a t e s

It

which contains pseudo-calls to This

phase

and can be executed

also

checks

such a

the

helps

in a n

33

is a b s o l u t e l y crucial

f u n c t i o n i n g of a s y s t e m .

Interface

is d e s i g n e d t o g u a r a n t e e this c o n s i s t e n c y .

between

fully i n d e p e n d e n t l y

consistency

to

establish

components

correct

interconnections

b y cl~ecking their i n t e r f a c e s

INTERCOL d e s c r i p t i o n of t h e o v e r a l l s y s t e m

structure.

It a l s o e x t r a c t s

description modules First,

adhere

resources

that

of

interface

must

provided

interfaces

specifications:

really

are expected

the

specified.

provide must

be

than

resources

specified.

Fourth,

all

as

discussed describe

with

in t h e

inter-module

We

followin~l s u b s e c t i o n .

We

we

also

independent

derive

one

would

type-specifications

compilation require from

a the

F i n a l l y , w e d i s c u s s (:he a c t i o n s n e c e s s a r y if

the

interconnections

the

m a r k e d our Choices of mechanisms ill

line. In t h e r e m a i n d e r of this s u b s e c t i o n ,

describe

our i m l } l e m e n t a t i o n of t h e i n d e l ) e n d e n t type-checking

(The incremental/incremental parts

Consider

system

based

on

INTERCOL.

mechanism for module

c a n b e i m p l e n l e n t e d in a w a y similar to the

$1MULA67-scheme

l a n g u a g e s can be handled in a t y p e - s a f e

way.

have

inter-module

p r o b l e m o f i n t e r f a c i n g s y s t e m p a r t s w r i t t e n in

components

to

a dashed

type-checking,

between

the

the

Fig. 1 b y e n c l o s i n g t h e c o r r e s p o n d i n g s q u a r e s w i t h

h o w t h e s c o p e for i n t e r f a c e errors can be

different

As for

incremental derives

u s a g e o f r e s o u r c e s , w b i c l l is in g e n e r a l impossible.

l i m i t e d w i t h i n f o r m a t i o n hiding t e c h n i q u e s , and how the

an

which

required

The c h e c k i n q of t h e s e four conditions

implemented

the

facility

must be used correctly with respect to

their types.

chose

automatically.

because

from it. Second, t h e

resources

we

mecllanism

m e c h a n i s m , w e c h o s e t h e i n c r e m e n t a l one as well,

the

Third, no module, may use more required

resources

is

to their

module

Therefore,

type-checking

t o e n s u r e t h a t t h e v a r i o u s programmed

each

types

parts.

information from t h a t

describing

and will n o t be d i s c u s s e d here.)

the

following

INTERCOL-program

a f r a g m e n t of an ( u n r e a l i s t i c ) parser.

change.

system PARSER 4.1. Inter-Module In t h e

Type-Checking

previous section

module IO provide function SrcChar : char; const lineLn; type Line = record { lineNurn : int; lineBuf : array[1..lineLn] of char; }; procedure ListLine(outLine : 1"Line);

we have characterized

t h e v a r i o u s s e p a r a t e c o m p i l a t i o n and t y p e - c h e c k i n g mechanisms.

Now

we

specify

and

motivate

our

choices.

end IO Clearly, have the

f o r i n d i v i d u a l modules w e would like to

completely various

each

p r o g r a m m e r t e a m s n e e d not w a i t for

other.

mechanism

The

requires

interfaces

indel)en(lent that

we

type-checking

specify

tile

module

in s o m e w a y . We n o t e d a l r e a d y t h a t this

is n o t a s e v e r e way

modulo LEXAN provide type Lexerne = (Keyword, Operator, Identifier); function NextLex : Lexerne; require SrcChar, lineLn, Line.{lineNum,lineBuf}, ListLine end LEXAN

i n ( l e p e n d e n t mechanisms, so t h a t

r e s t r i c t i o n - - in f a c t , it is the only

in w h i c h d i f f e r e n t

programs.

end PARSER

t e a m s can use e a c h o t h e r ' s

As f o r t h e c o m p i l a t i o n mechanism, w e do

The

system

PARSER c o n s i s t s of t i l e module I0

n o t w a n t t o e x c l u d e inline p r o c e d u r e s and generics,

(for input/output)

which

analysis).

m e a n s t h a t w e h a v e to use some m i x t u r e of

independent

and

incremental

compilation

function

mechanisms.

I0

and t h e module LE×AN (for l e x i c a l

provides

SrcChar

procedure

for

the reading

following

resources;

source, c h a r a c t e r s ,

L i s t L i n e for printing a line on t h e listing

m e d i u m , a c o n s t a n t i n d i c a t i n g t h e l e n g t h of a listing To speed translate single

line,

p i e c e s o f m o d u l e s s e p a r a t e l y , for e x a m p l e routines.

independent because

Ftowever,

we

type-checking

cannot mechanism

use

an

delivers

here,

evolving

interfaces

between

the

internal

representation

of

a

line.

the next

l e x e m e . It makes r e p e a t e d calls

t o S r c C h a r . LEXAN is a l s o r e s p o n s i b l e for g e n e r a t i n g the

in f a c t , it w o u l d be quite a nuisance to

the

and

M o d u l e LEXAN i m p l e m e n t s N e x t L e x , a function t h a t

t h e i n t e r f a c e s b e t w e e n module p i e c e s are

implicit --

specify

up c o m p i l a t i o n s , w e may also w a n t to

listing;

and t h e

module

34

hence

procedure

it n e e d s t h e d e f i n i t i o n s of Line ListLine.

Note t h a t w e h a v e

omitted

the

require-clause be specified they

type-specifications

in

complain

the

Second,

o f LEXAN. (In general, t y p e s n e e d to

required

resources;

i m p l i c i t l y in t h e s t r u c t u r e . LEXAN

in

other

resources

they

are

be

where

contained

its

noted

as

declaration. provides

This e n a b l e s us to reuse

systems,

an u n d e f i n e d

forward declaration.

p r o g r a m m e r m a k e s a t y p e - e r r o r in

t h e i m p l e m e n t a t i o n o f o n e of t h e r e s o u r c e s , this will

o n l y o n c e , u s u a l l y in t h e module w h e r e

o r i g i n a t e . ) We h a v e also o m i t t e d t h e origin of

the

about if t h e

an

inconsistency

with

a

forward

This m a k e s s u r e t h a t a module r e a l l y

the resources

t h a t are e x p e c t e d from it

a n d t h a t t h e i r t y p e s a r e c o r r e c t . ~ Note f u r t h e r t h a t

required

the

m a y c o m e from d i f f e r e n t p l a c e s .

type-definition

for Line has b e e n t r a n s p o r t e d

f r o m IO t o LEXAN. Note

that

processed or

LEXAN.

results

the

above

piece

of

text

must

be If

b e f o r e w e can s t a r t compiling e i t h e r IO

ill

Compiling a set

of

an

INTERCOL

e n v i r o n m e n t s , one

description for

the

compilation

of

a module s u c c e e d s ,

the

p r o g r a m m e r has t h e g u a r a n t e e t h a t its i n t e r f a c e will fit into the rest of the system.

each

This is v e r i f i e d at

m o d u l e . S u c h an e n v i r o n m e n t consists of a pair of

the

s a m e t i m e a s t h e i n t e r n a l t y p e - c o n s i s t e n c y of

preludes,

o n e c o n t a i n i l l { I thP. required, and one t h e

the

module,

resources.

status

provided

For t h e a b o v e e x a m p l e , w e

a n d c o m p l e t e l y i n d e p e n d e n t l y of t h e

of other modules.

obtain the following preludes: 4.2.

Information

Hiding

IO.require:

INTERCOL m a k e s it p o s s i b l e to a p p l y t h e principle IO.provide: forward function SrcChar : char; f o r w a r d const lineLn; type Line = record { LineNum : int; lineBuf : array[J_lineLn] of char; }; forward procedure ListLine(outLine : 1"Line);

o f m i n i m a l p r i v i l e g e a t module i n t e r f a c e s : No module m u s t b e g i v e n m o r e r e s o u r c e s or a c c e s s rights than it

actually

needs.

heterogeneous

This

interfaces,

is

achieved

name

control

with and

write-protection. Heterogeneous

LEXAN.require: extern function SrcChar : char; extern ¢onst IineLn; type Line = record { lineNum :int; lineBuf : array[L.lineLn] of char; }; extern procedure ListLine(outLine : 1"Line);

may access

contains

indicates

its i d e n t i t y :

a compiler d i r e c t i v e

read

LEXAN.require resources,

in

moduleB1

require a, b

three to

the

contains

other

in t h e i r

resources

besides

require-clause.

the

ones

This compares

favorably w i t h t h e usual programming environments, corresponding

where

preludes.

e v e r y m o d u l e has u n r e s t r i c t e d a c c e s s to the

complete

n a m e siSace of t h e s y s t e m .

t h e t y p e s of t h e e x t e r n a l

a n d t h e i r use can n o w b e t y p e - c h e c k e d .

Name

resource

in t h e form of f o r w a r d d e c l a r a t i o n s .

has two effects:

b, c

h o w l a r g e t h e s y s t e m is in which t h e s e any

L E X A N . p r o v i d e s p e c i f i e s t h e t y p e s of the p r o v i d e d resources

modules

m o d u l e s a r e e m b e d ( l e d , t h e y will not be able

use

specified

: : m o d u l e LEXAN::

will

provide a, b, c

No m a t t e r

that

As s o o n a s t h e c o m p i l e r e n c o u n t e r s t h a t d i r e c t i v e , it

module A

modulo B2 require

N o w l e t us e x a m i n e h o w LEXAN is compiled. Its text

Different

resources.

LEXAN.provide: type Le×eme = (Keyword, Operalor, Identifier); forward function NextLex : Le×eme;

program

Interfaces:

d i f f e r e n t s u b s e t s of a common module's

This

module

Control= x can

with be

Suppose

module

subresources given

access

A

provides

xl

and x 2 . Each

to

exactly

those

First, if t h e programmer f o r g e t s to

i m p l e m e n t o n e o f t h e s e r e s o u r c e s , t h e compiler will

=The keywords forward and oxtorn are not essential; their effects can be achieved with compiler directives as well.

35

subresources

t h a t it n e e ( i s :

module A

provide type x = record { xl : int; x2 : real; };

module B

require x.x2

program

code.

Instead

where

they

are

interconnection opaque compiler

can be accessed. cannot

of B will i n d i c a t e t h a t only x . x 2

be

t~amed

and

therefore

t y p e x = record { int; x2 : real; }

of

Protection=

(variables,

parameters,

This is t o p r o t e c t global v a r i a b l e s from

accidental

modifications,

while

other

still

program

(The

default

parts.

is

that

require i l , i2

has

Module

read-only B2 h a s

specified

imported

is e x p o r t e d

read-write originate

access

Let

equivalent

of

the

to i l ,

and i2. but t h e

facilities

have

us

Although

some

adequate,

we

think

proposed that

it

mechanisms

is

PASCAL

sense

something

from

information

hiding

at

the

inappropriate

On

the

module

that

global

information

use

a

type-

a n d PASCAL, ALGOL, and a s s e m b l e r

as b e f o r e . For modules w r i t t e n

ALGOL-declarations. translator

Thus,

or

we

need a

"decoder",

that

other

to

could

special our

primitive

develop

macros r~cord

PASCAl.

a

the etc.

compiler

types,

decoder

defining offsets,

data

For

that

correct But now

translates

to

l a n g u a g e . In t h a t c a s e , t h e r e is no n e e d

to write

a s p e c i a l d e c o d e r a t all - - w e can use t h e

existing

compiler itself. course,

if

a

language

as

low-level

as

is u s e d f o r s o m e modules, t h e r e is little consistency

that

INTERCOL

can

guarantee.

In p a r t i c u l a r , if t h e r e are no t y p e s in a

language,

no

expected.

hand,

example,

sequences,

interface

On

automatic the

other

type-checking hand,

closely

can

be

related

languages, o r l a n g u a g e s b e l o n g i n g to a family c a n

interconnection hiding

we

assembler

b e i n l ~ e r f a c e d w i t h a high d e g r e e of t y p e s a f e t y .

l e v e l c a n b e u s e d t o i m p r o v e s y s t e m f l e x i b i l i t y 11. It follows

the

assembler,

Of

are

- w h y should a programmer hide himself?

we

for

f u n c t i o n s , and v a l u e p a r a m e t e r s ) .

assembly

w i t h t h e m . I n f o r m a t i o n hiding local t o a module does make

that

(for

calling

burden the languages for programming-in-the-small 3 not

assume

of

procedures,

suppose

been

as programming language features before. the

programming

constructs

generates

and i2, since t h e y

proposed

of

tile

m a p p i n g m u s t I)e r e s t r i c t e d to c o m p a t i b l e language

t o i2 is in error, since t h a t

above

of

m a p s P A S C A L - d e c l a r a t i o n s to ALGOL. Of course, this

in t h a t m o d u l e an(l p r e s u m a b l y n e e d to be

three

a

E v e n t h e s u b l a n g u a g e for t y p e -

source-to-source

modified there. All

in

in ALGOL, w e n e e d t o t r a n s l a t e t h e s e preludes into

as r e a d - o n l y . Finally, A has to botll il

implemented

in PASCAL, w e g e n e r a t e p r e l u d e s w i t h e x t e r n - and

to resources il access

l)e

a s t h e I~rogramminq l a n g u a g e s . For modules w r i t t e n

- - # means read-write

read/write

write-acce=s

variable

the

in INTERCOI. i t s e l f can be r e p l a c e d .

specifications,

- - read-only

access

can

indepen(lent

customization

With

all

is

used.

examples.)

allowing

provide variable i! : int; - - read-write readonly i2 : int; - - read-only

module B2 require =dl, ~i2 B1

on

programming languages. How

forward-declarations

module B!

restrictions

( W e h a v e c h o s e n a m o d i f i e d PASCAL in tile previous

and record fields are read-only.)

module A

the

c o n t r o l w o r k in t h o s e c a s e s ?

specification

INTERCOL, t h i s c a n h e c o n t r o l l e d e x p l i c i t l y a t t h e interfaces.

different

languages

record

fields, etc.).

in

modules

of

INTERCOL

Some programming languages

data-resources

variables

enforce

does interface

p r o t e c t i o n a~ p a r t of tl~e d e c l a r a t i o n

read-access

( N e v e = t h e l e s s , f e a t u r e s like

4,3, Multiple Languages

not

Suppose

write

module

b y t h e l a n g u a g e s t h e m s e l v e s so t h a t a can

number

specify

the

This can be accomplished with a

referenced:

Write

level

at

required resources.)

r e c o r d d e f i n i t i o n c o n t a i n i n g an opaque field, i.e., one that

should be s p e c i f i e d

r e c o r d f i e l d s and w r i t e - p r o t e c t i o n must be

supported

The require-prelude

they

neechcd:

principles

s h o u l d n o t b e i m p l e m e n t e d a t t h e d e t a i l e d l e v e l of

36

v e r s i o n , w e n e v e r t h e l ~ : s s end up dealing with it in a

4 . 4 . Propagation of Interface Changes

n u m b e r o f v e r s i o n s i n t e r n a l l y : .1here is last w e e k ' s An

important

management these

problem

in large p r o j e c t s

is t h e

v e r s i o n , a s t a b l e v e r , ' ; i O l l , atl exl~erilltental version, a

o f i n t e r f a c e c h a n g e s . With our s y s t e m ,

testing

c a n b e p r o c e s s e d a u t o m a t i c a l l y , b e c a u s e all

the needed

i n f o r m a t i c n is c o . l t a i n e d in t h e INTERCOL

description.

C h a n g e r o f imr~rfaces are r e c o r d e d b y

modifying

t l l a t d e s c r i p t i o n and recompiling it.

in

this

before.

case

is

make

sure

that

This

operating least,

inconsistent

lay-out

o f r e c o r d s ) , r e c o m p i l a t i o n s can be s t a r t e d .

Before

going

designer have

prone

through

with

a

modification,

c o u l d a l s o b e i n f o r m e d a b o u t how much will

estimate

More.

the

impact

inH)ortant

still,

the

precise

chanties

way

can

sent

p r o q r a m m e r s of t h e a f f e c t e d modules

functional

hardware

and

the

The

ntltti,.~rol.lS

manaclement versions

and

creates

V~:rsio=~ ,~ontrol is d e s i g n e d to

o f orqaniTinq sttch a v a s t collection of More

..H)ecilically,

version

control

the following:

a n d t h e INTI-I}COL. d~...,;cril)tion, v e r s i o n c o n t r o l d e i e r m i n e s w h i c h v e r s i o n s of w h i c h component.~ should be combined t o c r e a t e , a particLdar v e r s i o n of a p a r t i c u l a r conficlnration.

be

in

groups, the

-Version S~.q~?ction. With a .';at of rules

a p r o p o s e d cllange.

documented to the

a

of

to

t h e p r o f l r a m m : : r from t h e t e d i o u s and e r r o r task

automates

t o b e r e c o m p i l e d or rel~rogrammed, so t h a t he

can

repair12. of

components.

the

pro qramn~eer A's

s y s t e m s , r e o r g a n i z a t i o n , and last, but not

problems.

relieve

( l i k e c h a n g e s to c o n s t a n t s or

user

changes

error

serious

version,

OI.her v e r s i o n s arise dtte to

individual

maintenance

m o d u l e s c a n n o t b e u s e d until t h e y are u p d a t e d . For minor modifications

to

enhancements,

The minimum a c t i o n to be t a k e n

to

(lelJugqing

version, etc.

tailoring

w i l l u s u a l l y d e s t r o y t h e cllobal i n t e r f a c e c o n s i s t e n c y established

and

temporary

and a u t o m a t i c a l l y

( b y p u t t i n g m e s s a g e s into m a i l b o x e s , for i n s t a n c e ) .

-Con.~truction. Ver.~ion control oral)adios After

an

determine

tile

preludes be

interface

affected

described

implemented

comparison

reveals

exactly

to

take

was were

modules.

have

to

Given

(letail~--.cl knowleclEle, al)ont t h e various c o n s t r u c t i o n proce:~sors t h a t n e e d to b e i n v o k e d t o g e n e r a t e a runable program.

the

a straiclht-forward of

the

which

old

manner: A

and n e w

preludes

module-interfaces

-Spaee/Ti/nc~ Trarh:off. Version control

were

m a i n t a i n s a d a t a I)a~,e of s o u r c e t e x t a n d t h e d e r i v e d ver...;ions like o b j e c t hie(hales, I ) a r t i ~ l l y linked s u b s y s t e m s , etc. It t r i e s to opLiltfize the .~;I)ace/ time tradeorf of storiticj derived versions or r e g e n e r a t i n g Lhem on demand.

i n t o a c c o t m t w h e t h e r a required r e s o u r c e

no

u s e d in t h e implementation; c h a n g e s

difference

not used.

isolated,

the

obsolete,

for

required

rosa[trees

that

O n c e t h e it~consistent modules are version

control

precompiled

recompilations, modules

first

Of c o u r s e , t h e comparison can be refined

actually

make

we

it~ a pr~:vious section, this can

in

simple

changed.

change,

and

system

versions,

flenerate

change

t h a t n e e d to be r e v i s e d .

simple c h a n g e - r e q u e s t s

can

delete

start

some

notices

-Reconstruction.

If a new source v e r s i o n e n t e r s t h e d a t a b a s e or if interfaces c h a n g e , v e r s i o n control determines which pro-constructed s u b s y s t e m s a r e ob.,=ol¢:te. r h e y will b e r e c o n s t r u c t e d on (]emand.

for

In this fashion,

as w e l l as major design

r e v i s i o n s c a n b e m a t l a g e d e f f i c i e n t l y and reliably.

in

5 . V e r s i o n Control

order

to

de,scribe

configurations, System

maintenance

in

complicated

by

projects

is

different

versions

system

is

planned

large the

proliferation

and c o t ] f i g u r a t i o n s . to

be

programming

available

accommodate

of

in

Even if a

an

family,

in a single

we

multiple expanded

versions INTERCOL

and to

t h e s e wotiot~:;. [acl~ module or s y s t e m

INTERCOL whose

The description

37

I'ave

descril~tion is n o w v i e w e d as a

n}eml)ers a r e t h e various versions. c a n t h e n be e x p l o i t e d to a u t o m a t e

the above

f u n c t i o n s . (For a d i f f e r e n t approach, t h e

interested

r e a d e r is r e f e r r e d t o Cooprider 13.)

t h a t c a n l)e g e n e r a t e d b y d i f f e r e n t settings of c o n d i t i o n a l compilation s w i t c h e s fall in this c l a s s too.

5 . 1 . Module Families 5 . 2 ° S y s t e m Families W e d i s t i n g u i s h t l l r e e o r t h o g o n a l kinds of members A

of a module family.

system

family

compositions. 1. Implementations. Impl(.'mentations of a m o d u l e f a m i l y a r e t h e a c t u a l source programs. T h e y s h a r e the same i n t e r f a c e and a b s t r a c t s p e c i f i c a t i o n s , b u t m a y l)e iml)lemenl.ed d i f f e r e n t l y , in different lan(lUa~le.'q or t a i l o r e d to different envirol}m(:nts, el)crating s y s t e m s , or usher groups, For e x a m p l e , a program :liar ruIIS iIn(ler t w o d i f f e r e n t o p e r a t i n g :;ystelilS may h a v e t w o d i f f e r e n t w : r s i o n s of the module t h a t p r o v i d e s t h e i(lealized o p e r a t i n g system environment.

components

consists

Each which

of

a

series

of

composition

is

a

of

are

other

list

module or

system

f a m i l i e s . Thus, e a c h c o m p o s i t i o n r e p r e s e n t s not only o n e , b u t a w h o l e s e t of f a m i l y members, d e p e n d i n g o n h o w r i c h t h e f a m i l i e s of its c o m p o n e n t s are. specific by

A

m e m b e r o f a c o m p o n e n t can be s e l e c t e d

indicating

version

of

implemP.l~tation, revision, and d e r i v e d a

composition

module

and

family,

components

or

of

by

indicating

a system

family.

T h i s l e a d s t o a r e c u r s i v e d e s c r i p t i o n , which can be simplified considerahl,l with defaults.

Example.

Suppose

M1

and

M2

are

module

f a m i l i e s , M 1 . 1 a n d M 1 . 2 a r e il]~plementations of M1,

2. Rovi.sions. Each i m p l e m e l l t a t i o n e x i s t s as a sequence of r e v i s i o n s t h a t succeed each other in the d e v e l o p m e n t h i s t o r y . Each r~¢vision is a m o d i f i c a t i o n of t h e p r e v i o u s one. For e x a m p l e , f i x i n g a hug in t h e l a t e s t revision of an implementation g e n e r a t e s a n e w one. All revisions of an iml)len~entation a r e linearly o r d e r e d b y t h e i r c r e a t i o n time. Althougl~ the n u m b e r o f r(~visions can be quite l a r g e , t h e i d e a is t h a t normally one d e a l s o n l y w i t h t h e top few, for e x a m p l e t h e e x p e r i m e n t a l , t h e stable, a n d t h e b a c k u p revL,;ions.

and

M2.1

S.S1

a n d M 2 . 2 a r e i m p l e m e n t a t i o n s of M2. If

= { M 1 , M 2 } is a composition of a s y s t e m

family

S,

three

then

the

following

examples represent

m e m b e r o f S: S.S 1(M 1. J.: 7 9 0 G 14:Opt, M2.2:79 04_22:0pt) S.S 1(MI.2, M2.2) £.S1

The

first

example

implementations, versions

(optinHze(I)

example

in t h i s

selected.

Versions. D e r i v e d v e r s i o n s are generated automatically from revisions of implementations. For example, each revision of an implementation written in p o r t a b l e Bliss c a n b e c o m p i l e d into a program t h a t r u n s on a P D P - 1 1 , a PDP-IO, or a VAX ([liven that no machinedependent featurf:s of Bliss-16, B l i s s - G 6 , or R l i s s - 3 2 are used). Other d e r i v e d v e r s i o n s can be p r o d u c e d b y a c o m p i l e r t h a t g~.nerates optimized or non-optimized c o d e , c o d e w i t h or without r u n - t i m e c h e c k s of a r r a y b o u n d s , w i t h or w i t h o u t d e b u g g i n g and i n s t r u m e n t a t i o n hooks. The v e r s i o n s

exist

The and

the newest

second derived

revisions are

they

will

be

used

regardless

of

t h e y a r e o p t i m i z e d or hot; o t h e r w i s e , non-

optimized third

(leMre(I.

re.visions

case,

which

If p r e c o m p i l e ( I d e r i v e d v e r s i o n s of t h e s e

already,

whether

explicitly

( b y (late), and d e r i v e d

at,:

suppresse.~

versions;

8. Derived

indicates

revisions

d e r i v e d v e r s i o n s will be g e n e r a t e d .

example

The

d o e s n o t mention implementations a t

all; in t h i s c a s e , t h e d e f a u l t i m p l e m e n t a t i o n s o f M1

and M 2 a r e s e l e c t e d .

5.a. A Complete Example We

now

primitive

38

present

parser

members

that

machines

and

our

as can under

a

earlier system

execute two

e x a m p l e of

the

family

two

on

two

diffetent

with

different operating

systems.

activities

fluctuate.

For e x a m p l e , t h e modifications

t o a p a r t i c u l a r s u b s y s t e m m a y go through c y c l e s of

system PARSER

h i g h a n d l o w a c t i v i t y . As t h e s u b s y s t e m a p p r o a c h e s a

module ]0 provide function SrcChar : ehar~ ¢onst lineLn; type Line = record { lineNum :int; lineBuf : array[L.lineLn] of char; }; procedure ListLine(outLine : ~Line);

the

for

version they

changes

When module,

version

because

of

interface

of

machine, w e o b t a i n a

is

that

a

the

By pairing LEXAN

the

cycle

can

optimize the

and

The t y p i c a l w o r k -

p r o g r a m m e r r e p e a t e d l y goes of

modification,

execution.

compilation,

Assume

that

the

is w o r k i n g in an e x p e r i m e n t a l a r e a (a f o r i n s t a n c e ) w h i c h contains a c o p y

module

system

controller

t i m e for t h e t e s t s y s t e m in which the

sub-directory

of I0, and compiling for

o f PARSER f o r a PDPIO.

the

is

R e - g e n e r a t i o n occurs on

m o d u l e is e m b e d d e d .

programmer

is c o m p a t i b l e BLISS. By pairing LEXAN with target

and

It

-Ihe only time t h a t t h e

obsolete

version

integration,

t h e r e is o n l y o n e ; l e t us assume, the d e f a u l t

the

module

a p r o g r a m m e r is t e s t i n g and debugging a

re-integration

the

through

as

each

requested.

or new revisions.

the

T h e i m p l e m e n t a t i o n o f LEXAN n e e d not be mentioned

PDPIO

of

was

demand only.

pattern

the

for a long time, it

c o n t r o l l e r d e l e t e s d e r i v e d v e r s i o n s is w h e n beco~le

f o r T O P S I O , an o p e r c t i n g s y s t e m for a DEC-PDPIO.

the TOPSlO°implementation

version that

in o r d e r t o c o n s e r v e s p a c e .

modified

language

partially

p r o g r a m m e r ' s r e s p o n s i b i l i t y t o d e l e t e some of t h e s e

H Y D R A - o p e r a t i n g s y s t e m running on C.mmp, and one

since

to

The v e r s i o n c o n t r o l l e r maintains t h e

derived

(sub-)system

one

appropriate

space.

latest

iml)lementations,

is

is n o t n e e d e d

the following:

composition CMMP = { LEXAN, ]O.HYDRA }:TarBet.PDP[ t composition PDPJO = { LEXAN, |O.TOPS } :TarBet.PDPJ0 end PARSER two

it

As a s i m p l e , s e m i - a u t o m a t i c solution w e propose

module LEXAN provide type Lexerne = (Keyword, Operator, Identifier)~ function NextLe× : Lexeme; require SrcChar, lineLn, Line.{lineNurn,lineBuf}, ListLine end LEXAN

has

state,

it a n d s t o r e it for l a t e r use. H o w e v e r , if

subsystem

wastes

implementation HYDRA.bliss implementation TOPS.bliss end IO

I0

stable

integrate

M

he

is

updating.

Suppose t h a t

X is t h e t e s t b e d for M. W h e n e v e r he issues

with

IO.HYDRA a n d compiling for a PDP11 t a r g e t , w e

t h e c o m m a n d t o r e - i n t e g r a t e X, he i n d i c a t e s tl]at he

can

generate

wants

a version

multiprocessor

that

runs on C.mmp (a

to substitute

also generates 5.4. System

The

Generation

INTERCOL d e s c r i p t i o n

revisions stack

versions

are

automatically. optimization machine

to

SDC 14

and

SCCS 15.

constructed

and

One

can

either

shortens

integrated

determined

Unfortunately, statically,

the

optimum c a n n o t

to of

linked X

in.

from

This

scratch

saves for

the

every

above

is

the

a

simple

integration

cache

til~le for

scheme

which

recently

used

C o m b i n e d w i t h t i m e - o u t s for deletions

f r o m t h e c a c h e , it s h o u l d t a k e c a r e of most of t h e

consume

space-management

t i m e b y r e g e n e r a t i n g d e r i v e d versions on

disk.

has

subsystems.

for

program d e v e l o p m e n t and

maintenance.

demand, o r o n e c a n s a v e t h a t time b y storing them on

be

M

The

Derived

This p o s e s a classical t i m e / s p a c e problem.

In all s u b s e q u e n t i n t e g r a t i o n s of X,

only

m o d i f i c a t i o n o f M.

o f an i m p l e m e n t a t i o n are maintained in a

similar

a p a r t i a l l y i n t e g r a t e d s y s t e m X with

only M unbound. re-integration

is used to s e t Ul) a

b a s e t h a t s t o r e s t h e v a r i o u s components. The

data

t h e n e w l y modified M. The first

t i m e h e i s s u e s t h a t command, t h e v e r s i o n controller

c o n s t r u c t e d o u t of 16 DEC-PDP1 l s).

be

In t h e p r e v i o u s s e c t i o n s w e d i s c u s s e d how the

because system generation

various

39

family

members

are

selected.

System

generation

is

integration

scheme.

interleaved This

performed

wilh

There

the

may

compile/

be

in t h i s t a s k .

several

p h a s e s of compilation and integration.

is d u e t o t h e f a c t

only logical interfaces.

m a c h i n e s c a n handle it e f f i c i e n t l y and reliably.

t h a t INTERCOL describes A logical i n t e r f a c e contains

6. Status (Juno 1979)

e n o u g h i n f o r m a t i o n to perform the first compilation p h a s e , n a m e l y s y n t a c t i c and semantic checking and the

generation

there code

of

i n t e r m e d i a t e code.

W e h a v e i m p l e m e n t e d a demonstration system to

However,

test

is n o t e n o u g h information to g e n e r a t e final because are

missing.

Examples

are

values

constants,

a r r a y hatreds, r e c o r d sizes, field o f f s e t s ,

decide

to

make

the

logical

of

interface

taken

in

the

undesirable system

specifications

(this

MESA-system).

of

because

this

data

arrays,

r e s t r i c t the w a y s d i f f e r e n t versions

follows:

The

first

related

into

intermediate

interfaces

code

in which

performs

base.

Next,

physical

the

and s t o r e s integration

interfaces

of

the

opaque

data

is s a f e

in the sense that

it is

address

aritllmetic.

(For

derefereneing,

accessing

records

and

and e v e n t y p e - h r P a c h i n g are all c h e c k e d

languages.

C and TC d i f f e r

We

chose TC as the t y p e -

sublangaJage for INTERCOL. Of course,

guaranteed

for

and w r i t e - p r o t e c t i o n can only module~ w r i t t e n

in TC.

For

I m p l e m e n t a t i o n of, and e x p e r i m e n t a t i o n with, the earlier

the physical

version

especially

o f r e q u i r e d r e s o u r c e s are still unbound. resources

partially

as w r i t e - p r o t e c t i o n for data.

l o g i c a l a n d p h y s i c a l i n t e r f a c e s at the moment.

system

T h i s p h a s e a l s o e x t r a c t s th,~. physical i n t e r f a c e s of provided

pro(Iramminq languages

s i m p l i f i c a t i o n , w e do not make a distinction b e t w e e n

c o m p l e t e t y p e - c h e c k , n o of ,~ module and t r a n s l a t e s it

and

well

strong type-checking

problems, w o r k s as phase

the

through

specification

compilation/integration

compilation

Its

e n o u g h t o s h o w t h e f e a s i b i l i t y of interfacing closely

be

avoids the3e

for

f o r p o t e n t i a l protP.ction violations.)

body. complicated

iml)lements

p a s s i n f l p a r a m e t e r s , c r e a t i n g or returning

pointers,

Furthermore, this

f a m i l y w o u l d h a v e t o f u n c t i o n w i t h the same inline

which

as

except

example,

i n l i n e p r o c e d u r e s w e r e p r e s c r i l ) e d in the interfaces,

more

curr~:ntly

i m p o s s i b l e t o gain w r i L e - a c c e s s to w r i t e - p r o t e c t e d

is

t h e n all r e v i s i o n s of all implementations of a module

A

and

TC is a s t r o n g l y t y p e d variant of C,

Write-protection

c a n b e c o n s t r u c t e d . For e x a m p l e , if the bodies of

scheme,

and opaque

structures

struct~=re may I)e aJnal)le to provide enough

would severely

INTERCOL

supporting

and

the d e s i g n e r of tile overall

d e t a i l t o d o t h e i)hysical bin(ling.

[~[)1>11/40

c o n t r o l as d e s c r i b e d in section 4.

C 1 6 a n d TC 17.

approach w a s

However,

a

main c o m p o n e l l t S are compilers for all early version

p h y s i c a l i n t e r f a c e i d e n t i c a l and include them fully in the

on

interface

b o d i e s o f inline p r o c e d u r e s , and generic definitions. could

a n d r e f i n e our ideas. The s y s t e m runs Lander

UNIX

p h y s i c a l pr(~perties of the i n t e r l a c e

elements

One

In any reali~flic s o f t w a r e project, it is

t o t a l l y h o p e l e s s to perl'or;, t h a t task by hand; only

with

greatly respect

improved

INTERCOL,

to the r e p r e s e n t a t i o n of

f a m i l i e s . Fleimplementation i=lcluding version

c o n t r o l is p l a n n e d .

them in the data phase collects the module's

required

7. C o n c l u s i o n s

r e s o u r c e s , o n c e f o r e a c h configuration in which the m o d u l e is u s e d . resources

Note t h a t the origin of tile required

We

is n e e d e d t o d e t e r m i n e which physical

interfaces

to

interconnections

use.

This

is

derived

from

the

generate

described and

guarantees

s p e c i f i e d in the INTERCOL program.

the

programmed

F i n a l l y , t h e l a s t p l l a s e uses tile physical i n t e r f a c e s to

have

development

m a c h i n e c o d e , again once for each

integrated

structural system

interconnections

an

maintenance

and

software

environment that

consistency

with

respect

version

of

a to

integration.

,Summarizing, its facilities are as follows:

configuration.

Interface C l e a r l y , t h e r e is s u b s t a n t i a l bookkeeping involved

Control g u a r a n t e e s the c o n s i s t e n c y of

the interfaces ensures

40

global

b e t w e e n the s y s t e m components. It type-correctness

by

performing

inter-module information

type-checkinfo.

It

implements

I m p a c t of Mesa on System Design, pages ?. ACM, IEEE, ERO, GI, Sept. 1 9 7 0 .

hiding w i t h d e t a i l e d name control and

write-protection.

It

detects

the

inconsistencies

c a u s e d b y i n t e r f a c e chart,lies and takes appropriate action.

7.

B i r t w i s t l e , G., En(h:zin, L., Ohlin, M. and Palme, d. DECsystem-10 Simula Language t t a n d b o o k Part 7. Rap. C 8 3 9 8 , Swedish N a t i o n a l D e f e n s e Research Institute, March 1976.

8.

W h i t e , John R. and Anderson, Richard K.. S u p p o r t i n g t h e S t r u c t u r e d Development of C o m p l e x PL/I S o f t w a r e Systems. S o f t w a r e - P r a c t i c e and Experience 7 (1977), 270-293.

9.

M i t c h e l l , d a m e s G., Mayl>ury, William, and S w e e t , Richard. ML~sa Language Manual. X e r o x Pale Alto Rer;earch Center, Feb. 1978.

10.

C l e v e l a n d , J . C . The Environ and Using F a c i l i t i e s o f ,41gel G(~C. Computer S c i e n c e D e p a r t m e n t , UCIA, April 1975.

11.

P a r n a s , David t . On the Criteria To Be Used in D e c o m p o s i n o Sy;~tems into Modules. C o m m u n i c a t i o n s of t h e / ] C M 15, 2 (Dec. 1972), 1053-105~.

12.

B e l a d y , L.A. and L~:hman, M.M. A Model for L a r g e Program D e w : l o p m e n t . IBM Systems J o u r n a l 1.G. 3 ( 1 9 7 6 ) , 2 2 5 - 2 5 2 .

13.

C o o l ) r i d e r , Lee W. The Representation of F a m i l i e s of P r o g r a m m e d Systems. Ph.D. Th,, Carney;lie-Mellon University, Department o f C o m p u t e r Scienc(:, 1078.

14,

H a b e r m a n n , A. Nice. ,4 Software Development Control System. C a r n e g i e - M e l l o n University, Department of C o m p u t e r S c i e n c e , 1970.

15.

Rochkind, Marc J. The Source Code Control S y s t e m . IEEE Transactions on Software E n g i n e e r i n g S E - I , 4 (Dec. 1075), 064-070.

16.

K e r n i g h a n , Brian W. and Ritchie, Dennis M. The C P r o g r a m m i n g Language. P r e n t i c e - H a l l , 197{;.

17.

T i c h y , W a l t e r F. The TC-Manual. TC is a s t r o n g l y t y p u d version of the C-language, d e v e l o p e d a t the Computer Science D e p a r t m e n t of Carnegie-Mellon University.

M u l t i p l e l a n g u a g e s can be accommodated.

Version

Control

generation

in

system.

It

selecting

a

performs

ensurE..:

versions

automatic

system

multi-version/multi-configuration structural

correctly.

consistency

by

It performs f l e x i b l e

v e r s i o n i n t e g r a t i o n b y handling logical and physical interfaces.

It mana qes a data base of numerous

components

and optindzes tile s p a c e / t i m e t r a d e o f f

of storing/regenerating changes

by

subsystems.

detecting

inconsistent

It responds to and

deleting

thank

A. Nice

obsolete versions. Acknowledgments:

I

wish

to

H a b e r m a n n f o r num~.rous discussions and valuable s u g g e s t i o n s , and Frank Deremer for his hell) in the d e s i g n o f an e a r l y v e r s i o n of INTERCOL. References

7.

B e l a d y , L.A. l arfle Soflware Systems. Rap. R C - 6 9 0 6 , IBM I boreas J. Watson R e s e a r c h C e n t e r , dan. 1978.

2.

B e l a d y , L.A. arid Lehman, M,M. The C h a r a c t e r i s t i c s of I ar(le Systelns In Peter W a g n e r , I~eso, lrch Directions ili Software Enginoerin.q, M.I.T. Press, 1979, pp. 106-138.

3.

D e R e m e r , Frank and Kron, Ilans H. P r o g r a n ] m i n g - i n - t h e - LI a r g e vs. P r o g r a n m f i n g - i n - t h e - S m a l l . IEEE Transactions on Software Engineering SE-2, 2 ( J u n e 1 0 7 6 ) , 80-~$G.

4.

5.

6.

T i c h y , W a l t e r F. INTERCOL User Manual. C a r n e g i e - M a r i o n University, Department of C o m p u t e r S c i e n c e , 1 0 7 0 . To be published.

Morris,,lan~es. The Sniggering l y p e - C h e c k e r Fxp~:riment. An e x p e r i m e n t c o n d u c t e d w i t h the Mesa t y p e - c h e c k e r at X e r o x Pare, Palo Alto; p r i v a t e communication. Lauer, Hugh C., S a t t e r t h w a i t e , Edwin H. The

41