Introduction to Com S 362 --------------------------- Course description from ISU Catalog: Com S 362. Object-Oriented Analysis and Design. (3-0) Cr. 3. F.S. Prereq: 228 with C- or better, Engl 150. Object-oriented requirements analysis and systems design. Design notations such as the Unifed Modeling Language. Design Patterns. Group design and programming with large programming projects. Nonmajor graduate credit. Course Details: Class web pages: http://www.cs.iastate.edu/~cs362 Meeting hours: MWF 11:00 - 11:50am Meeting venue: Atanasoff B0029 Instructor: Hridesh Rajan Instructor's E-mail: hridesh@cs.iastate.edu TA: Tyler Sondag TA's E-mail: sondag@cs.iastate.edu Some Important Dates: Mid-Term: Wednesday Oct 10, 11:00 - 11:50am Final Exam: Tuesday Dec 11, 9:45 - 11:45am Final Project Presentation: Wed Dec 5 & Fri Dec 7, 11:00 - 11:50am Required text books and articles for this course: Books: [Arnold05] Ken Arnold and James Gosling and David Holmes. The Java Programming Language Fourth Edition. Addison-Wesley, Reading, Mass., 2005, ISBN 032134980. [Gamma95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Boston, MA, 1995. ISBN 0201633612. [Baldwin and Clark] Baldwin, C. Y. and Clark, K. B. 1999 Design Rules: the Power of Modularity Volume 1. MIT Press. We will only use chapters 2 and 3 from this book, which is available at the library as reserve in an electronic form. [Fowler99] Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Roberts "Refactoring: Improving the Design of Existing Code", Addison Wesley Professional, 1999. We will only use chapter 1, which is available at the library as reserve in an electronic form. [Brown98] William J. Brown, Raphael C. Malveau, Thomas J. Mowbray. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, Wiley, First Edition 1998. We will only use chapter 5, which is available at the library as reserve in an electronic form. Articles: [RZF 94] Sridhar Raghavan, Gregory Zelesnik, and Gary Ford, Introduction to Requirements Elicitation, Software Engineering Institute, CMU, 1994. [Dijkstra 82] Dijkstra, E. W. (1982), On the role of scientific thought, in `Selected Writings on Computing: A Personal Perspective', Springer-Verlag, pp. 60--66. [Parnas 72] Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058. [Liskov and Zilles] Liskov, B. and Zilles, S. 1974. Programming with abstract data types. In Proceedings of the ACM SIGPLAN Symposium on Very High Level Languages (Santa Monica, California, United States, March 28 - 29, 1974). ACM Press, New York, NY, 50-59. [Beck and Cunningham] Beck, K. and Cunningham, W. 1989. A laboratory for teaching object oriented thinking. In Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications (New Orleans, Louisiana, United States, October 02 - 06, 1989). OOPSLA '89. ACM Press, New York, NY, 1-6. [Garlan and Shaw] Garlan, D. and Shaw, M. 1994 An Introduction to Software Architecture. Technical Report. UMI Order Number: CS-94-166., Carnegie Mellon University. [Meyer 92] Meyer, B. 1992. Applying "Design by Contract". Computer 25, 10 (Oct. 1992), 40-51. Syllabus and Approximate Timeline: The approximate timeline and the topics that will be covered in this class are as follows. This schedule will become more concrete as the semester progresses. Schedule updates will be announced via e-mail to the students. They will also be published on the course web site. * Review of Object-oriented programming * Review of Unified Modeling Language (UML) * Design principles: separation of concerns, information hiding, design rules, etc. * Requirements, specification and design * Architecture and high-level design * Object-oriented design * Object-oriented design anti-patterns (Examples of bad design) * Object-oriented design patterns (Examples of good design) * Beyond object-oriented design (Aspect-orientation, subject-oriented design, etc) Course Components: This course has the following components: * Homework: 20 * Class Participation and Quizzes: 15 * Mid-Term: 20 * Project: 25 * Final Exam: 20 * Extra Credit: variable All components are essential; you will not receive a passing grade in this course if you haven't completed a component of the course. For example, let us assume Jane Doe didn't hand in any homework, but received a 'B' grade or better in all other components. Her final grade will be 'F' without any exceptions. The class participation grade will be determined by your attendance in the class and your contributions to the class discussions. You will only be able to contribute to the class in a significant way, if you have carefully read the assigned readings for the class. Grade Computation Logic: You will receive an absolute letter grade for this course. There will not be any curving. As a result, everybody in this class may expect to receive an 'A'. The grades will be assigned as follows: * A: 90 and above * A-: 85 - 89 * B+: 80 - 84 * B: 75 - 79 * B-: 70 - 74 * C+: 65 - 69 * C: 60 - 64 * F: 59 and below Late Homework Policy: Late homework is not encouraged in this course. You are expected to submit your deliverables on time. Some homework solutions will be discussed in class after the due date. These homework will not be accepted after the due date and you will automatically receive a zero grade for them. The penalties for other homework submission are as follows: * Upto 1 day late: 5% * Upto 2 days late: 12.5% * Upto 3 days late: 20% * Upto 4 days late: 30% * Upto 5 days late: 50% * Upto 6 days late: 90% * 7 days or more: 100% Programming Assignments Test-Case Policy This policy applies to the programming assignment part of a homework. If we have provided test cases with the assignment, please ensure that your program passes all these test-cases before you turn in your homework. You will receive no grades for the failing program. Homework Packaging and Naming Convention Policy If we have provided a naming conventions for your files, classes, fields, methods, etc. and/or instructions on how to package your homework, please carefully follow them. Failure to do so may result in receiving no grades for that part of the homework Teamwork Policies Software design and development is a team activity. Most organizations have teams of varying sizes. In this class, we will practice software development as it is done in the real world. Team Formation At the beginning of the class, 3-4 students teams will be formed. Each team will either come up or will be assigned a name and a task to be completed in the rest of the semester. Conflicts Please try to resolve conflicts within the team by a conversation among team members. If the conflict is still not resolved, please bring it to the attention of the instructor. Contributions The teamwork process is up to the individual teams. However, each student in the team is responsible for understanding the work in the team, thus teams should be very careful to have the whole team check and explain parts of the work if it is split up. You, as a team member, should be sure that you understand all that goes on and that you take on a fair share of the work. Certifying Contributions To help make sure work contributions are rewarded fairly, we have the team rate the work contributions of its team members at the end of each homework. Individual contributions are rated on a scale of 1-5, with 5 being highest, and 1 lowest. These are used to adjust the grades of team members above and below the team’s grade. A rating X produces an increment to an individual’s grade of (X - 3)*2.5%, which is added to the team’s grade recorded for the individual (as long as the sum is between 0 and 100%). For example, suppose Alice is in a group whose homework got 80%, and her individual rating was 5; then Alice’s grade is recorded as 85%. In the same group if Bob has an individual rating of 2, then his grade is recorded as 77.5%. The team is constrained to make the total individual work ratings average to 3, and all members must agree on the contributions of all other members. The certification of individual contributions is to be done using a standard form, which is available as a MS Word document, as a HTML page, and as a text file from the course webpage. Policy on Academic Honesty Students enrolled in Computer Science courses at ISU are expected to maintain the highest standards of academic integrity. Cases of cheating that go undetected and hence unpunished skew the grading curve in a class, thereby lowering the grades for students who do not cheat. Students who cheat rob themselves not only of knowledge and skills that they should have acquired in a course, but also of the experience of learning how to learn, arguably the most valuable benefit of a university education. The reputation of the department, the university, and the value of the degree suffer if employers find the graduates of a program lacking in abilities that successful completion of specific courses should guarantee. Most professions, including Computer Science, have codes of ethics or standards to which individuals will be expected to abide by. At the University, you practice the integrity that you must demonstrate later. Suspected cases of academic misconduct will be pursued fully in accordance with ISU policies. Students are strongly urged to consult the university's policy on academic dishonesty. The information included here is intended to help students avoid unintentionally committing academic dishonesty. The primary purpose of assignments is to clarify and enhance the understanding of the concepts covered in the lectures. Past experience with this course has shown that this is helped by increased interaction among students. Discussion of general concepts and questions concerning the homework and laboratory assignments among students is encouraged. However, each student is expected to work on the solutions individually (except in the case of assignments that are explicitly assigned to teams of students). Laboratory Assignments When discussing code with other students, you may: * discuss algorithms, data structures, and implementation strategies * assist in debugging, possibly by suggesting diagnostic print statements or test cases * provide or receive help in understanding the code that is supplied to the class It is expected that you have written EVERY LINE OF CODE that you submit (with the exception of code given out in class) as part of your solution for a lab assignment. The following are examples of activities that are PROHIBITED: * Writing code with another student * Copying code from another student * Sharing code with another student (via email, printouts, web, ftp sites, etc.) * Posting code in a location that is accessible to others * Using code fragments provided by other students (including students who had taken the course in the past) * Using code fragments that are freely available (e.g., in public repositories) without properly acknowledging and citing the source Problem Sets When discussing problems from assigned problem sets (homework) with other students, you may: * discuss the material presented in class or included in the assigned readings needed for solving the problem(s) * assist another student in understanding the statement of the problem (e.g., you may assist a non-native speaker by translating some English phrases unfamiliar to that student) It is expected that you have independently arrived at solutions that you turn in for problem sets. The following are examples of activities that are PROHIBITED: * sharing solutions or fragments of solutions (via email, whiteboard, handwritten or printed copies, etc.) * posting solutions or fragments of solutions in a location that is accessible to others * using solutions or fragments of solutions provided by other students (including students who had taken the course in the past) * using solutions or solution fragments obtained on the Internet or from solution manuals for text books Term Projects Term project is in essence, a research project. You may make use of all the resources available at your disposal, including the published work of others, publicly available code, publicly available data sets, as well as consultation with others (fellow students, faculty, or other experts on the topic of your project). Note however, that your conduct of the project should be guided by the best practices of academic research and writing. In particular, you should exercise utmost care to avoid plagiarism: the deliberate use of someone else's language, ideas, data, code, or other original material that is not common knowledge without properly acknowledging the source. You should also familiarize yourself with appropriate ways to acknowledge the contributions of others and to cite all your sources (See for example, ISU library's index of resources for avoiding plagiarism). Students may choose to work in teams of 2 or 3 members on the term project. Collaboration within a team is expected and encouraged. Each team member is expected to contribute to all aspects of the project: including conception of the initial idea, planning, implementation (including design and analysis of algorithms, design, implementation, and testing of code, experimental evaluation) and reporting (including organization and writing of the report). However, because each individual brings unique abilities to a team, and one of the goals of working in a team is to take advantage of the unique abilities of the team members, it is not unusual for the contributions of individual team members to vary across tasks. To ensure that each team member gets credit for his or her contributions, the final report should include a statement of contributions that explicitly identifies the contributions of each team member and a statement that every team member concurs with the contents of the report. If there are irreconcilable differences among members your team, you should notify the course staff as early as possible (but after having made a good faith effort to resolve the differences among yourselves) so we can help resolve the differences or suggest alternatives. Submitting a single term project or paper for credit in two different classes (in the same semester or in different semesters) is not allowed unless explicit permission to do so is obtained in advance from each of the professors involved. Exams Copying someone else's solutions, using notes or reference materials (unless instructed otherwise), altering an exam for re-grading, getting an advance copy of the examination, or having someone else write the exam amount to cheating on an exam. You need to exercise special care with take-home exams. You should NEVER * share solutions or fragments of solutions (via email, whiteboard, handwritten or printed copies, etc.) * post solutions or fragments of solutions in a location that is accessible to others * use solutions or fragments of solutions provided by other students (including students who had taken the course in the past) * use solutions or solution fragments obtained on the Internet or from solution manuals for text books * use material from text books, reference books, or research articles without properly acknowledging and citing the source Prerequisites COM S 229 and ENGL 104 Disability Statement Please address any special needs or special accommodations with the instructor at the beginning of the semester or as soon as you become aware of your needs. Those seeking accommodations based on disabilities should obtain a Student Academic Accommodation Request (SAAR) form from the Disability Resources (DR) office (515-294-6624). DR is located on the main floor of the Student Services Building, Room 1076.