The Clock Constraint Specification Language for ... - Semantic Scholar

Innovations in Systems and Software Engineering Volume 1–2, pp. 99–106, March 2010

The Clock Constraint Specification Language for Building Timed Causality Models Application to Synchronous Data Flow graphs Fr´ed´eric Mallet · Julien DeAntoni · Charles Andr´e · Robert de Simone

Published on-line: 22 December 2009 Full text available from the editor at http://link.springer.com/article/10.1007/s11334-009-0109-0

Abstract The UML Profile for Modeling and Analysis of Real-Time and Embedded (RTE) systems has recently been adopted by the OMG. Its Time Model extends the informal and simplistic Simple Time package proposed by UML2 and offers a broad range of capabilities required to model RTE systems including discrete/dense and chronometric/logical time. The M ARTE specification introduces a Time Structure inspired from several time models of the concurrency theory and proposes a new clock constraint specification language (CCSL) to specify, within the context of the UML, logical and chronometric time constraints. A semantic model in CCSL is attached to a (UML) model to give its timed causality semantics. In that sense, CCSL is comparable to the Ptolemy environment, in which directors give the semantics to models according to predefined models of computation and communication. This paper focuses on one historical model of computation of Ptolemy (SDF - Synchronous Data Flow) and shows how to build SDF graphs by combining UML models and CCSL . Keywords CCSL · SDF · UML Marte

1 Introduction The Unified Modeling Language (UML) is a general-purpose modeling language. Its semantics is described in English in the Object Management Group specification [OMG(2007)]. F. Mallet, J. DeAntoni, C. Andr´e Universit´e Nice Sophia Antipolis Aoste team-project, INRIA-I3S-CNRS 2004 rte des Lucioles - F-06902 Sophia Antipolis cedex E-mail: [email protected], [email protected], [email protected] R. de Simone INRIA Sophia Antipolis M´editerrann´ee Aoste team-project, INRIA-I3S-CNRS 2004 rte des Lucioles - F-06902 Sophia Antipolis cedex E-mail: Robert.de [email protected]

2

Several aspects are left unspecified in so-called semantic variation points to allow userdefined adaptations for addressing domain-specific issues. There have been many efforts to use the UML in formal environments to address critical systems or domains where formal verification is mandatory. A brief classification is attempted hereafter even though it is usually acknowledged [Bruel et al(2000)] that building a full taxonomy is difficult: 1. The first kind consists in using a formal language to build UML expressions and/or constraints. Since, UML does not enforce any specific syntax for expressions and constraints, any language can be used. Even though the Object Constraint Language (OCL) [OMG(2006)] may seem the most natural choice, formal languages (e.g., Z [Grieskamp et al(2000)], Labelled Transition Systems [Sinnig et al(2009)]) are also used to specify invariants in UML use cases or pre-condidions/post-assertions on UML operations. Then, scenarios (UML interaction diagrams) or behaviors (state machines or activities) are analyzed statically [Chiorean et al(2004),Gogolla et al(2007), Yu et al(2008)] to check whether the use case invariants and the post-assertions hold. 2. The second kind of approaches is transformational. It consists in transforming every UML model element into a model element of a formal language (for instances, Petri Nets [St¨orrle(2005)] or π-calculus [Yang et al(2003)]). After transformation, various analyses become possible, like symbolic model-checking [Eshuis(2006)]. 3. In the third kind, the semantics resides in annotations (stereotypes). For instance, the semantics of Concurrent Sequential Processes [Hoare(1985)] can be given to a UML state machine provided that a UML profile for Concurrent Sequential Processes is defined [Frappier et al(2008)] . 4. In the fourth kind, only a subset of the UML is allowed to make it suitable for a specific domain, e.g., the very expressive UML state machines can be reduced to timed automata [Alur and Dill(1994)] thus giving access to a whole family of formal tools [Behrmann et al(2006)]. In all cases, the semantics remains outside the model and therefore the model may be interpreted differently by another tool or another user. This paper explores the possibility to build an explicit semantic model that would be linked into the model itself to define its time semantics. Our approach is not specific to UML models and can be used with domain-specific models as well. We propose to use the M ARTE time model and its companion language CCSL (Clock Constraint Specification Language) to build the semantic model. The UML profile for Modeling and Analysis of Real-Time and Embedded (M ARTE [OMG(2009)]) systems has been adopted by the OMG earlier this year. M ARTE supersedes the UML Profile for Schedulability, Performance and Time (SPT [OMG(2005)]) and extends the mainly untimed UML with several new constructs. Amongst several other things, M ARTE proposes a new resource model, an extensible way to express non functional properties and a time model. The time model adapts SPT timing mechanisms to the UML 2 (Unified Modeling Language) simple time and offers completely new features, like the support of logical and multiform time. M ARTE provides basic constructions to model simple time expressions but also proposes advanced mechanisms to build and associated with a UML model a Model of Computation and Communication (MoCC). This paper illustrates the construction of a MoCC (Synchronous Data Flow—SDF) with M ARTE and CCSL. Contrary to Ptolemy [Eker et al(2003)] that was devised to combine heterogeneous MoCCs, we only deal with one single MoCC. Ptolemy is a proprietary (even though open-source) environment in which MoCCs are hard-coded. We propose to build models with a UML graphical editor supporting the UML profile mechanism and to use CCSL to attach a semantic model.

3

Section 2 briefly describes SDF. Section 3 introduces the M ARTE time model and CCSL operators required to model SDF graphs. Section 4 builds a CCSL library for SDF, the usage of which is illustrated on one example presented in Section 5. Possible extensions are discussed in Section 6. Section 7 compares this work to related works.

2 Synchronous Data Flow Data Flow graphs are directed graphs where each node represents a function or a computation and each arc represents a data path. SDF is a special case of data flow in which the number of data samples produced and consumed by each node is specified a priori. This simple formalism is well suited for expressing multi-rate Digital Signal Processing algorithms that deal with continuous streams of data. This is a restriction of Kahn Process networks [Kahn(1974)] to allow static scheduling and ease the parallelization. SDF graphs are equivalent to Computation graphs [Karp & Miller(1966)] which have been proven to be a special case of conflict-free Petri nets [Petri(1987)]. Fig. 1 shows the metamodel of SDF graphs. Nodes (called actors) represent operations. Actors have inputs and outputs. Each input (resp. output) has a weight that represents the number of tokens consumed (resp. produced) when the actor executes. Each arc carries tokens, which represent data values (of any data type) stored in a first-in first-out queue.

SDFGraph actors

*

*

Actor executes() actor

inputs actor

*

Input enables()

I/O

arcs

Arc delay : UnlimitedNatural read() write() outgoing

weight: UnlimitedNatural

*

Output

outputs Fig. 1 Metamodel of Synchronous Data Flow graphs

SDF graphs obey the following rules. – An actor is enabled for execution when all inputs are enabled. An input is enabled when enough tokens are available on the incoming arc. Enough tokens means equal to or greater than the input weight. Actors with no inputs (Source actors) are always enabled. Enabling and execution do not depend on the token values, i.e., the control is data-independent. – When an actor executes, it always produces and consumes the same fixed amount of tokens. It produces on each output exactly the number of tokens specified by the output

4

weight; these tokens are written into the queue of the outgoing arc. It consumes on each input exactly the number of tokens specified by the input weight; these tokens are read (and removed) from the queue of the incoming arc. – Delay is a property of an arc. A delay of n samples means that n tokens are initially in the arc queue.

3 MARTE Time Model 3.1 Clock In M ARTE, a clock gives access to a time structure. A clock can be either chronometric or logical. The former is related to “physical time” while the latter is not. Logical clocks refer to discrete-time logical clocks and represent logical time. Logical time is the time in use in synchronous languages. To represent SDF graphs, we only need logical clocks. However, Section 6 discusses some possible extensions and gives some examples of chronometric clocks. A Clock is a 5-tuple hI , ≺, D, λ , ui where I is a set of instants, ≺ is a quasi-order relation on I , named strict precedence, D is a set of labels, λ : I → D is a labeling function, u is a symbol, standing for a unit. For logical clocks, u is often called tick, it can be processorCycle as well or any other logical activation of a behavior. The ordered set hI , ≺i is the temporal structure associated with the clock. ≺ is a total, irreflexive, and transitive binary relation on I . Logical clocks as originally defined by Lamport [Lamport(1978)] are a special case where the labeling function is an increasing monotonic function. A discrete-time clock is a clock with a discrete set of instants I . Since I is discrete, it can be indexed by natural numbers in a fashion that respects the ordering on I : let N? = N \ {0}, idx : I → N? , ∀i ∈ I , idx(i) = k if and only if i is the kth instant in I . In M ARTE, a logical clock can be associated with any Event: this clock “ticks” at each occurrence of the event. For any discrete time clock c = hIc , ≺c , Dc , λc , uc i, c[k] denotes the kth instant in Ic (i.e., k = idxc (c[k])). For any instant i ∈ Ic of a discrete time clock, °i is the unique immediate predecessor of i in Ic . For simplicity, we assume a virtual instant the index of which is 0, and which is the (virtual) immediate predecessor of the first instant.

3.2 Clock relations, expressions and operators A Time Structure is a pair hC, 4i where C is a set of clocks, 4 is a binary relation on S c∈C Ic , named precedence. 4 is reflexive and transitive. From 4 we derive two new relations: Coincidence (≡ , 4 ∩ 0, delay tokens are initially available in the queue, which means that the ith read operation gets the data written at the (i − delay)th write operation, for i > delay. The delay previous read operations actually get the initially available tokens that do not match an actual write operation. CCSL binary delay operator ($) can represent such a delay (Eq. 1). To represent SDF arcs, we propose to create in a library, a new relation definition, called token. Such a relation has three parameters: two clocks (write and read) and an integer (delay). The relation token applies the adequate constraint (1). When delay = 0, Eq. 1 reduces to write ≺ read. def token(clock write, clock read, int delay) ,

write ≺ (read $ delay)

(1)

Inputs require a packet-based precedence (keyword by in Eq. 2). A relation definition, called input, has three parameters. The clock actor represents the actor with which the

6

SDFGraph actors

*

*

Actor executes() actor

inputs actor

*

Arc

Input

delay : UnlimitedNatural read() write()

enables()

I/O

arcs

outgoing

weight: UnlimitedNatural

Output

* outputs

start

write

CCSLClock read

Fig. 2 Attaching clocks to the domain model elements

input is associated. The clock read represents the reading of tokens on the incoming arc. The strictly positive integer weight represents the input weight. def input(clock actor, clock read, int weight) ,

(read by weight) ≺ actor

(2)

The packet-based precedence has not been introduced before, nevertheless it can be built with the operator filteredBy (Eq. 3). When weight = 1, it reduces to read ≺ actor.   ω  read H 0weight−1 .1 ≺ actor

(3)

Outputs are represented by the relation definition out put, which has three parameters. The clock actor represents the actor with which the output is associated. The clock write represents the writing of tokens to the outgoing arc. The strictly positive integer weight represents the output weight. CCSL operator filteredBy is used (Eq. 4). When weight = 1, Eq. 4 simplifies into actor = write. def out put(clock actor, clock write, int weight) ,

actor =


ω  write H 1.0weight−1

(4)

Arcs can globally be seen as a conjunction of one output, one token and one input. The library relation definition arc (Eq. 5) defines a complete set of constraints for an arc with a delay delay, from an actor source, with an output weight out to another actor target,

7

with an input weight in. In that case, CCSL clocks write and read are local clocks but their declaration is omitted. def arc(int delay, clock source, int out, clock target, int in) ,

(5)

out put(source, write, out) ∧

token(write, read, delay)

∧

input(target, read, in)

5 Example The previous subsection defines, for each SDF model element, the CCSL clocks that must be created and the clock constraints to apply. This section illustrates the use of our CCSL library for SDF with a simple SDF graph (Fig. 3). Arc tcb has two delays otherwise neither actors B nor C could ever execute. C must execute exactly twice as often as B and A must execute at least twice as often but could execute more frequently if no other execution rule (like an As-Soon-As-Possible policy, see Section 6.1) is specified.

A

1 oab

tab

2 iab icb

B obc

2

2

tcb

tbc 1

1 ocb

C

ibc

Fig. 3 An example of an SDF graph

Eq. 6 uses our library to build a semantic model and imposes the model to behave as an SDF graph. Clocks are named after the model elements with which they are associated, i.e., the clock for actor A is named A. arc(0, A, 1, B, 2) ∧ arc(0, B, 2,C, 1) ∧ arc(2,C, 1, B, 2)

(6)

8

Figure 4 shows one possible execution of this specification produced by T IME S QUARE [Andr´e and Mallet(2009)]. Intermediate clocks are hidden and only actors are displayed because the relative execution of the actors is what matters when considering SDF graphs. High levels represent clock ticks and consequently instants at which actors execute. The dashed arrows are precedence instant relations and help identifying the possible slack in the simulation. Rounded rectangles represent packet-based relations. For instance, it shows that the two first ticks of A must precede the very first tick of B. However, the first tick of B following the third tick of A is purely an accidental result of the random simulation policy and is not strictly enforced by the specification itself. If clock A takes too much advance on clock B, the queue size between A and B increases. Section 6.1 further discusses that particular aspect.

Fig. 4 Simulation with TimeSquare - unbalanced equations

When the semantic model is complete, we can use a standard UML graphical editor to build a model that resembles an SDF graph. The actual diagram used does not matter and we can choose whatever diagram fits best our graphical requirements. In this example, we use UML activities (Fig. 5.a) and state machines (Fig. 5.b). Our intent is NOT to extend the semantics of UML activities and state machines but rather to use the UML editor as a mere graphical editor to build graphs, i.e., nodes connected by arcs. Our proposal is to attach CCSL clocks to some UML elements represented by the modeling editor. Papyrus gives the concrete graphical syntax and the clock constraints give explicitly the expected execution rules. Both models should be exchanged together in the same way as a map should always come with its legend. Instead of building another proprietary graphical tool, we propose to use existing ones1 . The UML is well adapted in several cases since it proposes many of the commonly used notations for both structural and behavioral aspects. M ARTE stereotypes can be used to embedd the CCSL model. The UML is far richer than required to build SDF graphs, we only use some of the available model elements to model the SDF graph. Since SDF graphs are data flow graphs, the first idea is to use the syntax of UML activities (Fig. 5.a) to represent them: actions, input/output pins and data flows. However, the common graphical syntax for SDF graphs is also close to state machines, so we may also want to use the syntax of UML state machines (Fig. 5.b): states and transitions. By instantiating elements of our CCSL library for SDF, we can give to these two models the execution semantics of the SDF graphs drawn in Figure 3. The idea is to add the semantics within the model explicitly without being implicitly bound to some external descriptions. In our case, the semantics is given by the CCSL specification and by explicit associations between CCSL clocks and model elements. In Figure 5.a, UML activities are used and actors are represented by actions. For each arc, the clock write (read, resp.) is associated with an input pin (output pin, resp.). In Figure 5.b, 1

We have used Papyrus http://www.papyrusuml.org for building this example.

9 a. Activity in Papyrus

b. State machine in Papyrus

SDF

SDF A

A o_ab

t_ab

i_ab

B

B i_cb

o_bc

t_bc

t_cb

o_cb

i_bc

C

C

Fig. 5 SDF graphs with Papyrus

UML state machines are used and actors are represented by states. Other clocks, having no graphical equivalent in UML state machines, are left unbound. Finally, our CCSL specification is bound to the UML model and clocks are explicitly connected to the actors (either states or actions). These connections are used by T IME S QUARE animator to animate the UML diagram in Papyrus depending on the execution processed in Figure 4. For instance, when a clock ticks, the state or the action or the pin turns red. The color of the UML model element turns back to its default value when the associated clock does not tick.

6 Discussions 6.1 Static Scheduling Figure 4 shows that tokens can stack up into the queue between actors A and B. Because the rates are known statically in SDF graphs, a static schedule can be processed to ensure that FIFO sizes are bounded if the graph is well-balanced. With this graph, the static scheduling would give the following result:

10

A A B C C B C C ... A A A A ...

After an initialization phase where A executes twice, a steady phase starts where B executes followed by two concurrent executions of A and C, repetitively. The simulation presented does not take that into account since the rules to balance equations have not been captured in the CCSL specification. For this particular graph, a balanced execution can be obtained by adding a back-pressure arc from B to A (Fig. 6). This is equivalent to adding a capacity to the FIFO in the queue tab .

tba 2

1 iba

A

1 oab

tab

oba

2 iab icb

B

obc

2

2 tbc 1

tcb 1 ocb

C

ibc

Fig. 6 Same example with a back-pressure arc from B to A.

To reflect this back-pressure arc, the previous CCSL specification must be extended with one new constraint: S = arc(0, A, 1, B, 2) ∧ arc(0, B, 2,C, 1) ∧ arc(2,C, 1, B, 2) ∧ arc(2, B, 2, A, 1)

(7)

Figure 7 shows one possible simulation after adding the back-pressure arc. The new precedence appears in red on the figure. In that example, the simulation policy is still random. Consequently, a clock is never forced to tick. To obtain the exact same result as the static analysis, another simulation policy should be used, like as soon as possible, without any modification of the specification.

11

Fig. 7 Simulation with TimeSquare - back-pressure arc

6.2 Extensions Several extensions are possible. For instance, we have considered that the execution of actors was atomic. We can also model the execution time explicitly. The way to do that in CCSL is to consider two clocks A.start and A. f inish for each actor A. To measure the duration of the actor execution, we need another clock, i.e., the time base on which the duration is measured. Usually, a duration is expressed relative to the physical time. Of course, CCSL can also access the physical time through the use of chronometric clocks. IdealClk is a dense chronometric clock, predefined in M ARTE Time Library, and supposed to follow “physical time” faithfully. The CCSL operator discretizedBy can be used to discretize IdealClk and build a discrete chronometric clock that ticks periodically. For instance, Eq. 8 builds a 1 kHz discrete clock c1 . c1 = IdealClk discretizedBy 0.001

(8)

With this new clock, we can build a new relation definition (Eq. 9) that we add to our library of CCSL relation definitions. This relation definition has three parameters. start stands for the start of the execution of the actor whereas f inish stands for the end of its execution. The duration is assumed to be in ms since we have used a 1 kHz clock as a reference for the time. The actual relation shown in Eq. 9 does not state that the duration is exactly duration but rather than the duration is necessarily less than duration. The strict equality could have been achieved by replacing the precedence by a coincidence. def actor(clock start, clock f inish, int duration) ,

f inish ≺ (start $c1 duration)

(9)

Note that, the ternary form of the delay operator is used. $c1 means that the delay is measured relative to clock c1 and not to clock start. By replacing Eq. 9 by Eqs. 10–11, we can define a range within which the operation should be executed. min and max are durations also expressed in ms, since the reference clock (c1 ) is a 1-kHz chronometric clock. (start $c1 min) ≺ start

(10)

f inish ≺ (start $c1 max)

(11)

With that new definition of what an actor is, the relation definitions input and out put should be modified so that the arriving of each input precedes the beginning of the execution of the related actor whereas the outputs are exactly emitted when the actor finishes its execution. Several other extensions could be modeled. However, additional complexity in the model reduces the number of good static properties.

12

7 Related Works Ptolemy [Eker et al(2003)] is one famous environment that explicitly deals with MoCCs. It specifically focuses on the interactions between heterogeneous MoCCs. Even though the MoCCs are formally defined, they are hard-coded within the tool and the models themselves are built in Java. Modeling a new MoCC requires to build a new Java library and to build the right director to describe the communications with other compatible MoCCs. ModHel’X [Boulanger et al(2008)] attempts to build a model-based equivalent to Ptolemy and to ease the definition of new MoCCs. However, the directors are still implemented in Java following a predefined template, so the actual semantics is hidden in the Java code and not explicit in the model. KerMeta [Muller et al(2005)] is a metamodeling language that allows a description of both the structural and the behavioral aspects of a model. KerMeta does not provide any specific mechanism to describe the behavioral semantics formally. Chen et al. [Chen et al(2005)] specify the behavioral semantics explicitly by relying on ASM (Abstract State Machine [B¨orger and St¨ark(2003)]), a formal language. Their approach requires a transformation from the domain-specific model under-study to an abstract model that relies on a restricted syntax. Consequently, the actual semantics of the model depends not only on the semantics of the ASM model but also on the abstraction performed during the transformation. Our approach does not require any transformation; we can use any UML model and attach an explicit behavioral semantics with a CCSL specification. The operational semantics is used to check properties and run simulations at the model level. It can also be used to check the conformity of implementations to the model [Andr´e and Mallet(2009)]. Finally, when the UML model is transformed into a specific (formal) language to perform a domain-specific analysis, the semantics of the transformation result can be compared (by bisimulation, for instance) to the semantics of the CCSL specification. 8 Conclusion We propose to use CCSL and M ARTE time model to specify the timed behavioral semantics of UML models. To illustrate the possible usages of CCSL, we have chosen to build a CCSL definition library for SDF. This library is used to build a specific SDF graph and the semantics of this graph is attached to two different UML models. The first UML model is an activity whereas the second is a state machine. To show that CCSL can be used to express both logical and physical time relations, we discuss a possible extension of the CCSL library for SDF where the actual physical durations of actor executions are considered. The actual equivalence between our CCSL model and the selected SDF graphs has not been done and should be done in future works. The idea here was to introduce our mechanism based on CCSL to attach a semantic model to another syntactic (UML) model. The Repetitive Structure Modeling (RSM) part of M ARTE deals with an extension of SDF that considers multiple dimensions. The CCSL library for RSM has not been built yet and appears as a new challenge for CCSL. Additionally, we have explored here how to build a specific MoCC with CCSL but have not investigated how to handle interactions between different MoCCs. References Alur and Dill(1994). Alur R, Dill DL (1994) A theory of timed automata. Theoret Comp Sci 126(2):183–235

13 Andr´e(2009). Andr´e C (2009) Syntax and Semantics of the Clock Constraint Specification Language (CCSL). Research Report RR-6925, INRIA, URL http://hal.inria.fr/inria-00384077/en/ Andr´e and Mallet(2009). Andr´e C, Mallet F (2009) Specification and verification of time requirements with CCSL and esterel. In: LCTES, ACM, pp 167–176 Behrmann et al(2006). Behrmann G, David A, Larsen KG, H˚akansson J, Pettersson P, Yi W, Hendriks M (2006) Uppaal 4.0. In: QEST, IEEE Computer Society, pp 125–126 Benveniste et al(1991). Benveniste A, le Guernic P, Jacquemot C (1991) Synchronous programming with events and relations: the signal language and its semantics. Sci Comput Program 16(2):103–149 B¨orger and St¨ark(2003). B¨orger E, St¨ark R (2003) Abstract state machines: a method for high-level system design and analysis. Springer Boulanger et al(2008). Boulanger F, Hardebolle C (2008) Simulation of multi-formalism models with ModHel’X. In: ICST ’08: Int. Conf. on Software Testing, Verification, and Validation, IEEE Computer Society, Washington, DC, USA, pp 318–327, DOI http://dx.doi.org/10.1109/ICST.2008.15 Bruel et al(2000). Bruel JM, Lilius J, Moreira AMD, France RB (2000) Defining precise semantics for uml. In: Malenfant J, Moisan S, Moreira AMD (eds) ECOOP Workshops, Springer, Lecture Notes in Computer Science, vol 1964, pp 113–122 Chen et al(2005). Chen K, Sztipanovits J, Neema S (2005) Toward a semantic anchoring infrastructure for domain-specific modeling languages. In: Int. Conf. on Embedded Software, ACM, NY, USA, pp 35–43 Chiorean et al(2004). Chiorean D, Pasca M, Cˆarcu A, Botiza C, Moldovan S (2004) Ensuring uml models consistency using the ocl environment. Electr Notes Theor Comput Sci 102:99–110 Eker et al(2003). Eker J, Janneck JW, Lee EA, Liu J, Liu X, Ludvig J, Neuendorffer S, Sachs S, Xiong Y (2003) Taming heterogeneity - the ptolemy approach. Proceedings of the IEEE 91(1):127–144 Eshuis(2006). Eshuis R (2006) Symbolic model checking of uml activity diagrams. ACM Trans Softw Eng Methodol 15(1):1–38 Frappier et al(2008). Frappier M, Gervais F, Laleau R, Fraikin B, St-Denis R (2008) Extending statecharts with process algebra operators. ISSE 4(3):285–292 Gogolla et al(2007). Gogolla M, B¨uttner F, Richters M (2007) Use: A uml-based specification environment for validating uml and ocl. Sci Comput Program 69(1-3):27–34 Grieskamp et al(2000). Grieskamp W, Lepper M (2000) Using use cases in executable z. In: ICFEM, pp 111–120 Hoare(1985). Hoare C (1985) Communicating Sequential Processes. Prentice-Hall Kahn(1974). Kahn G (1974) The semantics of a simple language for parallel programming. Information Processing pp 471–475 Karp & Miller(1966). Karp RM, Miller RE (1966) Properties of a model for parallel computations: Determinacy, termination, queueing. SIAM Journal on Applied Mathematics 14(6):1390–1411 Lamport(1978). Lamport L (1978) Time, clocks, and the ordering of events in a distributed system. Commun ACM 21(7):558–565 Mallet and Andr´e(2009). Mallet F, Andr´e C (2009) On the semantics of UML/MARTE clock constraints. In: ISORC, IEEE Computer Society, pp 305–312 Muller et al(2005). Muller PA, Fleurey F, J´ez´equel JM (2005) Weaving executability into object-oriented meta-languages. In: MoDELS, Springer, LNCS, vol 3713, pp 264–278 OMG(2005). Object Management Group (2005) UML Profile for Schedulability, Performance, and Time Specification. OMG document: formal/05-01-02 (v1.1) OMG(2006). Object Management Group (2006) Object Constraint Language. V. 2.0 formal/2006-05-11 OMG(2007). Object Management Group (2007) Unified Modeling Language, Superstructure. Version 2.1.2 formal/2007-11-02 OMG(2009). Object Management Group (2009) UML Profile for MARTE, v1.0. Object Management Group, OMG document: formal/2009-11-02 Petri(1987). Petri C (1987) Concurrency theory. In: Petri Nets: Central Models and their properties, LNCS, vol 254, pp 4–24 Sinnig et al(2009). Sinnig D, Chalin P, Khendek F (2009) LTS semantics for use case models. In: Shin SY, Ossowski S (eds) SAC, ACM, pp 365–370 St¨orrle(2005). St¨orrle H (2005) Semantics and verification of data flow in UML 2.0 activities. Electr Notes Theor Comput Sci 127(4):35–52 Yang et al(2003). Yang D, sheng Zhang S (2003) Using pi - calculus to formalize uml activity diagram. In: ECBS, IEEE Computer Society, pp 47–54 Yu et al(2008). Yu L, France RB, Ray I (2008) Scenario-based static analysis of UML class models. In: Czarnecki K, Ober I, Bruel JM, Uhl A, V¨olter M (eds) MoDELS, Springer, Lecture Notes in Computer Science, vol 5301, pp 234–248