> Hi Professor Johnson, > <> Thank you for your reply. Simon, Kevin, and I met today and tried > to come up with some research topics. Below is a list of our ideas > and some background information about each of us. We are > unattached to any particular topic though and would be open to any > suggestions you might have for us. Thanks again for your help!! > > Laura
Greetings Laura, Kevin, and Simon, Sorry for the delay in replying---I am actually emailing from Karlskona, a small town in southern Sweden! I have come up with an idea for an undergraduate research project that you might wish to pursue. While I think it's pretty interesting, I have no idea whether you folks will feel the same. One of the interesting recent developments in Java-based software engineering is the proliferation of open source static analysis tools for "bug finding": Checkstyle, FindBugs, PMD, Hammurapi, ESC/Java 2, JLint, and Lint4J are all examples, and there are probably more. (You can google to find them). Most of these look for bugs either by analyzing the source code or by analyzing the byte codes after compilation. In addition to bug-finding tools, there are other Java static analysis tools that look at coupling and complexity relationships as a way of predicting the "tendency" toward bugs or maintenance problems: Structure101 and DependencyFinder are a couple of examples. With all of these tools to evaluate Java code out there, the question naturally arises: what are the similarities and differences among them? Should all of them be used? Are some of them redundant? Can you gain additional information by combining the results from multiple tools? There is some initial work on this already available by people related to the FindBugs development team: <http://www.cs.umd.edu/~jfoster/papers/issre04.pdf> There are a number of issues left open by this interesting, yet very initial research: * There are interesting bug-finding tools not included in the study, such as Checkstyle and Hammurapi. It would be interesting to see if these tools impact on the above conclusions. * They do not look at the relationship between the data produced by bug-finding tools and the data produced by coupling/complexity tools such as Structure101 or DependencyFinder. For example, do areas of a program with excessive coupling/complexity also exhibit more "bugs"? * They looked at relatively large programs, which precluded assessment of false positives and false negatives. What would the results look like if the programs were run over smaller programs (such as programs you guys developed in the past) and the results were analyzed in detail to determine false positives and negatives? * They propose that it would be highly useful to have some sort of "meta-tool", which would enable the aggregation and synthesis of the results from the individual tools. By total chance, my research group has been developing a system for the past five years called Hackystat <http://www.hackystat.org> which would IMHO be the perfect infrastructure for such a meta-tool. Hackystat makes it relatively easy to collect the data output from a tool with a "sensor", send it to a centralized server, and then analyze that data in combination with other data collected in other ways from other tools. We already have developed sensors to collect data from Checkstyle, FindBugs, and PMD, and we even have some preliminary ways of combining the data. But we have not pushed very hard on this issue yet, we have not built sensors for some of the other tools, and so there are lots of research opportunities available here. What you might want to do is take a look at the paper I reference above, and also take a look at the Hackystat site, and see if this looks like this kind of project would be fun or misery. If the latter, then you can immediately stop and start looking for some other topic. Otherwise, the next step would be to download all of the tools that I mention above and just try to get them to work on a few of the Java programs that you guys have developed in the past. Gain some experience with the tools and what they output, and use that to more deeply understand the issues raised in the paper and how you might want to proceed with your project. If you're still intrigued by all of this, then the next step is to start developing additional sensors so that you can get all of the data to Hackystat. Then, start developing ways to combine and visualize the information and test hypotheses about the relative significance and utility of the output. Luckily, a large contingent of the Hac kystat development team (which I have cc'd on this email) is at UH, so you will have plenty of on-site help available to you when you get to the Hackystat-based part of the project. That seems like a healthy amount of work for an undergraduate project for three people. Note that I am not sure whether it is feasible to accomplish all of this in a single semester, so I would evaluate you mostly on your enthusiasm, effort, and progress, not on whether you completed every single last bit of work mentioned above by December. Let me know what you think. Cheers, Philip
