With the term process model we indicate the internal
computer description of an external process.
The internal process model is basically a typed network of chained and decomposed activity descriptions (see figure 1.2).
Figure 1.2: Network of decomposed and chained activities.
Tasks represent, in its most general sense, any PM activity.
Both human performances and tool activations are represented by
Products represent any software items produced by the process. We can say that products ``link'' activities, meaning that any activity needs some software item to work with and produces some other software item possibly needed for another activity.
A task type in SPELL expresses knowledge about a basic or composite step in the software process and the tools, the agents and the roles necessary for the enactment of the process. It also contains the information necessary for its activation and the code (or script) which must be executed to carry out the represented activity. It defines static and dynamic PRE and POST conditions around a CODE part, and serves as a tool signature or envelope. Static PRE and POST conditions are exploited for forward and backword reasoning without executing the script. Dynamic PRE and POST condition are convenient for dynamic triggering of tasks.
A task instance (or, simply, a task) is potentially active and stands in a task network or plan. The network uses product nodes to ``connect'' neighbor task nodes, and it can partially be automatically generated. FORMALS and DECOMPOSITION type constructors (static constraints expressing a graph grammar) and static PRE/POST-conditions regulate the structure and control flow of the task network (see figure 1.3).
Figure 1.3: Basic structure of a task.
Task execution can take place at any task node, not only at the
leaves. Network control-flow can be busy, periodic, opportunistic or
lazy (goal-oriented like Unix make). Task execution can be
automatic (derivate) or manual (human actor) with
arbitrary review or negotiation procedures.
The sequential code of a task is responsible for causing its dynamic POST-condition to become true. This may cause the dynamic PRE-conditions in other tasks to become true and so on. The CODE of a task may re-execute repeating the pattern above. It will typically execute procedures defined by the types of its input and output ``parameters'', i.e. the product nodes which constitute the input and the output of the task).