EVALUATING CONSISTENCY BETWEEN UML ACTIVITY AND

SEQUENCE MODELS

Yoshiyuki Shinkawa

Department of Media Informatics, Ryukoku University, 1-5 Seta Oe-cho Yokotani, Otsu, Shiga, Japan

Keywords:

UML, software engineering, model consistency, formal methods, process algebra.

Abstract:

UML activity diagrams and sequence diagrams describe the behavior of a target domain or a system from

different viewpoints. When we use these diagrams for modeling the same matter in an application, these di-

agrams, or the models written by them, must be consistent from each other. However, the evaluation for the

consistency is difﬁcult, since these diagrams have considerably different syntax and semantics. This paper

presents a process algebraic approach to evaluating the consistency between these models. CCS (Communi-

cating Sequential Processes) is used as process algebra.

1 INTRODUCTION

UML activity diagrams and sequence diagrams de-

scribe a target problem domain or a system from two

different contrastive viewpoints. The former mainly

focus on the usage and external behavior of the sys-

tem, whereas the latter deal with the interaction be-

tween components within the system and depict the

internal behavior of it (Ambler, 2004).

In dynamic or behavioral modeling for software

development, one of the most effective uses of these

diagrams is to represent a requirement model by ac-

tivity diagrams, for which the implementation model

is created using sequence diagrams. In this approach,

both the requirement and implementation models

must be consistent, or in other words, there must be no

conﬂicts between these models (Elaasar and Briand,

2004).

However it seems difﬁcult to examine and eval-

uate the consistency, since both the models are rep-

resented in the different notations with different syn-

tax and semantics. In addition, the granularity is of-

ten different between these models, which makes the

evaluation more complicated.

In order to evaluate the consistency rigorously, we

ﬁrst need to reveal the interrelationship between these

two models. This interrelationship can be shown in

the form of the correspondence between each model

element of these models.

However, even though the above element level in-

terrelationship is revealed, it only suggest structural

similarity of the models. For the evaluation of inter-

model consistency, we have to identify

1. what the models intend to express,

2. what conditions must be met for the consistency,

and

3. what inference rules can be applied to conclude

the consistency.

Unfortunately, UML is too vague and complicated

to accomplish the above. We need more formalized

and simpliﬁed way to express the behavior of UML

activity and sequence models

Various efforts have been made to formalize

UML models, using such formal techniques as logic

(France et al., 1997), Petri-nets (Hu and Shatz, 2004),

algebraic speciﬁcation (Favre and Clerici, 1999),

and other formal techniques (McUmber and Cheng,

2001).

The above formal approaches can express the be-

havior and semantics of each individual model rigor-

ously, however few efforts were made to evaluate the

inter-model consistency including activity-sequence

model consistency (Shinkawa, 2006).

This paper presents a formal approach to evalu-

ating the consistency between a UML activity model

and a sequence model. The paper is organized as fol-

lows. In section 2, we discuss the relationships be-

tween a UML activity model and a sequence model

between which the granularity might be different.

In this paper, we refer to a model composed of UML

activity diagram as an activity model, or as a sequence

model if it is composed of sequence diagrams.

282

Shinkawa Y. (2008).

EVALUATING CONSISTENCY BETWEEN UML ACTIVITY AND SEQUENCE MODELS.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 282-289

DOI: 10.5220/0001699302820289

 SciTePress

Section 3 presents a process algebraic representation

of these UML models. CCS (Communicating Se-

quential Processes) (Milner, 1989) is used as process

algebra. Section 4 presents how the consistency be-

tween an activity model and a sequence model is eval-

uated using CCS.

2 INTERELATIONSHIPS

BETWEEN ACTIVITY AND

SEQUENCE MODELS

UML 2.x provides us with thirteen different kinds of

diagrams, which can be classiﬁed into two groups of

structural diagrams and behavioral diagrams. The

former includes class, object, component, deploy-

ment, and package diagrams, whereas the latter in-

cludes use-case, sequence, communication, timing,

interaction overview, state-machine, and activity di-

agrams.

Even though each diagram can expresses various

target domains from various viewpoints, and there are

no deﬁnite restrictions on which diagrams to be used

for a speciﬁc purpose, the activity diagram and se-

quence diagram perform important roles in behavioral

modeling for business applications and enterprise in-

formation systems. Both diagrams depict the behav-

ioral or dynamic aspects of a system, however the

viewpoints are different, from which the models are

created.

An activity model, which is composed of activ-

ity diagrams, is created from an external viewpoint.

For example, in business applications, they often used

to represent business processes or workﬂows which

can be observed externally. On the other hand, a

sequence model is usually created from an internal

viewpoint, and represents interactions between ob-

jects or classes that compose a system. These inter-

actions occur within the system, which cannot be ob-

served externally.

We often create these two models for the same

matter in an application, one of which represents the

external behavior and the other does the internal be-

havior. In such case, no conﬂicts are allowed be-

tween them, or they must be consistent from each

other. However, the evaluation of the consistency be-

tween these models becomes complicated since the

model elements and their relationships are consider-

ably different between these models. In addition, the

granularity of these models might be different, which

makes the evaluation more complicated.

For this evaluation, we ﬁrst have to reveal the

structural interrelationship between these two models

which might have the different granularity. Succes-

sively we need to deﬁne the meaning of the consis-

tency between the models.

2.1 Structural Interrelationships

An activity model represents the behavior of a system

as a ﬂow of actions. An action is an atomic unit of the

behavior, which is connected with other actions using

directed arrows called ﬂows. There are two kinds of

ﬂows deﬁned, namely control ﬂows and object ﬂows,

which represent simple control sequences and mes-

sage passing respectively.

In addition to these two basic model elements, the

following complementary elements are provided

• Initial and ﬁnal nodes: represent the starting and

ending points of an activity model respectively.

• Fork and join nodes: A fork node splits a single

ﬂow into multiple parallel ﬂows, while a join node

synchronizes multiple parallel ﬂows into a single

ﬂow.

• Decision and merge nodes: A decision node im-

plements a conditional branch, which splits sin-

gle ﬂow into multiple ﬂows with conditions. Each

ﬂow becomes active only when the associated

condition is true. A merge node consolidates the

above split ﬂows.

• Accept event action and send signal actions: An

event and a signal represent interactions with ex-

ternal participants, e.g. people, systems, or pro-

cesses. An accept event action is an action that

waits for such events, while a send signal action

is an action that generates and sends a signal ac-

cording to the events. Events and signals may oc-

cur asynchronously.

• Exception handlers: An exception handler deals

with exceptional events that occur within the ac-

tivity,

• Data store nodes: A data store node represents a

place for persistent data, e.g. a database system.

• Expansion regions: An expansion region includes

action ﬂows inside, and processes an input collec-

tion like an array. The region is processed in one

of three modes, iteration, parallel, or stream.

• Interruptible activity regions: An action within

these regions can be interrupted by an event fol-

lowed by an action that handles it.

An activity model that is composed of the above ele-

ments can be divided into partitions, in order to em-

phasize the actors or participants that are responsible

to the activity, or to emphasize the functionality that

each partition performs.

EVALUATING CONSISTENCY BETWEEN UML ACTIVITY AND SEQUENCE MODELS

283

Unlike an activity model, a sequence model repre-

sents the behavior of a system as interactions between

objects, classes, or actors.

The simplest form of a sequence model is made

up of a set of lifelines along with the messages that

ﬂow between them. A point on a lifeline, from which

a message is leaving, is called a sending event occur-

rence, while a point at which a message is arriving is

called a receiving event occurrence. There are sev-

eral types of messages deﬁned, namely synchronous

messages and their return values, asynchronous mes-

sages, creation messages, lost messages, and found

messages.

In addition to the above basic elements, the fol-

lowing supplementary model elements are deﬁned.

• Execution occurrences: An execution occurrence

is a thin rectangle on a lifeline, which indicates

that the lifeline is active. If the lifeline represents

an object or class, it means the execution of meth-

ods.

• Interaction occurrences: An interaction occur-

rence represents a reference to another sequence

model.

• Gates: A gate is used to connect a message to a

port outside the current sequence model.

• State invariants: A state invariant expresses a con-

straint at a speciﬁc point on a lifeline.

• Combined fragments: A combined fragment is

used to express complicated control ﬂows, e.g. it-

erations, concurrency, conditional breaks, and so

on. The following types of combined fragments

are deﬁned.

– alt: indicates the if-then-else structure

– opt: indicates the simple if structure

– break: indicates the exit from the fragment

– loop: indicates the iteration structure

– par: indicates the concurrent or parallel execu-

tion

– seq: indicates the sequence of the messages is

imposed only to the same lifeline in this frag-

ment

– strict: indicates the messages must be pro-

cessed strictly in the given order in this frag-

ment

– critical: indicates the fragment is a critical sec-

tion, that is, it must not be interrupted

– assert, ignore, consider, neg: these are used as

comments to the fragment.

As shown above, an activity model and a sequence

model consist of considerably different model ele-

ments. One of the most fundamental model elements

in these models are an action and a message respec-

tively.

Each action in an activity model is performed by

either a person or a system. In case of a system, a

method in an object or a class is invoked manually or

automatically. On the other hand, a message in a se-

quence model reaches to either an object, a class, or

an actor. In case of an object or a class, an method in

it is invoked at the receiving event occurrence. There-

fore, actions and messages or receiving event occur-

rences are tied together through methods, as far as

they are dealt with objects or classes.

In order to deﬁne the structural interrelationships

between activity models and sequence models, we

ﬁrst regard actions in the former are interrelated with

receiving event occurrences in the latter. This deﬁni-

tion implies that the ﬂows in the former are interre-

lated with the messages in the latter.

Based on this basic interrelationship between

these models, other model elements can be interre-

lated as shown in Table 1.

Table 1: Interrelationships between activity and sequence

models.

Activity Model Sequence Model

Initial node The topmost sending event

occurrence

Final node The bottommost receiving

event occurrence

Decision/Merge node alt or opt fragment

Fork/Join node par fragment

Accept event action gate and a dedicated

lifeline

Send signal action gate and a message to it

Exception handler found message and a

dedicated lifeline

Data store node A dedicated lifeline for

data store

Expansion regions Combined fragment

parallel par

iterate loop

stream arguments of a message

There are several elements that are not interre-

lated, e.g. interruptible activity region in a activity

model or state invariant in a sequence model. These

are referred to in section 3.

2.2 Difference in Granularity

An activity model and a sequence model are often

created from different viewpoints, involving differ-

ent stakeholders. Therefore, classes and the meth-

ods within them are differently deﬁned between those

ICEIS 2008 - International Conference on Enterprise Information Systems

284

models, with different granularity and functional

boundaries.

The word “granularity” is often used vaguely in

several contexts. However in our consistency eval-

uation, methods in classes or objects are the com-

mon units between an activity model and a sequence

model, in order to match an action with a receiving

event occurrence. Therefore we only focus on the

granularity of the methods in this paper. When con-

sidering the granularity, there are two different stan-

dards to determine it. One is the abstraction level, and

the other is the scope of input to be processed.

The granularity based on the abstraction level can

place the associated methods in order. The granularity

of a method with higher abstraction level is larger or

coarser than that with lower abstraction level. For ex-

ample, in modeling the betting round of poker games,

a method “bet(int x)” is more abstract than that of

“raise(int x)”, “call()”, and ‘fold()”. The granularity

based on the abstraction level is formally deﬁned as

follows.

1. Let f and g be methods that are deﬁned as

f : P

× ··· × P

(= P) → R

g : Q

× ··· × Q

(= Q) → R

2. If {P

} ⊆ {Q

} and ∀~x ∈ P ∃~y ∈ Q [ f(~x) = g(~y)]

hold, the method g has larger granularity then f,

based on the abstraction level.

The granularity of a method f is denoted by γ( f),

and γ( f)  γ(g) represents that the granularity of g

is larger than or equals to f. We can deﬁne the inter-

section and difference of methods in such case. As-

suming γ( f )  γ(g),

f ∩ g = f

g− f : Q

× ··· × Q

− {~y} → R

On the other hand, the granularity based on the

input scope is deﬁned as follows.

1. Let two methods f and g have the same signature.

2. If If Dom( f) ⊆ Dom(g) and

∀~x ∈ Dom( f) [ f(~x) = g(~x)]

hold, the method g has the larger granularity than

3. If Dom( f) ∩ Dom(g) 6=

0, Dom( f) * Dom(g),

Dom( f) + Dom(g), and

∀~x ∈ Dom( f) ∩ Dom(g) [ f(~x) = g(~x)]

hold, f and g intersect, and have the different

functional boundaries.

The intersection and difference of methods can also

be deﬁned in such case as follows.

f ∩ g : Dom( f ) ∩ Dom(g) → Im(g)

g− f : Dom(g) − Dom( f) → Im(g)

where Im(g) is the co-domain of g.

We can deﬁne the common methods between an

activity model and a sequence model using the above

intersection of methods, when the granularity or func-

tion boundaries are different between them. The de-

tail is discussed in section 4.

3 EXPRESSING THE BEHAVIOR

USING PROCESS ALGEBRA

As discussed in section 1, an activity model represents

the external behavior of a system, while a sequence

model represents the internal behavior of it. In other

words, a sequence model realizes the corresponding

activity model. From this viewpoint, we ﬁrst deﬁne

the meaning of consistency as “all the behavior in an

activity model must occur in the corresponding se-

quence model, but not vice versa”. Or in other words,

any action sequence in the activity model must oc-

cur as a series of event occurrences in the sequence

model. However, this deﬁnition is still vague, and we

need to deﬁne the behavioral consistency more rigor-

ously. For this purpose, we introduce process alge-

bra, by which we express the behavior more rigor-

ously and evaluate the consistency accurately.

3.1 Process Algebra and Behavioral

Equivalency

Process algebra deals with system behavior as al-

gebraic expressions using rigorously deﬁed calcu-

lus rules. There have been several process algebras

proposed, which include CCS (Milner, 1989), CSP

(Hore, 1985), and ACP (Bergstra and Klop, 1985).

Among them, we use CCS as a consistency evaluation

tool, since it treats behavioral equivalency in depth,

and there is a standardized speciﬁcation language LO-

TOS (Ardis, 1994) based on CCS. CCS represents

each behavior of a system as an algebraic expression

called a process behavior expression or process ex-

pression in short. These process expressions are de-

ﬁned recursivelyas shown in the upper part of Table 2.

The most primitive unit of a CCS process expression

is an action, which transforms a process to another

one. CCS regards a system as a transition system be-

tween processes caused by the aboveactions. Axioms

or inference rules for these transitions are deﬁned as

CCS semantics shown in the lower part of Table 2.

EVALUATING CONSISTENCY BETWEEN UML ACTIVITY AND SEQUENCE MODELS

285

Table 2: CCS Syntax and Semantics.

CCS Syntax

L = A ∪ A (A : set of names A : set of conames )

Act = L ∪ {τ} ( τ : invisible action)

X : a set of process variables

K : a set of process constants

E : a set of process expressions

E includes X and K and contains the following

expressions, where E and E

are already in E

α.E a Preﬁx

∑

k∈I

a Summation (if I = {0,1} then E

+ E

)

a Composition

E \ L a Restriction

E[ f ] a Relabelling (f is a relabelling function)

µx

= E

} a Recursion

CCS Semantics

ACT :

α.E

−→E

SUM

−→E

′

∑

k∈I

−→E

′

( j ∈ I)

COM

−→E

′

E|F

−→E

′

COM

−→F

′

E|F

−→E|F

′

COM

−→E

′

−→F

′

E|F

−→E

′

RES :

−→E

′

E\L

−→E

′

(α,

α /∈ L) REL :

−→E

′

E[ f]

f(α)

−→E

′

[ f]

CON :

−→P

′

−→P

′

de f

= P) REC :

{µ˜x.

E/˜x}

−→E

′

µ˜x.

f(α)

−→E

−→ P

′

means a transition from state P to

state P

′

by action α.

Behavioral equivalency between two processes

is deﬁned based on the transitions they can make.

Many kinds of equivalency relations can be deﬁned in

CCS, however the most useful ones are strong equiv-

alence, weak equivalence, and observation congru-

ence, which are shown in Table 3. Among these

equivalency relations, observation congruence seems

most suitable for our consistency evaluation since

1. it can deal with an internal or invisible action “τ”

which can represent human actions in an activity

model or internal codes in a sequence model.

2. we can substitute any processes with observation-

ally congruent other processes, that is, the obser-

vation congruence

∼

is a congruence relation.

3.2 Transforming an Activity Model

into CCS Expressions

In a UML activity model, an action is a basic unit

of the behavior and can be regarded as a member

of Act (a set of actions) in CCS. Since an action in

an activity model is associated with a method with

arguments and a return value, it can be denoted by

a(~x). Onother model elements in an activity model

are represented in the form of CCS as follows.

Table 3: Equivalency between CCS Expressions.

Strong Bisimulation and Strong Equivalence

Let P, Q be processes, a binary relation S ⊆ P× P

for all α ∈ Act

∀α(P

−→ P

′

) ∃Q

′

−→ Q

′

and hP

′

i ∈ S)

∀α(Q

−→ Q

′

) ∃P

′

−→ P

′

and hP

′

i ∈ S)

∼= ∪ S : S is strong bisimulation

P and Q is strongly equivalent if P ∼ Q.

Bisimulation and Weakly Equivalence

Let P, Q be processes, a binary relation S ⊆ P× P

for all α ∈ Act

∀α(P

=⇒ P

′

) ∃Q

′

=⇒ Q

′

and hP

′

i ∈ S)

∀α(Q

=⇒ Q

′

) ∃P

′

=⇒ P

′

and hP

′

i ∈ S)

≈= ∪ S : S is bisimulation

P and Q is weakly equivalent if P ≈ Q

where

=⇒ P

′

means P(

−→)

∗

−→ (

−→)

∗

′

t = α

... α

t ∈ (Act)

∗

a string made from t, removing all “τ”s

=⇒

de f

−→ (τ)

∗

−→ . ..(τ)

∗

−→ (τ)

∗

Observation Congruence

P and Q are observationally congruent, if

∀α(P

=⇒ P

′

) ∃Q

′

=⇒ Q

′

and P

′

≈ Q

′

)

∀α(Q

=⇒ Q

′

) ∃P

′

=⇒ P

′

and P

′

≈ Q

′

)

we write P

∼

Q when P and Q satisﬁes the above.

Initial and Final Nodes. An action a that is directly

connected to the initial node means the ﬁrst action

to be taken in the model, while an action b that is

directly connected to the ﬁnal node means the last

action. Therefore the whole model can be denoted

by a.E.b, where E is an interim process between a

and b. The process preﬁx form E.b is not a standard

CCS notation, however a CCS based speciﬁcation

language LOTOS introduces this form.

Fork and Join Nodes. When an action a is split

into n processes E

,...,E

, which subsequently are

merged into an action b, the whole process can be

expressed as a.(E

|···|E

).b.

Decision and Merge Nodes. In order to represent a

decision node, we need to express guard conditions

associated with it. However CCS does not provides

us with any way to describe the conditions. Therefore

we introduce a new property to actions, which

associates a condition with an action. A condition

c that is associated with an action a is denoted by

a[c] in this paper, similarly to LOTOS. If one of

the actions b

,...,b

is performed after an action a

according to the conditions c

,...,c

, the process is

expressed as a.(b

] + ···+ b

]).

Accept Event Actions and Send Signal Actions.

An accept event action is an action that receive an

ICEIS 2008 - International Conference on Enterprise Information Systems

286

asynchronous message to be processed. This action

can be represented as a CCS action r, and the whole

process is expressed using the CCS composition as

|r.E

, where E

is a process for the normal case and

is a process to handle the asynchronous message.

On the other hand, a send signal action creates an

instance of a signal, which is transmitted to another

action called receive signal action.These send/receive

actions are expressed as CCS actions associated with

a name and its co-name. The action with the co-name

does not occur in the CCS expression if the receive

signal action belongs to another activity model.

Exception Handler. An exception handler is

an action that deals with exceptional events. An

exceptional event may occur synchronously or asyn-

chronously according to the type of the exception. A

synchronous exception handler is expressed similarly

to an action after a merge node. On the other hand,

in case of an asynchronous exception, there are two

possible behaviors that the process shows. One is

the behavior that the exception handler interrupts

the normal process to terminate it. The other is the

behavior that the handler is concurrently scheduled

with the normal process. Assuming the exception

handler is e, the former is expressed in CCS as

∑

where E

is a possible process before the exception,

while the latter is expressed as E|

∑

.e, where E

represents the normal process.

Data Store Nodes. A data store node itself is not a

part of the behavior, however the access to the data

store node can be regarded as an action to be included

in the process.

Expansion Regions. An expansion region deals with

a list or array of input data in either iterative, parallel,

or stream mode. An iterative mode represents a

while loop, and can be expressed as a recursion

µx.[x = E.(x+ s)], where E is the process within the

region and s is the ﬁrst action after the region. A

parallel mode represents a concurrent processing, and

expressed as E|··· |E. A stream mode represents that

all the input elements are processed at the same time,

and can be simply expressed as E in CCS.

Interruptible Activity Region. An interruptible ac-

tivity region represents a region within which any ac-

tions can be interrupted by other events. The behav-

ior of this region resemble an asynchronousexception

handler, and can be expressed as

∑

.e, where e is an

event handler action.

3.3 Transforming a Sequence Model

into CCS Expressions

In a UML sequence model, a message or its receiving

event occurrence corresponds to an action in an activ-

ity model and an action in CCS expressions. When

synchronous messages m

,...,m

ﬂow in the model

in this order, the process is expressed as a series of

action preﬁxes α.m

.....m

, where α is the initial ac-

tion of the sequence model, which represents the exe-

cution occurrence that includes m

On the other hand, an asynchronous message

splits the process into two concurrent processes, and

therefore the process is expressed as E

.(E

|a.E

where E

is the process before the asynchronous mes-

sage a, E

is the normal process after a, and E

is a

yieled process by a.

More complicated control structures provided by

combined fragments are expressed in the form of

CCS as follows.

Alt Fragments and Opt Fragments. An alt frag-

ment represents the if-then-else structure, and can

be expressed in CCS using guard conditions as

].E

+ a

].E

, where a

is the ﬁrst action in

the upper or the lower section of the fragment, and

is the guard condition that activate the upper or

lower section. a

represents the process within

the section. An opt fragment represents a simple if

structure, and can be expressed as a[c].E.

Loop Fragments. A loop fragment is expressed as

µx.[E.(x[c] + s[¬c])], where x is a process variable

that represents the fragment, E is the process expres-

sion within the fragment, c is the guard condition

for the loop, and s is the ﬁrst action taken after the

fragment.

Break Fragment. A break fragment represents a

process to terminate the outer fragment to which this

fragment directly belongs. This fragment forms an

exit point of the outer fragment. The break fragment

is associated with a condition c for terminating the

outer process, and the outer fragment is expressed

as E

.(E

[c].0 + E

[¬c]), where E

is the process

before the break fragment, E

is the process within

the break fragment, and E

is the process after the

break fragment.

Par Fragments. A par fragment represents a con-

current execution of processes and simply expressed

in CCS using the process composition as E

|···|E

where E

is the process within each section in the

fragment.

EVALUATING CONSISTENCY BETWEEN UML ACTIVITY AND SEQUENCE MODELS

287

Critical Fragments. A critical fragment represents

a process that halts all other processes outside the

fragment. In order to implement this fragment, we

need a lock mechanism in CCS. For this purpose, we

introduce a special variable l that represents a lock,

and special actions lock(l) and unlock(l) which set

and reset the lock respectively. The critical fragment

is expressed as lock(l).E.unlock(l), while all the

other processes that are concurrently performed with

this fragment are associated the condition “the lock l

is reset”.

Seq Fragment. A seq fragment represents that the

sequence of messages can be interchanged within the

fragment. A process within the fragment is expressed

as a summation of process preﬁxes

∑

6=ı

.....a

where a

is an action that represents a message in the

fragment.

Strict Fragments. A strict fragment represents that

the sequence of messages must be arranged along the

lifelines. In CCS expressions, action preﬁxes satisfy

this constraint, therefore the process can be expressed

as a

.....a

, where a

means the ith message in

the fragment.

Other Fragment Types. Other fragment types like

assert, ignore, etc. are used to make comments to a

sequence model. Therefore they also are treated as

comments in CCS expressions.

In addition to the above model elements, there are

several supplementary elements, namely, gates and

state invariants. A gate is used to send a message

to, or to receive a message from an object outside the

model. A gate can be implemented in CCS by con-

necting the processes like E

where E

is the pro-

cess before the gate and E

is the process outside the

model. A state invariant is a condition that must be

satisﬁed after a speciﬁc message, however it can be

treated as a comment in CCS.

4 CONSISTENCY EVALUATION

Once an activity model and a sequence model are ex-

pressed in the form of CCS process expressions, we

can evaluate the equivalency between them using the

observation congruence relation as discussed in sec-

tion 3.1. However, there are several considerations to

be taken into account.

Firstly, all the corresponding actions between

these models must have the same granularity and

functional boundaries as discussed in section 2.2.

Secondly, there might be the actions that occur in only

one model type, e.g. an action associated with human

interactions would occur only in the action model,

whereas an action associated with the internal codes

of a system would occur only in the sequence model.

In order to adjust these differences between the

models, the process expressions may have to be re-

constructed using the communized actions based on

the communized methods that were introduced in sec-

tion 2.2. Assuming there are two sets of CCS expres-

sions E = {E

,...,E

} and F = {F

,...,F

} that are

derived from an activity model and a sequence model

respectively, this reconstruction can be performed in

the following way.

1. Let { a

,...,a

} and {b

,...,b

} be the actions

which are included in E and F respectively.

2. For each action a

in the activity models, identify

a set of activities {b

} in the sequence model that

satisﬁes

∀ j, k ( j 6= k) [a

∩ b

0, b

∩ b

3. Deﬁne a new action a

= a

∩ b

. If there is no

such b

, replace a

by the CCS invisible action τ.

Similarly replace b

by τ if there is no such a

4. Decompose E

,...,a

) into a set of

expressions {E

,...,a

)} and

( ˜a

, ˜a

,..., ˜a

), where ˜a

= a

−

[

∩ b

5. Similarly, decompose F

,...,b

) into

,...,a

} and F

(

,...,

where

= b

−

[

∩ b

6. Each E

,...,a

) and F

,...,b

) are ex-

pressed using the common actions {a

} as

∑

··· j

,...,a

) + E

( ˜a

,..., ˜a

)

∑

··· j

,...,a

) + F

(

,...,

)

Following the above steps, the CCS expressions for

the activity model and sequence model include the

set of common activities {a

} and the exclusive ac-

tions { ˜a

} or {

}, along with the invisible action “τ”.

Since { ˜a

} and {

} are not interrelated between the

models, they are to be replaced by “τ”.

Even after commonizing the actions between the

models, there are two more considerations in our ap-

proach. One is the guard conditions that are not in-

cluded in the original CCS deﬁnition. The other is

the process preﬁx or the sequential composition E

that also are not included originally. Since there is no

procedure provided to evaluate the equivalency be-

tween the process expressions with these elements,

we have to develop a procedure.

ICEIS 2008 - International Conference on Enterprise Information Systems

288

A process preﬁx E

can be transformed into a

a regular CCS expression as follows.

1. Identify the ﬁnal elements {A

} in E

. A ﬁnal ele-

ment is either an action a

that occurs in the form

of a

.0 or a recursion µx.[x = E].

2. Identify the initial elements B

in E

. A initial

element is either an action with no preﬁx or a re-

cursion with no preﬁx.

3. E

is transformed into

∑

i, j

where E

is the process that ends with A

and F

is the pro-

cess that begins with B

If A

is a recursion, it is expressed as µx.[x = E.(x+0)]

in our approach, and E.(x+ 0) can be decomposed

in the above way. In case of B

, it is expressed as

µx.[x = E.(x+ E)] and can be treates similarly.

As for the guard conditions, we can introduce the

observation congruence with a condition “c”, which

is denoted by P

∼

[c]

Q as follows.

∀α(P

α[c]

=⇒ P

′

) ∃Q

′

α[c]

=⇒ Q

′

and P

′

≈ Q

′

)

∀α(Q

α[c]

=⇒ Q

′

) ∃P

′

α[c]

=⇒ P

′

and P

′

≈ Q

′

)

In the above deﬁnition, α[c] means that the action α

can be taken only under the condition c. This con-

ditional transition can also be applied to the CCS se-

mantics in Table 2,

Ideally, one CCS expression in the activity model

corresponds to that in sequence model. However, a

behavior in the activity modelmay correspond to mul-

tiple behaviors in the sequence models, or vice versa.

In such case, we need to decompose CCS expres-

sions into appropriate sizes. This decomposition is

performed by extracting a continuous part of an ex-

pression.

5 CONCLUSIONS

A process algebraic approach to evaluating consis-

tency between a UML activity model and a sequence

model is proposed. The behavior of an activity model

is characterized by a series of actions, while that of an

sequence model is characterized by a series of mes-

sages. The behavior of these models must be con-

sistent if they represent the same problem domain or

system. The consistency can be evaluated using CCS,

a kind of process algebra, if the behavior is expressed

in the form of CCS process expressions.

For this evaluation, the granularity and functional

boundaries of corresponding actions must be equal-

ized between these models. The equalization is per-

formed by a set theoretic adjustment. Even though

activity and sequence models show very different ap-

pearances, CCS can express them in the uniﬁed form.

The behavioral equivalency, which forms the

foundation of the consistency between models, is

evaluated using CCS observation congruence rela-

tion. This relation is extended to deal with conditions

that are introduced to represent the complicated con-

trol ﬂows in UML models. Similar to the differences

in each action, each CCS expression might have the

different granularity from each other. It can be re-

solved by decomposing the expressions.

REFERENCES

Ambler, S. W. (2004). The Object Primer, Third Edition.

Cambridge University Press.

Ardis, M. A. (1994). Lessons from using basic LOTOS.

In Proc. of the 16th International Conference on Soft-

ware Engineering (ICSE94), pages 5–14. EEEE.

Bergstra, J. A. and Klop, J. W. (1985). Algebra of Com-

municating Processes with Abstraction. In Theoreti-

cal Computer Science, Elsevier Science, volume 37,

pages 77–121.

Elaasar, M. and Briand, L. C. (2004). An Overview of UML

Consistency Management. Technical Report SCE-04-

18, Carleton University.

Favre, L. and Clerici, S. (1999). Integrating uml

and algebraic speciﬁcation techniques. In Proc.

of 32nd International Conference on Technology of

Object-Oriented Languages and Systems(TOOLS’99),

pp.151-162. IEEE.

France, R. B., Bruel, J. M., Larrondo-Petrie, M. M., and

Shroff, M. (1997). Exploring the semantics of uml

type structures with z. In Proc. of 2nd IFIP confer-

ence, Formal Methods for Open Object-Based Dis-

tributed Systems(FMOODS’97), pp.247-260. Chap-

man and Hall.

Hore, C. A. R. (1985). Communicating Sequential Pro-

cesses. Prentice-Hall International UK Ltd.

Hu, Z. and Shatz, S. M. (2004). Mapping UML Diagrams to

a Petri Net Notation for System Simulation. In Proc.

of the International Conference on Software Engineer-

ing and Knowledge Engineering (SEKE), pages 213–

219.

McUmber, W. E. and Cheng, B. H. C. (2001). A gen-

eral framework for formalizing uml with formal lan-

guages. In the 23rd International Conference on Soft-

ware Engineering (ICSE 2001), pp.433-442. EEEE.

Milner, R. (1989). Communication and Concurrency. Pren-

ticeHall.

Shinkawa, Y. (2006). Inter-Model Consistency in UML

Based on CPN Formalism. In Proc. of the 13th Asia

Paciﬁc Software Engineering Conference, pages 411–

419. EEEE.

EVALUATING CONSISTENCY BETWEEN UML ACTIVITY AND SEQUENCE MODELS

289