a matter at r programming, but also a matter of .... text of the module and may be used in the program ..... different lan(lUa~le. ..... ML~sa Language Manual.
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
