FAQ

1. What are design smells and why we should worry about them?

(click to expand/collapse)
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.

2. What design smells are supported by Designite?

(click to expand/collapse)
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.

3. What architecture smells are supported by Designite?

(click to expand/collapse)
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.

4. Why the names of supported design smells by Designite are quite different from commonly known names?

(click to expand/collapse)
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”.

5. Which implementation smells are supported by Designite?

(click to expand/collapse)
  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

6. What metrics are supported by Designite?

(click to expand/collapse)
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.

7. How metric violations are computed?

(click to expand/collapse)
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.

8. What thresholds Designite uses to compute metric violations?

(click to expand/collapse)
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

9. What is the threshold used by Designite for code clones detection?

(click to expand/collapse)
Designite currently uses 20 lines as a threshold to detect code clones.

10. Is Designite’s trial license fully functional?

(click to expand/collapse)
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.

11. Is Designite available for other languages?

(click to expand/collapse)
No. Currently, Designite only supports C#.

12. Do you offer a floating license?

(click to expand/collapse)
No, currently we do not offer a floating license.

13. How can I buy the license of Designite?

(click to expand/collapse)
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.

14. Do you offer any discount to students/researchers?

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

15. Which .NET version is required to execute Designite.

(click to expand/collapse)
You need .NET 4.0 or above to execute Designite.

16. After analysis, Designite is reporting that it could not analyze X out of Y projects. Why?

(click to expand/collapse)
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.

17. I am trying to export the analyzed results in MS Excel format but it is not working. What is wrong?

(click to expand/collapse)
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.

18. I have a professional license of Designite. Am I eligible for future updates of the software?

(click to expand/collapse)
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).

19. Is auto update supported by Designite?

(click to expand/collapse)
Yes. You may check for update within the application and initiate the auto-update.

20. How to report a bug?

(click to expand/collapse)
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.