- Email: [email protected]
Visual programming environment for hybrid expert systems
Expert Systems With Applications, Vol. 10, No. 3/4, pp. 481-486, 1996 Copyright © 1996 Elsevier Science Ltd Printed in Great Britain. All fights reserved 0957-4174/96 $15.00+0.00
Pergamon
S0957-4174(96)00028-0
Visual Programming Environment for Hybrid Expert Systems YOSHIYUKIKOSEKI,M [ D o m
TANAKA, YASUYUKI MAEDA AND YUICHI KOXKE
C & C ResearchLaboratories,NEC Corporation,4-1-1 Miyazaki,Miyamae-ku,Kawasaki216, Japan
Abstract--This paper proposes an architecture for hybrid expert system development which combines expert problem-solving functions and other conventional computational functions by visual programming technology. The visual programming technique is used both for task-specific knowledge representation and for procedural programming for connecting functional components. In knowledge representation, knowledge is visually represented in the form of decision tables and decision trees. In procedural visual programming, each functional object is displayed as a box-shaped icon with accessible ports which are connected by wires on the graphic editor. Based on the architecture, an expert system shell for the classification task, called HOLON/VP(DT), is incorporated in a visual programming system called HOLON/VP. This paper briefly describes the tool and its evaluation based on some application systems developed with the tool. Copyright © 1996 Elsevier Science Ltd
1. INTRODUCTION
• provide interface with other development systems by function call library.
in the 1970s, a large number of expert systems have been deployed. Experience gained in the development of those systems shows that the development of general functions, such as user interface, database access and simple data manipulation, requires much more effort than the development of the problem-solving part. Although conventional expert system tools provide many convenient functions for developing the problem-solving part, considerable effort is needed to implement those "hybrid" expert systems, which combine problemsolving functions with conventional computational functions. The objective of the research described in this paper is to provide an expert system tool which enables computer-novice domain experts themselves to create their own expert systems. Since domain experts are usually not computer experts, the tool should provide an environment for novice computer users to easily create a hybrid system. In recent years, a number of tools have been developed for knowledge base development. However, few attempts have been made to provide a hybrid expert system development environment. Most of the conventional tools take one of the following approaches: SINCE THE ADVENT OF EXPERT SYSTEM TECHNOLOGY
All of the approaches are simple extensions of conventional programming techniques. In any case, programming must be done by an embedded textual programming language, which may be LISP or C language. This paper introduces a novel expert system tool architecture, based on a visual programming technique. Based on the architecture, a visual programming system, named HOLON/VE was developed. This tool includes a classification task-specific expert system shell called HOLON/VP(DT). This paper describes the tool and its evaluation based on some application systems developed with the tool. Section 2 introduces the general architecture based on an object-oriented visual programming approach. The visual knowledge representation of the classification task-oriented problem-solving tool is described in Section 3. Section 4 illustrates the HOLON/VP visual programming tool in detail with some examples. Section 5 summarizes the advantages and disadvantages of the architecture and presents an empirical evaluation. Section 6 concludes by pointing out several areas for further work. 2. GENERAL A R C H I T E C T U R E
• provide conventional computation tools around the problem-solving tool • provide problem solver on a pre-existent program development environment
2.1. Requirements The requirements for a hybrid expert system development environment are listed below: 481
482
E Koseki et al.
(1) (2) (3) (4)
short learning time minimal development effort reasonable computational performance. high maintainability.
To meet these requirements, a visual knowledge representation and a visual porogramming language are introduced. That representation and language are evaluated according to the above requirements in Section 5. 2.2. Declarative and Procedural Knowledge
Expert systems consist of mainly two parts. One is the problem-solving part, which utilizes human expert knowledge. Knowledge is usually represented declaratively in task-specific forms, such as rules, decision trees, decision tables and object relation graphs. The other part combines conventional functions, such as main flow description, database query and graphical user interface. This part is usually represented procedurally. 2.3. Object-Oriented Architecture To realize hybrid expert systems, which consist of problem-solving components and conventional function components, we propose an object-oriented component assembly architecture (Fig. 1). An expert system is assembled as a set of task-specific components glued together. Those task-specific components are provided as objects, as defined in the object-oriented paradigm. Those objects have internal states and methods that can be activated by other objects. 2.4. Textual vs Visual Representation
The aim of expert system technology is to provide software systems with expert level intelligence. The key to realizing such a system is to capture and utilize the knowledge of experienced human experts. In the early days, separating a domain-independent inference engine from a domain-dependent declarative knowledge base made knowledge capture and utilization easier than with conventional software technology. However, the creation and maintenance of knowledge bases must still be done by specially trained technicians called knowledge engi-
,
User interface
epo.
,
•
IK
I
owledgel
Base
"1 Problem r
Solver
,
neers. Our goal is to provide a tool which allows the domain experts themselves to create knowledge bases, without the help of knowledge engineers. Since domain experts are usually computer novices, it is necessary to fill the gap between computational representation and human knowledge representation. Some recent works utilize comprehensible visual knowledge representations, such as rule diagrams, decision trees and decision tables, rather than textual representations. This visual representation approach has been successful in knowledge representation for task-specific tools. For example, we created a classification task-oriented tool which utilizes visual knowledge representation. The tool has been used in the unassisted creation of practical knowledge bases by domain experts. Its visual knowledge representation is briefly described in the next section. However, procedural programs, other than the knowledge base, had to be written in a procedural language by programmers. Therefore, to allow domain experts to be able to make these procedural programs themselves, an iconic visual programming tool was developed. This is the second and main topic of this paper and it is described in the later sections. 3. VISUAL KNOWLEDGE REPRESENTATION This section describes the visual knowledge representation, incorporated in the classification problem-solving component, called HOLON/VP(DT) (Koseki et al., 1991; Sugiura et al., 1993; Tanaka et al., 1994). It is unique in being based on a symbolic decision table and a graphical decision tree representation rather than on text rules. This representation makes a more comprehensible knowledge base than do rules. The classification problem is to find appropriate classes for unknown concepts, given a set of attribute value conditions for the concept. Consider a simple example for a grinder selection problem in a hypothetical factory. The problem is to select an appropriate grinder for a product according to product requirements, such as material features and required quality. An example of grinder selection knowledge described in decision table form is shown in Fig. 2. A decision table represents a set
,
Database , ~
,
roood ,' /
Grinder-H Grinder-H Grinder-L
[ presentation [
[ Tables [
Material Hard Soft O x x O x O
Quality High l.ow O O © x x O v
[othersystems I
FIGURE 1. General architecture.
FIGURE 2. Example decision table.
Visual Programming Environment
483
Material '~ G r i n d e r - H ~ i
iLo--~Grinder_L j
FIGURE 3. Example decision tree.
of propositional logic functions expressed in DNF (disjunctive normal form). This construct allows the handling of disjunctive concepts with multiple-value attributes. This knowledge can be described in decision tree form as shown in Fig. 3. The decision table representation has three advantages. First, the content is comprehensible to humans, because tables provide multiple views of a knowledge base. For example, when given a concept, a user can easily find which combination of attributes gives the concept as a conclusion. When a set of attributes is given, we can also see which concepts are selected as a conclusion. Comparing multiple concept functions is also an easy task with this representation. The second advantage is that it can provide a conclusion even if some of the query attributes are unknown. The third advantage is that tabular representation explicitly separates control knowledge from logical knowledge, whereas rule-based representation mixes them because the rule ordering expresses some control knowledge. A disadvantage of the tabular representation is that it may become sparse and take up too much space. In the worst case, it requires an exponential number of rows to implement certain functions, such as parity functions. However, this situation can be avoided by using hierarchically divided tables. The system consists of a decision table editor, a decision tree editor and a problem solver. Figure 4 shows
FIGURE 4. Example display of DT.
an example display of these editors. The decision table editor and decision tree editor allow direct manipulation of the knowledge base. As well as a "what you see is what you get" editing function, the decision table editor provides several functions to help in the construction of knowledge bases, namely simulation, minimization and verification. The simulation function allows users to validate a knowledge base. The minimization function shrinks the size of the knowledge base and improves its comprehensibility. The verification function checks the completeness and redundancy. The problem solver accomplishes classification by executing a candidate discrimination cycle. It dynamically chooses an appropriate attribute to be acquired according to the information gain per attribute cost. The problem solver can call multiple tables in a hierarchical manner, so that a large knowledge base can be implemented as a collection of tables. The problem solver also provides an interactive knowledge acquisition function for refining knowledge bases. Using that function, the user can refine the knowledge base by giving a critique of the final conclusion, without being aware of the internal representation. 4. VISUAL P R O G R A M M I N G The previous section introduced visual knowledge representation for classification problem solving. Although the system provides high productivity and maintainability for classification tasks, it is not applicable to other types of programming, particularly procedural ones. This section describes visual programming for the procedural parts and component connecting routines.
4.1. Iconic Programming Recently, research on visual programming has been active and a variety of languages have been implemented. Commercial products are already available for specific purposes, such as signal processing, simulation and control systems. Some systems have been designed for general-purpose use. The most popular architecture for recent visual programming languages is data flow iconic programming, such as LabVIEW, Prograph, Show and Tell and VisaVis (Hansen, 1994). Another interesting architecture is based on a visual rule production system, such as ChemTrains (Bell & Lewis, 1993). The programming language described in this paper is based on an "icon and wire" representation, where program objects are described as boxes and connections among them are indicated by wires. It is unique in its computational model that is not based on a data flow model, which is employed in most of other iconic visual languages. Rather than having one kind of wire to represent data flows among program components, the language employs two kinds of wires, one for control and one for data.
484
Y. Koseki et al.
~:~i~~'?~;
;i~:~ ~'
;::i~,ia;~;~-J
i:i::i~'ii}
[Name
]
property. Method is the procedure to be invoked by other objects. In the example, "Reply Window" has a method called "hide", which is called by the callback function of the "Bye" object in the "Hello Window". The callback function is particular to GUI objects; it generates an event to call other methods.
~ i~]ReplyWind!~|#;
IN e
I
FIGURE 5. Simple application. Figure 5 shows a simple visual program for a simple graphical user interface (GUI) application. This example is to provide two GUI windows, whose face designs are shown on the right side of the figure. Pressing the "Hello!" button in the top-right comer window named "Hello Window", causes the contents of the text-box below to be copied to the text-box of the other window, called "Reply Window". Pressing the "Bye" button terminates the program. To realize such a program, the user at first uses the user interface editor to create face designs of the two windows. In the figure, the two windows on the right side have already been created. After creating those windows, the user defines the program behavior as a "visual program" by using the visual program editor, which is shown on the left side of the figure. There are three boxes and four wires. The leftmost box in the visual program represents the "Hello Window", whose face design is shown in the top right of the figure. The second box represents the "Reply Window", shown in the bottom right. Those two boxes are created by simply dragging and dropping the GUI window objects into the visual programming editor. The third box is the "exit" box, which represents the terminating function. This box is provided by the visual program editor as a default.
4.2. Boxes Boxes represent functional components, such as problem solvers, GUI windows, database queries and control functions. Although there are many kinds of functional components, the box face designs are unified. Among them, GUI window objects are special objects that may contain multiple GUI objects, such as buttons and text boxes. Each box consists of several areas with accessible ports. There are three kinds of areas in a box: property, method and callback function. Each area has ports. There are two kinds of ports: control ports, which are displayed as triangles, and data ports, which are displayed as rectangles. The property area represents internal state data, which may be set or read through the ports. For example, the "name" text-boxes in both windows have the "text"
4.3. Control Wires and Data Wires The two kinds of wires are represented by solid and dotted lines. Solid wires show control flow, whereas dotted wires show data flow. Serially connected control wires represent a series of methods to be invoked in that order. For example, when the "Hello!" button of the "Hello Window" is pressed, the text property of the "Name" textbox of the "Reply Window" is set to the value of the "Name" textbox of the "Hello Window". When the "Bye" button is pressed, the "hide" method of the "Reply Window" is called and the window becomes hidden. Then the special function "Exit" is invoked to terminate the program. In the current implementation, the visual program is translated into an internal script language. Figure 6 shows the interpretation of the given example.
4.4. Implementing an Expert System by Visual Programming The visual programming is intended to glue together functional components. The first step in building a hybrid expert system is to implement the problem-solving function by providing a knowledge base and some parameters. The user interface is then designed using the user interface editor and connected to the problemsolving component by visual programming. Although the intended usage of the visual programming is as "glue", it is possible to implement a decision tree-based classification expert system entirely by visual programming, without using the decision tree component, as described in the previous section. Figure 7 shows a complete visual program for the previously introduced grinder selection system. This is also a good sample for evaluating the comprehensibility of the visual programming. The result is less comprehensible than the implementation with a task-specific tool, as described in the
"Click callback method of PushButton(.HelloO.HelloO.)" begin tempi := .Hello().Name0.t¢×t(); .Reply0Nam¢0.text 0 := temp I; end;
"Click callbackmethod of FushButton(.Hello0.Bye0.)" begin .Reply0.hide0;
,exit0; end;
FIGURE 6. Script representation of the example.
Visual Programming Environment
485
W~:.r ._J
.................. I
"
'
'
"
I
J
r-- ~ ~ .....
:
~
m~'*i"~l I
._.J •
C3
,
,
~: r m
"~i Material I,,|~
~t
Oual~/ I~l~l
IMa'e*''? I
~ t AnswerWindow I::~IN
I I FIGURE 7. Decision tree Implementation by visual programming.
previous section, because the problem-solving knowledge and implementation-specific routines, such as the window controlling routines (showing and hiding), are mixed in the visual programming implementation. However, it can be observed that the general flow of the decision tree is maintained in the visual program. 5, EVALUATION
development with the visual program system required almost same amount of time as did the textual programming. Errors due to mistyping are less frequent in visual programming, because text typing is seldom necessary except for variable names, method names and class names in visual programming.
5.3. Reasonable Computational Performance
Several experimental systems have been developed with the described visual programming tool. It is still too early to give a concrete evaluation without an extensive evaluation effort. However, from experience, the following simple evaluation with respect to the requirements described early in this paper may be given.
Because the visual language is converted into internal textual language in the current implementation, the computational performance is comparable to conventional language, with negligible overhead for conversion. The language can be either interpreted or compiled with reasonable performance.
5.1. Short Learning Time
5.4. High Maintainability
Inexperienced users prefer visual programming to textual programming, because visual program is relatively intuitive and comprehensible. Especially with proper sample programs, visual programs are easy to start with for inexperienced users. However, for experienced programmers, who are already familiar with textual programming style, learning another completely different programming type seems to be a burden.
High maintainability is considered to be the most significant advantage of visual language. Since the control flow is visible, it is easy to understand the flow of the program at a glance. This gives high maintainability to the program, since the program is readable and understandable at a later time by a person other than the developer. Visible data dependency with data lines also helps the comprehensibility of the program. In textual language, data dependencies must be investigated with the help of program analyzing tools. Inexperienced users at first tend to encounter a "line congestion problem", which may degrade maintainability. That is, when building a complex system, many control lines cross each other and make the visual program incomprehensible. To solve this problem, the system provides a function for splitting one box into multiple copies and putting them at arbitrary places (Koike et al., 1995). This capability allows programmers
5.2. Less Development Effort As a comparison, a small system was developed both with the visual programming system and a conventional textual programming. Before the experiment, drawing visual programs with mouse operations was expected to have a much higher productivity than textual programs. However, for casual programmers who are already comfortable with typing text with a keyboard, system
486
Y. Koseki et al.
to organize the program according to the main control flow of the program, so that the line congestion problem may be avoided. 6. CONCLUSION This paper describes an approach to using an objectoriented visual programming technique for developing hybrid expert systems. The system consists of several computational components, some of which are taskspecific problem-solving tools. Other parts are conventional computing functions, such as database access and graphical user interface. Visual programming is used to glue those computational components together to make up a complete system. The system has been used to develop some experimental expert systems. Empirical evaluation shows that its maintainability is superior to textual programming languages, because of its high comprehensibility. However, some problems remain to be solved in future work. The first problem encountered is scalability. Since the current implementation does not support hierarchical construction of visual programming, it is unable to construct highly complex systems by visual programming alone. The system is being enhanced to incorporate hierarchical visual programming. Second, even though visual programming results in high comprehensibility and maintainability, it requires almost the same effort as textual programming. We are currently investigating a way to incorporate a PBD (programming by demonstration) approach to creating initial visual programs (Sassin, 1994; Suguira & Koseki, 1995).
Third, in order to meet the various requirements of expert system development, a variety of problem-solving objects must be provided. Our future plan includes development of more task-oriented problem solvers, such as a combinatorial optimization problem solver.
Acknowledgements--The authors express their appreciation to Masahiro Yamamoto, Takeshi Yoshimura and Masanobu Watanabe of the NEC Corporation for giving them the opportunity to pursue this research.
REFERENCES Bell, B. & Lewis, C. (1993). ChemTrains: a language for creating behaving pictures. In Proc. of IEEE Symposium on Visual Languages, pp. 188-195. Hansen, W. J. (Moderator) (1994). The 1994 visual languages comparison. In Proc. of lEEE Symposium on Visual Languages, pp. 90-97. Koike, Y., Maeda, Y. & Koseki, Y. (1995). Improving readability of iconic programs with multiple view object representation. In Proc. of llth 1EEE Symposium on Visual Languages, pp. 37-44. Koseki, Y., Nakakuki, Y. & Tanaka, M. (1991). DT: A classification problem solver with tabular-knowledge acquisition. In Proc. Third Int. Conf. on Toolsfor A1, pp. 156-163. Sassin, M. (1994). Creating user-intended programs with programming by demonstration. In Proc. of 1994 IEEE Symposium on Visual Languages, pp. 153-160. Sugiura, A. & Koseki, Y. (1995). Creating database queries by demonstration. In Proc. of llth IEEE Symposium on Visual Languages, pp. 164-171. Sugiura, A., Riesenhuber, M. & Koseki, Y. (1993). Comprehensibility improvement of tabular knowledge base. In Proc. of AAAI-93, pp. 716-721. Tanaka, M., Aoyama, N., Sugiura, A. & Koseki, Y. (1994). Integration of multiple knowledge representation for classification problems. In Proc. of Japan/Korea Joint Conferences on Expert Systems, pp. 159-164.
Pergamon
S0957-4174(96)00028-0
Visual Programming Environment for Hybrid Expert Systems YOSHIYUKIKOSEKI,M [ D o m
TANAKA, YASUYUKI MAEDA AND YUICHI KOXKE
C & C ResearchLaboratories,NEC Corporation,4-1-1 Miyazaki,Miyamae-ku,Kawasaki216, Japan
Abstract--This paper proposes an architecture for hybrid expert system development which combines expert problem-solving functions and other conventional computational functions by visual programming technology. The visual programming technique is used both for task-specific knowledge representation and for procedural programming for connecting functional components. In knowledge representation, knowledge is visually represented in the form of decision tables and decision trees. In procedural visual programming, each functional object is displayed as a box-shaped icon with accessible ports which are connected by wires on the graphic editor. Based on the architecture, an expert system shell for the classification task, called HOLON/VP(DT), is incorporated in a visual programming system called HOLON/VP. This paper briefly describes the tool and its evaluation based on some application systems developed with the tool. Copyright © 1996 Elsevier Science Ltd
1. INTRODUCTION
• provide interface with other development systems by function call library.
in the 1970s, a large number of expert systems have been deployed. Experience gained in the development of those systems shows that the development of general functions, such as user interface, database access and simple data manipulation, requires much more effort than the development of the problem-solving part. Although conventional expert system tools provide many convenient functions for developing the problem-solving part, considerable effort is needed to implement those "hybrid" expert systems, which combine problemsolving functions with conventional computational functions. The objective of the research described in this paper is to provide an expert system tool which enables computer-novice domain experts themselves to create their own expert systems. Since domain experts are usually not computer experts, the tool should provide an environment for novice computer users to easily create a hybrid system. In recent years, a number of tools have been developed for knowledge base development. However, few attempts have been made to provide a hybrid expert system development environment. Most of the conventional tools take one of the following approaches: SINCE THE ADVENT OF EXPERT SYSTEM TECHNOLOGY
All of the approaches are simple extensions of conventional programming techniques. In any case, programming must be done by an embedded textual programming language, which may be LISP or C language. This paper introduces a novel expert system tool architecture, based on a visual programming technique. Based on the architecture, a visual programming system, named HOLON/VE was developed. This tool includes a classification task-specific expert system shell called HOLON/VP(DT). This paper describes the tool and its evaluation based on some application systems developed with the tool. Section 2 introduces the general architecture based on an object-oriented visual programming approach. The visual knowledge representation of the classification task-oriented problem-solving tool is described in Section 3. Section 4 illustrates the HOLON/VP visual programming tool in detail with some examples. Section 5 summarizes the advantages and disadvantages of the architecture and presents an empirical evaluation. Section 6 concludes by pointing out several areas for further work. 2. GENERAL A R C H I T E C T U R E
• provide conventional computation tools around the problem-solving tool • provide problem solver on a pre-existent program development environment
2.1. Requirements The requirements for a hybrid expert system development environment are listed below: 481
482
E Koseki et al.
(1) (2) (3) (4)
short learning time minimal development effort reasonable computational performance. high maintainability.
To meet these requirements, a visual knowledge representation and a visual porogramming language are introduced. That representation and language are evaluated according to the above requirements in Section 5. 2.2. Declarative and Procedural Knowledge
Expert systems consist of mainly two parts. One is the problem-solving part, which utilizes human expert knowledge. Knowledge is usually represented declaratively in task-specific forms, such as rules, decision trees, decision tables and object relation graphs. The other part combines conventional functions, such as main flow description, database query and graphical user interface. This part is usually represented procedurally. 2.3. Object-Oriented Architecture To realize hybrid expert systems, which consist of problem-solving components and conventional function components, we propose an object-oriented component assembly architecture (Fig. 1). An expert system is assembled as a set of task-specific components glued together. Those task-specific components are provided as objects, as defined in the object-oriented paradigm. Those objects have internal states and methods that can be activated by other objects. 2.4. Textual vs Visual Representation
The aim of expert system technology is to provide software systems with expert level intelligence. The key to realizing such a system is to capture and utilize the knowledge of experienced human experts. In the early days, separating a domain-independent inference engine from a domain-dependent declarative knowledge base made knowledge capture and utilization easier than with conventional software technology. However, the creation and maintenance of knowledge bases must still be done by specially trained technicians called knowledge engi-
,
User interface
epo.
,
•
IK
I
owledgel
Base
"1 Problem r
Solver
,
neers. Our goal is to provide a tool which allows the domain experts themselves to create knowledge bases, without the help of knowledge engineers. Since domain experts are usually computer novices, it is necessary to fill the gap between computational representation and human knowledge representation. Some recent works utilize comprehensible visual knowledge representations, such as rule diagrams, decision trees and decision tables, rather than textual representations. This visual representation approach has been successful in knowledge representation for task-specific tools. For example, we created a classification task-oriented tool which utilizes visual knowledge representation. The tool has been used in the unassisted creation of practical knowledge bases by domain experts. Its visual knowledge representation is briefly described in the next section. However, procedural programs, other than the knowledge base, had to be written in a procedural language by programmers. Therefore, to allow domain experts to be able to make these procedural programs themselves, an iconic visual programming tool was developed. This is the second and main topic of this paper and it is described in the later sections. 3. VISUAL KNOWLEDGE REPRESENTATION This section describes the visual knowledge representation, incorporated in the classification problem-solving component, called HOLON/VP(DT) (Koseki et al., 1991; Sugiura et al., 1993; Tanaka et al., 1994). It is unique in being based on a symbolic decision table and a graphical decision tree representation rather than on text rules. This representation makes a more comprehensible knowledge base than do rules. The classification problem is to find appropriate classes for unknown concepts, given a set of attribute value conditions for the concept. Consider a simple example for a grinder selection problem in a hypothetical factory. The problem is to select an appropriate grinder for a product according to product requirements, such as material features and required quality. An example of grinder selection knowledge described in decision table form is shown in Fig. 2. A decision table represents a set
,
Database , ~
,
roood ,' /
Grinder-H Grinder-H Grinder-L
[ presentation [
[ Tables [
Material Hard Soft O x x O x O
Quality High l.ow O O © x x O v
[othersystems I
FIGURE 1. General architecture.
FIGURE 2. Example decision table.
Visual Programming Environment
483
Material '~ G r i n d e r - H ~ i
iLo--~Grinder_L j
FIGURE 3. Example decision tree.
of propositional logic functions expressed in DNF (disjunctive normal form). This construct allows the handling of disjunctive concepts with multiple-value attributes. This knowledge can be described in decision tree form as shown in Fig. 3. The decision table representation has three advantages. First, the content is comprehensible to humans, because tables provide multiple views of a knowledge base. For example, when given a concept, a user can easily find which combination of attributes gives the concept as a conclusion. When a set of attributes is given, we can also see which concepts are selected as a conclusion. Comparing multiple concept functions is also an easy task with this representation. The second advantage is that it can provide a conclusion even if some of the query attributes are unknown. The third advantage is that tabular representation explicitly separates control knowledge from logical knowledge, whereas rule-based representation mixes them because the rule ordering expresses some control knowledge. A disadvantage of the tabular representation is that it may become sparse and take up too much space. In the worst case, it requires an exponential number of rows to implement certain functions, such as parity functions. However, this situation can be avoided by using hierarchically divided tables. The system consists of a decision table editor, a decision tree editor and a problem solver. Figure 4 shows
FIGURE 4. Example display of DT.
an example display of these editors. The decision table editor and decision tree editor allow direct manipulation of the knowledge base. As well as a "what you see is what you get" editing function, the decision table editor provides several functions to help in the construction of knowledge bases, namely simulation, minimization and verification. The simulation function allows users to validate a knowledge base. The minimization function shrinks the size of the knowledge base and improves its comprehensibility. The verification function checks the completeness and redundancy. The problem solver accomplishes classification by executing a candidate discrimination cycle. It dynamically chooses an appropriate attribute to be acquired according to the information gain per attribute cost. The problem solver can call multiple tables in a hierarchical manner, so that a large knowledge base can be implemented as a collection of tables. The problem solver also provides an interactive knowledge acquisition function for refining knowledge bases. Using that function, the user can refine the knowledge base by giving a critique of the final conclusion, without being aware of the internal representation. 4. VISUAL P R O G R A M M I N G The previous section introduced visual knowledge representation for classification problem solving. Although the system provides high productivity and maintainability for classification tasks, it is not applicable to other types of programming, particularly procedural ones. This section describes visual programming for the procedural parts and component connecting routines.
4.1. Iconic Programming Recently, research on visual programming has been active and a variety of languages have been implemented. Commercial products are already available for specific purposes, such as signal processing, simulation and control systems. Some systems have been designed for general-purpose use. The most popular architecture for recent visual programming languages is data flow iconic programming, such as LabVIEW, Prograph, Show and Tell and VisaVis (Hansen, 1994). Another interesting architecture is based on a visual rule production system, such as ChemTrains (Bell & Lewis, 1993). The programming language described in this paper is based on an "icon and wire" representation, where program objects are described as boxes and connections among them are indicated by wires. It is unique in its computational model that is not based on a data flow model, which is employed in most of other iconic visual languages. Rather than having one kind of wire to represent data flows among program components, the language employs two kinds of wires, one for control and one for data.
484
Y. Koseki et al.
~:~i~~'?~;
;i~:~ ~'
;::i~,ia;~;~-J
i:i::i~'ii}
[Name
]
property. Method is the procedure to be invoked by other objects. In the example, "Reply Window" has a method called "hide", which is called by the callback function of the "Bye" object in the "Hello Window". The callback function is particular to GUI objects; it generates an event to call other methods.
~ i~]ReplyWind!~|#;
IN e
I
FIGURE 5. Simple application. Figure 5 shows a simple visual program for a simple graphical user interface (GUI) application. This example is to provide two GUI windows, whose face designs are shown on the right side of the figure. Pressing the "Hello!" button in the top-right comer window named "Hello Window", causes the contents of the text-box below to be copied to the text-box of the other window, called "Reply Window". Pressing the "Bye" button terminates the program. To realize such a program, the user at first uses the user interface editor to create face designs of the two windows. In the figure, the two windows on the right side have already been created. After creating those windows, the user defines the program behavior as a "visual program" by using the visual program editor, which is shown on the left side of the figure. There are three boxes and four wires. The leftmost box in the visual program represents the "Hello Window", whose face design is shown in the top right of the figure. The second box represents the "Reply Window", shown in the bottom right. Those two boxes are created by simply dragging and dropping the GUI window objects into the visual programming editor. The third box is the "exit" box, which represents the terminating function. This box is provided by the visual program editor as a default.
4.2. Boxes Boxes represent functional components, such as problem solvers, GUI windows, database queries and control functions. Although there are many kinds of functional components, the box face designs are unified. Among them, GUI window objects are special objects that may contain multiple GUI objects, such as buttons and text boxes. Each box consists of several areas with accessible ports. There are three kinds of areas in a box: property, method and callback function. Each area has ports. There are two kinds of ports: control ports, which are displayed as triangles, and data ports, which are displayed as rectangles. The property area represents internal state data, which may be set or read through the ports. For example, the "name" text-boxes in both windows have the "text"
4.3. Control Wires and Data Wires The two kinds of wires are represented by solid and dotted lines. Solid wires show control flow, whereas dotted wires show data flow. Serially connected control wires represent a series of methods to be invoked in that order. For example, when the "Hello!" button of the "Hello Window" is pressed, the text property of the "Name" textbox of the "Reply Window" is set to the value of the "Name" textbox of the "Hello Window". When the "Bye" button is pressed, the "hide" method of the "Reply Window" is called and the window becomes hidden. Then the special function "Exit" is invoked to terminate the program. In the current implementation, the visual program is translated into an internal script language. Figure 6 shows the interpretation of the given example.
4.4. Implementing an Expert System by Visual Programming The visual programming is intended to glue together functional components. The first step in building a hybrid expert system is to implement the problem-solving function by providing a knowledge base and some parameters. The user interface is then designed using the user interface editor and connected to the problemsolving component by visual programming. Although the intended usage of the visual programming is as "glue", it is possible to implement a decision tree-based classification expert system entirely by visual programming, without using the decision tree component, as described in the previous section. Figure 7 shows a complete visual program for the previously introduced grinder selection system. This is also a good sample for evaluating the comprehensibility of the visual programming. The result is less comprehensible than the implementation with a task-specific tool, as described in the
"Click callback method of PushButton(.HelloO.HelloO.)" begin tempi := .Hello().Name0.t¢×t(); .Reply0Nam¢0.text 0 := temp I; end;
"Click callbackmethod of FushButton(.Hello0.Bye0.)" begin .Reply0.hide0;
,exit0; end;
FIGURE 6. Script representation of the example.
Visual Programming Environment
485
W~:.r ._J
.................. I
"
'
'
"
I
J
r-- ~ ~ .....
:
~
m~'*i"~l I
._.J •
C3
,
,
~: r m
"~i Material I,,|~
~t
Oual~/ I~l~l
IMa'e*''? I
~ t AnswerWindow I::~IN
I I FIGURE 7. Decision tree Implementation by visual programming.
previous section, because the problem-solving knowledge and implementation-specific routines, such as the window controlling routines (showing and hiding), are mixed in the visual programming implementation. However, it can be observed that the general flow of the decision tree is maintained in the visual program. 5, EVALUATION
development with the visual program system required almost same amount of time as did the textual programming. Errors due to mistyping are less frequent in visual programming, because text typing is seldom necessary except for variable names, method names and class names in visual programming.
5.3. Reasonable Computational Performance
Several experimental systems have been developed with the described visual programming tool. It is still too early to give a concrete evaluation without an extensive evaluation effort. However, from experience, the following simple evaluation with respect to the requirements described early in this paper may be given.
Because the visual language is converted into internal textual language in the current implementation, the computational performance is comparable to conventional language, with negligible overhead for conversion. The language can be either interpreted or compiled with reasonable performance.
5.1. Short Learning Time
5.4. High Maintainability
Inexperienced users prefer visual programming to textual programming, because visual program is relatively intuitive and comprehensible. Especially with proper sample programs, visual programs are easy to start with for inexperienced users. However, for experienced programmers, who are already familiar with textual programming style, learning another completely different programming type seems to be a burden.
High maintainability is considered to be the most significant advantage of visual language. Since the control flow is visible, it is easy to understand the flow of the program at a glance. This gives high maintainability to the program, since the program is readable and understandable at a later time by a person other than the developer. Visible data dependency with data lines also helps the comprehensibility of the program. In textual language, data dependencies must be investigated with the help of program analyzing tools. Inexperienced users at first tend to encounter a "line congestion problem", which may degrade maintainability. That is, when building a complex system, many control lines cross each other and make the visual program incomprehensible. To solve this problem, the system provides a function for splitting one box into multiple copies and putting them at arbitrary places (Koike et al., 1995). This capability allows programmers
5.2. Less Development Effort As a comparison, a small system was developed both with the visual programming system and a conventional textual programming. Before the experiment, drawing visual programs with mouse operations was expected to have a much higher productivity than textual programs. However, for casual programmers who are already comfortable with typing text with a keyboard, system
486
Y. Koseki et al.
to organize the program according to the main control flow of the program, so that the line congestion problem may be avoided. 6. CONCLUSION This paper describes an approach to using an objectoriented visual programming technique for developing hybrid expert systems. The system consists of several computational components, some of which are taskspecific problem-solving tools. Other parts are conventional computing functions, such as database access and graphical user interface. Visual programming is used to glue those computational components together to make up a complete system. The system has been used to develop some experimental expert systems. Empirical evaluation shows that its maintainability is superior to textual programming languages, because of its high comprehensibility. However, some problems remain to be solved in future work. The first problem encountered is scalability. Since the current implementation does not support hierarchical construction of visual programming, it is unable to construct highly complex systems by visual programming alone. The system is being enhanced to incorporate hierarchical visual programming. Second, even though visual programming results in high comprehensibility and maintainability, it requires almost the same effort as textual programming. We are currently investigating a way to incorporate a PBD (programming by demonstration) approach to creating initial visual programs (Sassin, 1994; Suguira & Koseki, 1995).
Third, in order to meet the various requirements of expert system development, a variety of problem-solving objects must be provided. Our future plan includes development of more task-oriented problem solvers, such as a combinatorial optimization problem solver.
Acknowledgements--The authors express their appreciation to Masahiro Yamamoto, Takeshi Yoshimura and Masanobu Watanabe of the NEC Corporation for giving them the opportunity to pursue this research.
REFERENCES Bell, B. & Lewis, C. (1993). ChemTrains: a language for creating behaving pictures. In Proc. of IEEE Symposium on Visual Languages, pp. 188-195. Hansen, W. J. (Moderator) (1994). The 1994 visual languages comparison. In Proc. of lEEE Symposium on Visual Languages, pp. 90-97. Koike, Y., Maeda, Y. & Koseki, Y. (1995). Improving readability of iconic programs with multiple view object representation. In Proc. of llth 1EEE Symposium on Visual Languages, pp. 37-44. Koseki, Y., Nakakuki, Y. & Tanaka, M. (1991). DT: A classification problem solver with tabular-knowledge acquisition. In Proc. Third Int. Conf. on Toolsfor A1, pp. 156-163. Sassin, M. (1994). Creating user-intended programs with programming by demonstration. In Proc. of 1994 IEEE Symposium on Visual Languages, pp. 153-160. Sugiura, A. & Koseki, Y. (1995). Creating database queries by demonstration. In Proc. of llth IEEE Symposium on Visual Languages, pp. 164-171. Sugiura, A., Riesenhuber, M. & Koseki, Y. (1993). Comprehensibility improvement of tabular knowledge base. In Proc. of AAAI-93, pp. 716-721. Tanaka, M., Aoyama, N., Sugiura, A. & Koseki, Y. (1994). Integration of multiple knowledge representation for classification problems. In Proc. of Japan/Korea Joint Conferences on Expert Systems, pp. 159-164.