1 Introduction
-
a classification framework for classifying, comparing, and evaluating solutions for executing UML models;
-
a systematic review of the states of the art and practice in executing UML models;
-
an exploration of emerging research challenges and implications for future research and practice of executing UML models.
2 Background
2.1 From programming to MDE
-
Interpretation the software program is interpreted by a language-specific virtual machine program executing on the target platform;
-
Translation the software program is translated into object code4 that could be executed directly on the target machine.
2.2 UML as an executable modeling language
LampPost_ Functional
represents the root software composite component, which contains six software components. Connections between software functionalities are achieved through connectors via ports. Behavioral descriptions of the software components are defined in terms of UML state machines, for defining the overall behavior by means of states and transitions, and Alf, for specifying fine-grained actions. The state machine diagram describing the behavior of the type ManagerR
is shown in the upper right corner of Fig. 2.3 Research method
-
Search and selection we performed a combination of automatic search and snowballing for identifying a comprehensive set of potentially relevant solutions for the execution of UML models. With snowballing, performed after the automatic search, we aimed at enlarging the set of potentially relevant solutions by considering each previously selected research study and focusing on those articles either citing or cited by it [49]. Next, the candidate solutions were filtered in order to obtain the final list of primary studies to be considered in later activities of the review. Section 3.2 describes in detail the search and selection process.
-
Classification framework definition: in this activity we organized the parameters pertaining to the technical characteristics of a solution for executing UML models. Because these were applicable to evaluating both tools and research studies, the result was a reusable classification framework, which can be used by both researchers and practitioners (see Sect. 3.3).
-
Data extraction and quality assessment in this activity we studied the details of each primary study, and based on that, filled in the corresponding data extraction form. Completed forms were then collected and aggregated for use in the next activity. More details about this activity are presented in Sect. 3.3. Furthermore, we assessed the quality of each selected research study according to a set of well-defined quality criteria (see Sect. 6.4).
-
Data synthesis this activity focused on a comprehensive analysis and summary of the data extracted in the preceding activity. The main goal here was to elaborate on the extracted data in order to answer the research questions (see Sect. 3.1). This involved both quantitative and qualitative analysis of the extracted data. The details of this activity are presented in Sect. 3.4.
3.1 Goal and research questions
-
RQ1—What are the publication trends of research studies about solutions for the execution of UML models?Objective: to identify and classify primary studies in order to assess interest, relevant venues, and publication types over the years.
-
RQ2—What are the technical characteristics of existing solutions for the execution of UML models?Objective: to classify existing solutions for executing UML models (e.g., execution strategy used, which elements of UML are supported, application domains targeted), using a systematic classification framework (see Sect. 3.3).
-
RQ3—What evidence exists to justify adoption of an existing solution?Objective: to investigate and qualify the quality of the evidence that could make a proposed solution applicable in practice. This is based on explicit quality criteria, such as the rigor and thoroughness of the validation strategies used (e.g., controlled experiment, industrial application, formal proofs).
-
RQ4—What are the limitations of existing solutions for the execution of UML models?Objective: to identify current limitations with respect to the state of the art. In this context, we focused on the limitations (and thereby needs for improvement) of the solutions as they were reported in the analyzed primary studies.
3.2 Search and selection strategy
-
Research studies search and selection this covers the research described in peer-reviewed publications in various research-oriented venues and forums such as international journals, conferences, books, workshops;
-
Tools search and selection this covers relevant open-source and commercial tools.
3.2.1 Research studies search and selection
3.2.2 Selection criteria for research studies
3.2.3 Tools search and selection
3.2.4 Selection criteria for tools
3.3 Data extraction and classification framework definition
-
the collected information was not interpreted correctly; in this case, the collected information was refined;
-
the parameters of the data extraction form were not representative enough for the considered primary study; in this case, the data extraction form was refined so that it better fit the collected information; previously analyzed primary studies were re-analyzed according to the refined data extraction form.
3.4 Data synthesis
3.5 Threats to validity
4 Publication trends
4.1 Publication year
4.2 Publication venues
Publication venue | Type | #Studies |
---|---|---|
European Conference on Modelling Foundations and Applications (ECMFA) | Conf. | 3 |
Design, Automation and Test in Europe Conference and Exhibition (DATE) | Conf. | 3 |
Design Automation for Embedded Systems (DAES) | Conf. | 3 |
Software and System Modeling (SoSyM) | Journal | 3 |
ACM Symposium on Applied Computing (SAC) | Conf. | 2 |
Forum on Specification and Design Languages (FDL) | Conf. | 2 |
Brasilian Symposium on Computing System Engineering (SBESC) | Conf. | 2 |
Executable Modeling (EXE) | Work. | 3 |
Others | – | 42 |
Total | – | 63 |
5 Technical characteristics
5.1 UML modeling
5.2 Execution strategy
5.2.1 Translational execution
5.2.2 Interpretive execution
Engine name | Studies |
---|---|
Moka—Papyrus | P18, T14 |
fUML virtual machine | P24, P25 |
Ad hoc engine based on IBM RSA-RT | P31 |
fUML engine based on Kermeta | P32 |
UML interpreter engine | P34 |
MOCAS | P23 |
Populo | P48 |
ACTi | P49 |
fUML reference implementation | T13 |
iUML | T11 |
BridgePoint | T12 |
5.3 Intended benefits
5.4 Associated process
5.5 Extensibility
5.6 Readiness level
5.7 Supported non-functional properties
Formal language | Usage | Study |
---|---|---|
Petri Net [41] | Translation target for performance analysis | P38 |
Translation target for acting as reference for services orchestration | P54 | |
NuSMV [11] | Generated for formally verifying the correctness of the specification | P17 |
Translation target for verifying temporal properties | P56 | |
FFSM (ad hoc) | Generated on the fly and interpreted at runtime | P31 |
Translation target for execution and analysis | P6 | |
KIV [21] | Automatically generated for proving security properties | P44 |
Jolie [38] | Translation target for formal verification of services composition | P53 |
Lisp [46] | Translation target for verification of user-defined properties and simulation | P57 |
BHDL [7] | Intermediate representation during the translation and properties verification | P60 |
Event B [2] | Action language in UML models and intermediate representation during the translation for properties verification | P60 |
Z [42] | Formal verification of user-defined properties | P61 |
TML (ad hoc) | Translation target for performance, liveness, reachability, and scheduling analysis | P2 |
ForSyDe (ad hoc) | Generated for formally verifying the behavioral of the modeled system | P10 |
5.8 Formal specification languages
6 Provided evidence
6.1 Applied research method
ID | Quality criteria |
---|---|
Q1 | Is there a clear statement of the aims of the research? |
Q2 | Is there an adequate description of the context (e.g., industrial use, laboratory-based investigation, product) in which the research was carried out? |
Q3 | Is there an adequate justification and description of the research design? |
Q4 | Is there a clear statement of obtained findings, including data supporting them? |
Q5 | Is there a critical discussion of the researchers’ roles, potential bias, and influence on the proposed research? |
Q6 | Is there a critical discussion of potential limitations of the proposed research? |
6.2 Type of evidence
-
Example: 1 in-house example.
-
Set of examples: several in-house (not industrial) examples, several runs and comparisons of one example, even several models for the system, e.g., with different sizes.
-
Empirical laboratory: case studies, controlled experiments and empirical evaluations in laboratory.
-
Industrial example: example coming from industry and performed in laboratory.
-
Set of industrial examples: several industrial examples (even several models for the system, e.g., with different sizes).
-
Empirical industrial: case studies, controlled experiments and empirical evaluations either in industry or in real-world scenarios.
-
Industrial evaluation: evaluation performed by industrial actors, solution used in industry.
6.3 Type of systems for evidence
6.4 Quality assessment results
ID | Title | Year | Score |
---|---|---|---|
P23 | Environment modeling and simulation for automated testing of soft real-time embedded software | 2013 | 6.0 |
P6 | On the Generation of Full-Fledged Code from UML Profiles and Alf for Complex Systems | 2015 | 5.5 |
P27 | A Plug-in Based Approach for UML Model Simulation | 2012 | 5.0 |
P56 | FSMC+, a tool for the generation of Java code from statecharts | 2007 | 5.0 |
P61 | Deriving executable process descriptions from UML | 2002 | 5.0 |
P3 | On the automated translational execution of the action language for foundational UML | 2016 | 5.0 |
7 Identified limitations
Type of limitations and unsolved challenges | #Studies | Studies |
---|---|---|
Expressiveness enhancement (e.g., support for more UML constructs, more expressive action language for behavioral specifications) | 31 | T5, T16, P1, P4, P5, P6, P7, P10, P12, P13, P14, P20, P24, P26, P27, P29, P30, P31, P36, P37, P38, P46, P49, P51, P53, P56, P57, P59, P61, P62, P63 |
Tool enhancement (e.g., refinement of the modeling editor, better testing of prototype tools) | 20 | P1, P2, P4, P6, P7, P8, P9, P10, P13, P17, P22, P27, P36, P37, P40, P45, P46, P54, P55, P60 |
Additional analysis of models (e.g., support for other timing and scheduling analyses on the UML models, new analysis for checking the conformance of the UML models to specific requirements) | 12 | T5, T14, T1, P9, P10, P16, P21, P24, P35, P38, P41, P42 |
Additional evaluation (e.g., more extensive experimentation for evaluating the approach, test the approach on additional systems and/or application domains) | 11 | P2, P5, P14, P16, P31, P32, P40, P45, P47, P53, P58 |
Execution platform improvement (e.g., more efficient scheduling of tasks at runtime, improvement of generated Java code) | 7 | P2, P4, P5, P8, P47, P51, P63 |
Generated code optimization (e.g., generate more efficient C++ code, generate Java code which implements Android development best practices) | 6 | P3, P5, P6, P8, P28, P59 |
Execution correctness assessment (e.g., automated consistency checks between the models and generated code, test the simulated models to check if they behave as expected) | 4 | P3, P18, P23, P26 |
Traceability enhancement (e.g., link error messages shown at runtime with entities in the UML models, trace and visualize the execution steps in the simulation directly into the UML models) | 4 | P36, P39, P40, P57 |
Support for model checking (e.g., support for deadlock detection, reachability analysis via model checking) | 4 | T15, P25, P33, P49 |
Reusability enhancement (e.g., improve the UML models repository, ability to reuse model elements across projects) | 3 | P10, P21, P41 |
Platform-specific limitations (e.g., the UML class diagram is bound to the Java single-inheritance constraint, only soft deadlines supported because the code generation does not target a real-time OS) | 2 | P19, P23 |
Support for runtime models update (e.g., process definition modified at runtime and without restarting the process execution, modification of execution contracts at runtime) | 2 | P32, P33 |
Additional execution targets (e.g., generated code beyond the already supported languages, like C++ code, generation of executable BPMN specifications) | 2 | P3, P54 |
Platform independence enhancement (e.g., development of a generic model of computation, independence with respect to the targeted programming language when performing translation) | 2 | P26, P27 |
Execution strategies combination (e.g., combination of interpretation and dynamic compilation) | 1 | P34 |
Scalability (e.g., avoid state space explosion when interpreting the models at runtime) | 1 | P31 |
Portability enhancement (e.g., porting of the UML virtual machine into other non-x86- based platforms) | 1 | P55 |
8 Horizontal analysis
8.1 Execution strategy versus UML diagrams
8.2 Application domain versus required UML profiles
8.3 Execution strategy versus production system
8.4 Execution strategy versus readiness level
8.5 Execution strategy versus publication year
8.6 Readiness level versus primary study type
8.7 Intended benefits versus publication year
8.8 Intended benefits versus execution strategy
8.9 Execution strategy versus fUML standard compliance
8.10 Simulation versus fUML standard compliance
8.11 Simulation versus model-level debugging
8.12 Covered MDA layers versus execution strategy
8.13 Identified limitations versus execution strategy
8.14 Identified limitations versus support for non-functional properties
8.15 Identified limitations versus support for simulation
8.16 Identified limitations versus readiness level
8.17 Production system versus support for simulation
8.18 Production system versus software platform
8.19 Support for simulation versus software platform
9 Discussion and future prospects
9.1 Future prospects for technical advancement
-
ability to execute abstract (high-level) and incomplete models;
-
enhanced observability of executing models;
-
enhanced control of model execution;
-
directly compiled model executables;
-
support for UML-compliant action languages;
-
support for executing models based on UML profiles;
-
integration of UML simulators into heterogeneous (multi-paradigm) simulation systems;
9.1.1 Ability to execute abstract (high-level) and incomplete models
9.1.2 Enhanced observability of executing models
9.1.3 Enhanced control of model execution
9.1.4 Directly compiled model executables
-
The translation tools, such as compilers, that are used in the second step are carefully designed to take full advantage of the semantics of their language. This allows them to implement numerous semantics-specific optimizations to realize time and memory savings. However, since they are designed for their programming language, they are unable to take advantage of UML-specific semantics. Invariably, the result is suboptimal code;
-
The intermediate step whereby the model is translated into a programming language equivalent creates an additional barrier to the link between the executable code and its source model. This is exacerbated by the fact that the programming language translator is insensitive to UML-specific semantics. (For example, it may optimize away some aspect that is critical for the inverse mapping.) Needless to say, this complicates any model observability strategies discussed above.