[ Home | What's New | Contents | Overview | Contributors | Distribution | Examples | Documentation | Manual | Publications | Mailing List Archive | Problems ] This page was last updated by Axel Belinfante on 2006-06-30
TorX Test Tool Information
Prev   Next

primer(1) - compute test primitives using explorer

Table of Contents

Name

primer - compute test primitives using explorer

Synopsis

primer [ options ... ] explorer [ explorer-options ... ]
torx --help

Description

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).

Options

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

Configuration File

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.

Example

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

See Also

torx-intro(1), torx-primer(5), torx-explorer(5)

Contact

By Email: <torx_support@cs.utwente.nl>

Version

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 Valid HTML 4.01! Appendix D: TorX Manual Pages: primexp(1) - provide torx-explorer interface to torx primer