Towards Systematic and Automatic Handling of Execution Traces

Associated with Scenario-based Models

Joel Greenyer

, Daniel Gritzner

, David Harel

and Assaf Marron

Leibniz Universit

at Hannover, Hannover, Germany

The Weizmann Institute of Science, Rehovot, Israel

Keywords:

Software Engineering, System Engineering, Scenario-based Programming, Behavioral Programming, Ab-

straction, Debugging, Program Repair, Execution Trace, Event Log.

Abstract:

Scenario-based speciﬁcation approaches offer system engineering advantages with their intuitiveness, exe-

cutability, and amenability to formal veriﬁcation and synthesis. However, many engineering tasks such as

debugging or maintenance are still far from trivial even when using such speciﬁcations. Speciﬁcally, it is hard

to ﬁnd out why a complex system behaves as it does, or how it would behave under certain conditions. Here,

we present work in progress towards the (semi-)automatic analysis of event traces emanating from simulation

runs and actual executions. These traces may be large, yet developers are often interested only in speciﬁc

properties thereof, like is any speciﬁcation property violated? are particular properties demonstrated? is there

a smaller sub-sequence of events that violates or demonstrates the same properties? which trace properties

are common to multiple traces and which are unique? etc. Our approach includes automatic techniques for

discovering and distilling relevant properties of traces, analyzing properties of sets of traces, using (sets of) ex-

ecution traces for understanding speciﬁed and actual system behavior and problems therein, planning system

enhancement and repair, and more. Our work leverages and extends existing work on trace summarization,

formal methods for model analysis, speciﬁcation mining from execution traces, and others, in the context of

scenario-based speciﬁcations. A key guiding perspective for this research is that interesting properties of a

trace often can be associated with one or very few concise scenarios, depicting desired or forbidden behavior,

which are already in the speciﬁcation, or should be added to it.

1 INTRODUCTION

Execution logs of complex systems often contain

thousands if not millions of events. Depending on

the task at hand, say, debugging an apparent problem,

studying existing behavior in preparing for new de-

velopments, or making a management decision, ex-

tracting from such logs, or traces, just the relevant

items can be a difﬁcult and error-prone task. Much

work has been done on trace summarization, mining,

and more, towards simplifying and accelerating tasks

in software and system engineering (SE) that require,

or that can take advantage of, execution traces. In

this paper we extend this work by observing that the

properties that one ﬁnds relevant in a given trace, may

change depending on the task one is working on, be it

helping a customer, debugging a problem, designing a

new feature, validation and veriﬁcation, detecting cy-

ber intrusions, or, demonstrating the capabilities and

limitations of a system to new audiences. More gen-

erally, we propose to create a systematic arsenal of al-

gorithms, tools, and development methodologies for

using event traces in SE.

Consider, for example, the case of a model of a

city-wide road system, with many autonomous and

human-driven cars, and with automated trafﬁc lights

and other controls. Then, during a model-based sim-

ulation a human observer looking at a video of the

system behavior notes several near-collision situa-

tions. The system’s event trace, will likely contain

a large number of events, including of course all car

movements, trafﬁc light changes, raw and event-based

sensor data coming in from cameras, range ﬁnders

and other instruments, as well as high level abstract

ones such as cars reaching their intended destina-

tions, cars having negotiated busy intersections suc-

cessfully, and, sudden queues having been handled

successfully. However, in analyzing each of the near-

collision situations, especially for the ﬁrst time, one

has to ﬁlter out the vast majority of the events in the

trace. Moreover, a human may be able to describe

the relevant portion of the video, or the trace, which

may still be quite large, with very few terms and im-

plicit abstractions, such as: “car C

stopped abruptly

because bicycle B

was quite fast, and was about to

cross in front of C

without slowing down; and, car C

560

Greenyer, J., Gritzner, D., Harel, D. and Marron, A.

Towards Systematic and Automatic Handling of Execution Traces Associated with Scenario-based Models.

DOI: 10.5220/0006671105600566

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 560-566

ISBN: 978-989-758-283-7

driving behind C

was barely able to brake in time and

nearly collided with C

; further, not only did C

not

keep a safe distance at that moment, but it has been

driving aggressively for some time now; this is inter-

esting because car C

seems to be autonomous...”.

Our context is the scenario-based programming

approach (SBP), in which models and even ﬁnal sys-

tems can be developed from components representing

different aspects of desired and undesired system be-

havior. Here, our goal is to assist engineers working

on development, debugging or maintenance of SBP

models by automating the handling of simulation and

execution traces, speciﬁcally, the extraction, and sub-

sequent use of succinct sub-traces and relevant ab-

stractions thereof.

In Section 2 we ﬁrst present a small running exam-

ple to be used as context for the rest of the paper; in

Section 3 we introduce scenario-based modeling and

programming; in Section 4 we discuss existing rele-

vant research and tools; in Section 5, via a few ex-

amples and preliminary results, we elaborate on the

desired capabilities of the proposed tools and meth-

ods; and, in Section 6 we conclude with a discussion

of the results and of the next steps in this research.

2 A RUNNING EXAMPLE

As a running example we use an advanced driver-

assistance system using automated car-to-x commu-

nication to replace classic trafﬁc control mechanisms

such as trafﬁc lights, towards safer and more efﬁcient

trafﬁc ﬂow. Fig. 1 shows an example situation in such

a system as well as a scenario that would appear in

a scenario-based speciﬁcation or model of that sys-

tem. Roadworks block one lane of a two-lane road.

Cars approach on either lane and need to communi-

cate with the obstacle’s controller in order to know

what signal (either Go or Stop) to show to their driver

on their dashboards. An example scenario from the

system’s speciﬁcation could be that: (1) when a car’s

sensors register an obstacle coming up ahead (2) the

car’s driver must be shown a Go or a Stop signal (3)

before the car actually reaches the obstacle.

Even experienced engineers usually need many it-

erations until a speciﬁcation is feature-complete and

defect-free. Understanding the behavior induced by

a speciﬁcation, including an intuitive scenario-based

one, is difﬁcult. Simple mistakes, e.g., forgetting to

specify the assumption that drivers obey the signals

on the dashboard, can lead to formal methods report-

ing that violations, e.g., car collisions, are still possi-

ble despite the expected outcome being different.

approaching

obstacle on narrow

passage lane

obstacle control

approaching an obstacle

on the blocked lane

show stop

or go

before

obstacle is

reached

Scenario “Dashboard of the car approaching on

the blocked lane shows STOP or GO”

approaching

obstacle on

blocked lane

Figure 1: Car-to-X example overview.

3 SCENARIO-BASED MODELING

Scenario-based Modeling (and Programming), also

termed behavioral programming, offers an intuitive

approach for writing formal speciﬁcations. Short sce-

narios specify sequences of events that involve mul-

tiple objects and that deﬁne how objects/components

may, must, or must not behave. A collection of these

scenarios is a speciﬁcation which, through the inter-

play of the contained scenarios, deﬁnes the overall

behavior of an entire system. Visual and textual for-

malisms and languages for writing scenarios include

Live Sequence Charts (LSCs) (Damm and Harel,

2001; Harel and Marelly, 2003), the Scenario Model-

ing Language (SML) (Greenyer et al., 2015; Greenyer

et al., 2016; Gritzner and Greenyer, 2017), and be-

havioral programming in general-purpose procedural

languages like C++ or Java (Harel et al., 2012). Fig. 2

shows an LSC of the scenario depicted in Fig. 1.

Key to the scenario-based approach is that execu-

tion of the speciﬁcation can be done intuitively using

play-out, namely concurrent execution of all scenar-

ios, while complying with the constraints and possi-

bilities deﬁned by the entire speciﬁcation and yielding

cohesive system behavior. Another execution method

is by synthesizing a composite automaton that reﬂects

the desired behavior of the system under all environ-

ment behaviors; in fact, this synthesis can be seen

as creating a strategy that guides event selection dur-

ing play-out. Yet another approach is execution with

lookahead, termed smart play-out, where the event se-

lection is subject to run-time assessment of all possi-

ble upcoming execution paths, to some limited depth

or horizon.

Scenarios consist of events, representing system

Towards Systematic and Automatic Handling of Execution Traces Associated with Scenario-based Models

561

:Sensor :Car

approachingObstacle

showGo

:Dashboard

alt

showStop

obstacleReached

Figure 2: LSC1: The dashboard of car approaching the

obstacle must display either “go” or “stop” before the car

reaches the obstacle.

:Sensor :Car

approachingObstacle

:ObstacleCtrl

alt

disallowPassage

allowPassage

:Dashboard

showGo

showStop

Figure 3: LSC2: A car approaching an obstacle must ﬁrst

board.

or environment actions. Scenarios deﬁne a partial or-

der of events and modalities encoding what events

may, must, or must not occur in each system state. An

event may be requested, waited for, or blocked. Dur-

ing play-out, at each state, an event that is requested

by some scenario and is not blocked by any scenario is

selected for triggering. All scenarios either requesting

or waiting for this event are notiﬁed and can change

their state and optionally change their declarations of

requested, blocked, and waited-for events.

Playing-out the scenarios in Figures 2 and 3, after

the event approachingObstacle both LSCs are active,

but the dashboard events showGo and showStop are

blocked due to the order enforced by LSC2. Thus,

stacle controller’s reply, the car will then update its

dashboard appropriately. If a car is able to reach the

obstacle before the dashboard shows either Go or Stop

the speciﬁcation is violated.

The amenability of SBP speciﬁcations to incre-

mental reﬁnement is accompanied by their often be-

ing under-speciﬁed and non-deterministic: depending

on the speciﬁcation, multiple events may be candi-

dates in a given state some of which may be undesir-

able or even lead to violations. The opposite, not all

desirable events are enabled in a given state, may also

be true. These situations are indicators for missing

features or defects and are vital for engineers to no-

tice and to understand their cause. However, ﬁnding

and reasoning about such situations is often difﬁcult,

especially in large systems.

4 RELATED WORK

Below we give brief examples of the kind of existing

research that can be applied ad-hoc in the use of exe-

cution traces in the desired SE activities. In Section 5

we explain how our contribution aims to extend these

capabilities.

Acting Upon Emergent Properties. Much of the

development process, and in particular in agile, incre-

mental methodologies, revolve around observing de-

sired and undesired properties in an existing model,

and reﬁning the speciﬁcation accordingly. Return-

ing to the example in the city-wide trafﬁc automation

in the introduction, clearly the human intuition that

not only collisions are violations, but near-collisions

should be reported and analyzed should be manifested

as part of the speciﬁcation. External sensors, as well

as programmed analysis of known and predicted car

movements can be used to alert about such risky con-

ditions. The speciﬁcation should then be enhanced

with scenarios that forbid such events from occur-

ring. At run time, these will thus be automatically

avoided where possible, and when they nevertheless

occur, a violation will be reported. The detection of

near-collisions in general traces (depending on ve-

locities and locations) can be speciﬁed by engineers

and regulators, or can be automatically inferred using

machine learning techniques. In (Harel et al., 2016)

the authors present an automated approach for detect-

ing emergent properties in sets of execution traces of

scenario-based models, and allowing the programmer

to determine if they are desired (perhaps so that they

should be formally proven), or undesired, in which

case the speciﬁcation should be repaired (manually or

automatically).

Trace Summarization and Analysis. A large va-

riety of techniques for summarizing and abstracting

execution traces, especially logs of method calls, has

been researched. E.g., in (Hamou-Lhadj and Leth-

bridge, 2006) the authors present a technique to iden-

tify low importance utility method calls by a fan-

in/fan-out metric. In (Braun et al., 2015) execution

traces are used to automatically generate system doc-

umentation via use case maps. The authors describe

eight algorithms (some emerging from prior works on

the topic) for assigning relevance or importance of

methods calls. These algorithms look at call patterns,

method size, etc. In other papers, such as (Noda et al.,

2017), ﬁltering of events is based on pre-designated or

inferred importance of the events themselves or of the

objects involved.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

562

While the structured data of a trace can be pro-

cessed using many classical techniques, including

storing in databases and subjecting the information

to database queries, another approach (Bertero et al.,

2017), treats the log data as free text and applies natu-

ral language processing techniques to summarize the

raw data and distill relevant properties thereof.

Causality Analysis. In the present context of SBP

we relate to causality, especially that of undesired

events, as the sequence of events preceding the unde-

sired one, where each one could occur only after one

of several explicitly-speciﬁed events have occurred

(triggered either by the system or the environment).

This chain of events can be readily examined in a

trace in which the states of all scenarios is known in

addition to the identity of the events that occurred.

Automated tools for problem detection (and repair)

analyze traces that violate the speciﬁcation or cause

a crash. The tools then attempt to detect the unex-

pected environment event, or the undesired system

decision that are the root cause for the violation, and

the sequence of events leading from that root cause to

the observed failure. The traces containing the prob-

lem may emanate from, e.g., execution failures (in

the ﬁeld or during testing) (Weimer et al., 2010), and

from counterexamples generated by formal veriﬁca-

tion (Clarke et al., 2003). In incremental SBP devel-

opment, when an added speciﬁcation scenario reﬂect-

ing a valid user requirement, causes the speciﬁcation

to become non-realizable, the engineers then search

for the unrealizable core of the speciﬁcation. In this

context the new scenario can be viewed both as part

of the speciﬁcation and as test run that violates it.

5 PROPOSED METHOD AND

PRELIMINARY RESULTS

The methodology we are developing for working with

execution traces should contain the following ele-

ments:

Working with Sets of Traces. Developers com-

monly work with one trace at a time. The methods we

propose enhance this kind of work, but also augment

it with tools for working with sets of traces, adding

to the considerations the analysis of common features

and of behaviors that are unique to certain traces. As

for generating these sets, naturally, many interesting

execution traces come from test runs, especially failed

ones, and from problem reports. To these we sug-

gest to add at least two variations: (a) collection of

traces emanating from random (possibly parameter-

ized) runs (see, e.g. (Harel et al., 2016)), and (b) dur-

ing model checking, do not sufﬁce with a single coun-

terexample run that violates the speciﬁcation or man-

ifests some desired behavior, but instead collect all

such paths in the model’s state graph (or a manage-

able subset thereof). In our current experiments we

have enhanced one of the SBP synthesis algorithms

to generate and collect all such paths.

Enhanced Traces. Whether in the development lab

or in the ﬁeld, we propose that classical event traces

be augmented. In our experiments, we enhanced the

classical trace of states labels and transition events

with an extensive snapshot including: a list of active

scenarios (ideally, this would include their respective

local states), the enabled events (metaphorically, the

‘roads not chosen’, at any given state) and, selected

objects (e.g., cars) and their states (i.e., property val-

ues). While such traces can become unwieldy in

large systems, we observe and propose that extensive

logging can be a game-changer in system real time

adaptivity a SE in general (see also (Marron, 2017)),

and developing fast automated ofﬂine and run-time

techniques for compressing and ﬁltering such traces

would be an important enabler.

Ad-hoc Tool Validation. While SBP offers advan-

tages in incremental development, our preliminary

experiments show that it is also advantageous in doing

the opposite: incremental removal of features, or iso-

lated insertion of well-speciﬁed undesired behaviors.

In the car-to-x SBP model described in Section 2 we

have experimentally modiﬁed (or have removed alto-

gether) individual speciﬁcation scenarios (both indi-

vidually and several together), and checked whether

the proposed techniques can help identify the root

cause of problems. We propose that when analyzing

the root cause of a particular behavior (e.g., a hard-to-

solve, hard-to-recreate customer-reported problem),

we also modify the speciﬁcation intentionally to gen-

erate similar external symptoms, and keep enhancing

our tools until they are able to automatically detect

the new known (synthetic) root cause. Then, we can

more safely apply the same tools to the traces from the

customer problem at hand. Speciﬁcally, in our exper-

iments we have modiﬁed the speciﬁcation as follows:

1. We changed an obstacle controller scenario to

have an ”off-by-one” error - where when only one

car is passing in the narrow area, cars arriving

from the other direction are not signaled to stop.

When two or more cars occupy the narrow area,

the signal works correctly.

Towards Systematic and Automatic Handling of Execution Traces Associated with Scenario-based Models

563

2. We removed the (often forgotten) environment as-

sumption that drivers obey the stop/go signal on

their dashboard. In fact we experimented with af-

fecting one, two, or all drivers in this manner.

3. We omitted the scenario that as soon as the narrow

area becomes free allows the passing of cars that

were previously told to wait.

A Rich, Dynamic and Open Trace-processing API.

In our experiments we externalized to end-users and

to higher-level scripts a rich and growing library of ﬁl-

tering and validation functions. The trace-processing

tools should allow engineer to readily incorporate any

heuristics they develop, as a method to be readily ac-

cessible in all future analyses, for the entire commu-

nity. For example,our proof-of-concept APIs include,

among others:

• extracting (from a set of traces) all those with

safety violations, and all those exhibiting liveness

‘violation’ within the trace, as well as the respec-

tive violated scenarios

• ﬁnding properties that are common to sets of

traces or sub-traces, by computing their intersec-

tion; additionally, compute the complements of

such sets, in search for properties that are unique

to individual traces or to particular (sub)sets of

traces

• ﬁltering sets of traces according to trace properties

• ﬁltering a trace according to entry properties

• a variety of queries on trace data

• trace transformation, especially according to

speciﬁcation properties

• ﬁnding a ﬁrst or a last entry with a particular prop-

erty in a trace, and

• quantitative analysis (e.g., producing histograms)

of trace properties (within a set of traces) and of

entry properties (within a trace or set of traces).

For example in our analysis of the set of traces

with all three defects, the initial set of traces occu-

pied 78MB. It contained about 5000 traces of about

20 events each. Clearly one or few of these small

traces could have been analyzed manually using tra-

ditional techniques, but in our initial experimentation

(to be elaborated in future work) we were able to

program the following automated analysis of the en-

tire set as follows: we extracted all traces that lead

to a safety violation of the speciﬁcation; we create

a list of all events which trigger a violation. We

(manually for now) observed in this list that viola-

tions occur upon the event of a car reaching the ob-

stacle or the event of a car passing the obstacle. We

used this observation to narrow our set of traces to all

those in which the event carB1.ObstacleReached

is the cause of a violation. (such choice can em-

anate from, say, a customer complaint — that after

certain actions certain undesired conditions emerged).

This yielded 670 traces, all with the same violated

scenario, the one with the self-explanatory name

of CarReceivesAnswerBeforeReachingObstacle.

Checking a failed trace against this scenario we see

that the above event occurred out of order and the ex-

pected event (of reaching the obstacle) has not arrived

yet at that point. Checking all scenarios which can

emit this event yielded (in this case) just a single one,

and ﬁnding the bug in this small scenario was then

straightforward. Again, while some of these steps are

similar to classical debugging, one should note that

some of the answers apply to a multitude of test runs

and not just one, providing a greater generality to the

analysis and to the proposed solution.

It should be noted that intersection of traces refers

to event sequences and not just to event sets. Con-

sider our analysis of the second defect we injected.

This defect caused car collision in the narrow passage

next to the obstacle to occur. As the intersection of

violating traces we obtained the following sub-trace

(shown here in text, with the sending and receiving

lifelines and the event method name):

env -> carA1.approachingObstacle()

carA1 -> obstacle.register()

env -> carB1.approachingObstacle()

carB1 -> obstacle.register()

env -> carA1.passingObstacle()

env -> carB1.passingObstacle()

and two kinds of complements of the intersection,

namely six traces containing

obstacle -> carA1.allowPassage() // may pass

obstacle -> carB1.disallowPassage() // must wait

and four traces containing

obstacle -> carB1.allowPassage()

obstacle -> carA1.disallowPassage()

Which suggested that indeed the drivers were not

obeying the signals.

The analysis of the liveness violation in the third

injected defect highlights the role of object data. Af-

ter several ﬁltering operations similar to the above,

we observe that the last event received (earlier) by

carB1 is carB1.disallowPassage(), and that no

allowPassage() was sent to it, despite all cars that

drive in the opposite direction being conspicuously

past the narrow area (e.g., the location of carA1 is

BehindObstacle).

Quantitative analysis showed its value as well.

While we knew what we were looking for, it was still

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

564

interesting to see certain suspicious pairs or triples

of events occurring, in this order, but not necessarily

purely consecutively, in large numbers of problematic

traces. E.g., in traces where collisions occurred due

to the second defect, the pair

obstacle->carB1.allowPassage();

env->carB1.passingObstacle()

and the triple

obstacle->carB1.disallowPassage();

env->carB1.obstacleReached();

env->carB1.passingObstacle()

occur thousands of times, indicating that carB1 may

not be obeying the signal sent to it.

Support for Demonstrating Relevant Properties.

We propose to give a particular emphasis to demon-

strating desired properties in speciﬁcations and sets

of traces. Consider for example the requirement that

the obstacle signal approaching cars to wait whenever

there are other cars in the opposite direction occupy-

ing the narrow area. Of course, a single test would be

a nice, but insufﬁcient demonstration. A straightfor-

ward formal veriﬁcation of this speciﬁcation property

may be misleading, e.g., if due to other modeling er-

rors it turns out that cars rarely, or even never arrive

at the obstacle from opposite directions at the same

time. Results indicating that the following triples oc-

curred thousands of times, repeatedly, and in distinct

traces

obstacle->carA1.allowPassage();

env->carB1.obstacleReached();

obstacle->carB1.disallowPassage()

indeed contributes substantially to demonstrating the

desired property. This also serves as a reminder that

a particular trace or set thereof may possess multiple

relevant properties, and engineers may be interested

in different properties at different times. E.g., during

our analysis of collisions in pursuing the second de-

fect, the automated trace analysis informed us (with-

out us asking explicitly) that the obstacle sent the re-

quired signals correctly in all possible runs.

6 DISCUSSION AND FUTURE

WORK

We have presented our direction towards a systematic

approach for management, summarization, analysis

and querying of large sets of large execution traces of

SBP models, and have shown preliminary results how

such tools can accelerate causal analysis, debugging

and maintenance.

A more systematic evaluation of the advantages of

such tools over manual techniques can motivate and

guide the particular areas that should be further de-

veloped.

For example, the approach can be enhanced via

richer queries on traces, scenarios and system states.

E.g., “what are the scenarios which request other en-

abled events when event E1 was selected (in traces

in the current set), and were these event requests ever

granted, or did the scenarios transition out of that state

due to other events that occurred?”.

In particular we would be interested in causality

queries, such “starting with a violation, ﬁnd the se-

quence of events that directly caused the triggering of

the last event”. In other words, going backwards, for

each triggered system event, what are all the scenar-

ios that requested it at that state (system cut); what

was the preceding event in each of these scenarios;

and then, repeat the process for each of these events.

In fact, this should be augmented with researching the

events that were blocked in those states, and how the

scenarios that blocked them have reached those par-

ticular states. While this chain of analysis may be

large, recall that it ﬁlters out all the events that are

not in this causal chain, and are merely the result of

parallel processes.

One can automate certain aspects of liveness prop-

erty analysis in traces, based on the fact that scenar-

ios distinguish events that must happen from those

that ‘just’ may happen, at a given state in a scenario.

Hence the speciﬁcation and traces can guide the dis-

covery of situations where scenarios wait for an ex-

tended period of time for events that were marked as

must happen, as well as the causality chains which

may have been broken.

Another area of intriguing research opportunity is

automating (or, at least, methodologically prescrib-

ing) the steps in the method that presently depend on

human decision and intuition.

The enrichment of the log with object data can

help analyze complex problems. For example, it

seems that only a few additional details, like time and

certain car properties, and a small amount of domain

knowledge (to be captured as additional assumption

scenarios), should be needed in further automating

the analysis of near-collisions described in Section 1.

We would expect the computer to be be able to reach

complex observations like: (i) “Car C

was actually

an ambulance on an emergency call with a siren and

lights on” (hence its driving aggressively may be ac-

ceptable); (ii) “the event of car C

pulling over to the

side to make way for C

is missing”; and (iii) “C

is not at fault as the ambulance has just turned into

the street in which C

was driving and there was not

enough time for C

to pull over before the bicycle

crossed its path.”.

Towards Systematic and Automatic Handling of Execution Traces Associated with Scenario-based Models

565

Another dimension in which this work should be

extended is to create generalized behavioral sum-

maries which transcend speciﬁcation scenarios and

individual trace summaries. E.g. we would like to

ﬁnd a formal, concise representation for SE knowl-

edge as contained in natural language sentences like:

“presently, always, (as opposed to ‘it happened once’)

when the user presses the green button the buzzer

sounds, but instead, the green light should go on”,

or “the user could not complete his desired action of

pressing buttons B1, B2, B3, B4 in this order, be-

cause, always after one presses button B2, button B3

is disabled”. Such formalization capabilities would

enable deeper analysis and perhaps streamline the

automation and complex development tasks such as

feature analysis, problem determination, and profes-

sional interaction with customers.

ACKNOWLEDGEMENTS

This work has been funded in part by grants from the

German-Israeli Foundation for Scientiﬁc Research

and Development (GIF) and from the Israel Science

Foundation (ISF).

REFERENCES

Bertero, C., Roy, M., Sauvanaud, C., and Tr

edan, G. (2017).

Experience Report: Log Mining using Natural Lan-

guage Processing and Application to Anomaly Detec-

tion. In 28th International Symposium on Software

Reliability Engineering (ISSRE).

Braun, E., Amyot, D., and Lethbridge, T. (2015). Generat-

ing Software Documentation in Use Case Maps from

Filtered Execution Traces. In International SDL Fo-

rum, pages 177–192. Springer.

Clarke, E., Grumberg, O., Jha, S., Lu, Y., and Veith, H.

(2003). Counterexample-guided abstraction reﬁne-

ment for symbolic model checking. Journal of the

ACM (JACM), 50(5):752–794.

Damm, W. and Harel, D. (2001). LSCs: Breathing life into

message sequence charts. In Formal Methods in Sys-

tem Design, volume 19, pages 45–80.

Greenyer, J., Gritzner, D., Gutjahr, T., Duente, T., Dulle,

S., Deppe, F.-D., Glade, N., Hilbich, M., Koenig, F.,

Luennemann, J., Prenner, N., Raetz, K., Schnelle, T.,

Singer, M., Tempelmeier, N., and Voges, R. (2015).

Scenarios@run.time – Distributed Execution of Spec-

iﬁcations on IoT-Connected Robots. In 10th Int. Work-

shop on Models@Run.Time (MRT), co-located with

MODELS 2015, CEUR Workshop Proceedings.

Greenyer, J., Gritzner, D., Katz, G., and Marron, A. (2016).

Scenario-Based Modeling and Synthesis for Reactive

Systems with Dynamic System Structure in Scenari-

oTools. In Proceedings of the MoDELS 2016 Demo

and Poster Sessions, co-located with ACM/IEEE 19th

International Conference on Model Driven Engineer-

ing Languages and Systems (MoDELS). CEUR.

Gritzner, D. and Greenyer, J. (2017). Controller Synthe-

sis and PCL Code Generation from Scenario-based

GR(1) Robot Speciﬁcations. In Proceedings of the

4th Workshop on Model-Driven Robot Software En-

gineering (MORSE 2017), co-located with Software

Technologies: Applications and Foundations (STAF).

Hamou-Lhadj, A. and Lethbridge, T. (2006). Summarizing

the content of large traces to facilitate the understand-

ing of the behaviour of a software system. In 14th

IEEE International Conference on Program Compre-

hension (ICPC), pages 181–190. IEEE.

Harel, D., Katz, G., Marelly, R., and Marron, A. (2016).

An Initial Wise Development Environment for Behav-

ioral Models. In Proc. 4th Int. Conf. on Model-Driven

Engineering and Software Development (MODEL-

SWARD), pages 600–612.

Harel, D. and Marelly, R. (2003). Come, Let’s Play:

Scenario-Based Programming Using LSCs and the

Play-Engine. Springer.

Harel, D., Marron, A., and Weiss, G. (2012). Behavioral

Programming. Comm. of the ACM, 55(7).

Marron, A. (2017). A Reactive Speciﬁcation Formalism for

Enhancing System Development, Analysis and Adap-

tivity. In 15th ACM-IEEE International Conference

on Formal Methods and Models for System Design

(MEMCODE).

Noda, K., Kobayashi, T., Toda, T., and Atsumi, N.

(2017). Identifying Core Objects for Trace Summa-

rization Using Reference Relations and Access Anal-

ysis. In Computer Software and Applications Confer-

ence (COMPSAC), 2017 IEEE 41st Annual. IEEE.

Weimer, W., Forrest, S., Le Goues, C., and Nguyen,

T. (2010). Automatic program repair with evolu-

tionary computation. Communications of the ACM,

53(5):109–116.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

566