![]() |
|||
![]()
|
![]() |
![]() |
![]() |
3.3.1. Separate Systems (Phase 1) Figure 5 identifies various models of separate ES and MM systems. Forms 1a and 1b illustrate the stand-alone and independent use of ES shells and MM systems that were dominant in the past. There are now thousands of Form 1a operational ES and a growing number of Form 1b MM systems that use authoring systems for program development and control. Form 1c is translational in nature; i.e., an application is initially developed with one tool and, after content and structure translation, migrated to another. With Form 1c, the order of system development may not be important unless requirements call for a specific final user system design, early application viability, or functionality testing. If functional testing is important, the ES should be developed first in order to take advantage of the rapid prototyping and validation/verification methodologies customarily used in the ES development process. For obvious reasons, and those discussed earlier, separate system models lack real integration synergy even though certain development advantages exist. Separate system models do, however, represent embryonic development stages of integrated systems. 3.3.2. MM Integration (Phase 2) MM integration shown in Figure 5 is the present state of the technology marriage. Form 2a uses the functionality built into most ES development tools to call external executable programs. As Bielawski and Lewand (1991, p. 95) note, "It is this feature that enables developers to transcend the constraints of a rigid expert system paradigm and to create systems that are more intelligent." In this manner, access to formatted alphanumeric data and unformatted text is retrieved and updated. Usually, this form of integration allows access to only one media type at a time. However, calls to executable programs allow access to various static and dynamic media (still images, drawings, animation, full-motion, and audio) stored on laserdiscs, and WORM devices. These program "hooks" allow more robust program functionality and provide a synergy not previously possible without time-consuming and costly raw code or symbolic program development. Loosely coupled models, Forms 2b and 2c, allow dominance by either technology. In these designs, the external call concept is expanded to take advantage of ES hooks to databases and spreadsheets. The database context allows the passage of bi-directional data to one or more shared database file(s), which can be resident on either PC or mainframe systems. An example of the Form 2b integration model is the development of a PC-based intelligent visual database management systems (IVDBMS) that uses ES to classify and retrieve still pictures and alphanumeric data from a shared database.
Forms 2d and 2e represent embedded designs that result in a more seamless integration of MM and ES than external calls and loose coupling can accommodate. The essence of these embedded designs, which is important to both developers and users, is that the interface is transparent with control maintained by the dominant system and supported by the other. An example of an embedded system would be one in which either the ES or the MM system contained an embedded database or subprogram that was of only secondary importance to the other. 3.3.3. HM Integration (Phase 3) Near-term HM integration models that link two or more media in an associative way are shown in Figure 5. Forms 3a and 3b represent tight coupling paradigms of virtual seamless integration. Similar to previously discussed embedded systems, direct data and parameter passing are used between systems. However, unlike embedded design Forms 2d and 2e, these models take advantage of the associative links inherent in HM systems. The specific form used is determined by the dominant application methodology. For example, knowledge-intensive applications would use Form 3a where the ES is supported by HM. Conversely, media-dominated applications (for example, one which is text or data intensive) would use Form 3b where ES support the HM system. Form 3c represents complementary integration where one system supports the other in a joint-venture manner. In these systems, MM is part of the application itself (e.g., animation of the simulation process), while the ES performs some advisory task (e.g., dealing with selection of models or giving advice about the length of the simulation). Form 3d, another near-term design possibility, is a hybrid that combines the features of complementary integration (Form 3c), embedded designs (Forms 2d and 2e), and tightly coupled features (Forms 3a and 3b) in an HM context. For this database supporting design, a complementary ES and HM system is used to interface in a seamless way to existing "legacy" corporate databases and information systems, primarily through the use of 4th-generation structured query language (SQL). In this model, the ES provides procedural control of the system and access to the corporate database. HM elements support a flexible user interface and provide access to online help. While many ES tools support SQL query and database access, none presently possess complementary HM functionality. As a result, applications of Form 3d are limited.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |