6.170 / Fall 2002 / General Information

Handout A1

• Course web site
• Registration Form
• Staff
  • Staff Hours
  • Whom to Ask
• Student Responsibilities
  
• Texts
  • Required and Recommended Texts
  • Recommended Java Tutorial
  • 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://6170.lcs.mit.edu/. Note: this is changed from previous years.

Registration Form

You must fill out the online registration form by midnight on the first day of class (4 September), 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 (recitations) 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: ... Why?"
  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: ...?"
  Ask a TA.
• "What does the problem set mean when it says this: ...?"
  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 and Recommended Texts

• Required: Barbara Liskov. Program Development in Java: Abstraction, Specification, and Object-Oriented Design. Addison Wesley, 2001.
• Recommended: 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.
• Recommended: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 1995.
  The seminal book on design patterns, usually referred to as the "Gang of Four book". Organized as a catalog.

Recommended Java Tutorial

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/ .

• 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.
• 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.
• For more on Java, see the Java websites listed in the Tools handout.

Where and When

Lectures and Review Sessions

6.170 meets Monday, Tuesday, Wednesday, and Thursday from 2--3 in the afternoon.
Monday, Tuesday, and Wednesday are lectures in 34-101, and Thursday is a review session.

Review Section Locations (Thursdays at 2pm):
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 assignments are now available. Email 6.170-staff@mit.edu with questions or concerns.

• By name
• By section

Quizzes

There will be two one-hour quizzes during class time on Wednesday, 16 October, and Wednesday, 6 November.

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 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 a 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 a bible. If you use any other software artifact, you must explicitly cite the source and describe what you used.
• 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 reviewed in section on the Thursday following their due dates, and will be returned to you on the following 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.