 |
Claims  |
|
|
What is claimed is:
1. An apparatus for enabling an object-oriented application, including
object-oriented statements to access a procedural operating system
including procedural functions saved as executable program logic which are
called to access services provided by said procedural operating system to
facilitate communication with another object-oriented task which is
executing on said procedural operating system, comprising:
(a) a computer;
(b) a memory component in said computer;
(c) a code library, stored in the memory component, comprising:
means for storing said executable program logic in an object-oriented class
library;
object-oriented operating system means for interfacing said object-oriented
application to said procedural operating system utilizing said executable
program logic;
(d) means, in said computer, for processing said object-oriented statements
by executing methods from the class library corresponding to said
object-oriented statements; and
(e) means, in said object-oriented class library including object-oriented,
interprocess communication (IPC) classes for enabling said object-oriented
application to access said procedural operating system services to
communicate with said another object-oriented task during run-time
execution of said object-oriented application in said computer.
2. The apparatus of claim 1, wherein said IPC classes comprise a first
object-oriented class stored in said memory component in said computer
which specifies a first protocol utilized in transmitting messages through
an IPC port to other processes and for receiving messages from other
processes, and a second protocol stored in said memory component in said
computer to create message data.
3. The apparatus of claim 2, wherein said IPC classes comprise a second
object-oriented class stored in said memory component in said computer
inherited from said first class, said second class including methods to
enable the application to access in an object-oriented manner operating
system services to perform IPC operations involving transmission of IPC
messages between processes.
4. The apparatus of claim 3, wherein said IPC classes comprise a third
object-oriented class defining a memory range, wherein an instance of said
third class is transmitted using said methods of said second class.
5. The apparatus of claim 1, wherein said IPC classes comprise a first
object-oriented class which defines a protocol for accessing a port, said
first class including methods to obtain a port name and determine whether
a port is inactive.
6. The apparatus of claim 5, wherein the IPC classes comprise a second
object-oriented class including information inherited from said first
class, said second class defining a port send right wherein instances of
said second class are included in IPC messages sent between processes.
7. The apparatus of claim 1, wherein said IPC classes comprise an
object-oriented class which defines a set of port rights that is
transmitted in IPC messages.
8. An apparatus for providing an object-oriented application including
object-oriented statements an interface to a procedural operating system
including procedural functions salved as executable program logic which
are called to access services provided by said procedural operating
system, comprising:
(a) a computer;
(b) a memory component in the computer;
(c) a code library, stored in the memory component, comprising:
means for storing said executable program logic in an object-oriented class
library;
object-oriented operating system means for interfacing said object-oriented
application to said procedural operating system by executing said
executable program logic from said object-oriented class library which
corresponds to said object-oriented statements; and
(d) said object-oriented operating system means, in said object-oriented
code library including interprocess communication (IPC) classes for
enabling the application to access said procedural operating system IPC
services to communicate with other processes during run-time execution of
the application in the computer.
9. The apparatus of claim 8, wherein the IPC classes comprise
object-oriented classes having methods to enable the application to access
operating system services to perform message dispatching and to wait to
receive messages from multiple message sources.
10. An apparatus for enabling an object-oriented application including
object-oriented statements to access a procedural operating system
utilizing procedural functions saved as executable program logic,
comprising:
(a) a computer;
(b) a memory component in said computer; and
(c) a code library, stored in said memory component, comprising:
means for storing said executable program logic in an object-oriented class
library;
object-oriented operating system means for interfacing said object-oriented
application to said procedural operating system by executing said
executable program logic from said object-oriented class library which
corresponds to said object-oriented statements;
wherein said executable program logic is insertable into said application
to enable said application to access said operating system IPC services
during run-time execution of said application in said computer.
11. The apparatus of claim 10, wherein the IPC classes comprise a first
object-oriented class stored in said memory component in said computer
which specifies a first protocol utilized in transmitting messages through
an IPC port to other processes and for receiving messages from other
processes, and a second protocol stored in said memory component in said
computer to create message data.
12. The apparatus of claim 11, wherein said IPC classes comprise a second
object-oriented class stored in said memory component in said computer
inherited from said first class, said second class including methods to
enable the application to access operating system services to perform IPC
operations involving transmission of IPC messages between processes.
13. The apparatus of claim 12, wherein said IPC classes comprise a third
object-oriented class defining a memory range, wherein an instance of said
third class is required to be included in each of said IPC messages
transmitted using said methods of said second class.
14. The apparatus of claim 13, wherein said IPC classes comprise a first
object-oriented class which defines a protocol for accessing a port, said
first class including methods to obtain a port name, and determine whether
a port is inactive.
15. The apparatus of claim 14, wherein the IPC classes comprise a second
object-oriented class including information inherited from said first
class, said second class defining a port send right wherein instances of
said second class are included in IPC messages sent between processes.
16. The apparatus of claim 10, wherein said IPC classes comprise an
object-oriented class which defines a set of port rights that is
transmitted in IPC messages.
17. A method for providing an object-oriented application including
object-oriented statements an interface to a procedural operating system
residing on a computer with a memory component in the computer and a code
library stored in the memory component, comprising the steps of:
(a) implementing an object-oriented class library, said object-oriented
class library comprising object-oriented, interprocess communication (IPC)
classes;
(b) communicating via said IPC with other processes during run-time
execution of said object-oriented application in said computer, said
object-oriented classes comprising methods for accessing said operating
system IPC services using procedural function calls to access said
procedural operating system; and
(c) inserting said methods from said object-oriented class library
corresponding to said object-oriented statements into said object-oriented
application to enable said object-oriented application to access said
procedural operating system IPC services during run-time execution of said
object-oriented application in said computer. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
A portion of the disclosure of this patent application contains material
which is subject to copyright protection. The copyright owner has no
objection to the facsimile reproduction by anyone of the patent
disclosure, as it appears in the Patent and Trademark Office patent files
or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTION
The present invention relates generally to object-oriented computing
environments, and more particularly to a system and method for providing
an object-oriented interface for a procedural operating system. An
object-oriented interprocess communication system is employed to enhance
communication between tasks.
BACKGROUND OF THE INVENTION
Object-oriented technology (OOT), which generally includes object-oriented
analysis (OOA), object-oriented design (OOD), and object-oriented
programming (OOP), is earning its place as one of the most important new
technologies in software development. OOT has already begun to prove its
ability to create significant increases in programmer productivity and in
program maintainability. By engendering an environment in which data and
the procedures that operate on the data are combined into packages called
objects, and by adopting a rule that demands that objects communicate with
one another only through well-defined messaging paths, OOT removes much of
the complexity of traditional, procedure-oriented programming.
The following paragraphs present a brief overview of some of the more
important aspects of OOT. More detailed discussions of OOT are available
in many publicly available documents, including Object Oriented Design
With Applications by Grady Booch (Benjamin/Cummings Publishing Company,
1991) and Object-Oriented Requirements Analysis and Logical Design by
Donald G. Firesmith (John Wiley & Sons, Inc., 1993). The basic component
of OOT is the object. An object includes, and is characterized by, a set
of data (also called attributes) and a set of operations (called methods)
that can operate on the data. Generally, an object's data may change only
through the operation of the object's methods.
A method in an object is invoked by passing a message to the object (this
process is called message passing). The message specifies a method name
and an argument list. When the object receives the message, code
associated with the named method is executed with the formal parameters of
the method bound to the corresponding values in the argument list. Methods
and message passing in OOT are analogous to procedures and procedure calls
in procedure-oriented software environments. However, while procedures
operate to modify and return passed parameters, methods operate to modify
the internal state of the associated objects (by modifying the data
contained therein). The combination of data and methods in objects is
called encapsulation. Perhaps the greatest single benefit of encapsulation
is the fact that the state of any object can only be changed by
well-defined methods associated with that object. When the behavior of an
object is confined to such well-defined locations and interfaces, changes
(that is, code modifications) in the object will have minimal impact on
the other objects and elements in the system. A second "fringe benefit" of
good encapsulation in object-oriented design and programming is that the
resulting code is more modular and maintainable than code written using
more traditional techniques.
The fact that objects are encapsulated produces another important fringe
benefit that is sometimes referred to as data abstraction. Abstraction is
the process by which complex ideas and structures are made more
understandable by the removal of detail and the generalization of their
behavior. From a software perspective, abstraction is in many ways the
antithesis of hard-coding. Consider a software windowing example: if every
detail of every window that appears on a user's screen in a graphical user
interface (GUI)-based program had to have all of its state and behavior
hard-coded into a program, then both the program and the windows it
contains would lose almost all of their flexibility. By abstracting the
concept of a window into a window object, object-oriented systems permit
the programmer to think only about the specific aspects that make a
particular window unique. Behavior shared by all windows, such as the
ability to be dragged and moved, can be shared by all window objects.
This leads to another basic component of OOT, which is the class. A class
includes a set of data attributes plus a set of allowable operations (that
is, methods) on the data attributes. Each object is an instance of some
class. As a natural outgrowth of encapsulation and abstraction, OOT
supports inheritance. A class (called a subclass) may be derived from
another class (called a base class, a parent class, etc.) wherein the
subclass inherits the data attributes and methods of the base class. The
subclass may specialize the base class by adding code which overrides the
data and/or methods of the base class, or which adds new data attributes
and methods. Thus, inheritance represents a mechanism by which
abstractions are made increasingly concrete as subclasses are created for
greater levels of specialization. Inheritance is a primary contributor to
the increased programmer efficiency provided by OOP. Inheritance makes it
possible for developers to minimize the amount of new code they have to
write to create applications. By providing a significant portion of the
functionality needed for a particular task, classes in the inheritance
hierarchy give the programmer a head start to program design and creation.
One potential drawback to an object-oriented environment lies in the
proliferation of objects that must exhibit behavior which is similar and
which one would like to use as a single message name to describe.
Consider, for example, an object-oriented graphical environment: if a Draw
message is sent to a Rectangle object, the Rectangle object responds by
drawing a shape with four sides. A Triangle object, on the other hand,
responds by drawing a shape with three sides. Ideally, the object that
sends the Draw message remains unaware of either the type of object to
which the message is addressed or of how that object that receives the
message will draw itself in response. If this ideal can be achieved, then
it will be relatively simple to add a new kind of shape later (for
example, a hexagon) and leave the code sending the Draw message completely
unchanged.
In conventional procedure-oriented languages, such a linguistic approach
would wreak havoc. In OOT environments, the concept of polymorphism
enables this to be done with impunity. As one consequence, methods can be
written that generically tell other objects to do something without
requiring the sending object to have any knowledge at all about the way
the receiving object will understand the message. Software programs, be
they object-oriented, procedure-oriented, rule based, etc., almost always
interact with the operating system to access the services provided by the
operating system. For example, a software program may interact with the
operating system in order to access data in memory, to receive information
relating to processor faults, to communicate with other processes, or to
schedule the execution of a process.
Most conventional operating systems are procedure-oriented and include
native procedural interfaces. Consequently, the services provided by these
operating systems can only be accessed by using the procedures defined by
their respective procedural interfaces. If a program needs to access a
service provided by one of these procedural operating systems, then the
program must include a statement to make the appropriate operating system
procedure call. This is the case, whether the software program is
object-oriented, procedure-oriented, rule based, etc. Thus, conventional
operating systems provide procedure-oriented environments in which to
develop and execute software. Some of the advantages of OOT are lost when
an object-oriented program is developed and executed in a
procedure-oriented environment. This is true, since all accesses to the
procedural operating system must be implemented using procedure calls
defined by the operating system's native procedural interface.
Consequently, some of the modularity, maintainability, and reusability
advantages associated with object-oriented programs are lost since it is
not possible to utilize classes, objects, and other OOT features to their
fullest extent possible.
One solution to this problem is to develop object-oriented operating
systems having native object-oriented interfaces. While this ultimately
may be the best solution, it currently is not a practical solution since
the resources required to modify all of the major, procedural operating
systems would be enormous. Also, such a modification of these procedural
operating systems would render useless thousands of procedure-oriented
software programs. Therefore, what is needed is a mechanism for enabling
an object-oriented application to interact in an object-oriented manner
with a procedural operating system having a native procedural interface.
SUMMARY OF THE INVENTION
The present invention is directed to a system and method of enabling an
object-oriented application to access in an object-oriented manner a
procedural operating system having a native procedural interface. The
system includes a computer and a memory component in the computer. A code
library is stored in the memory component. The code library includes
computer program logic implementing an object-oriented class library. The
object-oriented class library comprises related object-oriented classes
for enabling the application to access in an object-oriented manner
services provided by the operating system. The object-oriented classes
include methods for accessing the operating system services using
procedural function calls compatible with the native procedural interface
of the operating system. The system also includes means for processing
object-oriented statements contained in the application and defined by the
class library by executing methods from the class library corresponding to
the object-oriented statements.
Preferably, the class library includes:
(1) thread classes for enabling an application to access in an
object-oriented manner operating system services to Spawn, control, and
obtain information relating to threads;
(2) task classes for enabling an application to access in an
object-oriented manner operating system services to reference and control
tasks, wherein the tasks each represents an execution environment for
threads respectively associated with the tasks;
(3) virtual memory classes for enabling an application to access in an
object-oriented manner operating system services to access and manipulate
virtual memory in a computer;
(4) interprocess communication (IPC) classes for enabling an application to
access in an object-oriented manner operating system services to
communicate with other threads during run-time execution of the
application in a computer;
(5) synchronization classes for enabling an application to access in an
object-oriented manner operating system services to synchronize execution
of threads;
(6) scheduling classes for enabling an application to access in an
object-oriented manner operating system services to schedule execution of
threads;
(7) fault classes for enabling an application to access in an
object-oriented manner operating system services to process system and
user-defined processor faults; and
(8) machine classes for enabling an application to access in an
object-oriented manner operating system services to define and modify a
host and processor sets.
Further features and advantages of the present invention, as well as the
structure and operation of various embodiments of the present invention,
are described in detail below with reference to the accompanying drawings,
and in the claims. In the drawings, identical reference numbers indicate
identical or functionally similar elements. An object-oriented
interprocess communication system is employed to enhance communication
between tasks.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be described with reference to the accompanying
drawings, wherein:
FIG. 1 illustrates a block diagram of a computer platform in which a
wrapper of the present invention operates;
FIG. 2 is a high-level flow chart illustrating the operation of the present
invention;
FIG. 3 is a more detailed flowchart illustrating the operation of the
present invention;
FIG. 4 is a block diagram of a code library containing an object-oriented
class library of the present invention;
FIG. 5 is a class diagram of thread and task classes of the present
invention;
FIG. 6 is a class diagram of virtual memory classes of the present
invention;
FIGS. 7-9 are class diagrams of interprocess communication classes of the
present invention;
FIG. 10 is a class diagram of synchronization classes of the present
invention;
FIG. 11 is a class diagram of scheduling classes of the present invention;
FIGS. 12-15 are class diagrams of fault classes of the present invention;
FIG. 16 is a class diagram of host and processor set (machine) classes of
the present invention; and
FIG. 17 illustrates well-known icons for representing class relationships
and cardinality in class diagrams.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Computing Environment
The present invention is directed to a system and method for providing an
object-oriented interface to a procedural operating system having a native
procedural interface. The present invention emulates an object-oriented
software environment on a computer platform having a procedural operating
system. More particularly, the present invention is directed to a system
and method of enabling an object-oriented application to access in an
object-oriented manner a procedural operating system having a native
procedural interface during run-time execution of the application in a
computer. The present invention is preferably a part of the run-time
environment of the computer in which the application executes. In this
patent application, the present invention is sometimes called an
object-oriented wrapper since it operates to wrap a procedural operating
system with an object-oriented software layer such that an object-oriented
application can access the operating system in an object-oriented manner.
FIG. 1 illustrates a block diagram of a computer platform 102 in which a
wrapper 128, 129 of the present invention operates. It should be noted
that the present invention alternatively encompasses the wrapper 128, 129
in combination with the computer platform 102. The computer platform 102
includes hardware components 103, such as a random access memory (RAM) 108
and a central processing unit (CPU) 106. It should be noted that the CPU
106 may represent a single processor, but preferably represents multiple
processors operating in parallel. The computer platform 102 also includes
peripheral devices which are connected to the hardware components 103.
These peripheral devices include an input device or devices (such as a
keyboard, a mouse, a light pen, etc.), a data storage device 120 (such as
a hard disk or floppy disk), a display 124, and a printer 126. The data
storage device 120 may interact with a removable data storage medium 122
(such as a removable hard disk, a magnetic tape cartridge, or a floppy
disk), depending on the type of data storage device used. The computer
platform 102 also includes a procedural operating system 114 having a
native procedural interface (not shown). The procedural interface includes
procedural functions which are called to access services provided by the
operating system 102.
The computer platform 102 further includes device drivers 116, and may
include microinstruction code 210 (also called firmware). As indicated in
FIG. 1, in performing their required functions the device drivers 116 may
interact with the operating system 114. Application programs 130, 132, 134
(described further below) preferably interact with the device drivers 116
via the operating system 114, but may alternatively interact directly with
the device drivers 116. It should be noted that the operating system 114
may represent a substantially full-function operating system, such as the
Disk Operating System (DOS) and the UNIX operating system. However, the
operating system 114 may represent other types of operating systems. For
purposes of the present invention, the only requirement is that the
operating system 114 be a procedural operating system having a native
procedural interface. Preferably, the operating system 114 represents a
limited functionality procedural operating system, such as the Mach
micro-kernel developed by CMU, which is well-known to those skilled in the
relevant art. For illustrative purposes only, the present invention shall
be described herein with reference to the Mach micro-kernel. In a
preferred embodiment of the present invention, the computer platform 102
is an International Business Machines (IBM) computer or an IBM-compatible
computer. In an alternate embodiment of the present invention, the
computer platform 102 is an Apple computer.
Overview of a Wrapper
Various application programs 130, 132, 134 preferably operate in parallel
on the computer platform 102. Preferably, the application programs 130,
132, 134 are adapted to execute in different operating environments. For
example, the application programs 130A and 130B may be adapted to operate
in an object-oriented environment. The application program 132 may be
adapted to operate in a Microsoft Windows environment, an IBM PS/2
environment, or a Unix environment. As will be appreciated by those
skilled in the relevant art, the application programs 130A, 130B, and 132
cannot interact directly with the operating system 114 unless the
operating system 114 implements an environment in which the application
programs 130A, 130B, and 132 are adapted to operate. For example, if the
application 132 is adapted to operate in the IBM PS/2 environment, then
the application 132 cannot directly interact with the operating system 114
unless the operating system 114 is the IBM PS/2 operating system (or
compatible). If the application programs 130A and 130B are adapted to
operate in an object-oriented environment, then the applications 130A,
130B cannot directly interact with the operating system 114 since the
operating system 114 has a procedural interface. In the example shown in
FIG. 1, the application 134 is adapted to operate in the computing
environment created by the operating system 114, and therefore the
application 134 is shown as being connected directly to the operating
system 114.
The wrapper 128 is directed to a mechanism for providing the operating
system 114 with an object-oriented interface. The wrapper 128 enables the
object-oriented applications 130A, 130B to directly access in an
object-oriented manner the procedural operating system 114 during run-time
execution of the applications 130A, 130B on the computer platform 102. The
wrapper 129 is conceptually similar to the wrapper 128. The wrapper 129
provides an IBM PS/2 interface for the operating system 114, such that the
application 132 can directly access in a PS/2 manner the procedural
operating system 114 (assuming that the application 132 is adapted to
operate in the IBM PS/2 environment). The discussion of the present
invention shall be limited herein to the wrapper 128, which provides an
object-oriented interface to a procedural operating system having a native
| | |
