The final system that is delivered is similar in most parts to the original design. The changes that were made fall into 2 categories: graphics and coupling. The final graphic routines effected the design because of double buffering. The original design had low coupling along with autonomous fish. The end design has high coupling but the fish are still in control of themselves.
The original design for the graphics was to have each fish have its drawing loop run in its own thread, updating the screen periodically. Therefore each fish ran in its own thread with it also accepting messages up and down the fish list. The only problem with that is that the animation flickered badly. The fix was to use double buffering. This moved the threading into a different class that cycled through the class having each fish draw itself to the buffer and then updating the buffer.
Part of the basis of the design was that the fish have free will to go wherever they want following certain well defined rules. The rest of the system was designed to facilitate this. However this idea had a circular dependency built into it from the beginning because the fish were dependent on the fish shippers who were dependent on a fish tank that was dependent on a fish list which is dependent on fish. What was not known was that allowing the fish autonomy forced a dependence between most layers (fish have pointers to fish list, fish list is dependent on fish tank and so on.) While there may be a better design to eliminate this, the current design works. During the coding there was a constant trade off between low coupling and having the fish be autonomous. The fish always won.
Another important principle in the design was that the network needed to be robust. At the time the system was designed, only applications could talk to host other than the server they were loaded from. We felt that a system the relied on one server would be more prone to failure than a system that had nodes that only needed a server once when they started up. These 2 factors led to each fish tank being a Java application. 3 months later, breaking out of the Java sandbox is on the horizon and would be a better way to disseminate the fish tank. In another 6-12 months the fish tank should be an signed applet that is on a web page that would function identically to the application but would be easier for the user to use.
Each fish performs some calculation. The original design called for all of the fish to work on the same problem. This is what is implemented. However it would be a moderately difficult task to convert the system so that a user can start his/her own fish server up and have fish that originate from that tank work on that problem. Fish from tanks that do not have fish servers would ask a directory of fish servers for a fish server to work for. Problems that would have to be solved is dynamically sending code across the network as well as keeping a dynamic registry.
One problem that was not envisioned when the project was designed was the imbalance of the knowledge of tanks. In a large system fish know about many tanks and will randomly go to a different tank. In small systems fish tend to clump on one or 2 machines. Limiting the number of fish allowed in a fish tank introduces live lock situations in small systems (small here is 3-5 tanks.) It became obvious that the fish had to die and it is based on the number of hops it has made.
The design overall was a good one for this system. It should not be used as a template for other similar systems unless it is determined that the circular dependencies cannot be avoided. This system is small enough and the number of people working on it is small enough that we did not run into problems controlling the development.
Implementing the design did show that the design did not completely specify everything (in fact it had serious defects in it that were not evident until the group started coding it.) However the design was still a good guide for what should be done. The decisions that needed to be made were then made based on the principles that were used for the design.
The system does display the guiding principles that the design was based off of. The fish are autonomous, swimming to various tanks whenever they want to. The system is robust, tanking tanks off line do not effect other tanks and the tank server is only needed to bring tanks on line. Overall I would say that the system is not complete, but as the first version it is a success.
This addendum to the original critique will address some additional issues beyond the design of the system and its success and failure. Instead, it will concentrate upon the Java AWT and the UI issues encountered during development.
The first and largest issue is that we needed to use JDK 1.1 for our project. While the change from JDK 1.02 to JDK 1.1 was seamless for the other classes, the AWT over went an almost complete revamp by Sun. True, all the methods from 1.02 are still supported by 1.1, but they are tagged as "depreciated" and there is no assurance that they will be supported in future updates of the JDK. While this would not be so bad under normal circumstances, it was not especially easy to adapt to these changes. First, there is zero documentation in the form of text books and sample code about the changes in the AWT besides some (admittedly helpful) HTML pages on the Sunsoft web site. Seeming how Sun made both trivial changes (such as renaming a size() method to getSize() because it seemed more "consistent") and fundamental changes (such as redoing event handling completely, so that handleEvent is no longer used), some advance release would have been appreciated. Additionally, I had already modified sample menubar code, all of which were now "depreciated." So, I have slowly been attempting to change depreciated methods one at a time, but they have not been completely eliminated.
Second, while Sun seems committed to a cross platform strategy, it has yet to release a version of the JDK higher than 1.02 for the Macintosh. While it seems unlikely that Solaris, Windows 95/NT, and MacOS will all be released at once, it hindered my development because I could not do any serious work from my personal computer. Since SRL was stocked with slow IPXes, this was a problem.
Otherwise, the UI methods and classes went smoothly. Everything was up and running without much hassle, but it helped that I had already spent time using the AWT for another class. Compared to C or C++, this was very simple and easy.