Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
Milestone 7-GUI Coding
Initially, when our team began to hammer out the backend of the program, we had many ideas, each of which sounded absolutely great. By the time our UI design was complete, we had over thirty classes, including the backend code. But this was just the design; in other words, the code wasn’t in place yet. Unfortunately for us, this meant that we had to work a lot more to get even a third of the project running. This also meant that team members would have to communicate well and each work equally so that no one member was stuck doing all the work.
This brings us to our first pitfall. In the beginning of the UI design, we allocated the layouts of all widgets to a member of our group. However, the group member didn’t complete this task in time, so most of the work had to be done between two or three people on the team. The two main problems here were that the UI layout was assigned to one person and that the other group members didn’t step in to ask what needed to be done. Because of the poor communication, our design intentions were cut down.
Another problem that we encountered was the presence of one list box which displayed two lists with a radio button to select which list was selected. Our main UI designer worked on this problem and was able to get it resolved, but this took a long time to fix. Underestimation of the problem exacerbated the issue, as we all thought that the problem would be easy to fix. It turned out that this was one of the harder tasks in the project.
The idea of saving simulations was an overestimated problem that we encountered. Because of Smalltalk’s built in BOSS framework, saving and retrieving simulations were simplified greatly. Now, creating new simulations, opening simulations, and saving simulations are trivial. Due to multithreading, saving could take some time, however; all orders in the source mentioned above have to be cleared before the program can be saved. This could potentially be an issue, as if many invoices are in the source, saving could take much more time than expected.
Multithreading was one of the strong points in our UI design. By having classes act as buffers between the front end and back end, the threads were able to seamlessly access variables and perform tasks with ease. We initially thought that the integration of threads would be especially difficult due to the fact that none of us knew how to use Smalltalk proficiently, but with hard work, the threads began to work with the rest of the application; this is one of the positive aspects of the application; because of the multithreading, simulations of supply chains are possible. Since all invoices pass through a single source, our application could model a small scale version of a popular website, such as Amazon.
Graphing was one of the more difficult portions of the project. But, after the first graph was created, creating the rest of the graphs was relatively simple. The first graph that we created was the bar graph. Initially, getting the graph to work took about three hours, but after this, creating the rest of the graphs was relatively trivial. Much more functionality had to be added to the back end in order to collect all the data needed for the graphs. This functionality took some time to create, but in the end, everything worked smoothly.
By the end, some of our expected functionality was cut, but most of it was intact. In a nutshell, problems faced included communication and underestimation of certain problems, but successes included BOSS functionality, and multithreading.
Link to this Page