Object-oriented system for configuration history management with a project workspace and project history database for draft identification

Having thus described our invention, what we claim, and desire to secure by Letters Patent is:

1. A method for assembling in a project workspace, a version of a program configuration comprising a plurality of software program components, each of said software components being stored in a tree structure and containing member properties including at least one draft identifier identifying a draft of said component as belonging to said program configuration version, comprising the steps of:

A. creating a program component database and storing in the program component database a plurality of program component drafts, each of said program component drafts including a draft identifier identifying said program component draft as being associated with a program configuration version;

B. using information in the project workspace to locate said program component database and send a program component request including a component draft identifier for each component belonging to said program configuration version to said program component database; and

C. retrieving program component drafts from the program component database in response to said program component request using said draft identifier to identify said program component drafts belonging to said program configuration version.

2. A method according to claim 1 wherein step A comprises the step of:

A1. storing a plurality of component drafts for each component belonging to said program configuration version in the program component database; and step C comprises the step of:

C1. selecting one of the plurality of component drafts for program component retrieval.

3. A method according to claim 1 wherein step A comprises the steps of:

A2. creating a first program component database containing at least some of the components;

A3. storing some of the program component drafts associated with the program configuration version in the first component database;

A4. creating a second program component database; and

A5. storing some of the program component drafts associated with the program configuration version in the second program component database.

4. A method according to claim 3 wherein step A comprises the further step of:

A6. adding to the components located in the first program component database information for locating the second program component database.

5. A method according to claim 4 further comprising the steps of:

D. retrieving the information for locating the second program component database from the components in the first program component database; and

E. retrieving program component drafts from the second program component database.

6. A method according to claim 1 wherein the software program components are comprised of a plurality of component kinds and property kinds and wherein the method further comprises the step of:

F. storing the plurality of component kinds and property kinds in the project workspace.

7. A method according to claim 6 further comprising the step of:

G. sending the plurality of component kinds and property kinds from the project workspace to the program component database.

8. A method for assembling in a project workspace, a plurality of software program component drafts comprising a program configuration version over a client server network, the method comprising the steps of:

A. creating a history server;

B. connecting the history server to the network;

C. creating in the history server a program component database for storing a plurality of program component drafts each of the program component drafts including a component ID and a draft ID identifying the program component draft as being associated with a program configuration version;

D. creating a client terminal containing the project workspace, a draft ID associated with the program configuration version and means for locating the history server on the network;

E. connecting the client terminal to the network;

F. sending a program component request from the project workspace to the history server; and

G. retrieving program component drafts from the program component database in response to the program component request using the draft ID to identify program component drafts belonging to the program configuration version.

9. A method according to claim 8 wherein step A comprises the step of:

A1. creating a plurality of history servers;

step B comprises the step of:

B1. connecting each history server to the network; and

step C comprises the steps of:

C1. storing some of the program component drafts belonging to the program configuration version on a first history server;

C2. storing some of the program component drafts belonging to the program configuration on a second history server; and

C3. storing in the component drafts belonging to the program configuration version on the first history server information for locating the second history server on the network.

10. A method according to claim 9 wherein step C1 comprises the steps of:

C1A. storing in the first history server a component containing a list of program component drafts for the component belonging to the program configuration version which are located on the first history server; and

C1B. storing information in the component for locating the second history server on the network.

11. A method according to claim 8 further comprising the step of:

H. displaying a graph of program component drafts.

12. A method according to claim 11 wherein the component comprises a list of program component drafts belonging to the program configuration version and wherein step G comprises the step of:

G1. iterating through the program component draft list in response to the program component request.

13. A method according to claim 8 wherein step D comprises the steps of:

D1. creating in the client terminal a tree structure with branches; and

D2. adding program component drafts retrieved from the history server to the branches.

14. A method according to claim 8 wherein the program component drafts have component properties and component kinds and wherein step D further comprises the step of:

D3. storing the component properties and the component kinds in the client terminal.

15. Apparatus for use on a computer system with a memory, the apparatus assembling in a project workspace, a version of a program configuration comprising a plurality of software program components, each of the software components being stored in a tree structure and containing member properties including at least one draft identifier identifying a draft of the component as belonging to the program configuration version, the apparatus comprising:

a program component database in the memory including a plurality of program component drafts, each of the program component drafts including a draft identifier identifying the program component draft as being associated with a program configuration version;

means responsive to information in the project workspace for locating the program component database and for sending a program component request including a component draft identifier for each component belonging to the program configuration version to the program component database; and

means responsive to the program component request for retrieving program component drafts from the program component database using the draft identifier to identify the program component drafts belonging to the program configuration version.

16. Apparatus according to claim 15 wherein the program component database includes a plurality of component drafts for each component belonging to the program configuration version in the program component database; and retrieving means comprises means for selecting one of the plurality of component drafts for program component retrieval.

17. Apparatus according to claim 15 wherein the program component database comprises:

first program component database containing at least some of the components and some of the program component drafts associated with the program configuration version; and

a second program component database containing some of the program component drafts associated with the program configuration version.

18. Apparatus according to claim 17 wherein the first program component database includes information for locating the second program component database.

19. Apparatus according to claim 18 further comprising:

means for retrieving the information for locating the second program component database from the components in the first program component database; and

means for retrieving program component drafts from the second program component database.

20. A computer program product for use in a computer system having a memory, the computer program product assembling in a project workspace, a version of a program configuration comprising a plurality of software program components, each of the software components being stored in a tree structure and containing member properties including a at least one draft identifier identifying a draft of the component as belonging to the program configuration version, the computer program comprising a computer usable medium having computer readable program code thereon including:

program code for creating a program component database in the memory and program code storing in the program component database a plurality of program component drafts, each of the program component drafts including a draft identifier identifying the program component draft as being associated with a program configuration version;

program code for using information in the project workspace to locate the program component database and send a program component request including a component draft identifier for each component belonging to the program configuration version to the program component database; and

program code for retrieving program component drafts from the program component database in response to the program component request using the draft identifier to identify the program component drafts belonging to the program configuration version.

21. A computer program product according to claim 20 wherein the program code for creating a program component database comprises program code for storing a plurality of component drafts for each component belonging to the program configuration version in the program component database; and wherein the program code for retrieving program component drafts comprises program code for selecting one of the plurality of component drafts for program component retrieval.

22. A computer program product according to claim 20 wherein the program code for creating a program component database comprises:

program code for creating a first program component database containing at least some of the components;

program code for storing some of the program component drafts associated with the program configuration version in the first component database;

program code for creating a second program component database; and

program code for storing some of the program component drafts associated with the program configuration version in the second program component database.

23. A computer program product according to claim 22 wherein the program code for creating a program component database comprises program code for adding to the components located in the first program component database information for locating the second program component database.

24. A computer program product according to claim 23 further comprising:

program code for retrieving the information for locating the second program component database from the components in the first program component database; and

program code for retrieving program component drafts from the second program component database.

Description Submit all comments and votes

COPYRIGHT NOTIFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office. All other rights are expressly reserved.

FIELD OF THE INVENTION

This invention relates generally to improvements in computer systems and, more particularly, to object-oriented software for managing changes, revisions and modifications in software program development projects.

BACKGROUND OF THE INVENTION

The heart of a modern computer system is the software program which controls and coordinates the operation of the hardware components. The series of commands or steps which comprise the program are generally stored in a text file called a source code file. The program statements in the source code file agree generally human-readable and can be composed and edited by the program developer. As will be explained in more detail below, the human-readable source code is converted, or compiled, by another program called a compiler into binary object code which can actually be executed by the hardware.

When computer systems were first developed, both the hardware and the software programs were considerably simpler than they are today. The hardware consisted of a single processor and early software programs were relatively small and compact and generally consisted of a single text file which held the source code.

As both hardware and software became more sophisticated and software development progressed, programs grew in size and complexity. Therefore, it became necessary to break the program into smaller, more easily understood pieces. Breaking the program into pieces also had the advantage that, during program development, each piece of source code could be separately compiled into object code, a process that was much faster than compiling the entire program. Also, due to the complexity and time required to develop reliable software code, techniques were developed that allowed code pieces which were already developed to be reused in different parts of a single program and also between two separate programs.

For example, structured programming techniques were developed where most of the source code was written as separate subroutines and the main program simply calls the subroutines. In many cases it was convenient to store collections of the subroutines in separate files.

With the advent of object-oriented programming, the potential of reusing portions of prewritten code is greatly increased, but the complexity of the programs has increased even further. More particularly, as will hereinafter be described in more detail below, object-oriented programs consist of a collection of inter-related objects. In many modern programming languages each of these objects is typically defined by a header file which contains definitions of the data structures and the subroutines, or methods, which comprise the object. The object further has a source code file which contains the code which implements the methods. In a modern object-oriented program, the number of objects easily climbs into the hundreds and, in some cases, into the thousands. As with structured programs, collections of objects are generally placed in separate files so that a complex program may include hundreds of files.

Since the objects are interrelated, it is common for program files to reference other program files. This interrelation necessitates some type of file management to keep track of the files during compilation. For example, a typical program development sequence is shown in greatly simplified form in FIG. 1.

More particularly, the sequence starts in step 100 and proceeds to step 102 where overall design criteria are established for the software program. Then, in step 104, a program developer composes source code in order to control the computer to meet the design criteria established in step 102. As previously mentioned, the source code may comprise many different files which correspond to classes for creating, menus, icons, bitmaps, text strings, screen layouts and other components of the system.

Next, in step 106, the source code is compiled by a compiler program into object modules. Each separate source file may be compiled separately into a corresponding object module which contains binary code. The separate object modules are linked together in step 108 by means of a linker program to generate an executable program (which can actually be run on a computer). Next, in step 110, the executable program is run and evaluated against the design criteria established in step 102. If, based on the results of the evaluation in step 110, the program is found to meet design criteria in step 112 then the program development is finished (indicated by step 116). However, if the program is found not to meet design criteria, the source code is edited in step 114 and the compilation and linking steps, 106 and 108, are then repeated until the program eventually meets design criteria.

Generally, the editing of the source code in step 114 involves editing of some, but not all of the source code files. However, since some of the files may reference other files, certain source code files may have to be recompiled even if they have not themselves been modified. For example, if a subobject is modified the object file which contains a reference to the subobject may also have to be recompiled in step 106. Thus, it is necessary to keep track of references between files so that different changes or revisions to a file will reflect changes to other related files.

One conventional way to maintain references between source code files is a "project" file. The project file is a simplified database which maintains a list of source code files along with the references between the files and the current state of each file (whether the file has been modified or not). Generally, the file state is maintained by a date and time stamp which is applied to each source code file when the file is modified. When a project file is used, the compilation step takes the form of a project "build" during which all source code files in the project database which need recompiling are sequentially compiled. The project file also contains a date and time stamp for the last build time. The next time the executable program is built, the program development management software compares the time stamp of each source code file to the time stamp saved in the project file during the last program build. Those source codes files which have a time stamp later than the last build date are recompiled before linking.

The project file approach works well for small and medium size projects where only a few people are working on the project at the same time, however, in large projects, the project file approach becomes a bottleneck. In such large projects, there are often program development teams which share objects and other program components within a project and between projects. Accordingly, it is necessary in large projects to have some type of source code control program which can coordinate use of the these objects among projects to insure that the correct version is used during compilation.

Several commercial source code control systems are presently available including RCS, SCCS, and MPW Projector, however, these systems manage current versions of the source code for individual files and are not capable of managing any other additional information that can be used to control the code, for example, extra configuration information. Further these systems cannot provide history information concerning versions of the relationships between files which are useful for comparison and merging purposes.

Accordingly, it is an object of the present invention to provide a program development management system which supports the reliable sharing and reuse of objects and other program components by a program development team.

It is another object of the present invention to provide a program development management system which maintains configuration and revision information and which can store different code versions developed over time.

It is still a further object of the present invention to provide a program development management system which utilizes a distributed database operating over a network.

SUMMARY OF THE INVENTION

The foregoing objects are achieved and the foregoing problems are solved in one illustrative embodiment of the invention in which a distributed program configuration database system is designed for use on a client server network. The system consists of a plurality of program servers which maintain version information for various program components.

A program developer, upon logging into a client terminal on the network, establishes a workspace or project and connects with one of the servers. After connection to the server has been achieved, a draft of the program configuration is retrieved from the server. The configuration draft may include information for constructing some of the program components and "bridge" information identifying other program servers where additional program components are located. The workspace uses the component information to assemble components and the bridge information to connect to other servers and retrieve the remaining components in order to assemble the complete source code for a program in the workspace.

The servers may be shared among projects and store several versions of the code. Methods are provided in the servers to retrieve code versions and to generate code configurations.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified schematic diagram of a program development cycle.

FIG. 2 is a simplified diagram of a prior art client server system on which the present invention can run.

FIG. 3 is a simplified schematic of a personal computer system which can comprise either the client or the server node illustrated in FIG. 2.

FIG. 4 is an illustrative block diagram showing the arrangement of program components within a project and the relationship of the program components to different program history servers.

FIG. 5 is a block schematic diagram of a Project and a Project History Server illustrating the major components of each.

FIG. 6 is a simplified block diagram illustrating the creation of an agent object for performing transactions between a Project workspace and an associated History Server.

FIG. 7 is a flowchart illustrating the steps performed in connecting a Project workspace to an associated History Server.

FIG. 8 is a flowchart illustrating the steps performed during a CreateDraft command.

FIG. 9 is a flowchart of the steps involved in a RetrieveDraft command.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

The Project History Server of the present invention can be implemented in several ways. The simplest implementation is to use a single, centralized database contained in a local server node to hold a complete list of program components for all projects on the system. However, a preferred implementation uses several history servers connected to a network and distributes the program components over these servers. An example of such a distributed system is shown in FIG. 2. FIG. 2 illustrates a computer network arranged in a "client-server" configuration comprising a plurality of client nodes 206, 208, 220, 222 and 228 which may, for example, be workstations, personal computers, minicomputers or other computing devices on which run application programs that communicate over various network links including links 202, 210, 216, 226, 234 and 236 with each other and with server nodes, such as nodes 200, 212, 224, 232 and 238. The server nodes may contain specialized hardware devices and software programs that can provide a service or set of services to all or some of the client nodes. The client nodes are the users of the various network services which, in turn, are provided by the server nodes

Typically, project history databases 204, 213 and 229 are located in several of the server nodes, such as nodes 200, 212 and 232. A client node, such as client node 206, can access one or more of the databases 204, 213, 229 by initializing a project workspace 207 in node 206 and connecting to one of the server nodes which contains an entry associated with that project, such as database 204 in node 200, entering a project identifier or name and retrieving both the program components stored in database 204 and also network addresses of other servers which contain components of the project. The mechanism of initializing a project workspace, connecting to a history server and retrieving component drafts or versions will be discussed in detail below.

Both the client and server portions of the invention are preferably practiced in the context of an operating, s