MCS-270: Object-Oriented Software Development (Spring 2004)


The first half of this class (until Spring break) will be a crash course in object-oriented software development. For the second half (after Spring break), you will work in teams to develop custom software for clients. In the first half, our main focus will be on object-oriented analysis and design, which will be covered using the primary text. I'll be adding some additional analysis and design material, particularly regarding invariants. Also, I'll be slipping in some material on implementation technologies commonly used in modern "client/server" or "three tier" systems. Specifically, we'll look at relational databases, accessed using SQL, which can be done in Java using JDBC, and at communication with remote objects, which we'll do in Java using RMI.

Reaching me

All office, phone and schedule information will be maintained on my web page I'll try to keep it updated with any temporary changes to my schedule as well. In short, if my office door is open you are welcome; if I'm busy, we'll set up an appointment. Email and phone calls work, too.

All course handouts will be available through my World Wide Web page, and some supplementary materials such as code to use as a starting point in assignments may be available there as well. The URL for this course is


Our text will be Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (second edition) by Craig Larman (Prentice Hall, 2002). For those wishing to buy books tied to the programming side of the course (rather than just relying on the web and books owned by the department or myself), you might consider purchasing The Java Tutorial, Third Edition and The Java Tutorial Continued by Campione, Walrath, and Huml (Addison-Wesley, 2000) as supplemental texts. Since I am not having the Bookmark order these, you should check your favorite bookstore (online or otherwise).


Attendance is mandatory for all lab sessions, unless you have already turned in your lab report. There will be four labs, as shown in the class schedule. They will all involve concrete experiential work, but not necessarily seated in front of a computer. Each lab has a class day or two set aside for us to work together, but will also require you to spend additional time out of class.

Similarly, I expect you to show up regularly for the classes, since they will involve discussion and material from the book. In the second half of the course, your project team's weekly meeting with me will be covered under this attendance policy. I reserve the right to reduce your grade as I see fit for habitual lateness and non-attendance.


I will provide you with a letter grade on each lab assignment, test, and project report, in addition to the mid-term and final grades, so that you may keep track of your performance. As a guideline, the components will contribute in the following proportion to the final grade: However, I reserve the right to subjectively adjust your final grade. Please see me if you have any question how you stand. Class participation is not graded; however, it allows you to find and repair the gaps in your understanding before doing the homework or exam, and thus can dramatically improve your grade.

There will be one test, towards the end of the first half of the semester. It will be in-class, individual work, closed book and mostly closed notes, though one handwritten sheet of notes will be allowed. (Up to 8.5 by 11 inches, both sides of the sheet allowed.)

For the major team project in the second half of the semester, I will grade you in accordance with the goals you establish for yourselves. It is up to you to decide what the deliverables of your team are, subject to my general approval. If you decide that all there is going to be is a working program at the end of the semester, then that is what you will be graded on -- all or nothing. If, on the other hand, you establish a timetable in which there are other deliverables scheduled along the way -- such as a requirements document, one or more design documents, an interface mock-up, a web page of information for users, a suite of test cases, etc. -- then you will be graded on each of them, and you will have less of an "all the eggs in one basket" problem. But it is really up to you. Similarly, my default mode of grading will be to give the same grade to all members of the team. However, if you establish specific assignments of responsibility, then I will grade each team member on those items he or she is responsible for (as well as including a common grade portion for those items not assigned). Each portion of the project for which an individual is assigned responsibility needs some mechanism for separate assessment. For example, if someone has responsibility for programming a module, then that person must show test results for that module in isolation in order to show that it works, rather than just combining it with all the other modules and leaving it to me to figure out which ones work and which don't.

You will be permitted to hand in one lab assignment up to 72 hours late; any more late will be heavily penalized. (This very liberal policy is intended to accommodate illness or conflict. Please do not ask for additional exceptions unless your situation is unusual.)

Please point out any arithmetic or clerical error I make in grading, and I will gladly fix it. You may also request reconsideration if I have been especially unjust.

Style guidelines

All lab reports should be readily readable, and should not presuppose that I already know what you are trying to say. Use full English sentences where appropriate (namely almost everywhere) and clear diagrams, programs, etc. Remember that your goal is to communicate clearly, and that the appearance of these technical items plays a role in this communication process. Be sure your assignments are always stapled together and that your name is always on them.


Please contact me immediately if you have a learning or physical disability requiring accommodation.