Skip to main content
QUICK REVIEW

[论文解读] Extending Design by Contract for Aspect-Oriented Programming

David H. Lorenz, Therapon Skotiniotis|ArXiv.org|Jan 24, 2005
Advanced Software Engineering Methodologies参考文献 17被引用 23
一句话总结

本文通过将方面(aspects)分类为无差别型(agnostic)、顺从型(obedient)和叛逆型(rebellious)三种类型,将设计契约(Design by Contract, DbC)扩展至面向切面编程(Aspect-Oriented Programming, AOP),从而确定方法和方面断言的正确运行时执行顺序。该方法确保了AOP系统中责任归属的正确性与行为子类型化,已在Cona工具中实现,支持对类和方面均实现稳健、可验证的契约。

ABSTRACT

Design by Contract (DbC) and runtime enforcement of program assertions enables the construction of more robust software. It also enables the assignment of blame in error reporting. Unfortunately, there is no support for runtime contract enforcement and blame assignment for Aspect-Oriented Programming (AOP). Extending DbC to also cover aspects brings forward a plethora of issues related to the correct order of assertion validation. We show that there is no generally correct execution sequence of object assertions and aspect assertions. A further classification of aspects as agnostic, obedient, or rebellious defines the order of assertion validation that needs to be followed. We describe the application of this classification in a prototyped DbC tool for AOP named Cona, where aspects are used for implementing contracts, and contracts are used for enforcing assertions on aspects.

研究动机与目标

  • 为解决现有DbC方法论无法支持面向切面编程(AOP)中运行时契约强制执行与责任归属的问题。
  • 解决对象与方面断言执行顺序的模糊性,该问题影响AOP系统的正确性与错误报告。
  • 基于方面对方法契约的行为影响,定义其正式分类,以实现一致的运行时验证与子类型化保证。
  • 将DbC语义扩展至支持对通知(advice,即before/after/around)的契约,并确保原始方法与增强后方法之间的行为子类型化。
  • 在Cona中实现并评估该扩展,该工具为AOP感知的DbC工具,通过方面强制执行契约,并以类型安全、责任感知的方式验证断言。

提出的方法

  • 基于方面对方法行为及契约强制顺序的影响,提出将方面划分为无差别型、顺从型和叛逆型的三类分类法。
  • 定义严格的契约验证执行序列:先检查前置条件,后检查后置条件,执行顺序由方面类别决定。
  • 提出行为子类型化规则:被增强的方法必须是其原始对应方法的行为替代品,通过在方法和通知上均验证断言来实现。
  • 使用Cona工具实现DbC扩展,将通知上的前置与后置条件转换为利用AspectJ的切点(pointcut)与通知(advice)机制的运行时检查。
  • 通过追踪契约违反行为,根据方面类别与验证顺序,将责任归属至方法或方面。
  • 确保方面对基础系统契约保持无知状态,从而在保持模块化的同时支持验证。

实验结果

研究问题

  • RQ1在AOP中,验证对象与方面断言的正确运行时顺序是什么?为何不存在普遍适用的执行序列?
  • RQ2如何对方面进行分类,使其对方法契约的行为影响能决定正确且一致的断言验证顺序?
  • RQ3当通知修改方法行为时,如何保持行为子类型化?如何在运行时强制执行这一保证?
  • RQ4当方法与方面均包含断言时,如何准确分配契约违反的责任?
  • RQ5是否可以不修改基础语言或破坏模块化,将DbC机制扩展至AOP?

主要发现

  • 不存在验证对象与方面断言的普遍正确执行顺序,因为正确序列取决于方面在行为上的角色。
  • 将方面分类为无差别型、顺从型和叛逆型,可确定正确的验证顺序并确保行为子类型化。
  • 无差别型方面不影响方法行为,其断言在方法执行后验证;顺从型方面以需按顺序检查前置与后置条件的方式修改行为;叛逆型方面覆盖行为,需严格排序以保持子类型化。
  • Cona工具成功在方法与通知上强制执行契约,支持运行时断言检查与AOP系统中准确的责任归属。
  • 该方法允许方面实现契约,同时契约也强制验证方面上的断言,从而构建出自洽的验证机制。
  • 该分类体系无需复杂路径分析即可实现责任归属,简化了AOP应用中的错误报告。

更好的研究,从现在开始

从论文设计到论文写作,大幅缩短您的研究时间。

无需绑定信用卡

本解读由 AI 生成,并经人工编辑审核。