Flow Annotations

Execution of a use-case starts with the first step of its main scenario and then continues till the end, possibly, visiting optional branches. The execution can be further altered by:

• aborts which prematurely end the scenario -- typically as a reaction to an error;
• includes which incorporate (inline) another use-case in the place of a particular step,
• jumps (gotos) which move execution to a specified use-case step, and
• conditions (guards) of extensions and variations. In textual use-cases, everything is expressed in natural language. In FOAM, using so-called flow-annotations, we can make such information machine-readable.

#(abort)
This flow annotation expresses an abort of the scenario. An abort causes the execution of a use-case to be terminated at the step where the annotation appears. However, if the use-case has been included into another use-case, only the included use-case is terminated and the execution returns to the parent use-case at the step immediately following the including step.

#(goto:s)
This annotation represents a jump within the same use-case. The parameter s indicates the target step of the jump. It should be noted that after finishing a variation/extension, the default behavior is to continue in its parent scenario. It is strongly advised to restrict jumps to the parent scenario, even though in general, FOAM does not impose any restriction on jumps within a single use-case.

#(include:u)
This annotation specifies an inclusion (inlining) of another use-case u.

#(mark:b_i)
We assume the existence of globally accessible boolean variables b_1, .., b_n initialized to false. The #(mark:b_i) annotation sets b_i to true when visited.

#(guard: f(b_1, ..., b_k) )
The f parameter of this annotation is a propositional logic formula over the boolean variables b_1, ..., b_k. The annotation serves as a guard for extensions and variations. That is, a variation/extension can be followed only if the formula f is true.