Checking the Compliance of Timing Constraints in Software ApplicationsThanh-Binh Trinh, Tuan-Anh Do, Ninh-Thuan Truong, and Viet-Ha Nguyen College of Technology, Vietnam National Univers
Trang 1Checking 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
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
con-straints 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,
adap-tive 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
implemen-tation 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
charac-teristics in real-time, embedded systems Designing such
systems requires timing constraints in specification
docu-ments, which are sometimes referred to as critical sections
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 verify-ing 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
2009 International Conference on Knowledge and Systems Engineering
Trang 2to 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
Dia-grams 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
auto-matic teller machine system Section IV discusses related
works We conclude the paper and give some perspectives
in Section V
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
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
ob-ject oriented specification and design UML itself
con-tains 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
em-bedded 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 1 illustrates an
ex-ample 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
cus-tormer’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.
1 http://www.agilemodeling.com/artifacts/timingDiagram.htm
Figure 1 Start Transaction Timing Diagram.
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 modulariza-tion 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
Trang 3ex-ecution of a program In AOP, everything revolves around
joinpoints, since they are the places where the
crosscut-ting 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
exe-cution, 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
III Checking the execution of tasks with
tim-ing constraints
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
specifi-cation 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 2 describes the overall process presented above,
we concentrate on the generation of aspects in AspectJ
(Generator) The generated aspects can extract timing
con-straints 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
check-ing approach does not require programmers to do anythcheck-ing
with their programs The Java checked application can be
given in source code or compiled code and the weaving
Figure 2 Overall checking process.
process can be done at compile time or load time as supported by AspectJ
A Generating Verification Aspects
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 3 We define template aspect in Figure 4 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, advicebefore ():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
Figure 3 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
Trang 4import 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 4 Template for the Verification
As-pects.
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
Composing and translating the above timing constraints to
the logical expressions, and add them as the conditions to
the template in Figure 4 to check if timing execution of
methods satisfy their constraints
B A case study
We use the automatic teller machine (ATM) system
pre-sented 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 5
Figure 6 shows the timing constraints of the
scenario using Timing Diagram Suppose that,
Figure 5 UML Sequence Diagram of the Withdrawal scenario.
in this scenario, the Withdraw( ) method requests to be processed with within {w1,w2}
milliseconds, then Check_BalanceAccount( ),
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 invokeGive_Money( ) within {g1,g2} milliseconds to
give money to users
Figure 6 UML Timing Diagram of the With-drawal scenario.
In addition to the above timing constraints, specification documents of the system require that, the Withdrawal sce-nario processing have to take no longer than milliseconds
and that, the method Check_BalanceATM( ) finishes before the termination of the sequential execution of meth-odsCheck_BalanceAccount( )andReturn( )
Trang 5w 1 ≤ τ(Withdraw) ≤ w2 (1)
b 1 ≤ τ(Check BalanceAccount) ≤ b2 (2)
a 1 ≤ τ(Check BalanceATM) ≤ a2 (4)
g 1 ≤ τ(Give Money) ≤ g2 (5)
τ(Check BalanceATM) ≤
τ(Check BalanceAccount; Return) (6)
τ(Withdraw; ; Give Money) ≤ (7)
Expressing 7 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 min 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){
t 1 = System.currentTimeMillis();
}
after() : (execution(* *.*( )))&& !within(VAspcect){
mn = thisJoinPoint.getSignature(); //get method name;
t 2 = 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 7 Generated Verification Aspects.
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
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 automat-ically 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 real-time 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 do not check the compliance between run-time tasks and timing constraint specification
The paper [6] proposed a method of using Timing Dia-grams to estimate the overloading of the boundary ele-ments 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 com-pliance between implementation and timing constraints in Timing Diagrams
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 do not need to modify the source code We illustrated our approach by a case study of an Automatic Teller Machine system
Trang 6From 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
AOP-based platform for checking the conformity between the
implementation and its specifications
Acknowledgment
This work is partly supported by the research project
No QGTD 09.02 granted by Vietnam National University,
Hanoi
References
[1] Scott W Ambler The Object Primer: Agile Model-Driven
Development with UML 2.0 Cambridge University Press,
New York, NY, USA, 2004
[2] Scott W Ambler The Elements of UML 2.0 Style
Cam-bridge 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.
[4] Grady Booch, James Rumbaugh, and Ivar Jacobson
Uni-fied Modeling Language User Guide, The (2nd Edition)
(Addison-Wesley Object Technology Series).
Addison-Wesley Professional, 2005
[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
[7] Robert E Filman, Tzilla Elrad, Siobh´an Clarke, and
Mehmet Aks¸it, editors Aspect-Oriented Software
Devel-opment Addison-Wesley, Boston, 2005.
[8] Dimitar P Guelev and Dang Van Hung Software
tech-nology reasoning about qos contracts in the probabilistic
duration calculus, 2007
[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
[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
[12] Gail C Murphy, Robert J Walker, Elisa L A Banias-sad, Martin P Robillard, Albert Lai, and Mik A Kersten
Does aspect-oriented programming work? Commun ACM,
44(10):75–77, 2001
[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
[14] Jianlin Shi and Martin An overview of UML2 and brief assessment from the viewpoint of embedded control systems development, 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
[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 Soft-ware Engineering and Formal Methods, pages 382–386.
IEEE Computer Society, 2008
[17] Joachim Wegener and Matthias Grochtmann Verifying timing constraints of real-time systems by meansof
evo-lutionary testing Real-Time Syst., 15(3):275–298, 1998.