Les clones dans les systèmes orientés objet

Les systèmes logiciels orientés objets sont de plus en plus volumineux et complexes. Les exigences en termes de qualité ont également augmentées. Par ailleurs, la présence de clones dans la plupart des systèmes développés nuit à la qualité de ces derniers [1, 2, 3]. Ce problème est devenu un enjeu primordial qu’il faut absolument résoudre ou maîtriser.

Les clones en tant qu’éléments importants dans la création des logiciels représentent une mauvaise pratique de programmation et un des facteurs qui contribuent à la dégradation de la qualité des logiciels [4]. Il s’agit de copier des fragments de code existants et de les insérer dans divers endroits du code, avec ou sans modifications, ce qui peut donner lieu à différents types de clones. Les clones, du point de vue des chercheurs, représentent un sujet très délicat vu leur impact direct sur la qualité et la maintenance des logiciels. Gyorgy Hegedus et al. [6] ont cité l’influence négative possible de la présence des clones dans le code source sur les deux attributs de qualité : analysabilité et changeabilité, ainsi que sur leurs sous caractéristiques. Francesca Arcelli Fontana et al. [14] ont présenté à travers une analyse l’effet positif sur la plupart des métriques de qualité après élimination du code dupliqué en utilisant le refactoring.

La présence de clones est l’un des facteurs qui peut nuire à la qualité des logiciels. Le code dupliqué ou les clones, comme façon très courante dans la création des logiciels, représente une mauvaise pratique de programmation et parmi l’un des facteurs importants conduisant à la dégradation de la qualité [4] . La détection des bogues liés à un clone lors de l’exécution des programmes, oblige le programmeur à vérifier tous les fragments similaires pour éviter les mêmes bogues. Des problèmes de défaillance de logiciels, des difficultés d’entretien et l’augmentation considérable de la taille du projet peuvent être liés à cette façon de programmer (utilisation de clones) .

Le refactoring comme processus faisant face aux défis imposés par les différents changements à travers les activités de maintenance, s’est avéré une alternative très intéressante pour améliorer la qualité d’un logiciel donné. L’ensemble des chercheurs le catégorise parmi les solutions efficaces pour éliminer les codes dupliqués .

Les clones dans les systèmes orientés objet 

Les clones sont considérés comme une mauvaise pratique de programmation dans l’ingénierie de logiciel. Ils représentent toutes sortes de redondances, réplications et duplications de code. Les clones se créent généralement par la copie des fragments de code existants et de leur réutilisation (collage) avec ou sans modification. Il existe plusieurs définitions de clones dans la littérature. Baxter et al. [1] définissent les clones comme des fragments de code similaires en absence de définition exacte de la similitude. Par contre, Kamiya et al. [2] les définissent comme toutes parties identiques ou similaires à d’autres parties d’un fichier source.

Les clones du point de vue des chercheurs sont traités comme un sujet très délicat vu leur impact direct sur la qualité, en particulier sur la maintenance qui représente l’une des phases les plus coûteuses du processus de développement . La maintenance est définie comme la modification du produit logiciel après sa livraison afin de corriger les erreurs résiduelles, améliorer sa performance ou l’adapter à un autre environnement [9].

Plusieurs travaux portent sur la présence des clones dans le code source, leur importance et leur impact possible. Hotta et al. [10] ont conduit une étude empirique sur l’influence de la présence du code dupliqué. La mesure d’impact a été réalisée à travers la définition d’un nouvel indicateur appelé «fréquence de modifications». Cet indicateur mesure l’impact de la présence des clones comparativement à leur élimination avec la fréquence de modifications. Ils ont conclu que les clones affectent l’évolution du logiciel et sa stabilité, car les codes dupliqués sont susceptibles d’avoir plusieurs modifications pendant l’évolution.

Kim et al. [8], ont conduit une étude avec le même objectif, mais d’une façon différente. Ils ont développé une définition formelle de l’évolution des clones, ainsi qu’un outil de généalogie des clones. Selon ce groupe de chercheurs, cet outil permet d’extraire l’historique des clones à partir des dépôts de code source. Le refactoring des clones était déduit comme la solution idéale pour régler les problèmes de présence de clones dans le code source, mais ce n’est pas toujours le cas. Le refactoring de clones n’est pas préférable sur des clones volatils (les clones qui disparaissent avec l’évolution du logiciel) ou sur certains clones à long terme (les clones qui ne sont pas susceptibles de subir de refactoring).

les raisons de l’utilisation des clones 

Il existe plusieurs facteurs qui forcent le programmeur à créer des clones dans un système. Mais parfois, ils se créent accidentellement [3). La liste est longue [4), mais dans ce qui suit, nous allons citer les cas les plus importants:
• Le premier cas s’inscrit parmi les stratégies de développement. Cette catégorie représente le recours à la duplication de code en vue de le réutiliser dans un autre endroit du même projet. Il se fait soit par un copier/coller simple, soit par le Forking, un terme introduit et utilisé par Kapser et al. [5). Il représente la réutilisation des solutions similaires en espérant qu’elles vont diverger avec l’évolution du système [3).
• Fusionner deux ou plusieurs systèmes contenant des procédures identiques dans le but de créer un nouveau système s’inscrit parmi les cas de la deuxième catégorie. Cette opération donne une forte probabilité d’avoir un nouveau logiciel avec un nombre important de codes dupliqués [3).

Les types de clones et l’évolution des systèmes

Chanchal Kumar et al. [4], citent deux genres de similarité entre deux fragments de code: la similitude textuelle, et la similitude fonctionnelle .
➤ La similarité textuelle : Elle est basée sur la similarité des textes de code, en copiant des fragments et en les collant dans d’autres emplacements:
• Type 1: des fragments de code identiques, sauf pour les variations de blancs et de commentaires.
• Type Il: des fragments identiques structurellement / syntaxiquement à l’exception de variations des identifiants, des littéraux, des types, et des commentaires.
• Type III: des fragments copiés avec d’autres modifications; Les déclarations peuvent être modifiées, ajoutées où supprimées en plus des variations dans les identificateurs, les littéraux, les types, et les commentaires .
➤La similarité fonctionnelle: ce sont les cas où les fonctionnalités de deux fragments de code sont identiques ou similaires:
• Type IV: il inclut deux ou plusieurs fragments de code qui effectuent le même calcul, mais ils sont différents en termes de variantes syntaxiques. La création de clones dans les systèmes orientés objet peut dépendre fortement de l’évolution de ces derniers [11]. Il peut y avoir des clones au sein d’un système, mais qui disparaissent avec l’évolution du système en raison de travaux de maintenance. Ce genre de clones s’appelle: les clones volatils. L’autre type de clones, les clones à long terme, sont des cas considérés en général comme des clones qui ne sont pas susceptibles de subir de refactoring. Donc, ils vont rester dans toutes les versions du système.

Le refactoring orienté objet

Le refactoring est une activité d’ingénierie logicielle qui consiste à modifier le code source d’une application de manière à améliorer sa qualité sans altérer son comportement (du point de vue de ses utilisateurs) [3]. Cette activité permet de réduire les coûts de maintenance et d’améliorer la qualité [3, 7, 9]. Par ailleurs, la maintenance (corrective et évolutive) concerne l’évolution d’un logiciel. Il s’agit de répondre à l’urgence et d’être réactif. Elle permet de faire la modification directe sur le comportement d’un logiciel, en termes de correction de bogues et d’ajout ou d’amélioration des fonctionnalités [3]. Ce qui est complètement différent du refactoring. Le refactoring représente une démarche continue, qui vise à pallier activement aux problèmes d’évolution. Son application a été proposée en parallèle avec la maintenance dès lors qu’il est compatible avec ses contraintes de réactivité, car plus un refactoring est effectué tôt, moins il coûte cher [3]. Le refactoring étant un processus délicat qui améliore les caractéristiques non fonctionnelles comme la changeabilité et la stabilité. Il permet aussi d’assurer que [12] :
➤ Toute information nécessaire est disponible.
➤ Toute information redondante sera supprimée.
➤ Simplification des algorithmes et des méthodes.
➤ La complexité de chaque classe sera limitée.
➤ Le nombre de classes sera limité.

Table des matières

Chapitre 1-lntroduction 
Chapitre 2 – État de l’art: Refactoring basé sur les clones 
2.1 Introduction
2.2 Les clones dans les systemes orientés objet
2.2.1 Les raisons d’utilisation des clones
2.2.1 Les types de clones et l’evolution des systemes
2.3 Le refactoring orienté objet
2.3.1 Bénifices du refactoring
2.3.2 Quand et ou est ce qu’il faut appliquer le refactoring
2.3.3 Approches d’anticipation de refactoring basé sur les clones
2.3.4 Outils d’anticipation de refactoring basé sur les clones
2.3.5 Processus de refactoring
2.3.6 Differentes techniques de refactoring
2.4 Refactoring basé sur les clones, qualité et travaux connexes
2.5 Conclusion
Chapitre 3 – Elaboration d’un modèle conceptuel de Maintenabilité-Testabilité
3.1 Introduction
3.2 Les indicateurs de qualité selon ISO/IEC 9126
3.3 La maintenabilité comme un attribut qualité
3.4 La testabilité comme une sous caractéristique de la maintenabilité
3.5 Cadre d’evaluation de la maintenabilité – Testabilité en utilisant GQM.
3.6 Conclusion
Chapitre 4 – Évaluation empirique
4.1 Introduction
4.2 Objectifs de l’etude
4.3 Environnement et collecte de données
4.4 Résultats et interpretations
4.4.1 La statistique desciptive
4.4.2 Les correlations entre les métriques de code source et les métriques de classes de test
4.4.3 Analyse de correlation entre les métriques de code source et les métriques de classes de test en utilisant les differences
4.4.4 L’impact de variations des métriques de code source sur l’effort de test en utilisant la regression lineaire
4.5 Conclusion
Chapitre 5 – Conclusion générale

Télécharger le rapport complet