This course covers fundamental topics in software engineering, with an emphasis on object-oriented design using the Unified Modeling Language (UML). The core topics are:
The course also covers some advanced topics, such as:
The course outcomes are (copied from the official course description):
The project involves a database. Therefore, in addition to the official prerequisites, I recommend that all students have knowledge of databases, from taking CSE 305 or equivalent experience.
You need a book on UML. You should bring it to class every day during roughly the first half of the semester. The book will be very useful during in-class exercises, the open-book exam, and your project team meetings. There are some decent on-line UML resources, such as Allen Holub's UML Quick Reference and OMG's UML Resource Page, but they are useful as supplements, not substitutes, for a good textbook. I evaluated about a dozen books on UML and recommend that you get one of the following (you do not need both):
Simon Bennett, John Skelton, and Ken Lunn, Schaum's Outline of UML, 2nd edition, McGraw-Hill, 2004. This book has thorough coverage of UML and abundant examples. Unfortunately, it is out of print in the U.S., so the bookstore cannot stock it. Inexpensive used copies are usually available, e.g., on Amazon. A copy is on 2-hour reserve in the Science and Engineering Library.
Russ Miles and Kim Hamilton, Learning UML 2.0, O'Reilly Media, 2006. This is a reasonably priced book with thorough coverage of UML. It uses a blog management system as a running example. New and used copies are available, e.g., on Amazon. Do not buy an electronic edition (e-book)! The exam is open book, and electronic devices are prohibited; see the exam guidelines for details.
In addition to a UML book, you should read: Scott W. Ambler. Mapping Objects to Relational Databases: O/R Mapping In Detail.
For topics other than UML, the lecture notes (which will be posted on Blackboard after each lecture) are probably sufficient, but you can refer to almost any software engineering textbook for additional information, if you like. The library has numerous software engineering textbooks; well-known ones include Shari Lawrence Pfleeger, Software Engineering: Theory and Practice, which is on 2-hour reserve, and Ian Sommerville, Software Engineering.
Assignments and course documents are posted in Blackboard.
See Blackboard.
Section 1: Tue and Thu, 1pm-2:20pm, Frey Hall 105.
Instructor's Office Hours: Tue and Thu, 10am-11:30am, in Computer Science 1429. Also by appointment, and whenever I am in my office and not unusually busy.
TA's Office Hours: Mon and Wed, 11am-12pm, in Computer Science 2110.
Submission of Assignments. All assignments except team formation (hw1-team) and team evaluations must be submitted in two ways (yes, both): (1) Submit a printout of the specified material in class on the due date, and (2) Submit an electronic version of the specified material 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 on the due date. Any team member can submit the electronic version on Blackboard, but please coordinate so that exactly one team member submits 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. The first page of every printout should contain the team name, section number, and names of all team members. The name of every file uploaded to Blackboard should contain the team name and assignment name (e.g., Dream-Team-hw5.zip). We need the printout for grading (we write comments on it); a team that does not submit a printout does not get a grade for the assignment. We need the electronic submission so that we still have a copy of the team's work after we return the graded printout.
Team evaluations must be submitted on Blackboard by 11:59pm on the due date, using the appropriate "View/Complete Assignment" link.
Late Submissions. For assignments that involve presentations (design review, code review, and demo), lateness penalties are 10% per day and strictly enforced (except in extenuating circumstances), because rescheduling them is disruptive and inconvenient. For assignments that do not involve presentations, assignments submitted after the deadline and within 24 hours of it receive a -4% penalty. Assignments submitted within the next 24 hours receive a -8% penalty, and so on. I am generally not too strict about lateness penalties for non-presentation assignments, when one or two assignments are submitted a few hours late, but chronic offenders and significantly late assignments will be penalized.
Grading. Each assignment is graded relative to some maximum number of points (e.g., 20), which 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. The tentative weights (subject to adjustments, probably small) are as follows.
| hw1-team | 0 |
| hw2-requirements | 8 |
| hw3-design | 10 |
| hw4-dynamic-model | 4 |
| hw5-design-review | 5 |
| hw6-persistence-and-code1 | 15 |
| hw7-ethics | 2 |
| hw8-code2 | 10 |
| hw9-code-review | 4 |
| hw10-code3 | 30 |
| hw11-demo | 2 |
| exam | 10 |
| TOTAL | 100 |
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's ICF may be reduced, and in severe cases, the student may be removed from the team. A student removed from a team must complete the remaining assignments as a one-person team.
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.
Questions about Grading. To promote consistency of grading, questions about grading should be addressed first to the TA and then, if that does not resolve the issue, to the instructor. You are welcome to contact the TA by email or come to his office hour. If you would like to speak with the TA in person, and have a schedule conflict with his office hour, you are welcome to make an appointment to meet the TA at another time.
Electronic Communication Statement. Email and especially email sent via Blackboard is one of the ways the faculty officially communicates with you for this course. It is your responsibility to make sure that you read your email in your official University email account. For most students that is Google Apps for Education, but you may verify your official Electronic Post Office (EPO) address. If you choose to forward your official University email to another off-campus account, faculty are not responsible for any undeliverable messages to your alternative personal accounts. You can set up Google Mail forwarding using these DoIT-provided instructions. If you need technical assistance, please contact Client Support at (631)632-9800 or supportteam@stonybrook.edu.
Academic 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/If your team submits anything that includes any material created by other people, your team's submission must clearly identify that material and indicate its source; otherwise, it is plagiarism. Discussing assignments with other people is fine. However, each team must write its own code and documentation independently. Showing your team's code or documentation to other students, giving it to them, or making it accessible to them will be treated as a suspected instance of academic dishonesty.
Disabilities. The Provost requests that the following information be included in the syllabus for every course. If you have a physical, psychological, medical or learning disability that may impact your course work, please contact Disability Support Services, ECC (Educational Communications Center) Building, room 128, (631) 632-6748. They will determine with you what accommodations are necessary and appropriate. All information and documentation is confidential. https://web.stonybrook.edu/newfaculty/StudentResources/Pages/DisabilitySupportServices.aspx
Critical Incident Management. Stony Brook University expects students to respect the rights, privileges, and property of other people. Faculty are required to report to the Office of Judicial Affairs any disruptive behavior that interrupts their ability to teach, compromises the safety of the learning environment, or inhibits students' ability to learn.
Every team is encouraged to use a version control system, such as Subversion or git, to manage its project files.
Subversion: On the server side, the Computer Science Department has a Subversion server. If your team would like a repository on it, send a request for a repository, mentioning that it is for CSE308, and specifying the names and SBU ID numbers of all team members, to rt@cs.stonybrook.edu. A repository will be created within a few days. You can then access your team's repository using your Computer Science Department Windows Lab username with your Stony Brook ID as the password. On the client side, Netbeans and Eclipse both support Subversion, either natively or via a plug-in, or you can use a stand-alone GUI client, such as TortoiseSVN, or a command-line svn client (e.g., from cygwin).
Git: On the server side, Git repositories on bitbucket are free for up to 5 developers, and repositories on github are free for open-source code and inexpensive (expect $7/month) for private code. On the client side, git is supported in Netbeans and Eclipse, and there are stand-alone git clients, including several listed here, and Tortoise Git.
You may use any DBMS for the project. You may run the DBMS yourself, or you may use the Computer Science Department's MySQL, Oracle, or DB2 server. If your team would like an account on one of those servers, send a request, mentioning that it is for CSE308, and specifying the DBMS (MySQL, Oracle, or DB2) and the names and SBU ID numbers of all team members, to rt@cs.stonybrook.edu. An account will be created within a few days.
Every team is encouraged to use an Integrated Development Environment (IDE) for software development and debugging. Eclipse and Netbeans are available in the Windows Lab and can be installed for free on your own computer.
Several teams from prior years recommend using a build system such as Jenkins continuous integration server or Maven.
Note that some tools lack support for some kinds of diagrams, and that you will need to draw a component diagram for hw3-design.
Visual Paradigm for UML (Community Edition). The Community Edition is free for non-commercial use. It puts a "Community Edition" watermark on the diagrams; that's fine for this course. It supports all of the types of UML diagrams used in this course. It runs on Windows Vista/7/8, Linux, Mac OS X, etc. It is installed on the computers in the Windows Lab.
UMLet: an open-source UML tool. Runs stand-alone or as an Eclipse plug-in on Windows, OS X, and Linux. UMLet supports class diagrams, use case diagrams, sequence diagrams, state diagrams, deployment diagrams, activity diagrams, and component diagrams (I think), but not communication diagrams.
Visual Studio. I do not recommend Visual Studio, because it does not support communication diagrams or state diagrams, as of the last time I checked. It does support activity diagrams, component diagrams, class diagrams, sequence diagrams, and use case diagrams. It is available for free download through DreamSpark.
StarUML: an open-source UML modeling tool. Runs on Windows only. Not under active development. According to the Wikipedia entry for StarUML, StarUML supports most of the diagram types specified in UML 2.0, except object, package, timing and interaction overview diagrams (though the first two can be adequately modeled through the class diagram editor).
Netbeans UML Plug-in: I do not recommend this plug-in, because it does not support communication diagrams or component diagrams (last time I checked). It does support use case diagrams, class diagrams, activity diagrams, sequence diagrams, and state diagrams. It also supports forward and reverse engineering.
ArgoUML: Avoid ArgoUML, because it uses UML 1.4 notation.
Violet. I do not recommend Violet, because it does not support component diagrams, communication diagrams, or deployment diagrams, and it has limited support for sequence diagrams (lacks support for actor icons, loops, alternatives, conditions, etc.).
You are encouraged to use one of the above UML tools to create UML diagrams, because they provide some error checking that helps prevent you from producing invalid UML diagrams. The following general-purpose diagramming tools do not provide such error checking.
Lucidchart: a web-based diagramming tool with support for UML diagrams. It is available to all Stony Brook Google Apps users through Google Drive.
Microsoft Visio: a diagramming tool, with a library of UML shapes. Visio is available in the Windows Lab. I do not recommend Visio, because it often produces ugly UML diagrams; for example, it automatically positions edge labels, but the positions are often not what you want and (as far as I know) cannot be manually overridden.
Microsoft PowerPoint: Powerpoint can be used to draw UML diagrams, but not conveniently, because there is no library of UML shapes for it.
LibreOffice Draw or OpenOffice Draw: Draw can be used to draw UML diagrams, but I don't know how conveniently. It does not come with a library of UML shapes. You could try Mark Lautman's UML Shapes for Draw; I don't know which types of UML diagrams it supports.