Difference between revisions of "CA UI Implementation"
m (new name) |
|||
Line 1: | Line 1: | ||
− | + | [[Category:Code Analysis]] | |
− | + | ||
− | + | ||
== Graphical User Interface == | == Graphical User Interface == |
Revision as of 15:21, 3 June 2014
Contents
Graphical User Interface
The classes of the graphical user interface of Inspector Eiffel are all located in the interface cluster of EiffelStudio, in the subfolder graphical > tools > code_analysis. Here is a short overview of what the single classes do:
-
{ES_CODE_ANALYSIS_TOOL}
- Represents the code analysis GUI tool. Contains the tool title and icon, otherwise not much interesting stuff.
-
{ES_CODE_ANALYSIS_TOOL_PANEL}
- The graphical panel for the code analysis tool. It contains buttons, labels, the rule violations table view, and other user interface elements.
-
{ES_CODE_ANALYSIS_COMMAND}
- The command to launch the code analyzer. It can be added to toolbars and menus. It can be executed using stones. This class also handles the caching.
-
{ES_CODE_ANALYSIS_BENCH_HELPER}
- A helper class for the integration of the code analysis tool. It contains shared instances of
{CA_CODE_ANALYZER}
and{ES_CODE_ANALYSIS_COMMAND}
, which are used by the GUI. -
{ES_CA_SHOW_PREFERENCES_COMMAND}
- The command is used by the Preferences button in the panel.
-
{ES_CA_FIX_EXECUTOR}
- This class fixes a rule violation that has been found by the code analysis tool.
These are roughly the class relations for the Inspector Eiffel GUI:
Caching
It is a common case that GUI users run the code analyzer again after having made some changes to the code. We do not need to analyze the same unchanged code again and again. Therefore code analysis caches the results in memory. This only applies to the GUI mode.
Code analysis uses cached results exactly in one case: when the whole system is analyzed and the previous analysis was on the whole system, too.
The caching functionality is implemented in {ES_CODE_ANALYSIS_COMMAND}
. When the command for analyzing the system is executed, the timestamps of the last modification of the classes are stored in analysis_timestamp : HASH_TABLE [INTEGER, CLASS_I]
before the analysis. Note that the cached results (the rule violations) themselves are managed by {CA_CODE_ANALYZER}
. The only difference to a non-cached analysis is that the rule violations are not deleted by {ES_CODE_ANALYSIS_COMMAND}
before the next analysis. Then, in case the next command is also for analyzing the whole system, the current timestamps are compared to the stored timestamps. Any class that has been changed in the meantime will be analyzed again; for any unchanged class the rule violations are taken from the cache.
Example Command: Analyze One Class
We will now roughly go through the code that is executed on the GUI part when the user wants to analyze a single class. As mentioned in Chapter Running the Analyzer, this can be done using the class context menu or by dropping the class stone on the button Analyze Item.
In any case {ES_CODE_ANALYSIS_COMMAND}.execute_with_stone
is called, which delegates to execute_with_stone_content
:
execute_with_stone (a_stone: STONE) -- Execute with `a_stone'. do execute_with_stone_content (a_stone, Void) end execute_with_stone_content (a_stone: STONE; a_content: SD_CONTENT) -- Execute with `a_stone'. local l_save_confirm: ES_DISCARDABLE_COMPILE_SAVE_FILES_PROMPT l_classes: DS_ARRAYED_LIST [CLASS_I] do -- Show the tool right from the start. show_ca_tool if not eiffel_project.is_compiling then if window_manager.has_modified_windows then create l_classes.make_default window_manager.all_modified_classes.do_all (agent l_classes.force_last) create l_save_confirm.make (l_classes) l_save_confirm.set_button_action (l_save_confirm.dialog_buttons.yes_button, agent save_compile_and_analyze (a_stone)) l_save_confirm.set_button_action (l_save_confirm.dialog_buttons.no_button, agent compile_and_analyze (a_stone)) l_save_confirm.show_on_active_window else compile_and_analyze (a_stone) end end end
If there are modified, unsaved windows a save confirmation dialog is displayed. Eventually program flow passes on to compile_and_analyze
:
compile_and_analyze (a_stone: STONE) -- Compile project and perform analysis of stone `a_stone'. local l_helper: ES_CODE_ANALYSIS_BENCH_HELPER l_dialog: ES_INFORMATION_PROMPT do -- Compile the project and only analyze if the compilation was successful. eiffel_project.quick_melt (True, True, True) if eiffel_project.successful then create l_helper if l_helper.code_analyzer.is_running then create l_dialog.make_standard (ca_messages.already_running_long) l_dialog.show_on_active_window else perform_analysis (a_stone) end end end
eiffel_project.quick_melt
starts the compilation. A successful compilation is required for code analysis; otherwise nothing is analyzed. After compilation has succeeded we check if code analysis is already running. If this is the case then a dialog is displayed. If on the other hand this last possible obstacle is not present we finally start analyzing by calling perform_analysis
.
perform_analysis (a_stone: STONE) -- Analyze `a_stone' only. local l_helper: ES_CODE_ANALYSIS_BENCH_HELPER l_scope_label: EV_LABEL do -- For simplicity let us assume that `a_stone' does not -- correspond to the system or is equivalent to it. last_was_analyze_all := False create l_helper code_analyzer := l_helper.code_analyzer code_analyzer.clear_classes_to_analyze code_analyzer.rule_violations.wipe_out l_scope_label := ca_tool.panel.scope_label if attached {CLASSC_STONE} a_stone as s then code_analyzer.add_class (s.class_i.config_class) l_scope_label.set_text (s.class_name) l_scope_label.set_foreground_color (create {EV_COLOR}.make_with_8_bit_rgb (140, 140, 255)) l_scope_label.set_pebble (s) l_scope_label.set_pick_and_drop_mode l_scope_label.set_tooltip (ca_messages.class_scope_tooltip) elseif [...] [...] end disable_tool_button window_manager.display_message (ca_messages.status_bar_running) code_analyzer.add_completed_action (agent analysis_completed) code_analyzer.analyze end
(The code that deals with stones other than classes is omitted.)
At the start of the routine the code analyzer instance is retrieved from the helper class. All classes that may have been addedbefore, are removed. All previous rule violations are removed as well. The if clause creates a stone for the Last Scope label in the graphical panel. Then, the button in the tool is disabled so that starting another analysis is prevented until the current one has completed. Finally, the analysis is started. As soon as the analysis has completed {ES_CODE_ANALYSIS_COMMAND}.analysis_completed
is called. In this procedure the rule violations (and possibly the exceptions) are retrieved from the code analyzer and displayed in the list in the tool panel.
Command-Line Interface
The whole command-line functionality of the code analyzer is located in the class {EWB_CODE_ANALYSIS}
. It is located in the tty cluster of EiffelStudio. {EWB_CODE_ANALYSIS}
is invoked by {ES}
, the root class for the batch (command-line) version of EiffelStudio. In {ES}
, the invocation looks as follows:
elseif option.is_equal ("-code-analysis") then l_at_args := arguments_in_range (current_option + 1, argument_count) current_option := argument_count + 1 create {EWB_CODE_ANALYSIS} command.make_with_arguments (l_at_args)
Any command-line arguments after -code-analysis are passed on to {EWB_CODE_ANALYSIS}
. This class, in its creation procedure, processes the arguments as described in Command Line Usage. Classes that were passed as command-line arguments are added to the analyzer. Then the actual execution happens in the procedure execute
. EWB_CODE_ANALYSIS
of course uses the code_analysis library and the previously described interface of CA_CODE_ANALYZER
. After analysis a list of rule violations is output to the command-line. In the code it looks like this:
across l_code_analyzer.rule_violations as l_vlist loop if not l_vlist.item.is_empty then l_has_violations := True -- Always sort the rule violations by the class they are referring to. output_window.add (ca_messages.cmd_class + l_vlist.key.name + "':%N") -- See `{CA_RULE_VIOLATION}.is_less' for information on the sorting. across l_vlist.item as ic loop l_rule_name := ic.item.rule.title l_rule_id := ic.item.rule.id if attached ic.item.location as l_loc then l_line := ic.item.location.line.out l_col := ic.item.location.column.out output_window.add (" (" + l_line + ":" + l_col + "): " + l_rule_name + " (" + l_rule_id + "): ") else -- No location attached. Print without location. output_window.add (" " + l_rule_name + " (" + l_rule_id + "): ") end ic.item.format_violation_description (output_window) output_window.add ("%N") end end end if not l_has_violations then output_window.add (ca_messages.no_issues + "%N") end