Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-06-11
2001-04-24
Chaki, Kakali (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C707S793000, C707S793000
Reexamination Certificate
active
06223344
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to object-oriented programming and more specifically relates to managing version changes in object-oriented environments.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware (e.g., semiconductors, circuit boards, etc.) and software (e.g., computer programs). As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to develop and produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object-oriented programming concepts. The goal of using object-oriented programming is to create small, reusable sections of program code known as “objects” that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved. Closely connected with objects is the concept of “classes” of objects. A class is a formalized definition of a set of like objects. As such, a class can be thought of as an abstraction of the objects or as a definition of a type of object. Each object that is created in an object-oriented system is an instance of a particular class.
Typically, object-oriented application software programs or processes create and use objects to accomplish the required or desired goals of the application software. The objects that accomplish the required tasks for a given software process typically interact with other objects as part of the process. For example, a “client object” is an object that will request a certain service from another object, known as a “server object.” The server object will receive the request from the client object and take appropriate steps to fill the client object's request. These software processes create an object or group of objects and then use those objects during the lifetime of that particular process. In general, at the end of the process which created the object, the object is removed from memory and will cease to exist. However, certain types of objects, called long-lived objects or “persistent” objects, will exist beyond the lifetime of the process that created the object and will be accessible by other, independent processes.
Persistent objects usually contain “persistent” data. Persistent data is any data that must exist beyond the lifetime of the process which created it. Although persistent objects are removed from memory when the process which created them is finished, persistent objects and persistent data may be saved on some secondary storage media and can be reconstructed for use at a later time, if and when the object is needed. Persistent objects can be saved on any of several different types of secondary storage media including hard disks, floppy disks or magnetic tape.
The number of accessible persistent objects is not limited to the number of objects that can be created by one process. As mentioned above, one object that has been created by a first process can call procedures or “methods” on other objects that have been created by other, independent processes. Given that many different processes may create and use persistent objects, the number of persistent objects that are accessible in a given object-oriented environment may grow dramatically over time. The collection of objects containing persistent data maintained by an object-oriented system can easily grow to encompass millions of objects.
While the introduction and implementation of object-oriented programming concepts has been mostly beneficial, the use of object-oriented concepts in client/server environments is not without certain limits and, occasionally, undesirable side effects. For example, as the requirements and functions of a given computer system develop over a period of time, the nature of certain aspects of the computer system may change or gradually evolve. The explanation below illustrates one problem associated with using object-oriented solutions when system requirements change and/or evolve.
Specialized classes of objects are frequently created to store any necessary data that may be required for the system to perform the functions for which it was created. As time passes, the type and quantity of information stored by these specialized objects may need to be changed or enhanced to accommodate additional or different data types. In this case, the definition of the class that defines the object will, of necessity, be changed to support the new object data storage requirements. This scenario typically occurs when a software application is upgraded from a first version to a newer, more powerful version of the software application. The processes and activities associated with modifying, updating, and tracking changes to a class definition over a period of time are known as “versioning.”
Generally, an object version is updated by the simple method of shutting down the application, installing the new version or description of the class, restarting the application, and rebuilding the object instances from the new class description. The objects which belong to the new class become instances of the new class version. This method of updating the version of objects is very straightforward. However, several problems exist when updating the version of a persistent object via this method.
The versioning method described above, which is typically used with regular objects that do not contain persistent data (herein called non-persistent objects), cannot be efficiently applied to systems containing persistent objects. It is simply not practical to modify and rebuild each persistent object when the number of persistent objects may reach into the millions. The time and system overhead required to rebuild all of the objects can be overwhelming.
Further, existing related objects may reference the persistent object. Existing objects typically reference a persistent object using the object identity associated with the persistent object at the time it was created. As previously mentioned, typical versioning methods simply rebuild the new version of the object, which usually involves creating a new object with a new object identity at the time the object is created. However, with persistent objects, the new version of the persistent object must have the same object identity as the original version of the persistent object so that all previously established references to
Gerard Scott Neal
Halter Steven Lester
Munroe Steven J.
Voldal Erik E.
Chaki Kakali
Das Chameli Chaudhuri
Internationl Business Machines Corporation
Schmeiser Olsen & Watts LLP
LandOfFree
Apparatus and method for versioning persistent objects does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for versioning persistent objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for versioning persistent objects will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2484607