A Object-Oriented Implementation of a Chemical Waste Consolidation Expert System

Return to front page

1. Background and Rationale


2. Interface Design

• 2.1. The Chemical and Chemical Mixture Interface
• 2.2. The Bottle or Transporter Interface
• 2.3. The Drum Storage Interface

3. System Design

• 3.1. System Environment
• 3.2. The Waste Consolidation System Design Overview
• 3.3. The Chemical Library: Class ChemBook
• 3.4. The Bottle (Transporter) Library: Class BottleBook
• 3.5. The Drum Library: Class DrumBook

4. Evaluation and Results

• 4.1. Real-Time Application of Prototype
• 4.2. Software and Logic Testing
• 4.3. Usability Testing
  

5. Future Work

6. Conclusions

Bibliography and References

Appendix A. Example Drum Report

Appendix B. Chemical Compatibility Testing Data

2. Interface Design

The waste consolidation system assists with the consolidation of the various waste streams from the University to achieve a minimized cost from the waste contractor. The core software operates on three distinct libraries, each a fundamental building block for the next successor library. The entry screen to the waste consolidation software is illustrated in Figure 2.1. It includes disclaimers and warnings about the efficacy of the software and the dangerous nature of the consolidation process in general. The disclaimer states that “chemical consolidation is dangerous by nature and should only be attempted by a trained professional.” It is not intended to allow a person with minimal chemistry knowledge to consolidate waste; it is meant to make suggestions to trained chemists.

Figure 2.1. The Waste Consolidation Disclaimer Screen

The original proposal suggested modularization of the software into four divisions comprised of the initial collection of intermediate containers, data acquisition session, the bulk consolidation session and the data reconciliation session. This seemed logical from an exterior view but proved problematic from a programming standpoint; it did not lend itself to object-oriented division and well-defined classes. Writing a class to encompass an action such as consolidating the bottles overlaps multiple libraries and different data structure types, with no clearly defined functional boundaries. This fact became obvious during initial software design and spelled complete demise for the first prototype. The final division of the software and interface is completely obvious when considering the physical objects that the process employs: chemicals, bottles and drums. The Main Menu exemplifies the division of labor in the software itself and is shown in Figure 2.2.

Figure 2.2.   Main Menu of Consolidation Software

The software is hierarchical in construction. As shown in Figure 2.3, the smallest unit is the chemical, which is the building block for the intermediate containers.

Figure 2.3  The Drum Building Blocks

The drums contain multiple transporters or intermediate containers. It is easier and more intuitive to call the intermediate transporter containers “bottles” because the intermediate containers are predominately single gallon glass receptacles, although they can range from a few milligrams up to the standard 55 gallon drum. Glass is the small transport container of choice for almost all reactive or questionable chemical waste despite having the distinct disadvantage of being susceptible to impact breakage. It is non-reactive to the broadest spectrum of chemicals. Since it is the primary packaging from the chemical vendors, these bottles are readily available for recycle service as chemical waste transporters.