WO2009146979A1

WO2009146979A1 - Method system and computer program for identifying software problems

Info

Publication number: WO2009146979A1
Application number: PCT/EP2009/054928
Authority: WO
Inventors: Maurizio Simeoni
Original assignee: International Business Machines Corporation; Compagnie Ibm France
Priority date: 2008-06-05
Filing date: 2009-04-24
Publication date: 2009-12-10
Also published as: EP2286338B1; US8099628B2; JP2011522334A; KR20110025171A; EP2286338A1; JP5400873B2; US20090307668A1

Abstract

The preferred embodiment provides a mechanism for accelerating the processes of isolating a software problem, detecting the nature of the problem and resolving it, by isolating the software components involved in the usage scenario wherein the problem occurred. The preferred embodiment then tests the software components by: automatically executing a reference usage scenario within the infrastructure of the faulty software application; and comparing the results of the usage scenario wherein the problem occurred, with expected results from the reference scenario. The preferred embodiment may be used at the end of an installation process to check if the product or patch has been successfully installed by defining a usage scenario descriptor for the installation process. The preferred embodiment may also be used for usage scenario test progression. In particular, the preferred embodiment can allow a user to prepare a usage scenario descriptor for each regression scenario before applying a patch in a production environment. Furthermore, the preferred embodiment can automatically run the usage scenario discovery process in the test environment and cause the comparator to verify the result therefrom.

Description

METHOD, SYSTEM AND COMPUTER PROGRAM FOR IDENTIFYING

SOFTWARE PROBLEMS

Technical Field

The present invention relates to a method, system and computer program for identifying a software problem.

Background

To detect and resolve a software problem, it is typically necessary to identify and isolate the software components involved in the scenario wherein the software problem has occurred. For simplicity, these scenarios will be known henceforth as "usage scenarios" . More particularly, the process of troubleshooting the software problem requires the collection and analysis of the runtime dependencies and configurations of the identified software components. However, this process can be extremely costly and time-consuming (e.g. often taking several days and requiring the involvement of a customer-support facility) .

The IBM Tivoli Application Dependency Discovery Manager (TADDM) is a software tool which provides a mechanism for discovering and analysing the runtime dependencies and configurations of multi-tiered software applications. In particular, the TADDM provides snapshots of the current infrastructure of a software application in the form of read-only views of the entire topology of the application. The TADDM further comprises an analytic reporting tool which enables comparisons to be made between different snapshots of the software application under study. However, the TADDM does not allow the isolation of software components involved in a particular usage scenario of a software application. Similarly, the TADDM is not automatically executed and does not allow a scenario to be compared against a snapshot taken in a reference environment. Summary of the invention

According to the invention there is provided a method of identifying problems in a software application in a computer system, the method comprising the steps of: allowing a user to define a one or more usage scenarios of the software application; executing, in a reference computer system, the software application with one or more of the usage scenarios; acquiring data concerning a status of a one or more of the reference computer system and the software application therein, during the execution of the software application with the one or more of the usage scenarios; executing, in the computer system under study, the software application with the same one or more usage scenarios executed in the reference computer system; acquiring data concerning a status of a one or more of the computer systems under study and the software application therein, during the execution of the software application with the one or more of the usage scenarios; comparing the data from the reference computer system and the computer system under study, to identify the one or more differences therebetween.

The preferred embodiment provides a system and method for discovering and analysing the runtime dependency configurations on multi-tiered applications. In particular, the method and system of the preferred embodiment enables snapshots of the current infrastructure of a software system to be taken and compared against snapshots of a reference software system, to enable the specific software components involved in a problem fault in the current infrastructure, to be identified and detected.

The method of the preferred embodiment may be used at the end of an installation process to check if the product or patch has been successfully installed by defining a usage scenario descriptor for the installation process. The method of the preferred embodiment may also be used for usage scenario test progression. In particular, the method of the preferred embodiment can allow a user to prepare a usage scenario descriptor for each regression scenario before applying a patch in a production environment. Furthermore, the method of the preferred embodiment can automatically run the usage scenario discovery process in the test environment and cause the comparator to verify the result therefrom.

Brief description of the drawings

An embodiment of the invention is herein described by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a block diagram of the architecture of the system of the preferred embodiment;

Figure 2 comprises an XML file representing a usage scenario descriptor;

Figure 3 is a flowchart of the method of the preferred embodiment; and

Figure 4 is a block diagram of a computer system adapted to perform the method of the preferred embodiment.

Detailed description of the invention

1. Overview

The preferred embodiment provides a mechanism for accelerating the processes of: - isolating a software problem;

- detecting the nature of the problem; and

- resolving it.

The preferred embodiment achieves this, by isolating the software components involved in the software system in which the problem occurred. To this end, the preferred embodiment :-

- automatically executes a predefined usage scenario within the infrastructure of the faulty software application; and - compares the results of this process, with the results of executing the predefined usage scenario in a reference software system.

The predefined usage scenario can be a "reference usage scenario" or "real-world usage scenario". A reference usage scenario is a typical usage scenario of the product and is provided by the software manufacturer. A real-world usage scenario is a specific usage scenario implemented by a user for specific purpose. The choice of which usage scenario the user employs, is largely dependent on how the user uses the software system under study.

2. Detailed Description

Referring to Figure 1, the system 10 of the preferred embodiment comprises a usage scenario descriptor 12 and a usage scenario snapshot (not shown) being transmitted between a discovery engine manager 14 and a primary repository 16. The primary repository 16 is further accessed by a usage scenario viewer 18 and a usage scenario comparator 20.

In the present example, the usage scenario descriptor 12 is a file which describes a potential usage scenario and the software components involved in that usage scenario. The usage scenario can be a "reference usage scenario" or "real-world usage scenario". A reference usage scenario is a typical usage scenario of the product and is provided by the software manufacturer. A real-world usage scenario is a specific usage scenario implemented by a user for specific purpose. In the present example, the usage scenario descriptor 12 is provided in XML. However, the skilled person will understand that the usage scenario descriptor 12 could also be written in any other suitable language. Referring to Figure 2, the usage scenario descriptor 12 identifies a particular usage scenario by a scenario ID 22. The usage scenario descriptor 12 also identifies a software application, by an application ID 24. The software application and application components therein, are further detailed by a description tag 26 and a sequence of component elements 28. The sequence of components elements 28 contain the name of the component, details of the computer where it is installed (e.g. hostname, protocol (e.g. ssh) and password needed to remotely execute the component) . The usage scenario descriptor 12 further comprises a runtime section 30 which describes a set of actions to be performed on the components of the application under study. The actions include, for example, sending requests to components, receiving responses therefrom, collating the responses to form a snapshot (e.g. logs, application status, system information, registry information etc.) of the application under study. In the present example, the runtime section 30 is expressed in a script-like language. However, it will be appreciated that the runtime section could also be expressed in other languages. It will be appreciated that the above-mentioned formulation of the usage scenario descriptor 12 is provided for example purposes only, and should not be construed as meaning that the usage scenario descriptor 12 is limited in any way to this particular formulation. In particular, the usage scenario descriptor 12 may use other tagging and descriptor mechanisms to identify and refer to the usage scenario in question and the components of the software application in which the problem occurred.

The discovery engine manager 14 performs usage scenario discovery, namely, executing the scenario described in the runtime section 30 of the usage scenario descriptor 12, using the components listed in the components elements 28 section of the usage scenario descriptor 12. During this process, a usage scenario snapshot is taken of the computer system under study. For simplicity, the term "snapshot" will be understood to mean data pertaining to the status of a computer system.

The discovery engine manager 14 stores both the usage scenario descriptors 12 and the usage scenario snapshots in the primary repository 16.

The preferred embodiment also executes the same usage scenario on a reference computer system. The reference computer system is a computer system where the product is installed and where it is working as designed. It can be a test computer system, (i.e. a computer system used by the customer to verify a product before installing it in a production computer) , or the manufacturer' s computer wherein the product is tested and used for creating snapshots of 'reference usage scenarios'. It will also be understood that the term computer system, as used in the present embodiment, embraces a distributed computer system, since each of the software components of an application can reside on a different computer (i.e. physical or virtual) .

The usage scenario comparator 20 compares the usage scenario snapshot of the system under study with a snapshot taken of the reference computer system executing the same usage scenario. The usage scenario comparator 20 also outputs to inter alia the usage scenario viewer 18, the difference between the two snapshots. The usage scenario viewer 18 graphically represents the relationships and data-flow between the software components involved in the usage scenario. The usage scenario viewer 18 also depicts differences between the usage scenario snapshot of the system under study and the reference system.

Referring to Figure 3, the method of the preferred embodiment comprises the steps of allowing 32 a user to define a usage scenario descriptor for a particular usage scenario. As discussed, the usage scenario may be a "reference usage scenario" (a typical usage scenario of the product provided by the software manufacturer) or a "real-world usage scenario" (a specific usage scenario implemented by a user for a specific purpose) . The method of the preferred embodiment then allows 34 the user to execute a usage scenario discovery process in a reference environment and produce a snapshot thereof. The method of the preferred embodiment exports 36 the usage scenario descriptor and usage scenario snapshot of the reference environment, to the repository. The method of the preferred embodiment then allows 38 a user of a computer system under study, to perform usage scenario discovery of the computer system, using the same usage scenario as used with the reference system. As with the reference environment, the method of the preferred embodiment produces a snapshot of the system under study whilst executing the usage scenario discovery therein.

The method of the preferred embodiment then compares the usage scenario snapshot of the reference environment and that of the computer system under study; and allows the user to analyse 39 the results of this comparison in the scenario viewer so as to identify and detect the relevant problems therein .

Referring to Figure 4, a generic computer system 40 adapted to support the preferred embodiments is formed by several units that are connected in parallel to a system bus 42. In detail, one or more microprocessors (XP) 44 control operation of the computer 40; a RAM 46 is directly used as a working memory by the microprocessors 44, and a ROM 48 stores basic code for a bootstrap of the computer 40. Peripheral units are clustered around a local bus 50 (by means of respective interfaces) . Particularly, a mass memory consists of a hard-disk 52 and a drive 54 for reading CD-ROMs 56. Moreover, the computer 40 includes input devices 58 (for example, a keyboard and a mouse) , and output devices 60 (for example, a monitor and a printer) . A Network Interface Card

(NIC) 62 is used to connect the computer 40 to the network. A bridge unit 64 interfaces the system bus 42 with the local bus 50. Each microprocessor 44 and the bridge unit 64 can operate as master agents requesting an access to the system bus 42 for transmitting information. An arbiter 66 manages the granting of the access with mutual exclusion to the system bus 42.

Similar considerations apply if the system has a different topology, or it is based on other networks. Alternatively, the computers have a different structure, including equivalent units, or consist of other data processing entities (such as PDAs, mobile phones and the like) .

Alterations and modifications may be made to the above without departing from the scope of the invention.

Claims

1. A method of identifying a problem in a software application in a computer system, the method comprising the steps of: - allowing (32) a user to define a one or more usage scenarios of the software application;

- executing (34), in a reference computer system, the software application with one or more of the usage scenarios;

- acquiring (36) data concerning a status of a one or more of the reference computer systems and the software application therein, during the execution of the software application with the one or more of the usage scenarios;

- executing (38), in the computer system under study, the software application with the same one or more usage scenarios executed in the reference computer system;

- acquiring data concerning a status of a one or more of the computer systems under study and the software application therein, during the execution of the software application with the one or more of the usage scenarios; - comparing the data from the reference computer system and the computer system under study, to identify the one or more differences therebetween.

2. The method of claim 1 further comprising the step of:

- allowing the user to analyse (39) the differences to identify the difference most likely to represent the problem in the computer system under study.

3. The method as claimed in any preceding claim wherein the step of allowing (32) a user to define a one or more usage scenarios of the software application comprises the steps of: - allowing the manufacturer to define a one or more usage scenarios reflecting a typical usage scenario of the software application; and allowing a user to define a specific usage scenario reflecting a specific use of the software application.

4. The method as claimed in any one of the preceding claims wherein the method further comprises the step of depicting a one or more relationships and flows of data between a one or more software components in the software application executed in the computer system under study.

5. The method as claimed in any one of the preceding claims wherein the method comprises the step of executing the method at the end of a software installation process.

6. The method as claimed in any one of the preceding claims wherein the method comprises the steps of automatically executing the method on detection of an error in the computer system under study.

7. The method as claimed in any one of the preceding claims, wherein the method comprises the step of executing the method in a distributed computing environment.

8. A system for identifying a software problem, the system comprising components adapted to perform the method of any one of the preceding claims.

9. The system as claimed in Claim 7 wherein the potential usage scenarios and real usage scenarios are contained in XML files .

10. A computer program product stored in a medium readable by a computer machine, the computer program product tangibly embodying readable program means for causing the computer to perform the method according to any one of Claims 1 to 7.

11. A service deployed in a data processing system for performing the method of any claim 1 to 7.