Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1999-05-04
2002-06-18
Bayerl, Raymond J. (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C345S960000, C717S125000, C717S113000, C717S127000, C707S793000, C706S060000, C706S059000
Reexamination Certificate
active
06407753
ABSTRACT:
BACKGROUND
1. Technical Field
The present invention relates generally to software development tools and, more particularly, to a system and method for integrating entities using a graphical user interface (GUI) to provide user-interactive rule-based matching and difference reconciliation.
2. Description of Related Art
Typically, during software development, there are many situations where entities (e.g., objects, messages, or data) must be integrated, even though their detailed content is different (e.g. different data fields, types, aggregations, etc.). For example, during the development of object-oriented applications, common base classes may be factored out by analyzing the input classes to find “matching” data and methods which can be combined and then moved to the base class. Composite objects are formed by aggregating one or more input (component) classes that are exposed through a “combined” interface of the composite. Moreover, in messaging systems, multiple messages from different sources might have to be combined to form a single, integrated message.
Entities typically consist of many elements. When integrating entities, some elements of the entities to be integrated might match (i.e., they represent the same thing in the different representations) while others might not. The matching criteria used for integrating entities can vary greatly, ranging from simple element-name matching, to more complicated scenarios in which syntactically different input entities may actually represent the same thing. Once matching elements of the input entities have been identified, any differences between them must be reconciled, and then these reconciled elements are integrated to form the composite entity.
A similar, and even more common, situation for integrating entities is where entities must be shared by, or passed between, applications, but where the different applications have different expectations regarding the detailed content of such entities. This process is referred to by various names, depending on the nature of the entities involved. For example, if the entities are objects that communicate through interfaces, this process called “interface mapping” or application program interface (API) mapping. If the entities are messages or data, the process is called “message mapping” and “data mapping,” respectively. In these cases, integration is required not to produce a composite, but to map inputs to outputs. Indeed, the growing popularity of XML (Extensible Markup Language) as an interchange form has brought this issue to the forefront: XML dictates a common format, but not common content. Consequently, the integration of content elements is critical to realizing free interchange.
Conventionally, the process of integrating entities typically comprises two steps. The first step of the integration process typically involves examining the definitions of the entities to be integrated, and determining which of their elements match and how their differences can be reconciled. The second step of the integration process involves the execution of the integration in accordance with the determination made in the first step, which involves, for example, actually calling functions, or building integrated messages or data from actual input messages or data.
The first and second steps of the integration process typically occur at different times, referred to herein as “development-time” and “run-time,” respectively. “Development-time” refers to the time when the first step of the integration process is performed. For example, in the case of message integration, the first step occurs when developers examine definitions of messages that must be integrated, while a system is being developed or modified. On the other hand, the second step of the integration process typically occurs during “run-time,” (e.g., in the case of message integration, the time when actual messages are being sent and received). It is to be understood, however, that there are cases where “development-time” and “run-time” occur simultaneously. For example, if integration were used in a programming environment to help factor out base classes, as described above, the resulting base classes will actually be produced right after the user specifies how to do so.
Conventionally, the “development-time” task of matching common definitions of elements, reconciling their differences and determining how to produce an integrated result is generally a manual operation with very little, if any, tool support. For example, some existing development-time matching software tools are limited in that they only display and help users visualize the input elements while the user matches and reconciles each input element, one by one (i.e., user tailoring), but do not support mechanisms for performing automatic matching of elements.
In addition, other conventional software tools (or builders) that are used for software development, in general (e.g., building UML (Unified Modeling Language) designs), provide a combination of automatic processing when possible, as well as user tailoring. These systems, however, may be configured such that all or some of the information resulting from user tailoring is lost when the tool is run again, which is known in the art as the “round-trip” problem. The diagram of
FIG. 2A
illustrates a general approach utilized by some conventional software builder tools. With a conventional software tool, the result (denoted by “R”), which is generated by processing input components
1
1
and
1
2
, for example, is typically stored persistently, when the user is satisfied with the result. Although the result R is derived from processing the input components, it is nevertheless treated like an unrelated entity. Consequently, if the input components comprising the result R are slightly modified requiring some minor editing of the result R, the previous result must be analyzed in order to determine how the result R was derived from the inputs and what user tailoring was performed to obtain the result, which is difficult and sometimes virtually impossible. Alternatively, a new result can be produced by processing the modified inputs using the tool, discarding the previous result (including all the work the user put in to producing it), which is burdensome to the user.
Accordingly, there is a need for a software development system and method which supports both automatic and user guided rule-based matching and reconciliation for integrating one or more entities, whereby the matching/reconciliation rules are stored such that they can be recalled and applied during a subsequent editing session when the input entities change or a new composite entity of the inputs is desired.
SUMMARY OF THE INVENTION
The present invention is directed to a system and method for integrating entities using a graphical user interface (GUI) to provide user-interactive rule-based matching and difference reconciliation.
In one aspect of the present invention, a system for integrating entities employs a combination of default matching and reconciliation approaches and user tailoring to generate a composite entity from one or more input entities using a set of composition rules. The set of composition rules comprises a combination of default rules, as well as rules that represent user interactions that are performed via a graphical user interface when the user edits a composite result. The rules are captured and then stored persistently when the user requests that the composition be saved, such that the rules may be retrieved during a subsequent editing session associated with the same inputs. If the inputs change, the integration process (as specified by the rules) can automatically handle many changes. It is only when changed elements of the input are, or need to be, subject to specific rules that additional tailoring may be required.
In another aspect, the GUI is configured such that when a user selects a result element, the GUI will highlight the input elements that were integrated to form the selected result element. Similarly, when the user selects a
Budinsky Frank J.
Dobson Steven R.
Kaplan Matthew
Kruskal Vincent J.
Ossher Harold L.
Bayerl Raymond J.
F. Chau & Associates LLP
International Business Machines - Corporation
LandOfFree
System and method for integrating entities via... 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 integrating entities via..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for integrating entities via... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2913494