1. The Field of the Invention
This invention relates to the field of object-oriented databases wherein navigation between objects is a fundamental method for finding desired data. More specifically, this invention relates to the methods and structures for creating relationships between software objects in order to assist in object navigation.
2. Present State of the Art
Object-oriented systems, including databases, have become prevalent in recent years as a significant design technique that allows high degrees of code reusability between projects and for modeling real world solutions to problems in a more natural way. A software object is composed of data and methods to operate on or manipulate the data and otherwise give the object its xe2x80x9cbehavior.xe2x80x9d
In many database applications, it is useful to create a relationship between objects so that a client may navigate from one object to another based on the relationship. The usefulness of relationship navigation derives in part from the different types of objects and their arrangement with respect to one another in forming xe2x80x9cmodelsxe2x80x9d as part of an implemented software solution. For example, software objects used to present the various pieces in a development environment database would tend to have some very natural relationship. In such a database, an object representing a C++ source file would be related to other objects representing header files and to compiled code generated from the source file.
Relationships allow focused navigation through an object database. For example, a client testing the current state of a completed application in the development environment database would traverse or navigate the relationships between the objects representing the constituent parts to determine which modules would require recompilation or other action.
Furthermore, searches may be made on specific types of relationships to identify objects having a particular characteristic in the structured hierarchy of related objects. The relationship itself becomes an attribute that distinguishes the object.
In some database applications, it is only the state of an object that is stored in a repository. A software client will access the object state by instantiating an object having the assigned state and manipulate the object in order to operate on that state. Other objects may be instantiated as necessary through object methods to gain access to other object states and for navigating through the database. The key to navigating the database are methods that will instantiate necessary objects to traverse relationships between related objects. By allowing relationships between objects, structure is added to a database of objects and hence greater meaning can be given to the objects and the information represented therein. This allows object-oriented databases to more closely mimic structure and relationships found in the real world problems that object-oriented software products are intended to model.
Currently, relationships or links between objects are made on the entire object, usually defined in the class used to create the object upon instantiation. While this allows relationships to exist between objects, it lacks granularity for allowing objects of different types to be conventionally related without minimizing object functionality or increasing object overhead.
Ways are often sought to present an intuitive model for incrementally adding functionality into objects. One successful approach has been an object system where each object is composed of multiple interfaces, each interface representing a quantum of related functionality. An object is built of necessary interfaces for giving the object the desired character or behavior. It would be advantageous to incorporate relationship behavior on such interfaces to thereby allow interfaces to define relationships rather than object classes.
Methods of creating, managing, and defining object relationships are sought that increase system efficiency, expand potential functionality, are easily extensible, and otherwise add capabilities to object oriented designs. Those methods that allow greater flexibility and the ability to easily relate objects of different types (i.e., those created or instantiated by different classes) to be easily related based on object characteristics rather than the mechanical creation mechanisms are particularly important.
It is an object of the present invention to relate two separately instantiated objects through a logical link.
It is another object of the present invention to provide a navigation mechanism between related objects.
It is a further object of the present invention in some embodiments to represent relationships between objects as separate objects themselves so that behavior may be attributed to such relationship objects.
It is an object of the present invention to relate objects based on characteristics of the related objects rather than simply the class of the object, thereby allowing objects of different types to be easily related.
Additional objects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the invention as embodied and broadly described herein, a method and computer program product for implementing object relationships is provided.
A relationship is a connection between two objects and is a useful construct for traversing through related objects in an object oriented database or persistent object repository. The present invention is directed to a novel method and program code product for implementing an object relationship in a persistent object repository that stores object states. This is done by defining a relationship as a pair of complementary collections on two separate interfaces, each interface found on separate objects.
A link between objects is formed when an interface of one object lists an object supporting the related interface included in the latter object and vice versa. The collections may be of objects supporting the related interfaces or may be of specific relationship objects leading to objects supporting the related interfaces. By implementing a specific relationship object, behavior may be imparted to the relationship itself.
By defining the relationship on an interface of an object rather than the class of the object, objects of different types created by different classes may be easily related based on the same kind of relationship, due to the different classes supporting the same interface. This creates a more intuitive model since it is object characteristics (as defined by interfaces) that provide functional capabilities to clients rather than mechanisms such as class definitions used to create or instantiate an object.
In a first embodiment, the link between objects is formed when a collection on one interface of one object contains direct references to the related objects supporting the related interface. Correspondingly, a collection exists on objects having the former interface listing related objects supporting the latter interface. Generally, a collection pair relating or linking particular interfaces (and hence the objects supporting those interfaces) has an origin object associated with an origin interface and a destination object associated with a destination interface.
In a second embodiment, each of the collections described previously in connection with the first embodiment is implemented as a specific collection object that may be accessed by a method on an interface of the related objects (origin or destination). This implementation allows more generic navigation models and behavior may be extended from the collection object to implement custom behavior.
In a third embodiment, each of the collection objects described previously in connection with the second embodiment implements a collection of relationship objects that can be used to arrive at the actual related objects supporting the related interface. When implementing a relationship through relationship objects, specific behavior may also be implemented on the relationship object and extended as necessary according to the binary extensibility scheme of the underlying object model.
In a fourth embodiment, the facilities of both the second and third embodiments are combined so that a user has both options available. The more direct collection of objects supporting the related interface provides a more efficient and convenient link when only the related object is desired, while the collection of relationship objects allows behavior to be associated with the relationship itself. Again, both collections on the origin and destination objects are implemented by objects (e.g., one object for each collection) themselves.
In a fifth embodiment, a single collection object is implemented that in turn has the facilities for managing collections of related objects having the related interface, and relationship objects leading to related objects supporting the related interface. In this manner, a single collection object may be accessed by an origin or destination object rather than requiring two separate collection objects as shown in the fourth embodiment.
These embodiments showing implementation variations of the present invention have differing characteristics in terms of extensibility to add custom behavior, performance, and complexity. A designer will choose the embodiment that best suits the application and those skilled in the art may yet see other embodiments that incorporate the present invention.
These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
USPTO Backgrounds
USPTO Backgrounds