Analysing Anti-patterns Static Relationships with Design Patterns

Anti-patterns are motifs that are usually thought to be good solutions tosome design or implementation problems, but back-fires badly when applied. Previousstudies have reported that anti-patterns make object oriented systems hard tomaintain. Anti-patterns motifs usually have dependencies with other classes in thesystem. In this paper, we propose to analyse these dependencies (with in particulardesign patterns) in order to understand how developers can maintain programscontaining anti-patterns. To the best of our knowledge, no substantial investigationof anti-pattern dependencies with design patterns has been done before. This paperpresents the results of a study that we performed on three different systems, ArgoUML,JFreeChart, and XercesJ, written in Java, and of size ranges from 1,191to 3,325 classes, to analyse the static relationships between anti-patterns and designpatterns. We found that these relationships (1) exist, but (2) are temporaryand (3) classes participating in such relationships are more change-prone but lessfault-prone than other anti-pattern classes

Analysing artefacts dependencies to evolving software systems

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

Are Multi-language Design Smells Fault-prone? An Empirical Study

Nowadays, modern applications are developed using components written in different programming languages. These systems introduce several advantages. However, as the number of languages increases, so does the challenges related to the development and maintenance of these systems. In such situations, developers may introduce design smells (i.e., anti-patterns and code smells) which are symptoms of poor design and implementation choices. Design smells are defined as poor design and coding choices that can negatively impact the quality of a software program despite satisfying functional requirements. Studies on mono-language systems suggest that the presence of design smells affects code comprehension, thus making systems harder to maintain. However, these studies target only mono-language systems and do not consider the interaction between different programming languages. In this paper, we present an approach to detect multi-language design smells in the context of JNI systems. We then investigate the prevalence of those design smells. Specifically, we detect 15 design smells in 98 releases of nine open-source JNI projects. Our results show that the design smells are prevalent in the selected projects and persist throughout the releases of the systems. We observe that in the analyzed systems, 33.95% of the files involving communications between Java and C/C++ contains occurrences of multi-language design smells. Some kinds of smells are more prevalent than others, e.g., Unused Parameters, Too Much Scattering, Unused Method Declaration. Our results suggest that files with multi-language design smells can often be more associated with bugs than files without these smells, and that specific smells are more correlated to fault-proneness than others

On the relation between architectural smells and source code changes

Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open-source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts

Detailed Overview of Software Smells

This document provides an overview of literature concerning software smells covering various dimensions of smells along with their corresponding references

Zones of pain:Visualising the relationship between software architecture and defects

Substantial development time is devoted to software maintenance and testing. As development resources are usually finite, there is a risk that some components receive insufficient effort for thorough testing. Architectural complexity (e.g. tight coupling) can make effective testing particularly challenging. Software components with high architectural complexity are more likely be defect–prone. The aim of this study is to investigate the relationship between established architectural attributes and defect–proneness. We used the architectural attributes: abstractness, instability and distance to measure the architectural complexity of software components. We investigated the ability of these attributes to discriminate between defective and non-defective components on four open source systems. We visualised defect–proneness by plotting architectural complexity and defectiveness using Martin’s ‘Zones of Pain’. Our results show that architecture has an inconsistent impact on defect–proneness. Some architecturally complex components seem immune to defects in some projects. In other projects architecturally complex components significantly suffer from defects. Where architectural complexity does increase defect–proneness the impact is strong. We recommend practitioners monitor the architectural complexity of their software components over time by visualising potential defect–proneness using Martin’s Zones of Pain