Paniti Netinant

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.

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.

Separation of concerns for Multithreads Object-Oriented Programming

Multithreaded Object-Oriented Programming in concurrency environment using object-oriented technology is a complex activity. Programmers need to be aware of issues unrelated to their domain of problem, and are often unprepared for the challenges of the concurrent object-oriented programming brings. The interaction of their components becomes more complex, and makes it difficult to validate the design and correctness of the implemented program. Supporting separation of concerns in the design and implementation of the multithreaded object-oriented programming can provide a number of benefits such as comprehension, reusability, extensibility and adaptability in both design and implementation. We have tackled this problem by adopting the technique of separation of concerns in multithreaded object-oriented programming. In this paper we demonstrate an Aspect-Oriented approach that can be used for multithreaded object-oriented programming. We also show how better the separation of concerns in components. Readers/Writers problem is demonstrated using an aspect-oriented approach. Our methodology, which is based on aspect-oriented techniques as well as language and architecture independence, is an aspect-oriented framework.

Aspect-oriented frameworks (poster session): the design of adaptable operating systems

With software systems such as operating systems, the interaction of their components becomes more complex. This interaction may limit reusability, adaptability, and make it difficult to validate the design and correctness of the system. As a result, re-engineering of these systems might be inevitable to meet future requirements. There is a general feeling that OOP promotes reuse and expandability by its very nature. This is a misconception as none of these issues is enforced. Rather, a software system must be specifically designed for reuse, expandability, and adaptability [4]. Operating systems are dominated in many aspects. Supporting separation of concerns and aspectual decomposition in the design of operating systems provides a number of benefits such as reusability, expandability, adaptability and reconfigurability. However, such support is difficult to accomplish. Aspect-Oriented Programming (AOP) [7] is a paradigm proposal that aims at separating components and aspects from the early stages of the software life cycle, and combines them together at the implementation phase. Besides, Aspect-Oriented Programming promotes the separation of the different aspects of components in the system into their natural form. However, Aspect-Oriented software engineering can be supported well if there is an operating system, which is built based on an aspect-oriented design. Therefore aspects can be created in applications, reused and adapted from the aspects provided by the operating systems. Object-Oriented Operating Systems treat aspects, components, and layers as a two dimensional models, which is not a good design model. Aspects in the operating system cannot be captured in the design and implementation. Two-dimensional models lead to inflexibility, limit possibilities for reuse and adaptability, and make it hard to understand and modify. The poster will show an Aspect-Oriented Framework [1, 8], which simplifies system design by expressing its design at a higher level of abstraction, for supporting the design of adaptable operating systems. A framework is more than a class hierarchy and it is a reusable to produce custom systems and applications [5]. Aspect-Oriented Framework is based on a three-dimensional design that consists of components, aspects, and layers. Components consist of the basic functionality modules of the system. Aspects are the properties in the systems that cut across the components in the operating systems. Some aspects in operating systems such as synchronization, scheduling, fault-tolerance cut across, in horizontal and vertical, the basic functionality of the systems. Layers consist of the components and aspects. By separating aspects and components of the operating systems in every layer, we can provide a better generic design model of the operating systems. The framework uses design patterns [6]. The overall architecture is divided into two frameworks: Base Layer and Application Layer Framework. The poster will show The UML model of frameworks and how to maximize separation of aspects, components, and layers from each other. Our goal is to achieve a better design model and implementation of operating systems, in terms of reusability, adaptability, extensibility, and reconfigurability.