Automated display of trace historical data

BACKGROUND

Background and Relevant Art

Computing systems have revolutionized the way we work and play. Computing systems come in a wide variety of forms including laptop computers, desktop computers, personal digital assistants, telephones, and even devices that have not been conventionally associated with computing systems such as, for example, refrigerators and automobiles. Computing systems may even comprise a number of constituent computing systems interconnected via a network. Thus, some computing systems may be small enough to fit in the palm of the hand, while others are spread over much of the globe.

Regardless of their physical form, computing systems are composed of hardware and software. The hardware includes most fundamentally at least one processor and memory. The software includes instructions that may be embodied in the memory and/or in storage, and can be accessed and executed by the processor(s) to direct the overall functionality of the computing system. Thus, software plays a critical role in driving computing system functionality.

In order to construct software, a human being programmer first writes code that conforms to a programming language that contains syntax and semantics that are human readable and/or intuitive to a human being. Such code is referred to as “source code”. The source code is then compiled and/or interpreted into machine-readable binary for execution by a computing system.

As the capabilities of computing systems have increased, so has the complexity of the software that drives the computing system. Even the most basic of computer programs may be derived from thousands of lines of source code. Software programs can be so complex that despite diligent efforts from experienced software experts, the software may still not perform as designed in some circumstances. In order to diagnose what the problem is, software often causes to be written human-interpretable diagnostic information while executing. An entry of this diagnostic information is often termed a “trace” or “trace entry”. By reviewing the trace entries, a software professional may often diagnose the problem with the software, so that an appropriate fix may be implemented.

Trace information may even be recorded by distributed systems, where each system node may record its own historical trace information. The amount of trace information can be truly overwhelming or at least time consuming for a human being to interpret, especially in distributed systems.

BRIEF SUMMARY

Embodiments of the present invention relate to the intuitive display of trace historical data in a manner that processing control transfer between processing entities is represented in the context of trace data from multiple processing entities. For each processing entity, a set of one or more trace entries are identified for that processing entity and displayed in a manner that the trace entries for the processing entity are shown associated with the processing entity.

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 as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> schematically illustrates a suitable computing environment that may implement features of the present invention;

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates example schematic data structures and flows that may be used by the computing system of <figref idrefs="DRAWINGS">FIG. 1</figref> to implement features of the present invention;

<figref idrefs="DRAWINGS">FIG. 3</figref> schematically illustrates a trace entry data structure that may be used by embodiments of the present invention;

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a flowchart of a method for automatically causing to be displayed trace historical data in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a simple display that illustrates an activity graph including trace entries for each of multiple activities in accordance with a first embodiment of the present invention;

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a more extensive display that illustrates an activity graph including trace entries for each of multiple activities in accordance with a second embodiment of the present invention; and

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a method for visually identifying characteristics of trace entries that may be used consistent with the principles of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention extend to the intuitive display of trace historical data in a manner that processing control transfer between processing entities is visually represented in the context of trace data of the processing entities. First, an example computing system in which features of the present invention may operate will be described with respect to <figref idrefs="DRAWINGS">FIG. 1</figref>. Then, embodiments of the present invention will be described in further detail with respect to <figref idrefs="DRAWINGS">FIGS. 2 through 7</figref>.

The embodiments of the present invention may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail below. <figref idrefs="DRAWINGS">FIG. 1</figref> shows a schematic diagram of an example computing system <b>100</b> that may be used to implement features of the present invention. The described computing system is only one example of such a suitable computing system and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the invention be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, or even devices that have not been conventionally considered a computing system. In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one processor, and a memory capable of having thereon computer-executable instructions that may be executed by the processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

Referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, in its most basic configuration, a computing system <b>100</b> typically includes at least one processing unit <b>102</b> and memory <b>104</b>. The memory <b>104</b> may be system memory, which may be volatile, non-volatile, or some combination of the two. An example of volatile memory includes Random Access Memory (RAM). Examples of non-volatile memory include Read Only Memory (ROM), flash memory, or the like. The computing system <b>100</b> may also have storage <b>106</b>. Such storage may be removable or non-removable, and may include (but is not limited to) PCMCIA cards, magnetic and optical disks, magnetic tape, and the like.

As used herein, the term “module” or “component” can refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). While the system and methods described herein may be implemented in software, implementations in hardware, and in combinations of software and hardware are also possible and contemplated.

In the description that follows, embodiments of the invention are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions. An example of such an operation involves the manipulation of data. The computer-executable instructions (and the manipulated data) may be stored in the memory <b>104</b> of the computing system <b>100</b>.

Computing system <b>100</b> may also contain communication channels <b>108</b> that allow the computing system <b>100</b> to communicate with other computing systems over, for example, network <b>110</b>. Communication channels <b>108</b> are examples of communications media. Communications media typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information-delivery media. By way of example, and not limitation, communications media include wired media, such as wired networks and direct-wired connections, and wireless media such as acoustic, radio, infrared, and other wireless media. The term computer-readable media as used herein includes both storage media and communications media.

Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. For instance, the memory <b>104</b>, storage <b>106</b> and/or communication channels <b>108</b> (either singly or in combination) may each be considered a computer-readable media <b>120</b>. In this description and in the claims, a “physical” computer-readable media refers to either or both of memory <b>104</b> and storage <b>106</b>, or portions thereof.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. For instance, computer-executable instructions in the memory <b>104</b>, storage and/or on the communication channels <b>108</b> may director the processor(s) to cause items to be displayed on a display <b>112</b> of the computing system <b>110</b>. The display <b>112</b> is illustrated symbolically as a simple box, although the display will take a wide variety of forms depending on the nature of the computing system <b>100</b>, and depending on the designers' choices.

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 herein. Rather, the specific features and acts described herein are disclosed as example forms of implementing the claims.

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates example schematic data structures and flows <b>200</b> that may be used to implement aspects of the principles of the present invention to visually represent trace historical data. The data structures and flows <b>200</b> may be implemented in the context of the computing system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>, although that is not required by any means. <figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a flowchart of a method <b>400</b> for a computing system automatically causing trace historical data to be displayed on its display. For instance, when implemented by the computing system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>, the trace historical data may be displayed on the display <b>112</b>.

The display of trace historical data may be made in a manner that the flow of processing activity may be observed across multiple activities performed by multiple processing entities. This allows for a more intuitive understanding of the context of each trace entry within the entire flow of processing across multiple processing entities. Thus, the bulk of trace information may be more easily digested, allowing for more efficient diagnosis of software performance issues, even when multiple processing entities are involved. As the example data structures and flows <b>200</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> may be used to understand the method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref>, the method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref> will be described with frequent reference to the data structures and flows <b>200</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>.

Referring to the method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref>, trace entries representing trace historical data are accessed (act <b>401</b>). In the example of <figref idrefs="DRAWINGS">FIG. 2</figref>, the access module <b>210</b> access and provides trace entries <b>211</b>. In this particular example, there are 14 trace entries labeled <b>211</b>A through <b>211</b>M, though the principles of the present invention may be performed with any number of trace entries. Each trace entry records an action that was performed by one of processing entities <b>212</b>. A processing entity may be on the same or different computing system, and may or may not be implemented on the same computing system performing the method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref>. The processing entity may be a computer program, program component, process, thread, thread portion, or any other hardware or software that is capable of processing or being processed.

While the processing entity was previously executing, the trace entries were generated to describe actions that the processing entity was performing at particular points in time. If there was a trace entry that was generated by another computing system, the trace entry may be accessed over a network or over an out-of-band mechanism from the other computing system. The trace entry might also be accessed from local memory and/or storage. The precise mechanism by which the trace entries are accessed is not important to the principles of the present invention. Suffice it to say that there are a large number of mechanisms by which the trace entries may be accessed.

<figref idrefs="DRAWINGS">FIG. 3</figref> schematically represents a trace entry data structure <b>300</b>, and represents just one of numerous possible data structures that may be used to represent a trace entry, and thus should not be construed to limit the principles of the present invention. The trace entry <b>300</b> is illustrated simply to show the types of data that might be included in a trace entry, and not to suggest any physical restriction on the structure of a trace entry.

The trace entry <b>300</b> may include an action description <b>301</b> that represents the action that was performed by the processing entity. The action description <b>301</b> may be human-readable, although that need not be the case. The types of actions that may be recorded may vary widely depending on the situation, and depending on what actions are desired and helpful to be captured through the trace historical data. The principles of the present invention are in no way limited to the type of actions recorded in the trace entry. However, examples of actions recorded in the trace entries may include the sending of a message, the setting of a particular value, the branching of code, the passing of control to another component or processing entity, a variable becoming a certain value or moving into a certain value range, the occurrence of a processor interrupt, the writing to non-volatile memory, or an infinite variety of other possible actions. Even actions that may not be interesting to the evaluation of the processing entity's performance may be recorded.

The trace entry <b>300</b> may additionally or alternatively have an action code <b>302</b> that may be directly or indirectly computer-readable, or may even be interpreted using extrinsic information to identify the action recorded. An action may even be implied by the absence of an expressed indication of the action in the trace entry <b>300</b>.

The trace entry <b>300</b> also may include an activity identifier <b>303</b> that identifies the activity that the trace entry belongs to. In this description and the claims, an “activity” is a sequence of trace entries that have resulted from processing performed by a processing entity. As will become clearing hereinafter, the trace entries <b>211</b> may describe actions performed by a number of different processing entities. Accordingly, the trace entries <b>211</b> may include trace entries from different activities. The activity identifier <b>303</b> may be used to identify the trace sequence or “activity” that the trace comes from. The absence of an activity identifier may imply that the trace entry is part of a particular activity. Alternatively or in addition, extrinsic information may be used to identify the activity even if the trace entry itself contains no activity identifier per se.

The system identifier <b>304</b> may be used to identify the system that performed the processing that caused the activity to be generated. A system may include a physical computing system or a combination of physical computing systems. If the processing entities that are represented by the trace entries come from multiple systems, the system identifier <b>304</b> may be used to identify on which system the processing entity was running that caused the trace entry to be generated. Of course, the system identifier <b>304</b> may be eliminated if the trace entries all come from a single computing system or if the computing system is implied by the absence of the system identifier.

The trace entry <b>300</b> also includes a time stamp <b>305</b> that represents the rendering of time at the system that generated the trace entry at the approximately the time that the action recorded by the trace entry occurred. The trace entry <b>300</b> may also have correlation data <b>306</b> if the action <b>301</b> represents the partial or full passage of processing control from one processing entity to another. The correlation data <b>306</b> allows the actions on different processing entities to be correlated when those actions involved the transfer of processing control.

Although not yet apparent from the trace entries <b>211</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>, the trace entries <b>211</b> come from three different activities performed by processing entities <b>212</b> represented in <figref idrefs="DRAWINGS">FIG. 2</figref> symbolically as processing entities <b>212</b>A, <b>212</b>B and <b>212</b>C. Referring to <figref idrefs="DRAWINGS">FIG. 4</figref>, the acts <b>411</b> and <b>412</b> are performed for each activity. <figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a simple user interface <b>500</b> that may be generated using the trace entries <b>211</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>, and using the method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref>. The simple user interface <b>500</b> is referred to herein as a “simple activity graph”.

Referring back to <figref idrefs="DRAWINGS">FIG. 4</figref>, the trace entries corresponding to each processing entity are identified (act <b>411</b>). In this case, referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, trace entries <b>211</b>A, <b>211</b>I, <b>211</b>L, <b>211</b>K, <b>211</b>H and <b>211</b>G are identified as being performed in that order by the first processing entity <b>212</b>A. This identification may be performed by the activity identification module <b>220</b>. The identification may be performed by accessing and interpreting the activity identifier <b>303</b> (see <figref idrefs="DRAWINGS">FIG. 3</figref>) of each of the trace entries. The chronological ordering of the trace entries within a single activity may be identified by evaluating the time stamp <b>305</b> for each trace entry.

In the same manner, the trace entries <b>211</b>F, <b>211</b>E, <b>211</b>B and <b>211</b>M in that chronological order may be identified as being performed by the second processing entity <b>212</b>B. Furthermore, the trace entries <b>211</b>D, <b>211</b>C and <b>211</b>J in that chronological order may be identified as being performed by the third processing entity <b>212</b>C. This identification may be automated without user intervention by automatically reading and evaluating the activity identifier <b>303</b> and the time stamp <b>305</b> for each of the trace entries <b>211</b>.

Once the trace entries for any given processing entity have been identified optionally in chronological order within the activity, the computing system causes to be displayed on the display a representation of at least one of the associated trace entries as being associated with a first activity in an activity graph (act <b>412</b>). For instance, if the method <b>400</b> is performed, by the computing system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>, the computer-readable media <b>120</b> may contain computer-executable instructions that, when executed by the processor(s) <b>102</b>, causes the computing system <b>100</b> to represent the trace entries on display <b>112</b>. Referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, this display rendering may be performed by the display renderer <b>240</b>.

For instance, <figref idrefs="DRAWINGS">FIG. 5</figref>, as previously mentioned, represents a basic activity graph <b>500</b> that may be generated on the display <b>112</b>. A more complex and detailed example of an activity graph <b>600</b> is given with respect to <figref idrefs="DRAWINGS">FIG. 6</figref>. The simple activity graph <b>500</b> includes a representation <b>512</b>A (hereinafter, “activity <b>512</b>A”) of an activity formulated from actions performed by the first processing entity <b>212</b>A to perform a first task, a representation <b>512</b>B (hereinafter, “activity <b>512</b>B”) of an activity formulated from actions performed by the second processing entity <b>212</b>B to perform a second task, and a representation <b>512</b>C (hereinafter, “activity <b>512</b>C”) of an activity formulated from actions performed by the third processing entity <b>212</b>C to perform a third task.

In the example of <figref idrefs="DRAWINGS">FIG. 5</figref>, the activities are represented using vertical boxes with dashed lines in the form of an activity graph. However, the principles of the present invention are not limited to how the activities are represented on the display. There are numerous ways to represent an activity. In <figref idrefs="DRAWINGS">FIG. 5</figref>, the trace entries are represented as associated with an activity by having a corresponding visual representation of the trace entry included within the vertical box of the corresponding activity. In this example, the trace entries are represented using a simple box. Chronological ordering of trace entries for any given activity may be represented by the sequential ordering top-to-bottom of the corresponding trace entry box in the activity.

For instance, activity <b>512</b>A is displayed with traces representations <b>511</b>A, <b>511</b>I, <b>511</b>L, <b>511</b>K, <b>511</b>H and <b>511</b>G in that order from top to bottom. This represents that trace entries <b>211</b>A, <b>211</b>I, <b>211</b>L, <b>211</b>K, <b>211</b>H and <b>211</b>G (in that order) represent a trace sequence activity for processing entity <b>212</b>A towards the first task. Activity <b>512</b>B is displayed with trace representations <b>511</b>F, <b>511</b>E, <b>511</b>B and <b>511</b>M; representing that trace entries <b>211</b>F, <b>211</b>E, <b>211</b>B and <b>211</b>M (in that order) represent a trace sequence activity for processing entity <b>212</b>B towards the second task. Activity <b>512</b>C is displayed with trace representations <b>511</b>D, <b>511</b>C and <b>511</b>J; representing that trace entries <b>211</b>D, <b>211</b>C and <b>211</b>J (in that order) represent a trace sequence activity for processing entity <b>213</b>B towards the third task.

Thus, the principles of the present invention permit the automated display of activities performed by different processing entities using trace historical data documenting activities performed by the different processing entities. As will now be described in further detail, the principles of the present invention also allow for full or partial transfers of processing control between processing entities to be automatically identified and displayed.

For instance, walking through the example user interface <b>500</b> of <figref idrefs="DRAWINGS">FIG. 5</figref>, there are a variety of processing control transfers between activities. Some of the transfers may be partial transfers, in which the activity that transferred control continues processing and continues generation of trace entries. Others of the transfers may be full transfers, in which the processing entity that transferred control ceases processing and ceases generation of trace entries, at least until the processing entity receives processing control back.

In <figref idrefs="DRAWINGS">FIG. 5</figref>, the activity <b>512</b>A represents that the trace entries of processing, entity <b>212</b>A includes first in chronological order the trace entry <b>211</b>A as represented by the trace <b>511</b>A. The activity <b>512</b>A then includes trace <b>511</b>I, which corresponds to an action involving partial transfer of control to the activity <b>512</b>B as represented by arrow <b>513</b>A. Since this was only a partial transfer of control, activity <b>512</b>A continues with traces <b>511</b>L and <b>511</b>K. Meanwhile, the activity <b>512</b>B receives partial control as represented by the trace <b>511</b>F. Subsequently, the activity <b>512</b>B includes trace <b>511</b>E, which involves the full transfer of control to activity <b>512</b>C as represented by arrow <b>513</b>B. This is a full transfer since the activity <b>512</b>B does not perform further processing or trace generation until it receives control back from activity <b>512</b>C. The activity <b>512</b>C receives processing control as represented by trace <b>511</b>D.

Subsequently, the activity <b>512</b>C includes trace <b>511</b>C, and then trace <b>511</b>J involving transfer of control back to activity <b>512</b>B as represented by arrow <b>513</b>C. The activity <b>512</b>B receives processing control which is documented in trace <b>511</b>B. The activity <b>512</b>B then transfers processing control back to activity <b>512</b>A as represented by trace <b>511</b>M, arrow <b>513</b>D, and trace <b>511</b>H. The activity <b>512</b>A then includes trace <b>511</b>G. Thus, the simple example of <figref idrefs="DRAWINGS">FIG. 5</figref> involves four transfers of processing control between activities.

Referring back to <figref idrefs="DRAWINGS">FIG. 4</figref>, in order to properly display the transfers of processing control, acts <b>421</b> and <b>422</b> are performed for each transfer of control, whether a partial transfer or a full transfer. First, the transfer of processing control is first identified for each transfer (act <b>421</b>). This identification may be automated by having a transfer identification module <b>230</b> (see <figref idrefs="DRAWINGS">FIG. 2</figref>) evaluate the trace entries <b>211</b>. In this case, however, not all of the trace entries <b>211</b> involve the transfer of processing control. Instead, only trace entries <b>211</b>I, <b>211</b>F, <b>211</b>E, <b>211</b>D, <b>211</b>J, <b>211</b>B, <b>211</b>M and <b>211</b>H involve partial or full transfer, of processing control.

The transfer is identified by evaluating the action description or code for the trace entry. For processing entities that span a network, the transfer of processing control may be effected by the transmission and receipt of a message. For any given control transfer, the trace entry involved with sending control and the trace entry associated with receiving control are identified. This may be accomplished by using the correlation data <b>306</b> (see <figref idrefs="DRAWINGS">FIG. 3</figref>) of the trace entries. For instance, in the case of a network message, the message may include a specific identifier that is unique to that message. That way, the transfer identification module may identify the trace entry that records the action that initiated the control transfer in one activity, and the trace entry that records the action that completed the control transfer in the other activity. For control transfers that do not involve a network message, the correlation data may involve a data identifier for any data that is passed as part of the processing control transfer.

The control transfer identification (act <b>421</b>) is performed for each transfer of control. From this, the transfer identification module may identify that the action recorded in trace <b>211</b>I originated transfer of processing control from processing entity <b>212</b>A, and that the action record in trace <b>211</b>F completed the transfer of processing control to processing entity <b>212</b>B. The transfer may then be visually represented on the display (act <b>422</b>). For instance, in <figref idrefs="DRAWINGS">FIG. 5</figref>, arrow <b>513</b>A is represented originating from trace representation <b>511</b>I and ending at trace representation <b>511</b>F. The activities <b>512</b>A, <b>512</b>B, and <b>512</b>C are vertically adjusted so that the arrows are pointing sideways in this example. The rendering of the visual representation of the transfer may be performed by the display renderer <b>240</b> (see <figref idrefs="DRAWINGS">FIG. 2</figref>) once the transfer identification is made by the transfer identification module <b>230</b>.

Similarly, the action recorded in trace <b>211</b>E may be identified as originating transfer of processing control from processing entity <b>212</b>B, and the action recorded in trace <b>211</b>D may be identified as completing transfer of processing control to processing entity <b>212</b>C (act <b>421</b>). This second transfer may then be visually represented on the display (act <b>422</b>). For instance, in <figref idrefs="DRAWINGS">FIG. 5</figref>, arrow <b>513</b>B is represented originating from trace representation <b>511</b>E and ending at trace representation <b>511</b>D.

Furthermore, the action recorded in trace <b>211</b>J may be identified as originating transfer of processing control from processing entity <b>212</b>C, and the action recorded in trace <b>211</b>B may be identified as completing transfer of processing control to processing entity <b>212</b>B (act <b>421</b>). This third transfer may then be visually represented on the display (act <b>422</b>). For instance, in <figref idrefs="DRAWINGS">FIG. 5</figref>, arrow <b>513</b>C is represented originating from trace representation <b>511</b>J and ending at trace representation <b>511</b>B.

Finally, the action recorded in trace <b>211</b>M may be identified as originating transfer of processing control from processing entity <b>212</b>B, and the action recorded in trace <b>211</b>H may be identified as completing transfer of processing control to processing entity <b>212</b>A (act <b>421</b>). This last transfer in the example of <figref idrefs="DRAWINGS">FIGS. 2 and 5</figref> may then be visually represented on the display (act <b>422</b>). For instance, in <figref idrefs="DRAWINGS">FIG. 5</figref>, arrow <b>513</b>D is represented originating from trace representation <b>511</b>M and ending at trace representation <b>511</b>H.

The principles of the present invention have been described with respect to a relatively simple activity graph of <figref idrefs="DRAWINGS">FIG. 5</figref> in order to not obscure the principles of the present invention using a more complex example. However, the principles of the present invention may be used to automatically formulate a more complex and sophisticated visual representation of activity across multiple processing entities. <figref idrefs="DRAWINGS">FIG. 6</figref> illustrates an example of a much more complex user interface <b>600</b>.

The complex user interface <b>600</b> includes four frames <b>601</b>, <b>602</b>, <b>603</b> and <b>604</b>, in additional to an administration area <b>605</b>. The administration area <b>605</b> includes fields for searching and filtering the tracing information, and is not important for the principles of the present invention, and thus will not be described in further detail herein.

Frame <b>601</b> represents an activity graph. In this case, there are six total activities <b>612</b>A, <b>612</b>B, <b>612</b>C, <b>612</b>D, <b>612</b>E and <b>612</b>F, each resulting from actions performed by different processing entities identified on column header <b>616</b>. Two of the activities <b>612</b>A and <b>612</b>B are performed by one system identified as system “A”, and four of the activities <b>612</b>C, <b>612</b>D, <b>612</b>E and <b>612</b>F are performed by a processing entities on a second system identified as system “B”. There are also various arrows showing transfer of control between processing entities. One of the arrows <b>613</b> shows not only control between processing entities, but also transfer of processing control across systems. Arrows showing transfer of control across systems may be visually distinguished (e.g., shown in a different color, or with a different type of arrow) from transfers of control between processing entities within a single system. A time field <b>614</b> shows the approximate trace time of the trace aligned to the right. The column header <b>616</b> includes a box that describes the name of the processing entity performing the actions documented by traces in that column. The processing entities generating activities <b>612</b>A and <b>612</b>B are named “1” and “2”, respectively. The processing entities generating activities <b>612</b>C through <b>612</b>F are named “11” through “14”, respectively. Another column header <b>617</b> includes a system identification that identifies the system that runs the processing entities shown below the corresponding system identification.

Frame <b>602</b> includes descriptive information for the trace information before and after and including the trace selected by the highlighted row. The Clear Board frame <b>604</b> may be used in the diagnostic process to show prior diagnostic actions taken.

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a flowchart for visually distinguishing one trace from another in accordance with one embodiment of the present invention. As shown in <figref idrefs="DRAWINGS">FIGS. 5 and 6</figref>, the principles of the present invention may be used to automatically formulate a user interface (e.g., an activity graph) in which each trace performed by a processing entity is shown associated with the corresponding activity, and in which transfers of control between processing entities are intuitively visualized. This allows a human trace evaluator to intuitively view each trace in the context of processing activities that span multiple processing entities or even multiple computing systems. <figref idrefs="DRAWINGS">FIG. 7</figref> includes a flowchart of a method <b>700</b> that permits further information to be visually conveyed to a human evaluator in an intuitive fashion.

In particular, the method <b>700</b> identifies trace characteristics that are to be visually emphasized (act <b>701</b>), identifies one or more trace entries that have the trace characteristic (act <b>702</b>), and then causes the identified trace entries that have the trace characteristic to be displayed in a visually distinctive manner as compared to one or more trace entries that do not have the trace characteristic (act <b>703</b>).

For instance, referring to <figref idrefs="DRAWINGS">FIG. 6</figref>, there are several traces that are emphasized. The traces that include the letter “S” may be traces in which a message or control transfer is sent, traces that include the letter “R” may be traces in which a message or control transfer is received, traces that include the letter “E” may be traces in which a web message is executed, and traces that include the letter “M” may be traces in which a message is logged. A lighter trace may indicate a selected trace for which trace information is provided in frame <b>603</b>.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.