Towards Executable UML Interactions based on fUML

Marc-Florian Wendland

Fraunhofer Institut FOKUS, Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany

Keywords: UML Interactions, fUML, UML Activities, Executable UML, Executable Interactions, PSCS.

Abstract: Executable specifications for UML currently comprise fUML, precise semantics of composite structures and

in future precise semantics for state machines. An executable semantics for UML Interactions is on the

roadmap, but has not been addressed by the OMG Executable UML working group so far. Interactions are

said to be the second most used diagrams after class diagram of UML, thanks to their comprehensibility and

illustrative visualization. Unfortunately, they suffer from fuzzy semantics and technical issues that wastes the

potential Interactions could have for engineering activities apart from high-level specifications. In this

position paper we present first results from experiments and attempts to map UML Interactions to fUML

Activities in order to eventually execute them.

1 INTRODUCTION

UML Interactions, better known as sequence

diagrams, are a one of the standardized UML (UML,

2015) behavior kinds that describe the exchange of

messages among parts of a system or sub-system,

represented by Lifelines. Interactions are familiar to

many stakeholders because of their illustrative

graphical notation that is easy to comprehend.

However, the UML Interactions metamodel is not as

precise as desired, in particular with respect to data

(Wendland et al., 2013). As a result, they are mostly

used for sketching high-level specifications of use

cases or early protocol specification. UML

Interactions reveal global viewpoint on the interplay

of participating instances. This is different to UML

State Machines or UML Activities that usually

describe the behavior of dedicated participants from

an internal (or local) point of view. In fact, UML

Interactions are the only standardized UML behavior

that describe the exchange of Messages from a global

point of view. This give rise to the fact that

Interactions usually do not have no direct counterpart

in an implementation. They rather resembles a virtual

window that allows insights into the execution of

system at a certain point of time.

UML Interactions are said to be the UML’s

second most used diagrams (after class diagrams) due

to their easily comprehensible notation that foster

communication among stakeholder. For a more

precise system specification, however, the

aforementioned fuzzy semantics of UML Interactions

(including but not limited to the lack of data flow

concepts) makes it complicated to exploit their whole

potential. Executable Interactions help to overcome

the semantical shortcomings by explicitly stating

which features of UML Interactions can be used for

precise (yet executable) specifications and how these

features are modelled best with the UML Interactions

metamodel.

A working group at OMG has started giving

subsets of the UML behaviors a precise yet

executable semantics. The first standard of executable

UML was released in 2011 based on UML Activities.

It is called Foundational Subset for Executable UML

Models (fUML, 2012), in short fUML. Meanwhile, a

precise specification of the semantics of composite

structures (PSCS, 2015) is on the verge of being

standardized and above all the executable UML

working group is currently heading towards precise

semantics for executable state machines (PSSM).

UML Interactions are already on the roadmap of the

Executable UML working group but not in focus yet.

In this position paper, we report first results of a

mapping from UML Interactions to fUML in order to

assign the UML Interaction building blocks an

operational semantics. This enables the use of

Interactions for building executable specification,

which has, as we are certain, an enormous potential

to improve the entire development chain, spanning

from requirements engineering, rapid prototyping to

testing of executable specifications.

We focus in this position paper on UML

Wendland, M-F.

Towards Executable UML Interactions based on fUML.

DOI: 10.5220/0005809804050411

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 405-411

ISBN: 978-989-758-168-7

405

Interactions in an isolated way. UML behaviors are,

at least technically and theoretically, integrated with

each other. This enables engineers to select the

behavioral kind that is most appropriate for him or

her. The main objective of our work is to provide an

operational semantics for the constituents of an

Interaction (e.g. Messages, CombinedFragments etc.)

and the flow of execution within Interactions. As

such, the discussion about how Interactions integrate

with other UML behaviors (first and foremost fUML

Activities) is not part of this paper, but is rather a

research paper on its own.

This position paper implies familiarity with the

UML metamodel, in particular with Interactions and

Activities. Therefore, we spare an introduction into

the semantics and the metamodel of UML

Interactions, UML Activities and fUML.

The remainder of this paper is structured as

follows: In Section 2 the work related to our work will

be summarized. Section 3 summarizes the base

semantics and preliminary mapping rules of our

approach. Section 4 evaluates a proof-of-concept that

demonstrates the feasibility of our work. It

summarizes a issues we faced when working on the

mapping. Section 6 eventually concludes this paper

and sketches future work in the area of executable

UML Interactions.

2 RELATED WORK

A lot of work has been done in the first few years of

UML 2 in the realm of formal semantics of UML

Interaction traces. Haugen compares UML

Interactions and Message Sequence Charts (Haugen,

2004) showing that Interactions and MSCs are similar

down to small details.

Haugen, Stolen, Husa, and Runde have written a

series of paper on the compositional development of

UML Interactions supporting the specification of

mandatory and potential behavior, called STAIRS

approach (Haugen and Stølen, 2003; Haugen, Husa,

Runde and Stølen, 2005; Haugen, Husa, Runde and

Stølen, 2005; Runde, Husa, Haugen and Stølen,

2005). A depper analysis is dedicated to a fine-

grained differentiation of event reception,

consumption and timing (Haugen, Husa, Runde and

Stølen, 2005) and the refinement of Interactions with

regard to underspecification and nondeterminism

(Runde, Husa, Haugen and Stølen, 2005). Lund and

Stolen have presented an operational semantics for

UML sequence diagrams (Lund and Stølen, 2003).

Formal semantics of UML Interactions and

sequence diagrams were several times discussed.

Störrle presented a formal specification of UML

Interactions and a comparison of UML 2.0 and UML

1.4 Interactions (Störrle, 2003; Störrle, 2004). A

similar work was done by Knapp and Cengarle

(Knapp, 1999; Cengarle and Knapp, 2004), Li and

Ruan (Li and Ruan, 2011) and Shen et al., (2008).

Special attention was set to the semantics of assert

and negative CombinedFragments (Störrle, 2003;

Harel and Maoz, 2006), though. Prior to UML

sequence diagrams Damm and Harel (Damm and

Harel, 1999) worked on a notation called Life

Sequence Charts.

The work done by Wendland et al., (2013)

focuses a different aspect of UML Interactions,

namely the precise definition of Message arguments.

In that case, their work is different to the previously

mentioned papers that mostly dedicated to the trace

semantics of Message reception and consumption

within UML Interactions, but they did not focus on

precisely specifying data transmitted by Messages.

The work described in this paper is different to all

the previously mentioned work for it uses fUML to

state the semantics of UML Interactions. fUML’s

formal semantics was defined using the ISO standard

Process Specification Language (PSL, 2004) and

Common Logic (CL, 2007). The decision to map

UML Interactions to fUML was made to provide

engineers with an easy to understand and familiar

notation (UML Activities) for executable

Interactions. We think this increase both the

comprehensibility and applicability of executable

Interactions. In fact, an engineer who knows UML

Activities and its action semantics is capable of

reading and writing UML Interactions in a precise yet

executable manner.

3 TOWARDS EXECUTABLE

INTERACTIONS

The following section discusses some of the

fundamental concepts for executable Interactions.

Therefore, we related the semantics of UML

Interactions and some of its building blocks to fUML

concepts. Besides technical discussions we also

highlight restrictions to some meta-concepts of such

as the binding character or general trace semantics of

UML Interactions.

3.1 Descriptive Vs Prescriptive

Behaviors

UML introduces the notion of descriptive versus

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

406

prescriptive behaviors. UML State Machines and

Activities are prescriptive, whereas Interactions are

by definition descriptive. As such, Interactions tell

only parts of the story that is actually going on at

runtime. They do not claim to be complete, although

it not prohibited interpreting Interactions in such a

way. Descriptive (or partial) behavior is in particular

appropriate on a higher specification level, but for

model execution, prescriptive behavior is required.

Hence, the fundamental difference between

executable and non-executable Interactions is that the

first one prescribes explicitly what will happen and

does not describe what may happen at runtime.

3.2 Invalid Vs Valid Traces

UML Interactions are the only behavior that

differentiates between invalid and valid occurrence

traces, though. It enables engineers to model

scenarios that represent invalid system behavior, or

unwanted scenarios. Invalid traces are predestined

means to specify unwanted or undesired scenarios,

however, there is no understanding of the

consequences an invalid behavior entails once

occurred. This underpins the higher-level

specification character of Interactions, though.

Invalid traces are usually resolved into concrete

measures of an implementation or simulation like

e.g., throwing an exception or any other adequate

measure to handle and mitigate invalid system or

environment behavior (e.g., a user or an interacting

system behaves incorrectly). In fact, resolved invalid

traces constitute valid traces that specify what shall

happen in erroneous situations. Therefore, the notion

of invalid traces is excluded for executable

Interactions.

3.3 Ordering of Execution Traces

The main building blocks an Interactions consists of

are occurrences. An occurrence in the realm of

Interactions is the smallest piece of executable

behavior (e.g. a statement) and manifests as instance

of the metaclass OccurrenceSpecification in the

metamodel. (Actually, the real building blocks are

InteractionFragments, but only

OccurrenceSpecification represent execution of

event.) An OccurrenceSpecification is, thus,

semantically close to the metaclass Action that

represents the fundamental building blocks of

Activities.

fUML specifies the execution of a behavior as a

set of event occurrences called execution trace that

span from the invocation of the behavior over

behavior-local event occurrences to its termination.

This matches very well with the trace semantics of

Interactions that orders the InteractionFragments it

contains both globally and locally. The local

InteractionFragments (i.e., those covering the very

same Lifeline) result in corresponding Actions as

owned behavior of the Class that is represented by the

Lifeline. The corresponding Actions are connected by

ControlFlow edges (remember, no data manipulation

concepts). Global ordering of InteractionFragments is

for the construction of an Activity from a Lifeline less

important. If all the Lifelines are properly mapped to

Activities, abidance of global event occurrence

ordering is a result of abidance of local even

occurrence ordering.

The concrete Actions that constitute the resulting

executable fUML behavior of an Interaction

according to the covering InteractionFragments

depends eventually on the mapping rules for those

InteractionFragments.

3.4 Interaction and Lifelines

UML Interactions represent a global view on the

interplay of system parts. Even though we said earlier

that executable Interactions have to be prescriptive,

the global viewpoint of Interactions holds still true.

Nonetheless, the handling of a Lifeline’s lifecycle

needs to be co-ordinated. Therefore, an Interaction

(Interaction is also the name of the metaclass that

contains all building block, thus, it builds the

outermost boundary of the behavioral description) is

mapped to an Activity. This Activity is then

responsible for co-ordination. The co-ordinating

(henceforth called main) Activity is responsible to

initially create, accept (in case of an invocation of an

Interaction) and finally destroy Lifelines. The

semantics of Lifeline handling shall be aligned with

the PSCS semantics (PSCS, 2015), in particular with

its instantiation patterns.

A Lifeline indirectly represents (by representing a

part in a composite structure) a set of instances of a

Classifier. This Classifier shall only be of type Class

(there are further concrete subclasses of Classifier

such as DataType or Collaboration, though). The

reason is that only instances of the UML metaclass

BehavioralClassifiers are allowed owning behaviors

and as such offering methods to its environment.

Even though possible, executable Interactions

restrict the number of Lifelines that represent the

same part (role of a Class in the underlying composite

structure) to exactly one. This is mainly because the

selection mechanism of Lifelines, that distinguishes

sets of instances of the same role, is not precisely

Towards Executable UML Interactions based on fUML

407

specified in UML and requires clarification first.

UML states that the ValueSpecification that

constitute the selection mechanism shall evaluate to a

positive (range of) Integer, identifying the respective

instances in the set of all instances of the role. Since

roles may represent unordered collections, selection

by index cannot be applied.

Due to the global viewpoint of UML Interactions,

the use of parameters and global attributes needs

careful treatment. Such global ConnectableElements

(ConnectableElement is the common superclass of

Parameter and Property in UML), are in fact shared

among all Lifelines that take part in an Interaction

and, thus, need to be accessible by all Lifelines. This

means that there must be coordinating instance that

holds the ConnectableElements and grants access to

them. Since Interactions provide no concepts for data

flows or modifications as described in clause 17.1.1

in UML 2.5 (“…but the Interactions do not focus on

the manipulation of data even though data can be

used to decorate the diagrams.”), the use of global

ConnectableElements is discouraged for the time

being. Wendland, Schneider and Haugen have

recognized the lack of concepts to describe data flows

in Interactions and have provided a minimal

extension to the UML metamodel to mitigate these

shortcomings. This means that at some point in

future, when data flows are supported by Interactions,

the use of global ConnectableElements will be, for

sure, reconsidered by our work.

3.5 Mapping Rules Overview

Based on first investigations and experiments with

executable (i.e., fUML compliant) Interactions, we

identified a set of mapping rules between Interactions

and fUML metamodel. We spared all UML

Interaction concepts we have not yet fully

investigated. This means, every metaclass that is not

mentioned in Table 1 is left open for future work.

4 PROOF-OF-CONCEPT

Several prototypic (manual) compilations from UML

Interactions to fUML-based executable Interactions

have been performed prior to this work. A simple

abstract example that illustrates the feasibility of our

idea is depicted in Figure 1.

Table 1: Preliminary mapping rules for UML Interactions.

UML Interaction concept fUML Activity concept

Interaction (main) Activity

Lifeline Class with

classifierBehavior set to the

mapped Activity

Sending

MessageOccurrence

Specification (MOS)

SendSignalAction (later

also CallOperationAction,

Create/DestroyObjectActio

Receiving MOS AcceptEventAction (or

request to create/destroy

instances)

Message Arguments and signature

used to complete

InvocationAction; mapped

solely to Signal sending and

reception.

CombinedFragment

(only par, loop, alt, seq,

strict)

LoopNode, DecisionNode,

ForkNode,

ConditionalNode

GeneralOrdering Indirectly mapped to co-

ordinating Signals

InteractionOperand Sequence of Actions

connected by ControlFlow

4.1 Descriptions of the Example

The Collaboration ServiceChoreography consists of

two parts that are connected via a Connector that ends

in compatible Ports. The Interaction SD1 (potentially

in addition to further Interactions of the

Collaboration) is visualized as sequence diagram in

the lower compartment of the Collaboration (which

serves mere illustration purposes, but is not standard

UML). The Collaboration, its composite structure and

its owned behavior SD1 are compiled into a

corresponding fUML- and PSCS-compliant model

afterwerds.

Figure 1: Early proof-of-concepts for executable

Interactions.

In this example, however, we will solely focus on

the mapping of behavioral aspects. A precise

integration with PSCS, especially the create of new

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

408

instances (respectively Lifelines) is not covered in

this position paper.

The main Activity

ServiceChoreography_SD1

is responsible to instantiate and connect the instances

according to the PSCS rules. Afterwards, the

Operations that represent the respective Lifeline

behavior is started in parallel. Due to the already

instantiated and working instances, events can be put

into the respective event pools, thus, events will not

get lost, even if Service1_SD1 sends the Signal X

before Service2_SD1 awaits the Signal. The methods

of Service1_SD1 and Service2_SD1 are written in

pseudo-code that resemble literally the corresponding

fUML actions. We thought about employing the

Action Language for Foundational UML (Alf, 2013)

to denote the resulting fUML, but found the pseudo-

code simpler to understand for non-Alf experts,

though.

4.2 Evaluation

The proof-of-concept has confirmed the general

applicability of our idea. We were able to (manually)

translate the UML Interaction to a fUML Activity and

execute the Activity afterwards.

However, we spared on purpose more complex

aspects such as how Interactions integrate with other

behaviors and composite structures, and more

complicated building blocks (e.g., guards on

CombinedFragements, nested CombinedFragments,

Gates, creation/deletion of Lifelines etc.). These

aspects are subject to future research.

4.3 Faced Issues

The most severe fUML issue we encountered was the

missing of CallEvents and corresponding Actions like

AcceptCallEvent etc. Additionally, a

CallOperationAction is currently only allowed to be

synchronous, which is not sufficient for Interactions.

The lack of CallEvents leads to a situation where a

Lifeline may only actively wait for SignalEvents, but

not for CallEvents. Besides, the ongoing work on the

precise semantics for executable state machines

already identified the need to treat Signal sending and

Operation invocation equally based on the event

handing mechanism. There has already been an issue

submitted to OMG for this. We overcame this

shortcoming by mapping Messages with

MessageKind set to asynchCall and synchCall to

SendSignalActions and AcceptEventActions. For

future versions of fUML, however, we hope that the

missing Actions are incorporated into the language.

The fact that the work on PSSM introduces

CallEvents, we are confident that they will become

part of fUML as well rather soon.

Another fUML issue we found is that it does not

support the concept of owned behaviors unless they

represent the method of an Operation. This excludes

the BehaviorExecutionSpecification from the

mapping for it does not have an added value anymore.

Since it is not possible to pass parameters from the

calling Lifeline to an Behavior referenced from a

BehaviorExecutionSpecification and a Behavior

cannot be stand-alone owned by a Class, the only

behavior that could invoked by

BehaviorExecutionSpecifications is a context-free

Activity with optional or no parameters at all. Such

an invocation is of very limited use. We propose an

improvement to fUML to allow also context-aware,

stand-alone owned behaviors as well as a solution to

pass Parameters into

BehaviorExecutionSpecifications.

A third big, yet UML Interactions issue that needs

attention is the lack of concepts for describing data

flows. We hope that this issue will be eventually

addressed by executable UML state machine where it

is also required to access the data received by an

InvocationEvent for further processing (e.g., in

Transition guards and effects). Without data flow

mechanism, the use of Interaction for execution is

limited to the simulation of high- level specifications

where arguments of Messages have to be provide

always a priori. Such simulations may have their use,

but waste a lot of potential. We argue for addressing

the lack of data flow concepts in UML Interactions

rather sooner than later.

Apart from the issues that belong to fUML or

UML itself, there are a number of unresolved or

unclear mapping rules in our approach that need

further investigation. In this position paper, however,

we only discussed the mapping rules we had tried out

and verified so far. The UML Interactions metamodel

offers further metaclasses (such as Gate,

PartDecomposition, creation Message) that we have

not yet addressed.

5 CONCLUSIONS

In this position paper, we reported first results of our

preliminary work in the realm of executable UML

Interactions by relying on fUML semantics. We

argued why it make sense to strive for executable

Interactions, represented first and foremost by

sequence diagrams. We discussed the necessity for

the shift from descriptive UML Interactions to

prescriptive executable Interactions. Based on this,

Towards Executable UML Interactions based on fUML

409

we described a set of fundamental mapping rules

from the Interaction metamodel to the fUML

metamodel. A simple example was presented for

which we depicted a pseudo fUML snippet. Finally,

we raised awareness for open issues in fUML and

UML that we faced during our (manual) translation.

This approach is, to the best of our knowledge, the

first attempt to translate Interactions to fUML.

One surprising finding is that Interactions and

Activities, apart from fundamentally different

building blocks, are actually quite close to each other.

Even if not reported in this position paper, we have

identified suitable mappings for almost all concepts

in Interactions. Some of those mappings (which we

spared in this paper) are based on the assumption that

fUML supports the execution of context-aware

owned behaviors and CallEvents.

In particular the seamless integration of

executable Interactions with other executable UML

behaviors and the precise semantics of composite

structures needs more attention. For the sake of

simplicity, we treated Interactions in an isolated way

in our work. This led to a working, but autarkic proof-

of-concept. Such an autarkic view is suitable in order

to focus on the executable semantics of building

blocks firstly, but for a realistic application of

executable specifications, the seamless integration

needs to be achieved. Rules and constraints have to

be identified and specified to assist engineers building

such seamless and interworking executable

specification that potentially consist of fUML,

executable state machines, executable Interactions

and precise composite structures.

Future work in that area targets in particular

completion of our mapping rules. We plan

furthermore to support the executable UML working

group at OMG in raising awareness of the issues we

found and in resolving these issues. Our long-term

goal, however, is the utilization of fUML for building

a seamlessly integrated test execution system for

fUML simulations. The upcoming OMG standard

UML Testing Profile 2 enables specifying test case

specifications as Interactions, which are compiled

into executable test cases based fUML.

REFERENCES

Haugen, Ø. and Stølen, K.: STAIRS — Steps to analyze

interactions with refinement semantics. In Proc.

International Conference on UML, 2003.

Haugen, Ø., Husa, K. E., Runde, R. K., and Stølen, K.: Why

timed sequence diagrams require three-event

semantics. In Scenarios: Models, Transformations and

Tools, 2005.

Haugen, Ø., Husa, K.E., Runde, R.K., and Stølen, K.:

STAIRS towards formal design with sequence

diagrams. Journal of Software and Systems Modeling,

2005.

Runde, R. K., Haugen, Ø., Stølen, K.: Refining UML

interactions with underspecification and

nondeterminism. In: Nordic Journal of Computing, 2005.

Lund, M. S., and Stølen, K.: A fully general operational

semantics for UML 2.0 sequence diagrams with

potential and mandatory choice. In: Proceedings of the

14th international conference on Formal Methods

(FM'06), 2006.

Störrle, H.: Semantics of interactions in UML 2.0. In:

Proceedings of IEEE Symposium on Human Centric

Computing Languages and Environments, 2003.

Störrle, H.: Trace Semantics of UML 2.0 Interactions.

Technical report, University of Munich, 2004.

Knapp, A.: A Formal Semantics for UML Interactions. In:

R. France and B. Rumpe (eds.): Proc. 2nd Int. Conf.

Unified Modeling Language (UML’99), 1999.

Cengarle, M., Knapp, A.: UML 2.0 Interactions: Semantics

and Refinement. In: J. Jürjens, E. B. Fernàndez, R.

France, B. Rumpe (eds.): 3rd Int. Workshop on Critical

Systems Development with UML (CSDUML’04),

2004.

Li, M., and Ruan Y.: Approach to Formalizing UML

Sequence Diagrams. In: Proc. 3rd In-ternational

Workshop on Intelligent Systems and Applications

(ISA), 2011.

Shen, H., Virani, A.; Niu, J.: Formalize UML 2 Sequence

Diagrams. In: Proc. 11th IEEE High Assurance

Systems Engineering Symposium (HASE), 2008.

Störrle, H.: Assert, Negate and Refinement in UML-22

Interactions. In: J. Jürjens, B. Rumpe, R. France, and E.

B. Fernandez, Proc. Wsh. Critical Systems

Development with UML (CSDUML’03), 2003.

Harel, D., and Maoz, S.: Assert and negate revisited: modal

semantics for UML sequence diagrams. In: Proc.

International workshop on Scenarios and state

machines: models, algorithms, and tools, 2006.

Knapp, A., and Wuttke, J.: Model Checking of UML 2.0

Interactions. In; Proc. of the 2006 International

conference on Models in Software Engineering

(MoDELS'06), Springer, Heidelberg 2006.

Wendland, M.-F., Haugen, O., and Schneider, M.:

Evolutions of UML Interactions metamodel. In; Proc.

of the 2013 International conference on Models in

Software Engineering (MoDELS'13), Springer,

Heidelberg, 2013.

Damm, W., Harel, D.: LSCs: Breathing Life into Message

Sequence Charts. J. on Formal Methods in System

Design 19 (1), 45–80 (2001). In Proc. 3rd IFIP Int.

Conf. on Formal Methods for Open Object-Based

Distributed Systems (FMOODS’99 ), 1999.

UML, Object Management Group: Unified Modeling

Language 2.5, http://www.omg.org/spec/UML, 2015.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

410

fUML, Object Management Group: Semantics of a

Foundational Subset for Executable UML 1.1,

http://www.omg.org/spec/FUML/1.1, 2013.

PSCS, Object Management Group: Precise Semantics of

Composite Structures,

http://www.omg.org/spec/PSCS, 2015.

Alf, Object Management Group: Action Language for

Foundational UML, http://www.omg.org/spec/ALF/, 2013.

CL, International Standards Organisation, Common Logic

(CL): a Framework for a Family of Logic-Based

Languages,” ISO/IEC 24707:2007, 2007.

PSL, International Standards Organisation, Process

specification language, ISO 18629-1:2004, 2004.

Towards Executable UML Interactions based on fUML

411