Tornado Software Architecture Requirements

Overview

• 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 sources.
6. 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 copies.
7. 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.
8. 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.
9. 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 reference values.
10. 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 copied data.
11. Honor access validation and authentication mechanisms which may be required by subsystem components.
12. 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.
13. 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.
14. 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.
15. 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.
16. 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.

Document History

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