Tornado Software Architecture Requirements
Distribution Support Tools Group
May 5, 1994
This document defines the requirements for the Tornado Software
Architecture (TSA). The TSA defines how to construct an information
system that meets these general requirements:
Develop a long term plan to address the needs of expanding
markets and changing business processes.
Develop a commercial quality cross platform system built upon an
open architecture in a client server environment.
Address customer needs for improved HI functionality, resolve
unmet requirements, and simplify tools distribution.
Solve problems related to multiple data entry, poor product
modeling, and integrity of that data.
Tornado Software Architecture Requirements
The Tornado Software Architecture (TSA) must meet the following
Support the definition of a system comprised of multiple
subsystems, where a subsystem is a modular entity that can be
added or removed without impacting the operation of the system
other than for the specific functionality provided by the
subsystem. A subsystem provides data storage, user interface,
or computational resources. A subsystem is a logical entity
composed of software and one or more physical components. A
subsystem may itself be composed of independent subsystems, all
working in a coordinated fashion to perform a particular
function or functions.
Allow third-party database, HI, and computational components to
be full-fledged participants in the implementation of a system.
This means that the user's perception of third-party components
must be indistinguishable in all important operational respects
from an equivalent scratch-built component tailored to the
needs of the system. A component is not a full-fledged member
of the system if it requires the user to manually invoke some
command, transfer, or other procedure in order to complete a
previously initiated independent task.
Support multiple HI presentation techniques and systems. An HI
may employ graphics, text, voice recognition and response, or
other technologies as appropriate to the needs of the user.
Computational services must be memoryless. All inputs must be
presented explicitly at the time of the request for the
computational service. The result of a computational request
must depend only upon the inputs to a computation, and must be
independent of all previous computational requests. Any
intermediate results, in order to persist across requests for
computational services, must be stored in a database.
Access related data stored in disparate locations. It must be
possible to store portions of a database on a local disk as
well as on one or more corporate databases, and to integrate
these multiple sources according to the needs of the user. The
system must not require the construction of new database tables
for the sole purpose of relating data from multiple independent
Preserve the integrity of data which has a defined originator
(a reference, master, or originating source). Such data copied
to local storage (e.g. for performance reasons or for operating
a portable computer away from the corporate network) must
retain its association with the reference source so that any
updates can be propagated from the reference source to local
Allow the substitution of appropriate values to update missing
or inaccessible data. Depending upon the subsystem design, the
substitution may be provided by the user or computed.
Allow a data value to be declared undetermined. If an
undetermined value is used in a calculation, the results of the
calculation must be declared undetermined. An undetermined
value which is printed, displayed, or exported must be
explicitly and visibly marked as undetermined.
Reconcile substitute or undetermined data and derived results
when reference data becomes available. Reconcile derived
results when local copies of data are updated with new
Provide for user notification or approval when a subsystem
needs to update previously unknown, substituted, or copied
data. If dictated by the subsystem design and business rules,
the user must be able to retain previously substituted or
Honor access validation and authentication mechanisms which may
be required by subsystem components.
Communicate data, control, and signalling information between
subsystems using a format which is self-describing. New (or
modified) subsystems can introduce messages having new meaning
to the system without the need to recode subsystems that do not
use the new messages.
Subsystems must interact with each other using a communications
channel. The channel need not employ a media-based transport
when subsystems reside on the same host, but all data, control,
and signalling information must be ultimately representable as
a sequence of bytes or characters.
Interpret and act upon data under the control of validation
attributes or procedural descriptions that are themselves
stored as data. This allows incremental changes to business
rules without having to recode subsystems.
Affect the user's perception of data as seen through the HI by
using presentation attributes to control the appearance of the
data. Presentation attributes may be specific to particular HI
techniques or systems; equivalent attributes may be
differentiated according to the HI system in use.
Presentation information must be stored only as attributes,
never as primary data. All primary data represents objects of
interest to the business (e.g. product structure breakdowns,
customer records, network topologies) The form in which
these objects appear to the user is a function of the HI system
and any applicable presentation attributes.
Created 1994 02 14 by DBL
Reviewed 1994 02 15 by DBL, JDS, RWS
Revised 1994 02 16 by DBL - incorporate review comments
Approved 1994 02 15 by DBL, JDS, RWS
Revised 1994 03 07 by DBL - RISC changed to CRIS
Inspected 1994 03 16 by Tornado team
Revised 1994 03 16 by DBL - incorporate inspection comments
Reviewed 1994 03 17 by moderator (RGF)
Revised 1994 03 18 by DBL - incorporate moderator review comments
Inspected 1994 03 25 by Tornado team
Revised 1994 03 25 by DBL - incorporate inspection comments
Baseline 1994 03 28
Corrected 1994 05 05 by DBL - editorial per RWS
Converted 1997 03 03 by DBL - converted to HTML