Automated test generation technique for aspectual features in AspectJ

ContextAspect-oriented programming (AOP) has been promoted as a means for handling the modularization of software systems by raising the abstraction level and reducing the scattering and tangling of crosscutting concerns. Studies from literature have shown the usefulness and application of AOP across various fields of research and domains. Despite this, research shows that AOP is currently used in a cautious way due to its natural impact on testability and maintainability.ObjectiveTo realize the benefits of AOP and to increase its adoption, aspects developed using AOP should be subjected to automated testing. Automated testing, as one of the most pressing needs of the software industry to reduce both effort and costs in assuring correctness, is a delicate issue in testing aspect-oriented programs that still requires advancement and has a way to go before maturity.MethodPrevious attempts and studies in automated test generation process for aspect-oriented programs have been very limited. This paper proposes a rigorous automated test generation technique, called RAMBUTANS, with its tool support based on guided random testing for the AspectJ programs.ResultsThe paper reports the results of a thorough empirical study of 9 AspectJ benchmark programs, including non-trivial and larger software, by means of mutation analysis to compare RAMBUTANS and the four existing automated AOP testing approaches for testing aspects in terms of fault detection effectiveness and test effort efficiency. The results of the experiment and statistical tests supplemented by effect size measures presented evidence of the effectiveness and efficiency of the proposed technique at 99% confidence level (i.e. p < 0.01).ConclusionThe study showed that the resulting randomized tests were reasonably good for AOP testing, thus the proposed technique could be worth using as an effective and efficient AOP-specific automated test generation technique.     

一种基于概念模型的切点定义方法

针对面向方面编程中存在的切点软化问题,提出一种可视化的切点定义方法,切点定义依据一种概念模型而不再依赖于基础程序的具体结构,实现了切点定义与基础程序的解耦,提高了切点鲁棒性。概念模型是对AspectJ切点表达式的可视化的抽象概括,通过扩展UML元模型实现,文中称之为切点模型。同时,扩展了Rational Rose,使其支持切点模型的建模,并实现了由切点模型自动生成方面框架代码。     

基于扩展UML的面向方面的建模

提出了一个新的扩展UML进行面向方面建模的方法，它以合适的语义表达了AspectJ和AspectC++的元素和织入机制。在这个方法中，方面继承自类，切入点和通知继承自特征，这样切入点和通知是方面的一部分，方面与基本类的关系用横切依赖表示。切入点的图符可以表达多个方面在相同连接点的横切行为，通知以一致的方式建模结构横切和行为横切，通过在顺序图上新加一个通知发出焦点，并通知表示为消息，这样可以清晰建模通知在何时何处怎样影响系统的行为。     

Execution levels for aspect-oriented programming: Design,semantics, implementations and applications

In aspect-oriented programming (AOP) languages, advice evaluation is usually considered as part of the base program evaluation. This is also the case for certain pointcuts, such as if pointcuts in AspectJ, or simply all pointcuts in higher-order aspect languages like AspectScheme. While viewing aspects as part of base level computation clearly distinguishes AOP from reflection, it also comes at a price: because aspects observe base level computation, evaluating pointcuts and advice at the base level can trigger infinite regression. To avoid these pitfalls, aspect languages propose ad-hoc mechanisms, which increase the complexity for programmers while being insufficient in many cases. After shedding light on the many facets of the issue, this paper proposes to clarify the situation by introducing levels of execution in the programming language, thereby allowing aspects to observe and run at specific, possibly different, levels. We adopt a defensive default that avoids infinite regression, and gives advanced programmers the means to override this default using level-shifting operators. We then study execution levels both in practice and in theory. First, we study the relevance of the issues addressed by execution levels in existing aspect-oriented programs. We then formalize the semantics of execution levels and prove that the default semantics is indeed free of a certain form of infinite regression, which we call aspect loops. Finally, we report on existing implementations of execution levels for aspect-oriented extensions of Scheme, JavaScript and Java, discussing their implementation techniques and current applications.     

对AspectJ中Call和Execution语义的研究

AOP(面向方面编程)提供了一种有效的方法封装软件中的横切行为,AspectJ是对Java的一个通用AOP扩展。本文首先分析call和execution这两种类型PCD的语义,然后指出这两个PCD基于的一个共同基础存在语义上的不一致,最后基于前面的讨论分析给出了使用这两类PCD的使用建议。     

中介者模式的面向方面实现

中介者模式常被应用于多个对象需要交互的场合.使用传统的面向对象技术的实现方案容易导致代码分散,冗余代码多,可维护性低.使用面向方面技术实现中介者模式的方案,用方面来表达中介者对象,并把构建模式的同事对象所需要的代码也封装到方面中,对象的交互则使用切入点的定义与通知来实现.与传统实现方案相比,基于面向方面技术的实现方案具有代码集中、可读性强、可扩展性强等优点.     

<Emphasis Type="Italic">RAMBUTANS</Emphasis>: automatic AOP-specific test generation tool

Aspect-oriented programming (AOP) is a programmatic methodology to handle better modularized code by separating crosscutting concerns from the traditional abstraction boundaries. Automated testing, as one of the most demanding needs of the software development to reduce both human effort and costs, is a delicate issue in testing aspect-oriented programs. Prior studies in the automated test generation for aspect-oriented programs have been very limited with respect to the need for both adequate tool support and capability concerning effectiveness and efficiency. This paper describes a new AOP-specific tool for testing aspect-oriented programs, called RAMBUTANS. The RAMBUTANS tool uses a directed random testing technique that is especially well suited for generating tests for aspectual features in AspectJ. The directed random aspect of the tool is parameterized by associating weights to aspects, advice, methods, and classes by controlling object and joint point creations during the test generation process. We present a comprehensive empirical evaluation of our tool against the current AOP test generation approaches on three industrial aspect-oriented projects. The results of the experimental and statistical tests showed that RAMBUTANS tool produces test suites that have higher fault-detection capability and efficiency for AspectJ-like programs.     

Performance assessment and tuning for exchange of clinical documents cross healthcare enterprises

BackgroundTo integrate electronic health records (EHRs) from diverse document sources across healthcare providers, facilities, or medical institutions, the IHE XDS.b profile can be considered as one of the solutions. In this research, we have developed an EHR/OpenXDS system which adopted the OpenXDS, an open source software that complied with the IHE XDS.b profile, and which achieved the EHR interoperability.ObjectiveWe conducted performance testing to investigate the performance and limitations of this EHR/OpenXDS system.MethodologyThe performance testing was conducted for three use cases, EHR submission, query, and retrieval, based on the IHE XDS.b profile for EHR sharing. In addition, we also monitored the depletion of hardware resources (including the CPU usage, memory usage, and network usage) during the test cases execution to detect more details of the EHR/OpenXDS system's limitations.ResultsIn this EHR/OpenXDS system, the maximum affordable workload of the EHR submissions were 400 EHR submissions per hour, the DSA CPU usage was 20%, memory usage was 1380 MB, the network usages were 0.286 KB input and 7.58 KB output per minute; the DPA CPU usage was 1%, memory usage was 1770 MB, the network usages were 7.75 KB input and 1.54 KB output per minute; the DGA CPU usage was 24%, memory usage was 2130 MB, the network usages were 1.3 KB input and 0.174 KB output per minute. The maximum affordable workload of the EHR queries were 600 EHR queries per hour, the DCA CPU usage was 66%, the memory usage was 1660 MB, the network usages were 0.230 KB input and 0.251 KB output per minute; the DGA CPU usage was 1%, the memory usage was 1890 MB, the network usages were 0.273 KB input and 0.22 KB output per minute. The maximum affordable workload of the EHR retrievals were 2000 EHR retrievals, the DCA CPU usage was 79%, the memory usage was 1730 MB, the network usages were 19.55 KB input and 1.12 KB output per minute; the DPA CPU usage was 3.75%, the memory usage was 2310 MB, and the network usages were 0.956 KB input and 19.57 KB output per minute.Discussion and conclusionFrom the research results, we suggest that future implementers who deployed the EHR/OpenXDS system should consider the following aspects. First, to ensure how many service volumes would be provided in the environment and then to adjust the hardware resources. Second, the IHE XDS.b profile is adopted by the SOAP (Simple Object Access Protocol) web service, it might then move onto the Restful (representational state transfer) web service which is more efficient than the SOAP web service. Third, the concurrency process ability should be added in the OpenXDS source code to improve the hardware usage more efficiently while processing the ITI-42, ITI-18, and ITI-43 transactions. Four, this research suggests that the work should continue on adjusting the memory usage for the modules of the OpenXDS thereby using the memory resource more efficiently, e.g., the memory configuration of the JVM (Java Virtual Machine), Apache Tomcat, and Apache Axis2. Fifth, to consider if the hardware monitoring would be required in the implementing environment. These research results provided some test figures to refer to, and it also gave some tuning suggestions and future works to continue improving the performance of the OpenXDS.     

面向方面的程序设计:概念、实现与未来

面向对象程序设计（OOP）的出现极大地提高了软件的可读性、可维护性和可复用性,但OOP并没有彻底解决软件的维护和复用问题,本质上是因为OOP难以模块化处理软件系统的横切关注点,以至于业务逻辑代码和其它代码（如日志记录、安全验证等）相互“纠缠”在一起,使得程序难以维护和复用。面向方面的程序设计（AOP）由此诞生,它最主要的设计原则是模块化系统的横切关注点,将业务代码与其它代码解耦,在更高的抽象和分解层次上,进一步提高了软件的可维护性、可复用性和可扩展性。首先深度探索了AOP的起源,然后阐述了AOP的本质,接着介绍了AOP的基本概念并以最为流行的实现语言AspectJ为例,剖析了AOP的实现机制,最后讨论了AOP在软件开发、测试、分析、度量和重构等领域的研究状况。     

面向方面软件重构等价性形式化证明方法

软件重构在不改变程序行为的情况下通过对代码进行小的改进以提升设计，使之更容易理解和维护，面向方面的程序设计是软件开发的新技术，为了有效实施面向方面的软件重构，需要开发者识别面向方面程序的转化规则。然而，由于使用的AOP语言没有形式化的语义定义，难以确认转化和重构的程序运行行为。本文对MCI操作语义的面向方面的扩展使之支持程序的方面特征的描述，定义了两个程序的观测等价，讨论了AspectJ的形式语义模型的建立，在MCI的语义下形式化地精确证明了Add Before-executing编程规则的观测等价性，其基本原理和方法可以适用于其他规则的证明，通过上述工作提出了面向方面重构的程序和它的面向对象程序原型等价性的证明方法。     

面向方面的程序设计综述

现在大多数的软件项目都选择OOP，但OOP技术也有其局限性，它对某些需求并不能很好地进行描述。本文介绍了一种全新的程序设计方法一面向方面的程序设计方法，这种程序设计方法可以有效地描述OOP方法不能描述的横切关注点；介绍了面向方面程序设计的基本思想以及面向方面程序设计语言AspectJ的基本概念及面向方面软件开发方法。     

Blending design patterns with aspects: A quantitative study

Design patterns often need to be blended (or composed) when they are instantiated in a software system. The composition of design patterns consists of assigning multiple pattern elements into overlapping sets of classes in a software system. Whenever the modularity of each design pattern is not preserved in the source code, their implementation becomes tangled with each other and with the classes’ core responsibilities. As a consequence, the change or removal of each design pattern will be costly or prohibitive as the software system evolves. In fact, composing design patterns is much harder than instantiating them in an isolated manner. Previous studies have found design pattern implementations are naturally crosscutting in object-oriented systems, thereby making it difficult to modularly compose them. Therefore, aspect-oriented programming (AOP) has been pointed out as a natural alternative for modularizing and blending design patterns. However, there is little empirical knowledge on how AOP models influence the composability of widely used design patterns. This paper investigates the influence of using AOP models for composing the Gang-of-Four design patterns. Our study categorizes different forms of pattern composition and studies the benefits and drawbacks of AOP in these contexts. We performed assessments of several pair-wise compositions taken from 3 medium-sized systems implemented in Java and two AOP models, namely, AspectJ and Compose*. We also considered complex situations where more than two patterns involved in each composition, and the patterns were interacting with other aspects implementing other crosscutting concerns of the system. In general, we observed two dominant factors impacting the pattern composability with AOP: (i) the category of the pattern composition, and (ii) the AspectJ idioms used to implement the design patterns taking part in the composition.     

A constraint-weaving approach to points-to analysis for AspectJ

Points-to analysis is a static code analysis technique that establishes the relationships between variables of references and allocated objects. A number of points-to analysis algorithms have been proposed for procedural and object-oriented languages like C and Java, while few of them can be used for AspectJ as we know so far. One main reason is that AspectJ is an aspect-oriented language which implements the separation of crosscutting concerns by advices, pointcuts, and inter-type declarations, while a points-to analysis of AspectJ programs may be imprecise because any aspect woven into the base code may change the points-to relations in the program and thus a conservative analysis has to be taken in order to handle the aspects. In this paper, we propose a context-sensitive points-to analysis technique called AJPoints for AspectJ. Similar to the weaving mechanism for AspectJ, AJPoints obtains the constraints and templates on the points-to relations for the base code and the aspects, respectively, but weaves and solves them in an iterative manner in order to cross the boundary between the base code and the aspects. We have implemented AJPoints on abc AspectJ compiler and evaluated it by using twelve AspectJ benchmark programs. The experimental results show that our technique can achieve a high precision about points-to relations in AspectJ programs.     

Tool-Supported Refactoring of Existing Object-Oriented Code into Aspects

Aspect-oriented programming (AOP) provides mechanisms for the separation of crosscutting concerns - functionalities scattered through the system and tangled with the base code. Existing systems are a natural testbed for the AOP approach since they often contain several crosscutting concerns which could not be modularized using traditional programming constructs. This paper presents an automated approach to the problem of migrating systems developed according to the object-oriented programming (OOP) paradigm into aspect-oriented programming (AOP). A simple set of six refactorings has been defined to transform OOP to AOP and has been implemented in the AOP-migrator tool, an Eclipse plug-in. A set of enabling transformations from OOP to OOP complement the initial set of refactorings. The paper presents the results of four case studies, which use the approach to migrate selected crosscutting concerns from medium-sized Java programs (in the range of 10K to 40K lines of code) into equivalent programs in AspectJ. The case study results show the feasibility of the migration and indicate the importance of the enabling transformations as a preprocessing step     

面向方面测试方法的研究*

面向方面编程(AOP)允许程序员将跨越多个模块的横切关注行为封装到一个可重用的模块中,极大地增强了系统的可维护性和代码的重用性。但这样的新特性也给测试带来了新的挑战,因为方面与原始模块之间错综复杂的依赖关系可能导致新的错误,从而使得传统的测试方法不能很好适应。以AOP错误模型为基准,对四种具有代表性的AOP测试方法发现错误的能力和有效性进行了深入详细的研究和对比,分析总结了目前面向方面测试技术领域存在的主要问题以及将来的发展方向。     

Application-specific models and pointcuts using a logic metalanguage

In contemporary aspect-oriented languages, pointcuts are usually specified directly in terms of the structure of the source code. The definition of such low-level pointcuts requires aspect developers to have a profound understanding of the entire application's implementation and often leads to complex, fragile and hard-to-maintain pointcut definitions. To resolve these issues, we present an aspect-oriented programming system that features a logic-based pointcut language that is open such that it can be extended with application-specific pointcut predicates. These predicates define an application-specific model that serves as a contract that base program developers provide and aspect developers can depend upon. As a result, pointcuts can be specified in terms of this more high-level model of the application which confines all intricate implementation details that are otherwise exposed in the pointcut definitions themselves.     

New AspectJ Pointcuts for Integer Overflow and Underflow Detection

ABSTRACT

Aspect-oriented Programming (AOP) appears to be a promising paradigm for software security hardening. Using AOP, security experts can be responsible for coding security properties, and developers can concentrate on the basic functionality of the program. AspectJ extends the Java programming language to implement crosscutting concerns modularly in general. In this paper, we have extended AspectJ with new pointcuts in order to detect integer overflows and underflows in Java. Integer overflows and underflows in Java occur silently without throwing an exception. A malicious user can exploit them to produce a security breach. Hence, we implement new pointcuts: addition, multiplication, and subtraction that allow to write advices around integer arithmetic operations to detect integer overflow and underflow and consequently prevent considerable number of security breaches.     

Aspect-orientation is a rewarding investment into future code changes – As long as the aspects hardly change

ContextAspect-Oriented Programming (AOP) is often described as a technique which improves the resulting software’s modularity. However, previous experiments seem to indicate that AOP is a technique which potentially increases the development or maintenance time. A possible reason why previous experiments were not able to show such a benefit is that those experiments did not consider situations where AOP has its strength: situations where aspects change.ObjectivesOur objective is to analyze whether initial higher development times caused by aspect-oriented programming can be compensated by frequent changes on the aspect code.MethodThis study is an empirical study with 15 subjects based on a within-subject design (repeated measurement) using two randomized groups. The measurement is development time until programming tasks completion. Additionally, an exploratory study is performed which analyzed (a) in separation out- and under-performing subjects with respect to development time, (b) the possible influence of the lines of code, (c) the possible influence of the number of advice and pointcuts, and finally (d) the possible impact of if-statements in the aspect-oriented solutions.ResultsThe experiment shows that frequent changes in the crosscutting code which do not change the aspect’s underlying structure compensate an initial higher development time for those concerns. But it also shows that changes, which do alter the concern’s structure again, result in higher development times when using AOP. Furthermore, the paper shows that the results are similar for out- and under-performing subjects in the experiment. Finally it shows that if changes are required in an aspect’s structure, subjects tend to perform such structural changes in a non-uniform way.ConclusionAOP is a potential rewarding investment into future code changes – but it has risks.