| ... | ... | @@ -6,6 +6,22 @@ In this wiki page we describe how the Technical Debt Toolbox can be used per ind |
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
## Description
|
|
|
|
|
|
|
|
The purpose of the TD Management Toolbox is to provide suggestions to improve software maintainability than can be performed in two ways:
|
|
|
|
# TD Analysis - Breaking Point:
|
|
|
|
the analysis of the past commits of the system. This analysis will result 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:
|
|
|
|
the analysis of future (planned) commit. 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 end points. The web services allow the individual and remote invocation of the tools to start an 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 POSTb 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 with 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:
|
|
|
|
(a) in the form of extract method refactoring opportunities, i.e., ways to split a long method; and (b) in the form of move class refactorings, i.e., ways to improve the modularity of software packages so that they are obeying to the Single Responsibility Principle.
|
|
|
|
|
|
|
|
## Invocation of the individual services (APIs)
|
|
|
|
|
|
|
|
After starting the Docker Container of the Technical Debt Toolbox back-end, its web services are up and running. The Technical Debt Toolbox is accessible through the following end point:
|
| ... | ... | @@ -44,3 +60,8 @@ In order to invoke any of the available web services, the right resource (i.e., |
|
|
|
|
|
|
|
In the following, a more detailed description of how these services can be used is provided. Please use the following links to navigate more easily within the page:
|
|
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Quantitative Security Assessment Service |
