Systems, Methods and Computer Program Products for Generating and Validating User Defined Object Classes in an Object Oriented Programming Environment After Build Time

This invention relates generally to Object Oriented Programming Systems and methods, and more particularly to the creation and control of object classes and objects in an object oriented programming environment.

In contrast with traditional procedural programming techniques which are not easily adaptable to new procedural requirements and new data types, object oriented programming is a computer programming packaging technique which provides reusable and easily expandable programs. In a traditional procedural program, emphasis is placed on methods to be conducted on particular data sets. By contrast, emphasis is placed on data in an object oriented program.

As is well known to those having skill in the art, object oriented programs are composed of various types of "objects". An object is a data structure, also referred to as a "frame", and a set of operations or functions, also referred to as "methods", for accessing and manipulating the data structure. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as a "class." Objects are instances created from a particular class, and typically do not exist until run-time. Classes, however, are typically fixed at build-time. Each object inherits the data structure and methods of the particular class from which it was instantiated. A hierarchial inheritance relationship exists between multiple classes. For example, one class may be considered a "parent" of another class (the "child" of the parent class). The child class is said to be "derived" from the parent class and inherits all of the attributes and methods of the parent class.

Increasingly, users of vendor-supplied object oriented programs, referred to hereinafter as "base programs", are demanding the ability to customize base programs to fit individual needs. Typically, object oriented programs permit users to create additional object classes from "exemplar" classes provided in the base program. Exemplar classes allow additional object classes to be derived after build-time. However, because these additional object classes are derived after build-time, the base program code, without modification, may not recognize the new object classes and may not be able to handle objects instantiated from them. This is because the base program is bound at build-time and typically requires integration of the user-created object classes and recompiling. Although user code may be able to access and manipulate objects created from these post-build-time classes, it would be desirable to enable the base program to access and manipulate these objects as if the program code had been recompiled.

Presently, program code reintegration and recompiling occurs one of two ways. Either software vendors must have access to the newly-created object classes, or users must have access to the vendor's base program code. Unfortunately, it is typically impractical and inefficient for a user to provide a vendor with a new object class for incorporation into a base program. From the user's standpoint, integration of the object class into the base program is time consuming, expensive, and rather inflexible. From the vendor's standpoint, if many users request integration of new object classes into the base program, the vendor will end up with many different versions of the base program. Future upgrades and modifications will be time consuming and expensive. Furthermore, it is undesirable to provide program code to users because of the risk that the program code will be copied and reused without the consent of the vendor.

It is therefore an object of the present invention to allow users to customize object oriented programs whereby new object classes can be created and utilized in conjunction with the base program without requiring modification to the base program.

It is another object of the present invention to provide the ability to support future maintenance and upgrades to the base program without requiring reintegration of object classes created by users.

It is yet another object of the present invention to provide users with the ability to instantiate and validate new objects generated from a new object class.

These and other objects are accomplished according to the present invention, by systems and methods for generating object classes after build-time, instantiating objects from these object classes, and validating called objects. In particular, the present invention generates a new object class, after build-time, in an object oriented computing environment on a computing platform including first and second object classes arranged in an inheritance hierarchy. The second object class is derived from the first object class, and both the first and second object classes are generated before build-time. Before build-time, the first and second object classes are provided with respective first and second selector identifiers. The first and second object classes are provided with respective first and second class identifiers. The first and second selector identifiers are registered along with respective first and second object class names in a first portion of a registration table linked to the first object class. The first and second class identifiers along with respective first and second object class names are registered in a first subclass table linked to the first object class. The second class identifier along with the second object class name is registered in a second subclass table linked to the second object class. The attributes and methods inherited from the second object class may be modified, and new attributes and methods may be added.

An object class is generated after build-time, according to the present invention, by deriving a third object class having a third subclass table from the second object class. The value of the second object class selector identifier is assigned to a third object class selector identifier. The assigned third object class selector value along with the third object class name is registered in a second portion of the first object class registration table. A unique class identifier is assigned to the third object class. The assigned unique class identifier along with the third object class name is registered in each one of the first, second, and third subclass tables.

An object is instantiated from an object class generated after build-time, according to the present invention, by transmitting, to the first object class, a request to instantiate an object from the third object class coupled with the value of the third object class selector identifier. The second portion of the first object class registration table is searched for the transmitted selector identifier value. An object is instantiated from the object class registered in the registration table having a selector identifier value matching the transmitted selector identifier value.

An object instantiated from an object class generated after build-time is validated, according to the present invention, by transmitting, to the third object class, the value of the class identifier of the third object class. The transmitted class identifier value and associated object class name is searched for in the subclass table of the third object class. The identified object class is requested to verify that its class identifier value matches the class identifier value of the object class requested.

According to another aspect of the present invention, a computer program product is provided to generate object classes after build-time, instantiate objects from these object classes, and validate called objects. A computer usable medium includes computer readable program code embodied in the medium for generating a new object class after build-time in an object oriented computing environment on a computing platform including first and second object classes arranged in an inheritance hierarchy. The second object class is derived from the first object class, and the first and second object classes are generated before build-time. Computer readable program code provides the first and second object classes with respective first and second selector identifiers; provides the first and second object classes with respective first and second class identifiers; registers the first and second selector identifiers along with respective first and second object class names in a first portion of a registration table linked to the first object class; registers the first and second class identifiers along with respective first and second object class names in a first subclass table linked to the first object class; and registers the second class identifier along with the second object class name in a second subclass table linked to the second object class. A computer program product, according to the present invention, further comprises computer readable program code for modifying attributes and methods inherited from the second object class, and for adding new attributes and methods.

A computer program product, according to the present invention, further comprises computer readable program code that derives a third object class having a third subclass table from the second object class; assigns the value of the second object class selector identifier to a third object class selector identifier; registers the assigned third object class selector value along with the third object class name in a second portion of the first object class registration table; assigns a unique class identifier to the third object class; and registers the assigned unique class identifier along with the third object class name in each one of the first, second, and third subclass tables.

A computer program product, according to the present invention, further comprises computer readable program code for instantiating an object from an object class generated after build-time. Computer readable program code: transmits, to the first object class, a request to instantiate an object from the third object class coupled with the value of the third object class selector identifier; searches the second portion of the first object class registration table for the transmitted selector identifier value; and instantiates an object from the object class registered in the registration table with a selector identifier value matching the transmitted selector identifier value.

A computer program product, according to the present invention, further comprises computer readable program code for validating an object instantiated from an object class created after build-time. Computer readable program code: transmits, to the third object class, the value of the class identifier of the third object class; searches for the transmitted value and associated object class name of the class identifier in the subclass table of the third object class; and requests the identified object class to verify that its class identifier value matches the class identifier value of the object class requested.

The present invention is advantageous because the base program code need not be modified to allow users to generate new object classes and objects. Because user-created object classes are called before vendor provided object classes having the same selector identifiers, it is not necessary to recompile the program code to enable the program code to properly handle objects instantiated from object classes generated after build-time. As a result, users obtain a significant degree of flexibility and vendors are not forced into maintaining multiple versions of a base program. Furthermore, vendor-provided updates to the exemplary object classes will not overwrite the user-created object classes. In addition, the present invention avoids system crashes by providing the ability to validate object requests.

FIG. 1 schematically illustrates an object.

FIG. 2 schematically illustrates an example of an object.

FIG. 3 schematically illustrates an example of an inheritance hierarchy in an object oriented computing system. FIG. 3 consists of FIGS. 3A, 3B, 3C, and 3D.

FIG. 4 schematically illustrates a hardware and software environment in which the present invention operates.

Fig. 5 schematically illustrates the main components of an object oriented computing system.

FIG. 6 schematically illustrates an object class hierarchy at build-time, according to the present invention. FIG. 6 consists of FIGS. 6A and 6B.

FIG. 7 schematically illustrates an object class hierarchy at run-time, according to the present invention. FIG. 7 consists of FIGS. 7A and

FIGS. 8-12 are flow charts illustrating pre-build-time programming, run-time user object class generation, run-time user object instantiation, and run-time user object validation, according to the present invention.

The present invention now is described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

A portion of the disclosure of this patent document contains material which is 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 patent file or records, but otherwise reserves all copyright rights whatsoever.

FIG. 1 schematically illustrates an object comprising a data structure and a set of methods for accessing the data structure. The data structure is represented as a frame comprised of many slots, wherein each slot contains an attribute of the object. An attribute may be a primitive, i.e., an integer or a string, or a pointer to another object. A pointer is basically a memory address of a particular object or class. As illustrated, the frame of an object is "encapsulated" by its methods.

The blueprint from which every object is created is known as a class. All the attributes and methods for an object are specified in the class from which the object is created. Every object is referred to as an "instance" of its class. A hierarchial relationship typically exists among object classes. A parent object class often has child classes, or subclasses, related to it. An object subclass inherits all of the data characteristics and methods of its parent object class. In addition, some object oriented programs may permit the addition of attributes and methods to child classes.

FIG. 2 is a schematic illustration of an object class defined as "EMPLOYEE" wherein the data structure relates to employee data, and a number of methods encapsulate the data structure. Each instance, or object, created from this class inherits the particular data structure and encapsulating methods.

FIG. 3 schematically illustrates the inheritance hierarchy among four object classes: "EMPLOYEE", "EXECUTIVE", "MANAGER" and "HOURLY WORKER". The classes "EXECUTIVE", "MANAGER", and "HOURLY WORKER" are each subclasses of the parent class "EMPLOYEE". Each subclass includes an instance for illustrative purposes: "JOE MILLER" is an instance of "HOURLY WORKER"; "BETTY SMITH" is an instance of "MANAGER"; and "JOHN JONES" is an instance of "EXECUTIVE". Each subclass inherits the data structure and methods of the parent class "EMPLOYEE". As shown, attributes and methods can be added to each subclass. "HOURLY WORKER" and "EXECUTIVE" have each added an additional method, and each one of the subclasses has added at least one attribute. As will be described in detail below, the present invention assigns class identifiers and selector identifiers to each object class. Each class contains a subclass table, and the parent class also contains a registration table, as illustrated.

Referring now to FIG. 4, a hardware and software environment in which the present invention operates will now be described. The present invention allows for the creation and control of object classes and objects within an object oriented computing environment 11 operating on one or more computer platforms 12. It will be understood by those having skill in the art that a computer platform 12 typically includes computer hardware units 13 such as a central processing unit (CPU) 14, a main memory 15 and an input/output (I/O) interface 16, and may include peripheral components such as a display terminal 21, an input device 22 such as a keyboard or a mouse, nonvolatile data storage devices 23 such as magnetic or optical disks, printers 24 and other peripheral devices. Computer platform 12 also typically includes microinstruction codes 26 and an operating system 28.

As shown in FIG. 4, an object oriented computing environment 11 operates on computer platform 12. For example, each computer platform 12 may be a computer having an IBM System 370 architecture. However, it will be understood by those having skill in the art that an object oriented computing environment 11 may operate across multiple computer platforms. The operating system 28 may be an IBM multiple virtual storage (MVS) system. An object oriented computing environment 11 is typically written in an object oriented dialect of the C computer programming language, such as C++, or in conventional programming languages such as FORTRAN or COBOL.

The design and operation of computer platforms and object oriented computing programs, including that of an object manager, are well known to those having skill in the art and are described, for example in U.S. Pat. No. 5,161,225 to Abraham et al. entitled Persistent Stream for Processing Time Consuming and Reusable Queries in an Object Oriented Database Management System; U.S. Pat. No. 5,151,987 to Abraham et al. entitled Recovery Objects in an Object Oriented Computing Environment; and U.S. Pat. No. 5,161,223 to Abraham entitled Resumeable Batch Query for Processing Time Consuming Queries in an Object Oriented Database Management System, all assigned to the assignee of the present invention, the disclosures of which are hereby incorporated herein by reference, and in numerous textbooks such as Object Oriented Software Construction by Bertrand Meyer, published by Prentice Hall in 1988, the disclosure of which is incorporated herein by reference.

Referring now to FIG. 5, the main components of an object oriented environment 11 will be described. An object oriented computing environment 11 includes three primary components: a Messenger 51, an Object Management Table 52 and a Loaded Classes Table 53. The Messenger 51 controls communication between calling and called messages, Object Management Table 52 and Loaded Classes Table 53. Object Management Table 52 contains a list of pointers to all active object instances. The Loaded Classes Table 53 contains a list of pointers to all methods of active object classes.

Operation of an object oriented environment 11 will now be described for the example illustrated in FIG. 5, in which Method A (block 54) of an object sends a message to Method B (block 55) of an object. Method A sends a message to Method B by calling Messenger 51. The message contains (1) an object reference of the instance to receive the message, (2) the method the object instance is requested to perform on the data it encapsulates, and (3) any parameters needed by the receiving method. Messenger 51 obtains a pointer to the data frame 56 of the instance object specified by Method A, by searching the Object Management Table 52 for the instance object. If the specified instance object cannot be found, Object Management Table 52 adds the instance object to the table and calls the instance to materialize its data from the database. Once in the instance table, Object Management Table 52 returns the pointer to the materialized instance object.

Messenger 51 then obtains the address of Method B from the Loaded Classes Table 53. If the instance's class is not loaded, the Loaded Classes Table 53 will load it at this time to materialize its data. The Loaded Classes Table 53 searches for the specified method (Method B) and returns the address of the method to Messenger 51.

The Messenger 51 then calls Method B, passing it a system data area and the parameters from the call made by Method A including the pointer. Method B accesses the data frame 56 using the pointer. Method B then returns control to the Messenger 51 which returns control to Method A.

It is often the case that object class hierarchies, as well as the behavior of object classes themselves, evolve over the lifetime of a program. Many systems within which object oriented programs run are not conducive to the implementation of program changes after program code build-time. Traditionally, to modify or add an object class, the base program code had to be recompiled after object class changes or additions were made to the base program. An object oriented programming technique that permits object class change and manipulation without requiring program code recompiling, is known as the "exemplar idiom." See Chapter 8 of Advanced C++ Programming Styles and Idioms, by James O. Coplien, Addison-Wesley Publishing Company, 1992, which is incorporated herein by reference in its entirety.

Using the exemplar idiom, users can take a vendor-supplied object oriented program having an exemplar object class (an object class from which all subclasses are derived) and add new subclasses or modify existing subclasses without the necessity of modifying and recompiling the base program code. In general terms, the exemplar idiom gives object classes the characteristics of objects themselves, thereby permitting the base program to create and modify object classes at run-time rather than at build-time. However, when object classes are modified or replaced, the base program needs some method of recognizing and validating instances created from these object classes. The base program will not be aware of objects created from object classes modified or added after build-time. The present invention provides a solution to the problems presented by object classes generated after build-time.

Referring now to FIG. 6, an object class hierarchy of a base program incorporating the present invention is illustrated. The exemplary base class "EMPLOYEE" includes three subclasses: "HOURLY WORKER", "MANAGER", and "EXECUTIVE". Each one of these subclasses inherits attributes and methods from the base class "EMPLOYEE." At build-time, each class is also assigned a class identifier (class ID) and a selector identifier (selector ID). Each class ID is unique, so that no other class, even among hierarchies within the object oriented program, has the same ID. Each selector ID is unique within the hierarchy only. For example, if multiple hierarchies exist within a program, it is possible that a particular selector ID may be used in each of the hierarchies. However, a particular class ID will never be used more than once within the program.

As shown in FIG. 6, the exemplary object class "EMPLOYEE" also includes a registration table composed of two portions: a vendor class portion and a user class portion. The name of each one of the object classes existing at build-time are included in the vendor class portion of the registration table along with its respective selector ID. In addition, each one of the object classes includes a subclass table. The name of each one of the object classes are included, along with its respective class ID, in its respective subclass table and the subclass tables of all classes above it in the hierarchy. For example, the subclass table within the exemplary class "EMPLOYEE" contains the class ID for itself and each one of the subclasses beneath it in the illustrated hierarchy. The subclass table within the subclass "HOURLY WORKER", for example, includes only the class ID for itself, because there are no subclasses beneath it in the hierarchy.

Referring now to FIG. 7, the addition of a new object class after build-time, according to the present invention, is illustrated. A new subclass "VICE PRESIDENT" has been added as a subclass of the subclass "EXECUTIVE." "VICE PRESIDENT" is assigned a selector ID and a class ID, and the class ID is included within a subclass table therein. Although "VICE PRESIDENT" initially inherited the attributes and methods of "EXECUTIVE", as shown in FIG. 7, "VICE PRESIDENT" now includes only one attribute and no methods from "EXECUTIVE." The method "COMPUTE NEW BONUS" encapsulating the attributes of "VICE PRESIDENT" is a method not found anywhere in the hierarchy.

The selector ID assigned to "VICE PRESIDENT" is the same as the selector ID assigned to "EXECUTIVE." The name of the new subclass and its selector ID have been included within the user class portion of the registration table within the exemplary object class "EMPLOYEE." In addition, the class ID for "VICE PRESIDENT" has been included in the subclass table of each of the classes above it in the hierarchy.

Referring now to FIGS. 8-12, the creation and control of new object classes and objects instantiated therefrom, according to the present invention, will be described in greater detail. The present invention comprises pre-build-time programming (block 100), run-time user object class generation (block 200), run-time user object instantiation (block 300), and run-time user object validation (block 400) (FIG. 8).

Referring now to FIG. 9, pre-build-time programming (block 100) comprises providing selector IDs (block 102), providing class IDs (block 104), registering the selector IDs with the registration table (block 106), and registering class IDs with the subclass tables (block 108). Referring back to FIG. 6, a vendor-provided base program will comprise one or more object class hierarchies. Prior to building the program (compiling the program code, each object class will have been defined with respect to its attributes and methods, and will have been assigned a respective selector ID and class ID. A registration table within the exemplary class will comprise a list of the names and selector IDs of all subclasses beneath the exemplary class. A subclass table within each one of the classes will contain the name and class ID of itself and all classes beneath it in the hierarchy.

Referring now to FIG. 10, run-time user object class generation (block 200) comprises deriving a new object class (block 202), assigning and registering a selector ID (block 204), and assigning and registering a class ID (block 206). Referring back to FIG. 7, run-time user object class generation (block 200) is illustrated by the new subclass "VICE PRESIDENT." In the illustrated embodiment, a user has decided to customize the base program by creating a new object class "VICE PRESIDENT" as a subclass of the vendor-provided class "EMPLOYEE", and as a replacement for the vendor-provided subclass "EXECUTIVE."

Initially, the new class is derived from existing subclass "EXECUTIVE" (block 202). The attributes and methods of "EXECUTIVE" are inherited by "VICE PRESIDENT" and a subclass table is linked therewithin. The selector ID (4 in the illustrated embodiment) of "EXECUTIVE" is assigned to "VICE PRESIDENT" and registered in the user class portion of the registration table within the exemplary class "EMPLOYEE" (block 204). As is discussed in more detail below, by assigning the selector ID of a replaced vendor-provided class to a user-created class, an object oriented program is able to recognize and handle new object classes as if the program code had been modified prior to build-time. The new class is assigned a unique class ID which is then registered (block 206) in the subclass table of the new object class and the subclass tables of all classes above it. As shown in FIG. 7, "VICE PRESIDENT" has been assigned a class ID of 105, and it is registered within the respective subclass tables of "EMPLOYEE", "EXECUTIVE", and "VICE PRESIDENT."

Referring now to FIG. 11, run-time user object instantiation (block 300) comprises the steps of transmitting an instantiation request (block 302), searching the registration table for a matching selector ID (block 304), and instantiating an object (block 306). In a typical object oriented program, the subclasses of a parent class are known at build-time, and a request to instantiate an object from a subclass is understood by the base program. Object classes created after build-time cannot replace the behavior of object classes existing at build-time. According to the present invention, the base program is able to instantiate objects from classes it is not aware of via the registration table which retains the selector IDs for every subclass derived from the exemplar class. All vendor-provided classes, existing at build-time are registered in the vendor class portion of the table. All classes generated after build-time are registered in the user class portion of the table. Upon receiving an instantiation request from a user (block 302), the exemplar class scans the registration table, beginning with the user class portion, looking for a selector ID matching the request (block 304). When a matching selector ID is found, an object is instantiated from the object class having the same name as that linked to the found selector ID (block 306). Consequently, the exemplary class need not know that the requested object class exists. As long as an object class name and a corresponding selector ID is registered with the registration table, the base program can properly handle the instantiation of objects from unknown object classes.

The user class portion of the registration table is always scanned first, thereby ensuring that user-created object classes are called before vendor-provided object classes. For example, assume a user requests an object instantiated from object class "HOURLY WORKER" (FIG. 7). The user class portion of the registration table is scanned for a selector ID having the value of "2" Because no selector ID in the user class portion has the value "2", the vendor class portion of the registration table is then scanned. Since a selector ID having the value "2" exists in the vendor class portion of the registration table, the base program would proceed with instantiating an object from the "HOURLY WORKER" object class.

Assume that a user is not satisfied with the method of computing bonuses, "COMPUTE BONUS," included within the vendor-provided object class "EXECUTIVE." The user decides to generate a new object class entitled "VICE PRESIDENT" comprising a completely different method of calculating the yearly bonus. By registering "VICE PRESIDENT" in the user class portion of the registration table with the same selector ID as "EXECUTIVE," any base program code or user code that attempts to instantiate an "EXECUTIVE" object, will instantiate a "VICE PRESIDENT" object. Any requests to perform "COMPUTE BONUS" on an object will automatically call the new method "COMPUTE NEW BONUS." The base program will recognize only the first selector ID having the value transmitted in an instantiation request (block 302). All other object classes registered with the registration table with the same selector ID will be ignored. As a result, user-created object classes obtain control prior to any vendor-provided object classes having the same selector ID.

Because the present invention allows user-created object classes to effectively replace vendor-provided object classes without modification to the program code, there is a possibility that objects instantiated from object classes will not recognize other objects and vice-versa. The present invention provides a mechanism for validating objects instantiated by user-created object classes. Referring now to FIG. 12, run-time user object validation (block 400) comprises transmitting the class ID of the instantiated object (block 402), searching the object class subclass table for the transmitted class ID (block 404), and requesting the identified object class to verify itself (block 406).

When a user requests the base program to create an object, the class ID of the target object is transmitted to the exemplary class (block 402). The exemplary class searches its subclass table to see if the requested object class ID is registered (block 404). If the class ID is found in the exemplary class subclass table, a pointer is passed to the object class having the name registered with the class ID, and the object class is requested to verify that it is the correct object class (block 406). The program proceeds if the object class is valid, and terminates or returns an error message if not valid.

For example, referring to FIG. 7, assume a user desires to create an object "BILL SMITH" (not shown) from the user-created object class "VICE PRESIDENT" and compute the yearly bonus for "BILL SMITH" using the method "COMPUTE NEW BONUS." The class ID "105" of "VICE PRESIDENT" would be transmitted to the exemplary class with the request to create the object. The exemplary class "EMPLOYEE" would search its subclass table for a class ID having the value "105." Once found, the exemplary class would pass a pointer to the named class registered with the class ID "105" and request it to verify that it is the requested object class. If verified, the object is created. After the object is created, the new method "COMPUTE NEW BONUS" can be performed. If the object is not created, the method is not performed on the object "BILL SMITH" and an error message is returned.

The following is pseudo-code related to an implementation of the present invention. ##SPC1##

In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.