Syllabus
CSSE 220 – Object-Oriented Software Development
Fall 2016–2017  (a.k.a. 201710)

Prerequisites and Course Content

Prerequisites

The formal prerequisite is: CSSE 120 – Introduction to Software Development.

The main things you should bring into this course include:

Course catalog description

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.

CSSE Department's Official Learning Outcomes: CSSE 220

Students who successfully complete this course should be able to:

  1. Develop software that incorporates the following techniques:
    1. Inheritance and class hierarchies
    2. Interfaces
    3. Polymorphism
    4. Casting
    5. Exceptions
    6. Function objects
    7. Generics
    8. Collections
    9. Event-driven graphical user interfaces
    10. Exploring and using large-scale API packages such as Java’s Swing
    11. Recursion
    12. Parallelism and multi-threading
  2. Perform the following steps of the software development cycle effectively:
    1. Design expressed as UML class diagrams
    2. Documentation before coding
    3. Unit and system testing
  3. Explain the implementation of sequential and linked lists
  4. Explain the concepts of asymptotic worst, best, and average case run time.
  5. Predict the performance of simple algorithms, including search and sort, given their asymptotic worst, best, and average case run times.
  6. Select basic data structures (i.e., arrays, sequential lists, and linked lists) based on asymptotic time and space complexity of typical operations.
  7. Work in a team of 3–4 students on a small-to-medium-size software development project including at least three iterative development cycles, demonstrating effective:
    1. Use of team roles
    2. Team decision making
    3. Division of labor
    4. Conflict resolution

Contact info, Outside help

Instructor

Mike Hewner (feel free to call me Buffalo), Assistant Professor of Computer Science and Software Engineering
Email: hewner (at) rose-hulman.edu
Office phone: (812) 877-8517
Cell phone: (716) 517-7671 (it's frequently better to text me rather than call)
Office address: Moench F-204 (top floor, near CSSE labs)
Home page: http://www.hewner.com
Office hours: feel free to stop by whenever I'm in the office. Email also works.
Aaron Wilkin, Assistant Professor of Computer Science and Software Engineering
Email: wilkin <at> rose-hulman <dot> edu
Office phone: (812) 877-8575
Office address: Moench F-203 (top floor)
Home page: http://www.rose-hulman.edu/~wilkin
Office hours: feel free to stop by whenever I'm in the office. Email also works.
Matt Boutell, Associate Professor of Computer Science and Software Engineering
Email: boutell <at> rose-hulman <dot> edu
Office phone: (812) 877-8534
Office address: Myers 240C (near Global Studies and across from Dr. Mutchler's office)
Home page: http://www.rose-hulman.edu/~boutell
Office hours: As you can see on my calendar, I try to keep 4th and 8th hours on class days free of other meetings, so those are best. But feel free to stop by any time that's not otherwise reserved - I'm usually around. Email also works.

Other Sources of Help

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.

Books

Required text

PLEASE USE THE SPECIFIED VERSION! WE WILL NOT PROVIDE SECTION NUMBERS FOR ANY PREVIOUS VERSIONS OF THE TEXT.

Big Java: Early Objects

Big Java: Early Objects, 5th edition, by Cay Horstmann

Paperback: 1027 pages
Publisher: John Wiley & Sons, Inc., 2009
ISBN: 978-1118431115

Links: Companion Site· Source code· Errata

Please use the 5th edition of the textbook. Assignments will not be given for 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 read the Java code in the textbook; if there is something there that you don't understand, read the surrounding text also. After the first few chapters, almost everything will be new, and most reading assignments will be smaller.

"From the Source" Reference

Java Logo

The Java™ Tutorials, Sun Microsystems.

On-line: http://docs.oracle.com/javase/tutorial/
Publisher: Oracle (July 20, 2011)
Language: English

Reading assignments

In the beginning of the class, you will use your textbook to help you learn the Java programming language. For topics you already know from previous classes, we expect you to be able to use the textbook and relearn them in Java. Specific details will often not be covered in class; you'll need the book to refer to do your assignments.

Once we finish with review material from 120, each class will generally have an associated reading assignment. Reading assignments are generally optional, though we think that the material will definitely help you understand the content of the course. Keeping up with the reading is generally a good idea if you intend to do well in the course.

Occasionally we will have specific reading assignments we consider essential. Generally these topics will be harder or topics we don't have time to cover in class.

Homework and Projects

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

Late Assignment Policy

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 classes quizzes cannot be made up. However, we will drop your 3 lowest quiz grades.

Grading

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:

We will do our best to conform to the Rose-Hulman definition of the various grades, as described in the Academic Rules and Procedures. Note in particular that the phrase “thorough competence to do excellent work” appears there in the description of the “B” grade (not “A”), and it further states that “B” and “B+” will not be given for mere compliance with the minimum essential standards of the course.

Letter Grades

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%

We want you and the other students to feel welcomed in our classroom.

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:

You can do your part to ensure a welcoming, professional classroom climate by:

Citizenship Counts!

We may adjust your overall average up or down by up to 5 percent, based on your citizenship in the CSSE 220 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. After three unexcused absences you must speak with your instructor about whether you can continue in the course.

Serious illness is an excused absence. Running a fever? Contact the health center, don't come to class, email us so we know about the situation. We will work with you on a plan to make up the work when you're feeling better.

Bug Reports

If you find errors in the textbook or any of our course documents, please report them via email. 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. Please point out even little things like broken links and spelling errors.

Communication

We usually check email several times per day, and do our best to respond quickly. It is a good way to get answers to simple questions. We expect you to check your email daily (not necessarily on weekends, although even that is not a bad idea). When we send mail to you, we will use your Rose-Hulman address. If you do not currently read mail that is sent to that address, please have it forwarded to wherever you do read mail.

If you really want to ask your instructor a private question via email, please include 220 in your subject line (and include a real subject line), so that we can quickly pick it out from among the dozens of daily email messages that we receive and respond to you more quickly.

Some examples of good and bad subject lines:

Bad: Confusion about Assignment 1
Bad: CSSE 220
Good: CSSE 220: Confusion about Assignment 1

We welcome your suggestions for improving the course.  Please tell us about things in the course that help you to learn, and things we might do to improve the quality of 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.

Electronic Distraction

We do our best to keep class interactive. With laptops and cell phones in class there are many more ways to become distracted. When these distractions disrupt class learning your "Course Citizenship" grade will suffer.

We strongly encourage you to turn off IM and email software and only use other software for things directly related to class.

Sights/Smells/Sounds: As would be expected in the workplace, please be respectful of those around you. If your visual appearance (e.g., offensive computer desktops), smell (e.g., halitosis or tobacco), or sounds created (e.g., cell phone, computer noise, or snoring) are disruptive to class, you will be asked to leave until the issue can be corrected.

Academic Integrity

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 the class. This policy will by 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 have to:

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

This syllabus has been written and revised over several terms by Claude Anderson, Matt Boutell, Curt Clifton, Delvin Defoe, Micah Taylor, Mike Hewner, and Amanda Stouder.