In recent years, there has been a surge in research on theimpact of architectural smells on software maintainability.Maintainability in turn encompasses several other qualityattributes as sub-characteristics, such as modularity andtestability. However, the empirical evidence establishing aclear relationship between these quality attributes andarchitectural smells has been lacking. This study aims to fillthis gap by examining the correlation between sevenarchitectural smells and testability/modularity across 378versions of eight open-source projects. A self-developedtool—ASAT—was used to collect data on architecturalsmells and metrics relating to modularity and testability. Thecollected data was analyzed to reveal correlations at both theproject-level and within packages. Contrary to expectations,the findings show that, generally, there is no negativecorrelation between smells and modularity at the projectlevel, except for the Dense Structure smell. Remarkably,project-level testability showed the opposite result.However, a rival explanation proposes that the increasingsize of a project may be a stronger factor in this relationship.Similarly, package-level smells, as a whole, did not exhibit anegative correlation with testability. However, most smellsdemonstrated a stronger negative relationship with thequality attributes they were claimed to impair, incomparison to their counterparts. This empirical evidencesubstantiates the assertion that specific architectural smellsindeed relate to distinct quality attributes, which hadpreviously only been supported by argument.

Deficiencies in software design or architecture can severely impede and slow down the software development and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have been proposed to assist software engineers in identifying smells and guiding them through corresponding refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend to produce false positives which represent conscious constructs with symptoms similar or identical to actual bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design review in order to identify (missed) design smells and/or re-assess detected smell candidates. UML diagrams are the quasi-standard for documenting software design and are often available in software projects. In this position paper, we investigate whether (and to what extent) UML diagrams can be used for identifying and assessing design smells. Based on a description of difficulties in the smell detection process, we discuss the importance of design reviews. We then investigate to what extent design documentation in terms of UML2 diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss further challenges for UML-based identification and assessment of bad smells.