CS601/CS342: Object-Oriented Software Development
Last updated: August 28, 2008
Fall 2008
Tues/Thur: 3:30-5:15pm HRN 235
Instructor: Terence Parr
Office hours: Any time door is open or by appointment
TA: Leon Su, leonsu at msn dot com
Midterm exam: , 2008
Last day of class: Tuesday December 9, 2008
Final exam: Wednesday, December 17; 12:00 PM
This course is cross-listed as both CS601 and CS342;
undergraduates and graduate students will be evaluated and graded on
different scales.
Abstract
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
- have a firm grasp of structured programming, polymorphism,
encapsulation, and data-hinding.
- be comfortable developing and deploying software on Linux.
- know how to use perforce to manage software revisions.
- be familiar with sockets, web related protocols, and techniques related to
building servers.
- be able to generate web pages with a strict separation of code/data.
- be able to create database tables and write moderately complicated
SQL queries.
- understand the issues associated with multithreaded servers.
- have built a large server in Java and be able to use
sessions/cookies to interact with server clients
- be able to explain the concepts and benefits of the following
software development techniques:
- Programming "by contract"
- Aspect-oriented programming
- Extreme programming
- Refactoring
- Design patterns
- know how to use jUnit and know the principles of testing and
building robust software.
- be able to recognize poorly structured code
Syllabus
Lab topics
OO principles worksheet
UNIX
Perforce
unit testing with jUnit
Sockets
Threads
Data structures
Recursion worksheet
Databases
Web servers
HTML page generation
Servlets cookies sessions
POP / SMTP
Parsing
Build / deployment / test box
|
Lecture/Discussion topics
Technology
Optional: crash course on Java
Optional: Java I/O, collections
Open-source, patents, licensing; copyrights/patents
Top-down design
Object-oriented design
Threads
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
Refactoring
Testing, robustness
Design patterns
jGuru case study
Dealing with the complexities of team interactions
|
Lectures notes
Labs
Java I/O
Sockets
Perforce Revision Control
Multi-Programmer Perforce Revision Control
StringTemplate
Worksheets
Object-Oriented Principles Worksheet
Java I/O Worksheet
Sockets / Networking Worksheet
Servlets
Cookies, Sessions
Mini-projects
Building Dictionary Implementations (Due Sept 9)
Expression Evaluator (Due Sept 18)
Building Unit Tests (Due Sept 25)
Modifying existing source code (Due Oct 7)
HTTP Server (Due Oct 21)
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 - Nov 4
Release II - Nov 18
Release III - Dec 9 (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.
Grading
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 |
| 15% | Exam 2 |
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.
Resources
Books
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:
- Mythical Man Month
- Extreme programming explained
- Refactoring by Fowler
- Any Java book
- Java in a Nutshell
- Object-Oriented Software Development in Java:
Principles, Patterns, and Frameworks by Jia
- or, Book you currently own
- Any Dilbert book
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:
http://cs.usfca.edu/mailman/listinfo/cs601.
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:
-
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.
-
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.
-
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.
-
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. :)
Submission
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.
Miscellaneous
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.