Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-10-14
2001-05-01
Chaki, Kakali (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C707S793000, C717S152000
Reexamination Certificate
active
06226792
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to an improved object management system for tracking, cataloging, and managing data and code components; and, more specifically, to an object management system that stores objects within a technology domain for modeling the data and code components, and objects within an application domain for modeling application-related concepts, and that further includes object relationships that map objects from the application domain to objects within the technology domain for use in cataloging reusable code and data components.
2. Description of the Prior Art
Many of today's software solutions are being designed using an object-oriented approach. According to this methodology, a design is broken into code components wherein each component is tailored to perform a discrete function on any data to which it is passed. If each component is designed to accomplish the function in a generalized, versus a task-specific, way, the components may potentially be reused to solve a different task. Using this type of approach, a large library of components can be developed which may be mixed and matched to solve a variety of problems.
Using object-oriented design methodology, each reusable code or data component has predefined interfaces or relationships to other components. As a simple example, consider a program component that includes instructions that reference data in a table. The program component might be described as having a relationship to the table component of “references”. Within a large complex system, thousands of components and component relationships may be defined. Managing these components becomes a daunting task. For more information on object-oriented design methodology and the problems associated with component management, see “Object-Oriented System Development” by Dennis de Champeaux, Douglas Lea, and Penelope Faure, published by Addison Wesley, 1993.
Well-organized management of components and component relationships is essential if reuse of constructs is to be practical. This can be understood by considering a variety of situations in which groups of components must be identified. For example, assume a user makes a new version of a code component. Changes made to the code component may require that further modifications be made to related code components so that compatibility is maintained. Some method of identifying the related code components is needed. Preferably, this method of identification can be automated. Another related example involves the modification of a data component. For example, assume a component of the type “TableColumn”, which is a column of a table, is deleted. This deletion will affect any table that includes the column, and will further affect any code component that references the affected tables. Again, some method is needed of easily identifying the affected components before the change is made and incompatibility results.
Another situation requiring the tracking of components and component relationships involves the porting of solutions to a new environment. Because computer technology is rapidly evolving, it often becomes desirable to transport a software solution from a first data processing platform to a second data processing platform to leverage the existing knowledge base. This type of “transformation” operation may require re-implementation of a portion of the existing code components into a different coding language, or may involve creating additional layers of code called “wrappers” to bridge the existing code interfaces to the new platform architecture. To make this type of porting operation more expedient, all code and data components associated with the targeted solution must be easily identifiable.
Still another example of a situation necessitating component tracking involves renovation operations. These types of operations involve updating code and data components to accommodate changing requirements. A good illustration of this type of operation involves updating code components to correctly handle dates occurring after Dec. 31, 1999. Another type of renovation effort is needed to allow software to handle the European Monetary Unit (EMU), or “Euro”, which will become the common currency within many European countries within the next few years. Still other types of conversion are necessary when porting software between two machines that do not use the same word sizes. Software modification is further required when porting code to a machine having an expanded addressing space. These types of renovation efforts are generally performed on an identified solution, making it necessary to track all code and data components associated with a given solution.
The above-described objectives can be accomplished by tracking the various relationships existing between the components. As discussed above, object-based systems generally record relationships describing how code or data components of a particular type correlates to other components. For example, a code component may be said to “reference” a table component, or a table component may be said to “include” a column component. As another example, multiple code components may be “included” within part of a larger transaction management component. These types of relationships are described in terms of what the two related components are (e.g., a code module and a table.) It may be said these relationships, which are described in terms of software and data constructs and principles, are part of a “technology domain”. That is, these mappings model software technologies as objects and object relationships.
Although the relationships existing within a technology domain may be adequate to identify groups of components for purposes such as those described above, other situations require a different knowledge base. To illustrate, assume a new development effort is initiated to design a particular application. It may often be desirable to identify existing components that are related to that effort so that some of these components can potentially be reused to create the new solution. For example, assume a new transaction management system is being developed to handle debit cards issued by a bank. It is useful to determine which code and data components are already in existence to handle banking transactions. To this end, it is helpful to track components based on the type of applications with which they are associated. This may be described as providing a mapping of components to applications within an “application domain”. Thus, for example, a particular component may be mapped to the application “banking”, or perhaps, more specifically, to “mortgages”. The application mappings may then be used as a subject matter index when locating components.
While prior art object management systems may provide some type of a tracking mechanism related to application domain mappings, this mechanism is not related to, or interconnected with, a technology domain mapping As a result, two sets of mappings must be consulted when attempting to identify a set of components for a given purpose. For example, consider the case in which all banking applications are to be migrated from a first data processing platform to a second platform. Using some type of a first tracking system, a first check is made for all components mapped to application “banking” within the application domain. The resulting list of components may, and probably does, call other components that might be considered “general purpose”, and which are not included in this list. Therefore, the technology domain mapping must be utilized to determine which other components have relationships to components in the first list so that the related components can be included on the list. Finally, the list must be processed to remove duplicate components. This processing requires two individual processing efforts and some type of cross-checking operation. This can be time-consuming, and can make development of an automated component identification mechanism more difficult. The
Goiffon David A.
Hartmann Gerald E.
Johnson David R.
Atlass Michael B.
Chaki Kakali
Johnson Charles A.
McMahon Beth L.
Unisys Corporation
LandOfFree
Object management system supporting the use of application... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object management system supporting the use of application..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object management system supporting the use of application... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2511529