6.170 / Spring 2002 / General Information

Handout A1

• Course web site
• Registration Form
• Staff
  • Staff Hours
  • Whom to Ask
• Student Responsibilities
  
• Texts
  • Required Text
  • Recommended Java Texts
  • Other References
• Where and When
  • Lectures and Reviews
  • Quizzes
• Policies
  • Grading policy
  • Late/missing work
  • Collaborative work
• Procedures
  • Handouts
  • Graded Assignments
• Problem Set hints

Course web site

The course web site is http://web.mit.edu/6.170/www/.

Registration Form

You must fill out the online registration form by midnight on Tuesday February 5, or you will not be able to take the class.

Staff

Staff Hours

TAs will schedule office hours and locations by the end of the first week of class. Please visit your TA (or another TA, if necessary) during their office hours if you have anything you'd like to discuss about the course or course materials. Please see the TA Office Hours for the locations and times of of their office hours.

LAs will schedule LA hours held in designated clusters. Please feel free to work in the cluster so you can talk to them in person when you have questions about Java or other technical details. Time permitting, they also monitor the 6.170 zephyr instance while on duty, but they give priority to students who visit them in person. Please see the LA Lab hours for an up-to-date list of hours.

The lecturers are available by appointment but do not have fixed office hours.

Student Responsibilities

Students develop their abilities through several different activities:

• Lectures. The lectures focus on the fundamental concepts of software engineering. Since there is far more material in software engineering than can be fit into a single course, and since the interests of faculty members vary, the lecture content tends to differ slightly from term to term. This term there will be an emphasis on design idioms and representations. Some students wonder why they should attend lecture when written notes and textbooks are available. There are four reasons. First, the benefit of attending a lecture is to see how someone with more experience frames and articulates a problem: this is perhaps more important and of more enduring benefit than the technical content of the lecture. Second, a lecture will include comments and explanations that are not in the notes; this will be especially true this term. And third, many students who have the best intention of reading notes end up not doing so, and are forced to complete their problem sets with only a partial understanding of the material. Fourth, the quizzes will be based on material covered in the lecture.

• Problem Sets. For the first half of the term, students do weekly problem sets designed to help  them develop basic skills. The first two problem sets cover basic programming in Java, and are intended to be done in conjunction with self-study of Sun's Java Tutorial. The third problem set gives students practice specifying and implementing an abstract data type. The fourth problem set gives experience with object models and invariants. The fifth and sixth problem sets are design problems, in which students design a small program and assemble it using provided components.

• Project. For the second half of term, students work in teams of 3 or 4 on the design and construction of a small but intricate program. They get the opportunity to collaborate closely with each other, and to see a software development through from inception to completion.

• Reviews. Students meet for an hour each week in groups of about 20 for reviews with a teaching assistant. In each session, fragments of specification, design or code will be selected in advance by the teaching assistant, and presented to the group for critique. Peer review has been found to be one of the most effective methods of finding errors in software. In the second half of term, students will direct the presentations, and the teaching assistant will play a role more like a consultant than a teacher.

• Readings. Students are expected to read relevant portions from the course text as indicated in the schedule, before the lecture on the day on which the reading is shown. 

Whom to Ask

When solving your assignments, the laboratory assistants should be your first resource for problems with your Java code or the Athena environment. For other questions, the LAs may be able to help you with advice or information, but you should not rely on them. Your TA can answer most questions about the course. If for any reason, you are not satisfied with the help you are receiving, you should contact the lecturers.

Here are some examples of questions appropriate for various staff members. Naturally, you shouldn't ask a question unless you have first tried to find the answer yourself. When asking a question, be sure to say what you have already tried to do to solve the problem; that way the staff won't waste its time and yours repeating something you already know.

• "I run `java MyClass' and I get this error: XXX"
  Ask an LA.
• "What is an interface in Java?"
  First read your Java text and Liskov's Program Development in Java, then ask an LA or a TA.
• What does function foo in the JDK API do? What arguments does it take?
  Look in the JDK API documentation .
  (Don't ask this sort of question on the zephyr instance, either, unless you have carefully read the documentation and still do not understand it.)
• "The problem set asks for a set of test cases; are these enough: XXX"
  Ask a TA.
• "What does the problem set mean when it says this: XXX"
  Ask a TA.
• "I found a bug in the problem set."
  Ask a TA.
• "My TA hates me and won't answer my questions and makes me sit facing the corner during recitation."
  Ask a professor.

Texts

Required Text

Barbara Liskov. Program Development in Java: Abstraction, Specification, and Object-Oriented Design. Addison Wesley, 2001.
Available at Quantum Books (specially reserved), or from amazon.com . Extra copies of the book have been specially reserved at Quantum which not only sells the book at a discounted price, but will save you the cost of shipping, and, since it is for a class, sales tax.

Recommended Java Texts

This course is not about Java, but you will be required to learn Java during the first two weeks. We recommend that you use this book:

• Mary Campione, Kathy Walrath and Alison Huml. The Java Tutorial, Third Edition: A Short Course on the Basics. Addison Wesley, 2001.
  A step-by-step introduction to all the features of Java, with good examples and well explained. Does not assume familiarity with object-oriented programming.

• Start from: http://java.sun.com/docs/books/tutorial/ .
• Main chapters concerning the Java language: http://java.sun.com/docs/books/tutorial/java/ .
• Exceptions: http://java.sun.com/docs/books/tutorial/essential/ .
• Introductory chapter: http://java.sun.com/docs/books/tutorial/getStarted/ .

We also strongly recommend:

• Joshua Bloch. Effective Java: Programming Language Guide. Addison Wesley, 2001.
  A sophisticated book that explains in nice, short "items", about 60 useful tips about programming in Java. Assumes knowledge of Java and an appreciation of programming in the large. Not easy going for the beginner, but well explained, and well worth studying.

• Ken Arnold, James Gosling, and David Holmes. The Java Programming Language, 3rd edition, Addison-Wesley, 2000.
  A much briefer explanation of Java. Assumes more background; much less explanation about how to use Java's features. User interface libraries not discussed. New edition includes discussion of collection classes. Details at http://java.sun.com/docs/books/javaprog/thirdedition/
• David Flanagan. Java in a Nutshell, 3rd edition, O'Reilly, 1999.
  A reference book rather than a tutorial. Succinct but covers a lot. Assumes knowledge of a language like C. Details at http://www.oreilly.com/catalog/javanut3/ .
• Ivor Horton, Beginning Java 2 -- JDK 1.3 Edition, Wrox Press,2000.
  Tutorial introduction to all parts of Java, including user interface libraries. No knowledge of other languages is assumed. A big book (over 1200 pages!): you won't want to carry this around in your backpack! Available at Quantum Books , or from amazon.com .
• Bruce Eckel Thinking in Java, 2nd edition, Prentice-Hall, 2000.
  Also available on-line at http://www.bruceeckel.com/TIJ2/index.html (but don't try printing it yourself, as it is over 1000 pages). This is written for the person who can already program, but wants to learn object-oriented thinking and the Java language. It goes into lots of detail on the tricky aspects like GUIs, multithreading, and remote method invocation.
• For more on Java, see the Java websites listed in the Athena Environment handout.

Other References

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 995, ISBN 0-201-63361-2.
  The seminal book on design patterns, usually referred to as the "Gang of Four book". Organized as a catalog.
• Martin Fowler. Analysis Patterns: Reusable Object Models. Addison Wesley Longman, 1997.
  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.
• James Gosling, Bill Joy, and Guy Steele. The Java Language Specification.
  The official reference for Java by its inventors. Available as a book, or online at http://java.sun.com/docs/books/jls/index.html .
• Martin Fowler. Refactoring: Improving the Design of Existing Code . Addison-Wesley, 1999. ISBN 0-201-48567-2.
  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.

Where and When

Lectures and Review Sessions

6.170 meets Monday, Tuesday, Wednesday, and Thursday from 10-11 in the morning.
Monday, Tuesday, and Wednesday are lectures in 34-101, and Thursday is a review session.

Review Section Locations (Thursdays at 10am):
You will be assigned to a section based on the sign-up form you submit; the section assignment made by the registrar is ignored. 

Recitation section information will be distributed by email no later than the evening of Wednesday, February 6, and will also be available on the web.

Quizzes

There will be two one-hour quizzes during class time on Wednesday, March 6th, and Wednesday, April 10th.

Policies

Grading policy

All members of a team are usually given the same grade for the team project. The grade includes both written materials -- specifications, design and code -- as well as oral presentations and constructive participation in review sessions.

To encourage participation in reviews in the first half of term, teaching assistants can award significant credit (up to 10% of the final grade) for constructive contributions during review sessions. The total portion of the grade allotted to problem sets and participation is capped at 45% of the total grade, but using participation credit, it is possible to achieve a perfect score despite points lost on written problem sets.

Your written work will be graded on the quality of the ideas and the quality of their presentation. Code will be judged by its clarity, organization, style and correctness. It is the student's responsibility to demonstrate to the grader that the code is correct by showing the results of running a test suite. In the absence of such evidence, graders will assume that code is not correct. This is the standard you would be held to in industry. If there is no appropriate output to show, you should add a comment stating that a test suite executed successfully (or not, if it didn't).

We make every effort to standardize TA grading policies, but we reserve the right to normalize grades across recitation sections to account for remaining disparities.

Late/missing work

• Late work will receive no credit. Problem Sets are due on Mondays or Tuesdays in lecture (34-101) or the course secretary's office by 4pm. In unusual or extenuating circumstances (such as illness with a doctor's note), you may be able to turn in an problem set late and still obtain credit for it. Unless the circumstances are quite extraordinary, you must receive advance permission from your TA. 
• You must hand in:
• Problem Set 4, and
• one of Problem Set 5 or 6, and
• the project

or you will fail the course. You will not pass the course if you receive no credit for these, or if what you hand in is too insubstantial to be deemed a reasonable effort.

• Grades of "incomplete" will not be given, except under extraordinary circumstances.

Collaborative work

The Departmental Guidelines Relating to Academic Honesty require that we inform you of our expectations regarding permissible academic conduct.

• You may discuss any of the course material with other students.
• You may discuss the problem sets, and you may talk about potential solutions with other students, whether or not they currently enrolled in the class. What you hand in, however, must be entirely your own work (with the exception of reused code -- see below). You will be expected to be able to explain your work during reviews in front of other students, so it will be necessary for you to understand your solution to any problem in every detail. In particular, you must not copy explanations, written answers to questions, design diagrams, source code, or test cases from other students, in whole or in part.
• Throughout the course, you may make use of any software artifact -- specifications, design, algorithms or code -- in the public domain , so long as it was not prepared by a student for 6.170. For example, you can use code you find in textbooks and on the web, but you can't copy code from your fraternity's bible.
• For the project, you are encouraged to collaborate with your teammates on all aspects of the work, although every member of the team will be expected to contribute equally to the design and implementation. We will expect the team to be able to account for what each team member contributed to the project. The same policies that apply to individual students during the first half the term also apply to the project teams. For instance, a team can discuss design ideas with another team, but must not copy any of its design models.
• 'Pair programming' is permitted for the project, but is strictly forbidden for the individual problem sets.

This policy is more lenient than it has been in previous terms, in an attempt to foster constructive collaboration amongst students. We therefore depend on the honesty of students in not violating it, and will take very seriously even minor infractions. If you are found to have copied code from another student's work, you should expect to fail the course.

We rely on students' honesty in their declarations that test suites run successfully. It is a very serious violation of academic ethics to submit such a claim with code that does not in fact pass the suite. In order to avoid clerical errors that may give the appearance of dishonesty, we strongly suggest that you rerun all your test suites when you have completed your code immediately prior to submission.

Procedures

Handouts

Handouts will be distributed on the class web site. Announcements will be posted as Messages of the Day on the class website . These announcements are also available by subscribing to the 6.170-motd mailing list. Very important announcements will be emailed to all students.

Graded Assignments

Graded assignments will generally be returned to you in the review session on Thursday the same week that they were due (usually on Monday).

Problem Set hints

To complete the problem sets as efficiently as possible, and to derive the most benefit, we recommend that you:

• Start as early as possible. Elapsed time helps.
• Read the entire text of the assignment before starting any part of it.
• Don't rush to code. You'll find that the more time you spend on design, the less time you spend coding (and much less time debugging).
  
• Write test cases before you code. This avoids the pitfall of thinking about the code as you write your tests, which could cause you to overlook the same issues in your testing as you did when writing the program. You may want to add additional test cases after writing the code, of course, particularly if implementing the specification brought issues to your attention that you had not been aware of before you started coding.
• Don't debug aimlessly: you'll waste a lot of time and get frustrated. Instead, form a hypothesis and devise an experiment to check it. If you're stuck, leave your computer for a while. You may well find that clearing your head allows you to see an obvious problem that you'd missed before because you were focused on the (wrong!) details. When you're tired, stop.
• Make sure that your answers to questions are succinct and to the point.