CS 319 Object-Oriented Software Engineering Spring 2018
Section(s) 1 E. Tuzun 2 U. Dogrusoz
Description & Prerequisites A course on principles of object-oriented software development, 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 UML Sample Notation - Quick Reference - Reference Card (version 1.4!) -

Design Patterns Slides from past years - Examples - 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
Attendance/Quiz/Assignment 20
Project 40
Midterm [closed book & notes] (Mar 16, 2018, 17:40, EB 201,2,3) 15
Final [closed book & notes] (May ??, 2018, EB ??) 25
Those students who fail to get a minimum of 30 (out of 75) points from the weighted average of the total grades (attendace/quiz/assignment, project, midterm exam) before the final exam will get the grade FZ. For instance, A/Q/A: 5/10, P: 20/100, M: 40/100 (0.2 * 50 + 0.4 * 20 + 0.15 * 40 = 24) fails, whereas, A/Q/A: 8/10, P: 30/100, M: 40/100 (0.2 * 80 + 0.4 * 30 + 0.15 * 40 = 34) will take the final exam.
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.
Announcements 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 specified date, you are to finalize and freeze your project pages (Final Report, User's Guide, API documentation, sources, executables, etc.) and make available in your project repository's master branch. This is the version from which you are to demo your software!
  • Demos are to be done during scheduled time periods. Make an appointment directly with your instructor (on a first-come first-served basis) for a demo by email at least 24 hours before the Final deadline (specify the slot you'd like by slot number).
  • You are to submit your peer grades by the end of following day; please email them to Gulden 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!
  • You are to make a presentation on the architecture/design of your software (from a developer’s perspective), making especially use of component & class diagrams. Then, you are to demo your software. Presentation (Google slides) and demo (feel free to record a Youtube video) are to be finished within 15 minutes. Please come prepared; the most unpleasant question you can ask is "So, what should we show or say?". Well, it's your software; it's your demo! In the remainder of the time, we will ask you some questions about the project status and each student's role in the project!
  • 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, we 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).
  • We expect all team members to be present in your demo unless you have a valid excuse.
Projects Description - Groups - Demo Schedule

Template for reports

Date Assignment
Week of May 07 Project Demos
May 06 Project Peer Grades
May 05 Iteration 2 - Final Report
May 04 Project Demo Appointment
Apr 17 Iteration 2 - Project Design Report
Apr 03 Iteration 2 - Project Analysis Report
Week of Mar 19 Project Iteration 1 Demos
Mar 17 Iteration 1 - Project Final Report
Mar 16 Midterm Exam
Mar 03 Iteration 1 - Project Design Report
Feb 17 Iteration 1 - Project Analysis Report
Feb 07 HW 1 due (submit as hard copy to your TA by 17:00. Hasan Balci, EA 525)
Feb 03 GitHub repository created, README.md specifies choice of project with brief description.
Jan 31 Project groups announced

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.


Section 1

Instructor: Eray Tuzun, GitHub
Office, Hours: EA-429, Fri 8:40-10:30am Classroom, Hours: EE-317, Wed 13:40-15:30, Fri 15:40-17:30
TAs, Office Hours: Gulden Olgun, GitHub , EA 425, By Appointment
Grading 20% of the course grade will be based on pop-quizzes given during lecture hours, active class participation and homework assignments.
Announcements
  • Check here at least once a week!
Section 2

Instructor: Ugur Dogrusoz, GitHub
Office, Hours: EA-522, Mon, Fri AM Classroom, Hours: EA-Z01, Mon, Wed AM
TAs, Office Hours: Hasan Balci, GitHub , EA 525, Thu 13:40-15:30
Grading 20% of the course grade will be based on pop-quizzes given during lecture hours and homework assignments.
Announcements
  • Check here at least once a week!
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.