Towards a Systematic Approach for Driving Micro-Level Software Development Process

Software developers encounter many new and usually difficult problems in their every day work. Solving every new problem requires taking an appropriate strategy and careful planning, that needs full concentration and focus on the problem and enough consciousness about the current state of development. However, due to many factors, such as working on more than one task at the same time, the high degree of granularity of tasks, interruptions and the complexity of problems, developers usually have difficulties in obtaining the required concentration and focus on their current local problems and making progress in their work. This paper proposes a novel approach, which lets a developer follows a systematic step by step problem solving process in order to be focused on only one target in every moment while all needed details from the past and future steps are present to her. Moreover, this approach helps a developer to better understand the software development process and discover new ways for improving it

Model-Based Debugging

Software Debugging is still one of the most challenging and time consuming aspects of software development. Monitoring the software behavior and finding the causes of this behavior are located at the center of debugging process. Although many tools and techniques have been introduced to support developers in this part, we still have a long way from the ideal point. In this paper, we first give a detailed explanation of the main issues in this domain and why the available techniques and tools have been incapable of solving these issues completely. Then we explain how employing models can be helpful in solving stated problems. Finally, a detailed sketch of our approach based on using runtime models of executing software is described

Naming Anonymous JavaScript Functions

JavaScript developers create programs by calling functions and they use functions to construct objects. JavaScript development tools need to report to developers about those functions and constructors, for example in debugger call-stacks and in object representations. However, most functions are anonymous: developers need not to specify names for functions. Based on our analysis of ten large, widely used JavaScript projects, less than 7\% of JavaScript functions are named by developers. After studying examples from these JavaScript projects, we propose \textit{Static Function-Object Consumption}, a principled, automated approach based on local source code analysis for providing names to nameless JavaScript functions. We applied our approach to 90000 anonymous functions that appeared in the analyzed JavaScript project. The approach is successful in naming more than 99\% (91\% are unique within their file) of anonymous functions while the average length of function names is kept less than 37 characters

Querypoint Debugging

To fix a bug, software developers have to examine the bug-gy execution to locate defects. They employ different ap-proaches (e.g., setting breakpoints, inserting printing statements in the code) to navigate over buggy execution and inspect program state at suspicious points. In this pa-per we describe Querypoints, a new kind of compound conditional breakpoint relating two execution points. De-velopers specify Querypoints relative to a successfully paused conventional breakpoint or conventional watchpoint or to another Querypoint. The relative conditions contain runtime data values, like the last time a value was changed, or program statements, like the last conditional branch. The Querypoint combines the program state information from two execution points in the same execution; Querypoints can be chained to work backwards from effects to causes in a program. We present basic Querypoint concepts, two sample Que-rypoints, lastChange and lastCondition, and a description of our implementation of these Querypoints. To demon-strate that Querypoints are feasible we describe a prototype that implements an alternative approach to finding a bug in a graphical program analyzed previously with Whyline, one of the new logging-based debuggers