Next: Task Activity Model
Previous: Inheritance mechanism of
A simplified picture of the TaskEntity type is presented in
a series of fragments (the code was split to facilitate the
illustration). The first fragment is presented in figure
Figure 1.6: Instance-level attributes and procedures.
As seen in 1.4,the TaskEntity type is a subtype of
The only instance-level attribute of TaskEntity type is
Taskstate. It conveys information about the state of the task during
the process enactment.
The instance-level procedures start, stop and restart
are used to control task execution. i_ convert and
are used to delete and convert the instances. As can be imagined, the
implementation of such procedure must take into account many issues
about how to maintain consistency when we modify the type of an
Another important features of SPELL are triggers. Triggers are
special operations invoked before or after the occurance of a procedure call.
They are usually employed for exception-handling and
change-propagation. A trigger has the form:
<procName> WHEN =
<condition> ACTION =
<procName> is the name of a type-level or instance-level procedure
defined within the type or in a supertype.
<when> can be either before or after. It states
when the trigger action should be executed, with respect to the
procedure call execution.
<condition> is the condition to be evaluated, specified in Prolog.
<action> is the action to be performed if the condition
<override> is used for specifying the kind of inheritance
through the following semantics:
- true: The
<action> only must be performed (thus
<action>s eventually defined in the
- false: The
<action>s defined in the triggers of
the supertypes must be executed immediately afterwards the one
defined in the current trigger.
Type-level attributes (1.7) are the building block of EPOS-PM.
Figure 1.7: Type-level attributes
We illustrate the meaning of each attribute:
- Static pre- and post-conditions: they are used
by the Planner for building the task network.
For this to be possible, the input and output products
to the various tasks are in a situation of overall consistency (both
for number and state). The Planner builds the task network by matching
the pre and post conditions of the various parameters..
The evaluation of these attributes is not supposed to yield
- Dynamic pre conditions are checked by the Execution
Manager at run time. The task execution cannot start if the dynamic
pre-condition is not satisfied. It can yield side-effects, thus
allowing to evaluate differently on different occasions.
It has two parts: temporal and non-temporal. If the condition is not present in the definition, the one
defined in the nearest supertype which defines it, is applied (by
transitive closure, as expected). The default dynamic pre-condition
for an interactor (1.4) succeeds if all of tasks
which produce at least one of its inputs have terminated and its first
input has a satisfied status.
- Dynamic post conditions have been introduced, but their
usage has not been clearly defined yet.
- Code: it defines the set of actions performed when the
task is executed. In
practice, it is constituted by Prolog code used as a sequential
language. The code part is divided into three parts to support the
needs of both high-level and leaf tasks:
The code attribute is the one which makes the definition of the
inner inheritance mechanism really useful. The supertype defines some
general purpose code and the subtype ``customizes'' it for its
- Pre-Code: when an high-level task is executed, it
invokes the Planner to instantiate its children (
Decomposition attribute). If some action must be performed
before the Planner starts, the corresponding code must be inserted
- Main-Code: For high-level tasks this part must be
empty. For leaf tasks, it contains the code that must be
- Post-Code: It is responsible for setting the values of
the post-condition. High-level tasks can use this part to
perform some action when its children have terminated.
- Decomposition: It is used for high-level task types to
specify and/or constrain the
vertical breakdown. When the Planner tries to decompose a task,
it only considers the types defined within this type-level attribute.
Modelling subactivities is, thus, straightforward.
- Formals: It models the specification of the transformed
products. It constrains the product types of actual
in/out-parameters of a given task. It is used by the Planner to
generate task networks (in conjunction with pre and post-conditions),
in that it defines the horizontal task network construction.
The in and out keywords discriminate the two set (input
and output) of product-types.
- Executor: It explicitly specifies the name of the external
tool which will be invoked and the parameter bindings of its
input and output. Bindings is composed of a set of keyword which
have following semantics:
- outN or inN:
- (N is a number) means a filename of the n-th output
or input respectively.
- outs or ins:
- denotes filenames of all outputs and inputs
- will be replaced by the list of input filenames which
are newer than outputs.
This attribute refers to the kind of humans involved in the
interaction with the task type. EPOS has not emphasis on roles. This
attribute is mostly used to enforce constraints about who has the
right to accomplish a well-determined action or use a well-determined
This attribute gives information about the execution strategy that
instances of the task type will adopt. The feasible values are
goaldirected and opportunistic. A goal-directed execution does
not allow tasks to be re-executed automatically. In fact,
a goal-directed task is re-executed whenever its
pre-conditions are fulfilled and when its execution is explicitly
requested. When a task has finished its execution, its state will be
terminated; only if a request of re-execution is made, the task
state will change from terminated to initiated, and only
then its pre-conditions will be checked again.
portunistic execution is less constrained than the goal-directed
one. Opportunistic tasks may be re-executed when its pre-conditions
hold. After the execution of the task, its state changes from
active to initiated, i.e. it is automatically reset.
This is a boolean value, used within the DYNAMIC_PRE
conditions. If it is set to true, it means that before it starts
its execution, the task must wait for all its predecessors to be
terminated. The four possible combinations of the values of
Def_strict and Def_strategy yield four different strategies for the
The last part of the taskEntity type is composed by the
type-level procedures (figure 1.8).
Figure 1.8: The TaskEntity type
These procedures operate at the Meta-level, since they are used to
manipulate types, i.e. the process model itself. Their semantics is
suggested by their names: the first three deal with creating,
deleting and changing types. The last one is used to define instances
of the type which defines it. Their implementation must take rather
issues into account. We provide a few examples of those issues here,
without any claim of exhaustiveness:
- How should instances be modified when the corresponding type is
changed? In a few cases such modification is impossible and the
type should be prevented from changing (modification of
instance-level attributes); in other cases we should ``roll back''
what already accomplished by the task (modification of the Code
- The deletion of a type cannot take place if subtypes
have been created.
- The deletion of a type cannot take place if some relation
(1.10) involves the type (but not its supertype).
Of course, when type-level procedures are not defined, the ones
defined in the supertype apply.
Next: Task Activity Model
Previous: Inheritance mechanism of
Mon Feb 20 21:59:27 MET 1995