Interface mechanism and method for accessing non-object...

Details Interface mechanism and method for accessing non-object... Interface mechanism and method for accessing non-object...

1998-09-24

2001-01-09

Chaki, Kakali (Department: 2762)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S152000, C707S793000, C707S793000

Reexamination Certificate

active

06173439

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to object oriented programming and more specifically relates to a mechanism and method for storing and retrieving non-object oriented data from within an object oriented framework.
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, such as semiconductors and circuit boards, and software, also known as 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 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.
A central concept in object oriented programming is the “class.” A class is a template that defines a type of object. A class outlines or describes the characteristics or makeup of objects that belong to that class. By defining a class, objects can be created that belong to the class without having to rewrite the entire definition for each new object. This feature of object oriented programming promotes the reusability of existing object definitions and promotes more efficient use of program code.
Many software applications need to operate on data that already exists, and need to store data for later use by another software application. A database is generally used to store persistent data, that is, data that survives beyond the life of a software process that may create, use, or modify the data. Databases are known in the art as persistent storage mechanisms (or simply, persistent stores). One common type of database is a relational database (RDB), which stores data in rows and columns of a table. Each column typically defines an attribute of interest that is stored in the database. Each row typically defines a “record”, which is a single entry in the database that may contain data in each of the attribute fields, or columns. A database manager is typically provided in a relational database to store and retrieve data in the database. The data in a relational database table is referred to as “flat data”, meaning that only the data is stored in the database, and the data does not have corresponding methods that may be invoked to access the data, as would be the case if the data were stored in an object in an object oriented persistent store.
Many computer systems today employ relational databases or other non-object oriented mechanisms for storing persistent data. Many of these computer systems run object-oriented software that needs to access data in non-object oriented persistent datastores. Generally speaking, an interface must be custom-designed to allow an object oriented application to access non-object oriented data in a persistent datastore such as a relational database. This problem is aggravated by the fact that the same data may need to be accessed at different levels in the software application. For example, in an order processing system, we assume the orders and all detail information relating to each order are stored in a persistent store. The quantity of an order item may need to be accessed at different levels in the order processing system (i.e., by different order types or order detail types). For example, the quantity will need to be known to calculate the price, to calculate shipping expenses, to determine whether there is sufficient inventory to satisfy the order, etc. Rather than custom-designing an interface mechanism for each variation (or “type”) of order or order detail in the order process to access the needed data, it would be preferable to provide some type of common interface that could be customized as required for each order type. This approach would be particularly useful in object oriented frameworks.
Frameworks are relatively recent developments in object oriented programming that provide a group of pre-packaged classes and class relationships that are designed to help a user easily extend the framework to write a particular software program, such as a software application. Frameworks typically define certain core functions that cannot be changed by a programmer using the framework, and allow the programmer to extend the framework at defined extension points to generate a custom software application in much less time than coding the software application from scratch. In other words, a programmer could use an order processing framework to generate an order processing software application without having to program the code that represents the core functions of the framework. However, there is no uniform and consistent mechanism for providing access to non-object oriented data from within an object oriented framework, especially when the data needs to be accessed by different types of items in the framework. Without a mechanism for allowing an object oriented framework to access non-object oriented data in a persistent data store by different types of items in the framework, the computer industry will continue to suffer from object oriented frameworks that do not provide the desired power and flexibility, and that require that custom code be written to provide the needed interfaces.
DISCLOSURE OF INVENTION
In an object oriented computer system, an object oriented framework defines an interface mechanism that provides a common interface to a non-object oriented persistent datastore. This common interface can be customized by various types within the framework by effectively hiding attributes on the common interface that are not needed by a particular type. Attributes defined on the common interface may be accessed at any level in the framework through a process of delegation from one level to the next. In addition, one or more of these attributes on the common interface may be defined at various levels, which causes those attributes to be accessed at their respective levels instead of delegating to different levels.
The foregoing and other features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings.


REFERENCES:
patent: 5235701 (1993-08-01), Ohler e

Affiliated with

Also associated with

Rating

Interface mechanism and method for accessing non-object... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Interface mechanism and method for accessing non-object..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interface mechanism and method for accessing non-object... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2491670