Overview

This page contains some notes on how elements of the Task Planning spec might be visualised. Below, some classes are shown with property lists; those highlighted in yellow could be visualised in the diagrammatic form of the Task Plan; other properties would be shown in the usual way in a config panel on the side.

Logical Containment Structures

Work Plan

The top-level formal concept defined is the Work Plan, which

Task Plan

Within a Work Plan, each included Task Plan is a definition of work to be performed in a single work context, by a 'principal performer' and possibly other participants. Characterised by:

The other properties can be shown on a meta-data panel. Ignore properties whose names are in grey.

Task Group

The principal type of container of Plan Item Nodes in a Task Plan. A Task Group is characterised by:

Nodes

Decision Nodes

Technically, these are currently special kinds of Task Group, but we will probably change that in v2. The general concept is a decision group consists of a root node followed by 2 or more branches. Each branch does work like a Task Group in that it contains elements.

Condition group / Condition Branch

This is like an if / then / elseif statement, where every branch contains a Boolean-valued expression, eg. '$sys_bp > 160 or $body_temp > 40', '$sys_bp > 180' etc.

For this kind of structure, each outgoing branch carries a potentially complex expression (might be too big to display by default in its entirety)

Decision Group / Decision Branch

This structure is like a case or switch statement: the root node carries a single potentially complex expression of the form $xxx = a + b / c whose result can be Boolean, Numeric, Time duration etc, and the branches contain range expressions like 

You could display the ranges in other ways e.g. $xxx matches |0.0 .. 100.0| or similar.

Event Group / Event Branch

This is a wait state, each branch is like a when/then rule. When one of the conditions becomes True, that branch is followed. The 'when' part is expressed as a 'Task Wait' entity (see below).

Task

A Task is a 'doing' object, i.e. represents an item of work. There are different kinds of Task, in two groups - Dispatchable (someone else or something else will do this Task) or Performable (the principal_performer will do the task).

The sub-types are only 5 - 3 kinds of Dispatchable and 2 kinds of Performable Task:

Dispatchable Task

Hand-off

In addition to Dispatchable Task properties, Hand-off has a 'target' reference to another Task Plan in the same Work Plan - one with a different principal performer. Maybe visualise with arrow + icon representing Task Plan? See also Sub-plan below.

External Request

In addition to Dispatchable Task properties, an External Request has some properties representing the external organisastion to be sent a request. The organisation name could potentially be displayed.

System Request

In addition to Dispatchable Task properties, a System Request has a reference to a System Call, which defines a call into another system. Maybe display as some kind of icon representing the idea of a call into a system, include the SYSTEM_CALL.name (i.e. which system)?

Performable Task

All performable Tasks (Sub-plan and Defined Task) have the following items that could be visualised. 'action' is visualised by visualising the concrete subtype, below.

Sub-plan

In addition to Performable Task attributes above, Sub-plan 'target' is a reference to another Task Plan - could be visualised with an arrow and icon for TASK PLAN?

NB: A sub-plan is a more detailed part of the current plan - same principal_performer.

Defined Task

In addition to Performable Task attributes above, the 'prototype' is a reference to one or more existing archetypes; it might be visualised with the standard icon for ENTRY subtypes, i.e. OBSERVATION, EVALUATION etc - as used in ADL-Designer. Clicking that or hover might display the archetype id.

Task Wait

UML diag ref; UML class spec.

Object representing a point in time in terms of one or more events. The start_window is used to add an 'acceptable delay' time within which the Task should be start with respect to the intended start time. The timeout attribute can be used for non-deterministic Events.

Events

UML diag ref;

The various kinds of Event in a Task Wait object can be specified in the following ways: