Co-located with ECOOP 2008
Date: July 8, 2008. Location: Paphos, Cyprus.
Links ⇒ 2nd WASDETT @ ICSM 2008
Please find below all submissions of WASDeTT 2008. To stimulate discussions at the workshop, please take a look at these before the workshop.
Below you can find a preliminary schedule for the workshop. All authors will have a chance to present. We will have two types of presentations: feature presentations of 20 minutes and short presentations of 7 minutes. The feature presentations will be on Churrasco, Hopscotch and IntensiVE. All other presentations are short presentations.
09:00 Word of welcome 09:10 Feature presentation + questions (25 min.) 09:35 Short presentations (35 min. in total) 10:10 Mini-discussion (10 min.) 10:20 Feature presentation + questions (25 min.) 10:45 Short presentations (35 min. in total) 11:20 Mini-discussion (10 min.) 11:30 Coffee break
12:00 Feature presentation + questions (25 min.) 12:25 Short presentations (35 min. in total) 13:00 Plenary discussion (30 min.) 13:30 Lunch Break
15:30 - 17:00 Plenary discussions
Quite a number of researchers are involved in teaching software engineering courses. In these courses we lecture about requirements engineering, design, software architecture, etc. The observation is that when building software ourselves related to our research, we completely forget the standard software engineering practices. Often we use the excuse that we develop software in an XP-setting, we claim that we do not have "customers", or just we want to get something working in order to be able to write our next paper. However, in a few cases the developed software is picked up by the community and we are facing all kinds of problems that regular software engineers are facing as well. So, is software development in an academic environment really different from software development in a non-academic environment? If yes, in what respect is it different and what kind of software engineering principles apply? If not, how can we improve our way of working so that it fits with well established software engineering principles?
Researchers are increasingly leveraging components to assemble their tools instead of building them from scratch. Examples of components are off-the-shelf (OTS) products
-commercial as well as open source-such as Eclipse, Rational Rose, Emacs, Visio, Graphviz, Source Navigator and GCC. While many researchers are leveraging OTS products, comparably few experiences and lessons learned are described in the literature. In this context, we would like to discuss concrete experiences and, lessons learned of component-based building of software maintenance and comprehension tools. Question of interest are, for example: How to assess and select suitable OTS products? How to customize a certain OTS product (via its API or scripting)? How to interoperate with a certain OTS product?
Often tools are developed by a single researcher over a few years as part of his or her thesis or dissertation. These tools are typically prototypes that are abandoned after the degree is completed. In contrast, there are also tools that are developed and maintained over many years by a significant team of developers. In this context, we would like to discuss how team size and team diversity impacts tool building, and how to manage larger teams. Especially, is there a need to introduce more formality in the tool-development process? And how can this be achieved without stifling creativity in research?
There are examples of industrial tools that have started as academic prototypes. For example, the Bauhaus reverse engineering tool originated as part of a dissertation and is now commercialized by Axivion. Other examples of academic spin-offs are Legasys Corporation in Canada, which offered services in software maintenance automation for six years, and the Software Improvement Group in the Netherlands. The latter was founded by two Ph.D. students and now employs more than 30 people. In this context, we would like to discuss issues such as how to get the foot into industry’s door for conducting case studies and user studies, and successful business models to transition a research tool into a commercial offering. Also, how to effectively ensure tool stability for commercial customers while continuing to use the tool as a testbed to try out now research ideas?
The tools we are developping are written in a programming language (the tool implementation language), and work on programs written in one or more programming languages (the analyzed languages). The choice of what implementation language to use influences how easy it is to build and maintain the tool itself (C parser written in C versus one written in Ocaml or one in Java), how easy it is to collaborate with other people (extending Smalltalk tools versus extending Eclipse plugins written in Java), how scalable the end-result might be, etc. The choice of what languages to support is also important, and depends on the context tool is developped in (validation for a Ph.D. dissertation, used in a research project, developped for a third party, etc.), what it needs to do (reengineering of legacy code versus a compiler for a new language), etc.
The motivation for our workshop is the observation that tools and tool building play an important role in applied computer science research. The tangible results of research projects are often embodied in a tool. Even though tool building is a popular technique to validate research (e.g., proof-of-concept prototyping followed by user studies), it is neither simple nor cheap to accomplish. Given the importance of tool building and the significant cost associated with it, we would like to initiate a workshop that allows interested researchers to share their tool building experiences and to explore how tools can be build more effectively and efficiently.
Topics of interest include, but are not limited to:
Since the workshop has an interest not only in tool-builder issues, but also in experimental tools themselves, two different kinds of contributions are solicited from potential participants:
For contributions of the second kind, a special issue on Experimental Software and Toolkits (EST) of Elsevier’s Science in Computer Programming journal will be associated with this workshop. A pre-selection of articles to be submitted to this special issue will be made based on the quality of the submitted tool papers and their demonstrations during the workshop. Not every tool paper will be selected automatically for the EST. In addition, the size of articles for the special issues will be between 15 and 25 pages as opposed to the 5 to 10 pages that are requested for the workshop contributions. Nevertheless, reviewing of the EST articles will be done by the WASDeTT program committee, extended with a few extra referees if needed. Only if the workshop would not yield enough high quality contributions, the editors of the EST special issue may solicit additional articles on tools that were not submitted to the workshop.
We deliberately do not put any restrictions on the kinds of tools that can be submitted: the tools can be early prototypes, may have been around for years, or may have recently undergone a drastic re-implementation. Nevertheless we do have a particular interest in experimental research tools (as opposed to commercial tools) and tools that target the object-oriented software development paradigm.
In spite of our focus on experimental research tools, we explicitly solicit position papers from software industrials as well. Not only will their participation in the workshop allow them to get a sneak preview of state-of-the-art research tools, their opinions and visions would allow builders of research prototypes to learn more about the actual needs of industry.
Submit your position paper in PDF, so that we can collect all of the submissions on a web-site. Please keep all position papers between 5 and 10 pages, and use the style guidelines for Elsevier journal papers. A separate abstract including the e-mail addresses of the authors and URL’s of their home pages must be submitted in ASCII text.
NB: Submission timezone is APIA, ie out there in the Pacific at UTC-11.