Arndt von Staa

Modularizing design patterns with aspects: a quantitative study

Design patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately, object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability. Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare OO and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for the 23 Gang-of-Four patterns. We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although only 4 aspect-oriented implementations have exhibited significant reuse.

Quantifying the Effects of Aspect-Oriented Programming: A Maintenance Study

One of the main promises of aspect-oriented programming (AOP) is to promote improved modularization of crosscutting concerns, thereby enhancing the software stability in the presence of changes. This paper presents a quantitative study that assesses the positive and negative effects of AOP on typical maintenance activities of a Web information system. The study consists of a systematic comparison between the object-oriented and the aspect-oriented versions of the same application in order to assess to what extent each solution provides maintainable software decompositions. Our analysis was driven by fundamental modularity attributes, such as coupling, cohesion, conciseness, and separation of concerns. We have found that the aspect-oriented design has exhibited superior stability and reusability through the changes, as it has resulted in fewer lines of code, improved separation of concerns, weaker coupling, and lower intra-component complexity

Unit testing in multi-agent systems using mock agents and aspects

In this paper, we present a unit testing approach for MASs based on the use of Mock Agents. Each Mock Agent is responsible for testing a single role of an agent under successful and exceptional scenarios. Aspect-oriented techniques are used, in our testing approach, to monitor and control the execution of asynchronous test cases. We present an implementation of our approach on top of JADE platform, and show how we extended JUnit test framework in order to execute JADE test cases.

Separation of Concerns in Multi-agent Systems: An Empirical Study

With multi-agent systems (MASs) growing in size and complexity, the separation of their concerns throughout the different development phases is crucial to MAS engineers. Separation of concerns is a well-known principle in software engineering to achieve improved reusability and maintainability of complex software. Hence it is necessary to investigate systematically whether ions from object-oriented (OO) software engineering are able to isolate explicitly MAS concerns. This paper presents an empirical study that evaluates the degree to which abstractions associated with two OO techniques enable modularization of MAS concerns. The selected techniques involve basic OO ions, such as classes and objects, and more sophisticated ones, namely design patterns and aspects. The gathered results shown that the use of aspects allowed the construction of a MAS with a significant improvement in the modularization of different concerns. Also, the use of aspects resulted in: (i) fewer lines of code, (ii) fewer design and implementation components, and (iii) lower coupling between the components. However, the aspect-oriented approach produced lower cohesion in the MAS components. Finally, an important finding of this empirical study is that aspects supported a better alignment with higher-level abstractions from agent-oriented design models.

Are automatically-detected code anomalies relevant to architectural modularity?: an exploratory analysis of evolving systems

As software systems are maintained, their architecture modularity often degrades through architectural erosion and drift. More directly, however, the modularity of software implementations degrades through the introduction of code anomalies, informally known as code smells. A number of strategies have been developed for supporting the automatic identification of implementation anomalies when only the source code is available. However, it is still unknown how reliable these strategies are when revealing code anomalies related to erosion and drift processes. In this paper, we present an exploratory analysis that investigates to what extent the automatically-detected code anomalies are related to problems that occur with an evolving systems architecture. We analyzed code anomaly occurrences in 38 versions of 5 applications using existing detection strategies. The outcome of our evaluation suggests that many of the code anomalies detected by the employed strategies were not related to architectural problems. Even worse, over 50% of the anomalies not observed by the employed techniques (false negatives) were found to be correlated with architectural problems.

An exploratory study of code smells in evolving aspect-oriented systems

Although aspect-oriented programming (AOP) aims to improve software maintainability, developers can unwittingly introduce code smells in their programs. A code smell is any symptom in the source code that possibly indicates a deeper maintainability problem. Even though a few code smells for AOP have been reported in the literature, there is no evidence if and how they occur in evolving software projects. There is also little knowledge on their actual impact on maintenance effort, such as required refactorings or corrective changes in later software releases. This paper presents an exploratory analysis of code smells recurrently observed in a set of evolving aspect-oriented systems. We analyzed instances of code smells previously reported in the literature and newly-revealed ones. Our study involved in total 18 releases of 3 evolving aspect-oriented systems from different domains. The outcome of our evaluation suggests that previously-documented AOP smells might not occur as often as claimed. Our analysis also revealed that: (1) newly-discovered code smells might occur more often than well-known ones, and (2) the former ones seemed to be consistently associated with non-trivial refactorings and corrective changes.

Design patterns as aspects: a quantitative assessment

Design patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately, object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability. Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare object-oriented and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for a representative set of design patterns. We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although some aspect-oriented implementations of specific patterns resulted in higher coupling and more lines of code.

On the relationship of code-anomaly agglomerations and architectural problems

Several projects have been discontinued in the history of the software industry due to the presence of software architecture problems. The identification of such problems in source code is often required in real project settings, but it is a time-consuming and challenging task. Some authors assume that architectural problems are reflected in source code through individual code anomalies. However, each architectural problem may be realized by multiple code anomalies, which are intertwined in several program elements. The relationships of these various code anomalies and their architecture problems’ counterparts are hard to reveal and characterize. To overcome this limitation, we are studying the architecture impact of a wide range of code-anomaly agglomerations. An agglomeration is a group of code anomalies that are explicitly related to each other in the implementation – e.g. two or more anomalies affecting the same class or method in the program. In our empirical study, we analyzed a total of 5418 code anomalies and 2229 agglomerations within 7 systems. In particular, our analysis focused in understanding (i) how agglomerations and architectural problems relate to each other, and (ii) how agglomerations can support the diagnosis of well-known architectural problems. We observed that most of the anomalous code elements related to architectural problems are members of one or more agglomerations. In addition, this study revealed that, for each agglomeration related to an architectural problem, an average of 2 to 4 anomalous code elements contribute to the architectural problem. Finally, the result of our study suggests that certain types of agglomerations are better indicators of architectural problems than others.

Unveiling and taming liabilities of aspects in the presence of exceptions: A static analysis based approach

As aspects extend or replace existing functionality at specific join points in the code, their behavior may raise new exceptions, which can flow through the program execution in unexpected ways. Assuring the reliability of exception handling code in aspect-oriented (AO) systems is a challenging task. Testing the exception handling code is inherently difficult, since it is tricky to provoke all exceptions during tests, and the large number of different exceptions that can happen in a system may lead to the test-case explosion problem. Moreover, we have observed that some properties of AO programming (e.g., quantification, obliviousness) may conflict with characteristics of exception handling mechanisms, exacerbating existing problems (e.g., uncaught exceptions). The lack of verification approaches for exception handling code in AO systems stimulated the present work. This work presents a verification approach based on a static analysis tool, called SAFE, to check the reliability of exception handling code in AspectJ programs. We evaluated the effectiveness and feasibility of our approach in two complementary ways (i) by investigating if the SAFE tool is precise enough to uncover exception flow information and (ii) by applying the approach to three medium-sized ApectJ systems from different application domains.

Integrating Component and Product Lines Technologies

In this paper, we explore the integration of product line and component technologies in the context of the product derivation process. In particular, we propose new extensions to our existing model-based product derivation tool, called GenArch, in order to address the new abstractions and mechanisms provided by the Spring and OSGi component models. The GenArch extensions enable the automatic instantiation of product lines and applications - implemented using these component technologies. Moreover, it also enables different levels of customization, from fine-grained configuration of component properties to the automatic selection of components that will compose the final product.