View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Mighty Polymorphin' Smalltalk Rangers


General Suggestions

Here are some general suggestions and tips that we would recommend for developing a prototype for CS2340.


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.



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.

Uploaded Image: part1.GIF

2) create a architecture that you can visualize your SAAM analysis:

Uploaded Image: part2.GIF

Here's the SAAM Architecture:

Uploaded Image: ArchitectureWithTrustBoundary.jpg

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)

Uploaded Image: part3.GIF

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).

Uploaded Image: part4.GIF




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