The formal prerequisite is a C or better in CSSE 220 or CSSE 221, so I expect that you know how to program object-oriented Java code well, and that you have experience with recursion and simple sorting algorithms. What you really need for attitudes are (1) a willingness to work hard, (2) patience to plan your code, (3) the tenacity to code and debug until it works, and (4) attention to detail while doing analysis.
A list of attributes, for those who like lists, is here.
This course reinforces and extends students' understanding of current practices of producing object-oriented software. Students extend their use of a disciplined design process to include formal analysis of space/time efficiency and formal proofs of correctness. Students gain a deeper understanding of concepts from CSSE 220, including implementations of abstract data types by linear and non-linear data structures. This course introduces the use of randomized algorithms. Students design and implement software individually, in small groups, and in a challenging multi-week team project.
Students who successfully complete this course should be able to:
Micah Taylor
| Email: | taylormt
<at> rose-hulman
<dot> edu |
| Office address: | Moench F205 |
| Home page: | http://www.rose-hulman.edu/~taylormt |
| Office hours: | Almost any time- check my Exchange calendar or my website. |
We use Piazza for announcements and class discussion. The system is highly catered to getting you help fast and efficiently from classmates, the TAs, and the instructors. Rather than emailing questions to the teaching staff, I encourage you to post your questions on Piazza.
Bookmark our class page: http://piazza.com/rose-hulman/winter2015/csse230/
| David Robinson | Sunday 8pm – 11pm Percopo classroom | Monday 6pm – 9 pm Percopo 122 |
| Janelle Weir | Monday 8pm – 11pm Percopo classroom | Wednesday 9pm-12am Percopo 221 |
Data Structures and Problem Solving Using
Java,
4th edition by Mark Allen Weiss
Softcover: 984 pages
Publisher: Addison Wesley, 2010
Links: Errata Source code
Note that the book is also available electronically on CourseSmart.com, for about 40% of the list price.
The Java™ Tutorials, Sun Microsystems.
On-line:
http://download.oracle.com/javase/tutorial/
Publisher: Oracle, who purchased Sun Microsystems, originator of Java.
Language: English
We will use Moodle to post grades and materials that require restricted access (like quizzes, surveys, and homework solutions). Starting code for most programming projects will be provided via Subversion (details in the first programming assignment document).
Most static course materials will be on standard web pages:
We recommend that you bookmark the schedule page. You can get to the course main page from there, but you will use the schedule page more often.
Your solutions to programming problems should be well-designed and well-documented. Some will be with a partner, others will be individual. Each submitted program file should include (in comments at the top of your files) your name(s) and a description of the file’s contents. You should use reasonable and consistent comments, style, and indentation. Longer methods should contain internal comments that explain why you wrote the code the way you did. Your programs should not contain lines that are exceedingly long (causing wraparound and general unreadability of printouts). Grades for programming problems will be based on correctness, style, and efficiency.
We will assign several written homework problems and in-class exercises. They will usually be short thought problems, mathematical analyses, or algorithm-design exercises. We expect you to think through them carefully and write your answers legibly and clearly (if you can’t write it neatly, type it). On some problems, not only the correctness but also the quality of your solution will determine your grade. Some of the problems will be straightforward practice with concepts from the course; others will require creative solutions. Don’t put them off until the last minute! They will usually be assigned two class periods before they are due, so you will have a chance to ask questions about them in class on the intervening day.
There will often be in-class quizzes, which differ significantly from traditional quizzes. The answers to all of the questions should be contained in the lecture. The quizzes should help you to focus on some of the lecture material that we consider most important, to stay on track during discussion time, and to have some notes that you can use for review later. They are often graded, but not always.
It is important that you keep up with the course material as we go along. Thus we may occasionally give an unannounced quiz, over reading assignments or recent class discussions, written assignments, or programming assignments. Such a quiz will count toward your homework/programs grade.
Readings are posted on the schedule page for each day. In-class discussions will assume that you have done the reading and understood the "easy stuff" before class. Please ask in class or in our offices about any details that you don’t understand; answering questions is one of our favorite parts of the job. Developing software is hard. The more class time we can devote to hands-on work, the more we can help you to succeed. Time spent covering material that you really can learn from the book takes away from the hands-on time in class. We strongly believe that reading the textbook will help you. You may possibly be able to "get by" without reading the textbook. But did you come to Rose-Hulman to merely "get by" or did you come to be the best?
The Weiss textbook has many exercises at the ends of the chapters; it is a good idea to read all of them and to think about how you might approach them. We will only assign a few of them to be turned in, but others have been known to show up as exam problems. In addition, the Key Concepts sections at the end of each chapter provide a nice review of the major concepts in the chapters. You should learn the terminology as well as the ideas, so that you can effectively communicate with others.
Unless we offer a grace period† for a particular assignment, all assignments must be turned in before the due time if you want credit for them. This includes "written assignments" (which may sometimes have a small programming component), Moodle quizzes, and in-class exercises designated to be completed as part of the homework.
However, we all have days when we are extremely busy, or times when a program takes longer to complete than we expect it will. To account for this, we give each student a “late day bank account” that starts with three late days.
Late Day Procedures: You do not have to notify us when you earn or use a late day. We will keep track of your late and early days. These will be based on the time of your submission to an Moodle drop box or your latest commit time of a given project to your SVN repository. We will send you a link to the file where we irregularly update current late day balances. (You should also keep track of your balance.)
Some particular assignments may be designated as ”no late days“ assignments. This might happen because:
†grace period: Occasionally, we will allow extra time for everyone to complete a particular assignment without “extending the due date.” The difference is subtle. If you are working on an assignment during a grace period, you should do so with the recognition that you are behind, and you need to quickly finish it and move on to the next assignment. If we decide to give a grace period for an assignment, we will explain the reason for it.
There will be two exams during the term, and
a final
exam
during exam week. On each exam there will be a paper part and
a computer part. On the computer part most of the credit will be for
actually getting the code working. Typically, about 1/2 of
the credit for each exam will be for the computer part, although it
varies between 1/4 and 3/4. There will likely also be an exam 2a
(programming only).
| Weight | Criteria |
|---|---|
| 5% | In-class quizzes |
| 30% | Written assignments, programming projects, in-class exercises |
| 10% | Major project |
| 13% | Exam 1 |
| 7% | Exam 2a (programming only) |
| 15% | Exam 2 |
| 20% | Final Exam |
Final grades are also contingent on the following:
We will do our best to conform to the Rose-Hulman definition of the various grades, as described in the Academic Rules and Procedures. As you read it, note in particular that the phrase “thorough competence to do excellent work” appears in the description of the “B” grade (the standard for “A” is even higher), and it further states that “B” and “B+” will not be given for mere compliance with the minimum essential standards of the course.
We may adjust your overall average up or down by up to 5 percent, based on your citizenship in the CSSE 230 learning community. This includes attendance, promptness, preparation for class, positive participation in class and the online discussion forums, constructive partnership in pair and group assignments, timely completion of various surveys, and peer evaluation of other students’ code and of your team members for group projects.
The in-class time in this course constitutes an important learning experience. You should be there. Two unexcused absences will affect your Citizenship grade. Three or more unexcused absences may result in failure of the course.
If you find errors in the textbook or any of our course documents, please report them via the bug reports discussion forum on Moodle. We will give a small number of extra credit points to the first person to report a given bug. The number of points will depend on the severity and subtlety of the bug that you report. We recommend that you subscribe to that discussion forum (and to the other course discussion forums).
Piazza is a place where you can discuss various aspects of the course, including the assignments, with other class members. The student assistants and we will read the discussions and sometimes respond to your posts. One way to enhance the Citizenship part of your grade is to post thoughtful questions, answers, and comments to the forums.
We welcome your suggestions for the course. Please tell us about things in the course that help you to learn, and things we might do to improve the course for you. If there is something that you'd like to tell us, but don't feel comfortable with us knowing who it comes from, you can use the Anonymous Suggestion Box survey that we have provided on Moodle.
We will do our best to keep the class interactive and relevant. But we recognize that sometimes it is hard as a student to stay focused on the class. With laptops in class, there are many more ways to become distracted. Unfortunately these distractions are much more pernicious, since it is very easy to get drawn into things like IM conversations or RSS feeds.
In the classroom we strongly encourage you to turn off IM and email software and only use other software for things directly related to class. If you must use non-class-related software during class, then you should sit in the last allowed row. Doing so will keep you from distracting your classmates with what is on your screen.
Recall the Institute policy on academic misconduct:
“Rose-Hulman expects its students to be responsible adults and to behave at all times with honor and integrity.”
Exams and homework will be done on an individual basis except where explicitly noted. The simple rule of thumb for individual work is:
Never give or use someone else’s code or written answers.
Such exchanges are definitely cheating and not cooperation.
We encourage you to discuss the problems and general approaches to solving them with other students. However, when it comes to writing answers or code, it should be your own work (or the work of your group if it is a group assignment). If you are having trouble understanding how some library code works or pinning down a run-time or logic error in your program, by all means talk to someone about it. Get help with debugging when you need it.
If you use someone else’s ideas in your solution, you must:
If you are ever in doubt about whether some specific situation violates the policy, the best approach is to discuss it with your instructor beforehand. This is a very serious matter that we do not take lightly. Nor should you.
You should never look at another student’s code to get ideas of how to write your own code. Beginning the process of producing your own solution with an electronic copy of work done by other students is never appropriate.
Working on written problems with other students is strongly encouraged. However, once you have solved a problem, each student should write up the solution individually, without referring to the common solution, to make sure that all of you understand it. Again, electronic copying is never appropriate.
Plagiarism or cheating will result in a negative score (-100%) for the assignment or exam. Egregious cases will result in a grade of “F” for the course. More importantly, such dishonesty steals your own self-esteem and your opportunity to learn. So don’t cheat!