Source: http://www.google.com/patents/US5970498?dq=6480844
Timestamp: 2016-02-06 10:05:05
Document Index: 305892990

Matched Legal Cases: ['Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 95', 'Application No. 95', 'Application No. 95', 'Application No. 95', 'Application No. 95', 'Application No. 95']

Patent US5970498 - Object oriented framework mechanism for metering objects - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAn object oriented framework mechanism provides a straightforward and convenient way to implement metering within an object-oriented computer program for any type of program that needs to be metered. The object metering framework includes core function and extensible function. Core classes and core class...http://www.google.com/patents/US5970498?utm_source=gb-gplus-sharePatent US5970498 - Object oriented framework mechanism for metering objectsAdvanced Patent SearchPublication numberUS5970498 APublication typeGrantApplication numberUS 08/761,459Publication dateOct 19, 1999Filing dateDec 6, 1996Priority dateDec 6, 1996Fee statusPaidAlso published asCN1143233C, CN1188283A, EP0847007A2, EP0847007A3Publication number08761459, 761459, US 5970498 A, US 5970498A, US-A-5970498, US5970498 A, US5970498AInventorsDana Mark Duffield, Eric Leonard Fosdick, William Craig RappOriginal AssigneeInternational Business Machines CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (29), Non-Patent Citations (280), Referenced by (38), Classifications (10), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetObject oriented framework mechanism for metering objects
US 5970498 AAbstract
An object oriented framework mechanism provides a straightforward and convenient way to implement metering within an object-oriented computer program for any type of program that needs to be metered. The object metering framework includes core function and extensible function. Core classes and core class relationships define the core function of the framework mechanism. The extensible function is defined by extensible classes that can be extended by a programmer to implement a desired metering environment. The framework provides consistent programmer interfaces over a wide variety of different metering environments, which greatly enhances programmer efficiency and which makes the resultant code much easier to maintain.
1. A computer system, the computer system metering at least one metered object in a computer program executing on the computer system, the computer system comprising:a central processing unit; and a main memory coupled to the central processing unit, the main memory containing an object-oriented framework mechanism that provides at least one object metering environment for metering the number of times the at least one metered object is accessed, the framework mechanism executing on the central processing unit. 2. The computer system of claim 1 wherein the computer system includes multiple threads of control, and wherein one thread of control performs the metered client method and another thread of control performs the metering of the at least one object.
3. The computer system of claim 1 wherein the framework mechanism comprises at least one before after metaclass, the before after metaclass defining:a first set of object methods to perform a plurality of predetermined functions to implement the object metering environment. 4. The computer system of claim 3 wherein the first set of object methods includes at least one before object method that is executed before the execution of a metered client method.
5. The computer system of claim 3 wherein the first set of object methods includes at least one after object method that is executed after the execution of the metered client method is commenced.
6. The computer system of claim 3 wherein the before after metaclass is an extensible class of the framework mechanism that is defined by the framework mechanism to implement the at least one object metering environment.
7. The computer system of claim 3 wherein a meter usage metaclass, a meter concurrent usage metaclass, a meter users metaclass, a meter location metaclass, and a meter timing metaclass are all subclasses of the before after metaclass.
8. The computer system of claim 1 wherein the framework mechanism comprises a metered entity configuration class, the metered entity configuration class defining:at least one metered entity configuration object containing configuration data for at least one metered entity; and a second set of object methods to determine the configuration data for the at least one metered entity. 9. The computer system of claim 8 wherein the metered entity configuration class is a core class of the framework mechanism.
10. The computer system of claim 1 wherein the framework mechanism comprises a metered entity class and a metered suite class,the metered entity class defining: at least one metered entity object corresponding to a parameter to be metered;the metered suite class defining: at least one metered suite object containing at least one metered entity object; and a third set of object methods to determine which of the metered entity objects are contained in the metered suite object. 11. The computer system of claim 10 wherein the metered entity class and the metered suite class are extensible classes of the framework mechanism.
12. The computer system of claim 1 wherein the framework mechanism comprises a metered entity configuration class, a configuration data class, and a metered data class, the metered entity configuration class defining:at least one metered entity configuration object containing configuration data for at least one metered entity; and a second set of object methods to determine the configuration data for the at least one metered entity;the configuration data class defining: at least one configuration data object identifying the plurality of metered entity configuration objects; and a fourth set of object methods to determine the configuration for the at least one metered entity;the metered data class defining: at least one metered data object containing a plurality of metered entity data objects; a fifth set of object methods to determine the metered data for the plurality of metered entity data objects. 13. The computer system of claim 12 wherein the metered entity configuration class, the configuration data class, and the metered data class are core classes of the framework mechanism that are defined by the framework mechanism to implement the at least one object metering environment.
14. The computer system of claim 1 wherein the framework mechanism further comprises a metered entity data class and a threshold class, the metered entity data class defining:at least one metered entity data object containing metering data corresponding to at least one metered entity;the threshold class defining: at least one threshold object containing threshold data for the at least one metered entity; and a sixth set of object methods to determine the threshold data for the at least one metered entity. 15. The computer system of claim 14 wherein the metered entity data class and the threshold class are extensible classes of the framework mechanism.
16. The computer system of claim 14 wherein a metered usage data class, a metered concurrent usage data class, a metered user data class, a metered location data class, and a metered timing data class are all subclasses of the metered entity data class.
17. The computer system of claim 14 wherein a cumulative access threshold class and a concurrent access threshold class are subclasses of the threshold class.
18. The computer system of claim 1 wherein the framework mechanism comprises a principal class, the principal class defining:at least one principal object corresponding to a type of item to be metered; and a seventh set of object methods for determining the names of the principal objects. 19. The computer system of claim 18 wherein a program class, a location class, a user class, and a VIP user class are all subclasses of the principal class.
20. The computer system of claim 18 wherein the principal class is an extensible class of the framework mechanism.
21. The computer system of claim 4 wherein the first set of object methods includes at least one after object method that is executed after the execution of the metered client method is commenced.
22. The computer system of claim 21 wherein the framework mechanism further comprises a metered entity class and a metered suite class, the metered entity class defining:at least one metered entity object corresponding to a parameter to be metered;the metered suite class defining: at least one metered suite object containing at least one metered entity object; and a third set of object methods to determine which of the metered entity objects are contained in the metered suite object. 23. The computer system of claim 22 wherein the framework mechanism further comprises a metered entity configuration class, a configuration data class, and a metered data class, the metered entity configuration class defining:at least one metered entity configuration object containing configuration data for at least one metered entity; and a second set of object methods to determine the configuration data for the at least one metered entity;the configuration data class defining: at least one configuration data object identifying the plurality of metered entity configuration objects; and a fourth set of object methods to determine the configuration for the at least one metered entity;the metered data class defining: at least one metered data object containing a plurality of metered entity data objects; a fifth set of object methods to determine the metered data for the plurality of metered entity data objects. 24. The computer system of claim 23 wherein the framework mechanism further comprises a metered entity data class and a threshold class, the metered entity data class defining:at least one metered entity data object containing metering data corresponding to the at least one metered entity object;the threshold class defining: at least one threshold object containing threshold data for at least one metered entity object; and a sixth set of object methods to determine the threshold data for the at least one metered entity object. 25. The computer system of claim 24 wherein the framework mechanism further comprises a principal class, the principal class defining:at least one principal object corresponding to a type of item to be metered; and a seventh set of object methods for determining the names of the principal objects. 26. The computer system of claim 25 wherein the metered data class has a "has by reference" relationship with the metered entity data class.
27. The computer system of claim 25 wherein the configuration data class has a "has by reference" relationship with the metered entity configuration class.
28. The computer system of claim 25 wherein the metered entity configuration class has a "using" relationship with the metered entity class, the metered suite class, and the threshold class.
29. The computer system of claim 1 wherein the main memory contains an application program that supports an object oriented programming environment containing the framework mechanism, and wherein the framework mechanism is extended by providing information that implements the at least one object metering environment.
30. The computer system of claim 1 wherein the framework mechanism comprises:at least one core function defined by at least one core class and by the relationships between a plurality of classes within the framework mechanism, wherein the implementation of the at least one core function is defined by the framework mechanism and cannot be modified by a user of the framework mechanism; and at least one extensible function defined by at least one extensible class, wherein the implementation of the at least one extensible function is defined by the user of the framework mechanism by extending the at least one extensible class. 31. A computer-implemented method for metering at least one metered object in a computer program, the method comprising the steps of:providing an extensible object oriented framework mechanism that meters the objects according to extended portions of the framework mechanism that are customized to provide a desired object metering environment for metering the number of times the at least one metered object is accessed; and executing the object oriented framework mechanism on a computer system. 32. The method of claim 31 further including the step of:extending the framework mechanism to define the desired object metering environment. 33. The method of claim 31 further including the steps of:(a) invoking a client object method on a selected metered object; (b) executing the client object method; (c) retrieving metered data for the selected metered object; (d) determining the configuration of the selected metered object; and (e) updating the metered data for the selected metered object. 34. The method of claim 33 wherein step (b) is performed by one thread of control and steps (c)-(e) are performed by another thread of control in a multi-threaded system.
35. The method of claim 34 wherein the step of determining the configuration of the selected metered object includes the steps of:determining whether the selected metered object belongs to a suite; determining applicable thresholds for the selected metered object; determining which methods of the selected metered object to meter; and determining whether the selected metered object is in a synchronous mode. 36. A program product comprising:an object-oriented framework mechanism for metering at least one metered object in a computer program, the framework mechanism including an extensible object metering mechanism that meters the number of times the at least one metered object is accessed according to extended portions of the framework mechanism; and computer-readable signal bearing media bearing the framework mechanism. 37. The program product of claim 36 wherein the computer-readable signal bearing media comprises recordable media.
39. The program product of claim 36 wherein the framework mechanism comprises a first set of object methods to perform a plurality of predetermined functions to implement the object metering environment.
40. The program product of claim 36 wherein the first set of object methods includes at least one before object method that is executed before the execution of a metered client method.
41. The program product of claim 36 wherein the first set of object methods includes at least one after object method that is executed after the execution of the metered client method is commenced.
42. The program product of claim 36 wherein the framework mechanism comprises:at least one metered entity configuration object containing configuration data for at least one metered entity; and a second set of object methods to determine the configuration data for the at least one metered entity. 43. The program product of claim 36 wherein the framework mechanism comprises:at least one metered entity object corresponding to a parameter to be metered;the metered suite class defining: at least one metered suite object containing at least one metered entity object; and a third set of object methods to determine which of the metered entity objects are contained in the metered suite object. 44. The program product of claim 36 wherein the framework mechanism comprises:at least one metered entity configuration object containing configuration data for at least one metered entity; and a second set of object methods to determine the configuration data for the at least one metered entity; at least one configuration data object identifying the plurality of metered entity configuration objects; and a fourth set of object methods to determine the configuration for the at least one metered entity; at least one metered data object containing a plurality of metered entity data objects; a fifth set of object methods to determine the metered data for the plurality of metered entity data objects. 45. The program product of claim 36 wherein the framework mechanism further comprises:at least one metered entity data object containing metering data corresponding to at least one metered entity; at least one threshold object containing threshold data for the at least one metered entity; and a sixth set of object methods to determine the threshold data for the at least one metered entity. 46. The program product of claim 36 wherein the framework mechanism further comprises:at least one principal object corresponding to a type of item to be metered; and a seventh set of object methods for determining the names of the principal objects. 47. The program product of claim 36 wherein the framework mechanism further comprises:at least one metered entity object corresponding to a parameter to be metered; at least one metered suite object containing at least one metered entity object; and a third set of object methods to determine which of the metered entity objects are contained in the metered suite object. 48. The program product of claim 47 wherein the framework mechanism further comprises:at least one metered entity configuration object containing configuration data for at least one metered entity; and a second set of object methods to determine the configuration data for the at least one metered entity; at least one configuration data object identifying the plurality of metered entity configuration objects; and a fourth set of object methods to determine the configuration for the at least one metered entity; at least one metered data object containing a plurality of metered entity data objects; a fifth set of object methods to determine the metered data for the plurality of metered entity data objects. 49. The program product of claim 48 wherein the framework mechanism further comprises:at least one metered entity data object containing metering data corresponding to the at least one metered entity object; at least one threshold object containing threshold data for at least one metered entity object; and a sixth set of object methods to determine the threshold data for the at least one metered entity object. 50. The program product of claim 49 wherein the framework mechanism further comprises:at least one principal object corresponding to a type of item to be metered; and a seventh set of object methods for determining the names of the principal objects. 51. An object oriented framework mechanism for use in a computer system that supports an object oriented programming environment, the framework mechanism comprising:at least one metered entity object corresponding to a parameter to be metered; at least one metered entity configuration object containing configuration data for at least one metered entity; a second set of object methods to determine the configuration data for the at least one metered entity; at least one metered suite object containing at least one metered entity object; a third set of object methods to determine which of the metered entity objects are contained in the metered suite object; at least one configuration data object identifying the plurality of metered entity configuration objects; a fourth set of object methods to determine the configuration for the at least one metered entity; at least one metered data object containing a plurality of metered entity data objects; a fifth set of object methods to determine the metered data for the plurality of metered entity data objects; at least one metered entity data object containing metering data corresponding to at least one metered entity; at least one threshold object containing threshold data for the at least one metered entity; a sixth set of object methods to determine the threshold data for the at least one metered entity; at least one principal object corresponding to a type of item to be metered; and a seventh set of object methods for determining the names of the principal objects. 52. The object oriented framework mechanism of claim 51 wherein the framework mechanism comprises:at least one core function defined by at least one core class and by the relationships between a plurality of classes within the framework mechanism, wherein the implementation of the at least one core function is defined by the framework mechanism and cannot be modified by a user of the framework mechanism; and at least one extensible function defined by at least one extensible class, wherein the implementation of the at least one extensible function is defined by the user of the framework mechanism by extending the at least one extensible class. 53. A computer-implemented method for metering at least one metered object in a computer program, the method comprising the steps of:(a) invoking a client object method on a selected metered object; (b) determining whether any operations are required before executing the client object method; (c) performing any required operations before executing the client object method; (d) executing the client object method; (e) retrieving metered data for the selected metered object; (f) determining the configuration of the selected metered object; (g) updating the metered data for the selected metered object; (h) determining whether any operations are required after executing the client object method; and (i) performing any required operations after executing the client object method. 54. The method of claim 53 wherein step (d) is performed by one thread of control and steps (e)-(g) are performed by another thread of control in a multi-threaded system.
55. The method of claim 53 wherein the step of determining the configuration of the selected metered object includes the steps of:determining whether the selected metered object belongs to a suite; determining applicable thresholds for the selected metered object; determining which methods of the selected metered object to meter; and determining whether the selected metered object is in a synchronous mode. 56. A program product comprising:(A) an object oriented framework mechanism for metering at least one metered object in a computer program, the framework mechanism including at least one metered entity object corresponding to a parameter to be metered, at least one metered entity configuration object containing configuration data for at least one metered entity, a second set of object methods to determine the configuration data for the at least one metered entity, at least one metered suite object containing at least one metered entity object, a third set of object methods to determine which of the metered entity objects are contained in the metered suite object, at least one configuration data object identifying the plurality of metered entity configuration objects, a fourth set of object methods to determine the configuration for the at least one metered entity, at least one metered data object containing a plurality of metered entity data objects, a fifth set of object methods to determine the metered data for the plurality of metered entity data objects, at least one metered entity data object containing metering data corresponding to at least one metered entity, at least one threshold object containing threshold data for the at least one metered entity, a sixth set of object methods to determine the threshold data for the at least one metered entity, at least one principal object corresponding to a type of item to be metered, and a seventh set of object methods for determining the names of the principal objects; and (B) computer-readable signal bearing media bearing the object oriented framework mechanism. 57. A program product comprising:an object oriented framework mechanism for metering at least one metered object in a computer program, the framework mechanism including at least one core function defined by at least one core class and by relationships between a plurality of classes within the framework mechanism, wherein the implementation of the at least one core function is defined by the framework mechanism and cannot be modified by a user of the framework mechanism, the framework mechanism further including at least one extensible function defined by at least one extensible class, wherein the implementation of the at least one extensible class is defined by the user of the framework mechanism by extending the at least one extensible class, thereby defining an object metering environment for metering the number of times the at least one metered object is accessed; and computer-readable signal bearing media bearing the object oriented framework mechanism. 58. The program product of claim 56 wherein the computer-readable signal bearing media comprises recordable media.
59. The program product of claim 56 wherein the computer-readable signal bearing media comprises transmission media.
60. The program product of claim 56 wherein the metered data object, the configuration data object, and the metered entity configuration object with their associated methods comprise a core function of the framework mechanism.
61. The program product of claim 60 wherein the principal object, the metered entity data object, the metered suite object, the metered entity object, and the threshold object with their associated methods comprise an extensible function of the framework mechanism, the implementation of which by a user defines at least one object metering environment for metering the number of times the at least one metered object is accessed.
62. The program product of claim 61 wherein the extensible function further includes a program object, a location object, and a user object.
63. The program product of claim 61 wherein the extensible function further includes a metered usage data object, a metered user data object, a metered location data object, and a metered timing data object.
64. The program product of claim 61 wherein the extensible function further includes a cumulative access threshold object, and a concurrent access threshold object.
65. The program product of claim 57 wherein the computer-readable signal bearing media comprises transmission media.
66. The program product of claim 57 wherein the framework mechanism comprises:at least one metered entity object corresponding to a parameter to be metered; at least one metered entity configuration object containing configuration data for at least one metered entity; a second set of object methods to determine the configuration data for the at least one metered entity; at least one metered suite object containing at least one metered entity object; a third set of object methods to determine which of the metered entity objects are contained in the metered suite object; at least one configuration data object identifying the plurality of metered entity configuration objects; a fourth set of object methods to determine the configuration for the at least one metered entity; at least one metered data object containing a plurality of metered entity data objects; a fifth set of object methods to determine the metered data for the plurality of metered entity data objects; at least one metered entity data object containing metering data corresponding to at least one metered entity; at least one threshold object containing threshold data for the at least one metered entity; a sixth set of object methods to determine the threshold data for the at least one metered entity; at least one principal object corresponding to a type of item to be metered; and a seventh set of object methods for determining the names of the principal objects; wherein the object oriented framework mechanism meters the at least one object according to extended portions of the framework mechanism that are customized to provide the desired object metering environment. 67. A method for metering at least one object in a computer program using a computer system having a central processing unit and a main memory, the main memory having an application program that provides an object oriented programming environment, the method comprising the steps of:(A) providing in the program an object oriented framework mechanism that meters the at least one object according to extended portions of the framework mechanism that are customized to provide a desired object metering environment, the framework mechanism including:a set of core functions wherein the implementation of the core functions is defined by the framework mechanism and cannot be modified by a user of the framework mechanism; and a set of extensible functions wherein the implementation of the extensible functions is defined by the user of the framework mechanism; (B) extending the extensible functions in the framework mechanism to define particular classes having predetermined protocols and defining particular object methods that meter the plurality of objects, the extensible functions defining the desired object metering environment; (C) generating an executable object metering system by integrating together the extensible functions and the core functions; and (D) executing the executable object metering system on the computer system to meter the plurality of objects. 68. The method of claim 67 further including the steps of:(E) invoking a client object method on a selected metered object; (F) executing the client object method; (G) retrieving metered data for the selected metered object; (H) determining the configuration of the selected metered object; and (I) updating the metered data for the selected metered object. 69. The method of claim 68 wherein step (F) is performed by one thread of control and steps (G)-(I) are performed by another thread of control in a multi-threaded system.
70. The method of claim 68 wherein the step of determining the configuration of the selected metered object includes the steps of:determining whether the selected metered object belongs to a suite; determining applicable thresholds for the selected metered object; determining which methods of the selected metered object to meter; and determining whether the selected metered object is in a synchronous mode. 71. The program product of claim 57 wherein the computer-readable signal bearing media comprises recordable media.
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices that are used in a host of different applications. In the early days of computers, software was bundled with hardware and the two were sold together. However, in more recent times, software became available separate from any hardware, which could then be installed and used on a compatible computer system.
When computer software is "sold", ownership of the software is typically not transferred to the buyer, but the buyer is licensed to use the software subject to certain terms and conditions that are contained in the license agreement that accompanies the software. With the growing popularity of computer networks, many people may now have access to run a particular software program that is available on the network. Some software licenses allow a relatively large number of users, but restrict the number of simultaneous users to a much smaller number. In such an environment, the execution of the software must be monitored to assure that the use of the computer software on the network does not violate the license agreement. Any monitoring of a computer program as it runs is referred to herein as metering.
Other situations also arise that require metering computer software as it runs. One such situation is for benchmarking the performance of a computer program to determine how often the different portions of the program are executed and to measure overall system performance. There are numerous different situations where the metering of a computer program is desirable.
In the past, computers have been programmed with metering software. Metering software has typically been custom-developed according to the specific needs of a particular program that needs to be metered. While the specific metering requirements of different computer programs may differ considerably, many of the metering functions are similar across different programs. However, the differences in prior art metering software has precluded reusing very much metering code from one computer program to the next. Each different computer program typically has its own custom, dedicated way of performing the desired metering that is not easily adapted to any new or different computer program.
With the development of Object Oriented (OO) programming techniques, computer programs consist of a collection of objects that each contain data and associated operations or methods for operating on the data. In an object oriented environment, metering implies measuring certain parameters on objects that have methods that are invoked while a computer program executes. However, even in an OO programming environment, the details of the desired metering function must be programmed to fit a desired metering environment. Without a mechanism that can be readily customized and extended to meter a computer program in a particular metering environment, the time required to program and maintain metering software will be excessively long and expensive.
According to the present invention, an object oriented framework mechanism for metering objects provides an infrastructure that embodies the steps necessary to meter a computer program and a mechanism to extend the framework to fit a particular metering environment. Certain core functions are provided by the framework, which interact with extensible functions provided by the framework user. The architecture of the framework allows a programmer to determine the conditions and parameters that apply to the metering environment with an interface that is consistent regardless of the specific combination of parameters specified in the metering environment. The extensible functions allow new metering environments to be easily implemented using the framework. The framework thus allows a common programming interface for metering objects using the framework, which may be easily customized to include new or changed parameters. The framework greatly simplifies the programmer's job of developing code to meter an object-oriented computer program by providing a common programming interface, and by providing established classes that may be easily extended to implement the desired metering environment.
FIG. 18 is a class diagram showing examples of extending the framework of FIGS. 10-17 to implement four specific metering functions; and
FIGS. 19-24 are object diagrams of the metering examples of FIG. 18.
Object-oriented Technology versus Procedural Technology Though the present invention relates to a particular OO technology (i.e., OO framework technology), the reader must first understand that, in general, OO technology is significantly different than conventional, process-based technology (often called procedural technology). While both technologies can be used to solve the same problem, the ultimate solutions to the problem are always quite different. This difference stems from the fact that the design focus of procedural technology is wholly different than that of OO technology. The focus of process-based design is on the overall process that solves the problem; whereas, the focus of OO design is on how the problem can be broken down into a set of autonomous entities that can work together to provide a solution. The autonomous entities of OO technology are called objects. Said another way, OO technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures.
To begin the design process, our framework designer would likely begin with what is called a category diagram. Category diagrams are used to describe high level framework mechanisms, and how those mechanisms relate to one another. FIG. 1 is a category diagram for the example framework ZAF. The notation used in FIG. 1, and that used in the other figures of this specification, is explained in detail in the Notation section at the end of this specification (pages 43-49). Each mechanism in a category diagram represents groupings of objects that perform a particular function. For the purposes of illustration, assume that our framework designer decides that ZAF should be made up of four high level mechanisms: a zoo administration mechanism, a zoo keeper mechanism, an animal mechanism, and a containment unit mechanism.
The zoo administrator class is the definition of the object that is responsible for the overall control of ZAP. Again, OO classes only define the objects that interact to provide a solution to the problem. However, it is by exploring the characteristics of the class definitions that we are able to understand how the objects of the framework mechanism have been designed to provide a living solution that can be customized and/or extended to address future requirements.
As mentioned, an object is created to be a member of a particular class. Therefore, Zelda the Zoo Administrator [object 705] is an object that is a member (actually the only member) of the zoo administrator class. As such, object Zelda is responsible for overall control of ZAF. All of the zoo keeper objects have registered with the Zoo Keeper Register object [object 700]. Therefore, object Zelda obtains a list of the current zoo keepers by calling the list-- zoo-- keepers() operation [step 1] of the Zoo Keeper Register object. The Zoo Keeper Register object has been created as a member of the zoo keeper register class. For the purposes of illustration, assume that this occurs every five minutes as part of Zelda's 5-- minute-- timer() operation. The Zoo Keeper Register object then responds with the zoo keepers list [step 2]. The list of zoo keepers includes Tina the Temperature Checker [object 714], Vince the Vet. [object 740], and Fred the Animal Feeder [object 752]. Each zoo keeper has been created as a member of the zoo keepers class. In particular, objects Tina the Temp. Checker, Vince the Vet., and Fred the Feeder are respectively members of the temperature controller, veterinarian, and feeder subclasses.
Operating system 828 is a suitable multitasking operating system such as AIX; however, those skilled in the art will appreciate that the spirit and scope of the present invention is not limited to any one operating system. Operating system 828 preferably supports an object oriented programming environment such as that provided, for example, by the C++ programming language. One or more application programs 822 provide a programming environment for computer system 800, and include an object metering framework mechanism 870, which is preferably an object oriented framework mechanism. Framework mechanism 870 contains instructions capable of being executed on CPU 810 and may exist anywhere in the virtual memory space of computer 800.
Object Metering Framework Mechanism of the Present Invention
The object metering framework mechanism disclosed herein provides an architecture for metering the usage of objects in a computer program. Extending the framework to meter objects in a specific environment defines a "metering environment." For example, extending the framework to meter the usage of objects by one or more users creates a metering environment that is tailored to that specific task.
By providing framework mechanism 870 within computer system 800 to meter the usage of objects, a uniform interface for metering objects in any computer program is provided. Framework mechanism 870 may replace all of the proprietary systems for metering objects that are currently used. This would allow a common programmer interface for virtually any program that requires object metering. This common interface would greatly ease the burden of programming and maintaining custom object metering systems. Thus, one of the primary benefits of the framework disclosed herein is the capability to meter objects using a simple, easy to use interface defined by the framework.
Referring to FIG. 9, an object metering framework in accordance with the preferred embodiment performs steps that comprise a method 900 for metering objects. The framework is invoked whenever a method on a metered object is invoked (step 898). Once the method is invoked, the first step is to determine if any preprocessing (i.e., "before logic") is required before executing the method (step 910). If before logic is required (step 910=YES), a data collection is retrieved for all metered objects (step 920). The data collection contains all the metering data pertaining to the metered objects. Next, the configuration of the object corresponding to the invoked method is determined (step 930). The configuration may include information such as whether or not the object is a member of a suite, the applicable thresholds for use, the methods that are to be metered, and whether or not the metered data for the object is stored in a fixed location or is distributed across several locations. Once the configuration data has been determined (step 930), the appropriate before logic is executed (step 940). One example of suitable before logic is to start a timer when the timing of a method is to be metered. Note that before logic may include the updating of metered data for the object. Once any required before logic is executed, the invoked method is executed (step 950).
After the invoked method is executed (step 950), a determination is made whether or not there is any required postprocessing (i.e., "after logic" that must be executed) (step 960). If there is no required after logic (step 960=NO), method 900 ends. If there is after logic that must be performed (step 960=YES), method 900 first checks to see if configuration data for the invoked method has already been retrieved (step 962). If before logic was executed for the invoked method, the configuration data was previously retrieved in steps 920 and 930, and need not be retrieved again. If configuration data was not previously retrieved (step 962=NO), the data collection is retrieved (step 970) and the configuration is determined (step 980). Next, the after logic is executed (step 990).
Updating the metered data for an invoked method may occur during the execution of the before logic (step 940) or during the execution of the after logic (step 980). In the preferred embodiment, the updating of metered data is performed as part of the after logic so that access to the method may be granted without substantial overhead and delay, with the metering functions occurring in parallel with or after the execution of the invoked method by the after logic. The specific steps involved with updating the metered data depend on the type of metering being performed. For example, if usage of an object is being metered, the metered data is incremented to reflect another use of the object. If the users of an object are being metered, the user that called the method would be added to the list of users if this is the first time the user called a method on the object, or would increment the count of a user that had previously called a method on the object. If the timing of the called method is being metered, a timer would be started during the before logic (step 940) before invoking the method, and would be stopped during the after logic (step 990). The execution time for the method would then be stored as part of the after logic (step 990). As shown by the examples discussed above, the framework 870 may be extended by a programmer to define any number of different object metering environments.
The steps in method 900 are shown to be sequential, but may be performed in parallel in a multi-threaded system. In fact, a significant advantage that framework 870 provides when compared to prior art metering systems is that the method and the metering functions may be performed simultaneously, thereby reducing the overhead required to perform the metering function. A multi-threaded system may execute the invoked method with one thread and may perform the metering functions in another thread. Many prior art metering systems perform the metering functions before granting access to execute the method. This is one solution for preventing users that would exceed the number of users allowed by the license agreement from accessing the method. However, another solution that may be implemented using the object metering framework 870 is to grant access to the desired method each time the framework is invoked after checking a simple status register. If the status register indicates the method can be accessed, the method is executed, and the metering functions are performed either in parallel or after the method is executed. If the metering function determines that incrementing the number of users results in a number of users equal to the maximum number allowed by the license agreement, the metering function updates the status register to indicate that the method may not be accessed. In this manner the object metering may be performed in a multi-threaded system without the overhead associated with prior art metering systems, which typically determine the type of metering needed and perform extensive checks before granting access to the method.
The fact that the preferred embodiment of the framework is object oriented allows the user of the framework to easily define the needed functions by subclassing from the classes defined within the framework using known object oriented programming environments, such as C++. The preferred embodiment of the present invention is an object oriented object metering framework. While many different designs and implementations are possible, one suitable example of an object oriented object metering framework is disclosed below to illustrate the broad concepts of the present invention.
FIG. 10 is a category diagram of the object metering framework mechanism 870 in accordance with the preferred embodiment. Those skilled in the art will appreciate that the categories illustrated in FIG. 10 represent collections of object oriented programming (OOP) classes that encapsulate data attributes and behaviors (or methods). Objects instantiated as members of these classes are stored in the main memory 820 of computer system 800. These classes may be implemented, for example, in a computer system operating environment that supports the C++ programming language.
The classes have been divided into six categories: SOM Toolkit, Principals, Metered Data, Metering, Configurations, and Thresholds. All but the SOM Toolkit are extensible categories (as indicated by the "E" label), meaning that users may extend the classes in these categories by defining and implementing classes that are subclasses of framework-defined classes. The SOM Toolkit is not strictly necessary to an implementation of a framework in accordance with the invention (as indicated by the "N" label), but is included here in the preferred embodiment for the convenience it provides in providing persistence, defined metaclasses, and methods for subclasses of these classes. Some of the benefits SOM provides is persistence and metaclasses. The Principals, Metered Data, Metering, Configurations, and Thresholds categories each have a using relationship with the SOM Toolkit, indicating that classes within these categories may invoke the methods provided by the SOM Toolkit. Note that the relationships between categories are core relationships (as indicated by the "C" label), meaning that the framework user cannot modify these relationships.
FIG. 11 is a top level class diagram of metering framework 870. The SOM Toolkit category includes a PersistentObject class, and a BeforeAfter metaclass. The Principal class, SpecificPrincipals class, MeteredSuite class, and MeteredEntity class are all members of the Principals category. Classes that are members of the MeteredData category include: MeteredData, MeteredEntityData, and SpecificMeteredEntityData. The BeforeAfter metaclass is a member of the Metering category. Classes that are members of the Configurations category include: ConfigurationData, MeteredEntityConfiguration, and SpecificMeteredEntityConfigurations. The Thresholds category includes the Threshold class and the SpecificThresholds class. The methods provided in each class are not shown in FIG. 11, but are shown in subsequent figures.
FIG. 11 illustrates the relationships between the classes in the framework. The MeteredData class, the ConfigurationData class, and the MeteredEntityConfiguration class are core classes of the framework. The rest of the classes are extensible classes, while the relationships between the classes are part of the core function of the framework. The various classes of FIG. 11 with "specific" in their name represent any number of classes that are subclasses as required to define any number of object metering environments.
The framework as illustrated in FIG. 11 is extremely flexible and powerful. A programmer may define any number of metering configurations or environments by appropriate subclassing from the defined classes of the framework. In fact, the framework of FIG. 11 must be subclassed to perform a desired metering function. While FIG. 11 illustrates the framework of the present invention in broad terms, the details of the preferred embodiment are best understood with reference to the class diagrams of FIGS. 12-17, which illustrate subclasses that perform several specific metering functions. Note, however, that the specific metering functions defined in the preferred embodiments are exemplary of the types of metering functions that may be implemented by appropriate subclassing, and the framework mechanism expressly encompasses any and all suitable subclasses for metering any desired parameter relating to objects in a computer program.
A class diagram of the classes in the SOM Toolkit category are shown in FIG. 12 for the preferred embodiment. The classes in the SOM Toolkit are a portion of IBM's System Object Model (SOM) Toolkit version 2.1. The SOM toolkit is used merely for illustrating an example of one specific implementation of the object metering framework. Note that the SOM Toolkit of FIG. 12 provides a SOMMBeforeAfter metaclass and a SOMPPersistentObject class that correspond to the BeforeAfter metaclass and PersistentObject class of FIG. 11. While the SOM Toolkit is not strictly necessary to implement the object metering framework, it provides a very useful mechanism for defining many classes of the object metering framework through appropriate subclassing. The SOMPPersistentObject class is a subclass of the SOMObject class, whose metaclass is the SOMClass metaclass. SOMMBeforeAfter is a metaclass that is defined by subclassing from the SOMClass metaclass and the SOMObject class. The SOMObject class is the root class for all SOM classes. All SOM objects must be subclasses of SOMObject or one of its subclasses. SOMObject defines the set of methods that provide the behavior required for all SOM objects. For example, the somGetClassName() method is used to get the name of the class that defines the object being called.
The SOMMBeforeAfter metaclass provides two methods for invoking methods before and after each invocation of an instance. The sommBeforeMethod() is invoked before the invocation of an instance, and the sommAfterMethod() is invoked after the invocation of an instance Other methods for the SOM classes are also defined in the SOM Toolkit, but are not described here. The reader may refer to the appropriate SOM documentation for further details. The details of the SOM methods used in the object metering framework 870 are best understood with reference to the subclasses of FIG. 13.
Referring to FIG. 13, the MeterUsage class, the MeterConcurrentUsage class, the MeterUsers class, the MeterLocation class, and the MeterTiming class are all members of the Metering category, and represent suitable subclasses that define different types of metering. Each of these metaclasses correspond to a different BeforeAfter metaclass of FIG. 11. Each have methods that are used by the objects within the framework mechanism to perform the defined metering functions. For example, the MeterUsage metaclass is defined to meter basic usage of an object such as instantiation or general method usage. It uses the sommAfterMethod() method to meter the usage of the object after the invoked method on the object has already been executed. The MeterConcurrentUsage metaclass provides a mechanism to meter concurrent usage of an object. Invoking the sommBeforeMethod() method increments the concurrent usage of the object before the method is executed. In similar fashion, invoking the sommAfterMethod() method decrements the concurrent usage of the object after the method is executed.
The MeterUsers metaclass is defined to meter the User class, which is a subclass of the Principal class. The MeterUsers metaclass defines two methods. The first, getUserName(), is an internal method that determines which user (i.e., human) to associate with the object being metered, and returns a User instance corresponding to the human user. The second is sommAfterMethod(), which performs the metering function for the User after the client method is executed.
The MeterLocation metaclass is defined to meter the location of the metered entity in conjunction with the Location object, which is a subclass of the Principal class. MeterLocation defines a getLocation() method, a changeLocation() method, and a sommAfterMethod() method. The getLocation() method is an internal method that returns the Location object associated with a metered object for location. The changeLocation() method changes the Location object associated with a metered object. The sommAfterMethod( ) method performs the location metering function after the client method is executed.
The MeterTiming metaclass is defined to meter the amount of time needed to execute a metered method. MeterTiming defines the following methods: sommBeforeMethod(); sommAfterMethod(); startTimer(); and stopTimer(). The sommBeforeMethod() method is called before the execution of the client method, and calls the startTimer() internal method to start the timer. The method is then executed, and the sommAfterMethod() is called, which calls the stopTimer() internal method to stop the timer. The timer then contains the valid time that was required to execute the client method.
The metaclasses and methods illustrated in FIG. 13 represent suitable BeforeAfter metaclasses (of FIG. 11). One skilled in the art will recognize that these metaclasses that are defined in the preferred embodiment are merely examples of many different types of metering functions that may be implemented using the framework. Additional metaclasses may be defined as needed to define other types of metering that needs to be performed.
FIG. 14 illustrates suitable classes that belong to the Principals category in the preferred embodiment (with the exception of the two SOM classes from the SOM Toolkit category). MeteredEntity is an extensible abstract class. An object to be metered must be subclassed from the MeteredEntity class. MeteredSuite is a class that represents a group of MeteredEntity objects, as represented by the MeteredSuite class having a "has by value" relationship with the MeteredEntity class, with the "n" on the class relationship indicating that MeteredSuite may contain many different metered entities. A MeteredSuite's metered data is the sum of the metered Entities that it contains. The suite concept makes it easy to meter the usage of a group of objects, such as when a framework mechanism is invoked. MeteredSuite defines an addMeteredEntity() method, a getMeteredEntities() method, and a removeMeteredEntity() method. The addMeteredEntity() method adds a MeteredEntity to this MeteredSuite. The getMeteredEntities() method returns the collection of Metered Entities for this MeteredSuite. And the removeMeteredEntity() method removes a specified MeteredEntity from this MeteredSuite.
Principal is an abstract class that defines the behavior for principals in the framework. Principals are those objects that either use or are associated with the Metered Entities. Specific types of principals are subclasses of the Principals class, such as the Program class, Location class, and User class of the preferred embodiment illustrate in FIG. 14. Principal defines a setName() method, an is VIP() method, and a getName() method. The setName() method sets the name of the principal to the input string that is passed as a parameter. The is VIP() method is used to determine whether the object is a VIP (Very Important Principal), and returns a true if the object is a VIP and a false if not. The getName() method is used to determine and return the name of the Principal object. Note that the MeteredSuite class and the Principal class are both subclassed from the SOMPPersistentObject class to take advantage of its predefined methods, which provides persistence.
The Program, Location, User, and VIPUser classes are examples of SpecificPrincipals classes (from FIG. 11) that are defined in the preferred embodiment by appropriate subclassing from the Principal class. The Program class is a Principal that represents an executable program. The Program class defines a method execute() and a method new(). The execute() method executes a computer program associated with the Principal object. The new() method is invoked by passing the name of a program, which causes the Program object corresponding to this name to be instantiated.
The Location class represents a location where metered data can physically exist, such as on a computer workstation (i.e., node) on a network. Location defines a new() method, which is used to create a new object with the name passed as an argument in the new() method invocation.
The User class represents a human user who will use or interact with a MeteredEntity. User objects are created for users that need to be monitored. The User class defines a new() method that creates a new User object with a name that is passed as a parameter when the new() method is invoked.
The preferred embodiment as illustrated in FIG. 14 also includes a VIPUser class, which is a subclass of the User class and a VIP class. The VIP class defines a single method is VIP(), which returns true if the User is a VIP and a false if not. Since the VIP class is a VIP, is VIP() always returns true for this class. A VIP is a very important principal. The VIP class is defined so that objects of this class can enjoy special privileges. For example, an object that has VIP status may not be prevented from accessing an object if some limit had already been reached on that object. Subclasses of VIP must use correct class precedence to ensure that the subclass's is VIP() method is called. Otherwise, the object will not enjoy VIP status.
Classes in the Metered Data category are shown in the class diagram of FIG. 15, and include a MeteredData class, a MeteredEntityData class, a MeteredUsageData class, a MeteredConcurrentUsageData class, a MeteredUserData class, a MeteredLocationData class, and a MeteredTimingData class. Both MeteredData and MeteredEntityData are subclasses from the SOMPPersistentObject class to take advantage of its predefined methods which provide persistence. The MeteredData class is a collection of one or more MeteredEntityData objects, as represented by the "has by reference" relationship from MeteredData to MeteredEntityData. MeteredData defines two methods. The first is getMeteredEntityDataCollection(), which returns the collection of MeteredEntityData objects. The second is getMeteredEntityData(), which is used to access the MeteredEntityData for the object name that is passed as a parameter.
The MeteredEntityData class contains all the metered data for that class. MeteredEntityData defines two methods, clearData() and getData(). The clearData() method removes all the collected data for a metered object. The getData() method is used to return the data associated with the class specified by the input parameter. Different types of MeteredEntityData are defined by appropriate subclassing. In the preferred embodiment as illustrated in FIG. 15, a MeteredUsageData class, a MeteredConcurrentUsageData class, a MeteredUserData class, a MeteredLocationData class, and a MeteredTimingData class define different types of metered data that may need to be stored. Each of these represent a SpecificMeteredEntityData class as shown in FIG. 11.
The MeteredUsageData class collects usage data for Metered Entities, and includes two methods, incrementMethodInvocation() and incrementMethodInvocationData(). The incrementMethodInvocation() method is invoked to increment the usage for a metered object. The incrementMethodInvocation() method in turn invokes the incrementMethodInvocationData() internal method, which actually increments the usage count for the method specified by the class and method names that are passed as parameters. The MeteredConcurrentUsageData collects concurrent usage data for Metered Entities. This is a specialization of standard usage metering. Instead of simply incrementing the usage data for each access, the data must be incremented at the beginning of each access and must be decremented when the method has completed execution. In addition to the methods defined through subclassing, MeteredConcurrentUsageData also defines a decrementMethodInvocation() method and a decrementMethodInvocationData() method. The decrementMethodInvocation() method is called to decrement the data when a method has completed execution, and calls the internal method decrementMethodInvocationData() to perform this operation.
The MeteredUserData class collects data on human users who are associated with a MeteredEntity. Two methods on this class are defined. When the incrementUserAccess() method is called, the internal method incrementUserAccessData() is invoked to increment the access of the user corresponding to the class of the client method.
The MeteredLocationData class stores a location that is associated with a specified MeteredEntity, and defines three methods: changeLocation(), storeLocation() and storeLocationData(). The changeLocation() method is invoked to change the existing Location associated with a specified metered entity. Two parameters are passed with changeLocation() is invoked: the Class name, and the Location object. The Location of the class is then changed to the new location. The storeLocation() method assigns a Location object to a particular class name, where the Location and Class are passed as parameters. Both of these methods invoke the storeLocationData() internal method to store the Location associated with metered entities.
The last class to discuss in FIG. 15 is the MeteredTimingData class, which stores timing information for Metered Entities as a collection of individual time entries. The methods defined by the MeteredTimingData class include: addTimingEntry(), addTimingEntryData(), and getData(). The addTimingEntry() method adds a timing entry for a class and method name passed as parameters by invoking the addTimingEntryData() internal method. The getData() method returns the collection of time entries for a class passed as an input parameter.
Note that the number of subclasses to MeteredEntityData in the preferred embodiment is the same as the number of metaclasses in the Metering category (FIG. 13), and that each metaclass has a corresponding MeteredEntityData class. This makes sense because metering data must be defined for each type of metering to be performed.
Referring now to FIG. 16, the classes that are members of the Configurations category include a ConfigurationData class, a MeteredEntityConfiguration class, and a MeteredMethods class. The other classes in FIG. 16 come from other categories, as indicated. The ConfigurationData class is a collection of MeteredEntityConfiguration objects for each metered object, as indicated by the "has by reference" relationship with the MeteredEntityConfiguration class. The ConfigurationData class defines several methods, including: addEntityConfiguration(), getMeteredEntityConfiguration(), removeMeteredEntityConfiguration(), getCentralLocation(), and setCentralLocation(). The addEntityConfiguration() method is used to add a configuration for a new object to be metered. An input parameter defines the name of the metered class. The getMeteredEntityConfiguration() method returns the MeteredEntityConfiguration object for a class that is passed as a parameter. The removeMeteredEntityConfiguration() method removes configuration information for the class name passed as an input parameter. This method and addEntityConfiguration() are complementary methods, with one adding configuration data for a class and the other removing configuration data for a class. The getCentralLocation() method returns the location of the node on the network that has the metered data for all metered objects. Knowing the central location of all metered data is necessary in order to synchronously update metered data in the network. The setCentralLocation() method takes the node identifier that is passed as a parameter and sets the central location for metered data to that node.
The MeteredEntityConfiguration class defines a configuration object for each object to be metered. Each MeteredEntityConfiguration object contains all configuration data for the corresponding metered object, including whether the object belongs to a suite; any applicable thresholds that are needed to perform certain functions when certain metering conditions occur; and whether or not the object is in synchronous mode. These configuration options are discussed in more detail below.
The first type of configuration data we will consider for the preferred embodiment illustrated in FIG. 16 involves whether or not the object is included in a suite. A suite of objects is defined if the objects are all related in a particular way. One example of a suite is an object-oriented framework mechanism. All the objects in a framework could be listed as members of a suite so that access to one object in the suite is metered as an access to all objects that are members of the suite. Several methods are defined in the preferred embodiment that relate to suites. The first is addToSuite(), which adds the client object to the suite that is passed as a parameter. Another method is clearSuites(), which is used to remove all suites from the configuration data for this object. The getSuites() method is used to return the collection of all the suites that include the metered object corresponding to the configuration data. And the removeFromSuites() method is used to remove the suite that is passed as a parameter from the configuration data.
The second type of configuration data relates to appropriate thresholds that require the framework to take certain action. An example of a suitable threshold relates to the number of concurrent users, and if the number exceeds the threshold (corresponding to the number of concurrent users allowed by the license agreement), the framework takes appropriate actions, such as notifying a user or system administrator that the user limit has been exceeded. Several methods are defined that relate to thresholds. The addThreshold() method adds the threshold object that is passed as a parameter to the configuration data. The clearThresholds() method is used to remove all thresholds from the configuration data. The getThresholds() method returns a collection of threshold objects for the object to be metered that corresponds to this configuration data. And the removeThreshold() method is used to remove a threshold that is passed as a parameter from the configuration data.
Another type of configuration data relates to whether or not the metered object corresponding to the MeteredEntityConfiguration object is in synchronous mode or not. If the metered data needs to be collected from one central location, it is in synchronous mode. If the metered data may be collected at various locations and collated later, it is in asynchronous mode. The isSynchronousMode() method is used to determine whether the metered data is in synchronous mode or not. If this method returns true, the metered data is in synchronous mode. If false, it is in asynchronous mode. The setSynchronousMode() method is used to set the collection mode for this configuration, with a true indicating synchronous and a false asynchronous.
The MeteredEntityConfiguration class also defines a method clearAll(), which is used to clear all configuration data from the MeteredEntityConfiguration object corresponding to a metered object. Note that the MeteredEntityConfiguration class has a using relationship with the MeteredEntity class, and MeteredSuite class, and the Threshold class, since the methods within MeteredEntityConfiguration may need to call methods on these other classes.
The MeteredMethods class is a subclass of MeteredEntityConfiguration, and corresponds to one suitable SpecificMeteredEntityConfiguration class as shown in FIG. 11. Specifically, MeteredMethods is used to store configuration information for those classes that are being metered at a method level. One example of such a class is Metered Usage. In addition to the methods defined in MeteredEntityConfiguration, MeteredMethods also defines other methods that relate to which methods are being metered. The addMethodToInclude() method adds a method that is input as a parameter as a method to meter in this configuration. The clearMethodsToInclude() method removes all configuration information for methods to meter. And the getMethodsToInclude() method returns a collection of methods that are metered in this configuration.
Referring now to FIG. 17, classes that belong to the Thresholds category include a Threshold class, a CumulativeAccessThreshold class, and a ConcurrentAccessThreshold class. Threshold is a subclass of SOMPPersistentObject, and uses the Program class. The Threshold class defines the event to monitor, the applicable limit, and the program to notify if the limit is exceeded. The Threshold class provides methods that relate to the functions listed above. For example, the decrementUsage() method decrements the current limit setting by one, while the incrementUsage() method increments the current limit setting by one. The getLimit() internal method returns the current limit associated with this threshold. The getProgram() internal method returns the Program Principal associated with this threshold which is expected to run when the limit is exceeded for this threshold. The setLimit() method sets the threshold limit for this threshold. And the setProgram() method sets the program to call to the program passed as a parameter if the limit is exceeded.
The CumulativeAccessThreshold class and the ConcurrentAccessThreshold class are subclasses of the Threshold class, and define additional methods needed for their specific functions. For example, the CumulativeAccessThreshold class, which sets a threshold for total cumulative accesses, includes a decrementUsage() method and a new() method. Since the cumulative access threshold for a class will increase over time, the decrementUsage() method in this subclass is overridden to do nothing so that the incrementUsage() method adds to the limit but the decrementUsage() method does not perform the typical decrementing, resulting in a cumulative access threshold value. The new() method returns a new CumulativeAccessThreshold object that is instantiated when new() is invoked. In similar fashion, the new() method on the ConcurrentAccessThreshold class returns a new ConcurrentAccessThreshold object that is instantiated when new() is invoked. In this manner thresholds may be defined as needed.
FIG. 11 best distinguishes between core and extensible functions in the object metering framework of the present invention. Specifically, as noted above, the MeteredData class, the ConfigurationData class, and the MeteredEntityConfiguration class are core classes, while the remaining classes are extensible. All class relationships shown in FIG. 11 are core relationships, and may not be modified by the user of the framework. In fact, it is the fixed character of these relationships between classes that characterizes a framework and makes it useful and powerful. The core function of the object metering framework is defined by the core classes, the core class relationships, and the functional requirements that cause the framework to behave in the desired manner. As described above with respect to FIG. 9, the overall core function of the object metering framework includes the steps of method 900. The specific steps that make up any metering environment depend on how the user of the framework extends the classes and defines (or overrides) the appropriate methods.
Examples of Extending the Object Metering Framework
To understand how a programmer may use the object metering framework of the invention, several examples are described below. FIG. 11 illustrates how a programmer may subclass an Object to be Metered from the MeteredEntity class and assign it to an appropriate BeforeAfter metaclass to perform desired metering functions. For the preferred embodiment, specific examples of appropriate subclassing and assignments to metaclasses are shown in FIG. 18. If a programmer wants to meter Users of metered objects, a UserExample class could be subclassed from the MeteredEntity class and its metaclass is the MeterUsers metaclass. If the programmer wants to meter the time it takes to executed metered methods, a TimingExample class could be subclassed from the MeteredEntity class and its metaclass is the MeterTiming metaclass. If the programmer wants to meter the location where metered objects are stored, a LocationExample class could be subclassed from the MeteredEntity class and its metaclass is the MeterLocation metaclass. If the programmer wants to meter the usage of objects, a UsageExample class could be subclassed from the MeteredEntity class and its metaclass is the MeterUsage metaclass. In addition, if more complex metering is desired that will meter both usage and location of metered objects, the programmer could define a UsageAndLocationExample class as a subclass of the MeteredEntity class, and its metaclasses are the MeterUsage metaclass and the MeterLocation metaclass. From the examples above, we see that if a programmer wants to meter a particular attribute, he must define a suitable metaclass in the Metering category, then must subclass the metered object from the MeteredEntity class and select the corresponding metaclass. The operation of the object metering framework for the examples of FIG. 18 is discussed below with reference to the object diagrams of FIGS. 19-24.
An object diagram for the UsageExample in FIG. 18 is shown in FIG. 19. A ClientProgram object invokes the object metering framework by invoking a someMethod() (step 1) on UsageExample, which is a metered object. This method is executed (step 2). Following the execution of the method, or in parallel to it, the metering functions are performed, which are included in steps 3-12. The sommAfterMethod() on a MeterUsage object is invoked (step 3) to kick off all the functions that must be performed after the method is executed (in step 2) to perform the desired usage metering. The MeterUsage object invokes the getMeteredEntityCollection() method on the MeteredData object (step 4), which returns the collection of objects that correspond to Metered Entities (in this case, metered objects and/or methods). Once the MeterUsage object has the collection of Metered Entities, it invokes the somGetClassName() method on the UsageExample object (step 5), which returns the name of the class on which the client method was invoked in step 1. Next, the incrementMethodInvocation() method is invoked (step 6), with the class name and method name of the method invoked in step 1 passed as parameters. In order to know how to increment the method invocation, the configuration must first be determined by invoking the getMeteredEntityConfiguration() method (step 7), passing the name of the class for which the metered entity configuration is desired. This method identifies the MeteredMethods as the applicable configuration class. Next, the MeteredUsageData object invokes the getSuites() method (step 8), the getThresholds() method (step 9), the getMethodsToInclude() method (step 10), and the isSynchronousMode() method (step 11) on the MeteredMethods object to determine the configuration that pertains to the method invoked in step 1. Once the configuration is known, MeteredUsageData invokes its own incrementMethodInvocationData() method to appropriately increment the method invocation data. For example, if the UsageExample object is part of a suite, this method would increment the method invocation data for all objects in the suite, not just for the object that contains the client method called in step 1.
FIG. 20 shows the object diagram for the UserExample of FIG. 18. Again, the framework is invoked by a ClientProgram calling someMethod() (step 1), which is a method on UserExample, which is an object that has been selected for metering by appropriate subclassing. The UserExample object invokes the someMethod() method, which executes the method requested by the client program. Either after someMethod() executes (in single threaded systems), or in parallel (in multi-threaded systems), the framework may perform the metering functions represented by steps 3-14. UserExample invokes the sommAfterMethod() on the MeterUsers object (step 3) to commence the metering function. The MeterUsers object then invokes its own getUserName() method, which returns the name of the human user that invoked someMethod() in step 1. A User object for this user is then created by invoking the new() constructor method (step 5). Next, invoking the getMeteredEntityDataCollection() method on the MeteredData object returns the collection of metered entity data (step 6). MeterUsers then invokes the somGetClassName() method on the UserExample object (step 7), which returns the name of the class on which the client method was invoked in step 1. Next, the incrementUserAccess() method is invoked (step 8) to instruct the MeteredUserData object that it needs to update its count of how many times the user has accessed the method. The class pertaining to the method (from step 7) and the User are passed as parameters. But before the MeteredUserData can update the configuration data to reflect the new access to the method, it must first determine which configuration data pertains to the invoked method in step 1 by invoking the getMeteredEntityCollection() method on the ConfigurationData object (step 9). This method returns the object MeteredEntityConfiguration that corresponds to the client method called in step 1. The MeteredUserData object then determines the configuration by invoking the getSuites method (step 10), the getThresholds() method (step 11), and the isSynchronousMode() method (step 12) on the MeteredEntityConfiguration object, and appropriately increments the user access count by invoking its own incrementUserAccessData() method (step 13).
In reviewing the object diagrams of FIGS. 19 and 20, it seems that a pattern is developing in how the framework performs the needed metering in different metering environments. The object diagram of FIG. 21 shows the object interaction for the LocationExample in FIG. 18. Again, the framework is invoked by a ClientProgram invoking someMethod() (step 1) on LocationExample, which executes that method (step 2). Step 3 commences the metering function, step 4 determines the location of the LocationExample (the metered object), and step 5 creates a new Location object. Step 6 gets the data collection for all the metered entities, and step 7 gets the class name that the LocationExample was instantiated under. Step 8 passes the class name from step 7 and the Location to tell MeteredLocationData where to store the data. Step 9 returns the MeteredEntityConfiguration object that pertains to the method invoked in step 1, and MeteredLocationData then determines the configuration by performing steps 10-12. The MeteredLocationData is then updated in step 13, and step 14 gets the name of the Location object.
An object diagram for the TimingExample of FIG. 18 is shown in FIG. 22. Here, the object interaction is somewhat different than those examples previously discussed because the framework must start a timer before allowing the method to execute, and must stop the timer after the method executes. A ClientProgram invokes someMethod() in step 1. Step 2 invokes the sommBeforeMethod() method on the MeterTiming object, which causes it to invoke the getMeteredEntityDataCollection() in step 3, which returns the collection of metered entity data. Next, MeterTiming invokes startTimer() in step 4, and TimingExample then performs step 5 which executes the method invoked in step 1. After the method has executed, the sommAfterMethod() method is invoked in step 6, resulting in invoking the stopTimer() method in step 7. The class of the TimingExample object is then discovered in step 8 using the somGetClassName() method. In step 9, the time for executing someMethod() in step 5 is added to MeteredTimingData by invoking the addTimingEntry() method and passing the class discovered in step 8, and method invoked in step 1, and the time stored in MeterTiming as parameters. MeteredTimingData must first determine which MeteredEntityConfiguration applies to the method invoked in step 1 by performing step 10. MeteredTimingData then performs steps 11-13 on MeteredEntityConfiguration, and performs step 14 to appropriately add the timing entry.
An object diagram for the UsageExample of FIG. 18 is shown in FIG. 23. A ClientProgram invokes someMethod() in step 1, which is executed in step 2. Step 3 kicks off the metering function of the framework. Step 4 returns the collection of MeteredEntityData. Step 5 returns the class that UsageExample belongs to. Step 6 instructs MeteredEntityData to increment the method invocation for the method called in step 1, but MeteredEntityData must first determine in step 7 which MeteredMethods object applies to the client method invoked in step 1. This method returns the MeteredMethods object in FIG. 23. MeteredEntityData then determines the configuration in steps 8-11. We assume here that isSynchronousMode() in step 11 returned true, which requires that MeteredEntityData determine the central location in step 12, and change the MeteredUsageData at the central location (i.e., MeteredUsageData on Central) in step 13.
An object diagram corresponding to the UsageAndLocationExample of FIG. 18 is shown in FIG. 24. This object diagram traces through all steps (1-27) for metering both Usage and Location at the same time. The details of each step will be evident from a close examination of the object diagrams pertaining to the UsageExample (FIG. 19) and the LocationExample (FIG. 21). The object diagram of FIG. 24 illustrates that the framework may be used to monitor multiple features at once.
As the preferred embodiment illustrates, the framework provides an extremely flexible and powerful tool for implementing many different object metering environments by simply defining objects that implement the features specific to a particular metering environment. While the preferred embodiment is described in relation to FIGS. 12-17, with specific subclassing provided, the framework in its broadest sense is represented in FIG. 11. It should also be noted that not all of the features in FIG. 11 are strictly required, depending on the type and sophistication of the metering that is desired. For example, if the metering is for the purpose of simply logging and reporting usage of objects in a computer program, the framework of FIG. 11 with the Thresholds classes deleted would adequately perform the job. Many modifications to the object metering framework of the invention are possible and are anticipated within the scope of the invention.
There is, as yet, no uniformly accepted notation for communicating object-oriented programming ideas. The notation used in this specification is very similar to that known in the programming industry as Booch notation, after Grady Booch. Mr. Booch is the author of Object-Oriented Analysis and Design With Applications, 2nd ed. (1994), available from The Benjamin/Cummings Publishing Company, Inc. Use of Booch notation concepts within this specification should not be taken to imply any connection between the inventors and/or the assignee of this patent application and Mr. Booch or Mr.
Booch's employer. The notational system used by Mr. Booch is more fully explained at Chapter 5, pp. 171-228 of the aforementioned book. The notational system used herein will be explained generally below. Other notational conventions used herein will be explained as needed.
In FIG. 7, for example, the object called Zelda 705 obtains a list of current zoo keepers by calling an operation called List Zoo Keepers from the object called Zoo Keeper Register. The second processing step is represented in FIG. 7 by the Zoo Keeper Register object responding to the operation call by passing a message to the Zelda object that comprises the zoo keeper list. The zoo keeper objects include members of the Zoo Keepers class called Tina, Vince, and Fred. The third step indicated in the object diagram is for the object Zelda to pass a message to each of the zoo keepers instructing them to check the animals by calling the respective Check Animals operation of each zoo keeper object.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4943932 *Apr 15, 1987Jul 24, 1990Cimflex Teknowledge CorporationArchitecture for composing computational modules uniformly across diverse developmental frameworksUS5057996 *Jun 29, 1989Oct 15, 1991Digital Equipment CorporationWaitable object creation system and method in an object based computer operating systemUS5101364 *Feb 9, 1990Mar 31, 1992Massachusetts Institute Of TechnologyMethod and facility for dynamic video composition and viewingUS5119475 *Aug 29, 1991Jun 2, 1992Schlumberger Technology CorporationObject-oriented framework for menu definitionUS5181162 *Dec 6, 1989Jan 19, 1993Eastman Kodak CompanyDocument management and production systemUS5195172 *Jul 2, 1990Mar 16, 1993Quantum Development CorporationSystem and method for representing and solving numeric and symbolic problemsUS5226161 *Aug 31, 1992Jul 6, 1993Wang Laboratories, Inc.Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data typesUS5247693 *Nov 17, 1992Sep 21, 1993The Foxboro CompanyComputer language structure for process control applications and method of translating same into program code to operate the computerUS5249270 *Mar 29, 1991Sep 28, 1993Echelon CorporationDevelopment system protocolUS5257384 *Sep 9, 1991Oct 26, 1993Compaq Computer CorporationAsynchronous protocol for computer system managerUS5261080 *Aug 28, 1992Nov 9, 1993Wang Laboratories, Inc.Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formatsUS5274572 *Mar 6, 1990Dec 28, 1993Schlumberger Technology CorporationMethod and apparatus for knowledge-based signal monitoring and analysisUS5276775 *Oct 13, 1992Jan 4, 1994Texas Instruments Inc.System and method for building knowledge-based applicationsUS5287447 *Jun 28, 1991Feb 15, 1994International Business Machines CorporationMethod and system for providing container object attributes to a non-container objectUS5293470 *Jan 28, 1991Mar 8, 1994International Business Machines CorporationData processing system for defining and processing objects in response to system user operationsUS5297283 *Oct 16, 1992Mar 22, 1994Digital Equipment CorporationObject transferring system and method in an object based computer operating systemUS5315703 *Dec 23, 1992May 24, 1994Taligent, Inc.Object-oriented notification framework systemUS5367633 *Jan 11, 1994Nov 22, 1994Taligent, Inc.Objected oriented notification framework systemUS5369766 *Mar 25, 1993Nov 29, 1994Taligent, Inc.Object-oriented loader system with support for different load formatsUS5379430 *Aug 4, 1993Jan 3, 1995Taligent, Inc.Object-oriented system locator systemUS5388264 *Sep 13, 1993Feb 7, 1995Taligent, Inc.Object oriented framework system for routing, editing, and synchronizing MIDI multimedia information using graphically represented connection objectUS5390325 *Dec 23, 1992Feb 14, 1995Taligent, Inc.Automated testing systemUS5396626 *Aug 4, 1993Mar 7, 1995Taligent, Inc.Object-oriented locator systemUS5398336 *Jul 16, 1993Mar 14, 1995Consilium, Inc.Object-oriented architecture for factory floor managementUS5664180 *Mar 20, 1995Sep 2, 1997Framework Technologies CorporationDesign tool for complex objects which links object structures of a design object in multiple design domainsUS5745675 *Apr 23, 1996Apr 28, 1998International Business Machines CorporationObject oriented framework mechanism for performing computer system diagnosticsUS5768505 *Dec 19, 1995Jun 16, 1998International Business Machines CorporationObject oriented mail server framework mechanismUS5778378 *Apr 30, 1996Jul 7, 1998International Business Machines CorporationObject oriented information retrieval framework mechanismUS5787425 *Oct 1, 1996Jul 28, 1998International Business Machines CorporationObject-oriented data mining framework mechanism* Cited by examinerNon-Patent CitationsReference1Abstract for EPO Patent No. 619544, S. Danforth, Oct. 12, 1994, "Language-Neutral Object-Oriented Programming".2 *Abstract for EPO Patent No. 619544, S. Danforth, Oct. 12, 1994, Language Neutral Object Oriented Programming .3Abstract for U.S. Patent No. 5, 119, 475, Schoen et al., Jun. 2, 1992, "Object-Oriented Framework for Menu Definition".4 *Abstract for U.S. Patent No. 5, 119, 475, Schoen et al., Jun. 2, 1992, Object Oriented Framework for Menu Definition .5Abstract for U.S. Patent No. 5,369,766, Heninger et al., Nov. 29, 1994, "Object Oriented Application Processing Apparatus".6 *Abstract for U.S. Patent No. 5,369,766, Heninger et al., Nov. 29, 1994, Object Oriented Application Processing Apparatus .7Abstract for U.S. Patent No. 5,388,264 Milne et al., Feb. 7, 1995, "Object-Oriented Framework System for Enabling Multimedia Presentation with Routing and Editing of MIDI Information".8 *Abstract for U.S. Patent No. 5,388,264 Milne et al., Feb. 7, 1995, Object Oriented Framework System for Enabling Multimedia Presentation with Routing and Editing of MIDI Information .9Abstract for WIPO Patent Application No. 94/15281, Anderson et al., Jul. 7, 1994, "Atomic Command Object-Oriented System Software Platform".10 *Abstract for WIPO Patent Application No. 94/15281, Anderson et al., Jul. 7, 1994, Atomic Command Object Oriented System Software Platform .11Abstract for WIPO Patent Application No. 94/15282, Anderson et al., Jul. 7,1994, "Dialog System Object-Oriented System Software Platform".12 *Abstract for WIPO Patent Application No. 94/15282, Anderson et al., Jul. 7,1994, Dialog System Object Oriented System Software Platform .13Abstract for WIPO Patent Application No. 94/19740, Goldsmith et al., Sep. 1, 1994, "Framework Processor of Object-Oriented Application".14 *Abstract for WIPO Patent Application No. 94/19740, Goldsmith et al., Sep. 1, 1994, Framework Processor of Object Oriented Application .15Abstract for WIPO Patent Application No. 94/19740, Goldsmith et al., Sept. 1, 1994, "Framework Processor of Object-Oriented Application".16Abstract for WIPO Patent Application No. 94/19751, Anderson et al., Sep. 1, 1994, "Concurrent Framework Processing Apparatus for Application Users".17 *Abstract for WIPO Patent Application No. 94/19751, Anderson et al., Sep. 1, 1994, Concurrent Framework Processing Apparatus for Application Users .18Abstract for WIPO Patent Application No. 94/19752, Anderson et al., Sep. 1, 1994, "Concurrent Framework Processing Apparatus for Two or More Users".19 *Abstract for WIPO Patent Application No. 94/19752, Anderson et al., Sep. 1, 1994, Concurrent Framework Processing Apparatus for Two or More Users .20Abstract for WIPO Patent Application No. 95/01610, Koko et al., Jan. 12, 1995, "Object Oriented Product Structure Management in Computer-Aided Product Design".21 *Abstract for WIPO Patent Application No. 95/01610, Koko et al., Jan. 12, 1995, Object Oriented Product Structure Management in Computer Aided Product Design .22Abstract for WIPO Patent Application No. 95/02219, Helgeson et al., Jan. 19, 1995, "Distributed Computation Based on Movement, Execution and Insertion of Processes in Network".23 *Abstract for WIPO Patent Application No. 95/02219, Helgeson et al., Jan. 19, 1995, Distributed Computation Based on Movement, Execution and Insertion of Processes in Network .24Abstract for WIPO Patent Application No. WO 94/23364, Heninger et al., Oct. 13, 1994, "Framework Processing Appartus for Application Software".25 *Abstract for WIPO Patent Application No. WO 94/23364, Heninger et al., Oct. 13, 1994, Framework Processing Appartus for Application Software .26Abstract for WIPO Patent Application No. WO 9422081, Sep. 29, 1994, "Hardware-Independent Interface for Interrupt Processing", G. O. Norman et al.27 *Abstract for WIPO Patent Application No. WO 9422081, Sep. 29, 1994, Hardware Independent Interface for Interrupt Processing , G. O. Norman et al.28Abstract for WIPO Patent Application No. WO 95/04966, F.T. Nguyen, Feb. 16, 1995, "Automatic Management of Components in Object-Oriented System".29 *Abstract for WIPO Patent Application No. WO 95/04966, F.T. Nguyen, Feb. 16, 1995, Automatic Management of Components in Object Oriented System .30Abstract for WIPO Patent No. 94/20912, Sep. 15, 1994, "Object-Oriented System for Managing Financial Instruments".31 *Abstract for WIPO Patent No. 94/20912, Sep. 15, 1994, Object Oriented System for Managing Financial Instruments .32Abstract fpr WIPO Patent Application No. 95/04967, Feb. 16, 1995, "Access Method to Data Held in Primary Memory Based Data Base".33 *Abstract fpr WIPO Patent Application No. 95/04967, Feb. 16, 1995, Access Method to Data Held in Primary Memory Based Data Base .34Abstract from EPO Patent Application No. EP 622730, "Encapsulation of Extracted Portions of Documents Into Objects", M.A. Malamud, Nov. 2, 1994.35 *Abstract from EPO Patent Application No. EP 622730, Encapsulation of Extracted Portions of Documents Into Objects , M.A. Malamud, Nov. 2, 1994.36Abstract from U.S. Patent No. 5,371,891, "Object Constructions in Compiler in Object Oriented Programming Language", J. Gray et al., Dec. 6, 1994.37 *Abstract from U.S. Patent No. 5,371,891, Object Constructions in Compiler in Object Oriented Programming Language , J. Gray et al., Dec. 6, 1994.38Abstract from WIPO Patent Application No. WO 94/15286, Goldsmith, et al., Jul. 7, 1994, "Object-Oriented Framework for Object Operating System".39 *Abstract from WIPO Patent Application No. WO 94/15286, Goldsmith, et al., Jul. 7, 1994, Object Oriented Framework for Object Operating System .40Abstract from WIPO Patent Application No. WO 9415285, Jul. 7, 1994, "Object-Oriented Notification Framework System", D.R. Anderson et al.41 *Abstract from WIPO Patent Application No. WO 9415285, Jul. 7, 1994, Object Oriented Notification Framework System , D.R. Anderson et al.42 *Abstract No. 95 091003/12, Flexible Multi Platform Partitioning for Computer Applications in Object Oriented System .43Abstract No. 95-091003/12, "Flexible Multi-Platform Partitioning for Computer Applications in Object Oriented System".44Inspec Abstract No. 4050569, from Di Giovanni et al., 1990, "HOOD Nets".45Inspec Abstract No. 4060084, from Muller et al., 1990, "ODICE: Object-Oriented Hardware Description in CAD Environment".46Inspec Abstract No. 4067033, from Shaw et al., 1990, "Experience with the ET++Application Framework".47Inspec Abstract No. 4077440, from A. Mahler, 1991, "Organizing Tools in a Uniform Environment Framework".48Inspec Abstract No. 4090970, from P. Kougiouris, 1991, "Device Management Framework for an Object-Oriented Operating System".49Inspec Abstract No. 4117514, from Wuwongse et al., 1991, "An Object-Oriented Approach to Model Management".50Inspec Abstract No. 4152687, from M. Wolczko, 1992, "Encapsulation, Delegation and Inheritance in Object-Oriented Languages".51Inspec Abstract No. 4234438, from Madany et al., 1991, "Organizing and Typing Persistent Objects Within an Object-Oriented Framework".52Inspec Abstract No. 4244023, from George et al., 1991, "An Object-Oriented Data Model to Represent Uncertainity in Coupled Artificial Intelligence-Database Systems".53Inspec Abstract No. 4258051, from Rundensteiner et al., 1992, "Set Operations in Object-Based Data Models".54Inspec Abstract No. 4258492, from M. Ball, 1992, "Inside Templates: Implementing C ++Strategies".55Inspec Abstract No. 4270125, from Becker et al., 1991, "Reusable Object-Oriented Specifications for Decision Support Systems".56Inspec Abstract No. 4270361, from Artale et al., 1991, "Introducing Knowledge Representation Techniques in Databased Models".57Inspec Abstract No. 4275693, from Giannotti et al., 1991, "Non-Determinism in Deductive Databases".58Inspec Abstract No. 4275698, from Van den bussche et al., 1991, "Evaluation and Optimization of Complex Object Selections".59Inspec Abstract No. 4275707, from Tsukamoto et al., 1991, "DOT: A Term Representation Using DOT Algebra for Knowledge-Bases".60Inspec Abstract No. 4281362, from Marshall et al., 1992, "Using VDM within an Object-Oriented Framework".61Inspec Abstract No. 4287814, from Natarajan et al., 1992, "Issues in Building Dynamic Real-Time Systems".62Inspec Abstract No. 4297404, from Tanaka et al., 1992, "Two-Level Schemata and Generalized Links for Hypertext Database Models".63Inspec Abstract No. 4298324, from S. Nichol, 1992, "Extending Turbo Vision".64Inspec Abstract No. 4302722, from Eggenschwiler et al., 1992, "ET++SwapsManager: Using Object Technology in the Financial Engineering Domain".65Inspec Abstract No. 4318465, from P. Madany, 1992, "Object-Oriented Framework for File Systems".66Inspec Abstract No. 4331060, from Lau et al., 1992, "An Object-Oriented Class Library for Scalable Parallel Heruistic Search".67Inspec Abstract No. 4341376, from Bertino et al., 1992, "Optimization of Object-Oriented Queries Using Path Indices".68Inspec Abstract No. 4356300, from Bertino et al., 1993, "Path-Index: An Approach to the Efficient Execution of Object-Oriented Queries".69Inspec Abstract No. 4366189, from Holt et al., 1992, "A Framework for Using Formal Methods in Object-Oriented Software Development".70Inspec Abstract No. 4387201, from Chu et al., 1992, "A Pattern Based Approach of Integrating Data and Knowledge to Support Cooperative Query Answering".71Inspec Abstract No. 4391388, from Thomas et al., 1992, "A Generic Object-Oriented Concurrency Mechanism for Extensibility and Reuse of Synchronization Components".72Inspec Abstract No. 4395549, from Hogstrom et al., 1992, "Portability and Data Structure in Scientific Computing-Object-Oriented Design of Utility Routines in Fortran".73Inspec Abstract No. 4400350, from Y. Shoham, 1993, "Agent-Oriented Programming".74Inspec Abstract No. 4408394, from Allen et al., 1992, "GEM: Global Event Management in CAD Frameworks".75Inspec Abstract No. 4411998, from Yi Deng et al., 1992, "Unifying Multi-Paradigms in Software System Design".76Inspec Abstract No. 4417563, from E. Maim, 1992, "Recognizing Objects from Constraints".77Inspec Abstract No. 4417604, from Kraiem et al., 1992, "Mapping of Conceptual Specifications Into Object-Oriented Programs".78Inspec Abstract No. 4425343, from Demurjian et al., 1993, "Programming Versus Databases in Object-Oriented Paradigm".79Inspec Abstract No. 4426852, from Benveniste et al., 1992, "Concurrent Programming Notations in the Object-Oriented Language Arche".80Inspec Abstract No. 4447153, from Klein et al., 1992, "An Object-Oriented Framework for Curves and Surfaces".81Inspec Abstract No. 4459325, from Kesim et al., 1992, "on the Evolution of Objects in a Logic Programming Framework".82Inspec Abstract No. 4512593, from H. Sakai, 1993, "A Method for Contract Design and Delegation in Object Behavior Modeling".83Inspec Abstract No. 4525743, from Hakimzadeh et al., 1993, "Instance Variable Access Locking for Object-Oriented Databases".84Inspec Abstract No. 4528985, from Beneventano et al., 1993, "Taxonomic Reasoning with Cycles in LOGIDATA+".85Inspec Abstract No. 4534330, from Istavrinos et al., 1992, "Experiences with an Object-Oriented Mapper for Coherent Distributed Shared Memory".86Inspec Abstract No. 4534334, from Campbell et al., 1991, "A Technique for Documenting the Framework of an Object-Oriented System".87Inspec Abstract No. 4540729, from Bailes et al., "The Ecology of Class Refinement".88Inspec Abstract No. 4550414, from Parrish et al., 1993, "Automated Flow Graph-Based Testing of Object-Oriented Software Modules".89Inspec Abstract No. 4565630, from Karpovich et al., 1993, "A Paralel Object-Oriented Framework for Stencil Algorithms".90Inspec Abstract No. 4565630, from Karpovich et al., 1993, "A Parallel Object-Oriented Framework for Stencil Algorithms".91 *Inspec Abstract No. 4565630, from Karpovich et al., 1993, A Parallel Object Oriented Framework for Stencil Algorithms .92Inspec Abstract No. 4566447, from J. Rossazza, 1992, "An Object-Centered Fuzzy Representation".93 *Inspec Abstract No. 4566447, from J. Rossazza, 1992, An Object Centered Fuzzy Representation .94Inspec Abstract No. 458839, from L. Fisher, 1992, "Constructing a Class Library for Microsoft Windows".95 *Inspec Abstract No. 458839, from L. Fisher, 1992, Constructing a Class Library for Microsoft Windows .96Inspec Abstract No. 4588834, from G. Olander, 1992, "Chembench: Redesign of a Large Commercial Application Using Object-Oriented Techniques".97Inspec Abstract No. 4588834, from G. Olander, 1992, "Chembench: Redesign of a Large Commerical Application Using Object-Oriented Techniques".98 *Inspec Abstract No. 4588834, from G. Olander, 1992, Chembench: Redesign of a Large Commercial Application Using Object Oriented Techniques .99 *Inspec Abstract No. 4588834, from G. Olander, 1992, Chembench: Redesign of a Large Commerical Application Using Object Oriented Techniques .100Inspec Abstract No. 4588839, from L. Fisher, 1992, "Constructing a Class Library for Microsoft Windows".101 *Inspec Abstract No. 4588839, from L. Fisher, 1992, Constructing a Class Library for Microsoft Windows .102Inspec Abstract No. 4593721, Periyasamy et al., 1993, "A Formal Framework for Design and Verification of Robotic Agents".103 *Inspec Abstract No. 4593721, Periyasamy et al., 1993, A Formal Framework for Design and Verification of Robotic Agents .104Inspec Abstract No. 4596323, from Frank et al., 1993, "An Integrated Environment for Designing Object-Oriented Enterprise Models".105Inspec Abstract No. 4596323, from Frank et al., 1993, "An Integrated Environment for Designing Ojbect-Oriented Enterprise Models".106 *Inspec Abstract No. 4596323, from Frank et al., 1993, An Integrated Environment for Designing Object Oriented Enterprise Models .107 *Inspec Abstract No. 4596323, from Frank et al., 1993, An Integrated Environment for Designing Ojbect Oriented Enterprise Models .108Inspec Abstract No. 4603430, from G. Booch, 1994, "Designing an Application Framework".109Inspec Abstract No. 4603430, from G. Booch, 1994, "Designing and Application Framework".110 *Inspec Abstract No. 4603430, from G. Booch, 1994, Designing an Application Framework .111 *Inspec Abstract No. 4603430, from G. Booch, 1994, Designing and Application Framework .112Inspec Abstract No. 4613481, from Thieme et al., 1993, "Schema Integration in Object-Oriented Databases".113 *Inspec Abstract No. 4613481, from Thieme et al., 1993, Schema Integration in Object Oriented Databases .114Inspec Abstract No. 4618974, from Bowers, 1993, "Some Principles for the Encapsulation of the Behaviour of Aggregate Objects".115 *Inspec Abstract No. 4618974, from Bowers, 1993, Some Principles for the Encapsulation of the Behaviour of Aggregate Objects .116Inspec Abstract No. 461931, from Islan et al., 1993, "Uniform Co-Scheduling Using Object-Oriented Desgin Techniques".117Inspec Abstract No. 461931, from Islan et al., 1993, "Uniform Co-Scheduling Using Object-Oriented Design Techniques".118 *Inspec Abstract No. 461931, from Islan et al., 1993, Uniform Co Scheduling Using Object Oriented Desgin Techniques .119 *Inspec Abstract No. 461931, from Islan et al., 1993, Uniform Co Scheduling Using Object Oriented Design Techniques .120Inspec Abstract No. 4622794, from Campbell et al., 1993, "A Technique for Documenting the Framework of an Object-Oriented System".121 *Inspec Abstract No. 4622794, from Campbell et al., 1993, A Technique for Documenting the Framework of an Object Oriented System .122Inspec Abstract No. 4626386, from Arora et al., 1993, "Building Diverse Environments with PCTE Workbench".123 *Inspec Abstract No. 4626386, from Arora et al., 1993, Building Diverse Environments with PCTE Workbench .124Inspec Abstract No. 4642214, from Marshall et al., 1992, "Using VDM Within an Object-Oriented Framework".125 *Inspec Abstract No. 4642214, from Marshall et al., 1992, Using VDM Within an Object Oriented Framework .126Inspec Abstract No. 4647921, from Uhorchak et al., 1993, "An Object-Oriented Class Library for Creating Engineering Graphs Using PHIGS".127 *Inspec Abstract No. 4647921, from Uhorchak et al., 1993, An Object Oriented Class Library for Creating Engineering Graphs Using PHIGS .128Inspec Abstract No. 4664213, "Maintaining Information about Persistent Replicated Objects in a Distributed System", 1993 IEEE Conference on Distributed Computing Systems.129 *Inspec Abstract No. 4664213, Maintaining Information about Persistent Replicated Objects in a Distributed System , 1993 IEEE Conference on Distributed Computing Systems.130Inspec Abstract No. 89003142, from Tenna et al., 1986, "A System for Generating Language-Oriented Editors".131Inspec Abstract No. B90075006, from Gossain et al., 1989, "Designing a Class Hierarchy for Domain Representation and Reusability".132Inspec Abstract No. B91052096, from Cusack et al., 1990, "Object-Oriented Specifications in LOTOS and Z, or My Cat Really is Object-Oriented!".133Inspec Abstract No. B9310-6210L-099, "Templates, Types and Classes in Open Distributed Processing", 1993.134 *Inspec Abstract No. B9409 6210M 025, from Hellemans et al., 1994, An Object Oriented Approach to Dynamic Service Descriptions .135Inspec Abstract No. B9409-6210M-025, from Hellemans et al., 1994, "An Object-Oriented Approach to Dynamic Service Descriptions".136 *Inspec Abstract No. B9412 6210Q 016, from Oingzhong et al., 1992, An Object Oriented Model for Intelligent Networks .137Inspec Abstract No. B9412-6210Q-016, from Oingzhong et al., 1992, "An Object-Oriented Model for Intelligent Networks".138 *Inspec Abstract No. B9503 8110B 023, from Mautref, et al., 1995, An Object Oriented Framework for the Development of Interactive Decision Support Systems .139Inspec Abstract No. B9503-8110B-023, from Mautref, et al., 1995, "An Object-Oriented Framework for the Development of Interactive Decision Support Systems".140Inspec Abstract No. C81005505, from Mylopoulos et al., 1980, "Some Features of the TAXIS Data Model".141Inspec Abstract No. C84005713, from Meyer et al., 1983, "Towards a Two-Dimensional Programming Environment".142Inspec Abstract No. C86024804, from Greenspan et al., 1986, "A Requirements Modeling Language and Its Logic".143Inspec Abstract No. C86039588, from K. Fukunaga, 1985; "PROMPTER: A Knowledge Based Support Tool for Code Understanding".144Inspec Abstract No. C87007043, from Whitted et al., 1986, "Exploiting Classes in Modeling and Displat Software".145Inspec Abstract No. C88013915, from Woelk et al., 1987, "Multimedia Information Management in an Object-Oriented Database System".146Inspec Abstract No. C8807447, from P. Allen, 1987, "A Framework for Implementing Multisensor Robotic Tasks".147Inspec Abstract No. C89014870, from R. King, 1988, "Semantic and Object-Oriented Database Support for Software Environments".148Inspec Abstract No. C89033226, from Corradi et al., 1988, "PO: An Object Model to Express Parallelism".149Inspec Abstract No. C89039001, from Brophy et al., 1989, "A Framework for Multiple, Concurrent Graphical Representation".150Inspec Abstract No. C89049257, from Madany et al., 1989, "Class Hierarchy for Building Stream-Oriented File Systems".151Inspec Abstract No. C89056727, from Campbell et al., 1989, "Principles of Object-Oriented Operating System Design".152Inspec Abstract No. C89056859, from Hull et al., 1989, "On Accessing Object-Oriented Databases: Expressive Power, Complexity, and Restrictions".153Inspec Abstract No. C89062837, from Pasquier-Boltuck et al., 1988, "Prototyping an Interactive Electronic Book System Using an Object-Oriented Approach".154Inspec Abstract No. C90007733, from Weinand et al., 1989, "Design and Implementation of ET++, A Seamless Object-Oriented Application Framework".155Inspec Abstract No. C90030609, from Forde et al., 1990, "Object-Oriented Finite Element Analysis".156Inspec Abstract No. C90034818, from Q. Chen, 1988, "Extending the Object-Oriented Paradigm for Supporting Complex Objects".157Inspec Abstract No. C90047457, from Yokoyama et al., 1990, "A Constraint-Based and Object-Oriented Knowledge Representation".158Inspec Abstract No. C90052277, from I. Tervonen, 1990, "Object-Oriented Development as a Multiview Software Construction Methodology".159Inspec Abstract No. C90052627, from Schrefl et al., 1988, "A Knowledge-Based Approach to Overcome Structural Differences in Object Oriented Database Integration".160Inspec Abstract No. C91003997, from J. Muys-Vasovic, 1989, "MacApp: An Object-Oriented Application Framework".161Inspec Abstract No. C91004708, from Bertino et al., 1990, "Optimization of Queries Using Nested Indices".162Inspec Abstract No. C91010951, from T. Helton, 1990, "Level5 Object".163Inspec Abstract No. C91024852, from Pierra et al., 1990, "An Object Oriented Approach to Ensure Portability of CAD Standard Parts Libraries".164Inspec Abstract No. C91041980, from Choi et al., 1991, "Graph Interpretation of Methods: A Unifying Famework for Polymorphism in Object-Oriented Programming".165Inspec Abstract No. C91042655, from Q. Li, 1991, "Extending Semantic Object Model: Towards More Unified View of Information Objects".166Inspec Abstract No. C91042802, from T. Yokoyama, 1990, "An Object-Oriented and Constraint-Based Knowledge Representation System for Design Object Modeling".167Inspec Abstract No. C91053151, from E. Cusak, 1991, "Refinement, Conformance and Inheritance".168Inspec Abstract No. C91053475, from Queinnec et al., 1988, "An Open Ended Data Representation Model for EU-LISP".169Inspec Abstract No. C91058815, from Menga et al., 1990, "G++: An Environment for Object Oriented Analysis and Prototyping".170Inspec Abstract No. C91064580, from Gamma et al., 1989, "Integration of a Programming Environment into ET++-A Case Study".171Inspec Abstract No. C91064787, from Madany et al., 1989, "A Class Hierarchy for Building Stream-Oriented File Systems".172Inspec Abstract No. C91072016, from A. Lane, 1991, "/DOS/C++-Application Frameworks".173Inspec Abstract No. C91072574, from Hemery et al., "An Analysis of Communication and Multiprogramming in the Helios Operating System".174Inspec Abstract No. C91072815, from Holtkamp et al., 1990, "DEMOM-A Description Based Media Object Data Model".175Inspec Abstract No. C9402-6150G-002, from Bruegge et al., 1993, "A Framework for Dynamic Program Analyzers".176 *Inspec Abstract No. C9403 6180 027, 1991, An Event Object Recovery Model for Object Oriented User Interfaces from Proceedings of ACMSymposium on User Interface Software & Technology.177Inspec Abstract No. C9403-6180-027, 1991, "An Event-Object Recovery Model for Object-Oriented User Interfaces" from Proceedings of ACMSymposium on User Interface Software & Technology.178 *Inspec Abstract No. C9405 6180G 031, from Woyak et al., 1993, A Motif Like Object Oriented Interface Framework Using PHIGS .179Inspec Abstract No. C9405-6180G-031, from Woyak et al., 1993, "A Motif-Like Object-Oriented Interface Framework Using PHIGS".180 *Inspec Abstract No. C9406 0310F 011, 1993, Cost Benefit Analysis of Object Oriented Technology .181 *Inspec Abstract No. C9406 6110J 007, from J.D. Grimes, 1993, Objects 101 An Implementation View , Proceedings of COMPCON 1994.182 *Inspec Abstract No. C9406 6110J 029, A Comparison of Object Oriented Analysis and Design Methods , Proceedings of C World 1993.183 *Inspec Abstract No. C9406 6115 048, 1993, Constructing Multi View Editing Environments Using MViews .184 *Inspec Abstract No. C9406 6150N 015, from Schmidt et al., 1994, The Service Configurator Framework: An Extensible Architecture for Dynamically Configuring Concurrent, Multi Service Network Daemons .185 *Inspec Abstract No. C9406 7490 012, A Discrete Event Object Oriented Modeling Environment for Sawmill Simulation .186Inspec Abstract No. C9406-0310F-011, 1993, "Cost-Benefit Analysis of Object-Oriented Technology".187Inspec Abstract No. C9406-6110J-007, from J.D. Grimes, 1993, "Objects 101-An Implementation View", Proceedings of COMPCON 1994.188Inspec Abstract No. C9406-6110J-029, "A Comparison of Object-Oriented Analysis and Design Methods", Proceedings of C ++ World 1993.189Inspec Abstract No. C9406-6115-048, 1993, "Constructing Multi-View Editing Environments Using MViews".190Inspec Abstract No. C9406-6150N-015, from Schmidt et al., 1994, "The Service Configurator Framework: An Extensible Architecture for Dynamically Configuring Concurrent, Multi-Service Network Daemons".191Inspec Abstract No. C9406-7490-012, "A Discrete-Event Object-Oriented Modeling Environment for Sawmill Simulation".192 *Inspec Abstract No. C9407 6140D 014, from Satoh et al., 1994, Semantics for a Real Time Object Oriented Programming Language.193 *Inspec Abstract No. C9407 7420D 045, from Desai et al., Controller Structure Definition Via Intelligent Process Control .194Inspec Abstract No. C9407-6140D-014, from Satoh et al., 1994, Semantics for a Real-Time Object-Oriented Programming Language.195Inspec Abstract No. C9407-7420D-045, from Desai et al., "Controller Structure Definition Via Intelligent Process Control".196 *Inspec Abstract No. C9408 6110B 016, from Chen et al., An Experimental Study of Using Resuable Software Design Frameworks to Achieve Software Reuse .197 *Inspec Abstract No. C9408 6110J 011, from Gyu Chung et al., 1993, System Methodologies of Object Oriented Programs .198 *Inspec Abstract No. C9408 7420 021, from Pirklbauer et al., 1994, Object Oriented Process Control Software .199Inspec Abstract No. C9408-6110B-016, from Chen et al., "An Experimental Study of Using Resuable Software Design Frameworks to Achieve Software Reuse".200Inspec Abstract No. C9408-6110J-011, from Gyu-Chung et al., 1993, "System Methodologies of Object-Oriented Programs".201Inspec Abstract No. C9408-7420-021, from Pirklbauer et al., 1994, "Object-Oriented Process Control Software".202 *Inspec Abstract No. C9409 6180 059, from Wang et al., 1993, A Framework for User Customization .203Inspec Abstract No. C9409-6180-059, from Wang et al., 1993, "A Framework for User Customization".204 *Inspec Abstract No. C9410 6180G 015, from Eichelberg et al., 1993, Integrating Interactive 3D Graphics into an Object Oriented Application Framework .205Inspec Abstract No. C9410-6180G-015, from Eichelberg et al., 1993, "Integrating Interactive 3D-Graphics into an Object-Oriented Application Framework".206 *Inspec Abstract No. C9411 6115 035, from Mili et al., 1991, SoftClass: An Object Oriented Tool for Software Reuse .207 *Inspec Abstract No. C9411 6130B 108, from Mili et al., 1992, Building a Graphical Interface for a Resue Oriented CASE Tool .208 *Inspec Abstract No. C9411 6160J 011, from Odberg et al., 1992, A Framework for Managing Schema Versioning in Object Oriented Databases .209 *Inspec Abstract No. C9411 7100 029, from C. Le Pape, 1994, Implementation of Resource Constraints in ILOG Schedule: A Library for the Development of Constraint Based Scheduling Systems .210Inspec Abstract No. C9411-6115-035, from Mili et al., 1991, "SoftClass: An Object-Oriented Tool for Software-Reuse".211Inspec Abstract No. C9411-6130B-108, from Mili et al., 1992, "Building a Graphical Interface for a Resue-Oriented CASE Tool".212Inspec Abstract No. C9411-6160J-011, from Odberg et al., 1992, "A Framework for Managing Schema Versioning in Object-Oriented Databases".213Inspec Abstract No. C9411-7100-029, from C. Le Pape, 1994, "Implementation of Resource Constraints in ILOG Schedule: A Library for the Development of Constraint-Based Scheduling Systems".214 *Inspec Abstract No. C9412 6110B 221, Berghel et al., 1992, An Object Oriented Concurrency Mechanism for Extensibility and Reuse of Synchronization Components .215 *Inspec Abstract No. C9412 6110J 006, from Lau et al., 1993, Using SOM for Tool Integration .216 *Inspec Abstract No. C9412 6110J 014 from Griss et al., 1994, Object Oriented Resue .217 *Inspec Abstract No. C9412 6160J 025 from J. Livari, 1994, Object Oriented Information Systems Analysis: A Comparison of Six Object Oriented Analysis Methods .218 *Inspec Abstract No. C9412 7330 186, from Righter et al., 1994, An Object Oriented Characterization of Spatial Ecosystem Information .219 *Inspec Abstract No. C9412 7810 003, from Jung et al., 1993, Development of an Object Oriented Anthropometric Database for an Ergonomic Man Model .220Inspec Abstract No. C9412-6110B-221, Berghel et al., 1992, "An Object-Oriented Concurrency Mechanism for Extensibility and Reuse of Synchronization Components".221Inspec Abstract No. C9412-6110J-006, from Lau et al., 1993, "Using SOM for Tool Integration".222Inspec Abstract No. C9412-6110J-014 from Griss et al., 1994, "Object-Oriented Resue".223Inspec Abstract No. C9412-6160J-025 from J. Livari, 1994, "Object-Oriented Information Systems Analysis: A Comparison of Six Object-Oriented Analysis Methods".224Inspec Abstract No. C9412-7330-186, from Righter et al., 1994, "An Object-Oriented Characterization of Spatial Ecosystem Information".225Inspec Abstract No. C9412-7810-003, from Jung et al., 1993, "Development of an Object-Oriented Anthropometric Database for an Ergonomic Man Model".226Inspec Abstract No. C94204-6110J-017, "Choices, Frameworks and Refinement", R.H. Campbell et al., 1991.227 *Inspec Abstract No. C9501 6115 039, from Elia et al., 1993, G : An Object Oriented Environment for Developing Distributed Applications .228 *Inspec Abstract No. C9501 6140D 005, S. Vinoski, 1994, Mapping CORBA IDL Into C .229 *Inspec Abstract No. C9501 7160 020, C. Le Pape, 1993, The Cost of Genericity: Experiment With Constraint Based Representations of Time Tables .230 *Inspec Abstract No. C9501 7330 007, Salminen et al., 1994, Modelling Trees Using an Object Oriented Scheme .231Inspec Abstract No. C9501-6115-039, from Elia et al., 1993, "G++: An Object Oriented Environment for Developing Distributed Applications".232Inspec Abstract No. C9501-6140D-005, S. Vinoski, 1994, "Mapping CORBA IDL Into C++".233Inspec Abstract No. C9501-7160-020, C. Le Pape, 1993, "The Cost of Genericity: Experiment With Constraint-Based Representations of Time-Tables".234Inspec Abstract No. C9501-7330-007, Salminen et al., 1994, "Modelling Trees Using an Object-Oriented Scheme".235 *Inspec Abstract No. C9502 6130g 006, Support for Enterprise Modelling in CSCW , P. Hennessy et al., 1994.236 *Inspec Abstract No. C9502 7160 026, from Menga et al., 1995, An Object Oriented Framework for Enterprise Modelling .237 *Inspec Abstract No. C9502 7810C 058, from Lin et al., 1995, Can CAL Software Be More Like Computer Games .238Inspec Abstract No. C9502-6130g-006, "Support for Enterprise Modelling in CSCW", P. Hennessy et al., 1994.239Inspec Abstract No. C9502-7160-026, from Menga et al., 1995, "An Object-Oriented Framework for Enterprise Modelling".240Inspec Abstract No. C9502-7810C-058, from Lin et al., 1995, "Can CAL Software Be More Like Computer Games?".241 *Inspec Abstract No. C9503 6110B 045. from Rosiene et al., 1995, A Data Modeling Framework for Queueing Network Models .242 *Inspec Abstract No. C9503 6140D 045, Satoh et al., 1995, Process Algebra Semantics for a Real Time Object Oriented Programming Language .243Inspec Abstract No. C9503-6110B-045. from Rosiene et al., 1995, "A Data Modeling Framework for Queueing Network Models".244Inspec Abstract No. C9503-6140D-045, Satoh et al., 1995, "Process Algebra Semantics for a Real Time Object Oriented Programming Language".245Inspec Abstract No. C9503-6140D-045, Satoh et al.,1995, "Process Algebra Semantics for a Real Time Object Oriented Programming Language".246 *Inspec Abstract No. C9504 6130B 049, from A. van Dam, 1995, VR as a Forcing Function: Software Implications of a New Paradigm .247 *Inspec Abstract No. C9504 6140D 024, from Sheffler et al., 1995, An Object Oriented Approach to Nested Data Parallelism .248 *Inspec Abstract No. C9504 7460 042, Coleman et al., 1995, An End to End Simulation of A Surveillance System Employing Architecture Independence, Variable Fidelity Components and Software Reuse .249Inspec Abstract No. C9504-6130B-049, from A. van Dam, 1995, "VR as a Forcing Function: Software Implications of a New Paradigm".250Inspec Abstract No. C9504-6140D-024, from Sheffler et al., 1995, "An Object-Oriented Approach to Nested Data Parallelism".251Inspec Abstract No. C9504-7460-042, Coleman et al., 1995, "An End-to-End Simulation of A Surveillance System Employing Architecture Independence, Variable Fidelity Components and Software Reuse".252Inspec Abstract No. C9504-7460-043, Sells et al., 1995, "Implementation of the Architecture for a Time-Domain Dynamical System Simulation in a Very High-Level Pictorial Object-Oriented".253Text of IBM Technical Disclosure Bulletin, Allard et al., Feb. 1990, "Object-Oriented Programming in C--the Linnaeus System", pp. 437-439.254 *Text of IBM Technical Disclosure Bulletin, Allard et al., Feb. 1990, Object Oriented Programming in C the Linnaeus System , pp. 437 439.255Text of IBM Technical Disclosure Bulletin, Baker et al., Jun. 1991, "Distribution List Class", p. 159.256 *Text of IBM Technical Disclosure Bulletin, Baker et al., Jun. 1991, Distribution List Class , p. 159.257Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, "Model View Schema", pp. 321-322.258Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, "Office Container Class", pp. 309-310.259 *Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, Model View Schema , pp. 321 322.260 *Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, Office Container Class , pp. 309 310.261Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jul. 1991, "Icon Pane Class", pp. 118-119.262 *Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jul. 1991, Icon Pane Class , pp. 118 119.263Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jun. 1991, "Object-Oriented Documentation Tool", pp. 50-51.264 *Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jun. 1991, Object Oriented Documentation Tool , pp. 50 51.265Text of IBM Technical Disclosure Bulletin, vol. 36, Coskun, N., Jun. 1993, "Persistent Framework Independent Record/Playback Framework", pp. 261-264.266 *Text of IBM Technical Disclosure Bulletin, vol. 36, Coskun, N., Jun. 1993, Persistent Framework Independent Record/Playback Framework , pp. 261 264.267Text of IBM Technical Disclosure Bulletin, vol. 37, DeBinder et al., Feb. 1994, "Results Folder Framework", pp. 431-432.268 *Text of IBM Technical Disclosure Bulletin, vol. 37, DeBinder et al., Feb. 1994, Results Folder Framework , pp. 431 432.269 *Text of IBM Technical Disclosure Bulletin, vol. 37, No. 11, Nov. 1994, pp. 71 72, Behrs et al., Device Support Framework to Support ISO DPA 10175 and POSIX 1387.4 .270Text of IBM Technical Disclosure Bulletin, vol. 37, No. 11, Nov. 1994, pp. 71-72, Behrs et al., "Device Support Framework to Support ISO DPA 10175 and POSIX 1387.4".271 *Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 19 20, Al Karmi et al., Events Set for Event Tracing in Distributred Object Oriented Systems .272Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 19-20, Al-Karmi et al., "Events Set for Event Tracing in Distributred Object-Oriented Systems".273 *Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 375 378, Acker et al., Automatically Generating Formatted Documentation for Object Oriented Class Libraries .274Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 375-378, Acker et al., "Automatically Generating Formatted Documentation for Object-Oriented Class Libraries".275 *Text of IBM Technical Disclosure Bulletin, vol. 37, No. 6B, Jun. 1994, pp. 553 556, Gest et al., Portable Object Oriented Event Manager .276Text of IBM Technical Disclosure Bulletin, vol. 37, No. 6B, Jun. 1994, pp. 553-556, Gest et al., "Portable Object-Oriented Event Manager".277 *Text of IBM Technical Disclosure Bulletin, vol. 37, No. 7, Jul. 1994, pp. 145 146, Banda et al., Exception Management Algorithm for Multi Threaded Method Invocation .278Text of IBM Technical Disclosure Bulletin, vol. 37, No. 7, Jul. 1994, pp. 145-146, Banda et al., "Exception Management Algorithm for Multi-Threaded Method Invocation".279 *Text of IBM Technical Disclosure Bulletin, vol. 38, No. 1, Jan. 1995, pp. 411 414, J. Knapman, Generating Specific Server Programs in Distributed Object Oriented Customer Information Control System .280Text of IBM Technical Disclosure Bulletin, vol. 38, No. 1, Jan. 1995, pp. 411-414, J. Knapman, "Generating Specific Server Programs in Distributed Object-Oriented Customer Information Control System".* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS5456786 *Mar 22, 1993Oct 10, 1995Plastic Trim, Inc.Trim strip and method for making sameUS6108661 *Jul 14, 1997Aug 22, 2000Microsoft CorporationSystem for instance customizationUS6192368 *Feb 11, 1998Feb 20, 2001International Business Machines CorporationApparatus and method for automatically propagating a change made to at least one of a plurality of objects to at least one data structure containing data relating to the plurality of objectsUS6449659Jul 14, 1997Sep 10, 2002Microsoft CorporationSystem for instance customization with application independent programming of controlsUS6684388Aug 22, 2000Jan 27, 2004International Business Machines CorporationMethod for generating platform independent, language specific computer codeUS6718534Oct 3, 2000Apr 6, 2004Microsoft CorporationSystem for application independent programming of controlsUS6853994Aug 30, 2000Feb 8, 2005International Business Machines CorporationObject oriented based, business class methodology for performing data metric analysisUS6898783Aug 3, 2000May 24, 2005International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS6925632 *Nov 2, 2001Aug 2, 2005Martin ShiuSystem for configuration programmingUS7171455Aug 22, 2000Jan 30, 2007International Business Machines CorporationObject oriented based, business class methodology for generating quasi-static web pages at periodic intervalsUS7386571Dec 21, 2004Jun 10, 2008International Business Machines CorporationObject oriented based, business class methodology for performing data metric analysisUS7418459Aug 7, 2007Aug 26, 2008International Business Machines CorporationObject oriented based, business class methodology for performing data metric analysisUS7483955Oct 10, 2006Jan 27, 2009International Business Machines CorporationObject oriented based, business class methodology for generating quasi-static web pages at periodic intervalsUS7515977 *Mar 30, 2004Apr 7, 2009Fisher-Rosemount Systems, Inc.Integrated configuration system for use in a process plantUS7533366Sep 27, 2004May 12, 2009International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS7539647Aug 25, 2005May 26, 2009Microsoft CorporationUsing power state to enforce software metering stateUS7552166 *Sep 11, 2003Jun 23, 2009Chack Michael AMethod of queuing requests to access a communications networkUS7925719Oct 8, 2008Apr 12, 2011International Business Machines CorporationObject oriented based, business class methodology for generating quasi-static web pages at periodic intervalsUS8141033Jul 24, 2008Mar 20, 2012International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS8166454Jul 24, 2008Apr 24, 2012International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS8181155 *Feb 29, 2008May 15, 2012Microsoft CorporationUnified expression and location frameworkUS8191042Apr 1, 2008May 29, 2012Microsoft CorporationContinuation based declarative definition and compositionUS8499279Aug 6, 2008Jul 30, 2013International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS20020129330 *Nov 2, 2001Sep 12, 2002Martin ShiuSystem for configuration programmingUS20040073670 *Sep 11, 2003Apr 15, 2004Chack Michael A.Method of queuing requests to access a communications networkUS20050060684 *Sep 27, 2004Mar 17, 2005Ibm CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS20060112056 *Sep 27, 2004May 25, 2006Accenture Global Services GmbhProblem solving graphical toolbarUS20060171719 *Feb 3, 2005Aug 3, 2006Schmidt Theodore JOptical transmission system having optimized filter wavelength offsetsUS20070050297 *Aug 25, 2005Mar 1, 2007Microsoft CorporationUsing power state to enforce software metering stateUS20080010312 *Aug 7, 2007Jan 10, 2008Gupta Arun KObject Oriented Based, Business Class Methodology for Performing Data Metric AnalysisUS20090024949 *Jul 24, 2008Jan 22, 2009International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS20090037502 *Aug 6, 2008Feb 5, 2009International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS20090037874 *Jul 24, 2008Feb 5, 2009International Business Machines CorporationObject oriented based methodology for modeling business functionality for enabling implementation in a web based environmentUS20090222794 *Feb 29, 2008Sep 3, 2009Microsoft CorporationUnified expression and location frameworkUS20110185353 *Jul 28, 2011Jack MatthewMitigating Problems Arising From Incompatible SoftwareUS20150074642 *Nov 13, 2014Mar 12, 2015Rockwell Automation Technologies, Inc.Object designWO2004010295A2 *Jul 21, 2003Jan 29, 2004Xaffire IncMethod and apparatus for instrumentation on/offWO2007024822A1 *Aug 23, 2006Mar 1, 2007Microsoft CorpUsing power state to enforce software metering state* Cited by examinerClassifications U.S. Classification1/1, 707/999.104, 707/999.107, 707/999.102International ClassificationG06F9/44Cooperative ClassificationY10S707/99948, Y10S707/99943, Y10S707/99945, G06F8/24European ClassificationG06F8/24Legal EventsDateCodeEventDescriptionDec 6, 1996ASAssignmentOwner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW YFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DUFFIELD, DANA MARK;FOSDICK, ERIC LEONARD;RAPP, WILLIAM CRAIG;REEL/FRAME:008387/0064;SIGNING DATES FROM 19961203 TO 19961204Dec 19, 2002FPAYFee paymentYear of fee payment: 4Jan 10, 2007FPAYFee paymentYear of fee payment: 8Jan 29, 2011FPAYFee paymentYear of fee payment: 12RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services