Features

Architecture smells detection

The quality of your architecture decides vital quality parameters of your software product. DesigniteJava detects various architecture smells in your code to help you improve the agility of your software.

  • Cyclic Dependency: This smell arises when two or more architecture components depend on each other directly or indirectly.

  • Unstable Dependency: This smell arises when a component depends on other components that are less stable than itself.

  • Ambiguous Interface: This smell arises when a component offers only a single, general entry-point into the component.

  • God Component: This smell occurs when a component is excessively large either in the terms of LOC or number of classes.

  • Feature Concentration: This smell occurs when a component realizes more than one architectural concern/feature.

  • Scattered Functionality: This smell arises when multiple components are responsible for realizing the same high-level concern.

  • Dense Structure: This smell arises when components have excessive and dense dependencies without any particular structure.

Design smells detection

Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.” (from Refactoring for Software Design Smells: Managing Technical Debt)

DesigniteJava identifies design smells and presents them in a view that classifies them based on the fundamental principle they violate. In addition, DesigniteJava also points out the cause of the smell and therefore provides a clue towards refactoring of the smell.

The following design smells are detectable by DesigniteJava:

  • Abstraction Design Smells: Imperative Abstraction, Unnecessary Abstraction, Multifaceted Abstraction, Unutilized Abstraction, Feature Envy.

  • Encapsulation Design Smells: Deficient Encapsulation, Unexploited Encapsulation.

  • Modularization Design Smells: Broken Modularization, Insufficient Modularization, Hub-like Modularization, Cyclically-dependent Modularization.

  • Hierarchy Design Smells: Wide Hierarchy, Deep Hierarchy, Multipath Hierarchy, Cyclic Hierarchy, Rebellious Hierarchy, Missing Hierarchy, Broken Hierarchy.

Detect implementation smells

DesigniteJava supports variety of smells that may occur at implementation level as well. Refactoring these smells lead to better code quality. DesigniteJava supports detection of the following implementation smells:

  • Abstract Function Call From Constructor

  • Complex Conditional

  • Complex Method

  • Empty catch clause

  • Long Identifier

  • Long Method

  • Long Parameter List

  • Long Statement

  • Magic Number

  • Missing default

Detect testability smells

Testability refers to the degree to which the development of test cases can be facilitated by the software design choices. DesigniteJava supports the following testability smells.

  • Hard-wired dependencies

  • Global state

  • Excessive dependency

  • Law of Demeter violation

Find more information about testability smells in this paper.

Detect test smells

Test smells are defined as bad programming practices in unit test code that indicate potential design problems in the test code. DesigniteJava supports the following test smells.

  • Assertion roulette

  • Conditional test logic

  • Constructor initialization

  • Eager test

  • Empty test

  • Exception handling

  • Ignored test

  • Unknown test

Compute object-oriented metrics

DesigniteJava computes object-oriented design metrics that are helpful to gauge the structural health of the software project. A list of supported metrics by DesigniteJava is presented below.

  • LOC: Lines Of Code in a method or a class. We consider all lines in a method or class body, including empty lines and lines with comments.

  • CC: DesigniteJava uses traditional definition (i.e., number of unique complete paths in a method) of Cyclomatic Complexity to measure code complexity of a method.

  • PC: Parameter Count in a method.

  • NOF: Number of Fields i.e., member variables, both static and instance variables, of a class.

  • NOPF: Number of Public Fields i.e., public member variables of a class.

  • NOM: Number of Methods defined in a class irrespective of their accessibility modifier.

  • NOPM: Number of Public Methods defined in a class.

  • WMC: Weighted Methods per Class is the sum of cyclomatic complexities of all methods in the class.

  • NC: Number of Children of a class represents the number of classes inherited from the class.

  • DIT: Depth of Inheritance Tree of a class represents the number of ancestors (i.e., supertypes) in the inheritance hierarchy up to the class.

  • LCOM: Lack of Cohesion in Methods is a measure of lack of cohesion of a class. The implementation follows a custom implementation to avoid the problems of existing LCOM alternatives. Traditionally, LCOM value may range only between 0 and 1. However, there are many cases, when computing LCOM is not feasible and traditional implementations give value 0 giving us a false sense of satisfaction (that the class is perfectly cohesive). Therefore, this impelementation emits -1 for such cases indicating that we do not have enough information or LCOM is not applicable (for instance, for an interface). Find more information in this paper.

  • FANIN: Fan-in of a class represents the number of incoming unique dependencies.

  • FANOUT: Fan-out of a class represents the number of outcoming unique dependencies.