Method of Programming a Task, Having a Plurality of Processes, Created by a Plurality of Different Programmers, for Operation by a Computer

The present invention relates to a method of creating a program, comprising a plurality of processes, generated by a plurality of different programmers. The present invention also relates to the method of operating such a program.

Object programming is well known in the art. In object programming, objects are created by a program operating under the control of a computer. An object is a data structure having procedures attached to it wherein the data is operated upon by the procedure. Each object has a unique identifier, such as a name, and a location in memory where the object is located. When an object is called or accessed by a process, a message is sent to the object and is executed by the object.

In the prior art, a method of programming a task for operating by a computer has been accomplished by dividing the task into a plurality of processes. The processes are assigned to be programmed by a plurality of different programmers. Each of the processes is defined to contain a plurality of unique objects. However, in the event a certain process ("calling process") requires access to an object which is not located within the addressable memory of the calling process, the programmer for the calling process recreates, i.e. defines, that object within the calling process. This has created several problems. First, as programs evolve and change, identically named objects in different processes, may be different--even though they are supposed to be the same. Secondly, in the event processes with the same named objects are combined, i.e. the boundaries of the processes are removed or changed, this results in a process with two identically named objects in two different locations of memory.

In the present invention a method of programming a task for operation by a computer is disclosed. The task is divided into a plurality of processes. A plurality of unique objects is defined for each process. One or more phantom objects are created in a process for use by that process, wherein upon access by that process, the phantom object communicates with the process having the defined object to cause the defined object to be accessed.

FIG. 1 is the figure of drawing showing the method of the present invention .

Referring to the figure, there is shown a schematic drawing of the method of the present invention. In the present invention, a task 10 to be programmed is shown. The task 10 is to be operated upon by a computer. The task is divided into a plurality of processes 12(a . . . d). Each of the processes 12(a . . . d) is assigned to a different human being programmer to be programmed for execution under the computer.

As is well known in object programming, a plurality of unique objects is defined for each process 12(a . . . d). Thus, for process #1, object #1 and object #2 are uniquely defined. For process #2, object #3, #4, and #5 are uniquely defined for process #2.

In the event the programmer for process #1 wishes to access an object, e.g. object #4 which is uniquely defined in process #2, the programmer creates a phantom object 14'd within process #1. As will be seen, during execution of the process 12a, a phantom object 14'd behaves differently from a conventional object 14a. The phantom object 14'd is linked to the real object 14d through process #2. The phantom object 14'd knows the location in memory of the real object 14d to which it corresponds.

Once the processes 12(a . . . d) have been programmed by the various different programmers, they are executed. In the execution of the different processes, in the event process #1 accesses or calls upon object #1 14a, a message is sent by process #1 to object #1. The object #1 receives that message and executes that message in accordance with the procedure attached thereto.

Similarly, when process #1 accesses phantom object #4 14'd, a message is sent to real object #4 14d. However, unlike the real object 14a, (which is a conventional object) phantom object #4 14'd, instead of executing the message sent from process #1 12a, seeks out process #2 and causes process #2 to access the real object #4 14d in the memory location specified by the phantom object 14'd. When real object #4 14d receives the message from phantom object #4 14'd, real object #4 14d executes that message pursuant to the procedure attached thereto. The result of execution of that message is then transferred back to phantom object #4 14'd back into process #1 and then communicated to process #1.

In the preferred embodiment, the creation of a phantom object 14'd is accomplished by the use of a library routine. Attached herewith as Exhibit A is a listing of a computer program written in the CFlavors language (a library for the C language available from Teknekron Communications Systems, Inc. of Berkeley, Calif.). CFlavors is a C library for the C language that resolves variable names at run time. Although CFlavors library is used, any other object oriented language can be used. These include, but are not limited to, LISP, C, CLOS (Common Lisp Object System).

The computer program set forth on Exhibit A has sections that perform the following functions:

1. These files, client.c and server.c, describe the method of the present invention.

2. In the client.c file, this initializes the communications package.

3. This creates the different classes by the same names.

4. This creates a martian named Charlie, where martian is a type of object and Charlie is one particular object within the martian objects.

5. This registers the method with the phantom library. It allows messages to be carried by the phantom object across the interface boundary between processes.

6. This is the function that is called after the object of martian takes a drink.

7. Since these are no longer needed they are removed.

8. These lines of code evidences some more use of callbacks to look at more of the returned values from the martian object.

9. These lines of code create a water object.

10. This sets the values for the water object.

11. This creates a glass object.

12. This puts the water object in the glass object.

13. This is a callback which is called after the martian object in the "server" process is done.

14. This commences the process.

15. This initializes the communication package.

16. This creates all the classes.

17. This creates a callback. This is executed after cbProvide () is called on line 18.

18. This makes Charlie the first message to the callback.

19. The phantom is made. After it is made, the callback is executed and feed.sub.-- martian is called. The object in the "server" process with the name "Charlie" is found and a phantom object is created for it. It is the phantom object that is used as the second message to the feed.sub.-- martian function. The phantom object could be used later but in this example it is not used again.

There are a number of advantages to the method of the present invention. First and foremost, with the method of the present invention, the uniquely defined objects are never defined more than once. Thus, debugging is greatly facilitated. For example, any change to a uniquely defined object will cause the same change throughout all the different processes created by different programmers. Programmers in other processes which also use the uniquely defined objects need not be concerned with the definition of the object or of any change to the definition. Thus, for example, if real object #4 14d were changed, that change automatically flows to phantom object 14'd and the programming process #1 does not have to be concerned with the changes to the real object #4 14d.

In addition, the method of the present invention has the advantage of being flexible so that the object can be placed in any of the processes without a change in the code. Thus, objects in one process can be moved to another process, across the process boundary, without changes in the code. For example, if process #2 had additional lines of code requiring access to object #4, those lines of code can be moved into process #1 without changing the lines of code because object #4 is also defined in process #1 (albeit, the action of object #4 in its execution is entirely different from object #4 14d in execution in process #2).

Thirdly, the process boundary itself can be moved to maximize efficiency. The boundary for process #2 can be moved to encompass lines of code that were heretofore used in process #1 thereby changing the process boundary to maximize the efficiency of each of the processes. The movement of the process boundaries would require minimal rewriting of the lines of code.

Fourthly, the method of the present invention can be used to exchange data between processes.

Finally, with the method of the present invention, the development process is much easier when many of the separate processes are developed by different programmers. Each of the process can be developed in modular fashion and placed together with minimal changes in lines of code. ##SPC1##