Simple UML Statemachine
MoMuT::UML (“MoMuT for UML”) generates test cases from UML state machines, like the one shown to the right. The UML language features shown in this simple state machine are nesting, signal triggers, time triggers, and entry and exit actions. The given state machine is a model of a car alarm system. In the system’s initial state the doors are open and unlocked. By opening and closing the doors respectively, it is possible to move through the states, potentially triggering the alarm.
Any UML statechart is associated with a type (a class) whose behaviour it specifies. Hence the model of the car alarm system also contains a class diagram that defines the static structure. For the car alarm system example, the class diagram can be seen below. In addition to the car alarm system itself, classes of the test environment (AlarmArmed, AcousticAlarm, OpticalAlarm) and all needed signals (Lock, Unlock, Close, Open) are defined. Notice that the stereotypes “system_under_test”, and “environment” are MoMuT::UML specific and used by the tool to automatically determine the test-interface: Whenever the system under test (“AlarmSystem”) calls a method of the environment (e.g. “AlarmArmed.SetOn”, which is an abstract definition as it doesn’t define any behaviour), this call is mapped to some observable event. In contrast to observables are controllable events which are formed by the signal receptions (or public methods) of the system under test (“Lock”, “Unlock”, “Closed”, “Opened”). In summing up, controllables are input to the system under test, while observable are output of the system under test.
UML Class Diagram with Test-Interface Markup
The model shown here is a very simple one. Typical UML models will comprise much more complex UML state machines and many more classes. That said we want to stress, that the UML model shall only specify what is necessary for testing the system. In other words, it needs to be as simple as possible, only containing aspects that are needed for generating correct test cases. In case of the given car alarm system example this has been considered and, hence, the state machine does not contain a lot of internal, i.e. non-observable, behaviour. Any of the entry/exit actions will produce observables, while almost all the other transitions are triggered by controllables.
MoMuT::UML supports a large subset of UML’s state machine language. For example, MoMuT::UML supports (among others) orthogonal regions, nesting, time triggers, change triggers, signal and call triggers, choices, junctions, OCL expressions, and uses AGSL as a simple action language. MoMuT::UML also honors SysML Requirements annotations and allows mapping of tests to requirements. There are only a few elements that are currently not supported like history states. Some more general limitations concerning the inheritance of state machines and the late-binding or overloading of methods stem from the fact the UML is translated to OOAS for test case generation. However, these limitations should not be of any concern when dealing with test-models.
Test cases generated by MoMuT typically are linear sequences of inputs and outputs. In case the model is non-deterministic, MoMuT is also able to generate so-called adaptive tests, which are graphs. Depending on the test case generation strategy used, these tests are guaranteed to find particular versions of faulty implementations. Details of the technology driving the test case generation are explained under the “Technology” tab. For the given car alarm system, one particular test case looks as follows.
Notice that since the model is deterministic, the test case is linear. All transition-labels starting with “ctr” mark input to the system under test (Close – Lock …) while transitions starting with “obs” mark output of the system under test (AlarmArmed.SetOn, …). Test cases produced by MoMuT::UML are positive which means that as soon as there is output of the system under test that is NOT expected by the test case, the test failed.
As a final remark, the shown test case also resembles the asynchronous modeling style, as the inputs (ctrs) and outputs (obs) can occur in an arbitrary order/interleaving. By default MoMuT::UML will try to reduce these interleavings.