College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001

CEG 760: Advanced Software Engineering

Dr Prabhaker Mateti, 4 Credit Hours,  Spring Qtr 2000
Course Syllabus | Projects | Due Dates | news:wright.ceg.760

   

Overview

This course is primarily about the specification, design and implementation of software systems. Prerequisite: CEG 660; see below.

This course has a home page at
http://www.cs.wright.edu/people/faculty/pmateti/Courses/760 Bookmark this and visit it periodically.

Course Content

The following is tentative. Do not expect to have lectures on each item mentioned below.

There are several running examples in the course. A few are presented in the Prerequisites section below. The Common Words Problem, and Pascal Pretty Printer are published (see the citations below). The Screen-Oriented Text Editor is well-known and may become the core of our project work. Lectures on these examples will be spread over the course, and these are not mentioned again in the topics below.

The textbook is

Software Engineering, by M. Dorfman (Editor), Richard H. Thayer (Contributor), IEEE Computer Society; ISBN: 0818676094, November 1999.

Many of the chapters will be reading assignments announced during the term.  We will also be discussing a few classic papers not included in the book.

Perspective

1.  C. A. R. Hoare, ``Programming: Sorcery or Science?'', IEEE Software, 1984, 5-16.

2.  Eric S. Raymond, ``The Cathedral and the Bazaar'',  www.kde.org/ food/cathedral/cathedral-paper.html 1997/11/12 (See also Eric Raymond's book "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary " (Sebastopol, Calif.: O'Reilly & Associates, 1999).

2b. Nikolai Bezroukov, A Second Look at the Cathedral and the Bazaar, FirstMonday.Org,  9 December 1999.  A fairly harsh critique of Eric Raymond's seminal paper.

Specification Techniques

Sets, bags, sequences, tuples, and tables; calculus of relations; higher-order functions; higher-order logic. VDM, Z, and Mateti's design specification language OM. Functions: Explicit enumeration, implicit definition, putative definitions. Procedures: Global state, initial and final values of parameters of procedures. Data Types: data invariants, abstract data types, algebraic definitions. Examples: Longest Ascending Subsequences, Columnize a List of Words. The Telegram Problem.

3.  Bertrand Meyer, ``On Formalism in Specifications,'' IEEE Software, Jan 1985, 6-26.

4.  Mateti, P., ``A Specification Schema for Indenting Programs,'' Software - Practice and Experience, Vol.13, 163-179, 1983. (Reprinted in Software Specification Techniques, McGettrick and Gehani (Eds.), Addison-Wesley 1986.)

Design Techniques and Documentation

Virtual Machines, Object Oriented Design, Event driven designs. Design patterns.  

5.  ``Introduction to Software Patterns''
http://www-white.media.mit.edu/ tpminka/patterns/intro.html
http://www-white.media.mit.edu/ tpminka/patterns/intro2.html
 

6.  Donald E Knuth, ``A Literate Program [Most Common Words],'' Communications of the ACM, Vol. 29, No. 6, 471-483.

Grading

Exams 30 + 40%

There will be a midterm exam, and a final exam (during finals week).  Examinations will test you on all the reading assignments, and exercises left for you to complete.  Unless you have previously worked out the homework problems, you will find it difficult to complete the exam problems.

Homework and other problems are expected to be discussed in our newsgroup (wright.ceg.760).

Project 30%

Project work in this course consists of developing software and associated documents, and peer reviewing others software and documents.  While you may consult with others in the project work, the specs, design and implementations must be your own personal work, not that of a group.

The percentages shown in this subsection add up to 100%, which is weighted to become 30% of the grade.  To pass the course, you must receive at least 75% for the project.

  Your Own Work Review 1 Review 2
Specification 15 5 5
Design 20 5 5
Implementation+Testing 1 10 5 5
Implementation+Testing 2 (deleted) 10 5 5
Final Report 5 - -

Your project work consists of developing a spec, a design, two implementations, and reviewing two specs by others, two designs  by others, and testing two implementations  by others.  You must turn in these referee reports within a week of being given the task. Referee reports are expected to be thorough, critical enough, not superficial, and not just nit-picking. Studying, critiquing, and revising specs and designs are essential skills in software development.

All the reports will be turned in (i.e., uploaded to your web site) as HTML files, and printed hard copies in a professional manner.

I will give the entire class the same "rough and incomplete description" of a program in the form of source code files of an existing program, and a man page for it.  The project for the course is to take this description and develop specifications (20%), design (20%) and two implementations (10 + 10%) for it. 

Each of you will get two specifications written by two of your fellow students based on the ``rough and incomplete description of a program'' to review (5%). A few weeks later, you will also get two designs based on these specs to review (5%). 

You will be developing one implementation based on your own design and another based on one of the two designs you reviewed, my choice. You may choose for the implementations either Java or C++.  These two implementations are encouraged to share as much code as you wish, but they must faithfully reflect their designs. Be aware that it is rare for specs and designs to be perfect. You are also encouraged to communicate with the designer of the second implementation to get `things' clarified, but all such clarifications must be carefully documented. Your final implementation based on your design is expected to be either 10% faster or 10% shorter in code size than the given program.  With this goal in mind, decide if you wish to reuse the design that you may discern in the given source code or start from scratch.

Two implementations by others will be source-code reviewed, and tested  (5%) by you.   

At the end of the term, you will prepare and submit a comprehensive report/portfolio (5%) that includes all your work, and revisions that you made, especially the clarifications above, in the course project.

Prerequisites

We study specs and design issues at a much deeper level than in CEG 460/660. To help you evaluate yourselves, I suggest you try a few problems such as Print Error Numbers, Condense the List of Numbers, and Simple Simultaneous Substitutions from past exams of CEG 460/660 included in the directory /usr/local/lib/Languages/660.

Due Dates

  Your Own Work Reviews
Specification April 20 April 27
Design May 16 May 23
Implementation+Testing 1 May 23 May 30
Implementation+Testing 2 (deleted)    
Final Report June 1 --
Final Exam June 6