Tài liệu 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 1 2 In tr o d u c tio n 1.1 M otivation............................................................................................ 1 1.2 O bjectives............................................................................................. 3 1.3 C on tribu tions....................................................................................... 3 1.4 Thesis stru cture.................................................................................... 3 Background 2.1 2.2 2.3 2.4 3 1 5 Software verification and v a lid a tio n .................................................... 5 2.1.1 D e fin itio n ................................................................................... 5 2.1.2 Benefits of software v e rific a tio n ................................................ 6 2.1.3 Intermediate program representation ....................................... Component-based software engineering.............................................. 6 7 2.2.1 A ll over vieพ ................................................................................ 7 2/2.2 Component.................................................................................... 8 2.2.3 Component model .................................................................... Three-tier architectures and Е Л В ....................................................... 9 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 4 3.3 Converting CFG to Call Graph ( C G ) ................................................. 26 3.4 Algorithm to check the conformance betweentwo g ra 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 5 Related W o rk 35 6 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 ................................................. .. 6 2.2 Component interfaces............................................................................ 9 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 ra 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 1 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.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 2 briefly introduces software verification and validation, componentbased software engineering, three-tier architecture and Enterprise Ja\aBean$ (EJB), and ƯML specification. • Chapter 3 presents the main approach which is used to check the conformance between the implementation and PSM specification. • Chapter 4 gives the detail and some difficulties of the implementation of sup­ port tool. • Chapter 5 fiiscusses our approach in comparison with othor works. • Chapter ช gives our coiiclusion of the thesis arul some suggestions for the futuri works. Chapter 2 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. 2.1. S o ftw a re v e r ific a tio n a n d v a lid a tio n 6 Figure 2.1: Verification and Validation process 2.1.2 B enefits o f softw are verification Software development often proves far more expensive than expected. The earlier a defect is discovered in development, the less impact it has on both the time-scales and cost. Bugs discovered late in the development cycle sends costs soaring and risk the integrity and safety of a system, especially if the software has been deployed. Because of the integration with software development, process, software verification has some benefits: • It uncovers high-risk errors early, giving the development team time to evolve a comprehensive solution rather than forcing a makeshift fix to accommodate development deadline. This is the main advantage of software verification. • I t gives management continuous and comprehensive inform ation about the quality and progress of the development effort. • It gives the users an incrementai převieพ of system performance, with tho chance to make early adjustments. • It evaluates the products against system requirements. 2.1.3 Interm ediate program representation In order to analyse the program in an automatic fashion, one need an Intermedi­ ata Software Representation (Laski & Stanley, 2009) that is language iiulopc'iiclont, 2.2. C o m p o n e n t-b a s e d s o ftw a re e n g in e e rin g 7 tripped of unnecessary syntax features, accurate, easy to manipulate，and possibly indexed to the program text. The choice of a particular representation depends on the objectives of the analysis. Compiler design is based upon the availability of the program parse and (abstract) syntax tree, software engineering typically uses program flow graph (Cota et al., 1994) as an intermediate analysis tool. Let p be a program. The control flow graph of p is a quadruple G := (N, A, ร, E) where (1) JV is a set of nodes, each node corresponding to a single entry single exit executable code segment in the program, (2) A is a set of arcs, each arc (ท, m) in A } ท, ไท € N 、 • corresponding to a potential transfer of control from 71 to m and (3) ร and E are ， respectively, tile S tart and E x it nodes such th a t there are no incoming arc to ร and no out coming from E. 2 .2 Component-based software engineering 2.2.1 A n overview Component-based software engineering (CBSE) (Crnkovic，2002) is a reuse-based approach to software systems development,. It is the process of defining, implement­ ing and composing loosely coupled independent software components into systems. It has become an important software development approach because software sys­ tems are becoming larger and more complex and customers are demanding more dependable software that is developed quickly. The only way that we can cope with complexity and deliver better software more quickly is to reuse rather than reimplement software components. The major goals of CBSE arc as follows: • To provide support, for development of systems as assemblies of components; • To support the development of components as reusable entities; • To facilitate the maintenance and upgrading of systems bv customizing and replacing their components. 2.2. C o m p o n e n t-b a s e d s o ftw a re e n g in e e rin g 2.2.2 8 Com ponent a) D e fin itio n Components can be considered as a standalone service provider. It is an independent executable entity. Source code is not available, so the component does not have to be compiled before it is used with other system components. The service offered by a component are made available through an interface, and all interactions are through that interface. The component interface is expressed in terms of parameterised operations and its internal state is never exposed. b) C haracteristics Table 2.1 shows the essential characteristics of a component as used in CBSE. Component characteristics Standardised Independent Composablc Deployable Documented Description Component standardisation means that a component used in a CBSE process has to conform to some standardised com­ ponent modeL This model may define component interface, component meta data, documentation, composition, and de­ ployment. A component should be independent - it should be possible to c;ompose and deploy it without having to use other specific components. In situations where the component needs exter­ nal provided services, these should be explicitly set out in a requires interface specification. For a component to be composable，all external interactions must take place through publicly defined interfaces. In ad­ dition, it must provide external access to information about itself, such as its methods and attributes. To be deployable, a component has to be self-contained and must be able to operate as a standalone entity on a component platform that implements the component model. This usually means that a component is binary and does not have to be compiled before it is deployed. Components have to fully documented so that potential users can decide whether or not the components meet their needs， The syntax and, ideally, the semantics of all component in­ terfaces have to be specified. Table 2.1: Component characteristics 2 .2 . C o m p o n e n t-b a s e d s o ftw a re e n g in e e rin g 9 c) D efining com ponent Compoiumt are defined by their interfaces, and in tlie most general cases, can be thought of as having two related interfaces, as show in Figure 2.2 • A provides interface defines the services provided by the component. The provides interface，essentially, is the component API. It defines the methods that, can be called by a user of the component，Provides interfaces are indicated by a circle at the end of a line from component icon. • Л requires interface specifics what services must be provided by other compo­ nent in the system. If these are not 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 'ร envifvnmeni that it Provides interface 1 へ ノ ________________ I I- ~ ___________ Q ] I о _______ Q Defines the services that arc provided by the component to other components. Figure 2.2: Component interfaces 2.2.3 Com ponent model a) D e fin itio n A component model is a definition of standards for component implementation, documentation and deployment. These standards are for component developers to ensure that components can interoperate. They are also for providers of component execution infrastructures who provide middleware to simport component operation (Crnkovic, 2002). Many component models have been proposed, b lit the most important models are: CORBA component model from the OMG, Sun’s Enterprise Java Bean model, and Microsoft's COM+ model. b) Basic elements o f com ponent m odel Figure 2.3 shows the basic elements of component model. They can be classified as elements relating to the component interfaces, elements relating to information that 10 2.3. T h r e e - tie r a rc h ite c tu re s a n d E J B we need to use the component in a program and elements concerned with component deployment. Nami ng Composition convention Documentation Figure 2.3: The basic elements of component model 2.3 Three-tier architectures and EJB 2.3.1 T h ree-tier architecture a) D e fin itio n Three-tier (Bass et al., 1998) is a client-server architecture in which the user in­ terface, functional process logic (business rules), computer data storage and data access are developed and maintained as independent modules, most often oil sepa­ rate 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 ail application server, and an RDBMS on a database server contains the computer (lata storage logic (see Figure 2.4). b) F u n c tio n a lity o f tiers Each tier ill the architecture has different functionality, as follows: • Presentation tier，or user services layer, gives a user access to the application. This layer presents data to the user and optionally permits data manipulation and data entry. The two main types of user interface for this layer are the traditional application and the Web-based application. 2 .3 . T h r e e - tie r a r c h ite c tu re s a n d E J B 11 Figure 2.4: Three-tier Architecture • The middle tier, or business services layer, consists of business and data rules. It is where developers can solve mission-critical business problems and achieve major productivity advantages. • The data tier, or data services layer, interacts with persistent (lata usually stored in a database or in permanent storage. This layer consists of data access oompononts (rather than raw DBMS connections) to aid in resource sharing and to allow clients to be configured without installing the DBMS libraries and ODBC driver on each client. c) Advantages o f th re e -tie r a rch ite ctu re These are some advantages of a three-tier architecture: • It is easy to modify or replace any tier without effecting the other tiers; • Separating the application and database functionality means better load bal­ ancing; • Adequate security policies can be enforced within the server tiers without hindering the clients. 2.3. T h r e e - tie r a r c h ite c tu re s a n d E J B 2.3.2 12 Java EE architecture a) D e fin itio n Java, platform, Enterprise Edition (JavaEE) (Jendrock et al., 2006) is a componentbased and platform-independent architecture. It makes Java EE applications easy to write bccausc business logic is organized into reusable components. In addition, the Java EE server provides underlying services in the form of a container for every component type. b) C ontainer services Containers are the interface between a component and the lower-level platformspecific functionality that support the component. These services are: security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote connectivity. Here are some highlights: • The Java EE security model lets you configure a web component or enterprise bean so that system resource are accessed only by authorized users; • The Java EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit; • JNDI lookup services provide a unified interface to multiple naming and di­ rectory services in the enterprise so that application components can access these services; • The Java remoto connectivity model manages low-level communications be­ tween clients and enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it was in the same virtual machine (Venners, 1999). The container also manages non configurable services such as enterprise bean and servlet life cycles, database connection resource pooling, data persistences，and access to the Java EE platform APIs. c) C ontainer types Java EE Server: The runtime portion of a Java EE product. A Java EE Server provides EJB and web containers; 2.3. T h r e e - tie r a rc h ite c tu re s a nd E J B 13 Figure 2.5: Java EE Server and Containers • Enterprise Java Bean (EJB) container: Manages the execution of enterprise beans for Java EE applications. Enterprise bean and their container run on the Java EE Server; • Web container: Manages the execution of JSP page and servlet components for Java EE applications. Web components and their container run on the Java EE server. • Application Client cont ainer: Manages the execution of application client com­ ponents. Application clients and their container run on the client. • Applet container: Manages the execution of applets. Consists of a web browser and .Java Plug-in running on the client together. 2.3.3 Enterprise Beans a) D efin itio ns • Enterprise JavaBeans (EJB) technology (Panda et al., 2007; Matena et al.， 2003): is the server side component architecture for Java platform, Enterprise Edition (JavaEE). EJB technology enables rapid and .simplified development 2.3. T h r e e - tie r a rc h ite c tu re s a n d E J B 14 of distributed, transactional, secure and portable applications based on Java technology. • Enterprise beans: are Java EE components that implement EJB technology. Enterprise beans run in the EJB container within the Application Server (see Figure 2.5), and they encapsulate the business logic of an application. The business logic is the code that fulfills the purpose of the application. In an in­ ventory control application, for example, the enterprise beans might implement the business logic in methods called checklnventoryLevel and orderProduct. By invoking these methods, clients can access the inventory services provided by the application. b) Benefits o f E nterprise Beans For several reasons, enterprise beans simplify the development, of large, distributed applications. First, because the EJB container provides system-level services to enterprise beans, the beau developer can concentrate on solving business problems. Second, because the beans rather than the clients contain the applications busi­ ness logic, the client developer can focus on the presentation of the client. So, the clients are thinner, a benefit that is particularly important for clients that run on small devices. Third7because enterprise beans are portable components，the application assem­ bler carl build new applications from existing beans. These applications can run on any compliant Java EE server provided that they use the standard APIs. c) Types o f E nte rprise Beans Table 2.2 summarizes the two types1 of enterprise bean. The following is the dis­ cussion in more detail. Enterprise Beans Type Session Message-Driven Purpose Performs a task for client; optionally may imple­ ment a web service Acts as a listener for a particular messaging type, such as the Java Message Service API Table 2.2: Enterprise Bean Types 1E n tity beans have been replaced by Java Persistence A P I entities. 2.3. T h r e e - tie r a rc h ite c tu re s a n d E J B 15 Session bean represents a single client inside the Application Server. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server. A session bean is not shared and is not persistent. Xhere are two types of session bean: stateful and stateless. Stateful session bean: In a stateful session bran, the instance variables represent the state of a unique client-bean session. The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears. - Stateless session bean: it does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the beans instance variables may contain a state specific to that client, but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained. M essage-Driven bean allows Java EE applications to process messages asynchronously. It normally acts as a JMS2 message listener. The messages can bo .sent by anv Java EE component or by a JMS application or system thut does not use Java EE technology. The most visible differences between message-driven beans and session beans are: clients do not access message-driven beans through interfaces, a messagedriven bean has only a bean class. d) Contents o f an E nte rprise Bean 丁о (lovoloj) an enterprise bean, we must 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 defines the methods implemented by the enterprise bean class; 2Java Message Service is a messaging standard th a t allows application components based on the J2EE to create, send, receive, and read messages.