Software technique to correlate conceptually similar entities

Various technologies and techniques are disclosed for providing a framework with a common set of domain-specific entity identifier types that object models representing conceptually similar entities from a domain can use to correlate to model-specific object instances. A particular model-specific object instance of a particular one of the object models can be retrieved using a common set of domain-specific entity identifier types. An instance of a particular domain-specific entity identifier type can be retrieved from a corresponding one of the model-specific object instances. One or more extensibility mechanisms allow third parties to extend the set of domain-specific entity identifier types.

BACKGROUND

In the world of computer programming, object models are application programming interfaces (APIs) and/or classes that are used to represent specific types of information relating to some problem domain. Multiple object models frequently refer to the same domain of conceptual entity using their own internal representation. Individual object models are typically designed to facilitate some particular style of data access or algorithmic processing. Take, for example, a method object called “Method A” that represents a specific function in some computer program. There might be a performance analysis tool that stores performance data over a period of time for a certain method object called “Method A”. There might be a debugger that also stores debugging information for a method object called “Method A”. There might also be source code written using a software development program that contains the actual implementation for “Method A”. Each program uses its own model-specific object instances for referring to the same conceptual entity called “Method A”.

A problem arises when a process wants to correlate the different objects corresponding to “Method A” in a meaningful fashion. One approach that is sometimes taken is to independently recognize that they are referring to the same conceptual entity by invoking model-dependent application programming interfaces to retrieve the entities using model-dependent data extracted from the other model. For example, suppose that a debugger wants to use performance analysis data for a comparison. The debugger could ask the performance analysis tool for the data. The performance analysis tool would then analyze the performance record from the performance model, extract a method signature, recompose the method signature into a format that is acceptable to the debugger, and pass that information to the debugger. This solution is tedious and also only works if the object models make the data public and provide mechanisms for the entity data to actually be requested. When the data is actually private, or the object model does not expose a way of accessing that data, a client may not be able to correlate these models at all.

SUMMARY

Various technologies and techniques are disclosed for providing a framework with a common set of domain-specific entity identifier types that object models representing conceptually similar entities from a domain can use to correlate to model-specific object instances. A particular model-specific object instance of a particular one of the object models can be retrieved using a common set of domain-specific entity identifier types. An instance of a particular domain-specific entity identifier type can be retrieved from a corresponding one of the model-specific object instances. One or more extensibility mechanisms allow third parties to extend the set of domain-specific entity identifier types.

In one implementation, an application programming interface is provided with an abstract entity identifier class, with domain-specific entity identifier types being required to derive from the abstract entity identifier class, thereby allowing object models representing a conceptually similar entity to use the domain-specific entity identifier types to correlate model-specific object instances.

DETAILED DESCRIPTION

The system may be described in the general context as a framework application that allows conceptually similar entities to be correlated, but the system also serves other purposes in addition to these. In one implementation, one or more of the techniques described herein can be implemented as features within a framework program such as MICROSOFT®.NET Framework, or from any other type of program or service that provides platforms for building applications. In another implementation, one or more of the techniques described herein are implemented as features with other applications that deal with object models each having their own manner of referencing the same conceptual entity.

In one implementation, a framework is provided that has application programming interfaces (APIs) for allowing conceptually similar entities to be correlated. The framework has a common set of domain-specific entity identifier types that object models representing conceptually similar entities from a domain can use to correlate to model-specific object instances. The term “domain-specific entity identifier types” as used herein is meant to include identifiers implemented in an abstract class for the purpose of describing some conceptual entity in a particular domain. The term “model-specific object instance” is meant to include an object instance obtained from some specific model instance. Take, for example, the scenario that was previously described in the background. Suppose there is a performance analysis tool that stores performance data over a period of time for a certain method object called “Method A”. Suppose also that there is a debugger that also stores debugging information for a certain method object called “Method A”. Suppose also that there is source code written using a software development program that contains the actual implementation for “Method A”. Each program uses its own model-specific object instances for referring to the same conceptual entity called “Method A”. If some process wants to see the performance and debugger data for “Method A”, the common set of domain-specific entity identifier types can be used in order to correlate these object instances together in a meaningful fashion.

As shown inFIG. 1, an exemplary computer system to use for implementing one or more parts of the system includes a computing device, such as computing device100. In its most basic configuration, computing device100typically includes at least one processing unit102and memory104. Depending on the exact configuration and type of computing device, memory104may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. This most basic configuration is illustrated inFIG. 1by dashed line106.

Additionally, device100may also have additional features/functionality. For example, device100may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated inFIG. 1by removable storage108and non-removable storage110. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory104, removable storage108and non-removable storage110are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by device100. Any such computer storage media may be part of device100.

Computing device100includes one or more communication connections114that allow computing device100to communicate with other computers/applications115. Device100may also have input device(s)112such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)111such as a display, speakers, printer, etc. may also be included. These devices are well known in the art and need not be discussed at length here. In one implementation, computing device100includes framework application200. Framework application200will be described in further detail inFIG. 2.

Turning now toFIG. 2with continued reference toFIG. 1, a framework application200operating on computing device100is illustrated. Framework application200is one of the application programs that reside on computing device100. However, it will be understood that framework application200can alternatively or additionally be embodied as computer-executable instructions on one or more computers and/or in different variations than shown onFIG. 1. Alternatively or additionally, one or more parts of framework application200can be part of system memory104, on other computers and/or applications115, or other such variations as would occur to one in the computer software art.

Framework application200includes program logic204, which is responsible for carrying out some or all of the techniques described herein. Program logic204includes logic for providing a framework with a common set of domain-specific entity identifier types that a plurality of object models representing a conceptually similar entity can use to correlate model-specific object instances206; logic for providing one or more extensibility mechanisms to allow third parties to extend the set of domain-specific entity identifiers types208; logic for enabling the domain-specific entity identifier types to be extended by allowing one or more model-specific object instances to be provided for one or more domain-specific entity identifier types that a particular one or more of the object models did not originally support210; logic for enabling the domain-specific entity identifier types to be extended by allowing one or more domain-specific entity identifier types to be provided for model-specific object instances that a particular one or more of the object models did not originally support212; and other logic for operating the application220. In one implementation, program logic204is operable to be called programmatically from another program, such as using a single call to a procedure in program logic204.

Turning now toFIGS. 3-8with continued reference toFIGS. 1-2, the stages for implementing one or more implementations of framework application200are described in further detail.FIG. 3is a high level process flow diagram for framework application200. In one form, the process ofFIG. 3is at least partially implemented in the operating logic of computing device100. The process begins at start point240with providing a framework with a common set of domain-specific entity identifier types (unique or non-unique) that object models representing conceptually similar entities from a domain can use to correlate to model-specific object instances (stage242). The framework allows a particular model-specific object instance of a particular one of the object models to be retrieved using a common set of domain-specific entity identifier types (stage244). In one implementation, the correlation using the identifier types is independent of the model-specific object instance types (stage244). An instance of a particular domain-specific entity identifier type can be retrieved from a corresponding one of the model-specific object instances (stage246). The process ends at end point248.

FIG. 4illustrates one implementation of the stages involved in providing a framework with a common set of abstractions for creating object models with domain-specific entity identifier types. In one form, the process ofFIG. 4is at least partially implemented in the operating logic of computing device100. WhileFIG. 4is described as a series of stages, it will be appreciated that no particular order is intended. Further, it will be appreciated that fewer, all, and/or additional features can also be provided by framework application200than those described inFIG. 4and other figures. The process begins at start point270with providing the framework with a common set of abstractions and interfaces for creating the object models with the domain-specific entity identifier types (e.g. with domain-specific entity identifier types being provided through public classes) (stage272). Using the framework, the domain-specific entity identifier types derive from a common abstract base class (stage274). In one implementation, the domain-specific entity identifier types contain only simple data types (stage276). The domain-specific entity identifier types can be serialized and/or de-serialized (stage278), such as for transfer among computers and/or for easy storage on a file system. The process ends at end point280.

FIG. 5illustrates one implementation of the stages involved in providing an application programming interface for allowing correlation among conceptually similar entities. In one form, the process ofFIG. 5is at least partially implemented in the operating logic of computing device100. The process begins at start point290with providing an application programming interface (API) with an abstract entity identifier class (stage292). Domain-specific entity identifier types are required and/or allowed to derive from the abstract entity identifier class (stage294). Object models representing a conceptually similar entity can use the domain-specific entity identifier types to correlate model-specific object instances (stage296). The process ends at end point298.

FIG. 6illustrates one implementation of the stages involved in using the API described inFIG. 5with object models. In one form, the process ofFIG. 6is at least partially implemented in the operating logic of computing device100. The process begins at start point310with allowing the application programming interface to be applied to an object model (stage312). The object model can be either a root object model or a sub object model (stage314). A method is implemented with the object model that retrieves one or more of the domain-specific entity identifier types (stage316). A method is implemented with the object model that retrieves one or more sub object models using one or more of the domain-specific entity identifier types (stage318). The process ends at end point320.

FIG. 7illustrates one implementation of the stages involved in providing the API described inFIG. 5with an object handle interface. In one form, the process ofFIG. 7is at least partially implemented in the operating logic of computing device100. The process begins at start point340with providing the application programming interface (API) with an object handle interface (stage342). The term “handle” as used herein is meant to include a soft reference to a model-specific object instance. A method is implemented with the object handle interface for accessing one or more of the model-specific object instances (stage344). The process ends at end point346.

FIGS. 8-13illustrate exemplary classes and interfaces that can be used for implementing some or all of the techniques discussed inFIG. 1-7for allowing correlation of conceptually similar entities from multiple object models. It will be appreciated that the classes and interfaces' could be implemented using different names and/or features in alternate implementations.FIG. 8is a diagram illustrating a ModelIdentifier abstract class400of one implementation. Example characteristics of entity identifiers include:They are simple immutable value objects containing only simple data typesThey provide “value equality” semantics so that two instances are equal if their values are equalThey contain no model-dependent informationThey can be serialized and de-serializedThey define a data contract so they are not tightly coupled to a particular runtime type

In one implementation, all entity identifier classes derive from this common ModelIdentifier abstract base class. They typically offer additional data that a client can specify at instantiation time. Object models typically access these data through public properties exposed by those subclasses.

FIG. 9is a diagram illustrating an IModel type interface500of one implementation. In one implementation, object models that wish to support entity identifiers implement this common interface. Example characteristics of the IModel interface are:An IModel can be either a root model (which has no parent model) or a sub-model (it is the child of another IModel)It implements a method (e.g. IHandle GetModelHandle) to retrieve those sub-models using entity identifiers (the method returning a model handle to the sub-model).It implements a method (e.g. ModelIdentifier GetModelIdentifier) to obtain one or more entity identifiers of the requested type.

FIG. 10is a diagram illustrating an IHandle type interface600of one implementation. In one implementation, object models are accessible through model handles that implement the IHandle interface. Example characteristics of a model handle are:It implements a de-referencing method (IModelDereference) that returns the actual IModel instance to which it logically refersModel handles are simple immutable value objectsModel handles have “value equality” semanticsModel handles may be serialized and de-serializedModel handles define a data contract so they do not depend on a specific runtime type

An entity identifier is a domain-specific symbolic reference that can be applied to multiple models sharing a set of related entity identifier types, sometimes called an ontology. On the other hand, a model handle is a soft reference to a single model-specific object instance. The model handle abstraction permits tools to refer to entities in other object models in a uniform way. It can also avoid holding any model-specific data objects. When the tool wants to interact with a model object, it obtains it by de-referencing the handle.

FIG. 11is a diagram illustrating an IHandleModelService type interface700of one implementation. Authors of object models cannot always know in advance the complete set of entity identifiers they must support. For example, a client may need to correlate two object models, yet neither object model recognizes the other's entity identifiers. An extensibility mechanism is provided in one implementation to allow third parties to extend the set of entity identifiers that a particular object model recognizes. As part of the extensibility mechanism, the IHandleModelService type interface700is provided. Clients may ask for a model handle or an entity identifier, and the service will consult its list of known extensions to determine whether the request can be honored.

One implementation of IHandleModelService700aggregates all instances of ModelHandleFactory (800onFIG. 12) and ModelIdentifierFactory (900onFIG. 13), and delegates client requests to the appropriate one. Implementations of IModel that do not understand a particular entity identifier are expected to invoke IHandleModelService, thereby allowing third parties to extend them.

FIG. 12is a diagram illustrating a ModelHandleFactory type abstract class800of one implementation. The ModelHandleFactory type800permits third parties to extend the set of entity identifiers supported by a particular object model. Examples of metadata provided by each ModelHandleFactory includes:The type of IModel it can produceThe type of ModelIdentifier it will acceptThe type of IModel it requires for contextA model “tag” that uniquely identifies a particular implementation of the context IModel

The IHandleModelService implementation aggregates all ModelHandleFactory instances. When it receives a request for a model handle, it chooses the appropriate one based on the metadata listed above. It then delegates control to this factory to produce the requested model handle.

FIG. 13is a diagram illustrating a ModelIdentifierFactory type abstract class900of one implementation. The ModelIdentifierFactory type900permits third parties to extend the set of entity identifiers supported by a particular domain model. Examples of metadata provided by each ModelIdentifierFactory include:The type of ModelIdentifier it can produceThe type of IModel for which it can produce this ModelIdentifierThe type of IModel it requires for contextA model “tag” that uniquely identifies a particular implementation of the context IModel

The IHandleModelService implementation aggregates all ModelIdentifierFactory instances. When it receives a request for an entity identifier, it chooses the appropriate one based on the metadata listed above. It then delegates control to this factory to produce the requested entity identifier.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. All equivalents, changes, and modifications that come within the spirit of the implementations as described herein and/or by the following claims are desired to be protected.

For example, a person of ordinary skill in the computer software art will recognize that the client and/or server arrangements, user interface screen content, and/or data layouts as described in the examples discussed herein could be organized differently on one or more computers to include fewer or additional options or features than as portrayed in the examples.