Formal analysis and verification of embedded systems for healthcare

output abstract input concrete output concrete input Test Model (AML) Model-based Testing Tool Adapter Implementation Figure 2.18: Model-based Testing In Fig. 2.17 the behavioral specification is enclosed in a block labeled by 'ready'. This block consists of a non-deterministic choice between the rules of the DSL model. The guarded statement inside each option describes a rule and only allows the rule to be chosen if it is active (i.e. the guard evaluates to true). The first option in the non-deterministic choice describes the first rule from Fig. 2.4. Observe that we have extended the specification of the first rule with two sequential compositions. This indicates that after evaluating the do clause an output action is performed and then the behavior of the 'ready' block is repeated. The folded blocks also have these sequential compositions as their last steps. This enforces the alternating execution of the input and output actions as specified by the processes PIn and POut in Section 2.4. 2.6.3 Interpreting the Results of Model-based Testing Validating the compliance of an implementation to a DSL model by model-based testing requires extra care to interpret the results correctly. A failed test case shows a discrepancy between the behavior described by the test model and the behavior implemented in the implementation. This can have three different reasons: • a mistake in the transformation from the DSL to the test models; • a failure in the implementation; • a modeling mistake in the DSL model, which is cascaded to the test model. The transformation from the DSL to test models should preserve the semantics of the DSL. A mistake in realizing the semantics may result in failed test cases. In Section 2.7 we introduce an approach to gain more confidence in the correctness of the generated models in Fig. 2.5. When there is sufficient confidence in the correctness of test models, a failed test case may indicate a failure of the implementation. The last item mentioned above is particularly relevant if implementations are not generated from the DSL. In such cases, failed test cases could also indicate a mistake in DSL models; the intended behavior is not correctly described in the DSL (and the same modeling mistakes are cascaded to the test model) but the implementation has correctly realized the behavior.