Data processing: software development – installation – and managem – Software upgrading or updating – Plural version management
Reexamination Certificate
1997-08-28
2002-08-27
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software upgrading or updating
Plural version management
C717S166000
Reexamination Certificate
active
06442753
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to object-oriented programming and more specifically relates to an apparatus and method for checking for proper versions of classes in an object-oriented program.
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 revolved 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 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 as it is created. This feature of object-oriented programming promotes the reusability of existing object definitions and promotes more efficient use of program code.
JAVA is the name of one very well-known and popular object-oriented computer programming language which is used to develop software applications. JAVA's popularity stems in part from its relative simplicity and the fact that JAVA is written in a manner that allows different computers (i.e., platforms) to execute the same JAVA code. In other words, JAVA is platform-independent. This feature has caused the use of JAVA to greatly increase with the growing popularity of the Internet, which allows many different type of computer platforms to intercommunicate.
Computer programs naturally evolve over time. The evolution of object-oriented computer programs entails defining new classes that have implementations different than previous versions. A new release of an existing program may use a combination of new classes and classes that were defined in a previous version. The processes and activities associated with modifying, updating, and tracking changes in a class over a period of time are known as “versioning.” When one version of a first class requires a particular version of a second class, this is known as a “dependency”, i.e., that the first class depends on the second class being of the correct version. For a computer program to run properly, it must check to assure that all the dependencies between classes are satisfied.
A specific example will illustrate the concepts of versioning and dependency checking. Assume that a company has been in business for many years and that the nature of the “employee” class that defines employee-related data changed as the information needs of the business developed. Beginning in 1970, the employee class included the name, address, phone number, date of hire, supervisor, and salary for each employee. In 1980 the definition of the employee class was changed to include information regarding 401K plans for the employee, and in 1990 the definition for the employee class was changed again to include information regarding each employee's performance and evaluation reviews. Thus, three different versions of the employee class exist over time.
A 1997 release of the software that includes the employee class will require the 1990 version of the employee class. In other words, one or more classes in the 1997 release of the software will depend on the 1990 version of the employee class being used. This is a dependency that must be enforced if proper program execution is to be assured. If the 1970 or 1980 version of the employee class is used for the 1997 release, improper information will result which will generate errors. For example, if the 1980 version of the class is used, and the 1997 release tries to access an employee's performance review, that information will not be present in the 1980 version of the employee class, so an employee object instantiated as a member of the 1980 employee class will not have data allocated to the performance review information and will not have methods to access that data. As a result, any attempt to access this data will return an error. There exists a need to check all classes to determine whether or not the proper versions of the different classes are being used.
Without a mechanism for checking the dependencies of various versions of classes in an object-oriented program, the computer industry will continue to suffer from inefficient methods of checking new versions of program code.
DISCLOSURE OF INVENTION
According to preferred embodiments of the present invention, a dependency checking apparatus and method allows checking the version of classes in an object-oriented program to assure the proper version is being used for each release of the software. According to a first preferred embodiment, classes themselves include static code that checks dependencies when the class is loaded. The first embodiment is simple to implement for classes. According to a second preferred embodiment, information relating to version checking is stored external to the classes and is used to check dependencies. This second embodiment is more flexible, allowing the checking of interfaces as well as classes, and allows the dependency information to be altered without recompiling the classes being checked.
REFERENCES:
patent: 4558413 (1985-12-01), Schmidt et al.
patent: 5381547 (1995-01-01), Flug et al.
patent: 5404525 (1995-04-01), Endicott et al.
patent: 5421016 (1995-05-01), Conner et al.
patent: 5446899 (1995-08-01), Brett
patent: 5499357 (1996-03-01), Sonty et al.
patent: 5615400 (1997-03-01), Cowsar et al.
patent: 5630138 (1997-05-01), Raman
patent: 5634114 (1997-05-01), Shipley
patent: 5675803 (1997-10-01), Preisler et al.
patent: 5721824 (1998-02-01), Taylor
patent: 5748960 (1998-05-01), Fischer
patent: 5758072 (1998-05-01), Filepp et al.
patent: 5764992 (1998-06-01), Kullick et al.
patent: 5787019 (1998-07-01), Knight et al.
patent: 5805899 (1998-09-01), Evans et al.
patent: 5815705 (1998-09-01), Slivka et al.
patent: 5878256 (1999-03-01), Bealkowski et al.
pat
Gerard Scott Neal
Halter Steven Lester
Munroe Steven J.
Martin Derek P.
Martin & Associates L.L.C.
Morse Gregory
Nguyen-Ba Hoang-Vu Antony
LandOfFree
Apparatus and method for checking dependencies among classes... 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 checking dependencies among classes..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for checking dependencies among classes... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2909908