• Write and thoroughly test a large program (1000 lines minimum)
• Apply incremental development to a large program
• Write and test code as part of a team
• Employ version control software on a collaborative project
• Design usable graphical user interfaces
• Write a program that stores data in and retrieves data from a database using SQL commands
• Design relational database tables
• Use a parser generator to write a parser for a formal language from a grammar
• Write a properly synchronized multithreaded program in Java
• Identify when multithreading is necessary, and avoid it when it is not
• Understand and apply automated unit testing
• Assess line and condition coverage
• Design a system by decomposing a problem into multiple interacting classes
• Understand and apply the following design concepts:
  • Mutable and immutable classes
  • Cohesive methods
  • Levels of code abstraction
  • Loosely coupled modules
  • Cohesive classes
  • Information hiding
  • Delegation
  • Type inheritance
  • Implementation inheritance
• Read and understand library API documentation
• Write a program that communicates with another program over a computer network using a socket

• Program correctness:
  • Does the program correctly exhibit all required functionality?
  • Does the program have any bugs? If so, what is their severity?
• User interface design:
  • Can important program functionality be accessed quickly and easily?
  • Is the appearance of the program aesthetically pleasing?
  • Is the interface usable on machines with different monitor sizes and shapes?
• Automated Tests:
  • Do the automated unit tests satisfactorially demonstrate each property that ought to be true of the program?
  • Do the automated unit tests achieve 100% statement coverage and condition coverage of the source code?
    • To assess coverage, install EclEmma as an Eclipse plug-in.
    • There are two general exceptions to 100% coverage; other exceptions might be negotiated on a case-by-case basis. If there is any doubt as to whether a block of code qualifies for an exception, be sure to ask the instructor prior to submission:
      • We will not apply automated testing to GUI code. It is rather difficult to write an automated test to verify graphical rendering, for example. This reinforces the importance of having a clean separation between the user-interface and algorithmic elements of code.
      • At times, it is important to include error-handling code that compensates for potential bugs. It might not be possible to write a test case that triggers this code. When this arises, be sure to make note of it in the code review.
• Program design and readability:
  • Does the program exhibit a solid object-oriented design?
  • Is the code readable and understandable?
• Code reviews: For each assignment, you will write two code reviews: one for the intermediate deadline, and one for the final deadline. The reviews themselves will be due 24-72 hours after the code deadline. For team projects, every member of the team must submit an individual review.
  • Does the review describe the degree of completion of the project?
  • Are all known bugs described?
  • Does the review discuss the strong points and weak points of the design and readability of the source code?
  • Does the review state the properties assessed by the unit tests?
  • Does the review give the degree of code coverage achieved by the unit tests, and justify uncovered code?
  • For team projects, does the review specify the contributions of each team member?
• Intermediate Deadlines:
  • By the halfway point of the project, is the program arguably halfway complete?

For each category above, the total points earned will be divided by the total points possible to yield a percentage. These percentages will be weighted as given above. A final average of at least 90 earns an A; 80 earns a B; 70 earns a C; 60 earns a D; below 60 is failing.

Programming Teams: The first two projects will be individual; after that, all programming projects will be completed in teams. Team size may vary per project. For each project, teams may vary slighly in size. Each team will be awarded a common grade for the project. Based on the code reviews, the instructor may adjust the grade awarded to individual team members at his discretion.

Each programming project has five deadlines:

1. Intermediate Deadline: The source code, object code, and all auxiliary files necessary for execution should be uploaded via Moodle for evaluation. The program is expected to compile without errors and execute.
2. Intermediate Code Review: A progress report, containing all of the elements mentioned above.
3. Final Code Freeze: At the code freeze deadline, coding must stop. No further modifications are to be made. The source code, object code, and all auxiliary files necessary for execution should be uploaded via Moodle for evaluation. The program is expected to compile without errors and execute.
4. Final Code Review: The final code review, as described above.
5. Code Revision: Once the code and code review have been submitted for the final deadline, students are welcome to revise their programs. Although a grade might not necessarily have been received, students should be able to determine the key flaws in need of revision; if there is any doubt, a consultation with the instructor would be welcome. Revisions are limited to the parts of the assignment that were seriously attempted prior to the code-freeze deadline. The code review must also be revised. The revised code and review will have a simultaneous deadline, which will typically be before the start of the next project.

After the revision is submitted, the instructor will re-grade the project. The grade for the revision will replace the grade for the original submission. It follows from this that submitting a revision is optional.

Presentations: Throughout the semester, students will be assigned to present code samples to the class. These presentations will begin during the sixth week of classes. A schedule of presentations will be posted on the course web page. Each student will do two presentations over the course of the semester. The goal of each presentation is to have an open discusion to analyze the quality of the design. For each presentation:

• One code sample from an assignment completed this semester will be selected.
• It will begin with a brief PowerPoint-style presentation:
  • One slide to contextualize the code sample
  • One slide to summarize the best and worst aspects of the code sample
• The code sample itself will then be presented, with the student pointing out specific areas for discussion.
• The presentation should last about five minutes, to allow time for discussion.

At the start of each team assignment, teams will present their concept for the project to the class. Each presentation should be a properly developed PowerPoint-style presentation using the overhead.

• Overview of the user interface
  • A graphical visual should show what the interface is intended to look like.
  • This overview should justify the design decisions of the interface, in terms of the criteria articulated early in the semester.
• Overview of functionality
  • For each element of functionality, the plan for its implementation in terms of algorithms and data structures should be discussed.
• Division of labor
  • Roles and responsibilities for each team member relative to the project goals should be defined.