Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Team Vim Pride Cases
Cases Page For Extra Credit Written Solely By/For Brian Davidson
Team Vim Pride Anything on that link is group contributed, but this page is single contribution
CRC Cards (40)
Proper notation (responsibilities as English phrases, every responsibility is matched with the necessary collaborators, etc.) - 15
Appropriate design - 25
Have enough scenarios to properly test the system - 10
Be able to walk through the scenarios with the CRC cards - 10
Draft of User Interface (40)
It demonstrates the ability to do all the things specified above - 30
It looks like it is parseable - 10
The scenario text listed above shows the proper way to do scenarios. People often confuse function list and the scenarios. Scenarios are nice stories that have the function in them but in such a way that its not about the actual methods or features it will have but what the user should be able to do when they get done. From the TA alot of people got this wrong and just put feature list.
Create new animation
Jeff opens Squeakmation. He creates a new animation. He chooses a scene
and adds some characters. He gives one of the characters something to say.
He then saves and closes Squeakmation.
The parsable user interface, aka the script, was designed in such a way that its in parts. First is the Cast part, then Is the Music Part, then is Scene Part, Finally is the script part. The first few parts are simple, name of object, newline, [tab attribute = value newline, repeat]. The last part is time, object, action, args. This script is a very simple script and through the addition fo the specail time of afterlast it allows both relative dating and absolute dating. The final script implemented in Milestone 6 was very similar to this one with a few of the seperators changed for convience.
We were rather pleased with this stage in the project, the design of our system changed very little from teh intial design. The crc cards are not avaible because they were hand drawn and never returned which prevented us from scanning them in. But to say this moslty the same classses we have in the final uml shown below is the same classes and items that our crc cards contained. For future students, I would suggest getting a big dry erase board as we did and draw out the CRC cards on them. Then have people bring up squeak and check to make sure some of the basic functions exists, as you go through call by call and check to see if it will work. Like check on the SortedCollection when we use the EventSequence, which is a sorted collection, on how the sorting works and the temporal impact to accessing.
CRC Cards / Scenarios - 10
Unit Tests (50)
Good object-oriented style - 5
They work / are in proper format - 10
They cover the design - 25
They correspond to the UML - 10
Proper notation - 10
Class diagrams represent the design - 20
One other diagram is appropriate, and useful - 10
This was also a rather productive milestone. There were no major changes to the CRC Cards or Scenarios from the first one. The UML was created and photographs were taken of it and placed on the coweb. The unit test were created and the event queue system was semi-coded. There is example code that we started off with on the coweb page linked above, that was used to develope the real event system. The one major issue was the over reliance on threads, we got a little tread happy in this design which was problematic as we had to fix it in milestone 5 when there were thread conflicts that occurred in the turnin for milestone 4. Had we done more intesive testing of threading in milestone 3 to relize that we shoudlnt use threads like we did we could have saved alot of work and rewriting the even system and the unit test for the event system. The event system, in this milestone and in milestone 4, worked by creating a new thread for each event which would create new threads for its dependent events when the event is done and then die. The problem was that they both checked back with the main thread, which caused alot of semifore locks and concurency conditions, that caused it to run really slow and lock up as the threads were switching back and forth at hypersonic speed and nothing really getting done. As a recommendation to future students I suggest that while you dont need a complete working system in this milestone, you should prototype the core of the system with enough weight that it will be effective.
Updated CRC Cards and UML class diagram - 10
SUnit Tests - 10
Good object-oriented style, comments (class and method), and readable code - 10
The characters can do head-like things: blink, nod, open-mouth, etc. - 5
The characters can do body-like things: walk, wave, jump, etc. - 5
Characters can speak with both speech bubbles and voice synthesis. - 5
Mouth move along with speech. - 5
The same character can have different looks (such as a side view). - 5
Scene switches are possible. - 5
The perspective should be flexible, allowing background moving and pans. - 5
The perspective can focus such that one character/object is always in the center. - 5
It's possible to queue an action at an arbitrary point in time -5
It's possible to queue an action after another action has finished - 5
The scripting interface allows you to control all the features above. - 5
The scripting interface allows you to define new character and place them in a scene. - 5
You have a small animation that demonstrates the functionality - 10
As mentioned in the milestone 3 the whole event system had major problems in this milestone. While it did work, I wouldnt run anything on it. In the cross over between milestone 3 and milestone 4 the event system code was written and simpel square morph moving test code was written. It was rather simple and only 2 things ever moved at a time and the main checking code was the main squeak thread since i executed it within a workspace, but the problem arose that when modulizing this into the acutal code the threading wasnt the same, and everything sorta broke down. But that was a major bug only discovered in teh last few days. Second, the original GUI that was designed in the begginning of this milestone never actually made it to being turned in at all. There were serious problems with the gui and the bad object oriented design of the gui, it was hacked together. Due to spring break extension, there was extra time to completely rewrite the whole gui and fix all the problems with the gui. The new gui is exactly like the current gui except without all the checks that were added in milestone 5. It was not our intention in this milestone to halfway accomplish milestone 5 but that was a lucky side effect. I strongly recommend to future students, that you should design a working gui even if there is no backend, just use 'Transcript show' to show the output of certain actions, but its key because you will also run into errors with backend componnents that were totally unforceable in small testing. In retrospect, the dependence on threads was too much, and the threads did to little to constitue the overhead of the switching, but at the time they worked. The gui however was a oversite in task division, the group was split with not enough code review on the other half to find out that the gui designed wouldnt function as needed, thus there was the need to overhall the gui at the last minute.
Fully implements extension idea submitted - 40
SUnit - 5
Good object-oriented style, comments, and readable code - 10
Attend and review 3 other presentations - 10 (this is an individual grade)
Your animation is entertaining and/or informative - 10
Your presentation demonstrates your AnimationStudio features - 10
Update CRC Cards / Scenarios - 5
UML - 5
Update Test Plan - 5
The source code we turned in for Milestone 5
With the regular task for milestone 5 was the task of completley rewrting the event system to be a single thread that launches events (with a certain time step that it should complete instead of runnign till done) and keep giving time steps to the events till done. This is similar to a cpu process scheduler, in the fact that we just go through them giving each a piece, and starting new ones when necessary.
For milestone 5, the extension, we choose to design a user proof interface, thus no errors can be made that will cause the script to fail to execute. This user interface was designed through a series of PluggableListMorphs, as seen below.
Through the lack of proper documentation and discussion of pluggable list morphs, I will go into some detail here about how to use them. The following code sample comes from the main gui morph for the display, I create 5 Pluggable List Morphs and set them as dependents. I set the associated indexes for the list of each one to 0 thus the list is not preset with a value. I define the selectors and the object of selection.
charactersListMorph on: self list: #charactersList selected: #charactersListIndex changeSelected: #charactersListIndex: menu: #charactersListMenu: keystroke: #arrowKey:from:. self is the object, #characterList is the selector for the method that it uses to get the list of list items, #charactersListIndex is the getter for the index that i setup earlier to 0, #characterListIndex: is the setter for the same index, #characterListMenu: is the initializer for the menu when the menu square in the upper right hand corner of the pluggable list morph is clicked (This menu passes in a menu that should be modified with the contents you want), #arrowKey:from: is something that is inherited so dont worry about it.
charactersListMorph _ PluggableListMorph new color: Color lightGray.
visualsListMorph _ PluggableListMorph new color: Color lightGray.
soundsListMorph _ PluggableListMorph new color: Color lightGray.
scenesListMorph _ PluggableListMorph new color: Color lightGray.
eventsListMorph _ PluggableListMorph new color: Color lightGray.
self addDependent: charactersListMorph.
self addDependent: visualsListMorph.
self addDependent: soundsListMorph.
self addDependent: scenesListMorph.
self addDependent: eventsListMorph.
charactersIndex _ 0.
visualsIndex _ 0.
soundsIndex _ 0.
scenesIndex _ 0.
eventsIndex _ 0.
charactersListMorph on: self list: #charactersList selected: #charactersListIndex changeSelected: #charactersListIndex: menu: #charactersListMenu: keystroke: #arrowKey:from:.
visualsListMorph on: self list: #visualsList selected: #visualsListIndex changeSelected: #visualsListIndex: menu: #visualsListMenu: keystroke: #arrowKey:from:.
soundsListMorph on: self list: #soundsList selected: #soundsListIndex changeSelected: #soundsListIndex: menu: #soundsListMenu: keystroke: #arrowKey:from:.
scenesListMorph on: self list: #scenesList selected: #scenesListIndex changeSelected: #scenesListIndex: menu: #scenesListMenu: keystroke: #arrowKey:from:.
eventsListMorph on: self list: #eventsList selected: #eventsListIndex changeSelected: #eventsListIndex: menu: #eventsListMenu: keystroke: #arrowKey:from:.
(visualsListMorph position: 0@500) extent: 100@100.
(charactersListMorph position: 100@500) extent: 100@100.
(soundsListMorph position: 200@500) extent: 100@100.
(scenesListMorph position: 300@500) extent: 100@100.
(eventsListMorph position: 400@500) extent: 400@100.
self addMorph: charactersListMorph.
self addMorph: visualsListMorph.
self addMorph: soundsListMorph.
self addMorph: scenesListMorph.
self addMorph: eventsListMorph.
To set up the menu is rather simple you call into it with the method labels and supply the labels with a newline between and later supply the #selectors for those lables. The lines: #(2 3) specifies that I want horizontal line breaks in the menu after remove Character and after add new Character, specifically after the indexes which are given.
^ menu labels: ' edit Character
add new Character
move character up one
move character down one
move character to top
move character to bottom'
lines: #(2 3)
selections: #(editCharacter removeCharacter addCharacter moveCharacterUp moveCharacterDown moveCharacterTop moveCharacterBottom).
To get the extension implementation part of the grade we also added checking as shown in the image down below. The checking for dependency on removal is crucial to ensure that there is not a phantom reminent object left behind that will cause the script to fail to be parsed. In the center of the screen is another PluggableInputMorph but this time its in a custom designed pop up, and allows the user to edit the attributes of the object but still preserve the data of the object. Allowing straight text modification of the data is possible but not a good idea for then simple typo errors could cause large issues that may not be able to be resolved. When wanting to modify an attribute a FillInTheBlank morph is launched with through description of the attribute with current value, possible values, etc. There is type checking on the input to ensure that it will sucessfully work in the system, another security to enable bug proof animations.
The milestone 5 was a monsterious job, almost as bad as milestone 4 since in that milestone the gui had to be rewrote entirely. In milestone 5 we had to add all the functionality that we left out but alwasy wanted, which incuded the ability for sound, and pauseing, playing, and stopping. And the rewriting of the event sytstem, finishing off the forced user interface extension. There was alot, and to future students if you schedule your time better than we did and not have these bugs that get pushed back through a milestone then you could have an easier time. My overall suggestion for coing part of the class is that try to have NO BUGS at turn in for a milestone. Try actually to have no bugs day before milestone, so when you run into one you cna have it fixed.
The WeGLOW '06 Review of Our Milestone 5
The Vim Pride Rebutal of Our Milestone 5
Some test fix source code for Our Milestone 6
One of the first issues issues reported was the fact that you can’t delete an object without dependencies. When attempting to do so, the safety net, as described above, would catch the attempt and handle it as if there were dependencies. This error is the simplest of the errors that was reported. Due to a refactoring bug, the message “isNil” no longer is enough to check the dependencies but rather “isEmptyOrNil” is needed. By replacing this in four locations, the error is fixed. We have made this change and verified the result.
"remove the selected character"
| temp events scenes string |
temp _ self charactersListIndex.
temp > 0 ifTrue:[
events _ self findDependentEvents: ((self characters) at: temp).
scenes _ self findDependentScenes: ((self characters) at: temp).
((events isEmptyOrNil) and: [scenes isEmptyOrNil]) ifTrue: [
(self characters) removeAt: temp.
] ifFalse: [
string _ 'The remove did not occur because dependencies exist in the following'.
(events size > 0) ifTrue: [ string _ string, String crlf , 'EVENTS', String crlf].
events do: [:event |
string _ string, ((animationMagic scriptData) getEventString: event withParser: (animationMagic squeakmation parser)), String crlf .
(scenes size > 0) ifTrue: [ string _ string, String crlf , 'SCENES', String crlf].
scenes do: [:scene |
string _ string , (scene at: 'name') , String crlf .
PopUpMenu inform: string.
"need to also change the events"
self charactersListIndex: 0.
self changed: #charactersList.
Another one of the issues reported in milestone 6 was inefficiency in the creating of events. Currently, in Milestone 5, to create an event the user must first bring up the events menu, menu select the object and menu select the type of event. This will create the generic event for that object with that type, and then it is necessary to customize the event. This entails changing any attributes that are needed to be customized (e.g. time and duration), menu-selecting ‘Edit Attribute’ and then finally inputting the value, and repeating this for each action.
We will concede the fact that it is a slow process, but there is type checking at the end and syntax compliance forced throughout so we feel the slowness and complexity of the design is good. If the end user already knows what he wants to accomplish, the process can go quicker. To further ease the speed of the system, the group suggested using a double click method to bring up the menus, instead of the default method for “PluggableListMorph” which is to select from the list and click the menu button or use the yellow mouse button. To implement code for double click support requires little change since, the menu code is already in place for normal action support. To support double click requires a new method which is 4 lines of code for each menu and initialization of the double click selector thus approximately 20 lines of code total. The code will be similar to the following. This simple change has been tested and it does not impact the object oriented design at all.
| menu |
menu _ MenuMorph new defaultTarget: self.
(self charactersListIndex > 0) ifFalse: [self charactersListIndex: charactersLastIndex].
self charactersListMenu: menu.
menu popUpEvent: self activeHand lastEvent in: self world.
charactersListMorph doubleClickSelector: #doubleClickCharacter.
Another few issues that were reported were related to simple bug errors due to refactoring the code to allow for better checking. The issue that we werent doing checks on renaming was an oversite, and some other simple errors were oversite. In the code provides for this milestone, even though it wasnt required to fix anything, the bugs have been fixed and the double clicking enabled to show how easly PluggableListMorphs can be used and how they really do provide a very user friendly, and stable error proof system. To future students, if this is the same Milestone 6, I recommend doing what I did and figure out the code to fix one or two of the bugs, because if its not much it shows how well the object oriented design was. And it will make the future users of the project in the cases page, so much happier.
Overall, this project was a suprising sucess in the fact that with all the rewrites to the gui and the event system (event though the class responsibilty and dependency stayed the same the core functionaliyt changed greatly). There was alot that changed and alot that was unexpected as in bugs errors and etc. I personally was rather glad when I was actually able to get it done and turned in and able to demo it and get mostly possitive feedback from the fellow student. Mind you there was the one very very very hateful one about how you shouldnt have such a complicated menu system. The complicated menu system was INTENTIONAL, it was there to force the user to comply to the protocol, we could have allowed the user more freedom, but with freedom comes great responsibility. And our design was for a system where new squeak users could feel confortable in.
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu