Comprehension and change impact analysis of aspect-oriented programs through declarative reasoning

In this dissertation, we discuss an approach to support declarative reasoning over aspect-oriented programs, where the AspectJ programming language is deployed as a notable (and representative) technology. The approach is based on (i) the transformation of source code into a set of facts, and (ii) the definition and implementation of relationships and dependencies between different elements of the system into rules, stored in a Prolog database. Declarative analysis allows us to extract complex information through its rich and expressive mechanisms. Our approach has two contributions. First, it can improve the comprehension of AspectJ programs, and it can be deployed for any AspectJ-like language, like e.g. AspectC#, AspectC++. The second contribution is the provision of change impact analysis for AspectJ programs. Our method is automated and tool support is available. Expected beneficiaries of our approach include system maintainers performing tasks during the "change planning" stage of evolution

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Early aspects: aspect-oriented requirements engineering and architecture design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications

Locating bugs without looking back

Bug localisation is a core program comprehension task in software maintenance: given the observation of a bug, e.g. via a bug report, where is it located in the source code? Information retrieval (IR) approaches see the bug report as the query, and the source code files as the documents to be retrieved, ranked by relevance. Such approaches have the advantage of not requiring expensive static or dynamic analysis of the code. However, current state-of-the-art IR approaches rely on project history, in particular previously fixed bugs or previous versions of the source code. We present a novel approach that directly scores each current file against the given report, thus not requiring past code and reports. The scoring method is based on heuristics identified through manual inspection of a small sample of bug reports. We compare our approach to eight others, using their own five metrics on their own six open source projects. Out of 30 performance indicators, we improve 27 and equal 2. Over the projects analysed, on average we find one or more affected files in the top 10 ranked files for 76% of the bug reports. These results show the applicability of our approach to software projects without history

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

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

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

Towards an aspect weaving BPEL engine

This position paper proposes the use of dynamic aspects and the visitor design pattern to obtain a highly configurable and extensible BPEL engine. Using these two techniques, the core of this infrastructural software can be customised to meet new requirements and add features such as debugging, execution monitoring, or changing to another Web Service selection policy. Additionally, it can easily be extended to cope with customer-specific BPEL extensions. We propose the use of dynamic aspects not only on the engine itself but also on the workflow in order to tackle the problems of Web Service hot deployment and hot fixes to long running processes. In this way, composing aWeb Service "on-the-fly" means weaving its choreography interface into the workflow