Luận văn thạc sĩ VNU UET checking the comformance between the implementation and PSM specifications in component models

Checking the Conformance between the Im plem entation and PSM Specifications in Com ponent M odels Pham Van Viet Faculty of Information Technology College of Technology Vietnam National University, Hanoi Supervised by Dr Truong Ninh Thuan A thesis subm itted in fulfillm ent of the requirements for the degree of Master of Inform ation Technology December, 2009 ĐẠI HỌC QUỐC GIA HÀ N Ộ I TRUNG ТЛМ THÕNG TIN THƯ VlEN LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Table o f C ontents In tr o d u c tio n 1.1 M otivation 1.2 O bjectives 1.3 C on tribu tions 1.4 Thesis stru cture Background 2.1 2.2 2.3 2.4 Software verification and v a lid a tio n 2.1.1 D e fin itio n 2.1.2 Benefits of software v e rific a tio n 2.1.3 Intermediate program representation Component-based software engineering 2.2.1 A ll over vieพ 2/2.2 Component 2.2.3 Component model Three-tier architectures and Е Л В 10 2.3.1 Three-tier architecture 2.3.2 Java EE architecture 10 12 2.3.3 Enterprise B e a n s 13 ƯML S p e cifica tio n 16 2.4.1 An overview 16 2.4.2 General elements of Ư M L 16 2.4.3 Protocol State Machine 18 C hecking consistency between the im ple m en tatio n and P S M spec­ ific a tio n 20 3.1 Transforming PSM to a graph expression 20 3.2 Generating the CFG from Bytecodestream s .23 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com TABLE OF CO NTENTS 3.3 Converting CFG to Call Graph ( C G ) 26 3.4 Algorithm to check the conformance betweentwo g p h s 27 Im p le m e n ta tio n 29 4.1 Architecture of the support t o o l 29 4.2 Difficulties in the implementation of thesupport t o o l 31 4.2.1 How to generate bytecode stream? 31 4.2.2 How to find the set R in Algorithm 3, line 7? 4.3 32 4.2.3 Difficulties in building module P S M E d ito r 32 Analysis and evaluation 34 Related W o rk 35 Conclusion and F uture w ork 38 6.1 G.2 Conclusion 38 Future work .39 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com List of Figures *2.1 Verification and Validation p ro c e s s 2.2 Component interfaces 2.3 The basic elements of component model 2.4 Three-tier A rchitecture .11 2.5 Java EE Server and C o n ta in e rs 13 2.6 A Class D ia g m 17 2.7 A Protocol State M a c h in e 19 3.1 XM I form of PSM Specification 22 3.2 Source code of the method e x e c u te 24 3.3 The bytecode stream of execute method 3.4 3.5 CFG of the method e x e c u le () 27 The reduced graph of CFG of executemethod 28 4.1 The architecture of the support to o l 30 4.2 Support to o l 31 4.3 Generating Bytecode stream by c o d e 32 4.4 Writing data to XM L file 33 10 *25 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com List of Tables 2.1 Component characteristics 2.2 2,4 Enterprise Beall Types The diagrams of ƯML 2.0 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chapter Introduction 1.1 Motivation The enormous expansion in the use of software in every field of life makes demands of installing and developing reusable, robust, reliable，flexible, adaptive software system much accelerating As these demands are growing stronger, the complex­ ity of processes that software manages is increasing aloĩig with the demand for the integration of processes from different areas As a result, software programs are becoming increasingly large and complex The main challenge for software developers today is to cope with complexity and to adapt quickly to change Component-based software engineering (CBSE) (Crnkovic, 2002) and three-tier architecture (Ramirez, 2000) address this challenge of the software development by proposing an easy and effic ient method for developing large softwares The basic approadi of component-based development (CBD) is to build systems from well-defined, independently produced pieces However, the interesting aspects of CBD concern how this approach is realized to allow components to be devel­ oped as appropriate cohesive units of functionality, and to facilitate the design and assembly of systems from a mix of newly and previously developed components CBD extends the ideas of module-based, emphasizing the design of solutions in terms of pieces of functionality provisioned as components, accessible to others only through well-defined interfaces, outsourcing of the implementation of many pieces of the application solution, and focusing on controlled assembly of components using interface-based design techniques Moreover, three-tier architecture is a client-server architecture in which the user LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 1.1 M o tiv a tio n interface, functional process logic (business rules), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms Typically, the user interface run on a workstation and use a standard graphic user interface, functional process logic may consist of one or more separate modules running on a workstation or an application server, and an RDBMS on a (ỉatal)ase server contains the computer data storage logic This architecture meets the requirements of software: modifiability, available (Helal et al., 2001; Fernandez et al., 2008) A combination of CBSE and three-tier architecture can meet these above re­ quirements, and Enterprise JavaBeans technology is a specific case Enterprise JavaBoans is the server-side component architecture for Java platform, Enterprise Edi­ tion (JavaEE) (Jendrock et al., 2006) It enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java tech­ nology The core of a JavaEE application is comprised of one or several enterprise beans that perform the application's business operations and encapsulate the busi­ ness logic of an application Other parts of the JavaEE platform, such as the JSP, complete the EJB architecture to provide such functions as presentation logic and client interaction control logic In this application model, the application client runs on a client machine, it di­ rectly access enterprise beans running in the business tier Therefore, problems could arise in the system if components contain some implicit errors or the implementa­ tion does not (Xmform to the component's specification, this can lead transitionally to errors in other components Verifying the correctness of components thus is an important task ill component-based software development In order to specify component models, developers usually associate protocol state machine (PSM), a new diagram in UML 2.0 (OMG, 2005) into interfaces of compo­ nents PSM specifies which operations of the interfaces can be called in which state and under which condition, thus specifying the allowed call sequence on the interface methods A PSM presents the possible and permitted transitions on the instances of its context, classifier, together with the operations that carry the traiisitions Software requirements and specifications must be implemented by source codes of a programming language Intuitively, we check the conformance of order of event execution in the source code with its specifications However, this method may be difficult because the calling between methods can be made ill different component and that we may be not possible read source code as components are black boxes LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 1.2 O b je c tiv e s 1.2 Objectives This thesis aims at checking the conformance between the implementation and the PSM specification in component models, particularly in EJB The following are specific objectives that we will study： • Study component-base software engineering, individually Enterprise JavaBcan^ • Study UML specification，especially Protocol State Machine, • Learn about Java bytecode and its role in program implementation, • Propose an approach for checking the conformance between the implementa­ tion and PSM specification, • Design and implement a support tool based on the proposed approach 1.3 Contributions In this thesis, our main contribution is to propose an approach for checking the conformance between the implementation and PSM specification of a component This approach can be summarized by three steps as the following: • Transforming the sequence execution of methods extracted from bytecode of the implementation into a Call Graph, • Transforming the internal specifications of component interfaces expressed by protocol state machines (PSM) into a graph-based model, • บ $ing a graph-ЬазесІ algorithm to check the conformance between two above graphs Moreover, we have built a support tool allow us to graphically specify PSM specification and check automatically if the implementation and the specification are conformable 1.4 Thesis structure H ie remainder of this thesis is organized as follows LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 1.4 T h e s is s tr u c tu r e • Chapter briefly introduces software verification and validation, componentbased software engineering, three-tier architecture and Enterprise Ja\aBean$ (EJB), and ƯML specification • Chapter presents the main approach which is used to check the conformance between the implementation and PSM specification • Chapter gives the detail and some difficulties of the implementation of sup­ port tool • Chapter fiiscusses our approach in comparison with othor works • Chapter ช gives our coiiclusion of the thesis arul some suggestions for the futuri works LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chapter Background 2.1 Software verification and validation Verification and validation (V&V) (Sommerville，2006) is one of the software engi­ neering disciplines that help build quality into software This section explains what it is, some benefits of it, and presents about using language-independent intermedi­ ate software representation, one of the principles of program analysis 2.1.1 D efinition During and after the iinplementation process, the program being developed nmst be checked to ensure that it meets its specification and delivers the expected function­ ality Software verification involves evaluating software during each life cycle phase to ensure that it meets the requirements set forth in the previous phase It aaswers the question: 7iAre we building the product right?1' (Sommerville, 2006) Software verification is often confused with software validation Validation in­ volves testing software for its specification at the end of the development efort to ensure that it meets its roquirements (that it does what it is supposed to) It answers the question: M re we building the right product?” Software verification and validation are tightly integrated with software devel­ opment process (Fisher, 2006) For each activities ill the software development process, there is a corresponding software verification and validation activity :o ver­ ify or validate the products of activities Figure 2.1 represents a ” V-chart” (Eoehm, 1984) which shows the context of verification and validation activities throughout the software life cycle LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com C hapter Im plem entation Based on the approach mentioned above, we implemented a support tool and con­ ducted experiments During the implementation process, we encountered some tech­ nical difficulties as well as difficulties in algorithms Finally, we also found out the solution In this chapter, we present ail overview of the support tool difficulties in the implementation process, and some experimental results with this tool 4.1 Architecture of the support tool Figure 4.1 describes the architecture of the support, tool, inclviding modules with the corresponding function as follows: • P ro to co l S tate M achine E d ito r: Allows users to build PSM Specification of a component visually, the result is stored in a XM L file This module also allows us to load a specification file to continue specifying • P ro to co l S tate M achine Reader: Reads information from the XM I file to builci the graph expression associated with it The result will be used for the next module • G raph C onverter: Module PSM Reader generates a graph expression where each edge represent a method call Module Graph Converter will convert it into another form where every vertex as a method call and an edge between two vertices represents an order of method calls • B ytecode G e n e to r ：Reads the contents of the Java executable file (file 29 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 4.1 A r c h ite c tu r e o f th e s u p p o r t t o o l 30 class) and generate the corresponding bytecode stream in the form of text file (see Figure 3.3), making the bytecode manipulation becomes more convenient • C o n tro l Flow G ph M aker: The bytecode stream is unstructured control flow This module transforms it into a graph expression to easily represent all paths that might be traversed during execution of a method • C o n tro l Flow G ph R educer ：Obtain a graph of a CFG, this module removes vertices that are not method call instructions and ensure the order of methods calls as the original • C onform ance Checker: Checks if two graph are conformable If false, it output list of all invalid call sequences Figure 4.1: The architecture of the support tool Figure 4.2 is the interface of our support tool It consists of two two tabs: the first tab allows us to check the conformance between the implementation and PSM LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 4.2 D iffic u ltie s in th e im p le m e n ta tio n o f th e s u p p o rt t o o l _ 31 specification, and the second tab allows us specify PSM specification of a component visually The name of second tab is the name of the component Figure 4.2: Support tool 4.2 Difficulties in the implementation of the sup­ port tool 4.2.1 How to generate bytecode stream? Tile Java Development K it (JDK) has a program that allows us to disassemble a class file, namely javap (The Java Class File Disassemble) To obtain the result of this program and save it to a file for processing later, we use the pipeline mechanism that is available in most operating systems For example, when performing the command ” javap -c Hello > a.ouť，from the shell of an operating system, the file Hello.class w ill be disassembled and the result will be stored in a file named a.out To execute a shell command ỈỈ1 Java program, we invoke method R untim e ехеб( S trin g command) For example，to execute a shell command ”javap -c Hello > a.out” in Java program, we call R u n t im e ) exec(rjava -с Hello > LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 32 4.2 D iffic u ltie s in th e im p le m e n ta tio n o f th e s u p p o r t t o o l a.cmt” ) However, this instruction does not generate file a.out as executed in the shell How we solve this problem? To solve this problem, we control the process that created by execute0 method The R un tim e, execf) methods create a native process and return an instance of a subclass o f Process th a t can be used to control the process and obtain inform ation about it The class Process provides methods for performing input from the process, performing output to the process, waiting for the process to complete, checking the exit status of the process, and destroying (killing) the process Figure 4.3 illustrates a piece of Java code solving this difficulty E g : j a v a p Hello P r o c e s s p r o c =ะ R u n t i m e g e t R u n t i m e ( ) e x e c ( c o m m a n d ) ; / / —с i ท p i i t F i 1e — n e w B u f f e r e d R e a d e r ( n e w I n p u t S t r e a m R e a d c r ( p r o c g c t l n p u t S t r e a m ( ) ) ) ; o u t p u t F i le = n e w B u f f e r e d W r i t e r ( n e w F i l e W r i t e r ( o u t F i l e n a m e ) ) ; S tring lin e ; w h i l e ( { l i n e ะ= i ท p u t F i l c r e a d L i n e ( ) ) o u t p u t F ile w r i t e ( l i n e ) ; o u t p u t F i le n e w L in c ( ) ; in p u t P ile close ( ) ; о น t p u t F i 1e c l o s e ( ) ; c a t c h ( I О E xcept ion e ) / / !=ะ n u l l ) { , } { Process Exception h e r e , Figure 4.3: Generating Bytecode stream by code 4*2-2 How to find the set R in A lg o rith m 3，lin e 7? Given G is the graph of a CFG, and a vertex V in Ư We need to find the set of method invocation vertices that are neighbours of V (including invocation) This is a difficult problem because the next of V V if V is a method can be a multi-level branch instruction A branch instruction is called multi-level branch instruction if one of its target is another branch instruction We propose an algorithm (see Algorithm 5) to solve this problem This is a recursive algorithm 4*2.3 D ifficulties in b u ild in g m odule P S M E d ito r PSMEditor module allows users to build the PSM specification of a component through graphical objects, the result is stored into a file in X M L format The LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 4.2 D iffic u ltie s in th e im p le m e n ta tio n o f th e s u p p o r t to o l 33 A lg o rith m Finding next, method invocations N e x tM e th o d s (r) ะ 1：Initialize M ะ= 2：i f is h i ethodl nvocation(v) then 3： M ^ (Л / บ v) 4： else 5： Nb = n e ig h b o u rsO f{v) {Set of neighbours o f vertex I/} 6： 7： for each ท e Nb Л/