The Structured Matcher project was originally part of the CSCI 322: Object-Oriented Programming in A.I course. As time progressed, the project began to grow as features and enhancements were added to it. This snowball effect was fueled by new knowledge gained from the other courses that followed CSCI 322 in my academic syllabus. It would seem logical that as a culmination of my Masters program, to take this project to its conclusion and to document the knowledge gained while working on it. A particular area that would benefit from documentation is the use of the Swing (Java Foundation Classes) library as the user interface in the Structured Matcher project.
The Structured Matcher (SM) project is an effort to write an A.I. tool in Java to create and use structured matchers (Bylander). This tool is based on an existing one in the Generalized Task (GT) package which was written in the VisualWave Smalltalk environment. The SM project is part of a class wide project to create an A.I. tool set which includes the Classifier, Abductor and Design tools. SM was designed to be integrated with the other tools in the set, such as the Classifier and Design tool. These tools rely on structured matchers in their operations. To the end of integrating SM with other tools, success has been achieved. SM has been integrated with Craig McChesney's classifier. The project basic requirements have been met but as with almost any other software, it can stand some refinements and enhancement. Most of these refinements would fall under the user interface category as streamlining operations and adding more views into the data.
A structured matcher is a software construct that performs structured to provide a likelihood value to a particular statement. It does this by asking a set of questions pertaining to the subject in order to ascertain the confidence value that the statement is true. For example, in classification applications, the statement "X is a mammal" can be matched with the questions, "Is it warm blooded?", "Does it give birth to live young?" and "Does it suckle it's young?". Depending on how these questions were answered, the structured matcher could return one of six Likelihood values which include Strongly Matched, Neutral and Strongly Against. A structured matcher is a tree of simple matchers, each which contains a truth table like structure that actually implements the structured matching algorithm. This is so, such that a question "Is it warm blooded?" can be broken down to a statement that can be matched with further detailed questions. For a more extensive explanation of structured matching, please refer to Structured Matching paper.
The main reason why Java was used is because the project was specified as part of the CSCI 322 class which uses Java. Beside that, there are other good reasons to write SM in Java. Portability is an important factor, the next being the relative ease of implementing such a program in Java in comparison to the other mainstream languages C, C++ and even Smalltalk. Writing SM in Java also allows us to leverage the other much touted features and strengths of Java such as it being network savvy, protection against runtime crashes, and so on (Flanagan) (Horstmann). In contrast with GT/SmallTalk, the use of Java for SM allows it to be so portable such that it would not even need a recompile for a port to a different platform. This was demonstrated when SM, which was developed on the Windows platform, was brought to a Sun Unix workstation and was run successfully without modification. This kind of portability can lead to it's wider use and integration with other tools. Since a large part of SM consists of graphical user interfaces, it has been a benefit to use Java for it's cross platform UI features and the relative ease and simplicity in doing GUIs in Java. There however, is a wrinkle in regards to the actual implementation of the GUI in SM and that is due to the use of the new Swing libraries.
Although Swing will be the premier Java user interface library and promises great things, at the time of SM's development, it was still in beta. Swing shows tremendous potential and will be standard high level interface classes for Java. It provides a good framework for writing applications and contains many of the features that the SM project required for its user interface. The only problem with cutting edge software is, the developers using them end up on the bleeding edge of things. The SM team had to deal with bugs, and bad, in some cases, non-existent documentation for the Swing classes. We also did not have any third party books or guides on the usage of Swing and had to do an inordinate amount of experimentation and debugging. This situation will change as Swing becomes more mature but as of this writing, there still hasn't been published any books on the use of Swing. As such, I believe that those contemplating using Swing can benefit from the documentation that will be created as part of this project.
The SM project, besides serving its function in the A.I tool set, can also be used as a non-trivial example of an application written in Java and Swing, incorporating many advanced features of the language. The documentation that will be written as part of the Masters project can be a good supplement to those contemplating writing Java applications with Swing. This write-up covers problem areas and the practical application of knowledge from a few CSCI classes.