Abstract

A significant aspect in applying the Reflexion Method is the mapping of components found in the source code onto the conceptual components defined in the hypothesized architecture. To date, this mapping is established manually, which requires a lot of work for large software systems. In this paper, we present a new approach, in which clustering techniques are applied to support the user in the mapping activity. The result is a semi-automated mapping technique that accommodates the automatic clustering of the source model with the user’s hypothesized knowledge about the system’s architecture.

This paper describes three case studies in which the semi-automated mapping technique, called HuGMe, has been applied successfully to extend a partial map of real-world software applications. In addition, the results of another case study from an earlier publication are summarized, which lead to comparable results. We evaluated the extended versions of two automatic software clustering techniques, namely, MQAttract and CountAttract, with oracle mappings. We closely study the influence of the degree of completeness of the existing mapping and other controlling variables of the technique to make reliable suggestions.

Both clustering techniques were able to achieve a mapping quality where more than 90% of the automatic mapping decisions turned out to be correct. Moreover, the experiments indicate that the attraction function (CountAttract′) based on local coupling and cohesion is more suitable for semi-automated mapping than the approach MQAttract′ based on a global assessment of coupling and cohesion.

Keywords: Reflexion method; Semi-automated mapping; HuGMe; MQAttract; CountAttract

Article Outline

1. Introduction

2. Related research

2.1. Reflexion method

2.2. Clustering techniques

3. Integration of reflexion method and clustering techniques

3.1. Manual mapping

3.2. Semi-automated mapping

3.3. Clustering algorithm

3.3.1. Partial clustering

3.3.2. Attraction calculation

3.3.2.1. CountAttract

3.3.2.2. MQAttract

3.4. Candidate detection

3.5. Automated mapping

4. Evaluation scheme

5. Case studies

5.1. Case study: clones

5.1.1. System characteristics

5.1.1.1. Application domain

5.1.1.2. Size and language

5.1.2. Experimental setup

5.1.2.1. Architecture

5.1.2.2. Mapping

5.1.3. Results

5.1.3.1. Mapping rate

5.1.3.2. Average cmaps-to range size

5.1.3.3. Average percentiles

5.1.3.4. Hit rate

5.1.3.5. Degree of completeness

5.1.4. Discussion

5.2. Case study: SDCC

5.2.1. System characteristics

5.2.1.1. Application domain

5.2.1.2. Size and language

5.2.2. Experimental setup

5.2.2.1. Architecture

5.2.2.2. Mapping

5.2.3. Results

5.2.3.1. Mapping rate

5.2.3.2. Average cmaps-to range size

5.2.3.3. Average percentiles

5.2.3.4. Hit rate

5.2.3.5. Degree of completeness

5.2.4. Discussion

5.3. Case study: Tetris

5.3.1. System characteristics

5.3.1.1. Application domain

5.3.1.2. Size and language

5.3.2. Experimental setup

5.3.2.1. Architecture

5.3.2.2. Mapping

5.3.3. Results

5.3.3.1. Mapping rate

5.3.3.2. Average cmaps-to range size

5.3.3.3. Average percentiles

5.3.3.4. Hit rate

5.3.4. Discussion

5.4. Summary of results from the previous SHriMP case study

6. Limitations of the method

7. Conclusions

Acknowledgements

References