SAD stands for Software Architectural Defects and is our implementation of DETEX, following the DECOR method to specify and identify occurrences of anti-patterns in PADL models. A paper introducing DETEX and DECOR has been published by Moha, Guéhéneuc, Duchien, and Le Meur and can be used as reference.
| Names | Definitions |
|---|---|
| AntiSingleton | A class that provides mutable class variables, which consequently could be used as global variables. |
| BaseClassKnowsDerivedClass | A class that invokes or has at least binary-class relationship pointing to one of its subclasses. |
| BaseClassShouldBeAbstract | A class that has many subclasses without being abstract. |
| Blob | A large controller class that depends on data stored in surrounding data classes. A large class declares many fields and methods with a low cohesion. A controller class monopolises most of the processing done by a system, takes most of the decisions, and closely directs the processing of other classes. Controller classes can be identified using suspicious names such as Process, Control, Manage, System, and so on. A data class contains only data and performs no processing on these data. It is composed of highly cohesive fields and accessors. |
| ClassDataShouldBePrivate | A class that exposes its fields, thus violating the principle of encapsulation. |
| ComplexClass | A class that has (at least) one large and complex method, in terms of cyclomatic complexity and LOCs. |
| FunctionalDecomposition | A main class, i.e., a class with a procedural name, such as Compute or Display, in which inheritance and polymorphism are scarcely used, that is associated with small classes, which declare many private fields and implement only a few methods. |
| LargeClass | A class that has grown too large in term of LOCs. |
| LazyClass | A class that has few fields and methods. |
| LongMethod | A class that has (at least) a method that is very long, in term of LOCs. |
| LongParameterList | A class that has (at least) one method with a too long list of parameters in comparison to the average number of parameters per methods in the system. |
| ManyFieldAttributesButNotComplex | A class that declares many attributes but which is not complex and, hence, more likely to be some kind of data class holding values without providing behaviour. |
| MessageChains | A class that uses a long chain of method invocations to realise (at least) one of its functionality. |
| RefusedParentBequest | A class that redefines inherited method using empty bodies, thus breaking polymorphism. |
| SpaghettiCode | A class with no structure, declaring long methods with no parameters, and utilising global variables. The names of the class and methods may suggest procedural programming. It does not exploit and prevents the use of object-orientation mechanisms, polymorphism, and inheritance. |
| SpeculativeGenerality | A class that is defined as abstract but that has very few children, which do not make use of its methods. |
| SwissArmyKnife | A complex class that offers a high number of services, for example, a complex class implementing a high number of interfaces. A Swiss Army Knife is different from a Blob, because it exposes a high complexity to address all foreseeable needs of a part of a system, whereas the Blob is a singleton monopolising all processing and data of a system. Thus, several Swiss Army Knives may exist in a system, for example utility classes. |
| TraditionBreaker | A class that inherits from a large parent class but that provides little behaviour and without subclasses. |
The generation of code and design smell identification algorithms is straightforward. Class sad.rule.creator.RULECreator expects to find rule cards, i.e., files with extensions .rule in the rsc directory of project SAD Rules Creator. It provides a main method that iterates through all the rule cards and generates the corresponding identification algorithms into the SAD project. Once the generation process done, refresh and compile the SAD project and the new identification algorithms are available.
Identifying code and design smells using PADL is made easy by the helper class sad.helper.SmellsIdentifier. After having installed CPL, PADL, and POM, just go into the SAD Tests project and have a look at this class. It provides a main method with snippets of code to call the method analyseIdiomLevelModel(String[], String, IIdiomLevelModel, String), which handles all the details. Also have a look at the constant array listing the smells that must be identified or avoided: SMELLS_TO_IDENTIFY.
SAD requires POM to compute various metrics involved in the definitions of the code and design smells. These metrics are referenced by name in the rule cards, for example:
RULE_CARD : ComplexClass {
RULE : ComplexClass { UNION LargeClassOnly ComplexClassOnly } ;
RULE : LargeClassOnly { (METRIC: NMD + NAD, VERY_HIGH, 0) } ;
RULE : ComplexClassOnly { (METRIC: McCabe, VERY_HIGH, 20) } ;
};