Towards a Systematic, Tool-Independent Methodology for Deﬁning

the Execution Semantics of UML Proﬁles with fUML

emie Tatibou

et, Arnaud Cuccuru, S

ebastien G

erard and Franc¸ois Terrier

CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems, P.C. 174, Gif-sur-Yvette, 91191, France

Keywords:

Execution, Semantics, fUML, Alf, Proﬁle, Turing, DSML, MoC.

Abstract:

The purpose of UML proﬁle mechanism is to design domain speciﬁc languages (DSL) based on UML. It

exists a wide range of UML proﬁles: MARTE, ROOM, SysML. Current proﬁle design methodology only

considers the syntactic part of the language and keeps informal the execution semantics description. This

impairs Model Driven Engineering (MDE) promises which advocates for executable models. This paper

presents a systematic approach to formalize the execution semantics of UML proﬁles using foundational UML

(normative speciﬁcation) which deﬁnes a precise semantics for a subset of UML. This approach is integrated

into the reference proﬁle design methodology. It is illustrated on a small proﬁle to support Turing machines.

It demonstrates capability to execute resulting proﬁled models through the deﬁned semantics.

1 INTRODUCTION

The maturity of UML (OMG-UML, 2011) authoring

tools, the diversity of notations and concepts avail-

able, and the possibilities to adapt the language to

domain speciﬁc needs with proﬁles, are probably the

main reasons for the wide spreading of UML.

Since the beginning of its usage and adoption,

UML however suffered from a lack of formal,

machine-readable semantic description. Since 2010,

this drawback has been considerably reduced by the

release of foundational UML (OMG-fUML, 2010),

which standardizes execution semantics for a subset

of UML.

An obvious use case enabled by fUML concerns

execution of models, with the possibility for software

or system engineers to observe how their models be-

have at runtime. Engineers can thereby get reliable

evidences that their models actually perform what

they expect (Selic, 2009), with the guarantee that their

observations are not biased by tool-speciﬁc interpre-

tations. The interest of the UML community on using

such formalized semantics is conﬁrmed by the num-

ber of tools which already provide execution support

for fUML, with both open-source (e.g., Moliz, devel-

oped by the Vienna Technical University, or Moka

)

or commercial (e.g., the Cameo Simulation Toolkit

for Magic Draw, or the AMUSE extension for En-

Developed on top of Papyrus by our laboratory at the

CEA LIST

treprise Architect) tools. However, it is important

to remind that fUML formalizes execution semantics

only for a subset of UML. Obviously, the theoreti-

cal advantage of a common, tool-independent under-

standing only holds for models complying with this

subset. As soon as non-fUML constructs are required,

tool providers have to make choices, based on their

own interpretation of UML semantics.

One fundamental issue remains on the usage of

proﬁles, which are the usual mechanism to adapt

UML to domain speciﬁc needs. They typically im-

ply extending or overloading the UML semantics.

While these extensions may have signiﬁcant impacts

in terms of observable executions, the issue of for-

malizing execution semantics of UML proﬁles has

only triggered a few research proposals (Muller et al.,

2005), (Cuccuru et al., 2007), (Riccobene and Scan-

durra, 2010) and is still not standardized. This leads

proﬁle users to obtain application models for which

they do not have a shared understanding about their

expected behaviors. In addition, since a proﬁle has no

execution semantics, then models built with the pro-

ﬁle are not executable.

In previous works (Tatibouet et al., 2013) we pro-

posed an approach for controlling the execution of

fUML models according to speciﬁc Models of Com-

putation

(MoC). The approach was based on model

libraries formalizing the semantics of MoCs in the

Semantics of the interaction between modules or com-

ponents (Chang et al., 1997).

182

Tatibouët J., Cuccuru A., Gérard S. and Terrier F..

Towards a Systematic, Tool-Independent Methodology for Deﬁning the Execution Semantics of UML Proﬁles with fUML.

DOI: 10.5220/0004696801820192

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 182-192

ISBN: 978-989-758-007-9

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

form of executable fUML models. In this paper, we

propose to generalize this approach, using fUML to

formalize execution semantics of UML proﬁles, and

thus obtain a standard compliant support to deﬁne ex-

ecution semantics of both UML and proﬁled UML

models.

The remainder of this paper is organized as fol-

lows. In section 2, we give a reminder on the ref-

erence methodology for the deﬁnition of UML pro-

ﬁles (Selic, 2007) and we highlight the lack of guide-

lines to specify their execution semantics and its im-

pact on current practices. In section 3, we give an

overview of the tools and methodologies that have

been developed to formalize the semantics of mod-

eling languages. We provide a comparison with our

proposal. In section 4, we rigorously apply the pro-

ﬁle design process presented in section 2. First, we

describe the deﬁnition of a language for expressing

Turing machines and its projection on UML as a set

of stereotypes and constraints. Second, we explain

our main contribution which consists in showing how

the semantics are deﬁned with fUML and attached to

stereotyped model elements. To demonstrate the fea-

sibility of our approach, we show the execution of a

Turing machine modeled using this proﬁle. In section

5, we conclude this article with a discussion about rel-

evant future works.

2 PROFILE DESIGN PROCESS

The UML speciﬁcation describes the proﬁle mech-

anism as a capability to extend metaclasses, in or-

der to adapt them for different domains or platforms.

The underlying motivation is to provide people using

MDE in their everyday work with a mean to develop

specialized versions of UML, tailored to their spe-

ciﬁc needs. By tuning UML they get beneﬁt from the

wide range of modeling constructs and available tool-

ing. This general modeling framework allows them to

develop quickly a modeling language specialized for

their needs.

Designing a proﬁle is a rigorous process whose

guidelines are established in (Selic, 2007). Section

2.1 presents this methodology as well as the criteria

deﬁned in (Pardillo, 2010) to assess the quality of pro-

ﬁles. In section 2.2, we show that the current material

only provides guidelines about the syntactic dimen-

sion of the proﬁle and its static semantics. Execution

semantics are neglected. We explain why this is a real

issue, and we identify the requirements of a system-

atic approach for specifying the execution semantics

of a proﬁle.

2.1 Context and Methodology

Over the last decade a large number of proﬁles were

released in the MDE ﬁeld. An impartial study (Par-

dillo, 2010) evaluated a subset of 39 proﬁles presented

in the two top levels conferences of the domain and

assessed them according to the following criteria:

A. Presence of a domain model (metamodel)

B. Constraints limiting the expressiveness of stereo-

typed UML elements

C. Presence of diagrams showing the extended meta-

classes and their stereotypes.

D. Presence of a formalized execution semantics

The results obtained showed an important hetero-

geneity in terms of quality between the evaluated pro-

ﬁles (i.e., no domain model, no constraints on the ex-

tended metaclasses, difﬁculties to align the domain

concepts on the proﬁle). This can be explained by

the various levels of UML skills of proﬁle designers,

but the main reason is probably the lack of material

providing guidelines for the construction of proﬁles.

As far as we know, only one methodology has been

published (Selic, 2007). As illustrated in Figure 1, it

goes over three steps and can be coupled with quality

criteria previously presented. The ﬁrst step is the def-

inition of the domain concepts (P1 on Figure 1, Cri-

terion A). The second one is the projection of these

latter on UML as a set of stereotypes (P2 on Figure

1, Criterion C), and the last one consists in limiting

UML expressiveness to the domain (P3 on Figure 1,

Criterion B).

Figure 1: Proﬁle design process overview.

In the next section, we present this methodology

with an academic but representative example: a lan-

guage for expressing Turing machines. It will be used

as a case study all along the article. Basics about Tur-

ing machines are presented in section 4.1.

TowardsaSystematic,Tool-IndependentMethodologyforDefiningtheExecutionSemanticsofUMLProfileswithfUML

183

2.1.1 Deﬁnition of a Domain Model

A usual way to capture and formalize concepts of a

domain is to design a metamodel (denoted as P1 in

Figure 1) without any consideration to what the pro-

ﬁle should provide. This step is achieved by an expert

of the domain. It enables the deﬁnition of the abstract

syntax and the terminology of the modeling language.

An excerpt of the Turing Machine domain model is

depicted in the left-hand side of Figure 1.

2.1.2 Projection of Domain Concepts on UML

This step, denoted as P2 in Figure 1, consists in se-

lecting UML metaclasses that can represent concepts

provided by the domain model. A UML metaclass

is chosen if it is semantically close to a domain con-

cept. This evaluation is the result of the collabora-

tion between a domain expert and a UML expert, and

leads to the creation of speciﬁc stereotypes (e.g., Tur-

ingState in Figure 1) representing the domain concept

(e.g., State in the domain model). Although this step

is mostly manual, it can be computer assisted as ex-

plained in (Noyrit et al., 2013).

2.1.3 Limiting UML to the Domain

The UML constructs involved in a proﬁle usually

need to be constrained to respect the expressiveness

of the domain. For example, the UML metaclass State

can be associated with an entry Behavior. In the exe-

cution semantics of UML StateMachine, this Behav-

ior shall be executed when entering a State. In our

example, the domain concept State (left-hand side of

Figure 1) is mapped onto the metaclass State (right-

hand side of Figure 1) with stereotype TuringState.

However, it has slightly different execution semantics,

since leaving or entering a State in a Turing machine

has no effect. This requires OCL (OMG - OCL, 2012)

constraints to be added (P3 in Figure 1) within the

proﬁle to ensure the designer always produces syntac-

tically valid models (in this case, a TuringState shall

not have an entry behavior: base.entry→size()=0).

2.2 Semantics and Execution

This section highlights the lack of guidelines for spec-

ifying proﬁle semantics and the consequences on cur-

rent practices. Then, it explains the signiﬁcance of

formalizing proﬁles execution semantics and the di-

rect beneﬁts of such practise.

2.2.1 Proﬁles and Semantics

Foundations on providing a language with its seman-

tics (i.e., meaning) are given in (Harel and Rumpe,

2004). The process consists in mapping the syntax

of a language L to its semantic domain S (M:L→S).

This mapping step enables designers to have a shared

understanding on how models built from a language

have to be interpreted.

In section 2.1, we detailed the methodology pro-

posed by B. Selic to design a proﬁle. One can notice

it only considers the deﬁnition of the abstract syn-

tax (i.e., L) although the author makes suggestions on

how the semantic domain could be deﬁned (i.e., using

fUML). A consequence of this lack of guidelines is

that 80% (Pardillo, 2010) of them (i.e., proﬁles) only

provide an abstract syntax and its associated surface

notation. This is not sufﬁcient to allow proﬁle users

to share a common understanding of the meaning of

the language.

2.2.2 Proﬁles and Execution Semantics

According to (Harel and Rumpe, 2004), providing a

language with its semantics does not mean it is exe-

cutable. We perfectly agree on that point. However,

in a large number of cases, langages and especially

modeling languages are intended to be executable.

Providing a language with an execution semantics

means this latter is depicted as an interpreter or a pro-

gram describing all valid executions for the construc-

tions available in the language. Since the language is

executable, it enables to:

+ Observe the future system at runtime as soon as

possible in the development cycle for the purpose

of detecting unexpected behaviors. This offers a

good alternative to formal techniques that usually

have scalability problems to assess large models.

+ Make models capable of collaborating at runtime

with other models that may embed different exe-

cution semantics and different representations of

time (e.g., an fUML model collaborating with a

Simulink model).

+ Enable an easier communication between stake-

holders by animating the model at runtime.

Enabling these use cases, requires proﬁle design-

ers to provide proﬁles with a formalized execution se-

mantics.

Now the question is: do we have to design the ex-

ecution semantics for the domain model or for the

proﬁle ? Pragmatically, the semantics is known by

the domain expert. Therefore, we believe it should be

designed for the domain model but must be applicable

to the proﬁle.

A second question is: what are the requirements

that a systematic approach for specifying the exe-

cution semantics of a proﬁle must fulﬁll ? We iden-

tify four main requirements:

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

184

1. Make the speciﬁcation as independent as possible

from tooling: the execution semantics must rely

on a formalism which is open and standard in or-

der to promote cross-tooling compatibility.

2. Avoid exogeneous non-conservative transforma-

tions (i.e., transformation which takes a model de-

scribed in a language with no precise semantics

and produces a representation of that model in a

language having one. However nothing says both

models have the same meaning) between model-

ing formalisms: providing reliable feedbacks on

an applicative model and avoiding loss of seman-

tics implies minimizing the number of transfor-

mation steps to associate a modeling formalism

with its execution semantics.

3. Make the speciﬁcation easily accessible to design-

ers of application models: enabling them to share

a common understanding about how their proﬁled

models should behave at runtime requires an ex-

plicit model of the semantics.

4. Be as independent as possible from the UML pro-

jection details required by the proﬁle deﬁnition

under consideration: the semantics of the lan-

guage relates to the domain, not to its implemen-

tation in UML.

These requirements will be used in section 3 to as-

sess state-of-the-art methodologies proposed for spec-

ifying UML proﬁles execution semantics.

3 RELATED WORKS

This section presents strategies and methods used to

specify execution semantics of Domain Speciﬁc Mod-

eling Languages (DSML). Then, it focuses on the ap-

proaches recently proposed to specify execution se-

mantics of UML proﬁles. These approaches are dis-

cussed to highlight their limits and to position our ap-

proach.

3.1 Approaches for Specifying DSMLs

Execution Semantics

A DSML is deﬁned by a metamodel speciﬁed with

a metamodeling language. The most widespread

metamodeling language is the Meta Object Facility

(OMG-MOF, 2011), which, for example, has been

used for the deﬁnition of UML. However the scope

of MOF is limited to the structural description of a

language. No behavior can be associated with a meta-

model. Two similar approaches have been developed

to overcome this limitation.

The ﬁrst one is Kermeta (Muller et al., 2005). It

consists in composing the Essential MOF (EMOF)

metamodel with an action metamodel weaving the be-

havioral aspects into the structure. The result is an

executable EMOF metamodel.

The second one is xMOF (Mayerhofer et al.,

2012). As Kermeta does, this approach proposes to

enable the deﬁnition of behavioral concerns of a lan-

guage at the metamodel level. To do so it integrates

a subset of fUML as a way to specify behavioral se-

mantics at the MOF level. The main difference be-

tween these two approaches is related to fUML: the

Kermeta language does not allow expressing concur-

rency while fUML does.

These two approaches both rely on MOF. How-

ever this is not always the case. MetaEdit (MetaCase,

2012) rather provides an ad-hoc metamodeling frame-

work enabling experts of a speciﬁc domain to design

their own modeling language. In addition, unlike Ker-

meta and xMOF, execution semantics are not explic-

itly speciﬁed; they are hidden in the code generator

associated with the newly created language.

Although these approaches are interesting, they go

beyond the UML scope and do not consider the spec-

iﬁcation of UML proﬁles execution semantics which

is the core purpose of this paper. In addition, Kermeta

approach is speciﬁc to the tooling and MetaCase re-

lies on a non-standard formalisms.

3.2 Approaches for Specifying

Execution Semantics of UML

Proﬁles

Considering statistics provided in (Pardillo, 2010),

only 20% of the state-of-the-art proﬁles are released

with a description of their execution semantics. When

available, this description is most of the time infor-

mal, speciﬁed in natural language. However, we also

observe three other cases:

1. As for DSMLs, the execution semantics of a

proﬁle can be encapsulated in a code genera-

tor. For instance, in (Mraidha et al., 2008), a

framework is proposed for supporting execution

of models stereotyped with concepts issued from

the MARTE proﬁle (OMG-Marte, 2011). These

application models are transformed into equiva-

lent C++ code encapsulating the semantics. The

generated code is executed and constrained by the

resources deﬁned at the model level for the Ac-

cord—UMLvirtual machine (Phan et al., 2004).

2. Other approaches rely on model transforma-

tions. These latter consist in targeting a model-

ing formalism having a precise execution seman-

tics, and then to implement transformation rules

TowardsaSystematic,Tool-IndependentMethodologyforDefiningtheExecutionSemanticsofUMLProfileswithfUML

185

from the proﬁle deﬁnition to the target formalism.

Among approaches relying on this strategy, we

can cite (Riccobene and Scandurra, 2010). This

work proposes to specify the execution seman-

tics of a subset of the SystemC proﬁle (which is

deﬁned by the same authors) concerning process

state machines. To do so, the UML abstract syn-

tax for state machines (and extensions established

with SystemC stereotypes) is mapped to the Ab-

stract State Machine formalism (ASM), which is

formally deﬁned. At this step, execution seman-

tics are provided as ASM transition rules using a

textual surface notation. Therefore UML applica-

tions models annotated with the SystemC proﬁle

are then transformed into equivalent ASM mod-

els on which the execution semantics previously

deﬁned apply.

3. The third kind of approach consists in construct-

ing a model of the semantics of a language, usu-

ally in the form on an interpreter for that language.

In the UML context, few papers go in that di-

rection for specifying execution semantics of pro-

ﬁles. (Cuccuru et al., 2007), demonstrates how

proﬁling practices can be enhanced this way, with

a focus on semantics variation points introduced

by UML. It proposes a mechanism to encapsu-

late the operational semantics of semantic varia-

tion points with an execution model embedding a

behavioral description speciﬁed in fUML.

Discussion on Previous Approaches

The ﬁrst approach presented in this section requires

code generation from a model to obtain an executable

form. This strategy hides the execution semantics in-

side the code generator. This does not promote an

easy access to the execution semantics and contradicts

the requirement 3 presented in section 2.2.2. Indeed,

the only way to check out computations associated to

a modeling construct is to investigate the correspond-

ing source code.

The second approach presented is based on con-

servative model transformations to obtain an exe-

cutable model. Although preservation of semantics

might be ensured, the transformation step implies that

the model actually executed is not the one produced

by the designer. It could therefore be difﬁcult to pro-

vide feedbacks about the execution of the original

model (requirement 2 presented in section 2.2.2).

With respect to our requirements, the third ap-

proach seems the most interesting. By choosing

fUML, it makes the speciﬁcation independent from

tooling (requirement 1), promotes its accessibility

(requirement 2) and avoid additional transformation

steps to provide variation points with their execu-

tion semantics (requirement 3). However, the solu-

tion proposed by this article (Cuccuru et al., 2007) is

ad-hoc to the proﬁle and thus contradicts the require-

ment 4 presented in section 2.2.2. In addition, it was

proposed before fUML was released and can no more

be applied due to its dependency on UML templates

which are not included in the fUML ﬁnal speciﬁca-

tion.

3.3 Position of our Approach

fUML provides a formalized semantics for a

carefully-selected subset of the UML. This basic can

be viewed as a programming language and can there-

fore be used to specify semantics of other languages.

In (Tatibouet et al., 2013), we showed it was fea-

sible to formalize the execution semantics of a MoC

(i.e., semantics of interactions) using fUML and to in-

ject this latter in the runtime of an application model

to enable observation of different execution orders

and discrete time representation.

In this paper, we propose to extend this approach

and B. Selic methodology in order to specify pro-

ﬁles execution semantics. The idea is to provide a

domain model and to design its execution semantics

as a fUML model. Since the domain model and the

proﬁle are semantically aligned then the execution se-

mantics can be applied on both. We will obtain an ex-

ecution semantics playing the role of an interpreter for

a model conforming to the DSML deﬁned as a proﬁle.

This execution semantics will be itself interpreted by

the original semantics provided by fUML.

By specifying the execution semantics as a fUML

model, we make it compatible with any tool imple-

menting fUML and UML (i.e., Magic Draw, Papyrus,

Entreprise Architect, Moliz, AMUSE, etc). Therefore

we promote its accessibility and we rely on an open

standard formalism. These two points fulﬁll the re-

quirements 1 and 3 presented in section 2.2.2.

Since we propose to design the proﬁle and its exe-

cution semantics using the same modeling formalism,

then there is not any exogeneous model transforma-

tion required to map the language with its execution

semantics. This makes our approach compliant with

the requirement 2 presented in section 2.2.2 .

The way we design the semantics is independent

from the projection details existing between the do-

main model and the proﬁle. Indeed the semantics

is deﬁned according to the domain model without

any consideration to UML metaclasses that have been

chosen to be extended. This fulﬁlls the requirement 4

presented in section 2.2.2.

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

186

4 CASE STUDY: A DSML FOR

TURING MACHINE

In this section, we start by deﬁning a domain model

for Turing machines. Then, we present the projec-

tion of underlying concepts and their semantic align-

ment on UML using the proﬁle mechanism. Section

4.3 details the speciﬁcation of the execution seman-

tics of Turing machines (chosen due to their closeness

to UML state machines) as a fUML model, and how

we proceed to attach these semantics with stereotyped

elements. Finally, section 4.4 illustrates the proposal

with the execution of a Turing machine specifying the

copy of a string located at a certain position of a tape,

highlighting the technical issues that were solved.

4.1 A Metamodel for Turing Machines

According to the methodology we went through in

section 2.1 the construction of a proﬁle begins with

the construction of a metamodel capturing exclusively

the concepts of a domain without any consideration

for the future UML mapping. Figure 2 is the meta-

model we deﬁned for expressing Turing machines ac-

cording to the domain.

Figure 2: Metamodel for Turing machines.

• A TuringMachine represents a program that can

understand a speciﬁc set of inputs called alphabet.

It must be expressed as a set of States. One among

them is designated to be the initial state.

• A State represents a possible state during the ex-

ecution of a Turing Machine. It contains a set

of Rules describing state transitions, according to

symbols read on the tape.

• A Rule references an Input describing the ex-

pected symbol to be activated. It also contains an

Output which describes a set of actions that need

to be realized when activated.

• Input represents a symbol modeled as a string.

• Output represents a set of actions that needs to be

realized. The property symbol speciﬁes a string

to be written on the tape. The property direction

speciﬁes the direction to follow in order to move

the cursor positioned on the tape. Output also ref-

erences a target State which will be reached after

execution of the owning rule.

• TapeMovementKind element represents the differ-

ent direction that can be speciﬁed by a designer

for an Output element.

4.2 A UML Proﬁle for Turing Machines

The second step of the methodology consists in the

projection on UML of the domain concepts proposed

in the metamodel. The difﬁculty is to choose the right

metaclasses in the UML metamodel in order to se-

mantically align the created stereotypes to the domain

concepts. Figure 3 presents the structure of the pro-

ﬁle.

The UML speciﬁcation describes a StateMachine

as “a graph of state nodes interconnected by one or

more joined transition arcs”. Conceptually, it is close

to the TuringMachine concept. A UML StateMa-

chine describes a behavior whose dynamics is based

on event consumption. Consumption of an event is

only possible when the StateMachine is in a stable

state and occurs according to the Run To Completion

semantics. The event that is dispatched provokes a

state to be exited, a transition to ﬁre and the target

state to be entered.

Turing machines have similar semantics. In their

context, a symbol is read on a tape which makes a

rule of the current state to be activated. The execu-

tion of the rule will modify the tape and might change

the current state. Both concepts seem to be close con-

ceptually and semantically. Therefore it seems natu-

ral to express a TuringMachine through the concept

of StateMachine. The result is the Stereotype Turing-

Machine which extends the StateMachine metaclass.

In order to limit the modeling capabilities of the orig-

inal metaclass, we add OCL constraints (an excerpt

is shown on Figure 3). For instance, a StateMachine

stereotyped TuringMachine can only have one region

since there is no concurrency.

The same process is repeated for the different con-

cepts provided in the domain model. State of Turing

machine metamodel becomes active when it is entered

as a result of the execution of a Rule and becomes in-

active when it is exited as a result of the execution of

a Rule. This is close to the semantics attached to the

UML metaclass State. Therefore we deﬁne a stereo-

type TuringState which extends that metaclass.

A UML Transition is a directed relationship be-

TowardsaSystematic,Tool-IndependentMethodologyforDefiningtheExecutionSemanticsofUMLProfileswithfUML

187

Figure 3: Proﬁle for Turing machines.

tween a source state and a target state. A transition

can have a guard speciﬁed as a Constraint and an

effect speciﬁed as a Behavior. This latter describes

the computations to be realized whether this transition

ﬁres. An equivalent semantics is described for Turing

machines. In the domain model we have the concept

of Rule. A Rule is owned by a State and can only be

activated if the symbol read on the tape matches the

speciﬁed Input. At this step it seems natural to map

the Rule domain concept on the metaclass Transition

and to have the stereotype Rule extending that meta-

class. The condition speciﬁed for a Rule is depicted

by an Input. This input plays the same role than the

guard speciﬁed by UML transitions. A guard is speci-

ﬁed as a Constraint. Therefore it is cohesive to have a

stereotype Input extending the metaclass Constraint.

This will allow the guard speciﬁed on an application

model to have the stereotype Input applied. Turing

machine Rule speciﬁes Output which describes ac-

tions that need to be performed (i.e., move on the

tape, write on the tape and go to another state) when

a rule is executed. This perfectly matches the role of

effect speciﬁed for a UML transition as a behavior.

Therefore we decided to extend the metaclass Behav-

ior with the stereotype Output.

4.3 An Execution Semantics Written in

foundational UML

After having established the stereotypes and the

semantics alignment with the domain concepts,

comes the deﬁnition of the execution semantics.

A Turing machine consumes symbols placed on a

Tape. Reading the current symbol implies executing

a Rule of the current State. The execution of a Rule

consists ﬁrst in the comparison between the read input

(i.e., the symbol) and the one attached to the Rule. If

Figure 4: Semantic speciﬁcation for Turing Machines.

this condition is satisﬁed the actions speciﬁed by the

Output of the Rule are executed. This implies:

1. Writing a symbol at the current position of the

Tape.

2. If a direction is speciﬁed moving the Tape cursor

one step forward or one step backward.

3. Switching the current state to the target State of

the Rule.

The execution semantics is speciﬁed for the Tur-

ing Machine metamodel. It is depicted in Figure 4,

as a fUML model (yellow elements) separated from

the deﬁnition of the language being capable of inter-

preting Turing machines. In this semantic speciﬁca-

tion we have the class TuringMachineExecution. This

latter acts as a semantic visitor for a Turing machine

(i.e., speciﬁcation) and describes in the deﬁnition of

its execute operation how should the Turing machine

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

188

Figure 5: Semantics and application model representation at runtime.

be executed.

Figure 6: Behavior speciﬁcation for TuringMachine seman-

tic visitor.

This description is formalized by an fUML activ-

ity, compiled, from a speciﬁcation written with Alf

(OMG-Alf, 2012). This language is the textual sur-

face notation for fUML so there is no loss of seman-

tics during the generation step. As an example, the

Alf speciﬁcation of the TuringMachineExecution ex-

ecute method is depicted in Figure 6.

This way of specifying the semantics is compliant

with the design used by fUML for designing its se-

mantics (i.e., a metaclass and semantic visitor for that

metaclass).

How will things take Place at runtime? Figure 5

details the content of three levels of abstractions M2,

M1 and M0. The level M2 presents two fUML syntac-

tic elements (i.e., Association and Class) and their se-

mantic visitors. The semantic visitor for the metaclass

Class is the metaclass Object. The meaning of this

relation is that a fUML Object represents an instance

of Class. The level M1 contains the deﬁnition of the

domain model for Turing machines and its execution

semantics speciﬁcation. These two cannot be at the

level M2 since they are designed as fUML models

(i.e., models of UML classes). As an example, Fig-

ure 5, represents at the level M1 the relation between

the TuringMachine class and its semantic visitor Tur-

ingMachineExecution highlighted in red in Figure 4.

In the context of fUML, the runtime (i.e., level

M0) of a model is deﬁned as a set of extensional val-

ues stored in a locus. These values represent fUML

instances of a particular model. Therefore, to be ex-

ecuted a Turing machine speciﬁed from the domain

model needs to be represented at the fUML locus

(M0). As shown in Figure 5, we will have an in-

stance of the class TuringMachine represented as an

instance of a fUML Object (i.e instanceofTM) whose

type is that class. This object will represent part of an

application model which is a Turing machine. Such

instances have no behaviors and so will not evolve at

runtime because they offer only a structural view of

the application model and do not embed its semantics.

This means we also need to have the execution seman-

tics represented at the locus. Therefore we will have

the TuringMachineExecution class represented as an

TowardsaSystematic,Tool-IndependentMethodologyforDefiningtheExecutionSemanticsofUMLProfileswithfUML

189

instance of a fUML Object (i.e., instanceofTME) im-

plementing part of the execution semantics for mod-

els of Turing machines. In order to make the fUML

Object depicting part of the Turing machine (i.e in-

stanceofTM) executable by the fUML Object imple-

menting its execution semantics (i.e., instanceofTME)

we will need to have in the locus a instance that rep-

resents the association between those objects. fUML

provides a Link (M2) semantic element representing

an instance of an instance of the metaclass Associa-

tion. The instance of the Link will be typed by speciﬁ-

cation assoc (M1) as shown in Figure 5 that will own

two feature values representing values association for

both ends of the instance of the Association. This way

the association end tme will be assigned to the fUML

Object representing an instance of TuringMachineEx-

ecution (i.e., instanceofTME) and the other one spec-

iﬁcation will be assigned to the fUML Object repre-

senting the model element instance of Turing machine

(i.e instanceofTM in Figure 5). In other words, we

have at M0, an instance of the semantics model for

the Turing machines which is executed through the

semantics of fUML and the execution of that model

provokes the execution of an application model de-

scribing a Turing machine according to the execution

semantics provided in the semantic model.

4.4 Execution of a State Machine tuned

to the Turing Machine Domain

Being able to execute a state machine having the pro-

ﬁle for Turing machines applied through the execu-

tion semantics deﬁned for the domain model requires

solving two problems:

1. The Turing machine semantic model can only ex-

ecute an application model designed from the do-

main model.

2. To be represented at a speciﬁc locus an application

model must be designed with the elements that are

part of the fUML subset.

4.4.1 Case Study

In order to illustrate that section we designed a

particular instance of a Turing machine speciﬁed

as a proﬁled UML state machine (cf. Figure

7). This latter is capable of copying a string

located on a tape after a speciﬁc symbol. As

an example if the Turing machine works on the

tape [1—0—1—1—0—!—*—*—*—*—*—*—*]

it will copy the string “10110” after the delim-

iter “!”. The result would be the following tape

[1—0—1—1—0—!—1—0—1—1—0—*—*].

Figure 7: Speciﬁcation of a copy Turing machine.

4.4.2 Solution

A proﬁled state machine representing a Turing ma-

chine must be viewed as a set of instances classiﬁed

under speciﬁc UML metaclasses (i.e., State, Transi-

tion, Constraint, Region). At this step, these instances

cannot be registered at a speciﬁc Locus because they

are not fUML Object instances. Therefore, the ﬁrst

challenge is to be able to obtain an equivalent rep-

resentation of this application model (M1) designed

with state machines modeling constructs in fUML

(M0). To do so, we introduce a transformation step

which for every elements of the proﬁled state machine

speciﬁes how to obtain an equivalent fUML Object.

Figure 8: Projection of the application model to the fUML

runtime via transformation.

In the fUML context, the metaclass Transition has

no semantics then the created fUML Object should

not be typed by that metaclass. In the other hand, we

have in the deﬁnition of the Turing machine language

the metaclass Rule which is semantically aligned on

the meaning of a UML Transition stereotyped Rule.

Therefore we inject within the fUML Locus a fUML

Object classiﬁed under domain concept Rule (cf. Fig-

ure 8). First this action gives a counterpart of our

stereotyped transition in fUML. Next it makes it in-

terpretable by the execution semantics deﬁned for the

Turing machine language.

At this step, there is no synchronization between

the proﬁled model and its equivalent expressed with

fUML. In other words, this means we do not know

the matching between a stereotyped element and a

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

190

fUML Object. The interest in the formalization of that

matching is important at two levels. From a concep-

tual point of view, it shows the semantics alignment

between a stereotyped element and its fUML equiv-

alent. This ensures we are cohesive when we give

feedback on an execution related to a stereotyped el-

ement. From a technical point of view this link can

be used to highlight the graphical representation of a

model element in a diagram. This should really help

the designer to observe and understand the execution

of its application model.

Figure 9: Link between the proﬁled element and its coun-

terpart within the fUML Locus.

Formalization of this link between the proﬁled el-

ement and its fUML representation takes place while

transformation occurs. In fUML an Object represents

an instance of a class at a Locus. If that class has prop-

erties then the Object needs to be able to represent

them. This is realized thanks to the concept of Fea-

tureValue which associates a Property to its value. We

use this concept to represent the link between a stereo-

typed element and its fUML representation. As an ex-

ample, in Figure 9, R1 Object instance stands for the

representation of the stereotyped transition R1 in the

fUML context. To make the traceability link explicit

between these instances, we add a new feature value

to the fUML Object R1. This feature value either ref-

erences a property named proﬁledElement having the

type EObject and a value for this latter. The value is

of type EObjectValue which is a specialization of the

fUML type PrimitiveValue. It offers the possibility

of having a fUML value whose type is EObject (i.e.,

with the meaning of EMF

) and the pointed value is

the stereotyped transition R1. Therefore at any time

the fUML Object R1 remains synchronized with its

source stereotyped model element. This makes possi-

ble at runtime to ask information to this latter or notify

it in order to insert feedback about the execution at the

UML model level.

http://www.eclipse.org/modeling/emf/

ACKNOWLEDGEMENTS

We wish to acknowledge Bruno Marques, CEA LIST,

for its technical contribution in the context of this

project.

5 CONCLUSIONS, LIMITATIONS

AND FUTURE WORKS

This paper presents an approach for deﬁning the ex-

ecutable semantics of a DSML embedded in a pro-

ﬁle as a fUML model. This approach is integrated

in the proﬁle development process deﬁned in (Selic,

2007). In addition, we demonstrated its feasibility

by executing proﬁled state-machines deﬁning Turing

machines through the execution semantics we speci-

ﬁed as a fUML model.

By supporting the deﬁnition of an execution se-

mantics in the proﬁle design process we encourage

proﬁle designers to produce technically and semanti-

cally (i.e., which does not contradict UML) valid pro-

ﬁles. The interest for the users of these proﬁles is

that they get executable UML proﬁled models. Exe-

cutability enables them to drive development of their

application models. Indeed they are able to validate

them by simulation of well-deﬁned scenarios, assess

their design and use debugging facilities.

The format (i.e., a fUML model) chosen to embed

the semantics speciﬁcation ensures it is usable by any

tools implementing the UML standards (fUML and

UML 2.5). Moreover designer can easily access it and

share a common understanding on the meaning of the

language for which the semantics applies. Providing

the execution semantics of a proﬁle as a fUML model

ensures semantics preservation. Indeed we always are

in the context of a UML model capable of interpreting

another UML model.

A limitation of this work that can already be an-

ticipated is that the semantics is speciﬁed for proﬁled

elements that do not belong to the syntactical subset

considered by fUML. In our current on-going works

we evaluate how the approach presented in this paper

applies to specify the semantics of stereotyped activ-

ity nodes or edges. As an example, whether a Con-

trolFlow is stereotyped “delay”, this could imply a

different execution semantics than the one deﬁned by

fUML. Indeed this latter could provoke the behavior

owning the seterotyped ControlFlow to wait for cer-

tain quantum of time before transmitting tokens to the

target activity node.

The second limitation relies on the mapping be-

tween the domain concepts and the proﬁle. Instead of

having a one to one mapping we could have situations

TowardsaSystematic,Tool-IndependentMethodologyforDefiningtheExecutionSemanticsofUMLProfileswithfUML

191

where a domain concept maps to a set of UML ele-

ments and vice versa. This has an impact on the way

we keep the synchronization between the model rep-

resented at the fUML Locus and the proﬁled model.

We currently evaluate a solution applying the proxy

design pattern in order to deal safely with these situa-

tions.

At the present time, we are applying the approach

presented in this paper to specify the execution se-

mantics for the ROOM

(Selic and Limited, 1996)

proﬁle. This proﬁle is the projection of a modeling

language built for designing real-time and embedded

application.

REFERENCES

Chang, W.-T., Ha, S., and Lee, E. A. (1997). Heteroge-

neous simulation: Mixing discrete-event models with

dataﬂow. J. VLSI Signal Process. Syst., 15(1/2):127–

144.

Cuccuru, A., Mraidha, C., Terrier, F., and G

erard, S. (2007).

Enhancing uml extensions with operational semantics

behaviored proﬁles with templates. In Proceedings

of the 10th international conference on Model Driven

Engineering Languages and Systems, MODELS’07,

pages 271–285, Berlin, Heidelberg. Springer-Verlag.

Harel, D. and Rumpe, B. (2004). Meaningful model-

ing: What’s the semantics of semantics? Computer,

37(10):64–72.

Mayerhofer, T., Langer, P., and Wimmer, M. (2012). To-

wards xmof: executable dsmls based on fuml. In Pro-

ceedings of the 2012 workshop on Domain-speciﬁc

modeling, DSM ’12, pages 1–6, New York, NY, USA.

ACM.

MetaCase (2012). Domain speciﬁc modeling with

metaedit+ : 10 times faster than uml.

Mraidha, C., Tanguy, Y., Jouvray, C., Terrier, F., and

erard, S. (2008). An execution framework for marte-

based models. In Proceedings of the 13th IEEE In-

ternational Conference on on Engineering of Com-

plex Computer Systems, ICECCS ’08, pages 222–227,

Washington, DC, USA. IEEE Computer Society.

Muller, P.-A., Fleurey, F., and J

equel, J.-M. (2005).

Weaving executability into object-oriented meta-

languages. In Proceedings of the 8th international

conference on Model Driven Engineering Languages

and Systems, MoDELS’05, pages 264–278, Berlin,

Heidelberg. Springer-Verlag.

Noyrit, F., G

erard, S., and Terrier, F. (2013). Computer

assisted integration of domain-speciﬁc modeling lan-

guages using text analysis techniques. In Proceedings

of the 16th international conference on Model Driven

Engineering Languages and Systems, MoDELS’13.

OMG-Alf (2012). Action language for foundational uml.

Technical report, Object Management Group.

Real-Time Object-Oriented Modeling

OMG-fUML (2010). Semantics of a foundational subset

for executable uml models. Technical report, Object

Management Group.

OMG-Marte (2011). Modeling and analysis of real-time

embedded systems. Technical report, Object Manage-

ment Group.

OMG-MOF (2011). Meta object facility. Technical report,

Object Management Group.

OMG-UML (2011). Uniﬁed modeling language. Technical

report, Object Management Group.

Pardillo, J. (2010). A systematic review on the deﬁnition

of uml proﬁles. In Proceedings of the 13th interna-

tional conference on Model driven engineering lan-

guages and systems: Part I, MODELS’10, pages 407–

422, Berlin, Heidelberg. Springer-Verlag.

Phan, T. H., Gerard, S., and Terrier, F. (2004). Lan-

guages for system speciﬁcation. In Grimm, C., editor,

Languages for system speciﬁcation, chapter Real-time

system modeling with ACCORD/UML methodology:

illustration through an automotive case study, pages

51–70. Kluwer Academic Publishers, Norwell, MA,

USA.

Riccobene, E. and Scandurra, P. (2010). An executable se-

mantics of the systemc uml proﬁle. In Proceedings

of the Second international conference on Abstract

State Machines, Alloy, B and Z, ABZ’10, pages 75–

90, Berlin, Heidelberg. Springer-Verlag.

Selic, B. (2007). A systematic approach to domain-speciﬁc

language design using uml. In Proceedings of the

10th IEEE International Symposium on Object and

Component-Oriented Real-Time Distributed Comput-

ing, ISORC ’07, pages 2–9, Washington, DC, USA.

IEEE Computer Society.

Selic, B. (2009). Elements of model-based engineering with

uml2: What they don’t teach you about uml.

Selic, B. and Limited, O. (1996). Real-time object-oriented

modeling (room). In Proceedings of the 2nd IEEE

Real-Time Technology and Applications Symposium

(RTAS ’96), RTAS ’96, pages 214–, Washington, DC,

USA. IEEE Computer Society.

Tatibouet, J., Cuccuru, A., G

erard, S., and Terrier, F. (2013).

Principles for the realization of an open simulation

framework based on fuml (wip). In Proceedings of

the Symposium on Theory of Modeling & Simulation -

DEVS Integrative M&S Symposium, DEVS 13, pages

4:1–4:6, San Diego, CA, USA. Society for Computer

Simulation International.

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

192