Workshop on Aspects and Dimensions of Concern: Requirements on, and Challenge Problems For, Advanced Separation Of Concerns∗ Peri Tarr1, Maja D’Hondt2, Lodewijk Bergmans3, and Cristina Videira Lopes4 (editors) 1IBM Thomas J. Watson Research Center, P.O. Box 704, Yorktown, NY 10598 USA [email protected] 2Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium [email protected] 3University of Twente, Dept. of Computer Science, P.O. Box 217, 7500 AE, Enschede, The Netherlands [email protected] 4Xerox Palo Alto Research Center, 3333 Coyote Hill Road, Palo Alto, CA 94304, USA [email protected] Workshop web site: http://trese.cs.utwente.nl/Workshops/adc2000 Abstract. This document describes the results of the two-day Workshop on Aspects and Dimensions of Concern at ECOOP 2000. The workshop produced the beginnings of a set of goals, requirements, and issues to be addressed by approaches to advanced separation of concerns. These goals and issues are encapsulated, in part, in a set of challenge problems that are intended to be solved by providers of advanced separation of concerns technologies. The challenge problems and requirements begin to define the boundaries of this problem domain and solution space, and they will help provide a basis for evaluating and comparing different solutions and solution approaches. 1 Introduction The First Workshop on Aspects and Dimensions of Concern was held at ECOOP 2000, following several previous workshops on Aspect-Oriented Programming, Subject-Oriented Programming, and Multi-Dimensional Separation of Concerns. Whereas the goals of previous workshops had been to introduce and begin to explore the new subdomain of advanced separation of concerns, this workshop’s purpose was instead to begin to define a set of concrete goals for, requirements on, and issues to be addressed by, approaches to advanced separation of concerns. The explicit representation of these goals, requirements, and issues represents the start of the transition of advanced separation of concerns from an infant subdiscipline to a coherent, mature research area. When completed, they will help to define the ∗ This workshop was funded in part by Xerox PARC and IBM Research. boundaries of the problem domain and solution space, and they will provide a basis for evaluation of, and comparison among, different solutions and solution approaches. To accomplish the workshop goals, we brought together both practitioners and researchers who have experienced problems related to inadequate separation of concerns, and practitioners and researchers who have provided solution technologies or approaches that address these problems. It was our intention to establish a dialogue between these two groups, to reveal the needs of the former group and the capabilities of the latter, thus facilitating the identification of goals, requirements and issues for advanced separation of concerns. To achieve this, prospective participants were required to submit position papers describing either some problems they had encountered, or solutions they had developed, in the field of advanced separation of concerns. This resulted in more than 40 experienced researchers and developers participating in the workshop, and their position papers can be found on the workshop web site, http://trese.cs.utwente.nl/Workshops/adc2000. As a highly interactive setting seemed most suitable, we allocated the larger amount of the two-day workshop to group work, only occasionally alternating it with invited talks from some of the experts in the field and authors who provided highly incisive, challenging problems. Seven heterogeneous groups were formed, joining problem providers with solution providers, and distributing co-authors or colleagues over as many groups as possible. This policy ensured that as wide a variety of submitted problems and solutions as possible were discussed in each group. Over the two days, the groups analyzed selected problems and evaluated some solutions by applying them to the problems. Each group presented both an interim report and their final results. The workshop concluded with a panel consisting of one representative per group, which proved to be a valuable source of general insights to the community. The rest of this document describes some of the results of this two-day workshop. Depending on the viewpoint adopted by a group—either the problem perspective or the solution perspective—the group work resulted in the following kinds of results: − Challenge problems: Challenge problems are software engineering scenarios that highlight one or more key problems and issues in advanced separation of concerns. The problem statement also describes any necessary requirements or constraints on solutions. Challenge problems, as their name suggests, are intended to serve as challenges to those researchers and developers in this subdomain who have produced, or who will produce, models of, or tools to support, software engineering using advanced separation of concerns. It is our hope that the producers of such models and technologies will propose solutions to the challenge problems using their models and technologies. As a result, we expect that some limitations or interesting features of existing models and technologies will be uncovered, prompting new research, and that the various solutions will be used as a basis for comparing and contrasting the relative strengths and weaknesses of different approaches. – Generalization of challenge problems: Particular subsets of challenge problems suggest larger, abstract classes of problems. Such generalizations are particularly critical, as they help to identify and categorize key parts of the problem domain. − Requirements statements: Some of the requirements on advanced separation of concerns approaches are already well defined; for example, an advanced separation of concerns approach must facilitate the encapsulation of multiple kinds of concerns, including those that cross-cut objects. Many requirements, however, are not well defined or widely accepted. Requirements statements highlight requirements on approaches to advanced separation of concerns, and they are generally illustrated with examples. It is our intent that the producers of advanced separation of concerns models and technologies will indicate how their models and technologies address these requirements; if they do not, we hope that they will use the requirements to help them identify new areas for subsequent research. Each result is classified accordingly. The remainder of this document is organized as follows. Sections 2-8 describe, respectively, the results produced by a particular workshop subgroup. Finally, Section 9 presents some conclusions and future work. Clearly, a single, two-day workshop is not sufficient time to produce a complete set of requirements, issues, or challenge problems, or even to produce a representative set. The results reported in this document are preliminary. Subsequent efforts may determine that some of the results are incomplete, inadequate, mutually inconsistent, or erroneous. It is our intention for these results to be discussed, revised and expanded by the advanced separation of concerns community. Beyond all else, this document is intended to provide food for thought. 1.1 Contributors The results described in this paper are due to—and in many cases, adapted from reports written by—the workshop participants and organizers: Mehmet Aksit, Jean Paul Arcangeli, Federico Bergenti, Lodewijk Bergmans, Andrew Black, Johan Brichau, Isabel Brito, Laurent Bussard, Lee Carver, Constantinos Constantinides, Pascal Costanza, Krzysztof Czarnecki, Lutz Dominick, Maja D’Hondt, Wolfgang De Meuter, Kris de Volder, Erik Ernst, Robert Filman, Eric Hilsdale, Mathias Jung, Pertti Kellomäki, Mik Kersten, Gregor Kiczales, Thomas Kühne, Donal Lafferty, Cristina Videira Lopes, Mira Menzini, Tommi Mikkonen, Blay Mireille, Oscar Nierstrasz, Klaus Ostermann, J. Andrés Díaz Pace, Renaud Pawlak, Elke Pulvermüller, Bert Robben, Martin Robillard, Andreas Speck, Erlend Stav, Patrick Steyaert, Peri Tarr, Tom Tourwé, Eddy Truyen, Bart Vanhaute, John Zinky. 2 Safe Composition Group members: Laurent Bussard, Lee Carver, Erik Ernst, Mathias Jung, Martin Robillard, and Andreas Speck Issues: Semantically correct composition of aspects, concerns Categories: Challenge problems, requirements statements 2.1 Problem Overview Different aspects or concerns should only be composed when the result of composing them is semantically meaningful. Two classes of conflicts may occur among concerns that are to be composed which, if present during composition, may affect the correctness of the composed result: – Semantic mismatch conflicts: Semantic mismatch conflicts are ones in which the composition of two or more concerns produces semantically incorrect programs. The mismatches occur when composed concerns contain behaviors that interact in subtle (often multiple) ways, and the interactions are not addressed correctly in the composed program. We further divide the class of semantic mismatch conflicts into intentional and unintentional conflicts. Intentional conflicts are ones that are introduced deliberately by a developer—i.e., the developer designs two or more concerns or aspects to conflict (e.g., to be mutually exclusive). Unintentional conflicts, on the other hand, are ones that occur inadvertently, often due to non-obvious semantic interactions among the concerns or aspects. While these kinds of semantic mismatch conflicts look the same, we distinguish them because