Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-03-27
2004-03-09
Follansbee, John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06704802
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to operating systems within a computer. More specifically, the present invention relates to a software system in an object-oriented environment for communicating between independent software modules including temporarily-loadable software modules.
2. Description of the Related Art
Software programs are progressively increasing in size and complexity. Accordingly, software systems have evolved into highly complex structures, having applications that exhibit a rich and diverse set of behaviors. For such systems, an individual software developer has great difficulty understanding all subtleties of the system design. Software complexity arises inherently due to the complex problems that software is designed to address, the design flexibility intrinsic to software, the difficulty in managing a software development process and the problems of characterizing the behaviors of a discrete system.
What is needed are disciplined techniques for mastering this complexity.
In addition, this complexity is elevated by the complication that the requirements of a software system often change during development, typically because the very existence of the development project changes the scope of the problems originally addressed. Display and usage of early design products, such as design documents and prototypes, followed by usage of early operational system models, allows system users to understand and articulate the real needs to be addressed by the system. Critical feedback from the users to developers allows the developers to further understand the desired behaviors of the system.
In this manner, a software system becomes an evolving creation, conforming to the changing needs of users. Typically, other system components, such as the hardware systems upon which the software operates, are also evolving so that the software further evolves to adapt to the changing components.
To address the complexity and evolutionary nature of a software system, the system is best addressed as a hierarchic structure having multiple collaborating component parts.
What is further needed is a capability to apportion a software system into these collaborating components and logically organize these components so that multiple programmers can work on the software system at one time. By apportioning the software system into modules, problems of code and data sharing between the modules arises. As software systems continue to increase in complexity, techniques are needed to establish various system characteristics, such as software reliability and maintainability. An extensible system is advantageous to address the evolving nature of system capabilities, both in software and hardware components. A system having independence of modules advantageously promotes reliability, maintainability and extensibility. System efficiency is promoted by program code reuse, data sharing, dynamic loading and unloading of modules, persistent data, and bidirectional communication between system components such as between a parent process and a module.
Various conventional techniques have been attempted to address the problems that arise in complex software systems. These conventional techniques include usage of overlays and, in some environments, dynamic-link libraries (DLL). Neither of these techniques fully addresses the problems arising from software complexity.
The usage of overlays has several shortcomings. An overlay is a portion of a program that is called into memory as needed, overlaying a previous redundant section of the program. Overlays allow usage of programs that are larger than the memory capacity of a computer. When overlays are employed, all components of the program must be run through a linking process to resolve references so that all portions of the program must be present in the computer system at one time during the build process. If separate portions are developed in physically different locations, object modules corresponding to the separate portions must be shipped to a particular location for linking with other modules. Furthermore, some portions of the program may be developed at different times. When a new module is added to the program or if any portion of the program changes, all modules must be relinked. In addition, to maintain coherence between the data structures in the various modules, some modules must be modified to maintain compatibility with other modules. Furthermore, an overlay cannot save data between the different times that the overlay is loaded without resorting to error-prone and hard-to-support techniques.
The dynamic-link library (DLL) approach also has substantial disadvantages. A dynamic-link library is a library of shared functions to which applications link at runtime, as opposed to compile time. A single in-memory copy of the DLL satisfies requests from all calling applications. For example, the DLL technique does not allow for bi-directional communications as the DLL only responds to calls from a calling application. The DLL cannot originate a call to an application. In addition, once the DLL is loaded, the DLL usually remains loaded and therefore occupies valuable memory space. A DLL can allocate memory but cannot automatically reconnect to the allocated memory the next time the DLL is loaded.
SUMMARY OF THE INVENTION
In accordance with the present invention, a software system uses virtual functions to control communication between independent software modules configured in an architecture which includes a parent process and one or more independent child processes. Communication is established by the parent process which creates, loads and unloads both a child process and an object that describes the functions that are accessed by the child process. The parent process creates and loads the child process, then passes a pointer which designates the object to the child process. The child process completes a communication path by creating an object and granting access to the object to the parent process by passing a pointer designating the object to the parent process. A child process is associated to both the object created by the parent process and the object created by the child process and to a virtual table of pointers in each of the objects which designate the objects. The parent process controls memory allocation so that the child process can be unloaded from memory while the objects created by the child process and the virtual table associated to the child process are retained. In this manner, a software module is implemented as a loadable child process which is independent from other software modules.
In accordance with one embodiment of the invention, a method of communicating among independent software modules includes the steps of loading a parent process and, through a generating operation of the parent process, generating a child process. The parent process, through a creating operation, then creates a first object describing a first function that is accessible to the child process and loads, through a loading operation, the child process into a storage. The parent process passes a first pointer which designates a first object to the child process. The child process includes a creating operation that creates a second object that describes a second function that is accessible to the parent process. The child process, using a CALL function, passes a second pointer designating the second object to the parent process.
In accordance with another embodiment of the invention, a computer system has a storage and includes one or more interface modules, one or more system modules, one or more device modules and an application programming interface (API) connected to the one or more interface modules, the one or more system modules and one or more device modules. The API has a parent process which includes a constructor function for creating processes, objects and pointers, a loader function for loading processes and objects from the storage, and an unloader function for unloading processes and obje
Finch Richard W.
Stone Roderick W.
Dell USA LP
Follansbee John
Haynes and Boone LLP
LandOfFree
Method and system for communicating between independent... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for communicating between independent..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for communicating between independent... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3290672