CS 319 Sec 1&2 Object-Oriented Software Engineering Fall 2011 Course Web Page: COMMON INFORMATION TO ALL SECTIONS Instructor: Ugur Dogrusoz Office, Hours: EA-528, Tue, Fri PM Classroom, Hours: EB-104, Tue, Thu, Fri TAs, Office Hours: S.Onur Sumer (Wed 14:40-16:30) and Alper Karacelik (Thu 15:40-17:30)

Announcements	You may see your final exam papers on Monday (the 23rd) between 9:30 and 11:00am. This is your only chance, please plan accordingly! Unless otherwise stated, we do not hold the following lecture hour: Section 1: Tue 8:40-9:30, Section 2: Tue 15:40-16:30 Check here at least once a week!
Resources	Introduction OOSE w/ UML in a nutshell Slides (textbook slides as modified by UD in the order covered) Chapter 1 - Introduction Chapter 2 - Modeling with UML Chapter 4 - Requirements Elicitation Chapter 5 - Analysis - Object Model Chapter 5 - Analysis - Dynamic Model Chapter 3 - Project Organization and Communication Chapter 3 - ARENA - Case Study Chapter 6 - System Design: Decomposing The System Chapter 7 - System Design: Addressing Design Goals Chapter 8 - Object Design: Reusing Pattern Solutions Chapter 9 - Object Design: Specifying Interfaces Chapter 9 - Object Design: Object Constraint Language Chapter 8 & Appendix A - Object Design: Design Patterns I Chapter 8 & Appendix A - Object Design: Design Patterns II Chapter 10 - Mapping Models to Code Chapter 11 - Testing Chapter 11 - Integration & System Testing UML Quick Reference - Quick Reference - Reference Card (version 1.4!) - UML (MM Pres) - UML (PP Pres) Design Patterns Slides from past years - Examples Testing Documentation with an example Software Reuse Class reuse example
Grading	20% of the course grade will be based on pop-quizzes given during lecture hours and homework assignments.
Assignments	Date Assignment Jan 6 Project Final Report Week of Dec 19 Read Textbook – Chapter 11 Week of Dec 12 Read Textbook – Chapter 10 Week of Dec 5 Read Textbook – Chapter 9 Week of Nov 28 Read Textbook – Chapter 8 Week of Nov 14 Read Textbook – Chapter 6 & 7 Dec 11 Project Design Report completed Nov 30 Project Design Report - System Design done (sections 1 & 2) Nov 1 Project Analysis Report completed Week of Oct 25 Read Textbook – Chapter 5 Oct 18 Project Analysis Report - sections 1-4 & 5.1 done Week of Oct 10 Read Textbook – Chapter 4 Week of Oct 3 Read Textbook – Chapter 2 Oct 4 Choice of project, Web page up! Week of Sep 26 Read Textbook – Chapter 1
Projects	Description - Groups - Demo Schedule Template for reports Remarks on Final Submission and Demos Any individual or group that do not follow these guidelines will be penalized accordingly! Read the Project Description document! By the midnight of the 6th, you are to make available on your project Moodle wiki page, the final versions of all there is to your project (Final Report, User's Guide, API documentation, sources, executables, etc.) This is the version from which you are to demo your software! You may submit your peer grades later on (by the midnight of Jan 8th); please email them to the TA (Onur) as described in the Project Description document; do not forget to evaluate yourselves (on a scale from 0 to 10, you must explain your reasons unless a score is a 0 or a 10). Peer grades are to be kept strictly confidential! Failure to send in peer grades will certainly be penalized! Demos are to be done during Jan 10th thru 12th at designated time periods. Demo schedule is here. Make an appointment w/ us (on a first-come first-served basis) for a demo by emailing the TA (Onur) by the 4th. You are to make an informal presentation on the architecture/design of your software (from a developer’s perspective) for about 5 minutes, making especially use of component & class diagrams. During the remaining 20 minutes, you are to demo your software and talk about its status! You are to do your demos on your own computer(s). Laptops come in handy here. Please come prepared and have everything already set-up. Unless you get going within a couple of minutes with your preparation time, I might have to ask you to come back at a later time as time is critical with so many demos to see and evaluate. If your demonstrations are to require a network connection, you may use the public wireless at our floor. For any distributed software, you might need a second and perhaps a third computer. In such a case, have these other computers already set-up in your dorm room or lab or in TA's office (by arranging with the TA beforehand). I expect all team members to be present in your demo unless you have a valid excuse. Sample Projects These are sample projects from past years. In no way, do we claim that these projects are perfect! However, they were all among better projects of that particular semester. Bomberman Figure Drawing Tool Chicken Invaders Heroes of Might and Magic Comments on Reports A1: An Analysis Report is much more than simply a User’s Guide! It should mainly address the designer, possibly customers as well, but certainly not the end-user. A2: The sections of an Analysis Report (like any type of a report) should be organized with respect to some criteria (e.g., software components). Diagrams are just means for expressing ideas, models (like text or screenshots). Naming (sub-)sections Diagram 1, 2, 3 is not good way to organize material. A3: Need to make sure section titles are clear enough to see how the overall organization is, what each section really includes, and how they complement each other. A4: The order in which modeling activities during an analysis should be performed and written as part of the report should be as follows: UC model first, followed by Object and Dynamic Models. A5: Too many nested levels of sectioning (e.g. 3.1.2.3) makes flow of the document and hence its understanding unnecessarilly complicated. UC1: UC diagrams come pretty late and they seem to be done after the design of the menus. However UC analysis is the very first activity performed during analysis. On the contrary, menus should be designed around (in accordance with) UCs. Also remember that this documentation is not a post-analysis activity, it’s a live document summarizing/reporting the analysis itself! UC2: UC analysis mainly includes a textual description of the use-cases. UC3: Make sure each UC actually makes a good use-case (one of the important "selling points" of your software). "Quit Game" isn't one. UC4: Poor naming of use cases or actors: it should be "Get Help", not "Help", not "Getting Help"; "Player", not "Actor", not "Ali". SD1: A Sequence Diagram represents the interactions of the objects in the software during a sequence of events. Thus you should introduce such a diagram by stating what that sequence is. E.g., the following Sequence Diagram shows how Ali successfully destroys the enemy spaceship by using blah blah, after doing blah blah… SD2: Incorrect flow of control in Sequence Diagrams. SD3: Make sure each object in a Sequence Diagram is actually responsible for each incoming message/method call. SD4: Poor naming of objects in Sequence Diagrams. SD5: Properly show the data passing (parameters) during messaging in between objects. SD6: New object creations not shown properly. SD7: Actors should directly interact with boundary objects, not control or entity objects. ST1: Could make use of State Diagrams. ST2: States in a State Diagram belong to a particular object of a certain class, neither non-objects nor multiple objects. ST3: States in a State Diagram should be complementary and mutually exclusive. AD1: Activities in an Activity Diagram should be the activities of the system, not the user! AD2: Incorrect use of the synchronization in Activity Diagrams. AD3: Conditionals/branches not properly shown in Activity Diagrams. CD1: Improper naming of classes; should be nouns that are singular. CD2: Associations should be given proper role names. CD3: Multiplicities should be specified for associations where appropriate. G1: What you analyze, design, and implement is a software or software tool or simply tool, not simply a program. G2: In general it’s a lot more effective (in terms of conveying ideas) to have some pictures, screenshots as early as possible during a presentation or documentation in general. G3: Just like any other formal report, it should have a table-of-contents; all figures must be numbered and should have caption, etc. As “computer people” who write such documents regularly, we strongly recommend that you learn a word processor well; that is, use auto formatting, auto numbering, auto table of contents, etc. G4: Java API documentation is better be presented separately (than the internal document) as it is often long and clutters the report. G5: The explanations of UML diagrams should be in plain English (e.g., use “main menu” instead of “MainMenu class”; use “collision manager” instead of “CollisionMgr object”; say “a new weapon of this type is created” instead of “create method of WeaponMgr is called with this type”). G6: Some diagrams are redundant (similar kind of information is captured in multiple diagrams). G7: Anything "lifted" (i.e. copied) from some place else, should be cited properly; even an icon. G8: Figures/diagrams are not readable (e.g. zoom level too small). G9: Use a CASE tool to make sure UML notation is correctly followed. G10: The diagram does not present anything interesting/useful in particular.