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

Abstract

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 system's 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.

Exception handlers for healing component-based systems

“…Connectors can be implemented with the many different technologies available for the automated injection of additional behaviors into binary applications, such as aspectoriented frameworks [Constantinides et al 2000], the TPTP probekit [IBM 2012], bytecode instrumentation tools [Apache Software Foundation 2012] and extended middleware [Simons and Stafford 2004]. In this section, we describe the structure and the behavior of healing connectors without referring to any specific code injection strategy.…”

A Structural Computing Model for Dynamic Service-Based Systems

“…The term interoperability refers to commonality of access means for services in all domains, and is distinguished from, say, the provision of middleware components specifically related to particular domains, such as one finds in RPC or CORBA. A number of approaches to interoperability are to be found in the literature, including object-oriented approaches [22], 15], [16], layered approaches [17], and aspect oriented programming [11], [6]. While our approach has elements in common with several of these, we have not found any of these existing approaches entirely adequate for our needs.…”

Towards an aspect-oriented framework in the design of collaborative virtual environments

“…Aspects were introduced by [3] and are defined as system properties that tend to cut across functional components, increasing their interdependencies, and resulting in what was coined as the code tangling problem. This code tangling makes the source code difficult to develop, understand and evolve by destroying modularity and reducing software quality [1]. Current AOP approaches model components and aspects as two separate entities where the aspects are automatically weaved into the functional behaviour of the system in order to produce the overall system [2] [14].…”

“…These languages, called aspect languages, can be completely new languages or extensions of general-purpose languages. But the main drawback of this approach is that we need an aspect language for every type of aspect and also an automatic weaver tool that must implement one or more aspect languages [1]. The other alternative is the use of a general-purpose language as is, without any extensions to describe both components and aspects, which is more feasible.…”

“…One of these approaches is Aspect-Oriented Programming (AOP) [1] [2] [3] that introduces a new entity, the aspect, to model those features that cut across different components in the system, increasing its extensibility and configurability.…”