View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Milestone 4 Case Study

Milestone 4 Use Case

What Image
Stephanie Smiegowski
Andrew Thigpen
Justin Daniels
Michael Wentzel

Milestone 4

The goal of milestone 4 was to take the start from M2 and the design from M3, and start to put them together as a start to the final project. Milestone two was basically like the first one, but with some building buttons. This didn?t help us revamp our design at all since the easiest way to finish the second milestone was with a hack-job that didn?t account for the design of the rest of the milestones. The UML helped us get down the general design for the whole project, but milestone 4 brought up the point of ?now what?? with the actual implementation.

The UML helped us figure out how the classes were going to interact and the basic functionality of each one (or at least what we thought we needed), but the design submitted for M3 was not detailed enough to prepare us for the coding of M4. This phase of the project was the true start of the big picture, and a very large jump start at it for that matter. We went from having a set of straight lines with some .gif buttons to having the full campus, levels of zoom, a user interface, menus with lists of buildings, and lots of code.

What Went Wrong

The issue of not accounting for the user interface definitely caught up to us in this milestone. We had to go through and design many different classes that extended existing Morphic classes to accommodate the needs of the project. And, of course, a friendly user interface had to be created. This included finding a map that was more accurate and inclusive, alter it to take off the buildings, and make the building transition over to the new map.


A large part of getting the fourth milestone working was the decision to use a parser to get the data from the alumni website instead of hard-coding data in. This was much more difficult to implement than just plugging data in, but we felt that this would be a wise decision so that other web sites could be used to pull data in from in later phases, or just change buildings as the website does. This made our program much more portable and object-oriented, but took a lot more time.
Along the lines of parsing the data and not hard-coding it in was also doing other things that made the program more portable. Placing the buildings went from placing the buildings to certain points to being able to place any number of buildings to any place necessary regardless of coordinates.
Obviously we could not add all the buildings onto the map until we got the parser working properly. After this was done we were able to finish the map up with changing the building buttons to be more visually appealing, placing them on the map correctly, and proceeded to move onto zoom. Zoom took some effort with having to deal with moving between different levels and corresponding abilities that changed with each level. One of the things we had to learn with this part was to keep track of levels between the functions and setting models correctly within our code.
The problem with all of this is that theoretically we could have done some of these things starting at milestone 2 to help alleviate the workload of milestone 4. So this was a lesson in thinking ahead as by not thinking ahead we got to think all the way through the morning of the due date.

What Went Right
While there was a lot of work for this, we do not feel that the work we did was unnecessary. There were some things that could have been done with the earlier milestones, but realistically this will never all be done at the earliest possible time. Some of the user interface stuff could have been done, but other than that the rest of the items would have just been considered working ahead.
By making the parser, we made our program very portable and when the later phases came, we didn?t have to worry about tweaking coordinates or the data of the buildings since it had all become automated. It also made a lot of things easier with the user interface as the parser had many functions built in to make accessing building data easy for all concerned.
Doing all of this work obviously was not enjoyable to do in one phase, but all groups make mistakes regarding design, and this was our time to fix our design problems that had been discovered and implement the changes correctly to avoid future problems with the project. This was what happened in this milestone, so from this aspect, M4 was where our project turned in the right direction for good which is better than happening at the last milestone.
Also, by doing our map earlier so that the coordinates were consistent, when we decided to change a map in this phase, it was as easy as changing the picture. The coordinates transferred over perfectly with the adequate map layout from previous projects.


Old Map


Uploaded Image: bigmap-lined1.gif

New Map


Uploaded Image: mainmap32.gif

Lessons to be Learned

This milestone was the big transition learning process. It was a matter of going from the UML and CRC card design created in the previous milestone to having it come to life. This is always one of the largest parts of a project no matter how good the design. One of the largest lessons of this particular milestone was that the transition can be painful to begin and working ahead is invaluable since there is often much discussion required about little details that couldn?t have been foreseen earlier on.
Design a user interface from the beginning that can morph with the project instead of being thrown out and redone later is also essential.
Making a program portable and reusable can be time-consuming at the moment but makes life easier in the end.
Always know the model.

Link to this Page