CISC 475
Object-Oriented Software Engineering

Fall 2005
326 Purnell, Mondays 1900–2200

This is the Web page for CISC475, “Object-Oriented Software Engineering”. It will contain announcements, policies, and other pertinent material for the course. The page will be updated frequently—plan on checking for new or updated material at least twice a week.

About the course
Textbook
Schedule
Semester project
Teams
Final presentation
Final submission
Exams
Grading
Policies
Resources
Lecture materials

About the course

CISC475 presents an introduction to object-oriented software engineering concepts, methodologies and tools. It covers the analysis, specification, design, and implementation of software systems using object-oriented development processes including the Unified Process and UML. The course includes a semester-long team development project using the techniques discussed in class.

Prerequisites: A minimum grade of C− in CISC280 (Program Development Techniques) and Senior status. CISC361 (Operating Systems) is recommended.

Textbook

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development 3rd Edition Craig Larman ISBN: 0131489062

Class schedule

Semester project

A major part of this course consists of a semester-long team project. Each team will analyze, design, and build a significant software system using the Unified Process, and will deliver a complete set of UP artifacts (use cases, domain model, sequence diagrams, operation contracts, and so forth) along with the operating software. Projects will be implemented in Java.

Project topic: The project can be a productivity application, simulation, programming utility, game, or whatever, as long as it is:

• Interesting
• Not something any team member has already developed
• Complicated enough to demonstrate the team's engineering skills
• Not too complicated to finish within one semester
• Not a chat server, card game, or other trivial application.
• Approved by the instructor

In general, an acceptable project is one that supports multiple business functions, ideally for multiple types or classes of users. Requirements analysis and design for such a project will be more challenging than for a single-user, single function application (like a Solitaire game or an MP3 player).

Some possible project ideas are:

• Flexible network/resource monitoring application (like Servers Alive)
• High-volume real-time data historian
• Customer relationship management (CRM) system
• Project management application
• CASE tool for CISC475 semester projects :-)

Team member roles: Each team will consist of six students, and each student must have at least one well-defined role on the team. Each team must have a team leader, but the other roles will depend on the project topic selected. Some typical roles might be:

• Team leader—coordinates activities, leads design and implementation efforts, interfaces with the customer
• Test engineer—designs, codes, and runs unit tests and integration tests.
• Configuration manager—documents the development process, develops deliverables with a consistent look and feel
• Lead developer—develops core classes, oversees work of other coders
• Coder—the "ground state" for team members; everybody should be doing some coding
• Database developer

Project tools: You must follow the Unified Process for this project, and deliver a number of UP artifacts. Your grade also will be influenced by how well you adopt and use real software engineering tools, such as:

• CVS or some other version control package for both source code and artifacts.
• Ant to automate building, testing and deployment.
• JUnit to unit test your code.
• Javadoc to document your classes.
• A punchlist database (like Bugzilla, but simpler) to track bugs, missing features, potential refactorings, and other issues.
• A Wiki or some other tool for collaborative document editing.

Presentations: Each team will present its progress to the class at three points through the semester. At the second presentation, you will be expected to demonstrate major parts of your application. At the final presentation, you will demonstrate your complete application, and allow the instructor to “test drive” its functionality.

Submissions: Each team will submit a set of UP artifacts at four milestones through the semester. In all four submissions, you will submit all of your UML artifacts on paper. This will allow the TA and instructor to mark up the submissions when grading. At the second and third milestones, you will also submit all UML artifacts via e-mail as a ZIP file. At the fourth milestone, you will submit all UML artifacts, source code, build/test/install scripts, README files, installation instructions, and other documents on CD-ROM. The organization and professionalism of these submissions, and the ease with which the instructor can get your code running, will affect your grade.

The following Unified Process artifacts must be included in each submission:

1. Vision, Use Cases, Supplementary Specification, and Glossary.
2. Domain Model, System Sequence Diagrams, and Use Case Diagram
3. Specification and design documents: Operation Contracts, Collaboration Diagrams, and Design Class Diagram
4. Package Diagram, Deployment Diagram, project source code, .class files, javadoc files, installation scripts, installation instructions, help files, test scaffolding, etc.

Because the Unified Process is an iterative development process, artifacts will evolve throughout the project. Therefore, each submission must also include revised, updated versions of artifacts from all previous submissions.

3rd-party components: With the approval of the instructor, teams may use third-party libraries (for example, the Tomcat servlet container, the Hibernate object/relational persistence framework, or the XStream XML serializer) as components in their projects. Except for such approved components, the code and documentation developed in this course must be the new, original work of the project team members.

Teams

I've put up a page containing everything I know about the project teams. Team leaders should review this page for accuracy and send me any corrections.

Final Presentation

Final project presentations will be held in 304 Gore Hall on Monday, December 5th, with the first presentation starting at 1800. The classroom will be open starting at 1700 to allow you to stage and test your equipment. Attendance at the presentation is mandatory for all students in all teams.

There will be NO Internet connection available, so bring all of the hardware you need for your presentation. (The instructor will provide a power strip, a network hub or switch, and several network cables.) If your project is a networked application, the instructor may connect a laptop to your server and test-drive your system, so make sure that your network drivers are up and that any firewall permissions are set to permit this.

Each member of each team must introduce himself (not just be introduced by the team leader), and should make some part of the presentation. The instructor will take a photograph of each team.

Each presentation should take about 30–40 minutes, including setup/teardown and question/answer. Do at least one dress rehearsal of your presentation to make sure that everyone knows his part and that it will take about that amount of time.

Here are some examples of the things a good presentation will cover:

• System overview: Describe what the system is, and why you think it's a good idea.
• System functionality: Demonstrate all of the main Use Cases for your system.
• Pattern usage: Describe which design patterns you used in your code.
• Error handling: Describe how you handle common errors.
• Infrastructure: Show off your source code, build scripts, and CVS.
• Automated testing: This will be especially impressive.
• Lessons learned: What went wrong during the project, and how would you prevent it next time?

You can't cover all of these areas thoroughly in 30 minutes, so you'll have to choose the areas to emphasize that are most likely to impress the instructor and TA.

Final Submission

Final project submissions are due at the beginning of class (7:00PM) on 6th December. The submission will consist of both printed and machine-readable versions.

The printed submission must contain all project artifacts plus a table of contents. Do not include source or Javadoc printouts—there is no need to kill more trees. The submission should be bound (no loose pages) and should not contain any hand-drawn pictures.

The printed submission should include at least the following UP artifacts:

• Vision Statement
• Use Cases
• Supplementary Specification
• Glossary
• Domain Model
• Sequence Diagram (at least one)
• Operation Contract (at least one)
• Collaboration Diagram (at least one)
• Design Class Diagram(s)
• Package Diagram
• Deployment Diagram

The machine-readable version should be submitted on CD (preferred) or floppy. It must contain electronic versions of all of the printed documents, plus source code, Javadocs, and build and test scripts. Include a README.TXT file at the top level of the hierarchy. README.TXT should describe the organization of the submission, and should contain instructions for building and running your system, including detailed instructions for downloading and installing any 3rd-party components necessary.

Organize the files into a reasonable and functional directory hierarchy. The instructor should be able simply to copy the CD contents to hard disk, update CLASSPATH, and run Ant to rebuild your application.

If the submission includes any Microsoft Office documents, they must be in Office 97 format.

Exams

The midterm exam will cover all lectures, all reading assignments, and anything else discussed in any class prior to the exam date. It will probably include an extra-credit problem.

The final examination will cover all lectures, all chapters from the textbook, and anything else discussed in any class. It will probably include an extra-credit problem.

Lecture slides are available on the class Web page.

Grading

Grades for the semester will be based on:

Each student's project grade will be a combination of the group grade and an individual grade. Team members will be asked to review each other's contributions to their projects.

Policies

Exams: The course will include two exams, a midterm and a final. The lectures will introduce material not covered in the textbook, and this additional material will be on the exams. Exams will be closed-book.

Late assignments: There are no homework assignments (other than the project) in this course. There are four delivery milestones for components of the project, which must be met. No credit will be given for project materials turned in late.

Academic integrity: You will be expected to conform to the University's policy on academic integrity.

Grades by e-mail: The University has a strong policy on protecting PNPI (Personal Non-Public Information), and treats your grades as private, sensitive data. You may request that your grades for work in this class be sent to you via e-mail, but you are hereby warned that e-mail transmission is not secure and your grades may be visible to third parties.

Resources

• Violet, a simple open-source UML drawing tool
• ArgoUML, a free UML-based CASE tool
• UMLet, another UML drawing tool (closed-source, but free for educational use)
• Visual Paradigm offers a community edition of their UML modelling tool.
• Visio templates for drawing UML diagrams.
• The UML Specification is available on the Object Management Group's Web site.
• Alistair Cockburn's usecases.org site.
• The periodic table of design patterns.
• A catalog of antipatterns.
• CVSNT is a good CVS server for both Windows and Linux/Unix.
• DevGuy has a good CVS reference page.
• TortoiseCVS is a great CVS client for Windows.
• Findbugs is an excellent bug detector for Java.
• UseModWiki, a simple, flexible Wiki implementation
• How to write effective JavaDocs.
• Sometimes not using a database is a good idea.
• An excellent article about character sets and Unicode.
• Teach Yourself Programming in Ten Years!
• How to write unmaintainable code.
• How to write maintainable code.
• Are IDEs evil? Charles Petzold wonders whether Visual Studio rots the mind.
• Joel Spolsky's advice to CS majors.

Here are some recommended books:

Effective Java Programming Language Guide Joshua Bloch ISBN: 0201310058		Unit Testing In Java: How Tests Drive the Code Johannes Link ISBN: 1558608680
The Pragmatic Programmer: From Journeyman to Master Andrew Hunt & David Thomas ISBN: 020161622X		The PC is Not a Typewriter Robin Williams ISBN: 0938151495
Object-Oriented and Classical Software Engineering 6th Edition Stephen R. Schach ISBN: 0072865512		Software Engineering 6th Edition Ian Sommerville ISBN: 020139815X

Lecture materials

This section contains some of the PowerPoint slides and other materials from the lectures. Slides which duplicate material in the textbook may not be included—you should read the book instead. Many topics covered in the lectures are not on the slides but will be on the exams. Also, material in the textbook (at least in the chapters we're covering in lectures) can potentially be on the exams, whether discussed in class or not.

Remember that lecture slides are not a substitute for either attending the lectures or reading the textbook—see this version of the Gettysburg Address, this Wired article by Edward Tufte, and this Robert Cringely article for some reasons why.

Last modified: Saturday, 3 December 2005