Information about quizzes and exams Now including the FINAL EXAM.
ASSIGNMENTS Final project, due midnight Thurs, May 31st.
Addition of 5/16/01 Source code - including Base-Connection and Iterators
Javadoc -- Automation of APIs for your code
[version of May 30, 2001]
COM1204 -- Object-Oriented Design -- Spring 2001
College of Computer Science, Northeastern University
Professor Robert P. Futrelle
Important note on what we'll be doing to finish up this quarter (5/13/01)
After the Midterm, we will concentrate exclusively on the Project design and implementation. The students, Professor Futrelle and Ms. Shan all need to focus all their course time on the projects in an effort to bring it all to a proper conclusion. There will be no additional material from the book to study. I will update the Syllabus to reflect this schedule. But there may be aspects of the Java language that arise as we study the system design and implementations that you are doing. I will go over these and hold you responsible for them in your coding and especially, on the Final Exam. There will be a Final Exam. Sadly, there are students who get fairly far through their CCS major with little experience and skill in writing programs. This simply won't do. It is vitally important that you be able to sit down with a piece of paper in front of you and write basic code in at least one computer language. You need to be able to read and understand code too. After the Midterm on the 17th, there are only two weeks of classes left, five class meetings (Monday the 28th is the Memorial Day holiday). This is the time period in which you can focus exclusively on your project. It will be important for you to come to these last five classes, where you'll learn about aspects of Java you'll need to know as well as final guidelines for your project work as well as details about the Final exam.
This course follows the College's first year courses covering the basics of programming as well as an introduction to data structures and algorithms. With those behind them, students in this course, COM1204, can begin to focus on the problems of designing and implementing programs in a more orderly way, working up to the construction of large programs. We will be using Java on Unix systems for this course. We have an excellent textbook. To complement the text and give us hands-on experience, the class will be divided into four groups, each of which will design and implement a cell-phone simulation. The groups will further divide into subgroups of two or three people developing the details of the basic modules that model: The phone user, the phone, the "ether" that carries the messages, the base station that handles multiple phones, and the simulation that drives the other modules.
The textbook: We are lucky to have available and to use in this course a concise and intelligent textbook, Program Development in Java -- Abstraction, Specification, and Object-Oriented Design by Barbara Liskov and John Guttag (Addison-Wesley, 2001). Professors Liskov and Guttag at MIT are recognized authorities in the field of programming languages. As part of your assignments, you will be reading this entire book. That will mean reading about 50 pages per week(!) You probably have never done or were required to do, this much reading in any technical text. You will find it an interesting experience and it will help you prepare for the future, in which books about the newest CS technology will continue to come out at a furious rate and you'll need to read them to keep up with your profession (or even just to keep your job).
The programming project -- cell phone simulations: The book is meaty and will help us think hard and deeply about program development. At the same time, it is full of useful examples and good advice about the development process. But in addition, it's important to have something concrete and substantial to work on, to actually develop our own programs in interesting problem areas. To this end, I have chosen the simulation of a wireless phone system (cell phones) as the major programming project for the course. In designing complex systems, and cell phone networks are just one example, it is quite common to simulate the system to discover how well it will work and what needs to be done to assure that the system will work well under heavy loads and other difficult conditions. It is also quite common for CS people to be involved in projects in which they have to learn something about an application domain area outside of CS. Learning some wireless basics is an example of this. (I personally know one NU CCS graduate who's employed in the financial industry developing software for cell-phone / PDA systems.)
"Phone companies": Because cell phone systems divide naturally into collections of distinct components, it is natural to build the simulation software itself as a collection of interacting modules. For example, the cell phones, the base stations, the signals being exchanged and even the software component that "runs" the entire simulation can be developed independently. It follows very naturally from this to divide the class into groups and subgroups, each of which works on a particular module, while making sure that their module interacts correctly with the others. This is very much in line with the way all large software packages in industry are (and must be) built. This is why the class will be divided into four groups -- imagine that they are four "phone companies". Within each group, the five subgroups will work on the modules mentioned earlier: users, phones, ether, base station, and simulation. And have fun naming your new companies, designing their logos or T-shirts or whatever!
Synching the book and the project: It is simply not logically possible to keep the work based on the book and the design and programming project in synch. There will always be work on one that is not reflected in the other. But by the end of the course, all this should come together, because the entire collection of material in the book will reflect the entire collection of problems that we will face and solve in the projects.
How cell phones work: Real cell phone systems are quite complex and involve many complicated signals and concerns about radio wave signal strengths, noise and interference. We will ignore much of this complexity, yet still be able to simulate a working system. I will explain the basics of cell phone technology, our "application domain", early in the course.
Java, Unix and the project organization: One of the major products of the design process are fully described APIs for the various modules (application programming interfaces). The Java platform makes it very easy to build the documentation because the Java tool, javadoc, will turn your properly written comments in to full sets of linked web pages. Thus, the subgroup designing the phone can generate an API description using Javadoc and the designer of the simulated user will know that if they call the functions described in the phone API, they will work as advertised, e.g., initiateCall(int phoneNumber). In addition, each subgroup will need access to working code from the other groups so they can test their modules. To coordinate all this a system that allows easy posting of web pages and easy transfer of source and compiled files among users. Unix, as currently set up in CCS, is ideal for this sort of collaboration. (Some day in the future, the PCs will presumably have shared file systems and logins, etc., but that has not come about yet.) So everyone in the class will have to be using our Unix systems, though not in particularly sophisticated ways. Everyone in the class will need a CCS login. If you do not have such a user account, get one immediately. Another advantage of Unix is that you can access the systems from dorms or off-campus to do your work.
Web resources: The book is pretty self-contained, but the project involves a variety of things including unix files and editing, Java compilation and execution, and web pages. To help on all these topics, I will provide a number of web pages for you to use. And I'm always open to suggestions as to other web pages that you think would help other students in these areas.
Your grades: Because it is very difficult to figure out just who to reward for a job well done in a large collaborative programming project, I will rely most heavily on written tests for evaluating your understanding of object-oriented design. This will require you to design code and analyze software design on paper. And after all, good design does mean doing good work on paper, not just sitting down and hacking something together at the keyboard. Your projects should be available for grading electronically, though we will ask you to hand in some material in hardcopy, so we can make comments on your work on the hardcopies.
This course is designed to be educational, interesting, and hopefully fun! It is not designed to be easy, but the hard work required should pay off by substantially adding to your knowledge and skills in computer science.
-- Professor Futrelle