Course Information
Lecture Format
In class we will spend around half the time on lectures and the other half devoted to working through examples, project presentations, breaking up into groups and performing design exercises, etc. The syllabus describes the topics covered and the dateline describes what we will do each class period, and when assignments are passed out and are due.Coursework
The coursework consists of- one Java GUI programming assignment toward the start of the course;
- occasional written homework assignments;
- a semester-long team programming project with biweekly checkpoints throughout the term and two in-class presentations.
Read more about the course project »
The project will account for the substantial majority of the final grade. Half of the project grade will be the final iteration, and another half will be for the previous iterations.Frequently asked questions about the course »
Getting Up and Running
To get going in the course you will need to- Establish a method for using Java, either in a lab or on your own computer. See the java resources.
- You also probably want to get Eclipse installed to start playing with it. See the CASE tools page.
- Get the textbooks.
- Get going on assignment 1 -- see the dateline.
- Start looking around for other members of the class to form a project group with. Group size of 4-5 is recommended.
- Add yourself to the course forum--see next section
The Course Forum
The OOSE Forums are used for course announcements and for open discussion of course assigments, projects, etc.
You will need to register yourself for the forum using the Register link; please do that immediately so you can see the course announcements posted to the forum. We most strongly suggest that you click on the "subscribe forum" link at the bottom of the OOSE forum page so you will get an email any time a message is posted in the forum; otherwise you will have to check manually and may miss important course announcements such as assignment postings, corrections, extensions, etc.
In order to control spambots we will need to confirm your registration before your account is active. If you are having problems registering, email us.
Style
Your work throughout this course will be graded in accordance with industry development standards and practices. If you have no experience with industry practices (and most students will not), do not worry; the grading of the first assignment is quite lenient in this regard and you will receive feedback indicating on what you need to improve. That said, this assignment is a good opportunity to develop the right habits. Except for the most egregious offenses (naming a variable with a dollar sign or a complete lack of commentation, for exmaple), a warning is typically given to a student or group and points are only deducted if the next assignment does not improve. The following will be considered style requirements for the course.
- All code must be properly commented. All methods and classes must contain at least some Javadoc. Large methods with complex operations should feature inline comments.
- All code must be properly indented. Especially with the advent of auto-formatting utilities, there is simply no excuse for code which does not follow a consistent indentation convention. You should use either spaces or tabs (not both) for indentation. If you use spaces, always indent the same number for each level and always indent inner levels more than outer levels.
- All classes should be declared within packages. Use of the default package is unacceptable in any large software project.
- Give methods and variables meaningful, conventional names. The definition of a meaningful name is subjective, of course, but it should be obvious that connectionMapping is a more descriptive name than temp42. Names should also adhere to Java naming conventions (classes in upper camel case, etc.).
- Empty catch blocks are bad practice. If a method throws an exception, it is trying to tell you something. Simply ignoring it is just as bad as ignoring a method's return value or any other information at your disposal. If the exception is truly meaningless to you, at least throw some form of runtime exception wrapping it and include a comment indicating that the code cannot be reached for whatever logical reason.
- Program to interfaces, not to classes. For variables, always use the least possible interface which supports your needs. For instance, use List instead of ArrayList. This may become important practice later on, especially if your project group wishes to use powerful libraries such as Hibernate.
- Use generics when appropriate. For instance, declaring a variable of type List<String> is better practice than declaring a variable of type List. Using generic type variables reduces the amount of time you spend debugging type errors by orders of magnitude.
Again, remember that these are all very leniently approached in the first assignment. Style is an important part of project work; it makes your code more readable and more maintainable. With that said, you should definitely choose functionality if your time constraints force you to pick between the two. If you have any difficulty whatsoever with understanding or implementing these or any other requirements, feel free to contact the teaching assistant or instructor.