The software tool, refined in this project is an implementation of the structured matcher concept and will be referred to as a Structured Matcher. The Structured Matcher Shell has two types of users. The first type of user is the expert. The expert defines the information ( parameters and constraints ) required to build an accurate hypothesis test. The other type of user, is the non-expert. The non-expert would use a previously defined Structured Matcher to receive advise on a hypothesis. For example, a heart specialist (expert) may construct a Structured Matcher to give the likelihood that a person should be concerned about their heart condition. In this example, the non-expert is a person who is concerned about their health, or a medical person who just does not have the appropriate depth of knowledge in this particular subject. What follows is a walk through of the Structured Matcher from first the expert's point of view and then from a non-expert's point of view.

Expert's walk through - Creating a Structured Matcher. This walk through shows the creation of a Structured Matcher to test a hypothesis that a problem with an automobile is related to bad fuel. When the expert first starts the Structured Matcher program, it will display a screen as shown in Figure 3.

This first screen displays a starting simple matcher which is labeled Untitled [SM]. This screen is where the expert would add additional simple matchers to the root simple matcher. Before additions are made to the default setup, the expert may want to start a new set up by selecting File from the menu at the top of the program, and then selecting New from the sub-menu. The expert would then be prompted to enter a name for the Structured Matcher. Notice in Figure 4, how the name has been changed in both the program title bar, and in the viewing area as well. Remember, adding simple matchers to the root simple matcher allows for the hypothesis to be tested to be broken down into sub-decisions.

To add an addition simple matcher to the root simple matcher, the expert can either use the pull down menus at the top of the program or right click (pressing the right mouse button) on the simple matcher to get a pop-up menu as shown in Figure 4. Simple matchers are also referred to as nodes within the program, so for operation related to simple matcher, an expert could also use the Node menu at the top, or as mentioned earlier, right click on the simple matcher itself.

After the expert has added two additional simple matchers to handle sub-decisions of the overall hypothesis, the Structured Matcher screen would look like Figure 5.

As noted in Figure 5, the icon appearance changed for the root simple matcher when child simple matcher were added. At this point, the expert has not defined any of the parameters for the simple matchers, but has only set up the organization of the decision tree.

To define the parameters for a simple matcher the expert would double-click (tap the left mouse button twice quickly) on a simple matcher to be changed. If a simple matcher is opened which contains no other sub-decision simple matchers, a blank simple matcher will be presented with one column to represent the Results, or return value for the simple matcher. Figure 6 shows the child simple matcher which, as can be seen, represents the Fill-up Related sub-decision.

If the simple matcher in Figure 6 were to be run in its current state, it would return Neutral since no parameters have been defined for this simple matcher. A simple matcher will also return Neutral, if none of the simple matchers rows matched. Figure 7 shows the initial state for the root simple matcher called Bad Fuel Hypothesis. Notice that it contains a column for each of its child simple matchers, that are going to handle sub-decisions in regard to Performance Related, or Fill-up Related. A simple matcher column can be distinguished by the [SM] which the program adds to the end of the column name.

The values within the columns will be discussed later, but first we will return to the Fill-up Related simple matcher to define the parameters or questions. To add a question, the expert would select the Column menu from the top of the Simple Matcher window and then select Add from the sub menu. This would bring up a screen to allow a question to be defined, as shown in Figure 8.

This screen allows the expert to define a short name for the question, the question itself and what type of question it is. The type of question is selected at the bottom of the screen, and is in reference to how the question is to be answered. The True/False type is self explanatory, but the Likelihood type would be answered with a value from one of the following set {Strongly Against, Against, Slightly Against, Neutral, Slightly Match, Match, Strongly Match}. The area to the left of the screen allows an expert to select an previously defined question to be used again. Figure 9 shows what the screen would look like after being filled out for a second question in the Fill-up Related simple matcher. Notice that the first question is listed on the left. This box on the left will contain all the questions that have been constructed for the whole Structured Matcher, not just the questions for this simple matcher.

After three questions have been defined for the Fill-up Related simple matcher, it would look like Figure 10. Notice that a column was created for each question, and each matching constraint or cell value was assigned an initial value of ?- Don't Care. Now the expert must change the constraint values for the cells to reflect the proper decision making process. To change the constraint value of a cell, the expert would double click on the cell to bring up an editor for the cell.

Figure 11 shows the editing of a cell in the Higher Grade column.

The expert will also need to add additional rows to facilitate other options in the decision making process. To do this the expert would select Row from the menu at the top of the program and then select Add from the sub-menu. The expert would then proceed to change the constraints for each of the new rows as appropriate. Figure 12 shows the completely edited simple matcher for the Fill-up Related sub-decision.

After defining all the sub-decisions the expert would also need to define the cell constraints for the root simple matcher. So far, the cell editor for true and false has been shown, but when dealing with a range of values to be chosen from, a different type of cell editor must be used. Figure 13 shows an example of a different cell editor. Due to the range of values that can be selected as an answer, comparison operators are added to the constraint, so for example, a parameter can be said to be true or match if its value is greater than Neutral.

The relationship editor would be used to edit cells for questions that have a parameter type of likelihood, or for columns that represent sub-decision simple matchers, since simple matchers return a likelihood representing the confidence level of their sub-decision. The completed root simple matcher would look like the screen shown in Figure 14.

Each simple matcher has a run button which would allow the expert to test each simple matcher on its own. If the run button is pressed for the root simple matcher (Bad Fuel Hypothesis) as shown in Figure 14, instead of running one of the sub-decision simple matchers, this would run the whole Structured Matcher, because to resolve this simple matcher, it would need to resolve its sub-decision matchers (Performance Related, and Fillup Related).

After verifying that the Structured Matcher is complete, the expert would save it by selecting File from the menu at the top of the program and then they would select the Save sub-menu. At that point, the Structured Matcher would be defined and the expert would be finished with this specific Structured Matcher.

Non-expert's walk through - Running a Structured Matcher. The non-expert user of Structured Matcher has a much less complicated time of using the Structured Matcher program. The user would load a previously defined and saved Structured Matcher. To do this, first the user would start the Structured Matcher program, and then they would select the File menu item at the top of the program, and then select the Open from the sub-menu. At this point, the user would select a file that contains the hypothesis to be tested. After the program has loaded the information, the user would see the same information that was available to the expert who built the system. Figure 15 shows the freshly loaded Structured Matcher for the testing the Bad Fuel Hypothesis.

From this point the user would press the run button at the Structured Matcher screen, and the program would pop up small dialog windows with questions from the simple matchers, as shown in Figure 16.

The question order is dependent on how the constraints were entered within the columns of the simple matchers. The Structured Matcher will finish asking questions when the answers match the constraints for a complete row. Structured Matcher will keep asking questions until a row matches or until all rows have been compared.

When the above criteria has been met, the program will present a dialog that gives the level of confidence for the hypothesis, as shown in Figure 17. As the user is answering the questions pertaining to the parameters, the program will save the answers in a collection of answers for this particular user's case. This collection of answers is called a case, and can be saved, reloaded, or reset. This manipulation of the case can be done through the Case menu at the top of the program. A benefit of saving the case is that it can be used to go back to any of the simple matchers to determine which row matched by running the individual simple matcher. After a simple matcher has resolved, it will present a dialog, as shown in Figure 18, showing the result of the simple matcher and the row where it matched the constraints.

This ability to save and load cases provides a powerful tool for the expert to test the parts of the Structure Matcher during construction, or to gain more specific information about an individual user.

Overview of Program Design

The Structured Matcher program is set up along the lines of the Model-View-Control guidelines [Larman97], where the data of the program (model) was separated away from the user interface (UI) (view). This makes the code easier to maintain, because either piece of the program, the model or the view, can be altered without major changes to the other.

At its core the Structured Matcher program consist of two different types of models. A tree model that is the structured matching hierarchy, where each node of the tree represents a simple matcher. The second model is a table model which represents the information that is stored within each simple matcher. Corresponding to each model is the view that represents visually the data stored in the model and allows the users to interact or issue commands to the model for its manipulation. Figure 21 shows this parallel hierarchy with the models of the system being on the right, and the views being on the left side of the diagram. There are of course many supporting objects that are not shown in this diagram, but these are the core objects of the Structured Matcher program. Class diagrams of the whole system are given in Appendix B.