Content uploaded by Fernando Macías
Author content
All content in this area was uploaded by Fernando Macías on Jul 06, 2020
Content may be subject to copyright.
To appear in EPTCS.
Empowering Multilevel DSMLs with Integrated
Runtime Verification
Fernando Macías, Adrian Rutle, Volker Stolz
Western Norway University of Applied Sciences, Bergen, Norway∗
Torben Scheffel, Malte Schmitz
Institute for Software Engineering and Programming Languages, University of Lübeck, Germany
Within Model-Driven Software Engineering, Domain-Specific Modelling has proven to be a
powerful technique to specify systems and systems’ behaviour in a formal, yet understandable
way. Runtime verification (RV) has been successfully used to verify the correctness of such
behaviour. Specifying behaviour requires managing various levels of abstractions, making
multilevel modelling (MLM) a suitable approach for this task. In this paper, we present an
approach to combine MLM and RV with an example from the domain of distributed real-time
systems. The semantics of the specified behaviour as well as the evaluation of correctness
properties are given by model transformation rules. This facilitates simulation of the system
and checking against real-time temporal logic correctness properties.
1 Introduction and Background
Model-driven software engineering (MDSE) is one of the emergent responses from the scientific
and industrial communities to tackle the increasing complexity of software systems. MDSE
utilises abstractions for modelling different aspects of software systems, and treats models
as first-class entities in all phases of software development. There are quite a few studies
which support gains in quality, performance, effectiveness, etc. as a result of using MDSE
(see, e.g., [
WHR+13
,
WHR14
,
BHW14
,
MGS+13
,
MGSF13
]). However, using modelling to
understand a domain, making the right abstractions, and including all the stakeholders in the
development process, are without doubt the main gains of MDSE [BHW14, MFM+08, TK16].
According to empiric evaluations related to the status and practice of MDSE, the state-
of-the-art modelling techniques and tools do a poor job in supporting software development
activities [
WHR14
]. One way to increase the adoption of MDSE in practice is to develop
modelling approaches which reflect the way software architects, developers and designers, as
well as organisations, domain experts and stakeholders, handle abstraction and problem-solving.
We believe that domain-specific (meta)modelling (DSMM) [
dLGC15
,
MH10
,
TK16
,
KT08
] is an
approach that could unite software modelling and abstraction, software design and architecture,
and organisational studies [WHR14].
DSMM is the art of creating and using languages which are specifically tailored for a particular
domain [
dLGC15
,
Fow11
]. In this case, the concept of “domain” corresponds to both real-life
(problem) domains — such as banking, robotics, healthcare, product line systems, education, etc.
— and technical (solution) domains — such as SQL, HTML, SysML, Petri Nets, etc. The idea of
∗
This work was partially supported by the European Horizon 2020 project COEMS under grant agreement
no. 732016 (https://www.coems.eu/).
arXiv:2005.11366v1 [cs.SE] 22 May 2020
2Empowering Multilevel DSMLs with Integrated Runtime Verification
DSMM is already practiced in industry and academia and its positive results are documented in
the literature [
WHR14
,
BHW14
,
MGS+13
]. Moreover, mainstream approaches to DSMM and
design and implementation of domain-specific languages (DSL), such as the Eclipse Modelling
Framework [
Ecl
], the Unified Modelling Language, MetaCase [
MET
], etc., are all based on
two-level (meta)modelling approaches. That is, domain concepts are defined in metamodels, and
they are instantiated in models which conform to these metamodels. This also includes the usage
of so-called profiles’ or stereotypes’. Provided that in the real-life domains the way of thinking is
not limited to a certain number of abstraction levels, approaches which force designers to adapt
their way of thinking are deemed to fail. Furthermore, describing software domains only in terms
of models and their instances usually leads to unnecessary complexity and synthetic type-instance
relations [
AK08
]. In this work, we propose an alternative approach based on multilevel modelling
(MLM) for DSMM, so that the number of abstraction levels are not limited.
In addition to structure, modelling systems’ behaviour is necessary in order to fully understand
how they work in practice. Modelling behaviour is inherently multilevel since the behavioural
modelling language is defined by a metamodel while the semantics is described two levels below the
metamodel [
dLGC15
,
DLG10
,
RMWL12
]. The cause is that behaviour is reflected in the running
instances of the models which in turn conform to their metamodel. Hence, MLM hierarchies
could be used for DSMM, i.e., for the flexible organization of metamodelling languages, models
and their running instances [dLGC15].
Correctness of behaviour can be addressed through model checking, which usually requires
particular tools, and addressing issues such as state-space explosion. As we would like to keep
expressive modelling and some degree of verification within the same framework so that we can
link the system and its properties, we employ Runtime Verification (RV) as a lightweight formal
method, which checks one execution of the system against a temporal correctness property. By
representing both system and properties as models belonging to related MLM hierarchies, we
can simulate different executions of the system and check them against the specified properties,
while treating these two aspects of the system — behaviour and correctness — uniformly.
To explain our approach, we use distributed real-time systems (in particular, a robotic system)
as a sample modelling domain — which is complex enough yet easy to grasp — together with
linear temporal logic to define correctness properties. We will keep the behavioural models and
the correctness specification synchronized by connecting the propositions used in the correctness
properties to the models in a MLM hierarchy. The semantics of both the modelled behaviour and
the evaluation of the correctness properties are given by the application of model transformation
rulesThese rules are executed on the models and the properties simultaneously — creating and
verifying execution paths in the state space of the system — using a uniform technique.
We start with an explanation of the logic which we use for property specification in the
domain of distributed real-time systems in Section 2. Section 3 describes how we combine MLM
and RV in our setting, Section 4 contains how the simulation with MCMTs works and Section 5
explains how we can evaluate RV properties as models using model transformation rules. Related
work, conclusions and future lines of research are presented in Section 6.
2 Timed Linear Temporal Logic
Correctness properties for RV are usually specified in a temporal logic like the Linear Temporal
Logic (LTL). With LTL one can specify properties about the future of a single execution trace
Fernando Macías et al. 3
of the system under scrutiny. Such an execution trace is represented as a discrete sequence of
execution states, i.e. a finite word
w∈
Σ
+
. In every state, every atomic proposition of the finite
set
AP
is either true or false, i.e. Σ=2
AP
. With LTL one can specify occurrence and ordering
constraints, but LTL can be extended to timed LTL (TLTL, [
RS99
]) to express real-time timing
constraints. Now words are still discrete sequences, but every symbol is paired with a timestamp,
i.e.
w∈
(Σ
×T
)
+
for a time domain
T
. Special extensions of LTL are used to apply LTL to
asynchronous distributed systems (or agents), e.g. with the Distributed Temporal Logic (DTL,
[SS14]) one can specify on which agent subformulas are evaluated.
In this paper we consider asynchronous distributed systems without a shared global clock.
We combine a four-valued semantics for TLTL with a simplified version of DTL, where remote
subformulas are restricted to atomic propositions, to be able to specify and monitor real-time
constraints on the different agents. TLTL can express properties about relative time differences
through the prophecy operator
. We restrict TLTL to the future fragment which can only relate
current events with upcoming events. This fragment can be monitored using term-rewriting
techniques known as unrolling [
HR01
,
Leu11
]. Now let
AP
be the set of atomic propositions
which are evaluated either to
true
or
false
in every event. Then
w
= (
a0,t0
)
,...,
(
an,tn
)
∈
(Σ
×T
)
+
is a finite event sequence over the alphabet Σ=2
AP
with time domain
T
. For such a word
w
we denote with
wi
:= (
ai,ti
)
...
(
an,tn
)the suffix starting with event
ai
. The syntax of
TLTL formulas
ϕ
is given by the following grammar for
p∈AP
and
t1,t2∈T
with
t1< t2
:
ϕ
::=
p| ¬ϕ|ϕ∨ϕ|Xϕ|ϕUϕ|[t1,t2]p
. For formulas
ϕ
and
ψ
and a word
w
, the semantics for
a TLTL formula is given inductively as a relation
|
=between words and the formulas they fulfil:
w|=p⇔p∈a0
w|=¬ϕ⇔w6|=ϕ
w|=ϕ∨ψ⇔w|=ϕor w|=ψ
w|= Xϕ⇔ |w|>1∧w1|=ϕ
w|=ϕUψ⇔ ∃i:wi|=ψ∧ ∀j < i :wj|=ϕ
w|=[tl,th]p⇔ ∃i:p∈ai∧tl≤ti≤th
∧∀j: 0 < j < i →p /∈aj
Additional LTL operators can be added as syntactic sugar, e.g. through the following equivalences:
true
:
≡ϕ∨¬ϕ
,
false
:
≡ ¬true
,
ϕ∧ψ
:
≡ ¬
(
¬ϕ∨¬ψ
),
Fϕ
:
≡trueU ϕ
,
Gϕ
:
≡ ¬F¬ϕ
,
Xϕ≡
¬X¬ϕ
. The syntax and semantics can easily be extended to allow
[tl,th]¬p
through exchanging
p∈aiand p /∈ai.
Monitoring TLTL
. To evaluate a word against a TLTL formula a step-wise monitoring function
e
is used.
e
takes an input symbol (the set of atomic propositions valid in that event), the relative
time elapsed since the last event and the current formula.
e
returns an intermediate verdict
indicating if the formula is fulfilled by the word up to this event and the rest of the formula
which has not been fulfilled yet. We use the truth domain
B4
=
{>,>c,⊥c,⊥}
for the output
verdicts, where
>
and
⊥
represent final verdicts and
>c
and
⊥c
represent current verdicts up to
now, which might change with new events arriving [
Leu11
]. Because
B4
is a lattice it provides
the operators meet
u
,join
t
and complement as generalization of the boolean operators and
∧
,
or ∨and not, e.g. >u⊥c=⊥c,>t⊥c=>and ⊥c=>c.
Monitoring Distributed Systems
. We adopt the concepts behind DTL as presented in
[
SS14
] to get a simplified monitoring of the behaviour of a distributed system: The formula @
Aϕ
represents the formula
ϕ
being evaluated on agent
A
. The TLTL formula
ϕ
can contain other
@-annotations followed by atomic propositions, which refers to the current evaluation of that
proposition on that agent. Note that as in DTL we only specify properties with respect to the
knowledge that an agent has about the other agents.
4Empowering Multilevel DSMLs with Integrated Runtime Verification
3 Combining Models and Properties
In MDSE, models are commonly formalised using concepts from graph and category theory,
which is also applicable to multilevel modelling. In this paper, we use a graph-based formalisation
that defines multilevel hierarchies of models as graphs whose elements have typing relations
among them. That is, every element in a model has a type which must be defined in a model at
a higher level of abstraction. Models belong to levels, which are numbered incrementally from
level 0, which contains the self-defining root model of the hierarchy.
3.1 Robolang hierarchy
The MLM hierarchy used in this paper depicts a DSML which enables modelling of distributed
real-time robots (see Fig. 1). It allows to specify different agents, each with its own independent
workflow, as well as the messages that they send each other when firing a transition. These
messages can also act as guards of a transition, so that it is only fired once the message is received.
Additionally, the concepts of explicit time passing and timeout are part of the models. In this
hierarchy, elements are visualised as rectangles and their types are depicted with a blue ellipse
on the rectangle, while relations are visualised as arrows with their types in italics font style.
The top-most model of Fig. 1(a), robolang, contains the elements Task,Transition and Input,
and the references among them; as seen from the types EClass and EReference, this model is
typed over Ecore [
SBPM08
]. These three elements are contained inside Agent, a concept used
to represent each of the robots which participate in a scenario. Agents have an active boolean
attribute which indicates if the robot has switched to a new state in the last time step or remained
in its current one, e.g. by firing a transition or receiving a message. Agents can also contain
TimedGuards. The two attributes inside a timed guard are meant to be instantiated in adjacent
levels: when designing a specific workflow, the threshold attribute must be given a value which
indicates the minimum amount of time that the task prior to a transition must be executed
before the transition (which connects to the guard via the timedGuards arrow) can be fired. In
the levels below, the elapsed attribute is used to keep track of the amount of time that the task
has been running already. Once this number become greater or equal than the threshold specified
in the level above, the transition can be fired. The elapsed time in timed guards must increase in
the same amount as the global time in System, which represents the whole modelled scenario and
contains all agents.
As shown in the figure, Message can be contained by either the system (if the message was just
sent) or by an agent (if the message was received already). A transition can send the messages
indicated by the send relation when it is fired to the agents that the message connects to, using
the recipients relation. When the message is received, it can trigger other transitions to which it
is connected using the messageGuard relation.
In our case, we are working with simple Lego robots hence we adapt the language robolang to
cope for specific concepts and behaviour. The model legolang in Fig. 1(a) contains the refinements
of task, input and message into more specific ones. These refinements are performed by creating
a new modelling level and adding it to the hierarchy below robolang. Elements of the new model
are typed by elements of the original model, as indicated by the blue ellipses. We specify here
four types of movement in two dimensions for our robots: GoForward,GoBack,TurnLeft and
TurnRight. There are also tasks to make the robot Beep, stay Idle and the special task Inital which
marks the starting point of the workflow. There are also the inputs Edge and Obstacle, and two
Fernando Macías et al. 5
(d) master_saviour
GFM Beep
Obstacle
Master
GF1
Idle1
[Stop]
Slave1
GF2
Idle2
[Stop]
Slave2
Stop
Stopped1 Stopped2
(a) robolang
EClass
EClass
EClass
EClass
EClass
EClass
EClass
previous
EReference
inputs
EReference
next
EReference
send
EReference
recipients
EReference
timedGuards
EReference
tasks
EReference
messages
EReference
agents
EReference
inputs
EReference
transitions
EReference
timedGuards
EReference
received
EReference
messageGuards
EReference
(b) legolang
Task
Task
Task
Task
Task
Message
Input
Input
Task
Message
Task
(c) master_saviour
Agent@2
System@2
Agent@2
Agent@2
GoForward
Beep
Obstacle
Initial
Idle
Stop
GoForward
Stopped
Stopped
GoForward
Transition@2
Idle
Transition@2
Transition@2
Transition@2
Transition@2
Transition@2
Initial
Initial
master
agents@2
slave1
agents@2
slave2
agents@2
beep
tasks@2
initial
tasks@2
gfm
tasks@2
itm
transitions@2
tm
transitions@2
stopped
recipients@2
stopped
recipients@2
p
previous@2
n
next@2
p
previous@2
n
next@2
i
inputs@2
i
inputs@2
sendStopped
send@2
sendStopped
send@2
p
previous@2
n
next@2
p
previous@2
n
next@2
p
previous@2
n
next@2
p
previous@2
n
next@2
recipient1
recipients@2
receiver2
recipients@2
sendStop
send@2
initial
tasks@2
it1
transitions@2
gf1
tasks@2
t1
transitions@2
idle1
tasks@2
initial
tasks@2
it2
transitions@2
gf2
tasks@2
t2
transitions@2
idle2
tasks@2
relation
messageGuards@2
Figure 1: Robolang MLM hierarchy for definition of robot behaviour
6Empowering Multilevel DSMLs with Integrated Runtime Verification
types of message: Stop, where the sender orders the receiver to remain idle, and Stopped, as an
acknowledgement for it. Other refinements of the robolang model will give different branches
with a common root, hence yielding a tree-shaped hierarchy.
The master_saviour model in Fig. 1(a) shows a relatively simple scenario which uses most of
the concepts in this version of the language. Although it is machine readable, the syntax shown
in this model is not human-friendly. Therefore, we propose a concrete syntax for describing
scenarios in Fig. 1(d) using the following representations for the instances of different types:
•
The instance of system containing the other elements has no explicit representation, but
simply becomes the canvas in which the rest of the graphical elements are laid out.
•Instances of agents appear as black boxes.
•
Instances of tasks are represented as grey rectangles except the initial ones which are
represented with a black dot.
•Instances of transitions appear as arrows between previous and next tasks.
•
Instances of inputs are red boxes, connected by a dashed line to the transition they trigger.
•
Instances of messages which are sent appear as blue boxes, connected to the sender
transitions and to their receivers by dashed blue lines. Messages that act as guards appear
as a blue label for the transition they trigger and within square brackets.
Keeping this representation in mind, it is now easier to understand the modelled scenario:
There are three agents, which we can imagine moving in the same direction. One of them, the
master, has a sensor able to detect obstacles, whereas the other two agents, the slaves, are blind
and moving slightly behind their master. In case there is an obstacle in the way, the master must
alert the slaves so that they can stop before crashing into it, and then beep as a notification
that an obstacle was found. The slaves must just keep going forward until they receive the Stop
message, to which they respond by sending an instance of the Stopped message each, and then
become idle. Note that the types of the tasks and messages are not visible in this representation,
but can be checked in the abstract one, e.g. GF1 is an instance of GoForward.
3.2 Supplementary Hierarchies and Double-Typing
The hierarchy Robolang contains the language and the distributed scenario with the robots that
we want to simulate. We call this for application hierarchy, depicting that the application domain
is definition of robotic models. This hierarchy is independent from the TLTL hierarchy that
contains the syntax for the TLTL language. The TLTL hierarchy is shown in Fig. 2 and explained
shortly in Section 5. In order to relate both hierarchies and be able to specify temporal properties
for the simulated scenario, we exploit the concept of supplementary hierarchy [
MRS+18
]. By
declaring one hierarchy as supplementary to the application hierarchy, elements in the latter can
be double-typed with supplementary types. The supplementary typing relations are indicated in
green to differentiate them from the ones in the application hierarchy (in blue). Now we can
define temporal properties in which the atomic propositions are small model fragments, which
are at the same time part of the TLTL property (due to their supplementary type) and consistent
with the types of Robolang (due to their application type). The model in Fig. 2(b) represents the
property “when master detects an obstacle, both slaves will get messages within 3 time units”,
explained in Section 5.
Fernando Macías et al. 7
master_savior
legolang
robolang
(b) slaves_saved
EClass
1-1-*
G
EClass
1-1-*
Implication
EClass
1-1-*
Atomic
EClass
1-1-*
And
EClass
1-1-*
WeakProphecy
EClass
1-1-*
WeakProphecy
Obstacle
1-1-*
Element
EClass
1-1-*
Atomic
EClass
1-1-*
Atomic
Message@2
1-1-*
Element
Message@2
1-1-*
Element
f@1-1-*
EReference
l@1-1-*
EReference
r@1-1-*
EReference
e@1-1-*
EReference
l@1-1-*
EReference
r@1-1-*
EReference
f@1-1-*
EReference
f@1-1-*
EReference
e@1-1-*
EReference
e@1-1-*
EReference
(a) dtltl4
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
EClass
1-1-*
relation@1-1-*
EReference
formula@1-1-*
EReference
left@1-1-*
EReference
right@1-1-*
EReference
has@1-1-*
EReference
formula@1-1-*
EReference
Figure 2: TLTL property as model and TLTL language as supplementary hierarchy
4 Simulation Semantics with MCMTs
The semantics for models that represent behaviour, like the ones in the example, can be
implemented using model transformations. We will use Multilevel Coupled Model Transformations
(MCMT, [
MRS+18
]) rules for both the simulation of the system and the evaluation of TLTL
properties which the system should satisfy. MCMTs are a kind of model transformations which
use multilevel information to increase the flexibility and reusability of model transformations.
MCMT rules are expressed in a declarative manner, with a FROM block that needs to match
(i.e. be isomorphic and compatible with multilevel typing) against the model in order to be
applied. If such a match found, the matched subgraph is replaced by the one specified in another
block, called TO. The information about multilevel typing is specified in a different block called
META, which requires to be matched in the metalevels of the model being transformed, prior to
the match of FROM.
In the Robolang case, MCMTs describe the simulation semantics used to generate the sequence
of models which simulate the evolution of the system through time. While in the TLTL case,
MCMT rules are used to monitor the simulation, performing unrolling and evaluation on the
model which represents the TLTL property. These rules implement the TLTL monitor function
e
from Section 2. Both sets of MCMT rules are then coordinated to be run with specific
priorities, so that the simulation and the evaluation can be performed in an interleaving fashion,
as illustrated in the examples in Fig. 8 and 9 and described in more detail in the next section.
Using MCMTs we can specify the complete semantics of the Robolang language using a
coordination algorithm and four groups of rules: Behavioural,Environmental,Time stepping
and Remove active marks. The coordination algorithm is given at the end of this section and
defines the number of rules and the order in which the rules from each group are executed. In
the following, we explain the most relevant MCMTs, using the concrete syntax of our example in
8Empowering Multilevel DSMLs with Integrated Runtime Verification
Fig. 1, and an explanation of their semantics. For simplicity, instead of the blue ellipses we use
E:T to indicate that an element Ehas a type T.
4.1 Behavioural Rules
The behavioural rules encode the semantics of how agents evolve through time, execute tasks,
switch from one task to the next, and interact with messages and environmental information.
X:Task Y:Task
T:Transition
I:Input
in:inputs
A1:Agent
M:Message[n]
A2:Agent[n]
se:send[n]
re:recipient[n]
x:X i:I
a1:A1 a2:A2
y:Y i:I
a1:A1
m:M
a2:A2
r:re
META
FROM TO
Figure 3: MCMT Fire Transition with Input
Fire Transition with Input. (Fig. 3) This rule
allows an agent to progress by responding to
environmental inputs (red). If a message has to
be sent during the transition, messages into the
system (outside any agent) are created. One
message per receiving agent is created, with
exactly one reference to the sending agent and
exactly one reference to the recipient (blue).
Note that due to the [n] multiplicity specifier
this rule will match scenarios in which A1 sends any number of messages to the same number of
agents.
X:Task Y:Task
T:Transition
[G:Message]
mg:messageGuards
A1:Agent
M:Message[n]
A2:Agent[n]
se:send[n]
re:recipient[n]
x:X g:G
a1:A1 a2:A2
y:Y
a1:A1
m:M
a2:A2
r:re
META
FROM TO
Figure 4: MCMT Fire Transition with Guard
Fire Transition with Message Guard. (Fig. 4)
This rule is similar to the previous one, but
the transition is triggered by the reception of
a message, which acts as a guard. As opposed
to inputs, guards are consumed when the tran-
sition is fired. That means that this MCMT
removes the guard from the running instance
(in the TO block) once it is fired.
Two similar rules for firing both the initial
transitions and those triggered by a timed guard, together with a simple rule for adding them,
have been excluded due to space limitations and their absence in the example.
4.2 Environmental Rules
The rules from this group are applied to simulate changes on the environment of the agents, such
as a change perceived through some input from the agent’s sensors or a message being received
from another agent.
Insert Input. (Fig. 5) This rule creates an input inside an agent. It is a non-deterministic and
loose version of the next rule, since the appearance of such input may not cause any effect on
the execution.
Insert Effective Input. (Fig. 6) This rule creates an input inside an agent, ensuring that it will
cause its currently running task to stop, since it will introduce and input that will allow the rule
Fire Transition with Input to be executed next. Although this rule is more restrictive than Insert
Input, it is still non-deterministic, since there may be more than one agent in which this rule can
be matched.
Delete Input. Represents the deletion of a previously existing input. This rule reflects the fact
that an input, previously detected by an agent, can not be detected any more. For instance, if
Fernando Macías et al. 9
I:Input
A:Agent
a:A
i:I
a:A
META
FROM TO
Figure 5: MCMT Insert Input
X:Task Y:Task
T:Transition
I:Input
in:inputs
A:Agent
x:X
a:A
x:X i:I
a:A
META
FROM TO
Figure 6: MCMT Insert Effective Input
an agent is moving backwards, an obstacle detected in front of it should eventually disappear.
This rule is a mirrored version of Insert Input in Fig. 5.
A:Agent
M:Message
re:recipient
a:A
m:M
r:re [m:M]
a:A
META
FROM TO
Figure 7: MCMT Receive Message
Receive Message. (Fig. 7) If a message was previously
sent to an agent, but not received by it yet, this rule can
be applied to simulate the reception of such a message.
The rule makes the agent a container of the message.
Hence, after applying this rule, the message acts as a
guard, and its graphical representation changes.
Time Stepping Rule
. Contains a single rule Step
Time, not depicted due to its simplicity, which represents
the forward passage of time for a given amount.
Remove Active Marks Rule
. Same as before, this group just contains a very simple rule,
not shown, to set active=false in an agent, hence removing the mark.
4.3 Coordination Algorithm
The MCMT rules aforementioned must be coordinated with certain priorities in order to yield the
expected result. This process of coordination consists simply of a number of layers or priorities
which we indicate with circled numbers (
n
), to which each rule belongs. Inside a group, we can
either choose to run a single matching rule from that layer, or sequentially run rules from the
same layer until no more rules match. The coordination for our example scenario consists of the
following layers:
1
Run as many rules as possible from the Behavioural rules until no further
matching rules are found, thus allowing all agents to progress by reacting to environmental
changes or incoming messages.
2
Apply one rule from the Environmental Rules. If more than
one rule matches the current snapshot, the user can manually select (hence guiding the execution),
or the system will non-deterministically choose one of them.
3
Run the Time Stepping rule
once. This represents the global passage of time.
4
Apply the coordination (sub)algorithm for
the rules for monitoring TLTL properties, which is given in the next section.
5
Finally, apply
the rule Remove Active Mark as many times as possible, to remove it from all agents. Once the
last layer is reached, one new snapshot and its corresponding evaluation have been generated,
and the process starts from the beginning again. In Fig. 8, the layers applied to generate a new
snapshot are indicated with B(Behavioural), E(Environmental) and T(Time step). The TLTL
monitoring and Remove Active Marks layers are always executed after T.
10 Empowering Multilevel DSMLs with Integrated Runtime Verification
5 TLTL Modelling and Semantics
The model representing the TLTL language consists of nodes representing the non-terminal
symbols of the TLTL grammar, which are specialised using inheritance into the specific operators
of the language. The relations among operators in a property are expressed as edges, so that the
subformula contained inside an operator can be a whole expression, recursively defined. It is
worth mentioning that all nodes inherit from the one called Formula, which contains a boolean
attribute represented as
X
when set used during the property evaluation explained below. A
specific TLTL property is built as an instance of this model. Due to the EBNF-like structure of
this model, its instances are tree-shaped structures, with the outermost operator as the root of
the tree, its subformulas as the children nodes of the root, the outermost operator of a subformula
as the root of the subtree, and so on. The property shown in Fig. 9 expresses that whenever the
master encounters an obstacle, the slaves will stop within a given time interval (3 units) through
the temporal pattern G(o→([0,3]m1∧[0,3]m2)).
5.1 Snapshots, Words and Evaluation
To check if an execution sequence of Robolang snapshots fulfils a TLTL specification, we need
to relate a snapshot sequence to an input word for TLTL such that we can apply the TLTL
semantics as defined before. In order to link a language such as Robolang with the TLTL formulas,
the language must contain mappings for the following concepts: Agents, to be able to relate
monitors to the different actors in a distributed system; an Active mark in agents, to know
when their associated monitor must (re)evaluate a formula; Messages, for the distribution of
evaluations in remote monitors (see the example in Figure 8 and 9); and a clock, where each
agent can retrieve relative time differences to calculate the time increase. An Agent (white
box) contains the active boolean mark (blue corner), as well as Tasks (grey boxes), Transitions
(black arrows) that connect them and Messages (blue boxes) that can be send and received. The
Messages acting as guards (blue brackets), together with Inputs (red boxes) and Timed Guards
(not used in our example) can trigger a Transition (dashed lines) to the next Task.
GFM Beep
Obstacle
Master
GF1
Idle1
[Stop]
Slave1
GF2
Idle2
[Stop]
Slave2
Stop
Stopped1 Stopped2
@Master G(o→.[0,3]@Slave1s∧.[0,3]@Slave2s)
Obstacle [Stop]
:GFM :Obstacle
:Master
:GF1
:Slave1
:GF2
:Slave2
t=2.1
:GFM :Beep
:Obstacle
:Master
:GF1
:Slave1
:GF2
:Slave2
:Stop
t=2.1
:Beep :Obstacle
:Master
:GF1
:Slave1
:GF2
:Slave2
:Stop
t=2.1
:Beep
:Master
:GF1
:Slave1
:GF2
:Slave2
:Stop
t=2.6
:Beep
:Master
:GF1 [:Stop]
:Slave1
:GF2
:Slave2
:Stop
t=2.9
:Beep
:Master
:GF1 :Idle1
[:Stop]
:Slave1
:GF2
:Slave2
:Stop
:Stopped1 m1
t=2.9
:Beep [:Stopped1]
:Master
:Idle1
:Slave1
:GF2 [:Stop]
:Slave2
t=4.7
:Beep [:Stopped1]
:Master
:Idle1
:Slave1
:GF2
:Slave2
:Stop
t=4.1
:Beep [:Stopped1]
:Master
:Idle1
:Slave1
:GF2 :Idle2
[:Stop]
:Slave2
:Stopped2 m2
t=4.7
:Beep
[:Stopped1] [:Stopped2]
:Master
:Idle1
:Slave1
:Idle2
:Slave2
t=5.6
m1:sm2:s
m0:o→.0
[0,3]m1∧.0
[0,3]m2
m0:o→.0
[−.5,2.5]m1∧.0
[−.5,2.5]m2m1:s
m1:s
m0:.0
[−2,1]m1∧.0
[−2,1]m2m2:s
m2:s
m0:.0
[−3.5,−.5]m2
B B E,T
E,T E,T B B,E,T
B,E,T E,T B B,E,T
Figure 8: Example of simulation with the resulting snapshots
Fernando Macías et al. 11
G→o
X
∧.[0,3]
Xm1
.[0,3]
Xm2
∧
→o
X
∧.[0,3]
Xm1
.[0,3]
Xm2
X
Xϕ
∧
→true
∧.0
[0,3] m1
.0
[0,3] m2
X
Xϕ
∧→>
∧⊥c
⊥c
>c
⊥c
∧∧.0
[0,3]
X
m1
.0
[0,3]
X
m2
ϕ
X
∧
∧.0
[−.5,2.5]
X
m1
.0
[−.5,2.5]
X
m2
∧
→o
X
∧.[0,3]
Xm1
.[0,3]
Xm2
X
Xϕ
∧
∧.0
[−.5,2.5] m1
.0
[−.5,2.5] m2
∧
→false
∧.0
[0,3] m1
.0
[0,3] m2
X
Xϕ
∧
∧⊥c
⊥c
∧→⊥
∧⊥c
⊥c
>c
⊥c
∧∧.0
[−.5,2.5]
X
m1
.0
[−.5,2.5]
X
m2
ϕ
X
∧
∧.0
[−2,1]
X
m1
.0
[−2,1]
X
m2
∧
→o
X
∧.[0,3]
Xm1
.[0,3]
Xm2
X
Xϕ
∧
∧true
.0
[−2,1] m2
∧
→false
∧.0
[0,3] m1
.0
[0,3] m2
X
Xϕ
∧
∧>
⊥c
∧→⊥
∧⊥c
⊥c
>c
⊥c
∧.0
[−2,1]
X
m2
ϕ
X
∧
.0
[−3.5,−.5]
X
m2
∧
→o
X
∧.[0,3]
Xm1
.[0,3]
Xm2
X
Xϕ
∧false
∧
→false
∧.0
[0,3] m1
.0
[0,3] m2
X
Xϕ
∧⊥
∧→⊥
∧⊥c
⊥c
>c
⊥
ϕ
3 , 4
5 , 6 , 7
8
9
8,9
1 , 2
3 , 4
5 , 6 , 7
8
9
8,9
1 , 2
3 , 4
5 , 6 , 7
8
9
8,9
1 , 2
3 , 4
5 , 6 , 7
8
9
Figure 9: Example of evaluation of a distributed, timed LTL property
12 Empowering Multilevel DSMLs with Integrated Runtime Verification
Now we can interpret a snapshot sequence as word
w∈
(Σ
×T
)
+
: For a TLTL formula @
Aϕ
we
have a word
wA
= (
wA
0,tA
0
)
...
(
wA
n,tA
n
)for every agent
A
by having
wA
i
for the
i
-th snapshot that
has an active mark in
A
such that
wA
i
contains all propositions, whose linked model fragments
are present in the snapshot, and tA
iis the current timestamp of the snapshot.
We apply online monitoring through evaluating the TLTL properties along with executing
the Robolang models. We implemented the TLTL monitoring function in terms of MCMT rules:
We use unrolling for the currently to-be-evaluated temporal operators and then replace the
propositions with the truth values according to the current snapshot and propositions, as well as
adjusting the time of prophecy operators. Then, by replacing all currently evaluated operators
by the corresponding truth values from the four-valued domain, we can calculate the current
truth value resulting from the last seen snapshot. For the snapshots given in Fig. 8, this leads to
the trees in Fig. 9.
5.2 Monitoring TLTL using MCMTs
Formula
XOp:EClass
formula r:EReference
x:X op:Op
f:Formula
r:r
fo:formula
op:Op
f:Formula
r:r
META
FROM TO
Figure 10: Delete Weak Next
Due to space limitations, we do not include an exhaustive list
of all the MCMTs required to express the TLTL monitoring
function defined in Section 2. As an illustrative example,
Fig. 10 depicts the Delete Weak Next rule, used in step
8
. The rest of them follow a similar structure, and are
coordinated as follows (again representing layers as circles):
The first steps mark the outermost temporal operators:
1
Set
X
in the root of the expression.
2
As long as there is a
boolean operator having X, remove Xfrom it and set Xto all of its children.
Now all the outermost temporal operators and atomic propositions are marked with
X
. Next
we apply unrolling operations for the marked temporal operators:
3
For every temporal operator
having
X
, the corresponding unrolling rule is applied according to the monitoring function
described in Section 2. The rules that generate operators or atomic propositions outside of
temporal operators, mark these with
X
.
4
Update all
0
[t1,t2]
with
0
[t1−δ,t2−δ]
where
δ
is the time
difference between the current and the previous snapshot. If a timed boundary becomes negative,
it means that the boundary has been trespassed.
In the end, all the operators and atomic propositions outside of temporal operators are
marked with
X
. Next the prophecies and atomic propositions must be evaluated:
5
Replace
every atomic proposition having
X
with
true
or
false
, depending on whether we find a match of
the atomic proposition in the current snapshot.
6
For every
0
[t1,t2]
having
X
, replace it with
true
or
false
according to the monitoring function described in Section 2. If it remains unchanged,
remove
X
.
7
Replace every
[t1,t2]
having
X
with
0
[t1,t2]
. These rules then remove
X
from the
affected operators.
Next, the result of the previous steps is used for two different paths of transformations: On
one of them, the rules calculate the four-valued boolean evaluation of the property for the current
state of the system, i.e. current snapshot:
8
Replace
true
by
>
,
false
by
⊥
,
Xϕ
and
[t1,t2]ϕ
by
⊥c
, and
Xϕ
by
>c
. All subformulas
ϕ
from these operators are removed, leaving the tree just
with values from
B4
and boolean operators.
9
Apply operations on
B4
to the resulting tree until
the whole tree collapses to a single B4value, which is the current evaluation of the property.
Independent from the previous two steps, the state of the property is also used to calculate
the obligation property, i.e. what must be evaluated in the next snapshot. These two steps
Fernando Macías et al. 13
are performed in a different branch of execution, and therefore represented as filled circles:
8
For every
Xϕ
and
Xϕ
having
X
, they get replaced with their subtree
ϕ
.
9
Apply boolean
simplifications to any feasible match found throughout the tree, e.g.
true∧x≡x
. The resulting
model represents the obligation property to be evaluated in the next snapshot.
Fig. 9 displays the simplified model representation of the property evaluated by the monitor
m0
in the snapshots where the agent :Master is active, and its evaluation to ultimately false (
⊥
).
The blue arrows between models represent the application of each group of rules defined above.
6 Related Work & Conclusion
We have focussed on a temporal logic which is well-known, intuitive (to some degree), and that
does not distract with its complexity from the core idea of coupling simulation/execution and
runtime verification. The Linear Temporal Logic (LTL, [
Leu11
]) and its extensions to timed
and distributed properties [
SS14
,
RS99
] makes it suitable for our task, but are of course not the
only possible choice. As we encode the verification step-wise via the transformation rules of our
framework, other logics are equally suited. We distinguish this clearly from approaches where
verification is done via a separate tool that is connected through abstract events: while this may
allow a wider choice of logics, we no longer have the advantage of having the property coupled to
the actual model, but would rather require separate model transformation steps of translating the
property from its term-representation into the input for the verification tool, as well as serialize
events, and hence forgo the advantages of co-evolution between model and specification.
The verification community uses specialised tools such as Uppaal or CPNTools, but they
constrain the modeller, as the focus is more on verification than on concepts and modelling. A
notable exception are rewriting logics-based approaches in Maude: models are encoded via sorts,
which allows capturing a hierarchy of abstraction levels, and configurations that capture states.
Rewriting rules can then address orthogonal or overlapping concerns within a single configuration,
tying together the ontological model with its behaviour rules, supplementary sorts with their
own set of rules, and rules which map events in the model to input events to the logic [HR01].
Incorporating evolution of the model over time into the modelling process is in itself not
new. Model transformation are already used for definition of behaviour [
CHM+02
,
dLV02
,
Tae04
,
Ren04
,
RDV09
,
SR14
]. Model versioning and suitable techniques have been studied
by Altmanninger et al.[
ASW09
]. Linear Temporal OCL (LT-OCL, [
SE09
]) is an approach to
allow temporal queries over dynamic behaviour, for the purpose of defining reactive behaviour.
Gomez et al.[
GCW18
] have turned this idea into a working framework built on EMF, called
TemporalEMF. In this system, one would still need an additional layer of encoding e.g. for the
binary temporal operators into the OCL-dialect. Both in LT-OCL and TemporalEMF, one has
to some degree the desired co-evolution through syntax-checking of the OCL-queries against the
models. Encoding a temporal logic in a temporal query language fixed by OCL, any EMF-based
solution would still require additional logic and a flattened model to take into account the
multiple levels of the specification, i.e. the temporal language can not be easily changed by
swapping out a supplementary hierarchy.
Conclusion and Future Work.
In this paper we used the expressive power of MLM to
independently specify a behaviour model and its rules for execution, and a logic and its semantics
for verification. Through double-typing, we couple atomic propositions in the logic with the state
14 Empowering Multilevel DSMLs with Integrated Runtime Verification
of the simulation. Both the simulation rules and the evaluation rules for timed properties are
given as MCMTs, and through proper coordination we perform runtime verification of a run
of a model, i.e. evaluating a sequence of states wrt. the specified logical property. The close
link between the correctness properties and the models allows to keep both synchronized during
refinement processes of the models and even for the deployment of the models, e.g. using code
generation. Since in RV we only verify one particular run, we have been able to integrate the
progress of time and the behaviour of the environment as part of the execution.
We plan to extend the language of MCMTs with rule inheritance, which would avoid some
repetition (e.g. the rules for firing transitions). Another topic for future work would be how the
usage of different real time logics would affect our approach and if more expressive logics like
Metric Temporal Logic [Koy90] or Metric Interval Temporal Logic [AFH96] can be used.
References
[AFH96]
Rajeev Alur, Tomás Feder, and Thomas A. Henzinger. The benefits of relaxing punctuality.
J. ACM, 43(1):116–146, 1996.
[AK08]
Colin Atkinson and Thomas Kühne. Reducing accidental complexity in domain models.
Software & Systems Modeling, 7(3):345–359, 2008.
[ASW09]
Kerstin Altmanninger, Martina Seidl, and Manuel Wimmer. A survey on model versioning
approaches. IJWIS, 5(3):271–304, 2009.
[BHW14]
Håkan Burden, Rogardt Heldal, and Jon Whittle. Comparing and contrasting model-driven
engineering at three large companies. In ACM-IEEE Intl. Symposium on Empirical Software
Engineering and Measurement (ESEM), pages 14:1–14:10, 2014.
[CHM+02]
György Csertán, Gábor Huszerl, István Majzik, Zsigmond Pap, András Pataricza, and Dániel
Varró. VIATRA - visual automated transformations for formal verification and validation of
UML models. In Intl. Conf. on Automated Software Engineering, pages 267–270, 2002.
[DLG10]
Juan De Lara and Esther Guerra. Generic meta-modelling with concepts, templates and
mixin layers. In Intl. Conf. on Model Driven Engineering Languages and Systems, volume
6394 of LNCS, pages 16–30. Springer, 2010.
[dLGC15]
Juan de Lara, Esther Guerra, and Jesús Sánchez Cuadrado. Model-driven engineering with
domain-specific meta-modelling languages. Software & Systems Modeling, 14(1):429–459,
2015.
[dLV02]
Juan de Lara and Hans Vangheluwe. Atom
3
: A tool for multi-formalism and meta-modelling.
In Fundamental Approaches to Software Engineering (FASE), volume 2306 of LNCS, pages
174–188. Springer, 2002.
[Ecl]
Eclipse Modeling Framework. Eclipse Modeling Framework.
http://www.eclipse.org/
modeling/emf.
[Fow11] Martin Fowler. Domain-Specific Languages. Addison-Wesley, 2011.
[GCW18]
Abel Gómez, Jordi Cabot, and Manuel Wimmer. TemporalEMF: A temporal metamodeling
framework. In Juan C. Trujillo et al., editors, Conceptual Modeling, volume 11157 of LNCS,
pages 365–381. Springer, 2018.
[HR01]
Klaus Havelund and Grigore Rosu. Monitoring programs using rewriting. In 16th IEEE Intl.
Conf. on Automated Software Engineering, pages 135–143, 2001.
[Koy90]
Ron Koymans. Specifying real-time properties with metric temporal logic. Real-Time Systems,
2(4):255–299, 1990.
[KT08]
Steven Kelly and Juha-Pekka Tolvanen. Domain-Specific Modeling - Enabling Full Code
Generation. Wiley, 2008.
Fernando Macías et al. 15
[Leu11]
M. Leucker. Teaching Runtime Verification. In RV, volume 7186 of LNCS, pages 34–48.
Springer, 2011.
[MET] UML. https://www.metacase.com/. Accessed: 2017-03-15.
[MFM+08]
Parastoo Mohagheghi, Miguel Fernández, Juan Martell, Mathias Fritzsche, and Wasif Gilani.
MDE adoption in industry: Challenges and success criteria. In Workshops and Symposia at
MODELS, pages 54–59, 2008.
[MGS+13]
Parastoo Mohagheghi, Wasif Gilani, Alin Stefanescu, Miguel Fernández, Bjørn Nordmoen,
and Mathias Fritzsche. Where does model-driven engineering help? Experiences from three
industrial cases. Software & System Modeling, 12(3):619–639, 2013.
[MGSF13]
Parastoo Mohagheghi, Wasif Gilani, Alin Stefanescu, and Miguel Fernández. An empirical
study of the state of the practice and acceptance of model-driven engineering in four industrial
cases. Empirical Software Engineering, 18(1):89–116, 2013.
[MH10]
Parastoo Mohagheghi and Øystein Haugen. Evaluating domain-specific modelling solutions.
In ER Workshops, pages 212–221, 2010.
[MRS+18]
F. Macías, A. Rutle, V. Stolz, R. Rodriguez-Echeverria, and U. Wolter. An Approach to
Flexible Multilevel Modelling. Enterprise Modelling and Information Systems Architectures -
International Journal of Conceptual Modeling, 13:10:1–10:35, 2018.
[PNB04]
J. Pfaltz, M. Nagl, and B. Böhlen, editors. AGTIVE 2003, volume 3062 of LNCS. Springer,
2004.
[RDV09]
José Rivera, Francisco Durán, and Antonio Vallecillo. A graphical approach for modeling
time-dependent behavior of DSLs. In Symposium on Visual Languages and Human-Centric
Computing (VL/HCC), pages 51–55. IEEE, 2009.
[Ren04]
Arend Rensink. The GROOVE simulator: A tool for state space generation. In Pfaltz et al.
[PNB04], pages 479–485.
[RMWL12]
Adrian Rutle, Wendy MacCaull, Hao Wang, and Yngve Lamo. A metamodelling approach to
behavioural modelling. In Proc. of BM-FA ’12, pages 5:1–5:10. ACM, 2012.
[RS99]
J. Raskin and P. Schobbens. The Logic of Event Clocks – Decidability, Complexity and
Expressiveness. JALC, 4(3):247–286, 1999.
[SBPM08]
David Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. EMF: Eclipse Modeling
Framework. Addison-Wesley, 2008.
[SE09]
Michael Soden and Hajo Eichler. Temporal extensions of OCL revisited. In Richard F. Paige,
Alan Hartman, and Arend Rensink, editors, Model Driven Architecture - Foundations and
Applications, ECMDA-FA 2009, volume 5562 of LNCS, pages 190–205. Springer, 2009.
[SR14]
A. Schürr and A. Rensink. Software and systems modeling with graph transformations.
Software and systems modeling, 13(1):171–172, 2014.
[SS14]
T. Scheffel and M. Schmitz. Three-Valued Asynchronous Distributed Runtime Verification.
In MEMOCODE, pages 52–61. IEEE, 2014.
[Tae04]
Gabriele Taentzer. AGG: A graph transformation environment for modeling and validation
of software. In Pfaltz et al. [PNB04], pages 446–453.
[TK16]
Juha-Pekka Tolvanen and Steven Kelly. Model-driven development challenges and solutions
- experiences with domain-specific modelling in industry. In Intl. Conf. on Model-Driven
Engineering and Software Development (MODELSWARD), pages 711–719, 2016.
[WHR+13]
Jon Whittle, John Hutchinson, Mark Rouncefield, Håkan Burden, and Rogardt Heldal.
Industrial adoption of model-driven engineering: Are the tools really the problem? In
MODELS, volume 8107 of LNCS, pages 1–17. Springer, 2013.
[WHR14]
Jon Whittle, John Hutchinson, and Mark Rouncefield. The state of practice in model-driven
engineering. IEEE Software, 31(3):79–85, 2014.
