In the context of this chapter, we have presented a comprehensive approach that com- bines models of different development domains/disciplines and prepares them for analysis purposes. In particular, we focused on necessary test activities during model- based development. The question formulated in section 1.1
What kind of modeling conventions and metamodeling concepts are essential to effectively apply testing activities in the early stages of MDSD?
can therefore be answered as follows. The presented Omni Model approach allows using the modeling languages commonly utilized by the user, provided that the min- imum requirements for the subsequent integration are met. These are realized in the respective domains utilizing a set of modeling guidelines and thus form the basis for the modeling landscape. A model artifact created explicitly for integration purposes provides functionality for both structural and behavioral aspects and encapsulates in- formation important for model-centric testing. By defining a special metamodel for the analysis-specific view of the model landscape, i.e. EGPP, the basis for uniform process- ing of all model information is established. This representation is automatically derived from the original model artifacts through M2MTs. In particular, a sound basis was cre- ated for all processing steps of the MCSTLC. In addition to the conceptual solution of the problem definition, a prototype implementation was developed. The Architecture And Analysis Framework (A3F) created for this purpose offers extensive possibilities for the processing and analysis of model information, whereby the central concept of the framework is again the Omni Model approach. The focus was on the practical ap- plicability of the implementation as well as the integration into existing toolchains.
Each concept has certain strengths and weaknesses, which have to be communicated to the user such that a well-founded decision for or against the application of the approach can be made. For this reason, the following section deals with the advantages and disadvantages in the form of a brief discussion. Among the advantages of the current approach is the adaptability to the quantity and characteristics of the included model artifacts. In this context, the strict separation of concerns is advantageous, since no undesired cross-relationships and emergent behavior arise. Furthermore, the simple and intuitive display of cross-relationships and the specification of meta-information is another positive aspect. On the side of the technical implementation, the existence of a prototype implementation is to be emphasized, which shows the practical applicability.
Especially the applicability from very early phases up to late phases of model-centric developments gives the user an advantage.
Addressing the approach’s shortcomings, the mentioned functionalities are based to a large extent on a new and additional model artifact introduced especially for this purpose, namely the Integration Model. At this point, the additional effort of model creation and maintenance has to be taken into account. However, this effort can be kept relatively low by sophisticated support from the tools and strict implementation of modeling guidelines. Also, the effort for the specification of the M2MTs for the au- tomated derivation of the analysis-specific representation should not be neglected. Be- sides, this artifact has to be created by experts, since a high degree of modeling expe- rience and domain knowledge is required. Conceptual errors in the implementation of these transformations have serious effects on all downstream processing steps. There are some shortcomings on the technical level in the current implementation. These primarily concern the usability of the implementation and the connection to more ex- tensive and flexible interfaces for model data, such as OSLC or theModelBus.
In conclusion, possible starting points for future improvements/extensions on the side of the concept as well as the connected prototypical implementation are shown. On the conceptual side, the current integration of data flow information via the internal
pseudocode-like language is to be mentioned. In later stages of expansion, further con- cepts typical for certain programming languages can be taken into account to increase the functional extent. Likewise, the connection of the concepts just mentioned for the exchange of model information between tools (OSLC, ModelBus) represents a possible future extension of the implementation [132][35]. The same applies to the improvement of the user interface to enable the most intuitive interaction possible.
8
Model-Based Test Case Management
Based on the Omni Model of the SUT, whose basic concepts are explained in the previ- ous chapter, the first processing step of the MCSTLC takes place. In the context of this step, the test focus and the test level are mapped to the model landscape and thus lay the foundation for subsequent processing, such as test case generation. As already de- scribed at the beginning of chapter 6, some phases of the classical STLC are addressed at this point, albeit in a different order. In particular, the concepts presented in the following allow for the selection, prioritization, and reduction of test cases in an early phase of the MCSTLC before test cases are even derived from the model.
In contrast to the largely manual modeling work on the Integrated Model Basis, this process step represents the first part of the automated processing chain. In early iter- ations of the MCSTLC, i.e. at low integration levels, only the basic models created by the modeler/developer are processed. In contrast, in later iterations of this processing step, i.e. on higher integration levels, findings of the downstream test execution are fed back into the model and thus taken into account.
As the excerpt of the MCSTLC in figure 8.1 shows, besides the already mentioned In- tegrated Model Basis, some configuration parameters are necessary to realize the men- tioned functionality.
Model Creation/
Modification
Model-Based Test Case Management
Integrated Model Basis
Model-Based Test Suite Generation
Scoped Tes t Model(s) Configurat ion
Parameters
Legend:
Parameters Process Step Model Artifact
Figure 8.1: MCSTLC extract focusing the Test Case Management and involved informa- tion
The test engineer’s test focus must be able to be specified intuitively, again utilizing and expanding the Aspects concept (see section 7.1.3). The test level (Unit, Integration,
System) has to be applied to the set of models, which correspond to the specified test fo- cus. For this purpose, the Execution Graph++ Metamodel (EGPPMM) was introduced.
Based on this set of information, the processing can be performed to produce one or more so-calledScoped Test Models, each of which represents very specific portions of the original Test Model. Therefore, the algorithmic solution that realizes the extraction of these sub-models is calledTest Model Scoping.
8.1 Prerequisites for Test Model Scoping
To provide the necessary foundations for algorithmic processing in the context of Test Model Scoping, the relevant concepts are introduced in this section. In addition to the obvious configuration parameters like the test level, the mechanism for the specification of the test focus is presented as well as the relevant parts of the Omni Model.
8.1.1 Test Focus Specification
As previously mentioned, the extraction of a specific Test Model is the overall goal of this process step.Specificin this context means that the resulting model artifact and test cases tackle the focused System Model parts. Consequently, the generated test cases can challenge the focused parts as efficiently and effectively as possible. In this case, the Aspects concept introduced in section 7.1.3 serves as a basis, which realizes a uniform interface for intrinsic and synthetic information of the Integrated Model Basis.
Aspects Revisited - The Aspect Constraint Language
TheAspect Definition Languageallows specifying the available Aspects and their value ranges. Furthermore, the concrete values for model elements of the Integration Model, which reflects the instantiated version of the SUT in terms of its structure, are retrieved or specified using theAspect Specification Language. Similar to RBT, where risk assess- ments are used as a basis for the selection of test cases, this concept allows any infor- mation of the Omni Model to be included in the process [18][65].
To describe the test focus and to extract the model parts accordingly, theAspect Con- straint Language is developed. The language enables the user to specify constraints for certain Aspects and to combine them with logical operators. Listing 8.1 shows the grammar that realizes the mentioned functionalities.
In combination with theAspect Specification Language, the name of the Aspect serves as a reference to the respective definition. Starting from the Aspect name, the elementary constraints are described. Depending on the type of the underlying Aspect (ranged vs.
set), different operators can be used to specify the constraint.
1 acdsl: term;
2 3 term:
4 factor (boolbinaryop factor)*;
5
6 factor:
7 constraint | boolunaryop factor | ’(’ term ’)’;
8
9 constraint:
10 cname=ID ’:’ coparator=OP ’[’ cdefpart ’]’ (’:’ clogicop=LOGOP )?;
11
12 cdefpart:
13 ( value=ANYID ’,’)* value=ANYID;
14
15 boolbinaryop: BOOLAND | BOOLOR | BOOLXOR;
16
17 boolunaryop: BOOLNOT;
18
19 BOOLAND: ’&’;
20 BOOLOR: ’|’;
21 BOOLXOR: ’^’;
22 BOOLNOT: ’!’;
23
24 LOGOP : ’and’ | ’or’ | ’xor’;
25 OP : ’le’ | ’lee’ | ’in’ | ’gre’ | ’gr’;
26
27 fragment LETTER : [a-zA-Z\u0080-\u00FF_];
28 fragment DIGIT : [0-9];
29
30 ANYID : ’\’’ ( LETTER | DIGIT | ’.’)+ ’\’’;
31 ID : (LETTER(LETTER|DIGIT)* | NUMBER);
32
33 NUMBER : ’-’? (’.’ DIGIT+ | DIGIT+ (’.’ DIGIT*)? );
34
35 BLOCK_COMMENT: ’/*’ .*? ’*/’ -> channel(HIDDEN);
36
37 LINE_COMMENT: ’//’ ~[\r\n]* -> channel(HIDDEN);
38
39 WS : [ \t\r\n]+ -> skip ; // skip spaces, tabs, newlines
Listing 8.1: ANTLR grammar for the Aspect Constraint Language
For Aspects, which define a continuous value range, a truth value depending on the threshold value (cdefpart) can be derived using comparison operators (coperator:
<(le),<=(lee),=(in),>=(gre),>(gre)).
In contrast, for Aspects with a discrete set of values, only the overloadedinoperator can be used, which checks each concrete value of the Aspect, whether the respective element is contained in the set (cdefpart). For each pairwise comparison, a truth value is derived, which contributes to the overall result. How these partial results are linked to each other can be specified by three logical operators (clogicop:and,or,xor).
The elementary constraints can be combined into complex constraints. The unary log- ical negation operator (!) and the binary operators AND (&), OR (|), and XOR (ˆ) are
applicable. Beyond, parenthesis is supported for clarity and binding.
All in all, the presented language offers the necessary constructs to represent the test fo- cus of the test engineer. Therefore, the user has to develop anAspect Constraint Language expression made available to the automated processing chain. An exemplary applica- tion of theAspect Constraint Languagecan be seen in the course of the introduction of Test Model Scoping in section 8.2.
Execution Graph++-based Test Levels
Besides the constraint-based extraction of a specific part of the Integration Model, the classic test levels are mapped in the context of the EGPP-based representation of the original Test Models. Figure 7.24 in section 7.2.2 shows the concepts behind the EGPP- based Test Models. In particular, the connection to the stub concept is shown, which plays an important role in the further course.
Essentially, a system-level Test Model is defined by the fact that it is not itself integrated into another Test Model but integrates other Test Models. A unit-level Test Model, on the other hand, is integrated into other Test Models but does not itself include any Test Models. Any Test Models that include other Test Models and are themselves included in another Test Model are called integration-level Test Models. Further, there are no restrictions on the number of integration levels in the Test Models.
Analogous to the specification of an Aspect Constraint Language expression, the test engineer must specify the desired test level and make it available to the automated processing chain as a configuration parameter.
8.1.2 Excerpt of the Omni Model
The Omni Model, or Integrated Model Basis, containing the Test Model and its rela- tions to the Integration Model covers the structural relations and relations regarding the specified control flow. All these relations are specified on the original model and are further incorporated into the internal EGPP representation within the context of the M2MTs presented in section 7.2.2.
Furthermore, in the context of Test Model Scoping, the aspects defined and specified in the Omni Model play an important role and have a significant influence on the quality of the scoping results. The quality of these results can be improved by either connect- ing additional model information via the Integration Model, or by maintaining custom Aspect information in the Integration Model for a more precise focus specification.