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 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 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 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 List of Tables 2.1 Component characteristics 2.2 2,4 Enterprise Beall Types The diagrams of ƯML 2.0 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 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 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 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 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 ... available, then the component will not work Requires interfaces are indicated bv a semi-circle at the end of a line from the component icon Requires interface Defines the services from the component. .. provide the following files: • Enterprise Beall class: Implements the methods defined in the business inter­ face and any life cycle callback methods; • Business Interfaces: The business interface... 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