Browse Prior Art Database

Graphical Procedural Capability

IP.com Disclosure Number: IPCOM000120309D
Original Publication Date: 1991-Apr-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 8 page(s) / 378K

Publishing Venue

IBM

Related People

Jones, SA: AUTHOR [+3]

Abstract

A graphical method of defining decision support tasks that involve multiple steps, made easy for the user is described. Normal, silent and unattended modes of operation are supported and routing of output to a device - printer, plotter, shredder or outbasket - is permitted. The output from one object to become the input to another object is allowed, together with the output from one object to be the input to multiple objects. An object may receive multiple inputs and independent parallel chains may also be defined.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 17% of the total text.

Graphical Procedural Capability

      A graphical method of defining decision support tasks
that involve multiple steps, made easy for the user is described.
Normal, silent and unattended modes of operation are supported and
routing of output to a device - printer, plotter, shredder or
outbasket - is permitted.  The output from one object to become the
input to another object is allowed, together with the output from one
object to be the input to multiple objects.  An object may receive
multiple inputs and independent parallel chains may also be defined.

      Procedures are depicted graphically as a set of icons which
represent objects that are to be processed or manipulated.   An icon
can be connected to another to indicate a dependency, which implies
data transfer, so that chains of related tasks can be built.  Actions
to be performed on the objects are not stated specifically, but are
implied by a pair of connected icons.  For example, a report attached
to a printer is translated into a request to print the results of the
report.

      To open an object, a view of the object is displayed on the
screen, and is connected to an icon which represents the screen.
Conversely, if an object is not connected to a screen icon, the
object handler will be invoked in silent running mode so that no
display of that object appears on the screen.  A graphic procedure is
built by dragging icons from windows and positioning them within the
procedure.  They can then be moved, copied or deleted. Icons can also
be selected from a palette of object classes. This can be quicker
when building a procedure because the user does not have to find the
container which holds the real object.  At a later stage, a real
object can be associated with the object class icon.

      Display is based on a grid system, which can be visible at the
user's discretion.  Icons are positioned in empty cells of the grid.
Each cell of the grid is large enough to take a standard-sized icon
and the name of the object it represents.  Links between objects can
be established and broken as required.  If an icon is moved within
the procedure, existing links are maintained and re-drawn, there are
two types of links - Data Transfer and Wait.  Data transfer specifies
that the first object of a linked pair be used by the second object
of the pair, a data table can be used by a chart, or a report
be used by a printer.  Wait links indicate a dependency when no data
transfer is involved.  A Wait link might be specified to ensure that
an object is not discarded until other tasks using it have finished.
Procedures do not have to contain a single chain of related tasks.
Multiple chains can be started and come together, or remain apart.
Execution will start with the first chain and will proceed according
to the dependencies inherent within it.  However, if the procedure
regains control, when the current object handler enters a wait state,
for example, the next independ...