In an object oriented repository, a method for treating a group of objects as a single object during execution of an operation5557793Abstract In a computer system having a user interface, a memory and a database, a repository program operating in the computer system for accessing the database, the repository program executing a method for treating a group of objects as a single object. This method comprises the steps of retrieving a collection of references for a type from the repository; sorting out each reference in the collection of references that are composite references and have a versioned object type; for each sorted reference, retrieving objects from the reference; and calling up current operations for each retrieved object. Claims What is claimed is: Description FIELD OF THE INVENTION
______________________________________
Type Description
______________________________________
Array Creates a dynamic array of objects in which an
integer index can be used to access array
members. An array can contain duplicate
objects.
List Creates an ordered collection of objects. A
list can contain duplicate objects.
Set Creates an unordered collection of objects.
Objects in a set must be unique.
______________________________________
Operations An operation is a feature that represents a behavior that objects can possess. An operation can be thought of as a function: it has a name, an optional set of parameters, and an optional return type. Like properties, operations are applied to each object within the owning type. Consequently, an operation is generally invoked in the context of a specific object. An operation can have parameters that identify information a caller must provide when invoking the operation. If an operation has no parameters, a caller merely invokes the operation for the desired object. For example, consider the following features:
______________________________________
Domain/Return
Type Feature Type
______________________________________
Employee birthDate (attribute)
Date
age (operation)
Integer
______________________________________
As shown, the birthDate attribute has a domain of Date. Age is an operation (with no parameters) whose return type is Integer. The purpose of age is to compute an employee's current age (in years) from his or her birth date. Because the age operation is invoked for a specific employee, it is able to obtain the value of that employee's birthDate attribute, make the necessary computation, and return the appropriate integer without requiring parameters. When an operation has parameters, each parameter has semantics similar to those of properties. Each parameter has a name, a domain type, and a set of options that can be used to affect the behavior of the parameter. The following table shows an example of an operation, defined for the Employee type, that has parameters:
______________________________________
Parameter Parameter
Operation
Parameter Domain Options
______________________________________
setSalary
amount Real REQUIRED
authorizedBy
Manager REQUIRED
effective Date DEFAULT today's
date
______________________________________
The setSalary operation has three parameters: The amount parameter is a Real number (floating-point) that is required. Therefore, the caller must specify a value for this parameter. The authorizedBy parameter is a Manager object that also is required. The effective parameter is a date parameter that is not required. However, if the caller does not specify a value for this parameter, the current system date is used by default. A multi-valued parameter is a set, or collection, of values. Such a parameter is useful when the operation must operate on several objects even though it is invoked in the context of a single object. An operation optionally can return an object when it completes processing, just as a program function can return a value. An operation that returns an object is called typed because it has a return type specified. An operation that does not return an object is called un-typed because it does not have a return type specified. A return type must be one of the types recognized by the repository. An operation can return a set of objects by specifying a collection as its return type. An operation can be defined for a type and then redefined for each subtype of the original type. This process is called overriding an operation. When an operation is overridden, a subtype that inherits the operation has a separate method that redefines the functionality of that operation. The technique that the repository uses to choose which method to call for a given operation is called dynamic binding. Dynamic binding (also called polymorphism) means that the repository chooses the method that is most specific for a given object and operation. The most specific method is the one defined in the lowest subtype of which the object is an instance. For example, assume setSalary is an operation defined for the Employee type. An employee object can be an instance of the Employee type or one of its subtypes. If you call the setSalary operation for an object that is an Employee instance, the repository selects the method associated with the setSalary operation defined for the employee type. If you call the setSalary operation for an object that is a Manager instance, the repository selects the method associated with the setSalary operation as it is redefined for the Manager type. If the Manager type does not redefine the setSalary operation, the repository selects the method associated with the setSalary operation defined for the Employee type as the immediate supertype of the Manager type. You can define an operation to be called with different sets of parameters. For example, you might define the setSalary operation to be called with only an amount parameter or with both an amount parameter and an effectiveDate parameter. Each combination of parameters that an operation can accept is called a signature. To define multiple signatures for an operation, you define the operation more than once in the same owner type and use the desired signature for each definition. Methods The operations defined for a model form an interface that can be seen by a caller. Separate from this definition, each operation must be implemented by a module of code called a method. Methods are typically written as separate functions and bound into a set of code libraries. The method code library name for each operation is then identified to the repository as part of the definition of the operation. When a caller invokes an operation, the request is received by the repository, which finds and calls the appropriate method. The operation passes to the method the appropriate parameters. When a method is called, it can then act as a caller and call back into the repository to invoke other operations. Consequently, a method can be thought of as a specialized kind of application program. Objects An object is an abstract representation of a real-world concept or thing-such as a person, a software package, or an event-that is stored in the repository. In the repository, the state of an object is represented by the values of the properties defined for the type. For example, the state of an integer is its numeric value. The state of a person is its name, birthDate, spouse and so on. The behavior of an object is the set of functions that the object can perform. In the repository, the behavior of an object is represented by the operations defined for the owner type. A characteristic of object behavior is the ability to return some of its state to a requester. For example, the object person can return its name. For this reason, some object models describe object behavior as the set of messages that an object can receive and respond to. One example of object behavior is the capability an integer has to perform such functions as addition, square root and absolute value. Component Object is a versioned object (i.e., a particular historical state of an object) that is part of a composite object. The relationship of the component object to the composite object is defined by a composition relationship. A component object can itself be a composite object. In this case, the component object contains other component objects related to it by composition relationships. A component object can belong to several composite objects. This feature promotes sharing of objects in the repository. A Composite Context is a type that defines the scope of a composite hierarchy. The composite context identifies the top object for the hierarchy and the ghost objects that were created while the context was the current composite context. The term ghost as used herein means a value associated with a changeable object. Objects with ghost status can only be viewed in certain situations, i.e. they are only visible in the context in which they were created. A Composite Hierarchy is a tree structure composed of a composite object and its component objects. The hierarchy also includes the component objects for any component object that is itself a composite object. Thus, this structure defines the component objects of the top, or root object, the components of those components, and so on to the bottom of the hierarchy. A Composite Object is a versioned object for which at least one composite relationship is defined thus allowing the object to have components. A composite object can be thought of as owning its component objects. Some examples of these are: a car engine-the component objects include spark plugs, wires and pistons; a program-the component objects include files, record layouts and modules; a menu-the component objects are the various selections on the menu. A Composite Reference is the relationship that links a composite object to its component objects. The relationship between a car engine and its parts-spark plugs, pistons, wires and so on can be used to illustrate a composite relationship. The car engine and its components can be treated as a single object, yet each of the parts can be accessed individually. The term Visibility is used with versioned objects whose reserveStatus value is ghost. A ghost object is visible only in the composite context in which it was created. When this composite context is the current object, one can change the attributes of the ghost object, add or remove an object from the attributes of another object and so on. A composite object usually represents a structure such as a program or a system. However, the method of the present invention does not enforce a presentation methodology. Therefore, the user can define the composition relationship needed for a tool model and create the user interface best suited to displaying the composite objects to the tool user. The composite object service automatically creates a default composite context when the user begins a session with the repository. Thus, the tool does not need to create a composite context unless it requires one. The user can create a composite or component object as one would any other versioned object. To identify the top, or root, object in a composite hierarchy, the user designates that object as the top property value for the composite context. Once the user has designated a top object, reserving an object in the composite hierarchy causes all composite objects in the hierarchy that contain the reserved object to also be reserved. Any composites that contain these objects are also reserved, up to and including the top object. This process creates a new composite hierarchy that contains all the changed objects. The composite object service 22d enables the user to add and remove component objects by changing the property that defines the composition relationship for the composite object type. Because invoking the add and remove operations changes the composite object, the user must first reserve the object before inserting or removing a component. Invoking an operation for a composite object might also invoke the same operation for the component objects. For example, the following operations can impact component objects: The reserve operation enables the user to reserve the component objects as well as the composite object; The replace operation replaces all versioned objects related to the composite object by either a composite or reference relationship; and, The unreserve operation unreserves the composite object. If the composite object was reserved with its component objects, the operation also unreserves the components. In adding and removing versions of an object, the user can use an update relationship operation defined for the repository versioned object type to: Add new versions of a component object to a composite object; and, Remove old versions of a component object from a composite object. Two examples of a composite object are shown in FIGS. 2 and 3, wherein the example of FIG. 2 shows a simple composite hierarchy having a File object 30, a Record object 31 and three Field objects 32, 33 and 34. The scenario is as follows: the File object 30 has an attribute that defines a composition relationship allowing the File object 30 to contain records. The Record object 31 has an attribute that defines a composition relationship allowing the Record object to contain fields (such as field objects 32, 33 and 34). The Top attribute value in the user's current context is the object with the name Customer and the versionNumber attribute equal to 1. The File object 30 is referred to herein as the top object of the hierarchy. If the user wants to change an attribute of ZipCode, then the Field object 34 must be reserved. The resulting composite hierarchy with the newly created versions is shown in FIG. 3 Version 2 of Customer, Address and ZipCode are now created since Version I was reserved. For each of these objects, the reserveStatus attribute value is ghost. New versions of Name and City are not created; instead new composition relationships are created between these objects and version 2 of Address. With reference to FIGS. 4 and 5, the process to perform the operation of changing the FIG. 2 hierarchy to that shown in FIG. 3 is illustrated. (The pseudo code for the flow chart shown in FIG. 4 is listed in Appendix A hereof and that for FIG. 5 is shown in Appendix B hereof) From a START bubble 40, the process shown in FIG. 5 is called up, as depicted by a process block 41. From a START bubble 42 in FIG. 5, an inquiry is made as to whether or not the current object is the top object (decision diamond 43). An example of a "top object" is File 30 in FIG. 2. If the response to this inquiry is YES, then the return is TRUE, which means the top object has been found and the search is ended. The return TRUE operation is depicted by a process block 44. On the other hand if the answer to this inquiry is NO, then the returnFlag is set to FALSE as depicted by a process block 45. Setting the return flag is an initialization of a variable used to hold the return value. Following this step references for the type are retrieved as depicted by a process block 46. An inquiry is next made as to whether or not there are more references in the list returned by the step represented by the process block 46. This inquiry is depicted by a decision diamond 47. If the answer to this inquiry is YES, then a branch is taken to yet another decision diamond 48, where an inquiry is made as to whether or not the reference is of interest. A reference is of interest if its inverse is a composite reference. In other words, we are trying to find a path to the top object (see e.g. the path from object 34 to object 30 in FIG. 3), and keep track of the objects found in the path. If the reference is not of interest then a return is made back to the decision diamond 47 for the next reference. On the other hand, if the reference is of interest, then a branch is taken to a process block 49 where objects are retrieved for the current object and reference. Once this process step is complete an inquiry is made as to whether or not more objects are in the collection returned in the step represented by the process block 49. This inquiry is represented by a decision diamond 50. If there are no more objects in the collection, then a return is made back to the input of decision diamond 46 for the next reference in the list. However, if there are more objects in Reference (YES branch of decision diamond 50), then this process (FIG.5 flow chart) is called for the object, as depicted by a process block 51. Following this step, an inquiry is made as to whether or not the return value (from the step depicted by the process block 51) is TRUE, decision diamond 52. If the process did not return TRUE, then a branch is made back to the decision diamond 50. However, if the process did return TRUE, then a branch is taken to a process block 53 to add this object to the collection and set the returnFlag to TRUE, process block 54. After this step, a return is made back to the decision diamond 50 to repeat the process for the next object in the collection, if any. Once all the references in the list have been processed, a branch is taken from the NO leg of the decision diamond 48 to return returnFlag and the collection of objects found as illustrated by a process block 55. Following this an exit is made as represented by the END bubble 56. At this juncture a return is made to the process shown in FIG. 4 wherein an inquiry is made as to whether or not there are more objects to process in the collection returned in the step depicted by the process block 55. This inquiry is depicted by a decision diamond 55. If the answer is YES, then a branch is taken to a process block 58 to reserve the object. Following this reserve step, a return is made to the decision diamond 57. On the other hand, if there are no more objects, then a branch is taken out the NO leg of the decision diamond 57 to exit this process, END bubble 59. Note that only one pass is made through the flow chart shown in FIG. 4, while multiple passes are made through the flow chart shown in FIG. 5, i.e., one pass for each object at the process block 51. Referring now to FIG. 6, a flow chart illustrates the method for treating objects as groups of objects. From a start bubble 60 the references for type are retrieved, process block 61. As a result of this process step a collection of References are returned. An inquiry is next made as to whether or not there are more References on the list retrieved in the preceding step, as depicted by a decision diamond 62. If the answer to this inquiry is YES, then another inquiry is made as to whether or not this reference is of interest, i.e. a composite reference, decision diamond 63. If it is a composite reference then the YES branch is taken from the diamond 63. On the other hand if the reference is not of interest, then the NO branch is taken from the diamond 63 back to the input of the diamond 62 for the next reference. If the reference is of interest, then an exit is taken from the YES leg of the diamond 63 to a process block 64, wherein the objects in reference are retrieved. Next, an inquiry is made as to whether or not there are more objects in the list, decision diamond 65. If there are more objects, then an exit is taken on the YES branch to call the current operation for the object, as depicted by a process block 66. The current operation is called for the retrieved object. If there are no more objects then the NO exit is taken back to the decision diamond 62 for the next reference on the list. Referring now to FIG. 7, a flowchart is shown of the steps performed in updating references. The process begins with a start bubble 70, followed by the start of a database transaction, as depicted by a process block 71. Next a boolean flag, updated, is set to FALSE as depicted by a process block 72. This flag is used to hold a value for processing at the end of the process. Following this, the object is reserved (block 73). The new object returned from the reserve is called ghostObject. The next step is to retrieve the references for the object's type, as represented by a process block 74. Each reference is then retrieved from the collection, and an inquiry is made (decision diamond 75) as to whether or not there are more references in the collection. The next step in this process is to retrieve the objects contained in the reference (process block 76), and a collection of objects is returned. Each object is retrieved from the collection. An inquiry is made as to whether or not there are more objects in the collection, as depicted by a decision diamond 77. For each object retrieved from the collection a process shown in FIG. 8 and described hereinafter is performed (process block 78). Once all references have been processed, the NO exit is taken from the decision diamond 75 to another inquiry as to whether or not the Updated Flag is TRUE, decision diamond 79. If the updated Flag is TRUE, then a later version for one of the objects was found. The work performed by the process must be saved, which is represented by a process block labeled Commit Transaction 80. Following this, GhostObject is returned (process block 81), which was created in the process step represented by block 73. If the updated Flag is FALSE (NO leg exit from diamond 79), the transaction is aborted and no changes are saved into the database (process block 82). Next, a null object is returned to the caller (process block 83), following which the process is terminated (bubble 84). Referring now to FIG. 8, the balance of the flow chart of FIG. 7 is shown. Recall in the description above that each object retrieved as a result of the process step depicted by the process block 76 is further processed as referenced by the process block 78. We begin with a start bubble 85. Next,the latest version of object is found, which object is called latestVersion i.e., the latest version of the object on the same variant is found. The same object could be "found", indicating there is no later version on that variant. A local variable, latestVersion, holds this object for later processing. This process step is depicted by a process block 86. One of the parameters to updateReferences (current process) defines the desired visibility of the latest versions found. If the parameter's value is lastCheckedIn, we cannot use a ghost object. This process step is represented by a decision diamond 87, which inquiry is: UpdateType=LastCheckedIn and LatestVersion is ghost. If the answer is TRUE or YES, then the process directs the finding of the previous version of the object on the same variant, process block 88. This object is then stored in the local variable, LatestVersion, for later processing. This process step is depicted by a block 89, entitled LatestVersion=object found. After the process step depicted by process block 89 has been performed a return is made to the decision diamond 90. If the answer to the inquiry depicted by decision diamond 87 is NO, then another inquiry is made as to whether or not the objects in the references are updated themselves as represented by a decision diamond 90 labeled Depth Update? One of the parameters to updateReferences, depthUpdate, specifies whether the objects in the references are updated themselves (i.e., recursively). If the process is recursive, YES branch from the diamond 90, then the updateReferences is called for latestVersion. This process step is represented by a process block 91. The updateReferences process can return a new object or a null object. Hence, an inquiry is made as to whether the object returned is not the same as latestVersion, decision diamond 92. If the answer to this inquiry is yes, then the LatestVersion is set equal to the new object (process block 93). Following this step a return is made back to the input of the decision diamond 94. If the process is not recursive, then the NO branch is taken from the decision diamond 90. Next, the object in the latestVersion variable is compared with the object with which entry was made from the process block 78 in FIG. 7. This process step is represented by a decision diamond 94. If the two objects are not the same, then the ghostObject is updated by removing the object found in the process block 78 (FIG. 7) from the relationship and inserting the latestVersion object. This process step is depicted by a process block 95 labeled update original ghostObject. Following this step, the updated flag is set to TRUE, which is depicted by a process block 96. Next, this process is stopped (bubble 97). Also, if the comparison performed above (decision diamond 94) is FALSE the process is stopped. Although the invention has been described with reference to a specific embodiment, this description is not meant to be construed in a limiting sense. Various modifications of the disclosed embodiment as well as alternative embodiments of the invention will become apparent to one skilled in the art upon reference to the description of the invention. It is therefore contemplated that the appended claims will cover any such modifications of embodiments that fall within the true scope of the invention. APPENDICES: Appendix A, Pseudo Code for the FIG. 4 Flow Chart: After the composite object has been reserved the following steps are performed if the reserveComposites parameter is TRUE: 1. Call getAllComposites. 2. For each object in the returned array, call reserve with reserveComponent=FALSE and reserveComposites=FALSE. (This ensures we don't get all composites for these objects again). Appendix B, Pseudo Code for the FIG. 5 Flow Chart: The findCompositeToTop operation performs the following steps: 1. If "this"==top Return TRUE 2. Declare a boolean, returnValue, initial value is FALSE. 3. Get the type of the object (getByName of UrepMetaType).* 4. Call getAllFeatures for the type, with the parameter of references. 5. For each reference in the returned collection: a Retrieve the UREPMetaReference instance that is the inverse. If the composite attribute of the UREPMetaReference is TRUE then: i. Get the objects in the reference attribute for "this" (getProperty). * Note: Urep is an acronym for Unisys Repository, wherein Unisys Corporation is the assignee of this patent application. ii. For each object in the returned collection: If the object is not a member of compositescall findCompositeToTop for the object. If findComopositeToTop returns TRUE: Set return value =TRUE If the reserveStatus value for the object is not ghost, add the object to composites. 6. Return return Value. Appendix C, Pseudo Code for the FIG. 6 Flow Chart: The getAllComponents operation performs the following steps: 1. Create an instance of an array of UrepVersionedObject called components. 2. Get the type of the object (class attribute of the object). 3. Call getAllFeatures for the type, with the parameter of references. 4. For each instance in the returned collection: If the composite attribute of the UrepMetaReference is TRUE Retrieve the objects in the attribute for this object (getProperty) and add it to components. 5. Return components. Appendix D, Pseudo Code for FIGS. 7 and 8 Flow Charts: The updateReferences operation only returns a new object when one of the objects in its composite or reference is updated because a later version on the same variant was found. This creates new objects only when needed and preserves the reference to objects that have no later versions. The operation performs the following steps: 1. A short transaction is started. 2. Declare a boolean flag, updated, initial value is FALSE. 3. The object is reserved (using the variant parameter), with reserveComponent=FALSE. Call this object ghostObject. 4. Get the type of the object (getByName of UrepMetaType). 5. Get the relationships for this type by calling getA11Features with featureType=references. 6. For each reference where the reference is composite. a. Retrieve the objects in that reference attribute. b. For each object in the returned collection (call this object referencedObject) do the following: i. Find the last checked in or latest version, depending on updateType, on the variant of referencedObject. Call findVersion with Version=0 and variant=the variant of this object. Call this (possibly) new object latestVersion. If updateType=lastCheckedIn and reserveStatus of latestVersion is ghost, then get the previousVersion of latestVersion, on the same variant. ii. If depthUpdate is TRUE, call updateReference for latestVersion. If a new object is returned from this call, set latestVersion to this new object. iii. If latestVersion is not the same object as referencedObject (i.e. we found a later version), remove referencedObject from the attribute on ghostObject, and add latestVersion to the attribute on ghostObject. Set updated flag to TRUE. 7. If updated flag is TRUE, commit the transaction, and return ghostObject to the caller. Otherwise abort the transaction and return to NULL.
|
Same subclass Same class Consider this |
||||||||||