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

Checking the Conformance between the
Im plementation and PSM Specifications
in Component Models
Pham Van Viet
Faculty of Information Technology
College of Technology
Vietnam National University, Hanoi
Supervised by
Dr. Truong Ninh Thuan
A thesis submitted in fulfillment of the requirements for the degree of
Master of Information Technology
December, 2009
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRUNG ТЛМ THÕNG TIN THƯ VlEN
Table of Contents
1 In tr o d u c tio n 1
1.1 Motivation
1
1.2 Objectives 3
1.3 Contributions 3
1.4 Thesis structure 3
2 Background 5
2.1 Software verification and validation 5
2.1.1 D e fin itio n 5
2.1.2 Benefits of software verification 6
2.1.3 Intermediate program representation
.
6
2.2 Component-based software engineering 7
2.2.1 All 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 eans 13
2.4 ƯML Specification

16
2.4.1 An overview 16
2.4.2 General elements of Ư M L 16
2.4.3 Protocol State Machine 18
3 Checking consistency between the im plementation and PSM spec
ification 20
3.1 Transforming PSM to a graph expression

20
3.2 Generating the CFG from Bytecode streams 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 graphs
27
4 Im plementation 29
4.1 Architecture of the support to o l 29
4.2 Difficulties in the implementation of the support to 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 PSM Editor

32
4.3 Analysis and evaluation
34
5 Related W ork 35
6 Conclusion and Future work 38
6.1 Conclusion 38
G.2 Future work

39
List of Figures
*2.1 Verification and Validation process


6
2.2 Component interfaces 9
2.3 The basic elements of component model

10
2.4 Three-tier Architecture 11
2.5 Java EE Server and Containers
13
2.6 A Class D iagram 17
2.7 A Protocol State M achine 19
3.1 XMI form of PSM Specification 22
3.2 Source code of the method
execute

24
3.3 The bytecode stream of execute method

*25
3.4 CFG of the method
execule()
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 XML file 33
List of Tables
2.1 Component characteristics
2.2 Enterprise Beall Types
2,4 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 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 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 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 bjectives
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
Hie remainder of this thesis is organized as follows.
1.4. Thesis s tru c tu re
• 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.
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 Definition
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: Mre
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. Softw are ve rific a tio n and va lid a tio n
6
Figure 2.1: Verification and Validation process
2.1.2 Benefits of 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.
• It gives management continuous and comprehensive information 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.
2.1.3 Intermediate 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 om ponent-based softw are engineering 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 Start and Exit nodes such that 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 om ponent-based softw are engineering 8
2.2.2 Component
a) Definition
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) Characteristics
Table 2.1 shows the essential characteristics of a component as used in CBSE.
Component
characteristics
Description
Standardised
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.
Documented
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
c) Defining component
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
envifvnmeni that it I-~I о the component to
_______
Q other components.
Figure 2.2: Component interfaces
2.2. C om ponent-based softw are engineering 9
2.2.3 Component model
a) Definition
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, blit 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 component model
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 re e -tie r a rchite c tu re s and EJB 10
we need to use the component in a program and elements concerned with component
deployment.
Naming
Composition convention Documentation
Figure 2.3:
The
basic elements of component model
2.3 Three-tier architectures and EJB
2.3.1 Three-tier architecture

a) Definition
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) Functionality of 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 re e -tie r a rchitectu res and E JB
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 of three-tier architecture
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 ree -tie r a rchitectu res and E JB 12
2.3.2 Java EE architecture
a) Definition
Java, platform, Enterprise Edition (JavaEE) (Jendrock et al., 2006) is a component-
based 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) Container 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) Container 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 ree -tie r a rchite cture s and EJB 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) Definitions
• 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 re e -tie r a rchitec tu re s and E JB
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 of Enterprise 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.
Third7 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 of Enterprise Beans
Table 2.2 summarizes the two types1 of enterprise bean. The following is the dis
cussion in more detail.
Enterprise Beans Type Purpose
Session
Performs a task for client; optionally may imple
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 En tity beans have been replaced by Java Persistence API entities.
2.3. T h re e -tie r a rchitectu re s and E JB
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.
Message-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) Contents of an Enterprise 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 that allows application components based on
the J2EE to create, send, receive, and read messages.
2.4. U M L S pecification
16
• Helper classes: Other classes needed by the enterprise class, such as exception

and utility classes.
We package the files in the preceding list into an EJB JAR file, the module that
stores the enterprise bean. An EJB JAR file is portable and can be used for different
applications.
2.4 UML Specification
2.4.1 An overview
Modeling is the designing of software applications before coding. Modeling is an es
sential part of large software projects, and helpful to medium and even small projects
as well. Complex software designs that would be difficult to describe textually can
readily be conveyed through diagrams. Modeling provides three key benefits: visu
alization, complexity management and clear conimunication.
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, и ML 2 is the first major revision to the language.
2*4.2 General elements of U M L
The UML provides a set of modeling diagrams used for modeling systems. The
diagrams are composed of four genera] elements:
• Icons: They represent the atomic symbols of the diagrams. They are abstract
shapes that, are connected to other shapes,
• Two-dimensional symbols: They are similar to the icons except that they
have compartments that can contains other symbols, icons, or strings. Icon
do not contain other symbols.
ใObject Management Group is an international, open membership, not-for-profit computer
industry consortium.
• Paths： 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.
2.4. U M L S p ecification 17
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 diagrams: 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.
• Interaction diagrams: A subset of behavior diagrams which emphasize
object interactions. This includes communication, interaction overview, se
quence, and timing diagrams.
• Structure diagrams: 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 will 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
A
- iû/e
싶ᅳ
2.4. U M L Spe cifica tio n 18
Diagrams Description
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.
Composite
Structure
Depicts the internal structure of a classifier (such as a class,
component, or use caæ).
Deployment Shows the execution architecture of systems.
Interaction
Overview
A variant of an activity diagram which overviews the control
flow within a system or business process.
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
2.4.3 Protocol State Machine
When we want to show the sequence of events that an object reacts to • and the
resulting behaviour - we can use
a ML
behavioural state diagrams. Such state
diagrams have event/action pairs, entry actions, exit actions, and do activities.
Sometimes, however, we just want to show a specified sequence of events that object
responds to - and when it can respond - without having to show its behaviour. Such
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 pecification
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.
Chapter 3
Checking consistency betw een the
im plem entation and PSM
specification
In order to chock the conformance between the implementation and PSM specifica
tions, we have to transform the PSM specification into a graph and the bytecode
ill the implementation into another graph. The conformance is checked between
these two intermediate graphs. In this chapter, we will illustrate how to make these
transformations. In addition, we give an algorithm to check the consistency between
two obtained graphs.
3.1 Transforming PSM to a graph expression
UML graphical notations are used to express PSM specifications. A PSM is con
sidered as a graph in which the order of interface methods are edges, and states
of before and after the execution of methods are nodes (Figure 2.7). We aim at
transforming the graph of PSM (G) to another class where edges become nodes of
the new graph called derived graph (G;).
In graph theory, the derived graph
Gf
is similar to the notion of line bigraph of
G

but in our case, edges of the graph
G
may be identical. We give the definitions
of a graph and its derived graph as Definition 1 and Definition 2, respectively.
Definition 1
A
flow graph
G
is a tuple
G
= (V, JS, .ร, i,/i, Vs) ) where
20