Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Mighty Polymorphin' Smalltalk Rangers
WORK IN PROGRESS
General Suggestions
Here are some general suggestions and tips that we would recommend for developing a prototype for CS2340.
- Keep in constant touch with your teammates. Let them know what your schedule is like. Try to plan earlier deadlines and meet often as a group to insure that everyone is on track. If you cannot meet regularly, at least communicate via some type of instant messenger and email. Good communication is the key to success.
- When developing, and if using STORE, make sure to store your code often so other team members can track your progress and give feedback. Also, do not commit broken code unless absolutely necessary. Always remember to save your VisualWorks image, there's nothing worse than losing hours worth of hard work.
- Clearly divide the work amongst your group members to avoid wasting time working on duplicate features.
- Familiarize yourself with the Cincom VisualWorks Dev guides. They are a very useful resource.
- Utilize the class newsgroups and do not hesitate to contact the professor or your TAs for help.
- Check out the public newsgroups, specifically comp.lang.smalltalk. I've asked a few questions here, and I think it's a tremendous resource with very many experienced Smalltalk programmers. Here's a google groups link http://groups.google.com/group/comp.lang.smalltalk.
M1
Even though it may not seem like it at first, M1 is a very big and important part of the 2340 final project.
Here is an assortment of tips to do well in this stage.
- Choose your partners carefully. It is not always the best route to partner up with your friends. Form or join a group to consist of members who are compatible and work well together. If you do not put effort into this, the project could possibly turn into your worst nightmare.
- In this initial design phase, you need to identify the domain classes. We would recommend that your group met in person and brainstormed in order to come up with a nice refined list of domain classes. It is an important base step to successfully creating CRC cards and scenarios.
- Next, you will have to create CRC cards and we'd also recommend doing this together, maybe on the same occasion as the initial domain class brainstorming session. Once you've created the CRC cards, try to define responsibilities for each of them. Be sure to take input from every teammember, because others might have different better perspectives. Define the role stereotypes and collaborators.
- Each member in our group came up with a few different scenarios, and then we met to combine our work. This turned out to work well, and we came up with a great list.
- After synchronizing the scenarios, your group should role play them. We suggest meeting and carefully going through each scenario. If there are any inconsistencies, you will find them during role play.
M2
SAAM ANALYSIS
To better picture your designa and model and how all the classes interact in your programm, a SAAM analysis is a very handy exercise.
1) First seee the potential uses of your program through possible scenarios (see below). Check to see if the scenario directly affect your program or indirectly. Then figure out how the system might be changed that would necessitate new functionalities.
2) create a architecture that you can visualize your SAAM analysis:
Here's the SAAM Architecture:
the architecture with trust boundaries shows just how the model (the trusted part where you should be the least concerned about runtime problems) interacts with the untrusted regions(such as networking where the most runtime problems are first likely to occur). this gives a whole picture of your program and is good for visualizing everything together.
3) if from part 1, if you find any indirect scenarios, see what you will have to change to your model to make sure your model incorporates the new scnearios (see below)
4) finally, summmarize the impacts of the the indirect scenarios. So when you are trying to understand the effects of the scenarios, you can easily go to the summary for that quick info (see below).
M3
- SUnit testing is one of the major parts of this milestone. We would suggest writing a SUnit test after every domain object is implemented. Make sure that you fully test a domain object before moving on to another. This will really help you cut down on the errors.
- As far as coding and style goes, make sure you get into the habit of coding properly from the start. It will save you a lot of time and effort, and will also decrease debugging time. Code readability is also very important if you want anyone else to give you feedback or help.
M4
- The biggest piece of advice we have for M4 is to start early. The remaining required features do not seem to be very time consuming, but designing proper drawing algorithms is not the most trivial task in creating the prototype.
- A feature that we found very useful was the ability to assign graphic contexts to buttons and labels. This is also how we implemented drag and drop, with buttons being drop sources for graphical CRC cards.
M5
The first thing to remember is that never directly criticize negatively if the other group evaluating your project finds fault in your project.
What you should do is try to understand why they find something inconvenient while you don't. Remember you as the programmer is not the user
The better way to addreess your concern is to state:
1) what was the original purpose of the certain way you created the UI.
2) acknowledge that improvement can be done.
3) suggest other ways that the UI can be made better.
When doing the other team's evaluation....
if you are not sure what evaluation to use, you can try the cognitive walkthrough. Since almost always the GUI should try to be as simplitic and intuitive so that the average user does not get confused. Through the cognitive walkthrough, you can let the authors know that the average user would
find cetrain aspects of the gui confusing.
Use the heuristic approach if you are very sure about the specifications of the program. Otherwise you will evaluate the project with the wrong intention of the program in mind. for example, there exists a cetain command button "Send" in the gui, if you are not sure of the purpose of the program, you might think that the button is sending date over the network when in reality it might be sending the date to another part of the same program without networking.
Check to make sure there is a help menu, almost always will there be confusion when the average user tries to use the program. Shows a serious attempt
from the programmers to address possible concerns.
check to make sure the buttton actually do what they intend to. try to click the button and observe what it does.
Other Miscellaneous Tips
- Try to have fun. There is a lot of cool things you can do with Smalltalk and you should take advantage of being able to use this language in class.
- Try to implement the extra credit. Not only can you earn great amounts of extra credit points, but implementing features like drag and drop, data persistence using a database, and additional drawing algorithms is very interesting.
Soumo Gorai
Sam Hartsfield
Alexander Stocko
Links to this Page