Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
"LOOB: You'll need it"
In an effort to help out future students, here are a variety of recommendations for success in the CS2340 final project.
1. Form a 3-4 person team
This is the first step toward completing your project and it's a rather important one! Your team can and will be the difference between success and failure. What does this mean for you, the student?
- If you are able to choose your own team, choose people you trust. Surely, one can argue that it is good to meet other programmers by doing assignments with them, but for a final project it may be prudent to work with people you know you can already count on. You will all be relying on each other.
- When choosing a team, reliability aside, try to get partners with a variety of diverse skills. Important roles to fill: designer, manager, GUI expert, backend expert, and generally people who have a good knowledge of programming. Make sure that you can divide up responsibility in a way that utilizes each person in the group to their full potential.
- Your team should meet face to face as often as possible. We would have everyone meet in the lab at least 3-4 times a week. Even if it is only for a few hours, it's still worth it. It is enormously beneficial to have your entire team available while working on the project and you can avoid many conflicts of design or protocol by simply discussing things as they are implemented. Meet often!
- You may want to, at this point, set up version control software. It may seem early, but it's better to have it ready when you need it. STORE is actually a rather effective means of version control, especially compared to CVS, so make sure to use it to its full potential. Make sure to publish often, and if merging needs to be done, do it with the other person present to resolve conflicts without messing up each other's code. STORE has a very good Merge Tool, so you can largely avoid doing silly things like manually merging files.
- Start familiarizing yourself with your programming environment. Even though there isn't really any coding to be done until M3, this is time you have to start learning Smalltalk and VisualWorks, time that you'll need in the future. Having a good knowledge of the environment will save you an enormous amount of time in the long run. Cincom provides a good deal of documentation on both application development and GUI design included right along with VisualWorks, so make sure to look through it.
- If your team needs help, ask for it. That's why the TAs and Professor are there. Post questions to the newsgroup, so if they are answered, other people won't have to ask them in the future.
2. Identify Domain Classes
This is where important aspects of object oriented programming start becoming apparent. Domain classes are literally the "objects" in your domain. If you were a carpenter, they'd include things like "hammer," "nail," etc. Get together with your group and brainstorm about your domain. Try to identify nouns as these will often be the domain objects you are looking for.
3. Create CRC Cards and Scenarios for the Candidate Classes
Once again, make sure you are with your entire group and you have a nice stack of blank CRC cards and some paper. Eliminate the classes from your list that no longer make sense, and create cards for the rest of the classes left. Once you have your cards ready, it's time to start creating scenarios. Try to think of the steps involved in the actual usage of your program and create practical scenarios. Once you have created them, roleplay them to see if they make sense.
4. Assign Role Stereotypes and Responsibilities to your Cards
After roleplaying, you should have a good idea of what each class should be doing to achieve these usage scenarios. Add appropriate responsibilities to the relevant cards, and any more you happen to think of while going over the cards. Add the classes that collaborate with each responsibility. Add stereotypes as you see fit.
5. Roleplay Scenarios
Do this a second time! This will let you know if you've correctly assigned responsibilities and collaborators.
6. Meet with your TA after grading to discuss your design and possible improvements
This is rather self explanatory and will differ for every group. Remember, your TA is a resource to be utilized.
M1 is rather easy, but it's also very important. If you make a good design from the get-go, you'll be able to implement your prototype much easier and you'll be able to modify it without having to revamp your entire system. M1 lists suggestions for extra credit: plan for the inclusion of the ones you will attempt NOW.
- Wait until the last minute
- Create inadequate scenarios
In our case:
- We were able to complete the assignment on time and we were able to meet often
- If we had to make changes, perhaps our initial design was too ambitious: be realistic
- We were able to plan on doing lots of extra credit right off the bat and it helped us down the line
- We started learning Smalltalk early on, and it really paid off in the end
1. Add any extra necessary CRC cards or scenarios
If you've figured out something else that should have been included in your design, add it now. The next milestone you will have to start implementing your design.
2. Create UML Class and Sequence Diagrams
It's good to have your group together to make these. Make sure to not make your sequence diagrams too complex: they should represent a specific occurrence and not a slew of actions. When creating your class diagram, remember: not everything is an aggregation, and associations are NOT communication channels.
3. Architecture / Trust Boundaries / Class Identification
It can be helpful to discuss this with your group. Make sure to reference notes and the class slides to make sure you are doing these correctly.
4. UI Screen Prototypes
Once again, try to have your whole group present for this one. Everyone should chime in and collaborate as the UI is fleshed out. Just remember: you are not your user.
As recommended previously, try to complete this milestone with your entire group present. When engaging in software design, the discourse between teammates is one of the most useful things you end up with. It is hard to create a unified design and architecture if people are working separately.
- Wait until the last minute
- Create arcane designs that look awful in UML: if your design is full of loops and almost every class is associated with every other class, you've made a terrible mistake
- Create overly complex sequence diagrams
- Complete the assignment without meeting
In our case:
- We created our UML by hand, but perhaps it would be a better idea to use a program like Poseidon or Visio
- Once again, our greatest resource for completion of this milestone was meeting often
- We were able to learn more Smalltalk as we went along before the programming started
1. Domain Object Implementation
Ah, on to the coding. Smalltalk is different from other languages you may be used to, so if you haven't been reading up on it in the previous milestones, START IMMEDIATELY. While the domain objects themselves typically aren't the most complicated aspects of the program, they are important and must be implemented correctly.
2. Application Model and Views
VisualWorks and Smalltalk in general use the MVC paradigm for creating GUIs. What does this mean for you? First of all, you should know MVC like the back of your hand, or else you will have trouble creating an effective GUI. For this milestone, it doesn't have to fully implement the hooks into the domain objects, but you should create your basic layout. Luckily, VisualWorks provides a WYSWYG GUI editor that is rather simple to use, so you should have no trouble hammering out a basic layout.
3. Save / Load
This may seem like a daunting task at first, but Smalltalk has a surprisingly simple solution: if you have a unifying "Project" class, simply serialize it to a file. You can later load this same file and it will be like nothing ever changed. We think this is certainly the best way to go about loading and saving.
4. SUnit Tests for Domain Objects
SUnit is important: unit testing is heavily focused on in this course. You should be creating a test class for each of your domain classes, and you should test them THOROUGHLY, encompassing both success and failure scenarios.
5. Good Smalltalk Code and Style
You may have noticed: Smalltalk is not Java or C++. Generally, methods (or functions, as you prefer) should be relatively short. Make sure to comment your code well.
This may seem like a lot of work, but it should be relatively simple to implement your domain objects and basic application model if you've got a coherent design. Meet often, make sure you familiarize yourself with the STORE, and divide the work up evenly.
- Wait until the last minute
- Divide work unevenly
- Have everyone work on a separate piece and try to mash it all together on the day that it's due
- Ignore the importance of SUnit
In our case:
- We actually implemented almost everything required for the next milestone in this one. If you get done with this early, don't waste time: you can get a jump on the next milestone by continuing to work and buy yourself time later in the semester so you won't have to worry.
- We made sure that we had a submittable version ready the day before it was due and left the rest of the time to touch-ups and debugging/testing (just in case)
1. CRC Card Layout Display
We actually completed this for M3, but it's one of the most important parts of the project as a whole. We recommend creating a drag-and-drop interface right off the bat. It's much more intuitive than anything else, not that hard to implement, and gives you a nice helping of extra credit immediately.
2. Scenario Walkthrough
This can be done in a variety of ways. In our case, we had a pop-up window that launched when one selected a scenario and clicked "Roleplay." You may also want to create an embedded subcanvas or another view of some sort. This is worth a lot of points in this milestone, so make sure it is working properly and get it done pronto.
If you are using a drag and drop interface, this is almost the exact same thing as creating the CRC card layout. It is up to you how much freedom you give the user in the creation and modification of the UML class diagram. You may want to implement an algorithm to prevent overlapping and line-crossing if you are going to auto-generate the layout.
4. SUnit Tests / Smalltalk Style
Same as previous milestone.
This milestone is probably the most work you will be doing on this project and it will be especially tough if you are not familiar with the ins and outs of GUI design in VisualWorks.
- WAIT UNTIL THE LAST MINUTE
- Attempt to complete this part of the project without constantly meeting with your team
- Let feature creep get the best of you when you know the project is due soon
- Skip the opportunity to demo
In our case:
- Since we had completed most of the M4 requirements in M3, we were mostly just adding extra credit and testing. We made sure to be entirely done and have a submittable version well before it was due so that we could give it a thorough rundown.
- We made sure to demo this milestone with a TA: you need to make sure that, especially if you've done extra credit, you can point out exactly what makes your program neat and why you deserve points
This milestone is very different from the rest. You've already submitted your finished project. Now, you are going to do a UI evaluation of a group and also receive one yourself.
Creating the evaluation:
- Choose an appropriate method of evaluation
- Create a plan that you will follow when evaluating
- Execute the plan in an appropriate environment under the correct conditions
- Write the report
Later, once you receive your evaluation, you will have to write a rebuttal.
- Do not get defensive: this is not an attack on you or your group
- Do not try to contradict the findings, simply suggest ways to improve based on the evaluation
Make sure you carefully document everything that you do, otherwise the results of your evaluation are sort of meaningless. Be constructive and don't criticize in your report, simply explain what you as users had trouble understanding. In the rebuttal, be as cordial as you were in the evaluation.
- Wait until the last minute (last time I'll say this!)
- Be abrasive in your evaluation or rebuttal
In our case:
- We made the mistake of not editing our notes (perhaps leaving WTF in them was inappropriate)
- The evaluation we received gave us real insight into issues we hadn't even thought about: make sure to carefully consider the points brought up
In the End
If there is one point that we as a group can emphasize the most, it is this: MEET WITH YOUR ENTIRE TEAM OFTEN. Nothing has helped us more in creating our projects than being able to rely on meeting our teammates, having group discussions, and working out issues before they are even able to cause problems. This can be a good learning experience and, dare I say it, even a fun assignment so long as you coordinate your group properly. You will certainly feel a sense of accomplishment when you submit your final project, and you should: you worked hard. Right?
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu