DSpace at VNU: VERIFYING JAVA OBJECT INVARIANTS AT RUNTIME

August 20, 2011 10:46 WSPC/117-IJSEKE S0218194011005281 - SPI-J111 0218-1940 International Journal of Software Engineering and Knowledge Engineering Vol 21, No (2011) 605–619 c World Scientific Publishing Company DOI: 10.1142/S0218194011005281 VERIFYING JAVA OBJECT INVARIANTS AT RUNTIME Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only THU-TRANG NGUYEN Hanoi University of Technology 1, Dai Co Viet, Hai Ba Trung, Hanoi, Vietnam trangntt-it@hut.edu.vn NINH-THUAN TRUONG∗ and VIET-HA NGUYEN† College of Technology, Vietnam National University 144, Xuan Thuy, Cau Giay, Hanoi, Vietnam ∗thuantn@vnu.edu.vn †hanv@vnu.edu.vn Received 10 February 2009 Revised 17 February 2010 Accepted 13 June 2010 An object invariant consisting of a set of properties that must hold for all instances of a class at any time is usually used in object-oriented design However, verifying object invariants at runtime is always a challenging task in software verification This paper proposes a method for verifying invariants of Java objects at runtime using AOP Suppose that a software application is designed using UML models and its constraints are specified in OCL expressions, the software is then implemented, by default, using the UML design They propose to construct verifiable aspects which are automatically generated from OCL constraints These aspects can be woven into Java code to check whether object invariants are violated at runtime Benefiting from AOP in separation of crosscutting concerns and weaving mechanisms, generated aspects can the verification task whenever values of objects’ attributes are changed A Verification Aspect Generator (VAG) tool has been developed allowing the automatic generation of verifying aspects from the UML/OCL constraints Keywords: Software verification; OCL invariant; runtime; AspectJ; AOP Introduction Object-oriented programming has become a dominant programming paradigm in industry with its preeminent style for implementing complex programs including a large number of interacting components Successful implementation of object technology requires a method that integrates a development process and a modeling language with suitable construction techniques and tools The Unified Modeling Language (UML) [16] is a family of graphical notations helping to specify, to visualize, to construct, and to document the artifacts of 605 August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only 606 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen software systems [4] It is used particularly in software systems of object-oriented style The UML represents a collection of best engineering practices that have proven successful in modeling large and complex systems A UML diagram, for instance a class diagram, is typically not refined enough to provide all the relevant aspects of a specification of additional constraints about the objects in the model Practice has shown that describing such constraints in natural language will always result in ambiguities In order to write unambiguous constraints, so-called formal languages have been developed However, traditional formal languages are easily manageable to specialists with a strong mathematical background, but difficult to use for average system modelers The OCL (Object Constraint Language) [14, 27] has been developed to overcome this obstacle The OCL is a textual extension of the UML It promises ease of use, objectorientation and the adaptability of well-known formal analysis methods [15] The OCL allows to describe three principal types of constraints: invariant, precondition and post-condition From the OCL specification, invariants must hold for all instances of a class at any time [14] Indeed, the guarantee of the correctness and quality of software systems is becoming more and more important and considered as the dominant research goal in software engineering In this aspect, one of the most challenging tasks is the verification of object-oriented applications due to their popular efficiency in software development Many papers have dealt with the verification of object invariants in objectoriented applications [5, 7, 19, 22] However, the works reported so far only focused on the invariant verification by reasoning but none of them concerns the execution time of the program With the development of software engineering, Aspect-Oriented Programming (AOP) [23] has emerged as a new methodology This provides a possible separation of cross-cutting concerns by introducing a new unit of modularization as an aspect, which can be woven into the core modules following the weaving rules The power of AOP comes from the economical way in which the weaving rules can be expressed AspectJ [1, 13, 18] is a general-purpose, aspect-oriented extension to the Java programming language In this paper, we propose a method for the verification of the object-invariants correctness at runtime If we use UML/OCL as an object modeling and specifying language for the software system, the UML model is then implemented in Java by programmers We consider the transformation of the OCL constraints in the model to aspects in AspectJ Aspects are then woven to the implemented Java code by the AspectJ compiler to obtain the final program When the final program executes, the woven code can detect whether values of objects’ attributes violate their invariants To automatically apply this method in the practice, we have developed a Verification Aspect Generator tool and called it by the abbreviation VAG This tool accepts as inputs the UML model in an xmi file and the OCL invariants in an ocl file, and it provides verifying aspects specialized in AspectJ as outputs This tool also allows users to save these aspects into aj files, which are then woven into the August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Verifying Java Object Invariants at Runtime 607 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Java application The proposed method and tool can be used in the testing phase of software development, including unit test, integration test, acceptance test, etc to ensure the invariant preservation throughout the program execution This paper is organized as follows Section briefly introduces the background of UML, OCL and AspectJ Section presents our contribution, a method to verify Java object invariants at runtime Implementation of the support tool is presented in Sec Section discusses related works In Sec 6, we conclude the paper and give some future works Background We present in this section an overview of UML/OCL, a language for specifying the structure and constraints of object-oriented applications After that, we give a sketch of AspectJ, a practical aspect-oriented extension to Java 2.1 UML and OCL The Unified Modeling Language (UML) [6] is a standard from the Object Management Group (OMG) [20], proposed as a semi-formal specification language for object-oriented specification and design The Object Constraint Language (OCL) [14, 27] is an attempt to extend the UML by a more formal specification language UML itself contains several different diagrams for example state diagrams, collaboration diagrams, sequence diagrams, etc whereas OCL is a textual specification language, which is suitable for refinement of the UML diagrams by writing constraints on them One of the most important diagrams of the UML is the class diagram, which describes the types of objects in the system and the various kinds of static relationships that exist among them Class diagrams also show the properties and operations of a class and the constraints that apply to the way objects are connected In order to illustrate UML class diagrams and OCL constraints, we give an example of a simple credit banking system This system describes the relationship and activities between a bank and its customers The customers may be companies or persons A customer of a bank (a person or a company) can open one or many credit accounts in the bank A given mortgage is used to secure an arbitrary amount of credit accounts and each credit account must be secured by at least one mortgage This model is specified by a class diagram in Fig with four classes: Person, Company, CreditAccount and Mortgage The OCL expressions typically specify invariant conditions that must hold for the system being modeled or queries over objects described in a model When the OCL expressions are evaluated, they not have side effects (i.e., their evaluation cannot alter the state of the corresponding executing system) In the context of UML class diagrams, OCL is used to describe class invariants, pre-conditions and post-conditions of methods Following the OCL specification [14], invariants must hold for all instances of classifiers at any time The pre-conditions August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 608 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen Mortgage mortgages * −value:double −description:string mortgages * securities * company owner value Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Person CreditAccount −accountNo:long credits −opennedDate:Date −name:string −gender:string −monthlyInterest:double employee * −vbalance:double −age:int −monthlyIncome:double −duration:int −expireDate:Date Company −companyNo:int −name:strin −taxCode:long −address:string credits * company +getBalance():double +deposit(amount:double):void +withdraw(amount:double,feeRate:double):void Fig An example of class diagrams for a method describe the requirements on the program state before the method invocation The post-conditions for a method describe the requirements on the state after the method invocation Further, the concept of associations with multiplicities in UML can be understood as an abbreviation for relations with certain constraints, which can be expressed in OCL It is easy to see that the multiplicity expressed at one end of the association can be converted directly to an invariant at the other end In this paper, we consider to use OCL for specifying Java object invariants and for checking them at runtime The following constraints represent invariants of the classes in the model: (1) The age of a person must be greater than This invariant is shown in Listing Listing A simple invariant for age context Person inv minimumAge : self age > (2) The balance of a credit of a person must be at least 100 USD, and the balance of a credit of a company must be at least 1000 USD These invariants are illustrated in Listing Listing Associated invariants for balance of CreditAccount in P erson and Company context Person inv m i n i m a l A m o u n t P e r s o n : self credits - > forAll ( balance >=100) context Company inv m i n i m a l A m o u n t C o m p a n y : self credits - > forAll ( balance >=1000) August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Verifying Java Object Invariants at Runtime 609 (3) The sum payable of all monthly rates of all credits of a person may not surpass 50% of his/her monthly income and after paying all the rates the Person must have at least 1000 USD available Listing illustrates these invariants Listing Associated invariants for some attributes of CreditAccount in Company Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only context Company inv m i n i m a l A m o u n t C o m p a n y : self credits - > forAll ( balance >=100) inv m i n i m a l I n c o m e : m o n t h l y I n c o m e self credits monthlyRat e * self credits balance - > sum () >=1000 The first OCL constraint, called a simple property, concerns only attributes of one class The last two constraints, called the associated constraints, relate to attributes of some objects in the model The first invariant means that, when the program is executed, for all objects of the Person class, at any time, the value of the age attribute has to be greater than Similarly, the value of the balance attribute of an Account object, which belongs to a Person object is always at least 100 USD Every Account object belongs to a Company class has to be greater than 1000 USD, etc The problem given here is how to verify whether any attribute value of Java objects violates OCL invariants in the model at runtime of the program If there is any violation, the program must take some actions such as logging and/or tracing this violation according to the system requirements 2.2 AspectJ AOP has been widely applied to different languages but the most influential implementation is AspectJ [1, 13, 18] AspectJ is a seamless aspect-oriented extension of the Java programming language [2] that enables clean modularization of these crosscutting concerns An AspectJ compiler produces class files that conform to the Java byte-code specification, allowing any compliant Java virtual machine (JVM) to execute those class files By using Java as the base language, AspectJ passes on all the benefits of Java and makes it easy for Java programmers to understand the AspectJ language The task of integrating the crosscutting concern code and the primary application to run as a complete system is called weaving In AspectJ, the implementation of the weaving rules by the compiler is called crosscutting; the weaving rules cut across multiple modules in a systematic way in order to modularize the crosscutting concerns AspectJ defines two types of crosscutting: static crosscutting and dynamic crosscutting Dynamic crosscutting runs additional code when certain events occur during program execution The semantics of dynamic crosscutting is commonly understood and defined in terms of an event-based model Most of the crosscutting that happens in AspectJ is dynamic Dynamic crosscutting augments or even replaces the execution flow of core program in a way that cuts across modules, thus modifying the system behavior For example, to specify that a certain action be executed before the execution of certain methods or exception handlers in a set of classes, August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only 610 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen simply specify the weaving points and the action to take upon reaching those points in a separate module Dynamic crosscutting includes concepts of joinpoint, pointcuts and advices As a program executes, different events fire These events are called joinpoints Joinpoints are identifiable points such as method calls, constructor invocations, exception handlers, or other points in the execution of a program In AOP, everything revolves around joinpoints, since they are the places where the crosscutting actions are woven in A pointcut is a well-defined location in aspect when it should match the joinpoint so it corresponds with a grouping for specific joinpoints An advice is a piece of method-like code used to define additional behaviors at joinpoints that executes when the application reaches a joinpoint In AspectJ, the advice code can execute at three different places when a joinpoint is matched: before, around, and after the called method While dynamic crosscutting modifies the execution behavior of the program, static crosscutting modifies the static structure of the types (the classes, interfaces, and other aspects) and their compile-time behavior There are four broad classifications of static crosscutting: member introduction (inter-type declaration), typehierarchy modification, compile-time error and warning declaration, and exception softening Inter-type declarations allow programmers to modify the static structure of classes (methods and relationships between classes) The most common function of static crosscutting is to support the implementation of dynamic crosscutting In this paper, we use inter-type declaration to support dynamic crosscutting in : verifying invariants Aspects in AspectJ are then defined in a similar manner as Java classes, but they add joinpoint, pointcuts, advices, inter-type declarations type-hierarchy modification, compile-time error and warning declaration, exception softening and ordinary Java member declarations They are the unit in which crosscutting concerns are modeled in AspectJ With static and dynamic crosscutting, Aspect-Oriented Programming technology is strong enough to any actions: logging, tracing, throwing exceptions, preventing joinpoint execution, etc when a joinpoint is matched Verifying Object Invariants at Runtime In order to check constraint conformance of Java objects at runtime, we propose a verification process summerized as follows (Fig 2) (i) Firstly, designers compose the UML models and OCL constraints from the analysis document (ii) Java source code is then implemented from UML models by developers (iii) We define rules allowing verification aspects to be generated from UML/OCL constraints Advices in these aspects are then woven into the Java application by AspectJ compiler to obtain the final program The weaving process must follow special weaving rules of pointcuts in the aspects The final program now contains pieces of August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Verifying Java Object Invariants at Runtime UML model implement 611 Java codes Final program (self-verifying code) OCL constraints generate AspectJ advices weave Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Fig Verification process overview self-verifying code, which are pieces of normal executable code but they can check invariant violation by themselves at any time during the execution Listing A template for aspect generation privilege d public aspect AspectName { pointcut P o i n t c u t N a m e ( ObjectTyp e obj ): target ( obj )&& set ( A t t r i b u t e T y p e ObjectType attribute ); after ( ObjectType obj ): P o i n t c u t N a m e ( obj ){ // Check if the value of the a t t r i b u t e is c h a n g e d if ( attribute of the object violates invariant condition ) printInfo ; } } Recall that coding phase can be done by developers while weaving phase can be done by AspectJ compiler Therefore, the main problem in our method is how to build verification aspects from UML/OCL constraints In order to generate verification aspects, we have built some templates of aspect for corresponding type of invariant One of these templates is illustrated in Listing Two main phases needed to take into account in the process of automatically generated aspects: OCL Parsing and Aspect Generation 3.1 OCL parsing In order to grasp OCL constraints’ semantics, they must be parsed to a syntax tree Firstly, OCL constraints are used as the input to analyze to make a Concrete Syntax Tree (CST) The CST and UML specification are then transformed to an Abstract Syntax Tree (AST) Finally, this AST is used as the input to generate verification aspects 3.2 Generating verification aspects From the AST input, it is not difficult to get information of OCL constraints from its leaves In detail, from the leaves, we can identify the value of context (corresponding to a class name in UML model), relationship name between classes, attributes of August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 612 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen classes or operators, basic values, and collection operations (such as forAll, select, sum, count ) Two principal kinds of invariant are presented in OCL: Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only • Simple or combined invariants: In the expressions, there are only leaves related to attributes of one class, operators on predefined types (such as +,-,*,/, and, or, implies, etc.) • Associated invariants: In the expressions, there are also leaves related to associations between classes The association ends can be (in 1-1 relationship or 1-end of 1-n relationship) or n (n-end of 1-n relationship) through collection operations After analyzing the AST to get related information about invariant expressions, we can follow our algorithm to generate the verification aspects Whenever the value of any object attribute is changed, it is necessary to check whether it violates OCL invariants or not That means we need to add some pieces of code to verify constraints bound to attributes of an object Therefore, dynamic crosscuts need to be implemented In this context, static crosscuts are used to support dynamic crosscuts in some particular cases In order to determine when values of attributes are changed, pointcuts are defined to specify where the joinpoint in the core module is Since invariants are bound to attributes of objects, which are data members of a class, the joinpoint must be field write access joinpoint [18] That means, whenever and wherever field assignment occurs, the joinpoint will be matched and advices of the matched pointcut will be executed to verify this change Advices contain pieces of code for checking invariants, which are inserted before or after setting new value to attributes 3.2.1 Simple/combined invariants To verify simple or combined invariants,a we use just dynamic crosscuts Each attribute in a simple/combined invariant corresponds to a pointcut statement For this pointcut, there must be pieces of verification code that are advices to check if the new value of this attribute satisfies the OCL invariants If the invariant expression is violated, some loggings should be given such as the invariant violation or other information of related objects For the logging purpose, to get any attributes’ value of related objects, the generated aspect should be declared as privileged That means the aspect can access directly any attributes of objects regardless of their access modifiers Listing A sample aspect for a simple invariant privilege d public aspect P e r s o n V e r i f i e r { pointcut p c _ v e r i f y _ a g e _ P e r s o n ( Person obj ): target ( obj )&& set ( int Person age ); a Combined invariants combine several simple invariants concerning only attributes of one class August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Verifying Java Object Invariants at Runtime 613 after ( Person obj ): p c _ v e r i f y _ a g e _ P e r s o n ( obj ){ // Check after the value of age is c h a n g e d if (!( obj age >0)) p r i n t D y n a m i c J P I n f o ( t h i s J o i n P o i n t ); p r i n t S t a t i c J P I n f o ( t h i s J o i n P o i n t S t a t i c P a r t ); } private void p r i n t S t a t i c J P I n f o ( JoinPoint StaticPart sp ){ S o u r c e L o c a t i o n sl = sp g e t S o u r c e L o c a t i o n (); System out println ( " Source location : " + sl getFileNa m e () + " : " + sl getLine ()); } private void p r i n t D y n a m i c J P I n f o ( JoinPoint jp ){ } } Let us consider again the combined invariant in Sec 2.1 In order to check these invariants of the Person class, we have to verify the invariant expression whenever the value of the age attribute is changed A pc_verify_age_Person pointcut should be declared for the set(int Person.age) field write access joinpoint In general, an after advice is declared and implemented to perform verification tasks That means whenever the age attribute of the Person object is set anywhere, the joinpoint is matched and the after advice then is executed To illustrate our solution that is described above, we present a sample code fragment for a simple case in Listing 5, according to the template presented in Listing These above source code checks if the age attribute of Person objects is not satisfied invariant “age > 0” when then the system will print out some loggings Similarly, we can check other simple or combined invariants that relate only attributes of one class 3.2.2 Associated invariants Associated constraints contain the relation between objects appearing in OCL statement In the example in Sec 2.1, the OCL invariant in Listing shows the relation between a person/company and its credit accounts Generally, the relation between a composition class and a part class is implemented as references to objects of the part class in the composition class The objects of the part class is considered as attribute values of the composition class In the example, a person/company may be associated with several credit accounts Credit account is thus expressed as an attribute of the Person/Company class Listing shows an example the Person class in which the association is implemented as a Collection of CreditAccount ) objects Listing Association in the Person class public class Person { private int PersonNo ; // August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 614 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only private Collection < CreditAccount > credits = new ArrayList < CreditAccount >(); public void setCredits ( Collection < CreditAccount > credits ){ this credits = credits ; } public boolean a d d C r e d i t A c c o u n t ( C r e d i t A c c o u n t cc ){ return credits add ( cc ); } public boolean r e m o v e C r e d i t A c c o u n t ( C r e d i t A c c o u n t cc ){ return credits remove ( cc ); } // } In this case, the association is only kept in the Person, not in CreditAccount If a before advice is used to verify the balance attribute of CreditAccount objects as the case of simple/combined invariants, the advice will be executed whenever the value of the balance attribute is changed regardless of the owner of the CreditAccount However, the OCL invariant in Listing assert that the balance of a person should be at least 100 USD while the balance of a company should be at least 1000 USD Therefore, it is necessary to know who owns the credit card, a person or company, to check the right invariant Here, we can maintain the relation inside the CreditAccount object by creating a reflecting reference (called a reflector) — Person object — to the CreditAccount In AspectJ, this task can be done by static crosscuttings with inter-type declarations: Declaring a personReflector and a companyReflector in an aspect but for CreditAccount class The PersonReflector declared for the CreditAccount is the reflector of the Person who owns the credit account Therefore, this PersonReflector of the CreditAccount needs to be updated whenever any object of the CreditAccount collection in the Person is changed This update can be done by pointcuts for addCreditAccount(CreditAccount) method, removeCreditAccount(CreditAccount) method, and credits field write access with after advices These pointcuts and advices are illustrated in Listing In these advices, we also need to check the invariant conformation for any changed object Listing A sample pointcut to update the reflector // In the C r e d i t A c c o u n t V e r i f i e r aspect pointcut p c _ v e r i f y _ s e t _ c r e d i t s _ P e r s o n ( Person obj1 , Collection < CreditAccount > obj2 ): target ( obj1 ) && args ( obj2 ) && set (* Person credits ); after ( Person obj1 , Collection < CreditAccount > obj2 ): p c _ v e r i f y _ s e t _ c r e d i t s _ P e r s o n ( obj1 , obj2 ){ for ( C r e d i t A c c o u n t objTemp : obj2 ){ if (!( objTemp balance >100)){ objTemp s e t P e r s o n R e f l e c t o r ( obj1 ); objTemp s e t C o m p a n y R e f l e c t o r ( null ); // Do l o g g i n g for the i n v a r i a n t v i o l a t i o n August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Verifying Java Object Invariants at Runtime 615 } Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only } } pointcut p c _ v e r i f y _ a d d _ c r e d i t s _ P e r s o n ( Person obj1 , C r e d i t A c c o u n t obj2 ): target ( obj1 ) && args ( obj2 ) && execution (* Person a d d C r e d i t A c c o u n t ( C r e d i t A c c o u n t )); after ( Person obj1 , C r e d i t A c c o u n t obj2 ): p c _ v e r i f y _ a d d _ c r e d i t s _ P e r s o n ( obj1 , obj2 ){ obj2 s e t P e r s o n R e f l e c t o r ( obj1 ); obj2 s e t C o m p a n y R e f l e c t o r ( null ); if (!( obj2 balance >100)){ // Do l o g g i n g for the i n v a r i a n t v i o l a t i o n } } // Do the same to update c o m p a n y R e f l e c t o r Implementation We have implemented an aspect generator called Verification Aspect Generator (VAG), which accepts OCL constraints (.ocl files) and UML model (.xmi files) as the inputs The output of this tool is the corresponding verification aspects, which can be woven to the Java program implemented from the UML model in order to check OCL constraints of Java objects at runtime Figure shows the structure of AVG tool that contains two main modules: OCL Parser and Aspect Generator 4.1 OCL Parser The OCL Parser module in our tool is extended from the Dresden OCL Toolkit [17], which is developed by Software Technology Group at Dresden University of Technology This toolkit is reengineered according to the new requirements of the revised and approved specification of OCL [14] Fig Structure of VAG tool August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only 616 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen To process models with OCL constraints, it is necessary to obtain textual constraints from user inputs or from a file and convert it into a tree-like data structure for further processing The inputs of this module are OCL constraints and UML model Users can type the OCL constraints directly on the tool’s editor or browse an ocl file that contains the input OCL invariants Users also can import an xmi file, which represents the UML model The XML Metadata Interchange (XMI) is an OMG standard for exchanging metadata information via XML After importing ocl and xmi files, users can see the parsing result that is an AST, our tool provides a visual AST explorer This is our extension to the Dresden OCL Toolkit 4.2 Aspect generator In our implementation, we get OCL constraints from the AST analyzing results including context values, invariant names (if any) and invariant expressions with collection operations as well as the relationship between classes, attributes of classes We can also distinguish simple/combined invariants from associated invariants Given types of OCL invariants, we have developed templates for aspect generation These templates include fixed parts, which are the same for every aspect and alternative parts ($ $), which change for each specific invariant These alternative parts will be replaced with corresponding values from the AST We have developed many templates for aspect heads, add reflectors, pointcuts for updating reflectors, pointcuts for associations with, pointcuts for attributes, pointcuts for condition checking (in several cases: simple invariants, simple invariants, associated invariants with collection operations), loggings, aspect functions, etc Related Works Concerning the verification and validation of object-oriented applications with model constraints, many approaches have been proposed [7, 12, 21, 24, 26] Dresden OCL Toolkit [24] developed by Software Technology Group at Dresden University of Technology contains seven different modules Some of them try to validate or support the correctness of OCL constraints against the model The module OCLTypeChecker [10] checks type correctness of OCL expressions and offers type information towards other modules It only validates the OCL expressions against the model, not at runtime Two other modules, OCLInjector4Java [28] and OCL2SQL [11] try to ensure the correctness of OCL constraints in the development phase OCLInjector4Java generates wrapper methods for all methods that have to be checked in compliance with specified OCL constraints during execution OCL2SQL generates an SQL constraint check, assertion or trigger for OCL invariants However, this approach supports developers in the coding phase, while our method supports testers in the verification phase Richters et al [21] present an approach that allows the analysis and validation of UML models and OCL constraints They focus on models and constraints specified August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Verifying Java Object Invariants at Runtime 617 in the analysis and early design stage of a software development process For this purpose, a suitable subset of UML corresponding to the information that is usually represented in class diagrams is identified and formally defined This basic modeling language provides a context for all OCL constraints In order to demonstrate the practical applicability of their work, they have realized substantial parts of it in a tool named USE which supports the validation of models and constraints Design specifications can be executed and animated thus providing early feedback in an iterative development process This approach offers a way for checking user data against specifications, for automating test procedures, and for checking CASE tools for standards conformance Paper [12] studies the testing and certification of UML and OCL models as supported by the validation tool USE It extends the available USE features by introducing a language for defining properties of desired snapshots and by showing how such snapshots are generated In this approach, it is possible to take into account test cases and validation cases Test cases show that snapshots having desired properties can be constructed Validation cases show that given properties are consequences of the original UML and OCL model Brucker et al [7] propose an approach for checking OCL constraints in distributed component based systems In JavaBeans, controlling direct access to attributes is technically not feasible They propose to use accessor methods for checking invariants at, before, and after a method call, e.g through wrapping One of the famous projects relating to runtime verification is MonitoringOriented Programming (MOP) [8] It is a software development and analysis framework aiming at reducing the gap between formal specification and implementation In MOP, runtime monitoring is supported and encouraged as a fundamental principle for building reliable software: monitors are automatically synthesized from specified properties and integrated into the original system to check its dynamic behaviors during execution When a specification is violated or validated at runtime, user-defined actions will be triggered, which can be any code from information logging to runtime recovery However, this project concentrate on logic constraints while our approach uses UML notations attached with OCL constraints as a specification language, which are largely used in software development Paper [9] proposed to develop a unified framework for visible-state verification techniques for object invariants The specification and verification of this approach is based on the type system Contrary to our approach, Paper [25] supposes that an object’s invariant will be broken at some points in its lifetime, and as a result, invariant protocols have been suggested, which prescribe the times at which object invariants may be broken, and the points at which they have to be re-established Invariant protocols in this case express programmers’ intuitions, leading to better design, and allowing more succinct specifications and proofs In summary, different from the above approaches, our approach addresses the verification of objects at runtime of the program Object invariants in the approach August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 618 0218-1940 00528 T.-T Nguyen, N.-T Truong & V.-H Nguyen can be verified at any time and anywhere that the value of an attribute is changed, while checkers based on pre- and post-conditions can check only invariants before and after the execution of a method or constraints bounded to attributes through mutator methods (“set” method) Our approach can even check object attributes that have no mutator methods through field write access joinpoints of AspectJ This also makes our approach different from other verification approaches Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Conclusions In this paper, we have proposed a method for verifying object invariants during the execution of a program using AOP This method gives a desirable and natural way to guarantee the correctness of object-oriented applications written in Java with respect to their UML/OCL constraints Our method is based on UML/OCL, a specification language used to design object-oriented applications Relying on the UML/OCL, on one hand programmers develop Java programs with an unchecked code, and on the other hand, we provide a method to generate verifying aspects in AspectJ following our defined rules The verifying aspects are then woven to the unchecked code to get the final program Using it we can find violations to specified object invariants The proposed method can be applied in practice in testing phases of software development We have developed a tool called VAG (source code and a case study can be downloaded in [3]) that can observe and test some simple invariants violation of a object-oriented program at runtime For the next, we will extend our approach and tool to handle with some types of such complex invariants like the ones for inheritance relationship in object-oriented programming Acknowledgements This work is partly supported by the research project #102.02-2010.06 granted by NAFOSTED Vietnam References http://www.eclipse.org/aspectj http://www.java.sun.com http://fit.hut.edu.vn/˜trangntt/ToolforInvariantVerification.rar M Abadi and L.Cardelli, A Theory of Objects (Springer, 1996) M Barnett, R DeLine, M Fahndrich, K Rustan, M Leino and W Schulte, Verification of object-oriented programs with invariants (2003) G Booch, J Rumbaugh and I Jacopson, The Unified Modeling Language User Guide (Addison-Wesley, 1998) A Brucker and B Wolff, Checking OCL Constraints in Distributed Component Based Systems, Technical report, Institut fă ur Informatik Albert Ludwigs University at Freiburg, Germany (2001) F Chen and G Ro¸su, MOP: Reliable software development using abstract aspects, 2006, Technical report UIUCDCS-R-2006–2776 August 18, 2011 9:27 WSPC/117-IJSEKE - SPI-J111 0218-1940 00528 Int J Soft Eng Knowl Eng 2011.21:605-619 Downloaded from www.worldscientific.com by TEXAS CHRISTIAN UNIVERSITY on 02/05/15 For personal use only Verifying Java Object Invariants at Runtime 619 S Drossopoulou, A Francalanza, P Mă uller and A J Summers, A unied framework for verification techniques for object invariants, in ECOOP ’08: Proceedings of the 22nd European Conference on Object-Oriented Programming (Springer-Verlag, 2008), pp 412–437 10 F Finger, Design and Implementation of a Modular OCL Compiler, PhD thesis, Dresden University of Technology (2000) 11 B D F Heidenreich and C Wende, A Framework for Generating Query Language Code from OCL Invariants, in 7th OCL Workshop at the UML/MoDELS Conferences, 2007 12 M Gogolla and M Richters, Validation of UML and OCL models by automatic snapshot generation, in Proceedings of the 6th Int Conf Unified Modeling Language (UML 2003) (Springer, 2003), pp 265–279 13 J D Gradecki and N Lesiecki, Mastering AspectJ Aspect Oriented Programming in Java (John Wiley, 2003) 14 O M Group, UML OCL2 Specification, Object Management Group (2005) 15 M G Hinchey and J P Bowen, Applications of Formal Methods (Prentice Hall, 1995) 16 J Jackson, Inside the UML, Object Management Group (1999) 17 A Konermann, The Parser Subsystem of the Dresden OCL2 Toolkit: Design and Implementation (2005) 18 R Laddad, AspectJ in Action: Practical Aspect Oriented Programming (Manning Publications, 2003) 19 J W Nimmer and M D Ernst, Static verification of dynamically detected program invariants: Integrating Daikon and ESC/Java, in Proceedings of RV’01, First Workshop on Runtime Verification, Paris, France, 2001 20 OMG, Unified Modeling Language, OMG http://www.omg.org/docs/formal/03-0301.pdf, Version 1.5 (March 2003) 21 M Richters, A Precise Approach to Validating UML Models and OCL Constraints, PhD thesis, Universită at Bremen, Logos Verlag, Berlin, BISS Monographs, No 14 (2002) 22 K Rustan, M Leino, and P Muller, Object invariants in dynamic contexts, in ECOOP: European Conference on Object-Oriented Programming, Vol 3086 (2004), pp 95–108 23 E B S Clarke, Aspect-Oriented Analysis and Design: The Theme Approach (AddisonWesley Professional, 2005) 24 O C Suite, Implementation of an OCL compiler and code generator for Java, http://dresden-ocl.sourceforge.net/ 25 A J Summers, S Drossopoulou and P Mă uller, The need for exible object invariants, in IWACO ’09: International Workshop on Aliasing, Confinement and Ownership in Object-Oriented Programming (ACM, 2009), pp 1–9 26 N T Truong and J Souqui`eres, Validation of UML static diagrams using B, in International Conference on Software Engineering Research and Practice — SERP’05 (CSREA Press, 2005) 27 J Warmer and A Kleppe, The Object Constraint Language: Precise Modeling with UML (Addison-Wesley, 1999) 28 R Wiebicke, Utility Support for Checking OCL Business Rules in Java Programs, PhD thesis, Dresden University of Technology, 2000  ... execution, etc when a joinpoint is matched Verifying Object Invariants at Runtime In order to check constraint conformance of Java objects at runtime, we propose a verification process summerized as follows... simple or combined invariants that relate only attributes of one class 3.2.2 Associated invariants Associated constraints contain the relation between objects appearing in OCL statement In the example... invariant violation or other information of related objects For the logging purpose, to get any attributes’ value of related objects, the generated aspect should be declared as privileged That means