Version 5

    Guvnor is to support simulation and testing (see http://docs.jboss.org/drools/release/5.4.0.Final/droolsjbpm-introduction-docs/html/releaseNotes.html#releaseNotes_5.4.0_Expert).

     

    See https://issues.jboss.org/browse/GUVNOR-1910.

     

    This document captures the principle requirements and components.

     

     

    User-interface

     

    A new asset type is required to represent a simulation test. The asset can be authored and executed within Guvnor.

     

    A new screen(s) is required to visualise and define a timeline (consisting of one or more paths, each with one or more steps, each with one or more commands).

    Note: due to GWT restrictions when compiling to JavaScript, a GWT specific Path, Step and Command model has been created.

     

    There are some GWT-enabled "time-line" libraries available:

     

    There is no requirement to convert existing Test Scenarios to the newer Simulation Tool.

     

     

    Test data

     

    Commands can be composed and values defined using pluggable bean builders (for which there would be one per existing simulation command. Pluggable to support the addition of future commands).

        Note: Some commands are implicit, such create a knowledge base, builder and session for the chosen package "mortgages".

    Note: the GWT user commands map to multiple existing simulation commands. For example asserting that a rule has fired. The implementation deals with this.

     

    Bean builders facilitate defining data for a single command.

     

     

    Bulk test data-entry

     

    In addition to defining data for individual Commands it should be possible to define data in bulk.

     

    Bulk data for a simulation is effectively a sparsley populated cube of data, consisting of vertices for "Fact-Fields", "Fact-Field-Values" and "Command".

     

    Bulk data entry should be possible in a tabular form where columns define one axis of the foregoing cube and rows another.

     

    For example: columns represent "Commands" and rows represent "Fact-Fields". The values in the table therefore represent "Fact-Field-Values".

     

                  | InsertFactPerson    | InsetFactVehicle    | QueryFactCoverage

    --------------+---------------------+---------------------+------------------

    Person.age    | 18                  |                     |

    Vehicle.make  |                     | BMW                 |

    Vehicle.model |                     | M3                  |

    Cover.level   |                     |                     | LOW-COVER

     

    Another example: columns represent "Fact-Fields" and rows represent "Fact-Field-Values". The values in the table therefore represent "Commands".

     

                  | Person.age        | Vehicle.make        | Vehicle.model      | Cover.level

    --------------+-------------------+---------------------+--------------------+------------------

    18            | InsertFactPerson  |                     |                    |

    BMW           |                   | InsertFactVehicle   |                    |

    M3            |                   |                     | InsertFactVehicle  |

    LOW-COVER     |                   |                     |                    | QueryFactCoverage

     

    Data can be either entered manually, uploaded (consider CSV and XLS) or retrieved from a remote source (consider JSON, REST).

     

     

    Overlays

     

    Overlaying bulk data

     

    Data entered manually and individually for each Command's definition clearly has an explicit corrolation with the simulation step to which it relates.

     

    Bulk data's corrolation to the simulation steps to which individual components relate is much looser.

     

    A mechanism must be provided for batch data to be mapped to the simulation defintion. Furthermore, once a mapping has been created, it should be possible for different sets of bulk data to be overlaid on a simulation definition.

     

    Overlaying Paths

     

    A single simulation can be comprised of one or more Paths.

     

    It should be possible to combine different combinations of Paths. Thus it might be advantageous to consider authoring as a single Path, whereas runtime as a combination of selected paths.

     

     

    Parameters

     

    Some Commands may result in a bound Fact or Field.

     

    The simulation editor should be capable of allowing subsequent Commands to reference a bound Fact or Field.

     

     

    Runtime

     

    The following modes of execution should be supported:


    • Fire and forget: like JUnit, results of test assertions gathered and displayed as simulation runs.
    • Walk-through: like JUnit in debug mode, with break-points on Path's Steps' Commands.
      • Parameter \ state viewer during debug mode:-
      • View Drools Expert Agenda
      • View Drools Expert Audit (Agenda Listener derieved)

     

    Extra requirements

     

    1. The timeline needs 2 views: a page view and a global view. The page view shows a zoomed in portion of the timeline and the global view show the entire timeline.