CFP:
SPLAT!
Software-engineering Properties of Languages for Aspect Technologies


Reload
frames
A one-day workshop to be held in conjunction with the
Third International Conference on
Aspect-Oriented Software Development (AOSD 2004),
March 22-26 2004, Lancaster UK
http://aosd.net/conference

Overview

The so-called '-ilities' are crucial yardsticks for the assessment of the quality of software engineering activities and products, e.g., modularity, comprehensibility, evolvability, and analyzability. Hence, designers and users of aspect-oriented languages and systems must understand the effect on the 'ilities' of any aspect-oriented language, feature, system, style, etc. that they choose to use. Most aspect-related capabilities provide some benefits, but they also incur some disadvantages. Such a tradeoff arises, e.g., in connection with a dynamic weaving capability. This feature improves adaptability, but it may well adversely affect comprehensibility and analyzability, and sometimes, performance. It is critical to understand these tradeoffs.

Considering that software maintenance and evolution plays a major role in schedules and budgets, it is highly detrimental if software artifacts are hard to understand, and modifications likely to introduce ill effects along with the intended changes. In particular, complex semantic interactions between the parts of a software system may impede desirable evolution or delay or prevent the elimination of annoying bugs.

This workshop will explore issues in designing AOSD languages and systems that promote good software engineering properties, particularly with respect to comprehensibility, predictability, evolvability, and semantic interactions---which includes an open-minded discussion about the tradeoffs associated with all the great new ideas.

Topics and Goal

  • Novel aspect language and system design, along with an analysis of the effects on one or more of the 'ilities' in focus, i.e., comprehensibility, predictability, evolvability, and semantic interactions. This could for instance be a new language construct, along with an argument about why it makes software evolution easier, as well as an analysis of potential problems created or aggravated by usage of the new construct.
  • Experience reports or motivated examples demonstrating drawbacks or not-widely-known strenghts of existing approaches with respect to comprehensibility, predictability, evolvability, and semantic interactions. This could be a story from the trenches about how a special style in C programming solved all the evolution problems, or a story about a fancy new idea that turned out to have some hitherto unknown drawbacks when applied in practice.
  • Identification, analysis and examples of problems or not-widely-known benefits of existing AOSD languages and systems. This could be the presentation of a new concept, say 'spickling', an analysis of why AOSD programs are often quite 'spickled', why some existing approaches avoid it better than others, and what to do about it.

This workshop will advance the field of AOSD language design by emphasizing the need to understand the practical consequences of language design decisions on the software engineering properties of aspect-oriented software. In particular, it will help language designers understand and evaluate the tradeoffs entailed by aspect language features, and address the need for consistent language design to support comprehensibility, evolvability and controlled semantic interactions within AOSD software activies and products.

Format

The workshop will contain both plenary sessions and work in subgroups. The organizers will select topics for breakout groups based on areas of interest identified from the position papers. The plenary sessions will either include short presentations of some selected submissions, if they raise appropriate topics for discussion, or panels discussing topics raised by the participants' submissions. Plenary sessions will only be organized if they are likely to spark discussions or stimulate the work of the subgroups. At the end of the workshop, representatives of the subgroups will present the results of their groupwork to all participants.

In preparation of the workshop we will receive and review position papers, groups will be formed, and participants will be stimulated to interact, particularly within each group.

Submission Guidelines

Attendance to the workshop is limited to facilitate lively discussions and the exchange of ideas. Prospective participants will be solicited to submit a 4-6 page position paper in Postscript, PDF, Microsoft Word, or plain ASCII format, no later than Monday, January 19, 2004.

Submissions will be required to be strongly focused on the selected topics/issues, and they must evaluate the positive and negative effects on software engineering properties of the proposed or existing features and/or their interactions. The submissions will be reviewed by the organizers.

Submission format

We demand that submissions are fitted into the following format. The main motivation for this is to ensure that all workshop participants have a very similar background and topic to be discussed during the workshop, this avoids a lot of general discussion; introductions, backgrounds, hobbyhorses, and should increase the chances of actually working together on the same topic, and coming up with shared results at the end of the workshop. If you cannot fill all the entries of this outline, that's fine, too: just leaves those parts empty.

  1. Solution name, e.g. 'spickling' (this can be novel, or a well-known technique).
    NB: 'spickling' is a fantasy name; placeholder for your favorite or most hated language feature.
  2. Problem being addressed by 'spickling' (aka motivation) it is suggested that you introduce an example here to be used throughout the paper.
  3. Brief description of 'spickling'.
  4. Does 'spickling' support comprehensibility?
    1. general properties, assumptions, hypotheses about comprehensibility
    2. how 'spickling' supports comprehensibility
    3. how 'spickling' reduces comprehensibility
    4. conclusion about comprehensibility
  5. Does 'spickling' support predictability?
    1. General properties, assumptions, hypotheses about predictability
    2. how 'spickling' supports predictability
    3. how 'spickling' reduces predictability
    4. conclusion about predictability
  6. Does 'spickling' support evolvability?
    1. general properties, assumptions, hypotheses about evolvability
    2. how 'spickling' supports evolvability
    3. how 'spickling' reduces evolvability
    4. conclusion about evolvability
  7. Does 'spickling' cause semantic interactions?
    1. general properties, assumptions, hypotheses about semantic interactions
    2. how 'spickling' causes semantic interactions
    3. how 'spickling' reduces semantic interactions
    4. conclusion about semantic interactions
  8. Impact of 'spickling' on other software engineering properties.
  9. Discussion & Conclusion.

 

Important Dates

Issue Date
Position paper submission deadline February 6, 2004
Notification of Acceptance February 10, 2004
Final Versions of Papers Due March 1, 2004
Workshop March 22, 2004
 


Maintainer: Erik Ernst, eernst@daimi.au.dk.

This page was updated on 3-Apr-2004
URL - http://www.daimi.au.dk/~eernst/splat04/cfp.html