Approches de détection et correction des odeurs de code

Approches de détection et correction des odeurs de code

Plusieurs études ont récemment porté sur la détection des odeurs de code dans un logiciel en utilisant différentes techniques. Ces techniques sont classées dans trois catégories : manuelles, semi-automatiques et automatiques.

Approches manuelles

Il existe des stratégies pour détecter et corriger les codes smells qui nécessite l’intervention de l’être humain, dans le livre de Fowler (Fowler et al., 1999), il a proposé que les développeurs doivent détecter les odeurs de code d’une façon manuelle en spécifiant des techniques de ré usinage pour chaque type d’odeur de code, de leur part Travassos et ses collègues (Travassos, Shull, Fredericks & Basili, 1999) ont également proposé une approche manuelle pour détecter et corriger les odeurs de code et c’est en fournissant une aide technique ou des conseils pratiques.

Alikacem et Sahraoui (Alikacem & Sahraoui, 2009) ont suggéré une méthodologie pour identifier les odeurs de code dans les systèmes orientés objet. La terminologie a fourni les lignes directrices à l’aide de logique floue et des métriques.

Ces approches présentent plusieurs inconvénients, en effet ces techniques demandent un effort des développeurs et une forte interprétation, ce qui peut générer des pertes de temps. Aussi parmi les limites de ces approches est que les résultats ne sont pas tout à fait exacts, pour contourner ces problèmes des techniques semi automatisées sont apparues.

Approches semi-automatiques

Plusieurs autres travaux de recherche basés sur les techniques de refactoring semi-automatique seront discutés dans cette section.

Moha et ses collègues (Moha, Gueheneuc, Duchien & Le Meur, 2009) ont présenté une méthode spécifique intitulée DÉCOR décrivant toutes les étapes nécessaires à la spécification et à la détection des odeurs de code et de design. Ils ont aussi développé, DETEX, un outil qui permet aux développeurs de spécifier des odeurs à un niveau d’abstraction élevé à l’aide d’un vocabulaire unifié et d’un langage spécifique à un domaine. Ce vocabulaire est obtenu à partir d’une analyse de domaine approfondie.

Feng et ses collègues (Feng, Zhang, Wang & Wang, 2004) ont indiqué que la présence des odeurs de code dans le système dégrade les performances du code source. Ils ont proposé une microarchitecture pour générer un modèle de conception basé sur XML.

Baudry et ses collègues (Baudry, Le Traon & Sunyé, 2004) ont avancé l’idée de reconnaître les odeurs de code au niveau de la conception plutôt qu’au niveau de la mise en œuvre. La méthode d’extension UML a été utilisée pour améliorer la conception.

Murphy-Hill et ses collègues (Murphy-Hill, Black, Dig & Parnin, 2008) ont proposé différents types de techniques de refactoring comme la manipulation des historiques de code, la compréhension d’anciens travaux des programmeurs et l’archivage des outils qui ont été utilisés. Zhang et ses collègues (Zhang, Baddoo, Wernick & Hall, 2011) ont effectué une relation entre les fautes dans les logiciels et six mauvaises odeurs données par Fowler et al (Fowler et al., 1999). La relation justifiée sera utile dans l’application de refactoring par les développeurs.

Certains environnements de développement intégrés (IDE) modernes, tels que Eclipse  et Intellij  et plusieurs autres, fournissent un support semi-automatique de processus de refactoring. Ces outils permettent d’augmenter la vitesse avec laquelle les programmeurs peuvent maintenir le code tout en diminuant la probabilité qu’ils introduisent de nouveaux bogues.

La principale limite de ces approches est que les développeurs essayent d’appliquer des améliorations séparément sans considérer l’ensemble du programme. Aussi, l’approche semiautomatique est limitée à quelques opérations de refactoring possibles et peu de métriques de qualité.

Approches automatiques

Dans le cas de techniques de détection et de correction automatique, cadriciels (de l’anglais « frameworks »), des enquêtes et des outils entièrement automatiques ont été pris en considération.

Liu et ses collègues (Liu, Yang, Niu, Ma & Shao, 2009) ont essayé d’analyser les relations entre les différentes sortes de mauvaises odeurs de code et ils ont présenté la nécessité d’organiser un ordre lors de la résolution des mauvaises odeurs. Avec l’analyse, ils ont introduit un framework qui permet au développeur d’effectuer la restructuration automatique de code.

Ganea et ses collègues (Ganea, Verebi & Marinescu, 2017) ont présenté un plug-in Eclipse appelé « InCode », qui évalue en permanence la qualité des systèmes Java. Il aide également les développeurs à prendre des décisions de restructuration de code. Les odeurs de code comme la duplication de code et les classes de trop grande taille pourraient être facilement localisées par InCode.

Ekman et Schafer (Ekman, Schäfer & Verbaere, 2008) ont étendu JastAdd en générant un moteur qui effectue automatiquement le refactoring. Ils utilisent des blocs de refactoring simples comme base pour d’autres refactorings tels que le renommage et l’extraction des méthodes.

Chatzigeorgiou et Manakos (Chatzigeorgiou & Manakos, 2010) ont examiné les systèmes Orientés objets pour la détection des odeurs de code et ils ont répondu à plusieurs questions parmi eux nous citons : Si le nombre de problèmes augmente avec le passage des générations de logiciels, si les problèmes disparaissent avec le temps ou uniquement par une intervention humaine ciblée, si de mauvaises odeurs se manifestent au cours de l’évolution d’un module ou subsistent dès le début et si les refactorings visant à éliminer les odeurs sont fréquentes.

Tsantalis et Chatzigeorgiou (Chatzigeorgiou & Manakos, 2010) ont mis en évidence une technique de refactoring en Java en se basant sur le polymorphisme. L’idée proposée a été implémentée sous forme d’un « plugin » Eclipse.

Récemment, de nouvelles approches émergent où des techniques basées sur la recherche ont été utilisées pour automatiser les activités de refactoring. Dans ces approches le refactoring est considéré comme un problème d’optimisation. Ouni et ses collègues (Ouni, Kessentini, Sahraoui & Boukadoum, 2013b)ont proposé une approche d’optimisation multi-objectif pour trouver la meilleure séquence de refactorings en utilisant NSGA-II. L’approche proposée est basée sur deux fonctions objectifs, la qualité et l’effort de développeur pour modifier le code. De plus, dans une autre publication, Ouni (Ouni, Kessentini, Sahraoui & Hamdi, 2012) propose un nouvel outil multi-objectif pour trouver le meilleur compromis entre l’amélioration de la qualité et la cohérence sémantique en utilisant deux heuristiques liées à la similitude du vocabulaire et le couplage structurel. Plus tard (Ouni, Kessentini & Sahraoui, 2013a), ils ont intégré un nouvel objectif, qui vise à maximiser la réutilisation de bonnes techniques de refactoring appliqués à des contextes similaires .

Mkaouer et ses collègues (Mkaouer, Kessentini, Shaout, Koligheu, Bechikh, Deb & Ouni, 2015) ont également proposé une nouvelle approche pour recommander des séquences de restructuration de code basée sur un algorithme génétique multi-objectif NSGA-III. Ils utilisent l’historique de changement de code en tant qu’entrée de leur algorithme pour calculer la similarité d’un candidat de refactoring avec des refactorings antérieurs. Dans leur approche, ils visent à trouver les solutions optimales de modularisation qui améliorent la structure des packages, minimiser le nombre de modifications et préserver la cohérence sémantique.

Oliveira et ses collègues (de Oliveira, Freitas, Bonifácio, Pinto & Lo, 2019) ont présenté une nouvelle approche de recommandation de move method et move field en utilisant l’algorithme génétique multi objectif NSGA-II, qui supprime les dépendances de co-changement et les odeurs de code évolutives. C’est un type particulier de dépendance qui survient lorsque des entités à granularité fine appartenant à différentes classes changent fréquemment ensemble.

Finalement, Boukharata et ses collègues (Boukharata, Ouni, Kessentini, Bouktif & Wang, 2019) ont récemment développé une approche automatique de modularisation des interfaces des services Web, nommée WSIRem. L’approche proposée est basée sur l’optimisation multi-objectifs, en utilisant l’algorithme génétique NSGA-II et elle consiste à trouver la modularisation appropriée d’une interface de service. Leur outil analyse les fichiers WSDL des services web pour extraire les dépendances sémantiques et structurelles entre les opérations d’une interface. Ils ont défini trois fonctions objectifs qui visent à minimiser le couplage, maximiser la cohésion et minimiser les modifications des interfaces. WSIRem a été évalué sur un banc d’essai de 22 services Web d’Amazon et de Yahoo. D’autres travaux ont également exploré la décomposition/extraction des interfaces des services Web (Ouni, Kessentini, Inoue & Cinnéide, 2015; Ouni, Salem, Inoue & Soui, 2016; Ouni, Wang, Kessentini, Bouktif & Inoue, 2018; Wang, Ouni, Kessentini, Maxim & Grosky, 2016; Wang, Kessentini & Ouni, 2017) qui s’aligne avec l’extraction de classes mais avec différents technologies. Cependant, ces techniques d’extraction d’interfaces de services Web ne sont pas directement applicables dans le contexte des programmes Java.