How to identify maintainability issues in your C# codebase and start improving design agility? Here is a quick start guide for Designite that could help you achieve your goal of quality.

1. QUICK START GUIDE
Document version 1.1

2. CONTENTS
1. INTRODUCTION TO DESIGNITE ........................... 1
1.1. Why you need Designite ..........................................................................1
1.2. Features ................................................................................................1
1.2.1. Detect Design Smells ..........................................................................1
1.2.2. Compute Metrics.................................................................................2
1.2.3. Analyze Trend ....................................................................................3
1.2.4. Smell Distribution (Treemap) ...............................................................3
1.2.5. Dependency Structure Matrix (DSM) .....................................................3
1.2.6. Detect Implementation Smells..............................................................3
1.2.7. Identify Code Clones ...........................................................................3
1.2.8. Console Application .............................................................................3
1.2.9. Customize Your Quality Analysis ...........................................................4
1.2.10. Identify Hotspots .............................................................................4
1.2.11. Export Results .................................................................................4
1.2.12. Summary of Design Quality Analysis ..................................................4
1.3. How to Download and Install ....................................................................4
1.3.1. System Requirements .........................................................................4
2. GETTING STARTED............................................... 5
2.1. Detecting Design Smells Using Designite....................................................5
2.2. Using Sunburst Diagram for easier navigation and filtering...........................6
2.3. Understanding Software Metrics and Computing them Using Designite...........8
2.3.1. Size Metrics........................................................................................9
2.3.2. Complexity Metrics............................................................................10
2.3.3. Cohesion and Coupling Metrics ...........................................................10
2.3.4. Computing and Analyzing Software Metrics ..........................................11

3. 2.4. Analyzing Trend of Smells using Designite................................................12
2.5. Using the Power of Designite’s Console Application....................................17
2.5.1. Analyze C# Solutions/Projects ............................................................17
2.5.2. Trend Analysis..................................................................................18
2.5.3. Trend Analysis for GIT Repositories .....................................................20
2.6. Revealing the Distribution of Smells in Designite using Treemap .................21
2.7. Customize your Quality Analysis .............................................................22
2.7.1. Metric Threshold Customization ..........................................................23
2.7.2. Customize Smell Detection.................................................................23
2.7.3. Custom Analysis Using Console Application ..........................................24
3. CONTACT US ...................................................... 28

4. 1
1.INTRODUCTION TO DESIGNITE
Designite is a software design quality assessment tool for C#. Equipped with
many comprehensive features and visualization support, Designite assesses
the design quality of a software system and helps improve the design agility
of the software.
1.1. WHY YOU NEED DESIGNITE
Software design is an inherently complex activity that requires sound
knowledge of design principles and more importantly their skilful application.
A study of five organizations1 reported the number of software defects that
can be traced back to errors in software design as high as 64%. This statistic
highlights the importance of software design in software development. Despite
this, it is very common to see real-life projects suffering from poor design
quality and huge technical debt. Such issues significantly reduce
maintainability of the software.
Maintainability is a critical quality dimension for large companies relying on
large software systems. In the context of constantly changing environment, it
is hard to keep the maintainability high. Designite reveals the potential
maintainability problems (smells) not only at implementation granularity but
also at design granularity. Knowing treats to maintainability i.e. smells is an
important step towards keeping the maintenance high of a software system.
1.2. FEATURES
Designite supports following features in your pursuit to achieve high design
agility and reduce technical debt of your software system.
1.2.1. DETECT DESIGN SMELLS
Designite detects various design smells in your code to help you manage your
“design debt”.
“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)
Designite identifies design smells and presents them in a view that classifies
them based on the fundamental principle they violate. In addition, Designite
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 Designite:
1
http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf

5. 2
1.1.1.1. ABSTRACTION DESIGN SMELLS
Imperative Abstraction, Unnecessary Abstraction, Multifaceted Abstraction,
Unutilized Abstraction, Duplicate Abstraction.
1.1.1.2. ENCAPSULATION DESIGN SMELLS
Deficient Encapsulation, Unexploited Encapsulation.
1.1.1.3. MODULARIZATION DESIGN SMELLS
Broken Modularization, Insufficient Modularization, Hub-like Modularization,
Cyclically-dependent Modularization.
1.1.1.4. HIERARCHY DESIGN SMELLS
Wide Hierarchy, Deep Hierarchy, Multipath Hierarchy, Cyclic Hierarchy,
Rebellious Hierarchy, Unfactored Hierarchy, Missing Hierarchy.
Please note that the Designite follows classification proposed by “Refactoring
for Software Design Smells: Managing Technical Debt” by Girish
Suryanarayana, Ganesh Samarthyam, and Tushar Sharma.
1.2.2. COMPUTE METRICS
Designite computes object-oriented design metrics that are helpful to gauge
the structural health of the software project. Designite classifies these metrics
in four categories: solution-level metrics, project-level metrics, method-level
metrics and class-level metrics. Designite highlights specific metric values that
violate metric threshold as a metric violation in a different color to help you
spot the violations.
1.2.2.1. SOLUTION-LEVEL METRICS
LOC (Lines Of Code), NON (Number Of Namespaces), NOC (Number Of
Classes), NOM (Number Of Methods), MV (Metrics Violations), SD (Smell
Density), DUP (Code Duplication).
1.2.2.2. PROJECT-LEVEL METRICS
LOC (Lines Of Code), NON (Number Of Namespaces), NOC (Number Of
Classes), NOM (Number Of Methods), MV (Metrics Violations), SD (Smell
Density), DUP (Code Duplication), DDS (Detected Design Smells).
1.2.2.3. CLASS-LEVEL METRICS
NOF (Number Of Fields), NOM (Number Of Methods), NOP (Number Of
Properties), NOPF (Number of Public Fields), NOPM (Number of Public Methods),
LOC (Lines of Code), WMC (Weighted Methods per Class), NC (Number of
Children), DIT (Depth of Inheritance Tree), LCOM (Lack of Cohesion of
Methods), FANIN (Fan-in), FANOUT (Fan-out).
1.2.2.4. METHOD-LEVEL METRICS
LOC (Lines Of Code), CC (Cyclomatic Complexity), PC (Parameter Count).

6. 3
1.2.3. ANALYZE TREND
Designite supports “trend analysis” to reveal evolution of software from the
smells perspective. Specifically, the trend shows how many smells (both design
and implementation) have been introduced, remained, and removed from one
version to another. It is useful when the development team wanted to observe
the quality of the software especially after a refactoring cycle.
1.2.4. SMELL DISTRIBUTION (TREEMAP)
Designite allows the user to see the distribution of design and implementation
smells using Treemap. The smell treemap shows two dimensions – size of
classes/namespace and corresponding severity of smell density. The diagram
shows severity of smell density using intuitive color scheme; smell density
increases from green to red.
1.2.5. DEPENDENCY STRUCTURE MATRIX (DSM)
The Dependency Structure Matrix (DSM) is a compact and visual
representation of dependencies (with corresponding strength) among software
system entities (such as Type, Namespace, or Project) in the form of a square
matrix. Designite offers an interactive and simple yet effective implementation
of DSM.
1.2.6. DETECT IMPLEMENTATION SMELLS
Designite supports variety of smells that may occur at implementation level as
well (in addition to design smells). Refactoring these smells lead to better code
quality. Designite supports detection of the following implementation smells:
Long Method, Complex Method, Long Parameter List, Long Identifier, Long
Statement, Complex Conditional, Virtual Method Call from Constructor, Empty
Catch Block, Magic Number, Duplicate Code, Missing Default.
1.2.7. IDENTIFY CODE CLONES
Designite detects code duplication in your code and reports design smells
based on the identified clones. The identified code clones can be further
analyzed manually by exploring the excel sheet generated by Designite that
contains information associated with code clones along with the identified
design smells and metrics.
1.2.8. CONSOLE APPLICATION
Designite provides a console application with various options to allow
integration with external tools. For instance, one can integrate Designite with
SonarQube to see the design smells detected by Designite in SonarQube.
The new console application not only supports previously supported
functionality (analyze projects and export results in MS Excel, XML, or CSV
formats) but also allows a user to carry out trend analysis with a rich set of
options.

7. 4
1.2.9. CUSTOMIZE YOUR QUALITY ANALYSIS
Every piece of code is different in terms of domain, context, and its quality
requirements. Measuring quality aspects of all the software systems using the
same stick is not appropriate and often not desirable. Keeping it in mind,
Designite has introduced a new feature “Preferences” in version 1.33.0 to allow
users to customize their analysis by selecting thresholds based on their context
and requirements.
1.2.10. IDENTIFY HOTSPOTS
The hotspot analysis assigns a “Hotspot score” to each class based on the
detected design smells in the class and highlights the classes that you may
choose for refactoring first.
1.2.11. EXPORT RESULTS
Designite allows you to export the analyzed information (detected smells and
computed metrics). Three export formats are available to choose from: MS
Excel, XML, and CSV. This extremely useful feature allows you to share the
result of the tool with other stakeholders in your team and analyze the results
further.
1.2.12. SUMMARY OF DESIGN QUALITY ANALYSIS
Designite analyzes design of your software and presents the summary of the
analysis in a graphical form. The summary shows two bar charts that show
metric violations and detected design smells. The summary also includes total
size of the software solution in LOC, total number of metric violations and
design smells, and design smell density per KLOC. In addition, the project
specific numbers are also presented.
1.3. HOW TO DOWNLOAD AND INSTALL
Download latest version of Designite from Designite’s web-site
(http://www.designite-tools.com/download-2/). Once the download is
complete, install the tool by double-clicking the downloaded file and by
following the instructions. Once you are done, you may invoke the installed
tool.
By default, the tool comes with a trial license. The trial version can be used
indefinitely with a few restrictions. If you wish to use all the features of the
tool, consider buying the professional license of the tool.
1.3.1. SYSTEM REQUIREMENTS
 Windows 7 or above
 Minimum 1 GHz processor with at least 1 GB RAM

8. 5
2.GETTING STARTED
2.1. DETECTING DESIGN SMELLS USING DESIGNITE
Let us understand step by step, how we can identify design smells using
Designite for C# projects:
1. Download the trial version of Designite (if you have not done so far)
from the tool’s website and install it on your Windows machine.
2. Now, you don’t require to take any special action to acquire a trial
license, since by default Designite comes with a trial license.
3. Start the tool and select a solution file containing the projects that you
would like to analyze. The tool will list all the C# projects in the solution;
you can include/exclude individual projects for the analysis.
4. Once you click “Analyze”, the tool will analyze the selected projects and
present a summary of the analysis. The summary includes a few
important metrics such as total lines of code in the selected projects,
total classes, namespaces, and methods, total metric violations,
detected design smells, density of smells per thousand lines of code,
and code duplication percentage.
5. The summary page also shows two graphs viz. metric violations and
design smells (classified according to the principle they violate).
Additionally, the project specific key metrics could be found on the
summary page.
6. In the detailed view on the left-hand side pane, you can see the detected
design smells and computed metrics in detail. A sunburst diagram
appears when you double click design smells under any of the analyzed
projects. The sunburst allows you to navigate and filter the smells based
on their violated principle, name, or originating namespace or class.

9. 6
FIGURE 1: SUNBURST VISUALIZATION OF DETECTED DESIGN SMELLS
 You can click on any design smell to see the cause of the smell (in the
bottom pane) and corresponding participating entities.
 If you wish, you can export the list of identified design smells and
computed metrics along with code duplication instances to an MS-Excel
file. Although, this feature is not enabled in the trial version of the tool.
 Once you know the existing design smells in your code, you can analyze
the reported instances and refactor them to improve the maintainability
of your software system.
2.2. USING SUNBURST DIAGRAM FOR EASIER NAVIGATION AND
FILTERING
Designite offers Sunburst diagram for design and implementation smells that
are interactive and beautiful yet effective way to navigate and filter the
detected design smells. Let us understand the different elements of the
diagram and the associated semantics in the rest of the section.

10. 7
FIGURE 2: SUNBURST DIAGRAM EXPLAINED
A Designite’s Sunburst diagram can be divided into three sections column wise
viz. A, B, and C. The A section contains the sunburst diagram. The second
section (i.e. section B) is the summary of detected smells containing a total
number of smells detected per principle. The section C changes dynamically
based on the Sunburst’s fragment under the mouse pointer.
Designite’s Sunburst diagram has 4 rings. Each ring represents a dimension
associated with detected design smells. The first ring shows the distribution of
smells based on the violated principle. Thus, if a software has more abstraction
smells then the abstraction fragment will be the largest fragment. Different
colors represent a different violated principle. Blue, light brown, violet, and
light teal is used for abstraction, encapsulation, modularization, and hierarchy
smells respectively. The second ring represents the distribution of specific
design smells (such as duplicate abstraction and insufficient modularization)
detected. Similarly, the third and fourth rings represent the namespace and
the class respectively in which the specific design smell has been detected.
The diagram is quite interactive and offers a way to navigate and filter the
detected smells. Each fragment of each of the rings shows the associated smell
details. For instance, in the above diagram when we move the mouse pointer
over the fragment (that is highlighted in yellow color), section C shows the
associated details; in this case, the section C shows that we are pointing to an
Abstraction smell, more precisely – duplicate abstraction smell in NServiceBus

11. 8
namespace. If we click on the element, all the duplicate abstraction smell
instances occurred in NServiceBus namespace will be shown. Similarly, if we
only want to see Modularization design smells then that can be achieved by
clicking on the violet fragment in the first ring.
2.3. UNDERSTANDING SOFTWARE METRICS AND COMPUTING THEM
USING DESIGNITE
“You cannot control what you cannot measure.”
(by Tom De Marco)
“Measurement” is a fundamental activity to any engineering discipline.
Measuring and quantifying aspects associated with a system of interest help
us understand the characteristics of the system and pave the way to derive
interpretations and insights about the system.
In the context of software systems, there are numerous kinds of metrics
associated with different aspects of software and software development such
as product or process metrics where product metrics can be further classified
as static and dynamic metrics and even further such as code, requirement, or
test metrics. A software metric is a measure of some property of a software
system.
This section focuses on static code and design metrics to reveal the structural
health of a software system and discusses different metric types, their meaning
and interpretations as well as a few tools that could be helpful identifying such
metrics.
Table-1 summarizes metrics commonly used to analyze maintainability of a
software system. These metrics can be classified in three broad categories viz.
size, complexity, and cohesion and coupling. Let us take a deeper look at these
metrics.
Table 1: Software Metrics and their categories
Category
Entity
Project Namespace Type Method
Size
LOC LOC LOC LOC
NOC NOC NOM NP

12. 9
NON NOF
DIT
NC
Complexity WMC CC
Cohesion
and
Coupling
LCOM
CBO
Fan-in/Fan-
out
2.3.1. SIZE METRICS
Each software entity must be of moderate size. Large entities are difficult to
understand, use, reuse, and test. Often, large entities implement more than
one responsibilities and violate Single Responsibility Principle (SRP). Table-2
shows description and typical threshold used for each metric concerning size.
Table 2: Size metrics with description and typical threshold
Metric Description Threshold
LOC Lines Of Code – Total lines of code in a source-code
entity
Method – 80,
Type - 1000
NOM Number Of Methods – Total number of methods in
a type
30
NOF Number Of Fields – Total number of fields in a type 20
DIT Depth of Inheritance Tree – Maximum length of the
path from this type to root of the inheritance tree
6
NC Number of Children – Total number of sub-classes
of a type
10
NOC Number Of Classes – Total number of types in a
namespace
20

13. 10
NON Number of Namespaces – Total number of
namespaces in a project
5
NP Number of Parameters – Total number of
parameters in a method
6
A note about thresholds – The thresholds presented in the above table are
indicative and may change based on organization or project code quality
guidelines.
2.3.2. COMPLEXITY METRICS
Cyclomatic Complexity (CC) is a commonly used metric to measure the
complexity of a method. It indicates a total number of possible unique paths
from the beginning of a method to exit the method. It is considered crucial
since a high value of CC in a method indicates high number of tests required
to cover all the paths in the method (in fact, minimum number of tests must
be written for the method is equal to CC). Weighted Methods per Class (WMC)
is the sum of cyclomatic complexities of all the methods belonging to the class.
Table-3 lists the complexity metrics with description and associated thresholds.
Table 3: Complexity metrics with description and associated typical threshold
Metric Description Threshold
CC Cyclomatic Complexity – Total number of linearly
independent paths through a method
5
WMC Weighted Methods per Class – Sum of cyclomatic
complexities of all the methods belonging to the
class
100
2.3.3. COHESION AND COUPLING METRICS
We should strive for high cohesion and low coupling classes. A class with high
cohesion means that the methods and fields in the class are implementing
single responsibility and will be changed due to only a single reason. Similarly,
a class with low coupling means that the class is well isolated from the rest of
the software system and hence chances to introduce a change in the class due
to changes in other classes are low. The metrics used to measure cohesion and
coupling are listed in Table-4.

14. 11
Table 4: Cohesion and coupling metrics with description and associated typical
threshold
Metric Description Threshold
LCOM Lack of Cohesion of Methods – It is the lack of
correlation between the methods and the instance
variables of the class (typically represented as a
normalized value between 0 and 1 (both included),
low value is desired)
0.8
CBO Coupling Between Object classes – Number of
other classes to which the class is coupled
10
Fan-
in
Fan-in – Total number of classes that reference the
class (in-coming dependencies)
20
Fan-
out
Fan-out – Total number of classes referenced by
the class (out-going dependencies)
20
2.3.4. COMPUTING AND ANALYZING SOFTWARE METRICS
Visual Studio computes some of the metrics mentioned above; specifically,
cyclomatic complexity, lines of code, depth of inheritance, and class coupling.
Visual Studio also computes Maintainability index which could be used to infer
the overall maintainability of the software. However, it is a composite metric
which could not be used for further drill-down to carry out a deeper analysis if
one wishes to improve the maintainability of the software and wish to know
specific pain areas.
Designite computes commonly used metrics and presents them in the form of
an interactive pie chart (see Figure 1). The pie chart has four partitions viz.
green, yellow, orange, and red. Designite computes metrics associated with
types as well as methods and based on their values and pre-defined thresholds,
it shows the distribution of entities that fall in each partition. By looking at the
pie chart, one can instantly get an overall idea about the project code quality
from the selected metrics point of view.

15. 12
FIGURE 3: DETAILED METRICS ANALYSIS BY DESIGNITE
Apart from showing a distribution of classes that falls in each of the pie, the
pie chart can also be used as a navigation and filtering mechanism. For
instance, if one clicks on the red pie, classes that are dangerously above the
metric threshold will only be shown in the grid below the pie chart (not shown
here). One can see other associated metrics for the filtered classes and may
target these classes first for refactoring. Even further, one can change the
thresholds (green, yellow, and orange) to customize the analysis.
A word of caution: Always consider metric values as indicators of code quality
and not as an absolute line that must not be violated. A software with all
entities in green with respect to all commonly used metrics may not be a high-
quality code; however, a high-quality code will have most of the entities in
green with respect to all metrics. In summary, strive for quality not for
numbers.
2.4. ANALYZING TREND OF SMELLS USING DESIGNITE
Designite introduced “trend analysis” feature in version 1.30.3 that reveals the
smells-trend for the analyzed software. Specifically, the trend shows how many
smells (both design and implementation) have been introduced, remained, and
removed from one version to another. It is useful in many cases including when

16. 13
the development team wanted to observe the quality of the software after a
refactoring cycle.
NUnit is a well-known open-source unit-testing framework for .NET. The oldest
available version of the tool is NUnit 2.0 which was released way back in 2002.
Since then, it has been under active development. It is interesting to see how
the software evolved in recent years from the design and implementation
smells perspective. We took 10 different versions of the software from version
2.5.9 (released in December 2010) to version 3.2.1 (released in April 2016)
and analyzed them using Designite.
FIGURE 4: TREND ANALYSIS WINDOW IN DESIGNITE
Let us use Designite’s trend analysis feature to see how the smell profile of the
software evolved during this period. Start Designite and select “Trend analysis”
option from the “Analysis” menu to initiate the analysis. It will open a window
(see above) where we have to specify different versions of the software to be
analyzed. There are two ways to do so.

17. 14
1. We can specify different versions one by one. Clicking on the ellipsis
opens the standard Windows File-open dialog. We locate the solution file
of a specific version and select it. Also, we specify the version (up to 5
characters) and click on the “Add the solution” button.
2. If we are planning to execute a trend analysis (of same versions of the
software) periodically, then specifying each version separately every
time is cumbersome. In such a situation, we can prepare a batch file
containing version and path of all the versions that we would like to
analyze. Each line of the file should contain version string (not more
than 5 characters long) and absolute path of the solution file of the
specified version separated by a semi-colon. The batch file that we used
for analyzing various versions of NUnit is given below. Specify this file
by clicking on “Import solution list for trend analysis”.
2.5.9;c:WorkspacenunitNUnit-2.5.9.10348nunit.sln
2.510;c:WorkspacenunitNUnit-2.5.10.11092nunit.sln
2.6.0;c:WorkspacenunitNUnit-2.6.0.12051nunit.sln
2.6.1;c:WorkspacenunitNUnit-2.6.1-srcnunit.sln
2.6.2;c:WorkspacenunitNUnit-2.6.2nunit.sln
2.6.3;c:WorkspacenunitNUnit-2.6.3nunit.sln
3.0.0;c:WorkspacenunitNUnit-3.0.0-srcnunit.sln
3.0.1;c:WorkspacenunitNUnit-3.0.1-srcnunit.sln
3.2.0;c:WorkspacenunitNUnit-3.2.0-srcnunit.sln
3.2.1;c:WorkspacenunitNUnit-3.2.1-srcnunit.sln
We click on “Analyze” and wait for the tool to complete the analysis. The
waiting period depends on the number of versions and the size of the project.
We get the following trend for the selected versions of the software.

18. 15
FIGURE 5: TREND ANALYSIS RESULT BY DESIGNITE
The trend analysis summary shows the total number of design and
implementation smells that have been introduced, remained, and removed in
each of the analyzed versions of NUnit. Version 3 of NUnit was written almost
from the scratch and therefore, the number of new smells introduced is very
high. At the same time, it is interesting to observe that smell density in the
version 3.0.0 has been reduced (refer the table below the stacked column
chart). It indicates that despite a lot of new code has been written for version
3, the development team managed to write higher quality code.
We can dig a little deeper by looking at design smells and implementation
smells views separately. The detailed views allow us to see specific smells that
have been introduced, remained, or removed in each version.

19. 16
Stacked column charts are interactive that enable us to filter the results shown
in the grid below the chart. So, if we wanted to see smells that have been
removed in version 3.2.0, we can click on the green column for the said version
(as shown below).

20. 17
2.5. USING THE POWER OF DESIGNITE’S CONSOLE APPLICATION
With the release of version 1.31.0, Designite revealed a more powerful console
application. The new console application not only supports previously
supported functionality (analyze projects and export results in MS Excel, XML,
or CSV formats) but also allows a user to carry out trend analysis with a rich
set of options. Specifically, the new console application offers the following
capabilities:
 Analyze C# solution/projects and export the analysis results (design
smells, implementation smells, class and method metrics) in one of the
formats (MS Excel, XML, CSV).
 Carry out a trend analysis by analyzing different versions of C# solutions
and export the results.
 Carry out a trend analysis of a Git repository
 Exempt certain projects from the analysis for more relevant results
Let us explore these features in more detail.
2.5.1. ANALYZE C# SOLUTIONS/PROJECTS
The console application provides the usage instruction when you execute it
without any parameters.
FIGURE 6: USAGE INSTRUCTIONS OF THE NEW DESIGNITE CONSOLE APPLICATION

21. 18
To analyze a C# solution and to export the analysis results in the desired
format, you can use the following command:
DesigniteConsole.exe "c:Workspacexunitxunit.vs2015.sln" -E
"C:tempresult.xls"
The first parameter states the path of the C# solution file, the second
parameter (i.e. –E) tells the application to export the results in MS Excel format,
and the third parameter provides the path of the output file in which the result
of the analysis will be stored. Other supported formats are XML and CSV.
Specify –X for XML and –C for CSV. Note that you need to provide folder path
(rather than file path) when we specify –C as shown below:
DesigniteConsole.exe "c:Workspacexunitxunit.vs2015.sln" -C
"C:temp"
When you analyze a C# solution, the application tries to analyze all the C#
projects that are part of the solution. What if you wish to analyze only a few
specific projects? It’s fairly easy with the application. Create a batch file
containing the path of C# projects that you would like to analyze (one project
in one line). An example of such a batch file is given below:
[Projects]
c:WorkspaceNUnit-3.0.1-srcsrcNUnitConsolenunit3-consolenunit3-
console.csproj
c:WorkspaceNUnit-3.0.1-srcsrcNUnitEngineAddinsvs-project-
loadervs-project-loader.csproj
c:WorkspaceNUnit-3.0.1-srcsrcNUnitFrameworkmock-
assemblymock-nunit-assembly-4.5.csproj
It is important to mention “[Projects]” tag to help the application identify the
specific projects to analyze. The following command can be used to analyze
the above batch file.
DesigniteConsole.exe "C:WorkspaceNUnit-3.0.1-srcDesigniteTest.batch"
-C "C:temp"
2.5.2. TREND ANALYSIS
The new version of the console application also supports trend analysis. Create
a batch file containing version and solution file path in a line separated by a
semi-colon. An example of such a batch file is given below.
[Solutions for trend analysis]
2.6.3;C:WorkspacenunitNUnit-2.6.3nunit.sln
3.0.0;C:WorkspacenunitNUnit-3.0.0-srcnunit.sln

22. 19
Obviously, it is important to mention “[Solutions for trend analysis]” before
specifying version and path of a solution file. Specify the following command
to initiate the trend analysis:
DesigniteConsole.exe "C:Workspacenunittest_trend.batch" -trend
"C:temp"
The second parameter “-trend” states that you are interested in trend analysis
and the third parameter is the path of the folder where the result of the
analysis will be produced in CSV format.
FIGURE 7: TREND ANALYSIS USING DESIGNITE CONSOLE APPLICATION
It is often required to exclude a few certain projects from the trend analysis.
You can specify project names (case sensitive) under “[Exempt projects]” tag
to achieve the same. A project name containing one of the strings specified
under the exempt projects tag is excluded from the analysis. For instance, we
can exclude all the projects containing “test” in their names by specifying it
under the exempt projects tag as follows.
[Solutions for trend analysis]
2.6.3;C:WorkspacenunitNUnit-2.6.3nunit.sln

23. 20
3.0.0;C:WorkspacenunitNUnit-3.0.0-srcnunit.sln
[Exempt projects]
test
2.5.3. TREND ANALYSIS FOR GIT REPOSITORIES
The Designite console application can analyze a Git repository and produce
trend analysis results. You need to provide a few details in a batch file such as
the path of the Git repository and path of the temporary folder. Here is a
sample batch file that can be used to carry out a trend analysis for a Git
repository.
[Git repo path]
C:Workspacexunit
[Git bash path]
C:Program FilesGitgit-bash.exe
[Temp folder path]
C:DevDesignitetemp
[Versions]
399ea8c
3fdea50
6f6776a
You need to specify the path of the Git repository under the “[Git repo path]”
tag. You also need to provide a path of the Git bash console and temporary
folder. The Designite console application uses Git bash to work on a specific
version of the code; therefore, you need to provide the path of the Git bash
console. The application also makes copies of the Git repository and thus
requires a temporary folder to work with. Further, you need to specify commit
hash for the versions that you would like to analyze.
The following command will produce the trend analysis report.
DesigniteConsole.exe "C:Workspacenunittest_trend_git.batch" -trend
"C:temp"
There is another interesting feature that Designite console application supports.
If you want to analyze N number of versions distributed across all the
committed versions in a Git repository, you can do it easily with the application.
Specify the number of versions with “[Auto choose versions]” tag in a batch
file and leave the rest to the console application. Here is an example of such a
batch file.

24. 21
[Git repo path]
C:Workspacexunit
[Git bash path]
C:Program FilesGitgit-bash.exe
[Temp folder path]
C:DevDesignitetemp
[Auto choose versions]
5
Here, the application will choose 5 different versions from the specified
repository distributed almost uniformly since the first commit in the repository.
This feature is particularly useful when you wish to analyze a large number of
repositories automatically.
2.6. REVEALING THE DISTRIBUTION OF SMELLS IN DESIGNITE USING
TREEMAP
You know there are smells spread all over your code base. However, which of
the modules (or components) have more smells than others? What is the
distribution of smells in your code base? To know this, you may carry out
design smell analysis and then compute manually the distribution of smells. As
you can guess, figuring out the distribution of smells within your code base
manually is not really trivial; it may take a lot of your time and you may lose
the motivation to do so. In such a situation, Treemap is extremely useful.
Designite offers treemap visualization of your code base. Treemap shows two
aspects – “size” and “smell density” of a component/class. Designite analyzes
the selected code base and computes size and smell density for each class. In
the treemap, each rectangle with dark-red color outline represents a
namespace in the analyzed code base. The size of the rectangle depends on
the size of the namespace relative to the analyzed code base. Such rectangles
have many smaller filled rectangles (representing classes). Again, the size of
a filled rectangle depends on the relative size of the class. The color filled in
the rectangle shows the smell density. A class with low smell density is shown
by green color; the temperature of the rectangle increases with the smell
density i.e. a class with very high smell density is shown by dark red color.

25. 22
FIGURE 8: TREEMAP PRODUCED BY DESIGNITE
The treemap shown by Designite is user-friendly. It reveals the details of the
class (namespace, class, and smell density) based on the location of mouse
pointer. Therefore, if you wish to know the class identity of a class which is
looking really bad, you just need to point your mouse pointer over the
rectangle.
Moreover, Designite allows you to customize the analysis and the treemap by
changing the thresholds. These thresholds decide the color of each class shown
as a rectangle. Further, you may decide whether you are interested in only
design smells, implementation smells, or both. Even further, you may
customize the treemap by reducing the scope; it can be done by selecting a
specific project from the drop-down list.
2.7. CUSTOMIZE YOUR QUALITY ANALYSIS
Every piece of code is different in terms of domain, context, and its quality
requirements. Measuring quality aspects of all the software systems using the
same stick is not appropriate and often not desirable. Keeping it in mind,
Designite has introduced a new feature “Preferences” in version 1.33.0 to allow
users to customize their analysis by selecting thresholds based on their context
and requirements.

26. 23
2.7.1. METRIC THRESHOLD CUSTOMIZATION
You can now select one of the metric threshold profiles. Designite offers four
such profiles – Standard, Stringent, Lenient, and Custom. As the name
suggests, Standard profile is the default option with balanced metric
thresholds. By selecting Stringent, you can enable stricter metric thresholds.
Similarly, Lenient profile imposes lenient metric thresholds. If none of these
profiles suits your needs, you can choose Custom profile and change any
metric to your desired value.
FIGURE 9: CUSTOMIZE METRIC THRESHOLDS
2.7.2. CUSTOMIZE SMELL DETECTION
You can completely customize the design and implementation smell detection
in Designite. You can enable/disable smells i.e. whether you want Designite to
detect specific smells or not. In many cases, there are multiple thresholds
associated with a smell. You can change the threshold values based on your
requirements. Certain threshold values are fixed (for example, “number of
methods” in the case of Imperative Abstraction which is intentional to preserve
the essence of the smell).

27. 24
FIGURE 10: CUSTOMIZE SMELL ANALYSIS
If you see an error something like the following, then either you need to
execute the tool with administrative privileges or manually change the
configuration files.
2.7.3. CUSTOM ANALYSIS USING CONSOLE APPLICATION
If you are using Designite’s console application, you can specify your desired
threshold settings very easily.
For metric profile and threshold values, open “MetricThreshold.config” file in
the installation folder of Designite (if the file doesn’t exist, create one). Put the
following line in the file:
MetricThresholdProfile=STRINGENT
If you want to change the profile to Lenient, put “LENIENT” instead of
“STRINGENT”.
In case, you wish to customize one or more threshold values, your file may
look like as follows:

28. 25
MetricThresholdProfile=CUSTOM
CC=7
LOC=500
DIT=4
FANIN=15
FANOUT=15
LCOM=0.9
MLOC=60
NC=7
NOF=10
NOM=20
NOP=10
NOPF=1
NOPM=10
PC=4
WMC=60
Similarly, to customize your smell analysis, open “SmellThreshold.config” in
the installation folder of Designite. Create the file if it doesn’t exist. Paste the
following contents in the file:
UNNECESSARY ABSTRACTION=NO,5
IMPERATIVE ABSTRACTION=NO,100
MULTIFACETED ABSTRACTION=NO,0.6,10,10
UNUTILIZED ABSTRACTION=YES
DUPLICATE ABSTRACTION=YES,20
DEFICIENT ENCAPSULATION=YES,1,1
UNEXPLOITED ENCAPSULATION=YES,2
BROKEN MODULARIZATION=YES,5
INSUFFICIENT MODULARIZATION=YES,20,30,100
HUB-LIKE MODULARIZATION=YES,20,20
CYCLICALLY-DEPENDENT MODULARIZATION=NO
WIDE HIERARCHY=YES,10
DEEP HIERARCHY=YES,6
MULTIPATH HIERARCHY=YES
CYCLIC HIERARCHY=YES
REBELLIOUS HIERARCHY=YES
UNFACTORED HIERARCHY=YES
MISSING HIERARCHY=YES,2
BROKEN HIERARCHY=YES
LONG METHOD=YES,100

29. 26
COMPLEX METHOD=YES,8
LONG PARAMETER LIST=YES,5
LONG IDENTIFIER=YES,30
LONG STATEMENT=NO,120
COMPLEX CONDITIONAL=YES,3
VIRTUAL CALL FROM CONSTRUCTOR=YES
EMPTY CATCH BLOCK=YES
MAGIC NUMBER=YES
DUPLICATE CODE=YES
MISSING DEFAULT=YES
Each line contains the information about one smell. At the minimum, each line
contains whether the smell will be detected by the tool (obviously, yes means
the tool will look for the smell). A smell may have zero or more threshold
values; the number of thresholds depends on the smell. You can change the
threshold values based on your requirements. Please note that the order of
the smells can be changed; thus, Multifaceted Abstraction can come first and
Unnecessary Abstraction can appear in the last line.
Here is the table that summarizes the customizable thresholds for each smell.
Smells Threshold Values
UNNECESSARY ABSTRACTION Enable analysis – YES/NO
Max no of fields + properties
IMPERATIVE ABSTRACTION Enable analysis – YES/NO
Min LOC
MULTIFACETED ABSTRACTION Enable analysis – YES/NO
Min LOC
Min no of fields
Min no of methods
UNUTILIZED ABSTRACTION Enable analysis – YES/NO
DUPLICATE ABSTRACTION Enable analysis – YES/NO
Min consecutive duplicated lines
DEFICIENT ENCAPSULATION Enable analysis – YES/NO
Min no of public fields
Min no of public static fields
UNEXPLOITED ENCAPSULATION Enable analysis – YES/NO
Min no of typechecks belonging to
same hierarchy
BROKEN MODULARIZATION Enable analysis – YES/NO
Min no of fields + properties

30. 27
INSUFFICIENT MODULARIZATION Enable analysis – YES/NO
Min no of public methods
Min no of all methods
Min WMC
HUB-LIKE MODULARIZATION Enable analysis – YES/NO
Min Fan-in
Min Fan-out
CYCLICALLY-DEPENDENT
MODULARIZATION
Enable analysis – YES/NO
WIDE HIERARCHY Enable analysis – YES/NO
Min no of subtypes
DEEP HIERARCHY Enable analysis – YES/NO
Min DIT
MULTIPATH HIERARCHY Enable analysis – YES/NO
CYCLIC HIERARCHY Enable analysis – YES/NO
REBELLIOUS HIERARCHY Enable analysis – YES/NO
UNFACTORED HIERARCHY Enable analysis – YES/NO
MISSING HIERARCHY Enable analysis – YES/NO
Min no of typechecks
BROKEN HIERARCHY Enable analysis – YES/NO
LONG METHOD Enable analysis – YES/NO
Min method LOC
COMPLEX METHOD Enable analysis – YES/NO
Min CC
LONG PARAMETER LIST Enable analysis – YES/NO
Min parameter count
LONG IDENTIFIER Enable analysis – YES/NO
Min identifier length
LONG STATEMENT Enable analysis – YES/NO
Min statement length
COMPLEX CONDITIONAL Enable analysis – YES/NO
Min no of conditionals
VIRTUAL CALL FROM
CONSTRUCTOR
Enable analysis – YES/NO
EMPTY CATCH BLOCK Enable analysis – YES/NO
MAGIC NUMBER Enable analysis – YES/NO
DUPLICATE CODE Enable analysis – YES/NO
MISSING DEFAULT Enable analysis – YES/NO

31. 28
3.CONTACT US
You may contact us at contact@designite-tools.com to share your thoughts,
discuss any sales related topic, or to provide your feedback.