CN101957792A - 一种基于契约的aop应用程序中行为冲突问题的自动检查方法 - Google Patents
一种基于契约的aop应用程序中行为冲突问题的自动检查方法 Download PDFInfo
- Publication number
- CN101957792A CN101957792A CN 201010262900 CN201010262900A CN101957792A CN 101957792 A CN101957792 A CN 101957792A CN 201010262900 CN201010262900 CN 201010262900 CN 201010262900 A CN201010262900 A CN 201010262900A CN 101957792 A CN101957792 A CN 101957792A
- Authority
- CN
- China
- Prior art keywords
- contract
- program
- aop
- behavior
- advice
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
本发明涉及一种基于契约的AOP应用程序中行为冲突问题的自动检查方法，包括有以下步骤：1)基于契约式设计思想，使用Java Annotation描述基础程序和方面代码的相关契约；2)抽取源代码中的契约，通过断言验证程序生成工具把已抽取的契约转换成断言验证程序；3)执行包含断言验证程序的目标文件，从而在程序运行时实现行为冲突的自动检测。本发明的有益效果在于：可以在程序运行阶段实现Aspect组合中行为冲突的自动检测，为Aspect的安全组合提供了保障，有利于构建高可信的面向方面软件。
Description
技术领域
本发明涉及面向方面软件在实际应用中面临的关键问题的检测与处理领域，特别是涉及一种基于契约的AOP应用程序中行为冲突问题的自动检查方法。
背景技术
面向方面的程序设计(AOP，Aspect-Oriented Programming)[1][2][3]方法把软件系统的功能和非功能需求、平台特性等诸多不同的关注点相互独立，实现了更好的模块化。它被认为是对面向对象技术的一种必要的补充，弥补了面向对象程序设计方法在跨越多个模块行为上的不足。AOP通过引进Aspect将影响多个类的行为(横切关注点)封装到一个可重用模块中，从而消除了OOP引起的代码混乱和分散问题[4]，降低了类与类之间的耦合度，使软件更易于操作、维护、复用和扩展。一般来说，面向方面软件由两部分组成：实现系统功能的基础程序(base program)和实现横切关注点的程序(Aspect)。一个Aspect又包括两部分：切入点(pointcut)和通知(advice)。一个切入点(pointcut)是一组连接点(join point)的集合，而一个连接点是程序流中的一个特定的执行点。通知(advice)是在连接点(join point)之前(before)、之后(after)、或前后(around)被执行的代码。AspectJ[5]是目前被广泛使用的AOP语言。
目前，面向方面技术正朝着实用化的方向发展。但是，AOP在实际应用中面临一个关键问题：行为冲突。行为冲突也称为Aspect组合的语义冲突问题[6][7]。这种冲突表现为：原本能够正确运行的程序，织入Aspect后，不能正确运行；或者是多个Aspect织入到同一个连结点，织入的先后顺序可能导致Aspect间发生冲突；或者两个Aspect之间是一种互斥的关系，不能同时织入到同一个基础程序，等等。Aspect组合的语义冲突有可能发生于Aspect和基础程序之间，又可能发生于Aspect和Aspect之间。
AOP中的行为冲突问题引起了广泛的关注，产生了一些研究成果。但是大部分研究都还存在一些不足：1)契约检查工具检测不出全部违反契约的行为[8]；2)开发出的用于AOP的DBC(Design by Contract)[9][10]工具主要用于验证契约，而不是用于检测Aspect组合中的行为冲突[11]；3)只检测作用于同一个连接点的Aspect间的冲突[7][12]。随着软件规模的扩大，以及Aspect数量的增加，不仅要解决Aspect间可能发生的冲突，而且要解决Aspect和基础程序间可能发生的冲突。同时，不仅要考虑多个Aspect作用于同一个连接点的情况，而且要考虑Aspect作用于不同的连接点的情况。
参考文献：
[1]Kiczales，G.，Lamping，J.，Menhdhekar，A.，etal.Aspect oriented programming[C].In：Proceedings of ECOOP′97，Number 1241 in Lecture Notes in Computer Science，Springer Verlag，1997，220-242.
[2]Elrad，T.，R.Filman，A.Bader，etal.Aspect-Oriented Programming[J].Comm.ACM，2001，44(10)，special issue.
[3]Chengwan He，Zheng Li，Keqing He.Towards Trusted Aspect Composition.In：Proceedings of2008 International Conference on Computer Science and Software Engineering.Volume，Issue，8-11，2008，643-648.
[4]Jyri Laukkanen.Aspect-Oriented Programming.Computer Science，Seminar paper，2008.
[5]AspectJ Team.The AspectJTM Programming Guide.2003.http://www.eclipse.org/aspectj/doc/released/progguide/
[6]F.Tessier，M.Badri，L.Badri.A Model-Based Detection of Conflicts Between CrosscuttingConcerns：Towards a Formal Approach.In International Workshop on Aspect-Oriented SoftwareDevelopment，Peking University，China，September 2004.
[7]Pascal Durr，Tom Staijen，Lodewijk Bergmans，Mehmet Aksit.Reasoning About SemanticConflicts Between Aspects.In：EIWAS 2005：2nd European Interactive Workshop on Aspects inSoftware.
[8]Robert Bruce Findler，Mario Latendresse，Matthias Felleisen.Behavioral Contracts andBehavioral Subtyping.Foundations of Software Engineering，FSE 2001.pp.229-236.
[9]B.Meyer.“Design by Contract.”in Advances in Object-Oriented Software Engineering，D.Mandrioli and B.Meyer，eds.Prentice Hall，Englewnod Cliffs，N.J.1991，pp.1-50.
[10]Bertrand Meyer.Applying“design by contract”.IEEE Computer Society Press，1992，Volume25，Issue10，Pages：40-51.
[11]David H.Lorenz，Therapon Skotiniotis.Extending Design by Contract for Aspect-OrientedProgramming.arXiv：cs/0501070v1[cs.SE]24Jan，2005.
[12]Istvan Nagy，Lodewijk Bergmans，Mehmet Aksit.Composing Aspects at Shared Join Points.Workshop AID in 20th.ECOOP.France，2006.
发明内容
本发明所要解决的问题是针对上述现有技术而提出一种基于契约的AOP应用程序中行为冲突问题的自动检查方法，能在程序运行时检查由于aspect组合导致的行为冲突问题。
本发明为解决上述提出的问题所采用解决方案为：一种基于契约的AOP应用程序中行为冲突问题的自动检查方法，其特征在于包括有以下步骤：
1)基于契约式设计思想，使用Java Annotation描述基础程序和方面代码的相关契约，主要涉及前置条件和后置条件，织入的Aspect中advice的类型为before advice或/和after advice；
2)根据继承关系和Aspect的织入关系，抽取源代码中的契约，通过断言验证程序生成工具把已抽取的契约转换成断言验证程序；
3)执行包含断言验证程序的目标文件，把织入某个Aspect之前的基础程序视为父类型，织入该Aspect之后的基础程序视为子类型，如果父类型和子类型之间满足行为子类型的条件，就可以保证织入Aspect后程序行为的正确性，从而在程序运行时实现行为冲突的自动检测。
按上述方案，所述的行为子类型的条件是前置条件变弱，后置条件变强。
按上述方案，所述的执行包含断言验证程序的目标文件是指通过AOP语言编译器编译包含断言验证程序的源代码从而生成Java字节码，使用Java执行工具执行包含断言验证程序的目标文件，得到相关执行结果和契约检查报告。
按上述方案，当多个Aspect作用于同一个连接点时，首先确定织入Aspect的数量及其执行的优先级，在AOP语言AspectJ中，通过引入声明declare precedence指定作用于同一个连接点的advice执行的优先级，然后根据优先级的高低依次织入每个Aspect。
按上述方案，如果织入多个Aspect，当程序检查第i个Aspect的契约时，首先要判断第i-1个Aspect的织入类型。
本发明的有益效果在于：基于契约式设计思想，研究基础程序和织入Aspect后的契约继承机制，实现了AOP系统中行为子类型的概念。使用Java annotation描述基础程序和方面代码的相关契约，通过断言验证程序生成工具把基础程序和方面代码中的契约抽取出来，然后把它们转换成断言验证程序用于检查是否违反了相关契约，从而可以在程序运行阶段实现Aspect组合中行为冲突的自动检测，为Aspect的安全组合提供了保障，有利于构建高可信的面向方面软件。
附图说明
图1是行为冲突自动检测流程。
图2是织入Aspect(before advice)前后程序之间的关系。
图3是织入Aspect(after advice)前后程序之间的关系。
图4是织入Aspect(before advice和after advice)前后程序之间的关系。
图5是多个Aspect作用于同一个连接点的例子(引自参考文献[12])。
具体实施方式
下面结合实施例对本发明作进一步说明，但不能作为对本发明的限定。
(1)基于契约式设计思想，使用Java Annotation描述基础程序和方面代码(Aspect)(基础程序和方面代码统称为源代码)的相关契约，本发明主要涉及前置条件和后置条件，织入的Aspect中advice的类型为before advice、after advice或者同时包括before advice和afteradvice；
(2)假设Aspect作用于基础程序中某个类的方法m，为了保证程序行为的正确性，织入before advice、after advice以及同时织入before advice/after advice前后需要满足的契约分别如下表1、表2、表3所示。其中，
表示方面代码中before advice的前置条件；
表示方面代码中before advice的后置条件；
表示方面代码中after advice的前置条件；表示方面代码中after advice的后置条件；mpre表示方法m的前置条件；mpost表示方法m的后置条件；→表示如果前者的条件满足，则后者一定满足。表中的第1列为织入Aspect前程序需要满足的契约，即方法的前置条件和后置条件；第2列为织入Aspect后程序依次要检查的契约；
表1织入Aspect(before advice)前后程序需要满足的契约
表2织入Aspect(after advice)前后程序需要满足的契约
表3织入Aspect(before advice和after advice)前后程序需要满足的契约
(3)根据继承关系和Aspect的织入关系，抽取源代码中的契约，通过断言验证程序生成工具(契约转换程序)把已抽取的契约转换成断言验证程序；
(4)执行包含断言验证程序的目标文件，即通过AOP语言编译器编译包含断言验证程序的源代码从而生成Java字节码，使用Java执行工具执行包含断言验证程序的目标文件，得到相关执行结果和契约检查报告，把织入某个Aspect之前的基础程序视为父类型，织入该Aspect之后的基础程序视为子类型，只要它们之间满足行为子类型的条件(若织入beforeadvice，则织入后程序的前置条件变弱，即：若织入after advice，则织入后程序的后置条件变强，即：
若同时织入before advice和after advice，则织入后程序的前置条件变弱，后置条件变强，即：
)，可以保证织入Aspect后程序行为的正确性，从而在程序运行时实现行为冲突的自动检测。
而且，对于多个Aspect作用于同一个连接点的情况，首先确定织入Aspect数量及其执行的优先级，在AOP语言AspectJ中，通过引入声明declare precedence指定作用于同一个连接点的advice执行的优先级，然后根据优先级的高低依次织入每个Aspect，契约检测流程和织入单个Aspect情况相似。
例如：如图5所示的参考文献[12]中多个aspect作用于同一个连接点(after)call(voidEmployee.increaseSalary(int))的情况，具体实现如下：该例子中一共包括4个Aspect，我们假设数据库连接没有出现问题，所以Aspect XMLPersistence就不需要织入(仅当数据库不可用时才织入该Aspect)，即只需要织入3个Aspect。首先通过声明指定这3个Aspect的优先级，经分析，其优先级为(从高到低)：CheckRaise，DBPersistence，MonitorSalary。在AspectJ中，通过引入另一个Aspect来声明多个Aspect的优先级，也可以把声明优先级的语句分别加入到每一个Aspect，但后者会导致方面间产生不必要的耦合。所以我们采用第一种方法，优先级声明如下：
public aspect CoordinationAspect{
declare precedence：CheckRaise，DBPersistence，MonitorSalary；
}
然后根据已指定的优先级依次织入各个Aspect，根据表2中所示的织入Aspect后连接点处需要满足契约的顺序进行契约检查。需要注意的是：如果类Employee中的方法increaseSalary()以及需要织入的3个方面都包括契约(前置条件/后置条件)的话，当织入Aspect CheckRaise后，方法increaseSalary()的后置条件变强
即为
所以当织入Aspect DBPersistence时，方法的契约发生了变更，依次需要检查的契约是：
织入aspect MonitorSalary的契约检查情况和织入aspect DBPersistence的相似，织入Aspect DBPersistence后，方法的契约同样发生了变更(后置条件变强)，依次需要检查的契约是：
而且，对于织入多个Aspect的情况，当程序检查第i个Aspect的契约时，首先要判断第i-1个Aspect的织入类型，不同的织入类型(before advice/after advice)将导致程序中契约的检查顺序不同，连接点处契约发生的变化也不同。
根据表1，表2，表3所示的当基础程序分别织入before advice，after advice以及同时织入before advice和after advice的契约检查情况可知，它们的契约检查顺序不同。对于织入多个Aspect的情况，如上面文献[12]中的例子所示：如果织入的Aspect为after advice，则连接点处的后置条件会变强；相应的，如果织入的Aspect为before advice，则连接点处的前置条件会变弱。所以，当程序检查第i个Aspect的契约时，首先要判断第i-1个Aspect的织入类型，如果织入的第i-1个Aspect为before advice，则织入后连接点处的前置条件变弱，为已织入的第i-1个Aspect的前置条件；如果织入的第i-1个Aspect为after advice，则织入后连接点处的后置条件变强，为已织入的第i-1个Aspect的后置条件。
本发明提供解决方案的理论基础以便理解：契约式设计(DBC，Design by Contract)在面向对象领域应用得非常广泛，它通过指定前置条件(pre-condition)、后置条件(post-condition)、不变式(invariants)来保证某个方法的行为的正确性，同时，它能够精确地对违反契约的程序进行定位。行为子类型表示一种子类型关系，它不仅从结构上而且从行为上考虑父类型和子类型之间的关系。例如，类C1中包含A方法，C2继承C1，如果C2的实例能够替换C1的实例，则称C2是C1的行为子类型。即：假设父类C1中A的前置/后置条件分别表示为R1和E1，子类C2中A的前置/后置条件分别表示为R2和E2，则满足逻辑关系：(R1→R2)∧(R1→(E2→E1))，即子类C2中A的前置条件变弱，后置条件变强。
Claims (5)
1.一种基于契约的AOP应用程序中行为冲突问题的自动检查方法，其特征在于包括有以下步骤：
1)基于契约式设计思想，使用JavaAnnotation描述基础程序和方面代码的相关契约，主要涉及前置条件和后置条件，织入的Aspect中advice的类型为before advice或/和after advice；
2)根据继承关系和Aspect的织入关系，抽取源代码中的契约，通过断言验证程序生成工具把已抽取的契约转换成断言验证程序；
3)执行包含断言验证程序的目标文件，把织入某个Aspect之前的基础程序视为父类型，织入该Aspect之后的基础程序视为子类型，如果父类型和子类型之间满足行为子类型的条件，就可以保证织入Aspect后程序行为的正确性，从而在程序运行时实现行为冲突的自动检测。
2.按权利要求1所述的基于契约的AOP应用程序中行为冲突问题的自动检查方法，其特征在于所述的行为子类型的条件是前置条件变弱，后置条件变强。
3.按权利要求1所述的基于契约的AOP应用程序中行为冲突问题的自动检查方法，其特征在于所述的执行包含断言验证程序的目标文件是指通过AOP语言编译器编译包含断言验证程序的源代码从而生成Java字节码，使用Java执行工具执行包含断言验证程序的目标文件，得到相关执行结果和契约检查报告。
4.按权利要求1所述的基于契约的AOP应用程序中行为冲突问题的自动检查方法，其特征在于当多个Aspect作用于同一个连接点时，首先确定织入Aspect的数量及其执行的优先级，在AOP语言AspectJ中，通过引入声明declare precedence指定作用于同一个连接点的advice执行的优先级，然后根据优先级的高低依次织入每个Aspect。
5.按权利要求4所述的基于契约的AOP应用程序中行为冲突问题的自动检查方法，其特征在于如果织入多个Aspect，当程序检查第i个Aspect的契约时，首先要判断第i-1个Aspect的织入类型。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 201010262900 CN101957792A (zh) | 2010-08-26 | 2010-08-26 | 一种基于契约的aop应用程序中行为冲突问题的自动检查方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 201010262900 CN101957792A (zh) | 2010-08-26 | 2010-08-26 | 一种基于契约的aop应用程序中行为冲突问题的自动检查方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101957792A true CN101957792A (zh) | 2011-01-26 |
Family
ID=43485130
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 201010262900 Pending CN101957792A (zh) | 2010-08-26 | 2010-08-26 | 一种基于契约的aop应用程序中行为冲突问题的自动检查方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101957792A (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103092668A (zh) * | 2011-11-01 | 2013-05-08 | 镇江华扬信息科技有限公司 | 一种基于契约式设计的Java编译器实现方法 |
| CN103714290A (zh) * | 2013-12-26 | 2014-04-09 | 北京工业大学 | 一种软件行为获取、监控与验证方法 |
| CN103810423A (zh) * | 2012-11-06 | 2014-05-21 | 财团法人资讯工业策进会 | 应用程序的安全处理方法与安全处理系统 |
| CN107608898A (zh) * | 2017-10-10 | 2018-01-19 | 浙江网新恒天软件有限公司 | 一种再现测试流程以实现自动化回归测试的方法 |
| CN108572910A (zh) * | 2017-03-14 | 2018-09-25 | 百度在线网络技术（北京）有限公司 | 用于客户端的实验方法和装置 |
| CN111176660A (zh) * | 2019-12-31 | 2020-05-19 | 中信百信银行股份有限公司 | 一种面向分布式架构的微服务契约管理方法、装置、计算机设备、和可读存储介质 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1946042A (zh) * | 2006-10-09 | 2007-04-11 | 西安交通大学 | 基于aop技术的大规模集群管理监控系统中的报警方法 |
-
2010
- 2010-08-26 CN CN 201010262900 patent/CN101957792A/zh active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1946042A (zh) * | 2006-10-09 | 2007-04-11 | 西安交通大学 | 基于aop技术的大规模集群管理监控系统中的报警方法 |
Non-Patent Citations (1)
| Title |
|---|
| 《IEEE 8th International Conference on Computer and Information Technology Workshops》 20081231 Chengwan He et al Towards Trusted Aspect Composition 第645页右栏至第646页右栏 1-5 , 2 * |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103092668A (zh) * | 2011-11-01 | 2013-05-08 | 镇江华扬信息科技有限公司 | 一种基于契约式设计的Java编译器实现方法 |
| CN103810423A (zh) * | 2012-11-06 | 2014-05-21 | 财团法人资讯工业策进会 | 应用程序的安全处理方法与安全处理系统 |
| CN103714290A (zh) * | 2013-12-26 | 2014-04-09 | 北京工业大学 | 一种软件行为获取、监控与验证方法 |
| CN103714290B (zh) * | 2013-12-26 | 2016-08-17 | 北京工业大学 | 一种软件行为获取、监控与验证方法 |
| CN108572910A (zh) * | 2017-03-14 | 2018-09-25 | 百度在线网络技术（北京）有限公司 | 用于客户端的实验方法和装置 |
| CN107608898A (zh) * | 2017-10-10 | 2018-01-19 | 浙江网新恒天软件有限公司 | 一种再现测试流程以实现自动化回归测试的方法 |
| CN107608898B (zh) * | 2017-10-10 | 2020-01-07 | 浙江网新恒天软件有限公司 | 一种再现测试流程以实现自动化回归测试的方法 |
| CN111176660A (zh) * | 2019-12-31 | 2020-05-19 | 中信百信银行股份有限公司 | 一种面向分布式架构的微服务契约管理方法、装置、计算机设备、和可读存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8539475B2 (en) | API backward compatibility checking | |
| Apel et al. | Semistructured merge: rethinking merge in revision control systems | |
| CN101957792A (zh) | 一种基于契约的aop应用程序中行为冲突问题的自动检查方法 | |
| Li et al. | Classification of software defect detected by black-box testing: An empirical study | |
| Guo et al. | An application of ontology to test case reuse | |
| Eshkevari et al. | An exploratory study of identifier renamings | |
| Jiang et al. | Tracing back the history of commits in low-tech reviewing environments: a case study of the linux kernel | |
| Balliu et al. | Challenges of producing software bill of materials for java | |
| Haitzer et al. | DSL-based support for semi-automated architectural component model abstraction throughout the software lifecycle | |
| Zahid et al. | Evolution in software architecture recovery techniques—A survey | |
| Ahrendt et al. | The KeY system: Integrating object-oriented design and formal methods | |
| Xu et al. | Testing aspect‐oriented programs with finite state machines | |
| dos Santos et al. | Using model transformation to generate graphical counter-examples for the formal analysis of xUML models | |
| Lumpe et al. | PSPWizard: machine-assisted definition of temporal logical properties with specification patterns | |
| CN106033338A (zh) | 基于fog数据的源代码导入及解析的方法和装置 | |
| Seidl et al. | Generative software product line development using variability-aware design patterns | |
| Shao et al. | Combining lexical and structural information for static bug localisation | |
| Kherbouche et al. | An operationalized transformation for activity diagram into YAWL | |
| Sengupta et al. | Requirement traceability in software development process: an empirical approach | |
| Wang et al. | Using workflow patterns to model and validate service requirements | |
| Gaelli et al. | Composing Tests from Examples. | |
| Khan et al. | Natural interpretation of UML/MARTE diagrams for system requirements specification | |
| Ven et al. | Experiences with the automatic discovery of violations to the normalized systems design theorems | |
| Zapalowski et al. | The WGB method to recover implemented architectural rules | |
| US20120054713A1 (en) | Method for Generating Specifications of Static Test |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20110126 |