 |
Description  |
|
|
BACKGROUND OF THE INVENTION
This invention relates to software version management system and method for
handling and maintaining software, e.g. software updating uniformily
across the system, particularly in a large software development
environment having a group of users or programmers. The system is also
referred to as the "System Modeller".
Programs consisting of a large number of modules need to be managed. When
the number of modules making up a software environment and system exceeds
some small, manageable set, a programmer cannot be sure that every new
version of each module in his program will be handled correctly. After
each version is created, it must be compiled and loaded. In a distributed
computing environment, files containing the source text of a module can be
stored in many places in a distributed system. The programmer may have to
save it somewhere so others may use it. Without some automatic tool to
help, the programmer cannot be sure that versions of software being
transferred to another user or programmer are the versions intended to be
used.
A programmer unfamiliar with the composition of the program is more likely
to make mistakes when a simple change is made. Giving this new programmer
a list of the files involved is not sufficient, since he needs to know
where they are stored and which versions are needed. A tool to verify a
list of files, locations and correct versions would help to allow the
program to be built correctly and accurately. A program can be so large
that simply verifying a description is not sufficient, since the
description of the program is so large that it is impractical to maintain
it by hand.
The confusion of a single programmer becomes much worse, and the cost of
mistakes much higher, when many programmers collaborate on a software
project. In multi-person projects, changes to one part of a software
system can have far-reaching effects. There is often confusion about the
number of modules affected and how to rebuild affected pieces. For
example, user-visible changes to heavily-used parts of an operating system
are made very seldom and only at great cost, since other programs that
depend on the old version of the operating system have to be changed to
use the newer version. To change these programs, the "correct" versions of
each have to be found, each has to be modified, tested, and the new
versions installed with the new operating system. Changes of this type
often have to be made quickly because the new system may be useless until
all components have been converted. Members or users of large software
projects are unlikely to make such changes without some automatic support.
The software management problems faced by a programmer when he is
developing software are made worse by the size of the software, the number
of references to modules that must agree in version, and the need for
explicit file movement between computers. For example, a programming
environment and system used at the Palo Alto Research Center of Xerox
Corporation at Palo Alto, Calif., called "Cedar" now has approximately
447,000 lines of Cedar code, and approximately 2000 source and 2000 object
files. Almost all binary or object files refer to other binary or object
files by explicit version stamp. A program will not run until all
references to an binary or object file refer to the same version of that
file. Cedar is too large to store all Cedar software on the file system of
each programmer's machine, so each Cedar programmer has to explicitly
retrieve the versions he needs to run his system from remote storage
facilities or file servers.
Thus, the problem falls in the realm of "Programming-the-Large" wherein the
unit of discourses the software module, instead of
"Programming-in-the-Small", where units include scalor variables,
statements, expressions and the like. See the Article of Frank DeRemer and
H. Kron, "Programming-in-the-Large versus Programming in the small", IEEE
Transactions on Software Engineering, Vol. 2(2), pp. 80-86, June 1976.
To provide solutions solving these problems overviewed above, consider the
following:
1. Languages are provided in which the user can describe his system.
2. Tools are provided for the individual programmer that automate
management of versions of his programs. These tools are used to acquire
the desired versions of files, automatically recompile and load aprogram,
save new versions of software for others to use, and provide useful
information for other program analysis tools such as cross-reference
programs.
3. In a large programming project, software is grouped together as a
release when the versions are all compatible and the programs in the
release run correctly. The languages and tools for the individual
programmer are extended to include information about cross-package
dependencies. The release process is designed so production of release
does not lower the productivity of programmers while the release is
occurring.
To accomplish the foregoing, one must identify the kinds of information
that must be maintained to describe the software systems being developed.
The information needed can be broken down into three categories:
1. File Information: For each version of a system, the versions of each
file in the system must be specified. There must be a way of locating a
copy of each version in a distributed environment. Because the software is
always changing, the file information must be changeable to reflect new
versions as they are created.
2. Compilation Information: All files needed to compile the system must be
identified. It must be possible to compute which files need to be
translated or compiled or loaded and which are already in machine runnable
format. This is called "Dependency Analysis." The compilation information
must also include other parameters of compilation such as compiler
switches or flags that affect the operation of the compiler when it is
run.
3. Interface Information: In languages that require explicit delineation of
interconnections between modules (e.g. Mesa, Ada), there must be means to
express these interconnections.
There has been little research in version control and automatic software
management. Of that, almost none has built on other research in the field.
Despite good reasons for it, e.g. the many differences between program
environments, and the fact that programming environments ususally
emphasize one or two programming languages, so the management systems
available are often closely related to those programming languages, this
fact reinforces the singularity of this research. The following is brief
review of previous work in this area.
(1) Make Program
The Make program, discussed in the Article of Stuart J. Feldman, "Make-A
Program for Maintaining Computer Programs", Software Practice &
Experience, Vol. 9 (4), April, 1979, uses a system description called the
Makefile, which lists an acyclic dependency graph explicitly given by the
programmer. For each node in the dependency graph, the Makefile contains a
Make Rule, which is to be executed to produce a new version of the parent
node if any of the son nodes change.
For example the dependency graph illustrated in FIG. 1 shows that x1.o
depends on x1.c, and the file a.out depends on x1.o and x2.o. The Makefile
that represents this graph is shown in Table I below.
TABLE I
______________________________________
a.out: x1.o x1.o x2.o
______________________________________
cc x1.o x2.o
x1.0: x1.c
cc -c x1.c
x2.o: x2.c
cc -c x2.c
______________________________________
In Table I, the expression, "cc-c x1.c" is the command to execute and
produce a new version of x1.o when x1.c is changed. Make decides to
execute the make rule i.e., compile x1.c, if the file modification time of
x1.c is newer than that of x1.o.
The description mechanism shown in Table I is intuitively easy to use and
explain. The simple notion of dependency, e.g., a file x1.o, that depends
on x1.c must be recompiled if x1.c is newer, works correctly vitually all
the time. The Makefile can also be used as a place to keep useful commands
the programmer might want to execute, e.g.,
print:
pr x1.c x2.c
defines a name "print" that depends on no other files (names). The command
"make print" will print the source files x1.c and x2.c. There is usually
only one Makefile per directory, and, by convention, the software in that
directory is described by the Makefile. This makes it easy to examine
unfamiliar directories simply by reading the Makefile.
Make is an extremely fast and versatile tool that has become very popular
among UNIX users. Unfortunately, Make uses modification times from the
file system to tell which files need to be re-made. These times are easily
changed by accident and are a very crude way of establishing consistency.
Often the programmer omits some of the dependencies in the dependency
graph, sometimes by choice. Thus, even if Make employed a better algorithm
to determine the consistency of a system, the Makefile could still omit
many important files of a system.
(2) Source Code Control System (SCCS)
The Source Code Control System (SCCS) manages versions of C source programs
enforcing a check-in and check-out regimen, controlling access to versions
of programs being changed. For a description of such systems, see the
Articles of Alan L. Glasser, "The Evolution of a Source Code Control
System", Proc. Software Quality & Assurance Workshop, Software Engineering
Notes, Vol. 3(5), pp. 122-125, November 1978; Evan L. Ivie, "The
Programmer's Workbench-A Machine for Software Development", Communications
of the ACM, Vol. 20(10) pp. 746-753, October, 1977; and Marc J. Rochkind
"The Source Code Control System", IEEE Transactions on Software
Engineering, Vol. 1(4), pp. 25-34, April 1981.
A programmer who wants to change a file under SCCS control does so by (1)
gaining exclusive access to the file by issuing a "get" command, (2)
making his changes, and (3) saving his changed version as part of the
SCCS-controlled file by issuing a "delta" command. His changes are called
a "delta" and are identified by a release and level number, e.g., "2.3".
Subsequent users of this file can obtain a version with or without the
changes made as part of "delta 2.3". While the programmer has
"checked-out" the file, no other programmers may store new deltas. Other
programmers may obtain copies of the file for reading, however. SCCS
requires that there be only one modification of a file at a time. There is
much evidence this is a useful restriction in multi-person projects. See
Glasser, Supra. SCCS stores all versions of a file in a special file that
has a name prefixed by "s.". This "s." file represents these deltas as
insertions, modifications, and deletions of lines in the file. Their
representation allows the "get" command to be very fast.
(3) Software Manufacturing Facility (SMF)
Make and SCCS were unified in special tools for a development project at
Bell Labs called the Software Manufacturing Facility (SMF) and discussed
in the Article of Eugene Cristofer, F. A. Wendt and B. C. Wonsiewicz,
"Source Control & Tools=Stable Systems", Proceedings of the Fourth
Computer Software & Applications Conference, pp. 527-532, Oct. 29-31,
1980. The SMF uses Make and SCCS augmented by special files called slists,
which list desired versions of files by their SCCS version number.
A slist may refer to other slists as well as files. In the SMF, a system
consists of a master slist and references to a set of slists that describe
subsystems. Each subsystem may in turn describe other subsystems or files
that are part of the system. The SMF introduces the notion of a consistent
software system: only one version of a file can be present in all slists
that are part of the system. Part of the process of building a system is
checking the consistency.
SMF also requires that each slist refer to at least one Makefile. Building
a system involves (1) obtaining the SCCS versions of each file, as
described in each slists, (2) performing the consistency check, (3)
running the Make program on the version of the Makefile listed in the
slist, and (4) moving files from this slist to an appropriate directory.
FIG. 2 shows an example of a hierarchy of slists, where ab.sl is the
master slist.
SMF includes a database of standard versions for common files such as the
system library. Use of SMF solves the problem created when more than one
programmer is making changes to the software of a system and no one knows
exactly which files are included in the currently executing systems.
(4) PIE Project
The PIE project is an extension to Smalltalk developed at the Palo Alto
Research Center of Xerox Corporation and set forth in the Articles of Ira
P. Goldstein and Daniel G. Bobrow, "A Layered Approach to Software
Design", Xerox PARC Technical Report CSL-80-5, December 1980; Ira P.
Goldstein and Daniel G. Bobrow, "Descriptions for a Programming
Environment", Proceedings of the First Annual Conference of the National
Association of Artificial Intelligence, Stanford, Calif., August 1980; Ira
P. Goldstein and Daniel G. Bobrow, "Representing Design Alternatives",
Proceedings of the Artificial Intelligence and Simulation of Behavior
Conference, Amsterdam, July 1980; and the book "Smalltalk-80, The Language
and It Implemention" by Adele Goldberg and David Robson and published by
Addison-Wesley, 1983. PIE implements a network database of Smalltalk
objects, i.e., data and procedures and more powerful display and usage
primitives. PIE allows users to categorize different versions of a
Smalltalk object into layers, which are typically numbered starting at
zero. A list of these layers, most-preferred layer first, is called a
context. A context is a search path of layers, applied dynamically
whenever an object in the network database is referenced. Among objects of
the same name, the one with the layer number that occurs first in the
context is picked for execution. Whenever the user wants to switch
versions, he or she arranges his context so the desired layer occurs
before any other layers that might apply to his object. The user's context
is used whenever any object is referenced.
The distinction of PIE's solution to the version control problem is the
ease with which it handles the display of and control over versions. PIE
inserts objects or procedures into a network that corresponds to a
traditional hierarchy plus the threads of layers through the network. The
links of the network can be traversed in any order. As a result,
sophisticated analysis tools can examine the logically-related procedures
that are grouped together in what is called a Smalltalk "class". More
often, a PIE browser is used to move through the network. The browser
displays the "categories", comprising a grouping of classes, in one corner
of a display window. Selection of a category displays a list of classes
associated with that category, and so on until a list of procedures is
displayed. By changing the value of a field labeled "Contexts:" the user
can see a complete picture of the system as viewed from each context. This
interactive browsing features makes comparison of different versions of
software very convenient.
(5) Gandalf Project
A project, termed the Gandalf project at Carnegie Mellon University, and
discussed in the Article of A. Nico Habermann et al., "The Second
Compendium of Gandalf Documention", CMU Department of Computer Science,
May 1980, is implementing parts of an integrated software development
environment for the GC language, an extension of the C language. Included
are a syntax-directed editor, a configuration database, and a language for
describing what is called system compositions. See the Articles of A. Nico
Haberman and Dewayne E. Perry "System Compositions and Version Control for
Ada", CMU Computer Science Department, May 1980 and A. Nico Haberman
"Tools for Software System Construction", Proceedings of the Software
Tools Workshop, Boulder, Colo., May 1979. Various Ph.D these have explored
this language for system composition. See the Ph.D Thesis of Lee W.
Cooprider "The Representation of Families of Software Systems", CMU
Computer Science Department, CMU-CS-79-116, Apr. 14, 1979 and Walter F.
Tichy, "Software Development Control Based on System Structure
Description", CMU Computer Science Department, CMU-CS-80-120, January
1980.
Recent work on a System Version Control Environment (SVCE) combines
Gandalf's system composition language with version control over multiple
versions of the same component, as explained in the Article of Gail E.
kaiser and A. Nico Habermann, "An Environment for System Version Control",
in "The Second Compendium of Gandalf Documentation", CMU Department of
Computer Science, Feb. 4, 1982. Parallel versions, which are different
implementations of the same specification, can be specified using the name
of the specific version. There may be serial versions of each component
which are organized in a time-dependent manner. One of the serial
versions, called a revision, may be referenced using an explicit time
stamp. One of these revisions is designated as the "standard" version that
is used when no version is specified.
Descriptions in the System Version Control Language (SVCL) specify which
module versions and revisions to use and is illustrated, in part, in FIG.
3. A collection of logically-related software modules is described by a
box that names the versions and revisions of modules available. Boxes can
include other boxes or modules. A module lists each parallel version and
revision available. Other boxes or modules may refer to each version using
postfix qualifiers on module names. For example, "M" denotes the standard
version of the module whose name is "M," and "M.V1" denote parallel
version V1. Each serial revision can be specified with an "@," e.g.,
"M.V1@2" for revision 2.
Each of these expressions, called pathnames, identifies a specific parallel
version and revision. Pathnames behave like those in the UNIX system: a
path name that begins, for example, /A/B/C refers to box C contained in
box B contained in A. Pathnames without a leading "/" are relative to the
current module. Implementations can be used to specify the modules of a
system, and compositions can be used to group implementations together and
to specify which module to use when several modules provide the same
facilities. These ways of specifying and grouping versions and revisions
alloy virtually any level of binding: the user may choose standard
versions or, if it is important, the user can be very specific about
versions desired. The resulting system can be modified by use of
components that specialize versions for any particular application as
illustrated in FIG. 3.
SVCE also contains facilities for "System Generation". The Gandalf
environment provides a command to make a new instantiation, or executable
system, for an implementation or composition. This command compiles,
links, and loads the constituent modules. The Gandalf editor is used to
edit modules and edit SVCL implementations directly, and the command to
build a new instantiation is given while using the Gandalf editor. Since
the editor has built-in templates for valid SVCL constructs, entering new
implementations and compositions is very easy.
SVCE combines system descriptions with version control, coordinated with a
database of programs. Of the existing systems, this system comes closest
to fulfillng the three previously mentioned requirements: Their file
information is in the database, their recompilation information is
represented as lines in the database between programs and their interface
information is represented by system compositions.
(6) Intermetrics Approach
A system used to maintain a program of over one million lines of Pascal
code is described in an Article of Arra Avakian et al, "The Design of an
Integrated Support Software System", Proceedings of the SIGPLAN '82
Syposium on Compiler Construction, pp. 308-317, June 23-25, 1982. The
program is composed of 1500 separately-compiled components developed by
over 200 technical people on an IBM 370 system. Separately-compiled Pascal
modules communicate through a database, called a compool, of common
symbols and their absolute addresses. Because of its large size (90
megabytes, 42,000 names), a compool is stored as a base tree of objects
plus some incremental revisions. A simple consistency check can be applied
by a link editor to determine that two modules were compiled with
mutually-inconsistent compools, since references to code are stamped with
the time after which the object file had to be recompiled.
Management of a project this size poses huge problems. Many of their
problems were caused by the lack of facilities for separate compilation in
standard Pascal, such as interface-implementation distinctions. The
compool includes all symbols or procedures and variables that are
referenced by modules other than the module in which they are declared.
This giant interface between modules severely restricts changes that
affect more than one separately-compiled module. Such a solution is only
suitable in projects that are tightly managed. Their use of
differential-updates to the compool and creation times to check
consistency makes independent changes by programmers on different machines
possible, since conflicts will ultimately be discovered by the link
editor.
(7) Mesa, C/Mesa and Cedar
Reference is now made to the Cedar/Mesa Environment developed at Palo Alto
Research Center of Xerox Corporation. The software version management
system or system modeller of the instant invention is implemented on this
enviroment. However, it should be clear to those skilled in the art of
organizing software in a distributed environment that the system modeller
may be implemented in other programming systems involving a distributed
environment and is not dependent in principle on the Cedar/Mesa
environment. In other words, the system modeller may handle descriptions
of software systems written in other programming languages. However, since
the system modeller has been implemented in the Cedar/Mesa environment,
sufficient description of this environment is necessary to be familiar
with its characteristics and thus better understand the implementation of
the instant invention. This description appears briefly here and more
specifcally later on.
The Mesa Language is a derivative of Pascal and the Mesa language and
programming is generally disclosed and discussed in the published report
of James G. Mitchell et al, "Mesa Language Manual, Version 5.0", Xerox
PARC Technical Report CSL-79-3, April 1979. Mesa programs can be one of
two kinds: interfaces or definitions and implementations. The code of a
program is in the implementation, and the interface describes the
procedures and types, as in Pascal, that are available to client programs.
These clients reference the procedures in the implementation file by
naming the interface and the procedure name, exactly like record or
structure qualification, e.g., RunTime.GetMemory[] refers to the procedure
GetMemory in the interface RunTime. The Mesa compiler checks the types of
both the parameters and results of procedure calls so that the procedures
in the interfaces are as strongly type-checked as local, private
procedures appearing in a single module.
The interconnections are implemented using records of pointers to procedure
bodies, called interface records. Each client is passed a pointer to an
interface record and accesses the procedures in it by dereferencing once
to get the procedure descriptors, which are an encoded representation
sufficient to call the procedure bodies.
A connection must be made between implementations (or exporters) and
clients (or importers) of interfaces. In Mesa this is done by writing
programs in C/Mesa, a configuration language that was designed to allow
users to express the interconnection between modules, specifying which
interfaces are exported to which importers. With sufficient analysis,
C/Mesa can provide much of the information needed to recompile the system.
However, C/Mesa gives no help with version control since no version
information can appear in C/Mesa configurations.
Using this configuration language, users may express complex
interconnections, which may possibly involve interfaces that have been
renamed to achieve information hiding and flexibility of implementation.
In practice, very few configuration descriptions are anything more than a
list of implementation and client modules, whose interconnections are
resolved using defaulting rules.
A program called the Mesa Binder takes object files and configuration
descriptions and produces a single object file suitable for execution. See
the Article of Hugh C. Lauer and Edwin H. Satterthwaite, "The Impact of
Mesa on System Design", Proceedings of the 4th International Conference on
Software Engineering, pp. 174-182, 1979. Since specific versions of files
cannot be listed in C/Mesa descriptions, the Binder tries to match the
implementations listed in the description with flies of similar names on
the invoker's disk. Each object file is given a 48-bit unique version
stamp, and the imported interfaces of each module must agree in version
stamp. If there is a version conflict, e.g., different versions of an
interface, the Binder gives an error message and stops binding. Most users
have elaborate command files to retrieve what they believe are suitable
versions of files to their local disk.
A Librarian, discussed in the Article of Thomas R. Horsley and William C.
Lynch, "Pilot: A Software Engineering Case Study", Proceedings of the 4th
International Conference on Software Engineering, pp. 94-99, 1979, is
available to help control changes to software in multi-person projects.
Files in a system under its control can be checked out by a programmer.
While a file is checked out by one programmer, no one else is allowed to
check it out until it has been checked in. While it is checked out, others
may read it, but no one else may change it.
In one very large Mesa-language project, which is exemplified in the
Article of Eric Harslem and Leroy E. Nelson, "A Retrospective on the
Development of Star" Proceedings of the 6th International Conference on
Software Engineering, September 1982, programmers submit modules to an
integration service that recompiles all modules in a system quite
frequently. A newly-compiled system is stored on a file system and testing
begins. A team of programmers, whose only duty is to perform integrations
of other programmer's software, fix incompatibilities between modules when
possible. The major disadvantage of this approach is the amount of time
between a change made by the programmer and when the change is tested.
The central concern with this environment is that even experienced
programmers have a problem managing versions of Mesa or Cedar modules. The
lack of a uniform file system, lack of tools to move version-consistent
sets of modules between machines, and lack of complete descriptions of
their systems contribute to the problem.
The first solution developed for version mangement of files is based on
description files, also designated as DF files. The DF system automates
version control for the user or programmer. This version management is
described in more detail later on because experience with it is what led
to the creation of the version management system of the instant invention.
Also, the version management of the instant invention includes some
functionality of the DF system integrated into an automatic program
development system. DF files have information about software versions of
files and their locations. DF files that describe packages of software are
input to a release process. The release process checks the submitted DF
files to see if the programs they describe are made from compatible
versions of software, and, if so, copies the files to a safe location. A
Release Tool performs these checks and copies the files. If errors in DF
files are found and fixed employing an interactive algorithm. Use of the
Release Tool allows one making a release, called a Release Master, to
release software with which he may in part or even to a large extent, not
be familiar with.
SUMMARY OF THE INVENTION
According to this invention, the system modeller provides for automatically
collecting and recompiling updated versions of component software objects
comprising a software program for operation on a plurality of personal
computers coupled together in a distributed software environment via a
local area network. As used herein, the term "objects" generally has
reference to source modules or files, object modules or files and system
models. The component software objects are stored in various different
local and remote storage means throught the environment. The component
software objects are periodically updated, via a system editor, by various
users at their personal computers and then stored in designated storage
means.
The system modeller employes models which are also objects. Each of the
models is representative of the source versions of a particular component
software object and contain object pointers including a unique name of the
object, a unique identifier descriptive of the cronological updating of
its current version, information as to an object's dependencies on other
objects and a pathname representative of the residence storage means of
the object. Means are provided in the system editor to notify the system
modeller when any one of the objects is being edited by a user and the
system modeller is responsive to such notification to track the edited
objects and alter their respective models to the current version thereof.
The system modeller upon command is adapted to retieve and recompile
source files corresponding to altered models and load the binary files of
the altered component software objects and their dependent objects into
the user's computer.
The system modeller also includes accelerator means to cache the object
pointers in the object models that never change to thereby avoid further
retrieving of the objects to parse and to discern the object pointers. The
accelerator means for the models includes (1) an object type table for
caching the unique name of the object and its object type to enhance the
analysis of a model by the modeller, (2) a projection table for caching
the unique name of the source object, names of object parameters, compiler
switches and compiler version to enhance the translation of objects into
derived objects, and (3) a version map for caching the object pathname.
The system modeller is an ideal support system in a distributed software
environment for noting and monitoring new and edited versions of objects
or modules, i.e., source or binary or model files, and automatically
managing the compilation, loading saving of such modules as they are
produced. Further, the system modeller provides a means for organizing and
controlling software and its revision to provide automatic support for
several different kinds of program development cycles in a programming
system. The modeller handles the daily evolution of a single module or a
small group of modules modified by a single person, the assembly of
numerous modules into a large system with complex interconnections, and
the formal release of a programming system. The modeller can also
efficiently locate a large number of modules in a big distributed file
system, and move them from one machine to another to meet operational
requirements or improve performance.
More particularly, the system modeller automatically manages the
compilation, loading and saving of new modules as they are produced. The
system modeller is connected to the system editor and is notified of new
and edited versions of files as they are created by the system editor, and
automatically recompiles and loads new versions of software. The system
user decribes his software in a system model that list the versions of
files used, the information needed to compile the system, and the
interconnections between the various modules. The modeller allows the user
or programmer to maintain three kinds of information stored in system
models. The models, which are similar to a blueprint or schematic,
describe particular versions of a system. A model combines in one place
(1) information about the versions of files needed and hints about their
locations, (2) additional information needed to compile the system, and
(3) information about interconnections between modules, such as which
procedures are used and where they are defined. To provide fast response,
the modeller behaves like an incremental compiler so that only those
software modules that have experienced a change are analyzed and
recompiled.
System models are written in a SML language, which allows complete
descriptions of all interconnections between software modules in the
environment. Since these interconnections can be very complicated, the
language includes defaulting rules that simplify system models in common
situations.
The programmer uses the system modeller to manipulate systems described by
the system models. The system modeller (1) manipulates the versions of
files listed in models (2) tracks changes made by the programmer to files
listed in the models, (3) automatically recompiles and loads the system,
and (4) provides complete support for the release process. The modeller
recompiles new versions of modules and any modules that depend on them.
The advantages of the system modeller is (1) the use of a powerful module
interconnection language that expresses interconnections, (2) the
provision of a user interface that allows interactive use of the modeller
while maintaining an accurate description of the system, and (3) the data
structures and algorithms developed to maintain caches that enable fast
analysis of modules by the modeller. These advantages are further
expandable as follows.
First, the system modeller is easy to use, perform functions quickly and is
to run while the programmer is developing his software and automatically
update system descriptions whenever possible. It is important that a
software version management system be used while the programmer is
developing software so he can get the most benefit from them. When
components are changed, the descriptions are adjusted to refer to the
changed components. Manual updates of descriptions by the programmer would
slow his software development and proper voluntary use of the system seems
unlikely. The system modeller functioning as an incremental compiler, i.e.
only those pieces of the system that are actually change are recompiled,
loaded and saved.
Second, the exemplified computing environment upon which the described
system modeller is utilized is a distributed personal computer environment
with the computers connected over an Ethernet local area network (LAN).
This environment introduces two types of delays in access to versions of
software stored in files: (1) if the file is on a remote machine, it has
to be found, and (2) once found, it has to be retrieved. Since retrieval
time is determined by the speed of file transfer across the network, the
task of retrieving files is circumvented when the information desired
about a file can be computed once and stored in a database. For example,
the size of data needed to compute recompilation information about a
module is small compared to the size of the module's object file.
Recompilation information can be saved in a database stored in a file on
the local disk for fast access. In cases where the file must be retrieved
determining which machine and directory has a copy of the version desired
can be very time consuming. The file servers can deliver information about
versions of files in a remote file server directory at a rate of up to six
versions per second. Since directories can have many hundreds of versions
of files, it is not practical to enumerate the contents of a file server
while looking for a particular version of a file. The solution presented
here depends on the construction of databases for each software package or
system that contains information about file locations.
Third, since many software modules, e.g., Cedar software modules, have a
complicated interconnection structure, the system modeller includes a
description language that can express the interconnection structure
between the modules. These interconnection structures are maintained
automatically for the programmer. When new interconnections between
modules are added by the programmer, the modeller updates the model to add
the interconnection when possible. This means the user has to maintain
these interconnections very seldom. The modeller checks interconnections
listed in models for accuracy by checking the parameterization of modules.
Further advantages, objects and attainments together with a fuller
understanding of the invention will become apparent and appreciated by
referring to the following description and claims taken in conjunction
with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an illustration of a dependency graph for a prior art software
management system.
FIG. 2 is an illustration for a hierarchy of another prior art software
management system.
FIG. 3 is an illustration of the description specifiers of a still another
prior art software management system.
FIG. 4 is an illustration of a Cedar system client and implementor module
dependency.
FIG. 5 is an illustration of a Cedar system source and object file
dependency.
FIG. 6 is an illustration of a dependency graph for a Cedar System.
FIG. 7 is an example of a typical distributed computer evironment.
FIG. 8 is a flow diagram of the steps for making a release in a distributed
computer environment.
FIG. 9 is a dependency graph for DF files in the boot file.
FIG. 10 is a dependency graph illustrative of a detail in the boot file.
FIG. 11 is a dependency graph for interfaces.
FIG. 12 is a dependency graph for files outside the boot file.
FIGS. 13a and 13b illustrate interconnections between implementation and
interface modules.
FIG. 14 illustrates two different versions of a client module.
FIGS. 15a and 15b illustrate a client module to IMPORT different versions
of the module that EXPORTs.
FIG. 16 illustrates a client module with different types of objects.
FIG. 17 is an example of a model.
FIG. 18 are examples of object type and projection tables.
FIG. 19 is an example of a version map.
FIG. 20 is an illustration the user's screen for system modeller in the
Cedar system.
FIG. 21 is a flow diagram illustrating the steps the user takes in
employing the system modeller.
FIG. 22 is a modeller implementation flow diagram illustrating "StartModel"
analysis.
FIG. 23 is a modeller implementation flow diagram illustrating computation
analysis.
FIG. 24 is a modeller implementation flow diagram illustrating loader
analysis.
FIG. 25 illustrates the Move Phase two of the release utilitity.
FIG. 26 illustrates the Build Phase three of the release utility.
FIG. 27 is an example of a version map after release.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
1. The Cedar Environment, DF Software and the Release Process For The Cedar
Environment
One kind of management system of versions of software for a programmer in a
distribution environment is a version control system of modest goals
utilizing DF files. Each programmer lists files that are part of his
system in a description file which is called a DF file.
Each entry in a DF file consists of a file name, its location, and the
version desired. The programmer can use tools to retrieve files listed in
a DF file and to save new versions of files in the location specified in
the DF file. Because recompiling the files in his system can involve use
of other systems, DF files can refer also to other DF files. The
programmer can verify that, for each file in the DF file, the files it
depends on are also listed in the DF file.
DF files are input to a release process that verifies that the
cross-package references in DF files are valid. The dependencies of each
file on other files are checked to make sure all files needed are also
part of the release. The release process copies all files to a place where
they cannot be erroneously destroyed or modified.
The information about file location and file versions in DF files is used
by programs running in the distributed programming environment. Each
programmer has a personal computer on which he develops software. Each
personal computer has its own disk and file system. | | |
