6.170 / Fall 2001 / General Information
The course web site is http://web.mit.edu/6.170/www/
You must fill out the online registration
by midnight on Thursday September 6, or you will not be able to take
Teams for projects must be in the same recitation. Please, make sure
that your schedules coincide, and you can attend the same recitation.
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
Students develop their abilities through several different activities:
- Lectures. The lectures focus on the fundamental concepts, and
are grouped roughly according to the main divisions of the syllabus below.
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, and lectures will
include discussion of some case study programs which students will be asked
to look over in advance. Some students wonder why they should attend lecture
when written notes and textbooks are available. There are three 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 usually includes comments and explanations that are not in the
notes. And third, many students who have the best intention of reading notes
end up not doing so, and are forced to complete their exercises with only
a partial understanding of the material.
- Exercises. For the first half of the term, students do weekly
exercises designed to help them develop basic skills. The first two
exercises cover basic programming in Java, and are intended to be done in
conjunction with self-study of Sun's Java Tutorial. The third exercise gives
students practice specifying and implementing an abstract data type. The
fourth exercise gives experience with object models and invariants. The fifth
and sixth exercises 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
- "The exercise asks for a set of test cases; are these enough:
Ask a TA.
- "What does the exercise mean when it says this: XXX"
Ask a TA.
- "I found a bug in the exercise."
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.
Barbara Liskov. Program Development in Java: Abstraction, Specification,
and Object-Oriented Design. Addison Wesley, 2001.
Available at Quantum Books
(specially reserved), or from
. Extra copies of the book have been specially reserved at
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:
The entire text is on the web, but not in quite the same order as
- Mary Campione, Kathy Walrath and Alison Huml. The Java
Tutorial, Third Edition: A Short Course on the Basics. Addison
A step-by-step introduction to all the features of Java, with
good examples and well explained. Does not assume familiarity with object-oriented
We also strongly recommend:
Other books that students have found useful in the past:
- Joshua Bloch. Effective Java: Programming Language Guide. Addison
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.
- David Flanagan. Java in a Nutshell, 3rd edition, O'Reilly,
A reference book rather than a tutorial. Succinct but covers a lot.
Assumes knowledge of a language like C. Details at
- 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
- Bruce Eckel Thinking in Java, 2nd edition, Prentice-Hall, 2000.
Also available on-line at
(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
- For more on Java, see the
listed in the
- 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
- 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 2-3 in the
Monday, Tuesday, and Wednesday are lectures in 4-270, and Thursday is
a review session.
Note that the first Thursday is a lecture and not 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 section information will be distributed by email no later
than the evening of Monday, September 10, and will also be available on
There will be a single one-hour quiz during class time on Wednesday,
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
To encourage participation in reviews in the first half of term, teaching
assistants can award significant credit (up to 20% of the final grade) for
constructive contributions during review sessions. The total portion of
the grade allotted to exercises and participation is capped at 50% of the
total grade, but using participation credit, it is possible to achieve a
perfect score despite points lost on written exercises.
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
- Late work will receive no credit. Exercises are due at 4.05pm
on Wednesdays in the course secretary's office (NE43-529). In unusual or
extenuating circumstances (such as illness with a doctor's note), you may
be able to turn in an exercise 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:
- Exercise 4, and
- one of Exercise 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
The Departmental Guidelines Relating to Academic Honesty
require that we inform you of our expectations regarding permissible
- You may discuss any of the course material with other students.
- You may discuss the exercises, 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 exercises.
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.
Handouts will be distributed on the class web site. Announcements
will be posted as Messages of the Day on the class
. 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 will generally be returned to you in the review session
in the week after they were due.
To complete the exercises 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
- 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,
- Make sure that your answers to questions are succinct and to the
Back to Administrative Info
Back to the 6.170 home page
For problems or questions regarding this page, contact:
$Id: generalinfo.html,v 1.27 2001/09/20 21:41:05 bleung Exp $