|
|
|
# Technical Debt Toolbox - Execution as a Microservice
|
|
|
|
|
|
|
|
In this wiki page we describe how the Technical Debt Toolbox can be used per individual Microservice. More specifically, we describe how the three services that it provides (i.e., *TD Analysis and Refactorings*, *TD New Code*, and *Architecture Refactorings*) can be invoked, whereas intuitive examples are also provided, in an attempt to facilitate understanding.
|
|
|
|
|
|
|
|
In this wiki page, we describe how the Technical Debt Toolbox can be used per individual Microservice. More specifically, we describe how the three services that it provides (i.e., TD Analysis and Design Refactorings, TD New Code and Code Refactorings, and Architecture Refactorings) can be invoked. Intuitive examples are also provided as an attempt to make understanding easier.
|
|
|
|
|
|
|
|
## Execution of the Docker Container
|
|
|
|
|
|
|
|
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
|
|
|
|
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:
|
|
|
|
|
|
|
|
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.
|
|
|
|
• 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 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.
|
|
|
|
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:
|
|
|
|
|
|
|
|
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.
|
|
|
|
• 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)
|
|
|
|
|
| ... | ... | @@ -45,18 +37,26 @@ In order to invoke any of the available web services, the right resource (i.e., |
|
|
|
* /lineChartPrincipalTD/
|
|
|
|
* /lineChartBreakingPointTD/
|
|
|
|
* /cumulativeInterestLineChart/
|
|
|
|
* /projectLanguage/
|
|
|
|
|
|
|
|
- **TD New Code**:
|
|
|
|
* /api/sdk4ed/nc/projects
|
|
|
|
* /api/sdk4ed/nc/tddot/
|
|
|
|
* /api/sdk4ed/nc/introducedIssuesOnNewMethods/
|
|
|
|
* /api/sdk4ed/nc/branchCommits/
|
|
|
|
* /api/sdk4ed/qg/
|
|
|
|
* /api/sdk4ed/nc/projects
|
|
|
|
* /api/sdk4ed/nc/tddot/
|
|
|
|
* /api/sdk4ed/nc/introducedNewIssues/
|
|
|
|
* /api/sdk4ed/nc/branchCommits/
|
|
|
|
* /api/sdk4ed/qg/
|
|
|
|
* /api/sdk4ed/ha/analyze/
|
|
|
|
* /api/jira/issues
|
|
|
|
* /api/sdk4ed/project-details/findByUri
|
|
|
|
|
|
|
|
- **Design Refactorings**
|
|
|
|
* /extractMethodOpportunities/
|
|
|
|
* /moveClassRefactorings/
|
|
|
|
* /moveClassRefactoringMetrics/
|
|
|
|
|
|
|
|
- **Code Refactorings**
|
|
|
|
* /api/sdk4ed/nc/projects
|
|
|
|
* /api/sdk4ed/project-details/findByUri
|
|
|
|
* /api/sdk4ed/refactorings/ruleViolationPrct
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
| ... | ... | |
