Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
DDMM-Milestone 2
Expected Output:
For this milestone we were required to produce a design for what would become "The David Bowie Movie Maker". The following is a step by step description of what our group went through to create this design.
- Description of user interface.
- Screen mockup.
- Walkthrough of a user interface usage scenario.
- Walkthrough of a analysis scenario of data.
- CRC cards.
- Class Diagram
- Project Timeline
- Member Responsibilities
User Interface
Design
The first thing we decided to discuss in our group was what our movie maker was going to look like and how the user would interact with it. After a brief discussion of different ways to implement the user interface - between having a remote control and having the movie be full screen or having a static control panel and having the movie just be played in a morphic window - we decided to make some decisions and write stuff down. At this point we could have chosen any user interface; we were not worring about implementation at this point so the decision was arbitrary. After some sketches, we agreed upon one thing and a kindly group member of ours went home and pretty-ized it in a way that none of us would have had the willingness to do.
Usage Scenerio
Once we had the basic interface down we went into a more detailed description of what would happen when the user decided to interact with the program. We just expanded on our informal discussions and wrote down what would become our user interface usage scenario document. This document is listed above (below the GUI layout).
Movie Implementation
Analysis Scenario
Our next step was to walk through how the program would actually work on the inside. To do this we looked at the design of our movie editor and used that as a guide to help us along in the scenario. The following is one of the many scenarios that we came up with.
Adding A Movie Item:
1. User clicks on the "add" button.
2. The button sends a message to the MovieEditor notifying it that the "add" button had been clicked.
3. MovieEditor opens a DiskFileDialogPanel to show the list of files located on the user's computer for his selection.
4. User selects the file and clicks on an "open" button.
5. The "open" button notifies MovieEditor that a selection was made and passes the name of the selected file to it.
6. MovieEditor generates an instance of MovieItem, sets the data, and passes that to its MovieItemsCollection for adding.
7. MovieItemsCollection is the 'storage' for all the pictures and will have a method that saves a MovieItem to its list.
CRC Cards
After sorting out what the basic functional implementation of our movie editor we had a pretty good idea of what our classes were going to be. We began by writing down the basics classes such as MovieEditor, MovieItem and so forth. These rough layouts turned out to be our crc cards as follows:
To see our crc cards please click on the following link:
DBMM-M2-CRC
Class Diagram
We decided to go with the basic MVC model for our class diagram, however we put a little twist on it by allowing the individual MovieItem types to play themselves (allowing the model to have the view functionality). This worked perfect in the end because all of the different types of MovieItems were handled completely differently.
Many of the clases in the diagram should be clear in their purpose in in our program, but some parts deserve a bit more attention as to why they are hooked in the way they are.
MovieItemsCollection
This class was designed to be the sotrage of all the individual MovieItems that would be required for the Movie Editor. Acoording to the MVC paradigm, this class was the an essential component of the model, providing functionality that, put into any other class, could shift power too an unhealthy degree. It dealt with any issues regarding organization, creation, deletion, editing, finding the end time of the entire movie, etc.. of movie items, or any issues that required to manipulate the movie items as a whole. For any functionalities that were specific to a movie item, the MovieItemsCollection could be served to delegate those message calls to the movie items in its storage. Whether to implement this storage as a array, or linked list, or a tree is implementation specific, thus that part should not be of concern in the design stages. The important step was to identify the role of this class and the roles it would (or could in the future) carry out. This class also had no knowledge the user interface part (good MVC), or the MovieEditor for that matter, and can remain completely separate from it. Communication with the two sides can be simply done by have having the user interface gather input from the user and making method calls to this class with thoses parameters. So in the future if the UI were to have a different look, this class would not need to be changed.
MovieScreen
This class implements the mechanism by which the MovieItems are displayed (or played audibly) for the movie. In order to do this, it simply needs to send the #activateOn: message to the MovieItem, which should know how to handle its own activation.
MovieItemDialog, MovieSummaryPanel, MovieItemsListPanel, DiskFileDialogPanel
These classes are the ones that interact directly with the user (aside from the user pressing buttons on the MovieEditorUI). In short: the MovieItemDialog provides a window with a series of text fields wherein the user can enter data pertaining to aspects of the MovieItem the MovieSummaryPanel is a morph that simply lists a summary of the movie currently being used by the MovieEditor, and it knows what to display by asking the MovieItems passed to it in MovieItemCollection for a summary of themselves; the MovieItemsListPanel is similar to the MovieSummaryPanel in that it displays a summary of the movie, but it also provides the mechanism for the user to edit and/or remove items; DiskFileDialogPanel is a morph that enables the user to view the contents of their hard drive and select a file to be added to the movie. All of these classes extend the built-in Squeak SystemWindow. We decided to do this because it gave us greater control over the windows themselves, especially with regards to getting rid of "ugly" Squeak aspects of the window.
MovieSecondsTicker
This class is simply a timer that, every second, sends a message to the MovieEditor is connected to telling it that a second has passed. This is pretty much exactly the same as the class in the book. Another way of providing this same functionality, however, would be to eliminate the MovieSecondsTicker and use the built-in Squeak #step mechanism, which we discovered too far a long to bother changing.
Roses and such
Not only did the group discuss how the classes were going to be hooked up, but we also spent a reasonable amount of time discussing the names of the classes. The main issues that were raised in this discussion was the use of plurality of class names, "Window" vs "Panel" vs "Dialog", and the name of the DiskFileDialogPanel class. While I personally was a proponent of naming GUI classes by suffixing them with Window, some group members were unhappy with this choice of words. In an apparent misnomer, many of the classes that probably should have had the "Window" tacked on at the end ended up with "Panel." I say misnomer because the reasoning for this was "That's what they're called in Java." Well, in fact, they're not; they're called frames. There were also heated arguments over whether or not a "Dialog" was just another word for "Window". We decided on a vocabulary of sorts, though, with windows being referred to as "Panels" and windows that were small and used for a greater degree of user input "Dialog" (that is, it's a dialog between the user and the program).
Which brings up the issue of DiskFileDialogPanel. Well, we went through a whole host of names for this one, with nobody being completely satisfied. We knew it had to have either "Disk" or "File" in it, since it would be for opening files on the user's hard disk. And it should probably be indicated that it's a window in-and-of itself, so "Window," "Panel," or "Dialog" was needed. In the end, we just sort of stuck a bunch of nouns together that appeased everybody. Even now we get our giggles of the name of this class, because it's just obsurd. I think so, at least. So maybe it's just me that gets giggles.
Project Plan
Project Timeline
Once we figured out what needed to be done all that was left was to figure out when we needed to do it. The following was what we came up with as a rough outline:
schedule.doc
Member Responsibilities
As requested by the .nfo file we also included a break up of who was responsible for what - most of these decisions were based upon what interests the people had.
responsibility.doc
Link to this Page