Tzilla Elrad

Aspect-oriented programming: Introduction

together behavior and data into a single conceptual (and physical) entity. Object-orientation is reflected in the entire spectrum of current software development methodTzilla Elrad, Robert E. Filman, and Atef Bader, Guest Editors

Discussing aspects of AOP

Aspect-oriented programming is a new evolution in the line of technology for separation of concerns technology that allows design and code to be structured to reflect the way developers want to think about the system. AOP builds on existing technologies and provides additional mechanisms that make it possible to affect the implementation of systems in a crosscutting way.Aspect-oriented programming is a new evolution in the line of technology for separation of concerns technology that allows design and code to be structured to reflect the way developers want to think about the system. AOP builds on existing technologies and provides additional mechanisms that make it possible to affect the implementation of systems in a crosscutting way.

Decomposition of distributed programs into communication-closed layers

Abstract The safe decomposition of a distributed program into communication closed layers is suggested as a superstructure of its decomposition into a collection of communicating processes. This decomposition may simplify the analysis of a distributed program, as is exemplified by examples of program verification. A programming language construct to enforce safety of a decomposition is introduced. The application to systematic construction of distributed programs is also shown.

Designing an aspect-oriented framework in an object-oriented environment

Separation of concerns is at the heart of software development, and although its benefits have been well established, the core problem remains how to achieve it. For complex software systems the solution is still debatable and it is a major research area. Object Oriented Programming (OOP) works well only if the problem at hand can be described with relatively simple interface among objects. Unfortunately, this is not the case when we move from sequential programming to concurrent and distributed programming. The September 1993 CACM issue was devoted to the problematic marriage between OOP and Concurrency [Cohen 93]. Since then, numerous workshops, articles and books have attempt to tackle the problem. The core complexity is that concurrent and distributed systems manifest over more than one dimension. Features such as scheduling, synchronization, fault tolerance, security, testing and verifications are all expressed in such a way that they tend to cut across different objects. Hence, simple object interfaces are violated and the traditional OOP benefits no longer hold. One of the current attempts to resolve this issue is the Aspect Oriented Software Architecture. To address this multi-dimensional structure of concurrent systems we distinguish between components and aspects. Aspects are defined as properties of a system that do not necessarily align with the systems functional components but tend to cut across functional components, increasing their interdependencies, and thus affecting the quality of the software. Although not bound to OOP, Aspect-Oriented Programming (AOP) is a paradigm proposal that retains the advantages of OOP and aims at achieving a better separation of concerns. In this paper we provide an assessment of AOP and we discuss the architecture of an aspectoriented framework. The goals of our proposal is to achieve an improved separation of concerns in both design, and implementation, to provide adaptability, and to support the complex interaction among non-orthogonal aspects. 1. The “Code Tangling” Problem The traditional approach for organizing software systems has been based on some form of functional decomposition. A problem is broken down into sub-problems that can be addressed relatively independently. Current programming languages and paradigms support implementation, ___________________ Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its data appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee.

Aspect-Oriented Modeling: Bridging the Gap between Implementation and Design

Separation of Concerns is one of the software engineering design principles that is getting more attention from practitioners and researchers in order to promote design and code reuse. Separation of Concerns (SoC) separates requirements such as synchronization and scheduling from the core functionality. These requirements are often referred to as crosscutting-concerns. The implementation of such requirements is scattered throughout the system, which results in the code-tangling problem. Aspect Oriented Programming provides the user with the ability to modularize, and weave crosscutting-concerns in order to maximize code reusability and solves the code-tangling problem. Weaving is the process of combining crosscutting concerns with the core functionality. Using the UML to model and interweave these concerns is a craft that is hard to master due to the lack of formal modeling techniques based on SoC. In this paper we present a formal design methodology to model the systems concerns based on aspect-orientation.

Joinpoint inference from behavioral specification to implementation

Aspect-Oriented Programming languages allow pointcut descriptors to quantify over the implementation points of a system. Such pointcuts are problematic with respect to independent development because they introduce strong mutual coupling between base modules and aspects. This paper introduces a new joinpoint selection mechanism based on state machine specifications. Module interfaces include behavioral specifications defined as protocol state machines. These specifications are not defined with respect to potential aspects, but are used to model and simulate the architecture of a system and act as behavioral contracts between the modules of the system. We show how a smart joinpoint selection mechanism is able to infer points that might be located deep inside the implementation of a module, given pointcuts that are expressed entirely in terms of behavioral specification elements. We present a tool, the Motorola WEAVR, which implements this technique in a Model-Driven Engineering environment.

A layered approach to building open aspect-oriented systems: a framework for the design of on-demand system demodularization

Pyrido[1,4]benzodiazepines having antidepressant activity of the formula wherein Ar is 2, 3 and 4-pyridinyl, 2 or 3-thienyl, phenyl or a substituted phenyl; R is hydrogen, loweralkyl or an amine on the end of a hydrocarbon chain; Z is hydrogen, halogen, trifluoromethyl, loweralkyl, loweralkoxy, hydroxy or nitro; and Y is hydrogen, loweralkyl, loweralkoxy or hydroxy; and the pharmaceutical salts are prepared from [2-[(aminopyridinyl)amino]phenyl]arylmethanones which also have antidepressant activity.

Modeling aspect-oriented compositions

Crosscutting concerns are pervasive in embedded software, because of the various constraints imposed by the environment and the stringent QoS requirements on the system. This paper presents a framework for modularizing crosscutting concerns in embedded and distributed software, and automating their composition at the modeling level, for simulation and validation purposes. The proposed approach does not extend the semantics of the UML in order to represent aspects. Rather, it dedicates a metamodel to the representation of the composition semantics between aspects and core models. The paper illustrates this approach by presenting a model weaver for SDL statecharts developed at Motorola Labs. Crosscutting behavior is designed with plain SDL statecharts and encapsulated into modules called aspect beans. The weaver looks at the aspect beans and the core SDL statecharts from a perspective that is defined by lightweight extensions to the SDL and UML metamodels. A connector metamodel defines the structure of the aspect-to-core binding definition. Finally, a weaver behavioral metamodel defines composition primitives for specifying weaving strategies.

Extending the object model to provide explicit support for crosscutting concerns

Concurrent systems tend to have certain properties that are not localized in single modular units, but their implementations cut across functional components, increasing coupling and making modular units difficult to reuse and adapt. Example properties include concurrency, synchronization, and authentication. This problem is particularly apparent in systems with evolving requirements, as adapting code that is not localized in single modular units proves to be a tedious process. In this paper we discuss issues related to requirements of concurrent software systems to provide explicit support for these cross‐cutting concerns, and we present the Aspect Moderator, a framework extension to the object model that can ease the development of concurrent object‐oriented systems. Copyright

Scenario based resolution of aspect interactions with aspect interaction charts

Introduction of aspects into the system raises the level of separation of concerns within the system. At the same time it also raises the level of interactions among the various components and features within the system. Current modeling techniques(sequence diagrams, live sequence charts) are inadequate in handling this added level of interaction. A higher level of abstraction is needed in order to capture the interactions among aspects/features/core and provides two immediate benefits - better modularization of the requirements, and better adaptability for the resulting model. We propose the Aspect Interaction Charts (AIC) that build on top of the Live Sequence Charts (LSC) [3] in order to capture the interactions among various aspects at joinpoints. With the AIC we foresee the ability to capture aspect interactions at a joinpoint in a common specification in the form of use-case scenarios, and the ability to execute these scenarios while non-invasively manipulating the interactions among the various aspects. In addition to the aforementioned benefits, we plan on leveraging the tools that come with the LSC language, i.e. the Play Engine. The AIC would provide us with the ability to model, view and manipulate aspect interactions at joinpoints.