# A Method for Modeling and Testing Near-Real-Time System Scenarios
## 5 Sample Scenario
### Generating Tests for a Handover Scenario  
In the case of system modeling, it is difficult to show a consistent and reliable method for determining test cases based on the system design in UML. This is related to the flexibility of modeling and the lack of limitations imposed on IT system designers. In the case of safety-critical system models, certain assumptions can be made that increase software safety while simplifying the models themselves in UML or other formal languages. The basic principles related to the construction of real-time or near-real-time safety-critical systems that facilitate modeling are:  
* decomposition of functionalities affecting system safety;
* designing independent modules that communicate with each other synchronously or asynchronously and assigning them to various resources of computers and devices;
* avoiding deep nesting, including complex loops, in algorithm design. These types of design rules are used in the construction processes of elements of unmanned platforms that are subject to certification, such as flight control elements. In practice, this means that when designing algorithms in the form of UML sequence diagrams, it should not happen that there are multiple conditional branches (\(if\) section) or multiple  
Figure 9: Sequence diagram for the state (P1(HA), U(HA), E(FL), P2(HR)) shown in Figure 8.  
loops (_loop_ section), including nested loops, in the processing path. It can be assumed with a high degree of probability that in a safety-critical system the occurrence of loops in the software supervising the system control in almost every case comes down to the execution of a finite (and usually very small) number of iterations. At this point, most loops can be reduced to a finite sequence of instructions following each other without returns, which allows the processing path to be modeled in the form of a directed graph without cycles (DAG). To determine the path coverage in a graph, one must first convert the sequence diagram model shown in Figure 9 to the EESM machine shown in Figure 10. After conversion, a DAG is constructed on which path coverage can be determined. The algorithm consists of two steps: determining the allowable flow and determining the minimum flow (Ciurea and Ciupala [36]). At the same time, it is worth noting that software modules in which sequences of operations are repeated cyclically usually collect specific device states and transmit them to decision-making subsystems. Each of these algorithms can be checked individually, which is usually not a problem because the sequences of operations are not complicated. The presented test generation method allows for covering the scenario paths for a selected part of the system. Path coverage methods are one of the most popular planning methods for determining system testing paths. It is worth emphasizing again that these methods do not guarantee the determination of full coverage, i.e., coverage of all processing paths, which in the case of a multi-module system is an NP-hard problem and may not be feasible in practice in a  
Figure 10: Transformation of the sequence diagram from Figure 9 to EESM. DAG without additional loops that can be used to determine path coverage. In practice, a minimum path coverage is usually specified, which is sufficient to test the correct operation of the algorithm. finite time. The methods support the determination of the so-called minimum coverage, which guarantees that each program unit is checked at least once. A draft of the path coverage algorithm is shown in Algorithms 1 and 2. ```
Input: \(G\) Result: \(P=P_{1},\ldots,P_{k},\ldots,P_{K}\), \(K\) number of paths covering \(G\) Algorithm:
1. find cycles in \(G\)
2. convert \(G\) into DAG \(G^{\prime}\) by removing back edges leaving only tree, forward, and cross edges (DFS)
3. assign each \(v\in G^{\prime}\) vertex without a successor to the set \(V^{\prime}\)
4. select source vertex \(s\in G^{\prime}\)
5.