Principles of
Software Engineering


Instructor:
Location: BDK 329R
Phone: x7861
Email:
Office Hours: see my schedule or by appointment (email me and we can set something up).

meets:
MWF 8:00 - 9:00 am in SCI 261.

Text: Object Oriented Design using Java by Dale Skrien. (Required) Publisher's Website

Online Aid: The course website is at .
Kyle recommends using Wikipedia to find extra information about class topics. However, Kyle is not responsible for the correctness of Wikipedia's content; it might be incorrect!

Grading: Grades will be determined based on the following rubric:

Projects:	75%
Final Exam:	25%

Projects: Teams will be responsible for turning in projects on a regular basis. Each week(ish), a team will both add the new, assigned functionality to their project, as well as fix any logical and design issues from the previous week, as pointed out in the previous grading cycle. Projects are due at the beginning of class on the due date. Project submissions should include:

• A list of all your classes divided into three sublists:
  • Those classes for which the files were not changed at all. (Comments, file names, etc, count as a change.)
  • Those classes which were changed, but had no changes to their public interface (including JavaDoc).
  • Those classes which were changed and had their public interface change.
• A legible, hand-drawn UML diagram of the current code. Auto-generated diagrams will not be accepted! It is very acceptable to first generate your diagram, then trace it, so long as the result is legible. Your full diagram should be on one side of one sheet of paper. It must include:
  • Each class in your project. For each class, if the set of public members (instance variables and methods) did not change, just put the name of the class in a box.
  • Otherwise, list all the public members and private instance variables. If any were removed (or methods made private), list them, then strike them out.
  • Hollow arrows representing subclassing. Each arrow's base should come out of the top of the subclass's box.
  • Hollow arrows representing interface implementation. Just as subclassing, but the line should be dashed.
  • Full or 2-D arrows representing references. The arrow should point from the referencing instance variable (if listed, otherwise just the box) to the head of the class it's referencing. If there are more than one possible references, this should be noted as a number at the arrow base.
  • Other arrows representing connections between classes. Explain these arrows with a word above the shaft.
• The code for the project, emailed to me and also every member of the team. Each class file should have the name of the file in the top line of the JavaDoc text. All members of each class should be commented. Private members should have a standard comment, public members need to be correctly JavaDoc'ed.
• JavaDoc for the project. I shouldn't have to compile it myself.
• A brief team report, with all member names at the top, which describes all design changes that were made. This should also describe steps needed for me to run the code and where to find the JavaDoc.
• A personal report from each team member to me. Explain what the most important change you think your team made and also the most important thing you would have liked to have done but didn't have time for (if there was anything). Include a breakdown (pie chart, if you like) of the percentage of the effort you think each team member made in the latest iteration.

I will not accept your project until all of the above parts are turned in. Your project grade will be based on:

• Lateness. For each weekday late, I will take off 20%. All of the above parts must be turned in in order for me to accept it. Even worse than the grade penalty is that you will have less time to complete the next project, because my response will be delayed. Please do not be late with projects! Start early!
• Correctness. If your project does not meet the specifications (assignment) I will take off points. Please ask me questions in case something is not clear.
• Public Instance Variables. Don't have them. I will take off one percentage point for each one I find in each class.
• Elegance. After I grade your submission, I will mark places where the design of your code is flawed but not immediately take points off. If these flaws are not fixed in the next iteration, I will take off one percentage point for each instance of a flaw I find. If you are not sure how to fix something, come talk to me. If you think you've fixed it, but haven't actually, then I will take points off. If you think I made a mistake, come talk to me; you might be right! If I do agree with you, please write a commented note to me to that effect in the code so I won't take off points. Do not wait until the end of the project cycle to ask me about design flaws! Come talk to me right away!
• Cooperation. Don't leave your team to do all the work. If you feel that you are working more/less than other teammates, talk to each other. If you can't work things out, come talk to me. You will (probably) need to split up to work on these projects (this is the only class I teach where you're allowed to do this) but it's a bad idea to work on parts without letting your teammates know what you're doing.

In each cycle, I highly recommend first addressing the problems I've found, then adding on the new functionality.

Final Exam: The Final Exam will be an individual project due during finals week.

Class Policies:

Keeping in touch: The most convenient way to get in touch with me is to send me an email. I will often send email to the class and thus expect you to check your Wittenberg email. During class, I'll answer lots of your questions, but some administrative questions are better answered outside of class, and I may ask you to send me an email instead. I am often available on many IM clients, but I don't keep records of these conversations; email is better for anything that's important! The best way to get help is in a face-to-face conversation, so please come stop by my office. My basic schedule for this semester is available here. Naturally, if you have a question about class, then office hours are a great time to come by! Even if it's not my office hours, if I'm around, my door is almost always open. Outside my office, I keep a wheel that can tell you where I am and when I'll be back if I'm not there. Of course, once you are in touch with me, it is perfectly fine to call me "Kyle".

Due Dates: It would be wonderful if deadlines were not necessary. I would like nothing better than for you to go back and fix any errors in your assignments, but unfortunately time is a factor in this (and any) class! Unless otherwise specified, all assignments are due at the beginning of class. Do not turn in an assignment during class! For classes with two different lab sections, assignments are due at the beginning of the first section.

Submitting Assignments: Some classes are taught using Moodle. For those classes, be sure to submit all your projects using Moodle's online tools. If you can't submit a project via Moodle (and it's before the deadline) I probably set it up incorrectly. Email me so I can fix it! For other classes, you can email projects to me.

Late Assignments: For some classes, turning in late assignments is permitted, with a penalty. Do your best to turn things in on time, though sometimes it is advantageous to suffer the penalty and turn in a stronger assignment.

Grades: I try to keep my grading methods as transparent as possible, but they sometimes get a bit complex. If you are ever unsure how you are doing in the class, just ask me! You can ask me as many times as you'd like!

Academic Integrity: I've seen enough problems students have had when violations of the honor code have been tolerated. All of my courses will adhere strictly to the Wittenberg Code of Academic Integrity and any infractions will be reported to the honor council. Please take the time to read and understand the code. The next paragraph has some additional information about academic integrity as it applies to computer science.

Collaborating with Others: Assignments in computer science often consist of written homework and programming projects. For other types of assignments (tests, papers, presentations, etc) definitions of plagarism are fairly standard. For written homework, the rules are identical to those of math classes: you may talk to other students about assignments and potential solutions, but you must write up all your answers individually. As soon as you start writing up a solution, you should keep that work private from others (though you may give more general verbal summaries).

For programming projects, the rules are similar, except that some projects in some classes have group projects. The basic rule is that you may not look at someone's project who is not in your group! Although for most classes, it is completely acceptable to look at test runs of other code, it is not okay to view their source code. (With the Python IDLE, this means it is acceptable to share examples from the interactive mode, but not share pieces from a script.) Any sharing of source code is considered plagarism! Any violation of the above rules will be reported to the honor council. If you're not sure about the rules, please ask me.

Naturally, if you or your group needs any additional assistance on a project or assignment, please come by my office or send me an email! It is completely normal to be stuck on the same problem several times.

Working within your group: In most classes, it is assumed that you will be pair programming with other members of your team. Unless otherwise instructed, any actual programming for the project should be done with all group members present. It is not acceptable to code parts of the project on your own, though it is okay to test cases of the program looking for bugs.

Missing Class: If you miss class, you are responsible for getting a hold of whatever notes and information you missed on that class. If anything is unclear, please get the notes and material from someone else in class then come talk to me. If you have an excusable reason you will miss class, please let me know ahead of time via email! To agree with excused absences, I expect to be notified at least two weeks in advance. (This is especially important for midterm exams!) If you submit any assignments late, I must be able to find an email where I agreed to accept them late.

If you are sick, the first thing you should do is relax. You won't get better if you are too stressed out! Next, send me an email so I know you are sick and can accomodate your illness as much as appropriate. Return to relaxing as much as possible to get better. Do not wait until the end of your illness to contact me. (Have a friend email me if necessary!)

Although I don't usually take attendance, if I record that you are absent for five or more class periods (four or more for Tuesday-Thursday courses) you will automatically fail the course. Prior-known absences need to be approved by me before they happen.