Abstract:
A computer method and apparatus for managing changes for a given software system is disclosed. The invention method and apparatus forms a respective change request object to represent each user&#39;s request to make a change to a given software system. For each change request object, the invention method/apparatus provides an issue hierarchy of issue objects, a task hierarchy of task objects and an activity hierarchy of activity objects. Each issue object represents a respective issue, each task object defines work needed to address a respective issue and each activity object tracks respective work performed. There is provided a tabular user interface including a table representation of the respective issue hierarchy, task hierarchy and activity hierarchy of a change request object. The table representation serves as a to-do list per user and displays issue object, task objects, and activity objects as a function of user role.

Description:
RELATED APPLICATION 
     This application is a continuation-in-part of U.S. application Ser. No. 11,459,743, filed Jul. 25, 2006, the entire teachings of which are incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     Illustrated in  FIG. 1  is a typical software change management repository  100  of the prior art. In a software change management repository  100 , a set of objects  99  is maintained to capture the set of changes that have been requested by the developers and users of a software system. These changes request objects  99  are known by a variety of names in different change management repositories, such as Modification-Requests, Enhancement-Requests, Work-Items, Defects, and Bugs. In this disclosure, the term “Change-Request” is used to refer to these types of objects  99 . 
     The information about a change request is captured in a set of properties of the Change-Request object  99 . The property is represented by either an atomic value (such as a string, an integer, or a date) or a reference to another object  99  as illustrated by the ‘XX’ and dotted line arrow, respectively, of object  99   a  in  FIG. 1 . Some properties are pre-defined and present on all Change-Request objects  99 , but most properties are determined by a customer, and can vary from project to project. The current state of a change request is summarized in a pre-defined State property  102  of the Change-Request object  99 . Although the State property  102  is pre-defined, the legal values of the State property are determined by a customer. The customer defines a set of allowed transitions from one State value to another, and defines the actions that perform those transitions. 
     Some key problems with maintaining the state of a Change-Request object  99  are as follows:
         1. Different stake-holders in the change management process have different perspectives on what the current state of a given Change-Request should be. For example, a developer might believe that the Issue is resolved, while the submitter of the Issue believes the Issue requires further work. One approach to this problem is to introduce composite states such as “open-development-pending”, “open-development-complete” and, “closed-development-complete”. This approach results in a combinatorial explosion in the number of states as the number of stake-holders in the Change-Request management process increases, which makes it difficult to introduce new stake-holders to the change management process.   2. Multiple users of a software system might report similar problems. If each of these problems is entered as a separate Change-Request object  99 , it is error-prone and expensive to update the properties of each of these Change-Request objects as the problem is being resolved. If only a single Change-Request object  99  is used to track all of these problems, then it is difficult to capture important distinctions between the submitters of the problem, such as what release of the system was demonstrating the problem, and whether the problem has been resolved on the particular platform or product variant needed by a given user.   3. A given Change-Request might need to be resolved in different ways in multiple releases or variants of a given software system. It is important to be able to independently track how work is progressing in each of these releases or variants, but if there are separate Change-Request objects  99  for each release or variant, it is error-prone and expensive to update the problem description information on each of those change requests.   4. A given set of changes might be able to contribute to the completion of multiple tasks (especially when they are tasks to fix the same problem in different releases or variants of the software system). It is error-prone and expensive to be updating the multiple Change-Request objects  99  as work on that single activity progresses.   5. Different stake-holders in the change management process might be working at different sites with different replicas of the change management repository  100 , or working disconnected with a personal replica of a subset of the change management repository  100 . When multiple replicas are in use, different stake-holders can unwittingly modify the Change-Request object  99  in incompatible ways, resulting in difficult merge scenarios that require expensive manual merging or result in loss of information from automated merging. A standard solution to this problem is to assign one replica of the repository  100  as the master of a given Change-Request, and only users accessing that replica of the repository  100  can make any modifications to that Change-Request object  99 . But this results in serious delays and loss of information as stake-holders wait for mastership to be transferred to their replica.       

     SUMMARY OF THE INVENTION 
     In parent U.S. patent application Ser. No. 11/459,743 a software change management repository maintains a set of objects to capture the set of changes that have been requested by the developers and users of a software system. In order to accurately track the status of the different stake-holders for a given change request, a Change-Request object is partitioned into a set of linked sub-object hierarchies: namely, one Issue hierarchy, zero or more Task hierarchies, and zero or more Activity hierarchies. A given Task can be associated with multiple Issues (and therefore contribute to multiple Change-Requests), and a given Activity can be associated with multiple Tasks (and therefore contribute to multiple Change-Requests). 
     One of the user interfaces for a stake-holder in the change request management process is a tabular “to-do” list, where the list (table) contains the set of change-request objects upon which the stake-holder should perform some action. Some of these actions cause a given change-request object to be removed from this stake-holder&#39;s to-do list (the goal of any particular stake-holder is to get all change-requests, i.e., change request object, removed from his to-do list). But when a Change-Request is partitioned into a network of linked sub-object, where a given sub-object can be shared by multiple Change-Requests, it is unclear how to populate the rows of the to-do list table, since storing just the information of a particular sub-object in a given row would force the user to navigate around the rows to find related information, and would result in rows in the to-do list with incompatible fields, since different types of sub-objects have different types of fields. Alternatively, if information about related records is stored with each row for a given record, it is unclear what information from which related records should be displayed in the row of a record, what to do when there are multiple related records of the same type (which therefore have different values for the same columns in the table), and how to avoid the redundancy of having information in an object show up in the primary data of a column as well is in the related data of a variety of other objects. 
     The present invention addresses the above problems. In the present invention, the role of the user is used to select one of the types of sub-objects as being the primary sub-object. The different types of sub-objects of Change-Request are designed to partition the data according to the role of the user of the change request management system. In turn this ensures that the primary information for a given role of user is available for direct editing in the to-do list table. For example, if the role of the user is to discover and submit issues, the Issue is the primary sub-object for the to-do list for that user. If the role of the user is to identify work that needs to be performed to address an Issue, the Task is the primary sub-object for that user. If the role of the user is to make changes to software artifacts, the Activity is the primary sub-object for the to-do list for that user. The role of the user can be automatically determined from a role based change request management system, or otherwise it can be explicitly selected by the user. In case a given user acts in multiple roles, an operation is provided on the to-do list that makes it easy to switch the to-do list from one primary object to another. 
     In a preferred embodiment, a computer system and method manages changes for a given software system using the computer implemented steps of:
         forming a respective change request object to represent each user&#39;s respective request to make a respective change to a given software system;   for each change request object, providing an issue hierarchy of issue objects, a task hierarchy of task objects and an activity hierarchy of activity objects each issue object representing a respective issue, each task object defining work needed to address a respective issue and each activity object for tracking respective work performed; and   providing a tabular user interface including a table representation of the respective issue hierarchy, task hierarchy and activity hierarchy of a change request object, the table representation serving as a to-do list per user and displaying issue objects, task objects, and activity objects as a function of user role.       

     Accordingly, the present invention provides a computer method and apparatus for providing display of the data of interest to a given user (e.g., as a function of the user&#39;s role). Further the present invention provides a mechanism for creating new objects within a tabular form (representation of hierarchies of related objects and sub-objects) such that the new objects are automatically linked to the appropriate objects in the subject hierarchy. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention. 
         FIG. 1  is a block diagram of a change management repository of prior art. 
         FIGS. 2   a  and  2   b  are schematic and block diagrams, respectively, of computer network and digital processing environment in which embodiments of the present invention are deployed. 
         FIG. 3  is a schematic diagram of a change request object and object management system in embodiments of the present invention. 
         FIG. 4  is a block diagram of a to-do list table of the present invention utilized in the system of  FIGS. 5   a  and  5   b.    
         FIGS. 5   a - 5   b  are flow diagrams of one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     A description of example embodiments of the invention follows. 
       FIG. 2   a  illustrates a computer network of similar digital processing environment in which the present invention may be implemented. 
     Client computer(s)  50  and server computer(s)  60  provide processing, storage, and input/output devices executing application programs and the like. Client computer(s)  50  can also be linked through communications network  70  to other computing devices, including other client devices/processes  50  and server computer(s)  60 . Communications network  70  can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers. Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable. 
       FIG. 2   b  is a diagram of the internal structure of a computer (e.g., client processor  50  or server computers  60 ) in the computer system of  FIG. 4 . Each computer  50 ,  60  contains system bus  79 , where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. Bus  79  is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to system bus  79  is I/O device interface  82  for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer  50 ,  60 . Network interface  86  allows the computer to connect to various other devices attached to a network (e.g., network  70  of  FIG. 2   a ). Memory  90  provides volatile storage for computer software instructions  92  and data  94  used to implement an embodiment of the present invention (e.g., change request objects  13 , supporting table  41  and change request manager/system code  11  detailed below). Disk storage  95  provides non-volatile storage for computer software instructions  92  and data  94  used to implement an embodiment of the present invention. Central processor unit  84  is also attached to system bus  79  and provides for the execution of computer instructions. 
     In one embodiment, the processor routines  92  and data  94  are a computer program product (generally reference  92 ), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROMS&#39;s, CD-ROM&#39;s diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system. Computer program product  92  can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communications and/or wireless connection. In other embodiments, the invention programs are a computer program propagated signal product  107  embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/programs  92 . 
     In alternate embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network. In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of computer program product  92  is a propagation medium that the computer system  50  may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagating medium, as described above for computer program propagated signal product. 
     Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like. 
     Illustrated in  FIG. 3  is a change request object  13  employed in embodiments of the present invention. The change request object  13  is initiated in response to a given change request and stored in repositories  100  using similar first steps and technology of the prior art. Unlike prior art change request objects  99 , however, the subject change request object  13  is partitioned into a set of sub objects  21 ,  23 ,  25 ,  27 ,  31 ,  33 ,  37 . Each sub object is one of the sub object hierarchies, namely an Issue hierarchy  15 , a Task hierarchy  17 , and an activity hierarchy  19 . Preferably, there is one Issue hierarchy  15 , and there may be zero or more Task hierarchies  17  and zero or more Activity hierarchies  19 . The subject hierarchies  15 ,  17 ,  19  are linked to each other as illustrated by links  29 ,  35 , such that a given Task  27  can be associated with multiple Issues  21 ,  25  (and therefore contribute to multiple Change-Request), and a given Activity  31  can be associated with multiple Tasks  27  (and therefore contribute to multiple Change-Requests). 
     Some Issues can be logically decomposed into multiple sub-Issues, and respective sub-objects  23  of the Issue object  21  are created for each of those sub-Issues. When there are several software releases or variants in which an Issue  21 ,  25  is to be addressed, the system  11  creates a separate Task  27  for each release or variant, and links each Task  27  and its Sub-Tasks  37  to the Issue  21 ,  25  (as shown by dashed arrows  29  in  FIG. 3 ). The Activity hierarchy  19  contains the changes made to perform a given Task  27 . If one activity (represented by a respective object  31   a  for example) completes multiple tasks  27   a , . . .  27   n , system  11  associates the activity  31   a  with each of those tasks  27   a , . . .  27   n  (as illustrated at  35  in  FIG. 3 ). If one sub-activity  33  contributes to multiple activities  31 , system  11  makes a sub-object  33  of each of those sub-activities. 
     The present invention provides a tabular representation (or user interface)  41  of the linked hierarchy objects and sub-objects  21 ,  23 ,  25 ,  27 ,  31 ,  33 ,  37  of change requests  13  as shown in  FIG. 4 . The table  41  is formed of rows  43  intersected by columns  45 ,  47 ,  49 ,  57 . Each row  43  represents a respective change request object  13 , and table  41  effectively serves as a to-do list for users. In accordance with the present invention, the role of the user is used to select one of the types of hierarchy  15 ,  17 ,  19  objects (e.g., Issue, Task or Activity) as being the primary object for a given change request  13  (or row  43 ) of table  41 . 
     The first columns  45  of the table  41  are reserved for holding and displaying the desired fields of the primary object which as mentioned above depends on the role of the user. As with most tabular displays, the user is given the choice of whether a particular field should be displayed, how wide a particular field should be, the order in which the fields should appear, and which fields are used to sort the rows of the table (which field is the primary sort key, which field is the secondary sort key, etc.). Techniques known in the art are employed to support such display aspects. 
     Following the columns  45  of the primary fields are the columns  47 ,  49  for the fields of the sub-objects that are linked to the primary object for the row  43  (respective change request object  13 ). Note that information from both directly and indirectly linked objects  21 ,  23 ,  25 ,  27 ,  31 ,  33 ,  37  are held and displayed in the columns  47 ,  49  of a row  43 . For example, if the primary object is an Issue  21 , the secondary column  47  contains fields from the Tasks  27 ,  37  that are linked to the Issue  21  (directly linked objects), and secondary column  49  contains fields from the Activities  31 ,  33  that are linked to these Tasks  27 ,  37  (indirectly linked objects). 
     In simple cases where there is at most one linked object of a given type, the fields from that single linked object are stored and displayed in the appropriate secondary column  47 ,  49 . For example, say row  43   a  corresponds to change request object  13  of  FIG. 3 . If the primary object is an Issue  25  as a function of user role, then fields of Issue object  25  are indicated in first columns  45  of row  43   a  in table  41 . A single Task  27   m  is linked to that Issue (issue object)  25  and the fields from that corresponding task object  27   m  are held and displayed in the secondary column  47  of row  43   a  of table  41 . Further Task  27   m  is linked to a single Activity  31   n . The fields from the corresponding Activity object  31   n  are stored and displayed in the secondary column  49  of row  43   a  in table  41 . 
     As can be imagined, in many cases, an object/sub-object of one type is linked to many other objects/sub-object of another type. In this case, a “summary” value  40  is indicated for that field, where the summary value  40  of a given field is the result of a function that takes as input a set of values with the type of that field, and produces as output a single value with the type of that field. For example, a summary function for an integer-valued field might be a function that computes that average of a set of input integers, while a summary function for a date-valued field might be the earliest date from the set of input dates. For pre-defined fields, there are pre-defined summary functions, but these functions can be overridden in a given to-do list table  41  by a custom summary function. For customer-defined fields, there is a pre-defined summary function based on the type of the value of the customer-defined field, but a customer can define a customer default summary function for each type of field. The cells in secondary columns  47 ,  49  that contain summary values  40  are displayed in a distinctive way in table  41 , so that the user can easily determine when a summary value  40  is being displayed and when a direct value is being displayed. Known techniques are employed, such as color schemes, different fonts/font effects, flashing, blinking or other highlighting of table values and the like. 
     When a summary value  40  appears in a secondary column  47 ,  49  because multiple sub-objects are linked to the primary object, as user will sometimes want to be able to inspect the specific field values of the individual objects that contributed to that summary value  40 . To allow the user to inspect these individual values without losing the context of the table  41  data, system  11  enables the user to “expand” the table row  43  containing summary values  40 . This results in a list  43 ′ of rows, but only the initial row  51  in the resulting list  43 ′ contains primary values. The other rows in the resulting list  43 ′ contain no values (indicated as “blank” in  FIG. 4 ) in the primary columns  45 ′ to make it clear to the user that these are expansion rows (first set)  43 ′. Columns  47 ′ and  49 ′ of expanded list  43 ′ hold appropriate field values or summary values  40 ′ (further discussed below) of corresponding sub-objects. 
     For example, in a given row  43   c  of initial table  41 , if an Issue is the primary object and the Issue object  21   c  is linked to multiple Task (task objects)  27   a  . . . etc., a user can expand that given row  43   c . The row expansion results in a set of rows  43 ′ for that Issue  21   c  (one row for each Task  27   a  that is linked to that Issue  21   c ). In case the primary object is directly linked to more than one instance of one type of object (in the example, Issue  21   c  is linked to more than one Task  27 ), and one of the linked objects is in turn linked to multiple instances of another type of object (in the example, one of the linked Tasks  27   a  is linked to multiple Activities  31   a ,  33   a ,  33   b ), the expand operation on the row  43   c  for that primary object  21   c  only expands the directly linked object (in the example, a respective row is created for each directly linked Task  27   a  . . . ), and the indirectly linked objects are still displayed in summary from (in the example, the Activity  31   a  information for directly linked Task  27   a  is summarized at  40 ′ in rows  53  of expanded set  43 ′ where there are multiple Activities  31   a ,  33   a ,  33   b  linked to that Task  27   a ). 
     In this case, row  53  of the expanded row set  43 ′ can then be further expanded to second set (level)  43 ″. This expansion at  43 ″ produces one row for each object that is linked to the linked object represented by the subject row  53 . In the example, the row  53  having a summary value  40 ′ can be expanded upon user command to have a separate row for each Activity  33   a ,  33   b  linked to the corresponding Activity  31   a  (of Task  27   a ). As with the first level of expansion at  43 ′, in which the primary columns  45 ′ for all except the first row  51  are left empty, with the second level of expansion at  43 ″, the primary columns  45 ″ for the rows corresponding to directly linked sub-objects  33  are blank except for the first row  55  for that directly linked Activity object  31   a . Secondary columns  47 ″,  49 ″ hold and display pertinent sub-object field values. 
     One problem with having rows in the to-do list table  41  only for primary objects occurs when the user needs to create a new object. Although a new Issue object  21 ,  23   25  is usually created by a top-level “create-Issue” operation, a new Task or Activity object  27 ,  31  is usually created by applying an operation on an existing sub-object, which then both creates the Task  27  or Activity  31  and links it to that existing sub-object. For example, an “investigate” operation on an Issue sub-object  21 ,  23  creates a new Task object  27  that is linked to that Issue, and a “work-on” operation on a Task sub-object  37   n  creates a new Activity object  31  that is linked to that Task. But in this invention, the to-do list table  41  has rows only for existing primary objects, so the user would not have the appropriate sub-object in the table unless he is creating a primary object for a sub-object that is already linked to at least on primary sub-object (which is never the case initially in the preferred embodiment). 
     In addition, even for sub-objects that are linked to existing primary object, if more than one sub-object is related to an existing primary object, these sub-objects by default are collapsed into a single set of summary fields  40 , so it would not be easy to find the desired sub-object without expanding all of the summary fields,  40 ,  40 ′ (which would eliminate many of the benefits of the invention). 
     To solve the above problems, a “potential-new-object” query is associated with the to-do list table  41 . This query searches for records (rows and/or expanded rows  43 ,  43 ′,  43 ″) of the type of object that a user with this role would usually apply a “create”-type operation against (for example, Issue objects  21 ,  23 ,  25  for a user whose primary objects are Task objects  27 , and Task objects  27 ,  37  for a user whose primary objects are Activity objects  31 ). System  11  adds a work row  63  to the to-do list table  41  for each object that matches the potential-new-object query. Preferably system  11  indicates the information returns by the query in a “related information” column  57 . The newly added work row  63  then represents a “potential primary object” instead of an actual primary object, and the primary columns  45  of new work row  63  are displayed with special default values that indicate that this is a potential object. The user is then given a standard “create” operation that can be applied to any potential object row  63 . The primary columns  45  in the potential object row  63  are editable so that a user can specify information needed to initialize the potential new object when the “create” operation is applied to the object of that row. 
     According to the foregoing, embodiments of the present invention employ a Change Request object creator  51 , partitioning means  53  and Change Request management means (manager system)  55  as shown in  FIGS. 5   a - 5   b . In response to user request to change a subject software system (program or the like), invention system  11  through Change Request object creator  51  initiates a Change Request object  13 . Techniques known in the art may be employed to implement Change Request object creator  51 . Creator  51  stores initiated Change Request objects  13  in a repository  101  similar to the change management repositories  100  of prior art. 
     Partitioning means  53  generates the issue hierarchy  15 , task hierarchy  17  and activity hierarchy  19  corresponding to a Change Request object  13  stored in repository  101 . Linked objects, tree structures and other data structures are employed as discussed in related (parent) application Ser. No. 11/459,743 herein incorporated by reference. 
     Change Request management means  55  maintains associations between activity objects  31 , task objects  27  and issue/root objects  21 ,  25 . Change Request management means  55  computes and maintains status values and other values of the objects  21 ,  23 ,  25 ,  27 ,  31 ,  33 ,  37  in the hierarchies  15 ,  17 ,  19  according to techniques and methods in parent U.S. application Ser. No. 11/459,743. Further, manager  55  computes and maintains the to-do list table  41  of Change Request objects  13  for each user according to the role of that user. 
     With reference to  FIG. 5   b , manager  55 /system  11  creates and maintains (step  65 ) and entry (row  43 ) in table  41  for each change request object  13 . For a given table row  43 , system  11 /manager  55  indicates in first column (primary column)  45  the primary object as a function of user role (step  66 ). Cross referencing tables of users and users&#39; roles or other common techniques for this purpose are employed. Continuing with step  67 , system  11  indicates in subsequent columns  47 ,  49  of table  41  the fields of sub-objects directly and indirectly linked to the primary object. If multiple sub-objects are linked to the primary object, then at step  68  system  11  provides summary values in columns  47 ,  49 . In turn, system  11  enables a user to view a subject row  43  in an expanded version where the constituents of the summary values in columns  47 ,  49  of that row are displayed (step  69 ). Upon user selection or command to expand the subject row  43 , step  73  displays the expanded row set  43 ′. In the expanded row set  43 ′, system  11  (at step  73 ) indicates in form, style and the like that the current view is an expanded portion of the main view for table  41 . In one embodiment, step  73  displays the expanded row  43 ′ having blank primary column  45 ′ for all rows but the first row. If multiple sub-objects are linked to the primary object of the expanded row set  43 ′, then step  73  provides summary values in secondary columns  47 ′,  49 ′ and loops back to step  69  which enables the user to expand the view further. Loop  71  enables a user to layer by layer expand row  43  of table  41  where summary values  40 ,  40 ′ are displayed in columns  47 ,  49 ,  47 ′,  49 ′ of that row. 
     Continuing on the step  75 , system  11 /manager  55  supports the “potential-new-object” query by a user. In response to the user issuing such a query, step  75  adds appropriate work rows  63  to table  41  (one new row  63  for each object found that matches the query). In each added work row  63 , system  11  indicates in primary column  45  of that row the potential of a new object in the hierarchy of change request object  13 . Step  75  also indicates the searched and returned object/sub-object information in column  57  of work rows  63 . 
     System  11  provides to the user a “create” operation. Upon user selection of the create operation, step  77  applies that operation to the corresponding object of a given work row  63  (as selected by the user) and adjusts the change request object  13  (within hierarchies  15 ,  17 ,  19 ) accordingly. System  11  also at Step  77  enables user editing of the primary column  45  in the given row  63  to update indication of the corresponding object from “potential” to a now-existing object/sub-object. 
     While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims. 
     For example, the present invention may be implemented in a variety of computer architectures. The computer network of  FIGS. 2   a  and  2   b  are for purposes of illustration and not limitation of the present invention. 
     The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. 
     Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. 
     The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. 
     A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.