Deuce: A Lightweight User Interface for Structured Editing

We present a structure-aware code editor, called Deuce, that is equipped with direct manipulation capabilities for invoking automated program transformations. Compared to traditional refactoring environments, Deuce employs a direct manipulation interface that is tightly integrated within a text-based editing workflow. In particular, Deuce draws (i) clickable widgets atop the source code that allow the user to structurally select the unstructured text for subexpressions and other relevant features, and (ii) a lightweight, interactive menu of potential transformations based on the current selections. We implement and evaluate our design with mostly standard transformations in the context of a small functional programming language. A controlled user study with 21 participants demonstrates that structural selection is preferred to a more traditional text-selection interface and may be faster overall once users gain experience with the tool. These results accord with Deuce's aim to provide human-friendly structural interactions on top of familiar text-based editing.Comment: ICSE 2018 Paper + Supplementary Appendice

Mining developer communication data streams

This paper explores the concepts of modelling a software development project as a process that results in the creation of a continuous stream of data. In terms of the Jazz repository used in this research, one aspect of that stream of data would be developer communication. Such data can be used to create an evolving social network characterized by a range of metrics. This paper presents the application of data stream mining techniques to identify the most useful metrics for predicting build outcomes. Results are presented from applying the Hoeffding Tree classification method used in conjunction with the Adaptive Sliding Window (ADWIN) method for detecting concept drift. The results indicate that only a small number of the available metrics considered have any significance for predicting the outcome of a build

Java Smell Detector

“Code Smell” or “Bad Smell”, at the very least, is an indicator of badly written code and is often indicative of deeper problems in software design. In layman terms, it signals flaws in the core foundation or architecture of the software that can cause any number of more serious problems – from usability and runtime performance to supportability and enhancement. These problems can mostly be prevented by the systematic refactoring of the code. Refactoring is the process (and according to some, an ‘art’) of making incremental changes to existing source code to improve its nonfunctional attributes, without modifying its external functional behavior. Code smells are symptoms of deep-rooted problems in design, which, in most common cases, inhibit the understandability of the system for present and future programmers, hence rendering the program un-maintainable. The later these problems are identified, the costlier they are to correct as it is much harder to refactor a system in production and regression. Issues caused by refactoring can spiral out of control in advanced stages of the software development life cycle. So far, identification of these code smells has been thought of as an intuitive art rather than an exact science, as there are very few empirical measures or methodologies for doing so.In this project, I will examine each of the 22 code smells identified in prior research. I will implement Java Smell Detector (JSD), which will follow a scientific approach to detect five of these 22 code smells. JSD will give suggestions to refactor the code for all five of these smells. Further, the tool will provide an interactive process to refactor two of these cases; while for the rest, it will suggest an ideal refactoring technique that would need to be applied manually. I will be using Java code written by students of San Jose State University (SJSU) as test data for JSD and will compare its output against the code smells identified by the graduate students

Developing reproducible and comprehensible computational models

Quantitative predictions for complex scientific theories are often obtained by running simulations on computational models. In order for a theory to meet with wide-spread acceptance, it is important that the model be reproducible and comprehensible by independent researchers. However, the complexity of computational models can make the task of replication all but impossible. Previous authors have suggested that computer models should be developed using high-level specification languages or large amounts of documentation. We argue that neither suggestion is sufficient, as each deals with the prescriptive definition of the model, and does not aid in generalising the use of the model to new contexts. Instead, we argue that a computational model should be released as three components: (a) a well-documented implementation; (b) a set of tests illustrating each of the key processes within the model; and (c) a set of canonical results, for reproducing the model’s predictions in important experiments. The included tests and experiments would provide the concrete exemplars required for easier comprehension of the model, as well as a confirmation that independent implementations and later versions reproduce the theory’s canonical results

Using Students’ Screencasts as Alternative to Written Submissions

In this paper, we report our experiences on using student produced screencasts as a medium for students to explain and provide overview of their solution to advanced design and programming exercises. In our context, the screencasts have replaced written reports as submissions, and we report both on students' perception on work effort and effectiveness of screencasts as well as teaching assistants' experiences in assessing and marking the screencasts. Our main conclusions are that screencasted submissions is an important tool in the teacher's toolbox for some categories of learning tasks, but there are a number of best practices to follow to gain the full benefits of the approach

Improving software quality using an ontology-based approach

Ensuring quality in software development is a challenging process. The concepts of anti-pattern and bad code smells utilize the knowledge of reoccurring problems to improve the quality of current and future software development. Anti-patterns describe recurring bad design solutions while bad code smells describe source code that is error-free but difficult to understand and maintain. Code refactoring aims to remove bad code smells without changing a program’s functionality while improving program quality. There are metrics-based tools to detect a few bad code smells from source code; however, the knowledge and understanding of these indicators of low quality software are still insufficient to resolve many of the problems they represent. Minimal research addresses the relationships between or among bad code smells, anti-patterns and refactoring. In this research, we present a new ontology, Ontology for Anti-patterns, Bad Code Smells and Refactoring (OABR), to define the concepts and their relation properties. Such an ontological infrastructure encourages a common understanding of these concepts among the software community and provides more concise definitions that help to avoid overlapping and inconsistent description. It utilizes reasoning capabilities associated with ontology to analyze the software development domain and offer new insights into the domain. Software quality issues such as understandability and maintainability can be improved by identifying and resolving anti-patterns associated with code smells as well as preventing bad code smells before coding begins