Jazz Faculty Grant Proposal

Title Author
IBM Contacts

JAZZing for Help and Review Steven P. Reiss, Brown University, Department of Computer Science, Box 1910, Providence RI 02912-1910, [email protected] John Field, Harold Ossher, Wim de Pauw, Frank Tip

1. Research Focus
CSCI0320, Introduction to Software Engineering [1], is a sophomore level course at Brown University that teaches both advanced programming concepts and software engineering. At the heart of the course is a team project done by groups of four students over the course of the semester. The course also includes five programming assignments done by individuals or pairs of students. Eclipse and related software tools are used throughout the course. We plan to use Jazz to facilitate student collaboration for the team projects, including instruction on using its facilities in the labs that demonstrate the use of Eclipse and its tools. We see this, however, as only the first step. One of the major problems we have in the course is providing help to the students with their assignments and projects. The course uses undergraduate teaching assistants (UTAs), with one UTA for every 6-8 students. One or more UTAs are available every evening to answer questions and generally provide assistance to the students. Unfortunately, the UTAs are in one room in the CS department, while the students are working in labs, in their dorms, or in computer clusters spread over the whole campus. Additionally the UTAs are responsible for reviewing and grading student assignments, work that is often done using student presentations and demonstrations. Our research focus is going to be on using Jazz to support the UTAs in all of these activities. We want to use Jazz to enable UTAs to work with students individually or in groups when the students are distributed around campus. This involves a different cooperative model than the model of a team of equal programmers that is typically assumed by Jazz. In particular, the UTA is not a normal member of the students team and needs to be dynamically added to different teams at different times. UTAs need to have both complete and limited access to the project artifacts depending on the particular application. Students and student teams need to be able to demonstrate their programs and problems at both the design and code level to the UTAs. Beyond this, we want to provide tools that will help the UTAs in evaluating and reviewing student projects in a collaborative framework. We are working on a suite of tools for inquisitive programming, tools that let the programming environment analyze the users code either as they type or during a code review and ask the type of questions that a pair programmer or a review programmer would typically ask. These tools include dynamic style checkers [2], incremental flow analyzers [3], static checking of component usage [4,5], looking for patterns of unusual code and unusual data flows [6], micro type checkers, symbolic execution, fault localization [15], test coverage feedback, and existing tools like JML and ESCJava. These tools can be extremely useful for the UTAs when looking at a student programming problem and when reviewing code with the students while grading. If we want to use Jazz for these purposes, it is essential that these tools be integrated into the Jazz framework and work in the collaborative framework.

2. Research Contributions
While the immediate goal of this work is to provide support that allows UTAs to provide cooperative help to groups of students and to grade and review group and individual projects, the work has broader connotations. While development is primarily done by teams of programmers, managers or outside consultants often have to take on the role that our UTAs do, looking at particular programming or design

problems and providing solutions, doing code reviews, or doing periodic project reviews. Moreover, the inquisitive programming tools that we are aiming to integrate into a cooperative environment will be generally useful in a team programming effort. Extending Jazz support to handle these different types of cooperation and providing the type of tool support needed to support these activities will enhance the applicability of Jazz technology and will empower our UTAs and eventually managers and others who need to interact with teams of programmers. While the particular interactions we need to support are not necessarily novel, the suite of tools and the inquisitive interface that they will use is quite different and holds significant promise for improving programming, code review, and team cooperation.

3. Value to Jazz Community

We see the benefits of our research applying both to academic users of Jazz and, eventually, to commercial programming teams. Our experiences and any extensions we will develop to support our UTAs will be immediately useful to other schools that are using Jazz to support teams of student programmers in software courses. Interactive versions of our inquisitive programmer tools have the potential to greatly enhance team programmer productivity as well as providing a framework that can incorporate other tools into inquisitive cooperative programming.

4. Research Plan
We will use Jazz in CSCI0320 when it is taught during the spring of 2008 primarily for students working on their team projects. At the same time we will encourage the UTAs to attempt to use the existing Jazz facilities while providing help and during program reviews. Based on these experiences we will collect a set of requirements that describe exactly what will be needed to extend Jazz to properly support the UTAs in the course. During this period we will be developing our inquisitive programming tool suite for singleuser environments and will encourage the UTAs to try using these tools in their activities. We will use the funds from this grant to support a team of undergraduate programmers working over the summer to extend Jazz and implement the support needed to meet the given requirements and to extend the inquisitive programming tools to a cooperative framework. These will be tested initially in a smaller course with fewer team projects (CSCI0190 [7]) during the fall of 2008 before being used in production during next years version of CSCI0320.

5. Dissemination and Openness

All the results and tools developed under this grant will be made available for general use under an appropriate open source license from the Brown CS web sites and from Jazz repositories once they are available.

6. Track Record
We have developed a variety of Eclipse plug-ins including an interface to our constrained evolution tool [8,9,10], an initial plug-in for inquisitive editing that supports a message-bus interface to outside tools and a presentation framework, and a variety of rich client plug-ins for style analysis, pattern analysis, and line tracking [2,6,11]. We also have a simple interface to Eclipse that enables other tools such as our component checker [4,5] and other tools to access Eclipse project information. The first two plug-ins involved using SWT to provide appropriate interfaces. We also have extensive experience in developing web applications and web interfaces using Java, PHP, JavaScript, Ajax, FlapJax, Servlets, Perl and related tools, both for commercial applications (Simpli.com, enrichanother.com) and for research purposes (NewsView [12,13] and new work that displays the results dynamic performance analysis [14]).

7. References
[1] http://www.cs.brown.edu/courses/csci0320. [2] Steven P. Reiss, Automatic code stylizing, Proc. ASE 2007, November 2007.

[3] Steven P. Reiss, Specifying and checking component usage, Proc. AADEBUG 05, September 2005, pp. 1322.

[4] Steven P. Reiss, CHET: A system for checking dynamic specifications, Proc. ASE 2004. [5] Steven P. Reiss, Checking component specifications in Java systems, Proc. SoftMC 2005, July 2005. [6] Steven P. Reiss, Finding unusual code, Proc. ICSM 2007, October 2007. [7] http://www.cs.brown.edu/courses/csci0190 [8] Steven P. Reiss, Constraining software evolution, Proc. Intl. Conf. on Software Maintenance, October 2002. [9] Steven P. Reiss, Christina M. Kennedy, Tom Wooldridge, and Shriram Krishnamurthi, CLIME: An environment for constrained evolution, Proc. 25th Intl. Conf. on Software Engineering, May 2003. [10] Steven P. Reiss, Incremental maintenance of software artifacts, Proc ICSM 2005, September 2005, pp. 113-122. [11] Steven P. Reiss, Tracking source locations, submitted for publication, September 2007. [12] Steven P. Reiss, Visualizing what people are doing on the web (with Guy Eddon), Proc. VL/HCC 2005, September 2005, pp. 305-307. [13] Steven P. Reiss, A component model for Internet-scale applications, Proc. ASE 2005, November 2005, pp. 34-43. [14] Steven P. Reiss, Controlled dynamic performance analysis, submitted for publication, September 2007. [15] Manos Renieris and Steven P. Reiss, Fault localization with nearest neighbor queries, Proc. 18th Conf. on Automated Software Engineering, October 2003

8. Submission deadline
Please email your proposal to research (at) Jazz (dot) net, by November 13th, 23:59 Samoan time, 2007. This is a hard deadline. Responses will be sent by December 20th, 2007.