Courses:

Help support MIT OpenCourseWare by shopping at Amazon.com! MIT OpenCourseWare offers direct links to Amazon.com to purchase the books cited in this course. Click on the book titles and purchase the book from Amazon.com, and MIT OpenCourseWare will receive up to 10% of all purchases you make. Your support will enable MIT to continue offering open access to MIT courses.

6.170 meets four days per week. Generally speaking, the first three sessions per week are lectures, and the final session is a recitation.

For the first half of the term, you will have weekly problem sets. The problem statements will be made available on Wednesdays; solutions are due electronically before the final class session of the following week.

Each student will meet personally with his or her teaching assistant for 15 minutes each week to go over the completed problem set. The teaching assistant will have looked briefly at your work in advance, and will make a grading decision after the meeting. The purpose of the meeting itself is to give you a chance to explain your work, to answer questions about it, and to receive feedback. You should not expect to receive written comments in addition. Your teaching assistant will schedule the weekly meeting with you.

There will be a single quiz, focusing primarily on the technical material presented in lecture.

Your responsibilities are: to attend lectures, recitations and grading meetings, and to work on the individual problem sets and the final project.

To determine your grade, we will first compute a numerical value, based on your individual work on problem sets, your team work on the final project, and your quiz score. We will then rank all the students in the class, and delineate boundaries that correspond roughly to letter grades. We will then consider each student's work individually to check that the letter grade corresponds to our sense of the student's achievement, and may adjust the grade accordingly. This subjective evaluation is based on several factors, including: participation in recitations and final project team meetings, and contributions to the online discussion forum.

All team members in a project team will receive the same project grade. In order to have the best project experience, team up with students who have the same expectations and motivations as you do with respect to project and overall course grades.

Late work will receive no credit. Because the schedule is so tight in 6.170, we cannot let students get behind. Under extraordinary circumstances (such as severe illness), we may accept late work; in such cases, you will need written consent in advance from your teaching assistant. Grades of 'incomplete' will not be given.

Collaboration is encouraged for all assignments. In order to ensure that all students learn from the course, however, we require that the written work handed in during the first half of the term be your own. No materials that you develop jointly during meetings with other students or staff may be included in your submitted work; we therefore recommend that you do not take any materials away from such meetings at all. You may not look at solutions by other students, from this term or previous terms. It is your responsibility to ensure that other students do not copy your work, and it is therefore a violation of course policy to make your course directory readable by others.

You must acknowledge on the written work itself the contributions of other students with whom you discussed it. To encourage you to broaden your collaborative experiences, we permit you to collaborate with other students on at most two problem sets. You may collaborate on problem sets with your team members (but, of course, not more than twice with any particular team member).

For the final project, full collaboration on all aspects is permitted, although every member of the team will be expected to contribute a roughly equal share to the design and implementation.

A liberal collaboration policy increases the risk of cheating. Remember that cheating is unethical, and will be dealt with severely. A single cheating incident can permanently mar your MIT record. Be warned that we use technological means to expose cheating. You should also realize that your teaching assistant will be suspicious if there is a gross discrepancy between the quality of your written work and your ability to explain it during grading meetings.

There are no required textbooks. We recommend two books:

Liskov, Barbara, and John Guttag. Program Development in Java™: Abstraction, Specification, and Object-Oriented Design. Reading, MA: Addison-Wesley, 2000. ISBN: 0201657686.

Bloch, Joshua. Effective Java™: Programming Language Guide. Reading, MA: Addison-Wesley, 2001. ISBN: 0201310058.

The Liskov book parallels the course material closely; it's a good book for background reading. The Bloch book explains, in about 60 short items, some key ideas in program style, as well as some subtleties of Java^TM; it's perhaps better appreciated when you have some familiarity with Java^TM and want to delve deeper.

Some other excellent books you should consider for your reference library on software engineering are:

Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995. ISBN: 0201633612.
The seminal book on design patterns, usually referred to as the "Gang of Four book". Organized as a catalog.

Fowler, Martin. Analysis Patterns: Reusable Object Models. Reading, MA: Addison-Wesley Professional, 1996. ISBN: 0201895420.
A book on object models of problems, organized in the style of the "Gang of Four book". Notation differs slightly from the notation we'll use, but that shouldn't be a major obstacle.

———. Refactoring: Improving the Design of Existing Code. Reading, MA: Addison-Wesley, 1999. ISBN: 0201485672.
A book on techniques for restructuring code to make it more readable, extensible, and maintainable without changing its meaning. Particularly helpful for those coming from a non-object-oriented background. Examples are presented in Java^TM.

Jackson, Michael. Software Requirements and Specifications. Reading, MA: Addison-Wesley and ACM Press, 1995. ISBN: 0201877120.
A collection of short and entertaining essays on software development. One of the only books to explain clearly the difference between 'requirements' and 'specifications'.

The course is not about Java^TM, but you will be need to learn Java^TM in the first week or so. Some books you might find helpful are:

Horton, Ivor. Beginning Java™ 2: JDK 5 Edition. New York, NY: Wiley Publishing, 2004. ISBN: 0764568744.

Flanagan, David, and Brett McLaughlin. Java™ 1.5 Tiger: A Developer's Notebook. Cambridge, MA: O'Reilly Publishing, 2004. ISBN: 0596007388.
This book can also be read online on Safari through MIT Libraries (requires certificates).

The Flanagan and McLaughlin book should suit those who already know some Java^TM (we will be using Java^TM 5 this term). Those who don't know Java^TM are better off with the Horton book, which is a self-contained tutorial for the language.

A more advanced book on Java^TM, which just came out is:

Bloch, Joshua, and Neal Gafter. Java™ Puzzlers: Traps, Pitfalls, and Corner Cases. Reading, MA: Addison-Wesley Professional, 2005. ISBN: 032133678X.
It contains a very entertaining and thought-provoking collection of puzzlers that elucidate subtle aspects of Java^TM.

Other books on Java^TM include:

Arnold, Ken, James Gosling, and David Holmes. The Java™ Programming Language. 3rd ed. Reading, MA: Addison-Wesley, 2000. ISBN: 0201704331.
A brief explanation of Java^TM. Assumes more background; much less explanation about how to use Java's^TM features. User interface libraries not discussed. Details online.

Gosling, James, Bill Joy, and Guy Steele. The Java™ Language Specification. 3rd ed. Reading, MA: Addison-Wesley, 2005. ISBN: 0321246780.
The official reference for Java^TM by its inventors. Good for reference, but not an easy way to learn Java^TM. Available as a book, or online.

Flanagan, David. Java™ in a Nutshell. 4th ed. Cambridge, MA: O'Reilly Publishing, 2002. ISBN: 0596002831.
A reference book rather than a tutorial. Succinct but covers a lot. Assumes knowledge of a language like C. Details online.

Eckel, Bruce. Thinking in Java™. 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2002. ISBN: 0131002872.
Also available on-line at Mindview (but don't try printing it yourself - it's over 1000 pages long!). Written for someone who can already program but isn't familiar with Java^TM or object-oriented programming notions. Goes into lots of detail on tricky aspects like GUIs, multithreading, and remote method invocation.