Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: The present invention comprises a method for allowing a data controlling object to interface with any number of user interface objects without requiring separate interface code for each user interface object and without restricting the user interface to certain predetermined designs. The present method provides objects called association objects that are interposed between a data controlling object and each user interface object. Each kind of user interface object has a corresponding association object. The association object for a particular kind of user interface object contains code that allows the association object to interact with the specific kind of user interface object with which it is associated. Each association object also presents a standard interface to a data controlling object, regardless of the kind of user interface object with which the association object is associated.

Abstract: The present invention creates a model that maps object classes in an object-oriented environment to a data source. The model maps the relationship between properties of each object class and data of the data source. The present invention can be used with a data source such as a relational database, user interface, file system, or object-oriented database. An application's object classes and data source schema are designed independent of the other since the model can be used to map one to the other. The model is comprised of entities and attributes. An entity maps to an object class and to at least one table of the DBMS. An entity contains attributes either simple or derived. A simple attribute maps to a DBMS column. A derived attribute is a combination of other attributes and does not directly map to a DBMS column. A relationship creates a link between entities of the model. A relationship can be used to flatten an attribute or flatten a relationship.

Abstract: Various technologies and techniques are disclosed for providing an integration framework that enables tools to be integrated. The integration framework enables tools participating in the framework to be encapsulated in a manner that hides their implementations, thereby preventing them from taking deep dependencies on each other. The integration framework also enables the tools participating in the framework to carry formal type definitions called service and data contracts that describe the public behaviors they offer. The integration framework also provides support for migrating integration logic from tools into pluggable commands to further reduce coupling between the tools.

Abstract: The present invention creates a model that maps object classes in an object-oriented environment to a data source. The model maps the relationship between properties of each object class and data of the data source. The present invention can be used with a data source such as a relational database, user interface, file system, or object-oriented database. An application's object classes and data source schema are designed independent of the other since the model can be used to map one to the other. The model is comprised of entities and attributes. An entity maps to an object class and to at least one table of the DBMS. An entity contains attributes either simple or derived. A simple attribute maps to a DBMS column. A derived attribute is a combination of other attributes and does not directly map to a DBMS column. A relationship creates a link between entities of the model. A relationship can be used to flatten an attribute or flatten a relationship.

Abstract: The present invention comprises a method for allowing a data controlling object to interface with any number of user interface objects without requiring separate interface code for each user interface object and without restricting the user interface to certain predetermined designs. The present method provides objects called association objects that are interposed between a data controlling object and each user interface object. Each kind of user interface object has a corresponding association object. The association object for a particular kind of user interface object contains code that allows the association object to interact with the specific kind of user interface object with which it is associated. Each association object also presents a standard interface to a data controlling object, regardless of the kind of user interface object with which the association object is associated.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven t yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A system that facilitates software development by providing a software factory based on an instance of a metamodel. The metamodel supports the definition of one or more viewpoints with a viewpoint comprising one or more work product types, templates for one or more tasks supporting the creation and modification of instances of the viewpoints and work product types, and templates for workstreams comprising one or more tasks and relationships between them. The metamodel supports definition of relationship(s) among viewpoints and/or between viewpoint(s) and work product type(s), and operation(s) that can be performed across relationship(s). Additionally, asset(s), if any, available to particular task(s) can further be defined as supported by the metamodel. A software factory specification system can be employed by a factory developer to specify an instance of the metamodel which, along with the items described can be employed in an interactive development environment as a software factory.

Abstract: An anti-theft device for articles having some article body portion of lesser cross sectional area bounded by body portions of greater cross sectional area so that the smaller body portion can be lockably held within a passage and the larger body portions prevent removal of the article from the anti-theft device. Preferably, the anti-theft device can be used for cables and other devices having permanent non-removable enlarged sections, such as endoscopy cables.

Abstract: Various technologies and techniques are disclosed for providing an integration framework that enables tools to be integrated. The integration framework enables tools participating in the framework to be encapsulated in a manner that hides their implementations, thereby preventing them from taking deep dependencies on each other. The integration framework also enables the tools participating in the framework to carry formal type definitions called service and data contracts that describe the public behaviors they offer. The integration framework also provides support for migrating integration logic from tools into pluggable commands to further reduce coupling between the tools.

Abstract: The performing of actions on an object graph that contains multiple objects. The objects are categorized into partitions. Taking into account the partitions, a particular non-final action performed on the object graph may be undone without necessarily first undoing all of the one or more subsequent actions. Instead, if the subsequent actions involved objects of different partitions than the objects that were affected by the particular action desired to be undone, the particular action may be undone without undoing the subsequent actions.

Abstract: The present invention creates a model that maps object classes in an object-oriented environment to a data source. The model maps the relationship between properties of each object class and data of the data source. The present invention can be used with a data source such as a relational database, user interface, file system, or object-oriented database. An application's object classes and data source schema are designed independent of the other since the model can be used to map one to the other. The model is comprised of entities and attributes. An entity maps to an object class and to at least one table of the DBMS. An entity contains attributes either simple or derived. A simple attribute maps to a DBMS column. A derived attribute is a combination of other attributes and does not directly map to a DBMS column. A relationship creates a link between entities of the model. A relationship can be used to flatten an attribute or flatten a relationship.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven t yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: The present invention creates a model that maps object classes in an object-oriented environment to a data source. The model maps the relationship between properties of each object class and data of the data source. The present invention can be used with a data source such as a relational database, user interface, file system, or object-oriented database. An application's object classes and data source schema are designed independent of the other since the model can be used to map one to the other. The model is comprised of entities and attributes. An entity maps to an object class and to at least one table of the DBMS. An entity contains attributes either simple or derived. A simple attribute maps to a DBMS column. A derived attribute is a combination of other attributes and does not directly map to a DBMS column. A relationship creates a link between entities of the model. A relationship can be used to flatten an attribute or flatten a relationship.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves. This delayed resolution of relationships occurs in two stages: the creation of a placeholder object for the data to be fetched, and the fetching of that data only when it's needed.