Reference/Literaturverweis [Bre04d]

Bredereke, J., Larsson, S., Krishnamurthi, S., Stuckenholz, A., Sulzmann, C., van Ommering, R., Szyperski, C., and Weck, W.:
04511 Breakout Group -- Blame Assignment (abstract).
In: Reussner, R., Stafford, J., Szyperski, C. (editors), "Architecting Systems with Trustworthy Components", No. 04511 in Dagstuhl Seminar Proceedings, p. 5 (Mar. 2006).

Full Text of Abstract / Gesamter Text der Zusammenfassung

Blame assignment is difficult enough in theory: sometimes blame cannot be assigned to any proper subset of components, yet it isn't necessarily the fault of the integrator either. It may sometimes be better to blame the wrong component - just to initiate the investigation - than to cautiously blame none at all! Indeed, the economics of the situation potentially even moves the problem out of the technical arena: for instance, user perceptions may force major corporations to shoulder blame, even when a fault clearly lies with a supplier.

We must move towards architect components to enable blame assignment. This seems like a good role for a component framework, as the enforcer of such architectures. As blame problems grow in significance, integrators and users may come to expect components certified by independent bodies. In turn, developers may come to view the possibility of being blamed as a risk against which they can purchase insurance.

Keywords

Components; errors; blame analysis; blame assignment.