Thèse numérisée par la Division de la gestion de documents et des archives de l'Université de Montréal

No description available.

Les défauts de code et de conception sont des problèmes d'implémentation et de conception qui proviennent de ''mauvais'' choix conceptuels récurrents. Ces défauts ont pour conséquence de freiner le développement et la maintenance des systèmes en les rendant plus difficiles à maintenir et évoluer. Une détection et une correction semi-automatiques sont donc des facteurs clefs pour faciliter les phases de maintenance et d'évolution.<br /><br />Des techniques et outils ont été proposés dans la littérature à la fois pour la détection et la correction des défauts. Les techniques de détection proposées consistent principalement à définir des règles pour détecter les défauts et à les appliquer sur le code source d'un système. Quant aux techniques de correction, elles consistent à appliquer de façon automatique des refactorisations dans le code source du système analysé afin de le restructurer de manière à corriger les défauts. Cependant, la phase qui consiste à identifier les restructurations est réalisée manuellement par les<br />ingénieurs logiciels. Ainsi, il n'est pas possible de corriger<br />directement et automatiquement les défauts détectés. Ce problème est dû au fait que la détection et la correction des défauts sont traitées de façon isolée.<br /><br />Ainsi, nous proposons DECOR, une méthode qui englobe et définit toutes les étapes nécessaires pour la détection et la correction des défauts de code et de conception. Cette méthode permet de spécifier des règles de détection à un haut niveau d'abstraction et de suggérer des restructurations de code afin d'automatiser la correction des défauts.<br /><br />Nous appliquons et validons notre méthode sur des systèmes libres orientés objet afin de montrer que notre méthode permet une détection précise et une correction adaptée des défauts.

Lors de ces dix dernières années, le coût de la maintenance des systèmes orientés objets s'est accru jusqu' à compter pour plus de 70% du coût total des systèmes. Cette situation est due à plusieurs facteurs, parmi lesquels les plus importants sont: l'imprécision des spécifications des utilisateurs, l'environnement d'exécution changeant rapidement et la mauvaise qualité interne des systèmes. Parmi tous ces facteurs, le seul sur lequel nous ayons un réel contrôle est la qualité interne des systèmes. De nombreux modèles de qualité ont été proposés dans la littérature pour contribuer à contrôler la qualité. Cependant, la plupart de ces modèles utilisent des métriques de classes (nombre de méthodes d'une classe par exemple) ou des métriques de relations entre classes (couplage entre deux classes par exemple) pour mesurer les attributs internes des systèmes. Pourtant, la qualité des systèmes par objets ne dépend pas uniquement de la structure de leurs classes et que mesurent les métriques, mais aussi de la façon dont celles-ci sont organisées, c'est-à-dire de leur conception, qui se manifeste généralement à travers les patrons de conception et les anti-patrons. Dans cette thèse nous proposons la méthode DEQUALITE, qui permet de construire systématiquement des modèles de qualité prenant en compte non seulement les attributs internes des systèmes (grâce aux métriques), mais aussi leur conception (grâce aux patrons de conception et anti-patrons). Cette méthode utilise une approche par apprentissage basée sur les réseaux bayésiens et s'appuie sur les résultats d'une série d'expériences portant sur l'évaluation de l'impact des patrons de conception et des anti-patrons sur la qualité des systèmes. Ces expériences réalisées sur 9 grands systèmes libres orientés objet nous permettent de formuler les conclusions suivantes: • Contre l'intuition, les patrons de conception n'améliorent pas toujours la qualité des systèmes; les implantations très couplées de patrons de conception par exemple affectent la structure des classes et ont un impact négatif sur leur propension aux changements et aux fautes. • Les classes participantes dans des anti-atrons sont beaucoup plus susceptibles de changer et d'être impliquées dans des corrections de fautes que les autres classes d'un système. • Un pourcentage non négligeable de classes sont impliquées simultanément dans des patrons de conception et dans des anti-patrons. Les patrons de conception ont un effet positif en ce sens qu'ils atténuent les anti-patrons. Nous appliquons et validons notre méthode sur trois systèmes libres orientés objet afin de démontrer l'apport de la conception des systèmes dans l'évaluation de la qualité. / Maintenance costs during the past decades have reached more than 70% of the overall costs of object-oriented systems, because of many factors, such as changing software environments, changing users' requirements, and the overall quality of systems. One factor on which we have a control is the quality of systems. Many object-oriented software quality models have been introduced in the literature to help assess and control quality. However, these models usually use metrics of classes (such as number of methods) or of relationships between classes (for example coupling) to measure internal attributes of systems. Yet, the quality of object-oriented systems does not depend on classes' metrics solely: it also depends on the organisation of classes, i.e. the system design that concretely manifests itself through design styles, such as design patterns and antipatterns. In this dissertation, we propose the method DEQUALITE to systematically build quality models that take into account the internal attributes of the systems (through metrics) but also their design (through design patterns and antipatterns). This method uses a machine learning approach based on Bayesian Belief Networks and builds on the results of a series of experiments aimed at evaluating the impact of design patterns and antipatterns on the quality of systems. These experiments, performed on 9 large object-oriented open source systems enable us to draw the following conclusions: • Counter-intuitively, design patterns do not always improve the quality of systems; tangled implementations of design patterns for example significantly affect the structure of classes and negatively impact their change- and fault-proneness. • Classes participating in antipatterns are significantly more likely to be subject to changes and to be involved in fault-fixing changes than other classes. • A non negligible percentage of classes participate in co-occurrences of antipatterns and design patterns in systems. On these classes, design patterns have a positive effect in mitigating antipatterns. We apply and validate our method on three open-source object-oriented systems to demonstrate the contribution of the design of system in quality assessment.

No description available.

Les logiciels sont en constante évolution, nécessitant une maintenance et un développement continus. Ils subissent des changements tout au long de leur vie, que ce soit pendant l'ajout de nouvelles fonctionnalités ou la correction de bogues. Lorsque les logiciels évoluent, leurs architectures ont tendance à se dégrader et deviennent moins adaptables aux nouvelles spécifications des utilisateurs. En effet, les architectures de ces logiciels deviennent plus complexes et plus difficiles à maintenir à cause des nombreuses dépendances entre les artefacts. Par conséquent, les développeurs doivent comprendre les dépendances entre les artefacts des logiciels pour prendre des mesures proactives qui facilitent les futurs changements et ralentissent la dégradation des architectures des logiciels. D'une part, le maintien d'un logiciel sans la compréhension des les dépendances entre ses artefacts peut conduire à l'introduction de défauts. D'autre part, lorsque les développeurs manquent de connaissances sur l'impact de leurs activités de maintenance, ils peuvent introduire des défauts de conception, qui ont un impact négatif sur l'évolution du logiciel. Ainsi, les développeurs ont besoin de mécanismes pour comprendre comment le changement d'un artefact impacte le reste du logiciel. Dans cette thèse, nous proposons trois contributions principales : La spécification de deux nouveaux patrons de changement et leurs utilisations pour fournir aux développeurs des informations utiles concernant les dépendances de co-changement. La spécification de la relation entre les patrons d'évolutions des artefacts et les fautes. La découverte de la relation entre les dépendances des anti-patrons et la prédisposition des différentes composantes d'un logiciel aux fautes. / Program maintenance accounts for the largest part of the costs of any program. During maintenance activities, developers implement changes (sometimes simultaneously) on artefacts to fix bugs and to implement new requirements. Thus, developers need knowledge to identify hidden dependencies among programs artefacts and detect correlated artefacts. As programs evolved, their designs become more complex over time and harder to change. In the absence of the necessary knowledge on artefacts dependencies, developers could introduce design defects and faults that causes development and maintenance costs to rise. Therefore, developers must understand the dependencies among program artefacts and take proactive steps to facilitate future changes and minimize fault proneness. On the one hand, maintaining a program without understanding the different dependencies between their artefacts may lead to the introduction of faults. On the other hand, when developers lack knowledge about the impact of their maintenance activities, they may introduce design defects, which have a negative impact on program evolution. Thus, developers need mechanisms to understand how a change to an artefact will impact the rest of the programs artefacts and tools to detect design defects impact. In this thesis, we propose three principal contributions. The first contribution is two novel change patterns to model new co-change and change propagation scenarios. We introduce the Asynchrony change pattern, corresponding to macro co-changes, i.e., of files that co-change within a large time interval (change periods), and the Dephase change pattern, corresponding to dephase macro co-changes, i.e., macro co-changes that always happen with the same shifts in time. We present our approach, named Macocha, and we show that such new change patterns provide interesting information to developers. The second contribution is proposing a novel approach to analyse the evolution of different classes in object-oriented programs and to link different evolution behaviour to faults. In particular, we define an evolution model for each class to study the evolution and the co-evolution dependencies among classes and to relate such dependencies with fault-proneness. The third contribution concerns design defect dependencies impact. We propose a study to mine the link between design defect dependencies, such as co-change dependencies and static relationships, and fault proneness. We found that the negative impact of design defects propagate through their dependencies. The three contributions are evaluated on open-source programs.

Les logiciels sont en constante évolution, nécessitant une maintenance et un développement continus. Ils subissent des changements tout au long de leur vie, que ce soit pendant l'ajout de nouvelles fonctionnalités ou la correction de bogues. Lorsque les logiciels évoluent, leurs architectures ont tendance à se dégrader et deviennent moins adaptables aux nouvelles spécifications des utilisateurs. En effet, les architectures de ces logiciels deviennent plus complexes et plus difficiles à maintenir à cause des nombreuses dépendances entre les artefacts. Par conséquent, les développeurs doivent comprendre les dépendances entre les artefacts des logiciels pour prendre des mesures proactives qui facilitent les futurs changements et ralentissent la dégradation des architectures des logiciels. D'une part, le maintien d'un logiciel sans la compréhension des les dépendances entre ses artefacts peut conduire à l'introduction de défauts. D'autre part, lorsque les développeurs manquent de connaissances sur l'impact de leurs activités de maintenance, ils peuvent introduire des défauts de conception, qui ont un impact négatif sur l'évolution du logiciel. Ainsi, les développeurs ont besoin de mécanismes pour comprendre comment le changement d'un artefact impacte le reste du logiciel. Dans cette thèse, nous proposons trois contributions principales : La spécification de deux nouveaux patrons de changement et leurs utilisations pour fournir aux développeurs des informations utiles concernant les dépendances de co-changement. La spécification de la relation entre les patrons d'évolutions des artefacts et les fautes. La découverte de la relation entre les dépendances des anti-patrons et la prédisposition des différentes composantes d'un logiciel aux fautes. / Program maintenance accounts for the largest part of the costs of any program. During maintenance activities, developers implement changes (sometimes simultaneously) on artefacts to fix bugs and to implement new requirements. Thus, developers need knowledge to identify hidden dependencies among programs artefacts and detect correlated artefacts. As programs evolved, their designs become more complex over time and harder to change. In the absence of the necessary knowledge on artefacts dependencies, developers could introduce design defects and faults that causes development and maintenance costs to rise. Therefore, developers must understand the dependencies among program artefacts and take proactive steps to facilitate future changes and minimize fault proneness. On the one hand, maintaining a program without understanding the different dependencies between their artefacts may lead to the introduction of faults. On the other hand, when developers lack knowledge about the impact of their maintenance activities, they may introduce design defects, which have a negative impact on program evolution. Thus, developers need mechanisms to understand how a change to an artefact will impact the rest of the programs artefacts and tools to detect design defects impact. In this thesis, we propose three principal contributions. The first contribution is two novel change patterns to model new co-change and change propagation scenarios. We introduce the Asynchrony change pattern, corresponding to macro co-changes, i.e., of files that co-change within a large time interval (change periods), and the Dephase change pattern, corresponding to dephase macro co-changes, i.e., macro co-changes that always happen with the same shifts in time. We present our approach, named Macocha, and we show that such new change patterns provide interesting information to developers. The second contribution is proposing a novel approach to analyse the evolution of different classes in object-oriented programs and to link different evolution behaviour to faults. In particular, we define an evolution model for each class to study the evolution and the co-evolution dependencies among classes and to relate such dependencies with fault-proneness. The third contribution concerns design defect dependencies impact. We propose a study to mine the link between design defect dependencies, such as co-change dependencies and static relationships, and fault proneness. We found that the negative impact of design defects propagate through their dependencies. The three contributions are evaluated on open-source programs.

Les changements sont faits de façon continue dans le code source des logiciels pour prendre en compte les besoins des clients et corriger les fautes. Les changements continus peuvent conduire aux défauts de code et de conception. Les défauts de conception sont des mauvaises solutions à des problèmes récurrents de conception ou d’implémentation, généralement dans le développement orienté objet. Au cours des activités de compréhension et de changement et en raison du temps d’accès au marché, du manque de compréhension, et de leur expérience, les développeurs ne peuvent pas toujours suivre les normes de conception et les techniques de codage comme les patrons de conception. Par conséquent, ils introduisent des défauts de conception dans leurs systèmes. Dans la littérature, plusieurs auteurs ont fait valoir que les défauts de conception rendent les systèmes orientés objet plus difficile à comprendre, plus sujets aux fautes, et plus difficiles à changer que les systèmes sans les défauts de conception. Pourtant, seulement quelques-uns de ces auteurs ont fait une étude empirique sur l’impact des défauts de conception sur la compréhension et aucun d’entre eux n’a étudié l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes. Dans cette thèse, nous proposons trois principales contributions. La première contribution est une étude empirique pour apporter des preuves de l’impact des défauts de conception sur la compréhension et le changement. Nous concevons et effectuons deux expériences avec 59 sujets, afin d’évaluer l’impact de la composition de deux occurrences de Blob ou deux occurrences de spaghetti code sur la performance des développeurs effectuant des tâches de compréhension et de changement. Nous mesurons la performance des développeurs en utilisant: (1) l’indice de charge de travail de la NASA pour leurs efforts, (2) le temps qu’ils ont passé dans l’accomplissement de leurs tâches, et (3) les pourcentages de bonnes réponses. Les résultats des deux expériences ont montré que deux occurrences de Blob ou de spaghetti code sont un obstacle significatif pour la performance des développeurs lors de tâches de compréhension et de changement. Les résultats obtenus justifient les recherches antérieures sur la spécification et la détection des défauts de conception. Les équipes de développement de logiciels doivent mettre en garde les développeurs contre le nombre élevé d’occurrences de défauts de conception et recommander des refactorisations à chaque étape du processus de développement pour supprimer ces défauts de conception quand c’est possible. Dans la deuxième contribution, nous étudions la relation entre les défauts de conception et les fautes. Nous étudions l’impact de la présence des défauts de conception sur l’effort nécessaire pour corriger les fautes. Nous mesurons l’effort pour corriger les fautes à l’aide de trois indicateurs: (1) la durée de la période de correction, (2) le nombre de champs et méthodes touchés par la correction des fautes et (3) l’entropie des corrections de fautes dans le code-source. Nous menons une étude empirique avec 12 défauts de conception détectés dans 54 versions de quatre systèmes: ArgoUML, Eclipse, Mylyn, et Rhino. Nos résultats ont montré que la durée de la période de correction est plus longue pour les fautes impliquant des classes avec des défauts de conception. En outre, la correction des fautes dans les classes avec des défauts de conception fait changer plus de fichiers, plus les champs et des méthodes. Nous avons également observé que, après la correction d’une faute, le nombre d’occurrences de défauts de conception dans les classes impliquées dans la correction de la faute diminue. Comprendre l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes est important afin d’aider les équipes de développement pour mieux évaluer et prévoir l’impact de leurs décisions de conception et donc canaliser leurs efforts pour améliorer la qualité de leurs systèmes. Les équipes de développement doivent contrôler et supprimer les défauts de conception de leurs systèmes car ils sont susceptibles d’augmenter les efforts de changement. La troisième contribution concerne la détection des défauts de conception. Pendant les activités de maintenance, il est important de disposer d’un outil capable de détecter les défauts de conception de façon incrémentale et itérative. Ce processus de détection incrémentale et itérative pourrait réduire les coûts, les efforts et les ressources en permettant aux praticiens d’identifier et de prendre en compte les occurrences de défauts de conception comme ils les trouvent lors de la compréhension et des changements. Les chercheurs ont proposé des approches pour détecter les occurrences de défauts de conception, mais ces approches ont actuellement quatre limites: (1) elles nécessitent une connaissance approfondie des défauts de conception, (2) elles ont une précision et un rappel limités, (3) elles ne sont pas itératives et incrémentales et (4) elles ne peuvent pas être appliquées sur des sous-ensembles de systèmes. Pour surmonter ces limitations, nous introduisons SMURF, une nouvelle approche pour détecter les défauts de conception, basé sur une technique d’apprentissage automatique — machines à vecteur de support — et prenant en compte les retours des praticiens. Grâce à une étude empirique portant sur trois systèmes et quatre défauts de conception, nous avons montré que la précision et le rappel de SMURF sont supérieurs à ceux de DETEX et BDTEX lors de la détection des occurrences de défauts de conception. Nous avons également montré que SMURF peut être appliqué à la fois dans les configurations intra-système et inter-système. Enfin, nous avons montré que la précision et le rappel de SMURF sont améliorés quand on prend en compte les retours des praticiens. / Changes are continuously made in the source code to take into account the needs of the customers and fix the faults. Continuous change can lead to antipatterns and code smells, collectively called “design smells” to occur in the source code. Design smells are poor solutions to recurring design or implementation problems, typically in object-oriented development. During comprehension and changes activities and due to the time-to-market, lack of understanding, and the developers’ experience, developers cannot always follow standard designing and coding techniques, i.e., design patterns. Consequently, they introduce design smells in their systems. In the literature, several authors claimed that design smells make object-oriented software systems more difficult to understand, more fault-prone, and harder to change than systems without such design smells. Yet, few of these authors empirically investigate the impact of design smells on software understandability and none of them authors studied the impact of design smells on developers’ effort. In this thesis, we propose three principal contributions. The first contribution is an empirical study to bring evidence of the impact of design smells on comprehension and change. We design and conduct two experiments with 59 subjects, to assess the impact of the composition of two Blob or two Spaghetti Code on the performance of developers performing comprehension and change tasks. We measure developers’ performance using: (1) the NASA task load index for their effort; (2) the time that they spent performing their tasks; and, (3) their percentages of correct answers. The results of the two experiments showed that two occurrences of Blob or Spaghetti Code design smells impedes significantly developers performance during comprehension and change tasks. The obtained results justify a posteriori previous researches on the specification and detection of design smells. Software development teams should warn developers against high number of occurrences of design smells and recommend refactorings at each step of the development to remove them when possible. In the second contribution, we investigate the relation between design smells and faults in classes from the point of view of developers who must fix faults. We study the impact of the presence of design smells on the effort required to fix faults, which we measure using three metrics: (1) the duration of the fixing period; (2) the number of fields and methods impacted by fault-fixes; and, (3) the entropy of the fault-fixes in the source code. We conduct an empirical study with 12 design smells detected in 54 releases of four systems: ArgoUML, Eclipse, Mylyn, and Rhino. Our results showed that the duration of the fixing period is longer for faults involving classes with design smells. Also, fixing faults in classes with design smells impacts more files, more fields, and more methods. We also observed that after a fault is fixed, the number of occurrences of design smells in the classes involved in the fault decreases. Understanding the impact of design smells on development effort is important to help development teams better assess and forecast the impact of their design decisions and therefore lead their effort to improve the quality of their software systems. Development teams should monitor and remove design smells from their software systems because they are likely to increase the change efforts. The third contribution concerns design smells detection. During maintenance and evolution tasks, it is important to have a tool able to detect design smells incrementally and iteratively. This incremental and iterative detection process could reduce costs, effort, and resources by allowing practitioners to identify and take into account occurrences of design smells as they find them during comprehension and change. Researchers have proposed approaches to detect occurrences of design smells but these approaches have currently four limitations: (1) they require extensive knowledge of design smells; (2) they have limited precision and recall; (3) they are not incremental; and (4) they cannot be applied on subsets of systems. To overcome these limitations, we introduce SMURF, a novel approach to detect design smells, based on a machine learning technique—support vector machines—and taking into account practitioners’ feedback. Through an empirical study involving three systems and four design smells, we showed that the accuracy of SMURF is greater than that of DETEX and BDTEX when detecting design smells occurrences. We also showed that SMURF can be applied in both intra-system and inter-system configurations. Finally, we reported that SMURF accuracy improves when using practitioners’ feedback.

No description available.