SPLAT! 2007
Software Engineering Properties of Languages and Aspect Technologies

A workshop affiliated with AOSD 2007
Monday March 12, 2007. Vancouver, B.C, Canada

Papers

The workshop is now over, but the papers are available from the ACM Digital Library.

Call for Papers

Software engineering is a complex activity that may involve multiple languages, databases, internal and external documentation, design documents, makefiles, formal specifications, and still more kinds of software artefacts. This implies that separation of concerns must be supported in a way which will cope with heterogeneous sets of artefacts, and such that it is possible to cross the boundaries from source code in one language to source code in another language, and on to all the other kinds of artefacts. This year's SPLAT workshop uses the boundary crossing challenge as a starting point for the exploration of the software engineering properties of the design of AOSD languages and systems.

The so-called '-ilities'—e.g., comprehensibility, evolvability, modularity, and analyzability—are crucial yardsticks for the assessment of the quality of software engineering activities and products, and it is not acceptable if the 'ilities' are ignored as soon as the software system complexity goes up, or in particular when it involves a heterogeneous set of artefacts. Generally, 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. 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, and in particular in context of heterogeneous artefacts creating boundary crossing challenges. The workshop 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, to the extent possible, describe useful solutions.

Topics

The following list specifies a core subset of the topics which are relevant at this year's SPLAT workshop, and moreover for each of them we encourage points of view that include multiple heteregenous artefacts, multiple languages, or in some other way situations that give rise to boundary crossing challenges:

• 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.

Motivation

This workshop will advance the field of AOSD language design, tool support development and software engineering by emphasizing the need to understand the practical consequences of design decisions on the conflicts between desirable software engineering properties of aspect-oriented software. In particular, this year's edition will help language designers, tool support developers and software engineering researchers to understand and evaluate the tradeoffs entailed by aspect language features when 'boundaries' are being crossed: between multiple different software artefacts and/or multiple base and aspect languages.

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 aspect-oriented 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 control mechanisms like type systems, 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 led to both conflicts and feedback among these activities:

• The concept of making aspects oblivious to the base code has led 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 led to the use of templates in combination with pointcuts, and work done on Lisp has led to a consideration of dynamic scoping as an alternative means of implementing aspects. There is however the question 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.

In addition, material presented at past SPLAT workshops and the AOSD conference series has shown a growing interest in applying aspect-orientation in the context of using multiple aspect languages at once (such as combining AspectJ and the Demeter traversal strategies, or AspectJ and HyperJ, multiple domain-specific aspect languages, ...), multiple base languages (work by D'Hondt and others on combining rule-based business knowledge and object-oriented functionality through aspect-oriented technology), or even multiple software artefacts (several past papers at SPLAT were devoted to using architectural descriptions, models, or other forms of design documentation to develop "semantics-based" pointcuts; work exists on applying AOP to makefiles ...). This "crossing of boundaries" in AOP still requires further analysis to study the effect on the software engineering properties of multi-artefact/multi-language systems, and is therefore adopted as a special focus for this year's SPLAT. Submissions about single-language/single-artefact systems are still welcome, but we encourage submitters to think about "crossing boundaries".

Format

The SPLAT workshop format will combine focused group discussions with plenary presentations and a poster session. All accepted submissions to the workshop will be presented at the workshop through either a poster or a plenary presentation. The workshop program committee will assign the most appropriate presentation format to each submission, based on the nature of the submission and its potential for working well with that presentation format. Prospective participants will also be divided into groups prior to the workshop, based on common interests and the topics of their submission. The largest part of the workshop will be dedicated to focused discussions within these groups, interleaved with the plenary presentations. Discussions will be asked to focus on the topics presented and discussed at the plenary presentations. Each group should discuss and note the most interesting issues raised by each presentation. These issues could come directly from the presentation or the submission but they are likely to be spin-off ideas, inspired by the presented work. Some time will devoted to the plenary presentation of the results of each focused group discussion.

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–8 page position paper in PDF format (standard ACM SIGPLAN conference format: http://www.acm.org/sigs/sigplan/authorInformation.htm), no later than Friday, January 26th, 2007. Submission is by email to splat@cs.utwente.nl.

The position papers will be reviewed by the program committee. Submitted papers will be treated as confidential during the review process. The Submitted papers will be selected for incorporation into the workshop proceedings (published as a technical report). You will receive notification of acceptance in workshop and proceedings on February 2nd, 2007.

Important Dates

• Submission deadline: Friday, January 26th, 2007
• Notification of acceptance: Friday, February 2nd, 2007
• More detailed feed-back: Monday, February 12th, 2007

Organizers

Lodewijk Bergmans (University of Twente)
Johan Brichau (Université catholique de Louvain)
Erik Ernst (University of Aarhus)
Kris Gybels (Vrije Universiteit Brussel)

Previous Workshops

• SPLAT 2006
• SPLAT 2005
• SPLAT 2004
• SPLAT 2003