When an error is discovered when testing software, the software architect has to decide, which part of software the error is in and who is responsible for fixing the error. These tasks are called "blame analysis". Crnkovic et al. [1] define blame analysis as follows:

"The problem [of blame analysis] is related to a manifestation of a fault and the origin of the fault itself. An error can be detected in one component, but the reason can be placed in another. [...] The question is who performs this analysis if the producers of components A, B and C are not the same."

Blame analysis is especially important in component-based software development (CBSE). In CBSE you assemble software from pre-made components. These components can be developed in-house or be acquired from the market. Especially when using third-party components from the market, it is very important to assign the blame properly to components. This is because the component developers may charge you for error reports and you will lose time while doing so. Dealing with third-party components also makes the blame analysis especially hard, as you likely do not have the source code of these components available.

Performance blame analysis deals with performance errors. These errors occur when the software violates its response time, throughput, or resource usage requirements. Performance blame analysis is hard because every component participating in answering a specific request can be the one that is responsible for the error. In contrast to functional errors there is no natural distinction by functionality of components. Moreover, while the functionality of each component and also component operation is carefully described and sometimes even contractually specified, the performance of a component is usually unspecified.

Nowadays most performance analysis or performance blame approaches rely on a simple heuristic. This heuristic assumes that longer running operations are more likely to be responsible for performance errors than faster running operations. This heuristic does not have to be correct in any case. Especially when a lot of component operations are involved that are taking up about the same time, this heuristic is not very helpful.

Research topic

In our research we suggest the use of performance contracts. We assume these contracts are distributed along with the component by the component developers in the form of Palladio models [2]. These formalized performance contracts enable us to simulate test cases. This simulation results in performance data series that we can compare to the performance measurements from the actual failing test case. Using this comparison we can judge which component need to be blamed. For further information refer to Frank Brüseke.

Third-Party References

[1]

I. Crnkovic, M. Chaudron, und S. Larsson, „Component-Based Development Process and Component Lifecycle“, International Conference on Software Engineering Advances, IEEE, 2006, S. 44–44.

[2]

S. Becker, H. Koziolek, und R. Reussner, „The Palladio component model for model-driven performance prediction“, Journal of Systems and Software, vol. 82, Jan. 2009, S. 3–22.