![]() |
|||
![]()
|
![]() |
![]() |
![]() |
3.1.5. Full Integration In a full integration software architecture, as indicated in Figure 2, both systems are integrally linked. The ES and MM elements act in virtual unison, share data and knowledge representations, offer communication via their dual structure, and allow cooperative reasoning. An example is an interactive intelligent tutoring system in which various media forms, including test questions, are presented to a student by the MM system, while an embedded ES system continually monitors progress and performance and prescribes remediation. With this architecture, interactive exchange between system elements is done in real time and in a seamless way without user interaction. As indicated in Table 2, this architecture represents the highest integration possible (Level 4). Advantages include robustness, excellent runtime performance and resource utility, no redundancy in parameter or data processing, and improved problem-solving potential. From a design perspective at this level of integration, the designer is concerned with only one virtual environment -- better design and implementation of the overall application is possible. Also, a more uniform user interface and reduced system maintenance can be achieved with better design and implementation of the overall application. This architecture is not without some disadvantages. Experienced and proficient developers and programmers are needed to create and implement such a high-level and interactive architecture. Other disadvantages include specification and design issues, increased development time, lack of existing commercially available tools, validation and verification issues, and maintenance compatibility. 3.2. INTEGRATION ORIENTATIONSThe benefits of integration depend on specific system design orientations and their functionalities. From a user perspective, Figure 3 illustrates three integration orientations: (1) ES supported by MM, (2) MM supported by ES, and (3) complementary (joint venture) systems. In the first two orientations, one technology is dominant over the other. Both share equal status in the last orientation, with each technology executing different tasks to support the other. 3.2.1. ES Supported by MM Figure 4 illustrates the support MM can provide to ES. For discussion purposes, the structure of an ES is divided by a dashed line between the development and consultation environments. A series of numbered MM symbols shows the points of MM support during these ES phases. 3.2.1.1. Support to the Development Environment Providing knowledge. Knowledge for ES is acquired from two major sources: undocumented (experts) and documentation (e.g., manuals, procedures, databases, video/films, and textbooks). In many ES developments, multiple sources of undocumented and documented knowledge are used in the same application. Undocumented knowledge may be in various MM forms such as taped interviews (audio), interview transcripts (text), and knowledge structures and mental models (diagrams). Documented knowledge sources include an even larger variety of MM forms, including text, illustrations, still pictures, motion film, video, and audio recordings. It is becoming common for these analog and digital forms of knowledge to be stored magnetically and optically (MM 1 in Figure 4). If documentation knowledge is represented in one of these media forms and storage formats, it is easier to use than if it is resident in people who may not be available when needed or at all.
Acquisition of knowledge. One of the most difficult tasks in building ES is to acquire knowledge from human experts. Knowledge acquisition is a discovery activity that has been widely used to transfer knowledge from a source of expertise to a representational form. MM technologies have the potential to support this process (MM 2 in Figure 4) and include:
Representing the knowledge base. While traditional ES mainly use rules in their knowledge base, newer systems are venturing into the use of MM devices for knowledge-base rules and media storage and retrieval (e.g., CD-ROM, EROD, and WORM drives [MM 3 in Figure 4]). An example is the knowledge-based system described by Dean (1992) that writes specifications for building construction. The system stores rules and current specifications on a CD-ROM disk. Other knowledge representation such as frames and semantic networks may be stored as MM schema and object-oriented programming formats (e.g., icons [MM 3 in Figure 4]).
|
![]() |
|
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. |