Abstract: Separation of concerns is a well-established principle of software engineering. Nevertheless, the failure to separate concerns effectively has been identified as a continuing cause of the ongoing software crisis. This failure arises in part because most programming and modeling formalisms enforce a dominant decomposition that allows only a few concerns to be separated, whereas software in reality is subject to multiple simultaneous, overlapping, and crosscutting concerns.Several approaches to "advanced separation of concerns" have been proposed, including subject-oriented programming, aspect-oriented programming, and Hyperspaces. These focus mainly on coding but take a multidimensional view of concerns that applies across the software life cycle. To support such approaches, we are developing Cosmos, a general-purpose concern-space modeling schema. Cosmos distinguishes logical and physical concerns. Logical concerns include classifications, classes, instances, properties, and topics, physical include instances, collections, and attributes. Cosmos also identifies four categories of relationship, including categorical, interpretive, mapping, and physical. Cosmos can support software development activities such as rationale capture, impact analysis, compositional development, change propagation, customization, and reuse.

Abstract: For aspect-oriented software development (AOSD) to live up to being a software engineering method, there must be support for the separation of crosscutting concerns across the development lifecycle. Part of this support is traceability from one lifecycle phase to another.This paper investigates the traceability between one particular AOSD design-level language, Theme/UML, and one particular AOSD implementation-level language, AspectJ. This provides for a means to assess these languages and their incompatibilities, with a view towards eventually developing a standard design language for a broad range of AOSD approaches.

Abstract: We study a language construct superimpose for method-call interception (MCI). The construct enables a programmer to attach additional functionality to certain join points along the execution of specified method calls. This is done in a completely type-safe manner where the additional functionality shares its state with the registry location. We present the static and the dynamic semantics of MCI. We use a disciplined style of Natural semantics for an accessible specification of MCI. We organize the constructs in a design space so that we can add expressiveness to a simple object-oriented language core in a stepwise fashion. It is one simple extension to enable interactive MCI, that is, MCI code can interact with the objects involved in a method call. Another simple extension is to allow for collective MCI by using patterns for the calls to be intercepted.

Abstract: We describe an extension to the Java language, Handi-Wrap, that supports weaving aspects into code at runtime. Aspects in Handi-Wrap take the form of method wrappers, which allow aspect code to be inserted around method bodies like advice in AspectJ. Handi-Wrap offers several advantages over static aspect languages such as AspectJ. First, aspects can be woven into binary libraries. Second, a wrapper in Handi-Wrap is a first-class Java value, which allows users to exploit Java mechanisms to define and weave wrappers. For example, wrappers can be passed explicit constructor arguments, and wrapper objects can be composed. Finally, methods in all Java classes, including anonymous classes, can be wrapped. A prototype of Handi-Wrap is implemented in a compile-time metaprogramming system for Java, called Maya; we briefly describe how Maya's features support Handi-Wrap.

Abstract: Aspect-oriented programming (AOP) is a programming paradigm such that crosscutting concerns including synchronization policies, resource sharing and performance optimizations over objects are modularized as aspects that are separated from objects. A compiler, called a weaver, weaves aspects and objects together into a program. In AOP, however, it is not easy to verify the correctness of a woven program because crucial behaviors are strongly influenced by aspect descriptions. In order to deal with such problem, this paper proposes an automatic verification approach using model checking that verifies whether the woven program contains unexpected behaviors such as deadlocks. The objectives of this paper are as follows: 1) to verify the correctness of AOP-based programs using model checking, 2) to provide AOP-based model checking frameworks.

Abstract: Aspect-Oriented Programming separates in a new dimension, named aspect, those features that are spread over different components in a system. In this paper we present a Dynamic AO Framework where software components and aspects are first-order entities composed dynamically at runtime according to the architectural information stored in middleware layer. As an example we describe the coordination aspect, one of the most relevant and useful aspects our approach, essential to develop open distributed systems The main functionality of this aspect is to encapsulate interaction protocol among a set of components.

Abstract: Many design concepts can be expressed only indirectly in source code. When this occurs, a single concept at design results in a verbose amount of code that is scattered across the system structure. In this paper, we present explicit programming, an approach that enables a developer to introduce new vocabulary into the source to capture a design concept explicitly. An introduced vocabulary item modularizes the implementation details associated with a design concept, reducing the scattering of code needed to express the concept. The vocabulary item appears in the code where the concept is needed; uses of the vocabulary may thus remain distributed through the code. We believe explicit programming provides a useful engineering point, balancing modularization and separation in (at least) two cases. First, when a design concept is tightly coupled with particular constructs in a program, separation is unlikely to lead to any benefits of reusability or comprehensibility. Second, concepts that emerge as a system evolves can be encapsulated and recorded, paving the way for later separation when conditions warrant it. We introduce ELIDE, a tool that supports explicit programming in Java, and describe several cases showing the utility of the explicit programming approach.

Abstract: Code is modularized, for many reasons, including making it easier to understand, change, and verify. Aspect-oriented programming approaches extend the kind of code that can be modularized, enabling the modularization of crosscutting code. We conducted an inquisitive study to better understand the kinds of crosscutting code that software developers encounter and to better understand how the developers manage this code. We tracked eight participants: four from industry and four from academia. Each participant was currently evolving a non-trivial software system. We interviewed these participants three times about crosscutting concerns they had encountered and the strategies they used to deal with the concerns. We found that crosscutting concerns tended to emerge as obstacles that the developer had to consider to make the desired change. The strategy used by the developer to manage the concern depended on the form of the obstacle code. The results of this study provide empirical evidence to support the problems identified by the aspect-oriented programming community, and provide a basis on which to further assess aspect-oriented programming.

Abstract: The construction of complex, evolving software systems requires a high-level design model. However, this model tends not to be enforced on the system, leaving room for the implementors to diverge from it, thus differentiating the designed system from the actual implemented one. The essence of the problem of enforcing such models lies in their globality. The principles and guidelines conveyed by these models cannot be localized in a single module, they must be observed everywhere in the system. A mechanism for enforcement needs to have a global view of the system and to report breaches in the model at the time they occur.Aspect-Oriented Programming has been proposed as a new software engineering approach. Unlike contemporary software engineering methods, which are module centered, Aspect Oriented Programming provides mechanisms for the definition of cross-module interactions. We explore the possibility of using Aspect-Oriented Programming in general and the AspectJ programming language in particular for the enforcement of design models.

Abstract: Aspect-oriented (AO) methods and languages seek to enable the preservation of design modularity through mappings to program structures, especially where common (object-oriented) languages fail to do so. The general claim is made that AO approaches enable the modularization of crosscutting concerns. The problem that we address is that it is unclear to what extent such claims are valid. We argue that there are meaningful bounds on the abilities of past, present, and future languages to succeed in this regard---bounds that we need to understand better. To make this idea concrete we exhibit a significant bound: Component integration (Sullivan & Notkin 1992, 1994) is not adequately modularizable in AspectJ

Abstract: When it comes to software that runs on devices as varied as cell phones, PDAs and desktops, one size does not fit all. This paper describes how mixin layers, a kind of nested generic type, can be used to implement a graphical user interface library that can be configured to run on platforms with widely dissimilar capabilities. We describe the language support needed to incrementally build software in layers, and we describe how crosscutting concerns can be encapsulated within a layer. We then show how layers can be reconfigured to meet changing requirements. We also show how a new design pattern, the Sibling pattern, can be used with mixin layers to coordinate changes to multiple classes in the same inheritance hierarchy. When used appropriately, the Sibling pattern increases our ability to separate design concerns and to reuse code.

Abstract: A superimposition is a program module that can augment an underlying distributed program with added functionality, while cutting across usual language modularity constructs like processes, packages, or objects. Two ways of combining superimpositions to create new superimpositions are presented. In sequential combinations a new superimposition is obtained that is equivalent to first applying one, and then applying the second to the result. In merging combinations, it is as if each component superimposition is applied independently to a basic program, without mutual influences.In both cases the applicability conditions and the result assertions of the component superimpositions are compared and used to determine whether the combination is possible. If so, they are then combined along with the code of the components to obtain both the specification and the code of the resultant superimposition, without considering any specific basic program. By using combinations of superimpositions from libraries, fewer components need be constructed manually, and programming techniques for independent issues can be codified. Among the examples we consider are versions of dining philosopher algorithms (exemplifying different scheduling techniques), a superimposition to make a program with a fixed number of processes able to handle process addition and deletion, and snapshot algorithms.

Abstract: Using goal driven requirements engineering, requirements are derived from a goal model that captures multiple strategies for satisfying the goals and takes into account environmental constraints on the system. The model is therefore more stable than a conventional requirements document. We present early work in building a system for runtime monitoring of system goals, as part of normal system operation, so that failure to achieve goals caused by changes in the system environment can be detected and acted on. We make use of Hyper/J to separate instrumentation for monitoring from the core code, and to add instrumentation directly to class files, without the need to modify the core class files. We are currently using a peer to peer networking client as a testbed and we present examples based on this program.

Abstract: Code generation and refactoring tools have been quite useful for developing objectoriented applications [4, 2]. They increase development productivity by automating tedious, repetitive, and error-prone tasks. By reducing the number of programming errors, they also help to improve software quality. Based on our experience developing AspectJ [5] applications, we believe that aspect-aware code generation and refactoring tools can bring similar benefits for the development of aspect-oriented applications as well. Although aspect-oriented languages such as AspectJ provide some of the power of metaprogramming constructs, we think this is not enough for dispensing with code manipulation tools. In fact, code generation tools could generate part of the implementation of specific AspectJ patterns. For instance, we have noticed [6, 7] that the implementation of persistence and distribution aspects in several applications might follow the same structure, which could be automatically generated. The generation tools could also be used to instantiate specific AspectJ frameworks. This sometimes involves tedious coding that can only be avoided by generation tools or metaprogramming constructs more powerful than the ones currently supported by AspectJ. Similarly, AspectJ-aware refactoring tools could be used for improving and maintaining existing AspectJ code. Again, this would be necessary when implementing distribution concerns as suggested elsewhere [6], since for every newly introduced remote method we should introduce an associated advice following an specific pattern. The advice should also be removed when the method is removed. User defined refactorings could simultaneously change both the pure Java and the AspectJ code, keeping the code consistent. AspectJ refactoring tools could also help developers to restructure Java code in order to separately implement different concerns using AspectJ features. This is necessary, for example, when migrating Java applications to AspectJ. A well defined set of refactorings can guide the developer in this task and guarantee that the resulting AspectJ system preserves the behavior of the original system. Sometimes refactorings are also useful for exposing join points that should be intercepted by the aspect code.

Abstract: Welcome to AOSD 2002, the first conference dedicated to the field of Aspect-Oriented Software Development. The conference provides a variety of events and activities of interest to researchers and practitioners in the academic, industrial and government communities alike.This is a particularly exciting time to be involved in the AOSD field. The fundamental goal of AOSD -----effective separation of concerns--- was enunciated about 30 years ago, most notably by Dijkstra and Parnas. They even identified some of the challenging requirements that AOSD researchers are addressing today, but it took until recently for technology to catch up and provide solu- tions. The first two decades or so of research on separation of concerns focused primarily on providing new kinds of modules, able to separate concerns in new ways. This led to some key advances, including abstract data types and object-oriented programming, which have had dramatic impact on software engineering research and practice. The approaches suffered from a limitation, how- ever: they could encapsulate concerns that aligned with the dominant decomposition of the software into modules such as objects or classes, but not concerns that cut across multiple modules. With a few earlier glimmerings, several flavors of technology that enable separation of crosscutting concerns began to emerge in the early 1990s. These technological breakthroughs finally enabled more ambitions separation-of-concerns goals to be addressed. The advent and promulgation of aspect-oriented programming awakened broader interest in the area, on the part of researchers and practitioners alike. There is now an active and growing community engaged in research and reduction to practice using a variety of different approaches and at various phases of the software lifecycle.The time is right for practitioners to begin using AOSD technology, for researchers to solve some of the challenging problems that remain, and for researchers and practioners to work together to make AOSD a mainstream software development technology. This conference is designed to further these goals by providing:• A forum for dissemination and discussion of leading-edge research and for researchers in the field to get together.• Opportunities for researchers and practitioners to come together to discuss issues of mutual interest, including how AOSD technologies can be used in practice and details of real technical problems that can motivate further research.• Discussion of the challenges faced when adopting AOSD in industry, and what can he done to address them.Refereed papers are a cornerstone of any conference. Fifty papers were submitted to the program committee. Every paper was read by at least three reviewers, except program committee member papers, which were read by at least five reviewers. The program committee held a one-day meeting in Chicago to discuss the papers. The committe held the papers to a very high standard -- nine were selected as full papers and eight as short papers.In addition, the conference includes keynote presentations by Michael Jackson and Linda Northrop, four invited talks on early industrial applications of AOSD, a panel on commercialization of AOSD, and eight demonstrations of AOSD-related tools. Prior to the start of the main conference is a stimulating program of six tutorials and six workshops.

Abstract: Specifying a system from different viewpoints, in heterogeneous design notations, and using a distributed team, introduces several challenges that test the state of the art in software engineering. One of these challenges is to check the consistency of such heterogeneous notations, and to deal with the problem of inconsistency throughout the lifecycle — including the management of inconsistency between notations at the same stages of the lifecycle, such as multiple UML models, and inconsistency between stages, such as the consistency of design and code.

Abstract: When using Aspect Oriented Programming in the development of software components, a developer must understand the program units actually changed by weaving, how they behave, and possibly correct the aspects used. Support for rapid AOP prototyping and debugging is therefore crucial in such situations. Rapid prototyping is difficult with current aspect weaving tools because they do not support dynamic changes. This paper describes PROSE (PROgrammable extenSions of sErvices), a platform based on Java which addresses dynamic AOP. Aspects are expressed in the same source language as the application (Java), and PROSE allows aspects to be woven, unwoven, or replaced at run-time.

Abstract: Separation of concerns is a basic engineering principle that is also at the core of object-oriented analysis and design methods in the context of the Unified Modeling Language (UML). The UML gives the designer a rich, but somehow disorganized, set of views on her model as well as many features, such as design pattern occurrences, stereotypes or tag values, allowing her to add non-functional information to a model. Aspect-oriented concepts are applied to manage the multitude of design constraints. However, it can then be an overwhelming task to reconcile the various aspects of a model into a working implementation. In this paper, we present our UMLAUT framework as a toolkit for easily building application specific "weavers" for generating detailed design models from high level, aspect oriented UML models. This is illustrated with a toy example of a distributed multimedia application with a weaving generating an implementation model. More ambitious applications are briefly outlined in the conclusion.

Abstract: Languages that support incremental programming, that is, the construction of new program components by specifying how they differ from existing components, allow for clean separation of concerns. Object-oriented languages support incremental programming with inheritance and dynamic dispatch features: whenever a message is sent, a decision occurs, but the branches of the decision can be specified in separate components. Aspect-oriented programming and predicate dispatching both introduce language mechanisms that improve on this support by allowing an extensible decision to depend on information about the message send other than just the dynamic type of the receiver or arguments. A small prototype language is presented that unifies the best features of these mechanisms, providing uniform support for incremental programming whether concerns are crosscutting or not. The language is demonstrated with a running example, a small data structure library that is incrementally extended with optimizations and new operations.

Abstract: One of the major progress due to component based technology is the capability to let the "infrastructure" manage some (non functional or extra functional) aspects such as persistency, distribution and so on without having to change the application code, using a wrappers technology (containers). Aspect Oriented Programming (AOP) is a technology that provides a language in which different aspects can be applied to an application using a technology that "weaves" the code implementing the aspect inside the application code.Both technologies are addressing the same "separation of concerns" issue, but containers propose only a fixed set of services, while AOP require the capability to change the component code, and is working at the object level.In our work, we merge both approaches, allowing aspect designers to define new aspects or services and aspect users to apply these aspects or services on components without the component code availability. This goal is reached by providing two languages, one for aspect designers the other one for aspect users, and by using a palette of technologies including object (stub) generation, method call interception and run-time instrumentation.