Defining the problems of framework reuse

Abstract

Frameworks are an attractive form of reuse due to their paradigmatic simplicity. Unfortunately their size and complexity makes understanding how to use them difficult. In addition documentation to support framework reuse often lacks experimental validation and there is little understanding of what artefacts must be documented to increase the effectiveness of documentation techniques. This report describes an empirical investigation into framework reuse. Its aim is to identify the major problems of reuse and the impact of current documentation techniques on these problems. A qualitative approach is employed and developer experiences are captured from three separate reuse studies using multiple forms of data capture. Four major reuse problems are identified by this report. Understanding the functionality of components; the interactions between component; the mapping from the problem domain to the framework implementation and understanding the architectural assumptions in the framework design. The effectiveness of current forms of documentation is evaluated using these problem categories and, as a result, a number of suggestions for improving developer support during reuse are made

Comparison of different documentation styles for frameworks of object-oriented code

“…. Mapping modifications with class inheritance refers to identifying the problem of correctly expressing a modification in the language of the framework (Kirk et al 2002). The expectation is to reuse the functionality available between classes in the framework.…”

“…. Understanding functionality and interactions refers to being able to figure out the behaviour of elements within the framework (Kirk et al 2002).…”

A model-based extensible framework for efficient application design using FPGA

“…While a number of implementation choices are available for a signal processing kernel, it is not easy to manage a large number alternatives in a manner suitable for efficient evaluation of the design choices [Kirk et al 2002]. In addition, opportunities for runtime reconfiguration [Ghiasi et al 2004;Maestre et al 2001;Shirazi et al 1998] and device shutdown and startup also need to be evaluated for lowpower application design.…”