MBAT Overall Process


Origin: Jens Herrmann / Daimler, Brian Nielsen / Aalborg University

Also Known As: MBAT’s combined model-based Analysis and Test approach

Written: October 2014

Purpose: The “meta-pattern” of the MBAT methodology. In principle, all other AT-patterns are related to this pattern.

Context/Pre-Conditions: Critical system development, where several analysis and test methods/tools are already used, but with either too high costs or insufficient quality or efficience.

To consider: Tools from different sources usually speak different languages; hence their useful combination needs good guidance (enforcing tool combination at any cost likely fails).


Participants and Important Artefacts

(Initial) Requirements: Those properties, for which the fulfilment by the target system has to be shown with the combined analysis and test methods. Requ.s can be functional or non-functional. If the system is to be V&Ved at several levels (e.g. model, component, code), requirements for a certain level can be derived from objectives of the higher level, and itself define the objectives for the next lower level.

V&V Plan & Status: Documentation that assigns V&V steps (analysis or test) with requirements, and V&V steps with tools. This may occur hierarchically. It may define a V&V flow, and collects V&V results traceable.

A&T Model(s): Artefact(s) that describe(s) relevant system properties at a level of abstraction appropriate for the application of A&T tools.

Analysis Case: A particular static analysis step.

Execute Analysis: The act of executing an analysis step.

Test Case: A particular dynamic test step.

Execute Test: The act of executiing a test step.


Actions / Collaborations

(1) The V&V plan is established by deciding for each requirement how it‘s fulfilment can be shown best. For that purpose, an appropriate combination of analyis or test methods is chosen. If this is is not possible due to the requirement‘s complexity, it is restructured into more detailed requirements, for which this step is repeated.

(2) A&T models are prepared. This can be achieved using various sources and techniques, from manual creation to automatic derivation, e.g. from requirements. Validation of models should be considered, in particular if generated manually.

(3) A&T steps are executed, presumably after some preparation and usually according to a given workflow. They use the A&T models and provide results, which are recorded with the V&V plan.

(4) Depending on these results, the V&V plan and even the A&T model(s) require a modification, and a subsequent optimising A or T step may be initiated exploiting the results from the current step.



– Steps 3 and 4 are repeated until all requirements are fulfilled or a violation is encountered that enforces a modification of the SUT.

– If a requirement violation exhibits incorrect requirements, these are corrected and the process continued.

– Steps 1 and 2 have no strict order.


Application Examples

All MBAT use cases apply the MBAT overall process.


Relations to other Patterns

To some extent, all A&T patterns are related, usually as sub-patterns.