1. technology and computing
2. software

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:
<empty>
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