CSE 341 - Spring 2002 - Project

Jump to... [ Overview | Goals | Requirements | Deadline Summary | Project Ideas ]

Note one-day extension for the design and implementation plan.

This team project is meant to be fun and open-ended, as well as a good learning experience, so while we do provide guidelines on how you should work on it, there are very few restrictions on exactly what you work on. To help your team stay on track, there are a variety of intermediate milestones, and when you're done, we'll all enjoy seeing the work we've done in demos or on the course web.

These are the skills and experiences you should focus on in working on this project, roughly ordered with the most important first.

• designing and implementing in an object-oriented language, focusing on...
  • inheritance
  • problem decomposition
• learning more about the language features (including standard libraries) of Smalltalk or Java in a practical, project-oriented setting
• communicating well-considered design decisions and reasons to justify them
• developing software in a group

We would like you to work in groups of two to three, primarily for the reasons below. Let these goals guide how you work with each other to ensure you get the most out of this experience.

• You can learn better by communicating about ideas. Talking with peers about language features and other concepts will help you refine your understanding of them as you recognize concepts you feel more/less comfortable applying or discussing.
• OO language features facilitate group development. This is one way in which interfaces, multi-file projects, and other OO language features are useful.
• It's more realistic. All but the smallest real-world development efforts (whether in industry, academia, wherever you go) are collaborative.
• The whole is greater than the sum of the parts. You can get a more complex, more interesting, more fun, more (your favorite positive project attribute) project completed working in a group than you can alone. For instance, good design results from evaluating a wide variety of options at each decision step, so the more points of view, the better!

Since you will be doing demos of your projects during section time on Thu 06 June, we strongly recommend you team up with people in your section. All team members must be present for the demo, so if you don't team up within your section, at least make sure that everyone in the team can make it to at least one of the two section periods (8:30 and 9:30 am) on 06 June.

Form your team and give it a name by Wed 08 May, 7:00 pm and send one e-mail for your team to Ken <yasuhara@cs> with the following:

• full names of all team members
• team name

As you work on this project, we may ask each team member to submit a brief survey about how you think you and each of the other team members is contributing to the team.

If you have legitimate reasons for working individually, special arrangements can be made. Please contact Alan as soon as possible if this is the case.

To make sure you get a strong start early, by Mon 13 May, 7:00 pm, your team should submit a well-structured document discussing...

• what you intend to develop and why (one paragraph)
• which language (Java or Smalltalk) you chose and why, minimally discussing why the language you chose fits your project well, if not also discussing why the other option might not be so good (one to two paragraph)

If you choose Java, specify whether you intend to implement as an applet or a stand-alone application. (We suggest applet, which makes it easier to proudly share your work with friends and family.) Write your document as plain text and submit only via computer using turnin.

Think, and then code. To make sure you stay on the right track, by Mon 20 May Tue 21 May, 7:00 pm, your team should submit a document including...

• a description of the public interfaces (not implementation) of each of the main classes you will develop for your project (one paragraph per class)
• a description of how the classes will work together to form a useful program (one paragraph)
• a preliminary implementation timeline that specifies who will work on which classes (or you can work on them all together---just say so), and in what order the classes will be developed to ensure that you have a working (if not 100% complete) project done on time (one to two paragraphs)

In this document, we are primarily looking for the results of your engineering and design decisions, but you should be prepared to defend these decisions, since you will have to write about your reasons in the final project report.

You should also submit this as plain text via turnin only.

Code quality is Job 1. As you code, keep in mind the same goals as you do when you work on your homework. See the Homework Submission Guidelines page for a refresher. In particular, pay close attention to OO design, as stated in Goals above.

You're welcome to make full use of standard libraries, and if you use any other code you find elsewhere, make sure to cite it appropriately (what you used, who wrote it, where you found it, and how you changed it, if at all). (Obviously, we expect a significant extension of any existing code.)

Your code should be submitted by the beginning of class on Wed 05 June (same day as the final report) via computer only.

Not just what you did but why. Your final report should stand alone as a complete document and include the contents of your Project Proposal document and your Preliminary Design and Implementation Plan document, updated as necessary. In addition, your team should identify one significant engineering decision that was difficult to resolve and discuss...

• at least two options (different ways you could have made the decision)
• the advantages and disadvantages of each option
• what you ultimately decided and why

This report is due on Wed 05 June at the beginning of class and should be submitted both on paper and via computer. Please use plain text, HTML, PostScript, or PDF (all viewable across platforms). If you need to use another format, check with Ken <yasuhara@cs> first.

Be proud of what you've done. During section time on Thu 06 June, each team will be given about 10 min. to demo and discuss the project with the TAs. All team members should be prepared to discuss any part of the design and code. We will be meeting in one of the labs in Sieg Hall (room TBA Sieg 232).

Write these on your arm, if that's what it takes to remember them.

• Wed 08 May, 7:00 pm - team declaration (via e-mail to Ken)
• Mon 13 May, 7:00 pm - project proposal (via computer only)
• Mon 20 May Tue 21 May, 7:00 pm - design and implementation plan (via computer only)
• Wed 05 June, beginning of class - code (via computer only) and final report (via computer and paper)
• Thu 06 June, section (location TBA Sieg 232) - demo and interview
• Tue 11 Jun, 12:00 pm (noon) - retrospective survey

Not sure what to do? Below are some suggestions, but we encourage you to come up with your own ideas. Check with Alan, Harr, or Ken to discuss other ideas, what's feasible and appropriate for this project, what outside resources you should look to, etc.

• A graphical game. Consider doing a networked multiplayer game. (In Winter 2002, the Smalltalk project was an Asteroids game---one possible starting point. In previous quarters we did pinball.)
• A cool project from a previous quarter was a Logo interpreter applet. See the Logo Foundation for more about this simple (and fun!) programming language. Also check out an implementation called StarLogo, which happens to be implemented in Java.
• 3D maze exploration game
• animation of your favorite data structure or algorithm, e.g., binary search, various sorting algorithms, linked lists and variations, binary trees (If you've taken CSE 326 or 378, consider a more advanced data structure or circuit/hardware simulation.)
• a simple web browser - This would display the links and allow navigation. You obviously don't need to produce Netscape or Internet Explorer, but some simpler functionality should be quite possible.