diff --git a/docs/Images/State_diagram_srs.png b/docs/Images/State_diagram_srs.png new file mode 100644 index 00000000..88316301 Binary files /dev/null and b/docs/Images/State_diagram_srs.png differ diff --git a/docs/Images/WorkContextModel.png b/docs/Images/WorkContextModel.png index 14b93cb6..e7955ab1 100644 Binary files a/docs/Images/WorkContextModel.png and b/docs/Images/WorkContextModel.png differ diff --git a/docs/Images/product_boundary.png b/docs/Images/product_boundary.png new file mode 100644 index 00000000..cef9ba37 Binary files /dev/null and b/docs/Images/product_boundary.png differ diff --git a/docs/SRS/SRS.pdf b/docs/SRS/SRS.pdf index 836e1053..23fc2f07 100644 Binary files a/docs/SRS/SRS.pdf and b/docs/SRS/SRS.pdf differ diff --git a/docs/SRS/SRS.tex b/docs/SRS/SRS.tex index 8172eabb..732c64f7 100644 --- a/docs/SRS/SRS.tex +++ b/docs/SRS/SRS.tex @@ -28,6 +28,10 @@ } \usepackage{float} +\usepackage{tikz} +\usetikzlibrary{automata, positioning, arrows.meta, shapes, backgrounds} +\usepackage{float} % For precise figure placement + \newcommand{\lips}{\textit{Insert your content here.}} % Test line @@ -57,22 +61,34 @@ \section*{Revision History} -\begin{tabularx}{\textwidth}{p{3.7cm}p{1.8cm}X} - \toprule {\textbf{Date}} & {\textbf{Version}} & {\textbf{Notes}}\\ +\begin{tabularx}{\textwidth}{p{3.7cm}>{\raggedright\arraybackslash}p{1.8cm}X} + \toprule {\textbf{Date}} & {\textbf{Name}} & {\textbf{Notes}}\\ \midrule - October 11th, 2024 & 0 & Created initial revision of SRS\\ - January 2nd, 2025 & 1 & Added clarification to training requirements\\ - January 5th, 2025 & 0.1 & Update FR-7, FR-8, Ideas for Solution \\ - January 6th, 2025 & 0.1 & Fixed link references to tables and + October 11th, 2024 & All & Created initial revision of SRS\\ + January 2nd, 2025 & All & Added clarification to training requirements\\ + January 5th, 2025 & All & Update FR-7, FR-8, Ideas for Solution \\ + January 6th, 2025 & All & Fixed link references to tables and figures and added preambles to those sections, move glossary section, added symbolic constants\\ - February 8th, 2025 & 0.2 & Removed requirement for interfacing with + February 8th, 2025 & All & Removed requirement for interfacing with GitHub Actions.\\ - February 10th, 2025 & 0.2 & Updated the data dictionary and + February 10th, 2025 & All & Updated the data dictionary and business data model \\ - February 10th, 2025 & 0.2 & Updated costs, compliance requirements, + February 10th, 2025 & All & Updated costs, compliance requirements, security requirements and scope of the product. \\ - \bottomrule + March 24th, 2025 & All & Updated and added functional requirements. \\ + March 24th, 2025 & Mya Hussain & Updated Usability and Humanity Requirements. \\ + March 24th, 2025 & Ayushi Amin & Updated maintainability and support requirements. \\ + March 24th, 2025 & Ayushi Amin & Updated cultural requirements. \\ + March 24th, 2025 & Sevhena Walker & Updated solution constraints, style requirements, wider environment reqs, updated MD-EC1 to be less ambiguous. \\ + March 24th, 2025 & Mya Hussain & Updated Performance Requirements. \\ + March 24th, 2025 & Mya Hussain & Updated New Problems. \\ + March 24th, 2025 & Ayushi Amin & Updated Scope of Work. \\ + March 24th, 2025 & Ayushi Amin & Updated user documentation and training requirements. \\ + March 24th, 2025 & Ayushi Amin & Updated migration of new product. \\ + March 24th, 2025 & Ayushi Amin & Updated Costs section. \\ + March 24th, 2025 & Mya Hussain & Created state diagram closes feedback. \\ + \bottomrule \end{tabularx} ~\\ @@ -96,7 +112,7 @@ \section*{Symbolic Constants} MIN\_USER\_EOU & 80\% \\ SMALL\_FILE\_TIME & 5 sec \\ LARGE\_FILE\_TIME & 30 sec \\ - REFACTOR\_TIME & 10 sec \\ + REFACTOR\_TIME & 30 sec \\ DETECTION\_ACC & 90\% \\ LARGE\_CODE\_BASE\_TIME & 2 min \\ NEW\_REFACTOR\_TIME & 7 days \\ @@ -518,30 +534,14 @@ \subsection{Maintenance Users and Service Technicians} \section{Mandated Constraints} \subsection{Solution Constraints} \begin{enumerate}[label=MD-SL \arabic*., wide=0pt, leftmargin=*] - \item \emph{The system must refactor Python code without changing - its original functionality.}\\[2mm] - {\bf Rationale:} The project is focused on energy-efficient - refactoring for Python code, and altering functionality could - break existing software behaviour.\\ - {\bf Fit Criterion:} The system must pass all original test cases - after refactoring, ensuring that functionality remains unchanged.\\ + \item \emph{The system must exclusively focus on refactoring Python code.}\\[2mm] + {\bf Rationale:} Python, while widely adopted for its simplicity and versatility, is known to be less energy-efficient compared to other programming languages. This project aims to address this inefficiency by providing targeted refactoring solutions for Python code.\\ + {\bf Fit Criterion:} The system must accept only Python code as input and produce refactored Python code as output.\\ {\bf Priority:} High - \item \emph{The refactored code must result in measurable energy - savings.}\\[2mm] - {\bf Rationale:} The project's primary objective is to improve - the code's energy efficiency. Refactorings should lead to a - noticeable reduction in energy consumption.\\ - {\bf Fit Criterion:} The system must show at least a ENERGY\_SAVE - reduction in energy consumption, as measured by tools like - \texttt{CodeCarbon}, for most of the refactored code.\\ - {\bf Priority:} High - \item \emph{The refactored code must be provided to the user upon - completion of the refactoring process.}\\[2mm] - {\bf Rationale:} Developers need access to the refactored code to - utilize it in their projects immediately after the refactoring process.\\ - {\bf Fit Criterion:} The system must deliver the refactored code - to the user in a clear format, ensuring it is readily available - for implementation.\\ + + \item \emph{The plugin must be implemented as a Visual Studio Code (VSCode) extension.}\\[2mm] + {\bf Rationale:} VSCode is one of the most popular IDEs among developers, and integrating the tool as a VSCode extension ensures accessibility and ease of use.\\ + {\bf Fit Criterion:} The plugin must be installable from the VSCode marketplace and provide seamless integration with the VSCode environment.\\ {\bf Priority:} High \end{enumerate} @@ -557,7 +557,7 @@ \subsection{Implementation Environment of the Current System} to a wide range of users without the need for specialized hardware.\\ {\bf Fit Criterion:} The tool must be installable and functional on a standard laptop with Visual Studio Code. It should perform - well without requiring excessive processing power or memory.\\ + effectively on standard developer workstations without surpassing typical processing power or memory capacity limits.\\ {\bf Priority:} High \end{enumerate} \subsection{Partner or Collaborative Applications} @@ -682,19 +682,15 @@ \subsection{The Current Situation} \item \textbf{Developer Education:} Raising awareness about energy-efficient coding practices through the tool's suggestions and documentation. - \item \textbf{Continuous Improvement:} Implementing a reinforcement - learning model to improve refactoring suggestions over time based - on developer feedback and real-world energy savings data. \end{enumerate} \subsection{The Context of the Work} The purpose of this subsection is to illustrate the flow of inputs, outputs, and interactions between the refactoring library and its -external systems, such as developers, energy measurement tools, and -machine learning frameworks. \hyperref[img:work-context]{Figure 1} -highlights the connections between the system's components and -external elements, ensuring a comprehensive understanding of its -operational environment. +external systems, such as developers and energy measurement tools. +\hyperref[img:work-context]{Figure 1} highlights the connections between +the system's components and external elements, ensuring a comprehensive +understanding of its operational environment. \begin{figure}[H] \centering @@ -715,19 +711,19 @@ \subsection{Work Partitioning} \begin{table}[H] \centering \setlength\extrarowheight{5mm} - \begin{tabularx}{\textwidth}{|c|X|l|p{1.5in}|} + \begin{tabularx}{\textwidth}{|c|X|l|p{1.5in}|p{1.5in}|} \toprule \textbf{Event \#} & \textbf{Event Name} & \textbf{Input} - & \textbf{Output(s)} \\ + & \textbf{Output(s)} & \textbf{Requirements}\\ \midrule - 1 & Users submit Python code & Python Code & Refactored Code\\ - 2 & Energy Analysis of code & Python Code & Total Energy Consumed \\ - 3 & RI Model produces refactoring & Python Code & Correct Refactoring \\ - 4 & Testing and Validation of refactored code & Refactored Code & - Test Results \\ - 5 & Reporting Performance metrics of new code & Refactored Code & - Performance Reports \\ - 6 & Viewing Energy consumption reports & Refactored Code & Energy - Consumption Statistics \\ + 1 & Users submit Python code & Python Code & Refactored Code & + FR1, FR2, FR3, FR4, FR6, PR-SL1, PR-RFT1, PR-CR1, SR-AR1, MS-AD3\\ + 2 & Energy Analysis of code & Python Code & Total Energy Consumed & + FR6, OER-IAS2, SR-AR1, SR-AR2, MS-AD4\\ + 3 & Refactoring library produces refactoring & Python Code & Correct Refactoring & + FR3, FR4, PR-SCR1, PR-PAR2, SR-IR1, CR-SCR1\\ + 4 & Viewing Energy consumption metrics & Refactored Code & Energy + Consumption Metrics & + FR6, LFR-AP1, CULT1, SR-PR2 \\ \bottomrule \end{tabularx} \caption{Work Partitioning of System} @@ -740,35 +736,29 @@ \subsection{Specifying a Business Use Case (BUC)} handles specific scenarios. \begin{enumerate}[label={\bf BUC \arabic*:}, wide=0pt, font=\itshape] - \item {\bf Code Submission} \\[2mm] + \item {\bf Users submit Python code} \\[2mm] \textbf{Input:} Python Code \\ \textbf{Output:} Refactored Code \\ - \textbf{Pre-condition:} User uses either GitHub Action or a VS - Code plugin to submit code to the refactoring tool \\[2mm] + \textbf{Pre-condition:} User uses the VS Code plugin to submit python code to the + refactoring tool \\[2mm] \textbf{Scenario:} \begin{enumerate}[label=\arabic*.] \item Refactoring tool receives the Python code - \item PyJoules is used to store energy consumption data for the + \item Code Carbon is used to store energy consumption data for the original Python code submitted - \item Tool analyzes the code for inefficiencies (PySmells) - \item Python code is provided to the Re-enforcement learning - model to find a refactoring + \item Tool analyzes the code for inefficiencies (PyLint) + \item Python code is provided to the appropriate refactorer in the library + \item Specific refactorer produces the correct refactoring for the code \item Energy consumption is measured of refactored code and compared to the original data - \item Refactored code is tested to ensure functionality is - maintained from the original code \item Refactored code is received by the user \end{enumerate} \textbf{Sub Variation: } \begin{itemize} - \item \textit{4a:} If no PySmells are identified, then code is - returned to the user - \item \textit{6a:} If energy consumption increases for - refactored code, the reinforcement model is asked to find - another refactoring - \item \textit{7a:} If code functionality is not preserved for - refactored code, the reinforcement model is asked to find - another refactoring + \item \textit{4a:} If no code smells are identified, then user is notified of no code + smells present in the file and code is returned to the user + \item \textit{7a:} If energy consumption increases for refactored code, the original + code is returned to user with a description of the issue \end{itemize} \item {\bf Energy Analysis of Code}\\[2mm] @@ -780,68 +770,35 @@ \subsection{Specifying a Business Use Case (BUC)} \begin{enumerate}[label=\arabic*.] \item Tool receives Python Code \item Energy consumed is measured during execution - \item The analysis results are compiled into a report - \item Report of total energy consumed is received by the refactoring tool + \item Results of total energy consumed is received by the refactoring tool \end{enumerate} - \item {\bf Reinforcement Learning Model Produces Refactoring} \\[2mm] + \item {\bf Refactoring Library Produces Refactoring} \\[2mm] \textbf{Input:} Python Code \\ \textbf{Output:} Correct Refactoring \\ - \textbf{Pre-condition:} Request for refactored code from the - Reinforcement Learning Model \\[2mm] + \textbf{Pre-condition:} Request for refactored code from the specific refactorer + based on code smell\\[2mm] \textbf{Scenario: } \begin{enumerate}[label=\arabic*.] - \item Model receives Python Code - \item Analyze Code for potential refactoring - \item Generate suggestions based on previous learning and data - \item Implement suggested refactorings + \item Specific refactorer receives Python Code + \item Analyze Code for refactoring + \item Implement a refactoring for the given code based on pre-defined strategies + \item Return refactored code to user \end{enumerate} \textbf{Sub Variation: } \begin{itemize} - \item \textit{2a:} If there are no refactorings found, Model - outputs are given code back to the refactoring tool + \item \textit{4a:} If refactoring can not be done on given code, the refactorer + will return original code to user \end{itemize} - \item {\bf Testing and Validation of Refactored Code} \\[2mm] - \textbf{Input:} Refactored Code \\ - \textbf{Output:} Test Results \\ - \textbf{Pre-condition:} Energy consumed for refactored code is - less than the energy consumed for original code \\[2mm] - \textbf{Scenario: } - \begin{enumerate}[label=\arabic*.] - \item Conduct tests on refactored code - \item Conduct tests on original code - \item Validate results of refactored code to the results of the - original code to ensure functionality is intact - \item Signal to refactoring tool to send refactored code to the user - \end{enumerate} - \textbf{Sub Variation: } - \begin{itemize} - \item \textit{4a:} If functionality is not preserved, signal to - the refactoring tool to refactor again - \end{itemize} - - \item {\bf Reporting Performance Metrics of New Code} \\[2mm] - \textbf{Input:} Refactored Code \\ - \textbf{Output:} Performance Reports\\ - \textbf{Pre-condition:} Testing and validation is completed - successfully \\[2mm] - \textbf{Scenario: } - \begin{enumerate}[label=\arabic*.] - \item Generate detailed performance report based on testing outcomes - \item User receives the performance report - \end{enumerate} - - \item {\bf Viewing Energy Consumption Reports} \\[2mm] + \item {\bf Viewing Energy Consumption Metrics} \\[2mm] \textbf{Input:} Refactored Code \\ - \textbf{Output:} Energy Consumption Statistics \\ - \textbf{Pre-condition:} Testing and validation is completed - successfully \\[2mm] + \textbf{Output:} Energy Consumption Metrics \\ + \textbf{Pre-condition:} Energy consumption of refactored code is less than energy consumption + of original code \\[2mm] \textbf{Scenario: } \begin{enumerate}[label=\arabic*.] - \item Comprehensive statistics are compiled from energy analysis data - \item Information is compiled in an accessible format for - developers to review + \item Metrics are compiled in an accessible format for developers to review \end{enumerate} \end{enumerate} @@ -916,7 +873,7 @@ \subsection{Product Boundary} \begin{figure}[H] \centering - \includegraphics[width=0.9\textwidth]{../Images/use_case_diagram.png} + \includegraphics[width=1.1\textwidth]{../Images/product_boundary.png} \caption{Product Boundary Diagram of System} \label{img:prod-bound} \end{figure} @@ -929,37 +886,45 @@ \subsection{Product Use Case Table} describes the interaction between the user and the system. \setlength\extrarowheight{2mm} +\renewcommand{\arraystretch}{0.85} +\begin{longtable}{|c| + >{\raggedright\arraybackslash}p{1.5in}| % Reduced from 1.8in + >{\raggedright\arraybackslash}p{1in}| + >{\raggedright\arraybackslash}p{1.8in}| + >{\raggedright\arraybackslash}p{1.1in}|} % Increased from 0.8in + \caption{Product Use Case Table} + \label{tab:puc} \\ + \hline + \textbf{PUC \#} & \textbf{PUC Name} & \textbf{Actor/s} & \textbf{Input \& Output(s)} & \textbf{Requirement} \\ + \hline + \endfirsthead + + \hline + \textbf{PUC \#} & \textbf{PUC Name} & \textbf{Actor/s} & \textbf{Input \& Output(s)} & \textbf{Requirement} \\ + \hline + \endhead -\begin{table}[H] - \centering - \begin{tabularx}{\textwidth}{|c| - >{\raggedright\arraybackslash}X| - >{\raggedright\arraybackslash}p{1.2in}| - >{\raggedright\arraybackslash}X|} - \toprule \textbf{PUC \#} & \textbf{PUC Name} & \textbf{Actor/s} & - \textbf{Input \& Output(s)} \\ - \midrule - 1 & Detect Code Smells & VS Code Plugin (via Refactoring Library) - & Original Code (in), Identified Code Smells (out) \\ - 2 & Select Code Smell for Refactoring & User & Selected Code Smell (in) \\ - 3 & Refactor Code & VS Code Plugin (via Refactoring Library) & - Code Segment (in), Refactored Code (out) \\ - 4 & Measure Energy Consumption Before Refactoring & Refactoring - Library (via Energy Measurement Tool) & Original Code (in), - Initial Energy Consumption Results (out) \\ - 5 & Measure Energy Consumption After Refactoring & Refactoring - Library (via Energy Measurement Tool) & Refactored Code (in), - Final Energy Consumption Results (out) \\ - 6 & Show Results & VS Code Plugin & Refactored Code, Performance - Metrics (out) \\ - 7 & Accept or Reject Refactoring Results & User & Refactored - Code, Energy Consumption Results (in), Accepted or Rejected - Decision (out) \\ - \bottomrule - \end{tabularx} - \caption{Product Use Case Table of System} - \label{tab:puc} -\end{table} + \hline + \endfoot + + \hline + \endlastfoot + + 1 & Detect Code Smells & VS Code Plugin (via Refactoring Lib.) & Original Code (in), Identified Code Smells (out) & FR1, FR2, FR11, PR-SL1, LFR-ST1 \\ + 2 & Toggle Smell Linting & User & Toggle Command (in), Enabled/Disabled Linting (out) & FR17, LFR-ST1 \\ + 3 & Filter Code Smells & User & Filter Criteria (in), Filtered Smells (out) & FR10, LFR-ST1, UHR-EOU1 \\ + 4 & Configure Smell Detection & User & Threshold Parameters (in), Updated Detection Rules (out) & FR14, FR19, LFR-ST1 \\ + 5 & Configure Smell Display & User & Display Preferences (in), Updated VS Code Settings (out) & FR12, PR-LR1, OER-RL1 \\ + 6 & Select Code Smell & User & Selected Code Smell (in) & FR13, PR-LR1, OER-RL1\\ + 7 & Refactor Code & VS Code Plugin (via Refactoring Lib.) & Code Segment (in), Refactored Code (out) & FR3, FR4, FR8, PR-SCR1 \\ + 8 & Measure Energy (Before) & Refactoring Library (via Energy Tool) & Original Code (in), Initial Energy Results (out) & FR6, PR-LR1, OER-RL1, MS-AD5 \\ + 9 & Measure Energy (After) & Refactoring Library (via Energy Tool) & Refactored Code (in), Final Energy Results (out) & FR6, PR-LR1, OER-RL1, MS-AD5 \\ + 10 & Show Results & VS Code Plugin & Refactored Code, Performance Metrics (out) & FR6, FR11, LFR-AP1, CULT1 \\ + 11 & Accept/Reject Results & User & Refactored Code, Energy Results (in), Decision (out) & FR16, FLR-AP1, PR-SCR1 \\ + 12 & Clear Smell History & User & Clear Command (in), Reset Cache (out) & FR18, PR-LR1, OER-RL1, MS-AD5, MS-AD6, MS-AD7, UHR-EOU1 \\ + 13 & Access Documentation & User & Help Request (in), Documentation (out) & FR7, OER-PR1, MS-AD6 \\ + 14 & Generate System Logs & System & Log Request (in), Log File (out) & FR15, MS-AD6, MS-AD7 \\ +\end{longtable} \subsection{Individual Product Use Cases (PUC's)} This subsection expands on the use cases listed in @@ -971,8 +936,7 @@ \subsection{Individual Product Use Cases (PUC's)} \begin{enumerate}[label={\bf PUC \arabic*:}, wide=0pt, font=\itshape] \item \textbf{Detect Code Smells} \\[2mm] - \textbf{Trigger:} The VS Code Plugin processes the input code - using the refactoring library. \\[2mm] + \textbf{Trigger:} The VS Code Plugin processes the input code using the refactoring library. \\[2mm] \textbf{Preconditions:} \begin{itemize} \item The VS Code Plugin has received the original code. @@ -983,9 +947,53 @@ \subsection{Individual Product Use Cases (PUC's)} \textbf{Input:} Original Python Code. \\ \textbf{Output:} List of detected code smells. + \item \textbf{Toggle Smell Linting} \\[2mm] + \textbf{Trigger:} User requests to enable or disable smell detection highlighting. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item The VS Code Plugin is active. + \item Code file is open in the editor. + \end{itemize} + \textbf{Actors:} User. \\ + \textbf{Outcome:} Smell detection highlighting is toggled on/off. \\ + \textbf{Input:} Toggle Command. \\ + \textbf{Output:} Enabled/Disabled smell highlighting. + + \item \textbf{Filter Code Smells} \\[2mm] + \textbf{Trigger:} User applies filters to focus on specific smell types. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item Code smells have been detected. + \item Smell list is visible to user. + \end{itemize} + \textbf{Actors:} User. \\ + \textbf{Outcome:} Only filtered smells are displayed. \\ + \textbf{Input:} Filter Criteria. \\ + \textbf{Output:} Filtered subset of detected smells. + + \item \textbf{Configure Smell Detection} \\[2mm] + \textbf{Trigger:} User modifies detection parameters for specific smells. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item None. + \end{itemize} + \textbf{Actors:} User. \\ + \textbf{Outcome:} Smell detection thresholds are updated. \\ + \textbf{Input:} Threshold Parameters. \\ + \textbf{Output:} Updated Detection Rules. + + \item \textbf{Configure Smell Display} \\[2mm] + \textbf{Trigger:} User accesses settings to modify smell display preferences. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item None. + \end{itemize} + \textbf{Actors:} User. \\ + \textbf{Outcome:} Code smells are displayed according to user-configured visual styles. \\ + \textbf{Input:} Display Preferences (color, design). \\ + \textbf{Output:} Updated visual representation of smells in linted files. \item \textbf{Select Code Smell for Refactoring} \\[2mm] - \textbf{Trigger:} The user selects a detected code smell to be - refactored. \\[2mm] + \textbf{Trigger:} The user selects a detected code smell to be refactored. \\[2mm] \textbf{Preconditions:} \begin{itemize} \item The system has identified code smells. @@ -997,8 +1005,7 @@ \subsection{Individual Product Use Cases (PUC's)} \textbf{Output:} Selected smell is marked for refactoring. \item \textbf{Refactor Code} \\[2mm] - \textbf{Trigger:} The user has selected a code smell for - refactoring. \\[2mm] + \textbf{Trigger:} The user has selected a code smell for refactoring. \\[2mm] \textbf{Preconditions:} \begin{itemize} \item Code smells have been detected. @@ -1010,8 +1017,7 @@ \subsection{Individual Product Use Cases (PUC's)} \textbf{Output:} Refactored Python Code. \item \textbf{Measure Energy Consumption Before Refactoring} \\[2mm] - \textbf{Trigger:} The refactoring library submits the original - code to the energy measurement tool. \\[2mm] + \textbf{Trigger:} The refactoring library submits the original code to the energy measurement tool. \\[2mm] \textbf{Preconditions:} \begin{itemize} \item The system has received the original code. @@ -1023,8 +1029,7 @@ \subsection{Individual Product Use Cases (PUC's)} \textbf{Output:} Initial Energy Consumption Results. \item \textbf{Measure Energy Consumption After Refactoring} \\[2mm] - \textbf{Trigger:} The refactored code is submitted to the energy - measurement tool. \\[2mm] + \textbf{Trigger:} The refactored code is submitted to the energy measurement tool. \\[2mm] \textbf{Preconditions:} \begin{itemize} \item The system has refactored the code. @@ -1036,34 +1041,71 @@ \subsection{Individual Product Use Cases (PUC's)} \textbf{Output:} Final Energy Consumption Results. \item \textbf{Show Results} \\[2mm] - \textbf{Trigger:} Refactored code and energy consumption metrics - are ready. \\[2mm] + \textbf{Trigger:} Refactored code and energy consumption metrics are ready. \\[2mm] \textbf{Preconditions:} \begin{itemize} \item The refactoring process has completed. \item Energy consumption before and after refactoring has been measured. \end{itemize} \textbf{Actors:} VS Code Plugin. \\ - \textbf{Outcome:} The refactored code and performance metrics are - presented to the user. \\ + \textbf{Outcome:} The refactored code and performance metrics are presented to the user. \\ \textbf{Output:} Refactored Code, Energy Consumption Results. \item \textbf{Accept or Reject Refactoring Results} \\[2mm] - \textbf{Trigger:} The user reviews the refactored code and its - energy consumption results. \\[2mm] + \textbf{Trigger:} The user reviews the refactored code and its energy consumption results. \\[2mm] \textbf{Preconditions:} \begin{itemize} - \item The system has presented the refactored code and energy - consumption results. + \item The system has presented the refactored code and energy consumption results. \end{itemize} \textbf{Actors:} User. \\ - \textbf{Outcome:} The user accepts or rejects the refactored - code. If rejected, no changes are applied. If accepted, the - refactored code replaces the original. \\ + \textbf{Outcome:} The user accepts or rejects the refactored code. If rejected, no changes are applied. If accepted, the refactored code replaces the original. \\ \textbf{Input:} Refactored Code, Energy Consumption Results. \\ \textbf{Output:} Accepted or Rejected Decision. + \item \textbf{Clear Smell History} \\[2mm] + \textbf{Trigger:} User requests to clear previously detected smells. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item Smell detection history exists. + \end{itemize} + \textbf{Actors:} User. \\ + \textbf{Outcome:} All stored smell detection data is removed. \\ + \textbf{Input:} Clear Command. \\ + \textbf{Output:} Reset cache state. + + \item \textbf{Access Documentation} \\[2mm] + \textbf{Trigger:} User looks up for documentation. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item Documentation is available. + \end{itemize} + \textbf{Actors:} User. \\ + \textbf{Outcome:} Documentation is displayed to user. \\ + \textbf{Input:} Help Request. \\ + \textbf{Output:} Documentation content. + + \item \textbf{Generate System Logs} \\[2mm] + \textbf{Trigger:} System records operational data and user requests logs. \\[2mm] + \textbf{Preconditions:} + \begin{itemize} + \item User has used the system. + \end{itemize} + \textbf{Actors:} System. \\ + \textbf{Outcome:} Log entries are created for system events. \\ + \textbf{Input:} Log Request. \\ + \textbf{Output:} Log File entries. +% scale=0.5, +% transform shape \end{enumerate} +\subsection{System State Diagram} +The following is a state diagram of the system. +\begin{figure}[H] + \centering + \includegraphics[scale=0.5]{../Images/State_diagram_srs.png} + \caption{System State Diagram} + \label{img:state-diagram} +\end{figure} + \section{Functional Requirements} \subsection{Functional Requirements} @@ -1083,32 +1125,17 @@ \subsection{Functional Requirements} for the detection and reporting of the following smells: Long Parameter List (LPL), Long Message Chain (LMC), Long Element Chain (LEC), Long Lambda Function (LLF), Complex List - Comprehension (CLC), Member Ignoring Method (MIM), Repeating Chain (RC).\\ - {\bf Priority:} High - \item \emph{The system shall maintain the original functionality of - the Python code after refactoring.}\\[2mm] - {\bf Rationale:} Ensuring that the refactored code preserves the - original behaviour is critical to avoid regressions or unexpected - issues in the software.\\ - {\bf Fit Criterion:} The system runs the original test suite - against the refactored code and the amount of test to pass should - meet the TEST\_FUNCTION\_THRESH.\\ - {\bf Priority:} High - \item \emph{The system must allow users to input their original - test suite as a required argument.}\\[2mm] - {\bf Rationale:} Verifying that the refactored code preserves - functionality requires the use of the original test suite.\\ - {\bf Fit Criterion:} Users can specify a path to their test suite - that the tool recognizes and utilizes for testing the refactored code.\\ + Comprehension (CLC), Member Ignoring Method (MIM), Cache Repeated Calls (CRC), + String Concat in Loop (SCL).\\ {\bf Priority:} High \item \emph{The system must suggest at least one appropriate refactoring for each detected code smell to decrease energy consumption or indicate that none can be found.}\\[2mm] {\bf Rationale:} For developers to optimize their code, the tool - must provide appropriate refactoring suggestions based on + must provide an appropriate refactoring suggestion based on detected code smells.\\ {\bf Fit Criterion:} The suggested refactored code demonstrates a - measurable improvement in energy consumption as measured in joules.\\ + measurable improvement in energy consumption as measured in kg.\\ {\bf Priority:} High \item \emph{The system must produce valid refactored Python code as output or indicate that no possible refactorings were found.}\\[2mm] @@ -1128,14 +1155,10 @@ \subsection{Functional Requirements} environment and successfully analyzes and refactors code written for Python versions 3.8, 3.9, and newer.\\ {\bf Priority:} Medium - \item \emph{The tool must generate comprehensive reports on - detected smells, refactorings applied, energy consumption - measurements, and testing results.}\\[2mm] - {\bf Rationale:} Developers need clear reports to understand the - impact of the refactorings and to track changes effectively.\\ - {\bf Fit Criterion:} Reports are clear, well-structured, and - provide actionable insights, allowing users to easily understand - the results.\\ + \item \emph{The system must generate and display energy consumption metrics.}\\[2mm] + {\bf Rationale:} Developers need clear metrics as a justification for energy efficient refactorings.\\ + {\bf Fit Criterion:} Energy consumption metrics are clear, well-structured, and + provide actionable insights, allowing users to easily understand the results.\\ {\bf Priority:} Medium \item \emph{The tool must provide comprehensive documentation and help resources.}\\[2mm] @@ -1146,7 +1169,7 @@ \subsection{Functional Requirements} completeness from users.\\ {\bf Priority:} Medium \item \emph{The system shall provide developers with refactoring - suggestions within an IDE before committing code, allowing them + suggestions within an IDE before changing code, allowing them to review and approve energy-efficient changes.}\\[2mm] {\bf Rationale:} Giving developers control over which refactorings are applied ensures that they can maintain the @@ -1154,18 +1177,71 @@ \subsection{Functional Requirements} project requirements.\\ {\bf Fit Criterion:} The IDE plugin must display at least two refactoring options for inefficient code patterns, allowing - developers to either apply or reject them before committing the changes.\\ + developers to either apply or reject them before making any changes.\\ + {\bf Priority:} Medium + \item \emph{The system shall provide developers with refactoring + suggestions within an IDE before changing code, allowing them + to review and approve energy-efficient changes.}\\[2mm] + {\bf Rationale:} Giving developers control over which + refactorings are applied ensures that they can maintain the + balance between energy efficiency and their coding style or + project requirements.\\ + {\bf Fit Criterion:} The IDE plugin must display at least two + refactoring options for inefficient code patterns, allowing + developers to either apply or reject them before making any changes.\\ + {\bf Priority:} Medium + \item \emph{The system must allow users to filter detected code smells within the IDE plugin.}\\[2mm] + {\bf Rationale:} Developers should be able to focus on specific types of inefficiencies based on their + project needs and priorities.\\ + {\bf Fit Criterion:} The plugin provides a user-friendly interface that enables filtering detected code + smells by category, severity, or type, ensuring a customized refactoring experience.\\ + {\bf Priority:} Medium + \item \emph{The system should indicate code smells within a smell-linted file.}\\[2mm] + {\bf Rationale:} Developers need a clear visual representation of detected code smells to efficiently identify problematic areas in their code.\\ + {\bf Fit Criterion:} The system highlights detected code smells within the source file, for example, by underlining or marking affected lines.\\ + {\bf Priority:} High + + \item \emph{The system should allow users to configure how code smells are displayed within a smell-linted file.}\\[2mm] + {\bf Rationale:} Different developers may have varying preferences for visual indicators (e.g., colors, underlines, icons) to improve readability and accommodate accessibility needs.\\ + {\bf Fit Criterion:} The system provides user-adjustable settings (e.g., via a preferences menu) to modify the visual representation of code smells, such as changing highlight colors, toggling line markers, or selecting icon-based annotations.\\ + {\bf Priority:} Medium + +\item \emph{The system must allow for refactoring of specific smells.}\\[2mm] + {\bf Rationale:} Developers should have the flexibility to refactor only selected code smells rather than applying all refactorings at once.\\ + {\bf Fit Criterion:} Users can click on a specific detected smell and choose to refactor only that issue.\\ + {\bf Priority:} High + +\item \emph{The system must allow users to configure specific smell detection parameters.}\\[2mm] + {\bf Rationale:} Different projects may have varying definitions of what constitutes a long lambda function or a long message chain, so customizable thresholds improve flexibility.\\ + {\bf Fit Criterion:} The system provides a configuration interface where users can set thresholds for smell detection (e.g., defining the maximum acceptable length for a lambda function or the number of chained method calls before triggering a warning).\\ + {\bf Priority:} Medium + +\item \emph{The system should generate and allow users to access logs of system processes.}\\[2mm] + {\bf Rationale:} Logs provide transparency on system operations, helping users debug issues and track changes.\\ + {\bf Fit Criterion:} The system generates logs detailing detected smells, applied refactorings, and system errors, accessible through an interface or log file.\\ + {\bf Priority:} Medium + +\item \emph{The system must allow users to accept or reject suggested refactored changes and apply the corresponding action.}\\[2mm] + {\bf Rationale:} Developers should have control over the changes made to their code to ensure refactorings align with project requirements.\\ + {\bf Fit Criterion:} The tool provides an interface where users can review, accept, or reject suggested refactorings before they are applied.\\ + {\bf Priority:} High + +\item \emph{The system must allow users to toggle smell linting on and off within the IDE.}\\[2mm] + {\bf Rationale:} Users should be able to control whether code smell detection is actively running, especially to avoid distractions in certain workflows.\\ + {\bf Fit Criterion:} The system provides a toggle button to turn smell linting on or off. When this is enabled, the tool automatically highlights smells in open files, and when disabled, all highlighting/indications are removed.\\ + {\bf Priority:} Medium + +\item \emph{The system must allow users to remove the history of detected smells and other cached data.}\\[2mm] + {\bf Rationale:} Clearing stored data helps users maintain a clean workspace, manage storage, and reset the tool for a fresh start.\\ + {\bf Fit Criterion:} The system provides an option to delete previously detected smells and cached data, ensuring a reset state when needed.\\ {\bf Priority:} Medium - \item \emph{The system shall allow developers to undo any - refactorings applied, restoring the code to its previous state.}\\[2mm] - {\bf Rationale:} Developers may want to revert changes if they do - not align with specific project goals or introduce performance - bottlenecks unrelated to energy consumption.\\ - {\bf Fit Criterion:} The system must provide an option to revert - any refactoring commits applied within the - REFACTOR\_REVERT\_LIMIT, restoring both code and energy - consumption metrics to their original state.\\ + +\item \emph{The system should allow for the enabling and disabling of specific smells for detection.}\\[2mm] + {\bf Rationale:} Developers may want to focus on certain types of inefficiencies while ignoring others based on project-specific needs.\\ + {\bf Fit Criterion:} The system provides an interface where users can enable or disable specific code smells from being detected and reported.\\ {\bf Priority:} Medium + + \end{enumerate} \section{Look and Feel Requirements} @@ -1194,27 +1270,6 @@ \subsection{Appearance Requirements} \end{enumerate} \subsection{Style Requirements} \begin{enumerate}[label=LFR-ST \arabic*., wide=0pt, leftmargin=*] - \item \emph{The tool shall convey a professional and authoritative - appearance to instill confidence in developers.}\\[2mm] - {\bf Rationale:} A professional appearance helps build trust and - encourages developers to use the tool confidently for - energy-efficient refactoring.\\ - {\bf Fit Criterion:} After their first encounter with the tool, - the amount of representative developers that feel that it is a - trustworthy and reliable solution for energy-efficient - refactoring should be above the MIN\_USER\_CONFIDENCE.\\ - {\bf Priority:} High - \item \emph{The IDE plugin interface shall promote a calm and - focused atmosphere, enhancing the developer's ability to - concentrate on code improvements.}\\[2mm] - {\bf Rationale:} A calm environment reduces distractions and - improves productivity, allowing developers to focus on their work - effectively.\\ - {\bf Fit Criterion:} Developers should report feeling less - distracted and more productive while using the tool, with the - amount of developers indicating a positive change in their coding - environment meeting the MIN\_USER\_CONFIDENCE.\\ - {\bf Priority:} Medium \item \emph{The tool design shall be visually appealing and modern, aligning with contemporary software development tools.}\\[2mm] {\bf Rationale:} A modern design improves user experience and @@ -1248,15 +1303,17 @@ \subsection{Ease of Use Requirements} \subsection{Personalization and Internationalization Requirements} \begin{enumerate}[label=UHR-PSI \arabic*., wide=0pt, leftmargin=*] - \item \emph{The tool shall allow users to customize settings to - match their preferences (e.g., refactoring styles, detection - sensitivity).}\\[2mm] - {\bf Rationale:} Allowing customization improves the user - experience by letting developers tailor the tool to their - specific needs and workflows.\\ - {\bf Fit Criterion:} Users should be able to save and load custom - configurations easily.\\ - {\bf Priority:} Medium + \item \emph{The tool shall allow users to enable or disable detection of individual code smells.} + \\[2mm] + {\bf Rationale:} Developers should be able to focus on relevant code smells for their specific project needs.\\ + {\bf Fit Criterion:} Users can successfully toggle detection of any smell type on or off.\\ + {\bf Priority:} High + + \item \emph{The tool shall allow users to customize highlight colors for each detected code smell type.} + \\[2mm] + {\bf Rationale:} Custom colors improve readability and accommodate different visual preferences.\\ + {\bf Fit Criterion:} Users can successfully change highlight colors for any smell type.\\ + {\bf Priority:} Medium \end{enumerate} \subsection{Learning Requirements} @@ -1311,8 +1368,8 @@ \subsection{Speed and Latency Requirements} {\bf Rationale:} Fast analysis ensures that developers do not experience significant delays while reviewing code.\\ {\bf Fit Criterion:} The tool should complete the analysis for - files up to 1,000 lines of code in under SMALL\_FILE\_TIME, and - for files up to 10,000 lines in under LARGE\_FILE\_TIME.\\ + files up to 250 lines of code in under SMALL\_FILE\_TIME, and + for files up to 3000 lines in under LARGE\_FILE\_TIME.\\ {\bf Priority:} High \item \emph{The refactoring process shall be executed efficiently without noticeable delays.}\\[2mm] @@ -1330,23 +1387,11 @@ \subsection{Safety-Critical Requirements} or system failures.}\\[2mm] {\bf Rationale:} Preventing runtime errors ensures system stability and reliability after refactoring.\\ - {\bf Fit Criterion:} The tool should pass all tests from the - user-provided test suite after refactoring, confirming that the - original functionality remains intact. The output code is - syntactically correct and adheres to Python standards, validated - by an automatic linter.\\ + {\bf Fit Criterion:} The refactored code must produce valid Python code verified by the user upon accepting changes\\ {\bf Priority:} High \end{enumerate} \subsection{Precision or Accuracy Requirements} \begin{enumerate}[label=PR-PAR \arabic*., wide=0pt, leftmargin=*] - \item \emph{The tool shall maintain the functionality of the - original provided code in all its recommended refactorings.}\\[2mm] - {\bf Rationale:} Ensuring functionality preservation is critical - for refactorings to be reliable.\\ - {\bf Fit Criterion:} The tool should pass all tests from the - user-provided test suite after refactoring, confirming that the - original functionality remains intact.\\ - {\bf Priority:} High \item \emph{The tool shall reliably identify code smells with minimal false positives and negatives.}\\[2mm] {\bf Rationale:} High detection accuracy ensures that developers @@ -1359,7 +1404,7 @@ \subsection{Precision or Accuracy Requirements} {\bf Rationale:} Ensuring that the tool produces valid output is essential for maintaining code quality.\\ {\bf Fit Criterion:} The output code is syntactically correct and - adheres to Python standards, validated by an automatic linter.\\ + adheres to Python standards.\\ {\bf Priority:} Medium \end{enumerate} @@ -1372,15 +1417,6 @@ \subsection{Robustness or Fault-Tolerance Requirements} {\bf Fit Criterion:} The tool should provide clear error messages and recover from input errors without crashing, ensuring stability.\\ {\bf Priority:} High - \item \emph{The tool shall have fallback options if a specific - refactoring attempt fails.}\\[2mm] - {\bf Rationale:} Providing fallback options ensures the tool - remains functional even when a refactoring fails, reducing - disruptions in development.\\ - {\bf Fit Criterion:} In the event of a failed refactoring, the - tool should log the error and propose alternative refactorings - without stopping the process.\\ - {\bf Priority:} Medium \end{enumerate} \subsection{Capacity Requirements} @@ -1389,7 +1425,7 @@ \subsection{Capacity Requirements} {\bf Rationale:} Efficient handling of large projects ensures that the tool remains usable for teams working with extensive codebases.\\ {\bf Fit Criterion:} The tool must process projects with up to - 100,000 lines of code within LARGE\_CODE\_BASE\_TIME, maintaining + 3000 lines of code within LARGE\_CODE\_BASE\_TIME, maintaining performance standards.\\ {\bf Priority:} High \end{enumerate} @@ -1453,17 +1489,7 @@ \subsection{Expected Physical Environment} \end{enumerate} \subsection{Wider Environment Requirements} -\begin{enumerate}[label=OER-WE \arabic*., wide=0pt, leftmargin=*] - \item \emph{The system must align with widely used emissions - standards (e.g., GRI 305, GHG, ISO 14064) - ~\citep{GHG,ISO14064,GRI305}.}\\[2mm] - {\bf Rationale:} Providing metrics tailored to these standards, - makes the library reporting tool more attractive to users part of - companies looking to reduce their ecological footprint. \\ - {\bf Fit Criterion:} The emissions tracked by the standards are - present in the reported metrics. \\ - {\bf Priority:} Medium -\end{enumerate} +Not applicable. \subsection{Requirements for Interfacing with Adjacent Systems} \begin{enumerate}[label=OER-IAS \arabic*., wide=0pt, leftmargin=*] @@ -1534,8 +1560,8 @@ \subsection{Maintenance Requirements} {\bf Rationale:} Ensuring that new developers can easily understand and modify the system reduces dependency on original developers and facilitates long-term maintenance.\\ - {\bf Fit Criteria:} Comprehensive documentation is available, - including setup guides and code comments, allowing new developers + {\bf Fit Criteria:} Comprehensive documentation is available such + as setup guides and code comments, allowing new developers to understand and modify the system within COMPREHENSION\_TIME.\\ {\bf Priority:} High @@ -1569,17 +1595,8 @@ \subsection{Maintenance Requirements} \end{enumerate} -The following are defined as maintainability requirements: \subsection{Supportability Requirements} -\begin{enumerate}[label=MS-SP \arabic*., wide=0pt, leftmargin=*] - \item \emph{The tool must offer bilingual support for help documentation.}\\ - {\bf Rationale:} Bilingual support ensures that users from - different regions can understand and use the tool effectively, - increasing its accessibility.\\ - {\bf Fit Criteria:} Help documentation is available in both major - languages, English and French.\\ - {\bf Priority:} Low -\end{enumerate} +This section is not needed for this project. \subsection{Adaptability Requirements} \begin{enumerate}[label=MS-AD \arabic*., wide=0pt, leftmargin=*] @@ -1723,7 +1740,7 @@ \subsection{Privacy Requirements} refactoring suggestions without collecting, storing or transmitting any personal information about the user.\\ {\bf Priority:} High - \item \emph{Any data related to user submissions, energy reports + \item \emph{Any data related to user submissions, energy metrics and refactored results must be treated as confidential and handled securely throughout processing and transmission.}\\ {\bf Rationale:} The tool must ensure user trust by safeguarding @@ -1731,7 +1748,7 @@ \subsection{Privacy Requirements} or tampering. Secure handling of data during active sessions maintains the integrity and reliability of the tool. \\ {\bf Fit Criterion:} The system processes user submissions, - energy reports, and refactored results securely within the active + energy metrics, and refactored results securely within the active session. No data is stored or retained after processing, ensuring all user information remains private and protected.\\ {\bf Priority:} High @@ -1746,7 +1763,7 @@ \subsection{Audit Requirements} the user to debug or review tool behavior.\\ {\bf Fit Criterion:} The system generates a log of important operational events, such as the start and completion of analysis, - energy measurements, and refactoring. \\[2mm] + energy measurements, and refactorings. \\[2mm] {\bf Priority:} Medium \item \emph{The tool should log user-triggered actions, such as code submissions and the initiation of refactoring processes, @@ -1760,7 +1777,7 @@ \subsection{Audit Requirements} {\bf Priority:} Medium \end{enumerate} \subsection{Immunity Requirements} -\begin{enumerate}[label=SR-AUR \arabic*., wide=0pt, leftmargin=*] +\begin{enumerate}[label=SR-IMR \arabic*., wide=0pt, leftmargin=*] \item \emph{The tool must minimize exposure to external threats, ensuring that the refactoring process is protected from unauthorized interference.}\\[2mm] @@ -1788,14 +1805,6 @@ \subsection{Cultural Requirements} icons and colours used in the tool are neutral and universally acceptable. {\bf Priority:} Low - \item \emph{The tool must support both metric and imperial - measurement units.}\\ - {\bf Rationale:} Users have different preferences and standards - for measurement units. Supporting both metric and imperial units - ensures accessibility and ease of use for a global audience.\\ - {\bf Fit Criteria:} Users can toggle between metric and imperial - units for any measurements related to energy consumption. - {\bf Priority:} Medium \item \emph{The tool must not include content that could be considered culturally insensitive.}\\ @@ -1834,6 +1843,98 @@ \subsection{Standards Compliance Requirements} {\bf Priority:} Medium \end{enumerate} +\section{Traceability from Requirements to Use Cases} +\begin{longtable}{|p{2.5cm}|p{11cm}|} + \toprule + \textbf{Requirement} & \textbf{Use Case(s)} \\ + \midrule + \endfirsthead + + \multicolumn{2}{c}% + {{\bfseries \tablename\ \thetable{} -- continued from previous page}} \\ + \toprule + \textbf{Requirement} & \textbf{Use Case(s)} \\ + \midrule + \endhead + + \midrule + \multicolumn{2}{r}{{Continued on next page}} \\ + \endfoot + + \bottomrule + \endlastfoot + + FR1 & BUC-1, PUC-1 \\ + FR2 & BUC-1, PUC-1 \\ + FR3 & BUC-1, PUC-7 \\ + FR4 & BUC-1, PUC-7 \\ + FR5 & MD-SL1, MD-EC1 \\ + FR6 & BUC-1, PUC-8, PUC-9 \\ + FR7 & PUC-13 \\ + FR8, FR9 & PUC-7, PUC-11 \\ + FR10 & PUC-3 \\ + FR11 & PUC-1, PUC-2 \\ + FR12 & PUC-5 \\ + FR13 & PUC-6, PUC-7 \\ + FR14 & PUC-4 \\ + FR15 & PUC-14 \\ + FR16 & PUC-11 \\ + FR17 & PUC-2 \\ + FR18 & PUC-12 \\ + FR19 & PUC-4 \\ + LFR-AP1 & PUC-10, PUC-11 \\ + LFR-AP2 & All PUCs \\ + LFR-ST1 & All PUCs \\ + UHR-EOU1 & All PUCs \\ + UHR-EOU2 & PUC-1, PUC-7, PUC-11 \\ + UHR-PSI1 & PUC-3, PUC-4 \\ + UHR-PSI2 & PUC-5 \\ + UHR-LRN1 & PUC-13 \\ + UHR-LRN2 & PUC-13 \\ + UHR-UPL1 & All PUCs \\ + UHR-ACS1 & PUC-5 \\ + PR-SL1 & BUC-1, PUC-1 \\ + PR-SL2 & PUC-7 \\ + PR-SCR1 & PUC-7, PUC-11 \\ + PR-PAR1 & PUC-1 \\ + PR-PAR2 & PUC-7 \\ + PR-RFT1 & BUC-1 \\ + PR-CR1 & BUC-1 \\ + PR-SER1 & PUC-7 \\ + PR-LR1 & All PUCs \\ + OER-EP1 & All BUCs \\ + OER-EP2 & All BUCs \\ + OER-IAS1 & All PUCs \\ + OER-IAS2 & PUC-8, PUC-9 \\ + OER-PR1 & PUC-13 \\ + OER-RL1 & All PUCs \\ + MS-MNT1 & PUC-7 \\ + MS-MNT2 & PUC-14 \\ + MS-MNT3 & PUC-14 \\ + MS-MNT4 & PUC-14 \\ + MS-MNT5 & All PUCs \\ + MS-AD1 & All PUCs \\ + MS-AD2 & All PUCs \\ + MS-AD3 & BUC-1 \\ + MS-AD4 & PUC-8, PUC-9 \\ + MS-AD5 & All PUCs \\ + MS-AD6 & All PUCs \\ + MS-AD7 & All PUCs \\ + MS-AD8 & All PUCs \\ + SR-AR1 & BUC-1, PUC-8, PUC-9 \\ + SR-AR2 & PUC-8, PUC-9 \\ + SR-IR1 & PUC-7, PUC-11 \\ + SR-PR1 & All PUCs \\ + SR-PR2 & All PUCs \\ + SR-AUR1 & PUC-14 \\ + SR-AUR2 & PUC-14 \\ + SR-AUR3 & All PUCs \\ + CULT1 & PUC-5, PUC-10 \\ + CULT2 & All PUCs \\ + CR-LR1 & SR-PR1 \\ + CR-SCR1 & PUC-7, FR4 \\ +\end{longtable} + \section{Open Issues} This section outlines unresolved questions and challenges that may @@ -1939,11 +2040,6 @@ \subsection{Limitations in the Anticipated Implementation Environment That May the tool, especially for large codebases. Limited resources could result in longer processing times or failures during analysis and refactoring. - \item \textbf{Lack of Test Coverage:} If existing codebases lack - comprehensive test suites, validating the functionality of - refactored code may become challenging. Without adequate tests, - it will be difficult to ensure that the tool's changes do not - introduce new issues. \end{enumerate} \subsection{Follow-Up Problems} \begin{enumerate} @@ -1982,7 +2078,6 @@ \subsection{Project Planning} \item Implement code smell detection \item Develop appropriate refactorings for detected smells \item Measure energy consumption before and after refactoring - \item Ensure original code functionality is preserved \end{itemize} \item Build out additional features iteratively \item Conduct regular testing (unit, integration, user acceptance) @@ -2112,17 +2207,17 @@ \subsection{Requirements for Migration to the New Product} Developers can install the refactoring library directly using pip: \verb|pip install ecooptimizer| The IDE plugin can be installed by users through the Visual - Studio Code marketplace. + Studio Code Extensions marketplace. \item \textbf{Parallel Running:} There is no need for a phased implementation or parallel running of old and new systems. The tool can be directly integrated without affecting existing code or infrastructure. \item \textbf{Manual Backups:} - Since the tool does not alter data but rather provides - refactoring suggestions, no manual backups are required before installation. + Since the tool does not alter data without the user approval, no manual backups are required + before installation. \item \textbf{Phased Rollout:} - If required, developers can start using the refactoring library - first, followed by the IDE plugin. + If required, developers can start using the IDE plugin first, followed by the packaged version + of the tool which will be installed using pip. \end{itemize} \subsection{Data That Has to be Modified or Translated for the New System} Not Applicable @@ -2166,7 +2261,6 @@ \subsection{Cost Breakdown} \item \textbf{Tools and Software:} \begin{itemize} - \item GitHub (for CI/CD): Free account, with no cost expected. \item Open-source libraries: No associated costs. \end{itemize} @@ -2190,38 +2284,18 @@ \subsection{User Documentation Requirements} \item \textbf{User Manual} \begin{itemize} \item \textbf{Purpose:} Provide comprehensive guidance on how - to use the refactoring library + to use the refactoring plugin in VSCode \item \textbf{Target Audience:} Software developers integrating the library into their projects \item \textbf{Content:} Installation instructions, API - reference, usage examples, and best practices - \end{itemize} - - \item \textbf{Technical Specification} - \begin{itemize} - \item \textbf{Purpose:} Detail the library's architecture, - algorithms, and integration points - \item \textbf{Target Audience:} Technical leads and architects - evaluating the library - \item \textbf{Content:} System design, performance - characteristics, and technical limitations - \end{itemize} - - \item \textbf{Quick Start Guide} - \begin{itemize} - \item \textbf{Purpose:} Enable rapid adoption and basic usage - of the library - \item \textbf{Target Audience:} New users looking to quickly - implement the library - \item \textbf{Content:} Concise setup instructions and simple - usage examples + references, usage examples, and best practices \end{itemize} \end{enumerate} \subsection{Training Requirements} For end-users, formal training is not required. The tool is designed to be simple and intuitive, with the assumption that primary users with experience in Python and software development will -have the necessary technical expertise to use the library effectively. The refactoring library +have the necessary technical expertise to use the plugin tool effectively. The plugin tool operates through clear, well-documented interfaces and requires minimal setup, allowing users to quickly incorporate it into their workflow without additional training.\\