PROCEEDINGS OF THEASPECT-ORIENTED PROGRAMMING WORKSHOPATECOOP’97Organizers:Cristina Lopes, Kim Mens, Bedir Tekinerdogan, and Gregor KiczalesIncludes the workshop report and the position papers.The workshop report was published in Workshop Reader of the European Conference on Object-OrientedProgramming (ECOOP), Finland. Springer-Verlag LNCS 1357. June 1997.Its copyright notice follows below:© Copyright 1997 Springer-VerlagThis work is subject to copyright. All rights are reserved, whether the whole or part of the material isconcerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting,reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publicationin its current version, and permission for use must always be obtained from Springer-Verlag. Violations areliable for prosecution under the German Copyright Law.The position papers are copyrighted by their authors. All rights are reserved.1231 2 3 2Abstract.1 Intro ductionAsp ect-Oriented ProgrammingWorkshop Rep ortVrije Universiteit Brussel,Department of Computer Science, Programming Technology Lab,Pleinlaan 2, B-1050 Brussel, BelgiumXeroxPARC, Systems and Practices Lab oratory,3333 Coyote Hill Rd, Palo Alto, CA 94304, USAUniversityofTwente,Department of Computer Science, Software Engineerin g,P.O. Box 217, 7500 AE Enschede, The NetherlandsWhereas it is generall y acknowledged that code tanglingreduces the quality of software and that asp ect-oriented programming(AOP) is a means of addressing this problem, there is | as yet | noclear deniti on or characterisation of AOP. Therefore, the main goal ofthe ECOOP'97 AOP workshop was to identify the \go od questions" forexploring the idea of AOP.Kim Mens , Cristina Lop es , Bedir Tekinerdogan , and Gregor KiczalesMechanisms for dening and comp osing abstractions are essential elements ofprogramming languages. They allow programs to b e composed up from smallerunits, and they support design styles that proceed by decomposing a system intosmaller and smaller sub-systems.The abstraction mechanisms of most current programming languages | sub-routines, pro cedures, functions, ob jects, classes, modules and API's | can allbe thought of as tting into a generalised procedure call model. The design stylethey support is one of breaking a system down into parameterised componentsthat can be called up on to p erform some function.But many systems have prop erties that do not necessarily align with thesystem's functional comp onents. Failure handling, persistence, communication,replication, coordination, memory management, real-time constraints and manyothers are aspects of a system's b ehaviour that tend to cut-across groups offunctional components. While these aspects can b e thought ab out and analysedrelatively separately from the basic functionality, programming them using cur-rent comp onent-oriented languages tends to result in these aspects being spreadthroughout the co de. The source co de b ecomes a tangled mess of instructionsfor dierent purp oses.This \tangling" phenomenon is at the heart of much needless complexityinexisting software systems. It increases the dependenc ies b etween the functional++++2 Ab out the Workshopaspect-orientedprogrammingaspectscomponentweavecomponents. It distracts from what the comp onents are supp osed to do. It intro-duces numerous opportunities for programming errors. It makes the functionalcomponents less reusable. In short, it makes the source code dicult to develop,understand and evolve.Anumber of researchers [KLM 97] have begun working on approaches tothis problem that allow programmers to express each of a system's asp ects ofconcern in a separate and natural form, and then automatically combine thoseseparate descriptions into a nal executable form using automatic to ols. Theseapproaches have b een called asp ect-oriented programming (AOP).In this workshop, rather than fo cussing on the idea of automatic weaver to ols,a more general notion of AOP was adopted: AOP was regarded as a generalconcept or mechanism to solve the problem of mo delling the dierent asp ectsof concern in a system. The purpose of the workshop was to bring togetherresearchers and practitioners working in the area of AOP or related areas todiscuss the current status of AOP research.The second workshop on was organised by CristinaVideira Lop es, Gregor Kiczales, Kim Mens and Bedir Tekinerdogan on June10 during the 11th Europ ean Conference on Ob ject-Oriented Programming inJyvaskyla, Finland. (The rst AOP workshop | the \AOP friends meeting" |was held at XeroxPARC in conjunction with OOPSLA'96.)All participants were encouraged to submit a short p osition paper and theworkshop was organised around the common tendencies detected in these posi-tion papers, such as:1. What exactly are ?How can they be identied or characterised?[Meu97,MJV 97]2. What is the dierence between an asp ect and a ?How do com-ponents and asp ects interact? [HOT97,Lam97,Van97]3. Howto ? (I.e. how to merge the base comp onent program and thedierent asp ect programs into a nal executable form.) [Lam97]4. Need for a theoretical foundation for AOP. [Meu97]5. How to expand the use of aspects to other phases of the software develop-ment life-cycle: requirements, analysis, architecture, design, implementation,maintenance, . . . [Aks97,HOT97,MJV 97,Mul97,Wer97]6. What are the relationships or dierences between AOP and other approachesor programming paradigms and esp ecially b etween AOP, reection, op en im-plementations and meta-ob ject protocols? (For example, is AOP b etter thana general framework like reection?) [CES97,Meu97,DC97,MJV 97,Lam97]7. Visual represe ntations of AOP.(For example, visual presentation of relation-ships between comp onents/aspects, graphical representations of asp ects andaspect weaving, . . . ) [HOT97,Van97,Wer97]{{{{{{{{{3 Ab out the Participants8. Whereas the topics enumerated above are of a more general nature, manyposition pap ers mentioned specic concerns such as feedback on specicaspects and domains for AOP:How to express the \co ordination" asp ect in concurrent OO? [HPMS97]\Synchronisation" is not a single asp ect but should be separated in sev-eral more specic aspects. [HNP97]How to specify \failure detection" and \failure handling" in distributedOO using AOP? [Roy97]9. Another important question whichwas not raised in any p osition pap