Software component recommendation based on multiple trace runs

Abstract

Recommendations may be generated while calculating performance metrics from multiple uses of a software component. A tracing service may collect trace data from multiple uses of a software component, where each use may be done on different conditions. The performance metric analysis may identify various factors that may affect the performance of a software component, then present those factors to a user in different delivery mechanisms. In one such mechanism, a recommended set of hardware and software configurations may be generated as part of an operational analysis of a software component.

Description

BACKGROUND

Many computer programming languages have a vast trove of reusable software components, many of which may be open source. These components can range in quality from very poor to excellent, with an equal range of performance characteristics. In many languages, there may be hundreds of thousands or even millions of different components. This poses a difficult issue for a developer: how does one select a component from a vast library?

SUMMARY

Recommendations may be generated while calculating performance metrics from multiple uses of a software component. A tracing service may collect trace data from multiple uses of a software component, where each use may be done on different conditions. The performance metric analysis may identify various factors that may affect the performance of a software component, then present those factors to a user in different delivery mechanisms. In one such mechanism, a recommended set of hardware and software configurations may be generated as part of an operational analysis of a software component.

A recommendation system may identify compatible and incompatible software components, as well as other recommendations, by analyzing a graph of module usage across multiple applications that may use various modules. The graph may identify a module relationship that may be classified as a ‘hard’ relationship defined by being called or incorporated in another module, as well as ‘soft’ relationships that may be identified by being incorporated into an application with another module. The graph may further identify potentially mutually exclusive modules that may be identified when a module is removed and replaced with a second module. The graph may be used to recommend related modules or sets of modules for a give use case, among other uses.

A usage recommendation system may suggest hardware and software configurations as well as other compatible or useful modules based on information provided by a user. While architecting a software application or browsing modules, a user may be presented with modules that may be compatible in terms of their performance on similar hardware platforms or under similar loads, as well as by their compatibility based on relationships in a graph of module relationships that may be gathered from analyzing many different uses of various modules.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings,

FIG. 1 is a diagram illustration of an embodiment showing a system for software component recommendations.

FIG. 2 is a diagram illustration of an embodiment showing a network environment with devices that may generate component recommendations.

FIG. 3 is a diagram illustration of an embodiment showing an example component graph with relationships.

FIG. 4 is a diagram illustration of an embodiment showing recommendations with both relationships and performance data.

FIG. 5 is a flowchart illustration of an embodiment showing a method for parametric analysis of trace data.

FIG. 6 is a diagram illustration of an embodiment showing a data sources for constructing a component graph.

FIG. 7 is a flowchart illustration of an embodiment showing a method for building a component graph from an application repository.

FIG. 8 is a flowchart illustration of an embodiment showing a method for building a component graph from component repository.

FIG. 9 is a flowchart illustration of an embodiment showing a method for building a component graph from tracer data.

FIG. 10 is a flowchart illustration of an embodiment showing a method for identifying mutually exclusive relationships.

FIG. 11 is a flowchart illustration of an embodiment showing a method for generating suggestions.

FIG. 12 is a flowchart illustration of an embodiment showing a method for analyzing existing application prior to suggestion analysis.

DETAILED DESCRIPTION

Module Recommendation System Based on Multiple Trace Runs

A module recommendation system may analyze trace runs from multiple uses of a software component. The analysis may identify factors under which the software component performs well or poorly, and these factors may be used in a recommendation system for software components. The factors may include hardware and software configurations, input parameters, general usage parameters, and other factors.

The factors may be generated by comparing different trace datasets to each other and determining the dominant factors that help define the differences between the trace datasets. The dominant factors may help identify the conditions that may be favorable or unfavorable for the operation of various software components. These conditions may be used in several different manners to recommend software components and conditions for executing software components.

The trace datasets may be any type of data that may be collected while an application executes. In many cases, the trace datasets may be time series sequences of trace data that may include performance and operational information about the application. Such sequences may represent how an application and its various components may perform during execution and under load. In many cases, the trace datasets may include information about the load experienced by the application, and in some cases, load or other information may be inferred from analysis of the trace data or other data.

The factors contributing to a software component's favorable or unfavorable operation may be presented to a user as part of a software component statistics user interface. A software component statistics listing may identify which factors are dominant in the fully utilizing the software component, as well as the factors to avoid when deploying the software component. Such information may be helpful for a developer who may be searching for a software component to perform a certain function.

The factors may be implemented as a predictive model for a component's behavior. Such a predictive model may include the dominant factors that may affect a performance or other metric for the component. In a simple example, a predictive model may estimate a component's response time for handling a request given a set of hardware, software, and usage parameters that the component may experience.

Relationship Graph for Software Component Recommendations

A relationship graph for software components may identify different types of relationships between reusable software components. A ‘hard’ relationship may exist where one component calls or includes a second component, while a ‘soft’ relationship may exist where a developer uses two components in the same application. In some cases, a mutually exclusive relationship may be identified when one component is replaced by another in new revisions of an application.

The relationship graph may be created by many different data sources. In some cases, analyses may be performed from data in a repository containing many different applications or components. By analyzing applications, relationships between commonly used components may be identified. In some cases, an analysis of different versions of applications may identify situations where one component may be removed and another one added, thereby indicating a possible mutually exclusive relationship.

The relationship graph may be gathered in part from analyzing tracer data from multiple applications. The tracer data may include performance and operational data for components used within an application, and both ‘hard’ and ‘soft’ relationships may be identified. In some cases, a relationship graph may be generated from multiple sources, include data from multiple repositories as well as tracer data gathered by tracing multiple applications.

The relationships between modules may be used in many different manners. In one example, a component statistics display may include links to other components for which various relationships are known.

Component Usage Recommendation System with Relationship and Performance Matching

A component usage recommendation system may use both performance matching and component relationships to recommend various components or identify components for replacement. For various components, a set of influencing factors may be identified that increase or decrease a component's effectiveness when executed. Further, relationships between components may be identified through a relationship graph. The influencing factors and relationships may be used in several different scenarios to evaluate components and assist users.

In one use scenarios, an analysis may be performed of an application in its intended execution environment and anticipated execution conditions. The analysis may result in a suitability rating or other metric in some cases. Some systems may identify certain components that may be unsuitable for a specific execution environment or conditions, and may further recommend different components for the application.

In another use scenario, a user may define a set of deployment conditions, including hardware, software, loads, and other parameters. From the given conditions, components may be searched, sorted, ranked, or otherwise recommended that may match the intended deployment conditions.

Throughout this specification and claims, the term “component” is used to define a group of reusable code that may be incorporated into an application. A component may be known as a ‘module’, ‘library’, ‘subroutine’, or some other notion. For the purposes of this specification and claims, these terms are considered synonymous.

The “component” may be code that is arranged in a way that multiple applications may access the code, even though the applications may have no connection with each other. In general, a “component” may be code that is configured to be reused. In some cases, a component may be reused within the scope of a large application, while in other cases, the component may be shared to other application developers who may use the component in disparate and unconnected applications.

Many programming languages and paradigms have a notion of a “component” or library, where the component may have a defined interface through which an application may invoke and use the component. Some paradigms may allow a programmer to incorporate a component in a static manner, such that the component code does not further change after the application is written and deployed. Some paradigms may allow for dynamic libraries, which may be loaded and invoked at runtime or even after execution has begun. The dynamic libraries may be updated and changed after the application may have been distributed, yet the manner of invoking the libraries or components may remain the same.

Components may be distributed in source code, intermediate code, executable code, or in some other form. In some cases, components may be services that may be invoked through an application programming interface.

Throughout this specification and claims, the term “component” may be applied to a single reusable function. Such a function may be distributed as part of a library, module, or other set of code, and may reflect the smallest element of reusable code that may be distributed. A single “component” as referenced in this specification and claims may be an individual application programming interface call or callable subroutine or function, as well as a module, library, or other aggregation of multiple callable functions, application programming interface calls, or other smaller elements.

Throughout this specification and claims, the terms “profiler”, “tracer”, and “instrumentation” are used interchangeably. These terms refer to any mechanism that may collect data when an application is executed. In a classic definition, “instrumentation” may refer to stubs, hooks, or other data collection mechanisms that may be inserted into executable code and thereby change the executable code, whereas “profiler” or “tracer” may classically refer to data collection mechanisms that may not change the executable code. The use of any of these terms and their derivatives may implicate or imply the other. For example, data collection using a “tracer” may be performed using non-contact data collection in the classic sense of a “tracer” as well as data collection using the classic definition of “instrumentation” where the executable code may be changed. Similarly, data collected through “instrumentation” may include data collection using non-contact data collection mechanisms.

Further, data collected through “profiling”, “tracing”, and “instrumentation” may include any type of data that may be collected, including performance related data such as processing times, throughput, performance counters, and the like. The collected data may include function names, parameters passed, memory object names and contents, messages passed, message contents, registry settings, register contents, error flags, interrupts, or any other parameter or other collectable data regarding an application being traced. The collected data may also include cache misses, garbage collection operations, memory allocation calls, page misses, and other parameters.

Throughout this specification and claims, the term “execution environment” may be used to refer to any type of supporting software used to execute an application. An example of an execution environment is an operating system. In some illustrations, an “execution environment” may be shown separately from an operating system. This may be to illustrate a virtual machine, such as a process virtual machine, that provides various support functions for an application. In other embodiments, a virtual machine may be a system virtual machine that may include its own internal operating system and may simulate an entire computer system. Throughout this specification and claims, the term “execution environment” includes operating systems and other systems that may or may not have readily identifiable “virtual machines” or other supporting software.

Throughout this specification and claims, the term “application” is used to refer to any combination of software and hardware products that may perform a desired function. In some cases, an application may be a single software program that operates with a hardware platform. Some applications may use multiple software components, each of which may be written in a different language or may execute within different hardware or software execution environments. In some cases, such applications may be dispersed across multiple devices and may use software and hardware components that may be connected by a network or other communications system.

Throughout this specification, like reference numbers signify the same elements throughout the description of the figures.

In the specification and claims, references to “a processor” include multiple processors. In some cases, a process that may be performed by “a processor” may be actually performed by multiple processors on the same device or on different devices. For the purposes of this specification and claims, any reference to “a processor” shall include multiple processors, which may be on the same device or different devices, unless expressly specified otherwise.

When elements are referred to as being “connected” or “coupled,” the elements can be directly connected or coupled together or one or more intervening elements may also be present. In contrast, when elements are referred to as being “directly connected” or “directly coupled,” there are no intervening elements present.

The subject matter may be embodied as devices, systems, methods, and/or computer program products. Accordingly, some or all of the subject matter may be embodied in hardware and/or in software (including firmware, resident software, micro-code, state machines, gate arrays, etc.) Furthermore, the subject matter may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

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. 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 an instruction execution system. Note that the computer-usable or computer-readable medium could be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, of otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

When the subject matter is embodied in the general context of computer-executable instructions, the embodiment may comprise program modules, executed by one or more systems, computers, or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

FIG. 1 is an illustration of an embodiment 100 showing a system for providing recommendations for software components. The recommendations may use performance data and/or a component relationship graph to identify and suggest different components that may meet an anticipated usage and architecture for an application.

The recommendation system may use data that may be collected from multiple instances of a software component. The software component may be a module, library, subroutine, or other component that may be used in many instances of the same application or in many different applications. When data from multiple instances are analyzed, those factors that cause the component to behave in certain ways may be identified. The causal factors may be very useful to developers when selecting components that may operate optimally in the anticipated deployment conditions.

In the example of embodiment 100, a software component may be called within three different applications and executed under three different conditions. Different hardware components may be used, as well as different software platforms. The software platforms may include operating systems, execution environments, drivers, other applications, or any other software variable.

Tracer data may be collected when executing the application under the various conditions. A comparative analysis of the different tracer datasets may reveal which environmental and deployment factors are the dominant factors in affecting performance or other desired metrics. In a simple example, such an analysis may reveal that a certain component may operate very effectively when deployed on a single processor, but performance suffers when deployed on many processors. In another example, a component may be determined to operate optimally under certain types of loads but not under other loads.

A graph of relationships between components may be generated from tracer data as well as other sources. The graph may identify components that have express, implied, mutually exclusive, and other types of relationships.

An express relationship may be identified when one component calls another component. In such a situation, the first component includes the second component. While the second component may be used separately from the first, the first cannot be used without the second.

An implied relationship may be identified when two components may be used in the same application but without calling each other. Such a situation may occur when an application developer selects both components and uses both in the same application. An implied relationship may indicate that two components are complementary to each other. When making recommendations to a developer, an implied relationship may help identify components that the developer may be likely to consider when building an application.

A mutually exclusive relationship may indicate that one component may replace another. Such components may rarely be used in the same application, and may be identified when an application developer removes one component and replaces the component with another component. Such a situation may be observed by analyzing different versions of an application, tracking when a component is removed and when another component is added. While such an analysis may be not be conclusive that a mutually exclusive relationship exists, such an analysis may be one indicator that such a relationship may be present.

A mutually exclusive relationship between components may be useful to recommend components that may be candidates to replace a current set of components in an application. A recommendation system may use a mutually exclusive relationship to suggest changes to an application. When coupled with performance data analyses, such a recommendation may have performance or other data to support such a change.

The devices 102, 104, and 106 illustrate three different deployments of a software component. The devices may operate on three different hardware platforms 108, 110, and 112 and may have three different software platforms 114, 116, and 118, respectively. The hardware platforms may have different processor speed, number of processors, memory, storage, network interface, peripherals, or other parameters. Similarly, the software platforms may have different operating systems, execution environments, drivers, applications, or other software variations.

The applications 120, 122, and 124 may be different applications in some cases. The applications may be different versions of the same application, or completely different applications that may have different architectures, input streams, and different functions.

The components 126, 128, and 130 may be the component of interest in the example of embodiment 100, meaning that the components 126, 128, and 130 may be analyzed to determine the differentiating factors that affect the performance or other output of the component.

The different applications may use the components 126, 128, and 130 in different manners. Some of the applications may exercise some functions of the component while other applications may exercise other functions. Each of the various applications may have different input streams that may be processed by the components, and may exercise the components under different loads.

Additional components 132, 134, and 136 may be present in the applications 120, 122, and 126, respectively. The additional components may be selected by a developer to perform additional functions within the various applications, and the presence of these additional components may be used to establish relationships between various components.

Each of the components 126, 128, and 130 may have a tracer 138, 140, and 142, respectively, that may gather performance and other data, then transmit tracer data to an intake engine 144. In the example of embodiment 100, the tracers 138, 140, and 142 are shown as connecting to the components 126, 128, and 130, respectively. Such an illustration may show that the tracer may monitor only the component to which it is attached. Other embodiments may have a tracer that may gather trace data for an entire application or for multiple components within an application.

The intake engine 144 may receive tracer data from various devices. The tracer data may be stored in a tracer database 146, which may store tracer data from many different applications and software components. An analysis engine 148 may process the trace datasets to determine which of the many factors are dominant to affect the performance or other metric for a given component or application.

The trace data received by the intake engine 144 may also be processed by a graph engine 152 to create a component relationship graph 154. The component relationship graph 154 may contain express and implied relationships between various components. Such relationships may be generated from trace data as well as from other sources, such as various repositories.

A query engine 150 may receive requests containing input parameters 156 and return results 158. In one example of a query, a request may contain input parameters 156 that may define an anticipated execution scenario for an application, including usage and architecture information. These parameters may be used by the query engine 150 to generate a list of software components with performance data as options for a developer to consider.

FIG. 2 is a diagram of an embodiment 200 showing components that may collect data when an application executes and analyzes the data to identify recommendations or other uses. The example of embodiment 200 may illustrate one architecture where tracer data may be collected from multiple devices, then analyzed in a tracer database. A component graph may be generated from relationships identified from the tracer data or other sources.

The diagram of FIG. 2 illustrates functional components of a system. In some cases, the component may be a hardware component, a software component, or a combination of hardware and software. Some of the components may be application level software, while other components may be execution environment level components. In some cases, the connection of one component to another may be a close connection where two or more components are operating on a single hardware platform. In other cases, the connections may be made over network connections spanning long distances. Each embodiment may use different hardware, software, and interconnection architectures to achieve the functions described.

Embodiment 200 illustrates a device 202 that may have a hardware platform 204 and various software components. The device 202 as illustrated represents a conventional computing device, although other embodiments may have different configurations, architectures, or components.

In many embodiments, the device 202 may be a server computer. In some embodiments, the device 202 may still also be a desktop computer, laptop computer, netbook computer, tablet or slate computer, wireless handset, cellular telephone, game console or any other type of computing device. In some embodiments, the device 202 may be implemented on a cluster of computing devices, which may be a group of physical or virtual machines.

The hardware platform 204 may include a processor 208, random access memory 210, and nonvolatile storage 212. The hardware platform 204 may also include a user interface 214 and network interface 216.

The random access memory 210 may be storage that contains data objects and executable code that can be quickly accessed by the processors 208. In many embodiments, the random access memory 210 may have a high-speed bus connecting the memory 210 to the processors 208.

The nonvolatile storage 212 may be storage that persists after the device 202 is shut down. The nonvolatile storage 212 may be any type of storage device, including hard disk, solid state memory devices, magnetic tape, optical storage, or other type of storage. The nonvolatile storage 212 may be read only or read/write capable. In some embodiments, the nonvolatile storage 212 may be cloud based, network storage, or other storage that may be accessed over a network connection.

The user interface 214 may be any type of hardware capable of displaying output and receiving input from a user. In many cases, the output display may be a graphical display monitor, although output devices may include lights and other visual output, audio output, kinetic actuator output, as well as other output devices. Conventional input devices may include keyboards and pointing devices such as a mouse, stylus, trackball, or other pointing device. Other input devices may include various sensors, including biometric input devices, audio and video input devices, and other sensors.

The network interface 216 may be any type of connection to another computer. In many embodiments, the network interface 216 may be a wired Ethernet connection. Other embodiments may include wired or wireless connections over various communication protocols.

The software components 206 may include an operating system 218 on which various software components and services may operate. An intake engine 220 may receive tracer data from tracers on other devices and may store the tracer data into a tracer database 222. An analysis engine 224 may identify various differentiating factors that may affect the performance of the software components that were traced.

A graph engine 226 may identify relationships between software components and build a component graph 228. The graph engine 226 may use trace data, as well as data from other sources, including component repositories, application repositories, and other sources to identify relationships between the components.

A query engine 230 may respond to requests that may use either or both of the tracer database 222 and the component graph 228 to generate results to a query.

A network 232 may connect the various devices that may interact in embodiment 200.

Deployment systems 234 may execute applications and gather tracer data while the applications execute. In many cases, the deployment systems 234 may be production systems on which an application may execute. The deployment systems 234 may operate on various hardware platforms 236, which may be similar to those described for the hardware platform 204.

An operating system 238 or execution environment 240 may execute an application 242. The application 242 may contain various software components 244, and various other applications 246 may also execute on the deployment systems 234. A tracer 248 may operate within the execution environment 240. In some cases, a tracer 250 may execute within the operating system 238.

A development system 252 may illustrate a device on which a developer may create and edit an application's source code 258. The development system 252 may operate on a hardware platform 254, which may be similar to those described for the hardware platform 204.

An integrated development environment 256 may be an application or suite of applications that includes various tools used by a developer, such as an editor 260 and a compiler 262.

An analyzer 264 may analyze the application's source code 258 to generate a query for the query engine 230. The query may define characteristics of an application under development, and the query engine 230 may return information that may be displayed in a recommendation window 266. Such information may include performance data for components in the source code 258, as well as alternate components that may be considered for the application under development.

A repository system 268 may be a system that contains repositories 272 for source code 274. The repositories 272 may contain application code, component code, or other software. The repository system 268 may execute on a hardware platform 254, which may be similar to those described for the hardware platform 204.

The repositories may be analyzed by a graph engine 226 to build the component graph 228. The repositories may indicate implied relationships where two components may frequently be used together, express relationships where one component calls another, and mutually exclusive relationships where components may be exchanged for each other.

A client device 276 may be one mechanism for displaying query results from the query engine 230. The client device 276 may have a hardware platform 278, which may be similar to those described for hardware platform 204. A browser 280 may execute on the client device 276 and display a user interface 282. The user interface 282 may be a web page or other interface through which some of the query results may be displayed.

FIG. 3 is a diagram illustration of an example embodiment 300 showing a software component relationship graph. Embodiment 300 is a simple graph that illustrates components 302, 304, 306, and 308 along with various relationships.

The components may represent reusable software components that may be deployed on various applications. The components may have been discovered through tracer data, source code analysis, repository analysis, or other mechanisms, examples of which may be found later in this specification.

Components 302 and 304 are illustrated with an express relationship 310. The express relationship 310 may be directional, indicating that component 302 may be included or called from component 304. Such a relationship may be a hardcoded relationship, where the source code of component 304 may have called component 302.

Components 306 and 308 are illustrated with a mutually exclusive relationship 314. In a mutually exclusive relationship, two components may often be used in place of each other and rarely used together. Such relationships may be identified by analyzing changes made to an application over many versions. When one component is removed and another component added, such a situation may indicate a mutually exclusive relationship.

Components 302, 304, 306, and 308 may be joined by implied relationships 312. Implied relationships may be identified when two components may be used in the same application. Such relationships may indicate that two components are compatible with and complementary to each other.

A graph such as embodiment 300 may be used to recommend components. For example, an application may contain component 306, which may have implied relationships to components 302 and 304. During an analysis, components 302 and 304 may be recommended to a developer, as components 302 and 304 are commonly used with component 306. Additionally, component 308 may be recommended as a replacement to component 306 due to the mutually exclusive relationship.

FIG. 4 is a diagram illustration of an embodiment 400 showing recommendations with both relationship and performance data.

Embodiment 400 illustrates a request 402 that may include design parameters 404 and possible components 406 for an application. The request 402 may be processed by a query engine 408 to generate some results 414. In another scenario, a request 416 may be generated from an existing application and trace data.

In both types of requests, the query engine 408 may receive information regarding the operational characteristics and deployment architecture. The operational characteristics may be a description of how a component may be used. Such a description may include the load, frequency of requests, input parameters, and other descriptions of intended use. The deployment architecture may define the hardware and software platforms on which the component may execute. Such descriptors may include processor speed, number of processors, memory, storage capacity, storage and network bandwidth, throughput and latency, and other parameters.

The possible components 406 may be a preliminary architecture for an application. Such information may be a starting point for traversing a component graph and providing architecture recommendations. In one use case, the possible components 406 may be components that may represent intended functionality of an application. In such a use case, the results 414 may be a set of components that may match the deployment architecture and intended operational characteristics. Such a use case may be helpful to identify software components at the beginning of a project that may be optimally suited for an intended deployment.

An existing application request 418 may analyze an application that may be in some state of deployment. In some cases, the application may be in development and executing on test or development hardware, while in other cases, the application may have been deployed on production hardware and executed under production loads. Such an application 418 may include several components 420.

A set of trace data 422 may be included in the request 416. The trace data 422 may be analyzed by the analyzer 424 to extract actual operational characteristics and deployment architecture information. Such an analysis may be useful when the trace data 422 may be gathered in a production environment. In cases where the trace data 422 may not accurately reflect an intended production environment and usage, a user may manually select such parameters.

The query engine 408 may analyze a request to generate results 414 that may include a list of suggested components and various performance metrics for the components. A component graph 412 may be queried to identify comparable or related components to those identified in a request. The list of components may be analyzed against a trace database 410 to determine performance and other parameters. Once the performance is known, the components may be ranked or sorted. Recommendations may be made by comparing a baseline set of components in the request to other components that may be identified from the component graph 412.

FIG. 5 is a flowchart illustration of an embodiment 500 showing a method for parametric analysis of trace data. Embodiment 500 illustrates a simplified method for extracting differentiating factors from multiple trace datasets.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

Trace datasets may be received in block 502. An element to be analyzed may be identified in block 504. The element to be analyzed may be a software component, for example.

All datasets containing the element may be retrieved in block 506. For each dataset in block 508, a vector may be created containing any available metadata elements in block 510. After creating vectors for each dataset, multivariate analysis may be performed in block 512 to determine the differentiating factors, which may be stored in block 514.

The differentiating factors may be those factors having the largest effect on performance or other metric. These factors may indicate conditions under which a given component may operate well and which conditions the same component may operate poorly. Such factors may be useful when comparing similar components. For example, when suggesting or recommending components for a given set of execution conditions, a sort may be performed on the differentiating factors to identify components that may operate well under the selected conditions.

The differentiating factors may be useful to developers who may be responsible for a selected component. The factors may indicate performance issues under certain conditions and give the developer some direction for improving a component.

FIG. 6 is a diagram illustration of an example embodiment 600 showing mechanisms for generating a component graph. Embodiment 600 may illustrate three different sources for data from which components and relationships between the components may be identified.

An application repository 604, component repository 606, and tracer database 608 may each have data from which components and their relationships may be extracted. In some cases, certain types of relationships may be found from one source while other sources may have other types of relationships.

An application repository 604 may contain application source code 614. The application source code may contain multiple versions of the application. In each version, different sets of components 616, 618, and 620 may be present. The presence of multiple components in a single application may indicate an implied relationship between the components. Additionally, a component that may be removed and replaced by a second component in a subsequent version of an application may indicate a mutually exclusive relationship.

A component repository 606 may contain component source code 622. In some cases, a component source code 622 may contain calls to other components 624 and 626. Such calls may indicate an express relationship between the components, as the first component may include or call the other components in a hard coded manner.

A tracer database 608 may include tracer data 628 that may be collected by monitoring applications. In many cases, the trace data may be collected from monitoring many different applications 630, many of which may include reusable software components 632 and 634. Implied and express relationships may sometimes be inferred from trace data, depending on how detailed the trace data may be. In cases where different versions of an application may be traced, mutually exclusive relationships may be inferred.

A graph engine 610 may take data from any of the various sources, such as the application repository 604, component repository 606, and trace database 608 to create the component graph 612. Examples of such processes may be found later in this specification.

FIG. 7 is a flowchart illustration of an embodiment 700 showing a method for building a component graph. Embodiment 700 may illustrate an example method performed by a graph engine when accessing an application repository to identify reusable software components and implied relationships between the components.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

An application repository may be accessed in block 702. The repository may be a conventional source code repository with multiple versions of an application.

The applications to analyze may be identified in block 704. Each application may be analyzed in block 706. In many cases, the analysis of the application may be performed by static examination of source code. In other cases, the analysis may be performed by examining intermediate code, call traces, or other information.

If the application does not call multiple components in block 708, the process may return to block 706.

If the application does call multiple components in block 708, each component may be analyzed in block 710. If the component is not in a component graph in block 712, the component may be added in block 714.

After adding any new components in block 710, the components may be analyzed in block 716. For each component in block 716, each of the remaining components may be analyzed in block 718 and an implied relationship may be created in block 720. In some instances, an implied relationship may be a directional relationship, where the strength or type of relationship may be different from a first component to a second component than from the reverse direction.

After analyzing each application in block 706, the component graph may be stored in block 722.

FIG. 8 is a flowchart illustration of an embodiment 800 showing a method for building a component graph using data from a component repository. Embodiment 800 may illustrate an example method performed by a graph engine when accessing a component repository to identify reusable software components and express relationships between the components.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

A component repository may be accessed in block 802. The repository may be a directory of various components, and may contain metadata, source code, or other information about reusable software components. In some cases, the component repository may serve as a directory to search for components, and the component source code may be located in a different repository.

The components may be analyzed in block 804. For each component, if the component is not in the graph in block 806, the component may be added to the graph in block 808.

The component may be analyzed in block 810 to determine if any components are called from the current component. Each of the called components may be processed in block 812. If the called component is not in the graph in block 814, it may be added in block 816.

An express relationship may be created in block 818.

After processing all of the called components in block 812, the process may return to block 804. After processing all of the components in block 804, the component graph may be stored in block 820.

FIG. 9 is a flowchart illustration of an embodiment 900 showing a method for building a component graph from trace data. Embodiment 900 may illustrate an example method performed by a graph engine when accessing a trace database to identify reusable software components and implied relationships between the components. Embodiment 900 illustrates the analysis of a single trace dataset. For a large database, embodiment 900 may be applied to each dataset in the database.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

A trace dataset may be received in block 902. The trace dataset may represent tracing data collected by monitoring a single application. Each component within the dataset may be identified in block 904 and separately analyzed in block 906.

For each component in block 906, if the component is not the graph in block 908, the component may be added in block 910.

For each component in block 912, all other components in the application may be identified in block 914. Those additional components may be individually processed in block 916.

If the components from blocks 912 and 916 have a predefined express relationship in block 918, the process may return to block 916 without changing the relationship status. In many embodiments, an express relationship may dominate any implied relationships, such that when an express relationship exists, any implied relationship may be discarded.

If the components from block 912 and 916 do not have a predefined implied relationship in block 920, the implied relationship may be created in block 922. The newly created or predefined implied relationship may be strengthened in block 924.

Many embodiments may include a strength factor for implied relationships. A strength factor may be raised when multiple observations of the same relationship are made.

FIG. 10 is a flowchart illustration of an embodiment 1000 showing a method for identifying mutually exclusive relationships. Embodiment 1000 may illustrate an example method performed by a graph engine when accessing an application repository to identify mutually exclusive relationships between the components.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

Mutually exclusive relationships may be implied from analyzing different versions of an application. Such relationships may be identified when a developer replaces a component with another component from one version of an application to another. Such relationships may be implied through observations, and such relationships may be significantly strengthened when receiving human input that may confirm that the second component replaced the first.

An application repository may be accessed in block 1002. The applications to analyze may be identified in block 1004. Each application may be processed in block 1006.

For each application in block 1006, each version of the application may be processed in block 1008. For each version of the application in block 1008, a list of components in the version may be generated in block 1010. If there are no changes from the previous version in block 1012, the process may loop back to block 1008.

If changes to the list of components occurred in block 1012, each change may be processed in block 1014.

For each change in block 1014, an analysis may be made in block 1016 to determine if one component was removed and another component added. If such a determination is not true in block 1018, the process may return to block 1014.

If the determination is true in block 1018, an implied mutually exclusive relationship may exist. If such a relationship does not currently exist between components in block 1020, the relationship may be created in block 1022. The newly created or preexisting relationship may be strengthened in block 1024.

After processing all of the changes in block 1014 for each version in block 1008 of each application in block 1006, the component graph may be stored in block 1028.

FIG. 11 is a flowchart illustration of an embodiment 1100 showing a method for generating suggestions. Embodiment 1100 may illustrate an example method performed by a query engine to combine both performance data derived from trace data and a component graph.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

A usage description may be received for an application in block 1102. The usage description may include any parameters that may describe how an application may be used. Such a description may include items like the anticipated workload, desired reliability, or other performance metrics.

An architecture description may be received in block 1104. The architecture description may include hardware and software components on which the application may be executed.

In some cases, the usage description and architecture description may be derived from existing trace data of the application. Such a case may be useful when a recommendation may be generated for an application in production. In other cases, the usage description and architecture description may be a description of anticipated conditions under which an application may be executed.

The architecture description may be analyzed in block 1106 to identify reusable software components. The components may be determined by analyzing source code or from a general description of the application. Each component may be analyzed in block 1108.

For each component in block 1108, a set of performance metrics may be determined for the component. The performance metrics may be derived from a tracer database.

In many cases, the performance metrics may be estimated metrics based on the usage and architecture. Such metrics may reflect the anticipated performance given the anticipated usage and architecture.

A search of the component graph may be made in block 1112 to identify related components. For each related component in block 1114, performance metrics for those components may be determined in block 1116.

The group of related components may be sorted by the performance metrics in block 1118. An analysis of the current components verses the related components may be made in block 1120. If there are related components with better performance metrics in block 1122, the other components may be suggested to the user in block 1124. If no better components exist in block 1122, the suggestions may be omitted.

The suggestions may be presented to a user in block 1126.

FIG. 12 is a flowchart illustration of an embodiment 1200 showing a method for constructing a query based on an existing application and trace data. Embodiment 1200 may illustrate an example method performed by an analysis engine that may take existing applications and their trace data to prepare a recommendation query.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

An application may be received in block 1202 along with its trace data.

The application may be analyzed to identify all of its reusable components in block 1204. The analysis may be performed from the trace data, application source code, or other source.

The trace data may be analyzed in block 1206 to identify the usage conditions for the application. The usage conditions may be the actual usage conditions observed during tracing.

The usage and architecture information may be presented to a user in block 1208 and any manually made changes to the observations may be gathered in block 1210. The changes may be saved as a query in block 1212. The query may be transmitted in block 1214. In some embodiments, the query may be processed using a method similar to that of embodiment 1100.

The foregoing description of the subject matter has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the subject matter to the precise form disclosed, and other modifications and variations may be possible in light of the above teachings. The embodiment was chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and various modifications as are suited to the particular use contemplated. It is intended that the appended claims be construed to include other alternative embodiments except insofar as limited by the prior art.

Claims

1. A method performed on at least one computer processor, said method comprising: receiving a plurality of trace datasets, each of said trace datasets comprising a time series of performance data gathered while monitoring a first software component;analyzing said plurality of trace datasets to determine a differentiating factor that causes differences between said trace datasets, wherein determining the differentiating factor also includes identifying a set of one or more complementary components that, when executed, either increased or decreased an effectiveness of the first software component when the first software component was being executed; andpresenting said differentiating factor or said set of one or more complementary components to a user.

2. The method of claim 1, said differences comprising performance differences between said trace datasets.

3. The method of claim 2, said differentiating factor comprising hardware differences.

4. The method of claim 3, said differentiating factor further comprising software differences.

5. The method of claim 4 further comprising ranking a plurality of differentiating factors.

6. The method of claim 5, said performance data comprising resource consumption data.

7. The method of claim 6, said resource consumption data comprising at least one of a group composed of: processor resource consumption data; memory resource consumption data; and network resource consumption data.

8. The method of claim 6, said performance data comprising usage data.

9. The method of claim 8, said usage data comprising at least one of a group composed of: function call counts; and input parameters receives.

10. The method of claim 2, said first software component being an application.

11. The method of claim 10, a first trace dataset being gathered while executing said application on a first hardware configuration and a second trace dataset being gathered while executing said application on a second hardware configuration.

12. The method of claim 2, said first software component being a reusable software component.

13. The method of claim 12, a first trace dataset being gathered while executing said reusable software component as part of a first application, and a second trace dataset being gathered while executing said application as part of a second application.

14. A system comprising: a database comprising a plurality of trace datasets, each of said trace datasets being a time series of performance data gathered while monitoring a first software component;at least one processor; andan analysis engine operating on said at least one processor, said analysis engine that: receives a plurality of trace datasets, each of said trace datasets comprising a time series of performance data gathered while monitoring a first software component; andanalyzes said plurality of trace datasets to determine a differentiating factor that causes differences between said trace datasets, wherein determining the differentiating factor also includes identifying a set of one or more complementary components that, when executed, either increased or decreased an effectiveness of the first software component when the first software component was being executed.

15. The system of claim 14 further comprising: an interface that receives a first request and returns said differentiating factor as a response to said first request.

16. The system of claim 15, said interface being an application programming interface.

17. The system of claim 14, said first software component being a reusable software component.

18. The system of claim 17, a first trace dataset being collected while executing a first application using said reusable software component and a second trace dataset being collected while executing a second application using said reusable software component.