Synthesizing Decentralized Components from

a Variant of Live Sequence Charts

Dirk Fahland

and Amir Kantor

Eindhoven University of Technology, Eindhoven, The Netherlands

Weizmann Institute of Science, Rehovot, Israel

Keywords:

Live Sequence Charts, Scenarios, Decentralized Synthesis, Petri Nets, Partially Ordered Runs.

Abstract:

Live sequence charts (LSC) is a visual, executable, language for the modeling of reactive systems. Each chart

depicts an inter-object scenario arising in the modeled system, partitioned into two: a monitored prechart, and

a main chart. Despite the intuitive use of the language, complications arise when one wants to implement

an LSC speciﬁcation with decentralized components. In this paper, we introduce a variant of LSC, called

distributed LSC (dLSC), which is targeted for the modeling and synthesis of decentralized systems, composed

of several interacting components. While LSCs are commonly interpreted in terms of an interleaved execution

of the scenarios in a sequential run, dLSCs employ partially ordered runs. We investigate the expressive

power of dLSC compared to an established model of concurrent systems, namely, Petri nets, and show that

dLSCs are, computationally, strictly more expressive than low-level Petri nets and subsumed by higher-level

Petri nets. Speciﬁcally, we present an algorithm that synthesizes, given a dLSC speciﬁcation, an equivalent

token history net, which can serve as an executable implementation of the speciﬁcation. Most importantly, the

implementation is decentralized — components can be automatically extracted from the net. The synthesis of

Petri-net components from a dLSC speciﬁcation is supported by a tool.

1 INTRODUCTION

Scenario-based formalisms, such as message sequence

charts (MSC) (ITU, 1996) and live sequence charts

(LSC) (Harel and Marelly, 2003), are actively used to

describe the behavior of complex systems in an intu-

itive way, particularly at earlier stages of system design.

Scenarios visually describe interactions among com-

ponents and objects of the system. This inter-object

behavior is aligned along time-lines, corresponding

explicitly to the runs of the modeled system. In that

respect, scenarios are dual to the intra-object perspec-

tive taken in traditional system-models such as state-

charts (Harel, 1987) and Petri nets (Reisig, 1985). In

the latter, the system is described in terms of states

and actions of each object in the system. The latter are

useful as blueprints for implementing the system in

hardware or software, but they are generally hard to de-

vise. Thus, a notable challenge is to synthesize from a

speciﬁcation in the form of a set of scenarios, a system-

model, called an implementation of the speciﬁcation,

which behaves as speciﬁed in the scenarios.

A particularly challenging class of systems to de-

sign are concurrent systems (Ben-Ari, 2006). A con-

current system involves several interrelated compo-

nents that are executed simultaneously so that control

is decentralized among the components. Such systems

are very common, in particular when concurrency is

dictated by the underlying architecture that provides

no central control. Examples for such systems are web-

services executed over the Internet, and embedded sys-

tems composed of autonomous controllers. Moreover,

real-life processes, e.g., business processes, carried

out by several autonomous persons or units, can be

modeled and analyzed as concurrent systems.

In this paper, we address scenario-based modeling

of concurrent systems, and the problem of synthesiz-

ing such systems from the speciﬁcations. Scenarios,

which present interactions between components in a

partially ordered structure, can naturally describe ex-

ecutions of concurrent systems. In fact, MSCs are

extensively used in industry to describe sample inter-

actions in concurrent systems and distributed protocols.

Yet, MSCs are essentially too weak to capture the logic

that underlies most systems (Damm and Harel, 2001).

LSC enriches the scenarios of MSC, mainly by being

multi-modal, and makes them expressive enough to

become a fully-ﬂedged model for the system, expres-

Fahland D. and Kantor A..

Synthesizing Decentralized Components from a Variant of Live Sequence Charts.

DOI: 10.5220/0004320500250038

In Proceedings of the 1st International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2013), pages 25-38

ISBN: 978-989-8565-42-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

sively comparable to intra-object behavioral models.

However, the language of LSC, in its present form,

is not well suited for the modeling of concurrent,

decentralized, systems. First, play-out (Harel and

Marelly, 2003), the executable semantics of LSC, de-

ﬁnes a central controller that implements the system

as a whole. Moreover, regardless of how play-out

is deﬁned, it is shown in (Bontemps and Schobbens,

2007) that without additional coordination some LSC

speciﬁcations cannot be distributed into components.

As we discuss in Sect. 2, the standard interpretation

of LSC (Harel and Marelly, 2003) results in implicit

dependencies between the different parts of a scenario,

which arise throughout any typical speciﬁcation. For

systems which can be operated by a single controller,

this raises no difﬁculty. However, in decentralized

architectures, such dependencies require more interac-

tion between the components than speciﬁed.

If we were to use LSC, or any other formalism,

for specifying concurrent systems, the behavior that

can be speciﬁed in that formalism must be such that

it can be exhibited by decentralized components. In

this context, it is signiﬁcant to impose a restriction

on the components, that they coordinate and interact

with each other merely as described in the speciﬁcation.

Otherwise, components are not as autonomous, and the

system is more centralized than intended. Moreover,

as in typical LSC speciﬁcations, additional interactions

may result in a signiﬁcant efﬁciency overhead.

With the intention to support the modeling of con-

current systems, we introduce a variation on the se-

mantics of LSC. It is applied on a central fragment

of the language, which includes scenarios partitioned

into a prechart and a main chart (see Sect. 2). Instead

of the traditional interpretation, presented in terms of

interleaved sequential runs, we interpret LSC speci-

ﬁcations on the basis of partially ordered runs (Pratt,

1986); i.e., traces of executions in which events are

partially ordered. In such a semantic domain, also

known as a true-concurrency semantic domain, we

adopt LSC’s prechart/main-chart distinction. As runs

are partially ordered, they convey more information

than interleaved runs — regarding the causal dependen-

cies between the events. Here, as scenarios themselves

are partially ordered, a fragment of a scenario can be

identiﬁed with a matching sub-structure in the run.

Changing the semantic domain results in a sim-

ple variant of the language, which we refer to as dis-

tributed live sequence charts (dLSC). dLSC avoids

implicit dependencies between separate parts of a sce-

nario, and is thus, we believe, well suited for the mod-

eling of concurrent systems. Moreover, as partially

ordered runs directly correspond to the visual struc-

ture of charts, our interpretation is simple and compre-

hensible, and has a rigorous mathematical basis. We

demonstrate the language and its use with a case study.

We investigate the expressive power of dLSC with

respect to a common model of concurrent systems,

namely, Petri nets (Reisig, 1985). We show that dLSC

speciﬁcations are, effectively, strictly more expressive

than low-level Petri nets in the form of place/transition

nets (Reisig, 1985). However, they do not exceed

the expressive power of high-level nets; dLSC spec-

iﬁcations are subsumed by the class of token history

nets (Van Hee et al., 2008).

We present an algorithm that synthesizes, for any

given dLSC speciﬁcation

, an equivalent token his-

tory net

. A token history net, being a particular

kind of a coloured Petri net (Jensen, 1987), is an ex-

ecutable model, and thus may serve as an implemen-

tation of the speciﬁcation. Moreover, and most im-

portantly, the implementation is decentralized — the

components speciﬁed in

can be extracted from the re-

sulting net

, and, for a large class of speciﬁcations,

no additional interaction between the components is

involved. The synthesis of Petri-net components from

a dLSC speciﬁcation is supported by a prototype tool.

The paper is structured as follows. In Sect. 2, the

semantics of LSC is discussed more closely. In Sect. 3,

we introduce the variant of distributed LSC through an

example, whereas a formal representation of the for-

malism and its semantics is given in the appendix.

In Sect. 4, we investigate the expressive power of

dLSC. Our technique to synthesize system-models

from dLSC speciﬁcations and to extract decentralized

components from them is presented in Sect. 5 and 6,

as well as our prototype tool. We discuss related work

in Sect. 7, and conclude in Sect. 8.

2 FROM LSCs TO DISTRIBUTED

LSCs

In Fig. 1(a), we illustrate a live sequence chart

. In

the chart, there are three vertical lines, called

lifelines

which correspond to three objects: A, B, and C. The

interactions between the objects are depicted by four

arrows, labeled by a, b, c, and d, which designate

events or messages. Time passes along lifelines from

top to bottom, which determines the order between

the events (namely, a through d in that exact order).

Events in LSCs are, in general, partially ordered.

divided into two: a prechart, depicted inside a dashed

hexagon (containing event a), and a main chart, de-

picted inside a solid rectangle (containing events b

through d). The prechart and the main chart are of

two complementary modalities: monitored versus exe-

cute. The prechart is monitored; i.e., it is matched at

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

(a) (b)

Figure 1: A live sequence chart L

run-time against the events that are executed, but does

not yield new behavior. The main chart, in contrast,

supplements runs with new behavior. If and when the

prechart is met, the main chart is enabled and thus

executed. Accordingly, in

, if and when event a

occurs, events b, c, and d are executed.

The common semantics of LSC (see, e.g., (Harel

and Marelly, 2003)) is based on an interleaved execu-

tion of LSCs; i.e, a sequential run is constructed from

the interleaving of partial order scenarios. An LSC is

one consolidated structure, in the following sense: if

any of the events that appear in the chart happens to

occur out of the order prescribed by the chart, the sce-

nario is violated, and should be aborted. Consider, for

example, the chart

presented in Fig. 1(a), describ-

ing interactions between three objects, A, B, and C. If

event a occurs for some reason (perhaps due to some

other chart) after a, b, and c have all occurred, but

before d, then C should abort the scenario without exe-

cuting d. In order to achieve this kind of behavior, C

must be aware of occurrences of a. Thus, if the system

is to be implemented by decentralized components,

C must be notiﬁed of the executions of a (even those

coming from outside the present chart) one way or

another. There are many such implicit dependencies

alone. E.g., such a dependency arises also be-

tween b and d, so that C must be aware of executions

of b, and A must be aware of executions of d.

If the modeled system is to be implemented in a

decentralized architecture, such dependencies intro-

duce an essential complication, as the implementa-

tion would require additional unspeciﬁed interactions

between the components. Moreover, this results in

communication overheads and excessive run-time syn-

There is another multi-modal distinction in the language

of LSC (Harel and Marelly, 2003), between cold behaviors,

which may happen in the system (possible), and hot behav-

iors, which must happen (mandatory). In

, all events are

cold (possible), which is designated by blue dashed arrows,

and thus may be discarded in the presence of other, conﬂict-

ing, alternatives. The following observations are independent

of the hot/cold distinction.

(a) (b)

(e)

Figure 2: Distributed LSCs of an emergency management

procedure.

chronization among the components. In this paper

we establish the use of LSC, and speciﬁcally the lan-

guage’s prechart/main-chart distinction, in a semantic

domain that is more suited to the modeling of concur-

rent systems. The resulting formalism is referred to

as distributed LSC (dLSC). In this paper we address a

basic, central, fragment of the language of LSC. We

consider charts, each partitioned into a prechart and a

main chart, containing cold events.

3 THE VISUAL FORMALISM OF

DISTRIBUTED LSC

We introduce distributed LSCs in the context of an

example, which involves concurrently operating com-

ponents. We model the behavior of an emergency

management procedure. The procedure involves one

or more medics, providing ﬁrst-aid treatment, a clinic,

and an Emergency Management System (EMS), which

keeps track of pending emergencies and mediates be-

tween the medics and the clinic.

SynthesizingDecentralizedComponentsfromaVariantofLiveSequenceCharts

3.1 Scenarios

A dLSC speciﬁcation is a ﬁnite set of dLSCs (and an

initial run) which together describe the system’s be-

havior. Fig. 2(c) shows an illustrative dLSC of the

procedure, denoted by

. A dLSC is a partial order-

ing of events; events are drawn as rectangles, and the

ordering of events is indicated by arrows. The horizon-

tal dashed line divides

into a monitored prechart

(denoting the precondition that enables

) and a main

chart (denoting the behavior contributed by

, which

is to be executed once the prechart is met). The vertical

lifelines in

are used to graphically align events of

the same component but have no formal meaning.

The prechart of

consists of two unordered

events, labeled EMS.alert and M

.ready. Throughout

the speciﬁcation, the events of the

medic are pre-

ﬁxed by M

(for different concrete values of

), those of

the clinic are preﬁxed by C, and those of the EMS by

EMS. Event EMS.alert represents a notiﬁcation from

the EMS of a pending emergency. Event M

.ready

designates a notiﬁcation by the medic that he has be-

come ready to handle emergencies. If and when the

EMS notiﬁes of a pending emergency, and the medic

is ready, the execution may continue according to the

main chart as follows.

The main chart of

contains ﬁve events, start-

ing with M

.go, which indicates that the medic travels

to the location of the emergency. Then, the medic

transports the patient to the clinic (M

.transp), and,

concurrently, provides ﬁrst-aid treatment (M

.treat

After both events, the clinic enrolls the newly arrived

patient (C.enroll), and the medic becomes ready to

handle following emergencies (M

.ready).

Another dLSC,

depicted in Fig. 2(d), describes

medical treatment at the clinic. Its prechart is com-

prised of three events, two of which are ordered: the

clinic enrolls the arrival of a patient (event C.enroll)

after

receiving treatment by the medic (M

.treat

), and,

in addition, the resources of the clinic are set and ready

(C.ready). When the prechart is met, the execution

continues as indicated in the main chart: the patient

receives treatment at the clinic (C.treat), after which

the clinic’s resources are ready for the next patient

(C.ready).

The speciﬁcation includes three more charts.

dLSC

of Fig. 2(b) captures situations in which

ﬁrst-aid treatment by the medic is enough (M

.treat

)

after which the medic is available again (and the pa-

tient need not be brought to the clinic). dLSCs

and

have the same prechart. As we consider all events

to be cold (possible), we understand such scenarios

as alternatives: whenever the prechart of

and

is met, the execution continues according to either

or L

dLSC

of Fig. 2(a) captures the arrival of emer-

gency calls to the EMS. Whenever the EMS is ready

(EMS.ready), a new emergency may arrive, result-

ing in two independent events: the EMS alerts the

medics of a pending emergency (EMS.alert), and the

EMS becomes ready again to receive more emergen-

cies (EMS.ready). Finally, a speciﬁcation contains

an initial run that describes how the procedure be-

gins. It is depicted in Fig. 2(e) and is denoted by

In our example,

includes four unordered (indepen-

dent) events: the events EMS.ready, two events labeled

.ready and M

.ready (assuming the process involves

two medics; any number of medics is supported), and

the event C.ready.

3.2 Semantics

Syntactically, a dLSCs is just an LSC drawn in a

slightly more abstract form. For instance, LSC

of Fig. 1(a) can be represented as in Fig. 1(b). Where

dLSCs and LSCs actually differ is in their interpreta-

tion. Instead of LSC’s interleaved semantics, we in-

terpret dLSCs on the basis of Pratt’s partially ordered

runs (Pratt, 1986), a common framework to describe

the behavior of concurrent systems.

Partially Ordered Runs.

Fig. 3(a) shows a partially

ordered run

. It consists of 9 events (drawn as rectan-

gles) that are labeled and partially ordered according

to the directed arcs (the dashed vertical lines align

events graphically but have no formal meaning). A

partially ordered run captures the causal dependen-

cies between events — an event occurs after all its

predecessors have occurred. For instance, in Fig. 3(a),

events EMS.ready, M

.ready, M

.ready and C.ready

can all occur in the beginning, i.e., they are mutually

independent. Once EMS.ready occurred, EMS.alert

and the second EMS.ready event occur; M

.go can

only occur after both, M

.ready and EMS.alert have

occurred.

A partially ordered run

corresponds to a set of se-

quential runs, each being an interleaving of the events

that is consistent with the partial order in

. Such

an interleaving corresponds to what a global observer

overlooking the execution might see.

dLSCs Describe Partially Ordered Runs.

As indi-

vidual scenarios are themselves fragments of partially

ordered runs, the latter seems a natural candidate for

the semantic domain. When executions are represented

as partially ordered runs, the ordering of events in a

scenario directly carries over to the runs, and individ-

ual scenarios can be recognized inside the run. This

perspective suggests an alternative way to interpret

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

(a) ρ

(b) ρ

Figure 3: Runs of the emergency management procedure.

LSCs.

The behavior induced by a dLSC speciﬁcation

may be brieﬂy described as follows. The speciﬁcation

is executed starting with the initial, partially ordered,

run (

in our example). A prechart of some dLSC

matches the end of a run whenever the events of

the prechart occur at the end of the run — in the same

order. In this case, the events in the main chart of

are

locally concatenated at the end of the run. With such

concatenations, partially ordered runs are augmented,

possibly ad inﬁnitum. The exact formal semantics are

given in the appendix. In the following, we illustrate

this semantics by our running example.

The partially ordered run in Fig. 3(a), which we

denote by

, is an example of an execution of the

emergency management procedure. It is obtained as

follows. Starting with the initial run

, the prechart

is met, and so its main chart is concatenated.

This results, in particular, in the creation of the event

EMS.alert. Then, the precharts of both

and

are

met, so either one may be concatenated.

is the

result of concatenating

. The other possibility, of

concatenating

, appears in run

of Fig. 3(b). Runs

and

are alternatives. In

, the concatenation of

results, in particular, in the occurrence of the event

C.enroll. Then, the prechart of

is met, and so the

main chart of L

is also concatenated.

A slightly more involved execution is

Fig. 3(c). It contains two EMS.alert events. The ﬁrst

alert is handled by

according to dLSC

, and

the second alert is handled by

according to dLSCs

and

. Runs

, and

can be continued,

possibly ad inﬁnitum.

Difference from Classical LSC.

Observe that the ac-

tivities of the two medics in

are unordered, reﬂect-

ing the fact that the two medics operate independently.

In classical LSC (Harel and Marelly, 2003), this con-

current behavior would not have been obtained, as the

second EMS.alert event (that triggers

) would vio-

late

of Fig. 2(b) as long as

is not completed.

This illustrates the fundamental difference between

dLSC, which is interpreted on the basis of partially

ordered runs, and classical LSC.

3.3 The Extended Example

In order to illustrate other aspects in the semantics of

distributed LSC, we incrementally extend the emer-

gency management procedure with three additional

dLSCs.

, depicted in Fig. 4(a), describes another

alternative to

and

: a medic reaching the pa-

tient may realize that the clinic needs to prepare for

the incoming patient. The medic notiﬁes the EMS of

the incoming patient (M

.notify), which in turn noti-

ﬁes the clinic (EMS.notify). According to dLSC

of Fig. 4(b), the clinic prepares for the arrival of the

patient (C.prepare), and then waits for the patient

(C.wait4), concurrently to the other duties of the clinic

(due to C.ready). After the patient has enrolled in

the clinic, he is treated according to dLSC

(see

Fig. 4(c)).

An execution of the extended speciﬁcations is de-

picted in Fig. 5. The run, denoted

, is similar to

SynthesizingDecentralizedComponentsfromaVariantofLiveSequenceCharts

(a) (b)

(c)

Figure 4: Extending the emergency management procedure.

Fig. 3(c), but the second medical emergency is treated

according to

. After the concatenation of

and

the prechart of

is matched, while the prechart of

is not; only the main chart of

can be added, after

the events C.enroll and C.wait4. dLSC

illustrates

the expressive power of precharts to describe behavior

across components. dLSC

and

both include the

event C.enroll in their precharts, but it is preceded by

different events (namely, M

.treat

and M

.treat

). Therefore, the precharts reﬂect different sit-

uations. Moreover, the prechart of

states that the

event C.enroll corresponds to the same patient waited

for by C.wait4 because of the joint predecessor event

.notify.

4 EXPRESSIVE POWER

We just introduced dLSC, which interprets the core

concepts of LSC in the context of partially ordered

runs. In this section, we discuss whether this core

language and interpretation are sufﬁciently expressive

to describe decentralized systems.

dLSC Subsumes Petri Nets.

Distributed LSCs can

be seen to subsume low-level Petri nets in the form of

place/transition nets (PTN) (Reisig, 1985; Peterson,

Figure 5: A run

of the extended emergency management

procedure.

(a) N

p4p3p2

(b)

p1 p5p3

p4p2

p3 p5p1

t1 t3

(d) A run of S

Figure 6: Translating a place/transition net into a dLSC

speciﬁcation.

1977). PTNs are an abstract model for the flow of

control and information in systems, particularly con-

current and decentralized systems.

A PTN consists of places

(drawn as circles)

and transitions

(drawn as rectangles) that are con-

nected by arcs from places to transitions and from

transitions to places; see, for example, PTN

de-

picted in Fig. 6(a). The global state of the net is given

by a marking which puts in each place a nonnegative

number of tokens; a PTN has a dedicated initial mark-

ing. Given a marking, a transition

is enabled if each

place with an arc to

has a token. If

is enabled, it

may ﬁre, which results in a new marking obtained by

removing a token from each place with an arc going

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

and putting a token on each place with an arc

coming from

. These notions give rise to both an

interleaved semantics, presented in terms of sequen-

tial runs, and a true-concurrency semantics in terms

of partially ordered runs that is consistent with the

interleaved semantics (Goltz and Reisig, 1983). The

partially ordered runs of a Petri net can be constructed

by local continuations — each ﬁring of a transition is

recorded as a local continuation. Figure 6(c) shows a

partially ordered run of PTN

of Fig. 6(a) as follows:

transition

occurred, consuming a token from

and

producing a token on

;

occurred concurrently to

, consuming from

and producing on

; transition

occurred after

and

, consuming from

and

and producing on p

Next, we show that dLSC are expressive enough to

specify any place/transition Petri net. Given a PTN

one can construct an equivalent dLSC speciﬁcation

We take

Σ := T ∪P

to be the set of actions in our spec-

iﬁcation, which includes both transitions and places.

Places can be considered as auxiliary actions, and can

be abstracted away from the runs induced by the spec-

iﬁcation, in case one is only interested in the events

that are due to the ﬁring of transitions.

For each transition

t ∈ T

, we construct a dLSC

as follows (see Fig. 6(b), illustrating the dLSC cor-

responding to transition

). The prechart of

contains the input places of

as events. There is

no ordering between the events in the prechart. The

main chart of

begins with the event

, after which

the output places of

are included with no ordering

between them. The dLSC speciﬁcation corresponding

to the net

contains one dLSC

for each transition

, and an initial run

, where

contains for

each place

as many

-labeled events as there

are tokens on

in the initial marking, with no ordering

between the events. This construction also applies to

place/transition nets with arc weights, by duplicating

events representing places according to the weights.

It can be shown that the set of runs of

is iso-

morphic to the set of partial order Petri-net runs of

The idea is to represent the latter on the basis of local

continuations. Each continuation rule for construct-

ing the Petri-net runs, corresponds to a dLSC in

Fig. 6(c) illustrates the Petri-net run of

, starting

from the initial marking, while Fig. 6(d) depicts the

corresponding run of the dLSC speciﬁcation S

Strictly more Expressive than Petri Nets.

The con-

verse proposition, that each dLSC speciﬁcation can

be effectively translated into an equivalent PTN, does

not hold. Intuitively, PTNs cannot mimic the enabling

condition expressed by precharts with a complex struc-

ture. The enabling of a Petri net transition depends

only on the availability of tokens in its preplaces and

nothing else; the enabling of a dLSC can depend on

several past events and their causal ordering. The proof

that establishes the greater expressive power of dLSC

compared to PTN is a variation on a similar proof

in (Fahland, 2010). It shows that any instance of Post’s

correspondence problem (PCP) can be expressed as

a dLSC speciﬁcation, such that a particular event oc-

curs if and only if the PCP instance has a solution.

In PTN, the problem of deciding whether a particular

event can occur is decidable, whereas PCP is unde-

cidable. Therefore, there is no algorithm to translate

dLSC speciﬁcations into equivalent PTNs.

5 SYNTHESIZING SYSTEMS

Section 4 shows that distributed LSC, our interpreta-

tion of LSC in the context of partially ordered runs,

allows to specify the behavior of a large class of con-

current systems. In the remainder of the paper, we ad-

dress the following problem, which may be referred to

as the decentralized synthesis problem: given a dLSC

speciﬁcation

(i.e., a set of dLSCs, in which events

are assigned to components, and an initial run), syn-

thesize an implementation consisting of decentralized

components, in a suitable system-model formalism,

which behave and interact exactly as speciﬁed in S.

Section 4 shows that this problem is not trivial,

and that the class of simple place/transition nets is

not expressive enough to capture the behavior spec-

iﬁed in dLSC speciﬁcations. In order to solve the

decentralized synthesis problem, we use a slight ex-

tension of place/transitions nets, called token history

nets (Van Hee et al., 2008), to represent the synthesized

implementation. In the present section, we show how

to effectively synthesize from a given dLSC speciﬁca-

tion

an equivalent token history net

. Then, indi-

vidual components can be easily extracted from

which is discussed in Sect. 6.

The synthesis of

is carried out as follows.

Events of

are translated into transitions in

, and

the partial order between them is enforced in

through Petri-net places. To capture that the occur-

rence of some event of

depends on its preceding

events, we use the fact that tokens in

record their

own history, in terms of the transitions that they have

passed. A transition in

will only be enabled by to-

kens with the correct history. We ﬁrst present the class

of token history nets, and then deﬁne the synthesis

of N

from S.

5.1 Token History Nets

This part gives an informal introduction to token his-

SynthesizingDecentralizedComponentsfromaVariantofLiveSequenceCharts

tory nets; the formal deﬁnitions are given in (Fahland

and Kantor, 2012). A token history Petri net

(THPN) (Van Hee et al., 2007; Van Hee et al., 2008) is

a Petri net in which transitions are labeled with actions

or with

τ 6∈ Σ

;

are observable actions (which will

represent the actions in a dLSC speciﬁcation), while

is a silent (or, unobservable) action. The main dif-

ference from place/transition nets is that each token

of a THPN is a partially ordered run as discussed in

Sect. 3.2, representing the history of transition ﬁrings

that have led it to its current place. A ﬁring of a transi-

tion extends the histories of the tokens involved.

Figure 7(a) shows a token history net. As usual, a

circle represents a place, a rectangle represents a tran-

sition, and transition labels are inscribed. Moreover,

each transition has a guard in the form of a token his-

tory (shown for the transitions that go by the names

, and

). Intuitively, a transition is only enabled

if the token histories in its pre-places together end with

the token history in the guard.

We illustrate the semantics of THPNs with a par-

tially ordered run (Goltz and Reisig, 1983)

of the

THPN

of Fig. 7(a). Run

is shown in Fig. 7(b) as

an acyclic labeled Petri net: each place of

(called

a condition) with label

represents a token history

on the place

; a transition

(called an event),

with label

, represents a ﬁring of transition

;

the pre-places (post-places) of

represent the token

histories consumed (produced) by t.

For instance, in Fig. 7(b), condition

denotes that

the place

E.ready

is marked with history

(consist-

ing only of event

E.ready

). In this situation, transition

is enabled. Event

denotes the ﬁring of

, which

consumes

from

E.ready

and produces

(

ex-

tended with the occurrence of the silent transition

)

on both

and

, as represented by conditions

and

. Event

denotes the ﬁring of the transition la-

beled

E.alert

(the one consuming from

), which con-

sumes

from

, and produces

on place

E.alert

as represented by condition

. The run of Fig. 7(b)

shows how the token histories are built up event by

event, eventually joining several token histories into

one at event

. Note that transition

is only enabled

because the union of histories

and

ends with

the guard of

. Guards in a THPN can also be more

complex such as the guard of

which requires token

histories on

C.enroll

and

C.wait4

to have a joint event

.notify.

5.2 Translating Speciﬁcations into

Token History Nets

In the execution of a THPN, each token history records

the preceding events as a partially ordered run. This

allows us to capture the semantics of dLSC speciﬁca-

tions with token history nets. Fig. 7(a), for instance,

depicts the result of the translation of the speciﬁca-

tion of Sect. 3 into a THPN (to avoid cluttering the

ﬁgures, we show only one of the medics). The formal

translation is included in (Fahland and Kantor, 2012).

Translating the Speciﬁcation.

We translate a dLSC

speciﬁcation

S = hD, R

over actions

(where

a set of dLSCs and

is the initial run) into an equiv-

alent THPN

over

. We ﬁrst translate each chart

L ∈ D

into a net

, and then, compose the resulting

nets to form the net

of the entire speciﬁcation. The

different

’s are connected via shared places: for

each action

that appears maximal in some main chart

of a chart

L ∈ D

there is a shared place

, on which

produces. For a chart

∈ D

in which an event

labeled

appears maximal in the prechart,

will

consume from p

Translating Individual Charts.

Each dLSC

in the

speciﬁcation induces a net

. For each main-chart

event

contains a transition

that gets the

same label as

. The partial order of

’s main chart is

encoded by places. In addition, each transition

gets a guard that ensures that

is only enabled if

the token history produced by

ends with the history

, i.e., the events preceding

. The initial

run R

is translated into a net N

in the same way.

In Fig. 7(a), the result of translating the main charts

of the speciﬁcation of Sect. 3 as described above is

shown inside the shaded boxes. For instance, consid-

ering dLSC

, the net contains a transition labeled

.go for the minimal event in the main chart of

preceded by the activation place

. The last event in

, labeled M

.ready, produces on the shared place

.ready. The subnet

of the initial run is scat-

tered throughout between the other subnets; its activa-

tion places are p

, p

, and p

The transitions of

that represent the minimal

events in the main chart of

shall only be enabled

when all the maximal events in

’s prechart have oc-

curred. We formalize this by a main-chart activation

transition

with label

(unobservable);

consumes

from the shared places corresponding to the maximal

events in

’s prechart and produces on places that en-

able the minimal events in

’s main chart. In addition,

has a guard that enables

only if the prechart of

has occurred. A ﬁring of

will not be visible in

the resulting token history as

has a label

. E.g., in

Fig. 7(a), the

-transition

is the activation transition

of dLSC

of Fig. 2(b). When checking whether the

token histories consumed by a transition

satisfy the

guard of t, τ-labeled events in the tokens are ignored.

The synthesized net

exhibits the same behav-

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

E.alertE.ready

.go

.ready C.enroll

.transp

.treat

E.ready

E.alert

.ready

E.ready

.ready

.ready C.enroll

.notify

.go

E.notify

.go

.treat

.ready

.transp

.treat

C.enroll

C.ready

C.prepare

C.wait4

C.treat

C.ready

C.enroll

.treat

C.prepare

.notify

E.notify

C.wait4

guard (L

)

C.enroll

.treat

C.ready

guard (L

)

E.alert

.ready

guard (L

)

(a)

E.alertE.ready

E.ready

E.alert

.go

.treat

E.ready

.ready

C.ready

E.ready

E.alert

.ready

.go

E.ready

.treat

E.ready

E.alert

E.ready

E.alert

.ready

.go

E.ready

.ready

E.ready

E.alert

.ready

E.ready

.ready

C.ready

(b)

Figure 7: A token history net synthesized from dLSCs L

–L

(left), and a run ρ of this net (right).

ior that is speciﬁed in

. More precisely, the partial

order runs of

are the same as (i.e., isomorphic to)

those of

, after the events of

-labeled transitions

are abstracted away from the net’s runs. That is, the

speciﬁed behavior is reﬁned by unobservable actions

(more on this in Sect. 6).

6 EXTRACTING COMPONENTS

In Sect. 5, we introduced a technique to synthesize

from a dLSC speciﬁcation

, a THPN

with the

same behavior. In this section, we proceed and extract

decentralized Petri-net components from

. This

would complete the path from a scenario-based model,

namely, a dLSC speciﬁcation

, to Petri-net models of

the components that implement it.

6.1 Components

As in our running example, we assume that in the

speciﬁcation each action is performed by a particular

component, which is denoted explicitly. Speciﬁcally,

we assume a ﬁnite set of components

, such that each

As speciﬁed above, token histories can grow indeﬁnitely.

However, guards of transitions only consider the more recent

events. Thus, the length of token histories can be bounded

by the longest chart in the speciﬁcation, by truncating (e.g.,

in each transition) older events.

action of

is of the form

c.e

for some component

c ∈ C and an event name e.

Each transition

is then either labeled by

an action

c.e

, or it is a

-labeled transition that cap-

tures the activation of the main chart of some dLSC

(denoted by

in Sect. 5.2). In the former case,

associated with the component

that performs the un-

derlying action. In the latter case,

must be assigned

to a component; this is an important matter that we

address in Sect. 6.2. Assigning transitions to compo-

nents naturally induces a decomposition of the net

into Petri-net components.

For each

c ∈ C

, a Petri-net component

is de-

ﬁned to be the subnet of

containing the transitions

assigned to

, denoted by

, the places

that are

directly connected to the transitions in

, and the

arcs between

and

as appears in

. This stan-

dard construction is formalized in (Fahland and Kantor,

2012). A place

belonging to more than one compo-

nent is an interface place; otherwise, p is internal.

According to such decomposition, when the com-

ponents are put together they yield the original net

Therefore, when executed, the components exhibit pre-

cisely the behavior of the net

. As discussed in

Sect. 5, this behavior matches that prescribed in dLSC

speciﬁcation S.

Considering our running example, actions are pre-

ﬁxed by a component name: either E (the EMS), M

(the

medic), or C (the clinic). Extracting compo-

nents from the synthesized net of Fig. 7(a) as described

SynthesizingDecentralizedComponentsfromaVariantofLiveSequenceCharts

init

ready

treat_A

ready

treat_B

transport

ready

notify

transport

treat_C

ready

alert

init

ready

alert

notify

init

ready

enroll

ready

enroll

treat

ready

enroll

prepare

ready

wait4

treat

Medic

Clinic

EMS

Figure 8: The result of synthesizing components from

dLSCs L1–L7.

(a) (b)

(c)

Figure 9: Runs including unobservable actions.

(a) (b)

(c)

Figure 10: Unobservable actions abstracted away.

above yields the components shown in Fig. 8. This

ﬁgure was obtained using our tool SAM, which is de-

scribed in the following.

6.2 Interactions between Components

When considering decentralized synthesis from spec-

iﬁcations, the latter must impose restrictions on how

components interact with each other. Without any lim-

itation in that respect, one could construct components

that interact arbitrarily. This would undermine the

autonomous nature of the components, and lend the

problem not well-deﬁned.

In a partially ordered run, interaction is made ex-

plicit through the causal dependencies recorded in the

run. If an implementation presents exactly the same

partially ordered runs as in the speciﬁcation, then by

deﬁnition the components interact exactly as speci-

ﬁed (and exhibit no additional interaction). This is

the case for the net

synthesized from

, up to the

-labeled transitions of

that express the activation

of a main chart (see Sect. 5). In the following, we

discuss how such unobservable actions inﬂuence the

interaction between components. Then, we assign the

-labeled transitions of

to components so that the

latter interact as speciﬁed in S.

Unobservable Actions.

Compare the partially or-

dered runs of Fig. 9, which include

-labeled events,

with the corresponding runs of Fig. 10 in which the

-labeled events are abstracted away and the causal

dependencies between the observable events remain

intact. The runs in Fig. 10, which record only observ-

able events, correspond to speciﬁed behavior, while

the runs of Fig. 9 correspond to the runs of an im-

plementation containing also unobservable transitions.

In the runs, each event, including the unobservable

events, is associated with a particular component.

A direct causal dependency between events of dif-

ferent components gives rise to an interaction between

the components. E.g., in Fig. 10(a), as event c1.e

directly causes event c3.f, there is an underlying inter-

action between the components. Depending on how

labeled actions are performed, the interaction scheme

may change: in Fig. 9(a),

and

no longer interact

with each other; rather, through the

-labeled event

of component

interacts with

and

with

This is exactly the situation that must be avoided when

a decentralized implementation contains unobservable

actions that reﬁne the speciﬁed behavior.

Figures 9(b) and 9(c) show situations in which the

reﬁned behavior of the implementation presents the

same interaction scheme as in the speciﬁed behavior.

In Fig. 9(b) and 10(b), all events belong to the same

component, so no interaction is present. In Fig. 9(c),

there is an interaction between

and

, which is

also the case in Fig. 10(c) (multiple arrows from one

event in

to multiple events in the same component

count as one interaction). These two cases illustrate

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

sufﬁcient conditions in which unobservable events do

not change the interaction scheme: a

-labeled event

is termed pre-internal (post-internal) if all direct suc-

cessor (predecessors) events of

are performed by

the component performing

;

internal

if it is pre-

and post-internal. In Fig. 9(b), the

-labeled event is

internal, in Fig. 9(c) it is pre-internal, and in Fig. 9(a)

it is neither.

In the runs of the implementation, an unobserv-

able event that is pre- or post-internal does not change

the interaction scheme between the components com-

pared to the speciﬁcation. Thus, when assigning the

-labeled transitions of

to components, we have to

make sure they only yield pre- or post-internal events.

A Petri-net transition

yields only pre-internal events

if all post-places (having an arc from

) are internal

places, since the succeeding transitions belong to the

same component as

; similarly,

yields only post-

internal events if all pre-places are internal.

Assigning Activation Transitions.

There is a class of

speciﬁcations for which there is a natural way to assign

activation transitions to components. A dLSC

called local choice if all the minimal events in its main

chart are of the same component

c ∈ C

. Intuitively, in

this case, only component

is involved when the main

chart begins, and thus the choice for an activation of

the chart can be made locally in component

. For a

local choice dLSC

, the activation transition of

assigned to component c as well. A speciﬁcation S is

said to be local choice if all the dLSCs in

are local

choice. E.g., the speciﬁcation of our running example,

as one may easily verify, is local choice.

In local choice speciﬁcations, when activation tran-

sitions are assigned to components as indicated above,

any occurrence of a

-labeled action in the run is pre-

internal. This can be deduced from the structure of

as the post-places of each activation transition are in-

ternal. Therefore, the

-labled transitions in

not change the interaction scheme between the compo-

nents compared to the speciﬁcation.

As for non-local choice charts, activation transi-

tions need to be explicitly assigned by the modeler.

Then, although the observable behavior is precisely as

indicated in

, interactions that are not made explicit

in the speciﬁcation may be introduced. These can be

made explicit by reﬁning the speciﬁcation to become

local choice.

Tool Support.

Our technique for synthesizing Petri-

net components from dLSC speciﬁcations is imple-

mented in a prototype tool called SAM. The tool takes

as input a dLSC speciﬁcation in a simple textual syn-

tax, describing each dLSC’s prechart and main chart as

a partial order of events. Additionally, components can

Figure 11: A CPN Tools model of three components synthe-

sized by SAM.

be speciﬁed as sets of event names. SAM produces a

token history net with extracted components as a CPN

Tools model (Jensen et al., 2007; Ratzer et al., 2003).

CPN Tools implements the general class of coloured

Petri nets (Jensen, 1987), which supports deﬁning

datatypes for token histories, and can represent the ﬁr-

ing rule of a THPN with operations on tokens. Fig. 11

shows the components appearing in Fig. 8 within CPN

Tools. This allows to simulate and analyze the spec-

iﬁcation and the resulting components using the full

grown functionality of CPN Tools. SAM is available

at http://www.win.tue.nl/∼dfahland/tools/sam/.

7 RELATED WORK

As discussed in Sect. 2, dLSC builds on ideas from

the language of LSC (Harel and Marelly, 2003), and

implements them in a semantic domain that is more di-

rectly related to concurrent systems, based on partially

ordered runs. The change in the semantic domain al-

lows to identify scenarios with patterns that explicitly

appear in the constructed run. This contrasts with LSC,

which identiﬁes scenarios with their interleavings.

In LSC, whether two enabled charts can be exe-

cuted concurrently depends on the identity of their

events; that is, whether each can be executed with-

out violating the other. In the presence of violations,

the charts may become alternatives (in case of cold

main-chart events). In dLSC, in contrast, causality is

recorded in the run: two charts are executed concur-

rently if they are enabled at two causally independent

parts of the run, and they are alternatives if they are

enabled at overlapping (or identical) parts of the run.

Thus, the semantics of dLSC corresponds to that of

LSC whenever violations of charts coincide with the

charts being enabled at the same location of the run.

The semantics of dLSC somewhat resembles that

of the existential, conditional, interpretation of LSC

in (Sibay et al., 2008), which demands that whenever

SynthesizingDecentralizedComponentsfromaVariantofLiveSequenceCharts

a run ends with a prechart of an LSC, there exists

a run that continues with the main chart. In dLSC,

however, all possibilities to continue are induced by the

speciﬁcation, and progress is assumed whenever there

is an enabled main chart.

Moreover, again, dLSC

employs composition of partial orders whereas (Sibay

et al., 2008) interprets LSCs over sequential runs.

Distributed LSCs are closely related to

oclets (Fahland, 2009; Fahland, 2010), a

scenario-based formalism that employs LSC’s

prechart/

main-chart

distinction in terms of Petri nets

and their partially ordered runs. dLSC can be seen as

an adaptation of oclets in a context that is purely event-

based. This signiﬁcantly simpliﬁes the formalism, and

yet oclets’ Petri-net places can be represented in dLSC

by events. Moreover, in dLSC, as in LSC, a main chart

is completely synchronized after the prechart. This

eliminates implied scenarios (Uchitel et al., 2001),

i.e., additional behavior that is not explicitly speciﬁed,

which may occur in oclets. The framework of oclets

also allows to extract decentralized components from

a speciﬁcation (Fahland, 2010), but it requires a

different method that cannot take all speciﬁcations

as input, and has exponential worst-case complexity,

unlike the complete, polynomial, method proposed in

this paper.

Synthesis of systems and decentralized compo-

nents from scenario-based speciﬁcations is a well-

known problem, with many contributions; (Liang et al.,

2006) provides an extensive survey. Most approaches

consider (H)MSCs or UML Sequence Diagrams as

input, and translate the speciﬁcation into statecharts or

Petri nets somewhat similarly to our technique (Liang

et al., 2006), or through behavioral synthesis (Uchitel

et al., 2001; Bergenthum et al., 2009). Moreover, cen-

tralized synthesis from LSC has been studied, which

succeeds by structural translations to statecharts (Harel

and Kugler, 2002), or through game-based synthesis

techniques (Harel and Segall, 2012). However, in all

cases, synthesis introduces either non-speciﬁed behav-

ior (implied scenarios), or centralized synchronization

between the events that makes the extraction of de-

centralized components impossible. Our synthesis

technique makes synchronization information part of

the exchanged messages by means of token histories,

which effectively prohibits implied scenarios, and, for

a large class of speciﬁcations, limits the interactions

among components to those speciﬁed in the dLSCs.

One can slightly generalize the deﬁnition of dLSC to

also allow for charts for which, when enabled, progress is

not assumed. The synthesis algorithm, with trivial changes,

would still apply.

8 CONCLUSIONS

In this paper, we take a fresh look at an essential frag-

ment of live sequence charts (LSC) and provide a se-

mantics in terms of partially ordered runs by means

of simple scenario composition. This variant of LSC,

called distributed LSC (dLSC), has sufﬁcient expres-

sive power for specifying concurrent systems: effec-

tively, it is strictly more expressive than classical Petri

nets. We also provide a technique to synthesize, from

any dLSC speciﬁcation, an implementation in the class

of token history nets (THPN). Decentralized compo-

nents can be easily extracted from the THPN. The

approach has polynomial time and space complexity

and is implemented in a tool, which extracts a CPN

Tools model of the components.

While the CPN Tools model can be used for simu-

lation and analysis, or as a blueprint for implementing

the components in code, automatic code generation is

an interesting open issue. As for other future work,

one may extend dLSC with a notion of data, such as

from algebraic speciﬁcations; we believe our synthesis

technique still applies, as coloured Petri nets, which

support data manipulation, could be similarly synthe-

sized. Also, operations on dLSC speciﬁcations, such

as scenario (de-)composition and reﬁnement, are of

interest. They would permit to systematically develop

and reason on complex dLSC speciﬁcations.

ACKNOWLEDGEMENTS

We thank David Harel for his helpful comments on this

work. The research was supported in part by the John

von Neumann Minerva Center for the Development of

Reactive Systems at the Weizmann Institute of Science,

and by an Advanced Research Grant to David Harel

from the European Research Council (ERC) under the

European Community’s FP7 Programme.

REFERENCES

Ben-Ari, M. (2006). Principles of Concurrent and Dis-

tributed Programming. Addison-Wesley, second edi-

tion.

Bergenthum, R., Desel, J., Mauser, S., and Lorenz, R. (2009).

Synthesis of Petri Nets from Term Based Representa-

tions of Inﬁnite Partial Languages. Fundam. Inform.,

95(1):187–217.

Bontemps, Y. and Schobbens, P.-Y. (2007). The computa-

tional complexity of scenario-based agent veriﬁcation

and design. Journal of Applied Logic, 5(2):252 – 276.

Damm, W. and Harel, D. (2001). LSCs: Breathing Life into

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

Message Sequence Charts. J. on Formal Methods in

System Design, 19(1):45–80.

Fahland, D. (2009). Oclets - Scenario-Based Modeling with

Petri Nets. In ATPN’09, volume 5606 of LNCS, pages

223–242. Springer.

Fahland, D. (2010). From Scenarios to Compo-

nents. PhD thesis, Humboldt University of Berlin.

http://repository.tue.nl/685341.

Fahland, D. and Kantor, A. (2012). Synthesizing decentral-

ized components from a variant of live sequence charts.

Technical report. http://www.win.tue.nl/

∼

dfahland/

tools/sam/dlsc synthesis tr.pdf.

Goltz, U. and Reisig, W. (1983). Processes of

Place/Transition-Nets. In ICALP’83, volume 154 of

LNCS, pages 264–277. Springer.

Harel, D. (1987). Statecharts: A visual formalism for com-

plex systems. Sci. Comput. Program., 8(3):231–274.

Harel, D. and Kugler, H. (2002). Synthesizing State-Based

Object Systems from LSC Speciﬁcations. Int. J. of

Foundations of Computer Science, 13(1):5–51.

Harel, D. and Marelly, R. (2003). Come, Let’s Play:

Scenario-Based Programming Using LSCs and the

Play-Engine. Springer.

Harel, D. and Segall, I. (2012). Synthesis from scenario-

based speciﬁcations. Journal of Computer and System

Sciences, 78(3):970 – 980.

ITU (1996). International Telecommunication Union Rec-

ommendation Z.120: Message Sequence Charts. Tech-

nical report.

Jensen, K. (1987). Coloured Petri nets. In Petri Nets: Central

Models and Their Properties, volume 254 of LNCS,

pages 248–299. Springer.

Jensen, K., Kristensen, L., and Wells, L. (2007). Coloured

Petri nets and CPN Tools for modelling and valida-

tion of concurrent systems. International Journal on

Software Tools for Technology Transfer (STTT), 9:213–

254.

Liang, H., Dingel, J., and Diskin, Z. (2006). A Compara-

tive Survey of Scenario-Based to State-Based Model

Synthesis Approaches. In SCESM ’06, pages 5–12,

ACM.

Peterson, J. L. (1977). Petri nets. ACM Comput. Surv.,

9(3):223–252.

Pratt, V. (1986). Modeling concurrency with partial orders.

Int. J. Parallel Program., 15(1):33–71.

Ratzer, A., Wells, L., Lassen, H., Laursen, M., Qvortrup,

J., Stissing, M., Westergaard, M., Christensen, S., and

Jensen, K. (2003). CPN Tools for editing, simulating,

and analysing coloured Petri nets. In ATPN 2003,

volume 2679 of LNCS, pages 450–462. Springer.

Reisig, W. (1985). Petri Nets: An Introduction. Springer-

Verlag New York, Inc., New York, NY, USA.

Sibay, G., Uchitel, S., and Braberman, V. A. (2008). Existen-

tial live sequence charts revisited. In ICSE’08, pages

41–50. ACM.

Uchitel, S., Kramer, J., and Magee, J. (2001). Detecting

Implied Scenarios in Message Sequence Chart Speciﬁ-

cations. SIGSOFT Soft. Eng. Notes, 26(5):74–82.

Van Hee, K., Serebrenik, A., and Sidorova, N. (2008). Token

history Petri nets. Fundam. Inf., 85(1-4):219–234.

Van Hee, K., Serebrenik, A., Sidorova, N., and Van

Der Aalst, W. (2007). History-dependent Petri nets.

In ATPN’07, volume 4546 of LNCS, pages 164–183.

Springer.

APPENDIX

This appendix presents the formal semantics of dis-

tributed LSC. In the following we assume a set

actions. It includes names (or, labels) for all the events

that one wishes to refer to in a speciﬁcation.

Labeled Partial Orders.

We begin with some prelim-

inary deﬁnitions. A labeled partial order (lpo) is a

tuple

l = hE, <, λi

, where

is a (possibly inﬁnite)

set of events,

< ⊆ (E × E)

is a strict partial order re-

lation on

(i.e., irreﬂexive and transitive),

λ : E → Σ

is a labeling function, and, furthermore, for any event

x ∈ E

, the set

{y ∈ E : y ≤ x}

is ﬁnite. The last

property is included to restrict the form of lpo’s so that

they correspond to realizable traces of executions. We

write x ≤ y, iff x < y or x = y, for all x, y ∈ E.

Let

l = hE, <, λi

be an lpo. For any

A ⊆ E

, the

restriction of

is deﬁned by

= hA, < ∩ (A ×

A), λ|

, which is again an lpo. Let

= hE

, <

, λ

be another lpo.

ϕ : E → E

is an isomorphism from

onto

, denoted

∼

, if

is a one-to-one function

from

onto

, for any events

x, y ∈ E

holds

x < y

iff

ϕ(x) <

ϕ(y)

, and

◦ ϕ = λ

is isomorphic to

denoted

∼

, if there is

such that

∼

is said

to be ﬁnite (resp., empty) if E is ﬁnite (resp., empty).

We write

max(l)

(reps.,

min(l)

) for the maximal

(resp., minimal) events in

. Given a ﬁnite

A ⊆ E

, we

say that

is a maximal dense set in

max(l|

) ⊆

max(l)

, and for any

x, y ∈ A

and

z ∈ E

, if

x <

z < y

then

z ∈ A

. Given such

and another lpo

= hE

, <

, λ

such that

E ∩ E

= ∅

, the local

concatenation of

after

, is deﬁned by

l[A] →

= hE ∪ E

, < ∪ <

∪ ({x ∈ E : ∃y ∈ A : x ≤

y} × E

), λ ∪ λ

. It is easy to verify that it is again

an lpo. As a special case, the (global) concatenation

of l

after l is deﬁned by l →l

= l[E]→ l

Abstract Syntax of Distributed LSC.

A distributed

LSC (dLSC) is a tuple

L = hl

, l

, where

and

are ﬁnite nonempty lpo’s.

is called the prechart of

and

is called the main chart of

. As we assume

complete synchronization between the main chart and

the prechart, we technically separate the chart into

two lpo’s. A dLSC speciﬁcation consists of a tuple

S = hD, R

, where

is a ﬁnite set of dLSCs, and

is a ﬁnite lpo called the initial run.

Semantics of Distributed LSC.

Given an lpo

l =

hE, <, λi

and a dLSC

L = hl

, l

, we ﬁrst deﬁne the

SynthesizingDecentralizedComponentsfromaVariantofLiveSequenceCharts

set of all continuations of

according to

, which is

denoted by

. Put

= hE

, <

, λ

, and, with-

out loss of generality, assume that

E ∩ E

= ∅

(we

may always take

∼

satisfying this constraint).

Then,

is the set of lpo’s of the form

l[A] → l

where

A ⊆ E

is a ﬁnite maximal dense set in

such

that

∼

. Moreover, given a set

of dLSCs, the

set of all continuations of

according to the charts

in D is deﬁned by lB

L∈D

l B

Given a dLSC speciﬁcation

S = hD, R

, a con-

struction sequence for

is a sequence of lpo’s

with

domain

0 < D ≤ N

(i.e.,

is either the set

all natural numbers, or a natural number

n > 0

, in

the sense that

D = n = {i ∈ N : i < n}

), sat-

isfying the following:

= R

, and for all

i ∈ D

such that

i + 1 ∈ D

holds

i+1

∈ ρ

. For each

i ∈ D

, put

= hE

, <

, λ

. Then, the value of

is deﬁned to be the lpo corresponding to the limit

of the sequence, which can be formally deﬁned by

val(ρ) =



i∈D



It is easy to verify that

val(ρ)

is, in turn, a (pos-

sibly inﬁnite) lpo, and that if

is ﬁnite then

val(ρ)

is the last lpo in the sequence. The construction se-

quence

is said to be ﬁnal if also

val(ρ)B

= ∅

The (denotational) semantics of a dLSC speciﬁca-

tion

is an lpo language deﬁned by

L(S) = {val(ρ) :

ρ is a ﬁnal construction sequence for S}.

MODELSWARD2013-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment