| ... | ... | @@ -7,10 +7,34 @@ By clicking on 'Decision Support', the user is presented with the 2 options rese |
|
|
|
|
|
|
|
As shown above, the user is greeted with a warning message and asked to acknowledge that her project has already been analyzed from the analysis toolboxes1. Then, the user is welcome to initiate the Trade-off Manager flow via pressing the 'Gather Refactorings' button.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Upon pressing the button, results are retrieved from the analysis toolboxes and the initial design space is displayed to the user in two formats:
|
|
|
|
|
|
|
|
- Tabular form, where each refactoring suggestion is accompanied with the impacts it is expected to have in the code qualities of Energy, Technical Debt and Security. This format resembles the corresponding entry saved in the look-up table
|
|
|
|
- Three figures of 2-dimensional vectors, each focusing on the trade-offs between code quality pairs. The figures are interactive in the sense that the user can manually choose any subset of design space points that she may want to compareAs a visualization scheme, the choice of 2-dimensional vectors is intuitively fitting, even for a manual exploration of the design space. It is obvious that if the user wants to improve the Security aspect, then from the 'Energy vs Security' we can safely exclude the 'Loop Unrolling' option (black arrow) since it has no impact on the specific quality.
|
|
|
|
- Three figures of 2-dimensional vectors, each focusing on the trade-offs between code quality pairs. The figures are interactive in the sense that the user can manually choose any subset of design space points that she may want to compare. As a visualization scheme, the choice of 2-dimensional vectors is intuitively fitting, even for a manual exploration of the design space. It is obvious that if the user wants to improve the Security aspect, then from the 'Energy vs Security' we can safely exclude the 'Loop Unrolling' option (black arrow) since it has no impact on the specific quality.
|
|
|
|
|
|
|
|
We now proceed with the rest of the Trade-Off Manager functionality accessible by the front-end. Recall from the tool's description that the decision maker should be able to provide her preferences with respect to the qualities she would like to optimize through refactoring.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The above figure showcases how this user input is accommodated by the Trade-Off Manager front-end. Six rows of radio buttons have to be dealt with. Each one of the first five revolves around the reference comparisons needed by the FBWM decision-making algorithm (Fuzzy Best-Worst Method [Guo & Zhao] see deliverable D4.5 for details).
|
|
|
|
|
|
|
|
The sixth and final row handles the demonstration, or not, of project-specific information. With this we mean the following: as has been clarified in earlier work (D4.5), the design space is formed by lookup-table entries denoting single, local applications of particular refactoring operations. However, analysis toolboxes usually detect multiple locations in a software project where the same refactoring should be applied, and such multiplicities are reported upon invocation by the Trade-Off Manager.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After stating her preferences, the user may now invoke the FBWM MCDM algorithm via the 'Invoke MCDM' button. The results retrieved are visualized as shown above. The left panel shows, for each refactoring, the quality-specific contributions to its overall value. The right panel shows just the overall values.
|
|
|
|
|
|
|
|
Please note that by ‘value’ we refer to the degree of fitness of a particular option to the user’s requirements. As is analysed in D4.5, this number is actually a defuzzified sum of triangular membership functions.
|
|
|
|
|
|
|
|
Moving on, we shall demonstrate the final brick on the Trade-Off Manager structure, namely integration with the SDK4ED Forecasting Toolbox. This feature could prove useful to decision makers who would like to take into consideration the evolution of their project's qualities in the future. A necessary condition for this to bear meaning is to have previously analyzed a plethora of versions for the project in question (otherwise the Forecasting Toolbox could construct no reliable model).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The above figure showcases the interface with the Forecasting Toolbox, as it exists in Trade-Off Manager. The user may select what forecasting algorithm will be used, and how many versions in the future should the results be projected.
|
|
|
|
|
|
|
|
We utilize the Forecasting Toolbox outputs as follows. Based on the current quantitative indicators of each quality (retrieved by Trade-Off Manager upon querying the analysis toolboxes about available refactorings for a specific project), and by making use of the predicted values of said indicators by the Forecasting Toolbox, we calculate a 'future-to-current ratio' by dividing the predicted value with the current one. The timeseries of this ratio, comprising as many points as the size of the forecasted horizon selected by the user, are displayed on the left panel below. We use these ratios to scale the Energy, Technical Debt and Dependability components of each refactoring's value.
|
|
|
|
|
|
|
|
|
|
|
|
|
