technical-debt-toolbox-usage.md

@@ -6,13 +6,14 @@ In this wiki page, we describe how the Technical Debt Toolbox can be used per in
 
 Having the Technical Dent Toolbox Docker Container already deployed on your local machine (see the [Installation](technical-debt-toolbox-installation) page for more information), it can be started, paused and stopped using common Docker commands. The purpose of the TD Management Toolbox is to provide suggestions for the improvement of software maintainability than can be performed in two ways:
 
-• TD Analysis - Breaking Point: The analysis of the past commits of the system, results in the estimation of the three main TD concepts (namely: interest, principal, interest probability) and the breaking point for each artefact. For this analysis, we have developed the Breaking Point Tool container which also performs the design refactoring identification process.
-• TD New Code: This analysis will rely on past knowledge to estimate if the TD Principal that a new commit will add to the existing code is improving or harming TD. For this type of analysis, we have developed the New Code TD Tool. 
+• **TD Analysis - Breaking Point:** The analysis of the past commits of the system, results in the estimation of the three main TD concepts (namely: interest, principal, interest probability) and the breaking point for each artefact. For this analysis, we have developed the Breaking Point Tool container which also performs the design refactoring identification process.
+
+• **TD New Code:** This analysis will rely on past knowledge to estimate if the TD Principal that a new commit will add to the existing code is improving or harming TD. For this type of analysis, we have developed the New Code TD Tool. 
 
 Each of these tools has its own web service that is divided into additional endpoints. The web services allow the individual and remote invocation of the tools to start analysis and to return pre analysed data. This is achieved through the dedicated API exposed by the RESTful web server which allows the user to perform simple HTTP GET and POST requests to the web services. Several inputs need to be provided as URL-encoded parameters to these requests. The URLs, parameters and indicative examples for each of the web services are provided in the next sections. Regarding the identification of refactoring opportunities, in the toolbox, we include two high-level approaches:
 
-• Code-Level refactorings, as suggested by SonarQube: We present a list of TD issues identified at the source code level, ordered by code smell probability. In particular, we calculate the percentage of the files in which a specific code smell resides in (probability to maintain a file that suffers from the specific smell) and multiply it by the average interest probability of these files. The resulting code smells interest probability represents the possibility that a developer faces this issue when maintaining the system.
-• Design-Level refactorings are provided in two forms: Either in the form of extract method refactoring opportunities, i.e., ways to split a long method; or in the form of move class refactorings, i.e., ways to improve the modularity of software packages so that they obey to the Single Responsibility Principle.
+• **Code-Level refactorings, as suggested by SonarQube:** We present a list of TD issues identified at the source code level, ordered by code smell probability. In particular, we calculate the percentage of the files in which a specific code smell resides in (probability to maintain a file that suffers from the specific smell) and multiply it by the average interest probability of these files. The resulting code smells interest probability represents the possibility that a developer faces this issue when maintaining the system.
+• **Design-Level refactorings are provided in two forms:** Either in the form of extract method refactoring opportunities, i.e., ways to split a long method; or in the form of move class refactorings, i.e., ways to improve the modularity of software packages so that they obey to the Single Responsibility Principle.
 
 # Invocation of the individual services (APIs)