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

Milestone 2: Making Plans


In this milestone we were required to create a design for the remaining milestones using good Object Oriented design practices. We were also required to develop a mockup of our interface, scenarios, CRC cards, task list with member responsibilities, and a timeline for finishing each part of the project. Do not take this part of the project lightly! Try to make your design as flexible as possible because you will not be given the details of the last two milestones until later in the semester. If you have a rigid design, you might be going back to the drawing board, while other groups add a few simple functions and are done. Our advice: get started early and do many scenarios and walkthroughs. Have people outside of your group look at your interface mockup and pretend to use your system. Write down any inconsistencies or flaws that you discover.

Problems Encountered:

We did not encounter any problems during this phase. This was mainly due to the group dynamics. Every person in the group had worked with at least one other person in the group before. This is important. If
possible, choose people you have worked with before, who you know are willing to put in the time and effort. Most importantly, everyone in the group needs to be willing to spend time as a group. Throughout all group phases, most of the work was done as a team in the same location. If someone only wants to communicate through email or instant messenger, avoid letting them in your group. The group that works together, succeeds together.


Our design envisioned that we have the so-called frames which represent a chunk of the movie that has a certain media type (text, image, etc.). There would have been an abstract Frame class, and the different classes that represent different media types would have subclassed from it, and would have provided extra functionality, if needed (such as storing extra properties, for example).

Later on, the concept of frames had to be revised, until it started resembling Amiga module tracks, where each track carries a certain sample, which is activated at certain times. Similarly, later versions of our frames evolved to have slices, which indicate when the frame is to be activated. Hence, an image contained in a frame can appear at times 1-10 and 15-20 in the movie.

The moral of the story is, try to build in as much flexibility in your design, and cut out what you don't need in the implementation only after you're well into the testing phase.

Uploaded Image: class-diagram.gif

Class Interaction Scenario:

A class interaction scenario (a.k.a. analysis level scenario) is just a description of how the classes in your project interact to perform a specific task. The task should be narrowly defined. You should do many of these because they are useful to work out details of your design. When creating your design, keep in mind the requirements of the project. If you can not easily figure out how your classes will interact to meet the requirements, revise your design. Here is the Analysis Level Scenario that we submitted for this project.

User Interface:

To develop the design for our GUI we had one team member look at the interface requirements( play, pause, etc...) and come up with a basic GUI that met the requirements. Our entire group then reviewed the design. Having the whole group looking at the GUI and bouncing ideas off of each other really helped make the GUI more user friendly and understandable.
GUI: Sqeakers Anonymous

User Interface Scenario:

A user interface scenario is similar to a class interaction scenario, but instead of the interaction between the classes, it describes the interaction between the user and the user interface of your project. These are very useful for making sure that your user interface provides all the functionality required by the project. They are also very simple to do. Just imagine a task that the user would like to perform. Then describe step by step what the user does and what the feed back from the GUI is. Here is the User Interface Scenario that we turned in for this project.

User Interface Description:

We were asked to create a description of our user interface. The purpose of this is to make sure you really thought through your user interface. Here is our User Interface Description as an example of what the professor expects.


During this phase of the project, we were asked to create a list of responsibilities for the remaining phases of the project. This is worth the effort in case your team turns into one of those teams who cannot agree on who is supposed to do what. However, since you are still new to squeak, it will be hard to predict which parts of the project will take the longest. The moral: create the list of responsibilites, but leave room for flexibility. When we began each milestone, the first thing we did was review our list of responsibilites and revise them. This was very benificail because it kept the workload balanced. In addition, everyone knew exactly what each other was responsible for, so if one member was slacking we would know it immediately. Finally, we did not waste any effort because we never had two people working on the same exact thing. This is boring, but here is a sample Responsibility List.


During phase 2, we were also asked to create a schedule for the remaining four phases of the project. I know that most teams just made one up. DO NOT DO THIS! Take this seriously. Our schedule kept our team from pulling any all-nighters. We really did sit down and look at all of our schedules to come up with the best meeting times for all. This was very beneficial, because we did not waste effort on trying to decide when we would get together. This also kept our team motivated. We knew what to expect of each other by each meeting time. If a member did not meet the schedule the others would give him a hard time. Of course you can't anticipate all the things that can pop up during the semester, so leave some room for flexibility. The most useful thing future teams can gain from looking at our schedule, is that every milestone included time for testing and debugging. We were always basically done a couple of days before the assignment was due. We would spend the last couple of days searching for errors and improving the GUI or the performance. Here is our Schedule.

Link to this Page