Quality of the Source Code for Design and Architecture Recovery Techniques: Utilities are the Problem

An automated approach for noise identification to assist software architecture recovery techniques

“…However, classes 380 with high fan out values located at high architectural layers do not represent noise in the system structure. These classes can be controller classes that initiate processes or user interface classes and their isolation can lead to the misallocation of system modules[14,28]. We validate our results against the direct clients produced by Bunch, where the omnipresent classes set is formed by heav-385 ily used classes in the system.…”

“…Nonetheless, in our methodology we aim to discover noise in systems' design, thus we preserve utility methods in the results. We also verify our re-375 sults against the utility identification approach suggested in [19,14], using the utilityhood metric U . …”

“…The results of the proposed methodology are validated against: (a) Fan-In Analysis for crosscutting concern identification by Marin et al [22] and (b) 470 Utilityhood metric U by Pirzadeh et al [14] for measuring the extent that a class represents a utility in the system. As depicted in Table 5, the Spearman's correlation coefficient for noise categories presents positive significant correlation for all projects and therefore we can reject the null hypothesis that there is no …”

“…Intensively used classes do not positively contribute to the clustering methodologies of SAR [5], because their pervasive presence in the A C C E P T E D M A N U S C R I P T systems induces considerable noise. Consequently, identifying and removing classes that produce noise in a software system is an important preparatory procedure before attempting the comprehension of architecturally significant 30 elements, since their presence increases the gap between implementation and design [14]. Additionally, the authors of a recent feature location taxonomy and survey [15] observe that setting up benchmark systems that can be used in several research papers is challenging, partially because benchmarks may not be 100% accurate since they might contain noise (i.e.…”

Επαναχρησιμοποίηση Λογισμικού Βασισμένη Στην Ανάκτηση Αρχιτεκτονικής Πληροφορίας

“…Οι κλάσεις που χρησιμοποιούνται έντονα δεν συνεισφέρουν θετικά σε μεθοδολογίες ομαδοποίησης στην SAR [58], καθώς η επίμονη παρουσία τους στο σύστημα επιφέρει θόρυβο. Συνεπώς, η αναγνώριση και αφαίρεση των κλάσεων που παράγουν θόρυβο σε ένα σύστημα λογισμικού είναι μια σημαντική προκαταρκτική διαδικασία πριν την κατανόηση των αρχιτεκτονικά σημαντικών στοιχείων του συστήματος, καθώς η παρουσία τους αυξάνει το χάσμα μεταξύ της σχεδίασης και της υλοποίησης [74]. Τέλος, σχετική με την μελέτη είναι η αναγνώριση των διαθεματικών λειτουργιών.…”