CA2293114A1 - Representing a data mapping of an object reference - Google Patents
Representing a data mapping of an object reference Download PDFInfo
- Publication number
- CA2293114A1 CA2293114A1 CA002293114A CA2293114A CA2293114A1 CA 2293114 A1 CA2293114 A1 CA 2293114A1 CA 002293114 A CA002293114 A CA 002293114A CA 2293114 A CA2293114 A CA 2293114A CA 2293114 A1 CA2293114 A1 CA 2293114A1
- Authority
- CA
- Canada
- Prior art keywords
- key
- computer
- attribute
- referent
- providing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
Abstract
Methods, systems and computer program products of the invention are provided for representing a data mapping of an object reference, namely graphically representing an object reference to a referent object by a referring object including associated data mapping between attributes of the objects and the corresponding data of the objects.
Representing an object reference to a referent object in a computer environment is provided that includes providing a graphical tree of attributes of a referring object in a user interface and in the tree an object reference attribute corresponding to the object reference is included, the object object reference attribute comprising key part(s) corresponding to an attribute of the referent object that forms part of the key for the referent object.
Representing an object reference to a referent object in a computer environment is provided that includes providing a graphical tree of attributes of a referring object in a user interface and in the tree an object reference attribute corresponding to the object reference is included, the object object reference attribute comprising key part(s) corresponding to an attribute of the referent object that forms part of the key for the referent object.
Description
REPRESENTING A DATA MAPPING OF AN OBJECT REFERENCE
FIELD OF THE INVENTION
This invention relates to representing a data mapping of an object reference.
Particularly, the invention relates to graphically representing an object reference to a referent object by a referring object including associated data mapping between attributes of the objects and the corresponding data of the objects.
BACKGROUND OF THE INVENTION
As part of the development of software applications, software programmers have been provided new tools to facilitate rapid application development, such as visual application development tools and incremental compilers. A new breed of rapid application tools involves component-based development. Components may be loosely defined as software packages that contain a collection of related services and attributes that are typically discrete and hence re-usable.
Component-based development tools provide the ability to connect together these components to develop a software application. An example of such a tool is the IBM~
Component BrokerTM
product which is intended to be used by large enterprises that employ large numbers of developers in creating enterprise applications using components.
The Component Broker product provides a runtime, development and server management system that supports developing and executing distributed object-oriented applications in a client/server environment. It can provide a programming model, framework, tools and object class libraries and components to develop distributed applications, a runtime to execute the applications and systems management for the administration of the components.
The Component Broker product allows for the operation, creation and organization of business objects. A business object represents a business function and encapsulates in software the knowledge about real-world artifacts such as customers, accounts, bank transactions, ledgers, and so forth. Business objects deal with the business logic, rules, and constraints as defined by a specific domain. To that end, business objects comprise attributes that define the state ofthe business object and a method embodied in software that defines the behavior of the business object. Further, business objects typically have relationships with other business objects allowing them to be combined to perform a specific task. Typical examples of business objects are customer, invoice or account objects which can be combined to form, for example, a billing application. Business objects need not directly address user-interface aspects of a particular usage scenario or application. Neither need they be concerned with data storage technology. Ideally, they are usage and technology independent, reusable software building blocks. This is in stark contrast to procedural software, which was prone to intermingle all these aspects.
Related to the business object in the Component Broker product is the data object. A data object is responsible for managing the persistence of a business object's essential state information.
It manages essential state information by providing a business object with an interface for getting and setting all of the essential state information. Each attribute in a business object can correspond to zero or more attributes in a data object. A data object also isolates a business object from having to know which of many datastores to use to make its state persistent. It also isolates the business object from having to know how to access the datastore, and from having to manage the access.
Another object related to the data object in the Component Broker product is the persistent object. A persistent object provides a mechanism for storing an object's state in a datastore. Every persistent object has an identifier or a key that is used for locating its corresponding record within the datastore. There are two kinds of persistent objects in Component Broker:
database persistent objects and procedural adapter persistent objects. Database persistent objects represent a record of a table or a view in a relational database. The component's state data that is stored in the relational database by means of a persistent object lasts longer than the execution time of the application that calls the component. In a relational database such as a SQL database, all records are persistent because they are stored on a storage means, such as a disk, in the form of database tables. A
datastore, whether it is an object-oriented database management system or a relational database management system, stores an object's persistent data. A procedural adapter persistent object encapsulates not only the data associated with an application but also the application's transaction logic. It is usually an embodiment of an IMS~ and/or CICS~ transaction and corresponding data.
A feature of the Component Broker product is the Object Builder. The Object Builder facilitates creating business objects conforming to a programming model and based on a managed object framework of Component Broker. The Component Broker also facilitates creating the associated objects to a business object such as the data object and the persistent object. Functioning business objects in the Component Broker environment are referred to as managed objects each of which comprise: i) a business object class containing the fundamental business logic for the managed object; ii) the business object's associated data object which defines the essential data for the object;
and iii) the implementation binding that wrappers the business object and associates it with the required object services provided by a given instance manager. An instance manager provides a home for instances of managed objects much like a database system or file system provides a home for records and files. It is essentially an object-oriented database, responsible for providing system capabilities for its managed object instances. The role of Object Builder is to support the definition and/or automatic creation of all of the classes needed to produce a fully functional managed object.
Often when developing object-oriented programs such as applications using the business and other types of objects of the Object Builder, developers will make use of an object reference, a standard programming technique in object-oriented programming. Typically when a developer creates an object reference, the user must provide the detailed mapping coding that is required to create such a reference. That is, the user replicates the referent object table accessor code in the referring object. Accordingly, the reference code for the referent object directly accesses the object that facilitates persistence for the referent object or alternatively the referring object contains code inline that facilitates persistence for the referent object. The disadvantages of this method include i) having duplicated code which can lead to error prone implementations and ii) by not resolving the reference in object space, having multiple copies of the object in an unmanaged fashion which may leave it open to data corruption problems or database deadlock. Further, from a user interface perspective, it is common to provide a place for the user to specify the detailed implementation via an edit function. In some cases, the edit function provides sample mapping code as described above.
However, the user must perform the often tedious and sometimes error prone task of manual coding (or recoding the sample code) to create the object reference.
It is therefore desirable to provide a method, system and article of manufacture comprising a computer usable medium having computer readable program code means therein for graphically representing a data mapping of an object reference that can overcome some or all of the foregoing and other disadvantages of application development techniques.
SUMMARY OF THE INVENTION
Accordingly, there is provided new and useful methods, systems and articles of manufacture comprising a computer usable medium having computer readable program code means therein for graphically representing a data mapping of an object reference.
There is provided a method for representing an object reference to a referent object in a computer environment, comprising the steps of providing a user interface for a referring object; and in said user interface, providing a key icon representing a key for the referent object of said object reference. The above method may be further provided wherein providing the key icon comprises providing a key part corresponding to a referent object attribute of the key for the referent object.
This method may further comprise the step of matching the referent object attribute to an attribute that corresponds to data. And, the step of matching may comprise matching by comparing a name of the referent object attribute and a name of said attribute. The above methods may further comprise the step of automatically generating code corresponding to the object reference. This method may also be provided wherein the step of automatically generating code comprises generating accessor code for data access using key retrieval. The above methods may also be provided wherein the step of providing a key icon comprises providing the key icon as an attribute in a graphical menu for attributes of the referring object. Further, the above methods may comprise providing key information corresponding to the key in the user interface. This method may also be provided wherein providing key information comprises providing, upon selection of the key icon by a user, key name and home location information pertaining to the key in the user interface, said key name and home location information selectively modifiable by the user. Also, there may be provided the above methods wherein the step of providing a key icon comprises automatically locating the referent object and retrieving the key of the referent object.
Further there is provided a method for representing an object reference to a referent object in a computer environment, comprising the steps of providing a graphical tree of attributes of a referring object in a user interface; and automatically providing an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
The above method may be further provided wherein said step of automatically providing comprises locating the referent obj ect and retrieving the key of the referent obj ect.
And, the above methods may further comprise the step of generating code corresponding to the object reference.
Also provided are computer program products for executing any of the above methods. And articles of manufacture comprising a computer usable medium having computer readable program code means therein for executing any of the above methods. Further, articles of manufacture comprising a computer usable medium having computer readable program code means therein for representing an object reference to a referent object in a computer environment, the computer readable program code means in said computer program product comprising computer readable code means for causing a computer to execute the method steps of the above methods.
A computer system for representing an object reference to a referent object in a computer environment is also provided comprising means for providing a user interface for a referring object;
and means for providing, in said user interface, a key icon representing a key for the referent object of said object reference. The above computer system may be further provided wherein the means for providing the key icon comprises means for providing a key part corresponding to a referent obj ect attribute of the key for the referent object. The above computer systems may also comprise means for automatically generating code corresponding to the object reference. And, the computer systems above may be provided wherein the means for providing a key icon comprises means for providing the key icon as an attribute in a graphical menu for attributes of the referring object. And, the above computer systems may be provided wherein the means for providing a key icon comprises means for automatically locating the referent object and retrieving the key of the referent object.
And, there is provided a computer system for representing an obj ect reference to a referent object in a computer environment, comprising means for providing a graphical tree of attributes of a referring object in a user interface; and means for automatically providing an object reference attribute in said tree corresponding to the obj ect reference, said obj ect reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object. The above computer system may also be provided wherein the means for automatically providing comprises means for locating the referent object and retrieving the key of the referent object. Further, the computer systems above may further comprise means for generating code corresponding to the object reference.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar or corresponding elements and in which:
Figure 1 is a schematic diagram of an Employee object and a Department object;
Figure 2 is a representation of sample data corresponding to the attributes of the Employee and Department objects of Figure 1;
Figure 3 is a depiction of the graphical user interface of the Object Builder showing the type of the Employee object of Figure 1 with the attribute EmployeeName highlighted;
Figure 4 is a depiction of the graphical user interface ofthe Object Builder showing the type of the Employee object of Figure 1 with the attribute DepartmentRef highlighted;
Figure 5 is a depiction of the graphical user interface of the Object Builder showing the mapping of the persistent object corresponding to the Employee object of Figure 1 to a relational database corresponding to the Employee data of Figure 2;
Figure 6 is a depiction of the graphical user interface of the Object Builder showing the mapping of the persistent object corresponding to the Department object of Figure 1 to a relational database corresponding to the Department data of Figure 2;
Figure 7 is a depiction of the graphical user interface of the Object Builder showing the attributes mapping between the data object and the persistent object corresponding to the Employee object of Figure 1 with the DepartmentKey menu highlighted;
Figure 8 is a depiction of the graphical user interface of the Object Builder showing the attributes mapping between the data object and the persistent object corresponding to the Employee object of Figure 1 with the DepartmentNumber key attribute highlighted;
Figure 9 is a depiction of the graphical user interface of the Object Builder showing the attributes mapping between the data object and the persistent object corresponding to the Employee object of Figure 1 with the EmployeePO attribute (iPO.deptnum) corresponding to the DepartmentNumber key attribute highlighted;
Figure 10 is a portion of the Object Builder code for resolving an object reference of a source object (Source) to a referent target object (Target); and Figure 11 is SQL code representing the schema of the Employee and Department data of Figure 2.
DETAILED DESCRIPTION OF THE INVENTION
A preferred embodiment of the present invention will be described which provides for representing a data mapping of an object reference.
It is common for an object to have a reference to another object, especially in a distributed object system. Referring to Figure 1, an example of an object reference is depicted using an Employee object (e.g. to represent an employee of a company) and a referent Department object (e.g.
to represent a department within a company). As shown in Figure 1, the Employee object has a number of attributes including number (corresponding to the employee's identifying number in the company), name (corresponding to the employee's name), deptnum (corresponding to the employee's department number in the company), locnum (corresponding to the employee's location number) and sin (corresponding to the employee's Social Insurance Number /
Social Security Number). Further, the Department object has a number of attributes including deptnum (corresponding to the department's department number in the company), locnum (corresponding to the department's location number), address (corresponding to the department's address) and deptname (corresponding to the department's name). Further, attributes deptnum and locnum in the Employee object are indicated as being foreign keys (FK) which correspond to the same attributes in the Department object. Hence, there is an object reference from the Employee object to the referent Department object. It should be apparent to those skilled in the art that different types and numbers of objects, attributes and object references can be used in accordance with the invention.
Indeed, an object may have more than one object reference.
A common manner to represent an object reference is to provide the reference to a referent object as an attribute or property of the referring object. In the present example, attributes deptnum and locnum of the Employee object (the referring object) form the object reference to the Department object (the referent object) and its attributes. In this way, access can be made in the Employee object to the attributes of the Department object including the attributes deptnum, locnum, address and deptname.
Important to the use of the object reference is the notion of keys. An object reference comprises some form of location information for the referent object and some form of identity for the referent object. To that end, the location information of the referent object in a computer system is provided by a user and can be configurable or fixed. Location is not enough because there needs to be a way to identify an object, in the location, from other objects. To identify the referent object, a key is used. As shown in Figure 1 by the dividing line, the attributes number and name are designated as keys (by a user) for the Employee object. Similarly, attributes deptnum and locnum are designated as keys (by a user) for the Department object. Keys are used as identifiers of an object. Particularly, when a object reference is made, the reference uses a keys) to identify and locate an object. In this case, attributes deptnum and locnum of the Employee object are the foreign keys used to identify and locate the Department object, which has those key attributes - deptnum and locnum.
Further, the attributes of the Employee and Department objects may correspond to a record of a table or a view in a relational database. Sample data that corresponds to the attributes of the S Employee and Department objects are shown in Figure 2. Such data may be persisted and may be a database store although it should be apparent to those skilled in the art that the invention may equally be implemented using other than persisted data or database stores such as data stored temporarily in random access memory or on-line data communicated directly via electronic or other means. Referring to Figure 2, it can be seen that the attributes of Employee object have corresponding data. In this set of sample data, the number, name, deptnum, locnum and sin attributes have correspondingly named columns in this database store and relevant data beneath. Indeed, the key attributes to the Department object, deptnum and locnum, have corresponding data (and columns) in the table. Of course, the column names need not be identical to the object attribute names but rather, as discussed later, the attributes can be mapped to the columns even though the names are not identical. Further, the corresponding data to the Department object attributes are shown wherein the column names and attribute names of the Department object correspond accordingly. In a typical example, the schema for the Employee and/or Department sample data would be stored in a SQL Data Definition Language (DDL) file. The SQL code representing the schema of the Employee and Department data of the example described herein is provided in Figure 11.
Hereafter, the preferred embodiment of the invention is described using the example Employee and Department objects heretofore defined. Further, the invention is described in the context of the Object Builder and in terms of business, data and persistent objects. It should be apparent to those skilled in the art that any type of object may be used;
objects need not conform to the business, data and persistent objects model described above. Further, the invention need not only be implemented in programs like Obj ect Builder. The invention may equally be used in a wide range of other programs including other types of application development tools. And, objects used with the invention may represent other than employee and/or department data or logic. There are no bounds on what the objects may represent.
Using the Object Builder, a corresponding Employee business object to the Employee object and a corresponding Department business object to the Department object of Figure 1 can be created that can access the sample data in Figure 2. By using the Object Builder, a user can define the Employee and Department business object interfaces.
Referring to Figure 3, the Employee business object interface is shown in the graphical user interface of the Object Builder. As indicated, the attributes of the Employee business object type are shown in a graphical menu tree manner with the menu or folder Attributes shown in an open fashion with the attributes of the Employee business object shown therebelow as rungs.
Particularly, the simple attributes EmployeeNumber, EmployeeName, and SINSSN are shown along with the object reference attribute DepartmentRef in accordance with the invention and described further below. In this example, different attribute names were chosen than as shown in Figure 1 to facilitate showing attribute mapping although for ease the Employee and Department business objects may have attribute names that correspond exactly to the attribute names of Figure 1.
By clicking on the Attributes menu, a user can return the Attributes menu to a closed position thereby hiding the attribute rungs in the graphical user interface of Figure 3. Closing the Attributes menu does not delete the attributes from the Employee business object; closing simply hides the attributes from the user's graphical user interface and they can be returned to view by clicking the Attributes folder into an open position. Further, the EmployeeName attribute is highlighted thereby revealing the details associated with that attribute. As is self evident in Figure 3, the attribute name of the EmployeeName attribute is shown in the box labeled "Attribute Name".
Similarly, the data type of the attribute EmployeeName, namely string, is shown in the box labeled "Type".
By clicking on the appropriate rungs in the menu, the user highlights an attribute and thereby exposes the details of the highlighted attribute. With the details shown, the user can configure the highlighted attribute by modifying the data in the boxes and clicking on the buttons/checkboxes shown. Indeed, a user can add an attribute to the Employee business object by clicking on the "Add Another" button and/or delete an attribute from the Employee business object by highlighting the attribute to be deleted in the menu and clicking on the "Delete" button.
Further, the user can refresh the attribute data and menu by clicking on the "Refresh" button. Optionally, the user interface also allows an initializer value to be assigned to the highlighted attribute, the highlighted attribute to be designated as read-only, the highlighted attribute to be overrideable by a subclass and the string behavior to be defined. Using these user interface features, the Employee business object interface may be constructed and configured. While not shown in the Figures, the Department business object interface can equally be represented and constructed.
While the user constructs and configures the Employee business object, the Object Builder automatically prepares the appropriate computer language code (in this case C++ although it would be apparent to those skilled in the art that code could be generated in other computer languages such as Sun Microsystems, Inc.'s Java TM language) for the business object. The Object Builder also allows the user to create the Employee and Department business object implementations as well as the Employee and Department data object interfaces and implementations corresponding to the respective business obj ects (not shown). Additionally, the user specifies a key for the Employee and Department business objects by selecting the attributes of the respective business object that should form the key for that business object (not shown). Using this key, object references can be resolved.
In Figure 4, the type of the Employee business object is again shown in the graphical user interface of the Object Builder. In this case, the DepartmentRef attribute, the object reference, is highlighted and its details are shown. Like in Figure 3, the attribute name of the Department object reference, DepartmentRef, is shown in the box labeled "Attribute Name". In the box labeled "Type", it is indicated that DepartmentRef is an object reference, particularly to the object Sample Department. In the preferred embodiment, the Object Builder recognizes the use of an object name in the "Type" box as an object reference and treats it accordingly using CORBA
conventions. Object Management Group's CORBA (or Common Object Request Broker Architecture) is an architecture and specification, for creating, distributing, and managing distributed program objects in a network.
It will be apparent to those skilled in the art that other distributed application architectures and specifications, such as Microsoft's DCOM, may be used. Although the preferred embodiment treats the object reference in accordance with distributed architecture conventions, it should be apparent to those skilled in the art that distributed object conventions are not required and such object references may be local. Again, the user optionally may add another attribute, delete an attribute, designate the attribute as read-only, and designate the attribute as overrideable by a subclass as described above.
Along with the Employee and Department business objects and data objects, the persistent objects corresponding to the sample data (in the preferred embodiment, persisted in a database) of Figure 2 are created in the preferred embodiment of the present invention. As described above, the schema for this sample data could be stored in a SQL Data Definition Language (DDL) file and the SQL DDL file could be imported into the Object Builder to create a persistent object from the schema. The SQL code representing the schema of the Employee and Department data of the example described herein is provided in Figure 11.
Referring to Figure 5, the persistent object corresponding to the Employee data table of Figure 2 is shown. The name of this persistent object, EmployeePO is shown in the box titled "Name" and is indicated, with a check in the "Table is Updatable" checkbox of Figure 5, as being updateable i.e. data can be written to the table. Whether the table is updateable is user selectable.
Under the heading "PO Attribute" of Figure 5 are listed the various attributes defined for the EmployeePO persistent object, namely name, number, deptnum, locnum and sin. If importing an SQL DDL file to create the persistent object, Object Builder by default uses the column names from the SQL DDL file to create the EmployeePO attribute names (as shown in Figure 5). The EmployeePO attribute names may be renamed by the user in the graphical user interface of Figure 5. Notably, the number of attributes listed can be more or less than the number of columns in the data table. Indeed, not all columns in the data table need to have corresponding persistent object attributes nor does every persistent object require a corresponding column in the data table. In this case there is a direct match between persistent object attributes and columns in the data table.
Next to the "PO Attribute" heading in Figure 5 is the "Attribute Type" heading which provides the data type corresponding to each of the EmployeePO attributes listed under the "PO
Attribute" heading. Like the EmployeePO attribute names, such information is drawn from the SQL
DDL file if such a file is used to create the persistent object. Continuing along the headings is the "PO Key" heading under which are provided checkboxes to indicate whether the corresponding EmployeePO attribute is a key. If the schema was imported from a SQL DDL file, the Object Builder automatically checks the appropriate key checkboxes if the DDL file indicates which columns are keys. Again, the user can redefine those keys which, as described above, are used as an identifier of an object, in this case, the EmployeePO persistent object. In Figure 5, the PO
key checkboxes are checked for the number and name attributes indicating that these two attributes form the key for the EmployeePO persistent object. The last heading titled "Column Name" lists the actual data table columns that map to the corresponding EmployeePO attributes. Additionally, Figure 5 indicates the package file name in which the EmployeePO is contained, the name of the file containing the schema for the Employee data table ("Database.Employee") and the type of persistence used.
Referring to Figure 6, the persistent object corresponding to the Department data table of Figure 2 is shown, much like the persistent object corresponding to the Employee data table was shown in Figure 5. The name of this persistent object, DepartmentPO is shown in the box titled "Name" and is indicated, with a check in the ''Table is Updatable" checkbox of Figure 6, as being updateable i.e. data can be written to the table. Whether the table is updateable is user selectable.
Further, under the heading "PO Attribute" of Figure 6 are listed the various attributes defined for the DepartmentPO persistent object, namely deptnum, locnum, address and deptname. If importing an SQL DDL file to create the persistent object, Object Builder by default uses the column names from the SQL DDL file to create the DepartmentPO attribute names (as is shown in Figure 6). The DepartmentPO attribute names may be renamed by the user in the graphical user interface of Figure 6.
Next to the "PO Attribute" heading in Figure 6 is the "Attribute Type" heading which provides the data type corresponding to each of the DepartmentPO attributes listed under the "PO
Attribute" heading. Like the DepartmentPO attribute names, such information is drawn from the SQL DDL file if such a file is used to create the persistent object.
Continuing along the headings is the "PO Key" heading under which are provided checkboxes to indicate whether the corresponding DepartmentPO attribute is a key. If the schema was imported from a SQL DDL
file, the Object Builder automatically checks the appropriate key checkboxes if the DDL file indicates which columns are keys. Again, the user can redefine those keys. In Figure 6, the PO
key checkboxes are checked for the deptnum and locnum attributes indicating that these two attributes form the key for the DepartmentPO persistent object. The last heading titled "Column Name"
lists the actual data table columns that map to the corresponding DepartmentPO attributes.
Additionally, Figure 6 indicates the package file name in which the DepartmentPO is contained, the name of the file containing the schema for the Department data table ("Database.Department") and the type of persistence used.
Returning to the object reference DepartmentRef created in the Employee business object, the Object Builder facilitates establishing the data mapping of the object reference and representing the object reference in the graphical user interface of the Object Builder.
Referring to Figure 7, there is shown in a graphical user interface the mapping between the attributes of the Employee data object and corresponding Employee persistent object attributes. Although not shown, there is a similar graphical user interface showing the mapping between the attributes of the Department data object and the Department persistent object. Like Figure 4, the Employee attributes are shown in a graphical menu tree fashion with the menu or folder Attributes in an open position revealing the attributes of the Employee data object as rungs therebelow.
Each rung in the menu corresponds to an attribute of the Employee data object (and correspondingly to the attributes of the Employee business object) and is a menu itself shown in an open position. For the simple data types, the graphical user interface reveals the mapping of that attribute of the Employee data object to the corresponding attribute of the Employee persistent object. Referring to Figure 7, attribute EmployeeNumber is shown mapped to iPO.number, the corresponding attribute in the EmployeePO (in this case iPO.number corresponds to iEmployeePO.number but the "Employee" moniker has been dropped in the user interface by Object Builder for readability and convenience because the user will appreciate that the Employee data object attributes are being mapped to the Employee persistent object attributes) . Similarly, attribute EmployeeName is shown mapped to iPO.name and attribute SINSSN is shown mapped to iPO.sin.
In the preferred embodiment, such mapping is automatically determined by matching the Employee data object attribute names with the attribute names for the Employee persistent object to establish a match. It should be apparent to those skilled in the art that other forms of matching can be used such as matching by identification number. Incorrect matches can be altered by the user entering the correct Employee persistent object attribute name in the "Persistent Object Attribute" box shown in Figure 9 or deleting the mapping if appropriate.
Like the simple data type attributes just described, the object reference, DepartmentRef, in the Employee data object is shown as an attribute. However, an object reference receives different treatment from a simple data type attribute, particularly in the graphical user interface. Knowing that DepartmentRef is an object reference because of its definition above in Figure 4, Object Builder provides a DepartmentKey menu (signified by a key icon) in the graphical user interface of Figure 7 that contains the Department key attributes. Object Builder searches through its object repository to find the referent object - Department - to retrieve the keys of the Department object.
As defined for the Department business object earlier (not shown), attributes DepartmentNumber and LocationNumber of the Department object form the Department object's key. Using those Department keys, the attributes of the Employee data object that correspond to the Department key attributes are resolved. In the preferred embodiment, such resolution is determined by matching the Department key attribute names with the attribute names of the Employee persistent object. Accordingly, DepartmentNumber and LocationNumber are identified in the Employee persistent object and the mapping is shown in the graphical menu tree of Figure 7.
Thus, the DepartmentKey menu of the Employee data obj ect shows, in the open position, the key attributes DepartmentName and LocationNumber of the Employee data object as menus therebelow. Each of the DepartmentName and LocationNumber key attributes are further shown in an open position to reveal the mapping of the DepartmentName and LocationNumber attributes of the data object to the corresponding Employee persistent object attributes.
Accordingly, when the Employee data object is created, the Object Builder automatically determines and provides in the Employee data object the corresponding attributes in the Employee data object that reconcile the object reference in the Employee business object with the attributes, including key attributes, ofthe Employee and Department persistent objects. Incorrect matches can be altered by the user entering the correct Employee persistent object attribute name in the "Persistent Object Attribute" box shown in Figure 9 or deleting the mapping if required.
Finishing with Figure 7, the DepartmentKey menu is shown highlighted and the corresponding detailed information is provided. In the box labeled "Key", the user can rename the name of the DepartmentKey. And, in the box labeled "Home to Query", the user provides the location information of the Department object for resolution of the object reference at run-time. In the preferred embodiment, such location information can be provided at runtime. Like in previous Figures, the user has the option to refresh the user interface using the "Refresh" button and to delete the DepartmentKey using the "Delete" key. Functions that are grayed out are unavailable on this graphical user interface.
Referring to Figure 8, a graphical user interface like that of Figure 7 is shown of the mapping of attributes between the Employee data object and the Employee persistent object but with the DepartmentNumber key attribute of the DepartmentKey is highlighted. In this case, the details of the DepartmentNumber key attribute are shown in the graphical user interface.
In the box labeled "Data Object Attribute", the name of the DepartmentNumber key attribute is shown - appropriately it is called DepartmentNumber. In the box labeled "Type", the data type of the DepartmentNumber key attribute is shown, namely string and in the box labeled "Size" the size of type is shown, namely 18 characters. Additionally, the user may designate a mapping helper class and its associated methods in the "Mapping Helper Class" boxes on the graphical user interface of Figure 8 to facilitate translating data between the Employee data object and the Employee persistent object. For example, the user application may be written in C++ but make access to legacy data in an IBM CICS~
system. Such access may require translation of data types and the mapping helper class facilitates such translation. Like in previous Figures, the user may refresh the user interface using the "Refresh"
button.
In Figure 9, a graphical user interface like that of Figures 7 and 8 is shown of the mapping of attributes between the Employee data object and the Employee persistent object but in this case the EmployeePO attribute, iPO.deptnum, corresponding to the DepartmentNumber key attribute of the DepartmentKey is highlighted. In this case, the details of iEmployeePO.DepartmentNumber are shown in the graphical user interface. In the box labeled "Type", the data type of the attribute is shown, namely char. Further, in the box labeled "Size", the data type size of the attribute is specified - in this case 19 characters. Like in previous Figures, the user may refresh the user interface using the "Refresh" button. The user may also delete the attribute mapping by using the "Delete" button.
Thus, in the preferred embodiment, the attributes of the object reference to the Department object are stored in the Employee object. Indeed, in the present example, the Employee object contains the object reference DepartmentRef comprising the attribute DepartmentKey. In turn, the attribute DepartmentKey comprises the key attributes DepartmentNumber and LocationNumber which are mapped to corresponding persistent object attributes iEmployeePO.DepartmentNumber and iEmployeePO.LocationNumber respectively. Object Builder provides the actual translation and corresponding code automatically, tasks apparent to those skilled in the art.
Once all the objects have been completed (including all relevant mappings), the objects can be deployed into an application. In the preferred embodiment, the objects are created using the Object Builder as described above resulting in the creation of data access code that employs a key retrieval mechanism. In a distributed system, the home (location) needs to be identified for the key in order for the Component Broker tool to locate and access the keyed objects.
In the preferred embodiment, this type of location/path information can be resolved at runtime and is configurable.
A simple non-distributed system could have this information hard coded into the data access code.
Referring then to Figure 10, a portion of the Object Builder code is shown that resolves the object reference of a source object (Source) to a referent target obj ect (Target).
The first portion of the code labeled Part One makes a key for the Target out of the data in the Source and the second portion of the code labeled Part Two turns that key into a reference to the real object.
Thus, an object reference is treated like a simple attribute and thus a simple user interface metaphor showing the object reference as an attribute can "hide" the complex code that is required for this common coding paradigm. Indeed, the object reference attribute may contain several parts, as shown in Figures 7-9, each part also being treated like a simple attribute.
Like simple data types, the object reference attribute (and its parts) may be mapped to other object attributes and, directly or indirectly, mapped to corresponding data. Accordingly, in the Object Builder, the complete relational definition for the obj ect reference can be resolved and shown although the obj ect reference attribute itself looks like any other simple attribute.
Further, the Object Builder automatically determines attribute mappings (which are user configurable) and generates corresponding accessor code. Accordingly, an object reference may be easily established without detailed implementation. Manual coding is not required thus providing advantages of speed and consistency.
The detailed descriptions may have been presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. They may be implemented in hardware or software, or a combination of the two.
A procedure is here, and generally, conceived to be a self consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, objects, attributes or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator.
No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention; the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or similar devices.
Each step of the method may be executed on any general computer, such as a mainframe computer, personal computer or the like and pursuant to one or more, or a part of one or more, program modules or objects generated from any programming language, such as C++, Java, Fortran or the like. And still further, each step, or a file or object or the like implementing each step, may be executed by special purpose hardware or a circuit module designed for that purpose.
In the case of diagrams depicted herein, they are provided by way of example.
There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.
While the description herein may refer to interactions with the user interface by way of, for example, computer mouse operation, it will be understood that within the present invention the user is provided with the ability to interact with these graphical representations by any known computer interface mechanisms, including without limitation pointing devices such as computer mouses or trackballs, joysticks, touch screen or light pen implementations or by voice recognition interaction with the computer system.
While the preferred embodiment of this invention has been described in relation to the C++
language and CORBA, this invention need not be solely implemented using the C++ language and/or CORBA. It will be apparent to those skilled in the art that the invention may equally be implemented in other computer languages, such as object oriented languages like Sun Microsystems' JavaTM and Smalltalk and/or other architectures and specifications, for creating, distributing, and managing distributed program objects in a network distributed computing, such as the Distributed Component Object Model (DCOM).
The invention is preferably implemented in a high level procedural or object-oriented programming language to communicate with a computer. However, the invention can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
While aspects of the invention relate to certain computer language and other technological specifications (e.g. the CORBA specification), it should be apparent that classes, objects, components and other such software and technological items referenced herein need not fully conform to the specifications) defined therefor but rather may meet only some of the specification requirements. Moreover, the classes, objects, components and other such software and technological items referenced herein may be defined according to equivalent specifications) other than as indicated herein that provides equivalent or similar functionality, constraints, etc. For example, instead of the CORBA specification, classes, objects, components and other such software and technological items referenced herein may be defined according to Microsoft Corporation's DCOMTM specification where applicable and appropriate.
The invention may be implemented as an article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method steps of the invention, a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the method steps of the invention, or a computer program product. Such an article of manufacture, program storage device or computer program product may include, but is not limited to, CD-ROMs, diskettes, tapes, hard drives, computer RAM or ROM and/or the electronic, magnetic, optical, biological or other similar embodiment of the program. Indeed, the article of manufacture, program storage device or computer program product may include any solid or fluid transmission medium, magnetic or optical, or the like, for storing or transmitting signals readable by a machine for controlling the operation of a general or special purpose programmable computer according to the method of the invention and/or to structure its components in accordance with a system of the invention.
The invention may also be implemented in a system. A system may comprise a computer that includes a processor and a memory device and optionally, a storage device, an output device such as a video display and/or an input device such as a keyboard or computer mouse. Moreover, a system may comprise an interconnected network of computers. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such a cellular telephone). The system may be specially constructed for the required purposes to perform, for example, the method steps of the invention or it may comprise one or more general purpose computers as selectively activated or reconfigured by a computer program in accordance with the teachings herein stored in the computer(s). The procedures presented herein are not inherently related to a particular computer system or other apparatus. The required structure for a variety of these systems will appear from the description given.
While this invention has been described in relation to preferred embodiments, it will be understood by those skilled in the art that changes in the details of construction, arrangement of parts, compositions, processes, structures and materials selection may be made without departing from the spirit and scope of this invention. Many modifications and variations are possible in light of the above teaching. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation and that the specification and drawings) are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
FIELD OF THE INVENTION
This invention relates to representing a data mapping of an object reference.
Particularly, the invention relates to graphically representing an object reference to a referent object by a referring object including associated data mapping between attributes of the objects and the corresponding data of the objects.
BACKGROUND OF THE INVENTION
As part of the development of software applications, software programmers have been provided new tools to facilitate rapid application development, such as visual application development tools and incremental compilers. A new breed of rapid application tools involves component-based development. Components may be loosely defined as software packages that contain a collection of related services and attributes that are typically discrete and hence re-usable.
Component-based development tools provide the ability to connect together these components to develop a software application. An example of such a tool is the IBM~
Component BrokerTM
product which is intended to be used by large enterprises that employ large numbers of developers in creating enterprise applications using components.
The Component Broker product provides a runtime, development and server management system that supports developing and executing distributed object-oriented applications in a client/server environment. It can provide a programming model, framework, tools and object class libraries and components to develop distributed applications, a runtime to execute the applications and systems management for the administration of the components.
The Component Broker product allows for the operation, creation and organization of business objects. A business object represents a business function and encapsulates in software the knowledge about real-world artifacts such as customers, accounts, bank transactions, ledgers, and so forth. Business objects deal with the business logic, rules, and constraints as defined by a specific domain. To that end, business objects comprise attributes that define the state ofthe business object and a method embodied in software that defines the behavior of the business object. Further, business objects typically have relationships with other business objects allowing them to be combined to perform a specific task. Typical examples of business objects are customer, invoice or account objects which can be combined to form, for example, a billing application. Business objects need not directly address user-interface aspects of a particular usage scenario or application. Neither need they be concerned with data storage technology. Ideally, they are usage and technology independent, reusable software building blocks. This is in stark contrast to procedural software, which was prone to intermingle all these aspects.
Related to the business object in the Component Broker product is the data object. A data object is responsible for managing the persistence of a business object's essential state information.
It manages essential state information by providing a business object with an interface for getting and setting all of the essential state information. Each attribute in a business object can correspond to zero or more attributes in a data object. A data object also isolates a business object from having to know which of many datastores to use to make its state persistent. It also isolates the business object from having to know how to access the datastore, and from having to manage the access.
Another object related to the data object in the Component Broker product is the persistent object. A persistent object provides a mechanism for storing an object's state in a datastore. Every persistent object has an identifier or a key that is used for locating its corresponding record within the datastore. There are two kinds of persistent objects in Component Broker:
database persistent objects and procedural adapter persistent objects. Database persistent objects represent a record of a table or a view in a relational database. The component's state data that is stored in the relational database by means of a persistent object lasts longer than the execution time of the application that calls the component. In a relational database such as a SQL database, all records are persistent because they are stored on a storage means, such as a disk, in the form of database tables. A
datastore, whether it is an object-oriented database management system or a relational database management system, stores an object's persistent data. A procedural adapter persistent object encapsulates not only the data associated with an application but also the application's transaction logic. It is usually an embodiment of an IMS~ and/or CICS~ transaction and corresponding data.
A feature of the Component Broker product is the Object Builder. The Object Builder facilitates creating business objects conforming to a programming model and based on a managed object framework of Component Broker. The Component Broker also facilitates creating the associated objects to a business object such as the data object and the persistent object. Functioning business objects in the Component Broker environment are referred to as managed objects each of which comprise: i) a business object class containing the fundamental business logic for the managed object; ii) the business object's associated data object which defines the essential data for the object;
and iii) the implementation binding that wrappers the business object and associates it with the required object services provided by a given instance manager. An instance manager provides a home for instances of managed objects much like a database system or file system provides a home for records and files. It is essentially an object-oriented database, responsible for providing system capabilities for its managed object instances. The role of Object Builder is to support the definition and/or automatic creation of all of the classes needed to produce a fully functional managed object.
Often when developing object-oriented programs such as applications using the business and other types of objects of the Object Builder, developers will make use of an object reference, a standard programming technique in object-oriented programming. Typically when a developer creates an object reference, the user must provide the detailed mapping coding that is required to create such a reference. That is, the user replicates the referent object table accessor code in the referring object. Accordingly, the reference code for the referent object directly accesses the object that facilitates persistence for the referent object or alternatively the referring object contains code inline that facilitates persistence for the referent object. The disadvantages of this method include i) having duplicated code which can lead to error prone implementations and ii) by not resolving the reference in object space, having multiple copies of the object in an unmanaged fashion which may leave it open to data corruption problems or database deadlock. Further, from a user interface perspective, it is common to provide a place for the user to specify the detailed implementation via an edit function. In some cases, the edit function provides sample mapping code as described above.
However, the user must perform the often tedious and sometimes error prone task of manual coding (or recoding the sample code) to create the object reference.
It is therefore desirable to provide a method, system and article of manufacture comprising a computer usable medium having computer readable program code means therein for graphically representing a data mapping of an object reference that can overcome some or all of the foregoing and other disadvantages of application development techniques.
SUMMARY OF THE INVENTION
Accordingly, there is provided new and useful methods, systems and articles of manufacture comprising a computer usable medium having computer readable program code means therein for graphically representing a data mapping of an object reference.
There is provided a method for representing an object reference to a referent object in a computer environment, comprising the steps of providing a user interface for a referring object; and in said user interface, providing a key icon representing a key for the referent object of said object reference. The above method may be further provided wherein providing the key icon comprises providing a key part corresponding to a referent object attribute of the key for the referent object.
This method may further comprise the step of matching the referent object attribute to an attribute that corresponds to data. And, the step of matching may comprise matching by comparing a name of the referent object attribute and a name of said attribute. The above methods may further comprise the step of automatically generating code corresponding to the object reference. This method may also be provided wherein the step of automatically generating code comprises generating accessor code for data access using key retrieval. The above methods may also be provided wherein the step of providing a key icon comprises providing the key icon as an attribute in a graphical menu for attributes of the referring object. Further, the above methods may comprise providing key information corresponding to the key in the user interface. This method may also be provided wherein providing key information comprises providing, upon selection of the key icon by a user, key name and home location information pertaining to the key in the user interface, said key name and home location information selectively modifiable by the user. Also, there may be provided the above methods wherein the step of providing a key icon comprises automatically locating the referent object and retrieving the key of the referent object.
Further there is provided a method for representing an object reference to a referent object in a computer environment, comprising the steps of providing a graphical tree of attributes of a referring object in a user interface; and automatically providing an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
The above method may be further provided wherein said step of automatically providing comprises locating the referent obj ect and retrieving the key of the referent obj ect.
And, the above methods may further comprise the step of generating code corresponding to the object reference.
Also provided are computer program products for executing any of the above methods. And articles of manufacture comprising a computer usable medium having computer readable program code means therein for executing any of the above methods. Further, articles of manufacture comprising a computer usable medium having computer readable program code means therein for representing an object reference to a referent object in a computer environment, the computer readable program code means in said computer program product comprising computer readable code means for causing a computer to execute the method steps of the above methods.
A computer system for representing an object reference to a referent object in a computer environment is also provided comprising means for providing a user interface for a referring object;
and means for providing, in said user interface, a key icon representing a key for the referent object of said object reference. The above computer system may be further provided wherein the means for providing the key icon comprises means for providing a key part corresponding to a referent obj ect attribute of the key for the referent object. The above computer systems may also comprise means for automatically generating code corresponding to the object reference. And, the computer systems above may be provided wherein the means for providing a key icon comprises means for providing the key icon as an attribute in a graphical menu for attributes of the referring object. And, the above computer systems may be provided wherein the means for providing a key icon comprises means for automatically locating the referent object and retrieving the key of the referent object.
And, there is provided a computer system for representing an obj ect reference to a referent object in a computer environment, comprising means for providing a graphical tree of attributes of a referring object in a user interface; and means for automatically providing an object reference attribute in said tree corresponding to the obj ect reference, said obj ect reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object. The above computer system may also be provided wherein the means for automatically providing comprises means for locating the referent object and retrieving the key of the referent object. Further, the computer systems above may further comprise means for generating code corresponding to the object reference.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar or corresponding elements and in which:
Figure 1 is a schematic diagram of an Employee object and a Department object;
Figure 2 is a representation of sample data corresponding to the attributes of the Employee and Department objects of Figure 1;
Figure 3 is a depiction of the graphical user interface of the Object Builder showing the type of the Employee object of Figure 1 with the attribute EmployeeName highlighted;
Figure 4 is a depiction of the graphical user interface ofthe Object Builder showing the type of the Employee object of Figure 1 with the attribute DepartmentRef highlighted;
Figure 5 is a depiction of the graphical user interface of the Object Builder showing the mapping of the persistent object corresponding to the Employee object of Figure 1 to a relational database corresponding to the Employee data of Figure 2;
Figure 6 is a depiction of the graphical user interface of the Object Builder showing the mapping of the persistent object corresponding to the Department object of Figure 1 to a relational database corresponding to the Department data of Figure 2;
Figure 7 is a depiction of the graphical user interface of the Object Builder showing the attributes mapping between the data object and the persistent object corresponding to the Employee object of Figure 1 with the DepartmentKey menu highlighted;
Figure 8 is a depiction of the graphical user interface of the Object Builder showing the attributes mapping between the data object and the persistent object corresponding to the Employee object of Figure 1 with the DepartmentNumber key attribute highlighted;
Figure 9 is a depiction of the graphical user interface of the Object Builder showing the attributes mapping between the data object and the persistent object corresponding to the Employee object of Figure 1 with the EmployeePO attribute (iPO.deptnum) corresponding to the DepartmentNumber key attribute highlighted;
Figure 10 is a portion of the Object Builder code for resolving an object reference of a source object (Source) to a referent target object (Target); and Figure 11 is SQL code representing the schema of the Employee and Department data of Figure 2.
DETAILED DESCRIPTION OF THE INVENTION
A preferred embodiment of the present invention will be described which provides for representing a data mapping of an object reference.
It is common for an object to have a reference to another object, especially in a distributed object system. Referring to Figure 1, an example of an object reference is depicted using an Employee object (e.g. to represent an employee of a company) and a referent Department object (e.g.
to represent a department within a company). As shown in Figure 1, the Employee object has a number of attributes including number (corresponding to the employee's identifying number in the company), name (corresponding to the employee's name), deptnum (corresponding to the employee's department number in the company), locnum (corresponding to the employee's location number) and sin (corresponding to the employee's Social Insurance Number /
Social Security Number). Further, the Department object has a number of attributes including deptnum (corresponding to the department's department number in the company), locnum (corresponding to the department's location number), address (corresponding to the department's address) and deptname (corresponding to the department's name). Further, attributes deptnum and locnum in the Employee object are indicated as being foreign keys (FK) which correspond to the same attributes in the Department object. Hence, there is an object reference from the Employee object to the referent Department object. It should be apparent to those skilled in the art that different types and numbers of objects, attributes and object references can be used in accordance with the invention.
Indeed, an object may have more than one object reference.
A common manner to represent an object reference is to provide the reference to a referent object as an attribute or property of the referring object. In the present example, attributes deptnum and locnum of the Employee object (the referring object) form the object reference to the Department object (the referent object) and its attributes. In this way, access can be made in the Employee object to the attributes of the Department object including the attributes deptnum, locnum, address and deptname.
Important to the use of the object reference is the notion of keys. An object reference comprises some form of location information for the referent object and some form of identity for the referent object. To that end, the location information of the referent object in a computer system is provided by a user and can be configurable or fixed. Location is not enough because there needs to be a way to identify an object, in the location, from other objects. To identify the referent object, a key is used. As shown in Figure 1 by the dividing line, the attributes number and name are designated as keys (by a user) for the Employee object. Similarly, attributes deptnum and locnum are designated as keys (by a user) for the Department object. Keys are used as identifiers of an object. Particularly, when a object reference is made, the reference uses a keys) to identify and locate an object. In this case, attributes deptnum and locnum of the Employee object are the foreign keys used to identify and locate the Department object, which has those key attributes - deptnum and locnum.
Further, the attributes of the Employee and Department objects may correspond to a record of a table or a view in a relational database. Sample data that corresponds to the attributes of the S Employee and Department objects are shown in Figure 2. Such data may be persisted and may be a database store although it should be apparent to those skilled in the art that the invention may equally be implemented using other than persisted data or database stores such as data stored temporarily in random access memory or on-line data communicated directly via electronic or other means. Referring to Figure 2, it can be seen that the attributes of Employee object have corresponding data. In this set of sample data, the number, name, deptnum, locnum and sin attributes have correspondingly named columns in this database store and relevant data beneath. Indeed, the key attributes to the Department object, deptnum and locnum, have corresponding data (and columns) in the table. Of course, the column names need not be identical to the object attribute names but rather, as discussed later, the attributes can be mapped to the columns even though the names are not identical. Further, the corresponding data to the Department object attributes are shown wherein the column names and attribute names of the Department object correspond accordingly. In a typical example, the schema for the Employee and/or Department sample data would be stored in a SQL Data Definition Language (DDL) file. The SQL code representing the schema of the Employee and Department data of the example described herein is provided in Figure 11.
Hereafter, the preferred embodiment of the invention is described using the example Employee and Department objects heretofore defined. Further, the invention is described in the context of the Object Builder and in terms of business, data and persistent objects. It should be apparent to those skilled in the art that any type of object may be used;
objects need not conform to the business, data and persistent objects model described above. Further, the invention need not only be implemented in programs like Obj ect Builder. The invention may equally be used in a wide range of other programs including other types of application development tools. And, objects used with the invention may represent other than employee and/or department data or logic. There are no bounds on what the objects may represent.
Using the Object Builder, a corresponding Employee business object to the Employee object and a corresponding Department business object to the Department object of Figure 1 can be created that can access the sample data in Figure 2. By using the Object Builder, a user can define the Employee and Department business object interfaces.
Referring to Figure 3, the Employee business object interface is shown in the graphical user interface of the Object Builder. As indicated, the attributes of the Employee business object type are shown in a graphical menu tree manner with the menu or folder Attributes shown in an open fashion with the attributes of the Employee business object shown therebelow as rungs.
Particularly, the simple attributes EmployeeNumber, EmployeeName, and SINSSN are shown along with the object reference attribute DepartmentRef in accordance with the invention and described further below. In this example, different attribute names were chosen than as shown in Figure 1 to facilitate showing attribute mapping although for ease the Employee and Department business objects may have attribute names that correspond exactly to the attribute names of Figure 1.
By clicking on the Attributes menu, a user can return the Attributes menu to a closed position thereby hiding the attribute rungs in the graphical user interface of Figure 3. Closing the Attributes menu does not delete the attributes from the Employee business object; closing simply hides the attributes from the user's graphical user interface and they can be returned to view by clicking the Attributes folder into an open position. Further, the EmployeeName attribute is highlighted thereby revealing the details associated with that attribute. As is self evident in Figure 3, the attribute name of the EmployeeName attribute is shown in the box labeled "Attribute Name".
Similarly, the data type of the attribute EmployeeName, namely string, is shown in the box labeled "Type".
By clicking on the appropriate rungs in the menu, the user highlights an attribute and thereby exposes the details of the highlighted attribute. With the details shown, the user can configure the highlighted attribute by modifying the data in the boxes and clicking on the buttons/checkboxes shown. Indeed, a user can add an attribute to the Employee business object by clicking on the "Add Another" button and/or delete an attribute from the Employee business object by highlighting the attribute to be deleted in the menu and clicking on the "Delete" button.
Further, the user can refresh the attribute data and menu by clicking on the "Refresh" button. Optionally, the user interface also allows an initializer value to be assigned to the highlighted attribute, the highlighted attribute to be designated as read-only, the highlighted attribute to be overrideable by a subclass and the string behavior to be defined. Using these user interface features, the Employee business object interface may be constructed and configured. While not shown in the Figures, the Department business object interface can equally be represented and constructed.
While the user constructs and configures the Employee business object, the Object Builder automatically prepares the appropriate computer language code (in this case C++ although it would be apparent to those skilled in the art that code could be generated in other computer languages such as Sun Microsystems, Inc.'s Java TM language) for the business object. The Object Builder also allows the user to create the Employee and Department business object implementations as well as the Employee and Department data object interfaces and implementations corresponding to the respective business obj ects (not shown). Additionally, the user specifies a key for the Employee and Department business objects by selecting the attributes of the respective business object that should form the key for that business object (not shown). Using this key, object references can be resolved.
In Figure 4, the type of the Employee business object is again shown in the graphical user interface of the Object Builder. In this case, the DepartmentRef attribute, the object reference, is highlighted and its details are shown. Like in Figure 3, the attribute name of the Department object reference, DepartmentRef, is shown in the box labeled "Attribute Name". In the box labeled "Type", it is indicated that DepartmentRef is an object reference, particularly to the object Sample Department. In the preferred embodiment, the Object Builder recognizes the use of an object name in the "Type" box as an object reference and treats it accordingly using CORBA
conventions. Object Management Group's CORBA (or Common Object Request Broker Architecture) is an architecture and specification, for creating, distributing, and managing distributed program objects in a network.
It will be apparent to those skilled in the art that other distributed application architectures and specifications, such as Microsoft's DCOM, may be used. Although the preferred embodiment treats the object reference in accordance with distributed architecture conventions, it should be apparent to those skilled in the art that distributed object conventions are not required and such object references may be local. Again, the user optionally may add another attribute, delete an attribute, designate the attribute as read-only, and designate the attribute as overrideable by a subclass as described above.
Along with the Employee and Department business objects and data objects, the persistent objects corresponding to the sample data (in the preferred embodiment, persisted in a database) of Figure 2 are created in the preferred embodiment of the present invention. As described above, the schema for this sample data could be stored in a SQL Data Definition Language (DDL) file and the SQL DDL file could be imported into the Object Builder to create a persistent object from the schema. The SQL code representing the schema of the Employee and Department data of the example described herein is provided in Figure 11.
Referring to Figure 5, the persistent object corresponding to the Employee data table of Figure 2 is shown. The name of this persistent object, EmployeePO is shown in the box titled "Name" and is indicated, with a check in the "Table is Updatable" checkbox of Figure 5, as being updateable i.e. data can be written to the table. Whether the table is updateable is user selectable.
Under the heading "PO Attribute" of Figure 5 are listed the various attributes defined for the EmployeePO persistent object, namely name, number, deptnum, locnum and sin. If importing an SQL DDL file to create the persistent object, Object Builder by default uses the column names from the SQL DDL file to create the EmployeePO attribute names (as shown in Figure 5). The EmployeePO attribute names may be renamed by the user in the graphical user interface of Figure 5. Notably, the number of attributes listed can be more or less than the number of columns in the data table. Indeed, not all columns in the data table need to have corresponding persistent object attributes nor does every persistent object require a corresponding column in the data table. In this case there is a direct match between persistent object attributes and columns in the data table.
Next to the "PO Attribute" heading in Figure 5 is the "Attribute Type" heading which provides the data type corresponding to each of the EmployeePO attributes listed under the "PO
Attribute" heading. Like the EmployeePO attribute names, such information is drawn from the SQL
DDL file if such a file is used to create the persistent object. Continuing along the headings is the "PO Key" heading under which are provided checkboxes to indicate whether the corresponding EmployeePO attribute is a key. If the schema was imported from a SQL DDL file, the Object Builder automatically checks the appropriate key checkboxes if the DDL file indicates which columns are keys. Again, the user can redefine those keys which, as described above, are used as an identifier of an object, in this case, the EmployeePO persistent object. In Figure 5, the PO
key checkboxes are checked for the number and name attributes indicating that these two attributes form the key for the EmployeePO persistent object. The last heading titled "Column Name" lists the actual data table columns that map to the corresponding EmployeePO attributes. Additionally, Figure 5 indicates the package file name in which the EmployeePO is contained, the name of the file containing the schema for the Employee data table ("Database.Employee") and the type of persistence used.
Referring to Figure 6, the persistent object corresponding to the Department data table of Figure 2 is shown, much like the persistent object corresponding to the Employee data table was shown in Figure 5. The name of this persistent object, DepartmentPO is shown in the box titled "Name" and is indicated, with a check in the ''Table is Updatable" checkbox of Figure 6, as being updateable i.e. data can be written to the table. Whether the table is updateable is user selectable.
Further, under the heading "PO Attribute" of Figure 6 are listed the various attributes defined for the DepartmentPO persistent object, namely deptnum, locnum, address and deptname. If importing an SQL DDL file to create the persistent object, Object Builder by default uses the column names from the SQL DDL file to create the DepartmentPO attribute names (as is shown in Figure 6). The DepartmentPO attribute names may be renamed by the user in the graphical user interface of Figure 6.
Next to the "PO Attribute" heading in Figure 6 is the "Attribute Type" heading which provides the data type corresponding to each of the DepartmentPO attributes listed under the "PO
Attribute" heading. Like the DepartmentPO attribute names, such information is drawn from the SQL DDL file if such a file is used to create the persistent object.
Continuing along the headings is the "PO Key" heading under which are provided checkboxes to indicate whether the corresponding DepartmentPO attribute is a key. If the schema was imported from a SQL DDL
file, the Object Builder automatically checks the appropriate key checkboxes if the DDL file indicates which columns are keys. Again, the user can redefine those keys. In Figure 6, the PO
key checkboxes are checked for the deptnum and locnum attributes indicating that these two attributes form the key for the DepartmentPO persistent object. The last heading titled "Column Name"
lists the actual data table columns that map to the corresponding DepartmentPO attributes.
Additionally, Figure 6 indicates the package file name in which the DepartmentPO is contained, the name of the file containing the schema for the Department data table ("Database.Department") and the type of persistence used.
Returning to the object reference DepartmentRef created in the Employee business object, the Object Builder facilitates establishing the data mapping of the object reference and representing the object reference in the graphical user interface of the Object Builder.
Referring to Figure 7, there is shown in a graphical user interface the mapping between the attributes of the Employee data object and corresponding Employee persistent object attributes. Although not shown, there is a similar graphical user interface showing the mapping between the attributes of the Department data object and the Department persistent object. Like Figure 4, the Employee attributes are shown in a graphical menu tree fashion with the menu or folder Attributes in an open position revealing the attributes of the Employee data object as rungs therebelow.
Each rung in the menu corresponds to an attribute of the Employee data object (and correspondingly to the attributes of the Employee business object) and is a menu itself shown in an open position. For the simple data types, the graphical user interface reveals the mapping of that attribute of the Employee data object to the corresponding attribute of the Employee persistent object. Referring to Figure 7, attribute EmployeeNumber is shown mapped to iPO.number, the corresponding attribute in the EmployeePO (in this case iPO.number corresponds to iEmployeePO.number but the "Employee" moniker has been dropped in the user interface by Object Builder for readability and convenience because the user will appreciate that the Employee data object attributes are being mapped to the Employee persistent object attributes) . Similarly, attribute EmployeeName is shown mapped to iPO.name and attribute SINSSN is shown mapped to iPO.sin.
In the preferred embodiment, such mapping is automatically determined by matching the Employee data object attribute names with the attribute names for the Employee persistent object to establish a match. It should be apparent to those skilled in the art that other forms of matching can be used such as matching by identification number. Incorrect matches can be altered by the user entering the correct Employee persistent object attribute name in the "Persistent Object Attribute" box shown in Figure 9 or deleting the mapping if appropriate.
Like the simple data type attributes just described, the object reference, DepartmentRef, in the Employee data object is shown as an attribute. However, an object reference receives different treatment from a simple data type attribute, particularly in the graphical user interface. Knowing that DepartmentRef is an object reference because of its definition above in Figure 4, Object Builder provides a DepartmentKey menu (signified by a key icon) in the graphical user interface of Figure 7 that contains the Department key attributes. Object Builder searches through its object repository to find the referent object - Department - to retrieve the keys of the Department object.
As defined for the Department business object earlier (not shown), attributes DepartmentNumber and LocationNumber of the Department object form the Department object's key. Using those Department keys, the attributes of the Employee data object that correspond to the Department key attributes are resolved. In the preferred embodiment, such resolution is determined by matching the Department key attribute names with the attribute names of the Employee persistent object. Accordingly, DepartmentNumber and LocationNumber are identified in the Employee persistent object and the mapping is shown in the graphical menu tree of Figure 7.
Thus, the DepartmentKey menu of the Employee data obj ect shows, in the open position, the key attributes DepartmentName and LocationNumber of the Employee data object as menus therebelow. Each of the DepartmentName and LocationNumber key attributes are further shown in an open position to reveal the mapping of the DepartmentName and LocationNumber attributes of the data object to the corresponding Employee persistent object attributes.
Accordingly, when the Employee data object is created, the Object Builder automatically determines and provides in the Employee data object the corresponding attributes in the Employee data object that reconcile the object reference in the Employee business object with the attributes, including key attributes, ofthe Employee and Department persistent objects. Incorrect matches can be altered by the user entering the correct Employee persistent object attribute name in the "Persistent Object Attribute" box shown in Figure 9 or deleting the mapping if required.
Finishing with Figure 7, the DepartmentKey menu is shown highlighted and the corresponding detailed information is provided. In the box labeled "Key", the user can rename the name of the DepartmentKey. And, in the box labeled "Home to Query", the user provides the location information of the Department object for resolution of the object reference at run-time. In the preferred embodiment, such location information can be provided at runtime. Like in previous Figures, the user has the option to refresh the user interface using the "Refresh" button and to delete the DepartmentKey using the "Delete" key. Functions that are grayed out are unavailable on this graphical user interface.
Referring to Figure 8, a graphical user interface like that of Figure 7 is shown of the mapping of attributes between the Employee data object and the Employee persistent object but with the DepartmentNumber key attribute of the DepartmentKey is highlighted. In this case, the details of the DepartmentNumber key attribute are shown in the graphical user interface.
In the box labeled "Data Object Attribute", the name of the DepartmentNumber key attribute is shown - appropriately it is called DepartmentNumber. In the box labeled "Type", the data type of the DepartmentNumber key attribute is shown, namely string and in the box labeled "Size" the size of type is shown, namely 18 characters. Additionally, the user may designate a mapping helper class and its associated methods in the "Mapping Helper Class" boxes on the graphical user interface of Figure 8 to facilitate translating data between the Employee data object and the Employee persistent object. For example, the user application may be written in C++ but make access to legacy data in an IBM CICS~
system. Such access may require translation of data types and the mapping helper class facilitates such translation. Like in previous Figures, the user may refresh the user interface using the "Refresh"
button.
In Figure 9, a graphical user interface like that of Figures 7 and 8 is shown of the mapping of attributes between the Employee data object and the Employee persistent object but in this case the EmployeePO attribute, iPO.deptnum, corresponding to the DepartmentNumber key attribute of the DepartmentKey is highlighted. In this case, the details of iEmployeePO.DepartmentNumber are shown in the graphical user interface. In the box labeled "Type", the data type of the attribute is shown, namely char. Further, in the box labeled "Size", the data type size of the attribute is specified - in this case 19 characters. Like in previous Figures, the user may refresh the user interface using the "Refresh" button. The user may also delete the attribute mapping by using the "Delete" button.
Thus, in the preferred embodiment, the attributes of the object reference to the Department object are stored in the Employee object. Indeed, in the present example, the Employee object contains the object reference DepartmentRef comprising the attribute DepartmentKey. In turn, the attribute DepartmentKey comprises the key attributes DepartmentNumber and LocationNumber which are mapped to corresponding persistent object attributes iEmployeePO.DepartmentNumber and iEmployeePO.LocationNumber respectively. Object Builder provides the actual translation and corresponding code automatically, tasks apparent to those skilled in the art.
Once all the objects have been completed (including all relevant mappings), the objects can be deployed into an application. In the preferred embodiment, the objects are created using the Object Builder as described above resulting in the creation of data access code that employs a key retrieval mechanism. In a distributed system, the home (location) needs to be identified for the key in order for the Component Broker tool to locate and access the keyed objects.
In the preferred embodiment, this type of location/path information can be resolved at runtime and is configurable.
A simple non-distributed system could have this information hard coded into the data access code.
Referring then to Figure 10, a portion of the Object Builder code is shown that resolves the object reference of a source object (Source) to a referent target obj ect (Target).
The first portion of the code labeled Part One makes a key for the Target out of the data in the Source and the second portion of the code labeled Part Two turns that key into a reference to the real object.
Thus, an object reference is treated like a simple attribute and thus a simple user interface metaphor showing the object reference as an attribute can "hide" the complex code that is required for this common coding paradigm. Indeed, the object reference attribute may contain several parts, as shown in Figures 7-9, each part also being treated like a simple attribute.
Like simple data types, the object reference attribute (and its parts) may be mapped to other object attributes and, directly or indirectly, mapped to corresponding data. Accordingly, in the Object Builder, the complete relational definition for the obj ect reference can be resolved and shown although the obj ect reference attribute itself looks like any other simple attribute.
Further, the Object Builder automatically determines attribute mappings (which are user configurable) and generates corresponding accessor code. Accordingly, an object reference may be easily established without detailed implementation. Manual coding is not required thus providing advantages of speed and consistency.
The detailed descriptions may have been presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. They may be implemented in hardware or software, or a combination of the two.
A procedure is here, and generally, conceived to be a self consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, objects, attributes or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator.
No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention; the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or similar devices.
Each step of the method may be executed on any general computer, such as a mainframe computer, personal computer or the like and pursuant to one or more, or a part of one or more, program modules or objects generated from any programming language, such as C++, Java, Fortran or the like. And still further, each step, or a file or object or the like implementing each step, may be executed by special purpose hardware or a circuit module designed for that purpose.
In the case of diagrams depicted herein, they are provided by way of example.
There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.
While the description herein may refer to interactions with the user interface by way of, for example, computer mouse operation, it will be understood that within the present invention the user is provided with the ability to interact with these graphical representations by any known computer interface mechanisms, including without limitation pointing devices such as computer mouses or trackballs, joysticks, touch screen or light pen implementations or by voice recognition interaction with the computer system.
While the preferred embodiment of this invention has been described in relation to the C++
language and CORBA, this invention need not be solely implemented using the C++ language and/or CORBA. It will be apparent to those skilled in the art that the invention may equally be implemented in other computer languages, such as object oriented languages like Sun Microsystems' JavaTM and Smalltalk and/or other architectures and specifications, for creating, distributing, and managing distributed program objects in a network distributed computing, such as the Distributed Component Object Model (DCOM).
The invention is preferably implemented in a high level procedural or object-oriented programming language to communicate with a computer. However, the invention can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
While aspects of the invention relate to certain computer language and other technological specifications (e.g. the CORBA specification), it should be apparent that classes, objects, components and other such software and technological items referenced herein need not fully conform to the specifications) defined therefor but rather may meet only some of the specification requirements. Moreover, the classes, objects, components and other such software and technological items referenced herein may be defined according to equivalent specifications) other than as indicated herein that provides equivalent or similar functionality, constraints, etc. For example, instead of the CORBA specification, classes, objects, components and other such software and technological items referenced herein may be defined according to Microsoft Corporation's DCOMTM specification where applicable and appropriate.
The invention may be implemented as an article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method steps of the invention, a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the method steps of the invention, or a computer program product. Such an article of manufacture, program storage device or computer program product may include, but is not limited to, CD-ROMs, diskettes, tapes, hard drives, computer RAM or ROM and/or the electronic, magnetic, optical, biological or other similar embodiment of the program. Indeed, the article of manufacture, program storage device or computer program product may include any solid or fluid transmission medium, magnetic or optical, or the like, for storing or transmitting signals readable by a machine for controlling the operation of a general or special purpose programmable computer according to the method of the invention and/or to structure its components in accordance with a system of the invention.
The invention may also be implemented in a system. A system may comprise a computer that includes a processor and a memory device and optionally, a storage device, an output device such as a video display and/or an input device such as a keyboard or computer mouse. Moreover, a system may comprise an interconnected network of computers. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such a cellular telephone). The system may be specially constructed for the required purposes to perform, for example, the method steps of the invention or it may comprise one or more general purpose computers as selectively activated or reconfigured by a computer program in accordance with the teachings herein stored in the computer(s). The procedures presented herein are not inherently related to a particular computer system or other apparatus. The required structure for a variety of these systems will appear from the description given.
While this invention has been described in relation to preferred embodiments, it will be understood by those skilled in the art that changes in the details of construction, arrangement of parts, compositions, processes, structures and materials selection may be made without departing from the spirit and scope of this invention. Many modifications and variations are possible in light of the above teaching. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation and that the specification and drawings) are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Claims (36)
1. A method for representing an object reference to a referent object in a computer environment, comprising the steps of:
providing a user interface for a referring object; and in said user interface, providing a key icon representing a key for the referent object of said object reference.
providing a user interface for a referring object; and in said user interface, providing a key icon representing a key for the referent object of said object reference.
2. The method of claim 1, wherein providing the key icon comprises providing a key part corresponding to a referent object attribute of the key for the referent object.
3. The method of claim 2, further comprising the step of matching the referent object attribute to an attribute that corresponds to data.
4. The method of claim 3, wherein the step of matching comprises matching by comparing a name of the referent object attribute and a name of said attribute.
5. The method of any one of claims 1 to 4, further comprising the step of automatically generating code corresponding to the object reference.
6. The method of claim 5, wherein the step of automatically generating code comprises generating accessor code for data access using key retrieval.
7. The method of any one of claims 1 to 6, wherein the step of providing a key icon comprises providing the key icon as an attribute in a graphical menu for attributes of the referring object.
8. The method of any one of claims 1 to 7, further comprising providing key information corresponding to the key in the user interface.
The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:
1. A method for representing an object reference to a referent object in a computer environment, comprising the steps of:
providing a user interface for a referring object; and in said user interface, providing a key icon representing a key for the referent object of said object reference.
2. The method of claim 1, wherein providing the key icon comprises providing a key part corresponding to a referent object attribute of the key for the referent object.
3. The method of claim 2, further comprising the step of matching the referent object attribute to an attribute that corresponds to data.
4. The method of claim 3, wherein the step of matching comprises matching by comparing a name of the referent object attribute and a name of said attribute.
5. The method of any one of claims 1 to 4, further comprising the step of automatically generating code corresponding to the object reference.
6. The method of claim 5, wherein the step of automatically generating code comprises generating accessor code for data access using key retrieval.
7. The method of any one of claims 1 to 6, wherein the step of providing a key icon comprises providing the key icon as an attribute in a graphical menu for attributes of the referring object.
8. The method of any one of claims 1 to 7, further comprising providing key information corresponding to the key in the user interface.
The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:
1. A method for representing an object reference to a referent object in a computer environment, comprising the steps of:
providing a user interface for a referring object; and in said user interface, providing a key icon representing a key for the referent object of said object reference.
2. The method of claim 1, wherein providing the key icon comprises providing a key part corresponding to a referent object attribute of the key for the referent object.
3. The method of claim 2, further comprising the step of matching the referent object attribute to an attribute that corresponds to data.
4. The method of claim 3, wherein the step of matching comprises matching by comparing a name of the referent object attribute and a name of said attribute.
5. The method of any one of claims 1 to 4, further comprising the step of automatically generating code corresponding to the object reference.
6. The method of claim 5, wherein the step of automatically generating code comprises generating accessor code for data access using key retrieval.
7. The method of any one of claims 1 to 6, wherein the step of providing a key icon comprises providing the key icon as an attribute in a graphical menu for attributes of the referring object.
8. The method of any one of claims 1 to 7, further comprising providing key information corresponding to the key in the user interface.
9. The method of claim 8, wherein providing key information comprises providing, upon selection of the key icon by a user, key name and home location information pertaining to the key in the user interface, said key name and home location information selectively modifiable by the user.
10. The method of any one of claims 1 to 9, wherein the step of providing a key icon comprises automatically locating the referent object and retrieving the key of the referent object.
11. A method for representing an object reference to a referent object in a computer environment, comprising the steps of:
providing a graphical tree of attributes of a referring object in a user interface; and automatically providing an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
providing a graphical tree of attributes of a referring object in a user interface; and automatically providing an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
12. The method of claim 11 wherein said step of automatically providing comprises locating the referent object and retrieving the key of the referent object.
13. The method of claim 11 or claim 12 further comprising the step of generating code corresponding to the object reference.
14. A computer program product for executing the method steps of any one of claims 1 to 13.
15. An article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method steps of any one of claims 1 to 13.
16. An article of manufacture comprising a computer usable medium having computer readable program code means therein for representing an object reference to a referent object in a computer environment, the computer readable program code means in said computer program product comprising:
computer readable code means for causing a computer to provide a user interface for a referring object; and computer readable code means for causing a computer to, in said user interface, provide a key icon representing a key for the referent object of said object reference.
computer readable code means for causing a computer to provide a user interface for a referring object; and computer readable code means for causing a computer to, in said user interface, provide a key icon representing a key for the referent object of said object reference.
17. The article of manufacture of claim 16, wherein the computer readable code means for causing a computer to provide the key icon comprises computer readable code means for causing a computer to provide a key part corresponding to a referent object attribute of the key for the referent object.
18. The article of manufacture of claim 17, further comprising computer readable code means for causing a computer to match the referent object attribute to an attribute that corresponds to data.
19. The article of manufacture of claim 18, wherein the computer readable code means for causing a computer to match comprises computer readable code means for causing a computer to match by comparing a name of the referent object attribute and a name of said attribute.
20. The article of manufacture of any one of claims 16 to 19, further comprising computer readable code means for causing a computer to automatically generate code corresponding to the object reference.
21. The article of manufacture of claim 20, wherein the computer readable code means for causing a computer to automatically generate code comprises computer readable code means for causing a computer to generate accessor code for data access using key retrieval.
22. The article of manufacture of any one of claims 16 to 21, wherein computer readable code means for causing a computer to provide a key icon comprises computer readable code means for causing a computer to provide the key icon as an attribute in a graphical menu for attributes of the referring object.
23. The article of manufacture of any one of claims 16 to 22, further comprising computer readable code means for causing a computer to provide key information corresponding to the key in the user interface.
24. The article of manufacture of claim 23, wherein the computer readable code means for causing a computer to provide key information comprises computer readable code means for causing a computer to provide, upon selection of the key icon by a user, key name and home location information pertaining to the key in the user interface, said key name and home location information selectively modifiable by the user.
25. The article of manufacture of any one of claims 16 to 24, wherein computer readable code means for causing a computer to provide a key icon comprises computer readable code means for causing a computer to automatically locate the referent object and retrieve the key of the referent object.
26. An article of manufacture comprising a computer usable medium having computer readable program code means therein for representing an object reference to a referent object in a computer environment, the computer readable program code means in said computer program product comprising:
computer readable code means for causing a computer to provide a graphical tree of attributes of a referring object in a user interface; and computer readable code means for causing a computer to automatically provide an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
computer readable code means for causing a computer to provide a graphical tree of attributes of a referring object in a user interface; and computer readable code means for causing a computer to automatically provide an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
27. The article of manufacture of claim 26 wherein said computer readable code means for causing a computer to automatically provide comprises computer readable code means for causing a computer to locate the referent object and retrieve the key of the referent object.
28. The article of manufacture of claim 26 or claim 27 further comprising computer readable code means for causing a computer to generate code corresponding to the object reference.
29. A computer system for representing an object reference to a referent object in a computer environment, comprising:
means for providing a user interface for a referring object; and means for providing, in said user interface, a key icon representing a key for the referent object of said object reference.
means for providing a user interface for a referring object; and means for providing, in said user interface, a key icon representing a key for the referent object of said object reference.
30. The computer system of claim 29, wherein the means for providing the key icon comprises means for providing a key part corresponding to a referent object attribute of the key for the referent object.
31. The computer system of claim 29 or claim 30, further comprising means for automatically generating code corresponding to the object reference.
32. The computer system of any one of claims 29 to 31, wherein the means for providing a key icon comprises means far providing the key icon as an attribute in a graphical menu for attributes of the referring object.
33. The computer system of any one of claims 29 to 32, wherein the means for providing a key icon comprises means for automatically locating the referent object and retrieving the key of the referent object.
34. A computer system for representing an object reference to a referent object in a computer environment, comprising:
means for providing a graphical tree of attributes of a referring object in a user interface; and means for automatically providing an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
means for providing a graphical tree of attributes of a referring object in a user interface; and means for automatically providing an object reference attribute in said tree corresponding to the object reference, said object reference attribute comprising a key part corresponding to an attribute of the referent object that forms part of a key for the referent object.
35. The computer system of claim 34 wherein the means for automatically providing comprises means for locating the referent object and retrieving the key of the referent object.
36. The computer system of claim 34 or claim 35 further comprising means for generating code corresponding to the object reference.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002293114A CA2293114A1 (en) | 1999-12-23 | 1999-12-23 | Representing a data mapping of an object reference |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002293114A CA2293114A1 (en) | 1999-12-23 | 1999-12-23 | Representing a data mapping of an object reference |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2293114A1 true CA2293114A1 (en) | 2001-06-23 |
Family
ID=4164959
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002293114A Abandoned CA2293114A1 (en) | 1999-12-23 | 1999-12-23 | Representing a data mapping of an object reference |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2293114A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2002300866B2 (en) * | 2001-09-06 | 2004-07-29 | Canon Kabushiki Kaisha | A Method of Handling Asynchronous Events |
| US7225447B2 (en) | 2001-09-06 | 2007-05-29 | Canon Kabushiki Kaisha | Method of handling asynchronous events |
| CN111159275A (en) * | 2020-01-02 | 2020-05-15 | 广州虎牙科技有限公司 | Data import method and device, electronic equipment and storage medium |
-
1999
- 1999-12-23 CA CA002293114A patent/CA2293114A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2002300866B2 (en) * | 2001-09-06 | 2004-07-29 | Canon Kabushiki Kaisha | A Method of Handling Asynchronous Events |
| US7225447B2 (en) | 2001-09-06 | 2007-05-29 | Canon Kabushiki Kaisha | Method of handling asynchronous events |
| CN111159275A (en) * | 2020-01-02 | 2020-05-15 | 广州虎牙科技有限公司 | Data import method and device, electronic equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6704743B1 (en) | Selective inheritance of object parameters in object-oriented computer environment | |
| Florijn et al. | Tool support for object-oriented patterns | |
| US7577934B2 (en) | Framework for modeling and providing runtime behavior for business software applications | |
| US6158044A (en) | Proposal based architecture system | |
| US8296720B2 (en) | Framework to access a remote system from an integrated development environment | |
| US7730446B2 (en) | Software business process model | |
| US6243709B1 (en) | Method and apparatus for loading stored procedures in a database corresponding to object-oriented data dependencies | |
| Bernstein | Repositories and object oriented databases | |
| US6789251B1 (en) | System and method for managing a suite of data management tools | |
| US6385767B1 (en) | Method and system for creating and manipulating extensions to version control systems | |
| US20040230559A1 (en) | Information processing device and information processing method | |
| US6223185B1 (en) | Method for defining composed object methods and attributes by dynamically presenting composite values and options | |
| US6230161B1 (en) | Dynamic expression editor | |
| US8655857B1 (en) | Dynamic construction of java class hierarchy based on metadata | |
| CA2293114A1 (en) | Representing a data mapping of an object reference | |
| Thomas | Java Data Access—JDBC, JNDI, and JAXP | |
| EP1040432B1 (en) | Method and apparatus for loading stored procedures in a database corresponding to object-oriented data dependencies | |
| WO1999033004A1 (en) | An integrated graphical user interface method and apparatus for mapping between objects and databases | |
| WO2005073848A2 (en) | Computer operating environment | |
| Acharya | Post Office Management System Project Report | |
| Kouraklis et al. | TMS Aurelius | |
| Talby et al. | The design and implementation of a metadata repository | |
| Sperko et al. | Java persistence for relational databases | |
| Füchsle et al. | SAP CRM Web Client: Customizing and Development | |
| Guide et al. | Persistence Framework |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |