I have posted a
little package (LTSworks.zip) illustrating how eTSM can apply to LTS
monitoring/validation.
I consider this work as a piece of investigation about
requirements.
The package goes
much further than previous email outlining how Dale LTS definitions can be
translated into eTSM.
It also shows how
the eTSM script (to be generated from the LTS definition) will be compiled into
XSLT.
This XSLT
compilation is actually executed here and produces the LTS results (results.xml)
over a sample Event Board itself an XML file (testlog.xml).
My conclusions from this application work:
- the concept of Test Case is not to be equated
with the concept of "monitor" defined as a unit of workflow thread. The Test
Case (or Monutor Case, or TM-Case...) that corresponds to the monitoring
of a multi-message transaction (see these transactions in testlog.xml), involves
several monitors, as this is my recommendation for translating LTS graphs - one
monitor to manage each node or state of the
graph.
- multiple assignements of the same variable as
well as EXIT for the entire Test Case instance, can be emulated in XSLT (in
spite of XSLT model).
NOTES about concurrency and
XSLT:
In my example, all
the monitors involved execute sequentially, not concurrently, simply because of
the template execution model of the XSLT processor. But my hunch is that this
does not prevent from "emulating" an actual concurrent execution of monitors.
Something like an AND-join would be scripted as usual by catching (waiting) for
all end events posted by each "concurrent" thread to be joined, even if these
execute actually in sequence.
A difficulty arise
with OR joins and XOR joins, as you do not know which monitor execution will
"succeed" and yet if each one of the forked monitors are catching events
along the way, you do not want the failed or hanging sequential execution of one
of them to block the others from catching theirs. That could be the case if we
wanted to "XOR-join" the CancelOrder path and the Success0 path in our LTS
example. That calls for a sort of "pooling" of CATCHER templates in XSLT,
derived from all CATCHER eTSM operations that are supposed to execute
concurrently. That will be a compilation challenge in XSLT though not an
impossible one I believe. See my "pooling" of catching either the POresponse
"partial" event of the POresponse "full" event , whichever comes first. This
corresponds to an XOR forking.
Jacques