Contracts for Aspect-Oriented Design Sérgio Agostinho, Ana Moreira
Pedro Guerreiro
CITI / Universidade Nova de Lisboa 2829-516 Caparica, Portugal (+351) 21 294 85 36
Universidade do Algarve 8005-139 Faro, Portugal (+351) 289 800 900
{ sergioag, amm }@di.fct.unl.pt
[email protected]
ABSTRACT The Java approach to Object-Oriented Design by Contract can be extended and applied to Aspect-Oriented Software. For doing so, we need to address how current Object-Oriented Design by Contract can be modified to tackle aspect advising, as well as to actually extend the Design by Contract approach for aspect modules. Our approach is general enough to be applied to Java Aspect-Oriented extensions such as AspectJ, CaesarJ, and FuseJ.
Keywords Aspect-Oriented Design, Aspect-Oriented Programming, Design by Contract, Object-Oriented Programming, Object-Oriented Design.
1. INTRODUCTION Design by Contract (DbC), introduced in the Eiffel language [30], addresses the reliability concern in Object-Oriented Programming (OOP). Meyer [31] defines software reliability as correctness and robustness. For correctness and robustness, routines and classes can have assertions [21], namely: preconditions, conditions that must be true prior routine execution; postconditions, conditions that must be true as a result of the execution routine; and class invariants, conditions that must be true during the lifetime of a class object, between method calls. Postconditions may include “frame conditions”, a set of class variables that are changed by the method execution. In Eiffel, this is supported by the “only” clause. Aspect-Oriented Software Development (AOSD) deals with crosscutting concerns, and provides means for their systematic identification, separation, representation and composition [32]. Crosscutting concerns are encapsulated in modules, known as aspects, and composition mechanisms are later used to weave them back with other core modules, at load time, compilation time, or run-time [6]. The best known Aspect-Oriented Programming (AOP) implementation is AspectJ [23] [24]. Earlier implementations include, for example, composition filters [1], adaptive programming [18] and subject-oriented programming [20]. Java does not have native support for DbC, and so several projects have provided extensions and libraries to address this presumed shortcoming. Our goal is in the same direction, as this paper discusses how Java AOP can be extended with DbC. After this introduction, in Section 2 we present some of the techniques used to extend Java with DbC. Then, in Section 3 we concentrate on the problems raised in DbC by the interaction of aspects. In Section 4 we show how to extend with contracts for aspects. Finally, in Section 5 we briefly discuss some language specific
issues, namely on AspectJ [4], CaesarJ [3], and FuseJ [38]. We wrap up with a survey of related work. The conclusions follow.
2. DESIGN BY CONTRACT FOR JAVA The original Java specification, “Oak” [15], contained assertions, namely constraints on variables and method pre/postconditions. However, probably due to schedule constraints, this was not implemented in the final specification. Full Design by Contract support was been a pending Request For Enhancements (RFE) at the Sun Developer Network since 2001 and it is currently the #2 top RFE1. Despite community demand, the Java programming language has yet to fully support DbC, even if the assert statement was added in version 1.4 [17]. Whether or not Sun Microsystems will introduce DbC support in a future revision of the Java language is debatable, since historically the company has been reluctant to changes that imply major changes in the Java Virtual Machine. Indeed, changes in the language Abstract Syntax Tree would have to be significant, which might break backward compatibility. The following code listings provide some examples, which for simplicity use an arbitrary syntax extension (extensions in bold): Listing 1 for preconditions and postconditions, Listing 2 for the old keyword, and Listing 3 for class invariants. These examples refer to classes, but contracts can be added to interfaces too. In general, in the remaining of this paper, our observations on class contracts also apply to interfaces. class MathFunctions { static int factorial(int n) require { assert n >= 0; } { /* function body… */ } ensure { if (n == 0) assert result == 1; else assert result >= 1; } }
Listing 1. Extending Java with pre- and postconditions class Point2D { private int x, y; void moveBy(int deltaX, int deltaY) { /* method body… */ } ensure { assert this.getX() == old.getX() + deltaX; assert this.getY() == old.getY() + deltaY; } }
Listing 2. Extending Java with the old keyword
1
http://bugs.sun.com/bugdatabase/top25_rfes.do (Dec. 2007)
There are some proposals for extending the Java language syntax with contracts, for example: Handshake [11], ContractJava [13], and the KJC compiler [27]. Since doing this requires a specialized compiler, several ad-hoc solutions use different approaches for writing contracts, for example: executable code through naming conventions; or a constraint language such as the Java Modeling Language (JML) [8], embedded in comments or metadata annotations. Several techniques have been used for implementing DbC in Java: source code preprocessing (iContract [26]), bytecode instrumentation (Jcontractor [22]), AOP (Contract4J [39], DbC4J2), and more recently – compiler plug-in (Modern Jass [34]). class Simple2DCoordinates invariant { assert latitude >= -90 && latitude = -180 && longitude 0.00; assert obj.getValue() 0.00; } { double valueWithDiscount = sale.getValue() * 0.95; sale.setValue(valueWithDiscount); } }
Listing 5. Web store example aspect with contract While simple, the extended Liskov’s Principle raises some interesting issues. First, the assertions increase the coupling of the aspect with the classes, especially if they use private variables or methods. Secondly, contracts implemented as aspects have been criticized [5], since contracts should a part of the class interfaces. These are known issues of AOP, which can be mitigated through tool support, namely IDE visualization and documentation generation, similarly to the support offered by AspectJ Development Tools for Eclipse [9]. True aspect polymorphism is non-existent in current AOP, since advice are unnamed As such, partial pre/postconditions are composed through the OOP inheritance “axis” and then through the AOP advising “axis”. Advice subcontracting order is given by the AOP solution aspect precedence mechanisms, i.e. preA.foo() → preB.foo() .
4.4 Mixins and multiple inheritance A mixin [7] is a module with features meant to be inherited as module extension, not as type refinement. Therefore, the behavioral subtyping principle is not applicable to mixins.
However, inherited methods must respect its respective pre and postconditions, and the destination class invariants. Multiple inheritance is present in Java only with interfaces. If interfaces are to have contracts, then we have to deal with the substitution principle in the presence of multiple inheritance. The Eiffel language does it with routine renaming when name clashes occur. Another solution [14] is to generalize the behavioral subtyping principle, so that a subtype must conform to every super type subtyping rules. That is, if C is a subtype of A and B, and if method C.foo() is overriding or implementing A.foo() and B.foo(), then C.Foo’s precondition must be contravariant to A.preFoo()’s precondition and to B.preFoo()’s precondition. Postconditions and invariants follow similar rules.
5. LANGUAGE SPECIFIC CONSIDERATIONS
configurations, a set of linklets, a composition rule for mapping a set of components/services into a service. The component operations are expressed in regular Java interfaces. The linklet mechanism is particularly interesting, as it features an optional when clause, which is used to specific preconditions regarding the mapping. A possible approach to extending FuseJ to DbC could be adding an additional clause for postconditions. Invariants are not likely to be useful, since linklets link components, and the internal state of the classes that implement them is not available. However, in order to correctly enforce assertions, contracts must be part of interfaces and not of classes. The extended behavioral subtyping principle would work as defined before in Section 4.3.
The previous discussion was based on AspectJ-like advice, but it did not specify the actual AOP language. In this section, we specialize for some AOP languages.
Since FuseJ aspectization is performed only on components, contracts among classes proceed as in regular Java DbC. And, FuseJ focusing on component composition, mixins are not necessary.
5.1 AspectJ
6. RELATED WORK AND DISCUSSION
The aspect module in AspectJ [4] is essentially an extension to the class module, in terms of metamodel [19]. As such, we need to check OOP assertions in aspects. Pre/postconditions and invariants must be checked for aspect methods, including the aspect super types, since aspects can extend classes. The original substitution principle is applicable. There are no preconditions for constructors, since aspects are instantiated by the system.
The identification of new design challenges with AOP is not new. Klaeren et al. [25] identified a set of them including aspect composition through the use of DbC. Their approach in using contracts for aspect-oriented design reinforces our work, and it complements it, in the sense that it deals with aspect/aspect interaction, whereas ours only deals with aspect/class interaction.
As for the extended substitution principle, the declare precedence mechanism determines the aspectization order. AspectJ intertype declarations used with interfaces are an ad-hoc form of mixins, and follow the rules presented in Section 4.4.
5.2 CaesarJ CaesarJ [3] does not have a specific module for aspects. Instead, it features the virtual class module, which behaves both as class and aspect. As such, most of the comments on AspectJ in Section 5.1 apply for CaesarJ. The main difference is that CaesarJ features several modes of deployment. That is, CaesarJ “aspects” are explicitly instantiated (deployed) by “classes”. Therefore, they require contract evaluation for constructors, unless they are of singleton type, in which case they work just like in AspectJ. Besides, failures in “aspect” constructor preconditions will be blamed on the client, just like in a regular class. The “declare precedence” mechanism of AspectJ is supported in CaesarJ. Intertype declarations are not supported: instead, all virtual classes are mixins. Therefore, CaesarJ must follow the rules for mixin contracts that we presented in Section 4.4.
5.3 FuseJ FuseJ [38] is a Component-Based Software Development (CBSD) and AOP language whose authors claim that that there is no need for an “aspect” module, and that choosing either a component or aspect during early design compromises the evolution of the system. They propose that crosscutting concerns are implemented as components, and that the composition itself is performed at later stages of implementation, either as a regular component or as an aspect. FuseJ introduces new modules to support this: services, a set of operations that a component will provide and can expect to be available by the environment where it will be deployed; and
Open Modules [2] is a module system for aspects, which enables software evolution with AOP while maintaining the expected behavior for the module’s clients. It is accomplished by a new design approach: advice which are external to the module can only operate on the public pointcuts of that module. By forcing the pointcuts to be explicitly declared within the module itself, and it is more suited for CBSD than for AOSD in general. Crosscut programming interfaces (XPI) [16] is an approach based on the separation of advice and pointcuts into different aspects, using only AspectJ constructs. One aspect contains the actual aspect implementation, based on the pointcut exposed by the second aspect – the “interface” aspect. A third aspect enforces that no aspect can break the XPI contract, by advising the code through pointcuts other than the provided in the “interface” aspect. XPI relates to our work in the sense that it addresses the issue of maintaining module behavior in the presence of aspects, relying on contracts. However, it differs in that its contracts apply on pointcuts, whereas ours extend object interface contracts. Pipa [41] is a behavioral interface specification language for AspectJ, which extends JML [8]. It comes with a tool that transforms AspectJ/Pipa code into Java/JML, to take advantage of the JML support tools. While this ensures a good tool support, it is not clear how blame is assignment when a contract is broken. The authors make a distinction between module-level specifications, assertions on the behavior of advice, introductions, and methods; and aspect-level specifications, contracts on the aspect state. Pipa supports preconditions and postconditions (including frame conditions) on advice and introductions, as well as invariants on aspects. However it does not seem to comply with the substitution principle. As a result, advice preconditions and postconditions test the actual behavior of the advice code, instead of the advised method code.
ConFA [36] [29] is a tool for adding DbC support to Java and to AOP. The actual infrastructure is based in AOP. ConFA3 extends the Java and AspectJ syntax with support for DbC. Moreover, this work presents in-depth study on the evaluation sequence flow and blame assignment, by characterizing aspects in three types: agnostic, obedient, and rebellious. ConFA authors recognize that aspect advice may temporarily violate contracts, but do not enforce substitution principle. The issue is that in ConFA, like in Pipa, advice contracts are seen as advice assertions per se, not as contract extensions of the advised classes. Finally, ConFA does not address around advice or advice invariants. The tool infrastructure is somewhat cumbersome, since it involves preprocessing of extended Java/AspectJ source code (where contracts are mapped into aspects), prior to the AspectJ weaving. COW (Contract Writing language) [35] is a constraint language for AspectJ, using predicate logic. It features an approach to verification called Weaving by Contract. The language is based on the contract module which restricts a certain class, and declares preconditions, postconditions and invariants for each method. However, this work does not address contract inheritance or intertype declarations. The infrastructure is complex, as it includes an AspectJ analysis library, a predicate repository, as well as an API for Java and GNU Prolog interoperability. Moreover, the textual separation of contracts from modules violates of one the premises of Design by Contract [31] – contracts are inherently part of the modules.
7. CONCLUSIONS Design by Contract is widely accepted as an important mechanism for increasing reliability in reusable software modules, including amidst the Java developer community. As a consequence, multiple ad-hoc solutions have been developed for introducing DbC in Java and also in Aspect-Oriented systems based on Java. This has happened mostly in the academic world, but some examples exist in the industry. These are implemented using various technologies, and support different sets of features. Unfortunately, some of these mechanisms have incorrect semantics, especially in terms of the substitution [13]. These issues may be solved if a future release of Java actually offers native support for DbC but that is not on the horizon, to our knowledge. The AOSD community has boomed in the last decade, and most AOP implementations are based on Java. Although most of the developer and user community has been converging into AspectJ, making it the most popular AOP solution, it seems that AspectJ lacks expressiveness in some domains and for some tasks. More, defining effective approaches for AOD is still a subject under discussion [40]. We believe that these two issues are intertwined. When we try to integrate DbC and AOP, the rough edges of each of them surface in conflicting ways: DbC becomes more complex with aspect interactions, and extending AOP with contracts is not a simple task. Nevertheless, we believe that AOD must properly address contracts, so that developers can indeed acquire a correct understanding on the interfaces of reusable modules, thus increasing the reliability of the systems they are designing.
3
“ConFA” is not the actual name of the tool – its real name is an inappropriate word in Portuguese.
ACKNOWLEDGMENTS This work was partly supported by the Portuguese Fundação para a Ciência e Tecnologia, in the context of the SOFTAS project (POSI/EIA/60189/2004).
8. REFERENCES [1] Aksit, M., Bergmansand, L., and Vural, S. An ObjectOriented Language-Database Integration Model: The Composition-Filters Approach, Proceedings of the 6th European Conference on Object-Oriented Programming (ECOOP'92), 1992. [2] Aldrich, J. Open Modules: Modular Reasoning about Advice. ECOOP 05 Proceedings, LCNS 3586, Springer, 2005. [3] Aracic, I., Gasiunas, V., Mezini, M., and Ostermann, K. An Overview of CaesarJ. Transactions on Aspect-Oriented Software Development, 2006. [4] AspectJ Team, The. The AspectJ Programming Guide. 2003, available at http://www.eclipse.org/aspectj/doc/released/progguide/. [5] Balzer, S., Eugster, P., and Meyer, B. Can Aspects Implement Contracts? Proceedings of Rapid Integration of Software Engineering techniques (RISE) 2006, Geneva, Switzerland, September 13-15, 2006. [6] Baniassad, E., Clements, P. et al. Discovering early aspects. IEEE Software, Vol. 23, Issue 1, January/February 2006. [7] Bracha, G., and Cook, W. Mixin-based Inheritance, ECOOP/OOPSLA'90 Proceedings, October 21-25, 1990. [8] Burdy, L., Cheon, Y., Cok, D., et al. An overview of JML tools and applications. International Journal on Software Tools for Technology Transfer, June 2005. [9] Colyer, A., Clement, A., Harley, G., and Webster, M. Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools, The Eclipse Series, Addison-Wesley, 2004. [10] Dantas, D., and Walker, D. Harmless Advice. Annual Symposium on Principles of Programming Languages (POPL’06), South Carolina, USA, January 11-13, 2006. [11] Duncan, A., and Hölzle, U. Adding Contracts to Java with Handshake. Technical report TRCS98-32, December 8, 1998. [12] Filman, R., and Friedman, D. Aspect-Oriented Programming is Quantification and Obliviousness. RIACS Technical Report 01.12, May 2001. [13] Findler, R., and Felleisen, M. Contract Soundness for Object-Oriented Languages. Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA), Florida, USA, 2001. [14] Findler, R., Latendresse, M., and Felleisen, M. Behavioral contracts and behavioral subtyping. Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, Vienna, Austria, 2001. [15] First Person Inc. Oak Language Specification. 1994. [16] Griswold, W., Shonle, M, et al. Modular Software Design with Crosscutting Interfaces, IEEE Software (Vol. 23, No. 1), January/February 2006. [17] Gosling, J., Joy, B., Steele, G., and Bracha, G. The Java Language Specification (third edition). Prentice-Hall, 2005.
[18] Gouda, M., and Herman, T. Adaptive Programming, IEEE Transactions on Software Engineering, Volume 17 Issue 9, September 1991. [19] Han, Y., Kniesel, G., and Cremers, A. A Meta Model for AspectJ. Technical Report IAI-TR-2004-3, Computer Science Department III, University of Bonn, October 2004. [20] Harrison, W., and Ossher, H. Subject-Oriented Programming – A Critique of Pure Objects. ACM SIGPLAN Notices, Volume 28, Issue 10, October 1993. [21] Hoare, C. An Axiomatic Basis for Computer Programming. Communications of the ACM, Volume 12, Number 10 (October 1969), 576-580. [22] Karaorman, M., and Abercrombie, P. jContractor: Introducing Design-by-Contract to Java Using Reflective Bytecode Instrumentation. Formal Methods in System Design, Volume 27, Number 3, November, 2005. [23] Kiczales, G., Lamping, J., Mendhekar, A., et al. AspectOriented Programming. 11th European Conference on Object-Oriented Programming (ECOOP'97), Jyväskylä, Finland, June 9-13, 1997. [24] Kiczales, G., Hilsdale, E., Hugunin, J., et al. An Overview of AspectJ. 15th European Conference on Object-Oriented Programming (ECOOP 2001), Budapest, Hungary, June 1822, 2001. [25] Klaeren, H., Pulvermüller, E., Rashid, A., and Speck, A. Aspect Composition applying the Design by Contract Principle. Generative and Component-based SoftwareEngineering Second International Symposium (GCSE), Erfurt, Germany, 2000. [26] Kramer, R. iContract - the Java design by contract tool. 26th Technology of Object-Oriented Languages and Systems (TOOLS), California, USA, 1998. [27] Lackner, M., Krall, A., and Puntigam, F. Supporting Design by Contract in Java. Journal of Object Technology, Vol.1, No. 3, Special Issue: TOOLS USA 2002 proceedings. [28] Liskov, B., and Wing, J. Family Values: A Behavioral Notion of Subtyping. Technical report MIT/LCS/TR-562b, Carnegie Mellon University, July 16, 1993. [29] Lorenz, D., and Skotiniotis, T. Extending Design by Contract for Aspect-Oriented Programming. Technical Report NUCCIS-04-14, College of Computer and Information Science, Northeastern University, Boston, January 2005.
[30] Meyer, B. Eiffel: The Language. Prentice-Hall, 1991. [31] Meyer, B. Object-Oriented Software Construction (second edition). Prentice-Hall, 1997. [32] Rashid, A., Moreira, A., and Araújo, A. Modularisation and Composition of Aspectual Requirements. 2nd International Conference on Aspect-Oriented Software Development (AOSD‘03), Boston, USA, March 2003. [33] Rashid, A., and Moreira, A. Domain Models are NOT Aspect Free, Proceedings of the International Conference on Models 2006, LNCS 4199, 2006. [34] Rieken, J. Design By Contract for Java - Revised (master thesis), Carl von Ossietzky Universität - Correct System Design Group, April 24th, 2007. [35] Shinotsuka, S., Ubayashi, N., Shinomi, H., Tamai, T. An Extensible Contract Verifier for AspectJ. Proceedings of the 2nd Asian Workshop on Aspect-Oriented Software Development (AOAsia 2), 2006. [36] Skotiniotis, T., and Lorenz, D. Conaj: Generating Contracts as Aspects. Technical Report NU-CCIS-04-05, College of Computer and Information Science, Northeastern University, Boston, March 2004. [37] Stein, D., Hanenberg, S., Unland, R. Modeling Pointcuts. Early Aspects Workshop at AOSD’04, Lancaster, UK, March 2004. [38] Suvée, D., De Fraine, B., and Vanderperren, W. A Symmetric and Unified Approach Towards Combining Aspect-Oriented and Component-Based Software Development. Component-Based Software Engineering (CBSE) 2006, Västerås, Sweden, 2006. [39] Wampler, D. Contract4J for Design by Contract in Java: Designing Pattern-Like Protocols and Aspect Interfaces. Industry Track at AOSD 2006, Bonn, Germany, March 22, 2006. [40] Wampler, D. Aspect-Oriented Design Principles: Lessons from Object-Oriented Design. Sixth International Conference on Aspect-Oriented Software Development (AOSD’07), Vancouver, British Columbia, March 12-16, 2007. [41] Zhao, J., and Rinard, M. Pipa: A Behavioral Interface Specification Language for AspectJ. Proceedings of Fundamental Approaches to Software Engineering (FASE’2003), 2003.
