Checking the comformance between the implementation and PSM specifications in component models

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 workstatio

Checking the Conformance betw een the

Im plem entation and PSM Specifications

in C om 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 o f the requirements for the degree o f

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 I n t r o d u c t i o n 1

1.1 M o tiva tio n 1

1.2 O bjectives 3

1.3 C o n trib u tio n s 3

1.4 Thesis stru ctu re 3

2 Background 5 2.1 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 6

2.2 Component-based software engineering 7

2.2.1 A ll over vie พ 7

2/2.2 Component 8

2.2.3 Component model 9

2.3 Three-tier architectures and Е Л В 10

2.3.1 Three-tier architecture 10

2.3.2 Java EE architecture 12

2.3.3 Enterprise B e a n s 13

2.4 Ư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

3 C hecking consistency between the im p le m e n ta tio 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 Bytecode stre a m s 23

T A B L E O F C O N T E N T S

3.3 Converting CFG to Call Graph ( C G ) 26

3.4 Algorithm to check the conformance between two g ra p h s 27

4 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 the support 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? .32

4.2.3 Difficulties in building module P S M E d ito r 32

4.3 Analysis and evaluation 34

5 R elated W o rk 35 6 Conclusion and F u ture w ork 38 6.1 Conclusion 38

G.2 Future work .39

List o f 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 10

2.4 Three-tier A rchite cture 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 S pecification 22

3.2 Source code of the method e x e c u te 24

3.3 The bytecode stream of execute method *25

3.4 CFG of the method e x e c u le () 27

3.5 The reduced graph of CFG of execute method 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 f ile 33

List o f Tables

2.1 Component characteristics2.2 Enterprise Beall Types2,4 The diagrams of ƯML 2.0

Chapter 1

Introduction

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 be- coming 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 t io 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 Jav- aBoans 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, component- based 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

C hapter 2

Background

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

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

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 in fo rm a tio n about the

quality and progress of the development effort

• It gives the users an incrementai pře vie พ of system performance, with tho chance to make early adjustments

• It evaluates the products against system requirements

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 potentia l transfer of control from 71 to m and (3)

ร and E are，respectively, tile S ta rt and E x it nodes such th a t there are no incoming

arc to ร and no out coming from E.

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

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

Independent

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

Composablc

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

Deployable

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

c) D e fin in g 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 Provides interface

Defines the services へ 1 _ Q Defines the services from the component 'ร ノ I ] that arc provided by

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

2.3 T h r e e - tie r a rc h ite c tu r e s a n d E J B 10

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.1 T h re e -tie r architectu re

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 tie rs

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 r e 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 rc h ite c tu 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

b) C on taine r services

Containers are the interface between a component and the lower-level platform- specific 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 o n ta in e r 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 r c h ite c tu re s a n d 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

a) D e fin itio n s

• 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

By invoking these methods, clients can access the inventory services provided

by the application

b) Benefits o f E nte rprise 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

T h ird7 because 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 n te rp rise Beans

Table 2.2 summarizes the two types1 of enterprise bean The following is the dis­cussion in more detail

ment a web service

Message-Driven Acts as a listener for a particular messaging type,

such as the Java Message Service API

Table 2.2: Enterprise Bean Types

1 E n tity beans have been replaced by Java Persistence A P I entities.

2 3 T h r e e - tie r a r c h ite c tu r e 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

X here 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 asyn- chronously 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 message- driven bean has only a bean class

d) C ontents o f an E n te rp rise 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.

Unified Modeling Language (ƯML) (Bòoch et al., 1999) is a visual language for specifying, constructing, and documenting the artefacts of systems We can use ƯML with all processes, throughout the development life cycle) and across different implementation technologies UML wa5 approved by the OMG ；i ล*ร a standard in

1997 Over the past few years there have been minor modifications made to the language, и M L 2 is the first major revision to the language

do not contain other symbols

ใO bject Management G roup is an interna tion al, open membership, n o t-fo r-p ro fit computer industry consortium.

• P ath s： they represent the link from one icon or system to another They,normally, represent the flow from one shape to another.

• Strings: they are used to represent labels, descriptions, names etc of icons，

symbols and paths

Figure 2.6 shows a class diagram It consists of four class objects, one inheritance relationship and two association relationships

Figure 2.6: A Class Diagram

There are thirteen diagram types of ƯML 2.0 (see Tabic 2.4) and they are clas­sified into three groups (Ambler, 2005):

• Behavior diagram s: A type of diagram that depicts behavioral features of

a system or business process This includes activity, state machine, and use case diagrams as well as the four interaction diagrams

• In te ra c tio n diagram s: A subset of behavior diagrams which emphasize object interactions This includes communication, interaction overview, se­quence, and timing diagrams

• S tru c tu re diagram s: A type of diagram that depicts the elements of a speci­fication that are irrespective of time This includes class, composite structure, component, deployment, object, and package diagrams

In this thesis, we only interested in Protocol State Machine We w ill present details of it in the next section

OẠ1 HOC QUỐC GIA HÀ NỘI TRUNG ĨẢM THÒNG TIN THU VIỆN

2.4 U M L S p e c ific a tio n 18

D iagram s D e s c rip tio n

Activity Depicts high-level business processes, including data flow, or

to model the logic of complex logic within a system

Class Shows a collection of static model elements such as classes

and types, their contents，and their relationships

Communication Shows instances of classes, their interrelationships, and the

message flow between them

Component

Depicts the components that compose an application, system,

or enterprise The components, their interrelationships, inter­actions, and their public interfaces are depicted

Object Depicts objects and their relationships at a point ill time

Package Shows how model elements are organized into packages as well

as the dependencies between packages

Sequence Models the sequential logic, in effect the time ordering of mes-

sages between classifiers

State Machine Describes the states an object or interaction may be in, as

well as the transitions between states

Timing Depicts the change in state or condition of a classifier instance

or role over time

Use Case Shows use cases, actors, and their interrelationships

Table 2.4: The diagrams of UML 2.0

a specified sequence is callcd an event protocol Ill UML 2.0, we can describe event protocol by protocol state machines (PSMs) (OMG, 2005) They differ from behavioural state machines and have special uses Normally, we should use regular state diagrams to show internal sequences of behaviour for all object of a class Sometimes, however, we want to show a complex protocol (set of rules governing

2.4 U M L S p e c ific a tio n 19

communication) when using an interface for a class or a component

For example, when we are designing classes or components that access a database for applications we need to use cx>mmon operations like open, close, and update a database But, these operations must be called in the right order We cannot update the database before we open it Figure 2.7 shows the simple protocol state machine for the access database system

Figure 2.7: A Protocol State Machine

A protocol state machine is always defined in the context of a classifier It specifies which operations of the classifier can be called in which state and under which condition, thus specifying the allowed call sequences on the classifiers opera­tions A protocol state machine presents the possible and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions (OMG, 2005)

In the protocol state machine (1) An initial state is shown as a small solid filled circle, (2) A final state is shown as a circle surrounding a small solid filled circle, (3) A protocol transition specifies a legal transition for an operation, and has the following information: a pre-condition (guard), on trigger, and a post-condition.Since an interface of a component specifies conformance characteristics, it does not own detailed behaviour specification Instead, interface may own a protocol state machine that specifies event sequences and pre/post conditions for the operations and receptions described by the interfaces