Patent Application
20080109791
The present invention relates to the information technology field. More specifically, the invention relates to the management of errors in software applications.
The management of software applications is a very complex process. This is particularly true for large software applications, especially when they are intended to run in heterogeneous network environments or have multi-layer structures.
More in detail, the process of managing each software application involves a number of different activities. For example, the building of the software application starts with an analysis phase for the collection of its requirements. The analysis phase is then followed by a design phase for the corresponding architectural definition. Afterwards, it is possible to implement the actual code of the software application during a corresponding development phase. The software application so obtained is generally subjected to a test phase for verifying its correct operation. Once an acceptable level of confidence has been obtained, the software application is deployed into a production environment. During its life cycle, the software application is further subjected to maintenance operations. Particularly, patches (of fixes) are continuously applied to correct corresponding errors temporarily. Periodically, new versions or releases of the software application (incorporating all the available patches and providing new functions) are installed. In any case, the software application must be reconfigured whenever its operative parameters change.
Some tools are available to facilitate some activities of the above-described management process. For example, modeling tools are extensively used during the analysis and design phases. Those tools allow simplifying the representation of different aspects of the software application by means of models (for example, of the UML type), which provide an abstraction of real components to be built; in this way, it is possible to visualize, assess and communicate the software application before its actual implementation (so as to reduce the risks of the corresponding development). Generally, the modeling tools provide an Integrated Development Environment (IDE) which also facilitates the generation of the corresponding code. A very popular example of commercial modeling tool is the “Rational Rose” by IBM Corporation.
However, other phases of the management process still remain substantial manual tasks. Particularly, the activities relating to the management of the errors in the software application are based on an investigation process, which requires a heavy intervention of a system administrator. Indeed, the collection of the errors, their analysis, the corresponding reporting, and the planning of the required correction actions are completely in charge of the system administrator.
Therefore, the quality of the above-described error management process strongly depends on the skill of the system administrator; in any case, the obtained results are not repeatable and prone to errors.
Moreover, the documentation of any activities relating to the error management process is completely unstructured (for example, being based on a specification in prose). This makes it very difficult to convey and/or share any desired information.
The above-mentioned drawbacks also have a detrimental impact on the optimal allocation of the resources that are available for correcting the errors. Indeed, it is very difficult (if not impossible) for the system administrator to decide how to prioritize the errors for their correction.
All of the above may have deleterious effects on business aspects related to the software application (for example, when the correction of errors impacting critical business areas is delayed).
In its general terms, the present invention is based on the idea of representing the impact of the errors in the models.
Particularly, the present invention provides a solution as set out in the independent claims. Advantageous embodiments of the invention are described in the dependent claims.
More specifically, an aspect of the invention provides a method for managing errors in software applications. The method starts with the step of modeling a software application with a set of models (for example, of the UML type); the models include a plurality of artifacts (such as classes)—each one modeling an aspect of the software application—and a plurality of correlations among the artifacts (such as use, realize, form). The software application is then implemented according to the models; the software application includes a plurality of modules (such as objects), each one participating in the implementation of at least one of the artifacts. An error in a failing one of the modules is then detected. The method continues by setting as directly impacted by the error each artifact, which implementation is participated by the failing module. Moreover, there is set as indirectly impacted by the error each artifact, which is correlated in the models with at least one directly impacted and/or indirectly impacted artifact. At this point, there is generated a representation of the models with an identification of each directly impacted artifact and each indirectly impacted artifact.
Preferably, each artifact collecting at least one directly impacted artifact is also set as directly impacted by the error.
Typically, the proposed solution is applied to software applications of the object-oriented type.
Advantageously, it is possible to select the classes to be traced.
A way to facilitate this operation is of selecting a parent artifact (with the selection that is automatically applied to its dependent artifacts).
In a preferred embodiment, the directly/indirectly impacted artifacts are highlighted in the representation of the models (i.e., in their diagrams) by means of corresponding visual clues (such as colors).
As a further enhancement, is it possible to associate an indirection index to each indirectly impacted artifact (according to the number of correlations with the directly impacted artifacts).
Advantageously, different intensities of the visual clue for the indirectly impacted artifacts are used according to their indirection indexes (such as different shades of the same color).
Another aspect of the invention proposes a computer program for performing the above-described method.
A further aspect of the invention proposes a corresponding system.
The invention itself, as well as further features and the advantages thereof, will be best understood with reference to the following detailed description, given purely by way of a non-restrictive indication, to be read in conjunction with the accompanying drawings, in which:
a-1c show different modeling diagrams that may be used to implement the solution according to an embodiment of the invention;
a-2c show an exemplary application of the solution according to an embodiment of the invention on those modeling diagrams;
With reference in particular to
Particularly,
In detail, an actor plays the role of an End-user, or an external interacting system, of the software application. The End-user carries out four different use cases, denoted with Uaa, Uba, Ubb and Uab (as indicated by corresponding associations). The use case Uaa includes a use case Uca—as indicated by a corresponding dependency, represented with a dashed-line arrow, meaning that the (source) use case Uaa includes the behavior of the (target) use case Uba. Likewise, the use case Uba includes a use case Ucb, which in turn includes the use case Uca. At the end, both the use case Ubb and the use case Uab include a use case Ucc.
Moving now to
In the example at issue, the class diagram 100b provides a high-level representation of the software application by means of packages implementing the required use cases; each package (represented by a tabbed folder) groups together more classes correlated to each other. Particularly, a package Sa implements the use cases Uaa and Uab; likewise, a package Sb implements the use cases Uba and Ubb, while a package Sc implements the use cases Uca, Ucb and Ucc (of
With reference now to
More specifically, the package Sa realizes an interface Ia1—as indicated by a corresponding association, represented with a dashed-line arrow, meaning that the (source) package Sa implements the functionality defined by the (target) interface Sa1; the interface Ia1 exposes a method IMa1. The package Sa is formed by a class Ca1—as indicated by a corresponding aggregation, represented with an arrow starting with a diamond, meaning that the (source) package Sa has the (target) class Ca1; the class Ca1 exposes a method CMa1, which implements the method IMa1 of the interface Ia1. Likewise, the package Sb realizes an interface Ib1, which exposes a method IMb1; the package Sb is formed by a class Cb1, which exposes a method CMb1 implementing the method IMb1 of the interface Ib1. Moreover, the package Sc realizes an interface Ic1, which exposes three methods IMc1, IMc2 and IMc3; the package Sc is formed by a class Cc1 (exposing a method CMc1 that implements the method IMc1 of the interface Ic1), a class Cc2 (exposing a method CMc2 that implements the method IMc2 of the interface Ic1), and a class Cc3 (exposing a method CMc3 that implements the method IMc3 of the interface Ic1). The class Cc2 in turn uses the class Cc1.
The analysis and design phases are then followed by a development phase, wherein the software application is actually built starting from the provided models. In the example at issue, the software application is obtained by writing code that implements the above-described classes Ca1, Cb1, Cc1, Cc2, Cc3 in an object-oriented language (such as Java); the software application will then consist of different objects, each one being an instance of an available class.
In the solution according to an embodiment of the present invention, as described in detail in the following, the same models are also used to represent the impact of any error in the software application. More specifically, each error occurs in an object of the software application (hereinafter referred to as failing object). Therefore, each artifact (i.e., class, package or use case in the example at issue) which implementation is participated by the failing object is set as directly impacted by the error. At the same time, each artifact that is correlated to the directly impacted artifact is set as indirectly impacted by the error; the correlation can be either specifically with the directly impacted artifact or through one or more other indirectly impacted artifacts.
For example, with reference to the low-level class diagram 100c repeated in
The proposed solution strongly facilitates the management of the errors in the software application. Particularly, the representation of the impact of the errors in the models provides a useful support for a system administrator; for example, this aids the system administrator in the analysis of the errors, the corresponding reporting, and the planning of the required correction actions.
All of the above makes the process of managing the errors in the software application less dependent on personal skills; this has a beneficial impact on the quality of the corresponding results.
Moreover, the obtained documentation is well suited to convey and/or share the desired information.
The above-mentioned advantages improve the allocation of the resources that are available for correcting the errors, which resources may now be exploited at their best according to different priorities.
In any case, the proposed solution allows limiting the negative effects of the errors on business aspects related to the software application (for example, by immediately identifying and correcting any errors that impact critical business areas).
Advantageously, the (directly and indirectly) impacted artifacts are highlighted in the diagrams representing the relevant models. For example, as shown in the figure, the directly impacted artifacts Cc1, Sc are represented with a dark background; on the other hand, the indirectly impacted artifacts Cc1, Sa, Ca1, Sb, Cb1 are represented with a light background. Preferably, different colors are used for this purpose; for example, the directly impacted artifacts Cc1, Sc are colored in red, while the indirectly impacted artifacts Cc1, Sa, Ca1, Sb, Ch1 are colored in yellow.
This feature improves the visual representation of the directly/indirectly impacted artifacts (thereby facilitating the identification of the impact of the error in the software application).
In addition, it is also possible to assign an indirection index to each indirectly impacted artifact, according to its distance from the directly impacted artifact(s). For example, the indirection index is given by the number of correlations that are required to reach the closest directly impacted artifact—through any other indirectly impacted artifact (starting from 1 when the indirectly impacted object is immediately correlated to a directly impacted object). This indirection index provides a quantitative indication of the level of impact of the error.
Preferably, the indirectly impacted artifacts are differentiated in the diagrams representing the relevant models according to their indirection indexes. For example, let us assume that the class Ca1 uses the failing method CMc1 of the directly impacted class Cc1; in this case, the indirection index of the indirectly impacted class Ca1 will be equal to 1. Conversely, if the class Cb1 uses the method CMc2 of the indirectly impacted class Cc2 (which in turn uses the failing method CMc1 of the directly impacted class Cc1) the indirection index of the indirectly impacted class Cb1 will be equal to 2. In this case, the indirectly impacted artifacts Cc2, Ca1, Sa and Cb1, Sb are represented with different intensities of their background (such as with the higher the indirection index the lighter the background). Preferably, when a color representation is used, it is possible to provide different shades (of the yellow in the example at issue) for corresponding indirection indexes.
The same process may also be applied to all the other models of the software application. For example, considering the high-level class diagram 100b repeated in
Going back to the use case diagram 100a repeated in
The information provided by the above-described solution may also be used to implement a quantitative analysis of the impact of the error in the software application. For example, it is possible to assign a weight to each artifact—according to its importance from a business point of view (for example, from 0 when the modeled aspect is irrelevant for the operation of the software application to 100 when the modeled aspect is vital). The impact of the error for the different aspects of the software application may be quantified by calculating a criticality index for each artifact. For example, this result may be achieved by multiplying the weight of the artifact by a correction factor; the correction factor is set to 1 when the artifact is directly impacted by the error and to 0 when the artifact is not impacted by the error; intermediate values between 0 and 1 are used when the artifact is indirectly impacted by the error (for example, 0.5 for the indirection index 1, 0.25 for the indirection index 2, 0.125 for the indirection index 3, and so on). It is also possible to assign a global criticality index to the error as a whole—such as equal to the sum of the criticality indexes of all the artifacts or to their average. This information allows ordering the errors automatically from the most critical to the least critical. In this way, it is also possible to implement an algorithm for scheduling their treatment (for example, by assigning different priorities to the errors according to their criticality) and/or for managing the allocation of the available resources.
With reference now to
Particularly, a modeler 405 (such as the above-mentioned “Rational Rose”) is used by an analyst or a designer to define a series of models for each software application to be built. Typically, the modeler 405 provides a graphical user interface that allows creating, editing, viewing, and performing any other management operations on the diagrams representing the desired models. The definitions of the models are saved into a repository 410, for example, by means of corresponding files in the XML Metadata Interchange (XMI) format (action “A1.Model”). In this phase, the analyst/designer selects any artifact (i.e., classes, packages, use cases), which errors should be traced (action “A2.Select”). For this purpose, the analyst/designer can select the desired artifact directly (for example, by dragging a tracing icon onto it). Alternatively, the analyst/designer can select a (parent) artifact that collects one or more artifacts being dependent thereon; in this case, the selected parent artifact is automatically expanded into the collected dependent artifacts, so as to apply the selection to all of them (action “A3.Expand”). In both cases, the selected artifacts are flagged in the repository 410. In this way, it is possible to apply the proposed solution selectively (for example, only with respect to specific aspects of the software application of particular relevance). Particularly, the above-described automatic expansion of the parent artifacts strongly facilitates the selection of the desired artifacts (for example, for specific areas of interest).
A code generator 415 is used by a developer to actual build each desired software application 420 implementing the corresponding models (action “A4.Implement”). In this phase, the code generator 415 automatically instruments each class (participating in the implementation of a selected artifact) for the desired tracing—for example, by extending it with a dedicated method (action “A5.Instrument”).
During the life cycle of the software application 420, whenever an error occurs in an object instantiating an instrumented class a corresponding error message is returned (by a logger, not shown in the figure); for example, the error message includes a timestamp, an error code, the name of the class instantiated by the failing object, the name of the failing method, and a descriptive message. All the returned error messages are saved into a log 425 (action “A6.Trace”).
A tracing engine 430 accesses the model repository 410 and the error log 425. For each error, the tracing engine 430 determines all the directly impacted artifacts in the corresponding models (action “A7.Set direct”). Moreover, the tracing engine 430 also determines all the indirectly impacted artifacts in the same models (action “A8.Set indirect”); in this phase, for each indirectly impacted artifact, the tracing engine 430 also determines the corresponding indirection index. The information so obtained defines a corresponding report (for example, in the XMI format), which is saved into a database 435.
A rendering module 440 extracts the definition of a selected model from the repository 410. The rendering module 440 creates the graphical representation of the corresponding diagram, and displays it on the monitor of the computer (action “A9.Display”). The rendering module 440 also accesses a color palette 445; the color palette associates different colors with the directly/indirectly impacted artifacts in a lookup table (red for the directly impacted artifacts and yellow with multiple shades for the indirectly impacted artifacts in the example at issue). The rendering module 440 then identifies each directly impacted artifact of the selected model (according to the corresponding report in the database 435) and assigns it the corresponding color (according to the color palette 445); the directly impacted artifact is then highlighted on the monitor in red (action “A10.Highlight direct”). At the same time, the rendering module 440 identifies each indirectly impacted artifact of the selected model and assigns it the corresponding shade of color (according to its indirection index); the indirectly impacted artifact is then highlighted on the monitor in the desired shade of yellow (action “A11.Highlight indirect”).
In addition or in alternative, the report database 435 is also accessed by an analyzer 450. For each error, the analyzer 450 calculates the criticality index of each artifact, according to its weight and the correction factor depending on the impact of the error (action “A12.Quantify”). The analyzer 450 aggregates the criticality indexes of all the artifacts into the global criticality index of the error (action “A13.Aggregate”). This information allows a scheduler 455 to optimize the allocation of the available resources for solving the different errors (action “A14.Allocate”).
Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many modifications and alterations. Particularly, although the present invention has been described with a certain degree of particularity with reference to preferred embodiments) thereof, it should be understood that various omissions, substitutions and changes in the form and details as well as other embodiments are possible; moreover, it is expressly intended that specific elements and/or method steps described in connection with any disclosed embodiment of the invention may be incorporated in any other embodiment as a general matter of design choice.
For example, the proposed solution lends itself to be used to manage whatever type of errors in any software application. Similar considerations apply if the same idea is implemented with one or more UML models of other type and then with corresponding artifacts and correlations among them (such as represented with object diagrams, sequence diagrams, activity diagrams, collaboration diagrams, statechart diagrams, and so on); anyway, the reference to the UML language must not be interpreted in a limitative manner (with the proposed solution that may also be implemented with different formalisms, such a based on Petri networks). Moreover, the above-described scenarios are merely illustrative, with the obtained information that may be used in any other way (for example, for reporting purposes only).
It is emphasized that any other representation of the directly/indirectly impacted artifacts is within the scope of the invention; for example, the possibility of providing a textual description thereof (for example, in the XMI language) is contemplated.
Alternatively, equivalent rules may be used to determine the artifacts that are directly impacted by each error (according to the semantic of the relevant models).
In a very simplified implementation of the proposed solution, it is also possible only to trace the objects (and not the corresponding methods) causing the errors. Anyway, nothing prevents applying the same concepts to software applications that are implemented with standard languages (not of the object-oriented type); in this case, the error may relate to whatever module of the software application (such as a subroutine).
Any other technique may be used to select the artifacts to be traced (for example, by means of specific commands available in a menu of the modeler).
Alternatively, it is possible to support the selection of the artifacts to be traced only at the level of models, single artifacts, and the like.
However, this feature is not strictly necessary and it may be omitted in some embodiments of the invention (wherein the proposed solution is applied indiscriminately to all the artifacts).
Similar considerations apply if the directly/indirectly impacted artifacts are highlighted in the diagrams with equivalent visual clues. For example, is it possible to use other colors, different lines, fonts, and the like; moreover, the directly impacted artifacts may be made to blink.
In an alternative embodiment of the invention, the indirection indexes are calculated in another way (for example, by assigning different weights to the correlations); however, nothing prevents managing all the indirectly impacted artifacts in the same way (without any differentiation).
In this case as well, analogous comments apply if the indirection indexes associated with the indirectly impacted artifacts are represented in another way (for example, by means of different colors, numerical labels, and the like).
Similar considerations apply if the program (which may be used to implement each embodiment of the invention) is structured in a different way, or if additional modules or functions are provided; likewise, the memory structures may be of other types, or may be replaced with equivalent entities (not necessarily consisting of physical storage media). Moreover, the proposed solution lends itself to be implemented with an equivalent method (by using similar steps, removing some steps being not essential, or adding further optional steps—even in a different order). In any case, the program may take any form suitable to be used by or in connection with any data processing device, such as external or resident software, firmware, or microcode (either in object code or in source code). Moreover, it is possible to provide the program on any computer-usable medium; the medium can be any element suitable to contain, store, communicate, propagate, or transfer the program. For example, the medium may be of the electronic, magnetic, optical, electromagnetic, infrared, or semiconductor type; examples of such medium are fixed disks (where the program can be pre-loaded), removable disks, tapes, cards, wires, fibers, wireless connections, networks, broadcast waves, and the like.
In any case, the solution according to the present invention lends itself to be implemented with a hardware structure (for example, integrated in a chip of semiconductor material), or with a combination of software and hardware.
Alternatively, the proposed method may be implemented on a computer with a different architecture or that includes equivalent units (such as cache memories temporarily storing the programs or parts thereof to reduce the accesses to the mass memory during execution); more generally, it is possible to replace the computer with any code execution entity (such as a PDA, a mobile phone, and the like).
| Number | Date | Country | Kind |
|---|---|---|---|
| 06123469.6 | Nov 2006 | EP | regional |
