2009 International Conference on Knowledge and Systems Engineering Checking the Compliance of Timing Constraints in Software Applications Thanh-Binh Trinh, Tuan-Anh Do, Ninh-Thuan Truong, and Viet-Ha Nguyen College of Technology, Vietnam National University 144 Xuan Thuy, Cau Giay, Hanoi Hanoi, Vietnam Email: binhtt.di07@vnu.edu.vn Abstract It is desirable to be automatically checked as programs are being developed and later maintained Some static analysis methods have been proposed [11], [8] to predict the worst-case and best-case execution times of a task’s code or to estimate the time execution of a piece of source code These methods analyzes the execution paths and simulating processor characteristics without ever executing the program or requiring the program’s input The limitation of static analysis is that, this method is unable to apply to large or complex software systems It can work only with some simple predefined languages In addition, the hardware configuration must be described before using the method Our approach is based on the dynamic checking method in which programs are checked at run-time and the timing analysis is performed when the program is executed; the user can be informed of any potential timing constraint violations This promises to solve the limitations of static analysis approaches In our previous works [15], [16], we have been working on the combination between Aspect Oriented Programming (AOP) and the UML specification in order to verifying the conformity between the implementation and its specification Object invariants and protocol execution of methods are properties of software programs which have been checked using AOP technology This paper continues to propose an approach to dynamic checking a property of real-time software systems, the timing constraints To uniform with the previous works, this paper uses AOP technology to observe the execution of the program and to check if the execution of tasks satisfies their timing constraints Intuitively, timing constraints are specified by UML Timing Diagrams [2], a new diagram of UML 2.0 It enables to express visually timing constraints of tasks in the program using graphical notations This paper contributes an approach allowing to generate verification aspects from UML Timing Diagrams These aspects are then able to be woven to real-time applications in order Timing constraints play an important role in software development, particularly in real time systems This paper proposes an approach for checking the compliance of execution of tasks in an application with their timing constraints In this approach, timing constraints are specified by UML Timing Diagrams Aspect Oriented Programming technology is used to observe the execution of the program and to check if the execution of tasks satisfies their timing constraint specification The approach is illustrated by a case study of an Automatic Teller Machine system I Introduction The enormous expansion in the use of software in every field of life causes increasingly demands on installing and developing reusable, robust, reliable, flexible, adaptive software systems Beside the benefit of software, the damage may be severe if software errors appear in the execution This challenge requires software developers having efficient methods to verify software systems before using them in practice In software development, specification is the process used to describe overview structure and constraints of software systems This process allows stakeholders understanding functions, tasks and activities of the system Based on the specification, programmers then implement the system using programming languages However, as the implementation may be lead to errors with respect to its specification Accordingly, we need some automatic methods to verify if the implementation satisfy its specification Timing constraints are one of the most important characteristics in real-time, embedded systems Designing such systems requires timing constraints in specification documents, which are sometimes referred to as critical sections 978-0-7695-3846-4/09 $26.00 © 2009 IEEE DOI 10.1109/KSE.2009.38 220 to check the compliance of timing constraints between the implementation and UML Timing Diagrams The rest of this paper is organized as follows Section II briefly introduces the background of UML Timing Diagrams and AspectJ Section III presents our contribution, an approach for verifying the conformity of execution of a scenario with timing constraints at runtime And then, applying proposed approach to a case study of an automatic teller machine system Section IV discusses related works We conclude the paper and give some perspectives in Section V Figure Start Transaction Timing Diagram II Backgrounds This section gives an overview about the UML Timing Diagram that we use to specify timing constraints in the proposed approach After that, we introduce AspectJ, a simple and practical aspect-oriented extension to Java B AspectJ AOP has been widely applied to different languages but the most influential implementation is AspectJ [5], [7], [10] AspectJ is a seamless aspect-oriented extension of the Java programming language 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 [12], 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 is executed before the execution of certain methods or exception handlers in a set of classes, 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 ex- A UML Timing Diagram The Unified Modeling Language (UML) [1], [4], [14] is a standard from the Object Management Group (OMG), proposed as a semi-formal specification language for object oriented specification and design UML itself contains several different diagram types for example State Diagrams, Collaboration Diagrams, Sequence Diagrams, Class Diagrams, and many others Timing Diagrams are one of the new artifacts added to UML 2.01 , which are a specific type of interaction diagram, they focus on timing constraints Timing Diagrams are often used to design embedded software, such as control software for fuel injection system in an automobile, although they occasionally have their uses for business software They are used to explore the behaviors of one or more objects throughout a given period of time There are two basic flavors of Timing Diagram, the concise notation and the robust notation Figure illustrates an example of both concise (above) and robust (below) notations of Timing Diagrams of a scenario in the ATM system This scenario can be interpreted as follows Initially, a customer inserts his bank card, then the ATM requests to enter custormer’s Pin number within {r1,r2} seconds The system behaves in two possible ways either: the ATM controller receives a request to cancel the transaction within {c1,c2} seconds, or the ATM receives the customer’s pin number within {b1,b2} seconds If the ATM receives a request to cancel the transaction, it returns the custormer’s card and takes between {e1,e2} seconds If the ATM receives the customer’s pin number, it sends a request to the Bank to validate the Pin number within {v1,v2} seconds http://www.agilemodeling.com/artifacts/timingDiagram.htm 221 ecution 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 The significant advantage of AspectJ is the capabilitity of weaving aspects to a Java program to logging, tracing, observing, throwing exceptions, preventing joinpoint execution, etc Based on these special capabilities, we propose to use AspectJ to check the comformity of timing execution of tasks in a Java program with their timing constraint specification Figure Overall checking process process can be done at compile time or load time as supported by AspectJ A Generating Verification Aspects III Checking the execution of tasks with timing constraints The main steps for generating aspect are summarized as follows • Timing constraints are expressed by UML Timing Diagrams exported to XML Metadata Interchange (XMI) format • Getting a list of methods name and corresponding timing constraints from XMI files to produce aspects in AspectJ • Defining the advices in these aspects that is able to get timing execution of methods in the running application To generate verification aspect from UML Timing Diagram as in Fig We define template aspect in Figure In this template, first, we declare several private variables used to calculate the timing execution when a method is executed We also define two advices of the aspect The first one, advice before():execution, add a command to get the time before executing the method (in milliseconds) The second advice, after():execution, get the time after executing the method The timing execution of the method is measure by the subtraction result of these two moments In this section, we present the main contributions of this paper, an approach to check the execution of tasks in a Java application with their timing constraints The overview of the software development and the integration of our checking approach in this process can be described as follows • In specification documents, tasks in the program have been constrained using UML Timing Diagrams • The program is then implemented using the specification documents • We define rules enabling to generate aspect code in AspectJ containing timing constraints of tasks • Aspects, containing timing constraints and capability of getting time execution of the methods, are then woven to the Java application by AspectJ compiler to get the final program • When the final program is running, the woven codes can detect whether the execution time of a scenarios violate their timing constraints Figure describes the overall process presented above, we concentrate on the generation of aspects in AspectJ (Generator) The generated aspects can extract timing constraints from UML Timing Diagrams and measure timing execution of methods in the application Other phases have been supported by Java and AspectJ compilers Note that, the generated aspect does not affect the tasks execution time of the Java applications Since there is no statements affected by the aspect Furthermore our checking approach does not require programmers to anything with their programs The Java checked application can be given in source code or compiled code and the weaving Figure UML Sequence Timing Diagram This aspect states that when a method is invoked, we can run additional pieces of code before or after executing a 222 import org.aspectj.lang.joinpoint; variables Variables are declared here; aspect AspectName{ before() : (execution(* *.*( ))) && !within(AspectName){ − Get τ1 ; // the current system time; } after() : (execution(* *.*( )))&& !within(AspectName){ − Get τ2 ; // the current system time; − Get method name from XMI flie(task1, task2, ); − Get lower and upper bound on timing from XMI file(r1, r2, ); − τ = τ2 −τ1 ; //Calculate the execution time of the method; if (ξ(τ, r1, r2, ) = false)// Timing constraint conditions; − Produce violation reports; } Figure Template for the Verification Aspects method Suppose that τ (α) is the execution time of the task α If α, β two sequential execution tasks then τ (α; β) = τ (α)+τ (β), and is the upper bound on timing of the sequence tasks We formalize the timing constraints of the scenario that can be checked as follows: • Timing constraints of each task, r1 ≤ τ (α) ≤ r2 Where r1, r2 be the lower and upper bound on timing of the task α • Timing constraints of some sequential tasks executed, τ (α)+τ (β) ≤ • We also check the early accomplishment of parallel tasks: τ (α) ≤ τ (β) In which α, β are two parallel tasks being started at the same time Figure UML Sequence Diagram of the Withdrawal scenario in this scenario, the Withdraw( ) method requests to be processed with within {w1,w2} Check_BalanceAccount( ), milliseconds, then Return( ) and Check_BalanceATM( ) methods are executed in concurrent mode within {b1,b2}, {r1,r2}, and {a1,a2} milliseconds, respectively When both methods Check_BalanceATM( ) and Check_BalanceAccount( ) return true, the ATM will invoke Give_Money( ) within {g1,g2} milliseconds to give money to users Composing and translating the above timing constraints to the logical expressions, and add them as the conditions to the template in Figure to check if timing execution of methods satisfy their constraints B A case study We use the automatic teller machine (ATM) system presented in Section II to illustrate the proposed checking approach Intuitively, the ATM system consists of three components: potential customers that are represented by the object User, the ATM controller which is represented by the object ATM The last component, a host bank represented by the object Bank In the ATM system, we consider the Withdrawal scenario to test with our approach The UML sequence diagram which is used to describe the order execution of methods of the scenario is presented Figure Figure shows the timing constraints of the scenario using Timing Diagram Suppose that, Figure UML Timing Diagram of the Withdrawal scenario In addition to the above timing constraints, specification documents of the system require that, the Withdrawal scenario processing have to take no longer than milliseconds and that, the method Check_BalanceATM( ) finishes before the termination of the sequential execution of methods Check_BalanceAccount( ) and Return( ) 223 w1 ≤ τ (Withdraw) ≤ w2 b1 ≤ τ (Check BalanceAccount) ≤ b2 r1 ≤ τ (Return) ≤ r2 a1 ≤ τ (Check BalanceATM) ≤ a2 g1 ≤ τ (Give Money) ≤ g2 τ (Check BalanceATM) ≤ τ (Check BalanceAccount; Return) τ (Withdraw; ; Give Money) ≤ (1) (2) (3) (4) (5) the design levels but not at the implementation level as in our approach Joachim et al [17] proposed an approach for verifying timing constraints of Real-Time Systems by means of evolutionary testing In this paper, a violation of timing constraints means that outputs are produced too early, or their computation takes too long The task of the tester therefore is to find the input situations with the longest or shortest execution times, in order to check whether they produce a temporal error If the search for such inputs is interpreted as a problem of optimization, evolutionary computation can be used to automatically find the inputs with the longest or shortest execution times This automatic search for accurate test data by means of evolutionary computation is called evolutionary testing This testing approach differs from ours which use AOP to automatically check with timing constraint specification Beside, this approach and ours may be combined to become an efficiently checking H Guo and W Lee [9] proposed a compositional approach to specifying and verifying timing requirements for realtime systems in a systematic manner They specify both requirements and specification of a system using Modular TER nets [13], an extension of TER nets, to support timing analysis in a compositional way However, this paper can only check timing anomalies in requirements and the specification model using the incrementally composition but not check the compliance between run-time tasks and timing constraint specification The paper [6] proposed a method of using Timing Diagrams to estimate the overloading of the boundary elements of the system in the earliest possible stage of system designing It is based only on the Use Case diagrams and some additional information concerning the behavior of the user of the future system The aim of this work is to point out the possibility of using the Timing Diagrams to describe users behavior at the first stage of the system modeling but it is not intended to the checking the compliance between implementation and timing constraints in Timing Diagrams (6) (7) Expressing timing constraints above using AspectJ language and then combining them with the generated aspect in Figure 7, we can check the conformity between the implementation and the timing constraint specification In this aspect, we define two methods getMinConstraint(String methodName)and getMaxConstraint(String methodName) to get the time execution and max time execution of the method from UML Timing Diagram that will be substituted by specific values for each method patterns declared in the specification In addition, we use AspectJ API to report the exact location where the constraint is violated import org.aspectj.lang.joinpoint; variables aspectVAspect{ before() : (execution(* *.*( ))) && !within(VAspcect){ t1 = System.currentTimeMillis(); } after() : (execution(* *.*( )))&& !within(VAspcect){ mn = thisJoinPoint.getSignature(); //get method name; t2 = System.currentTimeMillis(); lb = getMinConstraint(mn); ub = getMaxConstraint(mn); et = t2−t1; //the execution time of the method tt+ = et; //the execution time of sequential methods if (et < lb || et > ub || tt > ) log(thisJoinPoint); } void log(JoinPointjp){ System.out.println(jp.getSourceLocation()+ jp.getSignature()); } Figure Generated Verification Aspects V Conclusion Timing constraints play an important role in real-time and embedded systems In this paper, we proposed an approach for checking the conformity among tasks in Java programs and their timing constraints The timing constrains are specified by UML Timing Diagrams and then translated automatically to monitor code in AspectJ As aspects can monitor the execution of a program from outside so programmers not need to modify the source code We illustrated our approach by a case study of an Automatic Teller Machine system IV Related work Several approaches have been proposed to verify timing constraints in software systems SACRES [3] is a verification environment for embedded systems that allows user to graphically specify properties as Symbolic Timing Diagrams Designs are translated into finite state machines which are optimized and then verified by symbolic model checking This work focused only on 224 From our arguments and experience, we believe that this approach is strong for checking the timing constrains and simple for programmers and tester to implement In the future, we plan to combine this approach with several other works such as checking object invariants, checking protocol execution of methods to develop a AOPbased platform for checking the conformity between the implementation and its specifications [9] Hui Guo and Woo Jin Lee Compositional verification of timing constraints for embedded real-time systems In ACOS’07: Proceedings of the 6th Conference on WSEAS International Conference on Applied Computer Science, pages 570–575, Stevens Point, Wisconsin, USA, 2007 World Scientific and Engineering Academy and Society (WSEAS) [10] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G Griswold An overview of aspectj In ECOOP ’01: Proceedings of the 15th European Conference on Object-Oriented Programming, pages 327– 353, London, UK, 2001 Springer-Verlag Acknowledgment This work is partly supported by the research project No QGTD 09.02 granted by Vietnam National University, Hanoi [11] Frank Mueller and Joachim Wegener A comparison of static analysis and evolutionary testing for the verification of timing constraints In Real-Time Systems, pages 144–154 IEEE, 1998 References [12] Gail C Murphy, Robert J Walker, Elisa L A Baniassad, Martin P Robillard, Albert Lai, and Mik A Kersten Does aspect-oriented programming work? Commun ACM, 44(10):75–77, 2001 [1] Scott W Ambler The Object Primer: Agile Model-Driven Development with UML 2.0 Cambridge University Press, New York, NY, USA, 2004 [13] Paddy Nixon and Lihua Shi Concurrent semantics for structured design methods In Proceedings of the First IFIP TC10 International Workshop on Software Engineering for Parallel and Distributed Systems, pages 158–169, London, UK, UK, 1996 Chapman & Hall, Ltd [2] Scott W Ambler The Elements of UML 2.0 Style Cambridge University Press, New York, NY, USA, 2005 [3] A Benveniste, M Siegel, L Holenderski, K Winkelmann, E Sefton, E Rutten, P Le Guernic, and T Gautier Safety critical embedded systems design: the sacres approach In Formal Techniques in Real-Time and Fault Tolerant systems, FTRTFT’98 school, Lyngby, Denmark, September 1998 [14] Jianlin Shi and Martin An overview of UML2 and brief assessment from the viewpoint of embedded control systems development, 2005 [4] Grady Booch, James Rumbaugh, and Ivar Jacobson Unified Modeling Language User Guide, The (2nd Edition) (Addison-Wesley Object Technology Series) AddisonWesley Professional, 2005 [15] Thanh-Binh Trinh, Anh-Hoang Truong, and Viet-Ha Nguyen Checking protocol-conformance in component models using Aspect oriented programming In Advances in Computer Science and Engineering, pages 150–155 Actapress, 2009 [5] A Colyer and A Clement Aspect-oriented programming with AspectJ IBM Syst J., 44(2):301–308, 2005 [6] Dariusz Dymek and Leszek Kotulski Estimation of system workload time characteristic using uml timing diagrams In DEPCOS-RELCOMEX ’08: Proceedings of the 2008 Third International Conference on Dependability of Computer Systems DepCoS-RELCOMEX, pages 9–14, Washington, DC, USA, 2008 IEEE Computer Society [16] Anh-Hoang Truong, Thanh-Binh Trinh, Dang Van Hung, Viet-Ha Nguyen, Nguyen Thi Thu Trang, and Pham Dinh Hung Checking interface interaction protocols using Aspect-oriented programming In SEFM ’08: Proceedings of the 2008 Sixth IEEE International Conference on Software Engineering and Formal Methods, pages 382–386 IEEE Computer Society, 2008 [7] Robert E Filman, Tzilla Elrad, Siobh´an Clarke, and Mehmet Aks¸it, editors Aspect-Oriented Software Development Addison-Wesley, Boston, 2005 [17] Joachim Wegener and Matthias Grochtmann Verifying timing constraints of real-time systems by meansof evolutionary testing Real-Time Syst., 15(3):275–298, 1998 [8] Dimitar P Guelev and Dang Van Hung Software technology reasoning about qos contracts in the probabilistic duration calculus, 2007 225 ... using the specification documents • We define rules enabling to generate aspect code in AspectJ containing timing constraints of tasks • Aspects, containing timing constraints and capability of. .. handlers in a set of classes, 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... advices in these aspects that is able to get timing execution of methods in the running application To generate verification aspect from UML Timing Diagram as in Fig We define template aspect in Figure