Object-oriented programming concepts, including the use of inheritance, interfaces, polymorphism, abstract data types, and encapsulation to enable software reuse and assist in software maintenance. Recursion, GUIs and event handing. Use of common object-based data structures, including stacks, queues, lists, trees, sets, maps, and hash tables. Space/time efficiency analysis. Testing. Introduction to UML.
The formal prerequisite is: CSSE 120 – Introduction to Software Development.
Outside of normal class time, we the instructors are almost always able to assist you when we are in our respective offices.
If you have a grading question you can contact the grader directly (listed on the Moodle submission):
Don’t try to be the “Lone Ranger” in this course, especially if you do not find the course easy. If you find that you have worked on something for 20 minutes without making any progress, it’s probably time to seek help! Software development is a team sport. The best programmers know that a fresh set of eyes can often spot a problem right away.
Big Java: Early Objects, 5th edition, by Cay Horstmann Paperback: 1027 pages Publisher: John Wiley & Sons, Inc., 2009 ISBN: 978-1118431115
Please use the 5th edition of the textbook. Assignments will not be given from other editions.
The book is excellent, but it is written for students who are new to programming as well as to Java. Thus in the beginning of the term the reading assignments are rather long, since you will already know many of the concepts. You should skim the text, looking for things you don’t know, and slow down to focus on those. Definitely study the Java code in the textbook; if there is something there that you don’t understand, read the surrounding text for explanation. After the first few chapters, almost everything will be new, and most reading assignments will be smaller.
The Java™ Tutorials, Oracle. On-line: http://docs.oracle.com/javase/tutorial/ Publisher: Oracle (July 20, 2011) Language: English
All assignments are due at 11:55pm on their due dates (except written assignments you’ll turn in in class — those are due at the beginning of class).
Your solutions to programming problems should be well-designed and well-documented. Unless otherwise stated you should work alone on programming assignments; there will be several paired assignments but these will be clearly identified.
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!
When problems are designated as allowing you to work with a partner, if you need help finding people to work with, let us know, and we will put you in touch with other students who indicate a similar need. If you do an assignment with someone else, it is your responsibility to not allow anyone’s name (including your own) to be placed on the submitted program if that person does not understand the solution.
Each submitted program file should include your name(s), and a description of the file’s contents in comments at the top of your files. They should have reasonable and consistent comments, style, and indentation. They should not contain lines that are more than about 80 characters long. (Long lines make you, and us, side scroll to read to the end of the line; side scrolling hides the context of the line and makes it harder to think about the algorithm.)
Grades for programming problems will be based on correctness (mostly), efficiency (some), and style (some).
In general, you should plan ahead and submit assignments on time. This course has no ‘late day’ policy and late assignments are generally worth 0 points unless you have made special arrangements.
However we understand that situations can arise. We handle all situations on a case-by-case basis. Here are some general guidelines:
In-class quizzes cannot be made up. However, we will drop your 3 lowest quiz grades.
| Weight | Criteria |
|---|---|
| 5% | In-class quizzes |
| 30% | Homework, programming problems and projects, in-class exercises |
| 10% | Team project |
| 16% | Exam 1 |
| 16% | Exam 2 |
| 23% | Final Exam |
Final grades are also contingent on the following:
The following table provides the TENTATIVE breakdown for each letter grade. Note that to receive an “A” in this course, your final grade in the course must be 93% or higher. Also note that below 65% is failing.
| Letter Grade | Final Average |
|---|---|
| A | 93‐100% |
| B+ | 88‐92% |
| B | 83‐87% |
| C+ | 78‐82% |
| C | 73‐77% |
| D+ | 68‐72% |
| D | 65‐67% |
| F | 0‐64% |
If at any point, you are not comfortable in the classroom, for ANY reason, or you observe any behaviors by ANYONE (classmates, course assistants, or your instructors) that may make the classroom climate feel less welcoming for students: please tell us.
Ways to do so include:
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 when 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. The departmental statement on academic honesty has more detailed advice.
This policy INCLUDES sharing code after an exam has completed. Due to the nature of our exams, you will have access to your code after the exam time has completed. This means that if you share your code, someone else may try to commit is as theirs. Understand we have access to commit logs and can easily see when changes were made and who made them. Also, you may be asked if you can share your code with a friend after an exam so they can see how to do the problems. While this may seem okay (as the exam is over) we have seen cases in which a student will ask a friend to “see” their code, then commit it to their own exam repository as their own. If this behavior is discovered, we will be prosecuting both the person who committed the code AND the person who shared the code. If a friend wants to see how you solved a problem after an exam, wait at least until grades are submitted, or you are risking an F on the exam and possibly in the class. This policy will be STRONGLY ENFORCED. The best thing to do in this case is to remind your friend of this policy, then suggest they speak to a TA or the professor so they can make sure they understand the code, which is much more important than just obtaining a copy.
This policy INCLUDES sharing code after graduating from this course. If your code is found used in some other students solution, after your have already completed this course - you will receive a retroactive F in this course.
We encourage you to discuss the problems and general approaches to solving them with other students. However, when it comes to writing code, it should be your own work (or the work of your group if it is a group or partner 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.
If you use someone else’s ideas in your solution (or any other work that you do anywhere), you should:
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 solution 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.
The least possible penalty for plagiarism or cheating is a -100% on the assignment (that’s negative points, not just 0 credit). In places where the cheating seems intentional, the penalty is an automatic F in the course. TO BE CLEAR: you can get an automatic F in this course if you are caught cheating on one small assignment, even one time.
Students are expected to behave professionally. A lack of professional behavior in a student’s interactions within a team, with an instructor, teaching assistants or during in-class activities can result in a penalty grade. Depending on the nature and the egregiousness of the behavior, the penalty grade might be a reduction in letter grade or an F in the class.
These policies has been written and revised over several terms by Claude Anderson, Matt Boutell, Curt Clifton, Delvin Defoe, Micah Taylor, Mike Hewner, and Amanda Stouder.