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

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, tool, style, etc. that they choose to use, from the perspectives of multiple stakeholders, including end users, language designers, and tool providers.

Most aspect-related capabilities provide some benefits, but they also incur some disadvantages. Such a tradeoff arises, for example, when considering the expressiveness property versus the analyzability property—more expressiveness usually implies less analyzability, and vice versa. Similarly, the "obliviousness" feature improves software adaptability via non-invasive extensions, but it may well lead to poor designs that expose too many join points to enable obliviousness, thus permitting changes that the software is not designed to handle.

This has led to numerous proposals for tool and linguistic mechanisms to restrict or control the set of available join points, to explicitly define adaptation interfaces, or to show developers explicitly the join points that will be affected and enable them to eliminate unintended ones.

This reduces obliviousness in favor of predictability and analyzability, and it reduces the potential for design errors. Quality in software engineering activities and products is often a question of balancing contradictory forces and ideals. It is, therefore, critical to understand these tradeoffs.

This workshop will explore issues in designing AOSD languages and systems that promote good software engineering properties, for example, with respect to analyzability, predictability, expressiveness, evolvability, and semantic interactions. It aims to identify some hard and deep issues and tradeoffs in achieving particular properties in AOSD languages and systems, to make these issues and tradeoffs explicit, and to try to characterize each conflict and potential resolutions, if any.

• Identification, description, and analysis of some key conflicts among desirable properties of languages and tools for AOSD (the "-ilities"), and their causes and effects.
• Experience reports or motivated examples of concrete applications of AOSD languages or tools that have demonstrated one or more key conflicts among -ility properties.
• Novel aspect languages, language features or tool support approaches that provide new insights or novel approaches to achieving -ility properties that normally conflict (e.g., achieving a good balance between expressability and analyzability).
• Novel aspect language and system design, along with an analysis of the impact upon a key conflict among -ility properties. This could, for instance, be a new language construct, along with an argument about why it promotes analyzability without reducing expressiveness in any significant way.
• "Patterns" or taxonomies of some of the -ility properties, their interactions, their costs and benefits, and drawbacks or strengths of existing approaches with respect to achieving them.

This workshop will advance the field of AOSD language design and software engineering by emphasizing the need to understand the practical consequences of language design decisions on the conflicts between desirable software engineering properties of aspect-oriented software. In particular, it will help language designers and software engineering researchers understand and evaluate the tradeoffs entailed by aspect language features, and address the need for consistent language design to improve the management of the deep conflicts among desirable properties of AOSD software activies and products.

SPLAT provides a forum for several groups of people to meet and discuss. In particular, aspect language designers, AOSD tool support developers and aspect programmers discuss the software engineering properties of existing and novel AOSD approaches. While these three groups have a common goal of improving the quality of aspectualized software, the activities they engage in tend to have different overriding forces in designing approaches to AOSD: When programming aspects, it is very convenient to use novel AOSD approaches providing powerful and flexible base-code adaptation mechanisms, but at the same time it is crucial that the overall code readability and evolvability of the software is maintained in the long run. Language designers would probably often go for powerful abstraction mechanisms or for type system like control mechanisms, depending on whether they are from one or the other language community. Tool designers and implementers might be able to mitigate this conflict somewhat by improving on sophisticated views of software and by building databases of static information.

Previous incarnations of SPLAT and other workshops have shown that these different forces have lead to both conflicts and feedback among these activities:

• The concept of making aspects oblivious to the base code has lead some language designers to consider more expressive pointcut languages. Many people have however expressed objections to the danger that they would no longer being able to foresee where and how an aspect influences the base code. In response, language designers have introduced the notion of limiting the hooks available to an aspect or introducing the notion of explicit pointcut interfaces, while tool support developers have aimed at pointcut analysis tools for assisting the programmer. The question of whether and how the conflicts of expressivity and comprehensibility can be solved and what direction novel AOSD language designers should take is however still unresolved.
• Currently AOSD concepts are moving from the realm of Java to being applied to other programming languages as well. The need for integrating these concepts in a clean and orthogonal way with the existing concepts of the language can lead language designers to take novel approaches. In the case of work done on C++ this has lead to the use of templates in combination with pointcuts, and work done on Lisp has lead to a consideration of dynamic scoping as an alternative means of implementing aspects. There is however the question of how this influences readability, evolvability etc.
• Designers of tools for aspect refactoring have expressed a desire for novel aspect language features to ease the refactoring process, such as making additional properties on joinpoints available and even including new types of joinpoints. The question however remains what impact such features will have on readability, evolvability etc.

The format of the workshop will incorporate structured group discussions and panel discussions/debates of selected topics and submissions.

Panel discussions/debates will focus on highly controversial topics, such as the desirability of the "obliviousness" property.

Attendance to the workshop is limited to facilitate lively discussions and the exchange of ideas. Prospective participants will be solicited to submit a 4-8 page position paper in PDF format, no later than January 24, 2005, by email to splat05@cs.utwente.nl (NB: this deadline has been delayed because the early registration date for the conference has been delayed). Please use the ACM Conference Proceedings Templates (http://www.acm.org/sigs/pubs/proceed/template.html), and do not forget to include page numbers.

NB: Because of a delay in the early registration date for the conference, deadlines have been pushed back similarly.

• Lodewijk Bergmans
• Kris Gybels
• Peri Tarr
• Erik Ernst

• SPLAT 2004
• SPLAT 2003