| ... | ... | @@ -55,11 +55,20 @@ Some toolboxes of the SDK4ED Platform impose some additional limitations and pre |
|
|
|
language = Java
|
|
|
|
```
|
|
|
|
1. *dir* is the name root directory of the project
|
|
|
|
2. *exec* corresponds to the command that executes the application. It is worth mentioning that for performing dynamic analysis, the Energy Toolbox needs to execute the application. Furthermore, when the user wants to analyse a project dynamically in order to have more accurate results, care must be taken that the application is terminated and not run indefinitely.
|
|
|
|
3. *source* is the path to the source files that the user wants to analyse separated by commas.
|
|
|
|
4. *include_dirs* is optional and contains the paths to directories that have to be included in order to compile the source files separately (needed for static analysis)
|
|
|
|
2. *exec* corresponds to the command that executes the application. It is worth
|
|
|
|
mentioning that for performing dynamic analysis, the Energy Toolbox needs to
|
|
|
|
execute the application. Furthermore, when the user wants to analyse a project
|
|
|
|
dynamically in order to have more accurate results, care must be taken that the
|
|
|
|
application is terminated and not run indefinitely.
|
|
|
|
3. *source* is the path to the source files that the user wants to analyse
|
|
|
|
separated by commas.
|
|
|
|
4. *include_dirs* is optional and contains the paths to directories that have to
|
|
|
|
be included in order to compile the source files separately (needed for static
|
|
|
|
analysis)
|
|
|
|
5. *build* includes the compiling and building commands.
|
|
|
|
6. *Finally*, language is “Java” or “C/C++” for specifying the project’s programming language.
|
|
|
|
6. *Finally*, language is “Java” or “C/C++” for specifying the project’s
|
|
|
|
programming language.<br/><br/><br/>
|
|
|
|
|
|
|
|
- <ins>C/C++ Projects:</ins> For C/C++ the building commands (either gcc commands or make) have to use gcc compiler with the -g debugging flag. All the paths to directories needed have also to be included using the -I flag. The static analysis can provide results without executing the project but the dynamic part (Hotspots identification, indicators monitoring, Acceleration estimation, optimizations suggestion) needs the project to be executed.
|
|
|
|
- <ins>Java Projects:</ins> Single jar executables have to be provided in exec parameter. The dynamic analysis requires the execution of the project.
|
|
|
|
- Forecasting Toolbox:
|
| ... | ... | @@ -85,7 +94,7 @@ The user needs to create a new project in order to define the characteristics of |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A pop-up window will be displayed to their screen, allowing them to define the details of the selected project (see Figure below). As can be seen by Figure 5, the user should define:
|
|
|
|
A pop-up window will be displayed to their screen, allowing them to define the details of the selected project (see Figure below). As can be seen by the figure below, the user should define:
|
|
|
|
- The accessibility of their project within the SDK4ED Platform (i.e., Public or Private)
|
|
|
|
- The name of the project, which should be identical to the Git project name
|
|
|
|
- The Git URL of the online repository (i.e., Git URL)
|
| ... | ... | @@ -158,7 +167,7 @@ Similarly, the user can navigate to other pages in order to inspect the produced |
|
|
|
|Energy|Energy|• Energy Consumption Estimation sub-panel: It is part of the Consumption Analysis sub-component. It provides fast results making Energy Consumption and Execution Time predictions about running an application on different platforms based on static analysis. <br/>• Energy indicators monitoring and hotspots identification sub-panel: Energy Consumption indicators (CPU cycles, Data races, Memory accesses, Ratio of branch misses, Cache miss rate, D cache misses) are presented by the Toolbox, in order to characterize the application in terms of Energy Consumption and to assist developers on identifying the individual characteristics of the application that consume more Energy. The Energy Hotspots are also identified: the blocks of code that may consume more energy. <br/>• History Analysis: Presents the static analysis Energy and Time estimations for all the project commits that have been analysed using the Toolbox in the past, retrieving the information from the embedded database.<br/>• Android Analysis: The Energy Toolbox additional mechanism for supporting Android applications was described in a detailed manner in D6.4. This tool reports Android specific Energy indicators such as Memory Usage (bytes), CPU Load (percentage), CPU Frequency (Hertz), Context Switches (count), Test case duration (seconds), System calls (count), Total Energy (Milijoules).<br/>• Optimization Suggestions sub-panel: This panel proposes refactoring opportunities for each energy hotspot.<br/>• Acceleration Specific indicators: Presents the indicators that influence the accelerator decision foreach hotspot.|
|
|
|
|
|Refactorings|Code Refactorings|This panel provides a ranking of the refactorings that can be performed based on the Change proneness and the impact of the identified TD item|
|
|
|
|
| |Design Refactorings|The panels provided the suggested refactorings for 2 types of refactorings:<br/>• Move Class Refactorings<br/>• Extract Long Method|
|
|
|
|
| |Architecture Refactoring|This panel presents the results of the architectural smell detection of the selected project. The following information is shown:<br/>• An interactive plot with the number of smells (divided by type) detected in the versions analaysed.<br/>• The list of architecture smells affecting the system. For each smell one can inspect the current version, or previous versions of the same smell detected in the previous versions of the project.|
|
|
|
|
| |Architecture Refactoring|This panel presents the results of the architectural smell detection of the selected project. The following information is shown:<br/>• An interactive plot with the number of smells (divided by type) detected in the versions analysed.<br/>• The list of architecture smells affecting the system. For each smell one can inspect the current version, or previous versions of the same smell detected in the previous versions of the project.|
|
|
|
|
|Decision Support|Trade-off Manager|On this panel, the user can inspect and compare the several refactoring suggestions proposed by each of the analysis toolboxes. Then, based on her stated preferences (in pairwise comparison form) the user can retrieve a tailored ranking of the available options.<br/>Note that a guaranteed-to-be-consistent set of preferences is “Absolutely more important”, “Quite more important” and “Quite more important”.<br/>Lastly, via an indirect invocation of the Forecaster Toolbox, the user can use the bottom panel to decide with a future time horizon in mind (where the value of each refactoring is recomputed based on the expected evolution of each quality).|
|
|
|
|
| |Refactorings as financial investment|This panel provides information about the expected financial impact that the proposed refactorings may have, if the user decides to apply them. The estimations are derived through a cost-benefit analysis that is performed by the toolbox based on user feedback.|
|
|
|
|
|Forecasting|TD Forecast|This panel provides projections of the future evolution of the *TD Principal* of the analysed software.|
|
| ... | ... | |
