Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Team 2 + 2 = 4
- Angela Liang
- Andrew Heckman
- Leslie Kubilius
- Greg Smith
Welcome to Team 2 + 2 = 4 case page. I bet you're wondering about our name. Well, even if you're not, here's the story anyway. Angela and Andrew were stuck with 2 other people at the beginning of the semester. One of the members decided to tell us he dropped the class the day milestone 2 was due. The other team member decided to stay in the class but didn't show up to any meetings. Meanwhile, Leslie and Greg were stuck with 2 team members that said they finished the milestone but once the due date came along, nothing was completed and they dropped the class. Both teams made Prof. Pierce aware of the situation and a new team was made when he said, "well, I know what happened and last time I remember 2 + 2 = 4." Hence the name “Team 2 + 2 = 4.” Yes, we know it's lame but anything is better than "unnamed 12."
So, what's the moral of the story? Pick reliable team members! By reliable, we don't mean you're best friend. Make sure your team members are hard-working people.
- Read and follow the Tips for working in groups page. This will help in avoiding conflicts and misunderstandings.
- Start early!! We cannot stress this part enough!
- Merge code early. Don't wait until the last minute to merge code. Code merges don't always go as planned.
- When emailing, email everyone, even if the email does not directly concern the group member. It's better to be safe than sorry.
- If the mouse is irritating but it's too cute to close, create and new morphic project and do all your code inside. To open a new mophic project, click on the world (any empty space), select 'open', then select 'morphic project'. A orange box will appear and click on it to go to a blank screen. You can create multiple morphic projects and switch back and forth between projects.
- Design the system as a group. Read milestone 3 for more info.
- Remember to document your code. TAs will take off points if you don’t document the classes and methods. Documenting also helps your teammate because they might have to work with on your code in future milestones.
- Even if you don’t use some fancy version control system for your code, you need to keep track of the code somehow. Our group used Yahoo briefcase to keep .st files. Usually, we don’t have problems with changing classes but the briefcase allows us to access our code from anywhere.
- Demo your system to the TA before the due date. This allows the TA to give you feedback on your design and implementation. Schedule this part at the beginning of the semester. That way, the group knows the date and time of the demo.
- If you don’t understand the requirements, ask. The coweb and newsgroup are monitored pretty well and questions are almost always answered in a timely manner.
- Schedule weekly group meetings. Set aside an hour to talk about the project. This allows the group to know where each member stands. This also allows members who are having trouble to seek other group members for help on a topic.
- Type all your code in the workspace, make sure it works, then copy and paste it in your method.
- After the code for the milestone has been completed, read through the requirements again. This ensures that you have every requirement before turning in the milestone.
- Read the entire project at the beginning. Try to code all your functions with the idea of expanding it in later milestones.
- Save and save often. Squeak crashes... especially with wonderland.
- Take a break. Whenever you feel frustrated, take a break. Squeak can be very frustrating.
Milestone 1: Create a help repository
The assignment for this milestone is located here:http://coweb.cc.gatech.edu/cs2340/3155
This milestone was an individual assignment to introduce Squeak. It's important for everyone to sit down and play around with Squeak before doing this milestone. When I was doing this assignment, it took me a while to realize how object-oriented this program is. It's nothing compared to java or C.
There's an easy way and a hard way to do this part. The easy way is to realize that Squeak is object-oriented and look at the existing methods given. The hard way is to ignore the that Squeak is object-oriented and to program it like C. Doing it the hard way makes the methods really long and hard to read.
Remember to comment the "?" area. We all lost points because we either didn't know about it or didn't remember. Also remember to comment individual methods even if it is copying and pasting from the project description. This will help you or your teammate in your future milestones.
Code for Milestone 1: M1.zip
Milestone 2: Create a Simple Guide
The assignment for this milestone is located here: http://coweb.cc.gatech.edu/cs2340/3157
This milestone involved creating a simple guide for beginning squeak users. This milestone also involved finding group members. Finding group members is an important part in this class. You need to find hard-working group members. Start early. If you wait until the last minute to find group members, all the good ones may already be taken. Then you will find yourself with other procrastinators. Try to form your team early. If you wait until 2 days before the project is due to find group members, then expect an all-nighter. If you have trouble finding group members, try the newsgroup or talk to someone sitting next to you. I know, I know, CS people are introverts and shy but in the real world, you need to work with people.
After getting to know our group members, we started on the assignment. As our team found out, this was not an easy task. This was quite a task because none of us were familiar enough with Squeak to use it, let alone write a simple guide for beginners using Squeak. We got around that problem by exploring Squeak ourselves and learning how to find the classes and methods we need.
Go to lectures. The lectures helped a lot because it gave example code. It gives you a starting point on the milestone. Our repository needed a GUI for this milestone so before we sat down to do the GUI, we looked at the morphic class. When starting a GUI, start with a SystemWindow and add parts like the java programming language. PluggableListMorph, AlignmentMorph, and PluggableButtonMorph might help you. You should also look at the properties of windows. For example, the workspace is made up of PluggableText.
Here's the GUI for our system:
Figure 1: Repository Browser
We decided to make our design simple, yet useful. The instructions for loading instructions were given when the browser starts up because it would be useful to the user of the system.
Figure 2: Loading Task
To load a task, our group decided to simply bring up a StandardFileMenu so the user can select the name of the file to load. We decided not to use another window because the menu gives us all the functionality we needed to load a task. Using another window would complicate the system.
Figure 3: Adding a new task
To add a task, click on the ‘Add New Task’ button. This will bring up a window to add the task name, task description, and steps. We decided to use a separate window because a lot of information is needed to add a new task. We want the user to be able to modify their changes. For example, if the user chooses to modify the task description after adding a few steps, s/he may do so. To add a new step, the user simply clicks on the ‘Add New Step’ button and enters in the step. We decided to use the FillInTheBlank request because that method handled taking in a string using a dialog box. The user may also edit previous steps. This also uses the FillInTheBlank request method but includes the step to be edited. We used a PluggableTextMorph for the task name and task description. This morph required us to accept the string after hitting the “enter” key. Therefore, after the user enters the task name or task description, s/he must hit enter before the ‘Done’ button works. We could not figure out how to accept the text once the user hits done so we used an alternative.
Figure 4: New task added in Repository Browser
Once the task has been added, the browser GUI refreshes with the new task.
For this milestone, the 'Guide' was really just a collection of methods to be used later by the UI for Milestone 4 to provide help on tasks for the user. This is separate from the browser (above) which is used to add/remove tasks from the repository. This part of the milestone was rather simple, the only important thing was to design the Guide to meet the requirements for the milestone as easily as possible, WHILE making it easy to add later functionality. This made our lives much easier when we reached M7 and had to add features like searching for free-form text and handling incompetent users.
Code for Milestone 2: M2.zip
Milestone 3: Design Everything
The assignment for this milestone is located here: http://coweb.cc.gatech.edu/cs2340/3159
This milestone involved designing the system and did not involve coding. Although this milestone seemed relatively easy at first, our group probably put more thought in to this milestone than any other milestone. It involved all of us to put our minds together and come up with a design for the rest of the system. We realize that if we figure out the design portion during this milestone, then we don’t need to modify the design later. This required some abstract thinking. Up until this milestone, our group had no experience with 3D and most of us were still thinking functionally instead of object-orientedly (if that’s a real word). So before we started to design the system, we have to know more about squeak. We first broke up the rest of the milestones. The milestones looked easy enough that 2 people can handle each milestone. Therefore, we rotated between 2 people for each milestone. That also allowed us to just past .st files around instead of using a repository. Merging was also easier this way because each team member would be working on a different portion of the system.
After we split up the task, team members became specialist for their section. For example, someone would focus on 3D and wonderland while another person would focus on the guide interface. After each team member learns about their section, we came together as a group and read the requirements for each milestone. We started with the UML diagram and then had no idea how to do the scenarios and CRC cards. Learn from our mistakes, don’t do the UML diagram first. Make your life easy and start with the scenarios.
After being scolded by our TA, we started our design by coming up with scenarios. Then we produced CRC cards (using real note cards) and walked through each scenario. Walking through scenarios helped us realize functions we were missing on our CRC cards. It also gave us more information about the relation between classes.
Another note on scenarios: make sure you read every requirement for the project (including future milestones) so your scenarios cover every possible case. We missed a scenario concerning a requirement in Milestone 7. It wasn't a big deal, we only lost a point, but its the small losses that are easy to avoid that can add up and make the difference in the end.
Upon completing the CRC cards, all we had to do was draw the UML diagram. Doing the scenarios and CRC cards made drawing the UML diagram very easy. We had all our classes and methods needed. All that was left was determining the relationship among classes.
What’s the moral of this milestone? Start your design with scenarios. After that, use real card for your CRC cards and play around with them. I know, you think it’s retarded and our group thought it was retarded too, but there’s a reason for that. It actually allows you to become familiar with each class and their responsibilities. It also makes your life easier when doing the UML diagram and class description.
We also recommend doing the design together as a group instead of separately. Don’t try to assign scenarios to one person, CRC cards to another person, and UML diagram to the other team member. When you guys come together, it will be a big mess and there will be 3 different designs. Doing the design as a group allows each person to contribute, to know the design of the entire system, and to be aware of his/her responsibilities.
Design for Milestone 3: M3.zip
Milestone 4: Give Your Guide an Interface
The assignment for this milestone is located here: http://coweb.cc.gatech.edu/cs2340/3161
This milestone involved incorporating 2D and 3D in Squeak. When we read the milestone, it seems like there was some sort of function to incorporate 2D and 3D. Once we found out there wasn’t a function, we looked into creating 3D objects in Squeak. This was not an easy task because it would have involved using some type of 3D editors and unless someone is good at Maya, this was not recommended. We asked the TA for advice and we were suppose to USE a 3D character, not CREATE a 3D character. This was very confusing because the requirements say, “To embody your Guide, create a 3D character that you can….” Therefore, we spent a lot of time on something we didn’t need to.
After we determined our character to be the bunny, we explored “Squeak in 3D” under “The Worlds of Squeak.” This was very useful because it came with a tutorial about Wonderland. The Quick Reference was also very useful because it acted as documentation for how 3D worked. Playing around with the scripting allowed us to be familiarized with the code and then it was easier for us to make the bunny do 3 amusing idle behavior. Our amusing behaviors are hopping, breathing, and a head spin. To see the amusing behavior, read the readme.txt file for milestone 4.
In order to attach the Avatar to the Guide, we decided to create a rectangle morph and attached both the Guide and Avatar to the morph. We came across the problem when we realize that both the Guide and Avatar were on the same hierarchy level. We need something higher in order to make them seem attach. If we could correct our mistake, we would have made the Avatar a child of the Guide, which would have made attaching easier.
For this milestone, we read the requirements wrong and though that “Cause a 2D morph to move around the screen with it” meant to have the Guide and Avatar attached. After receiving our grade, we realize that they meant another window, like a workspace or browser. That error was fixed in milestone 6.
We designed the UI for the guide to be as simple and straightforward as possible (a confusing help guide isn't going to 'help' anybody). In the center is a list of tasks the user can receive help on. On the right is a box that displays the description of the currently selected task. The 'List All' button, as you might have guessed, lists all the tasks in the repository. The user can also use the 'Search' button to list only the tasks matching a set of keywords. All the user has to do to view a task is select it and hit the 'Start' button at the bottom of the guide. The guide then shrinks to only display one step at a time. It allows the user to walk through the steps by using the 'Next' and 'Back' buttons. The user may also view a demonstration for the current step by hitting the 'Show' button.
Figure 5: Guide
Figure 6: Searching for help topic
Figure 7: Guide stepping through help topic
Code for Milestone 4: M4.zip
Milestone 5: Create a Demonstration Engine
The assignment for this milestone is located here: http://coweb.cc.gatech.edu/cs2340/3163
This milestone involved our group choosing five tasks from a list of things the class said they had trouble figuring out in Squeak. We decided on tasks that we thought we would have liked to have known how to do when we first started using Squeak and the ones that we thought would be the most helpful for a new Squeak user to know how to do. Once we chose them, we had to make it possible for the five tasks to be demonstrated so the user could see how to do them and not just read about it.
In order to show how to do the tasks we created a demonstration engine that broke each task up into smaller steps. These steps were made so that they could be added together to show the user how a task could be completed. By breaking the tasks up into steps that each had a method of there own we thought that we would be able to reuse code for other tasks that shared similar steps. We found this to be useful later in the semester when we were given five new tasks to implement. In order to demonstrate the tasks a script of the appropriate method calls was made in a workspace so the demonstration could be easily stepped through.
This project allowed us to learn more about how Squeak works. In order to open windows and write text to a workspace without using the mouse or keyboard seemed daunting at first. Once we started to look at the documentation of the classes we needed and learned to use tools such as "examine", it became clear that the only way to find out how something worked was to look at all the available information. Another thing we learned from this project was how important trial and error really is. Most of the time working on projects is not spent adding methods to classes, it is spent testing out new ideas in a workspace, over and over again. Just because a project may seem like it will be simple, doesn't mean you shouldn't start early! You never know how long it may take you to figure out the most simple problem. We had a couple of problems with this and ended up working late into the evening to finish on time. Just remember that this is Squeak and there is not as much documentation as there is for Java or C.
Code for Milestone 5: M5.zip
Milestone 6: Add Demonstrations to Your Guide
The assignment for this milestone is located here: http://coweb.cc.gatech.edu/cs2340/3165
This milestone involved adding the demonstrations that we made in Milestone 5 to our Guide. To do this we took the script that we had made and put each step of the script in a new variable in the TaskInstructions class. Doing this gave us two collections, one for describing the steps in the task and another which held the code to execute the step. This design decision was very simple and allowed us to make changes easily. It also made implementing the tasks in the guide very simple.
In this milestone we also had to be able to save and load our task instructions in XML format. In order to do this we had to learn about what tools Squeak has in order to parse text. We chose to use Squeak's XMLDomParser class to implement our XML functions. This was chosen because of its usability for users that don't know that much about XML formatting and parsing in general. We also had to decide what XML format we wanted our tasks to have. Below is a picture of what our XML files looked like when completed.
Figure 8: Sample XML
We changed our HelpRepository so that it would load and save XML files when save/load was clicked on. In retrospect, we probably should have made two more buttons for the xml features and left the old ones in so that the user could choose what format to use. After adding the XML files to the HelpRepository our guide was now able to "show" users how to execute the steps that made up the five tasks. This si done by reading the XML files and executing the methods that they say to call. The image below is what it looked like when the user clicks show for two of the steps in making a new class.
Figure 9: First "show me" image
Figure 10: Second "show me" image
Code for Milestone 6: M6.zip
Milestone 7: Expand Your Guide's Functionality
The assignment for this milestone is located here: http://coweb.cc.gatech.edu/cs2340/3167
For this milestone we had the five tasks that the professor assigned to the class that needed to be added to our guide. Because of the way we implemented milestone 5 this was not very difficult to do. We were able to reuse a lot of our methods from the previous five tasks on the new tasks because of how we broke the tasks down into small pieces. If we had not done this we would have had to rewrite a lot of the same code over and over again. We then had to add the five new tasks to the XML methods as well so they could be saved and loaded into the HelpRepositiory with the others. This project helped us to see why it is important to work on the code early so that you can find out how to implement it in the best way. If we had started late we would have been stuck wasting time redoing earlier milestones so this one would work correctly. In the end coding correctly the first time will save you a lot of hard work and wasted time.
This milestone also required use to extend our Guide’s search mechanism. Early on, we realize that we need to account for questions in the search mechanism since this was a help system. In milestone 4, we handled search where questions were involved. For example, “How do I create a class in Squeak?” returned the “Create a Class” help topic. After the TA informed us that we needed to strip out punctuations so our guide would return a topic for “What is a class?” we quickly changed our code.
Updating the guide to check for incompetent users was rather simple because of the way we designed our demonstration engine. We just created a method that took in a symbol representing the current "demo step" to be performed. The method would check if this step was dependent on another step that may or may not have already been performed. If the previous step had not performed, the method would make a recursive call with this previous step as its argument, and then demonstrate the step. The ease with which we met this requirement reinforces the idea that designing your system with the whole picture in mind, rather than just meeting each milestones requirements, usually pays off in the end.
Code for Milestone 7: M7.zip
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Justin Clark last edited on 2 August 2006 at 5:31 pm by c-69-180-23-104.hsd1.ga.comcast.net