On the Necessity of Empirical Studies in the Assessment of Modularization Mechanisms for Crosscutting Concerns Sven Apel, Christian K¨ astner University of Magdeburg {apel, kaestner}@iti.cs.uni-magdeburg.de Salvador Trujillo University of the Basque Country struji@ehu.es Abstract Collaborations are a frequently occurring class of cross- cutting concerns. Prior work has argued that collabo- rations are better implemented using Collaboration Lan- guages (CLs) rather than AspectJ-like Languages (ALs). The main argument is that aspects flatten the object- oriented structure of a collaboration, and introduce more complexity rather than benefits – in other words, CLs and ALs differ with regard to program comprehension. To ex- plore the effects of CL and AL modularization mechanisms on program comprehension, we propose to conduct a series of experiments. We present ideas on how to arrange such experiments that should serve as a starting point and foster a discussion with other researchers. 1. Introduction As well-established programming paradigms such as object-oriented programming (OOP) fail to modularize crosscutting concerns appropriately a plethora of new mod- ularization mechanisms emerges. Unfortunately, recent ad- vances have been made along different lines of research and the lack of a uniform taxonomy contributed to a general confusion about crosscutting concerns and their relationship to collaborations, which we address here. In prior work we [2,4,23] and others [11,26] helped to al- leviate this situation by categorizing crosscutting concerns. We identified two main classes of crosscutting concerns: while collaborations are sets of changes applied to multiple classes that introduce new classes, new members to classes, and that extend existing methods, advanced aspects apply either homogeneous changes (applying the same changes to multiple points in a program) or dynamic changes (applying changes depending on the runtime control flow or the value of runtime variables). Furthermore, we suggested programming guidelines that assist programmers in deciding when to use what modu- larization mechanism [2, 4]. We inferred these guidelines from the individual strengths and weaknesses of contempo- rary CLs and ALs: (1) use collaboration languages (CLs), e.g., Jak [6], Jx [27], Classbox/J [7], Scala [28], for col- laborations and (2) use AspectJ-like languages (ALs), e.g., AspectJ [18], AspectC++ [36], Eos [29], for advanced as- pects. 1 While these programming guidelines could be evaluated successfully by means of a non-trivial case study [3], a cou- ple of open issues remains. Some conclusions incorporated were based on arguments that are controversial [30,37]. For example, the claim that a collaboration should be explicit instead of merged into an aspect is reasonable but not sup- ported well. There are many such arguments in favor of CLs or of ALs. We realized that the discussion is often driven by personal preferences and plausibility arguments, often leading to entrenched positions. So we ask, is there any way to support or even prove such claims? Are CLs or ALs equally suited to implement collaborations or is one superior? These issues are important because prior studies indicated that collaborations occur frequently in contempo- rary programs [2, 3]. In this paper we illustrate the commonalities and sub- tle differences of implementing collaborations via CLs and ALs. We conclude that CLs and ALs are very similar in this matter. CLs and ALs differ only in the arrangement and interplay of language constructs and their concrete syn- tax. While these differences cannot be quantified by code metrics, they are significant for program comprehension es- pecially for large-scale collaborations [35]. In the end, it is the programmer who has to understand the resulting soft- ware. Thus, we argue that empirical studies that incorporate programmers are the key to decide between CLs and ALs. The aim of this paper is to sensitize researchers to the necessity for empirical studies in this field. We outline our first ideas on how to arrange empirical studies that should serve as a starting point for further discussion. 1 For simplicity, we do not consider languages that can be assigned to both, CLs and ALs, e.g., CaesarJ [26], FeatureC++ [5], Hyper/J [40]