CMSC 202, Spring 2002 -- Syllabus

Textbook

C++ How To Program, Third Edition by Deitel and Deitel, Prentice Hall Publishing

Course Description

This course continues the development of programming and problem-solving skills, focusing on recursion, pointers, data abstraction, and procedural abstraction. Topics include: recursion, introduction to asymptotic notation and analysis; data structures including lists, stacks, queues, hash tables and elementary binary search trees; sorting and searching; and an introduction to the C++ language and to object-oriented programming. Programming projects for this course will use the C++ programming language. Prerequisites: CMSC 201 and MATH 151.

CMSC Gateway

For students who enrolled in college for the first time in Summer 1998 or later, you have two choices: pass both of CMSC 201 and CMSC 202 with a grade of B or better or don't graduate as a CMSC major. The registrar has very specific rules about repeating courses in sequence; for example, if you were to have a C in 201 and then take and pass 202 expecting to retake 201, you can't. Since the classes form a sequence, you cannot retake an earlier class in the sequence once you've passed a later one. Also, note that all University deadlines (for adding or dropping courses, changing grading method, etc.) will be strictly enforced, so make sure you are familiar with these.

Objectives

The objectives of this course are:

To learn and practice problem solving techniques
To practice and understand recursion
To learn to understand algorithm efficiency in terms of asymptotic analysis
To master some basic data structures, including: linked lists, stacks, queues and binary search trees.
To understand the fundamental programming concepts of abstract data types, recursion, memory allocation and functional parameters.
To gain familiarity with basic algorithms for sorting, including binary search, Merge Sort and Quicksort.
To learn programming in C++ and object-oriented programming.

Section Independence

Note that Ms. Benincasa's sections and Ms. Mitchell's sections are completely independent. Although both sections will cover the same topics throughout the course of the semester, those topics will be covered in a different order, using different lectures, different notes, and different textbook readings. In addition, the projects used for the two sections will be completely independent, as will all exams. Therefore, you may not attend one instructor's lecture as a substitute for the other, nor can you attend one instructor's discussion section as a substitute for the other. This also means that staff for one section will not be able to assist you with projects or exams from the other section.

Lectures and Readings

You are expected to attend all lectures and discussions for the section in which you are enrolled. Although both classes will cover the same general topics, you are responsible for the specifics given during your section. You are expected to attend all discussion sections, and you are responsible for all material presented there.

You are expected to attend all lectures and your weekly discussion session. You are responsible for all material covered in class, even if it is not in the textbook. You are responsible for all material in the readings, even if it is not covered during class. If you should happen to miss a lecture or a discussion, you are responsible for getting any missed notes or announcements from a classmate.

Assignments and Grading

Grading Criteria

Your grade in this course is based on projects (which will include design assignments) and exams, which are discussed in more detail below. The grades are broken down as follows: 2 Midterms (15% each) = 30% 1 Final Exam = 20% 5 Projects (10% each) = 50%
Note: The 10% for each project is made up of both the grade for your source code and the grade for the design you submit.

Letter grades will follow the standard scale: 0 <= F < 60, 60 <= D < 70, 70 <= C < 80, 80 <= B < 90, 90 <= A <= 100 Your grade is based on timely work accomplished during the semester; incomplete grades will only be given for medical illness or other such dire circumstances.

Project grades will be mailed to your UMBC email account. Midterm exams will be returned to you either in lecture or in discussion. After each grade is returned, there is a grace period of one (1) week during which you may speak to your instructor about any problems you have with your grade. After that time, your grade will stand. If you wish to discuss your grade on any project or exam, you must see your instructor. No one else has the authority to discuss your grade with you.

Projects

The critical programming skills cannot be learned simply by attending the lectures. You should budget enough time to work on the projects as well. Projects are due by midnight of the due date. If you fail to turn in a project on time, a late penalty will be assessed (even if it's only one second late -- no excuses, no exceptions). Note: your entire project is considered to be submitted at the latest time any file for the project is submitted. Projects are accepted up to 48 hours past the due date; there is a 10% penalty for up to 24 hours late and a 25% penalty for 24-48 hours late. After 48 hours, no project submissions will be accepted -- no exceptions. Therefore, make sure to allow ample time for debugging your projects.

There will be five graded projects, as discussed above. Each project will also include a design assignment, as described below, to be worth a variable amount of each project grade. In addition, Project 0 is a mandatory ungraded project. The purpose of Project 0 is NOT to make sure you know how to use the submission system, but rather to make sure that the submission system is prepared to accept projects from your account. If you fail to submit Project 0, no future project submissions will be possible and your grade for those projects (which ARE graded) will suffer.

Network and computer failures at UMBC are a fact of life. They are out of your control and out of our control. However, they are not an excuse for a project to be submitted late, nor are they a reason for project deadlines to be extended, even if the outage occurs on the due date. Plan accordingly. Waiting to submit your project until 5 minutes before your project is due is a recipe for disaster. In the event of network outages or computer failures that last less than two weeks, you are still responsible for submitting your projects on time. There are labs on campus even if your dialup or ResNet connections are down. Also, it is your responsibility to take care of any problems with your account, such as quota overages, which interfere with your ability to complete and submit projects for the course. Project extensions will not be given for such problems.

Makefiles

Every project must be submitted with a makefile. It is to be named either makefile or Makefile (your choice). No other names are acceptable for your makefile. The grader will compile your submitted project by typing 'make', so your makefile must correctly make your project. This includes correct naming of the executable; the executable file produced for Project n must be named projn ; no other names for the executable are acceptable.
A number of tutorials on makefiles are available. One is the UCS tutorial. Another is an excerpt from the GNU tutorial.

Project Compilation

All projects must compile and link on UMBC's Linux system. To ensure you are accessing Linux, log on to linux.gl.umbc.edu. Do not develop your projects on the Irix machines (irix.gl.umbc.edu); different compilers are installed on the two systems, and what compiles on one may not compile on the other.
Please note that there are two g++ compilers on the Linux system. One compiler is located in the directory /usr/local/bin; the other is located in /usr/bin. All students must use the g++ compiler in /usr/local/bin. You should do the following to avoid using the wrong compiler:

In your project makefiles, explicitly specify the compiler as /usr/local/bin/g++ rather than simply as g++. Failure to do so will result in a point deduction on your project.
Modify your .cshrc file (found in your home directory -- note the leading dot) in one of the following ways:
Create an alias for g++ by adding the following line near the bottom of your file:
alias g++ /usr/local/bin/g++ (this is the easiest thing to do).

Modify your path environment variable to look in /usr/local/bin before it looks in /usr/bin .

To check that you are using the correct g++ compiler, execute the command which g++. The response should be /usr/local/bin/g++ .
Further, the compiler switches -ansi and -Wall must be used when compiling. These must be included in your makefile rules (failure to do so will also result in a point deduction on your project) and used whenever you compile "by hand".

Design Assignments

One part of each project will be a design description. The purpose of this is to spend some time thinking about the design of your project before actually implementing it. Generally, the design for a project will be due a week before the project itself. You will be graded not only on the merits of your design, but on whether or not you actually follow your design in the implementation of the project. Designs will be submitted electronically just like source code files; late designs are not accepted. More details will be provided with the first project assignment.

Exams

There will be three (3) exams -- two midterm exams worth 15% each and the final exam worth 20%. (Note that the last exam is given during the scheduled final exam time for the class.) Make-ups for exams are given under only the most dire circumstances (such as hospitalization). Exams must be taken with your lecture session.

Midterm exams are not cumulative; the final exam is cumulative. Note that you may be required to use skills from earlier in the semester (or even a previous course) while solving problems on an exam, but each midterm exam will focus on material that has not been tested on previous exams.

Unless otherwise noted, all exams are closed-book, closed-notes. Sample questions are not provided for CMSC 202 exams (as they are with CMSC 201 exams).

Academic Conduct Policies

All projects must be completed by your own individual effort. You should never have a copy of someone else's project either on paper or electronically under any circumstance. Also, you should never give a copy of your project, either on paper or electronically, to another student. This also means that you cannot "work" on the project together. Cases of academic dishonesty will be dealt with severely.

If you need help with your project, see your instructor, your TA, the Computer Science Help Center (room ECS 332), or tutors provided by the Learning Resource Center. We also encourage you to consult your textbook and the course web pages.

Having someone else's project in your possession, even briefly, is forbidden. Safeguard your account password; you are responsible for the actions of anyone else you may allow to log into your account.
Safeguard hard copies of your programs; excuses such as "I must have left a copy of my code in the lab where someone else must have found it" will not be accepted.

Your project will be checked for similarities with all other student projects. If your project is found to be "substantially similar" to that of another student, or if it is determined that someone else wrote your project for you, both you and the other student (if applicable) will receive a grade of 0 for that project. Furthermore, all parties concerned will have their prior projects re-checked for cheating. Any second incident will result in a grade of 'F' for the semester. Also, checking for cheating may occur at any time during the semester. Therefore, if you cheated on Project 1, you may be confronted about that at any time; receiving a grade for a project does not mean you are "in the clear".

Any act of dishonesty may be reported to the University's Academic Conduct Committee for further action, which may include, but is not limited to, academic suspension or dismissal from the university.

Email Policies

Email is great -- much better than voice mail. If you need to contact your instructor about this class outside of lecture and office hours, email is much better than the telephone. You should, however, observe the following etiquette:

Email is good for lots of things, but it is horrible for debugging. Instead, if possible, use your instructor's office hours, the TAs' office hours or the Help Center for debugging help.
When you send an email to your instructor, your instructor will reply to the address from which the email was sent.
When your instructor wishes to initiate an email to you, it will be sent to your UMBC gl account. Therefore, you should check your email at that account on a regular basis, as it will be used when necessary to communicate with the class outside of normal lecture time.
Use your real name. Email from "Hot Stuff" gets deleted without being read.
Use only the email addresses listed under "Staff Contact Information". Mail sent to any other addresses may not be read.
Include your name and section number in all email correspondence with course staff.
Include a meaningful subject line, something like "CMSC 202 Project 2 question". Your instructor teaches more than one course, so don't just refer to a project number.
Send email in text format only (no HTML, MS Word attachments, etc.)
Know the difference between "reply" and "reply to all".

In addition, due to the volume of student email during each semester, please note the following:

Do not expect responses during holidays or weekends, late in the evening, or on the evening a project is due.
Do not expect an immediate response to your mail. As a rule of thumb, expect two business days turnaround time. This means ask your project questions WELL BEFORE the due date, if you expect an answer in time to help you.
Do not wait to submit a project because you are waiting for a response to your email. Once you receive a response, you can resubmit an updated version of your project if you so choose (subject to the late penalties and policies outlined above).