Revisiting Semantics of Interactions for Trace Validity Analysis

Interaction languages such as MSC are often associated with formal semantics by means of translations into distinct behavioral formalisms such as automatas or Petri nets. In contrast to translational approaches we propose an operational approach. Its principle is to identify which elementary communication actions can be immediately executed, and then to compute, for every such action, a new interaction representing the possible continuations to its execution. We also define an algorithm for checking the validity of execution traces (i.e. whether or not they belong to an interaction’s semantics). Algorithms for semantic computation and trace validity are analyzed by means of experiments.


Introduction
Interaction languages (MSC and LSC [8], HMSC [23], MSD [15], UML-Sequence Diagrams, abbr. UML-SD [21] etc) are powerful mechanisms to express behavioral requirements in the form of scenarios called interactions. Those graphical languages represent parts involved in a communication scheme as vertical lines, so-called lifelines. Each one highlights a succession of instants, conventionally ordered from top to bottom, and where actions (emissions or receptions of messages) may occur. In Fig.1-a, we depict in the style of UML-SD an interaction denoting a message m passing between lifelines a and b. The correlation between events occurring on different lifelines is very loose as, by default, they are not ordered. Ordering has to be forced, e.g. for message passing ( Fig.1-a) when the rule stating that a messages cannot be received before being emitted applies (the origin of the arrow carrying m denotes an instant preceding the one depicted by its target). Considering the interaction of Fig.1-b, even though the reception of m 2 occurs graphically below the emission of m 1 , there is no specified order between those actions as they occur on arXiv:1911.03094v1 [cs.SE] 8 Nov 2019 different lifelines. This specificity is called weak sequencing. The expressivity of interaction languages is based on operators (e.g. UML-SD combined fragments) that structure interactions and specify relative scheduling for subscenarii.  In Fig.1-c, the scenario involving the usage of an alt operator specifies that either the emission of message m 1 from lifeline a (a!m 1 ) or the reception of m 2 on b (b?m 2 ) occur. Interaction languages such as UML-SD propose a variety of operators expressing among others parallelization, alternative, repetition, etc. When such languages come with formal semantics, requirements can be processed using formal techniques, such as trace recognition (acceptation or refusal of executions), model-checking ( [2]) or model-based testing ( [5,19]). Those semantics are often based on translations that map concepts of the given interaction language into a target formal framework, most often based on automata [14,15,4] or Petri nets [13]. Albeit those translations allow reusing the target framework's tools, relying on them to capture semantics leads to reasoning on foreign concepts. Indeed, as pointed out when we commented Fig.1, the key semantic concept underlying interactions is the causality relation between actions that their structure induce. Valid traces are those respecting the subsequent partial order [24,16]. In [18], the authors define a simple interaction language as a set of terms built above basic actions and provide it with a denotational semantics which associates each interaction term with a set of traces. This kind of formal framework, directly built over causality relations, can serve as reference for defining and proving theorems about interactions (e.g. the so-called satisfaction condition proven in [18]).
In this paper, we consider an interaction language which includes several distinct loop operators and provide it with a denotational semantics, directly comparable to that given by [18]. The semantics of an interaction with loops is defined by considering any finite number of loop unfolding combinations.Then, we introduce a second semantics, which can be qualified as operational, as we aim at presenting it in the style advocated in [22]. Our goal is to define accepted traces for an interaction i by identifying by which actions act they can start, and for each of those what is the next interaction i that will express the remainder of the trace. Representing it a set of rules of the form i act − − → i is challenging. Indeed, in order to keep track of possible conflicts between actions occurring on the same lifeline, the actions act that can be read first are identified using their position in i so that the computation of the resulting interaction i depends on both i and on the position of act in i. Our operational semantics have been adapted and implemented for both generation and analysis of traces w.r.t. a specifying interaction. Both implementations were the subject of experimentations on various interactions and traces, either manually or randomly defined.
The paper is organized as follows: Sec.2 introduces the interaction language and its denotational semantics. Sec.3 and Sec.4 resp. introduce our operational semantics and the subsequent trace analysis algorithm. Finally, Sec.5 and Sec.6 resp. discuss related work and provide concluding remarks.

Fig. 2: Positions & Subinteractions
This section provides a textual denotation of our basic (i.e. without loops) interaction language. Interactions are defined up to a given signature (L, M ) where L and M resp. are sets of so-called lifelines and messages. Their base building blocks are a set of communication actions (abbr. actions) over L and M : Act(L, M ) = {l∆m|l ∈ L, ∆ ∈ {!, ?}, m ∈ M } where l!m (resp. l?m) designates the emission (resp. reception) of the message m from (resp. on) the lifeline l.
For any action act in Act(L, M ) of the form l∆m, Θ(act) denotes the lifeline l. Actions can be composed using different binary operators that introduce a logic of execution between them, (weak or strict sequentiality, parallelism, mutual exclusivity). Fig.1 illustrates this composition mechanism from Act({a, b}, {m, m 1 , m 2 }). The empty interaction ∅ and actions of Act(L, M ) are elementary interactions. The strict and seq operators are sequential operators: in strict(i 1 , i 2 ), all the actions in i 1 must take place before any action in i 2 while in seq(i 1 , i 2 ) sequentiality is only enforced between actions that share the same lifeline. In Fig.1-b, b?m 2 may precede 3 a!m 1 (because a = b) while in Fig.1-a b?m cannot precedes a!m. Hence we use strict to encode the emission and reception of the same message object (e.g. strict(a!m, b?m) on Fig.1−a, drawn by convention as a plain arrow between a and b). In alt(i 1 , i 2 ), the behaviors specified by i 1 and i 2 are both acceptable but mutually exclusive (note that we handle the UML-SD opt operator as opt(i) = alt(i, ∅) = alt(∅, i)). For instance, in Fig.1-c (alt(a!m 1 , b?m 2 )), if a!m 1 happens then b?m 2 cannot happen and viceversa. In par(i 1 , i 2 ), the executions of i 1 and i 2 are interleaved. For instance, in par(a!m 1 , a!m 2 ), actions a!m 1 and a!m 2 can happen in any order. Interactions being defined as usual terms ( [9]), we use positions expressed in Dewey decimal notation ( [9]) to refer to subinteractions. A position p of i is a sequence of positive integers denoting a path leading from the root node of i to the subterm of i at position p. Because interactions are defined with operations whose arity is at most 2, positions are words 4 of {1, 2} * . In Def.2, the functions ST and pos resp. associate to any interaction the set of all its subinteractions and the set of its positions. Moreover, we use the usual notation i |p ( [9]) to designate unambiguously the subinteraction of i at position p for p ∈ pos(i) (cf. example in Fig.2).

Semantics
As explained in Sec.2.1, operators occurring in an interaction induce relations of precedence between its actions. In the example of Fig.2 the same reasoning can be applied except that the additional precedence relations only concern actions that share the same lifelines. Using the same notations, e = 1.e 1 ∪ 2.e 2 and o = 1.
..e n } characterizes a set of behaviors that express exactly once every action whose position belongs to e. Such a behavior is thus given under the form of an execution trace i |e α(1) ...i |e α(n) where α is a permutation of [1, n]. Obviously, not all those permutations are acceptable as they must not contradict the partial order specified by o. If we note The semantics σ(i) of an interaction i then comes naturally as the union of all sets sem(i, e, o) of execution traces of i compatible with (e, o) ∈ ord(i). When considering the example from Fig.2

Extension of the language with loops
A loop is an operator which hosts an inner subinteraction: the loop content, which can be instantiated any finite number of times. When the loop is instantiated, a copy of it is made and inserted into the interaction. For UML-SD, the norm ([1]) states that "the loop construct represents a recursive application of the seq operator where the loop operand is sequenced after the result of earlier iterations". As a result, the UML-SD loop is associated with the seq operator in so far as when instantiated, the loop content is ordered using seq i.e. loop(a!m) becomes seq(a!m, loop(a!m)) then seq(a!m, seq(a!m, loop(a!m))) and so on. In line with this explanation, we propose to consider 4 types of loops which are classified according to the operator being the root of the instantiated content. Among the 4 available binary operators "seq", "strict", "par" or "alt", we eliminate the "alt" operator as it would be of no benefit: instantiating loop(i) would lead to alt(i, loop(i)) meaning that the loop can only be read at most once and is therefore equivalent to opt(i). Using 2 basic examples, we illustrate the semantics of the other 3 operators denoted "loop seq " (the classical loop), "loop strict " and "loop par ". In Fig.3-a-i, i a|11 = a!m is the only immediately executable action and its execution leads to the interaction i a = strict(b?m, i a ) drawn on Fig.3-a-ii. Because of the strict operator, i a|211 = a!m is not immediately executable (preceded by i a|1 = b?m). As a result t a = a!m.a!m.b?m.b?m is not an accepted trace for i a . However, if there was a seq operator instead of the strict, i a|211 would be immediately executable and t a an accepted trace. Similarly, in Fig.3-b-i, i b|11 = a!m 1 is the only immediately executable action and its execution leads to the interaction i b = par(a!m 2 , i b ) drawn on Fig.3-b-ii. Because of the par operator, i b|211 = a!m 1 is immediately executable. As a result t b = a!m 1 .a!m 1 .a!m 2 .a!m 2 is an accepted trace for i b . However, if there was a seq operator instead of the par, i b|211 would not be immediately executable and t b not an accepted trace. Consequently, considering loop par and loop strict in addition of the classic loop seq improve expressiveness. In rough terms, loop par always allows new instantiations as each instance is executed in parallel w.r.t -

Fig. 4: Loop unfolding
For the remainder of the paper, in the same way that we proceeded in Def.6, any time we will canonically extend a definition from basic interaction to interactions, we will only define the missing cases concerning loop terms.
In order to define the semantics of interactions, we use the notion of term replacement ([9]), the notation t[s] p indicating the term t where its subterm at position p is replaced with the term s. For instance with i = seq(a!m, b?m), we have i[c?m] 2 = seq(a!m, c?m). This notation is convenient to represent terms obtained by loop unfolding. For example let us consider an interaction i ∈ I(L, M ) with a loop seq at a position p ∈ pos(i), that is, such that i |p = loop seq (i |p.1 ). Then, the interaction obtained from i by unfolding once the loop at position p is i[seq(i |p.1 , i |p )] p . In Def.7, the set Υ (i, n) of all n-unfoldings of an interaction i (i.e. the set of all interactions resulting from n instantiations of any loop from i) is defined recursively. On We can define a function

Operational Semantics
One of our goals is to define algorithms that can discriminate between accepted and non-accepted traces for any given interaction (i.e. if they belong or not to its semantics). However the denotational unfolding-based semantics from Sec.2.3 is problematic when applied to trace analysis. Let us suppose we want to analyze a trace w.r.t. an interaction i. If the trace happens to be incorrect, the analysis must ensure that there is no interaction obtained by unfolding of i that accepts the trace. A termination in finite time of the analysis process would therefore require defining some stopping criterion on the unfolding. This limitation would be even more problematic for monitoring processes where the length of the trace is initially unknown and increases at runtime via the arrival of new actions.
Consequently, we investigate another approach for defining interaction semantics, in the style of so-called operational semantics, i.e. consisting in: (a) identifying from the structure of the interaction term i itself which actions can be directly read in i and in (b) deriving for each of those actions act a new interaction term i specifying all the possible continuations of act within the set of execution traces specified by i. Instead of systematically unfolding loops, such an approach only does it on demand, when deriving an i resulting from the execution of an action that is part of a loop. This proves particularly suitable for trace analysis, which we address in Sec.4. For a given interaction i, the general idea is to build accepted traces of i recursively through the consumption of actions occurring in i. Starting from a given interaction i, let's suppose that we have reached, after a number of intermediate steps, an interaction i via the consumption of a sequence of actions forming the trace (prefix) t. i encapsulates all the continuations of t within the context of i i.e. t.σ r (i ) ⊂ σ r (i) where σ r (i) is the set of execution traces of i (see Def.14). t can be extended by actions act that are immediately executable (called frontier actions) in i . An action within an interaction is in the frontier if and only if no structural operators (parent nodes) coerce it to be preceded by another action (sibling leaf).
Let us consider a frontier action act for i . From the knowledge of i and 6 act, an interaction i can be built. i is the interaction that remains after the execution of act in i . Note that, between i , i and act there is the same relationship as between i , i and t, which can be roughly noted resp. i

Frontier actions
Herein is explained how to identify frontier actions. Our notion of frontier differs slightly from that of [7], where it refers to the set of positions p such that ∀j ∈ {1, 2} * , p.j ∈ pos(i) (i.e. positions of leaf nodes). Indeed, our frontiers contain only leaves that are immediately executable actions.
Any ordering as defined in Def.4 provides a partial order relation for the set of (positions of) actions of a basic interaction. A frontier action act on position p is then simply a minimal element given such a relation (e, o), i.e. such that ∃p ∈ e, (p , p) ∈ o i.e. act does not have to be preceded by any other action. The frontier of an interaction i is then defined as the union of such p, considering all the orderings from ord(i). As Def.4 did not include loop operators, we extend it in the following definition, in which the empty ordering (∅, ∅) corresponds to the case where the loop is not unfolded:

Pruning branches
The design of the rules i act − − → i hinted at earlier is made operational thanks to 3 mechanisms: conflict detection, pruning and execution. Given an action act ∈ f ront(i), branches preventing its execution are detected with conflict detection and then eliminated with pruning. However, this is not done on the whole interaction i but rather on specific neighboring (w.r.t. act) subinteractions. Execution orchestrates the calls to conflict detection and pruning, eliminates act and constructs the remaining interaction i .  We present at first the pruning mechanism. Given an interaction i, we need to remove from i all the actions which positions are in a set r. For instance, on Fig.6-b, let us consider the interactions i 1 = i |1 = loop seq (strict(a!m 1 , b?m 1 )) and i 2 = i |21 = loop seq (alt(a!m 2 , b?m 3 )) highlighted in green. We want to remove r 1 = {11} from i 1 and r 2 = {11} from i 2 . This corresponds to the actions i 1|11 = a!m 1 and i 2|11 = a!m 2 . If we do not want to get an interaction which is inconsistent or outwardly contradicts the original semantics, we can only prune subinteractions at positions where branching choices are made i.e. in alt and loop nodes. Indeed, by definition, eliminating a subinteraction at one such node would lead to a semantics that is included in the original. In i 2 , eliminating i 2|11 is easily done given that its parent node is an alt and that its brother node does not also need to be eliminated. Indeed, it suffices to operate the replacement i 2 [i 2|12 ] 1 i.e. replacing the alt node with its right child b?m 3 . In i 1 , eliminating i 1|11 is more delicate: its parent node is a strict and as such, behaviors from its left and right children must both happen (there is no branching choice). Thus, if we want to eliminate i 1|11 we must also eliminate the whole i 1|1 . The problem is hence forwarded upwards in the syntax. The parent i 1| is a loop operator, which characterizes a branching choice. We can eliminate the problematic branch by choosing not to instantiate the loop i.e. via the replacement i 1| [∅] .
The pruning mechanism is given in Def.11 as the recursive prune function. prune takes as arguments an interaction i, a set r of positions, and a position p. prune eliminates from i branching choices hosting actions in positions p ∈ pos(i) such that p.p ∈ r. Given that in practice, the initial call of prune is made on prune(i, r, ) with r ∈ P(pos(i)) the set of (positions of) actions that we want to remove, prune effectively eliminates from i all actions in r.
In a first phase, prune descends the syntax of i from its root node to its leaves. The p argument is incremented so that the current i argument is the subinteraction i 0|p of a given i 0 (s.t. i ∈ ST (i 0 ) and r ∈ P(pos(i 0 ))) at position p. Thus, when the leaves are reached, we have the possibility of p ∈ r. When reaching a leaf, prune returns an interaction and a boolean. This boolean represents the need to prune the current branch and it is forwarded bottom up until a branching choice that can be eliminated is reached. Leaves are either actions or the empty interaction. For an action act, if p ∈ r, the current branch must be pruned so prune(act, r, p) = (∅, ): the value of the returned interaction has no importance because a parent will be pruned anyway. Else (p ∈ r), prune(act, r, p) = (act, ⊥) because there is nothing to prune here. Similarly, we also have prune(∅, r, p) = (∅, ⊥). The mechanism to propagate the pruning needs and to reconstruct the "pruned" interaction is then rather straightforward. prune is recursively called on the left and right children with correctly incremented p argument. For the operators f ∈ {strict, seq, par}, if any one child must be pruned (b 1 ∨ b 2 ) then the whole branch must also be pruned and otherwise a reconstructed f (i 1 , i 2 ) is returned. For the exclusive alternative alt, if no branch needs pruning, alt(i 1 , i 2 ) is returned; if any single branch needs pruning, prune returns the one that does not need to be pruned and if both branches need pruning, then the whole interaction is pruned. For the repetition operators, if the loop content needs pruning then the choice of "never taking the loop" is made meaning that ∅ is returned, but with a boolean at f alse, and prune(i 2 , r, p.2) = (i 2 , b 2 ) we have: In next section, the prune function will be used in a function that, given a position in its frontier, rewrites an interaction i in a new interaction i that carefully removes problematic parts of i.

Execute function and formal semantics
Let us consider the example i from Fig.6. We wish to execute the frontier action i |22 = a!m 4 (highlighted in red). Given that Θ(i |22 ) = a, we need to consider possible conflicts for the availability of the lifeline a in parts of i that precede i |22 . In i those are the subinteractions i |1 and i |21 highlighted in green. More generally, the nature of our syntax is such that, for the execution of a frontier action at position p ∈ pos(i), we only need to look for conflict in subinteractions at positions p 0 .1 s.t. ∃p ∈ pos(i), p = p 0 .p i.e. in left cousins. Those conflicts correspond to actions that occur on the lifeline Θ(i |p ). Such actions can be detected by a simple β function (see Def.12) that takes as arguments an interaction We now define the execution function χ (Def.13), which takes as arguments an interaction i and a frontier position p and returns the remaining interaction i . As explained earlier, χ orchestrates the use of β and prune so as to remove from i all the problematic actions i.e. those which occur on Θ(i |p ) and are on the left cousins of i |p that are scheduled sequentially w.r.t. i |p . In the example from Fig.6 this first cleaning feature would result in the transformation of i from the diagram on Fig.6-a to the one on Fig.6-c. The only thing left to do is then to remove the executed action s.t. the result is the interaction from Fig.6-d. χ is defined inductively on both the structure of the interaction i and the position p = d 1 ...d n ∈ {1, 2} n . The execution of χ(i, p) traverses recursively the syntactic structure of i guided by the path defined by the position p, that is, from χ(i | , d 1 ...d n ) (root node), ..., up to χ(i |p , ) (target action leaf to execute). Here, χ(i |p , ) = ∅ constitutes the stopping criterion and i is then constructed when the algorithm goes back up through the syntactic structure of i. Assigning ∅ to χ(i |p , ) ensures that the action i |p is removed in the construction of i .
When a par node is encountered during the upward traversal, i.e. for j ∈ Indeed, as par specifies parallel executions, there is no need for pruning.
When an alt node is reached, using the same notations, we would have: . Indeed, we can "skip" the alt node itself and replace it directly with the interaction resulting from the execution of the chosen branch.
When a loop is reached, i.e. i |d1...dj = loop f (i |d1...dj .1 ) (with a mandatory d j+1 = 1), we have : . Indeed, the execution is done on a copy of the loop content that precedes (with f operator) the loop i |d1...dj itself, that is, on an unfolding of the loop.
For the sequential operators, pruning needs to be considered only if the action to execute is situated on the right branch of the seq or strict node (if the action is on the left branch, we have the same transformation as in the par case). Given i |d1...dj = seq(i |d1...dj .1 , i |d1...dj .2 ) and d j+1 = 2, when constructing χ(i |d1...dj , d j+1 ...d n ) we must prune in i |d1...dj .1 all the actions that could interfere with i |p i.e. those taking place on Θ(i |p ). As such, given (i 1 , b 1 ) = prune(i |d1...dj .1 , β(i |d1...dj .1 , Θ(i |p ))), we'll replace the left branch of the seq with i 1 and reconstruct: Given that the strict operator won't allow any action from the left branch to occur after an action on the right has, we can simply prune the whole left branch i.e. given i |d1...dj = strict(i |d1...dj .1 , i |d1...dj .2 ) and d j+1 = 2: Definition 13 (Execution). The function χ : I(L, M ) × {1, 2} * → I(L, M ) is defined for couples (i, p) with i ∈ I(L, M ) and p ∈ f ront(i) as follows: We now define the operational semantics as follows: Definition 14 (Interaction Operational Semantics). We define σ r : I(L, M ) → P(Act(L, M ) * ) as: In Def.14, interactions that express the empty trace are identified with the predicate exp . To sum up, our semantics express rules of the form i act − − → i where p is in f ront(i) with i |p = act and i is obtained by rewriting i through χ(i, p). We implemented both semantics (σ u from Def.8 and σ r from Def.14) and compared them on a significant set of interactions. Being defined as a set of terms, interactions of any finite depth can be enumerated. Hence we considered every interactions of depths d = 1 to d = 3 defined over sets L and M of resp. cardinals n l and n m . The numbers of syntactically distinct terms for every combination (n l , n m ) are shown on Fig.7, where each cell contains 3 numbers, for the resp. term depths. In total we therefore have 234175 (sum of bottom right cell) syntactically distinct interactions i on which we tested the equality σ u (i) = σ r (i) considering all integers between 0 and 4 for the unfolding of loop f operators. With this stopping criterion, the test concluded on the equality of both semantics in all cases. Although not a proof, our successful back-to-back comparison comforts our confidence in both semantics the more so because of the exhaustivity of the subject data set up to maximum numbers of lifelines, messages types, interaction depth (up to 3), number of loop unfolding (up to 4), allowing covering all 2 by 2 combinations of operators.

Trace analysis
The function ω of Def.15 takes as arguments an interaction i and a trace t and checks whether or not t is a trace of i. Additionally, traceability information is provided thanks to the four verdicts that ω can emit: • Covered is returned when t is a trace of i i.e. t ∈ σ r (i); • T ooShort is returned when t ∈ σ r (i) is a strict prefix of a trace of i i.e. ∃t + ∈ σ r (i) of the form t.t • T ooLong is returned when neither Covered nor T ooShort can be returned and t is of the form t − .t , where t − ∈ σ r (i) i.e. t extends a trace of i; • Out is returned when none of the other verdicts can be returned.
We define the enumerated type V erdict = {Out, T ooLong, T ooShort, Covered} and provide it with a total order Out ≺ T ooLong ≺ T ooShort ≺ Covered.
• If t is empty then: either i accepts the empty trace in its semantics and in this case ω(i, t) returns Covered, or it returns T ooShort. if t is then ω(i, t) = Covered (resp. T ooShort) if exp (i) = (resp. ⊥) if t is of the form act.t then: Fig.8-a is a graphical representation of the ω process when applied to the interaction from Fig.6-a and the trace a!m 4 .b?m 3 . It is automatically generated by our tool implementing Definition 15. Fig.8-b presents a synthesis of experiments conducted to assess the correctness of ω and of our implementation of it. We randomly sampled 1000 interactions from the set of reduced forms 7 of (a) graphic tool repr. of ω(i, a!m4.b?m3) Each of those traces were tested as well as a random selection of their prefixes and of interesting mutants. Addition (resp. replacement) mutants consists in adding an action to a trace (resp. prefix). By construction we could classify all those traces according to the verdicts they are expected to obtain. Fig.8-b details those results, showing a systematic concordance between the expected and obtained verdicts. Those results reinforce our confidence on ω, the more so that they were done on a panel of traces and interactions which covers all 2 by 2 combinations of operators.
To provide an evaluation of performances (plotting time vs. length), we needed a large model and long correct traces. Indeed, the time required by the analysis is not always correlated to trace length e.g. an arbitrarily long trace starting with an action act ∈ f ront(i) is analyzed immediately, whatever its length is. There is however a correlation for correct traces and their prefixes. We defined a partial high-level model of the MQTT [26] telecommunication protocol (see Fig.8-c). This model states that a communication session between a client and a broker starts (resp. ends) with a sequential connection (resp. disconnection) phase. In between, at any time, any number of instances of one of the 5 proposed subinteractions can be run concurrently. Hence, we used a multi-threaded Python script to generate 100 traces, each of those corresponding to the concurrent activation and execution at random time intervals of 20 instances of the loop par from Fig.8-c. All those traces (resp. prefixes) have the verdict Covered (resp. T ooShort); we evaluated computation times and plotted some of them on Fig.9. The linear regression shows curves with a great variability (some traces need 4 seconds while others only 0.06). In this precise model, it is explained by the presence of par (via loop par ) operators and by the fact that messages are not uniquely identified. For instance analyzing t = a!m.b?m on i = par(a!m, strict(a!m, b?m)) would give rise to 2 branches: i = strict(a!m, b?m) (resp. i = par(a!m, b?m)) with t = b?m which ends with Out (resp. Covered) because m is not uniquely identified. This number of branches can quickly explode when par operators are stacked which happens when the trace describes an execution where many loop content instances overlap. An applicable solution would be to treat message data arguments, given that communication protocols provide unique ids e.g. m(id1) = m(id2). On the plot below (traces 9, 34 & 61) we magnified on traces with a very short analysis time. We can surmise here that minimal (perhaps no) loop overlap occured as the derivatives are almost constants (especially for trace 61). In conclusion, performance highly depends on the model and input trace, but treating data which specifies unique ids for messages would generalize the best case scenario. In this case, the algorithm could be applied to monitoring within the limits of an input frequency that is inferior to the time required to analyze a trace of length 1.

Related work
Classical languages such as UML-SD ( [21]) or HMSC ( [11]) are complex languages and many authors have proposed their own takes on formal semantics (see the survey ( [21]) for UML-SD). The main obstacle to the definition of operational semantics is the combination of weak sequencing with repetition operators. Most existing semantics based on term interpretations are given in a denotational style [27,16,17,6,18]. Most other approaches rely on translations to automata or Petri nets [8,28,15,19,4,10,13]. Despite interaction languages specifying no synchronisation mechanisms between lifelines, several approaches that aim to (or do) implement tools, impose synchronisation points when entering and exiting combined fragments/operators and/or at decision points (alt, opt, loop) [28,3,25,4,10,21] (although more recent works such as [13,20] do not). The contribution in [20] presents an operational semantics that is somewhat similar to our own in the sense that it builds traces from transformations of the form i act − − → i . However, in addition to the interaction syntax, it relies on a so-called communication medium to define its semantics as the output of a combination of two transitions systems: an execution system which keeps track of the state of the communication medium, and a projection system which selects the next action to execute and provide the interaction resulting from the execution. Communication models, as explained in [12], are tasked with keeping track of which messages have been sent and which are pending receptions. They often take the form of a set of dedicated buffers (e.g. FIFO). Our approach has the advantage of making such communication models implicit as they are implied by the mechanism that construct continuation interactions.

Conclusion
In this paper we proposed an operational semantics for interaction languages, aimed at trace validity analysis. This semantics is build upon a formal syntax for interaction terms and validated back-to-back w.r.t. a reference denotational style semantics. In contrast with other approaches, we do not translate interactions toward some other behavioral language. Our semantics is build upon partial order relations induced on messages, allowing the identification of those that are enabled and those that need to be pruned to enable them, ensuring a consistent semantics based on successive transformations of the form i act − − → i . On this principle, we have defined and implemented algorithms to compute semantics and to analyze the validity of traces. Experiments were successfully conducted in order to evaluate the correctness of both. An analysis of performance for the trace analysis algorithm has also been carried out using an example issued from the domain of telecommunications. It yielded encouraging results, showing that the increase in time relative to trace length could be controlled in certain configurations (uniquely identified messages, minimal overlap of par operators, etc.).
As future works, we intend to further explore the adaptation of the trace validity checking algorithm to monitoring. The key point is to deal with the average frequencies of message observations made by probes so that our algorithmic treatments are fast enough to deal with them. We also plan to expand trace validity checking to a distributed context, where, instead of a single trace, a set of traces are analyzed concurrently on either the whole set of lifelines or a projection, other lifelines being considered unobserved. A third prospect is to extend our framework to include modality either in the form of UML-SDstyle operators assert and negate or MSD-style [15] hot and cold modalities. Finally we plan to associate symbolic treatments of variables and constraints to data-carrying timed interaction models.