Method of programming a task, having a plurality of processes, created by a plurality of different programmers, for operation by a computer

In the present invention, a method of programming a task by different programmers for operation by computers is disclosed. The task is divided into a plurality of processes with each process being programmed by a different programmer. 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 (calling process), wherein upon access by the calling process, the phantom object communicates with the process (called process) having the defined object associated with the phantom object. The defined object is then accessed by the called process and the result is communicated back to the phantom object to the calling process.

TECHNICAL FIELD 
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. 
BACKGROUND OF THE INVENTION 
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. 
SUMMARY OF THE INVENTION 
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.

DETAILED DESCRIPTION OF THE DRAWINGS 
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##