Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
For our project, we had to write a Quicken clone in Squeak - Squeaken. Our project was divided in to seven phases. The first two were individual, and concentrated on developing a hierarchy of 'account' classes for use as the back end of the larger group project. The third milestone was largely a design milestone where we sat down and had to figure out the overall plan of our project. The fourth phase was developing the GUI and the basic system. Milestone five involved saving/loading files and watch accounts, a special type of account used to alert users to certain conditions. The sixth milestone involved adding a querying mechanism to users via a subset of SQL. The seventh and final portion of our project was to web enable some of the functionality.
Where to Start Designing
The most helpful hint we can give you is to look ahead at all of your future milestones. If you don't consider what your system will have to do in the future, it can be very easy to corner yourself in a situation where you might have to overhaul a large portion of your code. If the later milestones require you to use libraries or built in functionality that you aren't yet familiar with, thatís ok. For example, you don't know how the XML parser works in Squeak, but you do know that its there. You may approximate this in UML with generic classes that encompass the entire system. Don't worry about individual message sends, instead consider how it will connect to the known part of your system. You do need to know how parsing works, you need to know about what you need to feed into this generic class and what ouput or functionality you expect from it.
For example, YAXO is an XML parser for squeak. When we designed our system we knew that we would have an XML file with data. We also knew that we had to serialize between objects in the system and this file. During design we therefore had a class (FileLoaderSaver) that would serialize the object to the file and vice-versa. We didn't bother with the internal working of this class or YAXO. We simply showed the connections between the rest of the system and this class.
For additional design information and help, go to our third milestone: M3 - The Design.
Where to Start Coding
One of the largest problems with Squeak is that it has a lot of built in functionality, but there is virtually NO documentation anywhere about what works, what doesn't, and how to use the stuff that does. The best way to get used to this environment is, of course, to jump right in and start digging around in the old squeak code. Another really helpful tool is the 'explorer'. Unlike the windows program, the Squeak explorer lets you view attributes of any object in a tree-like fashion. This is exremely helpful for GUI programming. Often, you may have seen a GUI component that you want to use in another Squeak GUI programs, but its difficult to figure out anything about it.
The Object Explorer
How to Work with Your Group
One of the biggest challenges with a software design class is working efficiently with your group. Whether all your members are already great friends and fellow coders or whether you just met each other for the first time when you arranged your first meeting, the following tips should help you work together efficiently for a successful project.
– Code Sharing
Sharing code among multiple group members is always a challenge, but it's of utmost importance that right from the start you establish some way to keep the most up-to-date, working copy of your project available to all group members, regardless of who's editing what. At work or in other classes, you may have used a tool called CVS. If you can get this set up for your group, we recommend you do so. You may also want to take a look at DVS, Squeak's interface for working with CVS. We must admit that we were never able to configure DVS in a way that was useful to all our group members with diverse access needs, but we still recommend looking into it as an option. If you can't get DVS to work or are worried that you're spending too much time on it, don't worry about it - it isn't crucial that you get it working, provided that you have some other alternative. However, we do recommend that you start this process early, long before the first coding milestone is due, so that the process is in place by the time you have to start seriously coding against a deadline.
– Use changesets
When we first started coding, we thought it would be sufficient to simply have each group member submit .st files containing all the classes he or she had been working on to our repository. Then, according to our plan, each member would update his or her image by filing in the other members' .st files. This is a very bad approach for several reasons. First, it becomes difficult to keep track of the various files you need to file in as your project grows. Additionally, the order in which you file in the files sometimes matters, and this can also be difficult to remember. Filing in lots of different files slows down the update process, which can not only be a pain but sometimes becomes a crucial matter when a deadline is fast approaching. Perhaps the biggest problem with this approach was that it is very difficult to keep track of who's edited what, so filing in several .st files may overwrite existing classes or categories in your image without warning. Sometimes the changes this causes are very subtle, and it can take quite a bit of extra time to find the bugs this problem introduces - bugs you thought you'd fixed long ago. The better alternative to this problem is to always use changesets. Advantages to using changesets are that you only have 1 file to keep track of, so you can file in everything at once. Additionally, the easier it is to configure Squeak to run your program, the more likely it is that the TAs will be able to do it when they grade, so it is very advantageous to turn in a changeset - if you've been using one all along, you're all set when turnin time comes around. To work with changesets, keep a clean, updated image of Squeak on your machine. A clean, updated image is a fresh downloaded image with no modifications except the official Squeak updates (to give you the most up-to-date version). You might also set up your image by deleting extra windows that come with Squeak, and arranging your menus as you like them. Just make sure you don't add anything new to this image. Using this clean image, all you have to do when you want to work on your project is to file in your changeset; when you're done coding, be sure to file out the new changeset. For more detail/ explanation of working with and creating changesets; also see the link under "Other Useful Things to Know About Squeak" below.
– Meet often - twice a week!
This is pretty self explanatory. It's very important to have frequent meetings so that all the group members feel informed about how each stage of the project is progressing. We found that meeting twice a week for about an hour at a time was sufficient. For the early stages that involved a lot of design we usually met for longer periods, since we felt it was best to have long brainstorming and discussion sessions with all members present. We recommend this approach in the beginning (our meetings usually lasted 2-3 hours in the design phase) so that all group members understand and approve of the design - if everyone has a hand in creating it, there should be no problems with misunderstandings later.
– Play around with Squeak
If you don't know how to do something in Squeak, allow for extra time to figure this out. For instance, you may know all about how to use XML in Java, so you should be able to figure out how to do it in Squeak pretty easily. Don't let this lull you into leaving little time to play around with whatever Squeak package you are using. This is especially true for the GUI. The GUI components in Squeak make extensive use of pre-existing, undocumented classes. Remember how long it took you to get used to Java's GUI system? Double or triple it for Squeak due to lack of a documented API.
– Take the schedule seriously
Your first group milestone will probably require that you come up with a schedule for the entire project. This seems like a real pain in the beginning, particularly when you don't know exactly how everything is going to work in the transition between milestones. However, as tempting as it is to just make something up, we recommend really putting some thought into this. Come up with a consistent weekly schedule for the group, and decide what stage of each milestone will be accomplished during each meeting. For example, the documentation for the project will need to be updated for each milestone - plan to address this at a meeting early on in each milestone so that the design for that portion is well-established from the start.
– Plan around vacations
Breaks from school can wreak havoc on your project, no matter how much you think you're going to be diligent and code over the break. This is especially an issue if you're taking the class in the spring, when you'll have a whole week away from your group. Even if you think you'll work over break, get the bulk of the work done before the break. Many groups are tempted to do individual coding over the break when they have "plenty of time" and then integrate their code when everyone gets back. THIS DOES NOT WORK. Never rely on group members to code over break, no matter how often they profess love for Squeak. Make sure your group has the bulk of the work done before break and that you've seen results from each member before you go your separate ways.
– Record Responbilities
As you decide on the components that need to be implemented for your system, decide on which group member would be best for what task. Then record the responsibilities of each member by the specific classes, tasks and/or the documentation that the member will be responsible for. Keep a log of this and add the tasks and classes as they become more detailed or specific as you progress through the project.
What follows is a series of links to the various tasks we were asked to carry out in the Squeaken project. Each of these links contains a brief description of our group's approach, an analysis of some of the tools we used, including brief tutorials where applicable. Note - these pages were not meant as much for a description of our specific project as they are to provide solutions to generic types of challenges you might encounter in Squeak programming. If you are looking for a detailed description of our implementation for our specific project, please contact one of the group members.
M3 - The Design. Click to see info on how to get started with CRC cards, scenarios, the UML and class descriptions when you're not sure what to do.
M4 - The GUI Maybe not everything you ever wanted to know about Squeak Morphic programming, but here you'll find a lot of helpful hints on where to get started with some examples you can follow along yourself.
M5 - Persistence. Click to learn how to implement the YAXO package to facilitate file loading and saving.
M6 - Parsing and Web Capture. You will probably cover the stuff we did here in class. There are some links to tutorials on smaCC and TGen.
M7 - Web Enabling. Click to learn how to use HTTPView and Comanche to web enable your application
We presented our project approach to the class. You can use this as an example of a presentation or to learn about our system in a quick 4-slide Powerpoint. The final presentation of our system:
Other Useful Things to Know About Squeak
Using SUnit for testing
How to create a changeset
How to retrieve code when Squeak crashes
Hopefully this has helped you! Good luck to all you future Squeakers!!!
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Kanishk Kapur last edited on 31 August 2004 at 6:45 pm by ip170-da-adit-va1.atl1.exsbs.net
- trying to edit 4 blind mice last edited on 29 April 2003 at 2:58 am by r74h66.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