You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: progNav Paper/progNav Paper.tex
+23-22Lines changed: 23 additions & 22 deletions
Original file line number
Diff line number
Diff line change
@@ -60,23 +60,30 @@
60
60
\section{Introduction}
61
61
Modern software systems contain millions of lines of source code.
62
62
As software grows in size and complexity, developers increasingly rely on tools to help them navigate the programs they create.
63
-
Program navigation is a central task tied to many critical activities, including exploring new code bases, debugging, and assessing security vulnerabilities.
63
+
Program navigation is a central task tied to many critical activities, including exploring new code bases, debugging, and assessing security vulnerabilities.
64
64
65
+
While navigating programs, developers ask questions about control flow and data flow throughout the program~\cite{latoza2010hard, Smith2015}. We will refer to these two concepts together as \textit{program flow}. Developers are interested in navigating program flow to trace how data is modified across multiple method invocations.
65
66
66
-
Code navigation is a critical task for software developers.
67
+
Integrated development environments (IDEs) present code linearly in the order methods are defined. However, successful developers do not navigate source code linearly (line by line starting at the top of the file). Instead, they methodically navigate the code's hierarchical semantic structures~\cite{robillard2004investigate}. To resovle this conflict and realize their ideal navigation strategies, developers rely on program navigation tools.
67
68
68
-
Successful developers do not investigate source code line by line starting at the top of the file. Instead, they navigate the code's hierarchical semantic structures ~\cite{robillard2004investigate}. Methodical and structured
69
-
Developers ask questions about control flow and data flow~\cite{latoza2010hard, Smith2015}.
69
+
% Probably more to come in here? What are some current tools and why are they limited.
70
+
% Discuss program visualization tools vs navigation tools.
70
71
71
-
Typically source code is presented to developers linearly. However, effective developers navigate
72
+
In this work we will design, implement, and evaluate a program navigation tool.
73
+
To address the limitations of existing program navigation tools, our tool will embody five key design principles (Section \ref{DesignPrinciples}). We will implement our tool as a plugin to the Eclipse IDE.
72
74
73
75
\section{Design Principles}
74
-
Derived these design principles by evaluating the limitations of existing program navigation tools.
76
+
\label{DesignPrinciples}
77
+
In this section we describe the design principles that we used to shape our tool. We derived these design principles by evaluating the limitations of existing program navigation tools.
78
+
75
79
\subsection{Powerful Program Analysis}
76
-
Program navigation tools should leverage powerful program analysis techniques.
80
+
By leveraging powerful program analysis techniques, navigation tools can provide more accurate information.
81
+
For example, by analyzing abstract syntax trees (ASTs) and call graphs, tools can make proper references to variables and methods.
82
+
Simple textual analysis may lead to inaccurate results, especially when programs include inheritance and duplicate variable names.
77
83
78
84
\subsection{Low Barriers to Invocation}
79
85
86
+
80
87
\subsection{Full Program Navigation}
81
88
Something that says the same tool allows users to analyze data flow \textit{across} methods upstream and downstream.
82
89
@@ -86,37 +93,31 @@ \subsection{In Situ Results}
86
93
87
94
88
95
\section{Related Work}
89
-
Summary of related work. Possibly a table evaluating existing tools on various design principles.
96
+
Summary of related work, including a table evaluating existing tools on various design principles.
97
+
Spoiler alert, none of the tools satisfy all of the principles.
90
98
91
99
92
100
\section{[Name of Tool]}
93
-
We implemented
101
+
We implemented our tool as a plugin to the Eclipse IDE [cite]. We chose Eclipse because of its popularity and extensibility. Eclipse is one of the most widely used open source IDEs for Java development and it provides many extension points for plugins.
94
102
95
103
\section{Preliminary Evaluation}
96
-
Same tasks as from: \cite{Smith2015}
97
-
Administered a post-test questionnaire.
104
+
We plan to perform a preliminary evaluation of our tool with approximately five to ten developers.
105
+
Our goals are to get some initial feedback on the usability of our tool and evaluate whether our approach shows promise in enabling developers to efficiently navigate program flow.
106
+
107
+
We will ask developers to perform two tasks that involve program flow navigation (Task 1 and Task 3 from \cite{Smith2015}).
108
+
We will measure their accuracy, speed, and administer a post-test usability questionnaire.
98
109
99
110
\section{Results}
100
111
Hopefully, participants are faster/more accurate with the tool. Rate positive experience on the questionnaire.
101
112
102
113
\section{Discussion}
103
-
\section{Limitations}
104
-
105
114
115
+
\section{Limitations}
106
116
107
117
\section{Conclusion}
108
-
The conclusion goes here.
109
-
110
118
111
-
112
-
113
-
% conference papers do not normally have an appendix
0 commit comments