Action System models, first proposed by Back, have been supported by MoMuT from the very beginning and still form the basis of the UML test case generation, as every UML model is converted to an action system before test case generation can start. The language is very simple as it only supports a hand-full of statements (taken from Dijkstra’s guarded command language), and disallows recursion/loops. With the non-deterministic choice operator, action systems lend themselves very well to the modelling of asynchronous systems.
MoMuT supports an extended action system language that features object-orientation (no late-binding and overwriting, though), complex data types, and three different statement-composition operators (sequential, non-deterministic, and prioritised). It also allows the definition of a simple scheduler.
The figure to the left gives a first impression of our action system language. In this (meaningless) example, three types are defined: (1) TSmallInt, (2) TBaseSystem, and (3) TSubSystem. TSmallInt is defined as an integer with a range of 0 to 256 inclusive. TBaseSystem is an action system with two member variables (a,b), one parameterised, internal (no “obs” or “ctr” keyword before the action identifier) action, called ActionOne, and a simple do-od block where ActionOne is being invoked. ActionOne itself comprises a guarded command that says only if “b > 10” and the parameter “p” is equal to “b” do the non-deterministic, parallel assignment of values “x” and “y” to “a” and “b” shown in line 9. Line 12 inside the do-do block shows the projection feature of the action system language. Line 12 means that the system needs to try all values “t”, with 1 <= t <= 20 and t mod 2 = 0, when invoking the action ActionOne. However, since b is initialised to 0 and never updated again and ActionOne requires that b > 10, ActionOne will never be enabled, regadeless of the value of t and, hence, the do-od block will cease execution right away. The third type, TSubSystem, that is defined shows “subtyping” of action systems and the non-deterministic choice between two assignment statements (line 20). At the very end of the exmple, the sheduler is defined. Not shown in this example are so called methods, which work similar to actions but can have a return value.
Our flavour of action systems are finite structures: We only allow object instantiation at the initialisation of member variables, disallow recursion, disallow loops (there is a fold operator available), and all types are of finite domain, e.g., lists have a maximum length.
Modeling the Car Alarm System shown at the UML page directly as Action System leads to the following model. First, some basic type definitions and the first two controllable events, “Close” and “Open”.
The Car Alarm System as Action System – Type Defintions
The next figure shows the observable “FlashOff” and the do-od block, again using projection.
The Car Alarm System as Action System – Dood Block
Notice the car alarm system’s do-od block will never cease execution as there always is at least one action enabled. Also, the model is very simple and only uses the very basic features of the action system language. Nevertheless, it gives a good impression on how a textual car alarm system model may look like as opposed to the UML statechart.
The test cases produced from the Action System model will look the same as the ones generated for the UML model.