Empowering Multilevel DSMLs with Integrated Runtime Verification

05/22/2020
by   Fernando Macías, et al.
0

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.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

10/08/2019

Multilevel Modelling and Domain-Specific Languages

Modern software engineering deals with demanding problems that yield lar...
09/29/2021

From Organisational Structure to Organisational Behaviour Formalisation

To understand how an organisational structure relates to organisational ...
10/15/2021

Simulation of emergence in artificial societies: a practical model-based approach with the EB-DEVS formalism

Modelling and simulation of complex systems is key to exploring and unde...
09/27/2018

Multi-Scale Verification of Distributed Synchronisation

Algorithms for the synchronisation of clocks across networks are both co...
11/26/2020

MIMOS: A Deterministic Model for the Design and Update of Real-Time Systems

Inspired by the pioneering work of Gilles Kahn on concurrent systems, we...
04/24/2018

Developing Theoretical Foundations for Runtime Enforcement

The ubiquitous reliance on software systems increases the need for ensur...
01/17/2019

Multilevel Coupled Model Transformations for Precise and Reusable Definition of Model Behaviour

The use of Domain-Specific Languages (DSLs) is a promising field for the...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

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., [WHR13, WHR14, BHW14, MGS13, 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, MFM08, 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 DSMM is already practiced in industry and academia and its positive results are documented in the literature [WHR14, BHW14, MGS13]. 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 of the system under scrutiny. Such an execution trace is represented as a discrete sequence of execution states, i.e. a finite word . In every state, every atomic proposition of the finite set is either true or false, i.e. . 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. for a time domain . 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 be the set of atomic propositions which are evaluated either to or in every event. Then is a finite event sequence over the alphabet with time domain . For such a word we denote with the suffix starting with event . The syntax of TLTL formulas is given by the following grammar for and with : . For formulas and and a word , the semantics for a TLTL formula is given inductively as a relation between words and the formulas they fulfil:

Additional LTL operators can be added as syntactic sugar, e.g. through the following equivalences: , , , , , . The syntax and semantics can easily be extended to allow through exchanging and .

Monitoring TLTL To evaluate a word against a TLTL formula a step-wise monitoring function is used. 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. 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 for the output verdicts, where and represent final verdicts and and represent current verdicts up to now, which might change with new events arriving [Leu11]. Because is a lattice it provides the operators meet , join and complement as generalization of the boolean operators and , or and not, e.g. , and .

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 represents the formula being evaluated on agent . 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.

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.

Figure 1: Robolang MLM hierarchy for definition of robot behaviour

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 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 [MRS18]. 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.

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, [MRS18]) 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 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 Fig. 1, and an explanation of their semantics. For simplicity, instead of the blue ellipses we use E:T to indicate that an element E has 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.

images/robolang-mcmt-fire-transition-with-input

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.

images/robolang-mcmt-fire-transition-with-message-guard

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 transition 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. 6) 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.

[scale=0.7]images/robolang-mcmt-insert-input
Figure 5: MCMT Insert Input
[scale=0.7]images/robolang-mcmt-insert-effective-input
Figure 6: MCMT Insert Effective Input

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 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. 6.

[scale=0.7]images/robolang-mcmt-receive-message

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.

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 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 .

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.

[width=.7825]images/example-execution

Figure 8: Example of simulation with the resulting snapshots
Figure 9: Example of evaluation of a distributed, timed LTL property

Now we can interpret a snapshot sequence as word : For a TLTL formula we have a word for every agent by having for the -th snapshot that has an active mark in such that contains all propositions, whose linked model fragments are present in the snapshot, and is 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

[scale=.53]images/ltl-mcmt-delete-weak-next

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 in the root of the expression. 2 As long as there is a boolean operator having , remove from it and set to all of its children.

Now all the outermost temporal operators and atomic propositions are marked with . Next we apply unrolling operations for the marked temporal operators: 3 For every temporal operator having , 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 . 4 Update all with 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 . Next the prophecies and atomic propositions must be evaluated: 5 Replace every atomic proposition having with or , depending on whether we find a match of the atomic proposition in the current snapshot. 6 For every having , replace it with or according to the monitoring function described in Section 2. If it remains unchanged, remove . 7 Replace every having with . These rules then remove 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 by , by , and by , and by . All subformulas from these operators are removed, leaving the tree just with values from and boolean operators. 9 Apply operations on to the resulting tree until the whole tree collapses to a single value, 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 are performed in a different branch of execution, and therefore represented as filled circles: 8 For every and having , they get replaced with their subtree . 9 Apply boolean simplifications to any feasible match found throughout the tree, e.g. . 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 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 [CHM02, 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 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.
  • [CHM02] 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: 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.
  • [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.
  • [MFM08] 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.
  • [MGS13] 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.
  • [MRS18] 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.
  • [WHR13] 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.