Conference PaperPDF Available

# PMExec: An Execution Engine of Partial UML-RT Models

Authors:

## 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.
PMExec: An Execution Engine of Partial UML-RT
Models
Queen’s University
mojtaba@cs.queensu.ca
Karim Jahed
Queen’s University
jahed@cs.queensu.ca
Naﬁseh 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
reﬁnement, 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 reﬁned automatically using model transformation techniques,
which mostly add decision points where missing information can
be supplied. Third, the reﬁned 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,
reﬁnement, 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 ﬂaws and bugs early in the development
process, when they are easiest to ﬁx [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 ﬂaws. 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 speciﬁcation, analysis, veriﬁcation,
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 reﬁnement, 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 reﬁne 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, reﬁnement, 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 reﬁnement, 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 deﬁnes
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()
ControlP: Protocol
off()
on()
trigger[guard]/
actioncode
transition
base port
conjugate port
Notations
typed
Figure 1: Structure model of a simpliﬁed trafﬁc 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 ﬁred 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 trafﬁc 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 trafﬁc 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 ﬁgure shows our conceptual framework
for executing partial models, which consists of three steps
(Static Analysis,Automatic Reﬁnement 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 Reﬁnement. During the reﬁnement phase the user-
deﬁned model is reﬁned automatically using model-to-model
transformation techniques and the results of the static analysis.
The goal of the reﬁnement is to ﬁx the problematic elements or
modify them in such a way (i.e., by adding decision-points)
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 reﬁnement of UML-RT models ﬁxes
all problems mentioned above and allows execution of any
UML-RT model at any stage of the software development,
assuming the structure is deﬁned and proper input is provided.
Input-driven Execution. The reﬁned 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 ﬁgure on the right shows the execution
ﬂow of a reﬁned UML-RT model in which
a debugging probe is hooked into the exe-
cution of the model. When the models starts
are started with the latter being inactive
(
---
). Thread main executes the models as
speciﬁed 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
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 deﬁning a run
conﬁguration (i.e., Eclipse run conﬁguration) 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 ﬁx 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 ﬁx/-
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 deﬁned 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, deﬁne 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. Deﬁned variables can help the user
record certain properties of the execution and deﬁne complex
debugging and testing scenarios. Once deﬁned, they can be
used until the end of the execution.
Communication commands To allow the user to ﬁx 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 deﬁned 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 ﬁx the problem by
using the following communication command (1) ‘inject UC
to start a debugging session with capsule UC. Note that the
reﬁnement ﬁxes the behavior of capsule even with no deﬁned
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
three parts: rule name, where, and when. The where statement
identiﬁes a component and a state and speciﬁes on which
elements the rule can be applied. Component/state names can
be speciﬁed using ‘*’ to cover all components/states. The when
speciﬁes 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 *{
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 reﬁnement.
The static analysis and reﬁnement 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, ﬁrst 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 reﬁnements 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 reﬁnement 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 reﬁnement. As discussed, the
reﬁnement adds certain elements to ﬁx 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 reﬁned 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 reﬁned
versions created in Experiment 1 and recorded the execution
time of the code generation.
Result: The code generation for the reﬁned 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 reﬁned 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 efﬁciently selects and applies the execution
rules. Thus we performed an experiment to measure the
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
Then, using a test program, we called the rule selection method
using a random context, and measured the rule selection times.
rules
# of
Rules
LOC of
Rules
(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
occurs only once the execution of the system starts. During the
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 ﬁrst 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 veriﬁcation and (2) automatic completion of missing
speciﬁcations, 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/ﬁle/d/1BsTQ8-
deqR1r3pbW tS3OmY DQY ZizY UF /view?usp =sharing.
[2] R. van Megen and D. B. Meyerhoff, “Costs and beneﬁts 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 classiﬁcation 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.
... We extended our previous work on model-level debugging [13], [33] in the context of UML-RT (i.e., a language for modeling of soft real-time systems) [34], and created an execution engine of partial UML-RT models (PMExec [35]) that embodies the proposed framework. To maximize the impact of our work, our implementation is publicly available, and only uses open source tools, including the Papyrus-RT MDE tool, for modelling and code generation, and the Epsilon [36] tools for model transformation. ...
Preprint
Full-text available
The iterative and incremental nature of software development using models typically makes a model of a system incomplete (i.e., partial) until a more advanced and complete stage of development is reached. Existing model execution approaches (interpretation of models or code generation) do not support the execution of partial models. Supporting the execution of partial models at the early stages of software development allows early detection of defects, which can be fixed more easily and at a lower cost. This paper proposes 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 to detect problematic elements of models that cause problems for the execution. Second, using model transformation techniques, the models are refined automatically, mainly by adding decision points where missing information can be supplied. Third, refined models are executed, and when the execution reaches the decision points, it uses inputs obtained either interactively or by a script that captures how to deal with partial elements. We created an execution engine called PMExec for the execution of partial models of UML-RT (i.e., a modeling language for the development of soft real-time systems) that embodies our proposed framework. We evaluated PMExec based on 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, which is mostly due to the refinement and the increase in model complexity it causes, is manageable. We also discuss the properties of the refinement formally and show how the refinement preserves the original behaviors of the model.
... Such approaches seem complementary to our work but they have not yet been used for executing and analyzing models online. Last but not least, the work in [2] defines a tool called PMExec that supports the execution of Partial UML-RT models. Using static analysis, the tool adds decision points where information is missing such that the user or an automated script provides the missing data during model execution. ...
... Therefore, an ideal replay-based debugger requires providing a deterministic replay of execution traces in an efficient way. In recent years, numerous Model-Driven Development (MDD) techniques and tools have been developed to mitigate the complexity of testing and debugging systems at model-level (e.g., MDebugger [4], PMExec [5,6], mCUTE [1]). However, they merely consider nondistributed systems which typically are executed by one processing unit. ...
Conference Paper
Full-text available
In this paper, we present MReplayer that supports ordering and replaying of execution traces of distributed systems that are developed using communicated state machine models. Despite the existing solutions that require detailed traces annotated with timestamps (logical or physical), MReplayer only requires a minimum amount of traces without timestamps. Instead, it uses model analysis techniques to order and replay the traces. MReplayer is composed of a set of engines that support an end-to-end solution to trace ordering and replay of distributed systems in three steps: first, a model of a distributed system is instrumented using model transformations to generate execution traces and broadcasts the traces either using a TCP connection or a log file. Second, static analysis of state machine models is performed to extract run-to-completion steps from them. Third, using the information collected (execution traces and rc-steps) in the previous steps, a lightweight centralized version of the distributed system is created and presented to users in a web-based application. We have implemented our approach using UML for Real-time (UML-RT) which is a language specifically designed for real-time embedded systems with soft real-time constraints. Finally, we have evaluated MReplayer against several use cases with various complexities. The result shows that MReplayer can reduce the size of the trace information collected by more than half while incurring similar runtime overhead. A video that demonstrates the tool: https://youtu.be/WG5ggqPoJHg CCS
... To the best of our knowledge, our work is also the first work to leverage SMT-Solvers for the synthesis of the models. An implementation of our approach is publicly available [24], and we are hopeful that in follow-up research we can (1) improve the applicability and scalability of the model synthesis, and (2) extend our approach to support completion of incomplete (partial) SMs [60,61]. ...
Conference Paper
Full-text available
The automated synthesis of behavioural models in the form of state machines (SMs) from higher-level specifications has a high potential impact on the efficiency and accuracy of software development using models. In this paper, inspired by program synthesis techniques , we propose a model synthesis approach that takes as input a structural model of a system and its desired system properties, and automatically synthesizes executable SMs for its components. To this end, we first generate a synthesis formula for each component, consistent with the system properties, and then perform a State Space Exploration (SSE) of each component, based on its synthesis formula. The result of the SSE is saved in a Labeled Transition System (LTS), for which we then synthesize detailed actions for each of its transitions. Finally, we transform the LTSs into UML-RT (UML real-time profile) SMs, and integrate them with the original structural models. We assess the applicability, performance, and scalability of our approach using several different use cases extracted from the literature. CCS Concepts • Software and its engineering → Model-driven software engineering ;
... We extended our previous work on model-level debugging [13], [33] in the context of UML-RT (i.e., a language for modeling of soft real-time systems) [34], and created an execution engine of partial UML-RT models (PMExec [35]) that embodies the proposed framework. To maximize the impact of our work, our implementation is publicly available, and only uses open source tools, including the Papyrus-RT MDE tool, for modelling and code generation, and the Epsilon [36] tools for model transformation. ...
Article
Full-text available
The iterative and incremental nature of software development using models typically makes a model of a system incomplete (i.e., partial) until a more advanced and complete stage of development is reached. Existing model execution approaches (interpretation of models or code generation) do not support the execution of partial models. Supporting the execution of partial models at early stages of software development allows early detection of defects, which can be fixed more easily and at lower cost. This paper proposes 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 to detect problematic elements of models that cause problems for the execution. Second, using model transformation techniques, the models are refined automatically, mainly by adding decision points where missing information can be supplied. Third, refined models are executed, and when the execution reaches the decision points, it uses inputs obtained either interactively or by a script that captures how to deal with partial elements. We created an execution engine called PMExec for the execution of partial models of UML-RT (i.e., a modeling language for the development of soft real-time systems) that embodies our proposed framework. We evaluated PMExec based on 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, which is mostly due to the refinement and the increase in model complexity it causes, is manageable. We also discuss the properties of the refinement formally, and show how the refinement preserves the original behaviors of the model.
Thesis
Model-driven Development (MDD) is a software development approach that advocates using models rather than source code. MDD can decrease complexity by raising the level of abstraction, and increase productivity by automation, e.g., code generation. Developers spend around 50% of their time on debugging and fixing bugs, and the cost of debugging, testing, and verification account for almost 50-75% of the software development budget. Existing MDD tools do not provide proper support for the debugging of models. Thus, developers often debug the generated source code in order to debug their models, which contradicts MDD principles, as many of the benefits of the abstraction are lost. This thesis introduces a novel approach to platform-independent model-level debugging, with the help of model transformation that equips the model with support for debugging services. The approach does not rely on program debuggers, and any changes to, e.g., the code generator or the hardware platform, leave the debugger unaffected. Based on the approach, a model-level debugger MDebugger is created that allows the debugging of UML-RT models. The typically iterative and incremental nature of software development implies that many development artifacts are incomplete until later stages of development. None of the model-level debuggers, including MDebugger, allows the debugging of incomplete (i.e., partial) models, because the model execution techniques (interpretation and code generation) cannot execute partial models. This 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. We propose a conceptual framework to execute partial models. Based on the framework, an execution engine of partial models (PMExec) is developed that allows the debugging and execution of partial UML-RT models at any stage of the software development process, assuming that the structural models are defined and proper input is provided. Finally, to keep pace with program debugging services, and optimize the PMExec and MDebugger we introduce a new approach for live modeling that allows the updating of model elements during the execution.
Article
Full-text available
Model transformation lies at the very core of model-driven engineering (MDE), and a large number of model transformation languages and tools have been proposed over the last few years. These tools can be used to develop, transform, merge, exchange, compare and verify models and metamodels. In this paper, we present a comprehensive catalogue of existing metamodel-based transformation tools and compare them using a qualitative framework. We begin by organizing the 60 tools we identified into a general classification based on the transformation approach used. We then compare these tools using a number of particular facets, where each facet belongs to one of six different categories and may contain several attributes. The results of the study are discussed in detail and made publicly available in a companion website with a capability to search for tools using the specified facets as search criteria. Our study provides a thorough picture of the state-of-the-art in model transformation techniques and tools. Our results are potentially beneficial to many stakeholders in the modeling community, including practitioners, researchers, and transformation tool developers.
Conference Paper
Full-text available
Ideally, debuggers for Model-Driven Development (MDD) tools would allow users to 'stay at the model-level' and would not require them to refer to the generated source code or figure out how the code generator works. Existing approaches to model-level debugging do not satisfy this requirement and are unnecessarily complex and platform-specific due to their dependency on program debuggers. We introduced a novel approach to model-level debugging that formulates debugging services at model-level and implements them using model transformation. This approach is implemented in MDebugger, a platform-independent model-level debugger using Papyrus-RT, an MDD tool for the modeling language UML-RT. https://youtu.be/L0JDn8eczwQ
Conference Paper
Full-text available
Providing proper support for debugging models at model-level is one of the main barriers to a broader adoption of Model Driven Development (MDD). In this paper, we focus on the use of MDD for the development of real-time embedded systems (RTE). We introduce a new platform-independent approach to implement model-level debuggers. We describe how to realize support for model-level debugging entirely in terms of the modeling language and show how to implement this support in terms of a model-to-model transformation. Key advantages of the approach over existing work are that (1) it does not require a program debugger for the code generated from the model, and that (2) any changes to, e.g., the code generator, the target language, or the hardware platform leave the debugger completely unaffected. We also describe an implementation of the approach in the context of Papyrus-RT, an open source MDD tool based on the modeling language UML-RT. We summarize the results of the use of our model-based debugger on several use cases to determine its overhead in terms of size and performance. Despite being a prototype, the performance overhead is in the order of microseconds, while the size overhead is comparable with that of GDB, the GNU Debugger.
Article
Full-text available
Models are good at expressing information about software but not as good at expressing modelers' uncertainty about it. The highly incremental and iterative nature of software development nonetheless requires the ability to express uncertainty and reason with models containing it. In this paper, we build on our earlier work on expressing uncertainty using partial models, by elaborating an approach to reasoning with such models. We evaluate our approach by experimentally comparing it to traditional strategies for dealing with uncertainty as well as by conducting a case study using open source software. We conclude that we are able to reap the benefits of well-managed uncertainty while incurring minimal additional cost.
Article
We propose a formal semantics for UML-RT, a UML profile for real-time and embedded systems. The formal semantics is given by mapping UML-RT models into a language called kiltera, a real-time extension of the $$\pi$$ -calculus. Previous attempts to formalize the semantics of UML-RT have fallen short by considering only a very small subset of the language and providing fundamentally incomplete semantics based on incorrect assumptions, such as a one-to-one correspondence between “capsules” and threads. Our semantics is novel in several ways: (1) it deals with both state machine diagrams and capsule diagrams; (2) it deals with aspects of UML-RT that have not been formalized before, such as thread allocation, service provision points, and service access points; (3) it supports an action language; and (4) the translation has been implemented in the form of a transformation from UML-RT models created with IBM’s RSA-RTE tool, into kiltera code. To our knowledge, this is the most comprehensive formal semantics for UML-RT to date.
Conference Paper
Support for automated model transformation is essential for realizing a Model Driven Development (MDD) process. However, model transformation is only one of the many tools in a model engineering toolkit. To apply MDD in the large, automated support for a number of additional tasks such as model comparison, merging, validation and model-to-text transformation, is essential. While a number of successful model transformation languages have been currently proposed, the majority of them have been developed in isolation and as a result, they face consistency and integration difficulties with languages that support other model management tasks. We present the Epsilon Transformation Language (ETL), a hybrid model transformation language that has been developed atop the infrastructure provided by the Epsilon model management platform. By building atop Epsilon, ETL is seamlessly integrated with a number of other task-specific languages to help to realize composite model management workflows.
Article
Defect detection activities are generally seen as expensive and time consuming. This article reports on actual experiences from large projects. Based on data, dependencies between the costs of early defect detection, late defect detection and defect fixing are analysed and some guidelines are derived for timing and resource allocation to ensure cost-effective defect detection. Experience reports show that the costs of defect fixing in software development grow dramatically when the defects are found late, i.e. when the defects have already influenced the next phase. This common experience is supported by all the projects, two of which are considered in this paper. However, metrics applied to the data show that it is not always an order of magnitude that lies between the costs of early and late fixing of defects. Rather, the average cost of defects found late decreases with introduction of early defect detection. This is due to the fact that early document reviews leave only minor defects, e.g. in the requirements or the design. Major and therefore expensive defects tend to be found in those early reviews. Further analysis of the data led to the use of metrics that proved very useful when planning and executing the required defect detection activities. For example the number of remarks per 100 lines was used to decide how efficient reviews of the design have been and whether more or less resources should be allocated to these reviews in a running project. As a conclusion, it is emphasized that a substantial amount of a project's budget and time will be saved by introducing systematic defect detection early in the project. It is suggested that defect detection activities should start as soon as the requirements documents are declared finished.
Execution and debugging of partial models in the context of model-driven development