CS 350 Section 701 Winter 2001/02

Overview:

This course is about good object oriented design and implementation. In the challenging projects that programmers face, the design stage is where the primary difficulties of programming are worked out. Implementation - the task of turning a design into a working program in a working programming language, is supposed to be very straight forward given a good design. Object oriented programming (OOP) allows for more robust code --- programming that is easier to reuse and easier to extend and maintain over a life cycle of usage. However, this power is achieved at the cost of making the program designer's task more complicated, due to the richness, subtlety and peculiar limitations of OO classes and class inheritance. A major objective of this course is to bring students to a level of competency in OO design so that they can handle team or individual projects of moderate complexity, such as those in CS451 (Software Engineering). Design skills include: the ability to decide which classes would be appropriate given only a problem specification, designing for ease of future code maintenance, being able to decide upon details of classes from a problem specification, finding well-known "software patterns" from typical problem specifications, and being able to communicate both static and dynamic aspects of designs using the Unified Modeling Language (UML). Design skills are applicable to any of the OO languages in vogue (e.g. C++, Eiffel, Java). Another object of this course is to make you confident and competent at implementing an OO design of moderate complexity, using coding techniques based upon generally recognized software engineering principles. Reasonable competence in C++ implementation includes a bit more than you may have gotten in CS 171/172 (or their equivalent). We will cover additional features of C++ that are important in object-oriented programming: abstract classes, virtual functions, templates, exception handling, etc, as well as coding and testing practices (e.g. naming conventions for classes, variables, constants, and files, pre-conditions, what thorough testing means, etc.). Many of these features can be found in other OO languages. A final objective of this course is to make you a conscious designer. By learning about and practicing with design and quality rationales the course will present, you are expected to be able to state, explain, judge, and justify design or implementation decisions in a way that would be generally acceptable among (at least) entry-level computing professionals

Your feedback:

If you have any suggestions/questions about the course please let me know through email. You feedback and criticism is welcomed. You are encouraged to ask questions during the lectures.

Class Description:

Instructor: / Anatoly Khusid
Office Hours: / By appointment only & before class
Email: /
MailBox: / College of Prof. and Evening Studies.
Class Webpage / http://www.mcs.drexel.edu/~gakhusid/mcs350/
Class Location: / TBA
Days & Times: / Tue 7:00 - 9:50pm
Credits: / 3.00

Tutors/Help:

In this course a lot of work is expected to be done on your own. Office hours are limited, and might not be enough to answer all your questions. Therefore, seek help early, before you fall to far behind. I encourage you to use MCS Korman Tutoring Center extensively for any help that you might need.

Pre - requisites:

We expect that all taking this class has had MCS 171/172 (Programming I and II) as well as MCS260 (Data structures) or their equivalent. The experience in these courses includes the design and implementation of at least fifteen programs in C++, including several that involve the use of classes, pointers, and dynamic storage allocation. The experience in writing these programs is also expected to have given you knowledge of basic coding practices such as: good selection of names, good quality commenting and indentation, good separation of code into separate files (e.g. appropriate use of .h files), what constitutes appropriate selection of test data, and how to develop a program incrementally (e.g. use of program stubs as placeholders for as-yet unwritten program modules). Experience with recursive programming design and implementation is also expected, as well as experience with the C++ standard template library (STL). Some assignments will assume that you find it routine to implement data structures such as trees or linked lists with the use of pointers. Some assignments will ask that you will be able to design and implement algorithms to solve simple problems on your own, without extensive hints or outside help. This will probably require a bit more mental effort on your part than many assignments from previous courses, in that you will have to devise the solution algorithm yourself based upon your prior experience with programming problem solutions. You can use the first programming assignment as an indication of what you are expected to have started with. If you have questions, please consult with the instructor.

I will assume that:

·  You know how to create, debug, compile and run C++ code

·  You have account on MCS Unix machine queen. During the first lecture I will collect the names of people who do not yet have an account. System Administrator should create your account.

·  You know and are currently using a reasonable and clear programming style

·  You have solid/working knowledge of C++ programming.

Unix

Homework will be submitted for test execution on the MCS Solaris (Unix) systems, so familiarity with Unix (as with MCS 390, Unix Programming Environment) is something that you should acquire if you don't already have it. You can do so by purchasing any good book on Unix (e.g. Unix for the Impatient by Abrahams and Larson, 864 pages 2nd edition (September 1, 1996) Addison-Wesley Pub Co; ISBN: 0201823764), through friends, or through web sites such as http://cslibrary.stanford.edu/107. We shall not be covering Unix usage in lecture but you may ask the instructor or consultants during office hours if you have questions about this. Every one enrolled in this course is entitled to an MCS Unix account if they do not already have one. Programming assignments will be tested to work with the Sun C++ compiler (CC, not gcc). You will not receive credit for correctness if your program fails to compile and execute correctly on the Sun platform with this compiler. Students from prior offerings of this course will tell you that often times additional bugs are often found from the attempt to port a program from a PC (Linux or Windows) environment to Solaris, or even between the gnu and Sun compilers on the MCS computers. If you do not have a high-speed connection to the MCS systems it is probably most expedient to do most of your development on your personal computer, but it is still your responsibility to have the program work correctly with the reference computer and compiler. Leave enough time before the assignment deadline to do the port.

Handing in Assignments

Assignments will be made available on the class web pages, and will be due as specified in each assignment. Grading scheme and criteria will also be specified in each assignment. There will be at least 4-5 programming assignments during the quarter, due at two-week intervals. The programming assignments will be done in C++ on the MCS departmental Suns. Please refer to "Handing in Assignments" (http://www.mcs.drexel.edu/~gakhusid/mcs350/projects.html) section for more instructions on how to hand in programming projects. There will also be a written work that should be submitted as specified in the assignment. Some assignments you will be asked to submit on paper to the instructor at the beginning of the class. Others you will be asked to submit electronically. When assignments call for written responses, they should be created using a text processor, written in intelligible, clear and correct English. Poorly written or sloppy work will be returned upgraded. Bring all paperwork not submitted electronically to class to hand in to the instructor. The paperwork, that is not submitted electronically, is due in class ONLY. No late penalty applies for paperwork that is due in class. Please refer to "Lateness and Absence" policy for this course for more information.

Course Objective


In this course you will learn:

·  To understand the need for Objects and Classes.

·  To understand the concepts of Object Oriented Design, its need, benefits, and applicability.

·  To design using Inheritance, as well as being able to implement it using C++

·  Polymorphism and Abstract classes.

·  To learn Design Notations using UML.

·  Binding, Visibility, Scope and Access Control

·  Operator overloading

·  Persistence

·  Exception Handling

·  Reuse of software design utilizing C++ templates and software patterns.

*For more detailed schedule, please refer to "Calendar/Notes" (http://www.mcs.drexel.edu/~gakhusid/mcs350/notes.html) section.

Text:
Required:

·  A Practical Introduction to Software Design With C++ (Worldwide Series in Computer Science) by Steven P. Reiss (September 1998) John Wiley & Sons; ISBN: 0471242136.

·  UML Toolkit by Hans-Erik Eriksson, Magnus Penker 397 pages. Bk&Cd-Rom edition (October 1997) John Wiley & Sons; ISBN: 0471191612


Recommended:

I really wanted to make these books required, but due to the overwhelming costs, I am making them recommended. Even though, most of the material presented in these books will be outlined in my notes, I strongly recommend that you have access to these books.

·  The C++ Programming Language, by Bjarne Stroustrup 3rd edition (July 1997 ). Addison-Wesley Pub Co; ISBN: 0201889544. Any other comprehensive guide to C++ will do. Not all textbooks cover all of the fine details of the language; all would-be professional programmers will want a book that is definitive and comprehensive.

·  UML Distilled (2nd edition): Applying the Standard Object Modeling Language by: Martin Fowler, Kendall Scott. Addison-Wesley. ISBN: 0-201-32563-2 pages: 208 ) 1997

·  Design Patterns : Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 395 pages (October 1994) Addison-Wesley Pub Co; ISBN: 0201633612

Grading:

Design Patterns Presentation: / 5%
Programming Projects / 40%
Mid-Term Exam: / 25%
Final Exam: / 25%
Quizzes, Attendance & Participation: / 5%

Examinations:

Midterm and Final exams will be in class and closed books. Midterm and final exam makeups must be arranged at least one week in advance, barring extreme situations.

Lateness and Absence:

You may turn in programming projects up to two days late (via email only), with a 20% grade penalty. You must turn in the paperwork on time in class only. Paperwork is something that you are asked to submit along with your project. The paperwork will typically include design diagrams. There is no late policy for the paperwork, it is due ONLY in class, otherwise grade 0 is assigned. Midterm and final exam makeups must be arranged at least one week in advance, again barring extreme situations.

Withdrawing from the course:

You may drop the course up to the last day of the sixth week of class and you do need to ask me for the permission. If you do not drop the class by then, you will receive a grade for the course!

Class Participation:

Part of your grade is based upon being present and having good quality participation in the class discussion. Some times the instructor will call upon people while at other times he may choose among only those who wish to speak up. It is not necessary to answer all questions correctly or speak up every day to receive a passing grade for participation, but you need to establish in the instructor's mind that you are typically prepared and can respond capably.

Academic Integrity:

You must be the sole original author of all assignments and examination solutions in their entirety, unless the instructor explicitly gives you permission to do otherwise in written directions on an assignment or exam. Design and implementation problems should be discussed with the instructor or the consultants only. This means that you should have an implementation plan that leaves enough time for such consultation. As the university's policy explains, penalties up to and including a failing grade for the course with no opportunity to withdraw, will be given for plagiarism, fabrication, or cheating. The standards for originality in a program are similar to those of other written works. Programs by different authors show clear and substantial differences as judged by most criteria, including but not limited to: choice of variable and procedure names, line spacing and indentation, choice of program structure, choice of algorithms, ordering of modules, style and content of documentation, module design, and ordering and choice of instructions. The original author of an assignment can explain each detail and how they came to create it on their own. It is your responsibility to avoid violating the university's policy. If you are unclear as to what the policy means in a particular situation, ask the instructor for clarification before you hand anything in. Students are encouraged to work together to understand the concepts of the course, but they are required to submit only their own work on homeworks, assignments and exams. For example, this means that code and text answers may not be shared, copied, jointly developed, peeked at, stolen, clairvoyantly perceived, retrieved from wastebaskets or retrieved from files of old assignments. When you hand something in, you affirm that it has been produced by you alone. A false affirmation is a serious breach of academic integrity and may result in failure in the course and referral to the Office of Judicial Affairs, as provided for in the university's Student Handbook. Students who make their work available to others to copy will also be liable for these penalties; hence you should be careful to keep your homework files protected