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

  1. Holger M. Kienle, Adrian Kuhn, Kim Mens, Mark Brand, and Roel Wuyts. Tool Building on the Shoulders of Others. In IEEE Software 26(1) p. 22—23, 2009. DOI URL 
  2. Roel Wuyts, Holger Kienle, Kim Mens, Mark Brand, and Adrian Kuhn. Academic Software Development Tools and Techniques. In Object-Oriented Technology. ECOOP 2008 Workshop Reader, p. 87—103, 2009. DOI URL 

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.

  1. Marco D’Ambros and Michele Lanza. Churrasco: Supporting Collaborative Software Evolution Analysis
  2. Francesca Arcelli, Christian Tosi, Marco Zanoni and Stefano Maggioni. The MARPLE Project - A Tool for Design Pattern Detection and Software Architecture Reconstruction
  3. Vassili Bykov. Hopscotch: Towards User Interface Composition
  4. Johan Brichau, Andy Kellens, Sergio Castro and Theo D’Hondt. Enforcing Structural Regularities in Software using IntensiVE
  5. Jan Friso Groote, Jeroen Keiren, Aad Mathijssen, Bas Ploeger, Frank Stappers, Carst Tankink, Yaroslav Usenko, Muck van Weerdenburg, Wieger Wesselink, Tim Willemse and Jeroen van der Wulp. The mCRL2 toolset
  6. Holger Kienle and Hausi Muller. The Rigi Reverse Engineering Environment
  7. Manuel Breugelmans and Bart Van Rompaey. TestQ: Exploring Structural and Maintenance Characteristics of Unit Test Suites
  8. Mircea Lungu and Michele Lanza. The Small Project Observatory
  9. Ahmad Waqas Kamal, Nick Kirtley and Paris Avgeriou. Developing a Modeling Tool Using Eclipse
  10. Arjan de Roo, Michiel Hendriks, Wilke Havinga, Pascal Durr and Lodewijk Bergmans. Compose: a Language and Platform Independent Aspect Compiler for Composition Filters
  11. Eelco Dolstra and Eelco Visser. The Nix Build Farm: A Declarative Approach to Continuous Integration
  12. Zoltán Horvath, Laszlo Lovei, Támas Kozsik and Róbert Kitlei. Building a Refactoring Tool for Erlang
  13. Vasco T. Vasconcelos, Isabel Nunes, Antónia Lopes, Nuno Ramiro and Pedro Crispim. Runtime Checking Java Code Using ConGu
  14. Richard Wettel and Michele Lanza. CodeCity
  15. Diomidis Spinellis. CScout: A Refactoring Browser for C

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:

  • Should tool building remain a craft?
  • Should research prototypes be of commercial quality?
  • How to integrate and combine independently developed tools?
  • What are the positive lessons learned in building tools?
  • What are the (recurring) pitfalls in tool building?
  • What are the good practices?
  • Are there architectures and patterns for tool building?
  • How to compare or benchmark tools?
  • What features in object-oriented languages make them easier to build tools for/with?

  • software engineering professionals (either from academia or industry) interested in state-of-the-art research tools and techniques that support object-oriented software development, maintenance and evolution, or tools that analyse, manipulate or reason about object-oriented software;
  • researchers and industrials with an experience in building such advanced tools and techniques. —>

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:

  • either a traditional position paper with the participant’s vision on tool-related issues;
  • or an actual tool submission where the participant will get the possibility of presenting his or her tool and how it was built.

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.

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.

  • !WASDETT Easychair Submission

Important Dates

  • Submission due: April 30, 2008 (changed, was May 18!)
  • Notification of acceptance: May 26, 2008
  • WASDeTT 2008: July 8, 2008
  • ECOOP 2008: July 7-11, 2008

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

Workshop Organizers

Program Committee


Last changed by admin on 21 April 2009