CS 319 Object-Oriented Software Engineering Course Web Page

Spring 2013 Section 1 (Can Alkan)
Description & Prerequisites A course on principles of object-oriented software development, CS 102 & CS 201
Objectives
  • Learn basics of the software engineering (SE) process life cycle.
  • Learn what the object-oriented (OO) approach to software development is, through OO principles and design patterns.
  • Learn UML (Unified Modeling Language) that is part of most CASE (Computer Aided Software Engineering) tools and the benefits of visual modelling / diagramming.
  • Practice the application of principles of object-oriented software development through the course group project.
  • Develop teamwork and communication skills through the course group project.
Resources Introduction
Slides (textbook slides as modified by UD in the order covered)
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

CASE Tools
Mockup Tools
Outline Getting Started
  • Intro to SE (Chapter 1)
  • Modeling w/ UML (Chapter 2)
  • Project Organization and Communication (Chapter 3 Sections 3.1 - 3.3)
Dealing w/ Complexity
  • Requirements Elicitation (Chapter 4)
  • Analysis (Chapter 5)
  • System Design (Chapters 6 & 7)
  • Object Design (Chapters 8 & 9)
  • Mapping Models to Code (Chapter 10)
  • Testing (Chapter 11)
Grading
Grading Criteria:
Component Weight Date/Due Location
Attendance/Quiz/Assignments 20 - -
Project 40 - -
Midterm 15 - -
Final 25 - -
Those who fail to get a minimum of 30% from the Project OR a minimum of 30% from Attendance/Quiz/Assignments will fail (get Fz) the course! Those who fail to get a minimum of 30% from the Final exam are likely to fail (get F or Fx) the course.
Textbooks Required
  • Object-Oriented Software Engineering, Using UML, Patterns, and Java, 3rd Edition, by Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2010, ISBN-10: 0136066836.
Recommended
  • Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development, by Craig Larman, Prentice Hall, 2004, ISBN: 0-13-148906-2. resources
  • Object-Oriented Software Engineering, by Timothy C. Lethbridge and Robert Laganiere, McGraw-Hill, 2001, ISBN: 0-07-709761-0. resources
  • Developing Software with UML, Object-Oriented Analysis and Design in Practice, by Bernd Oestereich, Addison-Wesley, 1999, QA76.9.03503713 1999.
  • Object-Oriented Analysis and Design with Applications, 2nd ed., by G. Booch, Benjamin/Cummings, Redwood City, CA, 1994, QA76.64.B66 1994.
  • Principles of Object-Oriented Software Development, by Anton Eliens, Addison-Wesley, 1995, ISBN: 0-201-62444-3.
Fall 2012 Sections 1-3
Instructor: Ugur Dogrusoz
Office, Hours: EA-429, Tue PM, Fri AM Classroom, Hours: EB-101/2, Tue, Wed, Fri
TAs, Office Hours: C.Cagdas Cengiz (EA 425 Mon 15:40-16:30, Tue 13:40-14:30) and Merve Cakir (EA 425 Wed, Thu 15:40-16:30)
Announcements
  • You may see your Final Exam papers on Jan 15, 2013 between 11:00am-12:00noon in my office (EA 522)
  • Make-up Exams for Midterm and Final Exams are to be held in my office (EA 522) on Friday (Jan 11, 2013) @ 13:30
  • Sample Solutions to Midterm
  • Sample Final
  • Unless otherwise stated, we do not hold the following lecture hour: Section 1: Fri 16:40-17:30, Section 2: Fri 13:40-14:30, Section 3: Fri 8:40-9:30
  • Check here at least once a week!
Grading 20% of the course grade will be based on pop-quizzes given during lecture hours and homework assignments.
Assignments
Date Assignment
Dec 28 Project Final Report
Week of Dec 10 Read Textbook – Chapter 11
Week of Dec 3 Read Textbook – Chapter 10
Nov 30 Project Design Report completed
Nov 16 Project Design Report - System Design done (sections 1 & 2)
Week of Nov 12 Read Textbook – Chapter 9
Week of Nov 5 Read Textbook – Chapter 8
Oct 23 Project Analysis Report completed
Week of Oct 22 Read Textbook – Chapter 7
Week of Oct 15 Read Textbook – Chapter 6
Oct 12 Project Analysis Report - sections 1-4 & 5.1 done
Week of Oct 8 Read Textbook – Chapter 5
Oct 1 HW 1 Solutions
Week of Oct 1 Read Textbook – Chapter 4
Week of Sep 24 Read Textbook – Chapter 2
Sep 25 Choice of project, Moodle Web page up!
Week of Sep 17 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 28th, 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 Dec 31st); please email them to the TA (Merve) 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 2nd thru 7th 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 (Merve) by the 28th.
  • 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 as well as answering our questions about the project 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.


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.