Course Description

This course covers fundamental topics in software engineering, with an emphasis on requirements and design using the Unified Modeling Language (UML). The main topics are:

• software development process, software lifecycle
• requirements capture, use cases, use case diagrams
• software design and architecture, component diagrams
• object-oriented design, class diagrams
• dynamic models: activity, communication, sequence, and state machine diagrams
• testing
• object-relational mapping, persistence

Readings

Schedule

Class: Monday and Wednesday, 2:20pm-3:40pm. Earth & Space 069.

Scott Stoller's Office Hours: Monday and Wednesday, 1pm-2pm, or by appointment, or by chance (i.e., if you stop by without an appointment and I happen to be available), Computer Science 1429.

Teaching Assistant: Yang Chen (cheny03   at   gmail   dot   com)
Office hours: Tuesday, 2:15pm-4:15pm, Computer Science 2110.

Policies

Grading. Each assignment is graded relative to some maximum number of points (e.g., 20). The maximum number of points is unrelated to the weight of the assignment in the course grade. Each score is normalized into a number between zero and one (e.g., 19/20 -> 0.95) and then multiplied by the weight of the assignment to obtain a weighted score. Course grades are based primarily on the sum of the weighted scores.

Grading of Teamwork. Each project assignment receives a score reflecting the quality of the work. At the end of the semester, each team member's score for that assignment is computed by multiplying that score by an individual contribution factor (ICF) that reflects the team member's overall contribution to the team effort for the entire semester. Ideally, every team member will contribute equally to the overall effort. In that case, every team member's ICF is 1. A team member who contributes less than his or her fair share will have an ICF less than 1; a team member who contributes more than his or her fair share will have an ICF larger than 1. Everyone should keep track of their contributions throughout the semester. We will evaluate each team member's contributions using all available information, including the team evaluations described next.

Students will periodically evaluate the contributions of all team members to the project. When a student's contribution is significantly below the team's expectations, the student will receive feedback from the instructor, indicating the problem and the areas that need improvement. Depending on the severity of the problem, the student's ICF may be reduced, and the student may be removed from the team. A student removed from a team must complete the remaining parts of the entire project as a team of one.

Each team member is responsible for ensuring that he or she contributes. If you believe that your teammates are preventing you from contributing, discuss the situation with the instructor immediately.

Submission of Assignments. For hw2-requirements, hw3-design, hw4-design-review, and hw5-detailed-design: these assignments must be submitted in two ways (yes, both, not one-or-the-other): (1) Submit a printout of the document in class on the due date, and (2) Submit an electronic version on Blackboard by 11:59pm on the due date, using the appropriate "View/Complete Assignment" link. The printout can also be submitted at the instructor's office (slide it under my door if I am not there) by the end of class (3:40pm) on the due date. Any team member can submit the electronic version on Blackboard, but please coordinate so that exactly one team member does it. If the printout or the electronic version is submitted late, then the assignment is considered to be submitted late, and a lateness penalty may apply.

For hw6-code-and-code-review: No printout is required. Submit electronic version on Blackboard.

For hw7-code-and-demo: Submit printout during demo. Submit electronic version on Blackboard.

For team-evaluation-{1,2,3}: submit on Blackboard by 11:59pm on the due date, using the appropriate "View/Complete Assignment" link.

Late Submissions. Assignments submitted after the deadline and within 24 hours of it receive a -3% penalty. Assignments submitted within the next 24 hours receive a -6% penalty, and so on. I am generally not too strict about this if one or two assignments are submitted a few hours late, but chronic offenders and significantly late assignments will be penalized.

Exam. The exam is mainly about UML. During the exam, you may use your own notes, printouts of your team's assignments, any software engineering textbook, any book on UML, and printouts of any on-line UML resources. You may not use copies of other people's notes or other team's assignments. Although you are permitted to bring printouts of all of your team's documentation, in the interest of saving trees, I encourage you to bring printouts only of your team's UML diagrams; other material won't be useful.

Integrity. In Fall 2006, the Undergraduate Council adopted the following statement and mandated that it be included in all undergraduate course syllabi.

Each student must pursue his or her academic goals honestly and be personally accountable for all submitted work. Representing another person's work as your own is always wrong. Any suspected instance of academic dishonesty will be reported to the Academic Judiciary. For more comprehensive information on academic integrity, including categories of academic dishonesty, please refer to the academic judiciary website at http://www.stonybrook.edu/uaa/academicjudiciary/

Transaction Lab

File Sharing and Version Control

Every team is strongly encouraged to use a version control system, such as CVS or Subversion, to manage its project files.

Integrated Development Environment

UML Tools

Diagramming Tools

I encourage you to use one of the above UML tools to create UML diagrams. You could use one of the following diagramming tools instead. These tools present less of a learning curve when you get started, but they have some disadvantages, namely, they cannot generate code from class diagrams, and they do not check consistency of the diagrams. For example, a UML modeling tool can check that a method used in a sequence diagram is also declared in the appropriate class diagram; a diagramming tool cannot do this.

Lecture Material