1st International Workshop on Academic Software Development Tools and Techniques 2008

Co-located with ECOOP 2008

Date: July 8, 2008. Location: Paphos, Cyprus.

Links ⇒ 2nd WASDETT @ ICSM 2008

Workshop Report and Articles

Papers

Download all Workshop Submissions

Please find below all submissions of WASDeTT 2008. To stimulate discussions at the workshop, please take a look at these before the workshop.

Tentative Schedule

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

Suggested discussion topics

1. Software engineering practices for tool building

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?

2. Component-based tool building

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?

3. Tool building in teams

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?

4. Tool building in industry

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?

5. Influence of Programming Language

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.

Call for Papers

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:

<!— The workshop is intended for:

Submissions and Proceedings

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:

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.

Submission Guidelines

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.

Important Dates

NB: Submission timezone is APIA, ie out there in the Pacific at UTC-11.

Workshop Organizers

Program Committee

Download

Download the Tools