SOAP

2011-12-22T13:30:07Z

Birgit Endrass:

SOAP

2011-12-22T13:29:27Z

Birgit Endrass:

SOAP

2011-12-22T13:26:58Z

Birgit Endrass:

2011-12-20T12:15:04Z

Birgit Endrass:

Sceneflows

2011-12-20T12:06:00Z

Birgit Endrass:

[[IRIS Wiki]] - [[Computational Models]] - '''{{PAGENAME}}'''
=== Background ===

=== Description ===
A sceneflow is a ''hierarchical'' and ''concurrent statechart'' that consists of different types of nodes and edges. A ''scenenode'' can be linked to one or more scenegroup playback or system commands and can be annotated with statements and expressions from a simple scripting language, such as type- and variable definitions as well as variable assignments and function calls to predefined functions of the underlying implementation language (Fig. 2(1)). A ''supernode'' extends the functionality of scenenodes by creating a hierarchical structure. A supernode may contain scenenodes and supernodes that constitute its subautomata. One of these subnodes has to be declared the ''startnode'' of that supernode (Fig. 2(2)). The supernode hierarchy can be used for type- and variable ''scoping''. Type definitions and variable definitions are inherited to all subnodes of a supernode. The supernode hierarchy and the variable scoping mechanism imply a hierarchy of local contexts that can be used for context-sensitive reaction to user interactions, external events or the change of environmental conditions. Different ''branching strategies'' within the sceneflow, such as ''logical'' and ''temporal'' conditions or randomization, as well as different interaction policies, can be modeled by connecting nodes with different types of edges. An ''epsilon edge'' represents an unconditional transition (Fig. 2(3)). They are used for the specification of the order in which computation steps are performed and scenes are played back. A timeout edge represents a timed or scheduled transition and is labeled with a timeout value (Fig. 2(4)). ''Timeout edges'' are used to regulate the temporal flow of a sceneflow's execution and to schedule the playback of scenes and computation steps. A ''probabilistic edge'' represents a transition that is taken with a certain probability and is labeled with a probability value (Fig. 5(2)). ''Probabilistic edges'' are used to create some degree of randomness and desired non-determinism during the execution of a sceneflow. A ''conditional edge'' represents a conditional transition and is labeled with a conditional expression (Fig. 3). Conditional edges are used to create a branching structure in the sceneflow which describes different reactions to changes of environmental conditions, external events or user interactions.

==== Interaction Handling Policies ====
User interactions as well as other internally or externally triggered events within the application environment can rise at any time during the execution of a model. Some of these events need to be processed as fast as possible to assert certain ''realtime requirements''. There may, for example, be the need to ''contemporarily'' interrupt a currently running dialogue during a scene playback in order to give the user the impression of presence or impact. However, there can also exist events that may be processed at some later point in time allowing currently executed scenes or commands to be regularly terminated before reacting to the event. These two different interaction paradigms imply two different interaction handling policies that find their syntactical realization in two different types of interruptibility or inheritance of conditional edges:
* ''Interruptive conditional edges'' (Fig. 3(1), 3(3)) are inherited with an interruptive policy and are used for handling of events and user interactions requiring a fast reaction. Whenever an interruptive conditional edge of a node can be taken, this node and all descendant nodes may not take any other edges or execute any further command. These semantics imply, that interruptive edges that are closer to the root have priority over interruptive edges farther from the root.
* ''Non-interruptive conditional edges'' (Fig. 3(2), 3(4)) are inherited with a non-interruptive policy, which means that a non-interruptive conditional edge of a certain node or supernode can be taken after the execution of the node's program and after all descendant nodes have terminated. This policy is implicitly giving higher priority to any conditional edge of nodes that are farther from the root.

Fig. 3 shows a supernode hierarchy with different conditional edges. If the condition stop becomes true during the execution of the two innermost scene playback commands, then the scene within the supernodes with the non-interruptive
conditions (Fig. 3(2), 3(4) ) will be executed to its end. However, the scene within the supernodes with the interruptive conditions (Fig. 3(1), 3(3)) will be interrupted as fast as possible. In the non-interruptive case the execution
of the scene ow continues with the inner end node (Fig. 3(4)) before the outer end node is executed (Fig. 3(2)). In the interruptive case the execution of the sceneflow immediately continues with the outer end node (Fig. 3(1)) because the
outer interruptive edge has priority over the inner interruptive edge (Fig. 3(3)).

=== Examples ===

=== References ===

Sceneflows

2011-12-20T12:02:43Z

Birgit Endrass:

[[IRIS Wiki]] - [[Computational Models]] - '''{{PAGENAME}}'''
=== Background ===

=== Description ===
A sceneflow is a ''hierarchical'' and ''concurrent statechart'' that consists of different types of nodes and edges. A ''scenenode'' can be linked to one or more scenegroup playback or system commands and can be annotated with statements and expressions from a simple scripting language, such as type- and variable definitions as well as variable assignments and function calls to predefined functions of the underlying implementation language (Fig. 2(1)). A ''supernode'' extends the functionality of scenenodes by creating a hierarchical structure. A supernode may contain scenenodes and supernodes that constitute its subautomata. One of these subnodes has to be declared the ''startnode'' of that supernode (Fig. 2(2)). The supernode hierarchy can be used for type- and variable ''scoping''. Type definitions and variable definitions are inherited to all subnodes of a supernode. The supernode hierarchy and the variable scoping mechanism imply a hierarchy of local contexts that can be used for context-sensitive reaction to user interactions, external events or the change of environmental conditions. Different ''branching strategies'' within the sceneflow, such as ''logical'' and ''temporal'' conditions or randomization, as well as different interaction policies, can be modeled by connecting nodes with different types of edges. An ''epsilon edge'' represents an unconditional transition (Fig. 2(3)). They are used for the specification of the order in which computation steps are performed and scenes are played back. A timeout edge represents a timed or scheduled transition and is labeled with a timeout value (Fig. 2(4)). ''Timeout edges'' are used to regulate the temporal flow of a sceneflow's execution and to schedule the playback of scenes and computation steps. A ''probabilistic edge'' represents a transition that is taken with a certain probability and is labeled with a probability value (Fig. 5(2)). ''Probabilistic edges'' are used to create some degree of randomness and desired non-determinism during the execution of a sceneflow. A ''conditional edge'' represents a conditional transition and is labeled with a conditional expression (Fig. 3). Conditional edges are used to create a branching structure in the sceneflow which describes different reactions to changes of environmental conditions, external events or user interactions.

==== Interaction Handling Policies ====
User interactions as well as other internally or externally triggered events within the application environment can rise at any time during the execution of a model. Some of these events need to be processed as fast as possible to assert certain ''realtime requirements''. There may, for example, be the need to ''contemporarily'' interrupt a currently running dialogue during a scene playback in order to give the user the impression of presence or impact. However, there can also exist events that may be processed at some later point in time allowing currently executed scenes or commands to be regularly terminated before reacting to the event. These two different interaction paradigms imply two different interaction handling policies that find their syntactical realization in two different types of interruptibility or inheritance of conditional edges:
* Interruptive conditional edges (Fig. 3(1), 3(3)) are inherited with an interruptive policy and are used for handling of events and user interactions requiring a fast reaction. Whenever an interruptive conditional edge of a node can be taken, this node and all descendant nodes may not take any other edges or execute any further command. These semantics imply, that interruptive edges that are closer to the root have priority over interruptive edges farther from the root.
*

=== Examples ===

=== References ===

Sceneflows

2011-12-20T12:00:10Z

Birgit Endrass:

Sceneflows

2011-12-20T11:59:49Z

Birgit Endrass: