US20050216915A1 - Method of ranking messages generated in a computer system - Google Patents

Method of ranking messages generated in a computer system Download PDF

Info

Publication number
US20050216915A1
US20050216915A1 US10/896,511 US89651104A US2005216915A1 US 20050216915 A1 US20050216915 A1 US 20050216915A1 US 89651104 A US89651104 A US 89651104A US 2005216915 A1 US2005216915 A1 US 2005216915A1
Authority
US
United States
Prior art keywords
message
messages
defect
ranking
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/896,511
Inventor
Jonathan Pincus
William Softky
David Sielaff
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US10/896,511 priority Critical patent/US20050216915A1/en
Publication of US20050216915A1 publication Critical patent/US20050216915A1/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/35Clustering; Classification
    • G06F16/353Clustering; Classification into predefined classes

Definitions

  • This invention relates to the analysis of computer programs, and in particular, the reporting of messages generated by the analysis of computer programs.
  • Computer programs are typically complicated structures. Various structural and behavioral aspects of computer programs are of interest to those who design and fix them. For example, a computer engineer (or programmer) may, in a large-scale software project, desire a list of subroutines that allocate memory or are likely to call other specific functions. Further, a programmer may want to establish a list of messages regarding circumstances under which resources (e.g., memory, disk space, and modem connections) are needed, allocated or removed. In addition, a programmer may desire a list of messages regarding possible paths in which the program may or may not execute, as well as possible paths along which the program might fail or produce defective results.
  • resources e.g., memory, disk space, and modem connections
  • messages are presented in the order in which the respective errors were found.
  • messages may be presented in alphabetical order. Therefore, it is typically necessary to wade through many non-critical messages before finding a message generated in response to the detection of a critical one. As a result, a great deal of time (and expense) may be spent examining unimportant messages before actually finding a critical message.
  • Computer program compiler systems rank and report messages to a system user according to program information, warnings and errors.
  • Compiler message rankings are solely based on the severity of detected errors, which are in turn based upon warning types.
  • compilers provide no explanation for why the ranking values are assigned to their respective messages.
  • compilers provide no method of sorting specific message types in which a programmer may be particularly interested. Therefore, a method of automatically assigning rankings to program messages in order to separate important messages from less significant messages before review is desired.
  • a method of automatically assigning a ranking value to a plurality of received messages includes receiving a first message, and automatically assigning a ranking value to the first message based upon a predetermined set of criteria.
  • FIG. 1 is a diagram of one embodiment of a computer
  • FIG. 2 is a block diagram of one embodiment of a system unit
  • FIG. 3 illustrates one embodiment of a message ranking system
  • FIG. 4 a illustrates one embodiment of information stored for messages received at a message ranking system
  • FIG. 4 b illustrates one embodiment of ranking stages at a message ranking system
  • FIG. 5 is a flow diagram for one embodiment of the operation of a message ranking system.
  • FIG. 6 is a flow diagram for one embodiment of the operation of a message ranking system.
  • FIG. 1 is a diagram of one embodiment of a computer 110 .
  • Computer 110 includes a system unit 111 , a keyboard 112 , a mouse 113 and a graphics display device (or monitor) 114 .
  • Keyboard 112 and mouse 113 are user-input devices
  • display device 114 is a user output device.
  • Mouse 113 is used to control a cursor 115 displayed on the screen 116 of display device 114 .
  • the Graphic User Interface (GUI) supported by computer 110 allows the user to “point-and-shoot” by moving cursor 115 to a specific location on screen 116 and pressing a button on mouse 113 in order to perform a command or selection.
  • the GUI may be implemented as a part of the operating system of computer 110 .
  • the GUI may be a Web browser.
  • FIG. 2 is one embodiment of a block diagram of system unit 111 .
  • System unit 111 includes a system bus 221 to which the various components within system unit 111 are coupled.
  • a microprocessor 222 is connected to the system bus 221 and is supported by Read Only Memory (ROM) 223 and Random Access Memory (RAM) 224 , also connected to system bus 221 .
  • ROM 223 contains, among other code, the Basic Input/Output System (BIOS) code which controls basic hardware.
  • BIOS Basic Input/Output System
  • RAM 224 is the main memory into which an operating system and application programs are loaded.
  • a memory management chip 225 is connected to the system bus 221 and controls Direct Memory Access (DMA) operations, including paging data between RAM 224 , a hard disk drive 226 and a floppy disk drive 227 .
  • DMA Direct Memory Access
  • system unit 111 includes a keyboard controller 228 , a mouse controller 229 and a video controller 230 , all coupled to system bus 221 .
  • keyboard controller 228 provides the hardware interface for keyboard 112
  • mouse controller 229 provides the hardware interface for mouse 113
  • video controller 230 provides the hardware interface for graphic display device 114 .
  • computer 110 may include other peripherals (e.g., optical storage media, audio I/O, printers, etc.).
  • computer 110 may include a network interface module for communications with other computer systems.
  • computer system 110 may perform simulating execution of a computer program in order to detect programming errors in the computer program.
  • a component of a computer program e.g., a procedure or function of the computer program
  • a component is analyzed by traversing the computer instructions (i.e., statements) of the component and tracking the state of the resources used by the component as affected by the statements of the component.
  • simulation/error detection application is not described in further detail in order not to unnecessarily obscure the present invention. Nevertheless, the simulation and error detection application performed by computer system 110 operates according to a protocol described in U.S. Pat. No. 5,694,539 to Haley et. al. and in U.S. Pat. No. 5,790,778 to Bush et al., herein incorporated by reference.
  • FIG. 3 is a block diagram of one embodiment of a message ranking system 300 wherein computer system 110 ranks messages generated as a result of the simulation of a computer program. Messages produced by simulation are analyzed in order to sort messages based on predetermined criteria. A relevancy ranking is provided for each message using various information associated with the message.
  • the ranking system is carried out by scoring each message according to various factors. For example, each received message may be weighted according to severity, accuracy, complexity (i.e., difficulty for a user to comprehend), a user's ability to fix, etc. The weights of each message are accumulated to provide a final ranking. According to one embodiment, messages that are of greater importance are provided a lower numerical ranking than those of less importance. Alternatively, messages that are of greater importance may be provided with a higher numerical ranking than the less important messages.
  • ranking system 300 automatically ranks defect messages after completion of a simulation.
  • a system user may selectively initiate the ranking of defect messages at ranking system 300 after the simulation of a computer program.
  • ranking system 300 includes a message database 310 , an initialization module 320 , a disqualification (DQ) module 330 , a ranking (rank) module 340 and a rank sort module 350 .
  • Database 310 stores defect messages generated upon the simulating execution of a computer program.
  • Initialization module 320 initializes each defect message received in database 310 by assigning a nominal rank value. For instance, each message may be assigned a value of 100 after it has been received.
  • DQ module 330 analyzes each message in order to determine whether a particular message meets a minimum standard. If a message does meet the standard, the message is disqualified and is not presented to the user. Additionally, an explanatory message may be included indicating that a particular message has been disqualified. According to one embodiment, messages may be disqualified by assigning an elevated weight value to each message that meets the standard. However, one of ordinary skill in the art will appreciate that other methods may be used to disqualify messages. Examples of messages that may be disqualified are messages with a defect type that has a very low priority and messages whose consequences are not severe (i.e., informational messages). According to a further embodiment, DQ module 330 may be programmable to permit a user to select the type of messages that are to be disqualified.
  • Rank module 340 further analyzes the messages that were not disqualified in order to provide numerical scoring for each message based upon the various factors.
  • each message is assigned a bonus weight for each important factor that is included, and a penalty weight for each factor indicating the undesirability of the message.
  • the bonuses are subtracted from the overall ranking, while the penalties are added. The bonuses and penalties are subsequently accumulated to provide a final ranking.
  • Bonuses may be given, for example, to messages that include an especially severe defect (e.g., an invalid pointer), that involve only a few lines of statements, or that occur completely within one function. Penalties may be given for messages that are difficult to understand, messages that involve inferences, messages that involve references to multiple functions, etc. In the case where a message includes references to multiple functions, a penalty may be added for each reference to a different function. Further, a penalty may be added for each program line that was involved in the message. In addition, other bonuses and penalties may be added for other message properties that reflect the mechanism by which the message was generated.
  • an especially severe defect e.g., an invalid pointer
  • the bonuses and penalties may additionally depend on details (such as protocols, approximations, internal models, etc.) that are used and stored by the software simulation process that produced the message.
  • rank module 340 may be programmable in order to provide a user with the ability to specify the relative weights to be given to each of the various factors.
  • Rank sort module 350 performs a sort for the non-disqualified messages based upon ranking. As described above, messages with the lowest rankings are presented at the top of the list, while the lowest scores are presented at the bottom. Consequently, a user is permitted to identify the most useful messages. According to one embodiment, each message may be assigned to one of a predetermined number of message bins after sorting at rank sort module 350 . The messages are assigned to a bin based upon the rankings. In such an embodiment, a user may display the messages with a particular level of importance by selecting a specific bin.
  • FIG. 4 a illustrates one embodiment of information stored in database 310 for each message received at message ranking system 300 .
  • Messages 14 are received at database 310 after program simulation.
  • Each message may include information fields, such as: WARNING_TYPE; LINES_EXECUTED; DESCRIPTION; RANK; RANK_BIN; and WHY_DISQUALIFIED.
  • the WARNING_TYPE field indicates the type of defect that occurred while simulating a particular instruction.
  • the LINES_EXECUTED field reveals the number of program lines involved with the particular defect, while the DESCRIPTION field specifies which instruction or function caused the defect.
  • the RANK field shows the current rank of the defect message after being analyzed at rank module 340 , and the RANK_BIN field designates which bin the message has been placed.
  • the WHY_DISQUALIFIED indicates the reason a message has been disqualified at DQ module 330 .
  • FIG. 4 b illustrates one embodiment of ranking stages at message ranking system 300 .
  • all defect messages received at database 310 are initialized to a nominal value.
  • messages 1 - 4 are initially set to a value of 100.
  • each message is analyzed by DQ module 430 .
  • a message may be disqualified if it contains so many nested levels of indexing that it is effectively unintelligible. Consequently, a command may be executed at DQ module 330 that analyzes the execution field of each message in order to determine if there is a message that contains excessive nesting. Any messages that meet the criteria of the command are disqualified by setting their RANK fields to a very high number (e.g., 400). Referring to FIG. 4 a , the DESCRIPTION field of message 1 includes “tempMem[x+y[2+z[ii]]]” which includes nested levels of indexing. Therefore, message 1 is disqualified by setting it to a value of 400 as shown in FIG. 4 b . The WHY_DISQUALIFIED field is updated to indicate that message 1 was disqualified due to too much nesting.
  • the remaining non-disqualified messages are analyzed at rank module 340 to determine whether they meet various criteria. For example, a bonus value of ⁇ 50 may be added to the RANK field of a message if the WARNING_TYPE field indicates that the defect was caused by an invalid pointer. This low bonus value is assigned to invalid pointers because they are especially severe program defects that are capable of causing immediate program failure. Also, a complexity penalty value of 10 may be added for each program line involved in the defect. Given that message 2 includes an invalid pointer defect, a bonus of ⁇ 50 is added. However, since the LINES_EXECUTED FIELD includes a 3, a penalty of 30 is added. Accordingly, the RANK field for message 2 is set at 80. Penalties of 40 and 90 are added to messages 3 and 4 , respectively due to the contents of the LINES_EXECUTED FIELD for each. Consequently, the rank of message 3 is 140 and the rank of message 4 is 190.
  • the messages are sorted and grouped into categories at sort module 350 .
  • the messages may be grouped into three categories (or bins). For messages that have a rank greater than 0 and less than 100, the RANK_BIN field is set to 1. In addition, for messages that have a rank greater than 100 and less than 200, the RANK_BIN field is set to 2. Further, for messages the have a rank greater than 200, the RANK_BIN field is set to 3. Therefore, message 1 is placed into bin 3 , message 2 is placed into bin 1 , and messages 3 and 4 are placed into bin 2 .
  • a user may display the messages in ascending order by rank. Alternatively, the user may display only the messages in a particular bin. Consequently, the user is able to focus on the most severe and intelligible messages first.
  • FIG. 5 is a flow diagram for one embodiment of the operation of message ranking system 300 .
  • messages are received at database 310 after a program simulation.
  • the RANK field of the first defect message is set to an initial value.
  • the first message is analyzed in order to determine whether it should be disqualified. If it is determined that the message should be disqualified, the RANK field of the message is set to a high value in process block 530 . After setting the RANK field of the message to a high value, or if it is determined that the message should not be disqualified, it is determined in process block 535 whether there are messages remaining that must be examined for disqualification. If there are further messages to be initialized, control is returned to process block 525 where a subsequent defect message is analyzed to determine whether it should be disqualified. If there are no further messages to analyze, the disqualification process has been completed.
  • the first defect message is scored with a bonus/penalty system similar to that described above. Consequently, the RANK field of the message is set to its final rank.
  • the first defect message is placed into the proper bin corresponding to its final rank value.
  • FIG. 6 is a flow diagram for another embodiment of the operation of message ranking system 300 wherein each message is processed all at once.
  • defect messages are received at database 310 after a program simulation.
  • the RANK field of a message is set to an initial value.
  • the same message is analyzed in order to determine whether it should be disqualified.
  • the defect message is scored with a bonus/penalty system in process block 630 . Consequently, the RANK field of the message is set to its final rank.
  • the defect message is grouped into the proper bin corresponding to its final rank value.
  • the RANK field of the message is set to a high value, process block 625 . Subsequently, it is determined whether there are messages remaining to be processed by message ranking system 300 , process block 640 . If there are further messages to be processed, control is returned to process block 615 where a subsequent defect message is initialized. If there are no further messages, the ranking operation has been completed.

Abstract

According to one embodiment, a method of automatically assigning a ranking value to a plurality of received messages is disclosed. Each of the received messages provides information about a computer program. The method includes receiving a first message, storing the first message in the database and initializing the first message. Further, it is determined whether the first message is to be disqualified. If it is determined that the first message is to be disqualified, the first message is disqualified. If it is determined that the first message is not to be disqualified, a ranking value is automatically assigning to the first message based upon a predetermined set of criteria.

Description

    FIELD OF THE INVENTION
  • This invention relates to the analysis of computer programs, and in particular, the reporting of messages generated by the analysis of computer programs.
  • BACKGROUND
  • Computer programs are typically complicated structures. Various structural and behavioral aspects of computer programs are of interest to those who design and fix them. For example, a computer engineer (or programmer) may, in a large-scale software project, desire a list of subroutines that allocate memory or are likely to call other specific functions. Further, a programmer may want to establish a list of messages regarding circumstances under which resources (e.g., memory, disk space, and modem connections) are needed, allocated or removed. In addition, a programmer may desire a list of messages regarding possible paths in which the program may or may not execute, as well as possible paths along which the program might fail or produce defective results.
  • One method of generating the messages described above is to manually produce them. However, this method is often times impractical since it may be very tedious and time consuming. Instead, various automated methods for producing list of messages have been developed. Applications in which messages are automatically generated include, for example, various computer program compilers (e.g., Native DEC and GNU C++ compilers) and software component simulation technology (e.g., PREfix/Enterprise developed by Intrinsa Corporation of Mountain View, Calif.). The automated methods for producing lists of messages, however, offer no effective method of distinguishing between messages that relate to issues that are of more importance to a programmer, without having to examine a vast majority of the generated messages. For instance, some of the generated messages may be of more importance, depending upon the content of the messages, the likelihood of the message being accurate, the ease with which the message can be understood, as well as other factors.
  • In typical message generation applications, messages are presented in the order in which the respective errors were found. Alternatively, messages may be presented in alphabetical order. Therefore, it is typically necessary to wade through many non-critical messages before finding a message generated in response to the detection of a critical one. As a result, a great deal of time (and expense) may be spent examining unimportant messages before actually finding a critical message.
  • Computer program compiler systems rank and report messages to a system user according to program information, warnings and errors. Compiler message rankings, however, are solely based on the severity of detected errors, which are in turn based upon warning types. In addition, compilers provide no explanation for why the ranking values are assigned to their respective messages. Moreover, compilers provide no method of sorting specific message types in which a programmer may be particularly interested. Therefore, a method of automatically assigning rankings to program messages in order to separate important messages from less significant messages before review is desired.
  • SUMMARY OF THE INVENTION
  • According to one embodiment, a method of automatically assigning a ranking value to a plurality of received messages is disclosed. Each of the received messages provides information about a computer program. The method includes receiving a first message, and automatically assigning a ranking value to the first message based upon a predetermined set of criteria.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention. The drawings, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
  • FIG. 1 is a diagram of one embodiment of a computer;
  • FIG. 2 is a block diagram of one embodiment of a system unit;
  • FIG. 3 illustrates one embodiment of a message ranking system;
  • FIG. 4 a illustrates one embodiment of information stored for messages received at a message ranking system;
  • FIG. 4 b illustrates one embodiment of ranking stages at a message ranking system;
  • FIG. 5 is a flow diagram for one embodiment of the operation of a message ranking system; and
  • FIG. 6 is a flow diagram for one embodiment of the operation of a message ranking system.
  • DETAILED DESCRIPTION
  • FIG. 1 is a diagram of one embodiment of a computer 110. Computer 110 includes a system unit 111, a keyboard 112, a mouse 113 and a graphics display device (or monitor) 114. Keyboard 112 and mouse 113 are user-input devices, and display device 114 is a user output device. Mouse 113 is used to control a cursor 115 displayed on the screen 116 of display device 114. The Graphic User Interface (GUI) supported by computer 110 allows the user to “point-and-shoot” by moving cursor 115 to a specific location on screen 116 and pressing a button on mouse 113 in order to perform a command or selection. According to one embodiment, the GUI may be implemented as a part of the operating system of computer 110. However, in other embodiments, the GUI may be a Web browser.
  • FIG. 2 is one embodiment of a block diagram of system unit 111. System unit 111 includes a system bus 221 to which the various components within system unit 111 are coupled. A microprocessor 222 is connected to the system bus 221 and is supported by Read Only Memory (ROM) 223 and Random Access Memory (RAM) 224, also connected to system bus 221. ROM 223 contains, among other code, the Basic Input/Output System (BIOS) code which controls basic hardware. RAM 224 is the main memory into which an operating system and application programs are loaded. A memory management chip 225 is connected to the system bus 221 and controls Direct Memory Access (DMA) operations, including paging data between RAM 224, a hard disk drive 226 and a floppy disk drive 227.
  • Further, system unit 111 includes a keyboard controller 228, a mouse controller 229 and a video controller 230, all coupled to system bus 221. As implied, keyboard controller 228 provides the hardware interface for keyboard 112, mouse controller 229 provides the hardware interface for mouse 113, and video controller 230 provides the hardware interface for graphic display device 114. One of ordinary skill in the art will appreciate that computer 110 may include other peripherals (e.g., optical storage media, audio I/O, printers, etc.). In addition, computer 110 may include a network interface module for communications with other computer systems.
  • According to one embodiment, computer system 110 may perform simulating execution of a computer program in order to detect programming errors in the computer program. In such an application, a component of a computer program (e.g., a procedure or function of the computer program) is analyzed to determine the effect of the component on resources used by the computer program. A component is analyzed by traversing the computer instructions (i.e., statements) of the component and tracking the state of the resources used by the component as affected by the statements of the component.
  • The simulation/error detection application is not described in further detail in order not to unnecessarily obscure the present invention. Nevertheless, the simulation and error detection application performed by computer system 110 operates according to a protocol described in U.S. Pat. No. 5,694,539 to Haley et. al. and in U.S. Pat. No. 5,790,778 to Bush et al., herein incorporated by reference.
  • After the simulation of a computer program, computer system 110 may also be configured to rank the resulting messages generated as a result of the simulation. FIG. 3 is a block diagram of one embodiment of a message ranking system 300 wherein computer system 110 ranks messages generated as a result of the simulation of a computer program. Messages produced by simulation are analyzed in order to sort messages based on predetermined criteria. A relevancy ranking is provided for each message using various information associated with the message.
  • The ranking system is carried out by scoring each message according to various factors. For example, each received message may be weighted according to severity, accuracy, complexity (i.e., difficulty for a user to comprehend), a user's ability to fix, etc. The weights of each message are accumulated to provide a final ranking. According to one embodiment, messages that are of greater importance are provided a lower numerical ranking than those of less importance. Alternatively, messages that are of greater importance may be provided with a higher numerical ranking than the less important messages.
  • According to one embodiment, ranking system 300 automatically ranks defect messages after completion of a simulation. In other embodiments, a system user may selectively initiate the ranking of defect messages at ranking system 300 after the simulation of a computer program. Referring to FIG. 3, ranking system 300 includes a message database 310, an initialization module 320, a disqualification (DQ) module 330, a ranking (rank) module 340 and a rank sort module 350. Database 310 stores defect messages generated upon the simulating execution of a computer program. Initialization module 320 initializes each defect message received in database 310 by assigning a nominal rank value. For instance, each message may be assigned a value of 100 after it has been received.
  • DQ module 330 analyzes each message in order to determine whether a particular message meets a minimum standard. If a message does meet the standard, the message is disqualified and is not presented to the user. Additionally, an explanatory message may be included indicating that a particular message has been disqualified. According to one embodiment, messages may be disqualified by assigning an elevated weight value to each message that meets the standard. However, one of ordinary skill in the art will appreciate that other methods may be used to disqualify messages. Examples of messages that may be disqualified are messages with a defect type that has a very low priority and messages whose consequences are not severe (i.e., informational messages). According to a further embodiment, DQ module 330 may be programmable to permit a user to select the type of messages that are to be disqualified.
  • Rank module 340 further analyzes the messages that were not disqualified in order to provide numerical scoring for each message based upon the various factors. According to one embodiment, each message is assigned a bonus weight for each important factor that is included, and a penalty weight for each factor indicating the undesirability of the message. In this embodiment, the bonuses are subtracted from the overall ranking, while the penalties are added. The bonuses and penalties are subsequently accumulated to provide a final ranking.
  • Bonuses may be given, for example, to messages that include an especially severe defect (e.g., an invalid pointer), that involve only a few lines of statements, or that occur completely within one function. Penalties may be given for messages that are difficult to understand, messages that involve inferences, messages that involve references to multiple functions, etc. In the case where a message includes references to multiple functions, a penalty may be added for each reference to a different function. Further, a penalty may be added for each program line that was involved in the message. In addition, other bonuses and penalties may be added for other message properties that reflect the mechanism by which the message was generated. For instance, the bonuses and penalties may additionally depend on details (such as protocols, approximations, internal models, etc.) that are used and stored by the software simulation process that produced the message. According to one embodiment, rank module 340 may be programmable in order to provide a user with the ability to specify the relative weights to be given to each of the various factors.
  • Rank sort module 350 performs a sort for the non-disqualified messages based upon ranking. As described above, messages with the lowest rankings are presented at the top of the list, while the lowest scores are presented at the bottom. Consequently, a user is permitted to identify the most useful messages. According to one embodiment, each message may be assigned to one of a predetermined number of message bins after sorting at rank sort module 350. The messages are assigned to a bin based upon the rankings. In such an embodiment, a user may display the messages with a particular level of importance by selecting a specific bin.
  • FIG. 4 a illustrates one embodiment of information stored in database 310 for each message received at message ranking system 300. Messages 14 are received at database 310 after program simulation. Each message may include information fields, such as: WARNING_TYPE; LINES_EXECUTED; DESCRIPTION; RANK; RANK_BIN; and WHY_DISQUALIFIED. The WARNING_TYPE field indicates the type of defect that occurred while simulating a particular instruction. The LINES_EXECUTED field reveals the number of program lines involved with the particular defect, while the DESCRIPTION field specifies which instruction or function caused the defect. The RANK field shows the current rank of the defect message after being analyzed at rank module 340, and the RANK_BIN field designates which bin the message has been placed. The WHY_DISQUALIFIED, if applicable, indicates the reason a message has been disqualified at DQ module 330.
  • Before any of the modules of message ranking system 300 have been executed, the RANK field for all of the messages shows a zero. FIG. 4 b illustrates one embodiment of ranking stages at message ranking system 300. As discussed above, all defect messages received at database 310 are initialized to a nominal value. In this particular embodiment, messages 1-4 are initially set to a value of 100. Subsequently, each message is analyzed by DQ module 430.
  • According to one embodiment, a message may be disqualified if it contains so many nested levels of indexing that it is effectively unintelligible. Consequently, a command may be executed at DQ module 330 that analyzes the execution field of each message in order to determine if there is a message that contains excessive nesting. Any messages that meet the criteria of the command are disqualified by setting their RANK fields to a very high number (e.g., 400). Referring to FIG. 4 a, the DESCRIPTION field of message 1 includes “tempMem[x+y[2+z[ii]]]” which includes nested levels of indexing. Therefore, message 1 is disqualified by setting it to a value of 400 as shown in FIG. 4 b. The WHY_DISQUALIFIED field is updated to indicate that message 1 was disqualified due to too much nesting.
  • The remaining non-disqualified messages are analyzed at rank module 340 to determine whether they meet various criteria. For example, a bonus value of −50 may be added to the RANK field of a message if the WARNING_TYPE field indicates that the defect was caused by an invalid pointer. This low bonus value is assigned to invalid pointers because they are especially severe program defects that are capable of causing immediate program failure. Also, a complexity penalty value of 10 may be added for each program line involved in the defect. Given that message 2 includes an invalid pointer defect, a bonus of −50 is added. However, since the LINES_EXECUTED FIELD includes a 3, a penalty of 30 is added. Accordingly, the RANK field for message 2 is set at 80. Penalties of 40 and 90 are added to messages 3 and 4, respectively due to the contents of the LINES_EXECUTED FIELD for each. Consequently, the rank of message 3 is 140 and the rank of message 4 is 190.
  • Finally, the messages are sorted and grouped into categories at sort module 350. According to one embodiment, the messages may be grouped into three categories (or bins). For messages that have a rank greater than 0 and less than 100, the RANK_BIN field is set to 1. In addition, for messages that have a rank greater than 100 and less than 200, the RANK_BIN field is set to 2. Further, for messages the have a rank greater than 200, the RANK_BIN field is set to 3. Therefore, message 1 is placed into bin 3, message 2 is placed into bin 1, and messages 3 and 4 are placed into bin 2. Once the RANK and RANK_BIN values have been set, a user may display the messages in ascending order by rank. Alternatively, the user may display only the messages in a particular bin. Consequently, the user is able to focus on the most severe and intelligible messages first.
  • One of ordinary skill in the art will appreciate that all of the modules described above are not necessary to implement ranking system 300. For example, it is not necessary to disqualify any of the defect messages prior to ranking process executed at rank module 340, nor is it necessary to initialize all of the messages to a preset value as is executed at initiation module 320.
  • FIG. 5 is a flow diagram for one embodiment of the operation of message ranking system 300. At process block 510 messages are received at database 310 after a program simulation. At process block 515, the RANK field of the first defect message is set to an initial value. At process block 520, it is determined whether there are messages remaining that must be initialized. If there are further messages to be initialized, control is returned to process block 515 where the rank of a subsequent defect message is initialized. If there are no further messages to be initialized, the initialization process has been completed
  • At process block 525, the first message is analyzed in order to determine whether it should be disqualified. If it is determined that the message should be disqualified, the RANK field of the message is set to a high value in process block 530. After setting the RANK field of the message to a high value, or if it is determined that the message should not be disqualified, it is determined in process block 535 whether there are messages remaining that must be examined for disqualification. If there are further messages to be initialized, control is returned to process block 525 where a subsequent defect message is analyzed to determine whether it should be disqualified. If there are no further messages to analyze, the disqualification process has been completed.
  • At process block 540, the first defect message is scored with a bonus/penalty system similar to that described above. Consequently, the RANK field of the message is set to its final rank. At process block 545, it is determined whether there are messages remaining that must be scored. If there are further messages to be scored, control is returned to process block 540 where a subsequent defect message is scored. If there are no further messages to be scored, the ranking process has been completed.
  • At process block 550, the first defect message is placed into the proper bin corresponding to its final rank value. At process block 555, it is determined whether there are messages remaining to be placed in a bin. If there are further messages to be placed, control is returned to process block 550 where a subsequent message is placed in the proper bin. If there are no further messages, message ranking system 300 has completed the ranking operation.
  • FIG. 6 is a flow diagram for another embodiment of the operation of message ranking system 300 wherein each message is processed all at once. At process block 610 defect messages are received at database 310 after a program simulation. At process block 615, the RANK field of a message is set to an initial value. At process block 620, the same message is analyzed in order to determine whether it should be disqualified.
  • If it is determined that the message should not be disqualified, the defect message is scored with a bonus/penalty system in process block 630. Consequently, the RANK field of the message is set to its final rank. At process block 635, the defect message is grouped into the proper bin corresponding to its final rank value. At process block 640, it is determined whether there are messages remaining to be processed by message ranking system 300. If there are further messages to be processed, control is returned to process block 615 where a subsequent message is initialized. If there are no further messages, message ranking system 300 has completed the ranking operation.
  • If it is determined that the message should be disqualified, the RANK field of the message is set to a high value, process block 625. Subsequently, it is determined whether there are messages remaining to be processed by message ranking system 300, process block 640. If there are further messages to be processed, control is returned to process block 615 where a subsequent defect message is initialized. If there are no further messages, the ranking operation has been completed.
  • Thus, a method of automatically assigning rankings to program messages in order to separate important messages from less significant messages before review has been described.

Claims (19)

1. (canceled)
45. A method of reporting defect messages, comprising:
receiving a plurality of defect messages providing information about a computer program;
automatically ranking the defect messages according to a set of criteria including the number of program lines involved to generate the defect message.
46. The method of claim 45, wherein the set of criteria includes whether the defect message includes an invalid pointer.
47. The method of claim 45, wherein the set of criteria includes whether the defect message involves an inference.
48. The method of claim 45, wherein the set of criteria includes whether the defect message refers to multiple functions.
49. The method of claim 45, further comprising storing a first message of the plurality of defect messages in a database after the first message has been received.
50. The method of claim 49, further comprising initializing the first message after it has been stored in the database.
51. The method of claim 50, wherein the process of initializing comprises assigning an initial value to the first message.
52. An apparatus comprising:
a ranking module for automatically ranking defect messages providing information about a computer program according to a set of criteria including whether a defect message refers to multiple functions.
53. The apparatus of claim 52, wherein the set of criteria includes whether the defect message includes an invalid pointer.
54. The apparatus of claim 52, wherein the set of criteria includes the number of program lines included in the defect message.
55. The apparatus of claim 52, wherein the set of criteria includes whether a defect message involves an inference.
56. The apparatus of claim 52, further comprising a sort module coupled to the ranking module, wherein the sort module sorts the defect messages according to a rank value assigned at the ranking module.
57. The apparatus of claim 52, further comprising a disqualification module coupled to the ranking module for disqualifying at least one of the defect messages.
58. The apparatus of claim 52, further comprising:
a database for archiving the defect messages; and
an initialization module coupled to the database for initializing the defect messages received at the database.
59. The apparatus of claim 56, wherein the defect messages are grouped into one of a plurality of bins according to the rank value assigned at the ranking module.
60. The apparatus of claim 57, wherein the defect messages are displayed on a graphical user interface (GUI) according to the rank value assigned at the ranking module.
61. The apparatus of claim 60, wherein the defect messages disqualified at the disqualification module are not displayed on the GUI.
62. The apparatus of claim 56, wherein an explanation is provided for the rank value of each defect message ranked at the ranking module.
US10/896,511 1999-04-05 2004-07-19 Method of ranking messages generated in a computer system Abandoned US20050216915A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/896,511 US20050216915A1 (en) 1999-04-05 2004-07-19 Method of ranking messages generated in a computer system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/286,500 US6782530B1 (en) 1999-04-05 1999-04-05 Method of ranking messages generated in a computer system
US10/896,511 US20050216915A1 (en) 1999-04-05 2004-07-19 Method of ranking messages generated in a computer system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/286,500 Continuation US6782530B1 (en) 1999-04-05 1999-04-05 Method of ranking messages generated in a computer system

Publications (1)

Publication Number Publication Date
US20050216915A1 true US20050216915A1 (en) 2005-09-29

Family

ID=32867850

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/286,500 Expired - Lifetime US6782530B1 (en) 1999-04-05 1999-04-05 Method of ranking messages generated in a computer system
US10/896,511 Abandoned US20050216915A1 (en) 1999-04-05 2004-07-19 Method of ranking messages generated in a computer system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/286,500 Expired - Lifetime US6782530B1 (en) 1999-04-05 1999-04-05 Method of ranking messages generated in a computer system

Country Status (1)

Country Link
US (2) US6782530B1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010085620A2 (en) * 2009-01-23 2010-07-29 The University Of Memphis Research Foundation Methods and systems for automatic clustering of defect reports

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10924933B2 (en) * 2018-08-23 2021-02-16 Motorola Solutions, Inc. System and method for monitoring the integrity of a virtual assistant

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4620276A (en) * 1983-06-02 1986-10-28 International Business Machines Corporation Method and apparatus for asynchronous processing of dynamic replication messages
US5428781A (en) * 1989-10-10 1995-06-27 International Business Machines Corp. Distributed mechanism for the fast scheduling of shared objects and apparatus
US5694539A (en) * 1994-08-10 1997-12-02 Intrinsa Corporation Computer process resource modelling method and apparatus
US5790778A (en) * 1996-08-07 1998-08-04 Intrinsa Corporation Simulated program execution error detection method and apparatus
US5864700A (en) * 1996-06-12 1999-01-26 International Business Machines Corporation Sequencing and error detection of template instantiations during compilation of C++ Programs
US5872966A (en) * 1996-05-10 1999-02-16 Apple Computer, Inc. System and method for logging and enabling further manipulation of system state information
US5940335A (en) * 1997-03-31 1999-08-17 International Business Machines Corporation Prioritizing the repair of faults in a semiconductor memory device
US6122672A (en) * 1996-12-16 2000-09-19 Samsung Electronics Co., Ltd. Method for sending messages among a group of subsets forming a network
US6173440B1 (en) * 1998-05-27 2001-01-09 Mcdonnell Douglas Corporation Method and apparatus for debugging, verifying and validating computer software
US6182243B1 (en) * 1992-09-11 2001-01-30 International Business Machines Corporation Selective data capture for software exception conditions
US6219827B1 (en) * 1998-03-12 2001-04-17 Hewlett-Packard Company Trace ranking in a dynamic translation system
US6282701B1 (en) * 1997-07-31 2001-08-28 Mutek Solutions, Ltd. System and method for monitoring and analyzing the execution of computer programs
US6393490B1 (en) * 1997-12-18 2002-05-21 Ian James Stiles Method and system for a programmatic feedback process for end-user support

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6053864A (en) * 1996-03-29 2000-04-25 Clawson; Jeffrey J. Method and system for giving remote emergency medical counsel to arrest patients
US6106459A (en) * 1996-03-29 2000-08-22 Clawson; Jeffrey J. Method and system for the entry protocol of an emergency medical dispatch system
US5989187A (en) * 1996-03-29 1999-11-23 Medical Priority Consultants, Inc. Method and system for giving remote emergency medical counseling for childbirth patients
US6010451A (en) * 1996-03-29 2000-01-04 Clawson; Jeffrey J. Method and system for giving remote emergency medical counsel to choking patients
US6004266A (en) * 1996-03-29 1999-12-21 Clawson; Jeffrey J. Method and system for the heart problem protocol of an emergency medical dispatch system
US5857966A (en) * 1996-03-29 1999-01-12 Clawson; Jeffrey J. Method and system for the unconscious or fainting protocol of an emergency medical dispatch system
US6076065A (en) * 1997-03-28 2000-06-13 Clawson; Jeffrey J. Method and system for the pregnancy condition protocol of an emergency medical dispatch system
US6078894A (en) * 1997-03-28 2000-06-20 Clawson; Jeffrey J. Method and system for evaluating the performance of emergency medical dispatchers
US6256664B1 (en) * 1998-09-01 2001-07-03 Bigfix, Inc. Method and apparatus for computed relevance messaging
US6327364B1 (en) * 1998-12-15 2001-12-04 Siemens Information And Communication Networks, Inc. Reducing resource consumption by ACD systems

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4620276A (en) * 1983-06-02 1986-10-28 International Business Machines Corporation Method and apparatus for asynchronous processing of dynamic replication messages
US5428781A (en) * 1989-10-10 1995-06-27 International Business Machines Corp. Distributed mechanism for the fast scheduling of shared objects and apparatus
US6182243B1 (en) * 1992-09-11 2001-01-30 International Business Machines Corporation Selective data capture for software exception conditions
US5694539A (en) * 1994-08-10 1997-12-02 Intrinsa Corporation Computer process resource modelling method and apparatus
US5872966A (en) * 1996-05-10 1999-02-16 Apple Computer, Inc. System and method for logging and enabling further manipulation of system state information
US5864700A (en) * 1996-06-12 1999-01-26 International Business Machines Corporation Sequencing and error detection of template instantiations during compilation of C++ Programs
US5790778A (en) * 1996-08-07 1998-08-04 Intrinsa Corporation Simulated program execution error detection method and apparatus
US6122672A (en) * 1996-12-16 2000-09-19 Samsung Electronics Co., Ltd. Method for sending messages among a group of subsets forming a network
US5940335A (en) * 1997-03-31 1999-08-17 International Business Machines Corporation Prioritizing the repair of faults in a semiconductor memory device
US6282701B1 (en) * 1997-07-31 2001-08-28 Mutek Solutions, Ltd. System and method for monitoring and analyzing the execution of computer programs
US6393490B1 (en) * 1997-12-18 2002-05-21 Ian James Stiles Method and system for a programmatic feedback process for end-user support
US6219827B1 (en) * 1998-03-12 2001-04-17 Hewlett-Packard Company Trace ranking in a dynamic translation system
US6173440B1 (en) * 1998-05-27 2001-01-09 Mcdonnell Douglas Corporation Method and apparatus for debugging, verifying and validating computer software

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010085620A2 (en) * 2009-01-23 2010-07-29 The University Of Memphis Research Foundation Methods and systems for automatic clustering of defect reports
US20100191731A1 (en) * 2009-01-23 2010-07-29 Vasile Rus Methods and systems for automatic clustering of defect reports
WO2010085620A3 (en) * 2009-01-23 2010-11-04 The University Of Memphis Research Foundation Methods and systems for automatic clustering of defect reports

Also Published As

Publication number Publication date
US6782530B1 (en) 2004-08-24

Similar Documents

Publication Publication Date Title
US7536294B1 (en) Method and apparatus for translating computer programs
US6209125B1 (en) Method and apparatus for software component analysis
US7870540B2 (en) Dynamic object validation
US7316000B2 (en) Interactive agent for a topological multi-tier business application composer
US6502233B1 (en) Automated help system for reference information
US7685260B2 (en) Method for analyzing state transition in web page
US7562344B1 (en) Method, system, and computer program product for providing real-time developer feedback in an integrated development environment
US20050076024A1 (en) System, method and program for database searching
US20010049697A1 (en) System and method for retrieving software release information
US5852564A (en) Method and apparatus for interactively displaying signal information during computer simulation of an electrical circuit
EP0536077A2 (en) Method for enhancing interactive query of a database
US7620888B2 (en) Quality enhancement systems and methods for technical documentation
JP2001521249A (en) Software system and method for extending classification and attributes in production analysis
JPH02130663A (en) User's interface
JP2009181536A (en) Software fault management device, test management device and program therefor
US5838949A (en) System and method for execution-sequenced processing of electronic design simulation results
US7035752B2 (en) Semiconductor test data analysis system
JPH09204300A (en) Packaged algorithm for object oriented application
US6938219B2 (en) Method and system for displaying actions and historical content in an output view
US6782530B1 (en) Method of ranking messages generated in a computer system
US6345270B1 (en) Data management system
JP2017049639A (en) Evaluation program, procedure manual evaluation method, and evaluation device
JP7246301B2 (en) Program development support system and program development support method
EP1073976A1 (en) Method and apparatus for alerting user-processing sites as to the availability of informaton
Lipworth et al. WITS-HEX: A renovated code for analysis of PIXE X-ray spectra

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001

Effective date: 20141014