Hose and Tricks Cases

General Advice

• Meet a few hours daily. This will help prevent stress and all nighters the day before turn-in.
• Work together as much as possible. It helps to have your teammates sitting with you when working on the project because two heads are better than one. Sometimes if you can't figure out a problem with the program or code, one of your teammates know the answer.
• Find some way to communicate with your group. We created a group on Facebook so that we could message each other and to keep up with what times people were available to meet.
• Use the Store on VisualWorks to share code. The Store is free and easy to use. It allows the group to merge code and go back to previous versions if something major happens to what you are currently working on. Make sure to merge as often as possible to prevent complications.
• Even if you are not working on a part of the project be there for your teammates for support and help.

M1: Design 1

• Form a 3 to 4 person team. Make sure that the people you form a team with are people that you can depend on. If you’re a go-getter and want to get everything done in a day, don’t team up with someone who is even remotely more laid back then you. If you’re not in that much of a hurry, make sure your groupmates aren’t either. You don’t want to be a nag or dead weight, anyways.

• Identify Domain Classes. When identifying your domain classes be sure to list as many possible classes as you can. List absolutely everything that comes to your mind. Seriously. You’ll bang your head against a wall for not adding something later. Well, you’ll be banging your head anyways, but you’ll save yourself a bump or two. Save the walls, man.

• Create CRC Cards and Scenarios for the Candidate Classes. Three words here: Divide and Conquer. Take on a few each and do it in front of each other, so you can discuss. Then do the scenarios together, and make each scenario as detailed as possible. “User clicks on…” usually doesn’t cut it. Go for out of the ordinary uses that will likely need more classes to accomplish. That way you can weed out the useless classes.

• Assign Role Stereotypes and Responsibilities to Classes. Again, do this together. Better to argue at first and save time. Also, know what these are from the lecture. If you skipped or fell asleep, go back and learn it (or at least make sure somebody in the group does).

• Roleplay Scenarios to Clarify Responsibilities and Collaborations. Yet another weeding process. Take this one seriously. Go through each card in each step and think long and hard about its usefulness. It works, folks. You’ll wind up saying to yourself “What was I thinking?” a few times.

• Meet with your Assigned TA. It’s useful to actually know who your TA is. That way you can hunt them down for help, even if they’re not on their office hours. Also, it’s an opportunity to get help and be nice to the TA. Yes, we mean suck up, but a little actually helps quite a lot without damaging your pride much. And the improvement to your grade can often be well worth it.

M2: Design 2

• Create your Software Architecture and Trust Boundaries. Like we said before, know what these are ahead of time. Either pay attention in lecture (I heard you groan) or go back to the lecture slides and figure it out. Every point helps!

• Identify your Application and Utility Objects. Utility objects are classes that structure other objects, such as the classes we used to structure out GUI panels. Application objects are classes that are important to making the backend part of the project work. Knowing this in advance will save you money (you won’t buy as many Aspirin).

• Add Necessary CRC Cards and any New Scenarios Needed. During the second part of the design phase as you look at your current classes, you will realize that some classes are not actually needed and other classes are needed to make your code a whole lot cleaner. If you think you don’t need any more, you’re either very good, or in deep trouble. Chances are you’re not that good, so go back and make sure you don’t need anything else.

• Submit a UML Class Diagram of your Refined Design. Take the time and use a free UML tool like Poseidon, or something similar. It’ll make your life easier to be able to change the diagram easily as well as have it easily accessible for reference later on. You won’t remember it (kudos to your photographic memory if you do), and you don’t want to be cursing your TA for taking too long to grade it and give it back to you.

• Submit 2 UML Sequence Diagrams that Show your Design Handling One or More Scenarios. Same as above. Use a program. Don’t just draw it out. You may need it later, and TA’s don’t like students demanding grades (no matter how right they are). Plus, Sequence diagrams are important because they are a visual layout of how your classes will interact to perform specific tasks and goals. These help in the coding portion of the project because it shows you which classes interact with each other and in which ways to perform methods.

• Submit Screen Mockups that Show your Preliminary User Interface. Honestly, take your best guess. Chances are you’ll end up changing it when you get to know Smalltalk better (you may regret that, but it’s a necessary evil). In any case, draw out what makes sense to you and try to stick to it, but don’t sweat it if you don’t.

M3: Implementation 1

• Implement Domain Objects. For this requirement we worked as a team to implement all of our domain objects. Each of our group members took a few classes, added methods, attributes, and initialized the various variables. By doing this we were able to have all of our classes implemented in a matter of hours. The design process makes this the easiest part, surprisingly, so don't freak out about this part. The craziness is below.

• Implement Basic UI Screens to Input Data. This, for us, was truly the hard part, if only because we had to decipher the GUI developer guide to try to understand the GUI (the documentation is very example specific, but for some help, check out Connecting GUI's and code: Starter guide on how to get and send information to your GUI). Two of our group members focused on developing our UI screens. WATCH OUT! The merge tool only takes one set of changes, so if two people make different changes to the GUI, the merge tool will only want to take one. The two group members worked on this requirement together using only one computer. Don't be afraid to ask questions about how to add things to the screen and how to make them communicate with the backend of the program.

• Create SUnit Tests to Unit Test your Core Domain Objects. For this requirement, only one of the group members focused on writing the tests. We chose to only have one person create SUnit tests because we felt the tests would be more unified. It would also give the other teammates the chance to focus on the UI screen and debugging the code.

M4: Implementation 2

• When a scenario is selected for roleplay, the cards display graphically on the screen, and arrows move from responsibility to responsibility showing the flow through your classes. We had one group member work on the code for this requirement; however, we were all there for support and help. This part of the project was a little more difficult, and required a more intimate knowledge of exactly how the GUI draws. We used the help of another group along with Bob's code to figure out how to draw to the screen. Once we learned how to draw to the screen, it was easy to add the information to the cards because they were saved to lists and just needed to be accessed and sent to the screen.

• When a UML diagram is requested, display a simple UML diagram showing the classes, and their relationships (limited to inheritance or basic association). For this requirement we had only one group member working on the code. The two group members working on the UML diagram and the roleplay were able to work together and help each other out. The other two group members were there to help figure out if things looked correctly and were working correctly.

M5: UI Evaluation

• For this milestone it is important to know and understand how to perform atleast one UI Evaluation. This milestone is very helpful in letting your group know how effective your UI is and how user friendly it is.

• Plan your evaluation. Choose the evaluation that you feel is most appropriate and will be most effective for the evaluation you are doing. Think of what needs to be done during the evaluation and how you will record your data. Also, figure out if you want one of your group members to perform the demo or if you want the other team to demo it to you while you take notes.

• Perform the evaluation. My group chose to do a think aloud evaluation of the other team's program. One of our group members demoed the program and another group member took notes. As they were performing specific tasks, they were talking out loud about what they were doing, what they thought they were doing, what the program was actually doing, and what they thought about the ways the program worked and its effectiveness.

• Usability Report. For this step make sure that you use constructive criticism. It is important to be honest in the problems you find so that your evaluation can be as helpful as possible for the other team. Let the team know what your concerns are and then give suggestions that you think would be helpful in correcting those concerns.

• Rebuttal. Think about how you would correct the concerns felt by the group who evaluated your program. Take these concerns and use them to improve your program and make it better. Whatever you do, don't take this evaluation personal. The other group is just trying to help give you an outside perspective on how user friendly your program is.

Link to this Page

• Case last edited on 1 May 2008 at 11:53 pm by r69h136.res.gatech.edu