Friday, March 23
Dr. Daqing Hou is currently a tenure-track Assistant Professor in the Electrical and Computer Engineering Department at Clarkson University, Potsdam NY. His teaching and research interests are in Software Engineering, applications of statistical learning theory, and Computer Science Education. He is the author and co-author of 38 rigorously peer-reviewed research papers. His research has been funded by the Province of Alberta, CITeR, IBM, NSERC, and NYSERDA. He has graduated 1 PhD and 8 MS students. Currently, he advises 1 PhD, 5 MS, and 2 Honors students. He regularly serves on the Program Committees of the IEEE International Conferences on Program Comprehension (ICPC), Software Maintenance (ICSM), and the IEEE Working Conference on Reverse Engineering (WCRE), as well as a reviewer for various journals.
Learning to use a software framework and its API (Application Programming Interfaces) can be a major endeavor for novices. To help, we have built a critic to advise the use of an API, within an IDE, based on the formal semantics of the API. Specifically, whenever the state of the API client code triggers any predefined formal API usage rules, the critic offers three kinds of critiques for the API client code: criticisms (“this code behavior is inappropriate”), explanations (“what have caused the code to behave this way”), and recommendations (“you may need this next”). These critiques are broadly designed to address the respective well-known challenges in debugging, understanding, and finding relevant solutions.
To assess to what extent our critic can help solve API usage problems and what kinds of API usage rule can be formulated, we manually analyzed 150 discussion threads from the Java Swing Forum that are related to GUI Composition and Layout. We categorize the discussion threads according to how they can be helped by the critic. We find that all three kinds of critiques are useful and justified, API problems of the same nature appear repeatedly in the forum, and that API problems of the same nature can be addressed by implementing a new API usage rule for our critic. We will illustrate the API usage rules with concrete examples. We will describe the nature of the API usage rules and how our critic checks them. We will also discuss the kind of code behavior inference that is needed in order to make the critic smarter and more powerful and the tradeoffs involved. Unlike past empirical studies that are focused on answering why frameworks and APIs are hard to learn, ours is the first designed to produce systematic data that is directly used to build and evaluate an API support tool.