Abstract:
A system for model analysis, the system including means for accessing a model stored on a computer-readable physical medium, the model having a plurality of classes and associations between the classes, and a model analyzer implemented as computer program embodied on a computer-readable physical medium, the model analyzer configured to query each class in the model that has an association with a class of any instance in a set of source instances, thereby identifying a set of target instances that are associated with any of the source instances.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to model analysis in general, and more particularly to providing data lineage information and impact analyses using models. 
       BACKGROUND OF THE INVENTION 
       [0002]    The information technology (IT) infrastructure of large enterprises may include vast numbers, amounts, and types of assets, including data, computer hardware and software, and sources and consumers of data, making their management a complex task. Two useful tools for managing IT assets within an enterprise are impact analysis and data lineage analysis. In impact analysis one or more assets of an enterprise&#39;s information technology infrastructure are analyzed to determine the impact they have on other assets. This is important where, for example, there is a need to modify, suspend, or decommission an asset, such as during routine system maintenance and system upgrades, as well as for disaster recovery planning. In data lineage analysis an analysis is performed of an enterprise&#39;s information technology infrastructure and/or an enterprise&#39;s operational logs in order to determine the path that data take from their initial entry into or generation within an enterprise to a specific destination within the enterprise. 
         [0003]    In recent years enterprises have sought ways to improve the use and management of their IT assets by employing models, such as metadata models, that provide information about their IT assets and their associations. These models are themselves expressed as data that are typically stored in relational databases. Techniques that employ models in support of impact analysis and data lineage analysis are therefore in demand. However, where an enterprise&#39;s many IT assets and associations result in increasingly large models that are stored on multiple distributed databases, and where performing such analyses on such models requires increasing amounts of CPU time and other system resources and involves increasing amounts of network communications overhead, efficient model analysis methods would be advantageous. 
       SUMMARY OF THE INVENTION 
       [0004]    The present invention provides for improved model-based analysis. 
         [0005]    In one aspect of the present invention a system is provided for model analysis, the system including means for accessing a model stored on a computer-readable physical medium, the model having a plurality of classes and associations between the classes, and a model analyzer implemented as computer program embodied on a computer-readable physical medium, the model analyzer configured to query each class in the model that has an association with a class of any instance in a set of source instances, thereby identifying a set of target instances that are associated with any of the source instances. 
         [0006]    In another aspect of the present invention a method is provided for model analysis, the method including accessing a model stored on a computer-readable physical medium, the model having a plurality of classes and associations between the classes, and querying each class in the model that has an association with a class of any instance in a set of source instances, thereby identifying a set of target instances that are associated with any of the source instances. 
         [0007]    In another aspect of the present invention a computer program is provided embodied on a computer-readable medium, the computer program including a first code segment operative to access a model stored on a computer-readable physical medium, the model having a plurality of classes and associations between the classes, and a second code segment operative to query each class in the model that has an association with a class of any instance in a set of source instances, thereby identifying a set of target instances that are associated with any of the source instances. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the appended drawings in which: 
           [0009]      FIG. 1  is a simplified conceptual illustration of system for model analysis, constructed and operative in accordance with an embodiment of the present invention; 
           [0010]      FIG. 2  is a simplified flowchart illustration of an exemplary method of operation of the model analyzer of  FIG. 1 , operative in accordance with an embodiment of the present invention; and 
           [0011]      FIG. 3  is a simplified graphical illustration of a set of paths generated from the results of exemplary queries applied to model  100  of  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0012]    Reference is now made to  FIG. 1  which is a simplified conceptual illustration of system for model analysis, constructed and operative in accordance with an embodiment of the present invention. In the system of  FIG. 1  an example of a model, generally designated  100  and bounded by dashed lines, is shown. Model  100  may be constructed using any known modeling technology, such as the Unified Modeling Language (UML), that supports classes representing data or metadata, such as of an enterprise IT infrastructure or other system, and the associations between the classes. In the example shown, model  100  includes a computer class  102  which provides metadata about one or more computers, a database class  104  which provides metadata about one or more databases, an application class  106  which provides metadata about one or more applications, and a user class  108  which provides metadata about one or more users. Typically, each class in model  100  collectively represents one or more instances of the class, such as computer  102  representing one or more actual computers. Model  100  also represents the associations between its classes, with each relationship between two classes shown as a solid arrow with an accompanying label. Thus, in the example shown, the relationship between computer  102  and database  104  indicates that computer  102  hosts database  104 . Two relationships are shown between application  106  and database  104 , one indicating that application  106  reads database  104  and one indicating that application  106  writes to database  104 . The relationship between user  108  and application  106  indicates that user  108  uses application  106 . 
         [0013]    Model  100  is typically stored in a model storage  110 , which may be computer memory, magnetic storage, or any other suitable information storage medium. Model  100  may be stored in storage  110  is any suitable format, such as in a relational database (RDB) or object-oriented database (OODB). Model  100  as stored in storage  110  is preferably accessible to one or more computers  112 , such as for impact analysis or data lineage analysis as may be performed by a model analyzer  114  whose operation may be controlled by computer  112 . 
         [0014]    Reference is now made to  FIG. 2 , which is a simplified flowchart illustration of an exemplary method of operation of the model analyzer of  FIG. 1 , operative in accordance with an embodiment of the present invention. In the method of  FIG. 2  a model is selected for analysis, such as for impact analysis or data lineage analysis. The selected model may be of an entire system or may be selected to only include those classes and their associations that are of interest in the context of the analysis being performed. Thus, in the example shown in  FIG. 1 , the classes and associations shown in model  100  may be selected to support an impact analysis that, for example, determines the impact that taking a particular computer offline would have on databases that are hosted by the computer, the applications that read from or write to the database, and users of such applications. An instance of a class is also selected as the starting point of the analysis, such as an instance of computer  102  identified as “Bob”. The selected instance populates the set “source instances” for a query in which each class in the selected model that has an association with a class of any instance in “source instances” is queried to identify the set “target instances” that is populated by instances in the queried classes that are associated with instances in “source instances”. This is preferably performed using a single query per association, with the results of the query being one or more pairs in the form (SourceInstance:Class, TargetInstance:Class). Thus, for example, database  104  is queried for each database instance that is hosted by “Bob”, and the results appear as (Bob:Computer, Customers:Database), (Bob:Computer, Orders:Database), etc. 
         [0015]    It will be appreciated that each pair resulting from the query represents a path segment of one or more unique paths from the root source instance of the analysis to a target instance of a pair. Representations of any of the paths may be created using any suitable format, such as the graph described hereinbelow with reference to  FIG. 3 . The next path segment of each path is determined by designating “target instances” as “source instances” for a next query. As before, a query is performed in which each class in the selected model that has an association with a class of any instance in “source instances” is queried to identify the next “target instances” set that is populated by instances in the queried classes that are associated with instances in “source instances”. This is likewise preferably performed using a single query per association, with the results again being expressed as (SourceInstance:Class, TargetInstance:Class) pairs. As before, each pair resulting from the query represents a path segment of one or more unique paths from the root source instance of the analysis to a target instance of a pair resulting from a query, with a target instance in one query becoming a source instance in the next query, and so on, thereby linking path segments from one set of query results to the next. To avoid path loops, a path segment represented by a pair resulting from a query is preferably only linked to an existing path where the target instance of the query does not already exist along the path. 
         [0016]    This process of designating “target instances” in one query as “source instances” in the next is preferably repeated until no new path segments are found. 
         [0017]    The method of  FIG. 2  may be alternatively expressed in pseudo code for use with a UML model as follows: 
         [0018]    Given a metadata UML model and an instance (object) of a class:
       create an empty map “PendingPaths”: reference-&gt;List of Path, where a reference is an association between two classes and is in a list of references which a Path needs to query in order to arrive at the next steps.   create a Path that contains just the start object   for each reference of the start object&#39;s class that participates in the analysis type:
           add Path to the list of Paths at this reference, in the PendingPaths map   
           while the PendingPaths map is not empty:
           use the reference with the most Paths in the PendingPaths map   fill a new list “SourceIDs” with the IDs of the respectively last object in each Path for the used reference   submit a query with the SourceIDs list and the used reference, obtain a list of pairs: [SourceID, TargetObject]   remove the current reference from the PendingPaths map   for each Path of the used reference:
               for each pair obtained from the query:
                   if the last object of Path has the ID “SourceID” of the current pair and it does not already contain TargetObject:    create a new Path as a continuation of current Path, by adding used reference and the TargetObject of the current pair    register the new Path with the map PendingPaths   
                   
               
           return the result paths.       
 
         [0032]    The pseudo code above assumes that partial paths may be included in the result set, although an alternative implementation might eliminate partial paths from the results. 
         [0033]    The query for returning pairs [SourceID, TargetObject] may be expressed as follows: 
         [0034]    Input parameters: reference, list of SourceIDs, SourceClass. 
         [0035]    The following pseudocode query may be used for returning pairs [SourceID, TargetObject], assuming an ORM (Object/Relational Mapping) layer:
       select source.ID, target   from source in SourceClass inner join target in source-&gt;reference   where source.ID in [list of SourceIDs]       
 
         [0039]    Where an ORM layer does not exist, the pseudocode may be converted into other query language, such as SQL, provided the reference corresponds to an explicit or implicit Foreign Key. 
         [0040]    Reference is now made to  FIG. 3 , which is a simplified graphical illustration of a set of paths generated from the results of exemplary queries applied to model  100  of  FIG. 1 . In the example shown, instances of database  100  associated with the source instance Bob:Computer via the “hosts” association are found as a result of a first query, resulting in the pairs 
         [0041]    (Bob:Computer, Customers:Database) 
         [0042]    (Bob:Computer, Orders:Database) 
         [0043]    (Bob:Computer, Insurance:Database). 
         [0044]    All instances of application  106  having a “read by” association with any of the instances found as a result of the first query are then found as the result of a second query, resulting in the pairs 
         [0045]    (Customers:Database, CustReporting:Application) 
         [0046]    (Customers:Database, CustSupport:Application) 
         [0047]    (Customers:Database, LogisticsWizard:Application) 
         [0048]    (Orders:Database, BalanceAnalyzer:Application) 
         [0049]    (Orders:Database, Support:Application) 
         [0050]    (Orders:Database, LogisticsWizard:Application) 
         [0051]    (Insurance:Database, RiskAnalyzer:Application) 
         [0052]    (Insurance:Database, Spending:Application). 
         [0053]    Finally, all instances of user  108  having a “uses” association with any of the instances found as a result of the second query are then found as the result of a third query, resulting in the pairs 
         [0054]    (CustReporting:Application, John:User) 
         [0055]    (CustSupport:Application, Jim:User) 
         [0056]    (LogisticsWizard:Application, John:User) 
         [0057]    (BalanceAnalyzer:Application, Terry:User) 
         [0058]    (Support:Application, Jill:User) 
         [0059]    (LogisticsWizard:Application, Brian:User) 
         [0060]    (RiskAnalyzer:Application, Kim:User) 
         [0061]    (Spending:Application, Lori:User). 
         [0062]    It may thus be seen that all paths within model  100  may be identified using just three queries. By contrast, a naïve, prior art approach might apply one query to the root source instance Bob:Computer, one query per database instance found, and one query per application found, resulting in 1+3+8=12 total queries for this example. 
         [0063]    For lack of room,  FIG. 3  does not address the association “writes to”. However, doing so using the methods of the present invention would result in applying only one more query, for a total of four queries, as opposed to a naïve, prior art approach applying additional queries per database instance found and per additional application instance found. 
         [0064]    It is appreciated that the present invention may be applied to any framework of modeled data, and not just to metadata models. For example, the present invention may be applied to an analysis for an on-line music store where, given a customer order for a music album, a list may be produced of all albums by musicians that ever played with any of the musicians on the ordered album. The list may then be used as part of a promotion offering discounts on the albums found during the analysis. 
         [0065]    It is appreciated that one or more of the steps of any of the methods described herein may be omitted or carried out in a different order than that shown, without departing from the true spirit and scope of the invention. 
         [0066]    While the methods and apparatus disclosed herein may or may not have been described with reference to specific computer hardware or software, it is appreciated that the methods and apparatus described herein may be readily implemented in computer hardware or software using conventional techniques. 
         [0067]    While the present invention has been described with reference to one or more specific embodiments, the description is intended to be illustrative of the invention as a whole and is not to be construed as limiting the invention to the embodiments shown. It is appreciated that various modifications may occur to those skilled in the art that, while not specifically shown herein, are nevertheless within the true spirit and scope of the invention.