Agile Processes in Software Engineering and Extreme Programming / Lecture Notes in Computer Science Bd.4536 (PDF)

reuse in the agile development literature, and at the time of writing there is only one published reuse concept whose stated aim is to reinforce agile development. This is the so called "agile reuse" approach of McCarey et. al. [12].

The reason for this lack of integration is the perceived incompatibility of agile approaches and software reuse. Whereas the former explicitly eschews the creation of software documentation, the latter is generally perceived as requiring it. And while agile methods usually regard class operations (i.e. methods) as defining the granularity of development increments, reuse methods typically regard classes as the smallest unit of reuse in object-oriented programming. As a third difference, reuse approaches tend to be more successful the "more" explicit architectural knowledge is reused (as in product line engineering), whereas agile development methods employ as little explicit architecture as possible. At first sight, therefore, there appears to be several fundamentally irreconcilable differences between the two approaches.

McCarey et. al suggest a way of promoting reuse in agile development through socalled "software recommendation" technology. Their "agile reuse" tool, RASCAL [10] is an Eclipse plug-in which uses collaborative and content-based filtering techniques [9] to proactively suggest method invocations to developers. It does this by attempting to cluster Java objects according to the methods they use, just as Amazon, for example, clusters its customers according to the books they buy. The tool monitors method invocations in the class currently under development to predict method calls that are likely to be soon needed and suggests them to the developer. To evaluate their system the authors experimentally predicted invocations of the Java Swing Library in common open source systems and claim precision rates of around 30%.

Although the concept of RASCAL fits well into the agile spirit of providing maximum support for "productive" activities, there is nothing in the technology which ties it specifically to agile development. The approach embodied in RASCAL can just as easily be used with any other development methodology that produces code, including traditional heavyweight processes. Moreover, the approach has the same fundamental weakness as other repository-based approaches – the quality of the recommendations is only as good as the quality of the code repository that is used to search for components. Unfortunately, to date there have been few if any successful attempts to set up and maintain viable component repositories [6]. The version of the tool described in [10] is clearly a prototype, but McCarey et el. do not present a strategy for solving this important problem. Moreover, although RASCAL showed impressive performance for the limited domain of Swing invocations, it is not clear whether this technique will work for other domains with many more classes that have much lower usage frequencies.

1.2 The Core Challenge

The core challenge of agile reuse lies in developing a reuse strategy that complements the principles of agile development and offers a way of promoting reuse in tandem with the key artifacts and practices of agile methods. Whilst proactive recommendation technology such as RASCAL is certainly valuable in complementing such a strategy it does not itself solve the issues mentioned above. In this paper we present an approach which we believe does address these challenges and thus represents a viable basis for the concept of agile reuse. The key idea is to use unit test cases, which in most agile methods should be defined before implementations, to influence the component searching process. Such test-driven development is one of the most fundamental principles of Extreme Programming, the most widely used agile method. Tests are used as the basic measure of a unit’s semantic acceptability. Once a code unit passes the tests defining its required behaviour it is regarded as "satisfactory" for the job in hand.