Checking the Consistency between UCM and PSMusing a Graph-based Method

Ninh-Thuan Truong, Thi-Mai-Thuong Tran, Van-Khanh To, Viet-Ha NguyenCollege of Technology

Vietnam National University, Hanoi144 Xuan Thuy, Cau Giay, Hanoi

Email: {thuantn,thuongttm,khanhtv,hanv}@vnu.edu.vn

Abstract

Checking the consistency in component models at designphase is essential in component-based software engineering(CBSE). In our previous work, we proposed an approach forverifying automatically the matching between protocol statemachines (PSMs) and the Use Case Map (UCM), using theB method. Due to the expressive power of B notations, how-ever, we cannot describe the parallel processing in the im-plementation machine, particularly we are not able to ex-press all features (such as AND-forks/joins, OR-forks/joins)of UCMs in a B implementation machine. In this work,we propose an approach to solve the expression problemof UCM features using a graph-based algorithm. The UCMpath which describes the interaction between components isextracted and then decomposed into sequential events pathsif it has AND-forks/joins and/or OR-forks/joins. Each ofsequential events paths will be checked with the order ofevents of PSMs by the proposed algorithm.

1 Introduction

The enormous expansion in the use of software in ev-

ery field of life causes increasingly demands on installing

and developing reusable, robust, reliable, flexible, adap-

tive software systems. Concurrently, the complexity of pro-

cesses that software manages is growing along with the de-

mand for the integration of processes from different areas.

As a result, software programs are becoming increasingly

large and complex. Component based software engineering

(CBSE) addresses this challenge of the software develop-

ment by proposing an easy and efficient method to develop

large software systems. The main feature of CBSE is to al-

low the construction of an application using independently

developed software components. This helps reducing de-

velopment costs and improving software quality. However,

problems arise if there are mismatches and inadequacies of

combined components. Verifying the correctness of com-

ponents composition thus is an important task in compo-

nent software development. Many approaches have been

proposed to verify the compatibility between components

by interfaces [9, 10], by behavior specifications [12], or by

models [11], etc.

Developers using component technologies such as

COM, COM+ [8] or JavaBeans[1] need to be able to define

and express specifications for their components. They can

do so using component diagrams of the Unified Modeling

Language (UML2.0) [7, 2]. However, they also need a sim-

ple process that ensures specifications relate consistently in

different views

To specify component models, developers usually use

protocol state machines (PSM) [2], a new diagram in

UML2.0, to describe interfaces of components. PSM spec-

ifies which operations of the interfaces can be called at

which state and under which condition, thus specifying the

allowed calls sequences of the interface methods. A proto-

col state machine presents the possible and permitted transi-

tions on the instances of its context classifier, together with

the operations that carry the transitions.

On the other hand, Use Case Maps (UCM) [3] is a vi-

sual notation used to describe functional requirements and

high level designs with causally linked responsibilities, su-

perimposed on structures of components. It is a scenario-

based approach showing cause-effects by traveling over

paths through a system. UCM is also applied in component

technology to model the execution of a scenario between

components. However, the UCM specification may be in-

compatible with PSM of component interfaces at the design

phase. As a consequence, it may lead to errors in compo-

nent software deployment.

Imagine that the interaction between component inter-

face protocols through an use case map is considered as a

running of chain gears system where each interface proto-

2009 First Asian Conference on Intelligent Information and Database Systems

978-0-7695-3580-7/09 $25.00 © 2009 IEEEDOI 10.1109/ACIIDS.2009.66

190

2009 First Asian Conference on Intelligent Information and Database Systems

978-0-7695-3580-7/09 $25.00 © 2009 IEEEDOI 10.1109/ACIIDS.2009.66

190

col plays the role as a gear and the use case map is a chain

driven. Cog-weels will be operated as a right direction. In

a similar way, a scenario specified by UCM is performed

according the order of events defined in protocol state ma-

chines.

UCMs are useful for describing multiple scenarios ab-

stractly in a single, integrated view. This promotes the un-

derstanding and reasoning about the system as a whole, as

well as the early detection of conflicting or inconsistent sce-

narios [4]. However, for complex UCMs (e.g. With many

alternative paths or with multiple levels of sub-maps), indi-

vidual scenarios become difficult to extract.

The consistency between UCM and PSM have been con-

sidered in [14]. Due to the expressive power of B nota-

tions, however, we could not describe the parallel process-

ing in the implementation machine, particularly we are not

able to express all features (such as AND-forks/joins, OR-

forks/joins) of UCMs in a B implementation machine. In

this paper, therefore, we propose an approach to check the

consistency between PSM and UCMs in component spec-

ifications using a graph algorithm in which we check each

of UCM paths extracted from UCM maps is a path in PSM

paths. This approach contributes to the verification tech-

nique in designing component models by analyzing the con-

sistency in model specifications. It can be summarized as

followings:

• Specify the component interfaces in model by UML

protocol state machines

• Describe the interaction between components to exe-

cute a task by use case maps

• Transform protocol state machines into graphical

model

• Decompose use case maps into sequential paths and

transforming them into graphical model

• Use the graph algorithm to check the conformance be-

tween UCM and PSMs

The rest of this paper is organized as follows. Section

2 presents the background of Use Case Maps and Proto-

col State Machines. Section 3 proposes a solution to verify

the conformance between PSM and UCM using the graph-

based algorithm. Section 4 discusses some related works.

We conclude and give some perspectives in Section 5.

2 Backgrounds

In this section, we give an overview of protocol state ma-

chines (PSM) and use case maps (UCM). We focus on some

basic concepts and how they are used.

2.1 Protocol state machines

When we want to show the sequence of events that an

object reacts to – and the resulting behavior – we can use

UML behavioral state diagrams. Such state diagrams have

event/action pairs, entry actions, exit actions, and do activi-

ties. 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 behavior. Such a

specified sequence is called an event protocol. In UML2.0,

we can describe event protocols by protocol state machines.

Normally we should use regular state diagrams to show

internal sequences of behavior for all objects of a class.

Sometimes, however, we want to show a complex proto-

col (set of rules governing communication) when using an

interface for a class. For example, when we are design-

ing classes that access a database for applications we need

to use common 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.

The Figure 1 shows the simple protocol state machine for

the acces database system.

DB

Created

Opened

Updated Closed

create()

open()

update()

close()

close()

Figure 1. Protocol State Machine

Since an interface of a component specifies conformance

characteristics, it does not own detailed behavior specifica-

tions. Instead, interfaces may own a protocol state machine

that specifies event sequences and pre/post conditions for

the operations and receptions described by the interface.

2.2 Use Case Maps

The Use Case Map (UCM) notation can help to describe

and understand emergent behavior of complex and dynamic

systems. They are considered as causal scenarios, architec-

tural entities, or behavior patterns. The basic idea of UCM

is captured by the phrase causal paths cutting across orga-

nizational structures. The realization of this idea produces

a lightweight notation that scales up, while at the same time

191191

covering all of the mentioned complexity factors in an in-

tegrated and manageable fashion. The notation represents

causal paths as sets of wiggly lines that enable a person to

visualize scenarios threading through a system without the

scenarios actually being specified in any detailed way (e.g.

with messages). Compositions of wiggly lines (which may

be called behavior structures) represent large-scale units

of emergent behavior cutting across systems, such as net-

work transactions, as first-class architectural entities that are

above the level of details and independent of them (because

they can be realized in different detailed ways).

Start point

Start point

End point

End point

Component

Responsibilities

Figure 2. Use Case Maps

UCMs do not have clearly defined semantics, their

strong point is to show how things work globally. The ba-

sic UCM notation is very simple. It is comprised of three

basic elements: responsibilities, paths, and components. A

simple UCM exemplifying the basic elements is shown in

Figure 2. A path is executed as a result of the receipt of

an external stimulus. Imagine that an execution pointer is

now placed on the start position. Next, the pointer is moved

along the path thereby entering and leaving components,

and touching responsibility points. A responsibility point

represents a place where the state of a system is affected or

interrogated. The effect of touching a responsibility point is

not defined since the concept of state is not part of UCM.

Finally, the end position is reached and the pointer is re-

moved from the diagram. A UCM is concurrency neutral,

that is, a UCM does not prescribe the number of threads

associated with a path. By the same token, nothing is said

about the transfer of control or data when a pointer leaves

one component and (re-)enters another one. The only thing

guaranteed is the causal ordering of executing responsibility

points along a path.

The UCM notations capability of integrating many sce-

narios in a single view is one of its strengths and is suit-

able for understanding, analyzing, and reasoning about the

system as a whole. However, individual scenarios are still

an important aspect, especially as we move towards the de-

tailed design phase and the testing phase. Scenarios which

begin at start points representing preconditions and trigger-

ing events, and they culminate with end points, which de-

scribe postconditions and resulting events. The scenarios

are said to be causal because they involve partial orders of

responsibilities and because they connect causes to effects.

Guarded choices (OR-forks) represent alternative scenarios

whereas OR-joins merge scenario paths. AND-forks in-

troduce concurrent paths which can be synchronized using

AND-joins.

3 Checking consistency between UCM andPSM

In PSM specifications, transitions are denoted by events

name while events in UCM are nodes of graphs. We thus

have to tranform PSM specification into a graph where its

edges become nodes of the graph. UCMs contain operators

such as sequence, alternatives or concurrency while PSM

contain only sequence operators. In order to check the con-

sistency between UCMs and graph of PSM in a model, we

have to eliminate alternative and concurrency operators of

UCMs by decomposing them. We finally propose a graph-

based algorithm to check the consistency between UCM de-

composed and PSM transformed.

3.1 Transforming PSM to a graph expres-sion

UML graphical notations are used to express PSM speci-

fications. A PSM is considered 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 1). We aim at

transforming the graph of PSM (G) to another graph where

edges become nodes of the new graph (G’).

In graph theory, the derived graph G′ is similar to the no-

tion 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, respec-

tively.

Definition 1. A graph G is a tuple G = (V, E, μ, ν), where

• V is the set of vertices,

• E ⊆ V × V is the set of edges,

• μ : V → LV is a function assigning labels to vertices,

• ν : E → LE is a function assigning labels to the edges.

In this definition, the edges are directed, i.e. there is an

edge from v1 to v2 if (v1, v2) ∈ E. The empty graph is

denoted by ∅.

Definition 2. A graph G′ is a derived graph of a graph G if

• V ′ = E is the set of vertices,

192192

• E′ is the set of edges, (vi′, vj

′) ∈ E′ if ∃vk′ ∈ E ∧

(vi′, vk

′) ∈ E ∧ (vk′, vj

′) ∈ E

In a reality model, we cannot read directly UML nota-

tions from an editor tool of UML, we have to save the PSM

specifications as an XMI (XML MetaData Interchange) file

type.

From the definition of the derived graph and the struc-

ture of XMI file represented PSM specifications, we give an

algorithm to convert the PSM specifications to a graph ex-

pressed the protocol execution of methods in a component.

This algorithm is presented in Algorithm 1, its complexity

is O(n3).

Algorithm 1 Transforming PSM specifications to a graph

expression

Transforming():1: Read data from XMI file to establish G = {V, E}2: Initialize V ′ = ∅, E′ = ∅3: for each i ≤ |V | do4: for each j ≤ |V | do5: for each k ≤ |V | do6: if (vi, vk) ∈ E ∧ (vk, vj) ∈ E then7: if op(vi, vk) ∈ V ′ then8: V ′ = V ′ ← op(vi, vk)9: end if

10: if op(vk, vj) /∈ V ′ then11: V ′ = V ′ ← op(vk, vj)12: end if13: E′ = E′ ← (op(vi, vk), op(vk, vj))14: end if15: end for16: end for17: end for

3.2 Decomposition of Use Case Maps

In UCMs, OR-fork/join and AND-fork/join constructs

can be used in any way to combine path segments while

integrating scenarios. They can also fork or join more

than two segments. Additionally, a UCM can have more

than one start point and more than one end point. All

of this not only increases the flexibility of the notation

for the modeler, but also makes the traversal of UCMs

quite difficult. A UCM can be seen as a graph where the

nodes are the UCM constructs and the arcs are the path

segments connecting them. Supposed that operators are

used for sequence (;), alternatives (+), and concurrency

(‖). With these operators, Figure 3 can be represented as

K;L;((N;O)+(M;(X‖(S;(T‖U)));W)).

Our goal is to obtain sequence paths from UCMs graph,

so alternative (+) and concurrency (‖) will be eliminated

from above representations. In Figure 3, we can detect

easily four potential individual scenarios (K;L;M;S;T;W,

K;L;M;S;U;W, K;L;M;X;W and K;L;N;O) without alterna-

tive and concurrency operators. The consistency between

PSM and UCMs now can be represented by the consistency

of each sequential individual scenario with PSM.

In a similar way as PSM specifications, we cannot read

directly UCM notations from an editor tool, we have to save

the UCM specifications as an XML file. The XML expres-

sion of the UCM presented in Figure 3 can be described as

follows.

<?xml version=’1.0’ standalone=’no’?><seq>

<do name="K" type="Start"/><do name="L" type="Resp"/><alt>

<seq><do name="M" type="Resp" /><par>

<do name="S" type="Resp" /><par>

<do name="T" type="Resp"/><do name="U" type="Resp"/>

</par><do name="X" type="Resp" />

</par><do name="W" type="End point" />

</seq><seq>

<do name="N" type="Resp" /><do name="O" type="End point" />

</seq></alt>

<seq>

In this XML expression, the tags < seq >, < par >, <alt > represent the sequential, concurrency and alternative

operators, respectively.

It is noted that each PSM specifies sequential events for

a component while UCM describes events interaction in

many components; hence when we check the consistency

between PSM and UCM, we cut only a segment of UCM

which traverses the component that have been represented

by PSM. From now on, when we say UCM, we mean it is

only a segment of UCM in a component.

3.3 A graph-based algorithm to check theconsistency between UCM and PSM

Recall that each UCM decomposed is a sequential sce-

nario, PSM have been transformed into a graph as described

Algorithm 1, expressing the sequential execution of events.

Decomposed PSM and UCM graph transformed can be con-

sidered as directed graphs, which are sometimes synony-

mously referred to as (attributed) relational graphs, or re-

lational structures. Such a graph consists of a finite num-

ber of nodes, or vertices, and a finite number of directed

edges. A finite number of labels are usually associated to

the nodes and edges. If we delete some nodes from a graph

G , together with their incident edges, we obtain a subgraph

G ⊆ G′ .

193193

O

ST

U WX

N

L

K

M

Figure 3. Use Case Maps

Definition 3. Given a graph G = (V, E, μ, ν), a subgraph

of G is a graph S = (Vs, Es, μs, νs) such that

• Vs ⊆ V

• Es = E ∩ (Vs × Vs)

• μs and νs are the restrictions of μ and ν to Vs and Es:

μs(v) = μ(v) if v ∈ Vs

νs(e) = ν(e) if e ∈ Es

In a software component model, the UCM and PSM are

consistent if each of sequential paths in the UCM is a path in

the PSM. It means that the graph expressing the execution

of the decomposed UCM is a subgraph of the one which

have been transformed from the PSM. From the definition

of subgraphs in Definition 3, we build an algorithm to check

the consistency between UCM and PSM as presented in Al-

gorithm 2.

Algorithm 2 Checking consistency between PSM (G) and

UCM (S)

cc← ConsistencyCheck (S, G):

1: Decomposing UCM, result is an array of sequential

graphs Si

2: for each graph Si do3: check if VSi ⊆ V4: check if ESi

= E ∩ (VSi× VSi

)5: for each vj ∈ VSi

do6: check if μSi

(vj) = μ(vj)7: end for8: for each ek ∈ ESi do9: check if νSi

(ek) = ν(ek)10: end for11: end for12: cc = TRUE if all conditions are true

Decomposing a UCM specification to an array of se-

quential graphs is similar to the problem of finding all paths

between two nodes in a directed graph. It has been resoved

in the article [13]. In this algorithm, the segment code from

the line 3 to line 10 is used to check if each graph Si is a

subgraph of G. The time complexity of this algorithm is

estimated (O(n2)).

4 Related work

Scenarios are recognized as a valuable representation to

be used at all phases of the software engineering process.

They are usually specified efficiently using UCMs. One ap-

proach of definitions and transformations of scenarios have

been stated in [6]. This paper addresses the challenges

faced during the automated generation of individual scenar-

ios from UCM specifications which enables the validation

of requirements and facilitates the transition from require-

ments to design. Scenario definitions and traversal algo-

rithms are first used to extract individual scenarios from

UCMs and to store them as XML [4] files. Transforma-

tions to other scenario languages (for instance, Message Se-

quence Charts) are then achieved using XSLT. Possible ap-

plications of this two-step generation process include early

validation and synthesis of design models.

Several proposals for verifying the consistency in com-

ponent specification have been made in literature.

The paper [11] presents a tool called Cadena, an inte-

grated environment for building and modeling CCM sys-

tems. Cadena provides facilities for defining component

types using CCM IDL, specifying dependency information

and transition system semantics for these types, assembling

systems from CCM components, visualizing various depen-

dence relationships between components, specifying and

verifying correctness properties of models of CCM systems

derived from CCM IDL, component assembly information,

and Cadena specifications, and producing CORBA stubs

and skeletons implemented in Java.

As a point of comparison, this paper generated a DSpin

model for the scenario that check the number of timeouts

issued in a system execution.

In [9, 10], protocols are specified using a temporal logic

based approach, which leads to a rich specification for com-

ponent interfaces. Henzinger and Alfaro [5] propose an ap-

proach allowing the verification of interfaces interoperabil-

ity based on automata and game theory.

The paper [12] proposes the Port State Machine (PoSM)

to model the communication on a port. Building on the

experience with behavior protocols, the paper models an

operation call as two atomic events request and response,

permitting PoSM to capture the interleaving and nesting of

194194

operation calls on provided and required interfaces of the

port. The trace semantics of PoSM yields a regular lan-

guage. They apply the compliance relation of behavior pro-

tocols to PoSMs, allowing to reason on behavior compli-

ance of components in software architectures.

In conclusion, all of above approaches mainly focus on

techniques for representing, modeling, transforming from

UCMs into specific languages at programming and testing

phase but do not consider the consistency between PSM and

UCM in the model.

In previous work [14], we used the B notation to specify

PSM and UCM and using B prover to check the consis-

tency between them. However, B-based approaches have

faced problems of expressive power of B notations. Partic-

ularly, they cannot describe the parallel processing in the

implementation machine, as well as not possible to express

all features (such as AND-forks/joins, OR-forks/joins) of

UCMs in a B implementation machine. In this paper, we

proposed an approach using a graph algorithm to solving

efficiently the expression problem of UCM features.

5 Concluding remarks

We have presented an approach for checking component-

based software models. In this method, the order execu-

tion of methods in each component interfaces is specified

by PSM. The communication of component composition is

described by UCM. PSMs and UCM are then transformed

to a graph model in order to check the consistency between

these specifications. Our contribution includes identifying

the consistency properties between UCM and PSMs and

using a graph-based algorithm to check their consistency.

With the proposed algorithm, we overcome disadvantages

of B notation in representing concurrency processing also

some other features in UCM.

A support tool which can be used to edit PSM and

UCM for component models is being built. We will inte-

grate the verification part into this tool in order to ensure

the consistency between different views of the specification.

Acknowlegments. This work is partially supported by

the project ”Methodologies and Tools for Component-based

Software Engineering” and by the research grant of College

of Technology, Vietnam National University, Hanoi.

References

[1] Sun Microsystems, JavaBeans 1.01 Specification,

http://java.sun.com/beans.

[2] http://www.omg.org.

[3] http://www.usecasemaps.org/.

[4] World Wide Web Consortium, XML,

http://www.w3c.org/XML/.

[5] L. Alfaro and T. A. Henzinger. Interface automata. In 9thAnnual Symposium on Foundations of Software Engineer-ing, pages 109–120. ACM press, 2001.

[6] D. Amyot, X. He, Y. He, and D. Y. Cho. Generating sce-

narios from Use Case Map specifications. In Third Interna-tional Conference On Quality Software, page 108, 2003.

[7] G. Booch, J. Rumbaugh, and I. Jacopson. The Unified Mod-eling Language User Guide. Addison-Wesley, 1998.

[8] G. Eddon and H. Eddon. Inside COM+ Base Services. Mi-

crosoft Press, 2000.[9] J. Han. A comprehensive interface definition framework for

software components. In Asia Pacific software engineeringconference, pages 110–117. IEEE Computer Society, 1998.

[10] J. Han. Temporal logic based specification of component

interaction protocols. In Proceedings of the Second Work-shop on Object Interoperability ECOOP’2000, pages 12–16.

Springer-Verlag, 2000.[11] J. Hatcliff et al. Cadena: an integrated development, analy-

sis, and verification environment for component-based sys-

tems. In Proceedings of 25th International Conference onSoftware Engineering, pages 160– 172, 2003.

[12] V. Mencl. Specifying component behavior with port state

machines. Electronic Notes in Theoretical Computer Sci-ence, 101C:129–153, 2004. Special issue: Proceedings of

the Workshop on the Compositional Verification of UML

Models.[13] M. Migliore, V. Martorana, and F. Sciortino. An algorithm

to find all paths between two nodes in a graph. J. Comput.Phys., 87(1):231–236, 1990.

[14] N. Truong, V. Tran, and V. Nguyen. Consistency be-

tween UCM and PSMs in component models. In Interna-tional Conference on Research, Innovation and Vision forthe Future in Computing and Communication Technologies(RIVF), pages 184–189, 2008.

195195