 |
Claims  |
|
|
Wherefore, having thus described our invention, we claim:
1. A computer device for building a software system having a sequence of
components, the device comprising:
(a) computer means for executing pre-established logic sequences and for
reading from and writing to memory;
(b) source code memory means for storing a basic source code for each
component of a plurality of software systems, each component comprising a
plurality of sequential statements, and for storing, for each basic source
code of a component, a sequence of modifications to the respective source
code, each modification defining a different version of the respective
component and being identified by a version number;
(c) build list means for designating the sequence of said component of a
desired software system to be built;
(d) version list means for listing on a rule basis user desired possible
versions of each of said components of the desired software system to be
built;
(e) version designation means for dynamically designating on a
component-by-component basis the version number to be currently employed
during the building of said desired software system;
(f) GET statement logic sequence means to be executed by said computer
means for accessing the source code memory means and for providing on
request the next statement in sequence of a designated version of a
component in the source code memory means according to the version
currently designated by said version designation means;
(g) derived object pool memory means for receiving and holding translated
components of said desired software system as the system is being built;
and
(h) system build logic sequence means to be executed by said computer means
for establishing from said build list means and said version list means a
sequence of components by version numbers, corresponding to rule
satisfying versions of the components, to be used to build the desired
software system, for periodically setting said version designation means
to reflect the version number of a component to be currently translated by
any one of different translators supported by the computer means, for
sequentially accessing said GET statement logic sequence means to
sequentially obtain the rule satisfying versions of the components on a
statement by statement basis from the source code memory means, and for
using said statements to build from the translated components the desired
software system comprising the designated components and rule satisfying
versions thereof in said pool memory area.
2. The computer device of claim 1 wherein:
said system build logic sequence means includes logic to use the most
recent version of a component if no version number is designated by said
version designation means.
3. The computer device of claim 1 further comprising:
(a) bound configuration memory for holding build histories of built
software systems as Historical Records, where
said system build logic sequence means, as part of the building of each
software system, creates a build history in said bound configuration
memory comprising a list of the components and versions employed to build
the system, each build history identified by a unique Historical Record
identifier; and
(b) build list designation logic sequence means, to be executed by said
computer means for accessing said bound configuration memory and using a
user designated Historical Record build history in conjunction with the
build list means and said version list means to designate the version of a
component of a to-be-built software system, such designation recreating a
prior built software system from only said unique Historical Record
identifier.
4. The computer device of claim 3 wherein:
said bound configuration memory is contained within said derived object
pool memory means.
5. The computer device of claim 1 further comprising:
(a) bound configuration memory for holding build histories of built
software systems as Historical Records, each build history including a
unique identifier for identifying each translated component created by the
translating of a version of a component with a respective executed logic
entry in said system build logic sequence means;
said system build logic sequence means, as part of the building of each
software system, creating a build history in said bound configuration
memory comprising a list of the components and versions employed to build
the software system and said unique identifier; and
said system build logic sequence means, as part of the building of each
software system, checking said Historical Records for each logic entry in
the system build logic sequence and utilizing a previously created
translated component having an executed logic entry corresponding to a
logic entry in the logic sequence rather than utilizing source code for
said logic entry to create said translated component, the previously
created translated component existing within said pool memory means.
6. The computer device of claim 1 wherein:
(a) said drived object pool memory means is adapted to have a plurality of
systems built within it at one time; and,
(b) said system build logic sequence means is adapted to concurrently
employ a plurality of said build list means and said version list means
simultaneously to build a plurality of said software systems within said
derived object pool memory means simultaneously.
7. The computer device of claim 6 further comprising:
a bound configuration memory for holding build histories of built software
systems as Historical Records, each build history including a unique
identifier for associating each translated component created from the
translating of a version of a component with a respective executed part of
said system build logic sequence means;
said system build logic sequence means, as part of the building of each
software system, creates a build history in said bound configuration
memory comprising a list of the components and versions employed to build
the system and said unique identifier; and
said system build logic sequence means, as part of the building of each
software system, checks said Historical Records for each part to be
executed of the system build logic sequence means and utilizes a
previously translated component corresponding to a said part to be
executed, rather than utilizing the source code for said part to be
executed, said translated component existing within said pool memory
means.
8. The computer device of claim 7 wherein:
(a) said Historical Records include last time used means for indicating
times of last utilization of translated components; and additionally
comprising,
(b) purge logic sequence means to be executed by said computer means for
periodically checking said last time used means and for purging from said
pool memory means translated components that have not been utilized within
a preset period of time.
9. The computer device of claim 1 further comprising:
(a) module modification logic sequence means to be executed by said
computer means for modifying and thereby generating new versions of
components in said source code memory means by adding to said sequence of
modifications in said source code memory means;
(b) monitors coupled with selected components of said source code memory
means, the monitors designating notifications to be made when
modifications are made to said components which have been selected for
monitoring; and,
(c) module monitoring logic means for establishing module monitoring
information and notification designations of said monitors, the module
monitoring logic means interfacing with said module modification logic
sequence means, and making notifications according to said designations of
monitors when a modification to respective components being monitored is
made.
10. The computer device of claim 9 further comprising:
(a) task designation logic sequence means to be executed by said computer
means for designation sequences of subtasks to be accomplished as tasks;
(b) task memory means for holding said task designations from said task
designation logic sequence means; and
(c) task control logic sequence means to be executed by said computer means
for automatically putting subtask completion information into said task
memory means, for interfacing with said module modification logic sequence
means, the task control logic sequence means putting subtask completion
information into said task memory means when a new version of a component
is created by the module modification logic sequence means.
11. A computer device for building software systems having a plurality of
elements, each element comprising a sequence of logic statements, the
device comprising:
an operating system having at least one computer language translator;
source code memory means for storing versions of elements of various
software systems;
a system model providing an indication of elements and a sequence of the
elements to be used to build a desired software system;
a configuration thread providing a rule-based indication of user chosen
possible versions of each element of the desired software system;
a version designator table for providing the translator an indication of
the version of an element to be currently translated, the table being
settable in a manner so as to dynamically provide an indication of version
of an element on an element by element basis during the building of the
desired software system; and
a system builder combining and evaluating the indications of the system
model and configuration thread to form a bound configuration thread for
the desired software system, the system builder determining a version of
an element in the system model and setting the version designator table to
indicate the version of the element according to the bound configuration
thread, such that as the version of an element is indicated by the table,
the system builder enables the operating system to read form the source
code memory means the version of the element indicated by the table and
enables the translator to translate the version of the element, the system
builder setting the version designator table for each element of the
desired software system.
12. A computer device as claimed in claim 11 wherein the source code memory
means stores versions by recording for each element a sequence of
modifications to the element, each modification in the sequence defining a
different version of the element and being identified by a version number;
the operating system reading and applying the sequence of modifications
during a reading of a version of return the respective version from the
source code memory means.
13. A computer device as claimed in claim 12 wherein the version designator
table provides an indication of the version of an element by a version
number which is used by the operating system to read directly a certain
version.
14. A computer device as claimed in claim 11 wherein a bound configuration
thread of a previously built software system is used in the configuration
thread to provide an indication of versions of elements in the desired
software system.
15. A computer device as claimed in claim 11 further comprising a derived
object pool in which translated elements are stored along with their
respective bound configuration threads.
16. A computer device as claimed in claim 15 wherein the system builder
compares the bound configuration thread formed for a to-be-built desired
software system with bound configuration threads in the derived object
pool to determine which elements of the to-be-built desired software
system are to be currently translated and which elements have
corresponding translations in the pool that may be used in the building of
the desired software system.
17. A computer device as claimed in claim 15 wherein the derived object
pool is a cache memory.
18. A computer device as claimed in claim 17 wherein the translated
elements stored in the derived object pool are purged in order of least
recently used to most recently used.
19. A computer device as claimed in claim 11 further comprising:
monitor means coupled with user selected versions of elements in the source
code memory logically means for providing notification, to a respective
user, of modifications of the selected versions of elements.
20. A computer device as claimed in claim 11 wherein the system builder
enables the operating system and translator to translate elements of more
than one desired software system at a time using in common the source code
memory means, the system builder dynamically setting the version
designator table accordingly. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
For many years, there was no such thing as automated "configuration
management" in relation to computer software. At first, there was nothing
of a software nature having a configuration to be managed. As the early
software "systems" were developed, documentation and control of the
"current version" was most often accomplished as a de-facto manual
configuration management in the manner shown in FIG. 1. A system was
built, tested, the components revised and the system rebuilt. It was then
installed and any future changes made by way of "patches" which were, in
turn hand written as generally indicated at 10 in FIG. 1 onto the program
listing 12 of the system as originally built and installed.
More recently, however, Computer-Aided Software Engineering (CASE)
environments are becoming not only helpful but, in many instances,
essential for complex software projects, just as Computer-Aided Design
(CAD) systems have become essential for complex hardware projects. The
phrase "software engineering environment", while used in many contexts,
generally refers to an operating system environment and a collection of
tools or subroutines. It is in this context that the term is used herein.
A few well know prior art CASE systems are:
UNIX/PWB--designed to run on AT&T's UNIX programming environment, includes
the SCCS source code control system and the MAKE configuration tool.
RCS--a more powerful source code control system that also runs on UNIX
systems.
CMS and MMS--the Digital Equipment Corp. VAX/VMS equivalent to SCCS and
MAKE. CMS provides a richer set of source control capabilities than does
SCCS or RCS; MMS is virtually the same as MAKE. SCCS/MAKE, RCS, and
CMS/MMS work with the standard compilers, editors, and debuggers found on
the host system.
ALS--the Ada Language System, was developed to meet the Stoneman
requirements for an Ada programming support environment. ALS includes an
Ada compiler, debugger, binder, and execution environment. In addition,
the ALS has a source code control system that keeps successive generations
and variants of packages. The ALS does not have a single configuration
management tool, but provides the primitives needed to build one. The ALS
Ada compiler/linker detects the need to recompile (as required by the Ada
standard).
Cedar--built on the Xerox PARC Computer Science Laboratory system. Although
the Cedar system does not provide for source code control, it does allow
several copies of a module to exist, each stamped with a date/time. The
Cedar "System Modeller" is a configuration management tool that notices
when a new version of a module comes into existence (via coordination with
the editor), and can build a complete program from an arbitrary set of
module versions. Cedar requires that only the Cedar editor and compiler be
used.
CONFIGURATION MANAGEMENT BACKGROUND
MAKE looks at each item in a "makefile" and finds its "date/time modified"
entry (DTM). If the DTM of an object pre-dates the DTM of any of the
objects it depends on, the object is rebuilt. This DTM based approach is
fine when you are trying to build a system from all "most recent" sources;
but, it fails to deal with the more typical, more complicated cases
involving old versions, variant branches, or multiple targets. Moreover,
MAKE is very "binary" oriented; the user must describe the system in terms
of the object modules that go into it, rather than in terms of the source
modules. MAKE supports a dynamic style of development, in which each user
sees other users' changes as soon as they become available.
The Cedar "system model" allows users to name specific versions of files
(basically by giving the desired creation date). This allows Cedar to
rebuild old systems, and to let individual users build their own versions.
Cedar is source oriented; that is, the model is given in terms of source
modules and the Cedar builder module goes off and searches for the binary,
if any, that corresponds to the requested version of the source. If no
binary is found, Cedar will re-build it from the source. Cedar supports a
cautious style of development in which each user is isolated from other
users' changes until an explicit request to incorporate someone else's
changes is made.
Most of the steps taken to accomplish a task modify elements, but not only
program module elements. For instance, adding an enhancement to a system
may also require updating the system's design specification, user manual,
and on-line "help" files. Some steps may involve off-line activities such
as giving a talk about the enhancement, constructing floppy disks for the
enhanced system and telephoning customers. In short, the software
development process involves much more than just programming. Therefore, a
practical software development enviromment should support more than just
programming.
For more details on CASE systems of others and related matters in general,
the reader is directed to the following publications:
D.B. Leblang, et al.
"Computer-Aided Software Engineering in a Distributed Workstation
Environment"
ACM/SIGPLAN/SIGSOFT Conference on Practical Software Development
Environments, Apr 1984. (Copy filed herewith)
Source Code Control System User's Guide
UNIX System III Programmer's Manual, Oct. 1981.
CMS/MMS: Code/Module Management System Manual
Digital Equip. Corp., 1982.
S. I. Feldman
"Make--A program for Maintaining Computer Programs"
Software Practice and Experience, Apr. 1979.
N. Habermann, et al.
The Second Compendium of Gandalf Documentation
CMU Comp Sci Dept, May 1982
P. Heckel
"A Technique for Isolating Differences Between Files"
CACM, Apr. 1978.
Several Papers
Software Eng. Sym. on High-Level Debugging
ACM/SIGSOFT/SIGPLAN, Aug. 1983.
E. L. Ivie
"The Programmer's Workbench"
CACM, Oct. 1977.
P. Leach, P. Levine, B. Dorous, J. Hamilton, D. Nelson, B. Stumpf
"The Architecture of an Integrated Local Network"
IEEE Journal on Selected Areas in Communications, Nov. 1983.
D. B. Leblang
"Abstract Systax Based Programming Environments",
ACM/AdaTEC Conf. on Ada, Washington D.C., Oct. 1982.
B. Lampson, E. Schmidt
"Organizing Software in a Distributed Environment"
SIGPLAN Jun. 1983.
B. Lampson, E. Schmidt
"Practical Use of a Polymorphic Applicative Language"
10th POPL Conf., Jan. 1983.
L. J. Osterweil, W. R. Cowell
"The TOOLPACK/IST Programming Environment"
IEEE/SOFTFAIR, Jul. 1983.
E. Sandewall
"Programming in an Interactive Environment: The "LISP"Experience"
Computing Surveys, Vol 10, No 1, Mar. 1978.
Collected papers
Tutorial: Software Development Environments
IEEE/COMPSAC-81, Nov. 1981.
"STONEMAN: Requirements for Ada Programming Support Environment"
U.S. Department of Defense, Feb. 1980.
R. Thall
"Large-Scale Software Development with the Ada Language System"
Proc. of ACM Computer Science Conf., Feb. 1983.
W. F. Tichy
"Design, Implementation and Evaluation Of a Revision Control System"
6th Int'l. Conf on Software Eng., Sep. 1982.
T. Teitelbaum
"The Why and Wherefore of the Cornell Program Synthesizer"
SIGPLAN, Jun. 1981.
W. Teitelman, L. Masinter
"The Interlisp programming environment"
Computer, Apr. 1981.
W. Teitelman
"Cedar: An interactive programming environment for a Compiler-Oriented
Language"
LANL/LLNL Conference on Work Stations in Support of Large Scale Computing,
Mar. 1983.
While prior art CASE systems as described above and otherwise have offered
an order of magnitude improvement in the ability to keep track of various
configurations of software systems as they are built and modified, they
all have limitations which prevent them from doing a really first-rate
job. The major drawback is shown in FIG. 2. In basic terms, the problem is
one of a lack of "transparency" and "concurrency" to users in the area of
configuration management. The Master program source codes 14 (i.e., the
basic or first versions of the programs) are maintained in a Master Table
16. Changes by version 18 are maintained in a Versions Table 20. The
various possible versions of a program (or system comprising multiple
programs) are not transparently available to users. Thus, for example as
depicted in FIG. 2, to build a given configuration of a system the System
Builder 22 cannot request in sequence and line by line the versions of the
programs to be used in the system build. Rather, as shown, control must
first be given to a Version Maker 24 along with designators of the version
of programs to be placed in a holding area 26. The Version Maker 24 then
accesses the Master Table 16 to obtain the master program source(s) 14 and
then gets and applies the version changes 18 from the Version Table 20.
The modified program(s) reflecting the designated version(s) is then
placed in the holding area 26. At that time, control is finally
transferred to the System Builder 22, which gets its input from the
holding area 26 from which it "builds" the desired system in the build
area 28. As used throughout this specification, the term "build" is used
to mean all the processes well known to those skilled in the art including
compilation, linking, etc. As can be realized, there are many shortcomings
from such an approach. In addition to the lack of transparency and
inconvenience it causes, there is also a high cost in lost time and space.
Moreover, unless multiple holding area 26 and attendant complex procedures
for their use are provided, there is a lack of concurrency in that only
one version of the system can be built at any one time. Since the System
Builder 22 gets its input stream from the holding area 26 and the build
area 28 is capable of handling one build at a time, any attempt for more
than one user to build a system concurrently will result in failure. If
both attempt to get their source codes into the holding area 26
simultaneously, the result will be an input stream to the System Builder
22 which is a combination of the two--producing an incoherent system to
both users. If one gets his/her source into the holding area 26 first, the
subsequent build of the second could totally overwrite the resultant
system in the build area 28 such that both users would be working with the
system of the second. Of all the drawbacks and limitations of the prior
art systems, this lack of easily used concurrency is probably the most
serious.
Another shortcoming of prior art configuration management systems is the
lack of any capability to track and report progress on tasks or to monitor
and notify of changes in areas critical to others.
Wherefore, it is the object of the present invention to provide a CASE
system providing transparent access to multiple versions, the ability to
build different configurations concurrently without interference, and
additional monitoring and reporting capabilities not found in known CASE
systems.
SUMMARY OF THE INVENTION
The above-described objects have been accomplished by the CASE system of
the present invention comprising computer means for executing
pre-established logic sequences and for reading from and writing to
memory; source code memory means for holding basic source code versions of
system program modules, each comprising a plurality of sequential
statements, and for holding for each module an incremental delta record or
sequence of modifications to the source code of the module each
modification defining a different version of the module and being
identified by a version number; build list means for designating a
sequence of the modules to be used to build a software system; version
list means for designating the version of each of the modules to be used
to build the software system; version designation means for dynamically
designating the version number of a module currently being employed during
the building of the software system; GET statement logic sequence means to
be executed by the computer means for accessing the source code memory
means and for providing on request the next statement in sequence of a
designated system program module according to the version currently
designated by the version designation means; derived object pool memory
means for receiving and holding compiled modules of the software system as
the system is being built; and system build logic sequence means to be
executed by the computer means for obtaining from the build list means and
the version list means a sequence of modules by version numbers to be used
to build a software system, for periodically setting the version
designation means to reflect the version number of a module to be
currently compiled by any compiler supported by the computer means, for
sequentially accessing the GET statement logic sequence means to
sequentially obtain the proper version of the modules on a statement by
statement basis from the source code memory means, and for using the
module statements to build and link the desired systems comprising the
designated modules and versions thereof in the pool memory area.
In the preferred embodiment the system build logic sequence means includes
logic to use the most recent version of a module if no version number is
designated by the version designation means.
The preferred embodiment additionally comprises bound configuration memory
means for holding build histories of built software systems as Historical
Records. The system build logic sequence means, as part of the building of
each system, creates a build history in the bound configuration memory
means comprising a list of the modules and versions employed to build the
system; each build history is identified by a unique Historical Record
identifier. The preferred embodiment additionally comprises build list
designation logic sequence means to be executed by the computer means for
accessing the bound configuration memory means and using a corresponding
one of the Historical Record build histories to set the build list means
and the version list means to designate the version of a module of a
to-be-built system, such designation recreating a prior system from only
the unique History Record identifier.
In the preferred embodiment, the bound configuration memory means includes
a unique identifier for associating each compiled module created by the
compiling of a version of a system module with an entry on the system
build logic sequence; and the system build logic sequence means, as part
of the building of each system, creates a build history in the bound
configuration memory means comprising a list of the system modules and
versions employed to build the system, and the above-described unique
identifier. Additionally, the system build logic sequence means, as part
of the building of each system, checks prior Historical Records for each
entry on the system build logic sequence and utilizes a previously created
compiled module corresponding to an entry rather than utilizing the source
code for the entry to create the compiled module; the previously created
compiled module exists within the pool memory means.
To provide the desired concurrency, the pool memory means is adapted to
have a plurality of systems built within it at one time; and, the system
build logic sequence means is adapted to concurrently employ a plurality
of the build list means and the version list means to build a plurality of
the software systems within the pool memory means simultaneously.
To improve speed of system building, the system build logic sequence means,
as part of the building of each system, checks the Historical Records for
each entry on the current system build logic sequence being used for the
build and utilizes a previously compiled module corresponding to an entry
rather than utilizing the source code for the entry when a compiled module
exists within the pool memory means.
Additionally, the Historical Records include last time used means for
indicating the last times compiled modules have been utilized; and purge
logic sequence means are provided for periodically checking the last time
used means and for purging from the pool memory means the compiled modules
that have not been utilized within a preset period of time.
Additionally the preferred embodiment may have module modification logic
sequence means to be executed by the computer means for modifying modules
in the source code memory means by adding to the incremental delta record
of modifications; monitors associated with selectable modules of the
source code memory means, the monitors designating notifications to be
made when modifications are made to the modules which have been selected
for monitoring; and, module monitoring logic means for establishing module
monitoring information and notification designations of the monitors, for
interfacing with the module modification logic sequence means, and for
making notifications according to the designations of the monitors when a
modification to a respective module being monitored is made.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a simplified drawing of a prior art approach to configuration
management wherein changes after system build are accomplished by patches
to the physical programs which are, in turn, documented through
handwritten notations of the program listing.
FIG. 2 is a simplified block diagram of a prior art, non-transparent
approach to system building where the versions of programs to be used in a
system build are first assembled into a holding area subsequently used as
the input stream for the system build.
FIG. 3 is a simplified block diagram of the basic system of the present
invention wherein the system builder is able to fetch any desired versions
of programs to be used in a system build on a line by line basis as the
system build takes place and, additionally, produce and manage multiple
versions of derived objects.
FIG. 4 is a representation of how multiple threads through different
versions of program modules can be used by different programmers
simultaneously when using the system of the present invention for software
development.
FIG. 5 is a representation how the task monitoring aspect of the present
invention operates.
FIG. 6 is a simplified block diagram showing the additions to the block
diagram of FIG. 3 utilized to provide the monitoring and task reporting
capabilities of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
The novel CASE system of the present invention is incorporated in DSEE (for
DOMAIN Software Engineering Environment) which is a distributed,
production quality, software development environment that runs on
workstations manufactured and sold by the assignee of this application
under the registered trademarks APOLLO and DOMAIN and where the
workstations (or "nodes" ) are designed to operate as part of an
interconnected ring network of multiple nodes. DSEE provides source code
control, configuration management, release control, advice management,
task management, and user-defined dependency tracing with automatic
notification. It incorporates and utilizes the novel features to be
described hereinafter.
DSEE is implemented as one program, with instances running at various nodes
in the network. It is designed to manage large-scale software development
efforts involving engineers, technical writers, managers, and field
support personnel. Since these organizations, and their data, are
typically spread among many locations, DSEE recognizes and supports
distributed development environments. The underlying Apollo DOMAIN
architecture helps by providing network-wide virtual address space,
transparent remote file access, and remote paging. DSEE uses a distributed
database management system (DBMS) to store historical information;
reliable, immutable files to store deltas and tasks; server processes that
watch for asynchronous events; and a store and forward inter-process
communication mechanism which is used in case the network becomes
temporarily partitioned. The DOMAIN system also supports multiple windows,
each of which may run a separate process. Some windows provide general
system commands through a standard shell; others run dedicated
applications like MAIL and CALENDAR. In the DOMAIN system, DSEE runs as a
dedicated window that provides commands for activities directly related to
software development.
A DSEE product goal requires that it work with any language or text
processor; in addition, that users be able to pick any editor. As will be
seen, in order to accomplish its various objects, parts of DSEE were
incorporated into the operating system. Thus, without changes to any
existing tools, the compilers, editors, print spoolers, etc. are all able
to understand DSEE file formats and obey DSEE Configuration Manager
version constraints. This powerful capability distinguishes DSEE from all
of the prior art systems described above under Background of the
Invention.
The heart of the present invention is shown in simplified block form in
FIG. 3. The basic operation and goal thereof will first be described,
after which, a detailed description of the present invention, as
incorporated into the tested CASE system DSEE, will follow.
Being a computer-based system so as to provide the advantages thereof, the
present invention resides in a computer 30 which is adapted to execute
pre-established sequences of logic statements (i.e., programs and/or
firmware) and to read from and write to memory. The central control
resides in the logic of the operating system 32. To achieve the objectives
of the present invention, many of the logic features to be described
hereinafter were incorporated into the operating system 32. The operating
system of many computers provides the "GET FILE" function whereby a
program running under the operating system can get a source file by
requesting it from the operating system. As will be seen hereinafter, the
implementation of the GET function in the operating system 32 of the
present invention provides a unique capability that permits the entire
CASE system to perform in a manner heretofore not possible in the systems
of the prior art.
The system of the present invention contains a source code memory 34
wherein the program listings in source code of the various modules to be
employed in system building are maintained by incremental differences;
that is, the source code memory 34 contains entries 36 for each module by
so-called "interleaved deltas", which permits the identification on a line
by line basis of each statement of a module according to a designated
version on one pass through a source module entry 36.
The system builder logic 22' of the pres | | |
