Hina Shah

Fault localization and repair for Java runtime exceptions

This paper presents a new approach for locating and repairing faults that cause runtime exceptions in Java programs. The approach handles runtime exceptions that involve a flow of an incorrect value that finally leads to the exception. This important class of exceptions includes exceptions related to dereferences of null pointers, arithmetic faults (e.g., ArithmeticException), and type faults (e.g., ArrayStoreException). Given a statement at which such an exception occurred, the technique combines dynamic analysis (using stack-trace information) with static backward data-flow analysis (beginning at the point where the runtime exception occurred) to identify the source statement at which an incorrect assignment was made; this information is required to locate the fault. The approach also identifies the source statements that may cause this same exception on other executions, along with the reference statements that may raise an exception in other executions because of this incorrect assignment; this information is required to repair the fault. The paper also presents an application of our technique to null pointer exceptions. Finally, the paper describes an implementation of the null-pointer-exception analysis and a set of studies that demonstrate the advantages of our approach for locating and repairing faults in the program.

Visualization of exception handling constructs to support program understanding

This paper presents a new visualization technique for supporting the understanding of exception-handling constructs in Java programs. To understand the requirements for such a visualization, we surveyed a group of software developers, and used the results of that survey to guide the creation of the visualizations. The technique presents the exception-handling information using three views: the quantitative view, the flow view, and the contextual view. The quantitative view provides a high-level view that shows the throw-catch interactions in the program, along with relative numbers of these interactions, at the package level, the class level, and the method level. The flow view shows the type-throw-catch interactions, illustrating information such as which exception types reach particular throw statements, which catch statements handle particular throw statements, and which throw statements are not caught in the program. The contextual view shows, for particular type-throw-catch interactions, the packages, classes, and methods that contribute to that exception-handling construct. The paper also presents a case study in which we evaluated a prototype of the visualization system on a small set of developers.

Why do developers neglect exception handling

In this paper, we explore the problems associated with exception handling from a new dimension: the human. We designed a study that evaluates (1) different perspectives of software developers to understand how they perceive exception handling and what methods they adopt to deal with exception handling constructs, and (2) the usefulness of a visualization tool that we developed in previous work for exception handling. We describe the design of our study, present details about the studys participants, describe the interviews we conducted with the participants, present the results of the study, and discuss what we learned from the study. Based on our analysis, we suggest several future directions, including the proposal of a new role for the software-development process---exception engineer, who works closely with software developers throughout all phases of the software-development life cycle and who concentrates on the integration of exception handling into the core functionality of programs.

Studying the influence of culture in global software engineering: thinking in terms of cultural models

Culture appears to have a greater influence on software-engineering practice than originally envisioned. Many recent studies have reported that cultural factors greatly impact global software-engineering (GSE) practice. However, many of these studies characterize culture as a set of dimensions (e.g., Hofstedes), which significantly limits the meaning of culture. In this paper, we discuss the limitations of such a dimensional approach to studying culture by highlighting the aspects of culture that such dimensions fail to capture. Next, we present the idea of thinking of culture in terms of cultural models (inspired by Shores work), and illustrate this idea by presenting cultural models adopted by the software-engineering domain. Then, based on this idea of cultural models, we present a conceptual reference framework for studying the influence of culture in the global software-engineering setting. Finally, we present some examples that use this framework, which illustrates the benefits of such a framework for studying cultures influence on GSE practice.

Outsourced, Offshored Software-Testing Practice: Vendor-Side Experiences

In the era of globally distributed software engineering, the practice of outsourced, off shored software testing (OOST) has witnessed increasing adoption. Although there have been ethnographic studies of the development aspects of global software engineering and of the in-house practice of testing, there have been fewer studies of OOST, which to succeed, can require dealing with unique challenges. To address this limitation of the existing studies, we conducted -- and, in this paper, report the findings of -- an ethnographically-informed study of three vendor testing teams involved in OOST practice. Specifically, we studied how test engineers perform their tasks under deadline pressures, the challenges that they encounter, and their strategies for coping with the challenges. Our study provides insights into the differences and similarities between in-house testing and OOST, the influence of team structures on the degree of pressure experienced by test engineers in the OOST setup, and the factors that influence quality and productivity under OOST.

Culture and Testing: What is the Relationship?

This paper presents the results of a four-month ethnographically-informed study that we performed at a vendor organization in India to understand how culture influences global software-testing practice. The paper discusses our findings and analysis of software-testing activities conducted by two teams: one working for a Japanese client, the other working for a U.S. client. The findings show the differences in the software-testing approaches of the two teams with respect to team structure, thought processes, expectations, testing focus areas, and trust levels. The analysis suggests that cultural differences (e.g., national, user, and software-developer) are responsible for these differences in testing approaches. The paper describes the study details, our observations about the different testing-approach patterns that the teams adopted, our analysis of the reasons for those differences, and our reflections and suggested implications based on the findings.

Exception handling negligence due to intra-individual goal conflicts

Despite research to provide support for improving the usage of exception handling in programs, studies show that exception handling is neglected. In previous work, we interviewed novice developers to understand their problems when dealing with exceptions. The results show that these developers gave exception handling low priority and they thought that use of exception handling was forced on them. Thus, developers adopted an ignore-for-now approach for dealing with exceptions. In this paper, we present the results of our investigation of this problem of neglecting exception handling. We conducted a literature study to understand the psychological aspects of the problem that may be affecting the appropriate usage of exception handling in programs. Based on our investigation that was supported by this study, we believe that developers have intra-individual conflicting goals when they are expected to design and code the core functionality as well as the exception handling functionality. We recommend some strategies to address this problem of conflicting goals at academic and industry levels.

A design evaluation of a user interface for tending long-term tasks

Organizational processes often take place over long periods of time and require intermittent attention. Remembering and reasoning about upcoming process tasks is important, but not adequately supported by existing tools. This paper describes Longitude, a tool that provides a compact timeline of tasks and deadlines. We discuss findings from an exploratory study of the system and propose new requirements for tools that help people participate in long-running group processes requiring intermittent and sporadic attention.