CHAPTER V

CONCLUSION

Results

The goal of this project was to extend and refine the Structured Matcher program. This goal was accomplished through the use of design patterns to gain separation between the logic of the program and the detailed specifics of the program that could vary. These varying parts of the programs were the classes dealing with different types of parameter or questions. An example of a parameter type would be Boolean type, and it would have a number of supporting classes, like BooleanQstn, BooleanCellElement and BooleanCellEditor that would be used by different parts of the program.

By separating out the question related information from Structured Matcher, the program was made much more robust. This robustness had a couple sources. First, the code of Structured Matcher was less complex because it could deal with parameters and their related objects in a more general fashion. This is shown in Figure 42. Second, new parameter types could be added to Structured Matcher very easily, in fact, with the addition of only one line of code. In the prototype design, to add a new parameter type, many of the objects within the program would need to be changed, and the majority these changes were not small or obvious. For this reason, additions were very difficult to make, and the process was very error prone.

There were also some consequences due to separating the parameter related details from the Structured Matcher. One consequence is an increase in the number of objects in the program. In the prototype design, most of the responsibility of the program was centralized in just a few bloated classes. To clean up the design, these responsibilities were redistributed out to smaller objects, where they belonged. New objects or interfaces were also introduced to the program to add a new level of indirection. This level of indirection is shown in Figure 42. The introduction of too many different objects to a program can make it harder to understanding the details of the program code due to the responsibilities being spread among the objects. If a detailed understanding is desired, an number of objects must be examination.

The benefits and consequences of the separation between the logic of the program and the varying details need to be weighed. The benefits usually outweigh the consequences, but before patterns are applied blindly, the consequences need to be considered. In the improved design, the number of objects involved in the system was increased, but the benefits far outweighed the consequences, due to the reasons laid out at the beginning of this chapter.

Challenges

In the completion of this project there were many areas that presented challenges. This section will present some of them briefly.

There are many books covering the topic of design patterns, but most do not include tools to help with the finding of appropriate patterns. The reader must read all the patterns and deciphering which pattern applies in what situations. This is a big shortcoming because design patterns are abstract in nature, and until a person applies one to a situation they are very illusive.

The task of understanding Structured Matcher was made more difficult, because many of the objects used were from the Swing packages in Java. The decision to use Swing was two fold. First of all, Swing windowing objects were peer-less. This is to say, they did not rely (delegate to )on the code of the operating system (OS)to do the background work for display objects. Objects which delegate task to native peer ( objects of the OS ) code become inconsistent in the way they display windowing items. For example, if a program using native peers uses a button, the button would look like a button of the underlying OS; if the underlying OS was Windows95, then the button would be a Windows95 button, but if the OS was Motif, then the button would be a Motif button. Thus the same program would be able to operate on the different OS, but would have a different look and feel.

A second reason for using Swing was Swing offered new classes not available in the standard Java packages. Swing offered tree and table classes, which played important roles in the Structured Matcher program.

So while Swing provide some solutions, it also provided many headaches. Fro the duration of the project, Swing was in Beta release (a test release given to developers and testers to verify stability before normal release). Being in Beta release, there was little or no documentation on the classes and the classes were unstable with bugs or changes Sun was making to fix the bugs. Recently Sun released a new book covering Swing, Graphic Java 2: Mastering the JFC, which was a great help in understanding the Swing objects [Geary99].

Another challenge encountered was due to the changing versions of Java. In the duration of the redesign project Java went through three updates. Early in the project, the code of the Structured Matcher program was migrated to the latest version of Java. This migration was made in hopes that some of the bugs in the Java code would be fixed. To migrate to a new version, changes would not only have to be made to the code of Structured Matcher, but also to the programming environment of the software tools used. In the later half of the redesign project, it was decided to finish the project without any further migrations to new releases of Java. As a result, the Structured Matcher program is not on the latest release of Java (Java2).

Recommendations for Future Work

There are a number of areas where work can be continued with this project, and this next section lays some of these out.

A redesign needs to be considered for allowing different types of Question. In the prototype design and in the improved design, the types of Question that could be added to the system were limited to ones that had a defined set of values that could be given for answers. For example the BooleanQuestion has the set of { true, false } as valid values, and LikelihoodQuestion has the set of { Strongly Against, Against, Slightly Against, Neutral, Slightly Match, Match, Strongly Match }as its valid values. For both of these Question types, the valid values were defined before program execution. It would be nice to have a Question type which could have it set of valid values defined during run time. For example, an expert who is a doctor might use this Question type to define a question to resolve the type of pain a patient is having. So the doctor would be able to enter at run time a set of valid values for this question as { Dull, Sharp, Throbbing, … }. This case would not present a problem to most of the improved design except in the way questions are defined using the QuestionDefineDialog. QuestionDefineDialog only allows an expert to define the question name, and the body of the question, and then select the type of question. QuestionDefineDialog is shown again in Figure 43.

To be able to facilitate this new type of Question, the way questions are defined would have to be redesigned. A good redesign may be to present a dialog to retrieve the Question type and then present an appropriate dialog to define that particular Question type.

As mentioned in the challenges section, the version of Java has been updated since the redesign of Structured Matcher was completed. So the program needs to be migrated to this new version on Java ( Java 2). One of the big improvements of this version of Java is that Swing has been finally incorporated within Java Software Development Kit (SDK). In all the past versions of Java, Swing was in a separate package, and was a developmental test version.

A redesign needs to be considered to allow parameter values to be retrieved from other sources than the user, such as databases. In the prototype and improved design, the Structured Matcher program could only retrieve parameter values by asking the user questions via a pop up dialog. But there may be circumstances where the information may be more quickly or accurately retrieved from other sources. For example Structured Matcher could be hooked up to a database with a person’s medical history to gain background knowledge of the person, and the person would only be asked questions dealing with new areas.

A last recommendation for future work is in the area of documentation. Java packages are usually documented in a standard format called Application Program Interface ( API ). This format summarizes the objects of a package so the objects can be quickly understood and put to use or changed for future refinements. One advantage of documenting the objects in the API format is that Sun provides a tool to create web pages from program code which has the proper type of documentation. For work to be continued with the Structured Matcher program it needs to be documented in a way that is very accessible, this would be accomplished through the use of documenting to the API standard.