Data processing: software development – installation – and managem – Software program development tool
Reexamination Certificate
1999-07-28
2004-09-07
Zhen, Wei (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
C717S120000
Reexamination Certificate
active
06789251
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to an improved tool management system for a data processing system; and, more specifically, relates to a system for managing a disparate set of tools that each performs an associated set of operations for processing data objects stored in a object repository, wherein the user interface provided by any of the tools may be used to select a data object and an operation to be executed to process the selected data object, and wherein the selected operation and data object will be routed to another one of the tools for execution automatically if the selected operation is not included in the set of operations provided by the initially-selected tool.
2. Description of the Prior Art
Today's data processing systems generally include a wide array of software applications and tools for managing, manipulating, creating, cataloging, and searching for data items. A simple example of such a system is the typical personal computer, which may include a first software application adapted for text editing, another application utilized for spread-sheet generation, a third application devoted to the generation of figures and diagrams, and so on. All of these applications may be used at some point to help create a single data item, which in this case may be a document including text, tables, and drawings. To accomplish this, however, the user must first become familiar with each of the tools. The user must also understand which tools are appropriate to accomplish a given task. For instance, a user may be provided a choice between the use of two schematic drawing programs, with the choice being dictated by the data format generated by the programs, and the compatibility of that format with the format used by the other tools. Alternatively, because of specific requirements associated with the data item being processed such as certain formatting requirements, only certain functions provided by a particular application program may be available for use in creating, updating, and/or processing that data item. Gaining this type of knowledge often requires a substantial amount of time and much “trial-and-error” experimentation.
Another disadvantage of using a disparate set of tools to manage or process a single set of data items involves the often disjointed use of the tool set to accomplish the task at hand. In the current example, for instance, a user may be required to use a first tool to perform a first data entry function on a data item. After this operation is completed, the updated data item must be saved, and a second tool is invoked manually to perform a second operation on that data item. This process may be repeated multiple times using multiple tools, resulting in a time-consuming process.
A more complex example of the problems associated with the use of a disparate tool set to process a common set of data items is provided upon considering an object management system of the type described in the co-pending application entitled “An Object Management System Supporting the Use of Application Domain Knowledge Mapped to Technology Domain Knowledge”, (hereinafter, “Co-Pending Application”) referenced above. This object management system supports the development and management of object-based, reusable code and data modules of the type commonly used in today's software development efforts.
As is known in the art, the object-based coding paradigm relies on the development of a base of reusable code and data modules. Cataloging and providing revision control for these components can be a daunting task. This is especially true because of the rapid pace at which computer technology is evolving. Often it is desirable to adapt software applications and repositories residing on one data processing platform so these applications become available from a different platform. Additionally, it may be desirable to “renovate” certain code and data modules. A common example of such a renovation effort is the adaptation of code to properly handle dates falling after Dec. 31, 1999 to remedy what has become known as the “Y2K problem”. Another type of renovation effort is needed to allow for the correct handling of the European Monetary Unit (EMU), or “Euro”, which will become the common currency within many European countries within the next few years.
Performing the type of code adaptation and renovation operations described above requires a detailed knowledge of the manner in which the object-based code and data components interrelate. It also requires some way to catalog and track the various revisions of the modules that exist on the system at any given time. The object management system mentioned above provides the ability to catalog the code and data modules and the associated interrelationships in a manner that allows code development tasks to proceed in a much more efficient manner. The details of this object management system are provided in the Co-Pending Application, and in the additional applications cross-referenced above.
The object management system catalogs and tracks code modules and the associated interrelationships by modeling these modules and interrelationships in an object repository. The repository stores objects, wherein ones of the objects referred to as “asset elements” each describes and models a respective code or data module. The repository further stores relationships between the objects that each models the relationships existing between the code and/or data modules modeled by the respective objects.
The objects and object relationships stored in the object repository may be viewed using various element and relationship viewing tools provided by the object management system. Some of these viewing tools allow the user to create, delete, and modify the various objects and object relationships. Other automated analysis tools are used to provide insight into the interdependencies existing between the objects. This knowledge is used to understand the interdependencies existing between the code modules stored within the system. Still other tools are used to develop batch-mode scripts that can be executed to invoke certain processing operations on the objects in the repository, or to perform operations on the code and data modules themselves, as is described in detail in the Co-Pending Application. Tools are also provided to execute these batch-mode scripts.
The various tools used to manage the object repository described above each provides a subset of the functions supported by the object management system. To use this tool set effectively, the user must understand which tool is used to accomplish a given task on a given object. This may not always be intuitively obvious, since some of the tools in the tool set provide similar functions, and the decision to use one tool instead of another is based on the type of object being processed. Additionally, each of the tools provides a user interface that may be dissimilar from the user interfaces provided by other tools. Because of these complexities, a substantial amount of time may be required to gain familiarity with this tool set. Moreover, if a user is processing a given object using a series of tool operations, the user may be required to manually invoke various tools in a manner that is cumbersome and time-consuming.
What is needed is a comprehensive tool management system and interface that hides the complexities associated with a disparate set of object management tools. This tool interface should allow any tool operation to be invoked using any tool interface, regardless of whether the invoked operation is actually supported by the tool used to initially invoke the operation. The tool that actually supports the operation should be automatically launched so that the invoked operation may be performed in a manner that is transparent to the user.
OBJECTS
It is the primary object of this invention to provide an improved tool management system and interface for a data processing system;
It is another object to provide an improved tool interface for a
Johnson Charles A.
McMahon Beth L.
Starr Mark T.
Unisys Corporation
Zhen Wei
LandOfFree
System and method for managing a suite of data management tools does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for managing a suite of data management tools, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for managing a suite of data management tools will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3266192