next up previous
Next: Task Activity Model Up: SPELL Previous: Inheritance mechanism of

The TaskEntity type

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 1.6 gif.

Figure 1.6: Instance-level attributes and procedures.

As seen in 1.4,the TaskEntity type is a subtype of PM_ Entity.
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 i_ delete 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 existing instance.
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:

ON_PROC = <procName> WHEN = <when>
* COND = <condition> ACTION = <action>
* OVERRIDE = <override>;

<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 holds.
<override> is used for specifying the kind of inheritance through the following semantics:

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:

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 subtle consistency issues into account. We provide a few examples of those issues here, without any claim of exhaustiveness:

Of course, when type-level procedures are not defined, the ones defined in the supertype apply.

next up previous
Next: Task Activity Model Up: SPELL Previous: Inheritance mechanism of

Passani Luca
Mon Feb 20 21:59:27 MET 1995