primer(1) - compute test primitives using explorer
Table of Contents
primer - compute test primitives using explorer
primer [ options
... ] explorer [ explorer-options ... ]
torx --help
primer starts the given explorer with the explorer-options
and then offers the torx-primer(5) interface on its standard input and output.
The explorer should implement the torx-explorer(5) interface.
The primer
can be used in multiple ``roles''. Usually it will be used to derive test primitives
using the ioco algorithm, (no -a or -S flag is needed: ioco is the default).
It can be used to generate the traces of a specification, without building
the suspension automaton as is done for ioco, for example, to generate
the traces of a test purpose (as in the configuration example below, if
used with a -a " traces" command line flag). It can also be used to execute
a test that was derived in batch mode, by specifying special events (actions)
that denote verdicts in the primer configuration file (see below).
The
following command line options are supported:
- -s nr
- seed for the random
number generator(s)
- -a algorithm
- -S algorithm the test derivation algorithm
to use. Accepted values: ioco, sim (use as simulator), and traces. Default
value: ioco
- -D rundir
- start the explorer in directory rundir
- -f configfile
- the configfile defines the partitioning of the actions over input and output
(and in the future, over multiple mioco channels). It also contains the
representation of the suspension action. The configfile format is discussed
below.
- -T
- enable the ioct algorithm. This algorithm differs from ioco in the
way tau (internal, invisible) actions are treated when the suspension automaton
is built. ioco will not add a suspension action to a state if it contains
an outgoing tau (internal, invisible) transition. If for ioco for a particular
state the presence of such a tau action the only reason is to not add a
suspension action, then the ioct algorithm will add the suspension action
to the state.
- -C iokind
- where iokind is input, output, or input,output enables
input, output (or both) completion. When we want to do a ``next'', we look if
the action that we want to do is in the menu, if so, we handle as before.
If the action is not in the menu, and completion is enabled for this iokind,
then we just accept (``do'') the action, but remain in the current superstate,
and change nothing.
The following obsolete command line options are recognized
but silently ignored:
- -i inputg1,g2,...
- input gate names
this is obsoleted by the -f configfile option
- -o outputg1,g2,...
- output gate
names
this is obsoleted by the -f configfile option
- -d event
- representation of
delta (suspension) action
this is obsoleted by the -f configfile option
- -t iokind
- channel types for
which suspension events should be added
this is obsoleted by the -f configfile option, and is now set automaticly
for the ``known'' algorithms
The (optional) configuration
file contains blocks of name=value tuples. The first name=value pair of
a block should start in column 0 (i.e. not be preceded by whitespace), the
other name=value pairs of a block should be preceded by whitespace. Multiple
name=value pairs may appear on the same line, separated by whitespace.
In principle, the fields of a block may appear in any order. The following
values for name are recognized:
- channel
- the value should be a channel name
(for ioco by convention in for the input channel and out for the output
channel). A block should contain exactely one channel or verdict definition.
- event
- the value is a pattern for the events that belong to the block. The
pattern looks quite a bit like a LOTOS action. The pattern consists of one
or more expressions, where the expressions in the pattern are separated
by exclamation marks ('!'). An expression can be a word (consisting of letters,
digits and underscore), or a word followed by a comma(',')-separated list
of expressions between parentheses ('(' and ')'). In the pattern a star '*' can
be used instead of an expression or subexpression. The number of '!' in a
pattern must match the number of '!' of the event from the specification
that it tries to match. A block may contain multiple event occurences.
- iokind
- the value should be input or output to indicate whether the block lists
input (stimuli) or output (observation) actions. A block should contain
at most one iokind definition.
- suspension
- the value is the event (action)
that denotes quiescense (or suspension). For the algorithms ioco, sim and
traces an action ``delta'' is automatically added for channel out. A block should
contain at most one suspension definition. If the suspmode (see below) for
a channel is recognize, then suspension can be a pattern as described for
event.
- suspmode
- the value should be compute or recognize to indicate whether
suspension actions should be computed or recognized for the channel. For
the algorithms ioco and sim suspmode is automatically set to compute for
channel out; for algorithm traces suspmode is automatically set to recognize
for channel out. A block should contain at most one suspmode definition.
- verdict
- the value should be a verdict: the verdict that is to be associated
with the event name=value pairs of the block. A block should contain exactely
one channel or verdict definition.
The following example primer configuration
file defines two channels (in,out) with their respective input and output
types (iokind=input) resp. (iokind=output), and the actions that ``belong''
to the channels, which are given using patterns. The default algorithm
(ioco) automatically adds the implicit action ``delta'' to the list of output
actions. This value ``delta'' can be overruled by explicitly adding the wanted
value to the channel=out block, for example suspension=my_delta.
channel=in
event=cfsap_in!*!join(*,*)
event=cfsap_in!*!datareq(*)
event=cfsap_in!*!leave
event=udp_in!udp1!*
event=udp_in!udp2!*
event=udp_in!udp3!*
iokind=input
channel=out
event=cfsap_out!*
event=cfsap_out!*!*
event=udp_out!udp1!*
event=udp_out!udp2!*
event=udp_out!udp3!*
iokind=output
torx-intro(1), torx-primer(5), torx-explorer(5)
By Email:
<torx_support@cs.utwente.nl>
This manual page documents version 3.9.0
of torx.
Table of Contents
|
Prev
|
Table of Contents
|
Next
|
|
Appendix D: TorX Manual Pages: preprocmkprimer(1) - preprocess input before invoking mkprimer
|
|
Appendix D: TorX Manual Pages: primexp(1) - provide torx-explorer interface to torx primer
|