Content uploaded by Mojtaba Bagherzadeh
Author content
All content in this area was uploaded by Mojtaba Bagherzadeh on Aug 13, 2019
Content may be subject to copyright.
PMExec: An Execution Engine of Partial UML-RT
Models
Mojtaba Bagherzadeh
Queen’s University
mojtaba@cs.queensu.ca
Karim Jahed
Queen’s University
jahed@cs.queensu.ca
Nafiseh Kahani
Queen’s University
kahani@cs.queensu.ca
Juergen Dingel
Queen’s University
dingel@cs.queensu.ca
Abstract—This paper presents PMExec, a tool that supports
the execution of partial UML-RT models. To this end, the
tool implements the following steps: static analysis,automatic
refinement, and input-driven execution. The static analysis that
respects the execution semantics of UML-RT models is used
to detect problematic model elements, i.e., elements that cause
problems during execution due to the partiality. Then, the models
are refined automatically using model transformation techniques,
which mostly add decision points where missing information can
be supplied. Third, the refined models are executed, and when the
execution reaches the decision points, input required to continue
the execution is obtained either interactively or from a script that
captures how to deal with partial elements. We have evaluated
PMExec using several use-cases that show that the static analysis,
refinement, and application of user input can be carried out with
reasonable performance, and that the overhead of approach is
manageable. https://youtu.be/BRKsselcMnc
Note: Interested readers can refer to [1] for a through discussion
and evaluation of this work.
I. INTRODUCTION
The typically iterative and incremental nature of software
development implies that many development artifacts are in-
complete until later stages of development. Unfortunately, this
partiality often prevents useful analyses that would allow the
detection of design flaws and bugs early in the development
process, when they are easiest to fix [2]. We present an
approach and supporting tool that addresses this problem in
the context of Model-driven Development (MDD). Our tool
allows the execution and debugging of partial models thus
facilitating early detection and correction of flaws. Moreover,
the tool helps dealing with large models by encouraging unit
testing and speculative model exploration through ’what if?’
analyses. Also, similar to proposals to program synthesis via
sketching [3], the approach can be used to ‘auto-complete’ a
partial model. Existing work on dealing with partial models at
design time allows for the specification, analysis, verification,
and transformation of partial models (e.g., [4]). However, to
the best of our knowledge, no work has addressed the execu-
tion (through interpretation of models or code generation) of
partial models.
We propose a conceptual framework for the execution of
partial models, which consists of three steps: static analysis,
automatic refinement, and input-driven execution. First, a static
analysis that respects the execution semantics of models is
applied, which detects problematic elements that may prevent
the execution from progressing or make certain states unreach-
able. Second, to make the partial models executable, model-to-
model (M2M) transformations [5] are used to refine the models
automatically by adding decision points where the elements
are missing. Third, during the execution these decision points
allow users to interactively (1) inspect and modify the system
using debugging services, and (2) select one of the available
options to continue the execution. The interactive execution
requires manual intervention, which can be tedious and time-
consuming. To mitigate this problem, our approach includes a
scripting language that captures user input as execution rules
which can be applied automatically during execution, without
having to stop the execution and interact with users.
This work presents PMExec, a tool that implements our
framework and supports the execution of partial UML-RT [6]
(i.e., a language for modeling of soft real-time systems) mod-
els. To maximize the impact of our work, our implementation
is publicly available [7], and only uses open source tools,
including the Papyrus-RT MDD tool for modelling and code
generation, the Epsilon [8] tools for model transformation,
and the MDebugger tool to provide debugging services [9],
[10]. We have evaluated PMExec using several use-cases that
show that the static analysis, refinement, and handling of user
input are performed with reasonable performance, and that
the overhead of approach, which is caused by increasing the
complexity of models by the refinement, is manageable.
II. BACKGROU ND
A. UML for Real-Time
UML for Real-Time (UML-RT) [6], [11] is a modeling
language for designing Real-Time Embedded (RTE) systems
with soft real-time constraints. It has been the basis of a lot
of academic work, industrial projects, and successful tools
(e.g., IBM RSA-RTE, HCL RTist, Eclipse eTrice, and Papyrus-
RT [12]). In UML-RT, a system is designed as a set of
interacting capsules. A capsule is an active object which has
attributes,operations,ports, and a behaviour modelled by
means of a hierarchical state machine [6]. A protocol defines
the different incoming and outgoing messages a capsule can
receive or send through its ports. A port is the sole interface
for the communication between the capsules which guarantees
high encapsulation. Ports of two capsules can be connected
through connectors only if they are typed with the same
protocol. A port can be conjugated in which the direction of
messages is reversed.
Controller StopLight
Driver
UserConsole
StopLightP: Protocol
red()
green()
yellow()
blink
ControlP: Protocol
blink()
off()
on()
trigger[guard]/
actioncode
transition
base port
conjugate port
Notations
typed
Figure 1: Structure model of a simplified traffic light in UML-
RT
A UML-RT State Machine (USM) consists of several states
connected with transitions. States can be of three kinds: basic
states, composite states (containing sub-states), and pseudo-
states (e.g., initial pseudo-state, choice point). A basic or
composite state can have entry and exit actions that are
executed when the state is entered or left, respectively. A
transition connects a source state to a target state. It may
contain a triggering event, a guard, and an effect. A transition
is taken when the triggering event is fired and the guard
evaluates to true. When it is taken, the code representing the
transition action, is executed.
B. Running Example
We use the control system of a simple traffic light as a run-
ning example. The top-level structure of the system is shown
in Figure 1, which consists of three capsules: UserConsole
(UC), Controller (CTR), and StopLightDriver (SLD). The CTR
is connected to UC and SLD using two ports, which are typed
by interfaces ControlP and StopLightP accordingly. The UC
component collects user input, which it passes on to the CTR
component, the component controlling the light. Using the
corresponding messages, the UC component sends the control
actions, to the SLD component which transfers the messages
through a hardware port to the traffic light. The behaviour of
CTR is shown in part 1of the Fig. 2, which is intentionally
left incomplete to demonstrate features of PMExec.
III. A CONCEPTUAL FRA ME WO RK A ND I TS AP PL IC ATIO N
TO UML-RT
The following figure shows our conceptual framework
for executing partial models, which consists of three steps
(Static Analysis,Automatic Refinement and Input-driven
Execution). In the following, we discuss the three steps and
their application to UML-RT.
Static Analysis. There are two groups of problems associated
with executing partial models: lack of progress and lack of
reachability. The former is related to situations in which
the execution cannot progress anymore. The latter captures
situations in which certain states in the statemachine are
not reachable. The result of the analysis on UML-RT w.r.t.
its execution semantics reveals these situations arise as a
consequence of the following nine types of problems:
P1: missing initial state of the USM, P2: childless composite
states, P3: broken chain, i.e., a pseudo-state has no outgoing
transitions, P4: dead state, i.e., a basic or composite state
has no triggerable transition, P5: unexpected messages, i.e.,
an incoming message that, in the current execution state,
cannot trigger any transition, P6: non-exhaustive guards of
choice-points, P7: connected components do not produce
required inputs as expected (missing inputs), P8: isolated
states, i.e., states, except for initial and history states, which
have no incoming transitions., P9: not-takeable transitions,
i.e., trigger-less transitions originating from a basic or
composite state.
Automatic Refinement. During the refinement phase the user-
defined model is refined automatically using model-to-model
transformation techniques and the results of the static analysis.
The goal of the refinement is to fix the problematic elements or
modify them in such a way (i.e., by adding decision-points)
that users can provide more information about them during
the execution. Depending on the modeling languages, certain
language constructs can be used as decision-points. In the
context of the UML-RT, we use choice-points with certain
actions and guards. The refinement of UML-RT models fixes
all problems mentioned above and allows execution of any
UML-RT model at any stage of the software development,
assuming the structure is defined and proper input is provided.
Input-driven Execution. The refined model can be executed
via interpretation or code generation. During the execution, the
executed model provides an interface for reading user input
either in interactive or batch mode.
The figure on the right shows the execution
flow of a refined UML-RT model in which
a debugging probe is hooked into the exe-
cution of the model. When the models starts
executing, a thread main and a thread probe
are started with the latter being inactive
(
---
). Thread main executes the models as
specified until it reaches a decision point
where it sends the execution context to probe
and waits for the user input. The execution
context contains relevant information concerning the execution
of the USM such as the current state of the execution and a
list of possible options to continue the execution. Thread probe
starts a debugging session (batch or interactive) that allows
users to investigate the current execution state and provide
input. At the end of the session, the user input is returned to
thread main to continue the execution.
IV. PME XE C FEATURES
In the following, we discuss the features of PMExec from
the user point of view. When it is possible, the use of features
is explained using the running example.
Setup and run: The PMExec is integrated into Papyrus-RT
as an Eclipse plug-in and can be downloaded and installed
from PMExec Repository [7]. After installation, it can be
1
2
Figure 2: User interface of PMExec
used to run partial UML-RT models simply by defining a run
configuration (i.e., Eclipse run configuration) inside Papyrus-
RT. The static analysis, transformation, code generation, build
run automatically in the background without distracting end
user. Upon successful execution, PMExec loads a UI as shown
in Figure 2 as soon as the execution requires user input to
continue the execution. The UI is split in two parts, a USM
view and a DBG console. In the USM view the user can see
the USM of the capsule where the current execution state is
highlighted. In the DBG console the user can interactively issue
commands to investigate and fix the execution problems. Basic
debugging commands (e.g., view and change variables) are
available and have been ported from MDebugger, our previous
work on model-level debugging of UML-RT models [9], [10].
Moreover, the following commands are available:
View/select options which lists the possible options to fix/-
continue the execution. E.g., the output of view options for the
CTR when its execution is stuck in state yellow is shown in
part 2of 2. Using the console, the execution can now be
steered to any of the defined states inside the USM. Command
select allows users to select one of the possible options, e.g.,
‘select state red’ steers the execution to state red.
Simple Expressions: Similar to scripting languages (e.g.,
Python interactive console), PMExec allows the user to issue
simple expressions (e.g., arithmetic expressions, define vari-
ables, and change/view the variables). This allows the user
to investigate/modify the execution before deciding how to
advance the execution. E.g., ‘x=5+1’ creates a new variable x
and sets its value to 6. Defined variables can help the user
record certain properties of the execution and define complex
debugging and testing scenarios. Once defined, they can be
used until the end of the execution.
Communication commands To allow the user to fix issues
concerning the missing inputs (P7), three communication
commands are provided: inject,send, and reply. Command
inject sends a signal to a capsule to start a debugging session,
command send sends messages on behalf of the capsule being
debugged to the connected capsules, and command reply sends
an incoming message back on the same channel it has been
received. E.g., in the context of running example, let us assume
that no behavior is defined for the UC. Thus, the execution of
the CTR will get stuck in state off and the overall execution
of the system will be locked. The user can fix the problem by
using the following communication command (1) ‘inject UC’
to start a debugging session with capsule UC. Note that the
refinement fixes the behavior of capsule even with no defined
behavior. (2) ‘send message on’ to send message on to the
CTR where it will trigger a transition to turn on the red light.
Random Execution: Support for random testing is available
through, e.g., the generation of a random message payload
(only for integer types) or the injection of a randomly chosen
input message.
Batch execution: Interactive execution stops and delays the
execution which is not suitable for some situations especially
for testing or debugging of time-sensitive systems. PMExec
supports a batch execution mode which allows users to provide
inputs using a script of execution rules. An execution rule
consists of a header and a body. The header consists of
three parts: rule name, where, and when. The where statement
identifies a component and a state and specifies on which
elements the rule can be applied. Component/state names can
be specified using ‘*’ to cover all components/states. The when
specifies a guard of the rule. A rule is applied when the current
execution context matches the where and the when evaluates to
true. The body of a rule is a sequence of debugging commands
which are executed when the rule is applied. The following
listing is an example of an execution script in the context
of the running example. The rule r1 steers the execution to
state red when a message timeout is received while in state
yellow. The rule r2 replies to any received message using a
random message and then moves the execution to a random
state. The rules with header ‘*’ are only selected when no
other rule matches in the current execution context. Note that
having only one rule similar to r2 is enough for the random
execution of any partial model using PMExec.
rule r1 where state yellow when receipt(timeout) {
select state red}
rule r2 where component *{
reply random
select state random }
V. EXPERIMENTA L EVALUATI ON
This section details experiments we conducted to assess the
performance and overhead of PMExec. In order to verify our
approach, several use cases are used. As shown in Table I,
models have different complexities that range from eight states
to more than 350 states. Model are described by Bagherzadeh
et al. [1], [9].
Experiment 1: Performance of analysis and refinement.
The static analysis and refinement are the core of our approach,
and their performance is a crucial metric for the practicality of
our approach. Thus, we conducted an experiment to measure
the time required for the analysis and transformation of
models. To effectively measure the performance of analysis
and transformation, first we used Epsilon [8] to create nine
Table I: Size of Use-cases, Transformation and Analysis Time
Model Model Comp. Ana. (ms) Tran. (ms)
C S T
Car Door Central Lock 5 11 15 925 3704
Digital Watch 9 47 57 1535 11126
Parcel Router 8 14 25 1674 5305
Rover 6 16 21 925 5001
FailOver 7 31 43 2247 10416
Debuggable FailOver 8 350 620 8454 35500
C: Component, S: State, T: Transition, Comp.: Complexity
Ana.: Analysis Time, Tran.: Transformation Time
versions of each model (partial versions), listed in Table I by
removing 10%-90% of their elements, randomly. This results
in 60 models (including the original ones). Second, we ran the
model analysis and refinements 20 times against the original
and their partial versions.
Results: The Analysis Time and Transformation Time columns
of Table I show the maximum time (worst-case) required
to analyze and transform the ten versions of each use case.
For the largest model (Debuggable FailOver), the worst-case
time of analysis and transformation are less than 10 and 40
seconds, respectively. We can conclude that the performance
of analysis and refinement is reasonable even in the worst-case
situation. Note that these operations are only performed once
for preparing the models for execution.
Experiment 2: Overhead of refinement. As discussed, the
refinement adds certain elements to fix the execution of partial
models. These new elements increase the complexity of the
models in terms of the number of components, states, and
transitions. The refined model is created temporarily before
execution and is only used for code generation. We investi-
gated the side effects of this increase. To do that, we performed
code generation 20 times on original models and their refined
versions created in Experiment 1 and recorded the execution
time of the code generation.
Result: The code generation for the refined models is only 8%
slower than the code generation for the original models, which
is calculated based on the median of time for code generation
of refined models, divided by the time for code generation of
original models.
Experiment 3: Performance of the execution in batch
mode. When executing the partial models, the execution state
of the USM is passed to the debugging probe, to read and
apply user input. In the interactive model, there is always a
delay imposed by the user, and the performance is not an
important factor. However, in the batch mode, it is essential
that the engine efficiently selects and applies the execution
rules. Thus we performed an experiment to measure the
loading/selection time of rules. To do that, we generated
10,000 rules with 100 lines of code (LOC) in the context of
the running example. We performed a test that loads the rules
in four scenarios, in which 100, 1000, 10,000 rules are used
accordingly. We recorded the loading time in each scenario.
Then, using a test program, we called the rule selection method
using a random context, and measured the rule selection times.
Result: Table II shows the required time for loading and
Table II: Required time for loading and selection of execution
rules
# of
Rules
LOC of
Rules
Loading time
(ms)
Selection time
(ms)
100 100 13 0.006
1000 100 96 0.006
10,000 100 950 0.010
selecting rules by the debugging probe. The selection time is
the median time of 1,000 rule selections. The loading of rules
occurs only once the execution of the system starts. During the
loading, the script of the execution rules is loaded and parsed.
The parsing in this phase only parses the rules’ header, and
saves their body as text. As shown in Table II the debugging
probe can load 10,000 rules in less than a second, which is
acceptable, because it happens only once and the time is on
the order order of milliseconds.
Also, the formal validation of the approach is discussed in [1].
VI. CONCLUSION
We have presented PMExec and discussed its use to execute
partial UML-RT models by providing proper input at run-time.
To the best of our knowledge, PMExec is one of the first tools
that supports the execution of partial models. The modeling
community can extend PMExec and use it for more research.
E.g., (1) exhaustive execution of partial models for testing or
run-time verification and (2) automatic completion of missing
specifications, rather than taking inputs from users.
REFERENCES
[1] M. Bagherzadeh, N. Kahani, K. Jahed, and J. Dingel, “Ex-
ecution and debugging of partial models in the context of
model-driven development,” IEEE Trans. Softw. Eng., under re-
view, preprint is available at: https://drive.google.com/file/d/1BsTQ8-
deqR1r3pbW tS3OmY DQY ZizY UF /view?usp =sharing.
[2] R. van Megen and D. B. Meyerhoff, “Costs and benefits of early
defect detection: experiences from developing client server and host
applications,” Software Quality Journal, vol. 4, no. 4, pp. 247–256.
[3] A. Solar-Lezama, R. Rabbah, R. Bodík, and K. Ebcio˘
glu, “Programming
by sketching for bit-streaming programs,” in ACM SIGPLAN Notices,
vol. 40, no. 6. ACM, 2005, pp. 281–294.
[4] M. Famelis, R. Salay, and M. Chechik, “Partial models: Towards
modeling and reasoning with uncertainty,” in Proceedings of the 34th
International Conference on Software Engineering, ser. ICSE ’12. Pis-
cataway, NJ, USA: IEEE Press, 2012, pp. 573–583.
[5] N. Kahani, M. Bagherzadeh, J. R. Cordy, J. Dingel, and D. Varró,
“Survey and classification of model transformation tools,” Software &
Systems Modeling, 2018.
[6] B. Selic, G. Gullekson, and P. T. Ward, Real-time object-oriented
modeling. John Wiley & Sons New York, 1994, vol. 2.
[7] “PMExec Repository,” https://bitbucket.org/moji1/partialmodels.git.
[8] D. S. Kolovos, R. F. Paige, and F. A. Polack, “The Epsilon transforma-
tion language,” in International Conference on Theory and Practice of
Model Transformations. Springer, 2008, pp. 46–60.
[9] M. Bagherzadeh, N. Hili, and J. Dingel, “Model-level, platform-
independent debugging in the context of the model-driven development
of real-time systems,” in Proceedings of the 2017 11th Joint Meeting on
Foundations of Software Engineering, 2017, pp. 419–430.
[10] M. Bagherzadeh, N. Hili, D. Seekatz, and J. Dingel, “Mdebugger: A
model-level debugger for UML-RT,” in Proceedings of the 40th Interna-
tional Conference on Software Engineering: Companion Proceeedings,
ser. ICSE ’18, 2018, pp. 97–100.
[11] E. Posse and J. Dingel, “An Executable Formal Semantics for UML-
RT,” Software & Systems Modeling, vol. 15, no. 1, pp. 179–217.
[12] “Papyrus for Real Time (Papyrus-RT),” https://www.eclipse.org/
papyrus-rt.