7.2 Analysis-Specific Models
7.2.2 Model to Model Transformations
of anotherEGPPGraph. Essentially, there are two types of scenarios to be considered, entering a sub-graph (grin) or leaving a sub-graph (grout). Consequently, the traversal of anEGPPGraph conforms to the following set of semantic rules further illustrated in figure 7.21:
n0 n1
... t0 gr t1 ...
...
ingr fngr
Figure 7.21: An illustration of a sub-graph embedded in a flow of its parentEGPPGraph (gr)
⟨n0,σ⟩Ð→ ⟨t0 ingr,σ⟩
ifB[[cond(t0)]]σ=tt (grintt)
⟨n0,σ⟩Ð→ ⟨t0 n0,σ⟩
ifB[[cond(t0)]]σ=ff (grinff)
⟨f ngr,σ⟩Ð→ ⟨t1 n1,σ⟩
ifB[[cond(t1)]]σ=tt∧f ngr∈Φgr
(grouttt)
⟨f ngr,σ⟩Ð→ ⟨t1 gr,σ⟩
ifB[[cond(t1)]]σ=ff∨f ngr∉Φgr
(groutff)
The syntactic and semantic definitions presented here provide the basis for most of the following steps. In particular, this laid the foundation for the Abstract Test Execution explained in more detail in section 10.2.
Stub EGPP System Model EGPP System Behavior Model
A
B
C
Main Loop Sub- Sys tem
guard
...
D
E F
G Behavi or
Join Fork
Figure 7.22: Pattern for EGPP instance transformed from structure and behavior System Model artifacts
The transformation is divided into two phases, whereby the structure and control flow aspects as well as the data flow aspects are performed separately. In addition to the differentiation into the phases of the transformation, a distinction is made according to the model context, that is, whether the original model is used for System Modeling or for Test Modeling.
Transformation of Structure and Control Flow Information
First, the transformation of structural information is discussed. For this purpose, pat- terns are developed for the two modeling contextsSystemandTest, according to which the instances of the target modeling language EGPP are built. The following section discusses the set of rules for the transformation of system structure and behavior infor- mation.
System Structure and Behavior Information to Execution Graph++ As already described in the introduction of the metamodel concepts of EGPP, both the structure and the behavior of a system can be implemented integrated into the graph-based rep- resentation. An exemplary section of an EGPP structure is shown in figure 7.22, where the system level serves as the entry point, which is developed top-down to the smallest included components. In the middle of the figure, there is the EGPPGraph, contain- ing especially the Main Loopas its main component. This represents the functionality of conventional systems to activate certain components either time- or event-triggered (guard), which in this case corresponds to traversing one of the parallel paths including possible sub-graphs. The concepts contained inMain Loopcan be either subsystems or behavioral models, each of which is mapped using EGPPGraph. On the right side of figure 7.22 is an example graph containing two alternative processes, where the sys- tem state can be changed by expressions contained in the nodesD,E,F,G. On the other
hand, if you take a look at theEGPPGraphof the sub-system shown, it would have the same components as the graph shown and explained in the middle of figure 7.22. How often this encapsulation and, accordingly, the nestedMain Loopsoccur depends on the number of integration levels of the System Model.
An essential difference between the use of the EGPP metamodel for system and Test Modeling is the use of the so-calledstub. This is anEGPPGraphthat is coupled to another EGPPGraphand reflects the initialization of its variables relevant to the system state. As shown in figure 7.22 on the left, this is anEGPPGraphthat consists of a path, with nodes A, B, Ccontaining variable assignments of initial values, e.g. x = 5;, while the initial values are not mandatory and may therefore be reduced to declarations. Processing of the information contained in thestub is done once at the beginning of execution, not per iteration of theMain Loops. The describedstub concept applies to the sub-system and behaviorEGPPGraphsof the lower levels.
As in the previous chapters, the running example shows how a portion of the System Model is mapped to the EGPP representation. Figure 7.23 shows the nesting of different EGPP graphs, each of which retains sub-functionality.
EGPP CSM (Block) EGPP CSM (Statemachine)
Main Loop EGPP CSM (St atemachi ne)
EGPP CSM_ON (Statemachine)
CSM_OFF CSM_ON
NORMAL
OVERSPEED
WARNING
SERVICE_BRAKE
EMER_BRAKE Fork
Join
Figure 7.23: Excerpt of the EGPP model for the CSM System Model
For clarity, detailed information such as edge labels has been omitted. On the left side, one can see the original SYSML block CSM which has been transformed into anEGPP- Graph. Since the CSM block does not contain any further blocks, only the transformed statemachine (original: see figure 16.3 (Supplementary Material)) is included in the main cycle. In the middle of the picture, you can see the first statemachine in the EGPP context, in which the sub-statemachine (original: see figure 16.4 (Supplementary Mate- rial)) shown on the right side is integrated. In the EGPP variants of the two statema- chines it is noticeable that an explicit final state was specified in each case, which can be reached from all intermediate states. This is necessary to comply with the EGPP metamodel.
Test Information to Execution Graph++ Analogous to the development of a pattern for software modeling, the structure of the EGPP models, which represents the test
context, is explained. At this point, a schematic representation of the structure of the target model is used, as shown in figure 7.24.
Stub EGPP Systemtest Model EGPP Integrationtest Model
A
B
C
A
D
E
G
H Integration
1 A
D
B
C
Unit 2
Unit 1 F
Figure 7.24: Pattern for EGPP instance transformed from Test Model artifacts
As already explained in the foundations’ chapter, test cases are specified for different integration levels. Thus, test cases of higher integration levels build on tested compo- nents of lower levels. This situation is reflected in EGPP models, where Test Modeling is divided along with the different levels of integration, starting from system level down to unit level. In the middle of figure 7.24, a transformed Test Model for the system level is shown schematically. Three possible paths (test cases) can be derived from this model, where one path incorporates the externally perceivable effects of an interme- diate level componentintegration 1on the next lower level. The Test Modeling of this component is shown on the right side of the figure. Based on this model a set of paths (test cases) can be derived, which partly build up again on insights from tests on deeper integration levels (seeUnit 1andUnit 2).
On the left side of figure 7.24, one can see another EGPPGraph, showing the role of the so-called stubs. In the context of Test Modeling, the stub encapsulates a set of paths, while each of the paths contains a set of nodes, that first evaluate the overall system state and then manipulate the system state accordingly. The contents of the paths emerge from successful test executions against the corresponding EGPP model.
With sufficient test data, the paths contained in thestubcan be aggregated to paths that represent equivalence classes to the input data. The information contained in thestub model is further utilized in the context of our approach to Abstract Test Execution (see section 10.2.4). Here, the information collected at lower levels of integration provides value to the model interpreter, which can use it to adjust the current system state with- out further evaluation of embedded EGPP models. Overall, extensive testing starting at lower integration levels can improve the performance of MCSTLC.
In this section, we use the running example, which is intended to illustrate the ex- plained facts. Figure 7.25 illustrates the split of the Test Model into the mentioned integration levels.
EGPP Unit 2 EGPP Integration 2
EGPP Systemlevel
Fork Fork
Fork
Join Join
Join
Test Path 1 Test Path 2 Test Path 1 Test Path 2 calc_speed_to_driver 1 calc_speed_to_driver 3
calc_speed_to_driver 2
EGPP Unit 1 EGPP
Integration 1
Tes tStep
Tes tStep
VP
Tes tStep
Tes tStep
VP
Tes tStep
VP EGPP
Integration 2
EGPP Unit 2
Figure 7.25: Excerpt of the EGPP model for the CSM Test Model
The EGPP representation of the Test Model for the system test level is shown on the left side of the figure. In particular, it represents a set of test cases by providing mul- tiple paths from theEGPPInitialNode to theEGPPFinalNode. As part of these paths, the stubs of the Test Models of deeper integration levels (see EGPP Integration 2) are included. The concept of stubs is dealt with separately in the context of chapter 8 since several independent models are potentially created from one model. This indicates that already tested behavior is used in an extended test context. This can be continued anal- ogously through the intended integration levels up to the unit level. At the right side of the figure, the test cases for the methodcalc_speed_to_driverare shown as an ex- ample, which in turn represent individual paths through the Test ModelEGPP Unit 2.
The test cases each consist ofEGPPNodes, which on the one hand representTestStepsand on the other handVerificationPoints (VP), determined by the types and contents of the EGPPTaggedData.
Transformation of Data Flow Information
In addition to the transformation of the structural information as well as the modeled control flow, the original model can already contain detailed information which has to be transformed. Detailed information such as code fragments, which are embed- ded in the model artifacts, conform to a certain language. Depending on the language scope and the size of the embedded code fragments, the transformation of the data flow information can have effects on the previously considered structure and control flow transformations.
The aim of the second phase of the M2MT is, to map the control flow components used in code fragments in (sub-)graphs and, to store the atomic data flow information in the EGPPTaggedDataof the respective model elements. For the former, the transformation procedure is relatively obvious. If the code fragments to be transformed contain control flow information, the model artifact previously implemented asEGPPNodeis replaced by anEGPPGraph, which in turn reflects the code-based control flow. The atomic data
flow information (assignments, conditions, etc.) is then stored as usual in the EGPP- TaggedDataof the respectiveEGPPNodeorEGPPTransition.
For the latter, depending on the programming language used, the concepts need to be mapped to our pseudocode-like language introduced in grammar 7.1. Since at this point the fragments are free of control flow components, this is just a syntactical ad- justment. If concepts are used in the original programming language that cannot be mapped in our language or can only be realized by changing the semantics, the limits of our approach are reached. This is the case, for example, as soon as temporal consid- erations or pointer arithmetic are applied.
In the course of the running example, data flow information is transformed. As al- ready mentioned, the transformation of the code fragment is limited to purely syntac- tical changes in the concrete case. Regarding the types used, no mappings are nec- essary. Besides, the control flow, which is encapsulated in method calls of the System Model, for example, is mapped by explicitEGPPGraphsto guarantee the requirement for atomic assignment operations in the context ofEGPPNodes. For example, the methods calc_permitted_speed_to_driver, calc_speed_to_driver, or calc_speed_onboard used in the context of the statemachine from figure 16.3 (Supplementary Material) and figure 16.4 (Supplementary Material) are affected.