FAQ

We adopted the following definition from “Refactoring for Software Design Smells: Managing Technical Debt” book by Girish et al. – "Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality."

We need to care about smells because smells negatively impact software quality. The presence of design smells reduces understandability, changeability, and flexibility leading to a software system difficult to understand and change. Such characteristics increase the cost of change over a period of time for the software. In addition, design smells make the software difficult to test and in turn, impacts reliability of the software.

Currently, Designite detects various design smells pertaining to Abstraction, Encapsulation, Modularization, and Hierarchy categories. At the time of writing this document, Designite supports 19 design smells which make Designite the most comprehensive design smells detector.

The list of supported design smells is given below:

Abstraction Design Smells

Imperative Abstraction: This smell arises when an operation is turned into a class.
Unnecessary Abstraction: This smell occurs when an abstraction that is actually not needed (and thus could have been avoided) gets introduced in a software design.
Multifaceted Abstraction: This smell arises when an abstraction has more than one responsibility assigned to it.
Unutilized Abstraction: This smell arises when an abstraction is left unused (either not directly used or not reachable).
Duplicate Abstraction: This smell arises when two or more abstractions have identical names or identical implementation or both.

Encapsulation Design Smells

Deficient Encapsulation: This smell occurs when the declared accessibility of one or more members of an abstraction is more permissive than actually required.
Unexploited Encapsulation: This smell arises when client code uses explicit type checks (using chained if-else or switch statements that check for the type of the object) instead of exploiting the variation in types already encapsulated within a hierarchy.

Modularization Design Smells

Broken Modularization: This smell arises when data and/or methods that ideally should have been localized into a single abstraction are separated and spread across multiple abstractions.
Insufficient Modularization: This smell arises when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both.
Hub-like Modularization: This smell arises when an abstraction has dependencies (both incoming and outgoing) with a large number of other abstractions.
Cyclically-dependent Modularization: This smell arises when two or more abstractions depend on each other directly or indirectly (creating a tight coupling between the abstractions).

Hierarchy Design Smells

Wide Hierarchy: This smell arises when an inheritance hierarchy is “too” wide indicating that intermediate types may be missing.
Deep Hierarchy: This smell arises when an inheritance hierarchy is “excessively” deep.
Multipath Hierarchy: This smell arises when a subtype inherits both directly as well as indirectly from a supertype leading to unnecessary inheritance paths in the hierarchy.
Cyclic Hierarchy: This smell arises when a supertype in a hierarchy depends on any of its subtypes.
Rebellious Hierarchy: This smell arises when a subtype rejects the methods provided by its supertype(s).
Unfactored Hierarchy: This smell arises when there is unnecessary duplication among types in a hierarchy.
Missing Hierarchy: This smell arises when a code segment uses conditional logic (typically in conjunction with “tagged types”) to explicitly manage variation in behavior where a hierarchy could have been created and used to encapsulate those variations.
Broken Hierarchy: This smell arises when a supertype and its subtype conceptually do not share an “IS-A” relationship resulting in broken substitutability.

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

The  following architecture smells are detectable by Designite:
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.

Many smells are referred by different names by different individuals. We have adopted the classification and catalog proposed by Girish et al. in their book “Refactoring for Software Design Smells”. It is quite possible that you know the smell by some other name that we support; for instance, Designite detects “God Class” design smell which we refer as “Insufficient Modularization”.

  1. Long Method
  2. Complex Method
  3. Long Parameter List
  4. Long Identifier
  5. Long Statement
  6. Complex Conditional
  7. Virtual Method Call from Constructor
  8. Empty Catch Block
  9. Magic Number
  10. Duplicate Code
  11. Missing Default
Designite supports metrics at various abstraction levels – Key metrics at solution-level, Key metrics at project-level, Class-level metrics, and Method-level metrics.

Here is the list of currently supported metrics:

Key metrics at solution-level

LOC (Total Lines Of Code): Total number of lines of code in the analyzed projects.
NON (Total No Of Namespaces): Total number of namespaces in the analyzed projects.
NOC (Total No Of Classes): Total number of classes in the analyzed projects.
NOM (Total No Of Methods): Total number of methods in the analyzed projects.
MV (Total No of Metric Violations): Total number of metric violations (where the value of a metric is more than the recommended threshold) in the analyzed projects.
SD (Total Smell Density): Total smell density per KLOC in the analyzed projects.
DUP (Total Percentage Duplication): Total percentage of duplicated lines in the analyzed projects.

Key metrics at project-level

NON (No Of Namespaces): Number of namespaces in the project.
NOC (No Of Classes): Number of classes in the project.
NOM (No Of Methods): Number of methods in the project.
LOC (Lines Of Code): Number of lines of code in the project.
MV (No of Metric Violations): Number of metric violations (where the value of a metric is more than the recommended threshold) in the project.
DDS (No of Detected Design Smells): Number of detected design smells in the project.
SD (Smell Density): Smell density per KLOC in the project.
DUP (Percentage Duplication): Percentage of duplicated lines in the project.

Class-level Metrics

NOF (Number Of Fields): Total number of fields in the class.
NOM (Number Of Methods): Total number of methods in the class.
NOP (Number Of Properties): Total number of properties in the class.
NOPF (Number of Public Fields): Total number of public fields in the class.
NOPM (Number of Public Methods): Total number of public methods in the class.
LOC (Lines of Code): Total number of source-code lines in the class.
WMC (Weighted Methods per Class): The sum of cyclomatic complexities of all the methods belonging to the class.
NC (Number of Children): Total number of children (sub-classes) of the class.
DIT (Depth of Inheritance Tree): It is the maximum inheritance path from this class to the root class.
LCOM (Lack of Cohesion of Methods): It measures the cohesion of the class; it is the correlation between the methods and the instance variables of the class.
FANIN (Fan-in): Total number of classes that reference the class (in-coming dependencies).
FANOUT (Fan-out): Total number of classes referenced by the class (out-going dependencies).

Method-level Metrics

LOC (Lines Of Code): Total number of source-code lines in the method.
CC (Cyclomatic Complexity): Cyclomatic Complexity directly measures the number of linearly independent paths through a program’s source code.
PC (Parameter Count): Total number of parameters in the method.

Designite has defined thresholds for each class-level and method-level metric. Whenever, the value of the metric crosses the corresponding threshold, Designite marks it as a metric violation.

Designite has defined thresholds for each class-level and method-level metric. Whenever, the value of the metric crosses the corresponding threshold, Designite marks it as a metric violation.

Class-level metrics

NOF – 20
NOM – 30
NOP – 20
NOPF – 0

NOPM – 20
LOC – 1000
WMC – 100
NC – 10
DIT – 6
LCOM – 0.8
FANIN – 20
FANOUT – 20

Method-level metrics

LOC – 100
CC – 8
PC – 5

Designite currently uses 20 lines as a threshold to detect code clones.

No. Trial version is for evaluating the tool in your context on a smaller scale. If you analyze a project with more than 50,000 LOC than you can see the summary but you cannot see the detected design smells and other information in detail. In addition, you cannot use some features such as “Export” with trial version.

Yes. Currently, we offer Designite (for C#) and DesigniteJava (for Java).

No, currently we do not offer a floating license.

You can buy the license online or offline. To buy the license online, follow the instructions given on the Buy page. Once we receive the payment, we respond within a day for further instructions to generate your Designite Professional license.

You may buy the license offline also either directly from us or via software resellers. The process is essentially same after we receive the payment. Write to us at contact@designite-tools.com if you wish to know more about it.

Yes. We offer a special license viz. “Academic” license to students and researchers for free. This license provides all the features without any restriction.

You need .NET 4.7 or above to execute Designite.

Designite needs to be installed in a developer machine with a fully functional development environment. If you install Designite on a bare machine which is not used for development, you may get such messages. If you have to analyze your code in such non-developer machines, you may need to setup the required environment (such as environment variables) for your project before initiating the analysis.

The MS Excel export functionality of Designite requires MS-Excel installation to work. If your machine does not have MS-Excel then you may not be able to export the results.

All customers who have purchased a Professional license of Designite are eligible for free updates of the software as far as the major version of the purchased license and the update is same. Therefore, if you have bought a Designite license for version 1.10.0 and the version of the new update is 1.21.2, then you are eligible to receive the update (since the major version is 1).

Yes. You may check for update within the application and initiate the auto-update.

You may report a bug to us by emailing the details at contact@designite-tools.com. Add as much as information you can (such as logs, and screenshots) to help us resolve the problem early.