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

It's Drinking Time!!!111oen Case

Team Members:
Brad Beglin
John Crosland
Alex Turyev

General Tips and Tricks
• Always pick group members very carefully. Coding with friends is usually a bad idea. Having members that are all genius programmers is not essential, but having dedicated members is what is really important.
• For diagrams, the program Dia is really good for what you need to do in this class. While many groups will use industry tools, those are all probably overkill for the simple uml diagrams in this class. Dia is open-source and availabe for both Windows and Linux.
• Using the RBCode Highlighting package in VisualWorks is also very helpful (there is a tutorial in the Spring 2007 cases). The code highlighting makes VisualWorks function more like a traditional IDE, so your coding is faster and not as error prone, as you can see mistakes as you type them.
• Its is generally a good idea to physically meet your groupmates to work on coding projects. However, because of the merge tool, there is some benefit to everyone working seperately and at different times. Our group rarely met to code, and as a result, we had very few merges and when we did have to merge, the merges were so trivial that VisualWorks was able to handle them automatically and within seconds. However, the downside is that pulling all the code together and testing the code is much more difficult. Also, splitting up the work evenly can be impossible under this method, depending on the structure of your application. In our case, our program was very modular, so it was easy to divided the work and it all worked out pretty evenly. The last negative of coding seperately is that it is difficult for everyone to remain familiar with each others code, which makes debugging more difficult.
• If you decided to work seperately on different parts of the code, good documentation of what each module, and key methods, are getting and sending is essential, since there is no strong typing in Smalltalk. We overlooked this fact, and had several bugs that were caused for no other reason than the fact that we were passing the data in the wrong form to the receiver.
• "True"/"False" is an user defined object in Smalltalk, "true"/"false" is an object with the behavior of the boolean values of true and false. This is important because if you say that a := True and then check to see if a = true, you will receive "false" (also, if you are using a conditional loop, then the "ifTrue" block will never be called), because you created a blank object named "True" and never initialized it. This was the cause of our two most major bugs (and a lot of laughs).
• If your connection to the repository seems to lock up in the middle of trying to publish code, disconnecting from the store will kill the lockup, and then you can reconnect to the store and publish your code.
• If your computer locks up in an infinite loop while running some code, hitting Control + y will kill the loop.

M4 - Domain Design and CRC

• Make a team page and indicate your team members and which option you are pursuing.
• A brainstormed list of Domain classes.
• A list of candidate classes after filtering.
• A set of CRC cards for the candidate classes. Cards should be filled out on both sides (role stereotypes and responsibilties/purpose).
• A set of scenarios that cover typical uses of system and exercise the CRC Cards.
• Meet with assigned TA after submission to discuss your design.

What we did right:
• We designed the application to include most of the extra credit, which made it very easy to implement the extra credit features.
• Our CRC cards were very good.

What we did wrong:
• We did not adapt the classes that we had drawn up into a really workable architecture, instead we just came up with the classes that we thought we will need.
• We created a bad model for User classes, which looked very pretty and very Object Oriented, however we had to completely redo User and create a User Rights models to better fit the needed functionality.

What we should have done differently:
• We should have designed more classes in the beginning of the design phase. When we implemented our design we ended up with 3-4 times the number of the original classes.
• We should have spent more time on naming our classes.
• We didn’t spend enough time on role-playing different scenarios.

M5 - Application Design and UML

• Create your Software Architecture and Trust Boundaries
• Identify your Application and Utility Objects
• Add necessary CRC Cards and any new scenarios needed (for newly discovered domain classes if any)
• Submit a UML Class diagram of your refined design (shows all domain and application/utility objects)
• Submit 2 UML Sequence diagrams that shows your full design handling one or more scenarios
• Submit screen mockups that show your preliminary user interface. These screens can either be hand-drawn, or prototyped with the VW Painter and then captured.

What we did right:
• The sequence diagrams were made correctly and actually helped us make a better application.
• The first user interface drawing was great, although we did not exactly implement it the way it was drawn because of technical issues.

What we did wrong:
• The UML diagram did not have enough methods and attributes in the class objects.
• Our class diagram was very helpful, but some of the entries on the class diagram were not fleshed out as much as it could have been.

What we should have done differently:
• We should have started working on M6 earlier.

M6 - Backend Code

• Implementing Basic Domain
• SUnit testing

What we did right:
• We extensively used SUnit throughout our M6 code, which let us experience test driven development, because every time we modified our classes we would check the TestRunner and fix the problems.
• Since we used Dia, all the diagrams were really easy.

What we did wrong:
• We did not test File In and File Out enough. Because it was working fine when testing, however when he plugged it into the GUI later in the project, we found major bugs in our code.
• We used some of the code of M2 to work it into the M6 code. However later it created a lot of problems.

What we should have done differently:
• We should have started working on M7 ahead of time. We had no idea that it is going to be hard.
• We should have looked ahead of what is required in M7, because some of our back end code had to be reworked when we plugged it into GUI.

M7 - UI Code

• Create the GUI for the program

What we did right:
• Reusing VisualWork's chart widgets (located in the BGOK parcel and explained in the UI Developer Guide) was a great idea.
• Our application gave users the feedback to their actions.
• We took into account the non static typing, when creating the GUI.
• Every person on our team was responsible for certain parts of the code. Which is why we almost did not have merges, and when they happened – they were very easy to process.

What we did wrong:
• We had to redesign our GUI several times, which wasted our time.
• We did not get familiar with what Smalltalk has to offer on the GUI side, and we did not learn how hard it would be to program some of our UI ideas.

What we should have done differently:
• We shouldn’t have worked on the GUI before we learned how to access embedded widgets. That of course applies to those who uses tabs in their GUI.
• We should have looked back into the back end code to make sure our naming was solid. For example, most of our lists were named “list”.

M8 - UI Evaluation

• Clearly identify the team whose prototype you evaluated and provide a one-page description of your evaluation plan and the rationale behind the plan, i.e., why you chose to conduct that evaluation on this prototype.
• Results of execution of usability plan, providing clearly documented printed evidence that you conducted the evaluation plan correctly.
• 3-page usability report highlighting the three top concerns arising from the usability evaluation. The report should identify clearly what each usability concern is and the evidence you have to support this problem being a real problem that should be corrected by the design team.
• 3-page rebuttal of the usability report submitted to your project team. Be careful not to get defensive in this report (resist refuting that the findings of the evaluation team are incorrect). Make a clear argument for how you would address each usability concern. Assess whether the object-oriented design you developed for your prototype made it any easier to address these usability concerns.

What we did right:
• Cognitive evaluation was a great choice for this project.
• Our rebuttal was very well written.

What we did wrong:
• We did not make our advices to the team we reviewed longer.

What we should have done differently:
• We should have created more subtasks for the evaluation to ensure going over every little move required to complete the task.

M9 – The Twist

• Adding a web front end to our application

What we did right:
• We fixed functionality problems from M6 and M7.
• We focused on functionality and user notification for the web UI.
• We finished our GUI.
• We did a lot of the extra credit

What we did wrong
• We did not address exception handling
• We merged incorrectly at the last minute and had to demo on two different laptops.
• We didn't have test cases for M7.

What we should have done differently:
• We should have made a plug-in for the web development to put our GUI in.
• We should have not tried to merge at the end, but instead we could have done then earlier.
• We should have made more test cases
• We should have give ourselves more time to pull all the pieces together, because it always takes a little longer than you plan.

This is our architecture design

This is our class diagram

Trust boundries

One of our sequence diagrams

The code for M9

Our M8 evaluation

The M8 rebuttal

Link to this Page