CS601/CS342: Object-Oriented Software Development

Last updated: January 21, 2009

Spring 2009
Tues/Thur: 3:30-5:15pm HRN 235

Instructor: Terence Parr

Office hours: Any time door is open or by appointment
TA: Shaoting Cai, caishaoting at gmail
  hours: Monday from 1pm to 5pm and Friday 10am to 4pm.
Midterm exam: March 19, 2009
Last day of class: Thursday, May 14, 2009
Exam 1: Mar 19
Exam 2: May 7

This course is cross-listed as both CS601 and CS342; undergraduates and graduate students will be evaluated and graded on different scales.


There is more to being a professional developer than learning the syntax and libraries of a programming language--that part is easy. You must learn how to use the myriad of programming tools, how to write robust code, how to produce a simple design, how to interact with team members, and how to cope with a constantly moving target. Furthermore, you must learn how the network, computer, operating system, and your software operate as a unit to provide a useful service. To do this, you must acquire skills traditionally associated with system hardware and software administration. This class provides a survey of real-world programming mechanics and introduces you to the latest object-oriented software development strategies.

My primary goal is to prepare you for a productive programming and research life while in graduate school at USF. Furthermore, I intend to give you a taste of the technologies, strategies, and problems you will encounter as a professional programmer. Most importantly, I want to teach you to how to learn new concepts and technologies, solve your own problems, and do your own research. As a programmer, you must constantly struggle to keep up with the latest advances or you and your skills will become obsolete in a few years.

Student Learning Outcomes

At the end of this course, the student will


Lab topics

OO principles worksheet
unit testing with jUnit
Data structures
Recursion worksheet
Web servers
HTML page generation
Servlets cookies sessions
Build / deployment / test box

Lecture/Discussion topics

Optional: crash course on Java
Optional: Java I/O, collections
Open-source, patents, licensing; copyrights/patents
Top-down design
Object-oriented design
Logging and its role in producing maintainable software
Security, encryption (basic ideas, what not to do, typical attacks)
System architecture and design issues
How DNS works and how email is shuffled around

How to be a better programmer
Mythical man-month
Programming "by contract"
Aspect-oriented programming
Extreme programming
Testing, robustness
Design patterns
jGuru case study
Dealing with the complexities of team interactions

Lectures notes

Technology lectures

Why writing software is not like engineering
Subversion in CS601
Compiling, Executing, and Jar'ing Java Code
The Relationship between C Structures and Java Classes
How To Look Like A UNIX Guru
Perforce Revision Control (optional)
Unit / Functional Testing and jUnit
Java Input/Output
Java Sockets
Java Threads
Databases & Java
Java Servlets
HTML Page Generation
Using StringTemplate To Generate Web Pages

Design and strategy lectures

The Essentials Of Debugging (Notes)
Top-Down Design In An Object-Oriented World
Writing Flexible Code
UML Diagrams
Multi-programmer development with Perforce
Software Patterns
Programming by contract
Mythical Man Month
Code Refactoring
jGuru System Case Study
Little Bits of Development Wisdom
Agile Development


Java I/O
Perforce Revision Control
Multi-Programmer Perforce Revision Control


Object-Oriented Principles Worksheet
Java I/O Worksheet
Sockets / Networking Worksheet
Cookies, Sessions


Building Dictionary Implementations (Due Feb 5)
Expression Evaluator (Due Feb 19)
Building Unit Tests (Due Feb 26)
Modifying existing source code (Due Mar 12)
HTTP Server (Due Apr 2)

There are no late projects.

I will deduct 10% if your program is not executable exactly in the fashion mentioned in the project; that is, class name and jar must be exactly right. For you PC folks, note that case is significant for class names and file names on linux! All projects will be graded and must run under linux.

Semester Project

WebMail Site
   Release I - Apr 16
   Release II - Apr 30
   Release III - May 14 (last day of class)

Instruction Format

Class periods of 1hr 45min each in 15 weeks. Class will often be broken down into lecture followed by lab with a 10 minute break in between to service coffee and/or junk food requirements. Instructor-student interaction during lecture is encouraged and discussion groups will be formed to solve problems and debate programming philosophy. "Pop quizzes" may appear during any class.


Your grade will be computed according to the following relationship:
5%Labs/Quizzes/Class participation
2.5%Dictionary project
5%Expression evaluator project
2.5%Unit testing project
5%Modifying existing code project
10%HTTP project
40%Webmail project
15%Exam 1 (Mar 3)
15%Exam 2 (May 1)

For the semester project, you must complete the required level to pass the class!

Please note that class participation is part of your grade. You must learn to interact with other developers and come up with solutions.

In general, I will read all papers, projects, quizzes etc... two times. Once to evaluate the average and a second time to assign scores. In the first pass, I also come up with a scoring strategy for each question.

I consider an "A" grade to be above and beyond what most students have achieved. A "B" grade is an average grade or what you could call "competence" in a business setting. A "C" grade means that you either did not or could not put forth the effort to achieve competence. An "F" grade implies you did very little work or had great difficulty with the class compared to other students.

I will be very strict and set a high standard in my grading, but I will work hard to help you if you are having trouble. You some of you may not get the grade you were hoping for in this class, but I will do everything I can to make sure you learn a lot and have a satisfying educational experience!

Unless you are sick or have a family emergency, I will not change deadlines for projects nor exam times. For example, I will not give you a special final exam just because you want to fly home early. Consult the university academic calendar before making travel plans.



There is no required book for this class, however, I will be assigning web reading and will pass out some material. You may find the following books useful:

CS601 Mailing List

I will be sending important information to this mailing list. You are required to sign up for this list. To sign up:


To post, email cs601@cs.usfca.edu.

Semester Project

You will build a web email hosting web server in Java beginning as soon as I think you have the necessary technology. The project is to be completed by the end of the class in December. The labs in the early part of the semester will prepare you. You will work individually to complete this project.

This course will emphasize real-world coding as if you were an employee of a software development company. As a result, you will note the following requirements that are unusual for a course:
  1. You will have to release and demonstrate your project on a regular basis (every 2 weeks) during the semester. At each release, you must have a working server. "Almost working" does not count. Imagine that you are building a site that users will begin to access immediately--you cannot release anything in a buggy or "almost-working" state. Show the working server from the last release rather than a new one that introduces bugs in the old functionality or that doesn't work. You can decide on partial functionality but not a partially implemented server. Every release must be tested and will optimally have new features even if the features are simplified versions. You will be graded on how many release dates you hit with new features.
  2. You will be given more work than can possibly be done in the allocated time period. You will need to prioritize the tasks and then decide which you will do, which you will simplify, and which you will not do. You may suggest alternative features or modified features. You may suggest that the instructor is nuts and a feature cannot be implemented. Your project management skills will be evaluated in this manner and will affect your grade.
  3. The project requirements and feature set will change during the semester in ways that will force fundamental changes in your software. You must learn to balance speed of coding with flexibility. Your ability to anticipate change in your code by making it flexible and your ability to refactor existing code will be evaluated.
  4. You may discuss the project but you may not share code. The other students are your "competitors" in the sense that your project is graded in comparison with the other students to get beyond the B grade level into the A range.
In summary, we will simulate a piece of in the real world: you have to constantly juggle releases with new coding, you always have too much to do and have to economize, the target changes constantly.

There are general definitions of C and B level work that must be completed to achieve those grades on the semester project. To get an A, you must impress me with your ability to code and do significant work beyond the B work in comparison to other projects.

The authors of the two best projects in the class will be excused from exam II. :)

The big project will be graded while you demonstrate your software in front of the instructor.

By definition, there is no late project--your last working release will be considered in lieu of any unfinished project. Missing a release in order to achieve a better result at the next release is acceptable once or twice, but remember missing all releases to turn in a finished project in December will yield a poor score.


Tardiness. All classes begin precisely at 3:30pm and will restart after the 10 minute break exactly on time.

Academic honesty. You must abide by the copyright laws of the United States and academic honesty policies of USF. If told you may for a particular project, use any code from the net that you find as long as it does not violate the software's license. You may not borrow code from other current or previous students. All suspicious activity will be investigated and, if warranted, passed to the Dean of Sciences for action.