like all other industrial com ponent m odels, does not provide a connector concept. N evertheless, com ponents are connected by linking facets to receptacles and event[r]
Trang 1VNU Journal of Science, N atural Sciences and Technology 24 (2008) 92-102
Checking the conformability in CORBA component mode
specifications
Tran Thi Mai Thuong*, V o Van Thanh, Truong N inh Thuan
College o f Technology, VNU, 144Xuan Thuy Road, Cau Giay District, Hanoi, Vietnam
Received 31 October 2007
A bstract We proposed in this paper an a p p ro a c h for checking the conformability in CORBA
com ponent m odel specifications In software engineering, it is dem onstrated that discovering bugs
in earlier phases is much more economical than later phases We focused thus on verifying
com ponents by their ports specification In order to do this, firstly we determ ined constraints on
kinds of port as well as on types of port which the connection between ports must satisfy, and then formalized them to be able to prove automatically using formal prover tools Here, we proposed to
u s e th e B m e th o d fo r v e rify in g c o m p o n e n ts in a CCM s p e c ific a tio n
1 In tro d u c tio n
T he enorm ous expansion in the use o f
softw are in every field o f life make dem ands on
installing and developing reusable, robust,
reliable, flexible, adaptive softw are systems
m uch accelerating As these dem ands are
grow ing stronger, the com plexity o f processes
that softw are m anages is increasing along with
the dem and for the integration o f processes
from different areas As a consequence,
softw are program s are becom ing increasingly
large and com plex The appearance o f
com ponent based softw are engineering (CBSE)
adapts this challenge o f the software
developm ent; it proposes an easy and efficient
m ethod for developing large software
In this approach, the architecture o f a
system is described as a collection o f
Corresponding author E-mail: thuongttm@vnu.edu.vn
com ponents (reusable parts) along w ith the interactions am ong those via their ports The main feature o f CBSE is to allow the construction o f an application using independently developed softw are com ponents, leading to reduce developm ent costs and
im proved softw are quality In this process, it is essential to ensure that individual com ponents can in fact interoperate together in the system
H ow ever the com ponents do not interact seam lessly Problem s could arise in the system
if there are m ism atches and inadequacies o f connected points betw een com ponents It is
im portant to verify the coưecùiess o f com ponent com position In order to do it, there are m any approaches appeared to verify the com patibility betw een com ponents by interfaces [1,2], behaviour specification [3],
m odels [4’
As we know, how ever, CBSE is also an approach to develop softw are systems, hence
92
Trang 2T.T.M Tỉm ong et a i / V N U Journal o f Science, N atural Sciences and Technology 24 (2008) 92-102 93
discovering bugs in the earlier phases will
reduce much time and effort in building
softw are systems, especially large systems So,
in this paper, we propose an approach to verify
the conform ability betw een com ponents
through specifications o f their ports This is a
buffer step before verifying behaviour
specifications o f com ponents, because it will
remove many unneccesary cases w hich are
inputs for checking behaviours
Here, we use the C O RB A Com ponent
M odel (CCM) ports Firstly, CCM specification
o f com ponents is described by XM L W e then
determine the conditions such that ports can be
connectable From the X M L desciption and
these constraints, we finally build a B abstract
m achine which can be used to check the
consistency o f connected ports in the model
The B m ethod [5] is used to verify the
compatibility betw een ports B ecause, the B
notations rUvQ based on set theory, generalised
substitutions and first order logic, these are
easily to describe ports and their relation In
addition, the p ro o f obligations for B
specifications are generated autom atically by
support tools like AtelierB [6], B -Toolkit [7'
and B4free [8] C hecking p ro o f obligations with
B support tools is autom atically perfom ed
In the following, we present an overview o f
com ponents specifying approaches W e then
describe our m ethod in Section 3 and illusừate
it with the case study o f the Stock Q uoter
System In Section 4, we discuss related work
The paper finishes w ith som e concluding
rem arks in Section 5
2 Specification o f so ftw a re c o m p o n en ts
Specification o f softw are com ponents is one
o f the most im portant research challenges in
com ponent-based softw are engineering It
represents the first step tow ards true com ponent
reuse as the com ponent specification gives all neccssary inform ation to the com ponent user on how /w hy the com ponent can be (re) used
A com ponent is considered to be a black box Hence, interfaces are the only access points to the com ponent and the specification o f the com ponent com es dow n to the specification
o f the com ponent interfaces
Specification o f the com ponent interfaces in the current com ponent-based systems is done
by two levels:
• On the first level, syntactical level, there are some specification models such as JavaB eans [9], C O M + [10], CCM [11], .NET [12], and the O pen Service G atew ay Initiative (O SG I) [13] A t this level, The com ponent specification consists o f specification o f provided and required interfaces Provided interfaces are the one that contain operations that a com ponent provides to other com ponents or to the
c o m p o n e n t u s e r, w h ile re q u ire d in te rfa c e s
are the one that contain operations used by the com ponent
s p e c ific a tio n , th e re a re tw o re p re s e n ta tiv e s:
U nified M odeling Language (U M L) and the O bject C onsừ aint Language (O CL), in which a com ponent im plem ents a set o f interfaces Each interface consists o f a set
o f operations w ith associated pre and postconditions, as well as com ponent state and invariants Preconditions are assertions that the com ponent assum es to be fulfilled before an operation is invoked, w hile postconditions are assertions that the com ponent guarantees w ill hold ju st after the operation has been invoked An invariant is a predicate over the interface’s state that will alw ays hold
In this paper, we focus on verifying the confonnability betw een com ponents by ports in CCM (CO RBA C om ponent M odels) The CCM
Trang 394 T.T.M T h u o n g et a l / V N U Journal o f Science, N atural Sciences and Technology 24 (2008) 92-102
is the m ost recen t and com plete com ponent
specification from O M G [14] It has been
designed on the basis o f the accum ulated
experience using C O R B A service, JavaBeans,
and EJB The m ajo r goal behind the CCM
specification is to provide solution to the
com plexity reach ed by C O RB A and its
services O ne o f the advantages o f CCM is its
effort to integrate m any o f the facets involved
in softw are engineering A s a consequence, a
softw are application is described in different
form alism s along tw o dim ensions: the time
dim ension (the life cycle, from design to
deploym ent) and the abstract dim ension (from
absừ actions to im plem entation) Altogether,
this m akes a rath er com plex specification
C CM sim ply defines the concept o f
connection as an object reference; thus CCM ,
like all other industrial com ponent m odels, does not provide a connector concept N evertheless, com ponents are connected by linking facets to receptacles and event sources to event sinks Connections are binaries and oriented, but the same port can handle m ultiple connections Connections can be explicitly described (in the assem bly descriptor, an X M L file) and established by the CCM fram ew ork at initialization
C om ponents support a variety o f surface features through w hich clients and other elem ents o f an application environm ent may interact w ith a com ponent These surface features are called ports The com ponent model supports four basic kinds o f ports [15] (see Figure 1):
A ttribute Event source Event sink Receptacle Facet
CO RB A com ponent interface P ort Fig 1 CO RB A com ponent interface and its ports
Facets, w hich are distinct nam ed interfaces
provided by the com ponent for client
interaction
R eceptacles, w hich are nam ed connection
points that describe the com ponent’s ability
to use a reference supplied by some external
agent
E vent sources, w hich are nam ed connection
points that em it events o f a specified type to
one or m ore interested event consum ers, or
to an event channel
Event sinks, w hich are nam ed connection
points into w hich events o f a specified type
m ay be pushed
Basic com ponents are not allow ed to offer facets, receptacles, event sources and sinks They m ay only offer attributes Extended com ponents may offer any type o f port
3 C ase stu d y : S to ck Q u o te r S y stem
T o dem onstrate our approach, we use a case study o f the Stock Q uoter S y stem ’ with two com ponents connected by their ports However, our approach will w ork w ith m ore complex system s in w hich there are m any connected com ponents A ccording to this approach, we
http://w w w ddj.com /cpp/184403889
Trang 4T T M Thiion<ị et a l / V N U Journol o f Science, N atural Sciences and Technology 24 (2008) 92-102 95
firstly transfonn CCM specification o f
com ponents into X M L format W e then express
XML description and constraints which we
defined above as inputs o f B abstract machine
Finally, we use an autom atic p ro o f tool to check
the consistency o f connected ports in the model
with B absừact machine
Figure 2 illustrates the com ponents in stock
quoter system exam ple using the CORBA
StockD istributor com ponent m onitors a real
time stock database W hen the values o f particular stocks change, it pushes a CCM eventtype that contains the sto ck ’s name via a CCM event source to the corresponding CCM event sink im plem ented by one or m ore StockBroker com ponents If these com ponents are interested in the stock they can obtain more inform ation about it by invoking a request/response operation via their CCM receptacle on a CCM facet exported by the StockD istributor com ponent
notifier_in
n o tifie ro u t
^ỉ> - ^
Q quoter_info_out
quoter_info^in
- 2- Stock
Broker
Fig 2 CO RBA com ponent interface and its ports
component StockBroker {
consumes StockName notifier_in;
uses StockQuoter quoter_info_in;
) ;
StockB roker contains two ports that
coư espond to the follow ing two roles it plays
It’s a subscriber that consum es a
StockN am e eventtype called n o tifie r jn th at’s
published by the StockD istributor when the
value o f a stock changes As shown in Figure 2,
the n o tifie r jn event sink w ill be connected to
the S tockD istributor’s notifierjD ut event source
by the standard CCM deploym ent and
configuration tools when the application is
launched
It uses the StockQ uoter interface provided
by the StockD isừibutor com ponent, which
reports additional inform ation about a stock,
such as the high, low, and m ost recent ừading
values o f the stock during the day The
dependency o f StockB roker on StockQ uoter is indicated explicitly in ID L 3.x via the
quoter infojD ut iacade by the deploym ent and
configuration tools w hen th e ” application is launched
We now present the im plem entation o f the StockD isừibutor com ponent, w hose ports are shown here:
component StockDistributor supports Trigger (
publishes StockName notifier_out;
quoter_info_out;
attribute long notification_rate; } ;
It publishes a StockN am e eventtype called
notifier_out that is pushed to the StockB roker
subscriber com ponents w hen a stock value
Trang 596 T.T.M Thiiong ct al / V N U Journal o f Science, Natural Sciences and Technology 24 (2008) 92-102
changes In addition, it defines a StockQuoter
facet called q u o te rjn fo _ o u t, w hich defines a
factory operation that returns object references
that StockBroker com ponents can use to obtain
more information about a particular stock
Finally, this com ponent defines the
adm inistrator applications can use to control the
rate at which the StockD istributor com ponent
checks the stock quote database and pushes
changes to StockBroker subscribers
We now consider the verification o f
conform ability betw een com ponents when we
have information describing the connection
between ports o f com ponents from their CCM
specification in this system
Recall that inform ation in com ponent
specification can be described by XM L XM L
(Extensible M arkup Language) [16] is a simple,
very flexible text format derived from SGML
Originally designed to meet the challenges o f
large scale electronic publishing, X M L is also
playing an increasingly im portant role in the
exchange o f a wide variety o f data on the W eb
and elsewhere
XM L can also use to define m etam odel or
metadata o f a system specification W ith a
X M L docum ent described valid CO RBA
system, it can provide an easy way to extract
infom iation about com ponents and its ports for
the verification purpose
The ADL specification o f the Stock Q uoter
System presented in Figure 2 can be described
by XM L as the following
Note that, in a CCM specification, if a
receptacle’s uses declaration does not include
the optional multiple keyw ord, then only a
single connection to the receptacle may exist at
a given time If a receptacle’s uses declaration
includes the optional m ultiple keyword, then
multiple connections to the receptacle may exist
simultaneously
There are two categories o f event sources,
em itters and publishers Both are implementec using event channels supplied by the container
An em itter can be connected to at most one proxy provider by the container A publishei can be connected through the channel to an arbitrary num ber o f consum ers, who are said to subscribe to the publisher event source A com ponent m ay exhibit zero or more emitters and publishers
A publisher event source has the following characteristics [ 11]:
• T h e e q u iv a le n t o p e ra tio n s fo r p u b lis h e rs
allow m ultiple subscribers (i.e., consum ers)
sim ultaneously
• Subscriptions to a publisher are d e le g a te d
to an event channel supplied by the container at run time The com ponent is guaranteed to be the only source publishing
to that event channel
An em itter event source has the following characteristics [ 11]:
• The equivalent operations for emitters allow only one consum er to be connected to the
em itter at a time
• The events pushed from an emitter are delegated to an event channel supplied by the container at run time O ther event sources, however, may use the same channel
As a consequence, CCM components can
be connected if their ports satisfy conditions:
P D l Facet can connect only to receptacles (provides port connect only to uses port) PD2 Event source can connect only to event sinks (W e can say that publishes and emits ports can connect only to consumes ports) PD3 Each provides port (facet) can connect to many uses ports (receptacles), each publishes port can connect to many consum es ports but not on the contrary
Trang 6Ĩ T M Thuong et aỉ í V N lỉ Ịournnỉ o f Science, N atural Sciences and Technoỉo<^y 24 (200S) 92-702 97
^D4 Each em its port connect only to one
consum es port
^D5 With tw o connectcd ports, type o f
provided ports (facets, event sources) is a
subtype o f the one o f required ports
(receptacles, event sinks)
I / C h ecking types o f p o r t in connections
Each com ponent IS described m a
component based model with two phases The
first one is the type, represents the functional
interface o f the com ponent, w hat is visible by
other com ponents The second one is the
im plem entation, describes the contents o f the
component
The aim o f separation o f a component
description into a type and an im plem entation is
the point o f view o f the com ponent Describing
the type m eans specifying the com ponent
interface, expressing how it is seen from an
external point o f view On the other hand, the
im plem entation represents the interior In
practice, Ihc description o f the type and the
im plem entation m ay be done by different
persons, each o f them dealing with one step in
the refinem ent o f the architecture description,
from the top level to the detail level
An inheritance m echanism exists to describe the com ponents It may be used for both the types and the implem entations This
m echanism is useful to refine a description by
o v e rw ritin g an already existing component Restrictions exist, w hich m ust be respected Thus, a com ponent type may inherit from another com ponent type o f the same category
In the same way, a com ponent implementation
im plem entation o f the sam e category
The final condition o f the compatibility betw een ports (PD5) states that, type o f provided ports is a subtype o f the one o f required ports A verification shound be considered to ensure the conform ity between the types and directions o f the connected ports
In order to verify conditions for connecting ports in a CCM specification, we propose to use the B method [5]
From the inheritance relationship between types o f ports, we create a simple B abstract
m achine called Types m achine (Figure 3) In this machine, if an interface T Y P E l inherits from an interface TY PE2, we define TY PEl is subtype o f the TY PE2 (T Y PE l c TYPE2)
MACHINE Types
CONSTANTS TYPEỈ, TYPE2, TYPES
PROPERTIES TYPEỈ ^ TYPE2; TYPE3 a TYPE2
END
Fig 3 T y p e s a b s tra c t m a c h in e
Trang 798 T.T.M Thuong et a i Ị V N U Ịournaỉ o f Science, N atural Sciences and Technology 24 (2008) 92-102
From the Types m achine, if we w ant to
check the consistency o f the type betw een two
ports in a connection, we have to get the type o f
required port (T Y P E l) and the type o f provided
port (TYPE2) Each time we get a connection,
we have to give a fragm ent specification as the
following into the B specification, according to
the definition o f subtype:
A N Y conn WHERE
conn e TYPE2
THEN
conn : e TY P E l
END
The B prover will check if TY PE2 is a
subtype o f TY PE 1 from this specification
3.2 Checking kinds o f p o rt in connections
The B machine that we build to verify the
coưectness o f the ADL A cm e specification [17^
is called the C onnectionCheck From the X M L
description, we can get all ports and the kind o f
port (uses port, provides port, consum es
ports ) in the specification They are presented
in the SETS clause o f the machine
We declare the variables connectionU _P to
contain and check the connection betw een uses
ports and provides ports, connectionC _P tc
contain the connection betw een consum es ports
and publishes ports, connectionC _E to contair
the connection betw een consum es ports and emits ports These variables have to satisfy four conditions (P D l, PD2, PD3, PD4) described in the above These constraints can be formally described in the E W A R IA N T S clause as the following:
con nectionu^peU SE SP O R T 7 -^ PRO VIDESPORT^ connectionC_EeCONSUMESPORT-^EMỈTSPORT^ comectionC_PeC0NSUMESP0RT7^PUBUSHESP0RT
In these constraints, type o f these three variable define the type o f a possible connections in the specification
W e use the partial function (-H>) to denote the relation betw een the dom ain and the range
o f the connection betw een uses port and provides ports; consum es port and publishes port It m eans that, one elem ent o f the domain cannot connect to have more than one element
o f the range and one elem ent o f the range can connect to m any elem ents o f the domain (Figure 4) W e use the partial bijection (>-^) to denote the relation betw een consum es port and emits port It m eans that each elem ent o f the domain can connect only to one elem ent o f the range
X
Y
Fig 4 Relations in a partial function
Trang 8r.T.M T huong et a l / V N U journal o f Science, N atural Sciences and Technologỵ 24 (2008) 92-102 99
In the O PERA TIO N S clause o f the
m achine, wc define operations for extracting all
connections in the CCM specification In these
operations, we intergrate the fragment
specification o f checking types betw een ports o f
the connection T he m achine presented in
Figure 5 illustrates the B notations o f the
verification puqDose for the case study o f the
Stock Q uoter System in Figure 2 It is to be
noted that, all infonnation in this abstract
m achine can be extracted from the X M L
description hence it can be built automatically
4 R elate d w o rk
Several proposals for verifying the
interoperability betw een com ponents have been
made
The paper [4] present a tool called Cadena,
an integrated environm ent for building and
m odeling CCM system s Cadena provides
facilities for defining com ponent types using
CCM IDL, specifying dependency information and transition system sem antics for these types, assem bling system s from CCM components, visualizing various dependence relationships betw een com ponents, specifying and verifying coưectness properties o f models o f CCM system s derived from CCM IDL, component
specifications, and producing CORBA stubs and skeletons im plem ented in Java
As a point o f com parison, this paper generated a D Spin m odel for the scenario that check the num ber o f tim eouts issued in a system execution
Zarem ski and W ing [18] propose an approach to com pare two softw are components They determ ine w hether one required com ponent can be substituted by another one They use formal specifications to model the behavior o f com ponents and exploit the Larch prover to verify the specification m atching o f com ponents
M A C H IN E ConnectionCheck SEES Types
SETS
U S E S P O R T = {quoter_ in fo jn };
PROVIDESPORT = {quoter_info_out};
CONSUMESPORT = jnotifierjn};
PUBLISHESPORTS - {notirier_out}; EMITSPORTS;
VA RIA B LES connectionU P, connectionC P, connectionC_E INV A RIA N TS
ConnectionU _P e
Ư SESPORT -^P R O V ID E SP O R T A
ConnectionC P G
ConnectionC_E e
INITIA LISA TIO N
C onnectionU P := 0 II
connectionC_P 0 II connectionC_E 0
OPERA TIO N S
G e tC o n n e c tio n U _ P =
PRE
ConnectionU p ƯSESPORT ^PROVIDESPORT
Trang 9100 T.T.M T huong et al. / VhJU Journal o f Science, N atural Sciences and Technology 24 (2008) 92-102
TH EN ConnectionU _P connectionU _P u {n o tifier_ in ~*notifier_out} II
A N Y conn W H ER E /* Check type o f ports */
conn STO CK N A M E /* type o f p ro v id e s port */
TH EN
conn ; e STOCKNAME /* type of uses port */
END END;
getConnectionCP =
PRE
connectionC_P G
CO N SƯ M ESPO RT ->PU B L ISH ESPO R T
TH EN connectionC _P := connectionC P u
{quoter_info_in —>quoter_info_out} II
A N Y conn W H ER E /♦ Check type o f ports V
conn e STOCKQƯOTER /* type of publishes port */
TH EN
conn : 6 STOCKQUOTER /* type of consumes port */
END END;
g e tC o n n e c tio n C E = PRE
connectionC _E e C O N SU M ESPO RT -> EM ITSPO RT
TH EN connectionC _E := connectionC_E u 0 END
END
Fig 5 B abstract m achine for verifying com patibility betw een com ponent ports
In [1,2], protocols are specified using a
tem poral logic based approach, w hich leads to a
rich specification for com ponent interfaces
H enzinger and Alfaro [19] propose an approach
allow ing the verification o f interfaces
interoperability based on autom ata and game
theories: this approach is well suited for
checking the interface com patibility at the
protocol level
The paper [3] proposes the Port State
M achine (PoSM ) to model the com m unication
on a Port B uilding on their experience with
behavior protocols, they m odel an operation
call as two atom ic events request and response,
perm itting PoSM to capture the interleaving
and nesting o f operation calls on provided and required interfaces o f the Port The trace sem antics o f PoSM yields a regular language They apply the com pliance relation o f behavior protocols to PoSM s, allow ing to reason on behavior com pliance o f com ponents in software architectures
O ur w ork focuses on the verification o f interoperability o f specification o f components through their ports W e determine the conditions for the connection betw een ports and use the B m ethod for verifying their compatibility
Trang 10T T M Thuon^ii ct nL / V N U journal o f Science, Natnrnl Sciences and Technoỉo^ỵ 24 (2008) 92-102 101
We have presented some aspects o f
com ponent specifications, outlined our
approach o f com ponents verification based on
kinds o f connectable ports, through proving the
correctness o f iheir CCM specification using B
method C oncurrently, we also described more
detail the transform ation from p o rts’ informal
connection constraints to formal formats to be
able to input into B m achine for verifying W e
have presented a small but illustrative case
study, show ing in particular kinds o f ports
w hich can be connectable as well as the activity
m achenism o f B m achine in proving the
soundness o f C CM specification
In previous work, we defined constraints on
ports, and thanks to these we can know which
com ponents can connect together properly if
their ports satisfy requirem ents w hich we given
At this degree, we have ju st only known kinds
o f port (facet, receptacle, event source, event
sink) and only verified constraints on these
kinds o f port In this paper, we conừibuted to
verifying connection conditions on types o f port
and integrating it into kinds o f port to assist our
approach This will support us much on
verifying the com patability betw een
coinponenls by behaviour specification at
sem antic level
In the future work, we will c a n y out to
check the com position betw een behaviors o f
ports w hen connection betw een types o f port is
coưect Since then, we will build a fram ew ork
supporting the process o f installing, verifying
and developing com ponent-based systems This
leaves the opportunity for the designer to use
the tool best suited to the problem , and to
perform formal analysis on parts o f the system
that particularly deserve it
A ck n o w leg m en ts This w ork is partly
supported by the research project No QC.07.04
granted by V ietnam N ational U niversity, Hanoi
[1] J Han, “ A com prehensive interface definition fram ework for software com ponents”, In A sia Pacific
software engineering confcrcnce, ỈE E E C om puter Society (1998) 110.
[2] J Han, Tem poral logic based specification o f
com ponent interaction protocols, In P roceedings o f the Second Workshop on Object Interoperability ECO O P-2000, Springer-V crlag, (2000) 12.
[3] V Mcncl, “ Specifying com ponent behavior with port state m achines” , Electronic N otes in Theoretical
Com puter Science, Special issue: Proceedings o f the Workshop on the C om positional Verification o f UML
A/oi/e/5, i01C :129, 2004.
[4] J H ct al ‘‘Cadcna: an integrated developm ent, analysis, and verification environm ent for
com poncnt-bascd system s”, In Proceedings o f 25th International Conference on Software Engineering,
(2003) 160.
[5] J.R Abrial, The B-Book, A ssigning P rogram s to
M eanings, Cam bridge U niversity Press, 1996.
[6] Stcria, O bligations de preuve: M anuel dc r e f ercnce' Steria - Technologies de I’inform ation, version 3.0,
A vailable at http://w w w atelicrb.societe.com [7] B.C Ltd B-Toolkit U ser’s M anual, O xford (UK),
1996, Release 3.2.
[8] Cicarsy, B4frcc A vailable at http://w w w b4free.com , 2004.
[9] Sun M icrosystem s, JavaB cans 1.01 Specification, http://java.sun.com /beans.
[10] G Eddon, H Eddon, Inside COM + Base Services
M icrosoft Press, 2000.
[11]C0RBA Component Model Specification, Version 4.0, http://w w w om g.org/cgi-bin/doc7ptc/2006-05-01 [12] M icrosoft, NET, http;//w w w m icrosoft.com /nct/ [13] OSGI, OSGI Service G atew ay Specification, Release 1.0, http://w w w osgi.org.
[14] http;//w w w om g.org.
[15] I C m kovic, M Larsson “ B uilding reliable com poncntbased Software System s”, A rtech House, Inc, 2002.
[16] W orld W ide W eb Consortium , XM L, http://w w w w 3c.org/X M L /.
[17] Nguyen Hoang Ha, Tran Thi Mai Thuong, Truong Ninh Thuan, Nguyen V iet Ha, “ V erifying the com patibility o f com ponents’ ports upon
specification” , In Japan Vietnam W orkshop on Softw are E ngineering 2007, Septem ber 2007.
[Ỉ8] A M Zarem ski, J M W ing, “Specification m atching
o f software com ponents” 6(4) (1997) 333.
[19] L Alfaro T.A Hcnzinger, “ Interface autom ata” , In
9th A nnual Sym posium on F oundations o f Softw are Engineering, ACM press, (2001) 109.