I-Face and I-View Notes

General notes

difficult ontology issues apply. e.g. the task-matrix needs sequence indicators (no real ordering info, but there is sense in the order of the rows!) It should be able to ask for sequence indicators. The modeller may have provided them. Modeller and viewer must both use the term "sequence indicator" (note: it is not part of the INCA model!)
there will be more than one process per session (created, viewed, and executed) . Viewers must state whether (and how?) they will deal with this

I-View things

A viewer will have:

individual properties which can be used to taylor its visual style

fonts, size of components, colours/colour schemes

some of these are set by system properties by default, e.g. screen size determines window size

available operations, e.g. switch on/off whether the user can

re-order rows in task overview matrix
move nodes in graph
edit the graph (modeller turns viewer)
...

notes of user profiles / preferences on

viewer properties that the user can change
visualisations of individual things (processes in process viewers)

e.g. which tasks are expanded in task overview matrix
e.g. node positions in process graph view (if edited by user)
...

an idea of

the fact that that they can view processes (i.e. they speak some form of INCA that is useful for communication purposes
which aspects of processes they can show

careful with discarding concepts! e.g. order of tasks may still be important when really just showing structural breakdown!

inputs

a set of events that they are interested in

for anything they display: viewers may express interest in events that affect what they are displaying

a set of events that they can cope with
commands/requests that they can service

outputs

a set of events that they can generate
commands/requests that they can issue

viewers may need to query models (process models)

for user interactions:

some will be serviced by the viewer itself (may need to notify the others)
some will be serviced by others, i.e. raise request/command/event

viewers may be closed, opened, re-sized, full-screen/normal size (sun zoom), cloned
...

To provide user level, configurable task and process management aids for inter-agent cooperation.

Panel things

Inputs for the Process Monitoring Panel

(communicable and storable via XML formats where appropriate)

a stream of agent messages providing inputs specifically informing the panel of some noteworthy events.
a stream of "issues" which external agents request that the process panel take responsiblity for.
0..N process specifications/fragments - with related constraints/conditions, and issues for each process.
0..N process product specifications - including descriptions of process product features.
[possibly 0..N process product status life cycle transitions. See Jessica Chen-Burger thesis and IBM's BSDM].
0..N external event monitoring plug-ins to acquire externally communicated messages (e.g. as notified to agent message logging services). The plug-ins provide these events on an internal channel to be streamed in along with the explicitly notified event stream.
0..N mappings between agent monitoring "events" notified explicitly or via plug-ins to the panel and:

begin of execution of a process node/activity
end of execution of a process node/activity
change in a process product feature

Others... Process Panel designs beyond the monitoring aspects (e.g. for active process coordination and control) will be given other inputs related to agent capabilities and constraints.

I-Face things

generic I-Face things are:

are there any generic things?
...

Task Matrix issues

rows and columns of cells (check out word tables for structure and operation, layout, style)

matrix has title and admin info
cells have labels and colour (small marks too? fonts? other?)
rows have labels (two? - left and right?)
columns have labels (two? - top and bottom?)
columns have width
columns can be added
rows can be added
rows can be re-ordered
columns can be re-ordered (not always)
rows can have sub-rows (collapsable)
...

Graph related issues

draw boxes and lines on a canvas

canvas has title and admin info
boxes can have colour, shape, labels (several?)
lines can have colour, shape, labels, direction/arrows, corners
lines happen between boxes
nodes can be moved
line shape can be changed (dog-leg...)
...

Product related issues

display a list of products and their properties

Process product features must include:

Name
Status (to reflect product life cycle)
Content type
Content [expressed as a URL?]

The process product features can also be extended to those features specific to given product types... [feature name. feature value]

Issue list issues

display a list of issues and their properties.
Things happen when you click on issues or their properties (e.g. hyperlink to more detail)

Issues may contain information about the intended performer of an issue, or may leave that to the panel.

Issues are likely to have the following fields:

Issue Reference Number
Issue verb
Issue contents (perhaps defined by a grammar)

Comments - first line being used for short display form
1..N methods by which the issue can be addressed

Some ideas for a sample issue viewer (one of the I-Views) is here.

Issues may be a request to execute a specific process instance - execute(process, parameters).

Communications

Communications of process models are done pragmatically within a panel. External/clean communications of process models are always in XML (also storable stuff for the process library!)

let people write their own in/outputters for their own formats

what about communications about process models?

Things to think about

Process specifications may include constraints/conditions (needed for monitoring aspects) and effects (needed for control aspects later). These constraints and effects may be specified in terms of process product features (often the process product status note). Other constraints such as time, etc, may be provided. Process specifications may also include "effects" which specify changes which should be made to product feqatures, etc.

Each process fragment that the panel knows about has an initial node which is specified as "enabled" or "not enabled". This may be altered at any time by a "process owner". A process must be enabled for an instance of it to begin execution. Once execution starts, that instance will continue until control returns to the initial node. If the process is not enabled at that stage, processing can be suspended. [Is this sufficient, or do we need preemptive termination of process instances for our work?]

The initial node of each process is "orange" (ready to execute) if the process is enabled, and red (not executable) if not enabled.

Process panels only accept responsibility for issues where there is a process that provides a capability to handle that issue. But, they do not guarantee to be able to address the issue when it is processed. They will report the failure or achievement of the issue to the issue provider though.

The status of processes and process products may be tracked by using events, agent activity logs and partial information which can be interpreted as indicating where we must be in one or more processes being executed, and what status process products must have at any stage. This can be done even where significant information is missing.

People

JohnL

multi-lingual presentation of plans
did graph view thing from SteveP's code
option trees for process modelling

did ttask structure viewer
is our interface to users (first instance of user himself)

Jeff

did issue viewer (proper grid!!)
can give us calls, test streams, required events

Jessica

Edify - have visual language foe dialogues, want better underlying plan rep for it and ways to keep records

Jussi

can be user for

process modelling
execution monitoring

Planning & Activity Management | I-X

Page maintained by j.stader@ed.ac.uk, Last updated: 19/1/01