Declarative Aspect Composition

Aspect-oriented languages provide means to attach certain program units (e.g. advice, filters) to a given set of join points. It is possible that not just a single , but several units need to execute at the same join point. Aspects that specify the insertion of these units are said to "share" the same join point. Such shared join points may give rise to several issues, such as determining the exact execution order and the dependencies among the aspects. In this position paper, we outline a declarative approach that addresses this problem. We evaluate it with respect to several software engineering properties, in particular comprehensibility, predictability and evolvability

Composing Aspects at Shared Join Points

Aspect-oriented languages provide means to superimpose aspectual behavior on a given set of join points. It is possible that not just a single, but several units of aspectual behavior need to be superimposed on the same join point. Aspects that specify the superimposition of these units are said to "share" the same join point. Such shared join points may give rise to issues such as\ud determining the exact execution order and the dependencies among the aspects. In this paper, we present a detailed analysis of the problem, and identify a set of requirements upon mechanisms for composing aspects at shared join points. To address the identified issues, we propose a general and declarative model for defining constraints upon the possible compositions of aspects at a shared join point. Finally, by using an extended notion of join points, we show how concrete aspectoriented programming languages, particularly AspectJ and Compose*, can adopt the proposed model

Aspect-oriented interaction in multi-organisational web-based systems

Separation of concerns has been presented as a promising tool to tackle the design of complex systems in which cross-cutting properties that do not fit into the scope of a class must be satisfied. Unfortunately, current proposals assume that objects interact by means of object-oriented method calls, which implies that they embed interactions with others into their functional code. This makes them dependent on this interaction model, and makes it difficult to reuse them in a context in which another interaction model is more suited, e.g., tuple spaces, multiparty meetings, ports, and so forth. In this paper, we show that functionality can be described separately from the interaction model used, which helps enhance reusability of functional code and coordination patterns. Our proposal is innovative in that it is the first that achieves a clear separation between functionality and interaction in an aspect-oriented manner. In order to show that it is feasible, we adapted the multiparty interaction model to the context of multiorganisational web-based systems and developed a class framework to build business objects whose performance rates comparably to handmade implementations; the development time, however, decreases significantly.Comisión Interministerial de Ciencia y Tecnología TIC2000-1106-C02-0

A Systematic Aspect-Oriented Refactoring and Testing Strategy, and its Application to JHotDraw

Aspect oriented programming aims at achieving better modularization for a system's crosscutting concerns in order to improve its key quality attributes, such as evolvability and reusability. Consequently, the adoption of aspect-oriented techniques in existing (legacy) software systems is of interest to remediate software aging. The refactoring of existing systems to employ aspect-orientation will be considerably eased by a systematic approach that will ensure a safe and consistent migration. In this paper, we propose a refactoring and testing strategy that supports such an approach and consider issues of behavior conservation and (incremental) integration of the aspect-oriented solution with the original system. The strategy is applied to the JHotDraw open source project and illustrated on a group of selected concerns. Finally, we abstract from the case study and present a number of generic refactorings which contribute to an incremental aspect-oriented refactoring process and associate particular types of crosscutting concerns to the model and features of the employed aspect language. The contributions of this paper are both in the area of supporting migration towards aspect-oriented solutions and supporting the development of aspect languages that are better suited for such migrations.Comment: 25 page

Aspect-Oriented Techniques for Web Services: a Model-Driven Approach

Web Service technologies offer a successful way for interoperability among applications, but in order to tackle the entire web service life cycle, it is necessary to face how to model systems based on service functionality and also how to add extra-functional properties to modelled services. In this regard, we propose first of all a versatile and simple UML profile based on the Service Component Architecture specification for modelling services, in order to provide a model environment in which to add extra-functional properties. Secondly, a new UML profile is proposed to model and reuse the said extra-functional properties in service models. The implemented models based on these profiles will be independent from a final implementation language or platform, thus it is necessary to specify a particular type of model to convert the independent one into in a subsequent step. In order to meet this requirement an object, an aspect and a policy based models are proposed as the intermediate step between the independent model and the final code. We acknowledge that there are tools available which convert Java models into web services\u27 Java code, and it is not our aim to build a tool to fulfil this requirement. Regarding extra-functional properties, aspect-oriented techniques allow them to be easily modularized and reused; in this respect, properties are implemented as aspects in a totally transparent way and avoid the need to modify service code in an intrusive manner on adding extra-functional properties, improving our system maintenance. Furthermore, this way traceability between the model and the code is perfectly maintained in both directions. This work has been developed thanks to the support of CICYT under contract TIN2005-09405-C02-02

Towards UML Modelling Extra-Functional Properties in Web Services and their Clients

Web Services provide our systems with a platform independent and loosely coupled implementation environment, being time to face how the named systems can be modelled. Service Component Architecture (SCA) allows us to define services independently of the final implementation technology; however, it does not integrate the remaining development stages. Model Driven Architecture provides a method to face all stages in development from the platform independent model to final code, although it is not specific to service technologies. Regarding web service extra-functional properties, WS-Policy establishes how to describe them in a loosely coupled manner; however the loosely coupled environment is not always maintained when modelling or implementing these properties, which can be solved by using aspect-oriented techniques. In this paper, we propose to use a model driven approach for extra-functional properties in SCA service based models, where generated code will consist of the policy description and an aspect-oriented implementation

Generic Concern-Oriented Model Transformations Meet AOP

Abstract. Separation of concerns allows developers to manage large distributed systems by tackling one problem at a time. Model transformations refine models along one concern-dimension. Aspects encapsulate implementation details that cut across the boundaries of several components. In this position paper, after a short introduction to these emerging technologies, we explain how generic concern-oriented model transformations can meet aspect-oriented programming in order to complete the life-cycle of software application development in a pure MDA-compliant way based on separation of concerns. At the end, we present some requirements that tool vendors should provide if they decide to support such an approach